IEEE Standard for Information technology—
Telecommunications and information exchange between systems
Local and metropolitan area networks—
Specific requirements
Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications
IEEE Computer Society
Sponsored by the
LAN/MAN Standards Committee
IEEE
3 Park Avenue IEEE Std 802.11™-2016
(Revision of
New York, NY 10016-5997
IEEE Std 802.11-2012)
USA
IEEE Std 802.11™-2016
(Revision of
IEEE Std 802.11-2012)
IEEE Standard for Information technology—
Telecommunications and information exchange between systems
Local and metropolitan area networks—
Specific requirements
Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications
Prepared by the 802.11 Working Group of the
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 7 December 2016
IEEE-SA Standards Board
Abstract: Technical corrections and clarifications to IEEE Std 802.11 for wireless local area
networks (WLANs) as well as enhancements to the existing medium access control (MAC) and
physical layer (PHY) functions are specified in this revision. Amendments 1 to 5 published in 2012
and 2013 have also been incorporated into this revision.
Keywords: 2.4 GHz, 256-QAM, 3650 MHz, 4.9 GHz, 5 GHz, 5.9 GHz, 60 GHz, advanced
encryption standard, AES, audio, beamforming, carrier sense multiple access/collision avoidance,
CCMP, channel switching, clustering, contention based access period, Counter mode with Cipher-
block chaining Message authentication code Protocol, confidentiality, CSMA/CA, DFS, direct link,
directional multi-gigabit, dynamic allocation of service period, dynamic extension of service period,
dynamic frequency selection, dynamic truncation of service period, E911, EDCA, emergency alert
system, emergency services, fast session transfer, forwarding, GCMP, generic advertisement
service, high throughput, IEEE 802.11™, international roaming, interworking, interworking with
external networks, LAN, local area network, MAC, management, measurement, medium access
control, media-independent handover, medium access controller, mesh, MIH, millimeter-wave,
MIMO, MIMO-OFDM, multi-band operation, multi-hop, multi-user MIMO, multiple input multiple
output, network advertisement, network discovery, network management, network selection,
noncontiguous frequency segments, OCB, path-selection, personal basic service set, PHY,
physical layer, power saving, QoS, quality of service, quality-of-service management frame, radio,
radio frequency, RF, radio resource, radio management, relay operation, spatial sharing, SSPN,
subscriber service provider, television white spaces, TPC, transmit power control, video, wireless
access in vehicular environments, wireless LAN, wireless local area network, WLAN, wireless
network management, zero-knowledge proof
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2016 by The Institute of Electrical and Electronics Engineers, Inc.
All rights reserved. Published 14 December 2016. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics
Engineers, Incorporated.
Print: ISBN 978-1-5044-3646-5 STD22369
PDF: ISBN 978-1-5044-3645-8 STDPD22369
IEEE Prohibits discrimination, harassment, and bullying.
For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These notices and
disclaimers, or a reference to this page, appear in all standards and may be found under the heading “Important Notices
and Disclaimers Concerning IEEE Standards Documents.” They can also be obtained on request from IEEE or viewed at
http://standards.ieee.org/IPR/disclaimers.html.
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards Docu-
ments
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are developed
within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (“IEEE-SA”)
Standards Board. IEEE (“the Institute”) develops its standards through a consensus development process, approved by
the American National Standards Institute (“ANSI”), which brings together volunteers representing varied viewpoints
and interests to achieve the final product. IEEE Standards are documents developed through scientific, academic, and
industry-based technical working groups. Volunteers in IEEE working groups are not necessarily members of the
Institute and participate without compensation from IEEE. While IEEE administers the process and establishes rules to
promote fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the
accuracy of any of the information or the soundness of any judgments contained in its standards.
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure against
interference with or from other devices or networks. Implementers and users of IEEE Standards documents are
responsible for determining and complying with all appropriate safety, security, environmental, health, and interference
protection practices and all applicable laws and regulations.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly
disclaims all warranties (express, implied and statutory) not included in this or any other document relating to the
standard, including, but not limited to, the warranties of: merchantability; fitness for a particular purpose; non-
infringement; and quality, accuracy, effectiveness, currency, or completeness of material. In addition, IEEE disclaims
any and all conditions relating to: results; and workmanlike effort. IEEE standards documents are supplied “AS IS” and
“WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there are no other
ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE
standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change
brought about through developments in the state of the art and comments received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for,
or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any other person or entity to
another. Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in
the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent
professional in determining the appropriateness of a given IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
PUBLICATION, USE OF, OR RELIANCE UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE
standard is translated, only the English version published by IEEE should be considered the approved IEEE standard.
3
Copyright © 2016 IEEE. All rights reserved.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual
shall not be considered or inferred to be the official position of IEEE or any of its committees and shall not be considered
to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an
individual presenting information on IEEE standards shall make it clear that his or her views should be considered the
personal views of that individual rather than the formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of membership
affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining to IEEE Standards
documents. Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important that
any responses to comments and questions also receive the concurrence of a balance of interests. For this reason, IEEE
and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to
comments or questions except in those cases where the matter has previously been addressed. For the same reason, IEEE
does not respond to interpretation requests. Any person who would like to participate in revisions to an IEEE standard is
welcome to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisions
of any IEEE Standards document does not imply compliance to any applicable regulatory requirements. Implementers of
the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the
publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents
may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws. They are made
available by IEEE and are adopted for a wide variety of both public and private uses. These include both use, by
reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering
practices and methods. By making these documents available for use and adoption by public authorities and private
users, IEEE does not waive any rights in copyright to the documents.
Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to photocopy portions
of any individual standard for company or organizational internal use or individual, non-commercial use only. To
arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer Service, 222 Rosewood
Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for
educational classroom use can also be obtained through the Copyright Clearance Center.
4
Copyright © 2016 IEEE. All rights reserved.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the
issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or
errata. An official IEEE document at any point in time consists of the current edition of the document together with any
amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years old and has
not undergone a revision process, it is reasonable to conclude that its contents, although still of some value, do not
wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of
any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended through the
issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at http://ieeexplore.ieee.org or contact IEEE
at the address listed previously. For more information about the IEEE SA or IEEE’s standards development process,
visit the IEEE-SA Website at http://standards.ieee.org.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL: http://
standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter covered by
patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of
any patent rights in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an
Accepted Letter of Assurance, then the statement is listed on the IEEE-SA Website at http://standards.ieee.org/about/
sasb/patcom/patents.html. Letters of Assurance may indicate whether the Submitter is willing or unwilling to grant
licenses under patent rights without compensation or under reasonable rates, with reasonable terms and conditions that
are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for
identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity
or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with
submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users
of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement
of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards
Association.
5
Copyright © 2016 IEEE. All rights reserved.
Participants
At the time this revision was sent to sponsor ballot, the IEEE 802.11 Working Group (WG) had the
following officers:
Adrian P. Stephens, Chair
Jon W. Rosdahl, 1st Vice Chair
Dorothy V. Stanley, 2nd Vice Chair
Stephen McCann, Secretary
The officers of the WG Task Group mc and the members of the WG ballot group for this revision are as
follows:
Dorothy V. Stanley, Chair
Mark A. Hamilton, Vice Chair
Jon W. Rosdahl, Secretary
Adrian P. Stephens, Technical Editor
Osama S. Aboulmagd Rojan Chitrakar Hiroshi Harada
Santosh P. Abraham Jinsoo Choi Daniel N. Harkins
Roberto Aiello Sangsung Choi Brian D. Hart
Thomas Alexander Li Chia Chia Choo Ahmadreza Hedayat
Peiman Amini Sayantan Choudhury Robert F. Heile
Sirikiat Lek Ariyavisitakul Liwen Chu Jerome Henry
Lee R. Armstrong Jinyoung Chun Chin Keong Ho
Yusuke Asai John Coffey Anh Tuan Hoang
Alex Ashley Kenneth Coop Dien Hoang
Kwok Shum Au Carlos Cordeiro Wei Hong
Vijay Auluck Neiyer Correal Ying-Chuan Hsiao
Stefan Aust Subir Das Jing-Rong Hsieh
David Bagby Hendricus De Ruijter David Hunter
Eugene Baik Rolf J. de Vegt Yasuhiko Inoue
Gabor Bajko Yohannes Demessie Mitsuru Iwaoka
Raja Banerjea Michael Denson Wuncheol Jeong
Phillip Barber Ting Dong Yangseok Jeong
Anuj Batra Xiandong Dong Sunggeun Jin
Tuncer Baykas Klaus Doppler ZhongYi Jin
Alan Berkema Roger P. Durand Nihar Jindal
Nehru Bhandaru Donald E. Eastlake V. K. Jones
Philippe Boucachard Peter Ecclesine Jari Junell
Andre Bourdoux Richard Edgar Padam Kafle
John Buffington Amal Ekbal Carl W. Kain
Lin Cai Marc Emmelmann Hyunduk Kang
George Calcev Vinko Erceg Mika Kasslin
Ping Fang Richard H. Kennedy
Chris Calvert
Stuart J. Kerry
Radhakrishna Canchi Yonggang Fang
Eunkyung Kim
Laurent Cariou Qin Fei
Jeongki Kim
William Carney Stanislav Filin
Jinho Kim
Jaesun Cha Norman Finn
Joo Young Kim
Romana Challans Matthew J. Fischer
Joonsuk Kim
Kim Chang George Flammer Suhwook Kim
Kuor-Hsin Chang Chittabrata Ghosh Taejoon Kim
Xin Chang James P. K. Gilb Youhan Kim
Clint F. Chaplin Reinhard Gloger Youngsoo Kim
Bin Chen Daning Gong Shoichi Kitazawa
Jiamin Chen David Goodall Jarkko Kneckt
Jixin Chen Elad Gottlib Gwangzeen Ko
Lidong Chen Sudheer A. Grandhi Fumihide Kojima
Qian Chen Stephen Grau Tom Kolze
Xi Chen Michael Grigat Timo Koskela
Minho Cheong David Halasz Bruce P. Kraemer
George Cherian Christopher J. Hansen Jin-Sam Kwak
Francois Chin Peng Hao Joseph Kwak
6
Copyright © 2016 IEEE. All rights reserved.
Hyoungjin Kwon Sandhya Patil Tong Tian
Young Hoon Kwon Xiaoming Peng Jens Tingleff
Paul Lambert Eldad Perahia Fei Tong
Zhou Lan James E. Petranovich Ha Nguyen Tran
Leonardo Lanante Albert Petrick Kazuyoshi Tsukada
James Lansford John Petro Masahiro Umehira
Jean-Pierre Le Rouzic Xu Ping Richard D. J. Van Nee
Anseok Lee Juho Pirskanen Allert Van Zelst
Donghun Lee Khiam Boon Png Prabodh Varshney
Jae Seung Lee Vishakan Ponnampalam Sameer Vermani
Wookbong Lee Ron Porat Dalton T. Victor
Zhongding Lei Henry S. Ptasinski Gabriel Villardi
Wai Kong Leung Rethnakaran Pulikkoonattu George A. Vlantis
Joseph Levy Chang-Woo Chang Pyo Chao Chun Wang
Feng Li Emily H. Qi Haiguang Wang
Huan-Bang Li Huyu Qu Haiming Wang
Liang Li Harish Ramamurthy James June Wang
Lingjie Li Jayaram Ramasastry Lei Wang
Yunbo Li Ivan Reede Lin Wang
Yunzhou Li Edward Reuss Qi Wang
Zhiqiang Li Maximilian Riegel Xiang Wang
Erik Lindskog Mark Rison Xuehuan Wang
Jianhan Liu Zhigang Rong Lisa Ward
Pei Liu Cheol Ryu Zou Wei-Xia
Yong Liu Kiseon Ryu Lei Wen
Zongru Liu Kazuyuki Sakoda Menzo M. Wentink
Peter Loc Ruben E. Salazar Cardozo Harya Wicaksana
Su Lu Hemanth Sampath Eric Wong
Long Luo Sigurd Schelstraete Harry R. Worstell
Yi Luo Jean Schwoerer Tianyu Wu
Zhendong Luo Jonathan Segev Zhanji Wu
Kaiying Lv Cristina Seibert Zhenyu Xiao
Michael Lynch Yongho Seok Dongmei Xu
Jouni K. Malinen Kunal Shah Quanping Xu
Hiroshi Mano Huairong Shao Guang-Qi Yang
Simone Merlin Zhenhai Shao Lin Yang
James Miller Stephen J. Shellhammer Xun Yang
Keiichi Mizutani Ian Sherlock Yunsong Yang
Apurva Mody Wei Shi Fan Ye
Michael Montemurro Nobuhiko Shibagaki James Yee
Kenichi Mori Shusaku Shimada Peter Yee
Hitoshi Morioka Chang Sub Shin Wai-Leong Yeow
Ronald Murias Thomas M. Siep Kaoru Yokoo
Andrew Myles Michael Sim Su Khiong Khiong Yong
Yukimasa Nagai Dwight Smith Christopher Young
Yuhei Nagao Graham Kenneth Smith Heejung Yu
Hiroki Nakano Myung Sun Song Zhan Yu
Chiu Ngo Sudhir Srinivasa Tevfik Yucek
Paul Nikolich Robert Stacey Guangrong Yue
Hiroyo Ogawa Lawrence Stefani Katsuo D. A. Yunoki
Minseok Oh Rene Struik Hongyuan Zhang
Min-Seok Oh Jung Hoon Suh Hui Zhang
David Olson Chin-Sean Sum Junjian Zhang
Satoshi Oyama Bo Sun Nianzu Zhang
Michael J. Paljug Chen Sun Xin Zhang
Santos Ghanshyam Pandey Sheng Sun Mu Zhao
Anna Pantelidou Kazuaki Takahashi Jun Zheng
Giwon Park Mineo Takai Shoukang Zheng
Minyoung Park Sagar Tamhane Mingtuo Zhou
Seung-Hoon Park Joseph Teo Yan Zhuang
Jaya Shankar Pathmasuntharam Thomas Tetzlaff Lan Zhuo
Jerry Thrasher
7
Copyright © 2016 IEEE. All rights reserved.
Major contributions were received from the following individuals:
Carlos Aldana Mitsuru Iwaoka Kazuyuki Sakoda
Yaron Alpert Assaf Kasher Amichai Sanderovich
Edward Au Peter Khoury Sigurd Schelstraete
Gabor Bajko Youhan Kim Yongho Seok
Sean Coffey Wookbong Lee Graham Kenneth Smith
Daniel Cohn Erik Lindskog Dorothy V. Stanley
Carlos Cordeiro Jouni K. Malinen Adrian P. Stephens
Peter Ecclesine Stephen McCann Bo Sun
Vinko Erceg Michael Montemurro Fei Tong
Matthew J. Fischer Hiroyuki Motozuka Payam Torab
Michael Fischer Andrew Myles Solomon Trainin
Mark A. Hamilton Eldad Perahia Ganesh Venkatesan
Daniel N. Harkins Emily H. Qi Qi Wang
Brian D. Hart Mark Rison Gaius Wee
Guido R. Hiertz Jon W. Rosdahl Menzo M. Wentink
Wei Hong Dick Roy Mingguang Xu
David Hunter Chen Yanming
The following members of the individual balloting committee voted on this revision. Balloters may have
voted for approval, disapproval, or abstention.
Osama S. Aboulmagd David Evans Assaf Kasher
Tomoko Adachi Zhong Fan Ruediger Kays
Iwan Adhicandra Liu Fangfang Stuart J. Kerry
Thomas Alexander Matthew J. Fischer Yongbum Kim
Richard Alfvin Michael Fischer Youhan Kim
Nobumitsu Amachi Avraham Freedman Patrick Kinney
Carol Ansley Dan Gal Bruce P. Kraemer
Butch Anton Devon Gayle Yasushi Kudoh
Yusuke Asai James P. K. Gilb Thomas Kurihara
Alfred Asterjadhi Tim Godfrey Paul Lambert
Stefan Aust Joel Goergen Jeremy Landt
Michael Bahr Randall Groves Mark Laubach
Gabor Bajko Robert Grow Hyeong Ho Lee
Phillip Barber Michael Gundlach Wookbong Lee
Tuncer Baykas Chris Guy James Lepp
Mathilde Benveniste Gloria Gwynne Joseph Levy
Harry Bims Rainer Hach Arthur H. Light
Gennaro Boggia Russell Haines William Lumpkins
Nancy Bravin Mark A. Hamilton Chris Lyttle
Theodore Brillhart Christopher J. Hansen Elvis Maculuba
Jerome Henry Jouni K. Malinen
John Buffington
James Marin
William Byrd Marco Hernandez
Roger Marks
Brent Cain Guido Hiertz
Jeffery Masters
Radhakrishna Canchi Ronald Hochnadel
Stephen McCann
Fengming Cao Werner Hoelzl
Michael McInnis
William Carney David Hunter Filip Mestanov
Juan Carreon Tetsushi Ikegami Apurva Mody
Minho Cheong Noriyuki Ikeuchi Jose Morales
Keith Chow Yasuhiko Inoue Ronald Murias
Jinyoung Chun Sergiu Iordanescu Rick Murphy
Charles Cook Akio Iso Andrew Myles
Todor Cooklev Atsushi Ito Juichi Nakada
Carlos Cordeiro Raj Jain Nabil Nasser
Steven Crowley Michael Johas Teener Michael Newman
Yezid Donoso Adri Jovin Chiu Ngo
Sourav Dutta Joe Natharoj Juisai Nicks Nikjoo
Donald E. Eastlake Naveen Kakani Paul Nikolich
Peter Ecclesine Shinkyo Kaku Satoshi Obara
Richard Edgar Hyunjeong Kang Robert O’Hara
Marc Emmelmann Piotr Karocki Yoshihiro Ohba
8
Copyright © 2016 IEEE. All rights reserved.
Satoshi Oyama Andy Scott Keat Beng Toh
Stephen Palm Yongho Seok Payam Torab
Glenn Parsons Kunal Shah Solomon Trainin
Arumugam Paventhan Ian Sherlock Ha Nguyen Tran
Brian Phelps Shusaku Shimada Kazuyoshi Tsukada
Walter Pienciak Robert Slater Mark-Rene Uchida
Subburajan Ponnuswamy Di Dieter Smely Lorenzo Vangelista
Clinton Powell Graham Kenneth Smith Allert Van Zelst
Venkatesha Prasad Daniel Smolinski Dmitri Varsanofiev
Emily H. Qi Kapil Sood Prabodh Varshney
R. K. Rannow Robert Stacey Ganesh Venkatesan
George A. Vlantis
Maximilian Riegel Dorothy V. Stanley
Khurram Waheed
Mark Rison Thomas Starai
Haiming Wang
Robert Robinson Adrian P. Stephens Lei Wang
Benjamin Rolfe Rene Struik Stephen Webb
Jon W. Rosdahl Walter Struppler Hung-Yu Wei
Kazuyuki Sakoda Mark Sturza Menzo M. Wentink
Osman Sakr Rakesh Taori Chun Yu Charles Wong
Amichai Sanderovich David Tepen Forrest Wright
John Santhoff Patricia Thaler James Yee
Naotaka Sato David Thompson Oren Yuen
Bartien Sayogo Edward Tiedemann Daidi Zhong
Sigurd Schelstraete Jens Tingleff Zhen Zhou
When the IEEE-SA Standards Board approved this revision on 7 December 2016, it had the following
membership:
Jean-Philippe Faure, Chair
Ted Burse, Vice Chair
John D. Kulick, Past Chair
Konstantinos Karachalios, Secretary
Chuck Adams Ronald W. Hotchkiss Mehmet Ulema
Masayuki Ariyoshi Michael Janezic Yingli Wen
Stephen Dukes Joseph L. Koepfinger* Howard Wolfman
Jianbin Fan Hung Ling Don Wright
J. Travis Griffith Kevin Lu Yu Yuan
Gary Hoffman Annette D. Reilly Daidi Zhong
Gary Robinson
*Member Emeritus
9
Copyright © 2016 IEEE. All rights reserved.
Introduction
This introduction is not part of IEEE Std 802.11-2016, IEEE Standard for Information technology—
Telecommunications and information exchange between systems—Local and metropolitan area network—Specific
requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
This revision gives users, in one document, the IEEE 802.11 standard for wireless local area networks
(WLANs) with all of the amendments that have been published to date.
Incorporating published amendments
The original standard was published in 1997, revised in 1999 with MIB changes, and reaffirmed in 2003.
A revision was published in 2007, which incorporated into the 1999 edition the following amendments:
— IEEE Std 802.11a™-1999: High-speed Physical Layer in the 5 GHz Band (Amendment 1)
— IEEE Std 802.11b™-1999: Higher-Speed Physical Layer Extension in the 2.4 GHz Band
(Amendment 2)
— IEEE Std 802.11b-1999/Corrigendum 1-2001: Higher-speed Physical Layer (PHY) extension in the
2.4 GHz band (Corrigendum 1 to Amendment 2)
— IEEE Std 802.11d™-2001: Specification for operation in additional regulatory domains
(Amendment 3)
— IEEE Std 802.11g™-2003: Further Higher Data Rate Extension in the 2.4 GHz Band (Amendment
4)
— IEEE Std 802.11h™-2003: Spectrum and Transmit Power Management Extensions in the 5 GHz
band in Europe (Amendment 5)
— IEEE Std 802.11i™-2004: Medium Access Control (MAC) Security Enhancements (Amendment 6)
— IEEE Std 802.11j™-2004: 4.9 GHz–5 GHz Operation in Japan (Amendment 7)
— IEEE Std 802.11e™-2005: Medium Access Control (MAC) Quality of Service Enhancements
(Amendment 8)
A revision was published in 2012, which incorporated into the 2007 revision the following amendments:
— IEEE Std 802.11k™-2008: Radio Resource Measurement of Wireless LANs (Amendment 1)
— IEEE Std 802.11r™-2008: Fast Basic Service Set (BSS) Transition (Amendment 2)
— IEEE Std 802.11y™-2008: 3650–3700 MHz Operation in USA (Amendment 3)
— IEEE Std 802.11w™-2009: Protected Management Frames (Amendment 4)
— IEEE Std 802.11n™-2009: Enhancements for Higher Throughput (Amendment 5)
— IEEE Std 802.11p™-2010: Wireless Access in Vehicular Environments (Amendment 6)
— IEEE Std 802.11z™-2010: Extensions to Direct-Link Setup (DLS) (Amendment 7)
— IEEE Std 802.11v™-2011: Wireless Network Management (Amendment 8)
— IEEE Std 802.11u™-2011: Interworking with External Networks (Amendment 9)
— IEEE Std 802.11s™-2011: Mesh Networking (Amendment 10)
This revision is based on IEEE Std 802.11-2012, into which the following amendments have been
incorporated:
— IEEE Std 802.11ae™-2012: Prioritization of Management Frames (Amendment 1)
— IEEE Std 802.11aa™-2012: MAC Enhancements for Robust Audio Video Streaming
(Amendment 2)
10
Copyright © 2016 IEEE. All rights reserved.
— IEEE Std 802.11ad™-2012: Enhancements for Very High Throughput in the 60 GHz Band
(Amendment 3)
— IEEE Std 802.11ac™-2013: Enhancements for Very High Throughput for Operation in Bands
below 6 GHz (Amendment 4)
— IEEE Std 802.11af™-2013: Television White Spaces (TVWS) Operation (Amendment 5)
Technical corrections, clarifications, and enhancements
In addition, this revision specifies technical corrections and clarifications to IEEE Std 802.11 as well as
enhancements to the existing medium access control (MAC) and physical layer (PHY) functions. In
addition, this revision removes some features previously marked as obsolete and adds new indications of
other obsolete features.
11
Copyright © 2016 IEEE. All rights reserved.
Renumbering of clauses and annexes
The numbering of certain clauses and annexes has been modified since IEEE Std 802.11-2012.
The evolution of this numbering is shown in Figure i.
Key:
Unchanged
Changed
Deleted
Amendments to Amendments to
IEEE Std 802.11‐2007 IEEE Std 802.11‐2012 IEEE Std 802.11‐
802.11‐2007 802.11‐2012
Clause 1 Clause 1 Clause 1
Clause 2 Clause 2 Clause 2
Clause 3 Clause 3 Clause 3
3.3
Clause 4 Clause 4
Clause 4
Clause 5 Clause 5
Clause 5
Clause 6 Clause 6
Clause 6
Clause 7 Clause 7
6.4
Clause 8 Clause 7 Clause 8
Clause 9 7.4 Clause 9
Clause 10 Clause 8 Clause 10
Clause 11 Clause 9 Clause 11
802.11w: Clause 11A Clause 10 Clause 12
801.11u: Clause 11B Clause 11 Clause 13
802.11s: Clause 11C Clause 12 Clause 14
Clause 12 Clause 13 Clause 15
Clause 13 Clause 14 Clause 16
Clause 14 Clause 15 Clause 17
Clause 15 Clause 16 Clause 18
Clause 16 Clause 17 Clause 19
Clause 17 Clause 18 Clause 20
Clause 18 Clause 19 Clause 21
Clause 19 Clause 20 Clause 22
802.11n: Clause 20 802.11ad: Clause 21 Annex A
Annex A 802.11ac: Clause 22 Annex B
Annex B 802.11af: Clause 23 Annex C
Normative
Annex C Annex A Annex D
Annexes
Annex D Annex B Annex E
Annex E Annex C Annex F
Annex F Annex D Annex G
Annex G Annex E Annex H
Annex H Annex F Annex I
Annex I Annex G Annex J
Annex J Annex H Annex K
Annex K Annex I Annex L
Annex L Annex J Annex M
Informative
Annex M Annex K Annex N
Annexes
Annex N Annex L Annex O
Annex O Annex M Annex P
Annex P Annex N Annex Q
Annex O Annex R
802.11k: Annex Q Annex P Annex S
802.11n: Annex R Annex Q Annex T
802.11n: Annex S Annex R Annex U
802.11n: Annex T Annex S Annex V
802.11z: Annex U Annex T
802.11v: Annex V Annex U 802.11aa: Annex X
802.11v: Annex W Annex V 802.11ad: Annex Y
802.11u: Annex X Annex W 802.11ad: Annex Z
802.11s: Annex Y
Figure i—The evolution of numbering in IEEE Std 802.11
12
Copyright © 2016 IEEE. All rights reserved.
Contents
1. Overview............................................................................................................................................ 122
1.1 Scope...................................................................................................................................... 122
1.2 Purpose................................................................................................................................... 122
1.3 Supplementary information on purpose................................................................................. 122
1.4 Word usage ............................................................................................................................ 123
1.5 Terminology for mathematical, logical, and bit operations................................................... 124
2. Normative references ......................................................................................................................... 125
3. Definitions, acronyms, and abbreviations.......................................................................................... 128
3.1 Definitions ............................................................................................................................. 128
3.2 Definitions specific to IEEE Std 802.11 ................................................................................ 143
3.3 Definitions specific to IEEE 802.11 operation in some regulatory domains......................... 170
3.4 Abbreviations and acronyms ................................................................................................. 170
3.5 Abbreviations and acronyms in some regulatory domains .................................................... 182
4. General description ............................................................................................................................ 183
4.1 General description of the architecture .................................................................................. 183
4.2 How wireless local area networks (WLANs) are different.................................................... 183
4.2.1 Introduction............................................................................................................ 183
4.2.2 Wireless station (STA)........................................................................................... 183
4.2.3 Media impact on design and performance ............................................................. 183
4.2.4 The impact of handling mobile STAs.................................................................... 184
4.2.5 Interaction with other IEEE 802® layers............................................................... 184
4.2.6 Interaction with non-IEEE-802 protocols.............................................................. 184
4.3 Components of the IEEE 802.11 architecture ....................................................................... 184
4.3.1 General................................................................................................................... 184
4.3.2 The independent BSS (IBSS) ................................................................................ 185
4.3.3 The personal BSS (PBSS)...................................................................................... 185
4.3.4 STA membership in a BSS is dynamic.................................................................. 185
4.3.5 Distribution system (DS) concepts ........................................................................ 186
4.3.5.1 Overview............................................................................................. 186
4.3.5.2 Extended service set (ESS): the large coverage network.................... 187
4.3.6 Area concepts......................................................................................................... 188
4.3.7 Integration with non-IEEE-802.11 LANs.............................................................. 189
4.3.8 Robust security network association (RSNA) ....................................................... 190
4.3.9 Centralized coordination service set (CCSS) and extended centralized
AP or PCP clustering (ECAPC)............................................................................. 190
4.3.10 QoS BSS ................................................................................................................ 192
4.3.11 Wireless LAN radio measurements ....................................................................... 193
4.3.11.1 General ................................................................................................ 193
4.3.11.2 Beacon................................................................................................. 194
4.3.11.3 Measurement pilot............................................................................... 194
4.3.11.4 Frame .................................................................................................. 194
4.3.11.5 Channel load ....................................................................................... 195
4.3.11.6 Noise histogram .................................................................................. 195
4.3.11.7 STA statistics ...................................................................................... 195
4.3.11.8 Location .............................................................................................. 195
4.3.11.9 Measurement pause............................................................................. 195
13
Copyright © 2016 IEEE. All rights reserved.
4.3.11.10 Neighbor report ................................................................................... 195
4.3.11.11 Link measurement............................................................................... 195
4.3.11.12 Transmit stream/category measurement ............................................. 195
4.3.12 Operation in licensed frequency bands .................................................................. 196
4.3.12.1 General ................................................................................................ 196
4.3.12.2 Dynamic STA enablement (DSE) in licensed bands .......................... 196
4.3.12.3 Contention based protocol (CBP) in nonexclusively licensed bands . 196
4.3.12.4 Using DSE STA identification to resolve interference....................... 196
4.3.12.5 Further coexistence enhancements in nonexclusively licensed bands 196
4.3.13 High-throughput (HT) STA ................................................................................... 196
4.3.14 Very high throughput (VHT) STA ........................................................................ 197
4.3.15 Television very high throughput (TVHT) STA ..................................................... 198
4.3.16 STA transmission of Data frames outside the context of a BSS ........................... 199
4.3.17 Tunneled direct-link setup ..................................................................................... 200
4.3.18 Wireless network management .............................................................................. 200
4.3.18.1 Overview............................................................................................. 200
4.3.18.2 BSS max idle period management ...................................................... 201
4.3.18.3 BSS transition management ................................................................ 201
4.3.18.4 Channel usage ..................................................................................... 201
4.3.18.5 Collocated interference reporting........................................................ 201
4.3.18.6 Diagnostic reporting............................................................................ 201
4.3.18.7 Directed multicast service (DMS)....................................................... 201
4.3.18.8 Event reporting.................................................................................... 202
4.3.18.9 Flexible multicast service (FMS)........................................................ 202
4.3.18.10 Location services................................................................................. 202
4.3.18.11 Multicast Diagnostic report................................................................. 202
4.3.18.12 Multiple BSSID capability.................................................................. 202
4.3.18.13 Proxy ARP .......................................................................................... 202
4.3.18.14 QoS traffic capability .......................................................................... 202
4.3.18.15 SSID list .............................................................................................. 203
4.3.18.16 Triggered STA statistics...................................................................... 203
4.3.18.17 TIM broadcast ..................................................................................... 203
4.3.18.18 Timing measurement........................................................................... 203
4.3.18.19 Fine timing measurement.................................................................... 203
4.3.18.20 Traffic filtering service ....................................................................... 203
4.3.18.21 U-APSD coexistence........................................................................... 203
4.3.18.22 WNM notification ............................................................................... 203
4.3.18.23 WNM sleep mode ............................................................................... 204
4.3.19 Subscription service provider network (SSPN) interface ...................................... 204
4.3.20 Mesh BSS .............................................................................................................. 205
4.3.20.1 General ................................................................................................ 205
4.3.20.2 Overview of the mesh BSS ................................................................. 205
4.3.20.3 Mesh STA ........................................................................................... 205
4.3.20.4 IEEE 802.11 components and mesh BSS ........................................... 206
4.3.20.5 Introduction to mesh functions ........................................................... 207
4.3.21 DMG STA.............................................................................................................. 210
4.3.22 DMG relay ............................................................................................................. 211
4.3.23 Robust audio video (AV) streaming ...................................................................... 211
4.3.23.1 Groupcast with retries (GCR) ............................................................. 211
4.3.23.2 Stream classification service (SCS) .................................................... 212
4.3.23.3 Overlapping BSS (OBSS) management ............................................. 212
4.3.23.4 Interworking with IEEE 802.1Q™ Stream Reservation Protocol
(SRP)................................................................................................... 212
4.3.23.5 Intra-access category prioritization ..................................................... 212
14
Copyright © 2016 IEEE. All rights reserved.
4.3.24 Operation under geolocation database (GDB) control .......................................... 213
4.4 Logical service interfaces ...................................................................................................... 215
4.4.1 General................................................................................................................... 215
4.4.2 SS ........................................................................................................................... 215
4.4.3 PBSS control point service (PCPS) ....................................................................... 216
4.4.4 DSS ........................................................................................................................ 216
4.5 Overview of the services........................................................................................................ 217
4.5.1 General................................................................................................................... 217
4.5.2 Distribution of MSDUs within a DS...................................................................... 218
4.5.2.1 Distribution ......................................................................................... 218
4.5.2.2 Integration ........................................................................................... 219
4.5.2.3 QoS traffic scheduling ........................................................................ 219
4.5.3 Services that support the distribution service and the PCP service ....................... 220
4.5.3.1 General ................................................................................................ 220
4.5.3.2 Mobility types ..................................................................................... 220
4.5.3.3 Association.......................................................................................... 220
4.5.3.4 Reassociation ...................................................................................... 221
4.5.3.5 Disassociation ..................................................................................... 221
4.5.4 Access control and data confidentiality services ................................................... 222
4.5.4.1 General ................................................................................................ 222
4.5.4.2 Authentication..................................................................................... 222
4.5.4.3 Deauthentication ................................................................................. 223
4.5.4.4 Data confidentiality............................................................................. 223
4.5.4.5 Key management................................................................................. 224
4.5.4.6 Data origin authenticity....................................................................... 224
4.5.4.7 Replay detection.................................................................................. 224
4.5.4.8 Fast BSS transition.............................................................................. 225
4.5.4.9 Robust management frame protection ................................................ 225
4.5.5 Spectrum management services............................................................................. 225
4.5.5.1 General ................................................................................................ 225
4.5.5.2 TPC ..................................................................................................... 225
4.5.5.3 DFS ..................................................................................................... 225
4.5.6 Traffic differentiation and QoS support................................................................. 226
4.5.6.1 General ................................................................................................ 226
4.5.6.2 Quality-of-service management frame support................................... 226
4.5.7 Support for higher layer timer synchronization ..................................................... 226
4.5.8 Radio measurement service ................................................................................... 227
4.5.9 Interworking with external networks ..................................................................... 227
4.5.10 Generic advertisement service (GAS) ................................................................... 228
4.6 Multiple logical address spaces ............................................................................................. 228
4.7 Differences among ESS, PBSS, and IBSS LANs.................................................................. 229
4.8 Differences between ESS and MBSS LANs ......................................................................... 231
4.9 Reference model .................................................................................................................... 231
4.9.1 General................................................................................................................... 231
4.9.2 Interworking reference model................................................................................ 231
4.9.3 Reference model for supporting multiple MAC sublayers .................................... 233
4.9.4 Reference model for multi-band operation ............................................................ 234
4.10 IEEE Std 802.11 and IEEE Std 802.1X-2010 ....................................................................... 236
4.10.1 General................................................................................................................... 236
4.10.2 IEEE 802.11 usage of IEEE Std 802.1X-2010 ...................................................... 236
4.10.3 Infrastructure functional model overview.............................................................. 237
4.10.3.1 General ................................................................................................ 237
4.10.3.2 AKM operations with AS ................................................................... 237
4.10.3.3 AKM operations with a password or PSK .......................................... 239
15
Copyright © 2016 IEEE. All rights reserved.
4.10.3.4 Alternate operations with PSK............................................................ 240
4.10.3.5 Disassociation ..................................................................................... 241
4.10.4 IBSS functional model description ........................................................................ 241
4.10.4.1 General ................................................................................................ 241
4.10.4.2 Key usage............................................................................................ 241
4.10.4.3 Sample IBSS 4-way handshakes......................................................... 241
4.10.4.4 IBSS IEEE 802.1X example ............................................................... 243
4.10.5 PBSS functional model description ....................................................................... 244
4.10.6 Authenticator-to-AS protocol ................................................................................ 245
4.10.7 PMKSA caching .................................................................................................... 245
4.10.8 Protection of group addressed robust Management frames................................... 245
5. MAC service definition ..................................................................................................................... 246
5.1 Overview of MAC services ................................................................................................... 246
5.1.1 Data service............................................................................................................ 246
5.1.1.1 General ................................................................................................ 246
5.1.1.2 Determination of UP ........................................................................... 246
5.1.1.3 Interpretation of priority parameter in MAC service primitives......... 246
5.1.1.4 Interpretation of service class parameter in MAC service
primitives in a STA ............................................................................. 247
5.1.2 Security services .................................................................................................... 248
5.1.3 MSDU ordering ..................................................................................................... 248
5.1.4 MSDU format ........................................................................................................ 249
5.1.5 MAC data service architecture .............................................................................. 250
5.1.5.1 General ................................................................................................ 250
5.1.5.2 Non-AP STA role................................................................................ 253
5.1.5.3 AP role ................................................................................................ 253
5.1.5.4 Mesh STA role .................................................................................... 253
5.1.5.5 Mesh gate role..................................................................................... 254
5.2 MAC data service specification ............................................................................................. 254
5.2.1 General................................................................................................................... 254
5.2.2 MA-UNITDATA.request ...................................................................................... 254
5.2.2.1 Function .............................................................................................. 254
5.2.2.2 Semantics of the service primitive ...................................................... 255
5.2.2.3 When generated................................................................................... 255
5.2.2.4 Effect of receipt................................................................................... 255
5.2.3 MA-UNITDATA.indication .................................................................................. 257
5.2.3.1 Function .............................................................................................. 257
5.2.3.2 Semantics of the service primitive ...................................................... 257
5.2.3.3 When generated................................................................................... 257
5.2.3.4 Effect of receipt................................................................................... 258
5.2.4 MA-UNITDATA-STATUS.indication.................................................................. 259
5.2.4.1 Function .............................................................................................. 259
5.2.4.2 Semantics of the service primitive ...................................................... 259
5.2.4.3 When generated................................................................................... 261
5.2.4.4 Effect of receipt................................................................................... 261
6. Layer management............................................................................................................................. 262
6.1 Overview of management model ........................................................................................... 262
6.2 Generic management primitives ............................................................................................ 263
6.3 MLME SAP interface ............................................................................................................ 263
6.3.1 Introduction............................................................................................................ 263
16
Copyright © 2016 IEEE. All rights reserved.
6.3.2 Power management................................................................................................ 264
6.3.2.1 Introduction......................................................................................... 264
6.3.2.2 MLME-POWERMGT.request............................................................ 264
6.3.2.3 MLME-POWERMGT.confirm........................................................... 264
6.3.3 Scan........................................................................................................................ 265
6.3.3.1 Introduction......................................................................................... 265
6.3.3.2 MLME-SCAN.request ........................................................................ 265
6.3.3.3 MLME-SCAN.confirm ....................................................................... 267
6.3.4 Synchronization ..................................................................................................... 276
6.3.4.1 Introduction......................................................................................... 276
6.3.4.2 MLME-JOIN.request .......................................................................... 276
6.3.4.3 MLME-JOIN.confirm ......................................................................... 278
6.3.5 Authenticate ........................................................................................................... 279
6.3.5.1 Introduction......................................................................................... 279
6.3.5.2 MLME-AUTHENTICATE.request .................................................... 279
6.3.5.3 MLME-AUTHENTICATE.confirm ................................................... 280
6.3.5.4 MLME-AUTHENTICATE.indication................................................ 282
6.3.5.5 MLME-AUTHENTICATE.response.................................................. 283
6.3.6 Deauthenticate ....................................................................................................... 284
6.3.6.1 Introduction......................................................................................... 284
6.3.6.2 MLME-DEAUTHENTICATE.request............................................... 284
6.3.6.3 MLME-DEAUTHENTICATE.confirm.............................................. 285
6.3.6.4 MLME-DEAUTHENTICATE.indication .......................................... 285
6.3.7 Associate ................................................................................................................ 286
6.3.7.1 Introduction......................................................................................... 286
6.3.7.2 MLME-ASSOCIATE.request............................................................. 286
6.3.7.3 MLME-ASSOCIATE.confirm............................................................ 288
6.3.7.4 MLME-ASSOCIATE.indication ........................................................ 292
6.3.7.5 MLME-ASSOCIATE.response .......................................................... 295
6.3.8 Reassociate............................................................................................................. 297
6.3.8.1 Introduction......................................................................................... 297
6.3.8.2 MLME-REASSOCIATE.request........................................................ 297
6.3.8.3 MLME-REASSOCIATE.confirm....................................................... 299
6.3.8.4 MLME-REASSOCIATE.indication ................................................... 303
6.3.8.5 MLME-REASSOCIATE.response ..................................................... 306
6.3.9 Disassociate ........................................................................................................... 309
6.3.9.1 MLME-DISASSOCIATE.request ...................................................... 309
6.3.9.2 MLME-DISASSOCIATE.confirm ..................................................... 309
6.3.9.3 MLME-DISASSOCIATE.indication.................................................. 310
6.3.10 Reset....................................................................................................................... 310
6.3.10.1 Introduction......................................................................................... 310
6.3.10.2 MLME-RESET.request....................................................................... 311
6.3.11 Start ........................................................................................................................ 311
6.3.11.1 Introduction......................................................................................... 311
6.3.11.2 MLME-START.request ...................................................................... 311
6.3.11.3 MLME-START.confirm ..................................................................... 317
6.3.12 Stop ........................................................................................................................ 317
6.3.12.1 General ................................................................................................ 317
6.3.12.2 MLME-STOP.request ......................................................................... 317
6.3.13 Protocol layer model for spectrum management and radio measurement............. 318
6.3.14 Measurement request ............................................................................................. 321
6.3.14.1 Introduction......................................................................................... 321
6.3.14.2 MLME-MREQUEST.request ............................................................. 321
6.3.14.3 MLME-MREQUEST.indication......................................................... 322
17
Copyright © 2016 IEEE. All rights reserved.
6.3.15 Channel measurement............................................................................................ 323
6.3.15.1 Introduction......................................................................................... 323
6.3.15.2 MLME-MEASURE.request................................................................ 323
6.3.15.3 MLME-MEASURE.confirm............................................................... 324
6.3.16 Measurement report ............................................................................................... 325
6.3.16.1 Introduction......................................................................................... 325
6.3.16.2 MLME-MREPORT.request................................................................ 325
6.3.16.3 MLME-MREPORT.indication ........................................................... 326
6.3.17 Channel switch....................................................................................................... 327
6.3.17.1 MLME-CHANNELSWITCH.request ................................................ 327
6.3.17.2 MLME-CHANNELSWITCH.confirm ............................................... 328
6.3.17.3 MLME-CHANNELSWITCH.indication............................................ 328
6.3.17.4 MLME-CHANNELSWITCH.response.............................................. 329
6.3.18 TPC request............................................................................................................ 331
6.3.18.1 Introduction......................................................................................... 331
6.3.18.2 MLME-TPCADAPT.request .............................................................. 331
6.3.18.3 MLME-TPCADAPT.confirm ............................................................. 331
6.3.19 SetKeys .................................................................................................................. 332
6.3.19.1 MLME-SETKEYS.request ................................................................. 332
6.3.20 DeleteKeys............................................................................................................. 333
6.3.20.1 MLME-DELETEKEYS.request ......................................................... 333
6.3.21 MIC (michael) failure event .................................................................................. 334
6.3.21.1 MLME-MICHAELMICFAILURE.indication.................................... 334
6.3.22 EAPOL................................................................................................................... 335
6.3.22.1 MLME-EAPOL.request...................................................................... 335
6.3.22.2 MLME-EAPOL.confirm..................................................................... 336
6.3.23 MLME-PEERKEY-START .................................................................................. 336
6.3.23.1 MLME-PEERKEY-START.request................................................... 336
6.3.24 SetProtection .......................................................................................................... 337
6.3.24.1 MLME-SETPROTECTION.request................................................... 337
6.3.25 MLME-PROTECTEDFRAMEDROPPED ........................................................... 338
6.3.25.1 MLME- PROTECTEDFRAMEDROPPED.indication ...................... 338
6.3.26 TS management interface ...................................................................................... 338
6.3.26.1 General ................................................................................................ 338
6.3.26.2 MLME-ADDTS.request ..................................................................... 339
6.3.26.3 MLME-ADDTS.confirm .................................................................... 341
6.3.26.4 MLME-ADDTS.indication ................................................................. 344
6.3.26.5 MLME-ADDTS.response ................................................................... 346
6.3.26.6 MLME-DELTS.request ...................................................................... 349
6.3.26.7 MLME-DELTS.indication.................................................................. 350
6.3.26.8 MLME-ADDTSRESERVE.request ................................................... 351
6.3.26.9 MLME-ADDTSRESERVE.confirm................................................... 352
6.3.26.10 MLME-ADDTSRESERVE.indication ............................................... 353
6.3.26.11 MLME-ADDTSRESERVE.response ................................................. 354
6.3.27 Management of direct links ................................................................................... 354
6.3.27.1 Introduction......................................................................................... 354
6.3.27.2 MLME-DLS.request ........................................................................... 355
6.3.27.3 MLME-DLS.confirm .......................................................................... 355
6.3.27.4 MLME-DLS.indication....................................................................... 356
6.3.27.5 MLME-DLS.response......................................................................... 357
6.3.27.6 MLME-DLS-TEARDOWN.request ................................................... 358
6.3.27.7 MLME-DLS-TEARDOWN.indication............................................... 359
6.3.28 Higher layer synchronization support.................................................................... 360
6.3.28.1 Introduction......................................................................................... 360
18
Copyright © 2016 IEEE. All rights reserved.
6.3.28.2 MLME-HL-SYNC.request ................................................................. 360
6.3.28.3 MLME-HL-SYNC.indication ............................................................. 361
6.3.29 Block Ack .............................................................................................................. 361
6.3.29.1 General ................................................................................................ 361
6.3.29.2 MLME-ADDBA.request..................................................................... 361
6.3.29.3 MLME-ADDBA.confirm ................................................................... 363
6.3.29.4 MLME-ADDBA.indication ................................................................ 364
6.3.29.5 MLME-ADDBA.response .................................................................. 365
6.3.29.6 MLME-DELBA.request ..................................................................... 367
6.3.29.7 MLME-DELBA.indication ................................................................. 368
6.3.30 Schedule element management.............................................................................. 369
6.3.30.1 Introduction......................................................................................... 369
6.3.30.2 MLME-SCHEDULE.request.............................................................. 369
6.3.30.3 MLME-SCHEDULE.indication ......................................................... 369
6.3.31 Vendor-specific action ........................................................................................... 370
6.3.31.1 Introduction......................................................................................... 370
6.3.31.2 MLME-VSPECIFIC.request............................................................... 370
6.3.31.3 MLME-VSPECIFIC.indication .......................................................... 371
6.3.32 Neighbor report request ......................................................................................... 372
6.3.32.1 General ................................................................................................ 372
6.3.32.2 MLME-NEIGHBORREPREQ.request............................................... 372
6.3.32.3 MLME-NEIGHBORREPREQ.indication .......................................... 373
6.3.33 Neighbor report response....................................................................................... 374
6.3.33.1 General ................................................................................................ 374
6.3.33.2 MLME-NEIGHBORREPRESP.request ............................................. 374
6.3.33.3 MLME-NEIGHBORREPRESP.indication......................................... 375
6.3.34 Link Measure Request ........................................................................................... 376
6.3.34.1 General ................................................................................................ 376
6.3.34.2 MLME-LINKMEASURE.request ...................................................... 376
6.3.34.3 MLME-LINKMEASURE.confirm ..................................................... 377
6.3.35 MLME SAP interface for resource request ........................................................... 378
6.3.35.1 MLME-RESOURCE-REQUEST.request........................................... 378
6.3.35.2 MLME-RESOURCE-REQUEST.indication ...................................... 379
6.3.35.3 MLME-RESOURCE-REQUEST.response ........................................ 380
6.3.35.4 MLME-RESOURCE-REQUEST.confirm ......................................... 380
6.3.35.5 MLME-RESOURCE-REQUEST-LOCAL.request............................ 381
6.3.35.6 MLME-RESOURCE-REQUEST-LOCAL.confirm........................... 382
6.3.36 MLME SAP interface for remote requests ............................................................ 382
6.3.36.1 MLME-REMOTE-REQUEST.request ............................................... 382
6.3.36.2 MLME-REMOTE-REQUEST.indication........................................... 383
6.3.37 Extended channel switch announcement ............................................................... 383
6.3.37.1 General ................................................................................................ 383
6.3.37.2 MLME-EXTCHANNELSWITCH.request......................................... 384
6.3.37.3 MLME-EXTCHANNELSWITCH.confirm ....................................... 385
6.3.37.4 MLME-EXTCHANNELSWITCH.indication .................................... 385
6.3.37.5 MLME-EXTCHANNELSWITCH.response ...................................... 387
6.3.38 DSE power constraint announcement.................................................................... 388
6.3.38.1 General ................................................................................................ 388
6.3.38.2 MLME-DSETPC.request.................................................................... 388
6.3.38.3 MLME-DSETPC.confirm................................................................... 389
6.3.38.4 MLME-DSETPC.indication ............................................................... 390
6.3.38.5 MLME-DSETPC.response ................................................................. 390
6.3.39 Enablement ............................................................................................................ 391
6.3.39.1 General ................................................................................................ 391
19
Copyright © 2016 IEEE. All rights reserved.
6.3.39.2 MLME-ENABLEMENT.request........................................................ 391
6.3.39.3 MLME-ENABLEMENT.confirm....................................................... 392
6.3.39.4 MLME-ENABLEMENT.indication ................................................... 393
6.3.39.5 MLME-ENABLEMENT.response ..................................................... 394
6.3.40 Deenablement ........................................................................................................ 395
6.3.40.1 MLME-DEENABLEMENT.request .................................................. 395
6.3.40.2 MLME-DEENABLEMENT.indication.............................................. 396
6.3.41 SA Query support .................................................................................................. 397
6.3.41.1 MLME-SA-QUERY.request............................................................... 397
6.3.41.2 MLME-SA-QUERY.confirm ............................................................. 398
6.3.41.3 MLME-SA-QUERY.indication .......................................................... 398
6.3.41.4 MLME-SA-QUERY.response ............................................................ 399
6.3.42 Get TSF timer ........................................................................................................ 400
6.3.42.1 General ................................................................................................ 400
6.3.42.2 MLME-GETTSFTIME.request .......................................................... 400
6.3.42.3 MLME-GETTSFTIME.confirm ......................................................... 400
6.3.43 Timing Advertisement ........................................................................................... 401
6.3.43.1 General ................................................................................................ 401
6.3.43.2 MLME-TIMING-ADVERTISEMENT.request ................................. 401
6.3.43.3 MLME-TIMING-ADVERTISEMENT.indication ............................. 402
6.3.44 TDLS Discovery .................................................................................................... 403
6.3.44.1 General ................................................................................................ 403
6.3.44.2 MLME-TDLSDISCOVERY.request.................................................. 403
6.3.44.3 MLME-TDLSDISCOVERY.confirm................................................. 404
6.3.44.4 MLME-TDLSDISCOVERY.indication ............................................. 405
6.3.44.5 MLME-TDLSDISCOVERY.response ............................................... 405
6.3.45 TDLS direct-link establishment............................................................................. 406
6.3.45.1 General ................................................................................................ 406
6.3.45.2 MLME-TDLSSETUPREQUEST.request........................................... 406
6.3.45.3 MLME-TDLSSETUPREQUEST.indication ...................................... 407
6.3.45.4 MLME-TDLSSETUPRESPONSE.request......................................... 408
6.3.45.5 MLME-TDLSSETUPRESPONSE.indication .................................... 409
6.3.45.6 MLME-TDLSSETUPCONFIRM.request .......................................... 409
6.3.45.7 MLME-TDLSSETUPCONFIRM.indication...................................... 410
6.3.45.8 MLME-TDLSPOTENTIALPEERSTA.request ................................. 410
6.3.45.9 MLME-TDLSPOTENTIALPEERSTA.confirm ................................ 411
6.3.46 TDLS direct-link teardown .................................................................................... 412
6.3.46.1 General ................................................................................................ 412
6.3.46.2 MLME-TDLSTEARDOWN.request.................................................. 412
6.3.46.3 MLME-TDLSTEARDOWN.indication ............................................. 413
6.3.47 TDLS peer U-APSD (TPU) ................................................................................... 413
6.3.47.1 General ................................................................................................ 413
6.3.47.2 MLME-TDLSPTI.request................................................................... 414
6.3.47.3 MLME-TDLSPTI.confirm.................................................................. 415
6.3.47.4 MLME-TDLSPTI.indication .............................................................. 415
6.3.47.5 MLME-TDLSPTI.response ................................................................ 416
6.3.48 TDLS channel switching ....................................................................................... 417
6.3.48.1 General ................................................................................................ 417
6.3.48.2 MLME-TDLSCHANNELSWITCH.request ...................................... 417
6.3.48.3 MLME-TDLSCHANNELSWITCH.confirm ..................................... 418
6.3.48.4 MLME-TDLSCHANNELSWITCH.indication.................................. 419
6.3.48.5 MLME-TDLSCHANNELSWITCH.response.................................... 419
6.3.49 TDLS peer PSM..................................................................................................... 420
6.3.49.1 General ................................................................................................ 420
20
Copyright © 2016 IEEE. All rights reserved.
6.3.49.2 MLME-TDLSPEERPSM.request ....................................................... 420
6.3.49.3 MLME-TDLSPEERPSM.confirm...................................................... 421
6.3.49.4 MLME-TDLSPEERPSM.indication................................................... 422
6.3.49.5 MLME-TDLSPEERPSM.response..................................................... 422
6.3.50 Event request.......................................................................................................... 423
6.3.50.1 General ................................................................................................ 423
6.3.50.2 MLME-EVLREQUEST.request ......................................................... 423
6.3.50.3 MLME-EVLREQUEST.indication..................................................... 424
6.3.51 Event report............................................................................................................ 425
6.3.51.1 General ................................................................................................ 425
6.3.51.2 MLME-EVLREPORT.request............................................................ 425
6.3.51.3 MLME-EVLREPORT.indication ....................................................... 426
6.3.52 Event ...................................................................................................................... 427
6.3.52.1 General ................................................................................................ 427
6.3.52.2 MLME-EVLOG.request ..................................................................... 427
6.3.52.3 MLME-EVLOG.confirm .................................................................... 427
6.3.53 Diagnostic request.................................................................................................. 428
6.3.53.1 General ................................................................................................ 428
6.3.53.2 MLME-DIAGREQUEST.request....................................................... 428
6.3.53.3 MLME-DIAGREQUEST.indication .................................................. 429
6.3.54 Diagnostic report.................................................................................................... 430
6.3.54.1 MLME-DIAGREPORT.request ......................................................... 430
6.3.54.2 MLME-DIAGREPORT.indication ..................................................... 431
6.3.55 Location configuration request .............................................................................. 431
6.3.55.1 General ................................................................................................ 431
6.3.55.2 MLME-LOCATIONCFG.request....................................................... 432
6.3.55.3 MLME-LOCATIONCFG.confirm ..................................................... 433
6.3.55.4 MLME-LOCATIONCFG.indication .................................................. 433
6.3.55.5 MLME-LOCATIONCFG.response .................................................... 434
6.3.56 Location track notification..................................................................................... 435
6.3.56.1 General ................................................................................................ 435
6.3.56.2 MLME-LOCATIONTRACKNOTIF.request ..................................... 435
6.3.56.3 MLME-LOCATIONTRACKNOTIF.indication................................. 436
6.3.57 Timing measurement ............................................................................................. 437
6.3.57.1 General ................................................................................................ 437
6.3.57.2 MLME-TIMINGMSMT.request......................................................... 438
6.3.57.3 MLME-TIMINGMSMT.confirm ....................................................... 439
6.3.57.4 MLME-TIMINGMSMT.indication .................................................... 440
6.3.58 Fine timing measurement (FTM)........................................................................... 441
6.3.58.1 General ................................................................................................ 441
6.3.58.2 MLME-FINETIMINGMSMT.request................................................ 442
6.3.58.3 MLME-FINETIMINGMSMT.confirm............................................... 443
6.3.58.4 MLME-FINETIMINGMSMT.indication ........................................... 444
6.3.59 BSS transition management................................................................................... 446
6.3.59.1 BSS transition management procedure ............................................... 446
6.3.59.2 MLME-BTMQUERY.request ............................................................ 446
6.3.59.3 MLME-BTMQUERY.indication........................................................ 448
6.3.59.4 MLME-BTM.request .......................................................................... 449
6.3.59.5 MLME-BTM.indication...................................................................... 450
6.3.59.6 MLME-BTM.response........................................................................ 451
6.3.59.7 MLME-BTM.confirm ......................................................................... 452
6.3.60 FMS setup .............................................................................................................. 453
6.3.60.1 General ................................................................................................ 453
6.3.60.2 MLME-FMS.request........................................................................... 454
21
Copyright © 2016 IEEE. All rights reserved.
6.3.60.3 MLME-FMS.confirm.......................................................................... 454
6.3.60.4 MLME-FMS.indication ...................................................................... 455
6.3.60.5 MLME-FMS.response ........................................................................ 456
6.3.61 Collocated Interference request ............................................................................. 456
6.3.61.1 General ................................................................................................ 456
6.3.61.2 MLME-CLINTERFERENCEREQUEST.request .............................. 457
6.3.61.3 MLME-CLINTERFERENCEREQUEST.indication.......................... 458
6.3.62 Collocated Interference report ............................................................................... 459
6.3.62.1 General ................................................................................................ 459
6.3.62.2 MLME-CLINTERFERENCEREPORT.request................................. 459
6.3.62.3 MLME-CLINTERFERENCEREPORT.indication ............................ 460
6.3.63 TFS setup ............................................................................................................... 460
6.3.63.1 General ................................................................................................ 460
6.3.63.2 MLME-TFS.request............................................................................ 461
6.3.63.3 MLME-TFS.confirm........................................................................... 462
6.3.63.4 MLME-TFS.indication ....................................................................... 462
6.3.63.5 MLME-TFS.response ......................................................................... 463
6.3.64 WNM sleep mode request...................................................................................... 464
6.3.64.1 General ................................................................................................ 464
6.3.64.2 MLME-SLEEPMODE.request ........................................................... 465
6.3.64.3 MLME-SLEEPMODE.indication....................................................... 465
6.3.64.4 MLME-SLEEPMODE.response......................................................... 466
6.3.64.5 MLME-SLEEPMODE.confirm .......................................................... 467
6.3.65 TIM broadcast setup .............................................................................................. 468
6.3.65.1 General ................................................................................................ 468
6.3.65.2 MLME-TIMBROADCAST.request ................................................... 469
6.3.65.3 MLME-TIMBROADCAST.confirm .................................................. 469
6.3.65.4 MLME-TIMBROADCAST.indication............................................... 470
6.3.65.5 MLME-TIMBROADCAST.response................................................. 471
6.3.66 QoS traffic capability update ................................................................................. 471
6.3.66.1 General ................................................................................................ 471
6.3.66.2 MLME-QOSTRAFFICCAPUPDATE.request................................... 472
6.3.66.3 MLME-QOSTRAFFICCAPUPDATE.indication .............................. 473
6.3.67 Channel Usage request........................................................................................... 473
6.3.67.1 General ................................................................................................ 473
6.3.67.2 MLME-CHANNELUSAGE.request .................................................. 474
6.3.67.3 MLME-CHANNELUSAGE.confirm ................................................. 475
6.3.67.4 MLME-CHANNELUSAGE.indication.............................................. 476
6.3.67.5 MLME-CHANNELUSAGE.response................................................ 477
6.3.68 DMS or GCR request and response procedure ...................................................... 478
6.3.68.1 General ................................................................................................ 478
6.3.68.2 MLME-GATS.request ........................................................................ 478
6.3.68.3 MLME-GATS.confirm ....................................................................... 479
6.3.68.4 MLME-GATS.indication.................................................................... 480
6.3.68.5 MLME-GATS.response...................................................................... 480
6.3.68.6 MLME-GATS-TERM.request............................................................ 481
6.3.68.7 MLME-GATS-TERM.indication ....................................................... 482
6.3.69 Timing measurement request................................................................................. 483
6.3.69.1 General ................................................................................................ 483
6.3.69.2 MLME-TIMINGMSMTRQ.request ................................................... 483
6.3.69.3 MLME-TIMINGMSMTRQ.indication............................................... 483
6.3.70 Fine timing measurement request .......................................................................... 484
6.3.70.1 General ................................................................................................ 484
6.3.70.2 MLME-FINETIMINGMSMTRQ.request .......................................... 484
22
Copyright © 2016 IEEE. All rights reserved.
6.3.70.3 MLME-FINETIMINGMSMTRQ.indication...................................... 485
6.3.71 WNM notification request ..................................................................................... 486
6.3.71.1 General ................................................................................................ 486
6.3.71.2 MLME-WNMNOTIFICATIONREQUEST.request .......................... 486
6.3.71.3 MLME-WNMNOTIFICATIONREQUEST indication...................... 487
6.3.72 WNM notification response................................................................................... 488
6.3.72.1 MLME-WNMNOTIFICATIONRESPONSE.request ........................ 488
6.3.72.2 MLME-WNMNOTIFICATIONRESPONSE.indication.................... 488
6.3.73 Network discovery and selection support .............................................................. 489
6.3.73.1 General ................................................................................................ 489
6.3.73.2 MLME-GAS.request........................................................................... 489
6.3.73.3 MLME-GAS.confirm.......................................................................... 490
6.3.73.4 MLME-GAS.indication ...................................................................... 492
6.3.73.5 MLME-GAS.response ........................................................................ 493
6.3.74 QoS Map element management ............................................................................. 494
6.3.74.1 General ................................................................................................ 494
6.3.74.2 MLME-QOS-MAP.request................................................................. 495
6.3.74.3 MLME-QOS-MAP.indication ............................................................ 495
6.3.75 Mesh peering management .................................................................................... 496
6.3.75.1 Introduction......................................................................................... 496
6.3.75.2 MLME-MESHPEERINGMANAGEMENT.request.......................... 496
6.3.75.3 MLME-MESHPEERINGMANAGEMENT.confirm......................... 497
6.3.75.4 MLME-MESHPEERINGMANAGEMENT.indication ..................... 498
6.3.75.5 MLME-MESHPEERINGMANAGEMENT.response ....................... 498
6.3.76 Mesh power management ...................................................................................... 499
6.3.76.1 Introduction......................................................................................... 499
6.3.76.2 MLME-MESHPOWERMGT.request................................................. 499
6.3.76.3 MLME-MESHPOWERMGT.confirm................................................ 500
6.3.77 Mesh neighbor offset synchronization................................................................... 500
6.3.77.1 Introduction......................................................................................... 500
6.3.77.2 MLME-MESHNEIGHBOROFFSETSYNCSTART.request ............. 501
6.3.77.3 MLME-MESHNEIGHBOROFFSETSYNCSTART.confirm ............ 501
6.3.77.4 MLME-MESHNEIGHBOROFFSETCALCULATE.request............. 502
6.3.77.5 MLME-MESHNEIGHBOROFFSETCALCULATE.confirm............ 502
6.3.77.6 MLME-MESHNEIGHBOROFFSETSYNCSTOP.request ................ 503
6.3.77.7 MLME-MESHNEIGHBOROFFSETSYNCSTOP.confirm ............... 503
6.3.78 Mesh TBTT adjustment ......................................................................................... 504
6.3.78.1 Introduction......................................................................................... 504
6.3.78.2 MLME-MESHTBTTADJUSTMENT.request ................................... 504
6.3.78.3 MLME-MESHTBTTADJUSTMENT.confirm .................................. 505
6.3.78.4 MLME-MESHTBTTADJUSTMENT.indication ............................... 506
6.3.78.5 MLME-MESHTBTTADJUSTMENT.response ................................. 506
6.3.79 MCCA management interface ............................................................................... 507
6.3.79.1 Introduction......................................................................................... 507
6.3.79.2 MLME-ACTIVATEMCCA.request ................................................... 507
6.3.79.3 MLME-MCCASETUP.request........................................................... 508
6.3.79.4 MLME-MCCASETUP.confirm.......................................................... 509
6.3.79.5 MLME-MCCASETUP.indication ...................................................... 510
6.3.79.6 MLME-MCCASETUP.response ........................................................ 511
6.3.79.7 MLME-MCCAADVERTISEMENT.request ..................................... 512
6.3.79.8 MLME-MCCAADVERTISEMENT.confirm .................................... 512
6.3.79.9 MLME-MCCAADVERTISEMENT.indication ................................. 513
6.3.79.10 MLME-MCCAADVERTISEMENT.response ................................... 514
6.3.79.11 MLME-MCCATEARDOWN.request ................................................ 514
23
Copyright © 2016 IEEE. All rights reserved.
6.3.79.12 MLME-MCCATEARDOWN.indication............................................ 515
6.3.80 MBSS congestion control ...................................................................................... 516
6.3.80.1 Introduction......................................................................................... 516
6.3.80.2 MLME-MBSSCONGESTIONCONTROL.request............................ 516
6.3.80.3 MLME-MBSSCONGESTIONCONTROL.indication ....................... 516
6.3.81 MBSS proxy update............................................................................................... 517
6.3.81.1 Introduction......................................................................................... 517
6.3.81.2 MLME-MBSSPROXYUPDATE.request........................................... 517
6.3.81.3 MLME-MBSSPROXYUPDATE.confirm.......................................... 518
6.3.81.4 MLME-MBSSPROXYUPDATE.indication ...................................... 519
6.3.81.5 MLME-MBSSPROXYUPDATE.response ........................................ 519
6.3.82 MBSS mesh gate announcement ........................................................................... 520
6.3.82.1 Introduction......................................................................................... 520
6.3.82.2 MLME-MBSSGATEANNOUNCEMENT.request............................ 520
6.3.82.3 MLME-MBSSGATEANNOUNCEMENT.indication ....................... 521
6.3.83 Mesh link metric .................................................................................................... 522
6.3.83.1 Introduction......................................................................................... 522
6.3.83.2 MLME-MESHLINKMETRICREAD.request .................................... 522
6.3.83.3 MLME-MESHLINKMETRICREAD.confirm ................................... 522
6.3.83.4 MLME-MESHLINKMETRICREPORT.request................................ 523
6.3.83.5 MLME-MESHLINKMETRICREPORT.indication ........................... 524
6.3.84 HWMP mesh path selection .................................................................................. 525
6.3.84.1 Introduction......................................................................................... 525
6.3.84.2 MLME-HWMPMESHPATHSELECTION.request ........................... 525
6.3.84.3 MLME-HWMPMESHPATHSELECTION.indication....................... 526
6.3.85 QMF policy............................................................................................................ 527
6.3.85.1 Introduction......................................................................................... 527
6.3.85.2 MLME-QMFPOLICY.request............................................................ 527
6.3.85.3 MLME-QMFPOLICY.indication ....................................................... 528
6.3.85.4 MLME-QMFPOLICYCHANGE.request ........................................... 528
6.3.85.5 MLME-QMFPOLICYCHANGE.confirm.......................................... 529
6.3.85.6 MLME-QMFPOLICYCHANGE.indication....................................... 530
6.3.85.7 MLME-QMFPOLICYCHANGE.response......................................... 530
6.3.85.8 MLME-QMFPOLICYSET.request..................................................... 531
6.3.86 SCS request and response procedure ..................................................................... 532
6.3.86.1 General ................................................................................................ 532
6.3.86.2 MLME-SCS.request............................................................................ 532
6.3.86.3 MLME-SCS.confirm........................................................................... 533
6.3.86.4 MLME-SCS.indication ....................................................................... 534
6.3.86.5 MLME-SCS.response ......................................................................... 535
6.3.86.6 MLME-SCS-TERM.request .............................................................. 535
6.3.86.7 MLME-SCS-TERM.indication........................................................... 536
6.3.87 QLoad report management .................................................................................... 537
6.3.87.1 General ................................................................................................ 537
6.3.87.2 MLME-QLOAD.request..................................................................... 537
6.3.87.3 MLME-QLOAD.confirm.................................................................... 538
6.3.87.4 MLME-QLOAD.indication ............................................................... 539
6.3.87.5 MLME-QLOAD.response ................................................................. 539
6.3.88 HCCA TXOP advertisement management ............................................................ 540
6.3.88.1 General ................................................................................................ 540
6.3.88.2 MLME-TXOPADVERTISEMENT.request....................................... 540
6.3.88.3 MLME-TXOPADVERTISEMENT.confirm...................................... 541
6.3.88.4 MLME-TXOPADVERTISEMENT.indication .................................. 542
6.3.88.5 MLME-TXOPADVERTISEMENT.response .................................... 543
24
Copyright © 2016 IEEE. All rights reserved.
6.3.89 GCR group membership management................................................................... 544
6.3.89.1 General ................................................................................................ 544
6.3.89.2 MLME-GROUP-MEMBERSHIP.request.......................................... 544
6.3.89.3 MLME-GROUP-MEMBERSHIP.confirm......................................... 545
6.3.89.4 MLME-GROUP-MEMBERSHIP.indication ..................................... 546
6.3.89.5 MLME-GROUP-MEMBERSHIP.response ....................................... 546
6.3.90 AP PeerKey management ..................................................................................... 547
6.3.90.1 General ................................................................................................ 547
6.3.90.2 MLME-APPEERKEY.request............................................................ 547
6.3.90.3 MLME-APPEERKEY.indication ....................................................... 548
6.3.91 On-channel Tunneling operation ........................................................................... 549
6.3.91.1 General ................................................................................................ 549
6.3.91.2 MLME-OCTunnel.request.................................................................. 550
6.3.91.3 MLME-OCTunnel.indication ............................................................. 550
6.3.92 Multi-band operation ............................................................................................. 551
6.3.92.1 General ................................................................................................ 551
6.3.92.2 MLME-FST-SETUP.request .............................................................. 551
6.3.92.3 MLME-FST-SETUP.indication.......................................................... 552
6.3.92.4 MLME-FST-SETUP.response............................................................ 552
6.3.92.5 MLME-FST-SETUP.confirm ............................................................. 553
6.3.92.6 MLME-FST-ACK.request .................................................................. 554
6.3.92.7 MLME-FST-ACK.indication.............................................................. 554
6.3.92.8 MLME-FST-ACK.response................................................................ 555
6.3.92.9 MLME-FST-ACK.confirm ................................................................. 555
6.3.92.10 MLME-FST-TEARDOWN.request.................................................... 556
6.3.92.11 MLME-FST-TEARDOWN.indication ............................................... 556
6.3.92.12 MLME-FST-INCOMING.request ...................................................... 557
6.3.93 DMG relay operation ............................................................................................. 558
6.3.93.1 General ................................................................................................ 558
6.3.93.2 MLME-RELAY-SEARCH.request .................................................... 558
6.3.93.3 MLME-RELAY-SEARCH.confirm ................................................... 559
6.3.93.4 MLME-RELAY-SEARCH.indication................................................ 559
6.3.93.5 MLME-RELAY-SEARCH.response.................................................. 560
6.3.93.6 MLME-RLS.request ........................................................................... 560
6.3.93.7 MLME-RLS.confirm .......................................................................... 561
6.3.93.8 MLME-RLS.indication ....................................................................... 562
6.3.93.9 MLME-RLS.response ......................................................................... 563
6.3.93.10 MLME-RLS-TEARDOWN.request ................................................... 563
6.3.93.11 MLME-RLS-TEARDOWN.indication............................................... 564
6.3.94 Quieting adjacent BSS operation ........................................................................... 564
6.3.94.1 General ................................................................................................ 564
6.3.94.2 MLME-QAB.request .......................................................................... 565
6.3.94.3 MLME-QAB.confirm ......................................................................... 565
6.3.94.4 MLME-QAB.indication...................................................................... 566
6.3.94.5 MLME-QAB.response........................................................................ 567
6.3.95 DMG beamforming................................................................................................ 568
6.3.95.1 General ................................................................................................ 568
6.3.95.2 MLME-BF-TRAINING.request ......................................................... 568
6.3.95.3 MLME-BF-TRAINING.confirm ........................................................ 569
6.3.95.4 MLME-BF-TRAINING.indication..................................................... 569
6.3.96 PN event report ...................................................................................................... 570
6.3.96.1 General ................................................................................................ 570
6.3.96.2 MLME-PN-EXHAUSTION.indication .............................................. 570
6.3.96.3 MLME-PN-WARNING.indication..................................................... 571
25
Copyright © 2016 IEEE. All rights reserved.
6.3.97 Channel Availability Query ................................................................................... 571
6.3.97.1 Introduction......................................................................................... 571
6.3.97.2 MLME-CHANNELAVAILABILITYQUERY.request ..................... 571
6.3.97.3 MLME-CHANNELAVAILABILITYQUERY.confirm .................... 572
6.3.97.4 MLME-CHANNELAVAILABILITYQUERY.indication ................. 573
6.3.97.5 MLME-CHANNELAVAILABILITYQUERY.response ................... 574
6.3.98 Channel schedule management.............................................................................. 575
6.3.98.1 Introduction......................................................................................... 575
6.3.98.2 MLME-CHANNELSCHEDULEMANAGEMENT.request.............. 575
6.3.98.3 MLME-CHANNELSCHEDULEMANAGEMENT.confirm............. 576
6.3.98.4 MLME-CHANNELSCHEDULEMANAGEMENT.indication ......... 577
6.3.98.5 MLME-CHANNELSCHEDULEMANAGEMENT.response ........... 578
6.3.99 Contact verification signal ..................................................................................... 579
6.3.99.1 Introduction......................................................................................... 579
6.3.99.2 MLME-CVS.request ........................................................................... 579
6.3.99.3 MLME-CVS.indication....................................................................... 580
6.3.100 GDD Enablement................................................................................................... 581
6.3.100.1 Introduction......................................................................................... 581
6.3.100.2 MLME-GDDENABLEMENT.request ............................................... 581
6.3.100.3 MLME-GDDENABLEMENT.confirm.............................................. 582
6.3.100.4 MLME-GDDENABLEMENT.indication........................................... 583
6.3.100.5 MLME-GDDENABLEMENT.response............................................. 583
6.3.101 Network channel control management .................................................................. 584
6.3.101.1 Introduction......................................................................................... 584
6.3.101.2 MLME-NETWORKCHANNELCONTROL.request......................... 584
6.3.101.3 MLME-NETWORKCHANNELCONTROL.confirm........................ 585
6.3.101.4 MLME-NETWORKCHANNELCONTROL.indication .................... 586
6.3.101.5 MLME-NETWORKCHANNELCONTROL.response ...................... 587
6.3.102 White space map (WSM)....................................................................................... 588
6.3.102.1 Introduction......................................................................................... 588
6.3.102.2 MLME-WSM.request ......................................................................... 588
6.3.102.3 MLME-WSM.indication..................................................................... 589
6.3.103 Estimated Throughput (ESTT) .............................................................................. 589
6.3.103.1 General ................................................................................................ 589
6.3.103.2 MLME-ESTIMATED-THROUGHPUT.request................................ 589
6.3.103.3 MLME-ESTIMATED-THROUGHPUT.confirm............................... 591
6.3.104 Get authentication/association state....................................................................... 591
6.3.104.1 General ................................................................................................ 591
6.3.104.2 MLME-GETAUTHASSOCSTATE.request....................................... 592
6.3.104.3 MLME-GETAUTHASSOCSTATE.confirm ..................................... 592
6.4 MAC state generic convergence function (MSGCF) ............................................................ 593
6.4.1 Overview of the convergence function .................................................................. 593
6.4.2 Overview of convergence function state machine ................................................. 593
6.4.3 Convergence function state list.............................................................................. 594
6.4.3.1 ESS_CONNECTED............................................................................ 594
6.4.3.2 ESS_DISCONNECTED ..................................................................... 594
6.4.3.3 ESS_DISENGAGING ........................................................................ 594
6.4.3.4 STANDBY.......................................................................................... 594
6.4.4 Convergence function state transitions .................................................................. 594
6.4.4.1 Transitions to ESS_CONNECTED .................................................... 594
6.4.4.2 Transitions to ESS_ DISCONNECTED ............................................. 595
6.4.4.3 Transitions to ESS_DISENGAGING ................................................. 595
6.4.4.4 Transitions to STANDBY................................................................... 595
6.4.5 Convergence function informational events .......................................................... 595
26
Copyright © 2016 IEEE. All rights reserved.
6.4.6 MAC state generic convergence SAP.................................................................... 595
6.4.7 ESS status reporting............................................................................................... 596
6.4.7.1 MSGCF-ESS-LINK-UP.indication..................................................... 596
6.4.7.2 MSGCF-ESS-LINK-DOWN.indication ............................................. 597
6.4.7.3 MSGCF-ESS-LINK-GOING-DOWN.indication ............................... 598
6.4.7.4 MSGCF-ESS-LINK-EVENT-ROLLBACK.indication...................... 599
6.4.7.5 MSGCF-ESS-LINK-DETECTED.indication ..................................... 600
6.4.7.6 MSGCF-ESS-LINK-SCAN.request ................................................... 601
6.4.7.7 MSGCF-ESS-LINK-SCAN.confirm .................................................. 602
6.4.8 Network configuration ........................................................................................... 602
6.4.8.1 MSGCF-ESS-LINK-CAPABILITY.request ...................................... 602
6.4.8.2 MSGCF-ESS-LINK-CAPABILITY.confirm ..................................... 603
6.4.8.3 MSGCF-ESS-LINK-PARAMETERS.request.................................... 604
6.4.8.4 MSGCF-ESS-LINK-PARAMETERS.confirm................................... 606
6.4.8.5 MSGCF-GET-ESS-LINK-PARAMETERS.request........................... 606
6.4.8.6 MSGCF-GET-ESS-LINK-PARAMETERS.confirm ......................... 607
6.4.9 Network events ...................................................................................................... 607
6.4.9.1 MSGCF-ESS-LINK-THRESHOLD-REPORT.indication ................. 607
6.4.10 Network command interface.................................................................................. 608
6.4.10.1 MSGCF-ESS-LINK-COMMAND.request......................................... 608
6.4.11 MAC state SME SAP—mobility management ..................................................... 609
6.4.11.1 MSSME-ESS-LINK-GOING-DOWN.indication............................... 609
6.5 PLME SAP interface ............................................................................................................. 610
6.5.1 General................................................................................................................... 610
6.5.2 PLME-RESET.request........................................................................................... 610
6.5.2.1 Function .............................................................................................. 610
6.5.2.2 Semantics of the service primitive ...................................................... 610
6.5.2.3 When generated................................................................................... 610
6.5.2.4 Effect of receipt................................................................................... 610
6.5.3 PLME-CHARACTERISTICS.request .................................................................. 611
6.5.3.1 Function .............................................................................................. 611
6.5.3.2 Semantics of the service primitive ...................................................... 611
6.5.3.3 When generated................................................................................... 611
6.5.3.4 Effect of receipt................................................................................... 611
6.5.4 PLME-CHARACTERISTICS.confirm ................................................................. 611
6.5.4.1 Function .............................................................................................. 611
6.5.4.2 Semantics of the service primitive ...................................................... 611
6.5.4.3 When generated................................................................................... 614
6.5.4.4 Effect of receipt................................................................................... 614
6.5.5 PLME-TXTIME.request........................................................................................ 614
6.5.5.1 Function .............................................................................................. 614
6.5.5.2 Semantics of the service primitive ...................................................... 614
6.5.5.3 When generated................................................................................... 614
6.5.5.4 Effect of receipt................................................................................... 614
6.5.6 PLME-TXTIME.confirm....................................................................................... 615
6.5.6.1 Function .............................................................................................. 615
6.5.6.2 Semantics of the service primitive ...................................................... 615
6.5.6.3 When generated................................................................................... 615
6.5.6.4 Effect of receipt................................................................................... 615
7. DS SAP specification......................................................................................................................... 616
7.1 Introduction............................................................................................................................ 616
7.2 SAP primitives....................................................................................................................... 616
27
Copyright © 2016 IEEE. All rights reserved.
7.2.1 General................................................................................................................... 616
7.2.2 MSDU transfer....................................................................................................... 617
7.2.2.1 General ................................................................................................ 617
7.2.2.2 DS-UNITDATA.request ..................................................................... 617
7.2.2.3 DS-UNITDATA.indication................................................................. 617
7.2.3 Mapping updates.................................................................................................... 618
7.2.3.1 General ................................................................................................ 618
7.2.3.2 DS-STA-NOTIFY.request .................................................................. 618
8. PHY service specification.................................................................................................................. 620
8.1 Scope...................................................................................................................................... 620
8.2 PHY functions........................................................................................................................ 620
8.3 Detailed PHY service specifications...................................................................................... 620
8.3.1 Scope and field of application ............................................................................... 620
8.3.2 Overview of the service ......................................................................................... 620
8.3.3 Overview of interactions........................................................................................ 620
8.3.4 Basic service and options....................................................................................... 620
8.3.4.1 PHY SAP peer-to-peer service primitives .......................................... 620
8.3.4.2 PHY SAP inter-(sub)layer service primitives..................................... 621
8.3.4.3 PHY SAP service primitives parameters ............................................ 621
8.3.4.4 Vector descriptions ............................................................................. 622
8.3.5 PHY SAP detailed service specification................................................................ 623
8.3.5.1 Introduction......................................................................................... 623
8.3.5.2 PHY-DATA.request............................................................................ 623
8.3.5.3 PHY-DATA.indication ....................................................................... 623
8.3.5.4 PHY-DATA.confirm........................................................................... 624
8.3.5.5 PHY-TXSTART.request..................................................................... 624
8.3.5.6 PHY-TXSTART.confirm.................................................................... 625
8.3.5.7 PHY-TXEND.request ......................................................................... 626
8.3.5.8 PHY-TXEND.confirm ........................................................................ 626
8.3.5.9 PHY-TXHEADEREND.indication..................................................... 627
8.3.5.10 PHY-CCARESET.request .................................................................. 627
8.3.5.11 PHY-CCARESET.confirm ................................................................. 628
8.3.5.12 PHY-CCA.indication .......................................................................... 628
8.3.5.13 PHY-RXSTART.indication ................................................................ 632
8.3.5.14 PHY-RXEND.indication..................................................................... 632
8.3.5.15 PHY-CONFIG.request........................................................................ 633
8.3.5.16 PHY-CONFIG.confirm....................................................................... 634
8.3.5.17 PHY-TXBUSY.indication .................................................................. 634
8.4 PHY management .................................................................................................................. 635
9. Frame formats .................................................................................................................................... 636
9.1 General requirements ............................................................................................................. 636
9.2 MAC frame formats............................................................................................................... 636
9.2.1 Basic components .................................................................................................. 636
9.2.2 Conventions ........................................................................................................... 636
9.2.3 General frame format............................................................................................. 637
9.2.4 Frame fields ........................................................................................................... 638
9.2.4.1 Frame Control field............................................................................. 638
9.2.4.2 Duration/ID field................................................................................. 644
9.2.4.3 Address fields...................................................................................... 645
9.2.4.4 Sequence Control field........................................................................ 646
28
Copyright © 2016 IEEE. All rights reserved.
9.2.4.5 QoS Control field ................................................................................ 647
9.2.4.6 HT Control field.................................................................................. 654
9.2.4.7 Frame Body field ................................................................................ 661
9.2.4.8 FCS field ............................................................................................. 665
9.2.5 Duration/ID field (QoS STA) ................................................................................ 665
9.2.5.1 General ................................................................................................ 665
9.2.5.2 Setting for single and multiple protection under enhanced
distributed channel access (EDCA) .................................................... 665
9.2.5.3 Setting for QoS CF-Poll frames .......................................................... 667
9.2.5.4 Setting for frames sent by a TXOP holder under HCCA.................... 668
9.2.5.5 Settings within a PSMP sequence....................................................... 668
9.2.5.6 Settings within a dual CTS sequence.................................................. 668
9.2.5.7 Setting for control response frames .................................................... 669
9.2.5.8 Setting for other response frames........................................................ 669
9.3 Format of individual frame types........................................................................................... 669
9.3.1 Control frames ....................................................................................................... 669
9.3.1.1 Format of Control frames.................................................................... 669
9.3.1.2 RTS frame format ............................................................................... 670
9.3.1.3 CTS frame format ............................................................................... 670
9.3.1.4 Ack frame format ................................................................................ 671
9.3.1.5 PS-Poll frame format .......................................................................... 671
9.3.1.6 CF-End frame format .......................................................................... 672
9.3.1.7 CF-End +CF-Ack frame format.......................................................... 672
9.3.1.8 BlockAckReq frame format ................................................................ 672
9.3.1.9 BlockAck frame format ...................................................................... 676
9.3.1.10 Control Wrapper frame ....................................................................... 680
9.3.1.11 Poll frame format ................................................................................ 681
9.3.1.12 Service period request (SPR) frame format ........................................ 681
9.3.1.13 Grant frame format.............................................................................. 682
9.3.1.14 DMG CTS frame format ..................................................................... 683
9.3.1.15 DMG DTS frame format..................................................................... 683
9.3.1.16 Sector sweep (SSW) frame format...................................................... 683
9.3.1.17 Sector sweep feedback (SSW-Feedback) frame format ..................... 684
9.3.1.18 Sector sweep Ack (SSW-Ack) frame format ...................................... 684
9.3.1.19 Grant Ack frame format...................................................................... 685
9.3.1.20 VHT NDP Announcement frame format ............................................ 685
9.3.1.21 Beamforming Report Poll frame format ............................................. 687
9.3.2 Data frames ............................................................................................................ 687
9.3.2.1 Format of Data frames ........................................................................ 687
9.3.2.2 Aggregate MSDU (A-MSDU) format ................................................ 690
9.3.3 Management frames............................................................................................... 692
9.3.3.1 Terminology of Management frames and MMPDUs ......................... 692
9.3.3.2 Format of Management frames ........................................................... 692
9.3.3.3 Beacon frame format........................................................................... 694
9.3.3.4 ATIM frame format ............................................................................ 698
9.3.3.5 Disassociation frame format ............................................................... 698
9.3.3.6 Association Request frame format...................................................... 699
9.3.3.7 Association Response frame format ................................................... 700
9.3.3.8 Reassociation Request frame format................................................... 702
9.3.3.9 Reassociation Response frame format ................................................ 704
9.3.3.10 Probe Request frame format ............................................................... 706
9.3.3.11 Probe Response frame format ............................................................. 708
9.3.3.12 Authentication frame format ............................................................... 712
9.3.3.13 Deauthentication ................................................................................. 715
29
Copyright © 2016 IEEE. All rights reserved.
9.3.3.14 Action frame format............................................................................ 715
9.3.3.15 Action No Ack frame format .............................................................. 716
9.3.3.16 Timing Advertisement frame format .................................................. 716
9.3.4 Extension frames.................................................................................................... 716
9.3.4.1 Format of Extension frames................................................................ 716
9.3.4.2 DMG Beacon ...................................................................................... 717
9.3.5 Frame addressing in an MBSS............................................................................... 721
9.4 Management and Extension frame body components ........................................................... 723
9.4.1 Fields that are not elements ................................................................................... 723
9.4.1.1 Authentication Algorithm Number field............................................. 723
9.4.1.2 Authentication Transaction Sequence Number field .......................... 724
9.4.1.3 Beacon Interval field........................................................................... 724
9.4.1.4 Capability Information field................................................................ 724
9.4.1.5 Current AP Address field.................................................................... 727
9.4.1.6 Listen Interval field............................................................................. 727
9.4.1.7 Reason Code field ............................................................................... 728
9.4.1.8 AID field ............................................................................................. 731
9.4.1.9 Status Code field ................................................................................. 731
9.4.1.10 Timestamp field .................................................................................. 736
9.4.1.11 Action field ......................................................................................... 736
9.4.1.12 Dialog Token field .............................................................................. 738
9.4.1.13 DLS Timeout Value field.................................................................... 738
9.4.1.14 Block Ack Parameter Set field............................................................ 738
9.4.1.15 Block Ack Timeout Value field .......................................................... 739
9.4.1.16 DELBA Parameter Set field................................................................ 739
9.4.1.17 QoS Info field...................................................................................... 739
9.4.1.18 Measurement Pilot Interval field......................................................... 741
9.4.1.19 Max Transmit Power field .................................................................. 741
9.4.1.20 Transmit Power Used field ................................................................. 741
9.4.1.21 Channel Width field ............................................................................ 741
9.4.1.22 Operating Class and Channel field...................................................... 742
9.4.1.23 SM Power Control field ...................................................................... 742
9.4.1.24 PCO Phase Control field ..................................................................... 743
9.4.1.25 PSMP Parameter Set field................................................................... 743
9.4.1.26 PSMP STA Info field.......................................................................... 744
9.4.1.27 MIMO Control field............................................................................ 745
9.4.1.28 CSI Report field .................................................................................. 746
9.4.1.29 Noncompressed Beamforming Report field ....................................... 748
9.4.1.30 Compressed Beamforming Report field ............................................. 750
9.4.1.31 Antenna Selection Indices field .......................................................... 753
9.4.1.32 Organization Identifier field................................................................ 753
9.4.1.33 Rate Identification field ...................................................................... 754
9.4.1.34 GAS Query Response Fragment ID field ........................................... 755
9.4.1.35 Venue Info field .................................................................................. 756
9.4.1.36 Target Channel.................................................................................... 759
9.4.1.37 Operating Class ................................................................................... 759
9.4.1.38 Send-Confirm field ............................................................................. 759
9.4.1.39 Anti-Clogging Token field.................................................................. 759
9.4.1.40 Scalar field .......................................................................................... 760
9.4.1.41 Finite field element (FFE) field .......................................................... 760
9.4.1.42 Confirm field....................................................................................... 760
9.4.1.43 Finite Cyclic Group field .................................................................... 760
9.4.1.44 TXOP Reservation field...................................................................... 760
9.4.1.45 Relay Capable STA Info field............................................................. 761
30
Copyright © 2016 IEEE. All rights reserved.
9.4.1.46 Band ID field....................................................................................... 761
9.4.1.47 DMG Parameters field ........................................................................ 761
9.4.1.48 VHT MIMO Control field................................................................... 763
9.4.1.49 VHT Compressed Beamforming Report field .................................... 764
9.4.1.50 TVHT Compressed Beamforming Report field.................................. 773
9.4.1.51 MU Exclusive Beamforming Report field .......................................... 774
9.4.1.52 TVHT MU Exclusive Beamforming Report field .............................. 778
9.4.1.53 Operating Mode field .......................................................................... 778
9.4.1.54 Membership Status Array field ........................................................... 782
9.4.1.55 User Position Array field .................................................................... 782
9.4.1.56 Device Location Information Body field ............................................ 782
9.4.1.57 WSM Type field and WSM Information field.................................... 783
9.4.2 Elements................................................................................................................. 784
9.4.2.1 General ................................................................................................ 784
9.4.2.2 SSID element ...................................................................................... 790
9.4.2.3 Supported Rates and BSS Membership Selectors element................. 790
9.4.2.4 DSSS Parameter Set element .............................................................. 792
9.4.2.5 CF Parameter Set element................................................................... 792
9.4.2.6 TIM element........................................................................................ 792
9.4.2.7 IBSS Parameter Set element ............................................................... 795
9.4.2.8 Challenge Text element ...................................................................... 795
9.4.2.9 Country element.................................................................................. 795
9.4.2.10 Request element .................................................................................. 798
9.4.2.11 Extended Request element .................................................................. 798
9.4.2.12 ERP element........................................................................................ 799
9.4.2.13 Extended Supported Rates and BSS Membership Selectors element. 799
9.4.2.14 Power Constraint element ................................................................... 800
9.4.2.15 Power Capability element ................................................................... 800
9.4.2.16 TPC Request element.......................................................................... 801
9.4.2.17 TPC Report element............................................................................ 801
9.4.2.18 Supported Channels element............................................................... 802
9.4.2.19 Channel Switch Announcement element ............................................ 802
9.4.2.20 Secondary Channel Offset element..................................................... 803
9.4.2.21 Measurement Request element ........................................................... 804
9.4.2.22 Measurement Report element ............................................................. 835
9.4.2.23 Quiet element ...................................................................................... 881
9.4.2.24 IBSS DFS element .............................................................................. 881
9.4.2.25 RSNE .................................................................................................. 882
9.4.2.26 Vendor Specific element ..................................................................... 890
9.4.2.27 Extended Capabilities element............................................................ 890
9.4.2.28 BSS Load element............................................................................... 896
9.4.2.29 EDCA Parameter Set element............................................................. 897
9.4.2.30 TSPEC element ................................................................................... 899
9.4.2.31 TCLAS element .................................................................................. 906
9.4.2.32 TS Delay element................................................................................ 914
9.4.2.33 TCLAS Processing element ................................................................ 914
9.4.2.34 Schedule element ................................................................................ 915
9.4.2.35 QoS Capability element ...................................................................... 916
9.4.2.36 AP Channel Report element................................................................ 916
9.4.2.37 Neighbor Report element .................................................................... 916
9.4.2.38 RCPI element ...................................................................................... 923
9.4.2.39 BSS Average Access Delay element .................................................. 923
9.4.2.40 Antenna element ................................................................................. 924
9.4.2.41 RSNI element...................................................................................... 925
31
Copyright © 2016 IEEE. All rights reserved.
9.4.2.42 Measurement Pilot Transmission element .......................................... 925
9.4.2.43 BSS Available Admission Capacity element...................................... 926
9.4.2.44 BSS AC Access Delay element .......................................................... 927
9.4.2.45 RM Enabled Capabilities element....................................................... 929
9.4.2.46 Multiple BSSID element..................................................................... 931
9.4.2.47 Mobility Domain element (MDE)....................................................... 933
9.4.2.48 Fast BSS Transition element (FTE) .................................................... 933
9.4.2.49 Timeout Interval element (TIE) .......................................................... 936
9.4.2.50 RIC Data element (RDE) .................................................................... 936
9.4.2.51 RIC Descriptor element ...................................................................... 937
9.4.2.52 DSE Registered Location element ...................................................... 937
9.4.2.53 Extended Channel Switch Announcement element ............................ 939
9.4.2.54 Supported Operating Classes element................................................. 939
9.4.2.55 Management MIC element.................................................................. 941
9.4.2.56 HT Capabilities element...................................................................... 941
9.4.2.57 HT Operation element......................................................................... 950
9.4.2.58 20/40 BSS Intolerant Channel Report element ................................... 954
9.4.2.59 Overlapping BSS Scan Parameters element ....................................... 955
9.4.2.60 20/40 BSS Coexistence element ......................................................... 955
9.4.2.61 Time Advertisement element .............................................................. 956
9.4.2.62 Link Identifier element........................................................................ 958
9.4.2.63 Wakeup Schedule element .................................................................. 958
9.4.2.64 Channel Switch Timing element......................................................... 959
9.4.2.65 PTI Control element............................................................................ 959
9.4.2.66 TPU Buffer Status element ................................................................. 960
9.4.2.67 Event Request element........................................................................ 961
9.4.2.68 Event Report element.......................................................................... 967
9.4.2.69 Diagnostic Request element................................................................ 973
9.4.2.70 Diagnostic Report element.................................................................. 984
9.4.2.71 Location Parameters element .............................................................. 986
9.4.2.72 Nontransmitted BSSID Capability element ........................................ 994
9.4.2.73 SSID List element ............................................................................... 994
9.4.2.74 Multiple BSSID-Index element .......................................................... 995
9.4.2.75 FMS Descriptor element ..................................................................... 995
9.4.2.76 FMS Request element ......................................................................... 996
9.4.2.77 FMS Response element....................................................................... 998
9.4.2.78 QoS Traffic Capability element ........................................................ 1000
9.4.2.79 BSS Max Idle Period element........................................................... 1001
9.4.2.80 TFS Request element ........................................................................ 1002
9.4.2.81 TFS Response element...................................................................... 1004
9.4.2.82 WNM Sleep Mode element............................................................... 1005
9.4.2.83 TIM Broadcast Request element....................................................... 1006
9.4.2.84 TIM Broadcast Response element .................................................... 1007
9.4.2.85 Collocated Interference Report element ........................................... 1008
9.4.2.86 Channel Usage element..................................................................... 1009
9.4.2.87 Time Zone element ........................................................................... 1010
9.4.2.88 DMS Request element ...................................................................... 1011
9.4.2.89 DMS Response element .................................................................... 1013
9.4.2.90 Destination URI element................................................................... 1016
9.4.2.91 U-APSD Coexistence element .......................................................... 1017
9.4.2.92 Interworking element ........................................................................ 1017
9.4.2.93 Advertisement Protocol element....................................................... 1019
9.4.2.94 Expedited Bandwidth Request element ............................................ 1021
9.4.2.95 QoS Map element.............................................................................. 1022
32
Copyright © 2016 IEEE. All rights reserved.
9.4.2.96 Roaming Consortium element .......................................................... 1023
9.4.2.97 Emergency Alert Identifier element.................................................. 1024
9.4.2.98 Mesh Configuration element............................................................. 1024
9.4.2.99 Mesh ID element............................................................................... 1028
9.4.2.100 Mesh Link Metric Report element .................................................... 1029
9.4.2.101 Congestion Notification element ...................................................... 1029
9.4.2.102 Mesh Peering Management element ................................................. 1030
9.4.2.103 Mesh Channel Switch Parameters element ....................................... 1031
9.4.2.104 Mesh Awake Window element ......................................................... 1032
9.4.2.105 Beacon Timing element .................................................................... 1032
9.4.2.106 MCCAOP Setup Request element .................................................... 1033
9.4.2.107 MCCAOP Setup Reply element ....................................................... 1034
9.4.2.108 MCCAOP Advertisement Overview element................................... 1035
9.4.2.109 MCCAOP Advertisement element.................................................... 1036
9.4.2.110 MCCAOP Teardown element........................................................... 1038
9.4.2.111 GANN element ................................................................................. 1039
9.4.2.112 RANN element.................................................................................. 1039
9.4.2.113 PREQ element................................................................................... 1040
9.4.2.114 PREP element ................................................................................... 1042
9.4.2.115 PERR element ................................................................................... 1044
9.4.2.116 PXU element ..................................................................................... 1045
9.4.2.117 PXUC element .................................................................................. 1046
9.4.2.118 Authenticated Mesh Peering Exchange element............................... 1047
9.4.2.119 MIC element ..................................................................................... 1047
9.4.2.120 Quality-of-Service Management Frame Policy element................... 1048
9.4.2.121 Intra-Access Category Priority element............................................ 1049
9.4.2.122 SCS Descriptor element .................................................................... 1050
9.4.2.123 QLoad Report element ..................................................................... 1051
9.4.2.124 HCCA TXOP Update Count element .............................................. 1053
9.4.2.125 Higher Layer Stream ID element ..................................................... 1054
9.4.2.126 GCR Group Address element .......................................................... 1054
9.4.2.127 DMG BSS Parameter Change element ............................................. 1055
9.4.2.128 DMG Capabilities element................................................................ 1055
9.4.2.129 DMG Operation element .................................................................. 1063
9.4.2.130 DMG Beam Refinement element...................................................... 1064
9.4.2.131 DMG Wakeup Schedule element...................................................... 1066
9.4.2.132 Extended Schedule element .............................................................. 1067
9.4.2.133 STA Availability element ................................................................. 1069
9.4.2.134 DMG TSPEC element....................................................................... 1070
9.4.2.135 Next DMG ATI element ................................................................... 1073
9.4.2.136 Channel Measurement Feedback element......................................... 1074
9.4.2.137 Awake Window element ................................................................... 1076
9.4.2.138 Multi-band element ........................................................................... 1076
9.4.2.139 ADDBA Extension element ............................................................. 1079
9.4.2.140 Next PCP List element .................................................................... 1079
9.4.2.141 PCP Handover element ................................................................... 1080
9.4.2.142 DMG Link Margin element ............................................................. 1080
9.4.2.143 DMG Link Adaptation Acknowledgment element........................... 1081
9.4.2.144 Switching Stream element ............................................................... 1082
9.4.2.145 Session Transition element .............................................................. 1083
9.4.2.146 Dynamic Tone Pairing (DTP) Report element ................................. 1084
9.4.2.147 Cluster Report element ..................................................................... 1085
9.4.2.148 Relay Capabilities element................................................................ 1086
9.4.2.149 Relay Transfer Parameter Set element.............................................. 1087
33
Copyright © 2016 IEEE. All rights reserved.
9.4.2.150 Quiet Period Request element........................................................... 1088
9.4.2.151 Quiet Period Response element ........................................................ 1089
9.4.2.152 BeamLink Maintenance element ...................................................... 1089
9.4.2.153 Multiple MAC Sublayers (MMS) element ...................................... 1090
9.4.2.154 U-PID element ................................................................................. 1091
9.4.2.155 ECAPC Policy element .................................................................... 1092
9.4.2.156 Cluster Time Offset element ............................................................ 1093
9.4.2.157 Antenna Sector ID Pattern element................................................... 1094
9.4.2.158 VHT Capabilities element................................................................. 1095
9.4.2.159 VHT Operation element.................................................................... 1102
9.4.2.160 Extended BSS Load element............................................................. 1104
9.4.2.161 Wide Bandwidth Channel Switch element ....................................... 1105
9.4.2.162 Transmit Power Envelope element ................................................... 1106
9.4.2.163 Channel Switch Wrapper element..................................................... 1108
9.4.2.164 AID element...................................................................................... 1109
9.4.2.165 Quiet Channel element...................................................................... 1109
9.4.2.166 Operating Mode Notification element .............................................. 1110
9.4.2.167 UPSIM element................................................................................. 1110
9.4.2.168 Fine Timing Measurement Parameters element................................ 1111
9.4.2.169 Device Location element .................................................................. 1115
9.4.2.170 White Space Map element ................................................................ 1115
9.4.2.171 Reduced Neighbor Report element ................................................... 1115
9.4.2.172 TVHT Operation element ................................................................. 1117
9.4.2.173 FTM Synchronization Information element ..................................... 1118
9.4.2.174 Estimated service parameters element .............................................. 1118
9.4.2.175 Future Channel Guidance element.................................................... 1120
9.4.3 Subelements ......................................................................................................... 1121
9.4.4 TLV encodings .................................................................................................... 1122
9.4.4.1 General .............................................................................................. 1122
9.4.4.2 Common TLVs ................................................................................. 1122
9.4.5 Access network query protocol (ANQP) elements.............................................. 1127
9.4.5.1 General .............................................................................................. 1127
9.4.5.2 Query List ANQP-element................................................................ 1128
9.4.5.3 Capability List ANQP-element......................................................... 1128
9.4.5.4 Venue Name ANQP-element............................................................ 1129
9.4.5.5 Emergency Call Number ANQP-element......................................... 1130
9.4.5.6 Network Authentication Type ANQP-element................................. 1130
9.4.5.7 Roaming Consortium ANQP-element .............................................. 1132
9.4.5.8 Vendor Specific ANQP-element....................................................... 1132
9.4.5.9 IP Address Type Availability ANQP-element.................................. 1133
9.4.5.10 NAI Realm ANQP-element .............................................................. 1134
9.4.5.11 3GPP Cellular Network ANQP-element........................................... 1137
9.4.5.12 AP Geospatial Location ANQP-element .......................................... 1138
9.4.5.13 AP Civic Location ANQP-element................................................... 1138
9.4.5.14 AP Location Public Identifier URI/FQDN ANQP-element ............. 1139
9.4.5.15 Domain Name ANQP-element ......................................................... 1139
9.4.5.16 Emergency Alert URI ANQP-element ............................................. 1140
9.4.5.17 Emergency NAI ANQP-element ...................................................... 1140
9.4.5.18 TDLS Capability ANQP-element ..................................................... 1140
9.4.5.19 Neighbor Report ANQP-element...................................................... 1141
9.4.5.20 Venue URL ANQP-element ............................................................. 1141
9.4.5.21 Advice of Charge ANQP-element .................................................... 1142
9.4.5.22 Local Content ANQP-element .......................................................... 1143
9.4.5.23 Network Authentication Type with Timestamp ANQP-element...... 1144
34
Copyright © 2016 IEEE. All rights reserved.
9.4.6 Registered location query protocol (RLQP) elements ......................................... 1144
9.4.6.1 General .............................................................................................. 1144
9.4.6.2 Channel Availability Query RLQP-element .................................... 1145
9.4.6.3 Channel Schedule Management RLQP-element............................... 1147
9.4.6.4 Network Channel Control RLQP-element........................................ 1147
9.4.6.5 Vendor Specific RLQP-element ....................................................... 1148
9.5 Fields used in Management and Extension frame bodies and Control frames .................... 1149
9.5.1 Sector Sweep field ............................................................................................... 1149
9.5.2 Dynamic Allocation Info field ............................................................................. 1149
9.5.3 Sector Sweep Feedback field ............................................................................... 1150
9.5.4 BRP Request field................................................................................................ 1151
9.5.5 Beamforming Control field.................................................................................. 1152
9.5.6 Beamformed Link Maintenance field .................................................................. 1154
9.6 Action frame format details ................................................................................................. 1155
9.6.1 Introduction.......................................................................................................... 1155
9.6.2 Spectrum management Action frames ................................................................. 1155
9.6.2.1 General .............................................................................................. 1155
9.6.2.2 Measurement Request frame format ................................................. 1156
9.6.2.3 Measurement Report frame format ................................................... 1156
9.6.2.4 TPC Request frame format ............................................................... 1156
9.6.2.5 TPC Report frame format ................................................................. 1157
9.6.2.6 Channel Switch Announcement frame format.................................. 1157
9.6.3 QoS Action frame details..................................................................................... 1158
9.6.3.1 General .............................................................................................. 1158
9.6.3.2 Basic and DMG ADDTS Request frame format .............................. 1159
9.6.3.3 Basic and DMG ADDTS Response frame format ............................ 1161
9.6.3.4 DELTS frame format ........................................................................ 1163
9.6.3.5 Schedule frame format ...................................................................... 1164
9.6.3.6 QoS Map Configure frame format .................................................... 1165
9.6.3.7 ADDTS Reserve Request frame format............................................ 1165
9.6.3.8 ADDTS Reserve Response frame format ......................................... 1166
9.6.4 DLS Action frame details .................................................................................... 1166
9.6.4.1 General .............................................................................................. 1166
9.6.4.2 DLS Request frame format ............................................................... 1167
9.6.4.3 DLS Response frame format............................................................. 1167
9.6.4.4 DLS Teardown frame format............................................................ 1168
9.6.5 Block Ack Action frame details........................................................................... 1169
9.6.5.1 General .............................................................................................. 1169
9.6.5.2 ADDBA Request frame format......................................................... 1169
9.6.5.3 ADDBA Response frame format ...................................................... 1170
9.6.5.4 DELBA frame format ....................................................................... 1171
9.6.6 Vendor-specific action details ............................................................................. 1172
9.6.7 Radio Measurement action details ....................................................................... 1173
9.6.7.1 General .............................................................................................. 1173
9.6.7.2 Radio Measurement Request frame format ...................................... 1173
9.6.7.3 Radio Measurement Report frame format ........................................ 1174
9.6.7.4 Link Measurement Request frame format ........................................ 1174
9.6.7.5 Link Measurement Report frame format .......................................... 1175
9.6.7.6 Neighbor Report Request frame format............................................ 1175
9.6.7.7 Neighbor Report Response frame format ......................................... 1176
9.6.8 Public Action details ............................................................................................ 1177
9.6.8.1 Public Action frames......................................................................... 1177
9.6.8.2 20/40 BSS Coexistence Management frame format ......................... 1178
9.6.8.3 Measurement Pilot frame format ...................................................... 1179
35
Copyright © 2016 IEEE. All rights reserved.
9.6.8.4 DSE Enablement frame format ......................................................... 1180
9.6.8.5 DSE Deenablement frame format ..................................................... 1181
9.6.8.6 DSE Registered Location Announcement frame format .................. 1182
9.6.8.7 Extended Channel Switch Announcement frame format.................. 1182
9.6.8.8 DSE Measurement Request frame format ........................................ 1183
9.6.8.9 DSE Measurement Report frame format .......................................... 1183
9.6.8.10 DSE Power Constraint frame format ................................................ 1185
9.6.8.11 Vendor Specific Public Action frame format ................................... 1186
9.6.8.12 GAS Initial Request frame format .................................................... 1186
9.6.8.13 GAS Initial Response frame format.................................................. 1187
9.6.8.14 GAS Comeback Request frame format............................................. 1188
9.6.8.15 GAS Comeback Response frame format .......................................... 1189
9.6.8.16 TDLS Discovery Response frame format......................................... 1190
9.6.8.17 Location Track Notification frame format........................................ 1191
9.6.8.18 QMF Policy frame format................................................................. 1192
9.6.8.19 QMF Policy Change frame format.................................................... 1193
9.6.8.20 QLoad Request frame format............................................................ 1193
9.6.8.21 QLoad Report frame format.............................................................. 1194
9.6.8.22 HCCA TXOP Advertisement frame ................................................. 1194
9.6.8.23 HCCA TXOP Response frame ......................................................... 1195
9.6.8.24 Public Key frame .............................................................................. 1196
9.6.8.25 Channel Availability Query frame format ........................................ 1197
9.6.8.26 Channel Schedule Management frame format.................................. 1197
9.6.8.27 Contact Verification Signal frame format......................................... 1199
9.6.8.28 GDD Enablement Request frame format .......................................... 1199
9.6.8.29 GDD Enablement Response frame format........................................ 1200
9.6.8.30 Network Channel Control frame format ........................................... 1200
9.6.8.31 White Space Map Announcement frame format............................... 1201
9.6.8.32 Fine Timing Measurement Request frame format ............................ 1201
9.6.8.33 Fine Timing Measurement frame format .......................................... 1202
9.6.8.34 QAB Request frame format .............................................................. 1205
9.6.8.35 QAB Response frame format............................................................ 1205
9.6.9 FT Action frame details ....................................................................................... 1206
9.6.9.1 General .............................................................................................. 1206
9.6.9.2 FT Request frame.............................................................................. 1207
9.6.9.3 FT Response frame ........................................................................... 1207
9.6.9.4 FT Confirm frame ............................................................................. 1208
9.6.9.5 FT Ack frame .................................................................................... 1209
9.6.10 SA Query Action frame details............................................................................ 1209
9.6.10.1 General .............................................................................................. 1209
9.6.10.2 SA Query Request frame .................................................................. 1210
9.6.10.3 SA Query Response frame................................................................ 1210
9.6.11 Protected Dual of Public Action frames .............................................................. 1211
9.6.12 HT Action frame details ...................................................................................... 1212
9.6.12.1 HT Action field ................................................................................. 1212
9.6.12.2 Notify Channel Width frame format................................................. 1212
9.6.12.3 SM Power Save frame format........................................................... 1213
9.6.12.4 PSMP frame format .......................................................................... 1213
9.6.12.5 Set PCO Phase frame format ............................................................ 1214
9.6.12.6 CSI frame format .............................................................................. 1214
9.6.12.7 Noncompressed Beamforming frame format.................................... 1215
9.6.12.8 Compressed Beamforming frame format.......................................... 1215
9.6.12.9 Antenna Selection Indices Feedback frame format .......................... 1216
9.6.13 TDLS Action field formats .................................................................................. 1216
36
Copyright © 2016 IEEE. All rights reserved.
9.6.13.1 General .............................................................................................. 1216
9.6.13.2 TDLS Setup Request Action field format......................................... 1217
9.6.13.3 TDLS Setup Response Action field format ...................................... 1218
9.6.13.4 TDLS Setup Confirm Action field format ........................................ 1220
9.6.13.5 TDLS Teardown Action field format................................................ 1221
9.6.13.6 TDLS Peer Traffic Indication Action field format ........................... 1221
9.6.13.7 TDLS Channel Switch Request Action field format ........................ 1222
9.6.13.8 TDLS Channel Switch Response Action field format ...................... 1222
9.6.13.9 TDLS Peer PSM Request Action field format.................................. 1223
9.6.13.10 TDLS Peer PSM Response Action field format ............................... 1223
9.6.13.11 TDLS Peer Traffic Response Action field format ............................ 1224
9.6.13.12 TDLS Discovery Request Action field format ................................. 1224
9.6.14 WNM Action details ............................................................................................ 1225
9.6.14.1 WNM Action fields........................................................................... 1225
9.6.14.2 Event Request frame format ............................................................. 1226
9.6.14.3 Event Report frame format ............................................................... 1226
9.6.14.4 Diagnostic Request frame format ..................................................... 1227
9.6.14.5 Diagnostic Report frame format ....................................................... 1227
9.6.14.6 Location Configuration Request frame format ................................. 1228
9.6.14.7 Location Configuration Response frame format............................... 1229
9.6.14.8 BSS Transition Management Query frame format ........................... 1230
9.6.14.9 BSS Transition Management Request frame format ........................ 1230
9.6.14.10 BSS Transition Management Response frame format ...................... 1232
9.6.14.11 FMS Request frame format............................................................... 1233
9.6.14.12 FMS Response frame format ............................................................ 1234
9.6.14.13 Collocated Interference Request frame format ................................. 1234
9.6.14.14 Collocated Interference Report frame format ................................... 1235
9.6.14.15 TFS Request frame format................................................................ 1236
9.6.14.16 TFS Response frame format ............................................................. 1236
9.6.14.17 TFS Notify frame format .................................................................. 1237
9.6.14.18 TFS Notify Response frame format .................................................. 1237
9.6.14.19 WNM Sleep Mode Request frame format ........................................ 1237
9.6.14.20 WNM Sleep Mode Response frame format...................................... 1238
9.6.14.21 TIM Broadcast Request frame format .............................................. 1240
9.6.14.22 TIM Broadcast Response frame format ............................................ 1240
9.6.14.23 QoS Traffic Capability Update frame format ................................... 1241
9.6.14.24 Channel Usage Request frame format .............................................. 1241
9.6.14.25 Channel Usage Response frame format ............................................ 1242
9.6.14.26 DMS Request frame format .............................................................. 1243
9.6.14.27 DMS Response frame format............................................................ 1243
9.6.14.28 Timing Measurement Request frame format .................................... 1243
9.6.14.29 WNM Notification Request frame format ........................................ 1244
9.6.14.30 WNM Notification Response frame format...................................... 1245
9.6.15 Unprotected WNM Action details ....................................................................... 1245
9.6.15.1 Unprotected WNM Action fields...................................................... 1245
9.6.15.2 TIM frame format ............................................................................. 1246
9.6.15.3 Timing Measurement frame format .................................................. 1246
9.6.16 Self-protected Action frame details ..................................................................... 1247
9.6.16.1 Self-protected Action fields .............................................................. 1247
9.6.16.2 Mesh Peering Open frame format ..................................................... 1248
9.6.16.3 Mesh Peering Confirm frame format ................................................ 1249
9.6.16.4 Mesh Peering Close frame format .................................................... 1251
9.6.16.5 Mesh Group Key Inform frame format............................................. 1251
9.6.16.6 Mesh Group Key Acknowledge frame format.................................. 1252
37
Copyright © 2016 IEEE. All rights reserved.
9.6.17 Mesh Action frame details ................................................................................... 1253
9.6.17.1 Mesh Action fields ............................................................................ 1253
9.6.17.2 Mesh Link Metric Report frame format............................................ 1253
9.6.17.3 HWMP Mesh Path Selection frame format ...................................... 1254
9.6.17.4 Gate Announcement frame format.................................................... 1254
9.6.17.5 Congestion Control Notification frame format................................. 1255
9.6.17.6 MCCA Setup Request frame format................................................. 1255
9.6.17.7 MCCA Setup Reply frame format .................................................... 1256
9.6.17.8 MCCA Advertisement Request frame format .................................. 1256
9.6.17.9 MCCA Advertisement frame format ................................................ 1257
9.6.17.10 MCCA Teardown frame format........................................................ 1257
9.6.17.11 TBTT Adjustment Request frame format ......................................... 1258
9.6.17.12 TBTT Adjustment Response frame format....................................... 1258
9.6.18 Multihop Action frame details ............................................................................. 1259
9.6.18.1 Multihop Action fields ...................................................................... 1259
9.6.18.2 Proxy Update frame format............................................................... 1259
9.6.18.3 Proxy Update Confirmation frame format ........................................ 1260
9.6.19 Robust AV Streaming Action frame details ........................................................ 1260
9.6.19.1 General ............................................................................................. 1260
9.6.19.2 SCS Request frame format................................................................ 1261
9.6.19.3 SCS Response frame format ............................................................. 1261
9.6.19.4 Group Membership Request frame format ....................................... 1262
9.6.19.5 Group Membership Response frame format..................................... 1262
9.6.20 DMG Action frame details .................................................................................. 1263
9.6.20.1 DMG Action field ............................................................................. 1263
9.6.20.2 Power Save Configuration Request frame format ............................ 1263
9.6.20.3 Power Save Configuration Response frame format.......................... 1264
9.6.20.4 Information Request frame format.................................................... 1265
9.6.20.5 Information Response frame format ................................................. 1265
9.6.20.6 Handover Request frame format ....................................................... 1266
9.6.20.7 Handover Response frame format..................................................... 1267
9.6.20.8 DTP Request frame format ............................................................... 1267
9.6.20.9 DTP Report frame format ................................................................. 1268
9.6.20.10 Relay Search Request frame format.................................................. 1268
9.6.20.11 Relay Search Response frame format ............................................... 1269
9.6.20.12 Multi-relay Channel Measurement Request frame format ............... 1269
9.6.20.13 Multi-relay Channel Measurement Report frame format ................. 1270
9.6.20.14 RLS Request frame format ............................................................... 1271
9.6.20.15 RLS Response frame format ............................................................. 1272
9.6.20.16 RLS Announcement frame format.................................................... 1272
9.6.20.17 RLS Teardown frame format ............................................................ 1273
9.6.20.18 Relay Ack Request frame format...................................................... 1274
9.6.20.19 Relay Ack Response frame format ................................................... 1274
9.6.20.20 TPA Request frame format ............................................................... 1275
9.6.20.21 TPA Response frame format............................................................. 1275
9.6.20.22 TPA Report frame format ................................................................. 1276
9.6.20.23 ROC Request frame format............................................................... 1276
9.6.20.24 ROC Response frame format ............................................................ 1277
9.6.21 FST Action frame details ..................................................................................... 1278
9.6.21.1 FST Action field................................................................................ 1278
9.6.21.2 FST Setup Request frame format...................................................... 1278
9.6.21.3 FST Setup Response frame format ................................................... 1279
9.6.21.4 FST Teardown frame format............................................................. 1280
9.6.21.5 FST Ack Request frame format ........................................................ 1281
38
Copyright © 2016 IEEE. All rights reserved.
9.6.21.6 FST Ack Response frame format...................................................... 1281
9.6.21.7 On-channel Tunnel Request frame format........................................ 1282
9.6.22 Unprotected DMG Action frame details.............................................................. 1283
9.6.22.1 Unprotected DMG Action field ........................................................ 1283
9.6.22.2 Announce frame format .................................................................... 1283
9.6.22.3 BRP frame format ............................................................................. 1284
9.6.23 VHT Action frame details.................................................................................... 1285
9.6.23.1 VHT Action field .............................................................................. 1285
9.6.23.2 VHT Compressed Beamforming frame format ................................ 1286
9.6.23.3 Group ID Management frame format ............................................... 1286
9.6.23.4 Operating Mode Notification frame format ...................................... 1287
9.7 Aggregate MPDU (A-MPDU)............................................................................................. 1287
9.7.1 A-MPDU format .................................................................................................. 1287
9.7.2 MPDU delimiter CRC field ................................................................................. 1290
9.7.3 A-MPDU contents ............................................................................................... 1290
10. MAC sublayer functional description.............................................................................................. 1295
10.1 Introduction.......................................................................................................................... 1295
10.2 MAC architecture ................................................................................................................ 1295
10.2.1 General................................................................................................................. 1295
10.2.2 DCF...................................................................................................................... 1296
10.2.3 PCF ...................................................................................................................... 1297
10.2.4 Hybrid coordination function (HCF) ................................................................... 1297
10.2.4.1 General .............................................................................................. 1297
10.2.4.2 HCF contention based channel access (EDCA)................................ 1297
10.2.4.3 HCF controlled channel access (HCCA) .......................................... 1300
10.2.5 Mesh coordination function (MCF) ..................................................................... 1301
10.2.6 Combined use of DCF, PCF, and HCF................................................................ 1301
10.2.7 Fragmentation/defragmentation overview ........................................................... 1301
10.2.8 MAC data service ................................................................................................ 1302
10.3 DCF...................................................................................................................................... 1303
10.3.1 General................................................................................................................. 1303
10.3.2 Procedures common to the DCF and EDCAF ..................................................... 1305
10.3.2.1 CS mechanism................................................................................... 1305
10.3.2.2 MAC-level acknowledgments........................................................... 1305
10.3.2.3 IFS..................................................................................................... 1306
10.3.2.4 Setting and resetting the NAV .......................................................... 1310
10.3.2.5 RTS/CTS with fragmentation ........................................................... 1311
10.3.2.6 VHT RTS procedure ......................................................................... 1313
10.3.2.7 CTS and DMG CTS procedure......................................................... 1313
10.3.2.8 Dual CTS protection ......................................................................... 1314
10.3.2.9 Acknowledgment procedure ............................................................. 1316
10.3.2.10 MU acknowledgment procedure....................................................... 1317
10.3.2.11 Duplicate detection and recovery...................................................... 1319
10.3.2.12 NAV distribution............................................................................... 1322
10.3.2.13 Operation of aSlotTime..................................................................... 1323
10.3.3 Random backoff time........................................................................................... 1323
10.3.4 DCF access procedure ......................................................................................... 1324
10.3.4.1 Introduction....................................................................................... 1324
10.3.4.2 Basic access....................................................................................... 1324
10.3.4.3 Backoff procedure for DCF .............................................................. 1325
10.3.4.4 Recovery procedures and retransmit limits....................................... 1328
10.3.4.5 Control of the channel....................................................................... 1329
39
Copyright © 2016 IEEE. All rights reserved.
10.3.5 Individually addressed MPDU transfer procedure .............................................. 1330
10.3.6 Group addressed MPDU transfer procedure........................................................ 1330
10.3.7 DCF timing relations ........................................................................................... 1331
10.3.8 Signal extension ................................................................................................... 1334
10.3.9 Determination of PLME aCWmin characteristics ............................................... 1334
10.4 PCF ...................................................................................................................................... 1334
10.4.1 General................................................................................................................. 1334
10.4.2 CFP structure and timing ..................................................................................... 1335
10.4.3 PCF access procedure .......................................................................................... 1337
10.4.3.1 General .............................................................................................. 1337
10.4.3.2 Fundamental access........................................................................... 1337
10.4.3.3 NAV operation during the CFP ........................................................ 1337
10.4.4 PCF transfer procedure ........................................................................................ 1338
10.4.4.1 General .............................................................................................. 1338
10.4.4.2 PCF transfers when the PC STA is transmitter or recipient ............. 1338
10.4.4.3 Operation with overlapping point-coordinated BSSs ....................... 1340
10.4.4.4 CFPMaxDuration limit ..................................................................... 1340
10.4.4.5 CF usage rules................................................................................... 1340
10.4.5 CF polling list ...................................................................................................... 1341
10.4.5.1 General .............................................................................................. 1341
10.4.5.2 Polling list processing ....................................................................... 1341
10.4.5.3 Polling list update procedure............................................................. 1341
10.5 Fragmentation ...................................................................................................................... 1342
10.6 Defragmentation .................................................................................................................. 1342
10.7 Multirate support.................................................................................................................. 1343
10.7.1 Overview.............................................................................................................. 1343
10.7.2 Basic HT-MCS Set field ...................................................................................... 1344
10.7.3 Basic STBC MCS ................................................................................................ 1344
10.7.4 Basic rate set, basic HT-MCS set, and basic VHT-MCS and NSS set for
mesh STA ............................................................................................................ 1345
10.7.5 Rate selection for Data and Management frames ................................................ 1345
10.7.5.1 Rate selection for non-STBC Beacon and non-STBC PSMP
frames................................................................................................ 1345
10.7.5.2 Rate selection for STBC group addressed Data and Management
frames................................................................................................ 1345
10.7.5.3 Rate selection for other group addressed Data and Management
frames................................................................................................ 1345
10.7.5.4 Rate selection for polling frames ...................................................... 1346
10.7.5.5 Rate selection for +CF-Ack frames .................................................. 1346
10.7.5.6 Rate selection for Data frames sent within an FMS stream .............. 1346
10.7.5.7 Rate selection for other individually addressed Data and
Management frames.......................................................................... 1346
10.7.6 Rate selection for Control frames ........................................................................ 1348
10.7.6.1 General rules for rate selection for Control frames........................... 1348
10.7.6.2 Rate selection for Control frames that initiate a TXOP .................... 1349
10.7.6.3 Rate selection for CF-End frames..................................................... 1349
10.7.6.4 Rate selection for Control frames that are not control response
frames................................................................................................ 1350
10.7.6.5 Rate selection for control response frames ....................................... 1351
10.7.6.6 Channel Width selection for Control frames .................................... 1355
10.7.6.7 Control frame TXVECTOR parameter restrictions .......................... 1356
10.7.7 Multirate support for DMG STAs ....................................................................... 1356
10.7.7.1 Usage of DMG Control modulation class......................................... 1356
40
Copyright © 2016 IEEE. All rights reserved.
10.7.7.2 Rate selection rules for Control frames transmitted by
DMG STAs ....................................................................................... 1356
10.7.7.3 Rate selection for group addressed Data and Management frames
transmitted by DMG STAs ............................................................... 1357
10.7.7.4 Rate selection for individually addressed Data and Management
frames transmitted by DMG STAs ................................................... 1358
10.7.7.5 Rate selection for BRP packets......................................................... 1358
10.7.8 Multiple BSSID Rate Selection ........................................................................... 1358
10.7.9 Modulation classes............................................................................................... 1358
10.7.10 Non-HT basic rate calculation ............................................................................. 1359
10.7.11 Channel Width in non-HT and non-HT duplicate PPDUs .................................. 1360
10.7.12 Rate selection constraints for VHT STAs............................................................ 1361
10.7.12.1 Rx Supported VHT-MCS and NSS Set ............................................ 1361
10.7.12.2 Tx Supported VHT-MCS and NSS Set............................................. 1361
10.7.12.3 Additional rate selection constraints for VHT PPDUs ..................... 1362
10.8 MSDU transmission restrictions .......................................................................................... 1363
10.9 HT Control field operation .................................................................................................. 1364
10.10 Control Wrapper operation .................................................................................................. 1364
10.11 MSDU processing................................................................................................................ 1364
10.12 A-MSDU operation.............................................................................................................. 1365
10.13 A-MPDU operation.............................................................................................................. 1367
10.13.1 A-MPDU contents ............................................................................................... 1367
10.13.2 A-MPDU length limit rules ................................................................................. 1367
10.13.3 Minimum MPDU Start Spacing field .................................................................. 1367
10.13.4 A-MPDU aggregation of group addressed Data frames ...................................... 1368
10.13.5 Transport of A-MPDU by the PHY data service ................................................. 1369
10.13.6 A-MPDU padding for VHT PPDU...................................................................... 1369
10.13.7 Setting the EOF field of the MPDU delimiter ..................................................... 1370
10.13.8 Transport of VHT single MPDUs........................................................................ 1370
10.14 PPDU duration constraint .................................................................................................... 1371
10.15 DMG A-PPDU operation..................................................................................................... 1371
10.16 LDPC operation ................................................................................................................... 1371
10.17 STBC operation ................................................................................................................... 1372
10.18 Short GI operation ............................................................................................................... 1372
10.19 Greenfield operation ............................................................................................................ 1373
10.20 Group ID and partial AID in VHT PPDUs.......................................................................... 1373
10.21 Operation across regulatory domains .................................................................................. 1375
10.21.1 General................................................................................................................. 1375
10.21.2 Operation upon entering a regulatory domain ..................................................... 1375
10.21.3 Operation with operating classes ......................................................................... 1375
10.21.4 Operation with the Transmit Power Envelope element ....................................... 1376
10.21.5 Operation with coverage classes.......................................................................... 1376
10.22 HCF...................................................................................................................................... 1377
10.22.1 General................................................................................................................. 1377
10.22.2 HCF contention based channel access (EDCA) .................................................. 1377
10.22.2.1 Reference model ............................................................................... 1377
10.22.2.2 EDCA backoff procedure.................................................................. 1379
10.22.2.3 EDCA TXOPs................................................................................... 1380
10.22.2.4 Obtaining an EDCA TXOP............................................................... 1380
10.22.2.5 EDCA channel access in a VHT or TVHT BSS ............................... 1383
10.22.2.6 Sharing an EDCA TXOP .................................................................. 1384
10.22.2.7 Multiple frame transmission in an EDCA TXOP ............................. 1384
10.22.2.8 TXOP limits ...................................................................................... 1387
10.22.2.9 Truncation of TXOP ......................................................................... 1388
41
Copyright © 2016 IEEE. All rights reserved.
10.22.2.10 Termination of TXOP ....................................................................... 1389
10.22.2.11 Retransmit procedures....................................................................... 1390
10.22.3 HCF controlled channel access (HCCA) ............................................................. 1392
10.22.3.1 General .............................................................................................. 1392
10.22.3.2 HCCA procedure............................................................................... 1393
10.22.3.3 HCCA TXOP structure and timing................................................... 1396
10.22.3.4 NAV operation of a TXOP under HCCA ......................................... 1397
10.22.3.5 HCCA transfer rules.......................................................................... 1397
10.22.4 Admission control at the HC ............................................................................... 1400
10.22.4.1 General .............................................................................................. 1400
10.22.4.2 Contention based admission control procedures............................... 1400
10.22.4.3 Controlled-access admission control ................................................ 1402
10.23 Mesh coordination function (MCF) ..................................................................................... 1404
10.23.1 General................................................................................................................. 1404
10.23.2 MCF contention based channel access ................................................................ 1404
10.23.3 MCF controlled channel access (MCCA)............................................................ 1404
10.23.3.1 General .............................................................................................. 1404
10.23.3.2 MCCA activation .............................................................................. 1405
10.23.3.3 MCCAOP reservations ..................................................................... 1405
10.23.3.4 Neighborhood MCCAOP periods at a mesh STA ............................ 1406
10.23.3.5 MCCA access fraction (MAF).......................................................... 1407
10.23.3.6 MCCAOP setup procedure ............................................................... 1407
10.23.3.7 MCCAOP advertisement .................................................................. 1408
10.23.3.8 MCCAOP teardown.......................................................................... 1413
10.23.3.9 Access during MCCAOPs ................................................................ 1414
10.23.3.10 Interaction with time synchronization............................................... 1415
10.24 Block acknowledgment (block ack) .................................................................................... 1415
10.24.1 Introduction.......................................................................................................... 1415
10.24.2 Setup and modification of the block ack parameters ........................................... 1416
10.24.3 Data and acknowledgment transfer using immediate block ack policy and
delayed block ack policy...................................................................................... 1418
10.24.4 Receive buffer operation...................................................................................... 1420
10.24.5 Teardown of the block ack mechanism ............................................................... 1421
10.24.6 Selection of BlockAck and BlockAckReq variants ............................................. 1421
10.24.7 HT-immediate block ack extensions.................................................................... 1422
10.24.7.1 Introduction to HT-immediate block ack extensions........................ 1422
10.24.7.2 HT-immediate block ack architecture............................................... 1422
10.24.7.3 Scoreboard context control during full-state operation..................... 1423
10.24.7.4 Scoreboard context control during partial-state operation ................ 1424
10.24.7.5 Generation and transmission of BlockAck frames by an HT STA
or DMG STA .................................................................................... 1425
10.24.7.6 Receive reordering buffer control operation ..................................... 1426
10.24.7.7 Originator’s behavior ........................................................................ 1428
10.24.7.8 Maintaining block ack state at the originator.................................... 1429
10.24.7.9 Originator’s support of recipient’s partial state ................................ 1429
10.24.8 HT-delayed block ack extensions ........................................................................ 1430
10.24.8.1 Introduction....................................................................................... 1430
10.24.8.2 HT-delayed block ack negotiation .................................................... 1430
10.24.8.3 Operation of HT-delayed block ack.................................................. 1430
10.24.9 Protected block ack agreement ............................................................................ 1430
10.24.10 GCR block ack..................................................................................................... 1431
10.24.10.1 Introduction....................................................................................... 1431
10.24.10.2 Scoreboard context control during GCR block ack .......................... 1431
10.24.10.3 GCR block ack BlockAckReq and BlockAck frame exchanges ...... 1432
42
Copyright © 2016 IEEE. All rights reserved.
10.24.11 DMG block ack with flow control ....................................................................... 1434
10.24.11.1 General .............................................................................................. 1434
10.24.11.2 DMG block ack architecture with flow control ................................ 1434
10.24.11.3 Scoreboard context control with flow control................................... 1435
10.24.11.4 Receive Reordering Buffer with flow control operation .................. 1435
10.24.11.5 Generation and transmission of BlockAck frame by a STA with
flow control ....................................................................................... 1437
10.24.11.6 Originator’s behavior with flow control support .............................. 1438
10.25 No Acknowledgment (No Ack) ........................................................................................... 1438
10.26 Protection mechanisms ........................................................................................................ 1438
10.26.1 Introduction.......................................................................................................... 1438
10.26.2 Protection mechanism for non-ERP receivers ..................................................... 1438
10.26.3 Protection mechanisms for transmissions of HT PPDUs .................................... 1440
10.26.3.1 General .............................................................................................. 1440
10.26.3.2 Protection rules for HT STA operating a direct link......................... 1443
10.26.3.3 RIFS protection ................................................................................. 1443
10.26.3.4 Use of OBSS Non-HT STAs Present field ....................................... 1443
10.26.3.5 Protection rules for an HT mesh STA............................................... 1444
10.26.4 L_LENGTH and L_DATARATE parameter values for HT-mixed format
PPDUs.................................................................................................................. 1445
10.26.5 L-SIG TXOP protection....................................................................................... 1446
10.26.5.1 General rules ..................................................................................... 1446
10.26.5.2 L-SIG TXOP protection rules at the TXOP holder........................... 1447
10.26.5.3 L-SIG TXOP protection rules at the TXOP responder ..................... 1449
10.26.5.4 L-SIG TXOP protection NAV update rule ....................................... 1449
10.26.6 Protection rules for VHT STAs ........................................................................... 1449
10.27 MAC frame processing ........................................................................................................ 1449
10.27.1 Introduction.......................................................................................................... 1449
10.27.2 Revision level field processing ............................................................................ 1449
10.27.3 Duration/ID field processing ............................................................................... 1449
10.27.4 Response to an invalid Action frame ................................................................... 1450
10.27.5 Operation of the Dialog Token field.................................................................... 1450
10.27.6 Element parsing ................................................................................................... 1450
10.27.7 Vendor specific element parsing.......................................................................... 1450
10.27.8 Extensible element parsing .................................................................................. 1450
10.27.9 Extensible subelement parsing............................................................................. 1450
10.27.10 Extensible TLV parsing ....................................................................................... 1451
10.28 Reverse direction protocol ................................................................................................... 1451
10.28.1 General................................................................................................................. 1451
10.28.2 Reverse direction (RD) exchange sequence ........................................................ 1451
10.28.3 Rules for RD initiator .......................................................................................... 1452
10.28.4 Rules for RD responder ....................................................................................... 1453
10.29 PSMP operation ................................................................................................................... 1454
10.29.1 General................................................................................................................. 1454
10.29.2 Frame transmission mechanism during PSMP .................................................... 1454
10.29.2.1 PSMP frame transmission (PSMP-DTT and PSMP-UTT)............... 1454
10.29.2.2 PSMP downlink transmission (PSMP-DTT) .................................... 1455
10.29.2.3 PSMP uplink transmission (PSMP-UTT) ......................................... 1455
10.29.2.4 PSMP burst ....................................................................................... 1456
10.29.2.5 Resource allocation within a PSMP burst......................................... 1458
10.29.2.6 PSMP-UTT retransmission ............................................................... 1459
10.29.2.7 PSMP acknowledgment rules ........................................................... 1460
10.29.2.8 PSMP group addressed transmission rules ....................................... 1461
10.29.3 Scheduled PSMP.................................................................................................. 1462
43
Copyright © 2016 IEEE. All rights reserved.
10.29.4 Unscheduled PSMP ............................................................................................. 1462
10.30 Sounding PPDUs ................................................................................................................. 1462
10.31 Link adaptation .................................................................................................................... 1463
10.31.1 Introduction.......................................................................................................... 1463
10.31.2 Link adaptation using the HT variant HT Control field ...................................... 1464
10.31.3 Link adaptation using the VHT variant HT Control field ................................... 1466
10.32 Transmit beamforming ........................................................................................................ 1468
10.32.1 HT steering matrix calculations........................................................................... 1468
10.32.2 HT transmit beamforming with implicit feedback .............................................. 1469
10.32.2.1 General .............................................................................................. 1469
10.32.2.2 Unidirectional implicit transmit beamforming ................................. 1470
10.32.2.3 Bidirectional implicit transmit beamforming.................................... 1471
10.32.2.4 Calibration......................................................................................... 1472
10.32.3 Explicit feedback beamforming........................................................................... 1477
10.32.4 VHT MU beamforming ....................................................................................... 1481
10.33 Antenna selection (ASEL) ................................................................................................... 1481
10.33.1 Introduction.......................................................................................................... 1481
10.33.2 Procedure ............................................................................................................. 1482
10.34 Null data packet (NDP) sounding ........................................................................................ 1485
10.34.1 HT NDP sounding protocol ................................................................................. 1485
10.34.2 Transmission of an HT NDP ............................................................................... 1487
10.34.3 Determination of HT NDP destination ................................................................ 1487
10.34.4 Determination of HT NDP source ....................................................................... 1487
10.34.5 VHT sounding protocol ....................................................................................... 1488
10.34.5.1 General .............................................................................................. 1488
10.34.5.2 Rules for VHT sounding protocol sequences ................................... 1488
10.34.5.3 Rules for fragmented feedback in VHT sounding protocol
sequences .......................................................................................... 1492
10.34.6 Transmission of a VHT NDP............................................................................... 1493
10.35 Mesh forwarding framework ............................................................................................... 1493
10.35.1 General................................................................................................................. 1493
10.35.2 Forwarding information ....................................................................................... 1494
10.35.3 Addressing and forwarding of individually addressed mesh Data frames .......... 1494
10.35.3.1 At source mesh STAs (individually addressed)................................ 1494
10.35.3.2 At intermediate and destination mesh STAs (individually
addressed).......................................................................................... 1495
10.35.4 Addressing and forwarding of group addressed mesh Data frames .................... 1496
10.35.4.1 At source mesh STAs (group addressed) .......................................... 1496
10.35.4.2 At recipient mesh STAs (group addressed) ...................................... 1497
10.35.5 Addressing of Management frames and MMPDU forwarding ........................... 1497
10.35.5.1 General .............................................................................................. 1497
10.35.5.2 MMPDU forwarding using individually addressed Multihop
Action frames.................................................................................... 1498
10.35.5.3 MMPDU forwarding using group addressed Multihop Action
frames................................................................................................ 1498
10.35.6 Detection of duplicate MSDUs/MMPDUs .......................................................... 1499
10.35.7 Mesh STAs that do not forward........................................................................... 1499
10.35.8 MSDU forwarding and unknown destination ...................................................... 1499
10.36 DMG channel access ........................................................................................................... 1500
10.36.1 General................................................................................................................. 1500
10.36.2 Access periods within a beacon interval.............................................................. 1500
10.36.3 ATI transmission rules......................................................................................... 1501
10.36.4 DTI transmission rules......................................................................................... 1503
10.36.5 Contention based access period (CBAP) transmission rules ............................... 1504
44
Copyright © 2016 IEEE. All rights reserved.
10.36.6
Channel access in scheduled DTI ........................................................................ 1505
10.36.6.1 General .............................................................................................. 1505
10.36.6.2 Service period (SP) allocation........................................................... 1506
10.36.6.3 Contention based access period (CBAP) allocation ......................... 1507
10.36.6.4 Pseudo-static allocations ................................................................... 1508
10.36.6.5 Guard time......................................................................................... 1508
10.36.6.6 DMG protected period ...................................................................... 1509
10.36.6.7 Service period recovery .................................................................... 1513
10.36.7 Dynamic allocation of service period .................................................................. 1513
10.36.7.1 General .............................................................................................. 1513
10.36.7.2 Polling period (PP)............................................................................ 1515
10.36.7.3 Grant period (GP).............................................................................. 1516
10.36.8 Dynamic truncation of service period.................................................................. 1517
10.36.9 Dynamic extension of service period................................................................... 1518
10.36.10 Updating multiple NAVs ..................................................................................... 1519
10.37 DMG AP or PCP clustering................................................................................................. 1521
10.37.1 General................................................................................................................. 1521
10.37.2 Cluster formation ................................................................................................. 1522
10.37.2.1 Decentralized AP or PCP cluster formation ..................................... 1522
10.37.2.2 Centralized AP or PCP cluster formation ......................................... 1524
10.37.3 Cluster maintenance............................................................................................. 1527
10.37.3.1 General cluster maintenance ............................................................. 1527
10.37.3.2 Decentralized AP or PCP cluster maintenance ................................. 1527
10.37.3.3 Centralized AP or PCP cluster maintenance..................................... 1528
10.37.3.4 Centralized AP or PCP cluster MAC requirements .......................... 1529
10.37.4 Cluster report and re-scheduling.......................................................................... 1530
10.37.5 Decentralized AP or PCP cluster request ............................................................ 1532
10.38 DMG beamforming.............................................................................................................. 1532
10.38.1 General................................................................................................................. 1532
10.38.2 Sector-level sweep (SLS) phase .......................................................................... 1535
10.38.2.1 General .............................................................................................. 1535
10.38.2.2 Initiator sector sweep (ISS)............................................................... 1537
10.38.2.3 Responder sector sweep (RSS) ......................................................... 1539
10.38.2.4 Sector sweep (SSW) feedback .......................................................... 1541
10.38.2.5 SSW ack............................................................................................ 1542
10.38.3 Beam Refinement Protocol (BRP) phase............................................................. 1543
10.38.3.1 General .............................................................................................. 1543
10.38.3.2 BRP setup subphase .......................................................................... 1545
10.38.4 Beamforming in BTI............................................................................................ 1547
10.38.5 Beamforming in A-BFT....................................................................................... 1548
10.38.5.1 Allocation of A-BFT ........................................................................ 1548
10.38.5.2 Operation during the A-BFT............................................................. 1548
10.38.5.3 STA Beamforming after A-BFT ....................................................... 1552
10.38.5.4 Beamforming in A-BFT with multiple DMG antennas .................... 1553
10.38.6 Beamforming in DTI ........................................................................................... 1553
10.38.6.1 General .............................................................................................. 1553
10.38.6.2 SLS phase execution ......................................................................... 1554
10.38.6.3 Multiple sector ID capture (MIDC) subphase .................................. 1555
10.38.6.4 BRP phase execution ........................................................................ 1563
10.38.7 Beam tracking ...................................................................................................... 1566
10.38.8 State machines ..................................................................................................... 1568
10.39 DMG link adaptation ........................................................................................................... 1570
10.39.1 General................................................................................................................. 1570
10.39.2 DMG TPC............................................................................................................ 1570
45
Copyright © 2016 IEEE. All rights reserved.
10.39.3 Fast link adaptation .............................................................................................. 1571
10.40 DMG dynamic tone pairing (DTP) ...................................................................................... 1572
10.41 DMG relay operation ........................................................................................................... 1573
10.41.1 General................................................................................................................. 1573
10.41.2 Link switching ..................................................................................................... 1573
10.41.2.1 General .............................................................................................. 1573
10.41.2.2 SP request and allocation .................................................................. 1573
10.41.2.3 Usage of RDS.................................................................................... 1574
10.41.2.4 Relay frame exchange rules .............................................................. 1574
10.41.2.5 Link monitoring ................................................................................ 1577
10.41.3 Link cooperation .................................................................................................. 1577
10.41.3.1 TPA procedure .................................................................................. 1577
10.41.3.2 Frame exchange operation ................................................................ 1579
10.41.4 Relay link adaptation ........................................................................................... 1580
11. MLME ............................................................................................................................................. 1581
11.1 Synchronization ................................................................................................................... 1581
11.1.1 General................................................................................................................. 1581
11.1.2 Basic approach ..................................................................................................... 1581
11.1.2.1 TSF for an infrastructure BSS or a PBSS ......................................... 1581
11.1.2.2 TSF for an IBSS................................................................................ 1582
11.1.2.3 TSF for an MBSS.............................................................................. 1582
11.1.3 Maintaining synchronization ............................................................................... 1582
11.1.3.1 General .............................................................................................. 1582
11.1.3.2 Beacon generation in non-DMG infrastructure networks................. 1582
11.1.3.3 Beacon generation in a DMG infrastructure BSS and in a PBSS..... 1583
11.1.3.4 DMG beacon generation before establishment of a BSS.................. 1585
11.1.3.5 Beacon generation in an IBSS .......................................................... 1586
11.1.3.6 Beacon generation in an MBSS ........................................................ 1586
11.1.3.7 Beacon reception............................................................................... 1587
11.1.3.8 Multiple BSSID procedure................................................................ 1588
11.1.3.9 TSF timer accuracy ........................................................................... 1589
11.1.4 Acquiring synchronization, scanning .................................................................. 1589
11.1.4.1 General .............................................................................................. 1589
11.1.4.2 Passive scanning ............................................................................... 1591
11.1.4.3 Active scanning................................................................................. 1591
11.1.4.4 Initializing a BSS .............................................................................. 1596
11.1.4.5 Synchronizing with a BSS ................................................................ 1597
11.1.4.6 Operation of Supported Rates and BSS Membership Selectors
element and Extended Supported Rates and BSS Membership
Selectors element .............................................................................. 1597
11.1.5 Adjusting STA timers .......................................................................................... 1598
11.1.6 Terminating a BSS............................................................................................... 1599
11.1.7 Supported rates and extended supported rates advertisement ............................. 1599
11.2 Power management.............................................................................................................. 1599
11.2.1 General................................................................................................................. 1599
11.2.2 Bufferable MMPDUs........................................................................................... 1600
11.2.3 Power management in a non-DMG infrastructure network................................. 1600
11.2.3.1 General .............................................................................................. 1600
11.2.3.2 STA power management modes ....................................................... 1601
11.2.3.3 AP TIM transmissions ...................................................................... 1602
11.2.3.4 TIM types.......................................................................................... 1602
11.2.3.5 Power management with APSD........................................................ 1603
46
Copyright © 2016 IEEE. All rights reserved.
11.2.3.6 AP operation during the CP .............................................................. 1607
11.2.3.7 AP operation during the CFP ............................................................ 1610
11.2.3.8 Receive operation for STAs in PS mode during the CP ................... 1611
11.2.3.9 Receive operation for STAs in PS mode during the CFP ................. 1612
11.2.3.10 Receive operation using APSD......................................................... 1612
11.2.3.11 STAs operating in the active mode ................................................... 1613
11.2.3.12 AP aging function ............................................................................. 1613
11.2.3.13 PSMP power management ................................................................ 1613
11.2.3.14 TDLS peer power save mode............................................................ 1614
11.2.3.15 TDLS peer U-APSD (TPU) .............................................................. 1616
11.2.3.16 FMS power management .................................................................. 1618
11.2.3.17 TIM Broadcast .................................................................................. 1621
11.2.3.18 WNM sleep mode ............................................................................. 1623
11.2.3.19 VHT TXOP power save.................................................................... 1625
11.2.4 Power management in an IBSS ........................................................................... 1626
11.2.4.1 Introduction....................................................................................... 1626
11.2.4.2 Basic approach .................................................................................. 1626
11.2.4.3 Initialization of power management within an IBSS ........................ 1628
11.2.4.4 STA power state transitions .............................................................. 1628
11.2.5 Power management in an MBSS ......................................................................... 1629
11.2.6 SM power save..................................................................................................... 1629
11.2.7 Power management in a PBSS and DMG infrastructure BSS ............................ 1630
11.2.7.1 General .............................................................................................. 1630
11.2.7.2 Non-AP and non-PCP STA power management mode .................... 1632
11.2.7.3 PCP power management mode ......................................................... 1636
11.2.7.4 ATIM frame usage for power management of non-AP STAs .......... 1639
11.2.8 ATIM frame and frame transmission in IBSS, DMG infrastructure BSS,
and PBSS ............................................................................................................. 1641
11.3 STA authentication and association..................................................................................... 1642
11.3.1 State variables ...................................................................................................... 1642
11.3.2 State transition diagram for nonmesh STAs ........................................................ 1643
11.3.3 Frame filtering based on STA state ..................................................................... 1643
11.3.4 Authentication and deauthentication ................................................................... 1646
11.3.4.1 General .............................................................................................. 1646
11.3.4.2 Authentication—originating STA..................................................... 1646
11.3.4.3 Authentication—destination STA..................................................... 1647
11.3.4.4 Deauthentication—originating STA ................................................. 1647
11.3.4.5 Deauthentication—destination STA ................................................. 1648
11.3.5 Association, reassociation, and disassociation .................................................... 1648
11.3.5.1 General .............................................................................................. 1648
11.3.5.2 Non-AP and non-PCP STA association initiation procedures.......... 1649
11.3.5.3 AP or PCP association receipt procedures........................................ 1651
11.3.5.4 Non-AP and non-PCP STA reassociation initiation procedures....... 1652
11.3.5.5 AP or PCP reassociation receipt procedures..................................... 1655
11.3.5.6 Non-AP and non-PCP STA disassociation initiation procedures ..... 1657
11.3.5.7 Non-AP and non-PCP STA disassociation receipt procedure .......... 1657
11.3.5.8 AP or PCP disassociation initiation procedure ................................. 1658
11.3.5.9 AP or PCP disassociation receipt procedure..................................... 1658
11.3.5.10 PBSS procedures for nonassociated STAs........................................ 1659
11.3.6 Additional mechanisms for an AP collocated with a mesh STA......................... 1659
11.3.7 Communicating PBSS information ..................................................................... 1659
11.3.8 Neighbor report information upon rejection with suggested BSS transition....... 1659
11.4 TS operation......................................................................................................................... 1660
11.4.1 Introduction.......................................................................................................... 1660
47
Copyright © 2016 IEEE. All rights reserved.
11.4.2 TSPEC construction............................................................................................. 1662
11.4.3 TS life cycle ......................................................................................................... 1662
11.4.4 TS setup ............................................................................................................... 1664
11.4.4.1 General .............................................................................................. 1664
11.4.4.2 Non-AP-STA-initiated TS setup....................................................... 1664
11.4.4.3 AP-initiated TS setup ........................................................................ 1665
11.4.4.4 TS setup procedures for both AP and non-AP STA initiation.......... 1666
11.4.4.5 TS renegotiation................................................................................ 1669
11.4.5 TS setup by resource request during a fast BSS transition .................................. 1669
11.4.6 PSMP management.............................................................................................. 1669
11.4.7 Failed TS setup .................................................................................................... 1670
11.4.8 Data transfer......................................................................................................... 1671
11.4.9 TS deletion ........................................................................................................... 1672
11.4.9.1 Deletion of a TS established between an HC, DMG AP, or PCP
and a non-AP and non-PCP STA...................................................... 1672
11.4.9.2 Peer-to-peer TS deletion and deletion of an allocation..................... 1673
11.4.10 TS timeout............................................................................................................ 1675
11.4.11 TS suspension ...................................................................................................... 1676
11.4.12 TS reinstatement .................................................................................................. 1676
11.4.13 DMG allocation formats ...................................................................................... 1678
11.4.13.1 General .............................................................................................. 1678
11.4.13.2 Isochronous allocations..................................................................... 1678
11.4.13.3 Asynchronous allocations ................................................................ 1678
11.4.14 PTP TS operation................................................................................................. 1679
11.5 Block ack operation ............................................................................................................. 1679
11.5.1 Introduction.......................................................................................................... 1679
11.5.2 Setup and modification of the block ack parameters ........................................... 1679
11.5.2.1 General .............................................................................................. 1679
11.5.2.2 Procedure at the originator ................................................................ 1680
11.5.2.3 Procedure at the recipient.................................................................. 1681
11.5.2.4 Procedure common to both originator and recipient......................... 1681
11.5.3 Teardown of the block ack mechanism ............................................................... 1682
11.5.3.1 General .............................................................................................. 1682
11.5.3.2 Procedure at the initiator of the block ack teardown ........................ 1682
11.5.3.3 Procedure at the recipient of the DELBA frame............................... 1682
11.5.4 Error recovery upon a peer failure ....................................................................... 1683
11.6 Higher layer timer synchronization ..................................................................................... 1684
11.6.1 Introduction.......................................................................................................... 1684
11.6.2 Procedure at the STA ........................................................................................... 1685
11.7 DLS operation...................................................................................................................... 1685
11.7.1 General................................................................................................................. 1685
11.7.2 DLS procedures ................................................................................................... 1686
11.7.2.1 General .............................................................................................. 1686
11.7.2.2 Setup procedure at the QoS STA ...................................................... 1687
11.7.2.3 Setup procedure at the AP................................................................. 1687
11.7.2.4 Operation of the DLS Timeout Value field ...................................... 1687
11.7.3 Data transfer after setup ....................................................................................... 1688
11.7.4 DLS teardown ...................................................................................................... 1688
11.7.4.1 General .............................................................................................. 1688
11.7.4.2 STA-initiated DLS teardown procedure ........................................... 1688
11.7.4.3 Teardown procedure at the AP.......................................................... 1689
11.7.4.4 AP-initiated DLS teardown procedure.............................................. 1689
11.7.5 Error recovery upon a peer failure ....................................................................... 1690
11.7.6 Secure DLS operation .......................................................................................... 1690
48
Copyright © 2016 IEEE. All rights reserved.
11.8 TPC procedures.................................................................................................................... 1690
11.8.1 General................................................................................................................. 1690
11.8.2 Association based on transmit power capability.................................................. 1691
11.8.3 Peering based on transmit power capability ........................................................ 1692
11.8.4 Interpretation of transmit power capability ......................................................... 1692
11.8.5 Specification of regulatory and local maximum transmit power levels .............. 1693
11.8.6 Transmit power selection..................................................................................... 1694
11.8.7 Transmit power adaptation .................................................................................. 1694
11.9 DFS procedures.................................................................................................................... 1694
11.9.1 General................................................................................................................. 1694
11.9.2 Association based on supported channels............................................................ 1696
11.9.2.1 Association based on supported channels in a non-DMG BSS ........ 1696
11.9.2.2 Providing supported channels upon association in a DMG BSS ...... 1696
11.9.3 Quieting channels for testing ............................................................................... 1696
11.9.4 Testing channels for radar.................................................................................... 1697
11.9.5 Discontinuing operations after detecting radar .................................................... 1698
11.9.6 Detecting radar..................................................................................................... 1698
11.9.7 Requesting and reporting of measurements......................................................... 1698
11.9.8 Selecting and advertising a new channel ............................................................. 1699
11.9.8.1 General .............................................................................................. 1699
11.9.8.2 Selecting and advertising a new channel in a non-DMG
infrastructure BSS ............................................................................. 1700
11.9.8.3 Selecting and advertising a new channel in an IBSS ........................ 1700
11.9.8.4 MBSS channel switching .................................................................. 1702
11.9.8.5 HT-greenfield transmissions in operating classes that include a
behavior limit of DFS_50_100_Behavior......................................... 1704
11.9.8.6 Selecting and advertising a new channel in a DMG BSS ................. 1705
11.9.9 Channel Switch Announcement element operation............................................. 1705
11.9.10 Future Channel Guidance operation .................................................................... 1705
11.10 Extended channel switching (ECS) ..................................................................................... 1706
11.10.1 General................................................................................................................. 1706
11.10.2 Advertising supported operating classes.............................................................. 1706
11.10.3 Selecting and advertising a new channel and/or operating class ......................... 1706
11.10.3.1 General .............................................................................................. 1706
11.10.3.2 Selecting and advertising a new channel in an infrastructure BSS... 1707
11.10.3.3 Selecting and advertising a new channel in an IBSS ........................ 1708
11.10.3.4 Selecting and advertising a new channel in an MBSS...................... 1708
11.11 Radio measurement procedures ........................................................................................... 1709
11.11.1 General................................................................................................................. 1709
11.11.2 Measurement on operating and nonoperating channels....................................... 1709
11.11.3 Measurement start time........................................................................................ 1709
11.11.4 Measurement Duration ........................................................................................ 1710
11.11.5 Station responsibility for conducting measurements ........................................... 1711
11.11.6 Requesting and reporting of measurements......................................................... 1711
11.11.7 Repeated Measurement Request frames .............................................................. 1714
11.11.8 Triggered autonomous reporting ......................................................................... 1714
11.11.9 Specific measurement usage ................................................................................ 1716
11.11.9.1 Beacon report .................................................................................... 1716
11.11.9.2 Frame report...................................................................................... 1719
11.11.9.3 Channel load report........................................................................... 1720
11.11.9.4 Noise Histogram report..................................................................... 1720
11.11.9.5 STA Statistics report ......................................................................... 1721
11.11.9.6 LCI report (Location configuration information report)................... 1723
11.11.9.7 Measurement Pause........................................................................... 1724
49
Copyright © 2016 IEEE. All rights reserved.
11.11.9.8 Transmit Stream/Category Measurement report............................... 1725
11.11.9.9 Location Civic report ........................................................................ 1726
11.11.9.10 Location Identifier report .................................................................. 1728
11.11.9.11 Fine Timing Measurement Range report .......................................... 1729
11.11.10 Usage of the neighbor report ............................................................................... 1730
11.11.10.1 General .............................................................................................. 1730
11.11.10.2 Requesting a neighbor report ............................................................ 1730
11.11.10.3 Responding to a neighbor report request .......................................... 1731
11.11.11 Link Measurement ............................................................................................... 1733
11.11.12 Measurement of the RPI histogram ..................................................................... 1733
11.11.13 Operation of the Max Transmit Power field ........................................................ 1734
11.11.14 Multiple BSSID set .............................................................................................. 1734
11.11.15 Measurement Pilot frame generation and usage .................................................. 1734
11.11.15.1 General .............................................................................................. 1734
11.11.15.2 Measurement Pilot frame generation by an AP ................................ 1735
11.11.15.3 Measurement pilot usage by a STA .................................................. 1737
11.11.16 Access Delay Measurement................................................................................. 1737
11.11.17 BSS Available Admission Capacity .................................................................... 1737
11.11.18 AP Channel Report .............................................................................................. 1738
11.11.19 Multicast diagnostic reporting ............................................................................. 1738
11.11.20 CCA request and report ....................................................................................... 1739
11.11.21 RPI Histogram request and report ....................................................................... 1739
11.12 DSE procedures ................................................................................................................... 1739
11.12.1 General................................................................................................................. 1739
11.12.2 Enablement and deenablement ............................................................................ 1740
11.12.2.1 General .............................................................................................. 1740
11.12.2.2 Enablement requester STA ............................................................... 1741
11.12.2.3 Enablement responder STA .............................................................. 1741
11.12.2.4 Deenablement requester STA ........................................................... 1741
11.12.2.5 Deenablement responder STA .......................................................... 1742
11.12.3 Registered STA operation.................................................................................... 1742
11.12.4 Enabling STA operation with DSE...................................................................... 1742
11.12.5 Dependent STA operation with DSE................................................................... 1743
11.13 Group addressed robust management frame procedures ..................................................... 1745
11.14 SA Query procedures........................................................................................................... 1745
11.15 HT BSS Operation ............................................................................................................... 1746
11.16 20/40 MHz BSS operation ................................................................................................... 1746
11.16.1 Rules for operation in 20/40 MHz BSS ............................................................... 1746
11.16.2 Basic 20/40 MHz BSS functionality.................................................................... 1746
11.16.3 Channel scanning and selection methods for 20/40 MHz operation ................... 1747
11.16.3.1 General .............................................................................................. 1747
11.16.3.2 Scanning requirements for a 20/40 MHz BSS .................................. 1747
11.16.3.3 Channel management at the AP and in an IBSS............................... 1749
11.16.4 40 MHz PPDU transmission restrictions ............................................................. 1751
11.16.4.1 Fields used to determine 40 MHz PPDU transmission restrictions .. 1751
11.16.4.2 Infrastructure non-AP STA restrictions ............................................ 1751
11.16.4.3 AP restrictions................................................................................... 1752
11.16.4.4 Restrictions on non-AP STAs that are not infrastructure BSS
members ............................................................................................ 1753
11.16.5 Scanning requirements for 40-MHz-capable STA .............................................. 1754
11.16.6 Exemption from OBSS scanning ......................................................................... 1754
11.16.7 Communicating 20/40 BSS coexistence information .......................................... 1755
11.16.8 Support of DSSS/CCK in 40 MHz ...................................................................... 1755
11.16.9 STA CCA sensing in a 20/40 MHz BSS ............................................................. 1756
50
Copyright © 2016 IEEE. All rights reserved.
11.16.10 NAV assertion in 20/40 MHz BSS ...................................................................... 1756
11.16.11 Signaling 40 MHz intolerance ............................................................................. 1756
11.16.12 Switching between 40 MHz and 20 MHz............................................................ 1757
11.17 Phased coexistence operation (PCO) ................................................................................... 1759
11.17.1 General description of PCO ................................................................................. 1759
11.17.2 Operation at a PCO active AP ............................................................................. 1760
11.17.3 Operation at a PCO active non-AP STA ............................................................. 1761
11.18 20/40 BSS Coexistence Management frame usage ............................................................. 1762
11.19 RSNA A-MSDU procedures ............................................................................................... 1763
11.20 Public Action frame addressing ........................................................................................... 1764
11.21 STAs communicating Data frames outside the context of a BSS........................................ 1764
11.22 Timing Advertisement ......................................................................................................... 1764
11.22.1 Introduction.......................................................................................................... 1764
11.22.2 Timing advertisement frame procedures ............................................................. 1765
11.22.3 UTC TSF Offset procedures ................................................................................ 1765
11.23 Tunneled direct-link setup ................................................................................................... 1765
11.23.1 General................................................................................................................. 1765
11.23.2 TDLS payload...................................................................................................... 1767
11.23.3 TDLS Discovery .................................................................................................. 1767
11.23.4 TDLS direct-link establishment........................................................................... 1767
11.23.5 TDLS direct-link teardown .................................................................................. 1769
11.23.6 TDLS channel switching ..................................................................................... 1770
11.23.6.1 General .............................................................................................. 1770
11.23.6.2 General behavior on the off-channel................................................. 1772
11.23.6.3 Setting up a 40 MHz direct link ........................................................ 1773
11.23.6.4 TDLS channel switching and power saving ..................................... 1774
11.23.6.5 Setting up a wide bandwidth off-channel direct link ........................ 1774
11.24 Wireless network management procedures ......................................................................... 1775
11.24.1 Wireless network management dependencies ..................................................... 1775
11.24.2 Event request and report procedures.................................................................... 1776
11.24.2.1 Event request and event report.......................................................... 1776
11.24.2.2 Transition event request and report................................................... 1777
11.24.2.3 RSNA event request and report ........................................................ 1778
11.24.2.4 Peer-to-peer link event request and report ........................................ 1778
11.24.2.5 WNM log event request and report................................................... 1779
11.24.2.6 Vendor Specific event request and report ......................................... 1779
11.24.3 Diagnostic request and report procedures............................................................ 1779
11.24.3.1 Diagnostic request and diagnostic report .......................................... 1779
11.24.3.2 Configuration Profile report.............................................................. 1781
11.24.3.3 Manufacturer information STA report.............................................. 1781
11.24.3.4 Association diagnostic ...................................................................... 1782
11.24.3.5 IEEE 802.1X authentication diagnostic ............................................ 1782
11.24.4 Location track procedures.................................................................................... 1783
11.24.4.1 Location track configuration procedures .......................................... 1783
11.24.4.2 Location track notification procedures ............................................. 1785
11.24.5 Timing measurement procedure .......................................................................... 1787
11.24.6 Fine timing measurement (FTM) procedure........................................................ 1789
11.24.6.1 Overview........................................................................................... 1789
11.24.6.2 FTM capabilities ............................................................................... 1790
11.24.6.3 Fine timing measurement procedure negotiation.............................. 1791
11.24.6.4 Measurement exchange..................................................................... 1793
11.24.6.5 Fine timing measurement parameter modification ........................... 1798
11.24.6.6 Fine timing measurement termination .............................................. 1798
11.24.6.7 LCI and Location Civic retrieval using FTM procedure .................. 1799
51
Copyright © 2016 IEEE. All rights reserved.
11.24.7 BSS transition management for network load balancing..................................... 1800
11.24.7.1 BSS transition capability................................................................... 1800
11.24.7.2 BSS transition management query.................................................... 1800
11.24.7.3 BSS transition management request ................................................. 1801
11.24.7.4 BSS transition management response ............................................... 1802
11.24.8 FMS multicast rate processing............................................................................. 1803
11.24.9 Collocated interference reporting ........................................................................ 1804
11.24.10 QoS Traffic capability procedure ........................................................................ 1805
11.24.11 AC Station Count................................................................................................. 1806
11.24.12 TFS procedures .................................................................................................... 1806
11.24.12.1 TFS capability ................................................................................... 1806
11.24.12.2 TFS non-AP STA operation.............................................................. 1808
11.24.12.3 TFS AP operation.............................................................................. 1808
11.24.13 BSS max idle period management....................................................................... 1809
11.24.14 Proxy ARP (including Proxy Neighbor Discovery) service ................................ 1809
11.24.15 Channel usage procedures ................................................................................... 1810
11.24.16 Group addressed transmission service ................................................................. 1811
11.24.16.1 General .............................................................................................. 1811
11.24.16.2 DMS procedures ............................................................................... 1811
11.24.16.3 GCR procedures................................................................................ 1814
11.24.17 WNM notification................................................................................................ 1824
11.25 WLAN interworking with external networks procedures.................................................... 1824
11.25.1 General................................................................................................................. 1824
11.25.2 Interworking capabilities and information........................................................... 1825
11.25.3 Interworking procedures: generic advertisement service (GAS)......................... 1825
11.25.3.1 Introduction....................................................................................... 1825
11.25.3.2 GAS Protocol .................................................................................... 1826
11.25.3.3 ANQP procedures ............................................................................. 1833
11.25.3.4 Registered location query protocol (RLQP) procedures................... 1838
11.25.4 Interworking procedures: IEEE 802.21 MIH support ......................................... 1838
11.25.5 Interworking procedures: interactions with SSPN............................................... 1839
11.25.5.1 General operation .............................................................................. 1839
11.25.5.2 Authentication and cipher suites selection with SSPN ..................... 1839
11.25.5.3 Reporting and session control with SSPN ........................................ 1840
11.25.6 Interworking procedures: emergency services support ....................................... 1841
11.25.7 Interworking procedures: emergency alert system (EAS) support ...................... 1842
11.25.8 Interworking procedures: support for the advertisement of roaming
consortiums.......................................................................................................... 1843
11.25.9 Interworking procedures: support for QoS mapping from external networks..... 1843
11.26 Quality-of-service management frame (QMF) .................................................................... 1844
11.26.1 General................................................................................................................. 1844
11.26.1.1 Overview........................................................................................... 1844
11.26.1.2 Default QMF policy .......................................................................... 1845
11.26.2 QMF policy advertisement and configuration procedures .................................. 1847
11.26.2.1 Overview........................................................................................... 1847
11.26.2.2 QMF policy change in an infrastructure BSS or in an MBSS .......... 1848
11.26.2.3 QMF policy configuration in an infrastructure BSS ......................... 1849
11.26.2.4 QMF policy configuration in an IBSS or OCB................................. 1850
11.26.2.5 QMF policy configuration in an MBSS............................................ 1850
11.26.3 Interpreting QMF access categories .................................................................... 1850
11.27 Robust AV streaming .......................................................................................................... 1851
11.27.1 Robust AV streaming dependencies .................................................................... 1851
11.27.2 SCS procedures.................................................................................................... 1851
11.28 Procedures to manage OBSS ............................................................................................... 1853
52
Copyright © 2016 IEEE. All rights reserved.
11.28.1 General ................................................................................................................ 1853
11.28.2 QLoad Report element......................................................................................... 1853
11.28.2.1 Introduction....................................................................................... 1853
11.28.2.2 Calculating field values .................................................................... 1854
11.28.2.3 Requesting QLoad Reports using radio measurement requests........ 1855
11.28.3 HCCA TXOP negotiation ................................................................................... 1856
11.28.4 HCCA AP timing synchronization for HCCA TXOP advertisement.................. 1860
11.28.4.1 General ............................................................................................. 1860
11.28.4.2 Timing offset..................................................................................... 1860
11.28.4.3 Clock drift adjustment ...................................................................... 1860
11.29 DMG beamformed link and BSS maintenance.................................................................... 1861
11.29.1 Beamformed link maintenance ............................................................................ 1861
11.29.2 PCP Handover...................................................................................................... 1863
11.29.2.1 General .............................................................................................. 1863
11.29.2.2 Explicit handover procedure ............................................................. 1864
11.29.2.3 Implicit handover procedure ............................................................. 1865
11.30 DMG BSS peer and service discovery ............................................................................... 1865
11.30.1 Information Request and Response ..................................................................... 1865
11.30.2 Peer Service Discovery ........................................................................................ 1866
11.31 Changing DMG BSS parameters ........................................................................................ 1867
11.31.1 General................................................................................................................. 1867
11.31.2 Moving the TBTT ................................................................................................ 1867
11.31.3 Changing beacon interval duration ...................................................................... 1868
11.31.4 Maintaining synchronization in an AP or PCP cluster ........................................ 1869
11.31.5 Recommending DMG BSS parameters to the AP or PCP................................... 1869
11.32 Spatial sharing and interference mitigation for DMG STAs ............................................... 1870
11.32.1 General................................................................................................................. 1870
11.32.2 Spatial sharing and interference assessment ........................................................ 1870
11.32.3 Achieving spatial sharing and interference mitigation ........................................ 1871
11.32.4 PBSS and infrastructure BSS stability in OBSS scenarios.................................. 1873
11.33 Multi-band operation .......................................................................................................... 1873
11.33.1 General................................................................................................................. 1873
11.33.2 FST setup protocol............................................................................................... 1875
11.33.2.1 General .............................................................................................. 1875
11.33.2.2 Transitioning between states............................................................. 1877
11.33.2.3 FST TS switching.............................................................................. 1882
11.33.3 FST teardown....................................................................................................... 1884
11.33.4 On-channel Tunneling (OCT) operation.............................................................. 1884
11.33.5 FST payload ......................................................................................................... 1886
11.34 MMSL cluster operation ..................................................................................................... 1886
11.34.1 Introduction.......................................................................................................... 1886
11.34.2 MMSL cluster setup............................................................................................. 1887
11.34.2.1 General .............................................................................................. 1887
11.34.2.2 MMSL cluster setup of non-AP and non-PCP MM-SME
coordinated STA with AP or PCP..................................................... 1888
11.34.2.3 MMSL cluster setup of non-AP and non-PCP STA with another
non-AP and non-PCP STA ............................................................... 1888
11.35 DMG coexistence with non-IEEE-802.11 systems ............................................................. 1888
11.36 DMG relay procedures......................................................................................................... 1889
11.36.1 General................................................................................................................. 1889
11.36.2 Common relay setup procedures.......................................................................... 1890
11.36.2.1 Introduction....................................................................................... 1890
11.36.2.2 Relay capabilities and RDS discovery procedures ........................... 1890
11.36.2.3 RDS selection procedure................................................................... 1890
53
Copyright © 2016 IEEE. All rights reserved.
11.36.2.4 RLS procedure .................................................................................. 1891
11.36.3 Relay operation-type change procedure .............................................................. 1891
11.36.4 Relay teardown .................................................................................................... 1892
11.37 Quieting adjacent DMG BSSs ............................................................................................. 1892
11.37.1 General................................................................................................................. 1892
11.37.2 Procedure at the requester AP.............................................................................. 1893
11.37.3 Procedure at the responder AP............................................................................. 1893
11.38 DMG beamforming.............................................................................................................. 1894
11.39 DMG MAC sublayer attributes............................................................................................ 1896
11.40 VHT BSS operation ............................................................................................................. 1896
11.40.1 Basic VHT BSS functionality.............................................................................. 1896
11.40.2 Channel selection methods for a VHT BSS......................................................... 1900
11.40.3 Scanning requirements for VHT STA ................................................................. 1900
11.40.4 Channel switching methods for a VHT BSS ....................................................... 1900
11.40.5 NAV assertion in a VHT BSS ............................................................................. 1903
11.40.6 VHT STA antenna indication .............................................................................. 1903
11.40.7 Basic VHT-MCS and NSS set operation ............................................................. 1903
11.40.8 Extended NSS BW Support Signaling................................................................. 1904
11.41 Group ID management operation ........................................................................................ 1904
11.42 Notification of operating mode changes .............................................................................. 1905
11.43 Basic TVHT BSS functionality ........................................................................................... 1907
11.44 Operation under the control of a GDB................................................................................. 1908
11.44.1 General................................................................................................................. 1908
11.44.2 GDD enabling STA operation ............................................................................. 1909
11.44.3 GDD dependent STA operation........................................................................... 1909
11.44.4 Channel availability query (CAQ) procedure ...................................................... 1911
11.44.4.1 Introduction....................................................................................... 1911
11.44.4.2 CAQ requesting STA ........................................................................ 1912
11.44.4.3 CAQ responding STA....................................................................... 1912
11.44.5 Channel schedule management (CSM) procedures ............................................. 1914
11.44.5.1 Introduction....................................................................................... 1914
11.44.5.2 CSM requesting STA ........................................................................ 1915
11.44.5.3 CSM responding STA....................................................................... 1915
11.44.6 Contact verification signal (CVS)........................................................................ 1916
11.44.7 Network channel control (NCC) procedures ....................................................... 1916
11.44.7.1 Introduction....................................................................................... 1916
11.44.7.2 NCC requesting STA ........................................................................ 1917
11.44.7.3 NCC responding STA ....................................................................... 1918
11.44.8 Reduced neighbor report...................................................................................... 1918
11.44.9 White space map (WSM)..................................................................................... 1919
11.45 Beacon RSSI ........................................................................................................................ 1920
11.46 Estimated throughput ........................................................................................................... 1920
12. Security ............................................................................................................................................ 1923
12.1 Conventions ......................................................................................................................... 1923
12.2 Framework ........................................................................................................................... 1923
12.2.1 Classes of security algorithm ............................................................................... 1923
12.2.2 Security methods.................................................................................................. 1923
12.2.3 RSNA STA capabilities ....................................................................................... 1923
12.2.4 RSNA establishment............................................................................................ 1923
12.2.5 RSNA PeerKey Support ...................................................................................... 1925
12.2.6 RSNA assumptions and constraints..................................................................... 1926
12.2.7 Requirements for the Protected Frame field ........................................................ 1927
54
Copyright © 2016 IEEE. All rights reserved.
12.2.8 Requirements for robust management frame protection...................................... 1927
12.2.9 Emergency service establishment in an RSN ...................................................... 1927
12.3 Pre-RSNA security methods ................................................................................................ 1927
12.3.1 Status of Pre-RSNA security methods................................................................. 1927
12.3.2 Wired equivalent privacy (WEP)......................................................................... 1928
12.3.2.1 WEP overview .................................................................................. 1928
12.3.2.2 WEP MPDU format .......................................................................... 1928
12.3.2.3 WEP state.......................................................................................... 1928
12.3.2.4 WEP procedures................................................................................ 1929
12.3.3 Pre-RSNA authentication .................................................................................... 1931
12.3.3.1 Overview........................................................................................... 1931
12.3.3.2 Open System authentication.............................................................. 1931
12.3.3.3 Shared Key authentication ................................................................ 1932
12.4 Authentication using a password ......................................................................................... 1935
12.4.1 SAE overview ...................................................................................................... 1935
12.4.2 Assumptions on SAE ........................................................................................... 1936
12.4.3 Representation of a password .............................................................................. 1936
12.4.4 Finite cyclic groups.............................................................................................. 1936
12.4.4.1 General .............................................................................................. 1936
12.4.4.2 Elliptic curve cryptography (ECC) groups ....................................... 1937
12.4.4.3 Finite field cryptography (FFC) groups ............................................ 1940
12.4.5 SAE protocol........................................................................................................ 1941
12.4.5.1 Message exchanges ........................................................................... 1941
12.4.5.2 PWE and secret generation ............................................................... 1942
12.4.5.3 Construction of an SAE Commit message........................................ 1942
12.4.5.4 Processing of a peer’s SAE Commit message .................................. 1942
12.4.5.5 Construction of an SAE Confirm message ....................................... 1943
12.4.5.6 Processing of a peer’s SAE Confirm message.................................. 1943
12.4.6 Anti-clogging tokens............................................................................................ 1943
12.4.7 Framing of SAE ................................................................................................... 1944
12.4.7.1 General .............................................................................................. 1944
12.4.7.2 Data type conversion......................................................................... 1944
12.4.7.3 Authentication transaction sequence number for SAE ..................... 1945
12.4.7.4 Encoding and decoding of SAE Commit messages.......................... 1945
12.4.7.5 Encoding and decoding of SAE Confirm messages ......................... 1946
12.4.7.6 Status codes....................................................................................... 1946
12.4.8 SAE finite state machine...................................................................................... 1946
12.4.8.1 General .............................................................................................. 1946
12.4.8.2 States ................................................................................................. 1947
12.4.8.3 Events and output.............................................................................. 1948
12.4.8.4 Timers ............................................................................................... 1948
12.4.8.5 Variables ........................................................................................... 1949
12.4.8.6 Behavior of state machine................................................................. 1949
12.5 RSNA confidentiality and integrity protocols ..................................................................... 1953
12.5.1 Overview.............................................................................................................. 1953
12.5.2 Temporal key integrity protocol (TKIP).............................................................. 1953
12.5.2.1 TKIP overview.................................................................................. 1953
12.5.2.2 TKIP MPDU formats ........................................................................ 1956
12.5.2.3 TKIP MIC ......................................................................................... 1957
12.5.2.4 TKIP countermeasures procedures ................................................... 1959
12.5.2.5 TKIP mixing function ....................................................................... 1963
12.5.2.6 TKIP replay protection procedures ................................................... 1967
12.5.3 CTR with CBC-MAC protocol (CCMP) ............................................................. 1967
12.5.3.1 General .............................................................................................. 1967
55
Copyright © 2016 IEEE. All rights reserved.
12.5.3.2 CCMP MPDU format ....................................................................... 1968
12.5.3.3 CCMP cryptographic encapsulation ................................................. 1969
12.5.3.4 CCMP decapsulation......................................................................... 1972
12.5.4 Broadcast/multicast integrity protocol (BIP) ....................................................... 1974
12.5.4.1 BIP overview..................................................................................... 1974
12.5.4.2 BIP MMPDU format......................................................................... 1975
12.5.4.3 BIP AAD construction ...................................................................... 1975
12.5.4.4 BIP replay protection ........................................................................ 1975
12.5.4.5 BIP transmission ............................................................................... 1976
12.5.4.6 BIP reception..................................................................................... 1976
12.5.5 GCM protocol (GCMP) ....................................................................................... 1977
12.5.5.1 GCMP overview ............................................................................... 1977
12.5.5.2 GCMP MPDU format ....................................................................... 1978
12.5.5.3 GCMP cryptographic encapsulation ................................................. 1978
12.5.5.4 GCMP decapsulation ........................................................................ 1980
12.6 RSNA security association management ............................................................................. 1982
12.6.1 Security associations............................................................................................ 1982
12.6.1.1 Security association definitions ........................................................ 1982
12.6.1.2 TPKSA .............................................................................................. 1987
12.6.1.3 Security association life cycle........................................................... 1988
12.6.2 RSNA selection.................................................................................................... 1991
12.6.3 RSNA policy selection in an infrastructure BSS ................................................. 1991
12.6.4 TSN policy selection in an infrastructure BSS .................................................... 1992
12.6.5 RSNA policy selection in an IBSS and for DLS ................................................. 1993
12.6.6 TSN policy selection in an IBSS ......................................................................... 1994
12.6.7 RSNA policy selection in an MBSS .................................................................... 1994
12.6.8 RSNA policy selection in a PBSS ....................................................................... 1995
12.6.9 RSN management of the IEEE 802.1X Controlled Port...................................... 1995
12.6.10 RSNA authentication in an infrastructure BSS.................................................... 1996
12.6.10.1 General .............................................................................................. 1996
12.6.10.2 Preauthentication and RSNA key management ................................ 1996
12.6.10.3 Cached PMKSAs and RSNA key management................................ 1997
12.6.11 RSNA authentication in an IBSS......................................................................... 1998
12.6.12 RSNA authentication in an MBSS....................................................................... 1999
12.6.13 RSNA authentication in a PBSS .......................................................................... 1999
12.6.14 RSNA key management in an infrastructure BSS ............................................... 2000
12.6.15 RSNA key management in an IBSS .................................................................... 2000
12.6.16 RSNA key management in an MBSS .................................................................. 2001
12.6.17 RSNA key management in a PBSS ..................................................................... 2001
12.6.18 RSNA security association termination ............................................................... 2001
12.6.19 Protection of robust Management frames ............................................................ 2002
12.6.20 Robust management frame selection procedure .................................................. 2003
12.6.21 RSNA rekeying.................................................................................................... 2004
12.6.22 Multi-band RSNA ............................................................................................... 2004
12.6.22.1 General .............................................................................................. 2004
12.6.22.2 Nontransparent multi-band RSNA ................................................... 2005
12.6.22.3 Transparent multi-band RSNA ........................................................ 2006
12.6.22.4 Multi-band RSNA with TDLS in a non-DMG BSS ......................... 2006
12.7 Keys and key distribution .................................................................................................... 2007
12.7.1 Key hierarchy....................................................................................................... 2007
12.7.1.1 General .............................................................................................. 2007
12.7.1.2 PRF.................................................................................................... 2008
12.7.1.3 Pairwise key hierarchy ...................................................................... 2009
12.7.1.4 Group key hierarchy.......................................................................... 2011
56
Copyright © 2016 IEEE. All rights reserved.
12.7.1.5 Integrity group key hierarchy............................................................ 2012
12.7.1.6 PeerKey key hierarchy ...................................................................... 2012
12.7.1.7 FT key hierarchy ............................................................................... 2014
12.7.2 EAPOL-Key frames............................................................................................. 2018
12.7.3 EAPOL-Key frame construction and processing................................................. 2027
12.7.4 EAPOL-Key frame notation ................................................................................ 2028
12.7.5 Nonce generation ................................................................................................. 2028
12.7.6 4-way handshake.................................................................................................. 2029
12.7.6.1 General .............................................................................................. 2029
12.7.6.2 4-way handshake message 1 ............................................................. 2030
12.7.6.3 4-way handshake message 2 ............................................................. 2031
12.7.6.4 4-way handshake message 3 ............................................................. 2033
12.7.6.5 4-way handshake message 4 ............................................................. 2035
12.7.6.6 4-way handshake implementation considerations............................. 2037
12.7.6.7 Sample 4-way handshake.................................................................. 2037
12.7.6.8 4-way handshake analysis................................................................. 2038
12.7.7 Group key handshake........................................................................................... 2040
12.7.7.1 General .............................................................................................. 2040
12.7.7.2 Group key handshake message 1 ...................................................... 2041
12.7.7.3 Group key handshake message 2 ...................................................... 2042
12.7.7.4 Group key handshake implementation considerations...................... 2042
12.7.7.5 Sample group key handshake............................................................ 2042
12.7.8 PeerKey handshake.............................................................................................. 2043
12.7.8.1 General .............................................................................................. 2043
12.7.8.2 SMK handshake ................................................................................ 2044
12.7.8.3 PeerKey setup and handshake error conditions ................................ 2049
12.7.8.4 STKSA rekeying ............................................................................... 2050
12.7.8.5 Error reporting................................................................................... 2051
12.7.9 TDLS PeerKey (TPK) security protocol ............................................................. 2052
12.7.9.1 General .............................................................................................. 2052
12.7.9.2 TPK handshake ................................................................................. 2052
12.7.9.3 TPK handshake security assumptions............................................... 2054
12.7.9.4 TPK Security Protocol handshake messages .................................... 2054
12.7.9.5 Supplicant state machine procedures ................................................ 2058
12.7.9.6 Supplicant PeerKey state machine states .......................................... 2060
12.7.9.7 Supplicant PeerKey state machine variables .................................... 2062
12.7.10 RSNA Supplicant key management state machine.............................................. 2062
12.7.10.1 General .............................................................................................. 2062
12.7.10.2 Supplicant state machine states......................................................... 2063
12.7.10.3 Supplicant state machine variables ................................................... 2063
12.7.11 RSNA Authenticator key management state machine......................................... 2064
12.7.11.1 General .............................................................................................. 2064
12.7.11.2 Authenticator state machine states.................................................... 2068
12.7.11.3 Authenticator state machine variables .............................................. 2069
12.7.11.4 Authenticator state machine procedures ........................................... 2070
12.8 Mapping EAPOL keys to IEEE 802.11 keys....................................................................... 2070
12.8.1 Mapping PTK to TKIP keys ................................................................................ 2070
12.8.2 Mapping GTK to TKIP keys ............................................................................... 2070
12.8.3 Mapping PTK to CCMP keys .............................................................................. 2071
12.8.4 Mapping GTK to CCMP keys ............................................................................. 2071
12.8.5 Mapping GTK to WEP-40 keys........................................................................... 2071
12.8.6 Mapping GTK to WEP-104 keys......................................................................... 2071
12.8.7 Mapping IGTK to BIP keys................................................................................. 2071
12.8.8 Mapping PTK to GCMP keys.............................................................................. 2071
57
Copyright © 2016 IEEE. All rights reserved.
12.8.9 Mapping GTK to GCMP keys ............................................................................. 2071
12.9 Per-frame pseudocode.......................................................................................................... 2072
12.9.1 WEP frame pseudocode....................................................................................... 2072
12.9.2 RSNA frame pseudocode..................................................................................... 2073
12.9.2.1 General .............................................................................................. 2073
12.9.2.2 Per-MSDU/Per-A-MSDU Tx pseudocode........................................ 2073
12.9.2.3 Per-MMPDU Tx pseudocode............................................................ 2074
12.9.2.4 Per-MPDU Tx pseudocode ............................................................... 2076
12.9.2.5 Per-MPDU Tx pseudocode for MMPDU ......................................... 2077
12.9.2.6 Per-MPDU Rx pseudocode............................................................... 2077
12.9.2.7 Per-MPDU Rx pseudocode for an MMPDU .................................... 2078
12.9.2.8 Per-MSDU/Per-A-MSDU Rx pseudocode ....................................... 2082
12.9.2.9 Per-MMPDU Rx pseudocode ........................................................... 2083
12.10 Authenticated mesh peering exchange (AMPE).................................................................. 2084
12.11 AP PeerKey support............................................................................................................. 2084
12.11.1 AP PeerKey overview.......................................................................................... 2084
12.11.2 AP PeerKey protocol ........................................................................................... 2085
13. Fast BSS transition........................................................................................................................... 2089
13.1 Overview.............................................................................................................................. 2089
13.2 Key holders .......................................................................................................................... 2089
13.2.1 Introduction.......................................................................................................... 2089
13.2.2 Authenticator key holders .................................................................................... 2090
13.2.3 Supplicant key holders......................................................................................... 2091
13.3 Capability and policy advertisement.................................................................................... 2092
13.4 FT initial mobility domain association ................................................................................ 2092
13.4.1 Overview.............................................................................................................. 2092
13.4.2 FT initial mobility domain association in an RSN .............................................. 2092
13.4.3 FT initial mobility domain association in a non-RSN ......................................... 2095
13.5 FT protocol .......................................................................................................................... 2096
13.5.1 Overview.............................................................................................................. 2096
13.5.2 Over-the-air FT protocol authentication in an RSN ............................................ 2096
13.5.3 Over-the-DS FT protocol in an RSN ................................................................... 2098
13.5.4 Over-the-air FT protocol in a non-RSN............................................................... 2100
13.5.5 Over-the-DS FT protocol in a non-RSN.............................................................. 2101
13.6 FT resource request protocol ............................................................................................... 2102
13.6.1 Overview.............................................................................................................. 2102
13.6.2 Over-the-air fast BSS transition with resource request ....................................... 2102
13.6.3 Over-the-DS fast BSS transition with resource request....................................... 2104
13.7 FT reassociation ................................................................................................................... 2107
13.7.1 FT reassociation in an RSN ................................................................................. 2107
13.7.2 FT reassociation in a non-RSN ............................................................................ 2108
13.8 FT authentication sequence ................................................................................................. 2109
13.8.1 Overview.............................................................................................................. 2109
13.8.2 FT authentication sequence: contents of first message........................................ 2110
13.8.3 FT authentication sequence: contents of second message ................................... 2110
13.8.4 FT authentication sequence: contents of third message....................................... 2111
13.8.5 FT authentication sequence: contents of fourth message .................................... 2112
13.9 FT security architecture state machines............................................................................... 2113
13.9.1 Introduction.......................................................................................................... 2113
13.9.2 R0KH state machine ............................................................................................ 2113
13.9.2.1 General .............................................................................................. 2113
13.9.2.2 R0KH state machine states ............................................................... 2114
58
Copyright © 2016 IEEE. All rights reserved.
13.9.2.3 R0KH state machine variables.......................................................... 2115
13.9.2.4 R0KH state machine procedures....................................................... 2115
13.9.3 R1KH state machine ............................................................................................ 2115
13.9.3.1 General .............................................................................................. 2115
13.9.3.2 R1KH state machine states ............................................................... 2117
13.9.3.3 R1KH state machine variables.......................................................... 2118
13.9.3.4 R1KH state machine procedures....................................................... 2119
13.9.4 S0KH state machine............................................................................................. 2119
13.9.4.1 General .............................................................................................. 2119
13.9.4.2 S0KH state machine states................................................................ 2119
13.9.4.3 S0KH state machine variables .......................................................... 2120
13.9.4.4 S0KH state machine procedures ....................................................... 2120
13.9.5 S1KH state machine............................................................................................. 2120
13.9.5.1 General .............................................................................................. 2120
13.9.5.2 S1KH state machine states................................................................ 2120
13.9.5.3 S1KH state machine variables .......................................................... 2123
13.9.5.4 S1KH state machine procedures ....................................................... 2124
13.10 Remote request broker (RRB) communication ................................................................... 2124
13.10.1 Overview.............................................................................................................. 2124
13.10.2 Remote request broker (RRB) ............................................................................. 2124
13.10.3 Remote Request/Response frame definition........................................................ 2125
13.11 Resource request procedures ............................................................................................... 2126
13.11.1 General................................................................................................................. 2126
13.11.2 Resource information container (RIC) ................................................................ 2126
13.11.3 Creation and handling of a resource request........................................................ 2129
13.11.3.1 FTO procedures................................................................................. 2129
13.11.3.2 AP procedures ................................................................................... 2130
14. MLME mesh procedures ................................................................................................................. 2132
14.1 Mesh STA dependencies ..................................................................................................... 2132
14.2 Mesh discovery .................................................................................................................... 2132
14.2.1 General................................................................................................................. 2132
14.2.2 Mesh identifier ..................................................................................................... 2132
14.2.3 Mesh profile ......................................................................................................... 2133
14.2.4 Mesh STA configuration ..................................................................................... 2133
14.2.5 Supplemental information for the mesh discovery .............................................. 2133
14.2.6 Scanning mesh BSSs ........................................................................................... 2134
14.2.7 Candidate peer mesh STA ................................................................................... 2134
14.2.8 Establishing or becoming a member of a mesh BSS ........................................... 2135
14.2.9 Establishing mesh peerings.................................................................................. 2135
14.3 Mesh peering management (MPM) ..................................................................................... 2136
14.3.1 General................................................................................................................. 2136
14.3.2 State variable management .................................................................................. 2137
14.3.3 Mesh authentication ............................................................................................. 2137
14.3.4 Mesh peering instance controller ......................................................................... 2138
14.3.4.1 Overview........................................................................................... 2138
14.3.4.2 Creating a new mesh peering instance.............................................. 2138
14.3.4.3 Deleting mesh peering instances....................................................... 2139
14.3.5 Mesh peering instance selection .......................................................................... 2139
14.3.6 Mesh peering open............................................................................................... 2140
14.3.6.1 Generating Mesh Peering Open frames ............................................ 2140
14.3.6.2 Mesh Peering Open frame processing .............................................. 2140
14.3.7 Mesh peering confirm .......................................................................................... 2140
59
Copyright © 2016 IEEE. All rights reserved.
14.3.7.1 Generating Mesh Peering Confirm frames ....................................... 2140
14.3.7.2 Mesh Peering Confirm frame processing.......................................... 2141
14.3.8 Mesh peering close .............................................................................................. 2141
14.3.8.1 Generating Mesh Peering Close frames............................................ 2141
14.3.8.2 Mesh Peering Close frame processing .............................................. 2141
14.4 Mesh peering management finite state machine (MPM FSM)............................................ 2141
14.4.1 General................................................................................................................. 2141
14.4.2 States .................................................................................................................... 2141
14.4.3 Events and actions ............................................................................................... 2142
14.4.4 Timers .................................................................................................................. 2143
14.4.5 State transitions.................................................................................................... 2144
14.4.6 IDLE state ............................................................................................................ 2145
14.4.7 OPN_SNT state.................................................................................................... 2146
14.4.8 CNF_RCVD state ................................................................................................ 2146
14.4.9 OPN_RCVD state ................................................................................................ 2147
14.4.10 ESTAB state ........................................................................................................ 2148
14.4.11 HOLDING state ................................................................................................... 2148
14.5 Authenticated mesh peering exchange (AMPE).................................................................. 2148
14.5.1 Overview.............................................................................................................. 2148
14.5.2 Security capabilities selection.............................................................................. 2149
14.5.2.1 Instance Pairwise Cipher Suite selection .......................................... 2149
14.5.2.2 Group cipher suite selection.............................................................. 2150
14.5.3 Construction and processing AES-SIV-protected mesh peering Management
frames................................................................................................................... 2150
14.5.4 Distribution of group transient keys in an MBSS................................................ 2151
14.5.5 Mesh peering Management frames for AMPE .................................................... 2151
14.5.5.1 General .............................................................................................. 2151
14.5.5.2 Mesh peering open for AMPE .......................................................... 2151
14.5.5.3 Mesh peering confirm for AMPE ..................................................... 2152
14.5.5.4 Mesh peering close for AMPE.......................................................... 2153
14.5.6 AMPE finite state machine .................................................................................. 2153
14.5.6.1 Overview........................................................................................... 2153
14.5.6.2 Additional events and actions to MPM FSM.................................... 2154
14.5.6.3 State transitions ................................................................................. 2154
14.5.7 Keys and key derivation algorithm for the authenticated mesh peering
exchange (AMPE)................................................................................................ 2156
14.6 Mesh group key handshake.................................................................................................. 2157
14.6.1 General................................................................................................................. 2157
14.6.2 Protection on mesh group key handshake frames................................................ 2158
14.6.3 Mesh Group Key Inform frame construction and processing.............................. 2158
14.6.4 Mesh Group Key Acknowledge frame construction and processing .................. 2159
14.6.5 Mesh group key implementation considerations ................................................. 2160
14.7 Mesh security ....................................................................................................................... 2160
14.8 Mesh path selection and metric framework ......................................................................... 2161
14.8.1 General................................................................................................................. 2161
14.8.2 Extensible path selection framework ................................................................... 2161
14.8.3 Link metric reporting ........................................................................................... 2161
14.9 Airtime link metric............................................................................................................... 2162
14.10 Hybrid wireless mesh protocol (HWMP) ............................................................................ 2163
14.10.1 General................................................................................................................. 2163
14.10.2 Terminology......................................................................................................... 2164
14.10.3 On-demand path selection mode.......................................................................... 2166
14.10.4 Proactive tree building mode ............................................................................... 2166
14.10.4.1 General .............................................................................................. 2166
60
Copyright © 2016 IEEE. All rights reserved.
14.10.4.2 Proactive PREQ mechanism ............................................................. 2167
14.10.4.3 Proactive RANN mechanism ............................................................ 2167
14.10.5 Collocated STAs .................................................................................................. 2168
14.10.6 Parameters for extensible path selection framework ........................................... 2168
14.10.7 Addressing of HWMP Mesh Path Selection frame ............................................. 2168
14.10.8 General rules for processing HWMP elements.................................................... 2170
14.10.8.1 General .............................................................................................. 2170
14.10.8.2 HWMP propagation .......................................................................... 2170
14.10.8.3 HWMP sequence numbering ............................................................ 2170
14.10.8.4 Forwarding information .................................................................... 2171
14.10.8.5 Repeated attempts at path discovery................................................. 2172
14.10.8.6 Limiting the rate of HWMP SN increments ..................................... 2173
14.10.9 Path request (PREQ) mechanism......................................................................... 2173
14.10.9.1 General .............................................................................................. 2173
14.10.9.2 Function ............................................................................................ 2173
14.10.9.3 Conditions for generating and sending a PREQ element.................. 2173
14.10.9.4 PREQ element processing................................................................. 2182
14.10.10 Path reply (PREP) mechanism............................................................................. 2183
14.10.10.1 General .............................................................................................. 2183
14.10.10.2 Function ............................................................................................ 2183
14.10.10.3 Conditions for generating and sending a PREP element .................. 2183
14.10.10.4 PREP element processing ................................................................. 2186
14.10.11 Path error (PERR) mechanism............................................................................. 2187
14.10.11.1 General .............................................................................................. 2187
14.10.11.2 Function ............................................................................................ 2187
14.10.11.3 Conditions for generating and sending a PERR element.................. 2188
14.10.11.4 PERR element processing................................................................. 2192
14.10.12 Root announcement (RANN) mechanism ........................................................... 2192
14.10.12.1 General .............................................................................................. 2192
14.10.12.2 Function ............................................................................................ 2193
14.10.12.3 Conditions for generating and sending a RANN element................. 2193
14.10.12.4 RANN element reception.................................................................. 2194
14.10.13 Considerations for support of STAs without mesh functionality ........................ 2195
14.11 Interworking with the DS .................................................................................................... 2195
14.11.1 Overview of interworking between a mesh BSS and a DS ................................. 2195
14.11.2 Gate announcement (GANN) .............................................................................. 2196
14.11.2.1 General .............................................................................................. 2196
14.11.2.2 Function ............................................................................................ 2196
14.11.2.3 Conditions for generating and sending a GANN element ................ 2196
14.11.2.4 GANN element processing ............................................................... 2198
14.11.3 Data forwarding at proxy mesh gates .................................................................. 2198
14.11.3.1 General .............................................................................................. 2198
14.11.3.2 Forwarding of MSDUs from the MBSS to the DS ........................... 2198
14.11.3.3 Forwarding of MSDUs from the DS to the MBSS ........................... 2199
14.11.4 Proxy information and proxy update ................................................................... 2200
14.11.4.1 General .............................................................................................. 2200
14.11.4.2 Proxy information ............................................................................. 2200
14.11.4.3 Proxy update (PXU).......................................................................... 2201
14.11.4.4 Proxy update confirmation (PXUC) ................................................. 2203
14.11.5 Mesh STA collocation ......................................................................................... 2204
14.12 Intra-mesh congestion control ............................................................................................. 2204
14.12.1 General................................................................................................................. 2204
14.12.2 Congestion control signaling protocol ................................................................. 2204
14.13 Synchronization and beaconing in MBSSs.......................................................................... 2205
61
Copyright © 2016 IEEE. All rights reserved.
14.13.1 TSF for MBSSs.................................................................................................... 2205
14.13.2 Extensible synchronization framework ............................................................... 2205
14.13.2.1 General .............................................................................................. 2205
14.13.2.2 Neighbor offset synchronization method.......................................... 2205
14.13.3 Beaconing ............................................................................................................ 2208
14.13.3.1 Beacon generation in MBSSs ........................................................... 2208
14.13.3.2 Beacon reception for mesh STA ....................................................... 2208
14.13.4 Mesh beacon collision avoidance (MBCA)......................................................... 2208
14.13.4.1 Overview........................................................................................... 2208
14.13.4.2 Beacon timing advertisement............................................................ 2209
14.13.4.3 TBTT selection ................................................................................. 2212
14.13.4.4 TBTT adjustment .............................................................................. 2212
14.13.4.5 Frame transmission across reported TBTT ....................................... 2214
14.13.4.6 Delayed beacon transmissions .......................................................... 2214
14.14 Power save in a mesh BSS................................................................................................... 2214
14.14.1 General................................................................................................................. 2214
14.14.2 Mesh power management modes......................................................................... 2215
14.14.2.1 General .............................................................................................. 2215
14.14.2.2 Peer-specific mesh power management modes ................................ 2215
14.14.2.3 Nonpeer mesh power management modes........................................ 2216
14.14.3 Mesh power management mode indications and transitions ............................... 2216
14.14.3.1 General .............................................................................................. 2216
14.14.3.2 Transition to a higher activity level .................................................. 2217
14.14.3.3 Transition to a lower activity level ................................................... 2217
14.14.4 TIM transmissions in an MBSS........................................................................... 2217
14.14.5 TIM types............................................................................................................. 2218
14.14.6 Mesh awake window ........................................................................................... 2218
14.14.7 Power save support .............................................................................................. 2218
14.14.8 Operation in peer-specific and nonpeer mesh power management modes.......... 2219
14.14.8.1 General .............................................................................................. 2219
14.14.8.2 Operation in active mode .................................................................. 2219
14.14.8.3 Operation in deep sleep mode for nonpeer mesh STAs.................... 2219
14.14.8.4 Operation in light sleep mode for a mesh peering ............................ 2220
14.14.8.5 Operation in deep sleep mode for a mesh peering ............................ 2220
14.14.8.6 Conditions for doze state................................................................... 2220
14.14.9 Mesh peer service periods.................................................................................... 2221
14.14.9.1 General .............................................................................................. 2221
14.14.9.2 Initiation of a mesh peer service period ............................................ 2221
14.14.9.3 Operation during a mesh peer service period.................................... 2222
14.14.9.4 Termination of a mesh peer service period ....................................... 2222
14.14.10 MCCA use by power saving mesh STA .............................................................. 2223
15. DSSS PHY specification for the 2.4 GHz band designated for ISM applications .......................... 2224
15.1 Overview.............................................................................................................................. 2224
15.1.1 General................................................................................................................. 2224
15.1.2 Scope.................................................................................................................... 2224
15.1.3 DSSS PHY functions ........................................................................................... 2224
15.1.3.1 General .............................................................................................. 2224
15.1.3.2 PLME ................................................................................................ 2224
15.1.4 Service specification method and notation .......................................................... 2224
15.2 DSSS PHY specific service parameter list ......................................................................... 2225
15.2.1 Introduction.......................................................................................................... 2225
15.2.2 TXVECTOR parameters...................................................................................... 2225
62
Copyright © 2016 IEEE. All rights reserved.
15.2.2.1 General .............................................................................................. 2225
15.2.2.2 TXVECTOR LENGTH .................................................................... 2225
15.2.2.3 TXVECTOR DATARATE............................................................... 2225
15.2.2.4 TXVECTOR SERVICE.................................................................... 2225
15.2.2.5 TXVECTOR TXPWR_LEVEL_INDEX ......................................... 2226
15.2.2.6 TXVECTOR TIME_OF_DEPARTURE_REQUESTED................. 2226
15.2.2.7 TXVECTOR TX_ANTENNA.......................................................... 2226
15.2.3 RXVECTOR parameters ..................................................................................... 2226
15.2.3.1 General .............................................................................................. 2226
15.2.3.2 RXVECTOR LENGTH .................................................................... 2226
15.2.3.3 RXVECTOR RSSI............................................................................ 2227
15.2.3.4 RXVECTOR SIGNAL ..................................................................... 2227
15.2.3.5 RXVECTOR SERVICE ................................................................... 2227
15.2.3.6 RXVECTOR RCPI ........................................................................... 2227
15.2.3.7 RXVECTOR SQ ............................................................................... 2227
15.2.3.8 RXVECTOR RX_ANTENNA ......................................................... 2227
15.2.4 TXSTATUS parameters ...................................................................................... 2227
15.2.4.1 General .............................................................................................. 2227
15.2.4.2 TXSTATUS TIME_OF_DEPARTURE........................................... 2227
15.2.4.3 TXSTATUS TIME_OF_DEPARTURE_ClockRate........................ 2227
15.3 DSSS PHY ........................................................................................................................... 2228
15.3.1 Overview.............................................................................................................. 2228
15.3.2 PPDU format........................................................................................................ 2228
15.3.3 PHY field definitions ........................................................................................... 2229
15.3.3.1 General .............................................................................................. 2229
15.3.3.2 PHY SYNC field............................................................................... 2229
15.3.3.3 PHY SFD .......................................................................................... 2229
15.3.3.4 PHY SIGNAL field........................................................................... 2229
15.3.3.5 PHY SERVICE field......................................................................... 2229
15.3.3.6 PHY LENGTH field ......................................................................... 2229
15.3.3.7 PHY CRC field ................................................................................. 2230
15.3.4 PHY/DSSS PHY data scrambler and descrambler .............................................. 2231
15.3.5 PHY data modulation and modulation rate change ............................................. 2232
15.3.6 Transmit PHY ...................................................................................................... 2232
15.3.7 Receive PHY ....................................................................................................... 2234
15.4 DSSS PLME ........................................................................................................................ 2235
15.4.1 PLME SAP sublayer management primitives ..................................................... 2235
15.4.2 DSSS PHY MIB .................................................................................................. 2235
15.4.3 DSSS PHY ........................................................................................................... 2235
15.4.4 PHY operating specifications, general................................................................. 2235
15.4.4.1 General .............................................................................................. 2235
15.4.4.2 Operating frequency range................................................................ 2235
15.4.4.3 Channel Numbering of operating channels....................................... 2236
15.4.4.4 Spreading sequence........................................................................... 2239
15.4.4.5 Modulation and channel data rates.................................................... 2239
15.4.4.6 Transmit and receive in-band and out-of-band spurious emissions.. 2240
15.4.4.7 TX-to-RX turnaround time ............................................................... 2240
15.4.4.8 RX-to-TX turnaround time ............................................................... 2240
15.4.4.9 Slot time ............................................................................................ 2240
15.4.4.10 Transmit and receive antenna connector impedance ........................ 2240
15.4.5 PHY transmit specifications ................................................................................ 2240
15.4.5.1 Introduction....................................................................................... 2240
15.4.5.2 Transmit power levels....................................................................... 2240
15.4.5.3 Minimum transmitted power level.................................................... 2241
63
Copyright © 2016 IEEE. All rights reserved.
15.4.5.4 Transmit power level control ............................................................ 2241
15.4.5.5 Transmit spectrum mask ................................................................... 2241
15.4.5.6 Transmit center frequency tolerance................................................. 2241
15.4.5.7 Chip clock frequency tolerance......................................................... 2241
15.4.5.8 Transmit power-on and power-down ramp....................................... 2241
15.4.5.9 RF carrier suppression ...................................................................... 2242
15.4.5.10 Transmit modulation accuracy.......................................................... 2243
15.4.5.11 Time of Departure accuracy.............................................................. 2245
15.4.6 PHY receiver specifications................................................................................. 2245
15.4.6.1 Introduction....................................................................................... 2245
15.4.6.2 Receiver minimum input level sensitivity ........................................ 2245
15.4.6.3 Receiver maximum input level ......................................................... 2245
15.4.6.4 Receiver adjacent channel rejection.................................................. 2246
15.4.6.5 CCA .................................................................................................. 2246
15.4.6.6 Received Channel Power Indicator Measurement ............................ 2247
15.4.6.7 DSSS PHY TXTIME calculation ..................................................... 2247
16. High rate direct sequence spread spectrum (HR/DSSS) PHY specification ................................... 2248
16.1 Overview.............................................................................................................................. 2248
16.1.1 General................................................................................................................. 2248
16.1.2 Scope.................................................................................................................... 2248
16.1.3 HR/DSSS PHY functions .................................................................................... 2248
16.1.3.1 General .............................................................................................. 2248
16.1.3.2 PLME ................................................................................................ 2249
16.1.4 Service specification method and notation .......................................................... 2249
16.2 HR/DSSS PHY .................................................................................................................... 2249
16.2.1 Overview.............................................................................................................. 2249
16.2.2 PPDU format........................................................................................................ 2249
16.2.2.1 General .............................................................................................. 2249
16.2.2.2 Long PPDU format ........................................................................... 2249
16.2.2.3 Short PPDU format ........................................................................... 2250
16.2.3 PPDU field definitions......................................................................................... 2251
16.2.3.1 General .............................................................................................. 2251
16.2.3.2 Long PHY SYNC field ..................................................................... 2251
16.2.3.3 Long PHY SFD................................................................................. 2251
16.2.3.4 Long PHY SIGNAL field ................................................................. 2251
16.2.3.5 Long PHY SERVICE field ............................................................... 2251
16.2.3.6 Long PHY LENGTH field................................................................ 2252
16.2.3.7 PHY CRC (CRC-16) field ................................................................ 2253
16.2.3.8 Long PHY data modulation and modulation rate change ................. 2255
16.2.3.9 Short PHY synchronization (shortSYNC) ........................................ 2255
16.2.3.10 Short PHY SFD field (shortSFD) ..................................................... 2255
16.2.3.11 Short PHY SIGNAL field (shortSIGNAL)....................................... 2256
16.2.3.12 Short PHY SERVICE field (shortSERVICE)................................... 2256
16.2.3.13 Short PHY LENGTH field (shortLENGTH) .................................... 2256
16.2.3.14 Short CRC-16 field (shortCRC)........................................................ 2256
16.2.3.15 Short PHY data modulation and modulation rate change................. 2256
16.2.4 PHY/HR/DSSS PHY data scrambler and descrambler ....................................... 2256
16.2.5 Transmit PHY ...................................................................................................... 2257
16.2.6 Receive PHY........................................................................................................ 2258
16.3 HR/DSSS PLME.................................................................................................................. 2261
16.3.1 PLME SAP sublayer management primitives ..................................................... 2261
16.3.2 HR/DSSS PHY MIB............................................................................................ 2261
64
Copyright © 2016 IEEE. All rights reserved.
16.3.3 HR/DSSS PHY .................................................................................................... 2263
16.3.4 HR/DSSS TXTIME calculation........................................................................... 2263
16.3.5 Vector descriptions .............................................................................................. 2264
16.3.6 PHY operating specifications, general................................................................. 2265
16.3.6.1 General .............................................................................................. 2265
16.3.6.2 Operating frequency range................................................................ 2265
16.3.6.3 Channel Numbering of operating channels....................................... 2265
16.3.6.4 Modulation and channel data rates.................................................... 2266
16.3.6.5 Spreading sequence and modulation for 1 Mb/s and 2 Mb/s ............ 2266
16.3.6.6 Spreading sequences and modulation for CCK modulation
at 5.5 Mb/s and 11 Mb/s.................................................................... 2267
16.3.6.7 Transmit and receive in-band and out-of-band spurious emissions.. 2269
16.3.6.8 TX-to-RX turnaround time ............................................................... 2269
16.3.6.9 RX-to-TX turnaround time ............................................................... 2269
16.3.6.10 Slot time ............................................................................................ 2269
16.3.6.11 Transmit and receive impedance at the antenna connector............... 2269
16.3.7 PHY transmit specifications ................................................................................ 2269
16.3.7.1 Introduction....................................................................................... 2269
16.3.7.2 Transmit power levels....................................................................... 2269
16.3.7.3 Transmit power level control ............................................................ 2270
16.3.7.4 Transmit spectrum mask ................................................................... 2270
16.3.7.5 Transmit center frequency tolerance................................................. 2270
16.3.7.6 Chip clock frequency tolerance......................................................... 2270
16.3.7.7 Transmit power-on and power-down ramp....................................... 2271
16.3.7.8 RF carrier suppression ...................................................................... 2271
16.3.7.9 Transmit modulation accuracy.......................................................... 2272
16.3.7.10 Time of Departure accuracy.............................................................. 2274
16.3.8 PHY receiver specifications................................................................................. 2274
16.3.8.1 Introduction....................................................................................... 2274
16.3.8.2 Receiver minimum input level sensitivity ........................................ 2274
16.3.8.3 Receiver maximum input level ......................................................... 2275
16.3.8.4 Receiver adjacent channel rejection.................................................. 2275
16.3.8.5 CCA .................................................................................................. 2275
16.3.8.6 Received Channel Power Indicator Measurement ............................ 2276
17. Orthogonal frequency division multiplexing (OFDM) PHY specification ..................................... 2277
17.1 Introduction.......................................................................................................................... 2277
17.1.1 General................................................................................................................. 2277
17.1.2 Scope.................................................................................................................... 2277
17.1.3 OFDM PHY functions ......................................................................................... 2277
17.1.3.1 General .............................................................................................. 2277
17.1.3.2 PLME ................................................................................................ 2277
17.1.3.3 Service specification method ............................................................ 2278
17.2 OFDM PHY specific service parameter list ........................................................................ 2278
17.2.1 Introduction.......................................................................................................... 2278
17.2.2 TXVECTOR parameters...................................................................................... 2278
17.2.2.1 General .............................................................................................. 2278
17.2.2.2 TXVECTOR LENGTH .................................................................... 2279
17.2.2.3 TXVECTOR DATARATE............................................................... 2279
17.2.2.4 TXVECTOR SERVICE.................................................................... 2279
17.2.2.5 TXVECTOR TXPWR_LEVEL_INDEX ......................................... 2279
17.2.2.6 TXVECTOR TIME_OF_DEPARTURE_REQUESTED................. 2279
17.2.2.7 TXVECTOR CH_BANDWIDTH_IN_NON_HT ............................ 2279
65
Copyright © 2016 IEEE. All rights reserved.
17.2.2.8 TXVECTOR DYN_BANDWIDTH_IN_NON_HT......................... 2280
17.2.3 RXVECTOR parameters ..................................................................................... 2280
17.2.3.1 General .............................................................................................. 2280
17.2.3.2 RXVECTOR LENGTH .................................................................... 2281
17.2.3.3 RXVECTOR RSSI............................................................................ 2281
17.2.3.4 RXVECTOR DATARATE............................................................... 2281
17.2.3.5 RXVECTOR SERVICE ................................................................... 2281
17.2.3.6 RXVECTOR RCPI ........................................................................... 2281
17.2.3.7 RXVECTOR CH_BANDWIDTH_IN_NON_HT............................ 2281
17.2.3.8 RXVECTOR DYN_BANDWIDTH_IN_NON_HT......................... 2282
17.2.4 TXSTATUS parameters ...................................................................................... 2282
17.2.4.1 General .............................................................................................. 2282
17.2.4.2 TXSTATUS TIME_OF_DEPARTURE........................................... 2282
17.2.4.3 TXSTATUS TIME_OF_DEPARTURE_ClockRate........................ 2282
17.3 OFDM PHY ......................................................................................................................... 2283
17.3.1 Introduction.......................................................................................................... 2283
17.3.2 PPDU format........................................................................................................ 2283
17.3.2.1 General .............................................................................................. 2283
17.3.2.2 Overview of the PPDU encoding process......................................... 2283
17.3.2.3 Modulation-dependent parameters.................................................... 2285
17.3.2.4 Timing-related parameters ................................................................ 2285
17.3.2.5 Mathematical conventions in the signal descriptions ....................... 2286
17.3.2.6 Discrete time implementation considerations ................................... 2288
17.3.3 PHY preamble (SYNC) ....................................................................................... 2288
17.3.4 SIGNAL field ...................................................................................................... 2290
17.3.4.1 General .............................................................................................. 2290
17.3.4.2 RATE field........................................................................................ 2290
17.3.4.3 PHY LENGTH field ......................................................................... 2291
17.3.4.4 Parity (P), Reserved (R), and SIGNAL TAIL fields......................... 2291
17.3.5 DATA field .......................................................................................................... 2291
17.3.5.1 General .............................................................................................. 2291
17.3.5.2 SERVICE field.................................................................................. 2291
17.3.5.3 PPDU TAIL field .............................................................................. 2292
17.3.5.4 Pad bits (PAD) .................................................................................. 2292
17.3.5.5 PHY DATA scrambler and descrambler .......................................... 2292
17.3.5.6 Convolutional encoder ...................................................................... 2295
17.3.5.7 Data interleaving ............................................................................... 2297
17.3.5.8 Subcarrier modulation mapping........................................................ 2298
17.3.5.9 Pilot subcarriers................................................................................. 2301
17.3.5.10 OFDM modulation............................................................................ 2301
17.3.6 CCA ..................................................................................................................... 2302
17.3.7 PHY data modulation and modulation rate change ............................................. 2302
17.3.8 PHY operating specifications (general) ............................................................... 2303
17.3.8.1 General .............................................................................................. 2303
17.3.8.2 Outline description............................................................................ 2303
17.3.8.3 Regulatory requirements ................................................................... 2304
17.3.8.4 Operating channel frequencies.......................................................... 2304
17.3.8.5 Transmit and receive in-band and out-of-band spurious emissions.. 2305
17.3.8.6 Slot time ............................................................................................ 2305
17.3.8.7 Transmit and receive impedance at the antenna connector............... 2305
17.3.9 PHY transmit specifications ................................................................................ 2305
17.3.9.1 General .............................................................................................. 2305
17.3.9.2 Transmit power levels....................................................................... 2305
17.3.9.3 Transmit spectrum mask ................................................................... 2305
66
Copyright © 2016 IEEE. All rights reserved.
17.3.9.4 Transmission spurious....................................................................... 2307
17.3.9.5 Transmit center frequency tolerance................................................. 2307
17.3.9.6 Symbol clock frequency tolerance.................................................... 2307
17.3.9.7 Modulation accuracy......................................................................... 2307
17.3.9.8 Transmit modulation accuracy test ................................................... 2308
17.3.9.9 Time of Departure accuracy.............................................................. 2309
17.3.10 PHY receiver specifications................................................................................. 2310
17.3.10.1 Introduction....................................................................................... 2310
17.3.10.2 Receiver minimum input sensitivity ................................................. 2310
17.3.10.3 Adjacent channel rejection................................................................ 2311
17.3.10.4 Nonadjacent channel rejection .......................................................... 2311
17.3.10.5 Receiver maximum input level ......................................................... 2312
17.3.10.6 CCA requirements............................................................................. 2312
17.3.10.7 Received Channel Power Indicator Measurement ............................ 2312
17.3.11 Transmit PHY ...................................................................................................... 2313
17.3.12 Receive PHY........................................................................................................ 2315
17.4 OFDM PLME ...................................................................................................................... 2317
17.4.1 PLME SAP sublayer management primitives ..................................................... 2317
17.4.2 OFDM PHY MIB ................................................................................................ 2317
17.4.3 OFDM TXTIME calculation ............................................................................... 2320
17.4.4 OFDM PHY characteristics ................................................................................. 2320
18. Extended Rate PHY (ERP) specification......................................................................................... 2322
18.1 Overview.............................................................................................................................. 2322
18.1.1 General................................................................................................................. 2322
18.1.2 Introduction.......................................................................................................... 2322
18.1.3 Operational modes ............................................................................................... 2322
18.1.4 Scope.................................................................................................................... 2323
18.1.5 ERP functions ...................................................................................................... 2323
18.2 PHY-specific service parameter list .................................................................................... 2323
18.3 Extended Rate PHY sublayer .............................................................................................. 2325
18.3.1 Introduction.......................................................................................................... 2325
18.3.2 PPDU format........................................................................................................ 2325
18.3.2.1 General .............................................................................................. 2325
18.3.2.2 Long preamble PPDU format ........................................................... 2326
18.3.2.3 Short preamble PPDU format ........................................................... 2326
18.3.2.4 ERP-OFDM PPDU format................................................................ 2326
18.3.3 PHY data modulation and rate change ................................................................ 2326
18.3.3.1 Long and short preamble formats ..................................................... 2326
18.3.3.2 ERP-OFDM format........................................................................... 2327
18.3.4 CCA ..................................................................................................................... 2327
18.3.5 PHY receive procedure ........................................................................................ 2327
18.4 ERP operating specifications (general)................................................................................ 2327
18.4.1 Introduction.......................................................................................................... 2327
18.4.2 Regulatory requirements...................................................................................... 2327
18.4.3 Operating channel frequencies............................................................................. 2328
18.4.4 Transmit and receive in-band and out-of-band spurious emissions .................... 2328
18.4.5 SIFS ..................................................................................................................... 2328
18.4.6 CCA performance ................................................................................................ 2328
18.4.7 PHY transmit specifications ................................................................................ 2328
18.4.7.1 General .............................................................................................. 2328
18.4.7.2 Transmit power levels....................................................................... 2328
18.4.7.3 Transmit spectral mask ..................................................................... 2328
67
Copyright © 2016 IEEE. All rights reserved.
18.4.7.4 Transmit center frequency tolerance................................................. 2329
18.4.7.5 Symbol clock frequency tolerance.................................................... 2329
18.4.7.6 Time of Departure accuracy.............................................................. 2329
18.4.8 PHY receive specifications .................................................................................. 2329
18.4.8.1 General .............................................................................................. 2329
18.4.8.2 Receiver minimum input level sensitivity ........................................ 2329
18.4.8.3 Adjacent channel rejection................................................................ 2329
18.4.8.4 Receive maximum input level capability.......................................... 2329
18.5 ERP PLME .......................................................................................................................... 2330
18.5.1 PLME SAP .......................................................................................................... 2330
18.5.2 MIB ...................................................................................................................... 2330
18.5.3 TXTIME .............................................................................................................. 2331
18.5.3.1 General .............................................................................................. 2331
18.5.3.2 ERP-OFDM TXTIME calculations .................................................. 2331
18.5.4 ERP characteristics .............................................................................................. 2332
19. High-throughput (HT) PHY specification ....................................................................................... 2334
19.1 Introduction.......................................................................................................................... 2334
19.1.1 Introduction to the HT PHY ................................................................................ 2334
19.1.2 Scope.................................................................................................................... 2334
19.1.3 HT PHY functions ............................................................................................... 2334
19.1.3.1 General .............................................................................................. 2334
19.1.3.2 PHY management entity (PLME)..................................................... 2334
19.1.3.3 Service specification method ............................................................ 2335
19.1.4 PPDU formats ...................................................................................................... 2335
19.2 HT PHY service interface.................................................................................................... 2335
19.2.1 Introduction.......................................................................................................... 2335
19.2.2 TXVECTOR and RXVECTOR parameters ........................................................ 2335
19.2.3 PHYCONFIG_VECTOR parameters .................................................................. 2342
19.2.4 Effect of CH_BANDWIDTH, CH_OFFSET, and MCS parameters on
PPDU format........................................................................................................ 2343
19.2.5 Support for NON_HT formats ............................................................................. 2344
19.2.6 TXSTATUS parameters ...................................................................................... 2346
19.3 HT PHY ............................................................................................................................... 2346
19.3.1 Introduction.......................................................................................................... 2346
19.3.2 PPDU format........................................................................................................ 2346
19.3.3 Transmitter block diagram................................................................................... 2348
19.3.4 Overview of the PPDU encoding process............................................................ 2349
19.3.5 Modulation and coding scheme (MCS) ............................................................... 2353
19.3.6 Timing-related parameters ................................................................................... 2354
19.3.7 Mathematical description of signals .................................................................... 2356
19.3.8 Transmission in the upper/lower 20 MHz of a 40 MHz channel......................... 2358
19.3.9 HT preamble ........................................................................................................ 2359
19.3.9.1 Introduction....................................................................................... 2359
19.3.9.2 HT-mixed format preamble .............................................................. 2359
19.3.9.3 Non-HT portion of the HT-mixed format preamble ......................... 2359
19.3.9.4 HT portion of HT-mixed format preamble ....................................... 2363
19.3.9.5 HT-greenfield format preamble ........................................................ 2373
19.3.10 Transmission of NON_HT format PPDUs with more than one transmit chain .. 2375
19.3.11 Data field.............................................................................................................. 2375
19.3.11.1 General .............................................................................................. 2375
19.3.11.2 SERVICE field.................................................................................. 2376
19.3.11.3 Scrambler .......................................................................................... 2376
68
Copyright © 2016 IEEE. All rights reserved.
19.3.11.4 Coding............................................................................................... 2376
19.3.11.5 Encoder parsing operation for two BCC FEC encoders ................... 2376
19.3.11.6 Binary convolutional coding and puncturing.................................... 2377
19.3.11.7 LDPC codes ...................................................................................... 2377
19.3.11.8 Data interleaver ................................................................................. 2382
19.3.11.9 Constellation mapping ...................................................................... 2384
19.3.11.10 Pilot subcarriers................................................................................. 2385
19.3.11.11 OFDM modulation............................................................................ 2387
19.3.11.12 Non-HT duplicate transmission ........................................................ 2392
19.3.12 Beamforming ....................................................................................................... 2392
19.3.12.1 General .............................................................................................. 2392
19.3.12.2 Implicit feedback beamforming ........................................................ 2393
19.3.12.3 Explicit feedback beamforming ........................................................ 2396
19.3.13 HT Preamble format for sounding PPDUs .......................................................... 2400
19.3.13.1 General .............................................................................................. 2400
19.3.13.2 Sounding with a NDP ....................................................................... 2401
19.3.13.3 Sounding PPDU for calibration ........................................................ 2401
19.3.13.4 Sounding PPDU for channel quality assessment .............................. 2402
19.3.14 Regulatory requirements...................................................................................... 2403
19.3.15 Channel numbering and channelization............................................................... 2403
19.3.15.1 General .............................................................................................. 2403
19.3.15.2 Channel allocation in the 2.4 GHz Band........................................... 2403
19.3.15.3 Channel allocation in the 5 GHz band .............................................. 2403
19.3.15.4 40 MHz channelization ..................................................................... 2403
19.3.16 Slot time............................................................................................................... 2404
19.3.17 Transmit and receive impedance at the antenna connector ................................. 2404
19.3.18 PHY transmit specification .................................................................................. 2404
19.3.18.1 Transmit spectrum mask ................................................................... 2404
19.3.18.2 Spectral flatness ................................................................................ 2406
19.3.18.3 Transmit power ................................................................................. 2406
19.3.18.4 Transmit center frequency tolerance................................................. 2407
19.3.18.5 Packet alignment ............................................................................... 2407
19.3.18.6 Symbol clock frequency tolerance.................................................... 2407
19.3.18.7 Modulation accuracy......................................................................... 2407
19.3.18.8 Time of Departure accuracy.............................................................. 2409
19.3.19 HT PHY receiver specification............................................................................ 2410
19.3.19.1 Receiver minimum input sensitivity ................................................. 2410
19.3.19.2 Adjacent channel rejection................................................................ 2410
19.3.19.3 Nonadjacent channel rejection .......................................................... 2411
19.3.19.4 Receiver maximum input level ......................................................... 2411
19.3.19.5 CCA sensitivity ................................................................................. 2411
19.3.19.6 Received channel power indicator (RCPI) measurement ................. 2413
19.3.19.7 Reduced interframe space (RIFS) ..................................................... 2413
19.3.20 PHY transmit procedure ...................................................................................... 2413
19.3.21 PHY receive procedure ........................................................................................ 2415
19.4 HT PLME ............................................................................................................................ 2420
19.4.1 PLME SAP sublayer management primitives ..................................................... 2420
19.4.2 PHY MIB ............................................................................................................. 2420
19.4.3 TXTIME calculation............................................................................................ 2424
19.4.4 HT PHY ............................................................................................................... 2425
19.5 Parameters for HT MCSs..................................................................................................... 2427
20. Directional multi-gigabit (DMG) PHY specification ...................................................................... 2436
69
Copyright © 2016 IEEE. All rights reserved.
20.1 DMG PHY introduction....................................................................................................... 2436
20.1.1 Scope.................................................................................................................... 2436
20.1.2 DMG PHY functions ........................................................................................... 2436
20.1.2.1 PHY management entity (PLME)..................................................... 2436
20.1.2.2 Service specification method ............................................................ 2436
20.2 DMG PHY service interface................................................................................................ 2436
20.2.1 Introduction.......................................................................................................... 2436
20.2.2 TXVECTOR and RXVECTOR parameters ........................................................ 2437
20.2.3 TXSTATUS parameters ...................................................................................... 2439
20.3 Common parameters ............................................................................................................ 2439
20.3.1 Channelization ..................................................................................................... 2439
20.3.2 Transmit mask...................................................................................................... 2440
20.3.3 Common requirements......................................................................................... 2440
20.3.3.1 Introduction....................................................................................... 2440
20.3.3.2 Center frequency tolerance ............................................................... 2440
20.3.3.3 Symbol clock tolerance..................................................................... 2440
20.3.3.4 Transmit center frequency leakage ................................................... 2441
20.3.3.5 Transmit rampup and rampdown ...................................................... 2441
20.3.3.6 Antenna setting ................................................................................. 2441
20.3.3.7 Maximum input requirement ............................................................ 2441
20.3.3.8 Receive sensitivity ............................................................................ 2441
20.3.4 Timing-related parameters ................................................................................... 2443
20.3.5 Mathematical conventions in the signal description............................................ 2444
20.3.5.1 General .............................................................................................. 2444
20.3.5.2 Windowing function ......................................................................... 2445
20.3.6 Common preamble............................................................................................... 2446
20.3.6.1 General .............................................................................................. 2446
20.3.6.2 Short Training field........................................................................... 2446
20.3.6.3 Channel Estimation field................................................................... 2447
20.3.6.4 Transmission of the preamble and BRP fields in an OFDM packet. 2448
20.3.7 HCS calculation for headers of DMG control mode, DMG OFDM mode,
and DMG SC mode.............................................................................................. 2449
20.3.8 Common LDPC parity matrices .......................................................................... 2449
20.3.8.1 General .............................................................................................. 2449
20.3.8.2 Rate 1/2 LDPC code matrix H = 336 rows x 672 columns, Z = 42.. 2450
20.3.8.3 Rate 5/8 LDPC code matrix H = 252 rows x 672 columns, Z = 42.. 2450
20.3.8.4 Rate 3/4 LDPC code matrix H = 168 rows x 672 columns, Z = 42.. 2450
20.3.8.5 Rate 13/16 LDPC code matrix H = 126 rows x 672 columns,
Z = 42 ................................................................................................ 2451
20.3.9 Scrambler ............................................................................................................. 2451
20.3.10 Received channel power indicator (RCPI) measurement .................................... 2451
20.4 DMG control mode .............................................................................................................. 2452
20.4.1 Introduction.......................................................................................................... 2452
20.4.2 PPDU format........................................................................................................ 2452
20.4.3 Transmission ........................................................................................................ 2452
20.4.3.1 Preamble............................................................................................ 2452
20.4.3.2 Header ............................................................................................... 2453
20.4.3.3 Data field........................................................................................... 2454
20.4.4 Performance requirements ................................................................................... 2455
20.4.4.1 Transmit requirements ...................................................................... 2455
20.4.4.2 Receive requirements........................................................................ 2456
20.5 DMG OFDM mode.............................................................................................................. 2456
20.5.1 Introduction.......................................................................................................... 2456
20.5.2 PPDU format........................................................................................................ 2457
70
Copyright © 2016 IEEE. All rights reserved.
20.5.3
Transmission ........................................................................................................ 2457
20.5.3.1 Header ............................................................................................... 2457
20.5.3.2 Data field........................................................................................... 2460
20.5.4 Performance requirements ................................................................................... 2466
20.5.4.1 Transmit requirements ...................................................................... 2466
20.5.4.2 Receive requirements........................................................................ 2468
20.6 DMG SC mode .................................................................................................................... 2468
20.6.1 Introduction.......................................................................................................... 2468
20.6.2 PPDU format........................................................................................................ 2469
20.6.3 Transmission ........................................................................................................ 2469
20.6.3.1 Header ............................................................................................... 2469
20.6.3.2 Data field........................................................................................... 2473
20.6.4 Performance requirements ................................................................................... 2479
20.6.4.1 Transmit requirements ...................................................................... 2479
20.6.4.2 Receive requirements........................................................................ 2480
20.7 DMG low-power SC mode .................................................................................................. 2481
20.7.1 Introduction.......................................................................................................... 2481
20.7.2 Transmission ........................................................................................................ 2481
20.7.2.1 Preamble............................................................................................ 2481
20.7.2.2 Header ............................................................................................... 2481
20.7.2.3 Data field........................................................................................... 2481
20.8 PHY transmit procedure ...................................................................................................... 2484
20.9 PHY receive procedure ........................................................................................................ 2487
20.10 Beamforming ....................................................................................................................... 2488
20.10.1 Beamforming concept.......................................................................................... 2488
20.10.2 Beamforming frame format ................................................................................. 2488
20.10.2.1 Sector-level sweep ............................................................................ 2488
20.10.2.2 Beam refinement ............................................................................... 2488
20.11 Golay sequences .................................................................................................................. 2492
20.12 DMG PLME ........................................................................................................................ 2494
20.12.1 PLME SAP sublayer management primitives ..................................................... 2494
20.12.2 DMG PHY MIB................................................................................................... 2494
20.12.3 TXTIME calculation............................................................................................ 2494
20.12.4 DMG PHY ........................................................................................................... 2495
21. Very high throughput (VHT) PHY specification ............................................................................ 2497
21.1 Introduction.......................................................................................................................... 2497
21.1.1 Introduction to the VHT PHY ............................................................................. 2497
21.1.2 Scope.................................................................................................................... 2498
21.1.3 VHT PHY functions ............................................................................................ 2498
21.1.3.1 General .............................................................................................. 2498
21.1.3.2 PHY management entity (PLME)..................................................... 2498
21.1.3.3 Service specification method ............................................................ 2498
21.1.4 PPDU formats ...................................................................................................... 2498
21.2 VHT PHY service interface ................................................................................................. 2499
21.2.1 Introduction.......................................................................................................... 2499
21.2.2 TXVECTOR and RXVECTOR parameters ........................................................ 2499
21.2.3 PHYCONFIG_VECTOR parameters .................................................................. 2507
21.2.4 Effects of CH_BANDWIDTH parameter on PPDU format................................ 2508
21.2.5 Support for NON_HT and HT formats................................................................ 2511
21.2.5.1 General .............................................................................................. 2511
21.2.5.2 Support for NON_HT format when NON_HT_MODULATION
is OFDM ........................................................................................... 2512
71
Copyright © 2016 IEEE. All rights reserved.
21.2.5.3 Support for HT formats..................................................................... 2513
21.2.6 TXSTATUS parameters ...................................................................................... 2513
21.3 VHT PHY ............................................................................................................................ 2514
21.3.1 Introduction.......................................................................................................... 2514
21.3.2 VHT PPDU format .............................................................................................. 2514
21.3.3 Transmitter block diagram................................................................................... 2515
21.3.4 Overview of the PPDU encoding process............................................................ 2522
21.3.4.1 General .............................................................................................. 2522
21.3.4.2 Construction of L-STF ...................................................................... 2522
21.3.4.3 Construction of the L-LTF ................................................................ 2523
21.3.4.4 Construction of L-SIG ...................................................................... 2523
21.3.4.5 Construction of VHT-SIG-A ............................................................ 2523
21.3.4.6 Construction of VHT-STF ................................................................ 2524
21.3.4.7 Construction of VHT-LTF ................................................................ 2524
21.3.4.8 Construction of VHT-SIG-B............................................................. 2525
21.3.4.9 Construction of the Data field in a VHT SU PPDU ......................... 2525
21.3.4.10 Construction of the Data field in a VHT MU PPDU ........................ 2527
21.3.5 VHT modulation and coding scheme (VHT-MCS)............................................. 2527
21.3.6 Timing-related parameters ................................................................................... 2528
21.3.7 Mathematical description of signals .................................................................... 2531
21.3.7.1 Notation............................................................................................. 2531
21.3.7.2 Subcarrier indices in use ................................................................... 2531
21.3.7.3 Channel frequencies.......................................................................... 2532
21.3.7.4 Transmitted signal............................................................................. 2533
21.3.7.5 Definition of tone rotation................................................................. 2537
21.3.8 VHT preamble ..................................................................................................... 2538
21.3.8.1 Introduction....................................................................................... 2538
21.3.8.2 Non-VHT portion of VHT format preamble..................................... 2538
21.3.8.3 VHT portion of VHT format preamble............................................. 2542
21.3.9 Transmission of NON_HT and HT PPDUs with multiple transmit chains ......... 2556
21.3.9.1 Transmission of 20 MHz NON_HT PPDUs with more than one
transmit chain.................................................................................... 2556
21.3.9.2 Transmission of HT PPDUs with more than four transmit chains ... 2556
21.3.10 Data field.............................................................................................................. 2556
21.3.10.1 General .............................................................................................. 2556
21.3.10.2 SERVICE field.................................................................................. 2557
21.3.10.3 CRC calculation for VHT-SIG-B ..................................................... 2558
21.3.10.4 Scrambler .......................................................................................... 2558
21.3.10.5 Coding............................................................................................... 2559
21.3.10.6 Stream parser..................................................................................... 2561
21.3.10.7 Segment parser.................................................................................. 2563
21.3.10.8 BCC interleaver................................................................................. 2564
21.3.10.9 Constellation mapping ...................................................................... 2566
21.3.10.10 Pilot subcarriers................................................................................. 2574
21.3.10.11 OFDM modulation............................................................................ 2575
21.3.10.12 Non-HT duplicate transmission ........................................................ 2577
21.3.11 SU-MIMO and DL-MU-MIMO Beamforming ................................................... 2578
21.3.11.1 General .............................................................................................. 2578
21.3.11.2 Beamforming Feedback Matrix V .................................................... 2579
21.3.11.3 Maximum Number of Total Spatial Streams in VHT MU PPDUs... 2579
21.3.11.4 Group ID ........................................................................................... 2579
21.3.12 VHT preamble format for sounding PPDUs........................................................ 2580
21.3.13 Regulatory requirements...................................................................................... 2580
21.3.14 Channelization ..................................................................................................... 2581
72
Copyright © 2016 IEEE. All rights reserved.
21.3.15 Slot time............................................................................................................... 2582
21.3.16 Transmit and receive port impedance .................................................................. 2582
21.3.17 VHT transmit specification.................................................................................. 2582
21.3.17.1 Transmit spectrum mask ................................................................... 2582
21.3.17.2 Spectral flatness ................................................................................ 2586
21.3.17.3 Transmit center frequency and symbol clock frequency tolerance... 2587
21.3.17.4 Modulation accuracy......................................................................... 2587
21.3.17.5 Time of Departure accuracy.............................................................. 2590
21.3.18 VHT receiver specification .................................................................................. 2590
21.3.18.1 Receiver minimum input sensitivity ................................................. 2590
21.3.18.2 Adjacent channel rejection................................................................ 2591
21.3.18.3 Nonadjacent channel rejection .......................................................... 2592
21.3.18.4 Receiver maximum input level ......................................................... 2593
21.3.18.5 CCA sensitivity ................................................................................. 2593
21.3.18.6 RSSI .................................................................................................. 2595
21.3.19 PHY transmit procedure ...................................................................................... 2595
21.3.20 PHY receive procedure ........................................................................................ 2597
21.4 VHT PLME.......................................................................................................................... 2602
21.4.1 PLME SAP sublayer management primitives ..................................................... 2602
21.4.2 PHY MIB ............................................................................................................. 2605
21.4.3 TXTIME and PSDU_LENGTH calculation........................................................ 2606
21.4.4 VHT PHY ............................................................................................................ 2607
21.5 Parameters for VHT-MCSs ................................................................................................. 2608
22. Television very high throughput (TVHT) PHY specification ......................................................... 2625
22.1 Introduction.......................................................................................................................... 2625
22.1.1 Introduction to the TVHT PHY ........................................................................... 2625
22.1.2 Scope.................................................................................................................... 2626
22.1.3 TVHT PHY functions .......................................................................................... 2626
22.1.3.1 General .............................................................................................. 2626
22.1.3.2 PHY management entity (PLME)..................................................... 2626
22.1.3.3 Service specification method ............................................................ 2626
22.1.4 PPDU formats ...................................................................................................... 2627
22.2 TVHT PHY service interface .............................................................................................. 2627
22.2.1 Introduction.......................................................................................................... 2627
22.2.2 TXVECTOR and RXVECTOR parameters ........................................................ 2627
22.2.3 Effects of CH_BANDWIDTH parameter on PPDU format................................ 2634
22.2.4 Support for NON_HT and HT formats................................................................ 2634
22.3 TVHT PHY sublayer ........................................................................................................... 2636
22.3.1 Introduction.......................................................................................................... 2636
22.3.2 VHT PPDU format in TVWS bands.................................................................... 2636
22.3.3 Transmitter block diagram................................................................................... 2637
22.3.4 Overview of the PPDU encoding process............................................................ 2638
22.3.4.1 General .............................................................................................. 2638
22.3.4.2 Construction of L-STF ...................................................................... 2638
22.3.4.3 Construction of the L-LTF ................................................................ 2639
22.3.4.4 Construction of L-SIG ...................................................................... 2639
22.3.4.5 Construction of TVHT-SIG-A .......................................................... 2640
22.3.4.6 Construction of TVHT-STF.............................................................. 2640
22.3.4.7 Construction of TVHT-LTF.............................................................. 2641
22.3.4.8 Construction of TVHT-SIG-B .......................................................... 2641
22.3.4.9 Construction of the Data field in an SU PPDU................................. 2641
22.3.4.10 Construction of the Data field in an MU PPDU ............................... 2642
73
Copyright © 2016 IEEE. All rights reserved.
22.3.5 Modulation and coding scheme (MCS) ............................................................... 2642
22.3.6 Timing-related parameters ................................................................................... 2643
22.3.7 Mathematical description of signals .................................................................... 2644
22.3.8 TVHT preamble ................................................................................................... 2648
22.3.8.1 Introduction....................................................................................... 2648
22.3.8.2 Non-TVHT portion of TVHT format preamble................................ 2648
22.3.8.3 TVHT portion of TVHT format preamble........................................ 2649
22.3.9 Transmission of NON_HT and HT PPDUs with multiple antennas ................... 2651
22.3.10 Data field.............................................................................................................. 2651
22.3.10.1 General .............................................................................................. 2651
22.3.10.2 SERVICE field.................................................................................. 2651
22.3.10.3 CRC calculation for TVHT-SIG-B ................................................... 2651
22.3.10.4 Scrambler .......................................................................................... 2651
22.3.10.5 Coding............................................................................................... 2651
22.3.10.6 Stream parser..................................................................................... 2651
22.3.10.7 Segment parser.................................................................................. 2651
22.3.10.8 BCC interleaver................................................................................. 2651
22.3.10.9 Constellation mapping ...................................................................... 2652
22.3.10.10 Pilot subcarriers................................................................................. 2653
22.3.10.11 OFDM modulation transmission in VHT format.............................. 2653
22.3.10.12 Non-HT duplicate transmission ........................................................ 2653
22.3.11 SU-MIMO and MU-MIMO Beamforming.......................................................... 2654
22.3.11.1 General .............................................................................................. 2654
22.3.11.2 Beamforming Feedback Matrix V .................................................... 2654
22.3.11.3 Group ID ........................................................................................... 2654
22.3.12 TVHT preamble format for sounding PPDUs ..................................................... 2654
22.3.13 Regulatory requirements...................................................................................... 2654
22.3.14 Channelization ..................................................................................................... 2655
22.3.15 Slot time............................................................................................................... 2656
22.3.16 Transmit and receive port impedance .................................................................. 2656
22.3.17 TVHT transmit specification ............................................................................... 2657
22.3.17.1 Transmit spectrum mask ................................................................... 2657
22.3.17.2 Spectral flatness ................................................................................ 2658
22.3.17.3 Transmit center frequency and symbol clock frequency tolerance... 2659
22.3.17.4 Modulation accuracy......................................................................... 2659
22.3.17.5 Time of Departure accuracy.............................................................. 2660
22.3.18 TVHT receiver specification ............................................................................... 2660
22.3.18.1 General .............................................................................................. 2660
22.3.18.2 Receiver minimum input sensitivity ................................................. 2660
22.3.18.3 Adjacent channel rejection................................................................ 2661
22.3.18.4 Nonadjacent channel rejection .......................................................... 2661
22.3.18.5 Receiver maximum input level ......................................................... 2662
22.3.18.6 CCA sensitivity ................................................................................. 2662
22.3.18.7 RSSI .................................................................................................. 2664
22.3.19 PHY transmit procedure ...................................................................................... 2664
22.3.20 PHY receive procedure ........................................................................................ 2664
22.4 TVHT PLME ....................................................................................................................... 2665
22.4.1 PLME SAP sublayer management primitives ..................................................... 2665
22.4.2 PHY MIB ............................................................................................................. 2665
22.4.3 TXTIME and PSDU_LENGTH calculation........................................................ 2665
22.4.4 TVHT PHY.......................................................................................................... 2665
22.5 Parameters for TVHT MCSs ............................................................................................... 2666
74
Copyright © 2016 IEEE. All rights reserved.
Annex A (informative) Bibliography ........................................................................................................ 2673
Annex B (normative) Protocol Implementation Conformance Statement (PICS) proforma..................... 2677
B.1 Introduction.................................................................................................................... 2677
B.2 Abbreviations and special symbols................................................................................ 2677
B.2.1 Symbols for Status column .............................................................................. 2677
B.2.2 General abbreviations for Item and Support columns...................................... 2677
B.3 Instructions for completing the PICS proforma............................................................. 2678
B.3.1 General structure of the PICS proforma........................................................... 2678
B.3.2 Additional information ..................................................................................... 2679
B.3.3 Exception information...................................................................................... 2679
B.3.4 Conditional status ............................................................................................. 2679
B.4 PICS proforma—IEEE Std 802.11-2016....................................................................... 2681
B.4.1 Implementation identification .......................................................................... 2681
B.4.2 Protocol summary ............................................................................................ 2681
B.4.3 IUT configuration............................................................................................. 2682
B.4.4 MAC protocol .................................................................................................. 2684
B.4.5 Direct sequence PHY functions ....................................................................... 2698
B.4.6 OFDM PHY functions ..................................................................................... 2701
B.4.7 High rate, direct sequence PHY functions ....................................................... 2712
B.4.8 Regulatory domain extensions ......................................................................... 2716
B.4.9 ERP functions................................................................................................... 2717
B.4.10 Spectrum management extensions ................................................................... 2719
B.4.11 Operating classes extensions ............................................................................ 2723
B.4.12 QoS base functionality ..................................................................................... 2723
B.4.13 QoS enhanced distributed channel access (EDCA) ......................................... 2724
B.4.14 QoS hybrid coordination function (HCF) controlled channel access
(HCCA) ............................................................................................................ 2725
B.4.15 Radio management extensions ......................................................................... 2726
B.4.16 DSE functions .................................................................................................. 2732
B.4.17 High-throughput (HT) features ..................................................................... 2735
B.4.18 Tunneled direct-link setup extensions.............................................................. 2742
B.4.19 WNM extensions.............................................................................................. 2743
B.4.20 Interworking (IW) with external networks extensions..................................... 2747
B.4.21 Mesh protocol capabilities ............................................................................... 2749
B.4.22 QMF extensions .............................................................................................. 2752
B.4.23 RobustAVT extensions ................................................................................... 2753
B.4.24 DMG features ................................................................................................. 2754
B.4.25 Very high throughput (VHT) features.............................................................. 2762
B.4.26 TVWS functions............................................................................................... 2769
Annex C (normative) ASN.1 encoding of the MAC and PHY MIB ......................................................... 2776
C.1 General........................................................................................................................... 2776
C.2 Guidelines for IEEE 802.11 MIB authors/editors ......................................................... 2776
C.3 MIB detail ...................................................................................................................... 2776
Annex D (normative) Regulatory references............................................................................................. 3269
D.1 External regulatory references ....................................................................................... 3269
D.2 Radio performance specifications.................................................................................. 3271
D.2.1 Transmit and receive in-band and out-of-band spurious emissions ................. 3271
D.2.2 Transmit power levels ...................................................................................... 3271
75
Copyright © 2016 IEEE. All rights reserved.
D.2.3 Transmit spectrum mask .................................................................................. 3272
D.2.4 Transmit Mask M ............................................................................................. 3273
D.2.5 CCA-ED threshold ........................................................................................... 3274
Annex E (normative) Country elements and operating classes ................................................................. 3275
E.1 Country information and operating classes ................................................................... 3275
E.2 Band-specific operating requirements ........................................................................... 3287
E.2.1 General ............................................................................................................. 3287
E.2.2 3650–3700 MHz in the United States .............................................................. 3287
E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) ................................... 3289
E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz)................................................... 3289
E.2.5 TVWS band in the United States and Canada (54 MHz to 698 MHz) ............ 3289
E.2.6 TVWS band in Europe ..................................................................................... 3291
Annex F (normative) HT LDPC matrix definitions................................................................................... 3293
Annex G (normative) Frame exchange sequences..................................................................................... 3296
G.1 General........................................................................................................................... 3296
G.2 Basic sequences ............................................................................................................. 3298
G.3 EDCA and HCCA sequences ........................................................................................ 3299
G.4 HT and VHT sequences ................................................................................................. 3301
Annex H (normative) Usage of Ethertype 89-0d....................................................................................... 3311
Annex I (informative) Examples of encoding a frame for OFDM PHYs and DMG PHYs...................... 3312
I.1 Example 1 - BCC encoding ........................................................................................... 3312
I.1.1 Introduction ...................................................................................................... 3312
I.1.2 The message for the BCC example .................................................................. 3313
I.1.3 Generation of the preamble .............................................................................. 3314
I.1.4 Generation of the SIGNAL field ...................................................................... 3319
I.1.5 Generating the DATA bits for the BCC example ............................................ 3323
I.1.6 Generating the first DATA symbol for the BCC example............................... 3327
I.1.7 Generating the additional DATA symbols....................................................... 3333
I.1.8 The entire packet for the BCC example ........................................................... 3334
I.2 Generating encoded DATA bits—LDPC example 1..................................................... 3342
I.2.1 The message for LDPC example 1................................................................... 3342
I.2.2 Prepending the SERVICE field for LDPC example 1 ..................................... 3343
I.2.3 Scrambling LDPC example 1........................................................................... 3345
I.2.4 Inserting shortening bits for LDPC example 1................................................. 3346
I.2.5 Encoding data for LDPC example 1 ................................................................ 3348
I.2.6 Removing shortening bits and puncturing for LDPC example 1 ..................... 3351
I.3 Generating encoded DATA bits—LDPC example 2..................................................... 3353
I.3.1 The message for LDPC example 2................................................................... 3353
I.3.2 Prepending the SERVICE field for LDPC example 2 ..................................... 3355
I.3.3 Scrambling LDPC example 2........................................................................... 3357
I.3.4 Inserting the shortening bits for LDPC example 2........................................... 3358
I.3.5 Encoding the data for LDPC example 2........................................................... 3360
I.3.6 Removing shortening bits and repetition for LDPC example 2 ....................... 3364
I.4 DMG example data vectors ........................................................................................... 3368
I.5 DMG Example 1 – DMG control mode encoding......................................................... 3368
I.5.1 DMG control mode preamble .......................................................................... 3368
76
Copyright © 2016 IEEE. All rights reserved.
I.5.2 Control mode header ........................................................................................ 3369
I.5.3 DMG control mode payload............................................................................. 3371
I.6 DMG Example 2 – DMG SC mode encoding ............................................................... 3372
I.6.1 DMG SC mode preamble ................................................................................. 3372
I.6.2 DMG SC mode header ..................................................................................... 3373
I.6.3 DMG SC mode payload ................................................................................... 3375
I.7 DMG Example 3 – DMG OFDM mode encoding ........................................................ 3381
I.7.1 DMG OFDM mode preamble .......................................................................... 3381
I.7.2 DMG OFDM mode header .............................................................................. 3381
I.7.3 DMG OFDM mode header modulation ........................................................... 3384
I.7.4 DMG OFDM mode payload coding................................................................. 3385
I.7.5 DMG OFDM mode MCS14 payload modulation............................................ 3385
I.7.6 DMG OFDM mode MCS17 payload modulation............................................ 3387
I.7.7 DMG OFDM mode MCS19 payload modulation............................................ 3388
I.7.8 DMG OFDM mode MCS23 payload modulation............................................ 3390
I.8 DMG Example 4 – DMG low-power SC mode encoding............................................. 3391
I.8.1 DMG low-power SC mode preamble............................................................... 3391
I.8.2 DMG low-power SC mode header................................................................... 3391
I.8.3 DMG low-power SC mode MCS26 payload ................................................... 3392
I.8.4 DMG low-power SC mode MCS30 payload ................................................... 3393
Annex J (informative) RSNA reference implementations and test vectors............................................... 3395
J.1 TKIP temporal key mixing function reference implementation and test vector............ 3395
J.1.1 TKIP temporal key mixing function reference implementation ...................... 3395
J.1.2 Test vectors ...................................................................................................... 3405
J.2 Michael reference implementation and test vectors ...................................................... 3407
J.2.1 Michael test vectors.......................................................................................... 3407
J.2.2 Sample code for michael .................................................................................. 3408
J.3 PRF reference implementation and test vectors ............................................................ 3415
J.3.1 PRF reference code .......................................................................................... 3415
J.3.2 PRF test vectors................................................................................................ 3416
J.4 Suggested pass-phrase-to-PSK mapping ....................................................................... 3416
J.4.1 Introduction ...................................................................................................... 3416
J.4.2 Test vectors ...................................................................................................... 3417
J.5 Suggestions for random number generation .................................................................. 3417
J.5.1 General ............................................................................................................. 3417
J.5.2 Software sampling............................................................................................ 3418
J.5.3 Hardware-assisted solution .............................................................................. 3419
J.6 Additional test vectors ................................................................................................... 3420
J.6.1 Notation ............................................................................................................ 3420
J.6.2 WEP cryptographic encapsulation ................................................................... 3420
J.6.3 TKIP test vector ............................................................................................... 3421
J.6.4 CCMP test vectors............................................................................................ 3422
J.6.5 PRF test vectors................................................................................................ 3423
J.7 Key hierarchy test vectors for pairwise keys ................................................................. 3425
J.7.1 General ............................................................................................................. 3425
J.7.2 CCMP-128 pairwise key derivation ................................................................. 3425
J.7.3 TKIP pairwise key derivation .......................................................................... 3425
J.8 Test vectors for AES-128-CMAC ................................................................................. 3426
J.9 Management frame protection test vectors .................................................................... 3426
J.9.1 BIP with broadcast Deauthentication frame..................................................... 3426
J.9.2 CCMP-128 with unicast Deauthentication frame ............................................ 3428
J.10 SAE test vector .............................................................................................................. 3429
77
Copyright © 2016 IEEE. All rights reserved.
J.11 GCMP ............................................................................................................................ 3430
J.11.1 Test vector ........................................................................................................ 3430
J.11.2 Example of encryption C code ......................................................................... 3433
Annex K (informative) TSPECs and Admission control........................................................................... 3446
K.1 Example use of TSPEC for admission control .............................................................. 3446
K.2 Recommendation for implementation of contention based admission control.............. 3447
K.2.1 Use of ACM (admission control mandatory) subfield ..................................... 3447
K.2.2 Deriving medium time ..................................................................................... 3447
K.3 Guidelines and reference design for sample scheduler and admission control unit ...... 3449
K.3.1 Guidelines for deriving service schedule parameters....................................... 3449
K.3.2 Reference design for sample scheduler and admission control unit ................ 3450
K.4 TSPEC construction....................................................................................................... 3452
K.4.1 Surplus Bandwidth Allocation ......................................................................... 3453
K.4.2 Minimum and Maximum Service Interval ....................................................... 3457
K.4.3 Minimum, Mean, and Peak Data Rate ............................................................. 3458
Annex L (informative) Examples and sample code for encoding a TIM Partial Virtual Bitmap.............. 3459
L.1 Introduction.................................................................................................................... 3459
L.2 Examples........................................................................................................................ 3459
L.3 Sample C code ............................................................................................................... 3462
Annex M (informative) Integration function ............................................................................................. 3468
M.1 Introduction.................................................................................................................... 3468
M.2 Ethernet V2.0/IEEE 802.3 LAN integration function ................................................... 3468
M.3 Example ......................................................................................................................... 3468
M.4 Integration service versus bridging................................................................................ 3470
Annex N (informative) AP functional description .................................................................................... 3471
N.1 Introduction.................................................................................................................... 3471
N.2 Terminology................................................................................................................... 3471
N.3 Primary ACM_STA functions ....................................................................................... 3475
N.4 Primary AP functions..................................................................................................... 3475
N.5 Primary DS functions..................................................................................................... 3477
N.6 Primary portal function .................................................................................................. 3477
Annex O (informative) Additional VHT and HT information .................................................................. 3478
O.1 VHT and HT waveform generator tool.......................................................................... 3478
O.2 A-MPDU deaggregation ................................................................................................ 3478
O.3 Example of an RD exchange sequence.......................................................................... 3480
O.4 Illustration of determination of NDP addresses............................................................. 3481
O.5 20/40 MHz BSS establishment and maintenance .......................................................... 3482
O.5.1 Signaling 20/40 MHz BSS capability and operation ....................................... 3482
O.5.2 Establishing a 20/40 MHz BSS ........................................................................ 3482
O.5.3 Monitoring channels for other BSS operation.................................................. 3483
Annex P (informative) Location and Time Difference accuracy test ........................................................ 3485
P.1 Location via Time Difference of arrival ........................................................................ 3485
78
Copyright © 2016 IEEE. All rights reserved.
P.2 Time Difference of departure accuracy test................................................................... 3485
P.3 Differential Distance Computation using Fine Timing Measurement frames............... 3487
Annex Q (informative) Example use of the Destination URI for Event and Diagnostic Reports ............. 3489
Q.1 Destination URI payload ............................................................................................... 3489
Q.2 Use of HTTP (or HTTPS) for Destination URI of Event and Diagnostic Reports ....... 3489
Annex R (informative) Interworking with external networks ................................................................... 3491
R.1 General........................................................................................................................... 3491
R.2 Network discovery and selection ................................................................................... 3491
R.2.1 General ............................................................................................................. 3491
R.2.2 Airport .............................................................................................................. 3491
R.2.3 Shopping........................................................................................................... 3492
R.2.4 Sales meeting.................................................................................................... 3493
R.2.5 Museum ............................................................................................................ 3493
R.2.6 Emergency call ................................................................................................. 3494
R.2.7 Emergency alert................................................................................................ 3495
R.3 QoS mapping guidelines for interworking with external networks ............................... 3495
R.3.1 General ............................................................................................................. 3495
R.3.2 Determination of the mapping for a STA......................................................... 3496
R.3.3 Example of QoS mapping from different networks ......................................... 3496
R.4 Interworking and SSPN interface support ..................................................................... 3498
R.4.1 General ............................................................................................................. 3498
R.4.2 SSPN interface parameters............................................................................... 3499
R.5 Interworking with external networks and emergency call support................................ 3503
R.5.1 General ............................................................................................................. 3503
R.5.2 Background on emergency call support over IEEE 802.11 infrastructure....... 3503
R.5.3 System aspects for emergency call support...................................................... 3504
R.5.4 Description of the Expedited Bandwidth Request element.............................. 3505
R.5.5 Access to emergency services in an RSN ........................................................ 3506
R.6 Peer information ............................................................................................................ 3507
R.7 Calculating Estimated Throughput ................................................................................ 3507
Annex S (informative) Mesh BSS operation ............................................................................................. 3510
S.1 Clarification of mesh Data frame format ....................................................................... 3510
S.2 Operational considerations for interworking ................................................................. 3510
S.2.1 Formation and maintenance of the IEEE 802.1D spanning tree ...................... 3510
S.3 Power save parameters selection ................................................................................... 3511
S.3.1 General ............................................................................................................. 3511
S.3.2 Selecting the mesh power management mode based on traffic load................ 3511
S.3.3 Scanning of mesh BSSs.................................................................................... 3511
S.3.4 Default parameters ........................................................................................... 3512
S.3.5 MSDU forwarding in an MBSS containing mesh STAs in light or deep
sleep mode........................................................................................................ 3512
S.3.6 Synchronization maintenance of mesh STAs in deep sleep mode................... 3512
S.4 SIV key wrapping test vector......................................................................................... 3513
S.5 Airtime link metric usage example ................................................................................ 3514
S.6 Generation of proactive PREP elements in the proactive PREQ mechanism of
HWMP ........................................................................................................................... 3514
S.6.1 General ............................................................................................................. 3514
S.6.2 Additions to forwarding information ............................................................... 3515
79
Copyright © 2016 IEEE. All rights reserved.
S.6.3 Actions when sending Data frames as source mesh STA ................................ 3515
S.6.4 Actions on receipt of a proactive PREQ element............................................. 3515
S.6.5 Generation of proactive PREP elements .......................................................... 3515
S.7 Generation of PREQ elements in proactive RANN mechanism of HWMP.................. 3516
S.7.1 General ............................................................................................................. 3516
S.7.2 Additions to forwarding information ............................................................... 3516
S.7.3 Actions when sending Data frames as source mesh STA ................................ 3516
S.7.4 Actions on receipt of proactive RANN element .............................................. 3516
S.7.5 Actions on receipt of a PREP element ............................................................. 3517
Annex T (informative) Overlapping BSS (OBSS) management............................................................... 3518
T.1 Introduction.................................................................................................................... 3518
T.2 QLoad Report element................................................................................................... 3518
T.2.1 General ............................................................................................................. 3518
T.2.2 Calculating medium time ................................................................................. 3519
T.2.3 Calculation of potential traffic self................................................................... 3519
T.2.4 Calculation of allocated traffic self .................................................................. 3521
T.2.5 Calculation of allocated traffic shared.............................................................. 3522
T.2.6 Calculation of EDCA Access Factor................................................................ 3522
T.2.7 EDCA Overhead Factor ................................................................................... 3523
T.2.8 Calculation of HCCA Access Factor ............................................................... 3524
T.3 Channel selection using QLoad report........................................................................... 3524
T.3.1 General ............................................................................................................. 3524
T.3.2 AP with admission control mandatory ............................................................. 3524
T.3.3 AP with an HC ................................................................................................. 3525
T.3.4 Channel selection procedures........................................................................... 3525
T.4 Sharing in an OBSS situation ........................................................................................ 3526
T.4.1 General ............................................................................................................. 3526
T.4.2 Sharing schemes ............................................................................................... 3527
T.5 Mitigating consequences of OBSS sharing in presence of noncollaborating devices ... 3529
Annex U (informative) Functions of the centralized coordination service root (CCSR) .......................... 3530
Annex V (informative) TSPEC aggregation for DMG BSSs .................................................................... 3531
80
Copyright © 2016 IEEE. All rights reserved.
Tables
Table 4-1—GDD mechanisms and timescales ............................................................................................ 214
Table 6-1—Supported TS management primitives ..................................................................................... 339
Table 6-2—Reason codes for network down .............................................................................................. 597
Table 6-3—Reason codes for ESS link down ............................................................................................. 598
Table 6-4—ESS description ........................................................................................................................ 600
Table 6-5—Trigger support values.............................................................................................................. 600
Table 6-6—Event Capability Set ................................................................................................................. 603
Table 6-7—ESS Link Parameter Set ........................................................................................................... 605
Table 8-1—PHY SAP peer-to-peer service primitives................................................................................ 620
Table 8-2—PHY SAP inter-(sub)layer service primitives .......................................................................... 621
Table 8-3—PHY SAP service primitive parameters ................................................................................... 621
Table 8-4—Vector descriptions................................................................................................................... 622
Table 8-5—The channel-list parameter elements ........................................................................................ 629
Table 9-1—Valid type and subtype combinations ...................................................................................... 639
Table 9-2—Control Frame Extension ......................................................................................................... 640
Table 9-3—To/From DS combinations in Data frames............................................................................... 641
Table 9-4—To/From DS combinations in Management frames ................................................................ 642
Table 9-5—Duration/ID field encoding ...................................................................................................... 645
Table 9-6—QoS Control field ..................................................................................................................... 648
Table 9-7—QoS Control field for frames transmitted within a DMG PPDU ............................................. 649
Table 9-8—TID subfield ............................................................................................................................. 649
Table 9-9—Ack Policy subfield in QoS Control field of QoS Data frames................................................ 650
Table 9-10—AC Constraint subfield values................................................................................................ 654
Table 9-11—RDG/More PPDU subfield values ......................................................................................... 655
Table 9-12—Subfields of Link Adaptation Control subfield ...................................................................... 656
Table 9-13—Subfields of the MAI subfield ................................................................................................ 656
Table 9-14—ASEL Command and ASEL Data subfields........................................................................... 657
Table 9-15—Calibration control subfields .................................................................................................. 658
Table 9-16—CSI/Steering subfield values .................................................................................................. 658
Table 9-17—VHT variant HT Control field subfields ............................................................................... 659
Table 9-18—MFB subfield in the VHT variant HT Control field ............................................................. 661
Table 9-19—Maximum data unit sizes (in octets) and durations (in microseconds) ................................. 662
Table 9-20—Valid values for the Address Extension Mode subfield ........................................................ 664
Table 9-21—BAR Ack Policy subfield ....................................................................................................... 673
Table 9-22—BlockAckReq frame variant encoding ................................................................................... 674
Table 9-23—BA Ack Policy subfield.......................................................................................................... 677
Table 9-24—BlockAck frame variant encoding ........................................................................................ 677
Table 9-25—STA Info subfields ................................................................................................................. 686
Table 9-26—Address field contents ............................................................................................................ 688
Table 9-27—Beacon frame body................................................................................................................. 694
Table 9-28—Disassociation frame body ..................................................................................................... 699
Table 9-29—Association Request frame body ............................................................................................ 699
Table 9-30—Association Response frame body ......................................................................................... 700
Table 9-31—Reassociation Request frame body......................................................................................... 702
Table 9-32—Reassociation Response frame body ...................................................................................... 704
Table 9-33—Probe Request frame body ..................................................................................................... 706
Table 9-34—Probe Response frame body ................................................................................................... 708
Table 9-35—Authentication frame body ..................................................................................................... 712
Table 9-36—Presence of fields and elements in Authentication frames..................................................... 713
Table 9-37—Deauthentication frame body ................................................................................................. 715
Table 9-38—Action frame body.................................................................................................................. 715
Table 9-39—Action No Ack frame body .................................................................................................... 716
81
Copyright © 2016 IEEE. All rights reserved.
Table 9-40—Timing Advertisement frame body ........................................................................................ 716
Table 9-41—DMG Beacon frame body ..................................................................................................... 717
Table 9-42—Valid address field usage for Mesh Data and Multihop Action frames ................................. 721
Table 9-43—Non-AP STA usage of QoS, CF-Pollable, and CF-Poll Request ........................................... 725
Table 9-44—AP usage of QoS, CF-Pollable, and CF-Poll Request............................................................ 726
Table 9-45—Reason codes .......................................................................................................................... 728
Table 9-46—Status codes ............................................................................................................................ 732
Table 9-47—Category values ...................................................................................................................... 736
Table 9-48—Settings of the Max SP Length subfield ................................................................................. 740
Table 9-49—Settings of the Channel Width field ....................................................................................... 742
Table 9-50—Settings of the PCO Phase Control field ................................................................................ 743
Table 9-51—Subfields of the MIMO Control field..................................................................................... 745
Table 9-52—CSI Report field (20 MHz)..................................................................................................... 746
Table 9-53—CSI Report field (40 MHz)..................................................................................................... 747
Table 9-54—Number of matrices and carrier grouping .............................................................................. 748
Table 9-55—Noncompressed Beamforming Report field (20 MHz) .......................................................... 749
Table 9-56—Noncompressed Beamforming Report field (40 MHz) .......................................................... 749
Table 9-57—Order of angles in the Compressed Beamforming Report field ............................................. 750
Table 9-58—Quantization of angles............................................................................................................ 751
Table 9-59—Compressed Beamforming Report field (20 MHz) ................................................................ 751
Table 9-60—Compressed Beamforming Report field (40 MHz) ................................................................ 752
Table 9-61—Venue group codes and descriptions ...................................................................................... 756
Table 9-62—Venue type assignments ......................................................................................................... 757
Table 9-63—Band ID field ......................................................................................................................... 761
Table 9-64—The BSS Type subfield when the Discovery mode field is 0................................................. 762
Table 9-65—The BSS Type subfield when the Discovery mode field is 1................................................. 762
Table 9-66—Subfields of the VHT MIMO Control field ........................................................................... 763
Table 9-67—Order of angles in the Compressed Beamforming Feedback Matrix subfield ...................... 765
Table 9-68—Quantization of angles............................................................................................................ 767
Table 9-69—VHT Compressed Beamforming Report information ........................................................... 767
Table 9-70—Subcarriers for which a Compressed Beamforming Feedback Matrix subfield is sent back 768
Table 9-71—Average SNR of Space-Time Stream i subfield..................................................................... 773
Table 9-72—MU Exclusive Beamforming Report information ................................................................. 775
Table 9-73—Number of subcarriers and subcarrier mapping .................................................................... 776
Table 9-74—Subfield values of the Operating Mode field ......................................................................... 779
Table 9-75—Setting of the Channel Width subfield and 160/80+80 BW subfield at a VHT STA
transmitting the Operating Mode field ........................................................................... 780
Table 9-76—WSM Type definition............................................................................................................. 783
Table 9-77—Element IDs ........................................................................................................................... 784
Table 9-78—BSS membership selector value encoding ............................................................................. 791
Table 9-79—Coverage Class field parameters ............................................................................................ 798
Table 9-80—Values of the Secondary Channel Offset field ....................................................................... 803
Table 9-81—Summary of use of Enable, Request, and Report bits ............................................................ 805
Table 9-82—Measurement type definitions for measurement requests ..................................................... 805
Table 9-83—Optional subelement IDs for Channel Load request .............................................................. 808
Table 9-84—Reporting Condition subfield for Channel Load report ......................................................... 809
Table 9-85—Optional subelement IDs for Noise Histogram request.......................................................... 810
Table 9-86—Reporting Condition subfield for Noise Histogram report..................................................... 810
Table 9-87—Measurement Mode definitions for Beacon request............................................................... 812
Table 9-88—Optional subelement IDs for Beacon request......................................................................... 812
Table 9-89—Reporting Condition subfield for Beacon report .................................................................... 813
Table 9-90—Reporting Detail values .......................................................................................................... 814
Table 9-91—Optional subelement IDs for Frame request........................................................................... 815
Table 9-92—Group Identity for a STA Statistics request ........................................................................... 816
82
Copyright © 2016 IEEE. All rights reserved.
Table 9-93—Optional subelement IDs for STA Statistics request.............................................................. 817
Table 9-94—Location Subject field definition ............................................................................................ 820
Table 9-95—Optional subelement IDs for LCI request ............................................................................. 821
Table 9-96—Optional subelement IDs for Transmit Stream/Category Measurement Request .................. 824
Table 9-97—Delayed MSDU Range Definitions ........................................................................................ 825
Table 9-98—Optional subelement IDs for Measurement Pause request..................................................... 826
Table 9-99—Optional subelement IDs for STA Multicast Diagnostics request ......................................... 828
Table 9-100—Civic Location Type field values ......................................................................................... 829
Table 9-101—Location Service Interval Units............................................................................................ 829
Table 9-102—Optional subelement IDs for Location Civic request ........................................................... 829
Table 9-103—Optional subelement IDs for Location Identifier request..................................................... 830
Table 9-104—Optional subelement IDs for Directional Channel Quality request...................................... 832
Table 9-105—Reporting Condition subfield for Directional Channel Quality report ................................ 832
Table 9-106—FTM Range subelement IDs for Fine Timing Measurement Range request........................ 834
Table 9-107—Measurement Type field definitions for measurement reports............................................. 837
Table 9-108—RPI definitions for an RPI histogram report ........................................................................ 839
Table 9-109—Optional subelement IDs for Channel Load report .............................................................. 841
Table 9-110—IPI Definitions for a Noise Histogram report ....................................................................... 842
Table 9-111—Optional subelement IDs for Noise Histogram report.......................................................... 843
Table 9-112—Optional subelement IDs for Beacon report......................................................................... 844
Table 9-113—Optional subelement IDs for Frame report........................................................................... 846
Table 9-114—Group Identity for a STA Statistics report ........................................................................... 848
Table 9-115—Optional subelement IDs for STA Statistics report.............................................................. 854
Table 9-116—Subelement IDs for LCI Report ........................................................................................... 856
Table 9-117—Delay definitions for a Transmit Stream/Category Measurement report
for a Bin 0 Range field value of 10 TU ........................................................................... 864
Table 9-118—Optional subelement IDs for Transmit Stream/Category Measurement report.................... 865
Table 9-119—Optional subelement IDs for Multicast Diagnostics report.................................................. 867
Table 9-120—Summary of fields used in the STA Multicast Diagnostics report....................................... 867
Table 9-121—Subelement IDs for Location Civic report ........................................................................... 868
Table 9-122—Location Shape IDs .............................................................................................................. 870
Table 9-123—Map Types ............................................................................................................................ 873
Table 9-124—Subelement IDs for Location Identifier report ..................................................................... 874
Table 9-125—URI/FQDN Descriptor field values...................................................................................... 875
Table 9-126—Optional subelement IDs for Directional Channel Quality report........................................ 877
Table 9-127—Optional subelement IDs for Directional Measurement report ............................................ 878
Table 9-128—Optional subelement IDs for Directional Statistics report ................................................... 879
Table 9-129—Error Code field values......................................................................................................... 880
Table 9-130—Optional subelement IDs for Fine Timing Measurement Range report ............................... 881
Table 9-131—Cipher suite selectors............................................................................................................ 884
Table 9-132—Cipher suite usage ................................................................................................................ 886
Table 9-133—AKM suite selectors ............................................................................................................. 886
Table 9-134—PTKSA/GTKSA/STKSA replay counters usage ................................................................. 889
Table 9-135—Extended Capabilities field .................................................................................................. 891
Table 9-136—ACI-to-AC coding ................................................................................................................ 898
Table 9-137—Default EDCA Parameter Set element parameter values if dot11OCBActivated is false ... 899
Table 9-138—Default EDCA parameter set for STA operation if dot11OCBActivated is true ................. 899
Table 9-139—Direction subfield encoding ................................................................................................. 900
Table 9-140—Access Policy subfield.......................................................................................................... 901
Table 9-141—TS Info Ack Policy subfield encoding ................................................................................. 901
Table 9-142—Setting of Schedule subfield................................................................................................. 902
Table 9-143—Reliability subfield values .................................................................................................... 906
Table 9-144—User Priority field of TCLAS element ................................................................................. 906
Table 9-145—Frame classifier type ............................................................................................................ 907
83
Copyright © 2016 IEEE. All rights reserved.
Table 9-146—Interpretation of the Classifier Mask Control subfield values ............................................. 908
Table 9-147—Map from location of Classifier Mask subfield to target subfield ....................................... 908
Table 9-148—Classifier parameters for Classifier Type 4 .......................................................................... 910
Table 9-149—Encoding of Processing subfield .......................................................................................... 915
Table 9-150—Reachability field ................................................................................................................. 917
Table 9-151—Optional subelement IDs for Neighbor report ..................................................................... 919
Table 9-152—Preference field values ......................................................................................................... 921
Table 9-153—HT/VHT Operation Information subfields........................................................................... 922
Table 9-154—RCPI values .......................................................................................................................... 923
Table 9-155—Optional subelement IDs for Measurement Pilot Transmission .......................................... 926
Table 9-156—Available Admission Capacity Bitmask definition .............................................................. 927
Table 9-157—RM Enabled Capabilities definition ..................................................................................... 929
Table 9-158—Optional subelement IDs for Multiple BSSID ..................................................................... 932
Table 9-159—Subelement IDs .................................................................................................................... 934
Table 9-160—Timeout Interval Type field value........................................................................................ 936
Table 9-161—Resource type code in RIC Descriptor element ................................................................... 937
Table 9-162—Subfields of the HT Capability Information field ................................................................ 942
Table 9-163—Subfields of the A-MPDU Parameters field......................................................................... 944
Table 9-164—Transmit MCS Set ................................................................................................................ 945
Table 9-165—Subfields of the HT Extended Capabilities field.................................................................. 946
Table 9-166—Subfields of the Transmit Beamforming Capabilities field.................................................. 947
Table 9-167—ASEL Capability field subfields........................................................................................... 950
Table 9-168—HT Operation element fields and subfields .......................................................................... 951
Table 9-169—Encoding of the Timing Capabilities field ........................................................................... 957
Table 9-170—Time Value field format when Timing Capabilities is 2...................................................... 958
Table 9-171—Event Type field definitions for event requests and reports................................................. 961
Table 9-172—Transition Event Request subelement .................................................................................. 962
Table 9-173—RSNA Event Request subelement ....................................................................................... 964
Table 9-174—Peer-to-Peer Link Event Request subelement ...................................................................... 966
Table 9-175—Event Report Status .............................................................................................................. 968
Table 9-176—Transition and Transition Query reasons ............................................................................. 969
Table 9-177—Peer Status definitions .......................................................................................................... 972
Table 9-178—Diagnostic Request/Report Type definitions ....................................................................... 973
Table 9-179—Association Diagnostic request contents .............................................................................. 974
Table 9-180—IEEE 802.1X Authentication Diagnostic request contents .................................................. 974
Table 9-181—Diagnostic subelement ID values ......................................................................................... 975
Table 9-182—Credentials values................................................................................................................. 976
Table 9-183—Collocated Radio Type ......................................................................................................... 978
Table 9-184—Device Type definitions ....................................................................................................... 978
Table 9-185—Power Save Mode definition ................................................................................................ 981
Table 9-186—Tx Power Modes .................................................................................................................. 983
Table 9-187—Manufacturer Information STA report contents................................................................... 984
Table 9-188—Configuration Profile report contents................................................................................... 985
Table 9-189—Association Diagnostic report contents ................................................................................ 985
Table 9-190—IEEE 802.1X Authentication Diagnostic report contents .................................................... 986
Table 9-191—Optional subelement IDs for Location Parameters ............................................................. 986
Table 9-192—Report Interval Units field.................................................................................................... 988
Table 9-193—Motion Indicator field .......................................................................................................... 991
Table 9-194—Speed Units........................................................................................................................... 991
Table 9-195—Indication Parameter values ................................................................................................. 993
Table 9-196—Optional subelement IDs for FMS Request subelements..................................................... 997
Table 9-197—Optional subelement IDs for FMS Response subelements .................................................. 998
Table 9-198—FMS Element Status and TFS Response Status definition................................................... 999
Table 9-199—QoS Traffic Capability Bitmask/Flags definition .............................................................. 1001
84
Copyright © 2016 IEEE. All rights reserved.
Table 9-200—TFS Action Code field values ............................................................................................ 1002
Table 9-201—Optional subelement IDs for TFS Request parameters ...................................................... 1003
Table 9-202—Optional subelement IDs for TFS Response parameters.................................................... 1004
Table 9-203—Action Type definitions...................................................................................................... 1006
Table 9-204—WNM Sleep Mode Response Status definition .................................................................. 1006
Table 9-205—Status field values............................................................................................................... 1007
Table 9-206—Usage Mode definitions...................................................................................................... 1010
Table 9-207—DMS Request Type field .................................................................................................... 1012
Table 9-208—Optional subelement IDs for DMS Descriptor................................................................... 1012
Table 9-209—GATS Retransmission Policy field values ......................................................................... 1013
Table 9-210—GCR Delivery Method field values.................................................................................... 1013
Table 9-211—Response Type field values ................................................................................................ 1014
Table 9-212—Optional subelement IDs for DMS Status .......................................................................... 1015
Table 9-213—Optional subelement IDs for U-APSD coexistence ........................................................... 1017
Table 9-214—Access network type........................................................................................................... 1018
Table 9-215—Advertisement protocol ID definitions............................................................................... 1020
Table 9-216—Precedence Level field description..................................................................................... 1022
Table 9-217—Active Path Selection Protocol Identifier field values ....................................................... 1025
Table 9-218—Active Path Selection Metric Identifier field values .......................................................... 1025
Table 9-219—Congestion Control Mode Identifier field values............................................................... 1026
Table 9-220—Synchronization Method Identifier field values ................................................................. 1026
Table 9-221—Authentication Protocol Identifier field values .................................................................. 1027
Table 9-222—Mesh Peering Protocol Identifier field values .................................................................... 1030
Table 9-223—MCCA Reply Code field values......................................................................................... 1035
Table 9-224—SCS Request Type definitions............................................................................................ 1050
Table 9-225—Optional subelement IDs for SCS Descriptor element....................................................... 1051
Table 9-226—Sharing Policy definitions .................................................................................................. 1052
Table 9-227—Optional subelement IDs for QLoad Report element......................................................... 1052
Table 9-228—Protocol ID definitions ....................................................................................................... 1054
Table 9-229—Subfields of the A-MPDU Parameters subfield ................................................................. 1057
Table 9-230—Beam Tracking Time Limit negotiation ............................................................................. 1060
Table 9-231—Mapping of Extended SC MCS to Maximum Supported Rx/Tx MCS subfield values..... 1061
Table 9-232—Maximum Number Of Basic A-MSDU Subframes In A-MSDU subfield ........................ 1062
Table 9-233—Maximum Number Of Short A-MSDU Subframes In A-MSDU subfield ........................ 1062
Table 9-234—FBCK-REQ field description ............................................................................................. 1065
Table 9-235—FBCK-TYPE field description ........................................................................................... 1066
Table 9-236—AllocationType subfield values.......................................................................................... 1068
Table 9-237—Allocation Format subfield values ..................................................................................... 1071
Table 9-238—Allocation Period field values ............................................................................................ 1072
Table 9-239—TSCONST Period values ................................................................................................... 1073
Table 9-240—Channel Measurement Feedback element format ............................................................ 1074
Table 9-241—Channel measurement ........................................................................................................ 1075
Table 9-242—STA Role subfield values .................................................................................................. 1077
Table 9-243—Activity field values .......................................................................................................... 1081
Table 9-244—Session Type subfield values ............................................................................................. 1083
Table 9-245—DTP Report element format ............................................................................................... 1084
Table 9-246—MMS Element Owner subfield definition .......................................................................... 1090
Table 9-247—Single AID subfield definition .......................................................................................... 1091
Table 9-248—LLC Header Copy field size............................................................................................... 1092
Table 9-249—Subfields of the VHT Capabilities Information field ......................................................... 1096
Table 9-250—Setting of the Supported Channel Width Set subfield and Extended NSS BW Support
subfield at a STA transmitting the VHT Capabilities Information field ....................... 1099
Table 9-251—Supported VHT-MCS and NSS Set subfields .................................................................. 1100
Table 9-252—VHT Operation Information subfields ............................................................................... 1103
85
Copyright © 2016 IEEE. All rights reserved.
Table 9-253—BSS bandwidth when the VHT Operation Information field Channel Width subfield
is 1.................................................................................................................................. 1104
Table 9-254—Meaning of Local Maximum Transmit Power Count subfield .......................................... 1107
Table 9-255—Definition of Local Maximum Transmit Power Unit Interpretation subfield .................... 1107
Table 9-256—Status Indication field values ............................................................................................. 1112
Table 9-257—Burst Duration field encoding ............................................................................................ 1112
Table 9-258— Format And Bandwidth field............................................................................................. 1114
Table 9-259—TVHT Operation Information subfields............................................................................. 1117
Table 9-260—Access Category subfield encoding ................................................................................... 1119
Table 9-261—Data Format subfield encoding .......................................................................................... 1119
Table 9-262—BA Window Size subfield encoding .................................................................................. 1120
Table 9-263—General TLV format ........................................................................................................... 1122
Table 9-264—Device Class field definition .............................................................................................. 1123
Table 9-265—Device Identification Information field definition ............................................................. 1123
Table 9-266—Device Location Information field definition .................................................................... 1123
Table 9-267—Channel Schedule Descriptor Tuple attribute definition .................................................... 1124
Table 9-268—Channel Schedule Descriptor Value fields ........................................................................ 1124
Table 9-269—WSM information values ................................................................................................... 1125
Table 9-270—WSM Information Value fields .......................................................................................... 1126
Table 9-271—ANQP-element definitions ................................................................................................. 1127
Table 9-272—Network Authentication Type Indicator definitions .......................................................... 1131
Table 9-273—IPv6 Address field values................................................................................................... 1133
Table 9-274—IPv4 Address field values................................................................................................... 1134
Table 9-275—Authentication Parameter types.......................................................................................... 1136
Table 9-276—Authentication Parameter format for the Expanded EAP method ..................................... 1137
Table 9-277—Vendor Specific Authentication Parameters ...................................................................... 1137
Table 9-278—Advice of Charge Type field values................................................................................... 1142
Table 9-279—Local Content State values ................................................................................................. 1143
Table 9-280—RLQP-element definitions.................................................................................................. 1145
Table 9-281—Reason Result Code field values ........................................................................................ 1146
Table 9-282—Reason Result Code field values ........................................................................................ 1148
Table 9-283—Encoding of BeamLink Maintenance Unit Index............................................................... 1154
Table 9-284—The Beamformed Link Maintenance negotiation............................................................... 1155
Table 9-285—Spectrum Management Action field values ....................................................................... 1155
Table 9-286—QoS Action field values ..................................................................................................... 1158
Table 9-287—Encoding of the ADDTS Request frame variant................................................................ 1159
Table 9-288—Encoding of the ADDTS Response frame variant ............................................................. 1159
Table 9-289—Basic ADDTS Request frame variant Action field format................................................. 1159
Table 9-290—DMG ADDTS Request frame variant Action field format ............................................... 1160
Table 9-291—Basic ADDTS Response frame variant Action field format .............................................. 1162
Table 9-292—DMG ADDTS Response frame variant Action field format ............................................. 1163
Table 9-293—DELTS frame Action field format ..................................................................................... 1164
Table 9-294—Schedule frame Action field format ................................................................................... 1164
Table 9-295—QoS Map Configure frame Action field format ................................................................. 1165
Table 9-296—ADDTS Reserve Request frame Action field format......................................................... 1165
Table 9-297—ADDTS Reserve Response frame Action field format ...................................................... 1166
Table 9-298—DLS Action field values ..................................................................................................... 1166
Table 9-299—DLS Request frame Action field format ............................................................................ 1167
Table 9-300—DLS Response frame Action field format .......................................................................... 1168
Table 9-301—DLS Teardown frame Action field format ......................................................................... 1169
Table 9-302—Block Ack Action field values ........................................................................................... 1169
Table 9-303—ADDBA Request frame Action field format...................................................................... 1170
Table 9-304—ADDBA Response frame Action field format ................................................................... 1171
Table 9-305—DELBA frame Action field format .................................................................................... 1172
86
Copyright © 2016 IEEE. All rights reserved.
Table 9-306—Radio Measurement Action field values ............................................................................ 1173
Table 9-307—Public Action field values .................................................................................................. 1177
Table 9-308—20/40 BSS Coexistence Management frame Action field format ...................................... 1178
Table 9-309—Optional subelement IDs for Measurement Pilot frame .................................................... 1180
Table 9-310—Reason Result Code field values ........................................................................................ 1181
Table 9-311—Reason Result Code field values ........................................................................................ 1181
Table 9-312—Reason Result Code field values ........................................................................................ 1185
Table 9-313—GAS Initial Request Action field format............................................................................ 1186
Table 9-314—GAS Initial Response Action field format ......................................................................... 1187
Table 9-315—GAS Comeback Request Action field format .................................................................... 1189
Table 9-316—GAS Comeback Response Action field format.................................................................. 1189
Table 9-317—TDLS Discovery Response Action field format ................................................................ 1190
Table 9-318—Location Parameters Element field for Location Track Notification frame....................... 1192
Table 9-319—QLoad Request frame Action field format......................................................................... 1193
Table 9-320—QLoad Report frame Action field format........................................................................... 1194
Table 9-321—Public Key Frame Usage field values ................................................................................ 1196
Table 9-322—Reason Result Code field values ....................................................................................... 1198
Table 9-323—Channel Schedule Management Mode field values ........................................................... 1198
Table 9-324—QAB Request frame Action field format ........................................................................... 1205
Table 9-325—QAB Response frame Action field format ......................................................................... 1206
Table 9-326—FT Action field values ........................................................................................................ 1206
Table 9-327—FT Request frame body ...................................................................................................... 1207
Table 9-328—FT Response frame body.................................................................................................... 1208
Table 9-329—FT Confirm frame body ..................................................................................................... 1208
Table 9-330—FT Ack frame body ............................................................................................................ 1209
Table 9-331—SA Query Action field values ............................................................................................ 1210
Table 9-332—Public Action field values defined for Protected Dual of Public Action frames................ 1211
Table 9-333—HT Action field values ....................................................................................................... 1212
Table 9-334—Notify Channel Width frame Action field format .............................................................. 1213
Table 9-335—SM Power Save frame Action field format ........................................................................ 1213
Table 9-336—PSMP frame Action field format........................................................................................ 1214
Table 9-337—Set PCO Phase frame Action field format.......................................................................... 1214
Table 9-338—CSI frame Action field format............................................................................................ 1214
Table 9-339—Noncompressed Beamforming frame Action field format................................................. 1215
Table 9-340—Compressed Beamforming frame Action field format....................................................... 1215
Table 9-341—Antenna Selection Indices Feedback frame Action field format........................................ 1216
Table 9-342—TDLS Action field values................................................................................................... 1216
Table 9-343—Information for TDLS Setup Request Action field ............................................................ 1217
Table 9-344—Information for TDLS Setup Response Action field.......................................................... 1218
Table 9-345—Information for TDLS Setup Confirm Action field ........................................................... 1220
Table 9-346—Information for TDLS Teardown Action field................................................................... 1221
Table 9-347—Information for TDLS Peer Traffic Indication Action field............................................... 1221
Table 9-348—Information for TDLS Channel Switch Request Action field............................................ 1222
Table 9-349—Information for TDLS Channel Switch Response Action field ......................................... 1223
Table 9-350—Information for TDLS Peer PSM Request Action field ..................................................... 1223
Table 9-351—Information for TDLS Peer PSM Response Action field................................................... 1223
Table 9-352—Information for TDLS Peer Traffic Response Action field................................................ 1224
Table 9-353—Information for TDLS Discovery Request Action field..................................................... 1225
Table 9-354—WNM Action field values .................................................................................................. 1225
Table 9-355—Location Parameters Element field for Location Configuration Request frame................ 1228
Table 9-356—Location Parameters Element field for Location Configuration Response frame ............. 1229
Table 9-357—BTM status code definitions............................................................................................... 1233
Table 9-358—Optional subelement IDs for WNM Sleep Mode parameters ............................................ 1239
Table 9-359—QoS Traffic Capability Flags definition ............................................................................. 1241
87
Copyright © 2016 IEEE. All rights reserved.
Table 9-360—WNM notification type ...................................................................................................... 1244
Table 9-361—Optional subelement IDs for WNM Notification Request ................................................. 1245
Table 9-362—WNM Notification Response Status .................................................................................. 1245
Table 9-363—Unprotected WNM Action field values.............................................................................. 1246
Table 9-364—Self-protected Action field values ...................................................................................... 1248
Table 9-365—Mesh Peering Open frame Action field format .................................................................. 1248
Table 9-366—Mesh Peering Confirm frame Action field format ............................................................. 1250
Table 9-367—Mesh Peering Close frame Action field format.................................................................. 1251
Table 9-368—Mesh Group Key Inform frame Action field format .......................................................... 1252
Table 9-369—Mesh Group Key Acknowledge frame Action field format............................................... 1252
Table 9-370—Mesh Action field values.................................................................................................... 1253
Table 9-371—Mesh Link Metric Report frame Action field format......................................................... 1253
Table 9-372—HWMP Mesh Path Selection frame Action field format ................................................... 1254
Table 9-373—Gate Announcement frame Action field format................................................................. 1255
Table 9-374—Congestion Control Notification frame Action field format .............................................. 1255
Table 9-375—MCCA Setup Request frame Action field format .............................................................. 1256
Table 9-376—MCCA Setup Reply frame Action field format ................................................................. 1256
Table 9-377—MCCA Advertisement Request frame Action field format................................................ 1256
Table 9-378—MCCA Advertisement frame Action field format ............................................................. 1257
Table 9-379—MCCA Teardown frame Action field format..................................................................... 1257
Table 9-380—TBTT Adjustment Request frame Action field format ...................................................... 1258
Table 9-381—TBTT Adjustment Response frame Action field format.................................................... 1258
Table 9-382—Multihop Action field values.............................................................................................. 1259
Table 9-383—Proxy Update frame Action field format............................................................................ 1259
Table 9-384—Proxy Update Confirmation frame Action field format ..................................................... 1260
Table 9-385—Robust AV streaming Robust Action field values ............................................................. 1260
Table 9-386—DMG Action field values .................................................................................................. 1263
Table 9-387—Power Save Configuration Request frame Action field format ......................................... 1264
Table 9-388—Power Save Configuration Response frame Action field format ....................................... 1264
Table 9-389—Information Request frame Action field format................................................................. 1265
Table 9-390—Information Response frame Action field format .............................................................. 1266
Table 9-391—Handover Request frame Action field format .................................................................... 1266
Table 9-392—Handover Response frame Action field format.................................................................. 1267
Table 9-393—Relay Search Request frame Action field format............................................................... 1268
Table 9-394—Relay Search Response frame Action field format ........................................................... 1269
Table 9-395—Multi-relay Channel Measurement Request frame Action field format............................. 1269
Table 9-396—Multi-relay Channel Measurement Report frame Action field format............................... 1270
Table 9-397—RLS Request frame Action field format ............................................................................ 1271
Table 9-398—RLS Response frame Action field format .......................................................................... 1272
Table 9-399—RLS Announcement frame Action field format ................................................................. 1273
Table 9-400—RLS Teardown frame Action field format ......................................................................... 1273
Table 9-401—Relay Ack Request frame Action field format .................................................................. 1274
Table 9-402—Relay Ack Response frame Action field format................................................................. 1274
Table 9-403—TPA Request frame Action field format ............................................................................ 1275
Table 9-404—TPA Response frame Action field format .......................................................................... 1276
Table 9-405—TPA Report frame Action field format .............................................................................. 1276
Table 9-406—ROC Request frame Action field format............................................................................ 1277
Table 9-407—ROC Response frame Action field format ......................................................................... 1277
Table 9-408—FST Action field values...................................................................................................... 1278
Table 9-409—FST Setup Request frame Action field format .................................................................. 1278
Table 9-410—FST Setup Response frame Action field format ................................................................ 1279
Table 9-411—FST Teardown frame Action field format.......................................................................... 1280
Table 9-412—FST Ack Request frame Action field format ..................................................................... 1281
Table 9-413—FST Ack Response frame Action field format ................................................................... 1281
88
Copyright © 2016 IEEE. All rights reserved.
Table 9-414—On-channel Tunnel Request frame Action field format ..................................................... 1282
Table 9-415—Unprotected DMG Action field values .............................................................................. 1283
Table 9-416—Announce frame Action field format ................................................................................ 1283
Table 9-417—BRP frame Action field format .......................................................................................... 1284
Table 9-418—VHT Action field values .................................................................................................... 1285
Table 9-419—VHT Compressed Beamforming frame Action field format.............................................. 1286
Table 9-420—Group ID Management frame Action field format............................................................. 1286
Table 9-421—Operating Mode Notification frame Action field format ................................................... 1287
Table 9-422— MPDU delimiter fields (non-DMG).................................................................................. 1289
Table 9-423—MPDU delimiter fields (DMG) .......................................................................................... 1289
Table 9-424—A-MPDU contexts .............................................................................................................. 1291
Table 9-425—A-MPDU contents in the data enabled immediate response context ................................. 1292
Table 9-426—A-MPDU contents in the data enabled no immediate response context ............................ 1293
Table 9-427—A-MPDU contents in the PSMP context ............................................................................ 1293
Table 9-428—A-MPDU contents MPDUs in the control response context.............................................. 1294
Table 9-429—A-MPDU contents in the VHT single MPDU context....................................................... 1294
Table 10-1—UP-to-AC mappings ............................................................................................................. 1298
Table 10-2—Dual CTS rules ..................................................................................................................... 1314
Table 10-3—Transmitter sequence number spaces ................................................................................... 1319
Table 10-4—Receiver caches .................................................................................................................. 1321
Table 10-5—Determination of the EstimatedAckTxTime based on properties of the PPDU causing
the EIFS ......................................................................................................................... 1333
Table 10-6—Modulation classes .............................................................................................................. 1359
Table 10-7—Non-HT reference rate.......................................................................................................... 1360
Table 10-8—Example of rate selection for VHT PPDUs.......................................................................... 1362
Table 10-9—Settings for the TXVECTOR parameters GROUP_ID and PARTIAL_AID ...................... 1374
Table 10-10—Channels indicated idle by the channel-list parameter ....................................................... 1383
Table 10-11—Modulation classes eligible for TXOP termination............................................................ 1389
Table 10-12—Rate and modulation class of a final transmission in a TXOP ........................................... 1390
Table 10-13—Protection requirements for HT Protection field values nonmember protection mode
and non-HT mixed mode ............................................................................................... 1441
Table 10-14—Applicable HT protection mechanisms .............................................................................. 1442
Table 10-15—STA type requirements for transmit beamforming with implicit feedback ....................... 1469
Table 10-16—Transmit beamforming support required with implicit feedback....................................... 1470
Table 10-17—Rules for HT beamformee immediate feedback transmission responding to
non-NDP sounding ........................................................................................................ 1479
Table 10-18—Rules for HT beamformee immediate feedback transmission responding to
NDP sounding................................................................................................................ 1479
Table 10-19—Mandatory and optional procedures in the Beamforming mechanism .............................. 1534
Table 11-1—Bufferable/nonbufferable classification of MMPDUs ......................................................... 1600
Table 11-2—Power states for an awake BI .............................................................................................. 1631
Table 11-3—Power states for a doze BI .................................................................................................... 1632
Table 11-4—Types of block ack agreement based on capabilities and ADDBA conditions for
non-DMG STAs............................................................................................................. 1681
Table 11-5—Types of block ack agreement based on capabilities and ADDBA conditions for
DMG STAs .................................................................................................................... 1682
Table 11-6—ReasonCode values for DLS teardown ................................................................................ 1689
Table 11-7—Allowed measurement requests............................................................................................ 1698
Table 11-8—Measurement Duration ......................................................................................................... 1710
Table 11-9—Allowed measurement requests............................................................................................ 1712
Table 11-10—Measurement pilot activated definition .............................................................................. 1735
Table 11-11—DSE STA attributes ............................................................................................................ 1740
Table 11-12—A-MSDU STA behavior for RSN associations ................................................................. 1763
Table 11-13—STA recovery procedures for a changed retransmission policy ........................................ 1820
89
Copyright © 2016 IEEE. All rights reserved.
Table 11-14—Non-AP STA recovery procedures for a changed delivery method................................... 1821
Table 11-15—ANQP usage ....................................................................................................................... 1833
Table 11-16—ESR and UESA field settings ............................................................................................. 1841
Table 11-17—Default QMF policy .......................................................................................................... 1845
Table 11-18—QMF policy description for valid combination of optional fields in the QACM field ...... 1851
Table 11-19—Contents of HCCA TXOP Response frame ....................................................................... 1859
Table 11-20—Exceptions for the initiator ................................................................................................ 1878
Table 11-21—FST status at state transition............................................................................................... 1880
Table 11-22—Setting of Single AID field................................................................................................. 1887
Table 11-23—DMG MAC sublayer attribute values ................................................................................ 1896
Table 11-24—VHT BSS bandwidth.......................................................................................................... 1897
Table 11-25—Setting of Channel Center Frequency Segment 0, Channel Center Frequency
Segment 1, and Channel Center Frequency Segment 2 subfields ................................. 1898
Table 11-26—Extended NSS channel width ............................................................................................. 1899
Table 11-27—TVHT BSS bandwidth ....................................................................................................... 1907
Table 12-1—AAD length .......................................................................................................................... 1970
Table 12-2—Robust management frame selection in an infrastructure BSS ............................................ 1992
Table 12-3—Robust management frame selection in an IBSS ................................................................. 1994
Table 12-4—Cipher suite key lengths ....................................................................................................... 2021
Table 12-5—Key RSC field ...................................................................................................................... 2022
Table 12-6—KDE...................................................................................................................................... 2023
Table 12-7—SMK error types ................................................................................................................... 2025
Table 12-8—Integrity and key-wrap algorithms ....................................................................................... 2027
Table 13-1—FT authentication elements .................................................................................................. 2110
Table 13-2—Remote Request/Response Payload format.......................................................................... 2126
Table 13-3—Resource types and resource descriptor definitions ............................................................. 2127
Table 14-1—State variables for mesh STAs ............................................................................................. 2137
Table 14-2—MPM finite state machine .................................................................................................... 2144
Table 14-3—AMPE finite state machine................................................................................................... 2155
Table 14-4—Airtime cost constants .......................................................................................................... 2162
Table 14-5—Parameters of the airtime link metric for extensible path selection framework................... 2163
Table 14-6—Precursor and next hop examples (forward path)................................................................. 2165
Table 14-7—Precursor and next hop examples (reverse path).................................................................. 2166
Table 14-8—Parameters of HWMP for extensible path selection framework .......................................... 2168
Table 14-9—Data for creation and update of forwarding information due to PREQ element and
PREP element ................................................................................................................ 2172
Table 14-10—Contents of a PREQ element in Case A ............................................................................. 2174
Table 14-11—Contents of a PREQ element in Case B ............................................................................. 2175
Table 14-12—Contents of a PREQ element in Case C ............................................................................. 2176
Table 14-13—Contents of a PREQ element in Case D ............................................................................. 2177
Table 14-14—Contents of a PREQ element in Case E1 ........................................................................... 2178
Table 14-15—Contents of a PREQ element in Case E2 ........................................................................... 2179
Table 14-16—Contents of a PREQ element in Case E3 ........................................................................... 2180
Table 14-17—Contents of a PREP element in Case A.............................................................................. 2184
Table 14-18—Contents of a PREP element in Case B .............................................................................. 2184
Table 14-19—Contents of a PREP element in Case C .............................................................................. 2185
Table 14-20—Contents of a PREP element in Case D.............................................................................. 2186
Table 14-21—Contents of a PERR element in Case A ............................................................................. 2188
Table 14-22—Contents of a PERR element in Case B ............................................................................. 2189
Table 14-23—Contents of a PERR element in Case C ............................................................................. 2190
Table 14-24—Contents of a PERR element in Case D ............................................................................. 2191
Table 14-25—Contents of a RANN element in Case A ............................................................................ 2193
Table 14-26—Contents of a RANN element in Case B ............................................................................ 2194
Table 14-27—Contents of a GANN element in Case A............................................................................ 2197
90
Copyright © 2016 IEEE. All rights reserved.
Table 14-28—Contents of a GANN element in Case B ............................................................................ 2197
Table 14-29—Contents of a PXU element ................................................................................................ 2202
Table 14-30—Contents of a PXUC element ............................................................................................. 2203
Table 14-31—Peer-specific mesh power management mode definition................................................... 2216
Table 14-32—Mesh peer service period triggering with RSPI and EOSP subfield combinations in
peer trigger frame........................................................................................................... 2222
Table 15-1—TXVECTOR parameters ...................................................................................................... 2225
Table 15-2—RXVECTOR parameters ...................................................................................................... 2226
Table 15-3—TXSTATUS parameters ....................................................................................................... 2228
Table 15-4—MIB attribute default values/ranges .................................................................................... 2237
Table 15-5—DSSS PHY characteristics.................................................................................................... 2238
Table 15-6—DSSS PHY frequency channel plan ..................................................................................... 2239
Table 15-7—1 Mb/s DBPSK encoding table ............................................................................................ 2239
Table 15-8—2 Mb/s DQPSK encoding table ............................................................................................ 2240
Table 16-1—SERVICE field definitions ................................................................................................... 2251
Table 16-2—Example of LENGTH calculations for CCK ....................................................................... 2253
Table 16-3—MIB attribute default values/ranges ..................................................................................... 2262
Table 16-4—HR/DSSS PHY characteristics ............................................................................................. 2263
Table 16-5—Parameter vectors ................................................................................................................. 2264
Table 16-6—HR/DSSS PHY frequency channel plan .............................................................................. 2265
Table 16-7—1 Mb/s DBPSK encoding table ............................................................................................ 2266
Table 16-8—2 Mb/s DQPSK encoding table ............................................................................................ 2267
Table 16-9—DQPSK encoding table ........................................................................................................ 2268
Table 16-10—5.5 Mb/s CCK encoding table ............................................................................................ 2268
Table 16-11—QPSK encoding table ......................................................................................................... 2269
Table 17-1—TXVECTOR parameters ...................................................................................................... 2278
Table 17-2—RXVECTOR parameters ...................................................................................................... 2280
Table 17-3—TXSTATUS parameters ....................................................................................................... 2282
Table 17-4—Modulation-dependent parameters ....................................................................................... 2285
Table 17-5—Timing-related parameters ................................................................................................... 2285
Table 17-6—Contents of the SIGNAL field.............................................................................................. 2290
Table 17-7—Contents of the first 7 bits of the scrambling sequence........................................................ 2293
Table 17-8—TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values ................................... 2294
Table 17-9—RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values................................... 2294
Table 17-10—DYN_BANDWIDTH_IN_NON_HT values ..................................................................... 2294
Table 17-11—Modulation-dependent normalization factor KMOD ........................................................... 2298
Table 17-12—BPSK encoding table.......................................................................................................... 2300
Table 17-13—QPSK encoding table ......................................................................................................... 2300
Table 17-14—16-QAM encoding table ..................................................................................................... 2300
Table 17-15—64-QAM encoding table ..................................................................................................... 2300
Table 17-16—Major parameters of the OFDM PHY ................................................................................ 2303
Table 17-17—Allowed relative constellation error versus data rate ......................................................... 2308
Table 17-18—Receiver performance requirements................................................................................... 2310
Table 17-19—Optional enhanced receiver performance requirements ..................................................... 2311
Table 17-20—MIB attribute default values/ranges ................................................................................... 2318
Table 17-21—OFDM PHY characteristics................................................................................................ 2321
Table 18-1—TXVECTOR parameters ...................................................................................................... 2324
Table 18-2—TXSTATUS parameters ....................................................................................................... 2324
Table 18-3—RXVECTOR parameters ...................................................................................................... 2325
Table 18-4—MIB attribute default values/ranges ..................................................................................... 2330
Table 18-5—ERP characteristics............................................................................................................... 2332
Table 19-1—TXVECTOR and RXVECTOR parameters......................................................................... 2336
Table 19-2—Interpretation of FORMAT, CH_BANDWIDTH, and CH_OFFSET parameters .............. 2343
Table 19-3—Mapping of the HT PHY parameters for NON_HT operation............................................. 2344
91
Copyright © 2016 IEEE. All rights reserved.
Table 19-4—TXSTATUS parameter......................................................................................................... 2346
Table 19-5—Elements of the HT PPDU ................................................................................................... 2347
Table 19-6—Timing-related constants ...................................................................................................... 2354
Table 19-7—Frequently used parameters.................................................................................................. 2355
Table 19-8—Value of tone scaling factor ................................................................................................. 2358
Table 19-9—Cyclic shift for non-HT portion of packet............................................................................ 2360
Table 19-10—Cyclic shift values of HT portion of packet ....................................................................... 2363
Table 19-11—HT-SIG fields ..................................................................................................................... 2364
Table 19-12—Determining the number of space-time streams................................................................. 2369
Table 19-13—Number of HT-DLTFs required for data space-time streams ............................................ 2369
Table 19-14—Number of HT-ELTFs required for extension spatial streams........................................... 2370
Table 19-15—LDPC parameters ............................................................................................................... 2378
Table 19-16—PPDU encoding parameters................................................................................................ 2379
Table 19-17—Number of rows and columns in the interleaver ................................................................ 2383
Table 19-18—Constellation mapper output to spatial mapper input for STBC ........................................ 2385
Table 19-19—Pilot values for 20 MHz transmission ................................................................................ 2386
Table 19-20—Pilots values for 40 MHz transmission (excluding MCS 32)............................................. 2386
Table 19-21—Maximum available space-time streams ............................................................................ 2402
Table 19-22—Allowed relative constellation error versus constellation size and coding rate.................. 2408
Table 19-23—Receiver minimum input level sensitivity.......................................................................... 2410
Table 19-24—HT PHY MIB attributes ..................................................................................................... 2420
Table 19-25—HT PHY characteristics...................................................................................................... 2425
Table 19-26—Symbols used in MCS parameter tables............................................................................. 2427
Table 19-27—MCS parameters for mandatory 20 MHz, NSS = 1, NES = 1 ............................................. 2427
Table 19-28—MCS parameters for optional 20 MHz, NSS = 2, NES = 1, EQM....................................... 2428
Table 19-29—MCS parameters for optional 20 MHz, NSS = 3, NES = 1, EQM....................................... 2428
Table 19-30—MCS parameters for optional 20 MHz, NSS = 4, NES = 1, EQM....................................... 2429
Table 19-31—MCS parameters for optional 40 MHz, NSS = 1, NES = 1 ................................................. 2429
Table 19-32—MCS parameters for optional 40 MHz, NSS = 2, NES = 1, EQM....................................... 2430
Table 19-33—MCS parameters for optional 40 MHz, NSS = 3, EQM ..................................................... 2430
Table 19-34—MCS parameters for optional 40 MHz, NSS = 4, EQM ..................................................... 2431
Table 19-35—MCS parameters for optional 40 MHz MCS 32 format, NSS = 1, NES = 1 ....................... 2431
Table 19-36—MCS parameters for optional 20 MHz, NSS = 2, NES = 1, UEQM.................................... 2431
Table 19-37—MCS parameters for optional 20 MHz, NSS = 3, NES = 1, UEQM.................................... 2432
Table 19-38—MCS parameters for optional 20 MHz, NSS = 4, NES = 1, UEQM.................................... 2432
Table 19-39—MCS parameters for optional 40 MHz, NSS = 2, NES = 1, UEQM.................................... 2433
Table 19-40—MCS parameters for optional 40 MHz, NSS = 3, UEQM................................................... 2434
Table 19-41—MCS parameters for optional 40 MHz, NSS = 4, UEQM................................................... 2434
Table 20-1—TXVECTOR and RXVECTOR parameters ........................................................................ 2437
Table 20-2—TXSTATUS parameters ....................................................................................................... 2439
Table 20-3—Receiver sensitivity .............................................................................................................. 2441
Table 20-4—Timing-related parameters ................................................................................................... 2443
Table 20-5—Frequently used parameters.................................................................................................. 2444
Table 20-6—Rate 1/2 LDPC code matrix (Each nonblank element i in the table is the cyclic
permutation matrix Pi of size Z × Z; blank entries represent the zero matrix
of size Z × Z) ................................................................................................................. 2450
Table 20-7—Rate 5/8 LDPC code matrix (Each nonblank element i in the table is the cyclic
permutation matrix Pi of size Z × Z; blank entries represent the zero matrix
of size Z × Z) ................................................................................................................. 2450
Table 20-8—Rate 3/4 LDPC code matrix (Each nonblank element i in the table is the cyclic
permutation matrix Pi of size Z × Z; blank entries represent the zero matrix
of size Z × Z) ................................................................................................................. 2450
92
Copyright © 2016 IEEE. All rights reserved.
Table 20-9—Rate 13/16 LDPC code matrix (Each nonblank element i in the table is the cyclic
permutation matrix Pi of size Z × Z; blank entries represent the zero matrix
of size Z × Z) ................................................................................................................. 2451
Table 20-10—DMG control mode modulation and coding scheme.......................................................... 2452
Table 20-11—DMG control mode header fields ....................................................................................... 2453
Table 20-12—DMG control mode EVM requirements............................................................................. 2456
Table 20-13—DMG OFDM mode header fields ...................................................................................... 2457
Table 20-14—DMG OFDM mode modulation and coding schemes ....................................................... 2459
Table 20-15—LDPC code rates................................................................................................................. 2460
Table 20-16—DMG OFDM mode EVM requirements ........................................................................... 2467
Table 20-17—DMG SC mode header fields ............................................................................................ 2469
Table 20-18—Parameters for computing Length field value in SC header when Extended SC MCS
Indication field is set to 1............................................................................................... 2471
Table 20-19—DMG SC mode modulation and coding schemes .............................................................. 2471
Table 20-20—LDPC code rates................................................................................................................. 2473
Table 20-21—Values of NCBPB .............................................................................................................. 2478
Table 20-22—DMG SC mode EVM requirements ................................................................................... 2479
Table 20-23—DMG low-power SC mode modulation and coding schemes ............................................ 2481
Table 20-24—Zero filling for DMG SC mode BRP packets .................................................................... 2491
Table 20-25—The sequence Ga128(n)...................................................................................................... 2493
Table 20-26—The sequence Gb128(n)...................................................................................................... 2493
Table 20-27—The sequence Ga64(n)........................................................................................................ 2493
Table 20-28—The sequence Gb64(n)........................................................................................................ 2493
Table 20-29—The sequence Ga32(n)........................................................................................................ 2493
Table 20-30—The sequence Gb32(n)........................................................................................................ 2493
Table 20-31—DMG PHY MIB attribute default values ........................................................................... 2494
Table 20-32—DMG PHY characteristics.................................................................................................. 2495
Table 21-1—TXVECTOR and RXVECTOR parameters ........................................................................ 2499
Table 21-2—Interpretation of FORMAT, NON_HT_MODULATION, CH_BANDWIDTH, and
CH_OFFSET parameters .............................................................................................. 2508
Table 21-3—Mapping of VHT PHY parameters for NON_HT operation................................................ 2512
Table 21-4—Fields of the VHT PPDU...................................................................................................... 2514
Table 21-5—Timing-related constants ...................................................................................................... 2528
Table 21-6—Frequently used parameters ................................................................................................. 2529
Table 21-7—Center frequency of the portion of the PPDU transmitted in frequency segment iSeg ....... 2534
Table 21-8—Tone scaling factor and guard interval duration values for PHY fields ............................... 2536
Table 21-9—CH_BANDWIDTH and ...................................................................................................... 2537
Table 21-10—Cyclic shift values for L-STF, L-LTF, L-SIG, and VHT-SIG-A fields of the PPDU........ 2538
Table 21-11—Cyclic shift values for the VHT modulated fields of a PPDU ........................................... 2542
Table 21-12—Fields in the VHT-SIG-A field .......................................................................................... 2544
Table 21-13—Number of VHT-LTFs required for different numbers of space-time streams .................. 2548
Table 21-14—Fields in the VHT-SIG-B field ........................................................................................... 2552
Table 21-15—VHT-SIG-B bits (before Tail field) in NDP for various channel widths ........................... 2553
Table 21-16—SERVICE field ................................................................................................................... 2557
Table 21-17—Number of rows and columns in the interleaver ................................................................ 2564
Table 21-18— J(iSS) values ...................................................................................................................... 2565
Table 21-19—LDPC tone mapping distance for each bandwidth ............................................................. 2571
Table 21-20—Constellation mapper output to spatial mapper input for STBC ....................................... 2573
Table 21-21—Pilot values for 80 MHz transmission ................................................................................ 2575
Table 21-22—Fields to specify VHT channels ......................................................................................... 2581
Table 21-23—Maximum transmit spectral flatness deviations ................................................................. 2586
Table 21-24—Allowed relative constellation error versus constellation size and coding rate.................. 2588
Table 21-25—Receiver minimum input level sensitivity.......................................................................... 2591
Table 21-26—Minimum required adjacent and nonadjacent channel rejection levels.............................. 2592
93
Copyright © 2016 IEEE. All rights reserved.
Table 21-27—Conditions for CCA BUSY on the primary 20 MHz ......................................................... 2594
Table 21-28—VHT PHY MIB attributes ................................................................................................. 2603
Table 21-29—VHT PHY characteristics ................................................................................................... 2607
Table 21-30—VHT-MCSs for mandatory 20 MHz, NSS = 1 ................................................................... 2608
Table 21-31—VHT-MCSs for optional 20 MHz, NSS = 2 ....................................................................... 2609
Table 21-32—VHT-MCSs for optional 20 MHz, NSS = 3 ....................................................................... 2609
Table 21-33—VHT-MCSs for optional 20 MHz, NSS = 4 ....................................................................... 2610
Table 21-34—VHT-MCSs for optional 20 MHz, NSS = 5 ....................................................................... 2610
Table 21-35—VHT-MCSs for optional 20 MHz, NSS = 6 ....................................................................... 2611
Table 21-36—VHT-MCSs for optional 20 MHz, NSS = 7 ....................................................................... 2611
Table 21-37—VHT-MCSs for optional 20 MHz, NSS = 8 ....................................................................... 2612
Table 21-38—VHT-MCSs for mandatory 40 MHz, NSS = 1 ................................................................... 2612
Table 21-39—VHT-MCSs for optional 40 MHz, NSS = 2 ....................................................................... 2613
Table 21-40—VHT-MCSs for optional 40 MHz, NSS = 3 ....................................................................... 2613
Table 21-41—VHT-MCSs for optional 40 MHz, NSS = 4 ....................................................................... 2614
Table 21-42—VHT-MCSs for optional 40 MHz, NSS = 5 ....................................................................... 2614
Table 21-43—VHT-MCSs for optional 40 MHz, NSS = 6 ....................................................................... 2615
Table 21-44—VHT-MCSs for optional 40 MHz, NSS = 7 ....................................................................... 2615
Table 21-45—VHT-MCSs for optional 40 MHz, NSS = 8 ....................................................................... 2616
Table 21-46—VHT-MCSs for mandatory 80 MHz, NSS = 1 ................................................................... 2616
Table 21-47—VHT-MCSs for optional 80 MHz, NSS = 2 ....................................................................... 2617
Table 21-48—VHT-MCSs for optional 80 MHz, NSS = 3 ....................................................................... 2617
Table 21-49—VHT-MCSs for optional 80 MHz, NSS = 4 ....................................................................... 2618
Table 21-50—VHT-MCSs for optional 80 MHz, NSS = 5 ....................................................................... 2618
Table 21-51—VHT-MCSs for optional 80 MHz, NSS = 6 ....................................................................... 2619
Table 21-52—VHT-MCSs for optional 80 MHz, NSS = 7 ....................................................................... 2619
Table 21-53—VHT-MCSs for optional 80 MHz, NSS = 8 ....................................................................... 2620
Table 21-54—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 1.......................................... 2620
Table 21-55—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 2.......................................... 2621
Table 21-56—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 3.......................................... 2621
Table 21-57—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 4.......................................... 2622
Table 21-58—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 5.......................................... 2622
Table 21-59—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 6.......................................... 2623
Table 21-60—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 7.......................................... 2623
Table 21-61—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 8.......................................... 2624
Table 22-1—TXVECTOR and RXVECTOR parameters ........................................................................ 2628
Table 22-2—PPDU format as a function of CH_BANDWIDTH parameter ........................................... 2634
Table 22-3—Modulation-dependent parameters for Non-HT duplicate mode in TVWS band ................ 2635
Table 22-4—RATE field in L-SIG ............................................................................................................ 2635
Table 22-5—Timing-related constants in Non-HT PPDU ........................................................................ 2636
Table 22-6—Tone location in Non-HT PPDU .......................................................................................... 2637
Table 22-7—Fields of the VHT PPDU in TVWS bands........................................................................... 2638
Table 22-8—Timing-related parameters ................................................................................................... 2643
Table 22-9—Tone location ........................................................................................................................ 2643
Table 22-10—Center frequency of a PPDU transmitted in frequency segment iSeg ............................... 2646
Table 22-11—Tone scaling factor and guard interval duration values for PHY fields ............................. 2647
Table 22-12—Transmission mode and Gamma subk,m ........................................................................... 2647
Table 22-13—B0-B1 (BW) in TVHT-SIG-A1 ......................................................................................... 2649
Table 22-14—Number of rows and columns in the interleaver ................................................................ 2652
Table 22-15—LDPC Tone Mapping Distance for each transmission mode ............................................. 2652
Table 22-16—Parameters for Non-HT duplicate transmissions................................................................ 2654
Table 22-17—Fields to specify TVHT channels ....................................................................................... 2655
Table 22-18—Spectral mask frequency scaling factor for contiguous transmission ................................ 2657
Table 22-19—Spectral mask frequency scaling factor for TVHT_MODE_4N........................................ 2657
94
Copyright © 2016 IEEE. All rights reserved.
Table 22-20—Spectral mask frequency scaling factor for TVHT_MODE_2N........................................ 2658
Table 22-21—Maximum transmit spectral flatness deviations ................................................................. 2659
Table 22-22—Receiver minimum input level sensitivity.......................................................................... 2661
Table 22-23—Minimum required adjacent and nonadjacent channel rejection levels.............................. 2662
Table 22-24—Conditions for CCA BUSY on the primary channel .......................................................... 2663
Table 22-25—TVHT PHY characteristics ................................................................................................ 2665
Table 22-26—TVHT MCSs for TVHT_MODE_1, NSS = 1.................................................................... 2666
Table 22-27—TVHT MCSs for TVHT_MODE_1, NSS = 2.................................................................... 2667
Table 22-28—TVHT MCSs for TVHT_MODE_1, NSS = 3.................................................................... 2667
Table 22-29—TVHT MCSs for TVHT_MODE_1, NSS = 4.................................................................... 2668
Table 22-30—TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 1 .......................... 2668
Table 22-31—TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 2 .......................... 2669
Table 22-32—TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 3 .......................... 2669
Table 22-33—TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 4 .......................... 2670
Table 22-34—TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 1 .......................... 2670
Table 22-35—TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 2 .......................... 2671
Table 22-36—TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 3 .......................... 2671
Table 22-37—TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 4 .......................... 2672
Table D-1—Regulatory requirement list ................................................................................................... 3269
Table D-2—Behavior limits ..................................................................................................................... 3270
Table D-3—Maximum STA transmit power classification for the 5.85–5.925 GHz band in the
United States .................................................................................................................. 3271
Table D-4—Spectrum mask data for 5 MHz channel spacing .................................................................. 3272
Table D-5—Spectrum mask data for 10 MHz channel spacing ................................................................ 3272
Table D-6—Spectrum mask data for 20 MHz channel spacing ................................................................ 3273
Table E-1—Operating classes in the United States ................................................................................... 3276
Table E-2—Operating classes in Europe................................................................................................... 3278
Table E-3—Operating classes in Japan ..................................................................................................... 3279
Table E-4—Global operating classes ........................................................................................................ 3283
Table E-5—Operating classes in China .................................................................................................... 3286
Table E-6—DSE timer limits .................................................................................................................... 3288
Table E-7—TVWS GDD timer limits ....................................................................................................... 3290
Table E-8—Device Identification Information Value fields ..................................................................... 3290
Table E-9—WSM Information Value fields ............................................................................................. 3291
Table E-10—TVWS GDD timer limits ..................................................................................................... 3292
Table F-1—Matrix prototypes for codeword block length n = 648 bits, subblock size is Z = 27 bits...... 3293
Table F-2—Matrix prototypes for codeword block length n = 1296 bits, subblock size is Z = 54 bits.... 3294
Table F-3—Matrix prototypes for codeword block length n = 1944 bits, subblock size is Z = 81 bits.... 3295
Table G-1—Attributes applicable to frame exchange sequence definition ............................................... 3296
Table H-1—Payload Type field values ..................................................................................................... 3311
Table I-1—The message for the BCC example......................................................................................... 3313
Table I-2—Frequency domain representation of the short sequences....................................................... 3314
Table I-3—One period of IFFT of the short sequences............................................................................. 3314
Table I-4—Time domain representation of the short sequence................................................................. 3315
Table I-5—Frequency domain representation of the long sequences........................................................ 3317
Table I-6—Time domain representation of the long sequence.................................................................. 3317
Table I-7—Bit assignment for SIGNAL field ........................................................................................... 3319
Table I-8—SIGNAL field bits after encoding ........................................................................................... 3320
Table I-9—SIGNAL field bits after interleaving ...................................................................................... 3320
Table I-10—Frequency domain representation of SIGNAL field............................................................. 3321
Table I-11—Frequency domain representation of SIGNAL field with pilots inserted ............................. 3321
Table I-12—Time domain representation of SIGNAL field ..................................................................... 3322
Table I-13—The DATA bits before scrambling........................................................................................ 3323
Table I-14—Scrambling sequence for seed 1011101................................................................................ 3325
95
Copyright © 2016 IEEE. All rights reserved.
Table I-15—The DATA bits after scrambling .......................................................................................... 3325
Table I-16—The BCC encoded DATA bits .............................................................................................. 3327
Table I-17—First permutation ................................................................................................................... 3330
Table I-18—Second permutation............................................................................................................... 3330
Table I-19—Interleaved bits of first DATA symbol ................................................................................. 3331
Table I-20—Frequency domain of first DATA symbol ............................................................................ 3333
Table I-21—Polarity of the pilot subcarriers ............................................................................................. 3333
Table I-22—Time domain representation of the short training sequence ................................................. 3334
Table I-23—Time domain representation of the long training sequence .................................................. 3335
Table I-24—Time domain representation of the SIGNAL field (1 symbol) ............................................. 3336
Table I-25—Time domain representation of the DATA field: symbol 1of 6............................................ 3337
Table I-26—Time domain representation of the DATA field: symbol 2 of 6........................................... 3338
Table I-27—Time domain representation of the DATA field: symbol 3 of 6........................................... 3339
Table I-28—Time domain representation of the DATA field: symbol 4 of 6........................................... 3339
Table I-29—Time domain representation of the DATA field: symbol 5 of 6........................................... 3340
Table I-30—Time domain representation of the DATA field: symbol 6 of 6........................................... 3341
Table I-31—Message for LDPC example 1 .............................................................................................. 3342
Table I-32—DATA bits for LDPC example 1 before scrambling ............................................................ 3343
Table I-33—DATA bits for LDPC example 1 after scrambling ............................................................... 3345
Table I-34—DATA bits for LDPC example 1 after insertion of shortening bits ...................................... 3346
Table I-35—DATA bits for LDPC example 1 after LDPC encoding ....................................................... 3348
Table I-36—DATA bits after puncturing and removal of shortening bits ................................................ 3351
Table I-37—Message for LDPC example 2 .............................................................................................. 3354
Table I-38—DATA bits for LDPC example 2 before scrambling ............................................................ 3355
Table I-39—DATA bits for LDPC example 2 after scrambling ............................................................... 3357
Table I-40—DATA bits for LDPC example 2 after insertion of shortening bits ...................................... 3359
Table I-41—DATA bits for LDPC example 2 after LDPC encoding ....................................................... 3361
Table I-42—DATA bits after removal of shortening bits and copying of repetition bits ......................... 3364
Table I-43—DMG control mode header settings ...................................................................................... 3369
Table I-44—DMG SC control header settings .......................................................................................... 3374
Table I-45—DMG OFDM mode header settings ...................................................................................... 3382
Table J-1—Test vectors for block function ............................................................................................... 3407
Table J-2—Test vectors for michael.......................................................................................................... 3407
Table J-3—Notation example .................................................................................................................... 3420
Table J-4—Sample plaintext MPDU ......................................................................................................... 3420
Table J-5—ARC4 encryption .................................................................................................................... 3421
Table J-6—Expanded MPDU after WEP encapsulation ........................................................................... 3421
Table J-7—Sample TKIP parameters ........................................................................................................ 3421
Table J-8—Sample plaintext and cipher text MPDUs, using parameter from Table J-7 .......................... 3422
Table J-9—RSN PRF Test Vector 1.......................................................................................................... 3423
Table J-10—RSN PRF Test Vector 2........................................................................................................ 3424
Table J-11—RSN PRF Test Vector 3........................................................................................................ 3424
Table J-12—RSN PRF Test Vector 4........................................................................................................ 3424
Table J-13—Sample values for pairwise key derivations ......................................................................... 3425
Table J-14—Sample derived CCMP-128 temporal key (TK) ................................................................... 3425
Table J-15—Sample derived PTK ............................................................................................................. 3426
Table K-1—Admissible TSPECs .............................................................................................................. 3446
Table K-2—SBA vs Packets/s ................................................................................................................... 3455
Table K-3—Table HCCA SBA for video streams .................................................................................... 3456
Table M-1—IEEE 802.11 integration service STT ................................................................................... 3468
Table M-2—Ethernet/IEEE 802.3 to IEEE 802.11 translation ................................................................. 3469
Table M-3—IEEE 802.11 to Ethernet/IEEE 802.3 translation ................................................................. 3469
Table Q-1—Destination URI payload ....................................................................................................... 3489
Table R-1—Mapping table of DSCP to 3GPP QoS information and EDCA ACs.................................... 3497
96
Copyright © 2016 IEEE. All rights reserved.
Table R-2—Example Enterprise DSCP to UP/AC mapping..................................................................... 3497
Table R-3—UP to DSCP range mapping example.................................................................................... 3498
Table R-4—SSPN Interface information or permission parameters ......................................................... 3499
Table S-1—Default parameters for mesh STAs that intend to operate in light or deep sleep mode
for mesh peerings........................................................................................................... 3512
97
Copyright © 2016 IEEE. All rights reserved.
Figures
Figure i—The evolution of numbering in IEEE Std 802.11.......................................................................... 12
Figure 4-1—BSSs ........................................................................................................................................ 185
Figure 4-2—DSs and APs............................................................................................................................ 186
Figure 4-3—ESS.......................................................................................................................................... 187
Figure 4-4—A representative signal intensity map ..................................................................................... 188
Figure 4-5—Collocated coverage areas....................................................................................................... 189
Figure 4-6—Connecting to other IEEE 802 LANs ..................................................................................... 189
Figure 4-7—CCSS and ECAPC .................................................................................................................. 191
Figure 4-8—SSPN interface service architecture ........................................................................................ 204
Figure 4-9—Example MBSS containing mesh STAs, mesh gates, APs, and portals ................................. 206
Figure 4-10—Example device consisting of mesh STA and AP STA to connect an MBSS and an
infrastructure BSS............................................................................................................ 207
Figure 4-11—MAC data transport over an MBSS ...................................................................................... 210
Figure 4-12—DMG relay in a DMG BSS ................................................................................................... 211
Figure 4-13—Multiple APs and multiple GDBs ......................................................................................... 213
Figure 4-14—IEEE 802.11 architecture for infrastructure BSS and PBSS................................................. 217
Figure 4-15—IEEE 802.11 Infrastructure model ........................................................................................ 218
Figure 4-16—IEEE 802.11 architecture (again).......................................................................................... 229
Figure 4-17—Logical architecture of an IBSS ............................................................................................ 230
Figure 4-18—Logical architecture of a PBSS ............................................................................................. 230
Figure 4-19—Portion of the ISO/IEC basic reference model covered in this standard............................... 232
Figure 4-20—Interworking reference model ............................................................................................... 232
Figure 4-21—ESS link illustration .............................................................................................................. 233
Figure 4-22—Reference model for supporting multiple MAC sublayers ................................................... 233
Figure 4-23—Reference model for a multi-band capable device (transparent FST)................................... 234
Figure 4-24—Reference model for a multi-band capable device (nontransparent FST)............................. 235
Figure 4-25—Establishing the IEEE 802.11 association............................................................................. 237
Figure 4-26—IEEE 802.1X EAP authentication ......................................................................................... 238
Figure 4-27—Establishing pairwise and group keys ................................................................................... 239
Figure 4-28—Delivery of subsequent group keys ....................................................................................... 240
Figure 4-29—Example using SAE authentication....................................................................................... 240
Figure 4-30—Sample 4-way handshakes in an IBSS .................................................................................. 242
Figure 4-31—Example using IEEE 802.1X authentication......................................................................... 243
Figure 4-32—Example of RSNA setup in a PBSS...................................................................................... 244
Figure 5-1—MAC data plane architecture .................................................................................................. 251
Figure 5-2—MAC data plane architecture (transparent FST) ..................................................................... 252
Figure 5-3—Role-specific behavior block for non-AP STA....................................................................... 253
Figure 5-4—Role-specific behavior block for AP....................................................................................... 253
Figure 5-5—Role-specific behavior block for mesh STA........................................................................... 254
Figure 5-6—Role-specific behavior block for mesh gate............................................................................ 254
Figure 6-1—GET and SET operations ........................................................................................................ 262
Figure 6-2—Layer management model ....................................................................................................... 318
Figure 6-3—Measurement request—accepted ............................................................................................ 319
Figure 6-4—Measurement request—rejected.............................................................................................. 320
Figure 6-5—TPC adaptation........................................................................................................................ 320
Figure 6-6—Channel switching................................................................................................................... 321
Figure 6-7—TDLS direct-link establishment .............................................................................................. 407
Figure 6-8—TDLS direct-link teardown ..................................................................................................... 412
Figure 6-9—TPU ......................................................................................................................................... 414
Figure 6-10—TDLS channel switching....................................................................................................... 417
Figure 6-11—TDLS peer PSM.................................................................................................................... 420
Figure 6-12—Event protocol exchange ....................................................................................................... 424
98
Copyright © 2016 IEEE. All rights reserved.
Figure 6-13—Diagnostic protocol exchange ............................................................................................... 428
Figure 6-14—Location configuration request and response protocol exchange ......................................... 432
Figure 6-15—Location track notification protocol exchange...................................................................... 435
Figure 6-16—Timing measurement primitives and timestamps capture..................................................... 437
Figure 6-17—Fine timing measurement primitives and timestamps capture.............................................. 441
Figure 6-18—BSS transition management request—accepted ................................................................... 447
Figure 6-19—FMS setup protocol exchange............................................................................................... 453
Figure 6-20—Collocated interference protocol exchange........................................................................... 457
Figure 6-21—TFS request and response exchange ..................................................................................... 461
Figure 6-22—WNM sleep mode request and response exchange ............................................................... 464
Figure 6-23—TIM broadcast setup protocol exchange ............................................................................... 468
Figure 6-24—QoS traffic capability update protocol exchange .................................................................. 472
Figure 6-25—Channel usage request protocol exchange ............................................................................ 474
Figure 6-26—DMS or GCR setup protocol exchange................................................................................. 478
Figure 6-27—Example SCS setup and termination protocol exchange ...................................................... 532
Figure 6-28—Operation of OCT ................................................................................................................. 549
Figure 6-29—MSGCF state machine .......................................................................................................... 593
Figure 7-1—DS architecture........................................................................................................................ 616
Figure 8-1—The channel-list parameter element for 40 MHz, 80 MHz, and 160 MHz channel width...... 630
Figure 8-2—The channel-list parameter element for 80+80 MHz channel width ...................................... 630
Figure 8-3—TVHT channel-list parameter element and channel bandwidth for TVHT_W,
TVHT_2W, and TVHT_W+W........................................................................................ 630
Figure 8-4—TVHT channel-list parameter element and channel bandwidth for TVHT_4W and
TVHT_2W+2W ............................................................................................................... 631
Figure 9-1—MAC frame format.................................................................................................................. 638
Figure 9-2—Frame Control field when Type is not equal to 1 or Subtype is not equal to 6 ...................... 638
Figure 9-3—Frame Control field when Type is equal to 1 and Subtype is equal to 6 ................................ 638
Figure 9-4—Sequence Control field............................................................................................................ 647
Figure 9-5—Sequence Number field in QMFs............................................................................................ 647
Figure 9-6—QoS AP PS Buffer State subfield............................................................................................ 652
Figure 9-7—Buffered AC subfield .............................................................................................................. 654
Figure 9-8—HT Control field...................................................................................................................... 654
Figure 9-9—HT Control Middle subfield of the HT variant HT Control field ........................................... 655
Figure 9-10—Link Adaptation Control subfield ........................................................................................ 655
Figure 9-11—MAI subfield ......................................................................................................................... 656
Figure 9-12—ASELC subfield .................................................................................................................... 657
Figure 9-13—HT Control Middle subfield of the VHT variant HT Control field ...................................... 659
Figure 9-14—MSI/STBC subfield when the Unsolicited MFB subfield is 1.............................................. 660
Figure 9-15—MFB subfield in the VHT variant HT Control field ............................................................. 660
Figure 9-16—Mesh Control field ................................................................................................................ 663
Figure 9-17—Mesh Flags subfield .............................................................................................................. 663
Figure 9-18—Mesh Address Extension subfield......................................................................................... 664
Figure 9-19—Frame Control field subfield values within Control frames ................................................. 669
Figure 9-20—RTS frame ............................................................................................................................. 670
Figure 9-21—CTS frame ............................................................................................................................. 670
Figure 9-22—Ack frame.............................................................................................................................. 671
Figure 9-23—PS-Poll frame ........................................................................................................................ 671
Figure 9-24—CF-End frame........................................................................................................................ 672
Figure 9-25—CF-End +CF-Ack frame........................................................................................................ 672
Figure 9-26—BlockAckReq frame.............................................................................................................. 673
Figure 9-27—BAR Control field ................................................................................................................. 673
Figure 9-28—Block Ack Starting Sequence Control subfield .................................................................... 674
Figure 9-29—BAR Information field (Multi-TID BlockAckReq).............................................................. 675
Figure 9-30—Per TID Info subfield ............................................................................................................ 675
99
Copyright © 2016 IEEE. All rights reserved.
Figure 9-31—BAR Information field format (GCR BlockAckReq)........................................................... 676
Figure 9-32—BlockAck frame .................................................................................................................... 676
Figure 9-33—BA Control field.................................................................................................................... 677
Figure 9-34—BA Information field (BlockAck)......................................................................................... 678
Figure 9-35—BA Information field (Compressed BlockAck) .................................................................... 679
Figure 9-36—BA Information field (Multi-TID BlockAck) ....................................................................... 679
Figure 9-37—BA Information field (Extended Compressed BlockAck) .................................................... 680
Figure 9-38—BA Information field format (GCR BlockAck) .................................................................... 680
Figure 9-39—Control Wrapper frame ......................................................................................................... 681
Figure 9-40—Poll frame format .................................................................................................................. 681
Figure 9-41—SPR frame format.................................................................................................................. 682
Figure 9-42—Grant frame format................................................................................................................ 682
Figure 9-43—DMG CTS frame format ....................................................................................................... 683
Figure 9-44—DMG DTS frame format....................................................................................................... 683
Figure 9-45—SSW frame format ................................................................................................................ 684
Figure 9-46—SSW-Feedback frame format................................................................................................ 684
Figure 9-47—SSW-Ack frame format ........................................................................................................ 685
Figure 9-48—Grant Ack frame format ........................................................................................................ 685
Figure 9-49—VHT NDP Announcement frame format .............................................................................. 685
Figure 9-50—Sounding Dialog Token field ................................................................................................ 686
Figure 9-51—STA Info field ....................................................................................................................... 686
Figure 9-52—Beamforming Report Poll frame format ............................................................................... 687
Figure 9-53—Data frame............................................................................................................................. 687
Figure 9-54—A-MSDU structure ................................................................................................................ 690
Figure 9-55—Basic A-MSDU subframe structure ...................................................................................... 691
Figure 9-56—A-MSDU subframe structure for Mesh Data ........................................................................ 691
Figure 9-57—Short A-MSDU subframe structure ...................................................................................... 692
Figure 9-58—Management frame format.................................................................................................... 692
Figure 9-59—Extension frame format......................................................................................................... 717
Figure 9-60—DMG Beacon frame format .................................................................................................. 717
Figure 9-61—Beacon Interval Control field................................................................................................ 719
Figure 9-62—Clustering Control field format if the Discovery Mode field is 0......................................... 720
Figure 9-63—Clustering Control field format if the Discovery Mode field is 1......................................... 721
Figure 9-64—Example addressing for a mesh Data frame.......................................................................... 723
Figure 9-65—Authentication Algorithm Number field............................................................................... 723
Figure 9-66—Authentication Transaction Sequence Number field ............................................................ 724
Figure 9-67—Beacon Interval field ............................................................................................................. 724
Figure 9-68—Capability Information field (non-DMG STA) .................................................................... 724
Figure 9-69—Capability Information field (DMG STA) ............................................................................ 725
Figure 9-70—Current AP Address field ...................................................................................................... 727
Figure 9-71—Listen Interval field ............................................................................................................... 727
Figure 9-72—Reason Code field ................................................................................................................. 728
Figure 9-73—AID field ............................................................................................................................... 731
Figure 9-74—Status Code field ................................................................................................................... 731
Figure 9-75—Timestamp field .................................................................................................................... 736
Figure 9-76—Action field ........................................................................................................................... 736
Figure 9-77—Dialog Token fixed field ....................................................................................................... 738
Figure 9-78—DLS Timeout Value fixed field ............................................................................................ 738
Figure 9-79—Block Ack Parameter Set fixed field..................................................................................... 738
Figure 9-80—Block Ack Timeout Value fixed field................................................................................... 739
Figure 9-81—DELBA Parameter Set field.................................................................................................. 739
Figure 9-82—QoS Info field when sent by an AP....................................................................................... 739
Figure 9-83—QoS Info field when set by a non-AP STA........................................................................... 740
Figure 9-84—Measurement Pilot Interval fixed field ................................................................................. 741
100
Copyright © 2016 IEEE. All rights reserved.
Figure 9-85—Max Transmit Power field .................................................................................................... 741
Figure 9-86—Transmit Power Used field ................................................................................................... 741
Figure 9-87—Channel Width fixed field..................................................................................................... 741
Figure 9-88—Operating Class and Channel field........................................................................................ 742
Figure 9-89—SM Power Control fixed field ............................................................................................... 742
Figure 9-90—PCO Phase Control fixed field.............................................................................................. 743
Figure 9-91—PSMP Parameter Set fixed field............................................................................................ 743
Figure 9-92—PSMP STA Info fixed field (group addressed) ..................................................................... 744
Figure 9-93—PSMP STA Info fixed field (individually addressed) ........................................................... 744
Figure 9-94—MIMO Control field.............................................................................................................. 745
Figure 9-95—CSI matrix coding ................................................................................................................. 748
Figure 9-96—V matrix coding (noncompressed beamforming) ................................................................. 750
Figure 9-97—First example of Compressed Beamforming Report field encoding..................................... 753
Figure 9-98—Second example of Compressed Beamforming Report field encoding ................................ 753
Figure 9-99—Antenna Selection Indices fixed field ................................................................................... 753
Figure 9-100—Organization Identifier field................................................................................................ 754
Figure 9-101—Identification field format ................................................................................................... 754
Figure 9-102—Mask field format................................................................................................................ 754
Figure 9-103—MCS Index field format when the MCS Selector field is 3, 4, 5, or 6................................ 755
Figure 9-104—GAS Query Response Fragment ID field ........................................................................... 756
Figure 9-105—Venue Info field format....................................................................................................... 756
Figure 9-106—Target Channel field format ................................................................................................ 759
Figure 9-107—Operating Class field format ............................................................................................... 759
Figure 9-108—Send-Confirm field ............................................................................................................. 759
Figure 9-109—Anti-Clogging Token field.................................................................................................. 759
Figure 9-110—Scalar field .......................................................................................................................... 760
Figure 9-111—FFE field ............................................................................................................................. 760
Figure 9-112—Confirm field....................................................................................................................... 760
Figure 9-113—Finite Cyclic Group field .................................................................................................... 760
Figure 9-114—TXOP Reservation field format .......................................................................................... 760
Figure 9-115—Relay Capable STA Info field............................................................................................. 761
Figure 9-116—DMG Parameters................................................................................................................. 762
Figure 9-117—VHT MIMO Control field................................................................................................... 763
Figure 9-118—Operating Mode field .......................................................................................................... 779
Figure 9-119—Membership Status Array field ........................................................................................... 782
Figure 9-120—User Position Array field .................................................................................................... 782
Figure 9-121—Device Location Information Body field format ................................................................ 783
Figure 9-122—Element format.................................................................................................................... 784
Figure 9-123—SSID element format........................................................................................................... 790
Figure 9-124—Supported Rates and BSS Membership Selectors element format ..................................... 791
Figure 9-125—DSSS Parameter Set element format .................................................................................. 792
Figure 9-126—CF Parameter Set element format ....................................................................................... 792
Figure 9-127—TIM element format ............................................................................................................ 793
Figure 9-128—IBSS Parameter Set element format.................................................................................... 795
Figure 9-129—Challenge Text element format........................................................................................... 795
Figure 9-130—Country element format ...................................................................................................... 795
Figure 9-131—Subband Triplet Sequence format....................................................................................... 796
Figure 9-132—Subband Triplet field .......................................................................................................... 796
Figure 9-133—Triplet field if dot11OperaratingClassRequired is true....................................................... 796
Figure 9-134—Format of m-th Operating/Subband Sequence field ........................................................... 796
Figure 9-135—Request element .................................................................................................................. 798
Figure 9-136—Extended Request element .................................................................................................. 798
Figure 9-137—ERP element........................................................................................................................ 799
Figure 9-138—ERP Parameters field .......................................................................................................... 799
101
Copyright © 2016 IEEE. All rights reserved.
Figure 9-139—Extended Supported Rates and BSS Membership Selectors element format ..................... 800
Figure 9-140—Power Constraint element format ....................................................................................... 800
Figure 9-141—Power Capability element format ....................................................................................... 800
Figure 9-142—TPC Request element format .............................................................................................. 801
Figure 9-143—TPC Report element format ................................................................................................ 801
Figure 9-144—Supported Channels element format ................................................................................... 802
Figure 9-145—Channel Switch Announcement element format ................................................................ 802
Figure 9-146—Secondary Channel Offset element format ......................................................................... 803
Figure 9-147—Measurement Request element format................................................................................ 804
Figure 9-148—Measurement Request Mode field ...................................................................................... 805
Figure 9-149—Measurement Request field format for a Basic request ...................................................... 806
Figure 9-150—Measurement Request field format for a CCA request....................................................... 807
Figure 9-151—Measurement Request field format for an RPI Histogram request ..................................... 807
Figure 9-152—Measurement Request field format for Channel Load request ........................................... 807
Figure 9-153—Channel Load Reporting data field format ......................................................................... 808
Figure 9-154—Measurement Request field format for Noise Histogram request....................................... 809
Figure 9-155—Noise Histogram Reporting data field format..................................................................... 810
Figure 9-156—Measurement Request field format for Beacon request...................................................... 811
Figure 9-157—Beacon Reporting data field format .................................................................................... 813
Figure 9-158—Measurement Request field format for Frame request........................................................ 815
Figure 9-159—Measurement Request field format for STA Statistics request........................................... 816
Figure 9-160—Triggered Reporting subelement for STA Counters ........................................................... 817
Figure 9-161—STA Counter Trigger Condition field ................................................................................. 818
Figure 9-162—Triggered Reporting subelement for QoS STA Counters ................................................... 818
Figure 9-163—QoS STA Counter Trigger Condition field......................................................................... 819
Figure 9-164—Triggered Reporting subelement for RSNA Counters ........................................................ 819
Figure 9-165—RSNA Trigger Condition field............................................................................................ 820
Figure 9-166—Measurement Request field format for LCI request ........................................................... 820
Figure 9-167—Azimuth Request subelement format .................................................................................. 821
Figure 9-168—Azimuth Request field ........................................................................................................ 821
Figure 9-169—Originator Requesting STA MAC Address subelement format ......................................... 822
Figure 9-170—Target MAC Address subelement format ........................................................................... 822
Figure 9-171—Format of Maximum Age subelement ................................................................................ 822
Figure 9-172—Measurement Request field format for Transmit Stream/Category Measurement
Request............................................................................................................................. 823
Figure 9-173—Traffic Identifier field ......................................................................................................... 823
Figure 9-174—Triggered Reporting subelement format ............................................................................. 824
Figure 9-175—Triggered Reporting field.................................................................................................... 824
Figure 9-176—Trigger Conditions bit-field ................................................................................................ 824
Figure 9-177—Delay Threshold subfield .................................................................................................... 825
Figure 9-178—Measurement Request field format for Measurement Pause request.................................. 826
Figure 9-179—Measurement Request field format for a Multicast Diagnostics request ............................ 827
Figure 9-180—Multicast Triggered Reporting subelement format ............................................................. 827
Figure 9-181—Multicast Trigger Condition field ....................................................................................... 827
Figure 9-182—Location Civic Request field format ................................................................................... 828
Figure 9-183—Location Identifier request field format .............................................................................. 830
Figure 9-184—Measurement Request field format for Directional Channel Quality request..................... 831
Figure 9-185—Directional Channel Quality Reporting data field format................................................... 832
Figure 9-186—Measurement Request field format for Directional Measurement request ......................... 833
Figure 9-187—Measurement Request field format for Directional Statistics request ................................ 833
Figure 9-188—Directional Statistics Bitmap field format .......................................................................... 834
Figure 9-189—Measurement Request field for a Fine Timing Measurement Range request..................... 834
Figure 9-190—Format of Maximum Age subelement ................................................................................ 835
Figure 9-191—Measurement Report element format.................................................................................. 836
102
Copyright © 2016 IEEE. All rights reserved.
Figure 9-192—Measurement Report Mode field ........................................................................................ 836
Figure 9-193—Measurement Report field format for a Basic report .......................................................... 837
Figure 9-194—Map field format ................................................................................................................. 838
Figure 9-195—Measurement Report field format for a CCA report........................................................... 838
Figure 9-196—Measurement Report field format for an RPI histogram report.......................................... 839
Figure 9-197—Measurement Report field format for Channel Load report ............................................... 840
Figure 9-198—Measurement Report field format for Noise Histogram report........................................... 841
Figure 9-199—Measurement Report field format for Beacon report.......................................................... 843
Figure 9-200—Reported Frame Information field ...................................................................................... 844
Figure 9-201—Measurement Report field format for Frame report............................................................ 845
Figure 9-202—Frame Count Report subelement format ............................................................................. 846
Figure 9-203—Frame Report Entry field format......................................................................................... 846
Figure 9-204—Measurement Report field format for STA Statistics report............................................... 847
Figure 9-205—Measurement Report field format for dot11Counters Group.............................................. 852
Figure 9-206—Measurement Report field format for dot11MACStatistics Group .................................... 852
Figure 9-207—Measurement Report field format for dot11QosCounters Group for UPx ......................... 853
Figure 9-208—Measurement Report field format for dot11BSSAverageAccessDelay Group................... 853
Figure 9-209—Measurement Report field format for RSNA Counters Group ........................................... 854
Figure 9-210—Data field of the Reporting Reason subelement for STA Counters .................................... 854
Figure 9-211—Data field of the Reporting Reason subelement for QoS STA Counters............................ 855
Figure 9-212—Data field of the Reporting Reason subelement for RSNA Counters................................. 855
Figure 9-213—Format of Location Configuration Information Report ...................................................... 855
Figure 9-214—LCI subelement format ....................................................................................................... 856
Figure 9-215—LCI field format .................................................................................................................. 856
Figure 9-216—Azimuth Report subelement format .................................................................................... 858
Figure 9-217—Azimuth Report subfield ..................................................................................................... 858
Figure 9-218—Z subelement format ........................................................................................................... 859
Figure 9-219—STA Floor Info field format................................................................................................ 859
Figure 9-220—Relative Location Error subelement format........................................................................ 860
Figure 9-221—Relative Location Error field format................................................................................... 860
Figure 9-222—Usage Rules/Policy subelement format .............................................................................. 861
Figure 9-223—Usage Rules/Policy Parameters field format ...................................................................... 861
Figure 9-224—Co-Located BSSID List subelement format ....................................................................... 862
Figure 9-225—Measurement Report field format for Transmit Stream/Category Measurement report..... 862
Figure 9-226—Reporting Reason field........................................................................................................ 863
Figure 9-227—Measurement Report field format for a Multicast Diagnostics report ................................ 865
Figure 9-228—Multicast Reporting Reason field ....................................................................................... 866
Figure 9-229—Location Civic report field format ...................................................................................... 867
Figure 9-230—Location Civic subelement format ...................................................................................... 868
Figure 9-231—Location Reference subelement format .............................................................................. 869
Figure 9-232—Location Shape subelement format..................................................................................... 869
Figure 9-233—2-Dimension Point Location Shape Value format .............................................................. 870
Figure 9-234—3-Dimension Point Location Shape Value format .............................................................. 870
Figure 9-235—Circle Location Shape Value format................................................................................... 870
Figure 9-236—Sphere Location Shape Value format ................................................................................. 871
Figure 9-237—Polygon Location Shape Value format ............................................................................... 871
Figure 9-238—Prism Location Shape Value format ................................................................................... 871
Figure 9-239—Ellipse Location Shape Value format ................................................................................. 872
Figure 9-240—Ellipsoid Location Shape Value format .............................................................................. 872
Figure 9-241—Arcband Location Shape Value format............................................................................... 872
Figure 9-242—Map Image subelement format ........................................................................................... 873
Figure 9-243—Location Identifier report field format ................................................................................ 874
Figure 9-244—Public Identifier URI/FQDN subelement format................................................................ 875
Figure 9-245—Measurement report field format for Directional Channel Quality report.......................... 876
103
Copyright © 2016 IEEE. All rights reserved.
Figure 9-246—Measurement Report field format for Directional Measurement report ............................. 877
Figure 9-247—Measurement Results field format ...................................................................................... 877
Figure 9-248—Measurement Report field format for Directional Statistics report .................................... 878
Figure 9-249—Measurement Report field format for a Fine Timing Measurement Range report ............. 879
Figure 9-250—Range Entry field format..................................................................................................... 879
Figure 9-251—Error Entry field format ...................................................................................................... 880
Figure 9-252—Quiet element format .......................................................................................................... 881
Figure 9-253—IBSS DFS element format................................................................................................... 882
Figure 9-254—Channel Map field format ................................................................................................... 882
Figure 9-255—RSNE format....................................................................................................................... 882
Figure 9-256—Suite selector format ........................................................................................................... 884
Figure 9-257—RSN Capabilities field format............................................................................................. 888
Figure 9-258—Vendor Specific element format ......................................................................................... 890
Figure 9-259—Extended Capabilities element format ................................................................................ 891
Figure 9-260—BSS Load element format ................................................................................................... 896
Figure 9-261—EDCA Parameter Set element............................................................................................. 897
Figure 9-262—AC_BE, AC_BK, AC_VI, and AC_VO Parameter Record field format ........................... 897
Figure 9-263—ACI/AIFSN field................................................................................................................. 897
Figure 9-264—ECWmin and ECWmax fields ............................................................................................ 898
Figure 9-265—TSPEC element format ....................................................................................................... 900
Figure 9-266—TS Info field ........................................................................................................................ 900
Figure 9-267—Nominal MSDU Size field .................................................................................................. 902
Figure 9-268—DMG Attributes field format .............................................................................................. 905
Figure 9-269—TCLAS element format....................................................................................................... 906
Figure 9-270—Frame Classifier field.......................................................................................................... 907
Figure 9-271—Frame Classifier field of Classifier Type 0 ......................................................................... 909
Figure 9-272—Frame Classifier field of Classifier Type 1 for traffic over IPv4........................................ 909
Figure 9-273—Frame Classifier field of Classifier Type 1 for traffic over IPv6........................................ 909
Figure 9-274—Frame Classifier field of Classifier Type 2 ......................................................................... 909
Figure 9-275—Frame Classifier field of Classifier Type 3 ......................................................................... 910
Figure 9-276—Frame Classifier subfield of Classifier Type 4 for traffic over IPv4 .................................. 911
Figure 9-277—Frame Classifier subfield of Classifier Type 4 for traffic over IPv6 .................................. 911
Figure 9-278—Frame Classifier field of Classifier Type 5 ......................................................................... 912
Figure 9-279—Frame Classifier field of Classifier Type 6 ......................................................................... 912
Figure 9-280—Frame Control Match Specification subfield of Classifier Type 6 ..................................... 912
Figure 9-281—Duration/ID Match Specification subfield of Classifier Type 6 ......................................... 913
Figure 9-282—Address 1 Match Specification subfield of Classifier Type 6 ............................................ 913
Figure 9-283—Address 2 Match Specification subfield of Classifier Type 6 ............................................ 913
Figure 9-284—Address 3 Match Specification subfield of Classifier Type 6 ............................................ 913
Figure 9-285—Sequence Control Match Specification subfield of Classifier Type 6 ................................ 913
Figure 9-286—Address 4 Match Specification subfield of Classifier Type 6 ............................................ 913
Figure 9-287—QoS Control Match Specification subfield of Classifier Type 6 ........................................ 913
Figure 9-288—HT Control Match Specification subfield of Classifier Type 6 .......................................... 914
Figure 9-289—TS Delay element................................................................................................................ 914
Figure 9-290—TCLAS Processing element ................................................................................................ 914
Figure 9-291—Schedule element ................................................................................................................ 915
Figure 9-292—Schedule Info field .............................................................................................................. 915
Figure 9-293—QoS Capability element format........................................................................................... 916
Figure 9-294—AP Channel Report element format .................................................................................... 916
Figure 9-295—Neighbor Report element format ........................................................................................ 917
Figure 9-296—BSSID Information field ..................................................................................................... 917
Figure 9-297—Capabilities subfield............................................................................................................ 918
Figure 9-298—TSF subelement format ....................................................................................................... 919
Figure 9-299— BSS Transition Candidate Preference subelement format ................................................. 920
104
Copyright © 2016 IEEE. All rights reserved.
Figure 9-300—BSS Termination Duration subelement format................................................................... 921
Figure 9-301—Bearing subelement format ................................................................................................. 921
Figure 9-302—Wide Bandwidth Channel subelement format .................................................................... 922
Figure 9-303—RCPI element format .......................................................................................................... 923
Figure 9-304—BSS Average Access Delay element format....................................................................... 923
Figure 9-305—Antenna element format...................................................................................................... 925
Figure 9-306—RSNI element format .......................................................................................................... 925
Figure 9-307—Measurement Pilot Transmission element format .............................................................. 925
Figure 9-308—BSS Available Admission Capacity element format .......................................................... 926
Figure 9-309—BSS AC Access Delay element format............................................................................... 927
Figure 9-310—Access Category Access Delay subfields ........................................................................... 928
Figure 9-311—RM Enabled Capabilities element format ........................................................................... 929
Figure 9-312—Multiple BSSID element format ......................................................................................... 931
Figure 9-313—Mobility Domain element format ....................................................................................... 933
Figure 9-314—FT Capability and Policy field ............................................................................................ 933
Figure 9-315—FTE format .......................................................................................................................... 933
Figure 9-316—MIC Control field................................................................................................................ 934
Figure 9-317—Optional Parameter(s) field ................................................................................................. 934
Figure 9-318—GTK subelement format...................................................................................................... 935
Figure 9-319—GTK subelement’s Key Info subfield ................................................................................. 935
Figure 9-320—IGTK subelement format .................................................................................................... 935
Figure 9-321—TIE format........................................................................................................................... 936
Figure 9-322—RDE format ......................................................................................................................... 936
Figure 9-323—RIC Descriptor element format........................................................................................... 937
Figure 9-324—DSE Registered Location element format .......................................................................... 937
Figure 9-325—DSE Registered Location Information field format............................................................ 938
Figure 9-326—Extended Channel Switch Announcement element format ................................................ 939
Figure 9-327—Supported Operating Classes element format ..................................................................... 939
Figure 9-328—Current Operating Class Extension Sequence field format ................................................ 940
Figure 9-329—Operating Class Duple Sequence field format .................................................................... 940
Figure 9-330—Management MIC element format ...................................................................................... 941
Figure 9-331—HT Capabilities element format .......................................................................................... 941
Figure 9-332—HT Capability Information field ......................................................................................... 942
Figure 9-333—A-MPDU Parameters field.................................................................................................. 944
Figure 9-334—Supported MCS Set field .................................................................................................... 944
Figure 9-335—HT Extended Capabilities field........................................................................................... 945
Figure 9-336—Transmit Beamforming Capabilities field........................................................................... 947
Figure 9-337—ASEL Capability field......................................................................................................... 949
Figure 9-338—HT Operation element format ............................................................................................. 950
Figure 9-339—HT Operation Information field .......................................................................................... 951
Figure 9-340—20/40 BSS Intolerant Channel Report element format ....................................................... 954
Figure 9-341—Overlapping BSS Scan Parameters element format............................................................ 955
Figure 9-342—20/40 BSS Coexistence element format.............................................................................. 955
Figure 9-343—20/40 BSS Coexistence Information field .......................................................................... 956
Figure 9-344—Time Advertisement element format .................................................................................. 956
Figure 9-345—Link Identifier element format ............................................................................................ 958
Figure 9-346—Wakeup Schedule element format ...................................................................................... 958
Figure 9-347—Channel Switch Timing element format ............................................................................. 959
Figure 9-348—PTI Control element format ................................................................................................ 959
Figure 9-349—TPU Buffer Status element format...................................................................................... 960
Figure 9-350—TPU Buffer Status Information field .................................................................................. 960
Figure 9-351—Event Request element format ............................................................................................ 961
Figure 9-352—Transition Target BSSID subelement format...................................................................... 962
Figure 9-353—Transition Source BSSID subelement format ..................................................................... 962
105
Copyright © 2016 IEEE. All rights reserved.
Figure 9-354—Transition Time Threshold subelement format................................................................... 963
Figure 9-355—Transition Result subelement format .................................................................................. 963
Figure 9-356—Match Value field definitions ............................................................................................. 963
Figure 9-357—Frequent Transition subelement format .............................................................................. 964
Figure 9-358—RSNA Target BSSID subelement format ........................................................................... 964
Figure 9-359—Authentication Type subelement format............................................................................. 965
Figure 9-360—EAP Method subelement format......................................................................................... 965
Figure 9-361—RSNA Result subelement format ........................................................................................ 965
Figure 9-362—Match Value field definitions ............................................................................................. 966
Figure 9-363—Peer Address subelement format......................................................................................... 966
Figure 9-364—Channel Number subelement format .................................................................................. 967
Figure 9-365—Event Report element format .............................................................................................. 968
Figure 9-366—Event Report format for Transition event ........................................................................... 969
Figure 9-367—Event Report format for RSNA event................................................................................. 971
Figure 9-368—Event Report format for peer-to-peer link event................................................................. 971
Figure 9-369—Event Report format for WNM log event ........................................................................... 972
Figure 9-370—Diagnostic Request element format .................................................................................... 973
Figure 9-371—Diagnostic subelement format ............................................................................................ 974
Figure 9-372—Credential Type subelement format .................................................................................... 976
Figure 9-373—AKM Suite subelement format ........................................................................................... 976
Figure 9-374—AP Descriptor subelement format....................................................................................... 976
Figure 9-375—Antenna Type subelement format ....................................................................................... 977
Figure 9-376—Cipher Suite subelement format.......................................................................................... 977
Figure 9-377—Collocated Radio Type subelement format......................................................................... 977
Figure 9-378—Device Type subelement format ......................................................................................... 978
Figure 9-379—EAP Method subelement format......................................................................................... 979
Figure 9-380—Firmware Version subelement format................................................................................. 980
Figure 9-381—MAC Address subelement format....................................................................................... 980
Figure 9-382—Manufacturer ID String subelement format ........................................................................ 980
Figure 9-383—Manufacturer Model String subelement format.................................................................. 980
Figure 9-384—Manufacturer OI subelement format................................................................................... 981
Figure 9-385—Manufacturer Serial Number String subelement format..................................................... 981
Figure 9-386—Power Save Mode subelement format ................................................................................ 981
Figure 9-387— Profile ID subelement format............................................................................................. 982
Figure 9-388—Supported Operating Classes subelement format ............................................................... 982
Figure 9-389—Status Code subelement format........................................................................................... 982
Figure 9-390—SSID subelement format ..................................................................................................... 983
Figure 9-391—Tx Power Capability subelement format ............................................................................ 983
Figure 9-392—Certificate ID subelement format........................................................................................ 983
Figure 9-393—Diagnostic Report element format ...................................................................................... 984
Figure 9-394—Location Parameters element format .................................................................................. 986
Figure 9-395—Location Indication Parameters subelement ....................................................................... 987
Figure 9-396—Location Indication Channels subelement .......................................................................... 989
Figure 9-397—Location Status subelement ................................................................................................ 989
Figure 9-398—Radio subelement ................................................................................................................ 990
Figure 9-399—Motion subelement.............................................................................................................. 991
Figure 9-400—Location Indication Broadcast Data Rate subelement ........................................................ 992
Figure 9-401—Time of Departure subelement............................................................................................ 992
Figure 9-402—Location Indication Options subelement ............................................................................ 993
Figure 9-403—Options Used field format................................................................................................... 993
Figure 9-404—Nontransmitted BSSID Capability element format ............................................................ 994
Figure 9-405—DMG BSS Control field format .......................................................................................... 994
Figure 9-406—SSID List element format ................................................................................................... 994
Figure 9-407—Multiple BSSID-Index element format............................................................................... 995
106
Copyright © 2016 IEEE. All rights reserved.
Figure 9-408—FMS Descriptor element format ......................................................................................... 995
Figure 9-409—FMS Counter format ........................................................................................................... 996
Figure 9-410—FMS Request element format ............................................................................................. 996
Figure 9-411—FMS subelement format...................................................................................................... 997
Figure 9-412—FMS Response element format ........................................................................................... 998
Figure 9-413—FMS Status subelement format ........................................................................................... 998
Figure 9-414—TCLAS Status subelement format .................................................................................... 1000
Figure 9-415—QoS Traffic Capability element format ............................................................................ 1000
Figure 9-416—BSS Max Idle Period element format ............................................................................... 1001
Figure 9-417—Idle Options field .............................................................................................................. 1002
Figure 9-418—TFS Request element format............................................................................................. 1002
Figure 9-419—TFS subelement format .................................................................................................... 1003
Figure 9-420—TFS Request Vendor Specific subelement format ........................................................... 1003
Figure 9-421—TFS Response element format .......................................................................................... 1004
Figure 9-422—TFS Status subelement format .......................................................................................... 1005
Figure 9-423—TFS Response Vendor Specific subelement format ......................................................... 1005
Figure 9-424—WNM Sleep Mode element format ................................................................................... 1005
Figure 9-425—TIM Broadcast Request element format ........................................................................... 1006
Figure 9-426—TIM Broadcast Response element format......................................................................... 1007
Figure 9-427— Collocated Interference Report element format............................................................... 1008
Figure 9-428—Interference Level Accuracy/Interference Index field format .......................................... 1008
Figure 9-429—Channel Usage element format ......................................................................................... 1010
Figure 9-430—Time Zone element format................................................................................................ 1010
Figure 9-431—DMS Request element format........................................................................................... 1011
Figure 9-432—DMS Descriptor ................................................................................................................ 1011
Figure 9-433—GCR Request subelement format...................................................................................... 1013
Figure 9-434—DMS Response element format ........................................................................................ 1014
Figure 9-435—DMS Status field format ................................................................................................... 1014
Figure 9-436—GCR Response subelement format ................................................................................... 1016
Figure 9-437—Destination URI element format ....................................................................................... 1016
Figure 9-438—U-APSD Coexistence element format .............................................................................. 1017
Figure 9-439—Interworking element format ............................................................................................ 1018
Figure 9-440—Access Network Options field format............................................................................... 1018
Figure 9-441—Advertisement Protocol element format ........................................................................... 1019
Figure 9-442—Advertisement Protocol Tuple field format ...................................................................... 1020
Figure 9-443—Query Response Info field format..................................................................................... 1020
Figure 9-444—Expedited Bandwidth Request element format................................................................. 1021
Figure 9-445—QoS Map element format .................................................................................................. 1022
Figure 9-446—DSCP Exception format.................................................................................................... 1022
Figure 9-447—DSCP Range description................................................................................................... 1023
Figure 9-448—Roaming Consortium element format............................................................................... 1023
Figure 9-449—OI #1 and #2 Lengths field format.................................................................................... 1024
Figure 9-450—Emergency Alert Identifier element format ...................................................................... 1024
Figure 9-451—Mesh Configuration element format ................................................................................. 1024
Figure 9-452—Mesh Formation Info field ................................................................................................ 1027
Figure 9-453—Mesh Capability field........................................................................................................ 1028
Figure 9-454—Mesh ID element format ................................................................................................... 1028
Figure 9-455—Mesh Link Metric Report element format ........................................................................ 1029
Figure 9-456—Flags field.......................................................................................................................... 1029
Figure 9-457—Congestion Notification element format........................................................................... 1030
Figure 9-458—Mesh Peering Management element format ..................................................................... 1030
Figure 9-459—Mesh Channel Switch Parameters element format ........................................................... 1031
Figure 9-460—Flags field.......................................................................................................................... 1031
Figure 9-461—Mesh Awake Window element format ............................................................................. 1032
107
Copyright © 2016 IEEE. All rights reserved.
Figure 9-462—Beacon Timing element format......................................................................................... 1032
Figure 9-463—Report Control field .......................................................................................................... 1033
Figure 9-464—Beacon Timing Information field ..................................................................................... 1033
Figure 9-465—MCCAOP Setup Request element format ........................................................................ 1034
Figure 9-466—MCCAOP Reservation field ............................................................................................. 1034
Figure 9-467—MCCAOP Setup Reply element format............................................................................ 1035
Figure 9-468—MCCAOP Advertisement Overview element format ....................................................... 1035
Figure 9-469—Flags field format .............................................................................................................. 1036
Figure 9-470—MCCAOP Advertisement element format ........................................................................ 1036
Figure 9-471—MCCAOP Advertisement Element Information field ...................................................... 1037
Figure 9-472—MCCAOP Reservation Report field ................................................................................. 1038
Figure 9-473—MCCAOP Teardown element format ............................................................................... 1038
Figure 9-474—GANN element format...................................................................................................... 1039
Figure 9-475—RANN element format ...................................................................................................... 1039
Figure 9-476—Flags field format .............................................................................................................. 1040
Figure 9-477—PREQ element format ....................................................................................................... 1040
Figure 9-478—Flags field format .............................................................................................................. 1041
Figure 9-479—Per Target Flags field format ............................................................................................ 1042
Figure 9-480—PREP element format........................................................................................................ 1043
Figure 9-481—Flags field format .............................................................................................................. 1043
Figure 9-482—PERR element format ....................................................................................................... 1044
Figure 9-483—Flags field format .............................................................................................................. 1044
Figure 9-484—PXU element format ......................................................................................................... 1045
Figure 9-485—Proxy Information field..................................................................................................... 1045
Figure 9-486—Flags subfield .................................................................................................................... 1046
Figure 9-487—PXUC element format....................................................................................................... 1046
Figure 9-488—Authenticated Mesh Peering Exchange element format ................................................... 1047
Figure 9-489—MIC element format.......................................................................................................... 1048
Figure 9-490—QMF Policy element format ............................................................................................. 1048
Figure 9-491—QACM field format........................................................................................................... 1048
Figure 9-492—QACM Header subfield .................................................................................................... 1048
Figure 9-493—Intra-Access Category Priority element format ................................................................ 1049
Figure 9-494—Intra-Access Priority field format ..................................................................................... 1049
Figure 9-495—SCS Descriptor element format ........................................................................................ 1050
Figure 9-496—QLoad Report element format .......................................................................................... 1051
Figure 9-497—QLoad field format............................................................................................................ 1053
Figure 9-498—HCCA TXOP Update Count element format ................................................................... 1053
Figure 9-499—Higher Layer Stream ID element format .......................................................................... 1054
Figure 9-500—GCR Group Address element format................................................................................ 1054
Figure 9-501—DMG BSS Parameter Change element format ................................................................. 1055
Figure 9-502—Change Type Bitmap field format .................................................................................... 1055
Figure 9-503—DMG Capabilities element format .................................................................................... 1055
Figure 9-504—DMG STA Capability Information field format ............................................................... 1056
Figure 9-505—A-MPDU parameters subfield format............................................................................... 1057
Figure 9-506—Supported MCS Set subfield format ................................................................................. 1058
Figure 9-507—DMG AP Or PCP Capability Information field format .................................................... 1059
Figure 9-508—Extended SC MCS Capabilities field................................................................................ 1061
Figure 9-509—DMG Operation element format ....................................................................................... 1063
Figure 9-510—DMG Operation Information field format ........................................................................ 1063
Figure 9-511—DMG BSS Parameter Configuration field format............................................................. 1064
Figure 9-512—DMG Beam Refinement element format .......................................................................... 1064
Figure 9-513—FBCK-REQ field format ................................................................................................... 1065
Figure 9-514—FBCK-TYPE field format ................................................................................................. 1066
Figure 9-515—DMG Wakeup Schedule element format .......................................................................... 1067
108
Copyright © 2016 IEEE. All rights reserved.
Figure 9-516—Extended Schedule element format................................................................................... 1067
Figure 9-517—Allocation field format...................................................................................................... 1068
Figure 9-518—Allocation Control subfield format ................................................................................... 1068
Figure 9-519—STA availability element format....................................................................................... 1069
Figure 9-520—STA Info field format ....................................................................................................... 1070
Figure 9-521—DMG TSPEC element format ........................................................................................... 1070
Figure 9-522—DMG Allocation Info field format.................................................................................... 1071
Figure 9-523—Traffic Scheduling Constraint Set field format................................................................. 1072
Figure 9-524—Constraint subfield format ................................................................................................ 1073
Figure 9-525—Next DMG ATI element format........................................................................................ 1073
Figure 9-526—Awake Window element format ....................................................................................... 1076
Figure 9-527—Multi-band element format .............................................................................................. 1076
Figure 9-528—Multi-band Control field format ...................................................................................... 1077
Figure 9-529—Multi-band Connection Capability field format................................................................ 1078
Figure 9-530—ADDBA Extension element format .................................................................................. 1079
Figure 9-531—ADDBA Capabilities field format .................................................................................... 1079
Figure 9-532—Next PCP List element format .......................................................................................... 1079
Figure 9-533—PCP Handover element format ......................................................................................... 1080
Figure 9-534—DMG Link Margin element format................................................................................... 1080
Figure 9-535—DMG Link Adaptation Acknowledgment element format ............................................... 1081
Figure 9-536—Switching Stream element format..................................................................................... 1082
Figure 9-537—Switching parameters field format .................................................................................... 1082
Figure 9-538—Session Transition element format.................................................................................... 1083
Figure 9-539—Session Control field format ............................................................................................. 1083
Figure 9-540—Cluster Report element format .......................................................................................... 1085
Figure 9-541—Cluster Report Control field format .................................................................................. 1085
Figure 9-542—Relay Capabilities element format .................................................................................... 1086
Figure 9-543—Relay Capability Information field format........................................................................ 1087
Figure 9-544—Relay Transfer Parameter Set element format .................................................................. 1087
Figure 9-545—Relay Transfer Parameter field format.............................................................................. 1088
Figure 9-546—Quiet Period Request element format ............................................................................... 1088
Figure 9-547—Quiet Period Response element format............................................................................. 1089
Figure 9-548—BeamLink Maintenance element format........................................................................... 1089
Figure 9-549—MMS element format ........................................................................................................ 1090
Figure 9-550—MMS Control field format ................................................................................................ 1090
Figure 9-551—U-PID element format....................................................................................................... 1092
Figure 9-552—ECAPC Policy element format ......................................................................................... 1092
Figure 9-553—ECAPC Policy Detail field format.................................................................................... 1092
Figure 9-554—Cluster Time Offset element format ................................................................................. 1093
Figure 9-555—Antenna Sector ID Pattern element format ....................................................................... 1094
Figure 9-556—Sequence Generator 1 ....................................................................................................... 1094
Figure 9-557—Sequence Generator 2 ....................................................................................................... 1095
Figure 9-558—VHT Capabilities element format ..................................................................................... 1095
Figure 9-559—VHT Capabilities Information field .................................................................................. 1096
Figure 9-560—Supported Channel Width Set field (TVHT) .................................................................... 1100
Figure 9-561—Supported VHT-MCS and NSS Set field.......................................................................... 1100
Figure 9-562—Rx VHT-MCS Map and Tx VHT-MCS Map subfields and Basic VHT-MCS And
NSS Set field.................................................................................................................. 1102
Figure 9-563—VHT Operation element format ........................................................................................ 1102
Figure 9-564—VHT Operation Information field ..................................................................................... 1102
Figure 9-565—Extended BSS Load element format ................................................................................. 1104
Figure 9-566—Wide Bandwidth Channel Switch element format............................................................ 1106
Figure 9-567—Transmit Power Envelope element format........................................................................ 1106
Figure 9-568—Transmit Power Information field..................................................................................... 1106
109
Copyright © 2016 IEEE. All rights reserved.
Figure 9-569—Channel Switch Wrapper element format ......................................................................... 1108
Figure 9-570—AID element format .......................................................................................................... 1109
Figure 9-571—Quiet Channel element format .......................................................................................... 1109
Figure 9-572—Operating Mode Notification element .............................................................................. 1110
Figure 9-573—UPSIM element format ..................................................................................................... 1110
Figure 9-574—UPSIM Flags field format................................................................................................. 1110
Figure 9-575—Fine Timing Measurement Parameters element format .................................................... 1111
Figure 9-576—Fine Timing Measurement Parameters field format ......................................................... 1111
Figure 9-577—Calculation of Partial TSF Timer field ............................................................................. 1113
Figure 9-578—Device Location element format....................................................................................... 1115
Figure 9-579—WSM element format........................................................................................................ 1115
Figure 9-580—Reduced Neighbor Report element format ....................................................................... 1115
Figure 9-581—Neighbor AP Information field format ............................................................................. 1116
Figure 9-582—TBTT Information Header subfield .................................................................................. 1116
Figure 9-583—TBTT Information field .................................................................................................... 1117
Figure 9-584—TVHT Operation element format...................................................................................... 1117
Figure 9-585—TVHT Operation Information field................................................................................... 1117
Figure 9-586—FTM Synchronization Information element format.......................................................... 1118
Figure 9-587—Estimated Service Parameters element format.................................................................. 1118
Figure 9-588—ESP Information field format............................................................................................ 1119
Figure 9-589—Future Channel Guidance element format ........................................................................ 1120
Figure 9-590—Subelement format ............................................................................................................ 1121
Figure 9-591—ANQP-element format ...................................................................................................... 1127
Figure 9-592—Query List ANQP-element format .................................................................................... 1128
Figure 9-593—Capability List ANQP-element format ............................................................................. 1129
Figure 9-594—Venue Name ANQP-element format ................................................................................ 1129
Figure 9-595—Venue Name Tuple subfield ............................................................................................. 1130
Figure 9-596—Emergency Call Number ANQP-element format ............................................................. 1130
Figure 9-597—Emergency Call Number Duple subfield format .............................................................. 1130
Figure 9-598—Network Authentication Type ANQP-element format ..................................................... 1131
Figure 9-599—Network Authentication Type Tuple subfield format....................................................... 1131
Figure 9-600—Roaming Consortium ANQP-element format................................................................... 1132
Figure 9-601—OI Duple subfield format .................................................................................................. 1132
Figure 9-602—Vendor Specific ANQP-element format ........................................................................... 1133
Figure 9-603—IP Address Type Availability ANQP-element.................................................................. 1133
Figure 9-604—IP Address field format ..................................................................................................... 1133
Figure 9-605—NAI Realm ANQP-element format................................................................................... 1134
Figure 9-606—NAI Realm Tuple subfield format .................................................................................... 1134
Figure 9-607—NAI Realm Encoding subfield format .............................................................................. 1135
Figure 9-608—EAP Method Tuple subfield format.................................................................................. 1135
Figure 9-609—Authentication Parameter subfield format ........................................................................ 1136
Figure 9-610—3GPP Cellular Network ANQP-element format ............................................................... 1138
Figure 9-611—AP Geospatial Location ANQP-element format............................................................... 1138
Figure 9-612—AP Civic Location ANQP-element format ....................................................................... 1138
Figure 9-613—AP Location Public Identifier URI/FQDN ANQP-element format.................................. 1139
Figure 9-614—Domain Name ANQP-element format.............................................................................. 1139
Figure 9-615—Domain Name Duple subfield format ............................................................................... 1139
Figure 9-616—Emergency Alert URI ANQP-element format.................................................................. 1140
Figure 9-617—Emergency NAI ANQP-element format........................................................................... 1140
Figure 9-618—TDLS Capability ANQP-element format ......................................................................... 1140
Figure 9-619—Neighbor Report ANQP-element format .......................................................................... 1141
Figure 9-620—Venue URL ANQP-element format.................................................................................. 1141
Figure 9-621—Venue URL Duple field .................................................................................................... 1141
Figure 9-622—Advice of Charge ANQP-element format......................................................................... 1142
110
Copyright © 2016 IEEE. All rights reserved.
Figure 9-623—Advice of Charge Duple field ........................................................................................... 1142
Figure 9-624—Plan Information Tuple field............................................................................................. 1142
Figure 9-625—Local Content ANQP-element format .............................................................................. 1143
Figure 9-626—Local Content Duple field................................................................................................. 1143
Figure 9-627—Network Authentication Type with Timestamp ANQP-element format .......................... 1144
Figure 9-628—Network Authentication Timestamp Tuple subfield format ............................................. 1144
Figure 9-629—RLQP-element format....................................................................................................... 1145
Figure 9-630—Channel Availability Query RLQP-element format ......................................................... 1145
Figure 9-631—Channel Query Info field format....................................................................................... 1146
Figure 9-632—Channel Schedule Management RLQP-element format ................................................... 1147
Figure 9-633—Network Channel Control RLQP-element format ............................................................ 1147
Figure 9-634—Vendor Specific RLQP-element format............................................................................ 1149
Figure 9-635—SSW field format .............................................................................................................. 1149
Figure 9-636—Dynamic Allocation Info field format .............................................................................. 1150
Figure 9-637—SSW Feedback field format when transmitted as part of an ISS ...................................... 1150
Figure 9-638—SSW Feedback field format when not transmitted as part of an ISS ................................ 1151
Figure 9-639—BRP Request field format ................................................................................................ 1151
Figure 9-640—BF Control field format when both IsInitiatorTXSS and IsResponderTXSS subfields
are equal to 1 and the BF Control field is transmitted in Grant or Grant Ack frames... 1152
Figure 9-641—BF Control field format in all other cases......................................................................... 1153
Figure 9-642—Beamformed Link Maintenance field format.................................................................... 1154
Figure 9-643—Measurement Request frame Action field format............................................................. 1156
Figure 9-644—Measurement Report frame Action field format............................................................... 1156
Figure 9-645—TPC Request frame Action field format ........................................................................... 1157
Figure 9-646—TPC Report frame Action field format ............................................................................. 1157
Figure 9-647—Channel Switch Announcement frame Action field format.............................................. 1157
Figure 9-648—Vendor Specific frame Action field format ...................................................................... 1172
Figure 9-649—Radio Measurement Request frame Action field format .................................................. 1173
Figure 9-650—Radio Measurement Report frame Action field format .................................................... 1174
Figure 9-651—Link Measurement Request frame Action field format .................................................... 1174
Figure 9-652—Link Measurement Report frame Action field format ...................................................... 1175
Figure 9-653—Neighbor Report Request frame Action field format........................................................ 1176
Figure 9-654—Neighbor Report Response frame Action field format ..................................................... 1176
Figure 9-655—Measurement Pilot frame Action field format .................................................................. 1179
Figure 9-656—Condensed Capability Information field........................................................................... 1179
Figure 9-657—DSE Enablement frame Action field format..................................................................... 1180
Figure 9-658—DSE Deenablement frame Action field format................................................................. 1181
Figure 9-659—DSE Registered Location Announcement frame Action field format .............................. 1182
Figure 9-660—Extended Channel Switch Announcement frame Action field format.............................. 1182
Figure 9-661—DSE Measurement Request frame Action field format .................................................... 1183
Figure 9-662—DSE Measurement Report frame Action field format ...................................................... 1184
Figure 9-663—DSE LCI field format........................................................................................................ 1184
Figure 9-664—DSE Power Constraint frame Action field format ............................................................ 1185
Figure 9-665—Vendor Specific Public Action frame Action field format ............................................... 1186
Figure 9-666—Query Request Length field .............................................................................................. 1187
Figure 9-667—Query Request field .......................................................................................................... 1187
Figure 9-668—GAS Comeback Delay field.............................................................................................. 1188
Figure 9-669—Query Response Length field............................................................................................ 1188
Figure 9-670—Query Response field ........................................................................................................ 1188
Figure 9-671—Location Track Notification Action field format .............................................................. 1191
Figure 9-672—QMF Policy frame Action field contents .......................................................................... 1192
Figure 9-673—QMF Policy Change Action field contents ....................................................................... 1193
Figure 9-674—HCCA TXOP Advertisement frame Action field format ................................................. 1194
Figure 9-675—HCCA TXOP Response frame Action field format.......................................................... 1195
111
Copyright © 2016 IEEE. All rights reserved.
Figure 9-676—Public Key Action field format ......................................................................................... 1196
Figure 9-677—Channel Availability Query frame Action field format .................................................... 1197
Figure 9-678—Channel Schedule Management frame Action field format.............................................. 1197
Figure 9-679—Contact Verification Signal frame Action field format .................................................... 1199
Figure 9-680—GDD Enablement Request frame Action field format...................................................... 1199
Figure 9-681—GDD Enablement Response frame Action field format ................................................... 1200
Figure 9-682—Network Channel Control frame Action field format ....................................................... 1200
Figure 9-683—White Space Map Announcement frame Action field format .......................................... 1201
Figure 9-684—Fine Timing Measurement Request Action field format .................................................. 1202
Figure 9-685—Fine Timing Measurement Action field format ................................................................ 1203
Figure 9-686—Format of the TOD Error field .......................................................................................... 1203
Figure 9-687—Format of the TOA Error field .......................................................................................... 1203
Figure 9-688—FT Request frame Action field format .............................................................................. 1207
Figure 9-689—FT Response frame Action field format ........................................................................... 1207
Figure 9-690—FT Confirm frame Action field format ............................................................................. 1208
Figure 9-691—FT Ack frame Action field format .................................................................................... 1209
Figure 9-692—SA Query Request frame Action field format .................................................................. 1210
Figure 9-693—SA Query Response frame Action field format ................................................................ 1210
Figure 9-694—Event Request Action field format.................................................................................... 1226
Figure 9-695—Event Report Action field format...................................................................................... 1227
Figure 9-696—Diagnostic Request Action field format............................................................................ 1227
Figure 9-697—Diagnostic Report Action field format.............................................................................. 1227
Figure 9-698—Location Configuration Request Action field format ....................................................... 1228
Figure 9-699—Location Configuration Response Action field format..................................................... 1229
Figure 9-700—BSS Transition Management Query Action field format ................................................. 1230
Figure 9-701—BSS Transition Management Request Action field format .............................................. 1230
Figure 9-702—Request Mode field ........................................................................................................... 1231
Figure 9-703—Disassociation Timer field format..................................................................................... 1232
Figure 9-704—Session Information URL field format ............................................................................. 1232
Figure 9-705— BSS Transition Management Response Action field format ........................................... 1232
Figure 9-706—FMS Request Action field format ..................................................................................... 1233
Figure 9-707—FMS Response Action field format .................................................................................. 1234
Figure 9-708—Collocated Interference Request Action field format ....................................................... 1234
Figure 9-709—Request Info field format .................................................................................................. 1235
Figure 9-710—Collocated Interference Report Action field format ......................................................... 1235
Figure 9-711—TFS Request frame format ................................................................................................ 1236
Figure 9-712—TFS Response Action field format.................................................................................... 1236
Figure 9-713—TFS Notify Action field format ........................................................................................ 1237
Figure 9-714—TFS Notify Response Action field format ........................................................................ 1237
Figure 9-715—WNM Sleep Mode Request frame format ........................................................................ 1238
Figure 9-716—WNM Sleep Mode Response Action field format ............................................................ 1238
Figure 9-717—WNM Sleep Mode GTK subelement format .................................................................... 1239
Figure 9-718—WNM Sleep Mode IGTK subelement format................................................................... 1239
Figure 9-719—TIM Broadcast Request Action field format..................................................................... 1240
Figure 9-720—TIM Broadcast Response Action field format .................................................................. 1240
Figure 9-721—QoS Traffic Capability Update Action field format ......................................................... 1241
Figure 9-722—Channel Usage Request Action field format..................................................................... 1242
Figure 9-723—Channel Usage Response Action field format .................................................................. 1242
Figure 9-724—DMS Request Action field format .................................................................................... 1243
Figure 9-725—DMS Response Action field format.................................................................................. 1243
Figure 9-726—Timing Measurement Request Action field format .......................................................... 1244
Figure 9-727—WNM Notification Request Action field format .............................................................. 1244
Figure 9-728—WNM Notification Response Action field format ............................................................ 1245
Figure 9-729—TIM Action field format ................................................................................................... 1246
112
Copyright © 2016 IEEE. All rights reserved.
Figure 9-730—Timing Measurement Action field format ........................................................................ 1246
Figure 9-731—SCS Request frame Action field format ........................................................................... 1261
Figure 9-732—SCS Response frame Action field format ......................................................................... 1261
Figure 9-733—SCS Status duple format ................................................................................................... 1261
Figure 9-734—Group Membership Request frame Action field format ................................................... 1262
Figure 9-735—Group Membership Response frame Action field format................................................. 1262
Figure 9-736—DTP Request frame Action field format ........................................................................... 1267
Figure 9-737—DTP Report frame Action field format ............................................................................. 1268
Figure 9-738—Channel Measurement Info field format ........................................................................... 1270
Figure 9-739—Relay Operation Type field format ................................................................................... 1277
Figure 9-740—Definition of the OCT MMPDU field............................................................................... 1282
Figure 9-741—A-MPDU format ............................................................................................................... 1287
Figure 9-742—EOF Padding field format ................................................................................................. 1287
Figure 9-743—A-MPDU subframe format ............................................................................................... 1288
Figure 9-744—MPDU delimiter (non-DMG) ........................................................................................... 1288
Figure 9-745—MPDU delimiter (DMG)................................................................................................... 1288
Figure 9-746—MPDU Length field (non-DMG) ...................................................................................... 1289
Figure 9-747—MPDU delimiter CRC calculation .................................................................................... 1290
Figure 10-1—Non-DMG STA MAC architecture..................................................................................... 1295
Figure 10-2—DMG STA MAC architecture............................................................................................. 1296
Figure 10-3—Fragmentation ..................................................................................................................... 1302
Figure 10-4—Some IFS relationships ....................................................................................................... 1306
Figure 10-5—RTS/CTS/data/Ack and NAV setting ................................................................................. 1311
Figure 10-6—RTS/CTS with fragmented MSDU ..................................................................................... 1312
Figure 10-7—RTS/CTS with transmitter priority and missed acknowledgment ...................................... 1312
Figure 10-8—Example of dual CTS mechanism (STBC initiator) ........................................................... 1316
Figure 10-9—Example of dual CTS mechanism (non-STBC initiator) .................................................... 1316
Figure 10-10—Individually addressed data/Ack/BA frame ...................................................................... 1317
Figure 10-11—Example of TXOP containing VHT MU PPDU transmission with immediate
acknowledgment to VHT MU PPDU ............................................................................ 1318
Figure 10-12—Example of TXOP containing VHT MU PPDU transmission with no immediate
acknowledgment to VHT MU PPDU ............................................................................ 1318
Figure 10-13—Example of exponential increase of CW........................................................................... 1324
Figure 10-14—Basic access method.......................................................................................................... 1325
Figure 10-15—Backoff procedure............................................................................................................. 1326
Figure 10-16—Example topology of NAV setting in DMG STAs ........................................................... 1327
Figure 10-17—Backoff procedure for DMG STAs................................................................................... 1327
Figure 10-18—Transmission of a multiple-fragment MSDU using SIFS................................................. 1329
Figure 10-19—DCF timing relationships .................................................................................................. 1331
Figure 10-20—CFP/CP alternation ........................................................................................................... 1335
Figure 10-21—Beacon frames and CFPs .................................................................................................. 1336
Figure 10-22—Example of delayed beacon and shortened CFP ............................................................... 1336
Figure 10-23—Example of PCF frame transfer ........................................................................................ 1338
Figure 10-24—Reference implementation model when dot11AlternateEDCAActivated is false or
not present...................................................................................................................... 1378
Figure 10-25—Reference implementation model when dot11AlternateEDCAActivated is true ............. 1378
Figure 10-26—EDCA mechanism timing relationships............................................................................ 1382
Figure 10-27—Illustration of TXOP sharing and PPDU construction...................................................... 1385
Figure 10-28—Example of TXOP truncation ........................................................................................... 1389
Figure 10-29—CAP/CFP/CP periods ........................................................................................................ 1394
Figure 10-30—Polled TXOP ..................................................................................................................... 1396
Figure 10-31—Example MCCAOP reservation with MCCAOP Periodicity equal to 2 .......................... 1406
Figure 10-32—Message sequence chart for block ack mechanism: (a) setup, (b) data and
acknowledgment transfer, and (c) teardown.................................................................. 1416
113
Copyright © 2016 IEEE. All rights reserved.
Figure 10-33—Typical block ack sequence when immediate policy is used............................................ 1419
Figure 10-34—Typical block ack sequence when delayed policy is used ................................................ 1420
Figure 10-35—HT-immediate block ack architecture............................................................................... 1423
Figure 10-36—Example of frame exchange with GCR block ack retransmission policy......................... 1433
Figure 10-37—DMG block ack architecture ............................................................................................. 1434
Figure 10-38—Flow control and its associated parameters as a function of receiver buffer size ............. 1435
Figure 10-39—Basic concept of L-SIG TXOP protection ........................................................................ 1446
Figure 10-40—Example of L-SIG duration setting ................................................................................... 1447
Figure 10-41—Illustration of PSMP sequence with and without PSMP recovery.................................... 1457
Figure 10-42—PSMP burst ....................................................................................................................... 1457
Figure 10-43—PSMP burst showing resource allocation.......................................................................... 1459
Figure 10-44—PSMP burst showing retransmission and resource allocation .......................................... 1459
Figure 10-45—Example PPDU exchange for unidirectional implicit transmit beamforming .................. 1471
Figure 10-46—Example PPDU exchange for bidirectional implicit transmit beamforming .................... 1472
Figure 10-47—Calibration procedure with sounding PPDU containing an MPDU ................................. 1474
Figure 10-48—Calibration procedure with NDP ...................................................................................... 1475
Figure 10-49—Calibration procedure with NDP when STA B supports transmitting sounding
PPDUs for which only one channel dimension can be estimated (i.e., a single
column of the MIMO channel matrix) .......................................................................... 1476
Figure 10-50—Transmit ASEL ................................................................................................................. 1483
Figure 10-51—Receive ASEL................................................................................................................... 1484
Figure 10-52—Example of the sounding protocol with a single VHT beamformee................................. 1490
Figure 10-53—Example of the sounding protocol with more than one VHT beamformee ...................... 1490
Figure 10-54—Example of access periods within a beacon interval......................................................... 1501
Figure 10-55—Example of frame exchanges during the ATI ................................................................... 1502
Figure 10-56—The guard time .................................................................................................................. 1509
Figure 10-57—Example of dynamic allocation of service period mechanism.......................................... 1514
Figure 10-58—Decentralized AP or PCP clustering for 3 APs and PCPs ................................................ 1523
Figure 10-59—An example of beamforming training ............................................................................... 1533
Figure 10-60—An example of SLS ........................................................................................................... 1536
Figure 10-61—An example of SLS ........................................................................................................... 1536
Figure 10-62—Initiator TXSS or initiator RXSS ...................................................................................... 1538
Figure 10-63—Responder TXSS or responder RXSS............................................................................... 1540
Figure 10-64—Example of beam refinement transaction.......................................................................... 1544
Figure 10-65—Example of BRP setup subphase procedure (SLS in BTI and A-BFT) ............................ 1547
Figure 10-66—Example of skipping the BRP setup subphase (SLS in DTI) ........................................... 1547
Figure 10-67—A-BFT structure ................................................................................................................ 1550
Figure 10-68—SSW slot (aSSSlotTime) definition .................................................................................. 1550
Figure 10-69—Example of time allocation for the MIDC subphase with MID and BC subphases ......... 1555
Figure 10-70—Example of time allocation for the MIDC subphase with the MID subphase only .......... 1555
Figure 10-71—Example of using BRP setup subphase to set up subsequent MIDC subphase in
A-BFT and DTI ............................................................................................................. 1556
Figure 10-72—Example of using BRP setup subphase to set up subsequent MIDC subphase in DTI..... 1557
Figure 10-73—Conceptual flow of sample MIDC subphase execution with MID and BC subphases
for initiator link .............................................................................................................. 1558
Figure 10-74—Examples of using MID Extension field during execution of MID subphase .................. 1560
Figure 10-75—Beam combining ............................................................................................................... 1561
Figure 10-76—Conceptual flow of sample MIDC subphase execution with only MID subphase
for initiator link .............................................................................................................. 1561
Figure 10-77—Example of using BRP setup subphase to set up subsequent R-MID subphase ............... 1562
Figure 10-78—Example beam refinement transaction (receive training) ................................................. 1565
Figure 10-79—Example beam refinement transaction (transmit training)................................................ 1565
Figure 10-80—Example beam refinement transaction (combination of receive and transmit training) ... 1565
Figure 10-81—Example of beam tracking procedure with initiator requesting TRN-R ........................... 1567
114
Copyright © 2016 IEEE. All rights reserved.
Figure 10-82—Example of beam tracking procedure with initiator requesting TRN-T ........................... 1568
Figure 10-83—SLS phase state machine (initiator) .................................................................................. 1569
Figure 10-84—SLS phase state machine (responder) ............................................................................... 1569
Figure 10-85—Example of fast link adaptation procedure ....................................................................... 1572
Figure 10-86—Example of Normal mode operation with FD-AF relay ................................................... 1575
Figure 10-87—Example of operation with HD-DF relay.......................................................................... 1577
Figure 10-88—TPA mechanism ................................................................................................................ 1578
Figure 10-89—Example of data transmission in SP with link cooperation relay ..................................... 1579
Figure 11-1—Beacon transmission on a busy network ............................................................................. 1583
Figure 11-2—Example of DMG beacon transmission by an AP or PCP during the BTI ......................... 1584
Figure 11-3—Beacon transmission in an IBSS ......................................................................................... 1587
Figure 11-4—Probe response .................................................................................................................... 1592
Figure 11-5—Active scanning for DMG STAs......................................................................................... 1593
Figure 11-6—PCP factor for a DMG STA ................................................................................................ 1596
Figure 11-7—Infrastructure power management operation (no PCF operating)....................................... 1603
Figure 11-8—Power management in an IBSS—basic operation .............................................................. 1627
Figure 11-9—State transition diagram of non-AP and non-PCP STA in active and PS modes................ 1633
Figure 11-10—State transition diagram of PCP power management mode.............................................. 1637
Figure 11-11—Example operation of PPS mode ...................................................................................... 1639
Figure 11-12—Example of ATIM frame response behavior in PS mode ................................................. 1640
Figure 11-13—Relationship between state and services between a given pair of nonmesh STAs ........... 1643
Figure 11-14—TS life cycle ...................................................................................................................... 1663
Figure 11-15—TS setup............................................................................................................................. 1664
Figure 11-16—TS setup when initiated by the AP.................................................................................... 1665
Figure 11-17—Failed TS setup detected within non-AP STA’s MLME .................................................. 1671
Figure 11-18—TS deletion ........................................................................................................................ 1673
Figure 11-19—Deletion of a TS established using a PTP TSPEC ............................................................ 1674
Figure 11-20—Deletion of an allocation in which both Source AID and Destination AID are not the
broadcast AID ................................................................................................................ 1674
Figure 11-21—TS timeout......................................................................................................................... 1677
Figure 11-22—Block ack setup ................................................................................................................. 1680
Figure 11-23—Block ack deletion............................................................................................................. 1682
Figure 11-24—Error recovery by the receiver upon a peer failure ........................................................... 1683
Figure 11-25—The four steps involved in direct-link handshake ............................................................. 1685
Figure 11-26—DLS message flow ............................................................................................................ 1686
Figure 11-27—STA-initiated DLS teardown message flow ..................................................................... 1688
Figure 11-28—Example of Measurement Pilot frame scheduling ............................................................ 1736
Figure 11-29—Dependent STA state machine .......................................................................................... 1743
Figure 11-30—Phased coexistence operation (PCO) ................................................................................ 1759
Figure 11-31—Events occurring for a TDLS direct-link channel switch.................................................. 1771
Figure 11-32—STA transmission on three channels, three frames per channel with Normal Report
Interval ........................................................................................................................... 1785
Figure 11-33—Timing measurement procedure........................................................................................ 1788
Figure 11-34—Concurrent FTM sessions ................................................................................................. 1790
Figure 11-35—Example negotiation and measurement exchange sequence, ASAP=0, and FTMs
per Burst = 2 .................................................................................................................. 1794
Figure 11-36—Example negotiation and measurement exchange sequence, ASAP=1, and FTMs
per Burst = 2 .................................................................................................................. 1795
Figure 11-37—Example negotiation and measurement exchange sequence for a single burst instance,
ASAP=1, and FTMs per Burst = 3 ................................................................................ 1796
Figure 11-38—GAS frame sequence with dot11GASPauseForServerResponse equal to true................. 1826
Figure 11-39—GAS frame sequence with GAS fragmentation and
dot11GASPauseForServerResponse equal to true......................................................... 1827
115
Copyright © 2016 IEEE. All rights reserved.
Figure 11-40—GAS frame sequence with GAS fragmentation and
dot11GASPauseForServerResponse equal to false ....................................................... 1828
Figure 11-41—Example TDLS Capability discovery using ANQP.......................................................... 1837
Figure 11-42—Example of beamformed link maintenance ...................................................................... 1863
Figure 11-43—Moving the TBTT position ............................................................................................... 1868
Figure 11-44—Changing beacon interval duration ................................................................................... 1869
Figure 11-45—Example of spatial sharing assessment ............................................................................. 1871
Figure 11-46—Example of spatial sharing between SP1 and SP2 ............................................................ 1872
Figure 11-47—Procedure of the FST setup protocol................................................................................. 1875
Figure 11-48—States of the FST setup protocol ....................................................................................... 1876
Figure 11-49—On-channel tunneling procedure ....................................................................................... 1884
Figure 11-50—Quieting adjacent BSS operation ...................................................................................... 1893
Figure 11-51—Beamforming training procedure in the DTI .................................................................... 1895
Figure 11-52—Beamforming training when joining an infrastructure BSS or PBSS ............................... 1895
Figure 11-53—GDD dependent STA state transition diagram ................................................................. 1910
Figure 12-1—Construction of expanded WEP MPDU ............................................................................. 1928
Figure 12-2—WEP encapsulation block diagram ..................................................................................... 1930
Figure 12-3—WEP decapsulation block diagram ..................................................................................... 1930
Figure 12-4—SAE finite state machine..................................................................................................... 1947
Figure 12-5—TKIP encapsulation block diagram..................................................................................... 1954
Figure 12-6—TKIP decapsulation block diagram..................................................................................... 1955
Figure 12-7—Construction of expanded TKIP MPDU ............................................................................. 1956
Figure 12-8—TKIP MIC relation to IEEE 802.11 processing (informative)............................................ 1957
Figure 12-9—TKIP MIC processing format ............................................................................................. 1958
Figure 12-10—Michael message processing ............................................................................................. 1959
Figure 12-11—Michael block function ..................................................................................................... 1959
Figure 12-12—Authenticator MIC countermeasures ................................................................................ 1961
Figure 12-13—Supplicant MIC countermeasures ..................................................................................... 1962
Figure 12-14—Phase 1 key mixing ........................................................................................................... 1965
Figure 12-15—Phase 2 key mixing ........................................................................................................... 1966
Figure 12-16—Expanded CCMP MPDU .................................................................................................. 1968
Figure 12-17—CCMP encapsulation block diagram................................................................................. 1969
Figure 12-18—AAD construction ............................................................................................................. 1970
Figure 12-19—Nonce construction ........................................................................................................... 1971
Figure 12-20—Nonce Flags subfield......................................................................................................... 1971
Figure 12-21—CCMP decapsulation block diagram................................................................................. 1972
Figure 12-22—BIP Encapsulation............................................................................................................. 1975
Figure 12-23—BIP AAD Construction ..................................................................................................... 1975
Figure 12-24—Expanded GCMP MPDU.................................................................................................. 1978
Figure 12-25—GCMP encapsulation block diagram ................................................................................ 1978
Figure 12-26—Nonce construction ........................................................................................................... 1979
Figure 12-27—GCMP decapsulation block diagram ................................................................................ 1980
Figure 12-28—Pairwise key hierarchy ...................................................................................................... 2009
Figure 12-29—Group key hierarchy (informative) ................................................................................... 2012
Figure 12-30—PeerKey hierarchy............................................................................................................. 2013
Figure 12-31—FT key hierarchy at an Authenticator ............................................................................... 2015
Figure 12-32—EAPOL-Key frame ........................................................................................................... 2019
Figure 12-33—Key Information bit layout................................................................................................ 2019
Figure 12-34—KDE format....................................................................................................................... 2023
Figure 12-35—GTK KDE format.............................................................................................................. 2024
Figure 12-36—MAC address KDE format................................................................................................ 2024
Figure 12-37—PMKID KDE format ......................................................................................................... 2024
Figure 12-38—SMK KDE format ............................................................................................................. 2024
Figure 12-39—Nonce KDE format ........................................................................................................... 2024
116
Copyright © 2016 IEEE. All rights reserved.
Figure 12-40—Lifetime KDE format ........................................................................................................ 2025
Figure 12-41—Error KDE format ............................................................................................................. 2025
Figure 12-42—IGTK KDE format ............................................................................................................ 2025
Figure 12-43—Key ID KDE...................................................................................................................... 2026
Figure 12-44—Multi-band GTK KDE ...................................................................................................... 2026
Figure 12-45—Multi-band Key ID KDE................................................................................................... 2027
Figure 12-46—Sample 4-way handshake.................................................................................................. 2038
Figure 12-47—Sample group key handshake............................................................................................ 2043
Figure 12-48—PeerKey handshake Supplicant key management state machine...................................... 2061
Figure 12-49—RSNA Supplicant key management state machine........................................................... 2063
Figure 12-50—Authenticator state machines, part 1 ................................................................................. 2065
Figure 12-51—Authenticator state machines, part 2 ................................................................................. 2066
Figure 12-52—Authenticator state machines, part 3 ................................................................................. 2066
Figure 12-53—Authenticator state machines, part 4 ................................................................................. 2067
Figure 13-1—FT key holder architecture .................................................................................................. 2090
Figure 13-2—FT initial mobility domain association in an RSN.............................................................. 2093
Figure 13-3—FT initial mobility domain association in a non-RSN ........................................................ 2095
Figure 13-4—Over-the-air FT protocol in an RSN ................................................................................... 2096
Figure 13-5—Over-the-DS FT protocol in an RSN .................................................................................. 2098
Figure 13-6—MLME interfaces for over-the-DS FT protocol messages.................................................. 2099
Figure 13-7—Over-the-air FT protocol in a non-RSN .............................................................................. 2100
Figure 13-8—Over-the-DS FT protocol in a non-RSN ............................................................................. 2101
Figure 13-9—Over-the-air FT resource request protocol in an RSN ........................................................ 2103
Figure 13-10—Over-the-air FT resource request protocol in a non-RSN................................................. 2103
Figure 13-11—Over-the-DS FT resource request protocol in an RSN ..................................................... 2105
Figure 13-12—Over-the-DS FT resource request protocol in a non-RSN ................................................ 2105
Figure 13-13—R0KH state machine ......................................................................................................... 2114
Figure 13-14—R1KH state machine, including portions of the SME (part 1).......................................... 2116
Figure 13-15—R1KH state machine, including portions of the SME (part 2).......................................... 2117
Figure 13-16—S0KH state machine.......................................................................................................... 2119
Figure 13-17—S1KH state machine, including portions of the SME (part 1) .......................................... 2121
Figure 13-18—S1KH state machine, including portions of the SME (part 2) .......................................... 2122
Figure 13-19—Sample message flow for over-the-DS resource request .................................................. 2125
Figure 13-20—RIC-Request format .......................................................................................................... 2127
Figure 13-21—Resource Request format .................................................................................................. 2127
Figure 13-22—Resource Request example #1 .......................................................................................... 2127
Figure 13-23—Resource Request example #2 .......................................................................................... 2128
Figure 13-24—RIC-Request example #1 .................................................................................................. 2128
Figure 13-25—RIC-Request example #2 .................................................................................................. 2128
Figure 13-26—RIC-Request example #3 .................................................................................................. 2128
Figure 13-27—RIC-Response format........................................................................................................ 2128
Figure 13-28—Example QoS RIC-Response ............................................................................................ 2128
Figure 13-29—Overview of RIC processing at an AP .............................................................................. 2130
Figure 14-1—Logical flowchart of protocol interaction in the mesh peering management framework ... 2136
Figure 14-2—Finite state machine of the MPM protocol.......................................................................... 2145
Figure 14-3—Finite state machine of the AMPE protocol........................................................................ 2156
Figure 14-4—Illustration of definitions..................................................................................................... 2164
Figure 14-5—Example of mesh power management mode usage ............................................................ 2215
Figure 14-6—Mesh power management operation ................................................................................... 2219
Figure 14-7—Mesh peer service period .................................................................................................... 2221
Figure 15-1—PPDU format....................................................................................................................... 2228
Figure 15-2—CRC-16 implementation ..................................................................................................... 2230
Figure 15-3—Example CRC calculation ................................................................................................... 2231
Figure 15-4—Data scrambler .................................................................................................................... 2231
117
Copyright © 2016 IEEE. All rights reserved.
Figure 15-5—Data descrambler................................................................................................................. 2232
Figure 15-6—Transmit PHY ..................................................................................................................... 2232
Figure 15-7—PHY transmit state machine................................................................................................ 2233
Figure 15-8—Receive PHY....................................................................................................................... 2234
Figure 15-9—PHY receive state machine ................................................................................................. 2236
Figure 15-10—Transmit spectrum mask ................................................................................................... 2241
Figure 15-11—Transmit power-on ramp................................................................................................... 2242
Figure 15-12—Transmit power-down ramp.............................................................................................. 2242
Figure 15-13—Modulation accuracy measurement example .................................................................... 2243
Figure 15-14—Chip clock alignment with baseband eye pattern.............................................................. 2244
Figure 16-1—Long PPDU format ............................................................................................................. 2250
Figure 16-2—Short PPDU format ............................................................................................................. 2250
Figure 16-3—CRC-16 implementation ..................................................................................................... 2254
Figure 16-4—Example of CRC calculation............................................................................................... 2255
Figure 16-5—Data scrambler .................................................................................................................... 2256
Figure 16-6—Data descrambler................................................................................................................. 2257
Figure 16-7—Transmit PHY ..................................................................................................................... 2258
Figure 16-8—Receive PHY....................................................................................................................... 2259
Figure 16-9—PHY receive state machine ................................................................................................. 2261
Figure 16-10—Transmit spectrum mask ................................................................................................... 2270
Figure 16-11—Transmit power-on ramp................................................................................................... 2271
Figure 16-12—Transmit power-down ramp.............................................................................................. 2271
Figure 16-13—Modulation accuracy measurement example .................................................................... 2272
Figure 16-14—Chip clock alignment with baseband eye pattern.............................................................. 2273
Figure 17-1—PPDU format....................................................................................................................... 2283
Figure 17-2—Illustration of OFDM frame with cyclic extension and windowing for (a) single
reception or (b) two receptions of the FFT period......................................................... 2287
Figure 17-3—Inputs and outputs of inverse Fourier transform ................................................................. 2288
Figure 17-4—OFDM training structure..................................................................................................... 2289
Figure 17-5—SIGNAL field bit assignment ............................................................................................. 2290
Figure 17-6—SERVICE field bit assignment ........................................................................................... 2291
Figure 17-7—Data scrambler .................................................................................................................... 2292
Figure 17-8—Convolutional encoder (k = 7) ............................................................................................ 2295
Figure 17-9—Example of the bit-stealing and bit-insertion procedure (r = 3/4, 2/3) ............................... 2296
Figure 17-10—BPSK, QPSK, 16-QAM, and 64-QAM constellation bit encoding .................................. 2299
Figure 17-11—Subcarrier frequency allocation ........................................................................................ 2302
Figure 17-12—Transmitter and receiver block diagram for the OFDM PHY .......................................... 2303
Figure 17-13—Transmit spectrum mask for 20 MHz transmission .......................................................... 2306
Figure 17-14—Transmit spectrum mask for 10 MHz transmission .......................................................... 2306
Figure 17-15—Transmit spectrum mask for 5 MHz transmission ............................................................ 2307
Figure 17-16—Constellation error............................................................................................................. 2309
Figure 17-17—Transmit PHY ................................................................................................................... 2313
Figure 17-18—PHY transmit state machine.............................................................................................. 2315
Figure 17-19—Receive PHY..................................................................................................................... 2316
Figure 17-20—PHY receive state machine ............................................................................................... 2318
Figure 19-1—PPDU format....................................................................................................................... 2347
Figure 19-2—Transmitter block diagram 1 ............................................................................................... 2350
Figure 19-3—Transmitter block diagram 2 .............................................................................................. 2350
Figure 19-4—Timing boundaries for PPDU fields.................................................................................... 2356
Figure 19-5—L-SIG structure ................................................................................................................... 2362
Figure 19-6—Format of HT-SIG1 and HT-SIG2 ..................................................................................... 2365
Figure 19-7—Data tone constellations in an HT-mixed format PPDU..................................................... 2366
Figure 19-8—HT-SIG CRC calculation .................................................................................................... 2367
Figure 19-9—Generation of HT-DLTFs ................................................................................................... 2371
118
Copyright © 2016 IEEE. All rights reserved.
Figure 19-10—Generation of HT-ELTFs.................................................................................................. 2371
Figure 19-11—Puncturing at rate 5/6 ........................................................................................................ 2377
Figure 19-12—Examples of cyclic-permutation matrices with Z=8 ......................................................... 2379
Figure 19-13—LDPC PPDU encoding padding and puncturing of a single codeword ............................ 2381
Figure 19-14—Beamforming MIMO channel model (3x2 example) ....................................................... 2393
Figure 19-15—Baseband-to-baseband channel ......................................................................................... 2394
Figure 19-16—Example of an NDP used for sounding............................................................................. 2401
Figure 19-17—Transmit spectral mask for 20 MHz transmission in the 2.4 GHz band ........................... 2404
Figure 19-18—Transmit spectral mask for a 40 MHz channel in the 2.4 GHz band ................................ 2405
Figure 19-19—Transmit spectral mask for 20 MHz transmission in the 5 GHz band .............................. 2405
Figure 19-20—Transmit spectral mask for a 40 MHz channel in the 5 GHz band ................................... 2406
Figure 19-21—Packet alignment example (HT-greenfield format packet with short GI)......................... 2407
Figure 19-22—PHY transmit procedure (HT-mixed format PPDU) ........................................................ 2414
Figure 19-23—PHY transmit procedure (HT-greenfield format PPDU) .................................................. 2414
Figure 19-24—PHY transmit state machine.............................................................................................. 2416
Figure 19-25—PHY receive procedure for HT-mixed format PPDU format ........................................... 2417
Figure 19-26—PHY receive procedure for HT-greenfield format PPDU................................................. 2417
Figure 19-27—PHY receive state machine ............................................................................................... 2418
Figure 20-1—Transmit mask .................................................................................................................... 2440
Figure 20-2—Packet structure ................................................................................................................... 2444
Figure 20-3—Illustration of windowing function ..................................................................................... 2445
Figure 20-4—SC preamble ........................................................................................................................ 2446
Figure 20-5—OFDM preamble ................................................................................................................. 2446
Figure 20-6—Channel Estimation field for SC packets ........................................................................... 2447
Figure 20-7—Channel Estimation field for OFDM packets ..................................................................... 2447
Figure 20-8—Data scrambler .................................................................................................................... 2451
Figure 20-9—DMG control mode PPDU format ...................................................................................... 2452
Figure 20-10—DMG control mode preamble ........................................................................................... 2452
Figure 20-11—OFDM frame format ......................................................................................................... 2457
Figure 20-12—64-QAM modulation mapping.......................................................................................... 2463
Figure 20-13—SC frame format................................................................................................................ 2469
Figure 20-14—BPSK constellation bit encoding ...................................................................................... 2476
Figure 20-15—QPSK constellation bit encoding ...................................................................................... 2476
Figure 20-16—16-QAM constellation bit encoding.................................................................................. 2477
Figure 20-17—64-QAM constellation bit encoding.................................................................................. 2478
Figure 20-18—Block transmission ............................................................................................................ 2479
Figure 20-19—Blocking for DMG low-power SC mode .......................................................................... 2484
Figure 20-20—PHY transmit procedure.................................................................................................... 2485
Figure 20-21—Typical Tx state machine (Training Length = 0 is assumed; some optional features
such as DMG SC low-power mode are not shown)....................................................... 2486
Figure 20-22—PHY receive procedure ..................................................................................................... 2487
Figure 20-23—Typical Rx state machine (some optional features such as DMG low-power SC
mode are not shown)...................................................................................................... 2489
Figure 20-24—BRP packet structure......................................................................................................... 2490
Figure 20-25—TRN field definition.......................................................................................................... 2492
Figure 21-1— PHY interaction on transmit for various PPDU formats.................................................... 2511
Figure 21-2—PHY interaction on receive for various PPDU formats ...................................................... 2511
Figure 21-3—PHY-CONFIG and CCA interaction with Clause 17, Clause 19, and Clause 21 PHYs .... 2512
Figure 21-4—VHT PPDU format.............................................................................................................. 2514
Figure 21-5—Transmitter block diagram for the L-SIG and VHT-SIG-A fields ..................................... 2515
Figure 21-6—Transmitter block diagram for the VHT-SIG-B field of a 20 MHz, 40 MHz, and
80 MHz VHT SU PPDU................................................................................................ 2516
Figure 21-7—Transmitter block diagram for the VHT-SIG-B field of a 20 MHz, 40 MHz, and
80 MHz VHT MU PPDU .............................................................................................. 2516
119
Copyright © 2016 IEEE. All rights reserved.
Figure 21-8—Transmitter block diagram for the VHT-SIG-B field of a 160 MHz VHT SU PPDU ....... 2517
Figure 21-9—Transmitter block diagram for the VHT-SIG-B field of an 80+80 MHz VHT SU PPDU . 2517
Figure 21-10—Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz
VHT SU PPDU with BCC encoding ............................................................................. 2518
Figure 21-11—Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz
VHT SU PPDU with LDPC encoding ........................................................................... 2518
Figure 21-12—Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz
VHT MU PPDU............................................................................................................. 2519
Figure 21-13—Transmitter block diagram for the Data field of a 160 MHz VHT SU PPDU with
BCC encoding................................................................................................................ 2520
Figure 21-14—Transmitter block diagram for the Data field of a 160 MHz VHT SU PPDU with
LDPC encoding.............................................................................................................. 2520
Figure 21-15—Transmitter block diagram for the Data field of an 80+80 MHz VHT SU PPDU with
BCC encoding................................................................................................................ 2521
Figure 21-16—Transmitter block diagram for the Data field of an 80+80 MHz VHT SU PPDU with
LDPC encoding.............................................................................................................. 2522
Figure 21-17—Timing boundaries for VHT PPDU fields ........................................................................ 2534
Figure 21-18—VHT-SIG-A1 structure ..................................................................................................... 2543
Figure 21-19—VHT-SIG-A2 structure ..................................................................................................... 2543
Figure 21-20—Data tone constellation in the VHT PPDU pre-VHT modulated fields ............................ 2546
Figure 21-21—Generation of VHT-LTF symbols per frequency segment ............................................... 2550
Figure 21-22—VHT-SIG-B bits in 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz
transmissions.................................................................................................................. 2553
Figure 21-23—VHT-SIG-B and SERVICE field relationship .................................................................. 2558
Figure 21-24—Constellation bit encoding for 256-QAM (1st quadrant).................................................. 2567
Figure 21-25—Constellation bit encoding for 256-QAM (2nd quadrant) ................................................ 2568
Figure 21-26—Constellation bit encoding for 256-QAM (3rd quadrant) ................................................. 2569
Figure 21-27—Constellation bit encoding for 256-QAM (4th quadrant) ................................................. 2570
Figure 21-28—VHT NDP format.............................................................................................................. 2580
Figure 21-29—Example transmit spectral mask for 20 MHz mask PPDU ............................................... 2583
Figure 21-30—Example transmit spectral mask for 40 MHz mask PPDU ............................................... 2583
Figure 21-31—Example transmit spectral mask for 80 MHz mask PPDU ............................................... 2584
Figure 21-32—Example transmit spectral mask for 160 MHz mask PPDU ............................................. 2584
Figure 21-33—Example transmit spectral mask for 80+80 MHz mask PPDU......................................... 2585
Figure 21-34—PHY transmit procedure for SU transmission................................................................... 2596
Figure 21-35—PHY transmit state machine for SU transmission............................................................. 2598
Figure 21-36—PHY receive procedure for SU transmission .................................................................... 2599
Figure 21-37—PHY receive state machine ............................................................................................... 2600
Figure 22-1—VHT PPDU format in TVWS bands................................................................................... 2636
Figure 22-2—Transmitter block diagram for the Data field of a TVHT_MODE_2N or
TVHT_MODE_4N SU PPDU with BCC encoding ...................................................... 2639
Figure 22-3—Transmitter block diagram for the Data field of a TVHT_MODE_2N or
TVHT_MODE_4N SU PPDU with LDPC encoding.................................................... 2640
Figure 22-4—Example transmit spectral mask for an 6+6 MHz mask PPDU .......................................... 2658
Figure D-1—Transmit spectrum mask and application............................................................................. 3273
Figure H-1—Ethertype 89-0d frame body................................................................................................. 3311
Figure I-1—DMG control mode preamble expressed in Ga128 and Gb128 sequences............................ 3369
Figure I-2—DMG control mode header coding and modulation .............................................................. 3370
Figure I-3—DMG control mode payload coding and modulation ............................................................ 3371
Figure I-4—DMG SC mode preamble expressed in Ga128 and Gb128 sequences .................................. 3372
Figure I-5—DMG SC mode header coding and modulation..................................................................... 3373
Figure I-6—DMG SC mode MCS1 payload coding and modulation ....................................................... 3376
Figure I-7—DMG SC mode MCS2—MCS12 payload coding and modulation....................................... 3377
Figure I-8—DMG OFDM mode preamble................................................................................................ 3381
120
Copyright © 2016 IEEE. All rights reserved.
Figure I-9—DMG OFDM mode header coding ........................................................................................ 3382
Figure I-10—DMG OFDM mode header modulation............................................................................... 3384
Figure I-11—DMG OFDM mode payload coding .................................................................................... 3385
Figure I-12—DMG OFDM mode SQPSK payload modulation ............................................................... 3386
Figure I-13—DMG OFDM mode QPSK payload modulation ................................................................. 3387
Figure I-14—DMG OFDM mode 16-QAM payload modulation ............................................................. 3389
Figure I-15—DMG OFDM mode 64-QAM payload modulation ............................................................. 3390
Figure I-16—DMG low-power SC mode payload coding and modulation .............................................. 3392
Figure J-1—Randomness generating circuit.............................................................................................. 3419
Figure K-1—Schedule for stream from STA i .......................................................................................... 3450
Figure K-2—Schedule for streams from STAs i to k ................................................................................ 3451
Figure K-3—Reallocation of TXOPs when a stream is dropped .............................................................. 3452
Figure L-1—Partial Virtual Bitmap example #1 ....................................................................................... 3459
Figure L-2—Partial Virtual Bitmap example #2 ....................................................................................... 3460
Figure L-3—Partial Virtual Bitmap example #3 ....................................................................................... 3460
Figure L-4—Partial Virtual Bitmap example #4, Method A and Method B ............................................. 3460
Figure L-5—Partial Virtual Bitmap example #5, Method A or Method B ............................................... 3461
Figure L-6—Partial Virtual Bitmap example #6, Method A..................................................................... 3461
Figure L-7—Partial Virtual Bitmap example #6, Method B ..................................................................... 3462
Figure N-1—Very high level UML use case diagram for the AP ............................................................. 3472
Figure N-2—Very high level UML use case diagram for the WLAN system .......................................... 3472
Figure N-3—High-level UML use case diagram for the WLAN system.................................................. 3473
Figure N-4—High-level UML entity diagram for the WLAN system ...................................................... 3474
Figure N-5—AP UML composition diagram (alternate syntax) ............................................................... 3475
Figure N-6—High-level UML use case diagram for the AP..................................................................... 3476
Figure O-1—A-MPDU parsing ................................................................................................................. 3479
Figure O-2—Example of RD exchange sequence showing response burst .............................................. 3480
Figure O-3—Determination of NDP source and destination for unidirectional NDP sequences ............. 3481
Figure O-4—Determination of NDP source and destination for bidirectional NDP sequence ................. 3482
Figure P-1—Parameters recorded by Observing STA when monitoring an FTM message exchange ..... 3488
Figure R-1—Interworking IEEE 802.11 infrastructure supporting multiple SSPNs ................................ 3496
Figure R-2—Basic architecture of the interworking service ..................................................................... 3499
Figure S-1—Format of a CCMP-128-encrypted mesh Data frame containing a single MSDU ............... 3510
Figure V-1—Example of TSPEC aggregation (SPCA and EDCA access policies) ................................. 3531
Figure V-2—Example of TSPEC aggregation (SPCA, EDCA, and SEMM access policies)................... 3532
121
Copyright © 2016 IEEE. All rights reserved.
IEEE Standard for Information technology—
Telecommunications and information exchange between systems
Local and metropolitan area networks—
Specific requirements
Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications
1. Overview
1.1 Scope
The scope of this standard is to define one medium access control (MAC) and several physical layer (PHY)
specifications for wireless connectivity for fixed, portable, and moving stations (STAs) within a local area.
1.2 Purpose
The purpose of this standard is to provide wireless connectivity for fixed, portable, and moving stations
within a local area. This standard also offers regulatory bodies a means of standardizing access to one or
more frequency bands for the purpose of local area communication.
1.3 Supplementary information on purpose
Specifically, in the context of IEEE 802.11™-compliant devices, this standard
— Describes the functions and services required by a device to operate within independent, personal,
and infrastructure networks as well as the aspects of device mobility (transition) within those
networks.
— Describes the functions and services that allow a device to communicate directly with another such
device outside of an independent or infrastructure network.
— Defines the MAC procedures to support the MAC service data unit (MSDU) delivery services.
— Defines several PHY signaling techniques and interface functions that are controlled by the MAC.
— Permits the operation of a device within a wireless local area network (WLAN) that coexists with
multiple overlapping IEEE 802.11 WLANs.
— Describes the requirements and procedures to provide data confidentiality of user information and
MAC management information being transferred over the wireless medium (WM) and
authentication of devices.
— Defines mechanisms for dynamic frequency selection (DFS) and transmit power control (TPC) that
may be used to satisfy regulatory requirements for operation in any band.
122
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Defines the MAC procedures to support local area network (LAN) applications with quality-of-
service (QoS) requirements, including the transport of voice, audio, and video.
— Defines mechanisms and services for wireless network management of devices that include BSS
transition management, channel usage and coexistence, collocated interference reporting,
diagnostic, multicast diagnostic and event reporting, flexible multicast, efficient beacon
mechanisms, proxy ARP advertisement, location, timing measurement, directed multicast, extended
sleep modes, traffic filtering, and management notification.
— Defines functions and procedures aiding network discovery and selection by devices, information
transfer from external networks using QoS mapping, and a general mechanism for the provision of
emergency services.
— Defines the MAC procedures that are necessary for wireless multi-hop communication to support
wireless LAN mesh topologies.
— Defines medium access control mechanisms to support the prioritization of Management frames.
— Defines mechanisms to improve audio video (AV) streaming QoS while maintaining data and voice
performance.
— Defines the PHY signaling, MAC, and beamforming procedures required for operation with
directional antenna patterns.
1.4 Word usage
In this document, the word shall is used to indicate a mandatory requirement. The word should is used to
indicate a recommendation. The word may is used to indicate a permissible action. The word can is used for
statements of possibility and capability.
The construction “x to y” or “x-y” represents an inclusive range (i.e., the range includes both values x and y).
The construction “up to y” represents an inclusive upper bound (i.e., the range includes the value y).
Any action specified as relating to a SAP primitive is to be interpreted as an action on an invocation or
instance of that primitive.
If represents a scalar field, scalar subfield, scalar parameter or scalar MIB attribute:
— if “ is” is used in a context that relates to the testing or setting the value of “” this usage is to
be interpreted as though written “the value of is”
— “ indicate(s)” is to be interpreted as though written “the value of indicate(s)”
— “indicated by ” is to be interpreted as though written “indicated by the value of ”
— “ that indicate” is to be interpreted as though written “ whose value indicates”
If represents a frame, element, subelement, structured field, structured subfield, structured parameter or
structured MIB attribute:
— “ indicate(s)” is to be interpreted as though written “the contents of indicate”
— “indicated by ” is to be interpreted as though written “indicated by the contents of ”
— “ that indicate” is to be interpreted as though written “ whose contents indicate”
If represents a SAP primitive:
— “ indicate(s)” is to be interpreted as though written “the (or an) invocation of indicates”
— “indicated by ” is to be interpreted as though written “indicated by the (or an) invocation of
”
123
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The construction of descriptions for uses of the SHA family of hash functions [HMAC-]SHA-<1,256,384>[-
n] is used to refer to hash functions/HMACs where square brackets indicate optional information, and n is an
integer indicating the length, in bits, of the output when truncating.
1.5 Terminology for mathematical, logical, and bit operations
Floor (x), also written as x , is the largest integer smaller than or equal to x. For example, Floor (2.3) is 2
and Floor (–2.3) is –3. The two parameter form, Floor (x, y), is the largest multiple of y smaller than or
equal to x; this operator is not used in this standard if y is negative. For example, Floor (3.3, 2) is 2 and
Floor (–3.3, 2) is –4.
Ceil (x), also written as x is the smallest integer larger than or equal to x. For example, Ceil (2.3) is 3 and
Ceil (–2.3) is –2. The two parameter form, Ceil (x, y), is the smallest multiple of y larger than or equal to
x; this operator is not used in this standard if y is negative. For example, Ceil (2.3, 2) is 4 and Ceil (–2.3, 2)
is –2.
Round (x) is the integer closest to x, rounding values with a fractional part of 0.5 away from zero. For
example, Round (2.3) is 2, Round (2.5) is 3, Round (–2.3) is –2 and Round (–2.5) is –3.
x mod y is the remainder when x is divided by y; this operator is not used in this standard if y is negative; the
result is positive even if x is negative. For example, 5 mod 3 is 2 and –5 mod 3 is 1.
The symbol represents bitwise exclusive OR (XOR).
log2 (x) is the logarithm of x to the base 2. For example, log2 (32) is 5.
Re (z) is the real part of complex number z. Im (z) is the imaginary part of complex number z (not including
the factor i). For example, Re (1 – 2i) is 1 and Im (1 – 2i) is –2.
x && y is the short-circuiting Boolean AND.
x || y is the concatenation of x and y, except in code, where it sometimes is the short-circuiting Boolean OR
(as determined by the context).
!x is the Boolean NOT.
x >> y is x logically shifted right (i.e., zeros are inserted at the most significant end) by y; this operator is not
used in this standard if y is negative.
x << y is x shifted left (i.e., zeros are inserted at the least significant end) by y; this operator is not used in this
standard if y is negative.
x == y is Boolean equality.
x != y Boolean inequality.
x & y, where x and y are numbers, is the bitwise AND of x and y.
x | y, where x and y are numbers, is the bitwise OR of x and y.
0x introduces a hexadecimal number. For example, 0x12 is 18 decimal.
124
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
L (S, F, N) is bits F to F+N–1 of the bit string S starting from the left, using the IEEE 802.11 bit conventions
from 9.2.2.
Truncate-N (S) is bits 0 to N–1 of the bit string S starting from the left, using the IEEE 802.11 bit
conventions from 9.2.2). Other bits are irretrievably deleted.
exp (x) is e to the power x, where e is the base of natural logarithms.
2. Normative references
The following referenced documents are indispensable for the application of this standard (i.e., they must be
understood and used; therefore, each referenced document is cited in the text and its relationship to this
document is explained). For dated references, only the edition cited applies. For undated references, the
latest edition of the referenced document (including any amendments or corrigenda) at the time of
publication of this standard applies.
3GPP TS 24.302, Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3.1
ETSI EN 301 893, Broadband Radio Access Networks (BRAN); 5 GHz high performance RLAN; Part 2:
Harmonized EN covering essential requirements of article 3.2 of the R&TTE Directive.2
FIPS PUB 180-4, Secure Hash Standard.3
FIPS PUB 197, Advanced Encryption Standard (AES).
IANA EAP Method Type Numbers, http://www.iana.org/assignments/eap-numbers.
IEEE Std 754™-2008, IEEE Standard for Binary Floating-Point Arithmetic.4,5
IEEE Std 802®-2014, IEEE Standards for Local and Metropolitan Area Networks: Overview and
Architecture.
IEEE Std 802.1AS™, IEEE Standard for Local and Metropolitan Area Networks—Timing and
Synchronization for Time-Sensitive Applications in Bridged Local Area Networks.
IEEE Std 802.1Q™-2003, IEEE Standard for Local and Metropolitan Area Networks: Media Access
Control (MAC) Bridges and Virtual Bridged Local Area Networks.
IEEE Std 802.1Q™-2011, IEEE Standard for Local and Metropolitan Area Networks: Media Access
Control (MAC) Bridges and Virtual Bridged Local Area Networks.
IEEE Std 802.1X™-2010, IEEE Standard for Local and Metropolitan Area Networks: Port-Based Network
Access Control.
IEEE Std 802.21™-2008, IEEE Standard for Local and Metropolitan Area Networks: Media Independent
Handover Services.
13GPP™ documents are available from the 3rd Generation Partnership Project Web site (http://www.3gpp.org).
2
ETSI documents are available from the European Telecommunications Standards Institute (http://www.etsi.org).
3
FIPS publications are available from the National Technical Information Service (NTIS) (http://csrc.nist.gov).
4The IEEE standards or products referred to in this clause are trademarks owned by The Institute of Electrical and Electronics
Engineers, Inc.
5
IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).
125
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IEEE Std 802.3™-2012, IEEE Standard for Ethernet.
IETF RFC 791, Internet Protocol, Sept. 1981.6
IETF RFC 826, An Ethernet Address Resolution Protocol, David C. Plummer, November 1982.
IETF RFC 925, Multi-LAN Address Resolution, J. Postel, Oct. 1984.
IETF RFC 1035, Domain Names — Implementation and Specification, P. Mockapetris, Nov. 1987.
IETF RFC 1042, A Standard for the Transmission of IP Datagrams over IEEE 802® Networks, J. Postel, J.
Reynolds, Feb. 1988.
IETF RFC 1321, The MD5 Message-Digest Algorithm, Apr. 1992 (status: informational).
IETF RFC 2104, HMAC: Keyed-Hashing for Message Authentication, H. Krawczyk, M. Bellare,
R. Canetti, Feb. 1997 (status: informational).
IETF RFC 2409, The Internet Key Exchange (IKE), D. Harkins, D. Carrel, Nov. 1998 (status: Standards
Track).
IETF RFC 2460, Internet Protocol, Version 6 (IPv6), S. Deering, R. Hinden, Dec. 1998.
IETF RFC 5424, The Syslog Protocol, R. Gerhards, March 2009.
IETF RFC 3394, Advanced Encryption Standard (AES) Key Wrap Algorithm, J. Schaad, R. Housley,
Sept. 2002 (status: informational).
IETF RFC 3610, Counter with CBC-MAC (CCM), D. Whiting, R. Housley, N. Ferguson, Sept. 2003
(status: informational).
IETF RFC 3629, UTF-8, a transformation format of ISO 10646, F. Yergeau, Nov. 2003.
IETF RFC 3748, Extensible Authentication Protocol (EAP), B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson,
H. Levkowetz, June 2004.
IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, Jan. 2005.
IETF RFC 4017, Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs, D.
Stanley, J. Walker, B. Aboba, Mar. 2005 (status: informational).
IETF RFC 4119, A Presence-based GEOPRIV Location Object Format, J. Peterson, December 2005.
IETF RFC 4282, The Network Access Identifier, Dec. 2005.
IETF RFC 4776, Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic
Addresses Configuration Information, Nov. 2006.
IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten, E. Nordmark, W. Simpson,
H. Soliman, Sept. 2007.
IETF RFC 5216, The EAP-TLS Authentication Protocol, D. Simon, B. Aboba, R. Hurst, March 2008.
6
IETF documents (i.e., RFCs) are available for download at http://tools.ietf.org/html/ and http://tools.ietf.org/pdf/.
126
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IETF RFC 5227, IPv4 Address Conflict Detection, S. Cheshire, July 2008.
IETF RFC 5297, Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced
Encryption Standard (AES), D. Harkins, October 2008 (status: informational).
IETF RFC 5985, HTTP-Enabled Location Delivery (HELD), M. Barnes (Ed.), September 2010.
IETF RFC 6225, Dynamic Host Configuration Protocol Options for Coordinate-Based Location
Configuration Information, J. Polk, M. Linsner, M. Thomson, B. Aboba, July 2011.
ISO 639, Codes for the Representation of Names of Languages.
ISO 14962:1997, Space data and information transfer systems — ASCII encoded English.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions—Part 1: Country
codes.7
ISO 3166-2, Codes for the representation of names of countries and their subdivisions— Part 2: Country
subdivision code.
ISO 4217 Currency codes.8
ISO/IEC 7498-1:1994, Information technology—Open Systems Interconnection—Basic Reference Model:
The Basic Model.
ISO/IEC 8802-2:1998, Information technology—Telecommunications and information exchange between
systems—Local and metropolitan area networks—Specific requirements—Part 2: Logical link control.
ISO/IEC 8824-1:1995, Information technology—Abstract Syntax Notation One (ASN.1): Specification of
basic notation.
ISO/IEC 8824-2:1995, Information technology—Abstract Syntax Notation One (ASN.1): Information
object specification.
ISO/IEC 8824-3:1995, Information technology—Abstract Syntax Notation One (ASN.1): Constraint
specification.
ISO/IEC 8824-4:1995, Information technology—Abstract Syntax Notation One (ASN.1): Parameterization
of ASN.1 specifications.
ISO/IEC 11802-5:1997, Information technology—Telecommunications and information exchange between
systems—Local and metropolitan area networks—Technical reports and guidelines—Part 5: Medium
Access Control (MAC) Bridging of Ethernet V2.0 in Local Area Networks (previously known as IEEE
Std 802.1H-1997 [B24]9).
ISO/IEC 15802-3, Information Technology—Telecommunications and information exchange between
systems—Local and metropolitan area networks—Common specifications—Part 3: Media Access Control
(MAC) Bridges.
7
ISO/IEC publications are available from the ISO Central Secretariat (http://www.iso.ch/). ISO/IEC publications are also available in
the United States from the American National Standards Institute (http://www.ansi.org/).
8See http://www.currency-iso.org/en/home/tables/table-a1.html
9
The numbers in brackets correspond to the numbers of the bibliography in Annex A.
127
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ITU-R Recommendation TF.460-4(2002), Standard-frequency and time-signal emissions.10
ITU-T Recommendation O.150, General requirements for instrumentation for performance measurements
on digital transmission equipment.
ITU-T Recommendation Z.120 (2004), Programming Languages—Formal Description Techniques
(FDT)—Message Sequence Chart (MSC).
NIST Special Publication 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC
Mode for Authentication, Dworkin, M.11
NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/
Counter Mode (GCM) and GMAC, Morris Dworkin, November 2007.
OASIS Emergency Management Technical Committee, “Emergency Data Exchange Language (EDXL)
Distribution Element, v. 1.0.” OASIS Standard EDXL-DE v1.0, May 2006.
OMA OMA-TS-ULP-V2_0_1 UserPlane Location Protocol, December 2012.12
3. Definitions, acronyms, and abbreviations
3.1 Definitions
For the purposes of this standard, the following terms and definitions apply. IEEE Standards Dictionary
Online should be referenced for terms not defined in this clause.13
access control: The prevention of unauthorized usage of resources.
access point (AP): An entity that contains one station (STA) and provides access to the distribution
services, via the wireless medium (WM) for associated STAs. An AP comprises a STA and a distribution
system access function (DSAF).
access point (AP) reachability: An AP is reachable by a station (STA) if preauthentication messages can be
exchanged between the STA and the target AP via the distribution system (DS).
NOTE—Preauthentication is defined in 12.6.10.2.14
additional authentication data (AAD): Data that are not encrypted, but are cryptographically protected.
admission control: An algorithm intended to prevent the violation of parameterized service commitments
made by the network to admitted flows by controlling the admittance of a new flow into a resource
constrained network.
aggregate medium access control (MAC) protocol data unit (A-MPDU): A structure that contains one or
more MPDUs and is transported by a physical layer (PHY) as a single PHY service data unit (PSDU).
10ITU publications are available from the International Telecommunications Union (http://www.itu.int/).
11
NIST publications are available from the National Institute of Standards and Technology (http://csrc.nist.gov/).
12
OMA publications are available from the Open Mobile Alliance (http://openmobilealliance.org/).
13IEEE Standards Dictionary Online is available at http://ieeexplore.ieee.org/xpls/dictionary.jsp.
14
Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement
the standard.
128
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
aggregate medium access control (MAC) protocol data unit (A-MPDU) subframe: A portion of an A-
MPDU that contains a delimiter and optionally contains an MPDU plus any necessary padding.
aggregate medium access control (MAC) service data unit (A-MSDU): A structure that contains one or
more MSDUs and is transported within a single (unfragmented) data medium access control (MAC)
protocol data unit (MPDU).
aggregate medium access control (MAC) service data unit (A-MSDU) subframe: A portion of an
A-MSDU that contains a header and associated MSDU.
antenna connector: The measurement point of reference for radio frequency (RF) measurements in a
station (STA). The antenna connector is the point in the STA architecture representing the input of the
receiver (output of the antenna) for radio reception and the input of the antenna (output of the transmitter)
for radio transmission. In systems using multiple antennas or antenna arrays, the antenna connector is a
virtual point representing the aggregate output of (or input to) the multiple antennas. In systems using active
antenna arrays with processing, the antenna connector is the output of the active array, which includes any
processing gain of the active antenna subsystem.
antenna selection (ASEL) receiver: A station (STA) that performs receive ASEL.
antenna selection (ASEL) transmitter: A station (STA) that performs transmit ASEL.
antenna weight vector (AWV): A vector of weights describing the excitation (amplitude and phase) for
each element of an antenna array.
association: The service used to establish access point/station (AP/STA) mapping and enable STA
invocation of the distribution system services (DSSs).
authentication: The service used to establish the identity of one station (STA) as a member of the set of
STAs authorized to associate with another STA.
Authentication Server (AS): An entity that provides an authentication service to an Authenticator. This
service determines, from the credentials provided by the Supplicant, whether the Supplicant is authorized to
access the services provided by the Authenticator. (IEEE Std 802.1X-201015)
Authenticator: An entity at one end of a point-to-point LAN segment that facilitates authentication of the
entity attached to the other end of that link. (IEEE Std 802.1X-2010)
authenticator address (AA): The medium access control (MAC) address of the IEEE 802.1X
Authenticator.
authorization: The act of determining whether a particular right, such as access to a resource, is granted to
an entity.
NOTE—See IETF RFC 2903 [B35].
authorized: To be explicitly allowed.
average noise plus interference power indicator (ANIPI): A medium access control (MAC) indication of
the average noise plus interference power measured on a channel that meets the two simultaneous
conditions: 1) the station (STA) is not transmitting a frame, and 2) the station (STA) is not receiving a frame
addressed to itself.
15
Information on references can be found in Clause 2.
129
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
azimuth: The horizontal orientation of the front surface of a station or of a radio antenna system’s main lobe
measured clockwise from true north.
basic service area (BSA): The area containing the members of a basic service set (BSS). It might contain
members of other BSSs.
basic service set (BSS): A set of stations (STAs) that have successfully synchronized using the JOIN
service primitives16 and one STA that has used the START primitive. Alternatively, a set of STAs that have
used the START primitive specifying matching mesh profiles where the match of the mesh profiles has been
verified via the scanning procedure. Membership in a BSS does not imply that wireless communication with
all other members of the BSS is possible.
basic service set (BSS) max idle period: A time period during which the access point (AP) does not
disassociate a station (STA) due to nonreceipt of frames from that STA.
basic service set (BSS) transition: Change of association by a station (STA) from one BSS to another BSS
in the same extended service set (ESS).
beamformee: A station (STA) that receives a physical layer (PHY) protocol data unit (PPDU) that was
transmitted using a beamforming steering matrix.
beamformer: A station (STA) that transmits a physical layer (PHY) protocol data unit (PPDU) using a
beamforming steering matrix.
beamforming: A spatial filtering mechanism used at a transmitter to improve the received signal power or
signal-to-noise ratio (SNR) at an intended receiver. Syn: beam steering.
beamforming steering matrix: A matrix determined using knowledge of the channel between a transmitter
and an intended receiver that maps from space-time streams to transmit antennas with the goal of improving
the signal power or signal-to-noise ratio (SNR) at the intended receiver.
big endian: The concept that, for a given multi-octet numeric representation, the most significant octet has
the lowest address.
broadcast address: A unique group address that specifies all stations (STAs).
calibration initiator: A station (STA) that initiates a calibration sequence.
calibration responder: A station (STA) that transmits during a calibration sequence in response to a
transmission by a calibration initiator.
candidate peer mesh station (STA): A neighbor mesh STA to which a mesh peering has not been
established but meets eligibility requirements to become a peer mesh STA.
channel: An instance of wireless medium (WM) use for the purpose of passing physical layer (PHY)
protocol data units (PDUs) between two or more stations (STAs).
channel spacing: The difference between the center frequencies of two nonoverlapping and adjacent
channels of the radio transmitter.
cipher suite: A set of one or more algorithms, designed to provide data confidentiality, data authenticity or
integrity, and/or replay protection.
16
Description of these primitives can be found in 6.3.4.
130
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
clear channel assessment (CCA) function: The logical function in the physical layer (PHY) that
determines the current state of use of the wireless medium (WM).
collocated interference: Interference that is caused by another radio or station (STA) emitting radio energy
located in the same physical device as the reporting STA, where the reported characteristics of the
interference are known a priori without interference detection, measurement, or characterization by the
reporting STA.
collocated radio: A radio capable of emitting radio-frequency energy located in the same physical device as
the reporting station (STA), where the radio’s type and some link characteristics are known without signal
detection or measurement by the reporting STA.
configuration profile: A collection of parameters identified by a profile identifier (ID) that represent a
current or available configuration of a station (STA).
contiguous transmission: A transmission that uses only one frequency segment.
coordination function: The logical function that determines when a station (STA) is permitted to transmit
protocol data units (PDUs) via the wireless medium (WM).
Counter mode with Cipher-block chaining Message authentication code (CCM): A symmetric key
block cipher mode providing confidentiality using counter mode (CTR) and data origin authenticity using
cipher-block chaining message authentication code (CBC-MAC).
NOTE—See IETF RFC 3610.
cryptographic encapsulation: The process of generating the cryptographic payload from the plaintext data.
This comprises the cipher text as well as any associated cryptographic state required by the receiver of the
data, e.g., initialization vectors (IVs), sequence numbers, message integrity codes (MICs), key identifiers.
data confidentiality: A property of information that prevents disclosure to unauthorized individuals,
entities, or processes.
deauthentication service: The service that voids an existing authentication relationship.
decapsulate: To recover an unprotected frame from a protected one.
decapsulation: The process of generating plaintext data by decapsulating an encapsulated frame.
dependent station (STA): A STA that is not registered and whose operational parameters are dictated by
messages it receives from an enabling STA. Once enabled by the dynamic STA enablement (DSE) process,
a dependent STA’s continued operation becomes contingent upon being able to receive messages from its
enabling STA over the wireless medium (WM).
destination mesh station (STA): A mesh STA that is the final destination of a MAC service data unit
(MSDU). This mesh STA might reside in a proxy mesh gate that might forward the MSDU to a STA outside
of the mesh basic service set (MBSS). A destination mesh STA might be an end station as defined in
IEEE Std 802.
direct link: A bidirectional link from one quality-of-service (QoS) station (STA) to another QoS STA
operating in the same infrastructure QoS basic service set (BSS) that does not pass through a QoS access
point (AP). Once a direct link has been set up, all frames between the two QoS STAs are exchanged directly.
directed frame: See: individually addressed.
131
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
directed multicast service (DMS): A service in which the access point (AP) transmits group addressed
frames as individually addressed frames to the requesting non-AP station (STA).
disassociation service: The service that removes an existing association.
distributed coordination function (DCF): A class of coordination function where the same coordination
function logic is active in every station (STA) in the basic service set (BSS) whenever the network is in
operation.
distribution service: The service that, by using association information, delivers medium access control
(MAC) service tuples within the distribution system (DS).
distribution system (DS): A system used to interconnect a set of basic service sets (BSSs) and integrated
local area networks (LANs) to create an extended service set (ESS).
distribution system access function (DSAF): A function within an access point (AP) or mesh gate that
uses the medium access control (MAC) service and distribution system service (DSS) to provide access
between the distribution system (DS) and the wireless medium (WM).
distribution system medium (DSM): The medium or set of media used by a distribution system (DS) for
communications between access points (APs), mesh gates, and the portal of an extended service set (ESS).
distribution system service (DSS): The set of services provided by the distribution system (DS) that enable
the medium access control (MAC) to transport MAC service tuples between stations (STAs) that are not in
direct communication with each other over a single instance of the wireless medium (WM).
NOTE 1—These services include transport of MAC service tuples between the access points (APs) of basic service sets
(BSSs) within an extended service set (ESS), transport of MAC service tuples between the portal and BSSs within an
ESS, transport of MAC service tuples between mesh gates in the same or different mesh basic service sets (MBSSs),
transport of MAC service tuples between mesh gates and APs, transport of MAC service tuples between mesh gates and
a portal, and transport of MAC service tuples between STAs in the same BSS when the MAC service tuples has a group
destination address or the destination is an individual address and the STA is associated with an AP.
NOTE 2—DSSs are provided between pairs of MACs not on the same instance of the WM.
dynamic frequency selection (DFS): Facilities mandated to satisfy requirements in some regulatory
domains for radar detection and uniform channel spreading in the 5 GHz band. These facilities might also be
used for other purposes, such as automatic frequency planning.
dynamic station (STA) enablement (DSE): The process by which an enabling STA grants permission and
dictates operational procedures to STAs that are subject to its control.
effective isotropic radiated power (EIRP): The equivalent power of a transmitted signal in terms of an
isotropic (omnidirectional) radiator. The EIRP equals the product of the transmitter power and the antenna
gain (reduced by any coupling losses between the transmitter and antenna).
emergency alert system (EAS): A U.S. national public warning system.
enabling station (STA): A registered STA that has the authority to control when and how a dependent STA
can operate. An enabling STA communicates an enabling signal to its dependents over the wireless medium
(WM). An enabling STA chooses whether other dynamic STA enablement (DSE) messages are exchanged
over the air, over the distribution system (DS), or by mechanisms that rely on transport via higher layers.
encapsulate: To construct a protected frame from an unprotected frame.
encapsulation: The process of generating a protected frame by encapsulating plaintext data.
132
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
extended service area (ESA): The area within which members of an extended service set (ESS) can
communicate. An ESA is larger than or equal to a basic service area (BSA) and might involve several basic
service sets (BSSs) in overlapping, disjointed, or both configurations.
extended service set (ESS): A set of one or more interconnected basic service sets (BSSs) that appears as a
single BSS to the logical link control (LLC) layer at any station (STA) associated with one of those BSSs.
extended service set (ESS) transition: Change of association by a station (STA) from one basic service set
(BSS) in one ESS to another BSS in a different ESS.
fast basic service set (BSS) transition: Change of association by a station (STA) that is from one BSS in
one extended service set (ESS) to another BSS in the same ESS and that minimizes the amount of time that
the data connectivity is lost between the STA and the distribution system (DS).
fast session transfer (FST): The transfer of a session from a channel to another channel, in the same or
different frequency bands. The term “session” refers to non-physical layer state information kept by a pair of
stations (STAs) that communicate directly (i.e., excludes forwarding).
fixed station (STA): A STA that is physically attached to a specific location. In licensed bands, a fixed STA
might be authorized to operate only at a specific location.
forwarding information: The information maintained by a mesh station (STA) that allows the mesh STA
to perform its path selection and forwarding functions.
frame: A unit of data exchanged between peer protocol entities.
frequency segment: A contiguous block of spectrum used by a transmission.
frame exchange sequence: A sequence of frames specified by Annex G.
Gaussian frequency shift keying (GFSK): A modulation scheme in which the data are first filtered by a
Gaussian filter in the baseband and then modulated with a simple frequency modulation.
geolocation: A location within an earth-centric frame of reference.
group: The entities in a wireless network, e.g., an access point (AP) and its associated stations (STAs), or all
of the STAs in an independent basic service set (IBSS) network.
group address: A medium access control (MAC) address that has the group bit equal to 1. Syn: multicast
address.
group addressed: A group addressed medium access control (MAC) service data unit (MSDU) is an MSDU
that has a group address as its destination address (DA). A group addressed MAC protocol data unit
(MPDU) is an MPDU that has a group address in its Address 1 field. Syn: multicast.
group master key (GMK): An auxiliary key that might be used to derive a group temporal key (GTK).
group temporal key (GTK): A random value, assigned by the group source, which is used to protect group
addressed medium access control (MAC) protocol data units (MPDUs) from that source. The GTK might be
derived from a group master key (GMK).
hidden station (STA): A STA whose transmissions are not detected using carrier sense (CS) by a second
STA, but whose transmissions interfere with transmissions from the second STA to a third STA
133
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
homogenous extended service set (ESS): A collection of basic service sets (BSSs), within the same
extended service set (ESS), in which every subscription service provider network (SSPN) or other external
network reachable at one BSS is reachable at all of them.
idle power indicator (IPI): A physical layer (PHY) indication of the total channel power (noise and
interference) as measured in the channel at the receiving antenna connector while the station (STA) is idle,
i.e., neither transmitting nor receiving a frame.
IEEE 802.1X authentication: Extensible Authentication Protocol (EAP) authentication transported by the
IEEE 802.1X protocol.
independent basic service set (IBSS): A basic service set (BSS) that forms a self-contained network, and in
which no access to a distribution system (DS) is available.
individual address: A medium access control (MAC) address in which the group bit is 0. Syn: directed
address, unicast address.
individually addressed: When applied to a medium access control (MAC) service data unit (MSDU), it is
an MSDU with an individual address as the destination address (DA). When applied to a MAC protocol data
unit (MPDU), it is an MPDU with an individual address in the Address 1 field. Syn: directed, unicast.
infrastructure: An infrastructure comprises a distribution system (DS), one or more APs, zero or one
portal, and zero or more mesh gates. It is also the logical location of distribution and integration service
functions of an extended service set (ESS).
infrastructure authorization information: The information that specifies the access rights of the user of a
non-access-point (non-AP) station (STA). This information might include the rules for routing the user
traffic, a set of permissions about services that a user is allowed to access, quality-of-service (QoS)
configuration information, or the accounting policy to be applied by the infrastructure.
integration service: The service that enables delivery of medium access control (MAC) service data units
(MSDUs) between the distribution system (DS) and a local area network (LAN) (via a portal).
integrity group temporal key (IGTK): A random value, assigned by the broadcast/multicast source station
(STA), which is used to protect group addressed medium access control (MAC) management protocol data
units (MMPDUs) from that source STA.
link margin: Ratio of the received signal power to the minimum required by the station (STA). The STA
might incorporate rate information and channel conditions, including interference, into its computation of
link margin. The specific algorithm for computing the link margin is implementation dependent.
link metric: A criterion used to characterize the performance, quality, and eligibility of a link.
little endian: The concept that, for a given multi-octet numeric representation, the least significant octet has
the lowest address.
liveness: A demonstration that the peer is actually participating in this instance of communication.
location subject local: The term used when a location request is for the location of the requesting STA, i.e.,
when the requesting STA asks, “Where am I?”
location subject remote: The term used when a location request is for the location of the reporting STA,
i.e., when the requesting STA asks, “Where are you?”
134
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
location subject third party: The term used when the location request is for the location of a station (STA)
other than the requesting STA or the requested STA, (i.e., when the requesting STA asks, “Where is he/
she?”)
master session key (MSK): Keying material that is derived between the Extensible Authentication Protocol
(EAP) peer and exported by the EAP method to the Authentication Server (AS).
NOTE—In this standard, this key is at least 64 octets in length.
medium access control (MAC) frame: The unit of data exchanged between MAC entities. Syn: medium
access control (MAC) protocol data unit (MPDU).
NOTE—In contexts in which the MAC is clearly the subject, “frame” is an implicit reference to a MAC frame.
medium access control (MAC) protocol data unit (MPDU): The unit of data exchanged between two peer
MAC entities using the services of the physical layer (PHY). Syn: medium access control (MAC) frame.
medium access control (MAC) service data unit (MSDU): Information that is delivered as a unit between
MAC service access points (SAPs).
medium access control (MAC) service tuple: The collection of a MAC service data unit (MSDU) along
with the source address, destination addresses, priority, and service class associated with the MSDU, which
are passed as parameters across the MAC service access point (SAP) and are delivered across the
distribution system between access points (APs), mesh gates, and the portal of an extended service set
(ESS).
mesh basic service set (MBSS): A basic service set (BSS) that forms a self-contained network of mesh
stations (STAs) that use the same mesh profile. An MBSS contains zero or more mesh gates, and can be
formed from mesh STAs that are not in direct communication.
mesh facility: The set of enhanced functions, channel access rules, frame formats, mutual authentication
methods, and managed objects used to provide data transfer among autonomously operating stations (STAs)
that might not be in direct communication with each other over a single instance of the wireless medium.
Communication between STAs using the mesh facility takes place using only the wireless medium. The
mesh facility transports an MSDU between source and destination STAs over potentially multiple hops of
the wireless medium without transiting the MAC SAP at intermediate STAs.
mesh gate: Any entity that has a mesh station (STA) function and a distribution system access function
(DSAF) to provide access to a single distribution system for the mesh basic service set (MBSS).
mesh link: A link from one mesh station (STA) to a neighbor mesh STA that have a mesh peering with each
other.
mesh neighborhood: The set of all neighbor mesh stations (STAs) of a particular mesh STA.
mesh path: A concatenated set of mesh links from a source mesh station (STA) to a destination mesh STA.
mesh path selection: The process of selecting a mesh path.
mesh peering: A relationship between two mesh stations (STAs) that is required for direct communication
over a single instance of the wireless medium (WM). A mesh peering is established with a mesh peering
protocol.
135
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
mesh profile: A set of values of parameters that identifies the attributes of the mesh basic service set
(MBSS) and that is used in a single MBSS.
NOTE—The mesh profile consists of the identifiers that are the values for the parameters: mesh ID, active path selection
protocol, active path selection metric, congestion control mode, synchronization method, and authentication protocol.
mesh services: The set of services that enable the creation and operation of a mesh basic service set
(MBSS).
mesh station (STA): A quality-of-service (QoS) STA that implements the mesh facility.
message integrity code (MIC): A value generated by a cryptographic function. If the input data are
changed, a new value cannot be correctly computed without knowledge of the cryptographic key(s) used by
the cryptographic function.
NOTE—This is traditionally called a message authentication code (MAC), but the acronym MAC is already reserved
for another meaning in this standard.
mobile station (STA): A type of STA that uses network communications while in motion.
mobility domain: A set of basic service sets (BSSs), within the same extended service set (ESS), that
support fast BSS transitions between themselves and that are identified by the set’s mobility domain
identifier (MDID).
mobility domain identifier (MDID): An identifier that names a mobility domain.
multi-level precedence and preemption (MLPP): A framework used with admission control for the
treatment of traffic streams based on precedence, which supports the preemption of an active traffic stream
by a higher precedence traffic stream when resources are limited. Preemption is the act of forcibly removing
a traffic stream in progress in order to free up resources for another higher precedence traffic stream.
multi-user multiple input, multiple output (MU-MIMO): A technique by which multiple stations
(STAs), each with one or more antennas, either simultaneously transmit to a single STA or simultaneously
receive from a single STA independent data streams over the same radio frequencies.
NOTE—IEEE Std 802.11 supports only downlink (DL) MU-MIMO. See downlink multi-user multiple input,
multiple output (DL-MU-MIMO) (in 3.2).
multicast: See: group addressed.
multicast address: See: group address.
multicast-group address: A medium access control (MAC) address associated by higher level convention
with a group of logically related stations (STAs).
multiple basic service set identifier (BSSID) capability: The capability to advertise information for
multiple BSSIDs using a single Beacon or Probe Response frame instead of using multiple Beacon or Probe
Response frames, each corresponding to a single BSSID, and the capability to indicate buffered frames for
these multiple BSSIDs using a single traffic indication map (TIM) element in a single Beacon.
multiple input, multiple output (MIMO): A physical layer (PHY) configuration in which both transmitter
and receiver use multiple antennas.
multiple medium access control (MAC) station management entity (SME) (MM-SME): Component of
station management that manages multiple cooperating stations (STAs).
136
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
neighbor access point (AP): Any AP that is a potential service set transition candidate.
neighbor station (STA): A STA in the following relationship: STA A is a neighbor to STA B if STA A can
both directly transmit to and receive from STA B over the wireless medium.
network access identifier (NAI): The user identity submitted by the Supplicant during IEEE 802.1X
authentication.
NOTE—See IETF RFC 4282.
network access server (NAS) client: The client component of a NAS that communicates with the
Authentication Server (AS).
network allocation vector (NAV): An indicator, maintained by each station (STA), of time periods when
transmission onto the wireless medium (WM) is not initiated by the STA regardless of whether the STA’s
clear channel assessment (CCA) function senses that the WM is busy.
next-hop mesh station (STA): The next peer mesh STA on the mesh path to the destination mesh STA.
non-access-point (non-AP) station (STA): A STA that is not contained within an access point (AP).
nonce: A numerical value, used in cryptographic operations associated with a given cryptographic key, that
is not to be reused with that key, including over all reinitializations of the system through all time.
noncontiguous transmission: A transmission that uses nonadjacent frequency segments.
nonoperating channel: A channel that is not the operating channel of the basic service set (BSS) of which
the station (STA) is a member.
non-quality-of-service (non-QoS) access point (AP): An AP that does not support the quality-of-service
(QoS) facility.
non-quality-of-service (non-QoS) basic service set (BSS): A BSS that does not support the quality-of-
service (QoS) facility.
non-quality-of-service (non-QoS) station (STA): A STA that does not support the quality-of-service
(QoS) facility.
operating channel: The operating channel is the channel in which beacons are transmitted.
NOTE—In IEEE Std 802.11, the serving access point (AP) of an infrastructure basic service set (BSS) or the dynamic
frequency selection (DFS) owner of an independent basic service set (IBSS) transmits beacons.
operating channel width: The channel width in which the station (STA) is currently able to receive.
overlapping basic service set (OBSS): A basic service set (BSS) operating on the same channel as the
station’s (STA’s) BSS and within (either partly or wholly) its basic service area (BSA).
over-the-air fast basic service set (BSS) transition (FT): An FT method in which the station (STA)
communicates over a wireless medium (WM) link to the target access point (AP).
over-the-DS (distribution system) fast basic service set (BSS) transition (FT): An FT method in which
the station (STA) communicates with the target access point (AP) via the current AP.
137
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
pairwise: Referring to, or an attribute of, two entities that are associated with each other, e.g., an access
point (AP) and an associated station (STA), or two STAs in an independent basic service set (IBSS)
network. This term is used to refer to a type of encryption key hierarchy pertaining to keys shared by only
two entities.
pass-phrase: A secret text string employed to corroborate the user’s identity.
password: A shared, secret, and potentially low-entropy word, phrase, code, or key used as a credential for
authentication purposes.
NOTE—The method of distribution of a password to the units in the system is outside the scope of this standard.
path metric: An aggregate multi-hop criterion used to characterize the performance, quality, and eligibility
of a mesh path.
peer mesh station (STA): A mesh STA to which a mesh peering has been established.
peer-to-peer link: A direct link within a quality-of-service (QoS) basic service set (BSS), a tunnelled
direct-link setup (TDLS) link, or a STA-to-STA communication in an independent basic service set (IBSS).
peer-to-peer traffic specification (PTP TSPEC): The quality-of-service (QoS) characteristics of a data
flow between non-access point (non-AP) QoS stations (STAs).
per-frame encryption key: A unique encryption key constructed for each medium access control (MAC)
protocol data unit (MPDU).
physical layer (PHY) frame: The unit of data exchanged between PHY entities. Syn: physical layer
(PHY) protocol data unit (PPDU).
NOTE—In contexts in which the PHY is clearly the subject, “frame” is an implicit reference to a PHY frame.
physical layer (PHY) protocol data unit (PPDU): The unit of data exchanged between two peer PHY
entities to provide the PHY data service.
piggyback: The overloading of data with an acknowledgment of a previously received frame to the station
(STA) to which the data is directed.
portable station (STA): A type of station (STA) that might be moved from location to location, but that
only uses network communications while at a fixed location.
portal: The logical point at which the integration service is provided.
NOTE—For the purposes of this Standard, there is at most one portal in a given ESS’s infrastructure. In an
implementation, a single logical portal function may be provided by multiple devices that provide integration services
for the ESS. How such multiple devices coordinate to appear as a single logical portal is implementation dependent.
precursor mesh station (STA): A neighbor peer mesh STA on the mesh path to the destination mesh STA,
that identifies the mesh STA as the next-hop mesh STA.
preshared key (PSK): A static key that is distributed to the units in the system by some out-of-band means.
primary channel: The common channel of operation for all stations (STAs) that are members of the basic
service set (BSS).
138
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
prioritized quality of service (QoS): The provisioning of service in which the medium access control
(MAC) protocol data units (MPDUs) with higher priority are given a preferential treatment over MPDUs
with a lower priority.
NOTE—Prioritized QoS is provided through the enhanced distributed channel access (EDCA) mechanism.
protection mechanism: Any procedure that attempts to update the network allocation vector (NAV) of all
receiving stations (STAs) prior to the transmission of a frame that might or might not be detected as valid
network activity by the physical layer (PHY) entities at those receiving STAs.
protection mechanism frame: Any frame that is sent as part of a protection mechanism procedure.
protocol instance: An execution of a particular protocol that consists of the state of the communicating
parties as well as the messages exchanged.
proxy mesh gate: A mesh gate acting as an intermediary for IEEE 802 stations (STAs) outside the mesh
basic service set (MBSS).
pseudorandom function (PRF): A function that hashes various inputs to derive a pseudorandom value. In
order to ensure liveness of a communication in which a pseudorandom value is used, a nonce is used as one
of the inputs to the function.
public safety answering point (PSAP): A physical location where emergency calls are received and routed
to the appropriate emergency service dispatch center.
NOTE—See NENA 08-002 [B56].
quadrature binary phase shift keying (QBPSK): A binary phase shift keying modulation in which the
binary data is mapped onto the imaginary (Q) axis.
quality-of-service (QoS) access point (AP): An AP that supports the QoS facility.
NOTE—In IEEE Std 802.11, the functions of a QoS AP are a superset of the functions of a non-QoS AP, and thus a QoS
AP is able to function as a non-QoS AP to non-QoS stations (STAs).
quality-of-service (QoS) basic service set (BSS): A BSS that provides the QoS facility. An infrastructure
QoS BSS contains a QoS access point (AP).
quality-of-service (QoS) facility: The set of enhanced functions, channel access rules, frame formats, frame
exchange sequences and managed objects used to provide parameterized and prioritized QoS.
quality-of-service (QoS) independent basic service set (IBSS): An IBSS in which one or more of its
stations (STAs) support the QoS facility.
quality-of-service (QoS) station (STA): A STA that implements the QoS facility.
NOTE—A QoS STA acts as a non-QoS STA when associated in a non-QoS basic service set (BSS).
radio frequency (RF) chain: The physical entity that is able to act as a receive chain or transmit chain, or
both.
reassociation service: The service that enables an established association [between access point (AP) and
station (STA)] to be transferred from one AP to another (or the same) AP.
receive chain: The physical entity that implements any necessary signal processing to provide the received
signal to the digital baseband. Such signal processing includes filtering, amplification, down-conversion,
and sampling.
139
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
receive power: Mean power measured at the antenna connector.
received channel power indicator (RCPI): An indication of the total channel power (signal, noise, and
interference) of a received frame measured on the channel and at the antenna connector used to receive the
frame.
received power indicator (RPI): A quantized measure of the received power level as seen at the antenna
connector.
registered location: The geolocation of a station (STA) registered in accordance with the requirements for
the regulatory domain.
registered location query protocol (RLQP): The query protocol for registered location information that is
received and transported by generic advertisement service (GAS) Public Action frames.
registered location secure server (RLSS): An entity that accesses and manages a database that organizes
storage of information by geographic location and securely holds the location and some operating
parameters of one or more basic service sets (BSSs).
registered station (STA): A STA for which information needs to be submitted to an appropriate regulatory
or coordination authority before it is allowed to transmit.
remote request broker (RRB): The component of the station management entity (SME) of an access point
(AP) that supports fast basic service set (BSS) transitions over the distribution system (DS).
roaming consortium: A group of subscription service providers (SSPs) having inter-SSP roaming
agreements.
service set transition: A station (STA) movement from one basic service set (BSS) to another BSS, i.e.,
either a BSS transition or an extended service set (ESS) transition.
serving access point (AP): The AP to which the station (STA) is associated.
single-user (SU) physical layer (PHY) protocol data unit (PPDU): A PPDU with a format that is capable
of carrying only a single PHY service data unit (PSDU), or no PSDU.
sounding: The use of preamble training fields to measure the channel for purposes other than demodulation
of the Data portion of the physical layer (PHY) protocol data unit (PPDU) containing the training fields.
NOTE—These uses include calculation of transmit steering, calculation of recommended modulation and coding
scheme (MCS), and calculation of calibration parameters.
source mesh station (STA): A mesh STA from which a medium access control (MAC) service data unit
(MSDU) enters the mesh basic service set (MBSS). A source mesh STA is either a mesh STA that is the
source of an MSDU or a proxy mesh gate that receives an MSDU from a STA outside of the MBSS and
forwards the MSDU on a mesh path.
space-time streams: Streams of modulation symbols created by applying a combination of spatial and
temporal processing to one or more spatial streams of modulation symbols.
spatial multiplexing (SM): A transmission technique in which data streams are transmitted on multiple
spatial channels that are provided through the use of multiple antennas at the transmitter and the receiver.
140
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
spatial stream: One of several streams of bits or modulation symbols that might be transmitted over
multiple spatial dimensions that are created by the use of multiple antennas at both ends of a
communications link.
station (STA): A logical entity that is a singly addressable instance of a medium access control (MAC) and
physical layer (PHY) interface to the wireless medium (WM).
NOTE—For IEEE 802.11 purposes, a station is any MAC/PHY entity providing the IEEE 802.11 MAC services. This
differs from the IEEE 802 definition of ‘station,’ which includes bridges (or ‘end stations’) that are endpoints of link
layer data traffic.
station service (SS): The set of services that support transport of medium access control (MAC) service
data units (MSDUs) between stations (STAs) within a basic service set (BSS).
subscription service provider (SSP): An organization (operator) offering connection to network services,
perhaps for a fee.
subscription service provider network (SSPN): The network controlled by a subscription service provider
(SSP). The network maintains user subscription information.
Supplicant: An entity at one end of a point-to-point LAN segment that is being authenticated by an
Authenticator attached to the other end of that link. (IEEE Std 802.1X-2010)
Supplicant address (SPA): The medium access control (MAC) address of the IEEE 802.1X Supplicant.
television white spaces (TVWS): The opportunistic use of allocated but not assigned spectrum—spectrum
allocated for broadcast television, but with no assignment at a particular location.
time unit (TU): A measurement of time equal to 1024 µs.
traffic category (TC): A label for medium access control (MAC) service data units (MSDUs) that have a
distinct user priority (UP), as viewed by higher layer entities, relative to other MSDUs provided for delivery
over the same link. Traffic categories are meaningful only to MAC entities that support quality of service
(QoS) within the MAC data service. These MAC entities determine the UP for MSDUs belonging to a
particular traffic category using the priority value provided with those MSDUs at the MAC service access
point (MAC SAP).
traffic classification (TCLAS): The specification of certain parameter values to identify a protocol data
unit (PDU) or a medium access control (MAC) service data unit (MSDU). The classification process is
performed above the MAC service access point (MAC SAP), within the MLME, or within the MAC, based
on the type of classification.
traffic filter: A set of traffic specifications defined by the use of traffic classification (TCLAS) elements
that are utilized by the traffic filtering service (TFS) to identify specific allowed frames.
traffic filtering service (TFS): A service provided by an access point (AP) to a non-AP station (STA) to
reduce the number of frames sent to the non-AP STA by not forwarding individually addressed frames
addressed to the non-AP STA that do not match traffic filters specified by the non-AP STA.
traffic identifier (TID): Any of the identifiers usable by higher layer entities to distinguish medium access
control (MAC) service data units (MSDUs) to MAC entities that support quality of service (QoS) within the
MAC data service.
NOTE—There are 16 possible TID values; eight identify traffic categories (TCs), and the other eight identify
parameterized traffic streams (TSs). The TID is assigned to an MSDU in the layers above the MAC.
141
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
traffic specification (TSPEC): The quality-of-service (QoS) characteristics of a data flow to and from a
QoS station (STA).
traffic stream (TS): A set of medium access control (MAC) service data units (MSDUs) to be delivered
subject to the quality-of-service (QoS) parameter values provided to the MAC in a particular traffic
specification (TSPEC). TSs are meaningful only to MAC entities that support QoS within the MAC data
service. These MAC entities determine the TSPEC applicable for delivery of MSDUs belonging to a
particular TS using the priority parameter provided with those MSDUs at the MAC service access point
(MAC SAP).
transmission opportunity (TXOP): An interval of time during which a particular quality-of-service (QoS)
station (STA) has the right to initiate frame exchange sequences onto the wireless medium (WM).
NOTE—A TXOP is defined by a starting time and a maximum duration.
transmit chain: The physical entity that implements any necessary signal processing to generate the
transmit signal from the digital baseband. Such signal processing includes digital to analog conversion,
filtering, amplification and up-conversion.
type/length/value (TLV): A format that consists of a type, a length, and a value.
unauthorized disclosure: The process of making information available to unauthorized individuals,
entities, or processes.
unauthorized resource use: The use of a resource not consistent with the defined security policy.
unicast: See: individually addressed.
unicast address: See: individual address.
uniform spreading: A regulatory requirement for a channel selection mechanism that provides uniform
usage across a minimum set of channels in the regulatory domain.
unreachable destination: A destination mesh station (STA) for which the link to the next hop of the mesh
path to this destination mesh STA is no longer usable.
user priority (UP): A value associated with an medium access control (MAC) service data unit (MSDU)
that indicates how the MSDU is to be handled. The UP is assigned to an MSDU in the layers above the
MAC.
validated AP: An AP that has either been explicitly configured as a neighbor or learned through a
mechanism such as the Beacon report.
wildcard BSSID: A BSSID value used to represent all BSSIDs.
NOTE—In IEEE Std 802.11, this is represented by all binary 1s.
wildcard SSID: A SSID value used to represent all SSIDs.
NOTE—In IEEE Std 802.11, this is represented by the value “null”.
wireless medium (WM): The medium used to implement the transfer of protocol data units (PDUs)
between peer physical layer (PHY) entities of a wireless local area network (LAN).
142
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
3.2 Definitions specific to IEEE Std 802.11
The following terms and definitions are specific to terms or references in this standard and are not appropriate
for inclusion in the IEEE Standards Dictionary: Glossary of Terms & Definitions.
20 MHz basic service set (BSS): A BSS in which the Secondary Channel Offset field is equal to no
secondary channel (SCN).
20 MHz high-throughput (HT): A Clause 19 transmission with TXVECTOR parameter FORMAT equal
to HT_MF or HT_GF and TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20.
20 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
a) A Clause 17 PPDU transmitted using the 20 MHz transmit spectral mask defined in Clause 17.
b) A Clause 18 orthogonal frequency division multiplexing (OFDM) PPDU transmitted using the
transmit spectral mask defined in Clause 18.
c) A high-throughput (HT) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to
HT_CBW20 and the CH_OFFSET parameter equal to CH_OFF_20 transmitted using the 20 MHz
transmit spectral mask defined in Clause 19.
d) A very high throughput (VHT) PPDU with TXVECTOR parameter CH_BANDWIDTH equal to
CBW20 transmitted using the 20 MHz transmit spectral mask defined in Clause 21.
e) A Clause 17 PPDU transmitted by a VHT STA using the transmit spectral mask defined in
Clause 21.
f) An HT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20 and the
CH_OFFSET parameter equal to CH_OFF_20 transmitted by a VHT STA using the 20 MHz
transmit spectral mask defined in Clause 21.
20 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 15 PPDU, Clause 17 PPDU (when
using 20 MHz channel spacing), Clause 16 PPDU, Clause 18 orthogonal frequency division multiplexing
(OFDM) PPDU, Clause 19 20 MHz high-throughput (HT) PPDU with the TXVECTOR parameter
CH_BANDWIDTH equal to HT_CBW20, or Clause 21 20 MHz very high throughput (VHT) PPDU with
the TXVECTOR parameter CH_BANDWIDTH equal to CBW20.
20/40 MHz basic service set (BSS): A BSS in which the supported channel width of the access point (AP)
or dynamic frequency selection (DFS) owner (DO) station (STA) is 20 MHz and 40 MHz (Channel Width
field is equal to 1) and the Secondary Channel Offset field is equal to a value of secondary channel above
(SCA) or secondary channel below (SCB).
40-MHz-capable (40MC) high-throughput (HT) access point (AP): An HT AP that included a value of 1
in the Supported Channel Width Set subfield (indicating its capability to operate on a 40 MHz channel) of its
most recent transmission of a frame containing an HT Capabilities element.
40-MHz-capable (40MC) high-throughput (HT) access point (AP) 2G4: An HT AP 2G4 that is also a
40MC HT AP.
40-MHz-capable (40MC) high-throughput (HT) access point (AP) 5G: An HT AP 5G that is also a
40MC HT AP.
40-MHz-capable (40MC) high-throughput (HT) station (STA): An HT STA that included a value of 1 in
the Supported Channel Width Set subfield (indicating its capability to operate on a 40 MHz channel) of its
most recent transmission of a frame containing an HT Capabilities element.
143
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
40-MHz-capable (40MC) high-throughput (HT) station (STA) 2G4: An HT STA 2G4 that is also a
40MC HT STA.
40-MHz-capable (40MC) high-throughput (HT) station (STA) 5G: An HT STA 5G that is also a 40MC
HT STA.
40 MHz high-throughput (HT): A Clause 19 transmission with TXVECTOR parameter FORMAT equal
to HT_MF or HT_GF and TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40.
40 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
a) A 40 MHz high-throughput (HT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
HT_CBW40) transmitted using the 40 MHz transmit spectral mask defined in Clause 19.
b) A 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
NON_HT_CBW40) transmitted by a non-very high throughput (non-VHT) STA using the 40 MHz
transmit spectral mask defined in Clause 19.
c) A 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW40)
transmitted by a very high throughput (VHT) STA using the 40 MHz transmit spectral mask defined
in Clause 21.
d) A 20 MHz HT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20
and the CH_OFFSET parameter equal to either CH_OFF_20U or CH_OFF_20L transmitted using
the 40 MHz transmit spectral mask defined in Clause 19.
e) A 20 MHz VHT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW20
transmitted using the 40 MHz transmit spectral mask defined in Clause 21.
f) A 40 MHz VHT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW40
transmitted using the 40 MHz transmit spectral mask defined in Clause 21.
g) A 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40)
transmitted by a VHT STA using the 40 MHz transmit spectral mask defined in Clause 21.
h) A 20 MHz non-HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW20)
transmitted using the 40 MHz transmit spectral mask defined in Clause 19.
i) A 20 MHz non-HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW20)
transmitted by a VHT STA using the 40 MHz transmit spectral mask defined in Clause 21.
40 MHz physical layer (PHY) protocol data unit (PPDU): A 40 MHz high-throughput (HT) PPDU
(TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40), or a 40 MHz non-HT duplicate PPDU
(TXVECTOR parameter CH_BANDWIDTH equal to NON_HT_CBW40 or TXVECTOR parameter
CH_BANDWIDTH equal to CBW40), or a 40 MHz very high throughput (VHT) PPDU (TXVECTOR
parameter CH_BANDWIDTH equal to CBW40).
4-way handshake: A pairwise key management protocol defined by this standard. This handshake confirms
mutual possession of a pairwise master key (PMK) by two parties and distributes a group temporal key
(GTK).
4-way station-to-station link (STSL) transient key (STK) handshake: A key management protocol
between two parties that confirms mutual possession of an STSL master key (SMK) and distributes an STK.
80 MHz mask physical layer (PHY) protocol data unit (PPDU): A PPDU that is transmitted using the
80 MHz transmit spectral mask defined in Clause 21 and that is one of the following:
a) An 80 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal
to CBW80)
b) An 80 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter
CH_BANDWIDTH equal to CBW80)
144
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) A 20 MHz non-HT, high-throughput (HT), or VHT PPDU (TXVECTOR parameter
CH_BANDWIDTH equal to CBW20)
d) A 40 MHz non-HT duplicate, HT, or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH
equal to CBW40)
80 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 21 80 MHz very high throughput
(VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80) or a Clause 21 80 MHz non-
high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80).
160 MHz mask physical layer (PHY) protocol data unit (PPDU): A PPDU that is transmitted using the
160 MHz transmit spectral mask defined in Clause 21 and that is one of the following:
a) A 160 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal
to CBW160)
b) A 160 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter
CH_BANDWIDTH equal to CBW160)
c) A 20 MHz non-HT, high-throughput (HT), or VHT PPDU (TXVECTOR parameter
CH_BANDWIDTH equal to CBW20)
d) A 40 MHz non-HT duplicate, HT, or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH
equal to CBW40)
e) An 80 MHz non-HT duplicate or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
CBW80)
160 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 21 160 MHz very high throughput
(VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW160) or a Clause 21 160 MHz
non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to
CBW160).
80+80 MHz mask physical layer (PHY) protocol data unit (PPDU): A PPDU that is transmitted using
the 80+80 MHz transmit spectral mask defined in Clause 21 and that is one of the following:
a) An 80+80 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH
equal to CBW80+80)
b) An 80+80 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter
CH_BANDWIDTH equal to CBW80+80)
80+80 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 21 80+80 MHz very high
throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80+80) or a
Clause 21 80+80 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter
CH_BANDWIDTH equal to CBW80+80).
access category (AC): A label for the common set of enhanced distributed channel access (EDCA)
parameters that are used by a quality-of-service (QoS) station (STA) to contend for the channel in order to
transmit medium access control (MAC) service data units (MSDUs) with certain priorities.
access network query protocol (ANQP): The query protocol for access network information retrieval
transported by generic advertisement service (GAS) Public Action frames.
access period: A time period during a beacon interval established in a directional multi-gigabit (DMG)
basic service set (BSS).
access point (AP) path: Path between two tunneled direct-link setup (TDLS) peer stations (STAs) via the
AP with which the STAs are currently associated.
145
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
active mode: A power management mode in which a nonmesh station (STA) remains in the awake state,
and a mesh power management mode with respect to a neighbor peer mesh STA in which a mesh station
remains in the awake state and is expected to receive frames from this neighbor peer mesh STA.
advanced groupcast with retries (GCR): A set of features comprising the GCR block acknowledgment
retransmission policy and the GCR service period (GCR-SP) delivery method.
advertisement protocol: Access network query protocol (ANQP) and higher layer protocols defined
external to this standard that are used for network and service discovery.
advertisement server: A logical server that provides the information repository for a specific advertisement
protocol. The location of the physical server that instantiates the advertisement server is outside the scope of
this standard.
aggregated schedule: The aggregation of delivery and/or poll schedules by the quality-of-service (QoS)
access point (AP) for a particular QoS station (STA) into a single service period (SP).
authentication and key management (AKM) suite: A set of one or more algorithms designed to provide
authentication and key management, either individually or in combination with higher layer authentication
and key management algorithms outside the scope of this standard.
average noise power indicator (ANPI): A medium access control (MAC) indication of the average noise
plus interference power measured when the channel is idle as defined by three simultaneous conditions:
1) the virtual carrier sense (CS) mechanism indicates idle channel, 2) the station (STA) is not transmitting a
frame, and 3) the STA is not receiving a frame.
bandwidth signaling transmitter address (TA): A TA that is used by a very high throughput (VHT)
station (STA) to indicate the presence of additional signaling related to the bandwidth to be used in
subsequent transmission in an enhanced distributed channel access (EDCA) transmission opportunity
(TXOP). It is represented by the IEEE medium access control (MAC) individual address of the transmitting
VHT STA but with the Individual/Group bit set to 1.
base channel: Channel on which the tunneled direct-link setup (TDLS) peer station (STA) is associated
with an access point (AP).
basic channel unit (BCU): For television very high throughput (TVHT) operation, 6 MHz, 7 MHz, or
8 MHz, depending on the regulatory domain.
basic modulation and coding scheme (MCS) set: The set of MCS values that are supported by all high-
throughput (HT) stations (STAs) that are members of an HT basic service set (BSS).
basic space-time block coding (STBC) modulation and coding scheme (MCS): An MCS value and
STBC encoder specification used in the transmission of STBC-encoded Control frames and STBC-encoded
group addressed frames.
beacon header interval (BHI): The period of time that starts at the target beacon transmission time (TBTT)
of a beacon interval of a directional multi-gigabit (DMG) basic service set (BSS) and that ends no later than
the beginning of the data transfer interval (DTI) of the beacon interval.
beacon transmission interval (BTI): The time interval between the start of the first Directional Multi-
gigabit (DMG) Beacon frame transmission by a DMG station (STA) in a beacon interval to the end of the
last DMG Beacon frame transmission by the STA in the same beacon interval.
146
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
bufferable medium access control (MAC) management protocol data unit (MMPDU): An MMPDU
that is eligible to be queued for delivery using a power-saving mechanism (see Table 11-1).
bufferable unit (BU): A medium access control (MAC) service data unit (MSDU), aggregate MAC service
data unit (A-MSDU) [high-throughput (HT) stations (STAs) and directional multi-gigabit (DMG) STAs
only], or bufferable MAC management protocol data unit (MMPDU).
centralized coordination service root (CCSR): An entity that provides synchronization and configuration
services to synchronization access points (S-APs).
centralized coordination service set (CCSS): The collection of one centralized coordination service root
(CCSR) and a set of one or more synchronization access points (S-APs) that are stationary with respect to
their local environment while operating and are connected to the CCSR.
concealed groupcast with retries (GCR) frame: A group addressed frame that is transmitted using the
aggregate medium access control (MAC) service data unit (A-MSDU) frame format with the destination
address (DA) field set to the GCR concealment address.
contention based access period (CBAP): The time period in the data transfer interval (DTI) of a directional
multi-gigabit (DMG) basic service set (BSS) during which enhanced distributed channel access (EDCA) is
used.
contention free (CF) pollable: A station (STA) that is able to respond to a CF poll with a Data frame if such
a frame is queued and able to be generated.
contention free period (CFP): The time period during the operation of a point coordination function (PCF)
when the right to transmit is assigned to stations (STAs) solely by a point coordinator (PC), allowing frame
exchanges to occur between members of the basic service set (BSS) without contention for the wireless
medium (WM).
contention period (CP): The time period outside of the contention free period (CFP) in a point-coordinated
basic service set (BSS). In a BSS where there is no point coordinator (PC), this corresponds to the entire
time of operation of the BSS.
controlled access phase (CAP): A time period during which the hybrid coordinator (HC) maintains control
of the medium, after gaining medium access by sensing the channel to be idle for a point coordination
function (PCF) interframe space (PIFS) duration. It might span multiple consecutive transmission
opportunities (TXOPs) and can contain polled TXOPs.
deep sleep mode: A mesh power management mode with respect to a neighbor peer mesh STA in which a
mesh station (STA) alternates between awake and doze states and is not expected to receive beacons from
this neighbor peer mesh STA.
delivery-enabled access category (AC): A quality-of-service (QoS) access point (AP) AC where the AP is
allowed to use enhanced distributed channel access (EDCA) to deliver traffic from the AC to a QoS station
(STA) in an unscheduled service period (SP) triggered by the STA.
delivery traffic indication map (DTIM) interval: The interval between the consecutive target beacon
transmission times (TBTTs) of beacons containing a DTIM. The value, expressed in time units, is equal to
the product of the value in the Beacon Interval field and the value in the DTIM Period subfield in the TIM
element in Beacon frames.
147
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
destination directional multi-gigabit (DMG) station (STA): A DMG STA identified by the destination
association identifier (AID) field contained in a Grant frame or Extended Schedule element that caused the
allocation of a service period (SP) or a contention based access period (CBAP).
direct sequence spread spectrum/complementary code keying (DSSS/CCK): A Clause 15 or Clause 16
transmission.
directional multi-gigabit (DMG): Pertaining to operation in a frequency band containing a channel with
the channel starting frequency above 45 GHz.
NOTE—The channel starting frequency for IEEE 802.11 stations (STAs) is defined in Annex E.
directional multi-gigabit (DMG) access point (AP): An AP whose radio transmitter is capable of
transmitting and receiving DMG physical layer (PHY) protocol data units (PPDUs).
directional multi-gigabit (DMG) antenna: A DMG antenna is a phased array, a single element antenna, or
a set of switched beam antennas covered by a quasi-omni antenna pattern.
directional multi-gigabit (DMG) basic service set (BSS): A BSS in which DMG Beacon frames are
transmitted by DMG stations (STAs).
directional multi-gigabit (DMG) frame: A frame transmitted or received within a DMG physical layer
(PHY) protocol data unit (PPDU).
directional multi-gigabit (DMG) physical layer (PHY) protocol data unit (PPDU): A Clause 20 PPDU.
directional multi-gigabit (DMG) station (STA): A STA whose radio transmitter is capable of transmitting
and receiving DMG physical layer (PHY) protocol data units (PPDUs).
directional transmission: A transmission that does not use an omnidirectional antenna pattern or quasi-
omni antenna pattern.
downlink: A unidirectional link from an access point (AP) to one or more non-AP stations (STAs) or a
unidirectional link from a non-AP destination directional multi-gigabit (DMG) STA to a non-AP source
DMG STA.
downlink multi-user multiple input, multiple output (DL-MU-MIMO): A technique by which an access
point (AP) with more than one antenna transmits a physical layer (PHY) protocol data unit (PPDU) to
multiple receiving non-AP stations (STAs) over the same radio frequencies, wherein each non-AP STA
simultaneously receives one or more distinct space-time streams.
dynamic bandwidth operation: A feature of a very high throughput (VHT) station (STA) in which the
request-to-send/clear-to-send (RTS/CTS) exchange, using non-high-throughput (non-HT) duplicate physical
layer (PHY) protocol data units (PPDUs), negotiates a potentially reduced channel width (compared to the
channel width indicated by the RTS) for subsequent transmissions within the current transmission
opportunity (TXOP).
dynamic frequency selection (DFS) owner: A station (STA) in an independent basic service set (IBSS) or
off-channel tunneled direct link setup (TDLS) direct link that takes responsibility for selecting the next
channel after radar is detected operating in a channel. Due to the nature of IBSSs, it cannot be guaranteed
that there is a single DFS owner at any particular time and the protocol is robust to this situation.
EAPOL-Key confirmation key (KCK): A key used to integrity-check an EAPOL-Key frame.
148
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
EAPOL-Key encryption key (KEK): A key used to encrypt the Key Data field in an EAPOL-Key frame.
EAPOL-Key frame: A Data frame that carries all or part of an IEEE 802.1X EAPOL PDU of type EAPOL-
Key.
EAPOL-Key request frame: A Data frame that carries all of part of an IEEE 802.1X EAPOL-Key protocol
data unit (PDU) with the Request bit in the Key Information field in the IEEE 802.11 key descriptor set to 1.
EAPOL-Start frame: A Data frame that carries all or part of an IEEE 802.1X EAPOL PDU of type
EAPOL-Start.
emergency services association: A robust security network association (RSNA) between an access point
(AP) and a non-AP station (STA) without security credentials; the non-AP STA is granted access to
emergency services using unprotected frames via this association.
enhanced distributed channel access (EDCA): The prioritized carrier sense multiple access with collision
avoidance (CSMA/CA) access mechanism used by quality-of-service (QoS) stations (STAs) in a QoS basic
service set (BSS) and STAs operating outside the context of a BSS. This access mechanism is also used by
the QoS access point (AP) and operates concurrently with hybrid coordination function (HCF) controlled
channel access (HCCA).
enhanced distributed channel access function (EDCAF): A logical function in a quality-of-service (QoS)
station (STA) that determines, using enhanced distributed channel access (EDCA), when a frame in the
transmit queue with the associated access category (AC) is permitted to be transmitted via the wireless
medium (WM). There is one EDCAF per AC.
extended centralized access point (AP) or personal basic service set (PBSS) control point (PCP)
cluster (ECAPC): The collection of 1) a single centralized coordination service set (CCSS), 2) the set of
centralized AP or PCP clusters such that each synchronization AP (S-AP) of a centralized AP or PCP cluster
is within the CCSS, and 3) all stations (STAs) within the basic service sets (BSSs) of the S-APs and member
APs and PCPs of the centralized AP or PCP clusters.
extended channel switching (ECS): A procedure that is used to announce a pending change of operating
channel, operating class, or both.
extended rate physical layer (ERP): A physical layer (PHY) compliant with Clause 18.
extended rate physical layer (PHY) using complementary code keying (CCK) modulation (ERP-
CCK): A mode of operation of a PHY operating under Clause 18 rules, where MODULATION=ERP-CCK.
extended rate physical layer (PHY) using direct sequence spread spectrum (DSSS) modulation (ERP-
DSSS): A PHY operating under Clause 18 rules, where MODULATION=ERP-DSSS.
extended rate physical layer (PHY) using direct sequence spread spectrum (DSSS) or complementary
code keying (CCK) modulation (ERP-DSSS/CCK): A PHY operating under Clause 18 rules, where
MODULATION=ERP-CCK or MODULATION=ERP-DSSS.
extended rate physical layer (PHY) using orthogonal frequency division multiplexing (OFDM)
modulation (ERP-OFDM): A mode of operation of a PHY operating under Clause 18 rules, where
MODULATION=ERP-OFDM.
extended service set (ESS) link: In the context of an IEEE 802.11 medium access control (MAC) entity, a
connection path through the wireless medium between a non-access-point (non-AP) station (STA) and one
of the APs that is a member of the ESS.
149
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
fast basic service set (BSS) transition (FT) 4-way handshake: A pairwise key management protocol used
during FT initial mobility domain association. This handshake confirms mutual possession of a pairwise
master key, the PMK-R1, by two parties and distributes a group temporal key (GTK).
fast basic service set (BSS) transition (FT) initial mobility domain association: The first association or
first reassociation procedure within a mobility domain, during which a station (STA) indicates its intention
to use the FT procedures.
fast basic service set (BSS) transition (FT) originator: A station (STA) that initiates the FT protocol by
sending an FT Request frame or an Authentication frame with Authentication Algorithm Number field equal
to Fast BSS Transition.
fine timing measurement (FTM) procedure: A procedure that allows a station (STA) to determine its
distance from another STA.
flexible multicast service (FMS): A service that enables a non-access-point (non-AP) station (STA) to
request a multicast delivery interval longer than the delivery traffic indication map (DTIM) interval for the
purposes of lengthening the period of time a STA can be in a power save state.
flexible multicast service (FMS) stream: A succession of frames transmitted by the access point (AP) that
correspond to a single flexible multicast stream identifier (FMSID).
flexible multicast service (FMS) stream set: A collection of FMS streams identified by the value of the
FMS Token field, used during the FMS Request procedure.
flexible multicast stream identifier (FMSID): An identifier assigned by the access point (AP) to a
particular group addressed stream subsequent to a successful FMS Request.
fragmentation: The process of partitioning a medium access control (MAC) service data unit (MSDU) or
MAC management protocol data unit (MMPDU) into a sequence of smaller MAC protocol data units
(MPDUs) prior to transmission. The process of recombining a set of fragment MPDUs into an MSDU or
MMPDU is known as defragmentation. These processes are described in 5.8.1.9 of ISO/IEC 7498-1:1994.
future channel guidance: future channel guidance communicates likely future channel information so that
STAs can efficiently move their activity when the absence of Beacon frames is noticed.
geolocation database (GDB): A database whose operation is mandated or authorized by a regulatory
authority and that organizes storage of information by geographic location.
geolocation database dependent (GDD): A modifier describing when station (STA) operation is
dependent on information received from a geolocation database (GDB).
geolocation database dependent (GDD) access point (AP): A station (STA) dependent on information
received from a geolocation database (GDB) in order to initiate and maintain a network.
geolocation database dependent (GDD) dependent station (STA): A STA that is under the control of a
GDD enabling STA.
geolocation database dependent (GDD) enabling station (STA): A STA that has the authority to control
the operation of GDD dependent STAs after obtaining available spectrum for use at its own location.
geolocation database dependent (GDD) fixed station (STA): A STA whose geographical location
information is fixed and maintained in a geolocation database (GDB) and whose operation depends on
information received from that database.
150
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
geolocation database dependent (GDD) geolocated non-access point (non-AP) station (STA): A STA
that is not an AP and is authorized by a geolocation database (GDB) to operate at its current location.
geolocation database dependent (GDD) non-access point (non-AP) station (STA): A STA that is not an
AP but operates under the control of a GDD enabling STA.
generic advertisement service (GAS): An over-the-air transportation service that provides over-the-air
transportation for frames of higher layer advertisements between stations (STAs) or between an
advertisement server and a non-access-point (non-AP) STA. The protocol(s) used to relay frames between
an AP, portal, and advertisement server is outside the scope of this standard. GAS supports higher layer
protocols that employ a query/response mechanism.
global operating class: An operating class value that is any of the non-reserved values in Table E-4.
group addressed bufferable unit (BU): A group addressed medium access control (MAC) service data unit
(MSDU) or group addressed bufferable MAC management protocol data unit (MMPDU).
group addressed quality-of-service management frame (GQMF): A group addressed Management
frame that is transmitted using the quality-of-service management frame (QMF) service.
group addressed transmission service (GATS): A mechanism comprising directed multicast service
(DMS) and groupcast with retries (GCR), for delivery of group addressed frames.
group key handshake: A group key management protocol defined by this standard. It is used only to issue
a new group temporal key (GTK) to peers with whom the local station (STA) has already formed security
associations.
group temporal key security association (GTKSA): The context resulting from a successful group
temporal key (GTK) distribution exchange via either a group key handshake or a 4-way handshake.
groupcast with retries (GCR) active (GCR-A) delivery: A delivery method for a group addressed stream
subject to a GCR agreement wherein the frames are transmitted without regard to the power state of non-
access-point (non-AP) stations (STAs).
groupcast with retries (GCR) concealment address: A medium access control (MAC) address that is used
to prevent group addressed frames transmitted via the GCR unsolicited retry or GCR block ack
retransmission policies from being passed up the medium access control service access point (MAC SAP) of
GCR-incapable stations (STAs).
groupcast with retries (GCR) frame: A group addressed frame subject to a GCR agreement between the
access point (AP) and at least one station (STA) within the infrastructure basic service set (BSS) or between
peer mesh STAs in a mesh BSS.
groupcast with retries (GCR) group address: A group address subject to a GCR agreement between the
access point (AP) and at least one station (STA) within the basic service set (BSS) or between peer mesh
STAs in a mesh BSS.
groupcast with retries (GCR) service: A means for transmission and retransmission of medium access
control (MAC) service data units (MSDUs) to a destination that is a group address. The GCR service
provides greater reliability by using group addressed retransmissions, concealed from GCR-incapable
stations (STAs).
151
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
groupcast with retries (GCR) service period (GCR-SP) aggregate medium access control (MAC)
service data unit (A-MSDU): An A-MSDU subject to the GCR service with the delivery method equal to
GCR-SP.
groupcast with retries (GCR) service period (GCR-SP) frame: A frame subject to the GCR service when
the delivery method is GCR-SP.
groupcast with retries (GCR) service period (GCR-SP) medium access control (MAC) service data
unit (MSDU): An MSDU subject to the GCR service with the delivery method equal to GCR-SP.
groupcast with retries (GCR) transmission opportunity (TXOP): An interval of time during which an
access point (AP) or a mesh station (STA) has the right to initiate frame exchange sequences onto the
wireless medium (WM) for the purpose of transmitting multiple frames that are subject to the GCR service.
high-throughput (HT) basic service set (BSS): A BSS in which Beacon frames transmitted by an HT
station (STA) include the HT Capabilities element.
high-throughput (HT) beamformee: An HT station (STA) that receives an HT physical layer (PHY)
protocol data unit (PPDU) that was transmitted using a beamforming steering matrix and that supports an
HT transmit beamforming feedback mechanism.
high-throughput (HT) beamformer: An HT station (STA) that transmits an HT physical layer (PHY)
protocol data unit (PPDU) using a beamforming steering matrix.
high-throughput (HT) delayed (HT-delayed) block acknowledgment (Ack): A delayed block ack
mechanism that requires the use of the compressed BlockAck frame and the No Acknowledgment ack
policy setting within both BlockAckReq and BlockAck frames. This block ack scheme is negotiated
between two HT stations (STAs) that both support HT-delayed block ack.
high-throughput (HT) greenfield (HT-greenfield) format: A physical layer (PHY) protocol data unit
(PPDU) format of the HT PHY using the HT-greenfield format preamble. This format is represented at the
PHY data service access point (SAP) by the TXVECTOR/RXVECTOR FORMAT parameter being equal to
HT_GF.
high-throughput (HT) immediate (HT-immediate) block acknowledgment (Ack): An immediate block
ack mechanism that requires the use of the compressed BlockAck frame and an implicit block ack request
and allows partial-state operation at the recipient. This block ack scheme is negotiated between two HT or
directional multi-gigabit (DMG) stations (STAs).
high-throughput (HT) mixed (HT-mixed) format: A physical layer (PHY) protocol data unit (PPDU)
format of the HT PHY using the HT-mixed format preamble. This format is represented at the PHY data
service access point (SAP) by the TXVECTOR/RXVECTOR FORMAT parameter being equal to HT_MF.
high-throughput (HT) modulation and coding scheme (HT-MCS): A specification of the HT physical
layer (PHY) parameters that consists of modulation order (e.g., BPSK, QPSK, 16-QAM, 64-QAM), forward
error correction (FEC) coding rate (e.g., 1/2, 2/3, 3/4, 5/6), and number of spatial streams (NSS) and that is
used in an HT PHY protocol data unit (PPDU).
high-throughput (HT) null data packet (NDP) announcement: A physical layer (PHY) protocol data unit
(PPDU) that contains one or more +HTC frames (i.e., frames with an HT Control field) that have the HT
NDP Announcement subfield equal to 1.
high-throughput (HT) physical layer (PHY) protocol data unit (PPDU): A Clause 19 PPDU with the
TXVECTOR FORMAT parameter equal to HT_MF or HT_GF.
152
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
high-throughput (HT) station (STA) 2G4: An HT STA that is also a STA 2G4.
high-throughput (HT) station (STA) 5G: An HT STA that is also a STA 5G.
hybrid coordination function (HCF): A coordination function that combines and enhances aspects of the
contention based and contention free access methods to provide quality-of-service (QoS) stations (STAs)
with prioritized and parameterized QoS access to the wireless medium (WM), while continuing to support
non-QoS STAs for best-effort transfer. The HCF includes the functionality provided by both enhanced
distributed channel access (EDCA) and HCF controlled channel access (HCCA).
hybrid coordination function (HCF) controlled channel access (HCCA): The channel access mechanism
utilized by the hybrid coordinator (HC) to coordinate contention free media use by quality-of-service (QoS)
stations (STAs) for downlink individually addressed, uplink, and direct-link transmissions.
hybrid coordinator (HC): A type of coordinator, defined as part of the quality-of-service (QoS) facility,
that implements the frame exchange sequences and medium access control (MAC) service data unit
(MSDU) handling rules defined by the hybrid coordination function (HCF).
IEEE 802.11 station (STA): Any station that is compliant with IEEE Std 802.11. Any reference to the term
station (STA) in this standard that is not qualified by the term IEEE 802.11 implicitly refers to an
IEEE 802.11 station.
individually addressed bufferable unit (BU): An individually addressed medium access control (MAC)
service data unit (MSDU), individually addressed aggregate MAC service data unit (A-MSDU) [high-
throughput (HT) stations (STAs) and directional multi-gigabit (DMG) STAs only], or individually
addressed bufferable MAC management protocol data unit (MMPDU).
individually addressed quality-of-service management frame (IQMF): An individually addressed
Management frame that is transmitted using the quality-of-service management frame (QMF) service.
interworking service: A service that supports use of an IEEE 802.11 network with non-IEEE-802.11
networks. Functions of the interworking service assist non-access-point (non-AP) stations (STAs) in
discovering and selecting IEEE 802.11 networks, in using appropriate quality-of-service (QoS) settings for
transmissions, in accessing emergency services, and in connecting to subscription service providers (SSPs).
key counter: A 256-bit (32-octet) counter that is used in the pseudorandom function (PRF) to generate
initialization vectors (IVs). There is a single key counter per station (STA) that is global to that STA.
key data encapsulation (KDE): A format for data other than elements in the EAPOL-Key Data field.
key management service: A service to distribute and manage cryptographic keys within a robust security
network (RSN).
light sleep mode: A mesh power management mode with respect to a neighbor peer mesh STA in which a
mesh station (STA) alternates between awake and doze states and is expected to receive beacons from this
neighbor peer mesh STA.
link: In the context of an IEEE 802.11 medium access control (MAC) entity, a physical path consisting of
exactly one traversal of the wireless medium (WM) that is usable to transfer MAC service data units
(MSDUs) between two stations (STAs).
location configuration information (LCI): As defined in IETF RFC 6225: includes latitude, longitude, and
altitude, with uncertainty indicators for each.
153
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
medium access control (MAC) management protocol data unit (MMPDU): The unit of data exchanged
between two peer MAC entities, using services of the physical layer (PHY), to implement the MAC
management protocol. The MMPDU is transported in one or more Management frames. The MMPDU
might include a Mesh Control field or management message integrity code element (Management MIC
element), but does not include a MAC header, a frame check sequence (FCS), or any other security
encapsulation overhead.
NOTE—The MMPDU occupies a position in the management plane similar to that of the MAC service data unit
(MSDU) in the data plane. An MSDU or MMPDU is transmitted in one or more MAC protocol data units (MPDUs)
(with the Type field set to Data or Management, respectively). An MSDU can be carried in an aggregate MAC service
data unit (A-MSDU). An A-MSDU is transmitted in one MPDU. An MSDU, A-MSDU, or MMPDU can be carried (in
an MPDU) in an A-MPDU.
mesh awake window: A period of time during which the mesh station (STA) operates in awake state after
its Beacon or Probe Response frame transmission that contained the Mesh Awake Window element.
mesh coordination function (MCF): A coordination function that combines aspects of the contention
based and scheduled access methods. The MCF includes the functionality provided by both enhanced
distributed channel access (EDCA) and MCF controlled channel access (MCCA).
mesh coordination function (MCF) controlled channel access (MCCA): A coordination function for the
mesh basic service set (MBSS).
mesh coordination function (MCF) controlled channel access opportunity (MCCAOP): A period of
time scheduled for frame transmissions between mesh stations (STAs) using MCF controlled channel access
(MCCA).
mesh Data frame: A Data frame that is transmitted by a mesh station (STA).
mesh peer service period: A period of time during which one or more individually addressed frames are
transmitted between two peer mesh stations (STAs) with at least one of those mesh STAs operating in light
sleep or deep sleep mode. A mesh peer service period is directional and might contain one or more
transmission opportunities (TXOPs).
mesh peer service period owner: A mesh station (STA) that obtains transmission opportunities (TXOPs),
transmits individually addressed frames to the recipient mesh STA in the mesh peer service period, and
terminates the mesh peer service period.
mesh peering management: A group of protocols to facilitate mesh peering establishment and closure.
mesh power management mode: The activity level identifier of a mesh station (STA) set per mesh peering
or for nonpeer neighbor STAs. A lower activity level enables a mesh STA to reduce its power consumption.
mesh power management mode tracking: Operation to observe the peering-specific mesh power
management modes from the peer mesh STAs and to maintain the peering-specific mesh power
management modes for each peer mesh STA.
message integrity code (MIC) key: TKIP only: The portion of a transient key used to validate the integrity
of medium access control (MAC) service data units (MSDUs) or MAC protocol data units (MPDUs).
michael: The message integrity code (MIC) for the temporal key integrity protocol (TKIP).
minimum downlink transmission time (DTT) to uplink transmission time (UTT) [DTT2UTT] spacing:
The minimum time within a power save multi-poll (PSMP) sequence between the end of a station’s (STA’s)
PSMP-DTT and the start of its PSMP-UTT.
154
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
modulation and coding scheme (MCS): A specification of the physical layer (PHY) parameters that
consists of modulation order (e.g., BPSK, QPSK, 16-QAM, 64-QAM, and 256-QAM), forward error
correction (FEC) coding rate (e.g., 1/2, 2/3, 3/4, 5/6), and, depending on the context, the number of space-
time streams.
modulation and coding scheme 32 (MCS 32) format: A physical layer (PHY) protocol data unit (PPDU)
format of the high-throughput (HT) PHY in which signals in two halves of the occupied channel width
contain the same information. This HT PPDU format supports the lowest rate.
modulation and coding scheme (MCS) feedback (MFB) requester: A station (STA) that transmits a
physical layer (PHY) protocol data unit (PPDU) containing an HT Control field in which the MCS request
(MRQ) subfield is equal to 1.
modulation and coding scheme (MCS) feedback (MFB) responder: A station (STA) that transmits a
physical layer (PHY) protocol data unit (PPDU) containing an HT Control field with the MFB field
containing an MCS index or the value 127 in response to a PPDU containing an HT Control field in which
the MCS request (MRQ) subfield is equal to 1.
multiple basic service set identifier (BSSID) set: A collection of cooperating access points (APs), such
that all of the APs use a common operating class, channel, and antenna connector.
multiple medium access control (MAC) sublayers link (MMSL): A link between two stations (STAs),
wherein one of the STAs is coordinated by a multiple MAC station management entity (MM-SME) that
delivered a Multiple MAC Sublayers (MMS) element to the peer STA.
multiple medium access control (MAC) sublayers link (MMSL) cluster: The set of all MMSLs between
a pair of stations (STAs).
multi-user (MU) beamformee: A non-access-point (non-AP) station (STA) that receives a physical layer
(PHY) protocol data unit (PPDU) that was transmitted using a multi-user beamforming steering matrix and
that supports the very high throughput (VHT) transmit beamforming feedback mechanism with a VHT null
data packet (NDP) Announcement frame that includes more than one STA Info field.
multi-user (MU) beamformer: An access point (AP) that transmits a physical layer (PHY) protocol data
unit (PPDU) using a multi-user beamforming steering matrix.
multi-user (MU) physical layer (PHY) protocol data unit (PPDU): A PPDU that carries one or more
PHY service data units (PSDUs) for one or more stations (STAs) using the downlink multi-user multiple
input, multiple output (DL-MU-MIMO) technique.
no acknowledgment/no retry (No-Ack/No-Retry): A retransmission policy for group addressed frames in
which each frame is transmitted once and without acknowledgment.
non-40-MHz-capable (non-40MC) high-throughput (HT) station (STA): A STA that is not a 40-MHz-
capable (40MC) HT STA.
nonaggregate medium access control (MAC) protocol data unit (non-A-MPDU) frame: A frame that is
transmitted in a physical layer (PHY) protocol data unit (PPDU) with the TXVECTOR AGGREGATION
parameter either absent or equal to NOT_AGGREGATED.
nonbandwidth signaling transmitter address (TA): An address in the TA field of an medium access
control (MAC) protocol data unit (MPDU) in which the Individual/Group bit has the value 0.
155
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
nonbufferable medium access control (MAC) management protocol data unit (MMPDU): An
MMPDU that is not a bufferable MMPDU.
nonconcealed groupcast with retries (GCR) frame: A group addressed frame that is not transmitted to the
GCR concealment address.
nonextended rate physical layer (NonERP): A physical layer (PHY) compliant with Clause 15 or
Clause 16, but not with Clause 18.
nongroupcast with retries (non-GCR): A method for delivering group addressed frames without using the
groupcast with retries (GCR) unsolicited retry retransmission policy, the GCR block acknowledgment
retransmission policy, or the GCR service period (GCR-SP) delivery method.
nongroupcast with retries service period (non-GCR-SP): A method for the delivery of group addressed
frames without the use of a groupcast with retries service period (GCR-SP).
non-high-throughput (non-HT): A modifier meaning neither high throughput (HT) nor very high
throughput (VHT).
non-high-throughput (non-HT) duplicate: A transmission format of the physical layer (PHY) that
duplicates a 20 MHz non-HT transmission in two or more 20 MHz channels and allows a station (STA) in a
non-HT basic service set (BSS) on any one of the 20 MHz channels to receive the transmission. A non-HT
duplicate format is one of the following:
a) 40 MHz non-HT duplicate: A transmission format of the PHY that replicates a 20 MHz non-HT
transmission in two adjacent 20 MHz channels.
b) 80 MHz non-HT duplicate: A transmission format of the PHY that replicates a 20 MHz non-HT
transmission in four adjacent 20 MHz channels.
c) 160 MHz non-HT duplicate: A transmission format of the PHY that replicates a 20 MHz non-HT
transmission in eight adjacent 20 MHz channels.
d) 80+80 MHz non-HT duplicate: A transmission format of the PHY that replicates a 20 MHz non-HT
transmission in two frequency segments of four adjacent 20 MHz channels where the two frequency
segments of channels are not adjacent.
non-high-throughput (non-HT) duplicate frame: A frame transmitted in a non-HT duplicate physical
layer (PHY) protocol data unit (PPDU).
non-high-throughput (non-HT) duplicate in television white spaces (TVWS) band: A transmission
format of the physical layer (PHY) that duplicates a single basic channel unit (BCU) non-HT transmission in
two or more BCUs and allows a station (STA) in a non-HT basic service set (BSS) on any one BCU to
receive the transmission. A non-HT duplicate format is one of the following:
a) TVHT_W non-HT duplicate: A PHY transmission that replicates a non-HT PHY protocol data unit
(PPDU) two times in a single BCU
b) TVHT_2W non-HT duplicate: A PHY transmission that replicates a non-HT PPDU four times in
two contiguous BCUs
c) TVHT_4W non-HT duplicate: A PHY transmission that replicates a non-HT PPDU eight times in
four contiguous BCUs
d) TVHT_W+W non-HT duplicate: A PHY transmission that replicates a non-HT PPDU two times in
each single BCU
e) TVHT_2W+2W non-HT duplicate: A PHY transmission that replicates a non-HT PPDU four times
in each of two contiguous BCUs
156
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
non-high-throughput (non-HT) duplicate physical layer (PHY) protocol data unit (PPDU): A PPDU
transmitted by a Clause 19 or Clause 21 PHY with the TXVECTOR FORMAT parameter equal to
NON_HT and the CH_BANDWIDTH parameter equal to NON_HT_CBW40, CBW40, CBW80, CBW160,
or CBW80+80.
non-high-throughput (non-HT) duplicate physical layer (PHY) protocol data unit (PPDU) in
television white spaces (TVWS) band: A PPDU transmitted by a Clause 22 PHY with the TXVECTOR
parameter FORMAT set to NON_HT and the TXVECTOR parameter CH_BANDWIDTH set to TVHT_W,
TVHT_2W, TVHT_4W, TVHT_W+W, or TVHT_2W+2W.
non-high-throughput (non-HT) physical layer (PHY) protocol data unit (PPDU): A PPDU that is
transmitted by Clause 15, Clause 16, Clause 17, or Clause 18 PHY, or not using a TXVECTOR FORMAT
parameter equal to HT_MF, HT_GF or VHT.
non-high-throughput (non-HT) SIGNAL field (L-SIG) transmit opportunity (TXOP) protection: A
protection mechanism in which protection is established by the non-HT SIG Length and Rate fields
indicating a duration that is longer than the duration of the PPDU itself.
nonpeer mesh power management mode: The activity level identifier of a mesh station (STA) toward
nonpeer neighbor mesh STAs. Two nonpeer mesh power management modes are defined: active mode and
deep sleep mode.
non-personal basic service set (BSS) control point (non-PCP) station (STA): A STA that is not a
personal BSS control point (PCP).
non-phased-coexistence-operation-capable (non-PCO-capable) 20/40 station (STA): A high-throughput
(HT) STA that included a value of 1 in the Supported Channel Width Set subfield (indicating its capability
to operate on a 40 MHz channel) of its most recent transmission of a frame containing an HT Capabilities
element and that sets the PCO field in the HT Extended Capabilities field to 0.
nonprimary channel: In a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz very high throughput (VHT) basic
service set (BSS), any 20 MHz channel other than the primary 20 MHz channel.
non-quality-of-service management frame (non-QMF) access point (AP): An AP that does not
implement the quality-of-service management frame (QMF) service.
non-quality-of-service management frame (non-QMF) station (STA): A STA that does not implement
the quality-of-service management frame (QMF) service.
non-space-time-block-coding (non-STBC) frame: A frame that is transmitted in a physical layer (PHY)
protocol data unit (PPDU) that has the TXVECTOR STBC parameter equal to 0, or a frame that is received
in a PPDU that has the RXVECTOR STBC parameter equal to 0.
nontransmitted basic service set (BSS) identifier (BSSID): A BSSID that is not transmitted explicitly, but
that can be derived from the information encoded in Probe Response, Beacon and directional multi-gigabit
(DMG) Beacon frames and Neighbor reports.
null data packet (NDP): A physical layer (PHY) protocol data unit (PPDU) that carries no Data field.
off-channel: A channel used by a tunneled direct link setup (TDLS) station (STA) that does not overlap the
channel(s) used by the access point (AP) with which the TDLS STA is associated.
operating class: An E.1 index into a set of values for radio operation in a regulatory domain.
157
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
operational rate set: The set of data rates that a station (STA) is capable of receiving. The operational rate
set is defined locally by the OperationalRateSet parameter of the MLME-START.request or MLME-
JOIN.request primitive. The operational rate set of a peer is defined by the data rates (i.e., excluding the
MSB of each octet of the (Extended) Supported Rates field) from the peer’s Supported Rates and BSS
Membership Selectors element and, if present, the Extended Supported Rates and BSS Membership
Selectors element.
outside the context of a basic service set (BSS) (OCB): A mode of operation in which a STA is not a
member of a BSS and does not utilize IEEE 802.11 authentication, association, or data confidentiality
services.
pairwise master key (PMK): The key derived from a key generated by an Extensible Authentication
Protocol (EAP) method or obtained directly from a preshared key (PSK).
pairwise master key (PMK) R0 key holder (R0KH): The component of robust security network
association (RSNA) key management of the Authenticator that is authorized to derive and hold the
PMK-R0, derive the PMK-R1s, and distribute the PMK-R1s to the R1KHs.
pairwise master key (PMK) R0 key holder identifier (R0KH-ID): An identifier that names the holder of
the PMK-R0 in the Authenticator.
pairwise master key (PMK) R0 name (PMKR0Name): An identifier that names the PMK-R0.
pairwise master key (PMK) R0 (PMK-R0): The key at the first level of the fast basic service set (BSS)
transition (FT) key hierarchy.
pairwise master key (PMK) R1 key holder (R1KH): The component of robust security network
association (RSNA) key management of the Authenticator that receives a PMK-R1 from the R0KH, holds
the PMK-R1, and derives the pairwise transient keys (PTKs).
pairwise master key (PMK) R1 key holder identifier (R1KH-ID): An identifier that names the holder of
a PMK-R1 in the Authenticator.
pairwise master key (PMK) R1 name (PMKR1Name): An identifier that names a PMK-R1.
pairwise master key (PMK) R1 (PMK-R1): A key at the second level of the fast basic service set (BSS)
transition (FT) key hierarchy.
pairwise master key (PMK) S0 key holder (S0KH): The component of robust security network
association (RSNA) key management of the Supplicant that derives and holds the PMK-R0, derives the
PMK-R1s, and provides the PMK-R1s to the S1KH.
pairwise master key (PMK) S0 key holder identifier (S0KH-ID): An identifier that names the holder of
the PMK-R0 in the Supplicant.
pairwise master key (PMK) S1 key holder (S1KH): The component of robust security network
association (RSNA) key management in the Supplicant that receives a PMK-R1 from the S0KH, holds the
PMK-R1, and derives the pairwise transient keys (PTKs).
pairwise master key (PMK) S1 key holder identifier (S1KH-ID): An identifier that names the holder of
the PMK-R1 in the Supplicant.
158
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
pairwise master key security association (PMKSA): The context resulting from a successful IEEE
802.1X authentication exchange between the peer and Authentication Server (AS) or from a preshared key
(PSK).
pairwise transient key (PTK): A concatenation of session keys derived from the pairwise master key
(PMK) or from the PMK-R1. Its components are a key confirmation key (KCK), a key encryption key
(KEK), and a temporal key (TK), which is used to protect information exchanged over the link.
pairwise transient key (PTK) name (PTKName): An identifier that names the PTK.
pairwise transient key security association (PTKSA): The context resulting from a successful 4-way
handshake between a peer and Authenticator.
parameterized quality of service (QoS): The treatment of the medium access control (MAC) protocol data
units (MPDUs) depends on the parameters associated with the MPDU. Parameterized QoS is primarily
provided through the hybrid coordination function (HCF) controlled channel access (HCCA) mechanism,
but is also provided by the enhanced distributed channel access (EDCA) mechanism when used with a
traffic specification (TSPEC) for admission control.
payload protected (PP) aggregate medium access control (MAC) service data unit (A-MSDU): An
A-MSDU that is protected with counter mode (CTR) with cipher-block chaining message authentication
code (CBC-MAC) protocol (CCMP) or Galois/counter mode (GCM) protocol (GCMP) but does not include
the A-MSDU Present field (bit 7 of the QoS Control field) in the construction of the additional
authentication data (AAD).
peer trigger frame: A Mesh Data or quality-of-service (QoS) Null frame that initiates a mesh peer service
period.
PeerKey handshake: A key management protocol composed of the station-to-station link (STSL) master
key (SMK) handshake and the 4-way STSL transient key (STK) handshake. This is used to create new SMK
security associations (SMKSAs) and STK security associations (STKSAs) to secure the STSLs.
peer-specific mesh power management mode: The activity level identifier of a mesh station (STA) set per
mesh peering. Three peer-specific mesh power management modes are defined: active mode, light sleep
mode, and deep sleep mode.
per-frame sequence counter: For temporal key integrity protocol (TKIP), the counter that is used as the
nonce in the derivation of the per-frame encryption key. For counter mode with cipher-block chaining
message authentication code protocol (CCMP) or Galois/counter mode (GCM) protocol (GCMP), the per-
frame initialization vector (IV).
personal basic service set (PBSS): A directional multi-gigabit (DMG) basic service set (BSS) that includes
one STA that is in a PBSS control point (PCP), and in which access to a distribution system (DS) is not
present.
personal basic service set (PBSS) control point (PCP): An entity that contains one station (STA) and
coordinates access to the wireless medium (WM) by STAs that are members of a PBSS.
personal basic service set (PBSS) control point (PCP) or access point (AP) cluster: A single directional
multi-gigabit (DMG) synchronization AP or synchronization PCP, plus zero or more neighboring DMG APs
or PCPs (or a mixture of both) that join as member APs and PCPs to the synchronization AP or
synchronization PCP.
159
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
phased coexistence operation (PCO): A basic service set (BSS) mode with alternating 20 MHz and
40 MHz phases controlled by an access point (AP).
phased coexistence operation (PCO) active access point (AP): A high-throughput (HT) AP that is
operating PCO.
phased coexistence operation (PCO) active basic service set (BSS): A BSS in which a PCO active access
point (AP) has the PCO Active field in the HT Operation element equal to 1.
phased coexistence operation (PCO) active non-access-point (non-AP) station (STA): A high-
throughput (HT) non-AP STA that is associated with a PCO basic service set (BSS) and following PCO.
phased coexistence operation (PCO) active station (STA): A STA that is either a PCO active access point
(AP) or a PCO active non-AP STA.
phased coexistence operation (PCO) capable (PCO-capable) access point (AP): A high-throughput (HT)
AP that sets the PCO field in the HT Extended Capabilities field to 1.
phased coexistence operation (PCO) capable (PCO-capable) non-access-point (non-AP) station
(STA): A high-throughput (HT) non-AP STA that sets the PCO field in the HT Extended Capabilities field
to 1.
phased coexistence operation (PCO) capable (PCO-capable) station (STA): A STA that is either a PCO
capable access point (AP) or a PCO capable non-AP STA.
phased coexistence operation (PCO) inactive basic service set (BSS): A 20/40 MHz BSS in which an
access point (AP) has the PCO Active field in the HT Operation element equal to 0.
point coordination function (PCF): A class of possible coordination functions in which the coordination
function logic is active in only one station (STA) in a basic service set (BSS) at any given time that the
network is in operation.
point coordinator (PC): The entity within the STA in an AP that performs the point coordination function.
power save (PS) mode: A power management mode in which a nonmesh station (STA) alternates between
awake and doze states.
power save multi-poll (PSMP): A mechanism that provides a time schedule that is used by an access point
(AP) and its stations (STAs) to access the wireless medium. The mechanism is controlled using the PSMP
frame.
power save multi-poll (PSMP) burst: A series of one or more PSMP sequences, separated by short
interframe space (SIFS).
power save multi-poll downlink transmission time (PSMP-DTT): A period of time described by a PSMP
frame during which the access point (AP) transmits.
power save multi-poll (PSMP) sequence: A sequence of frames in which the first frame is a PSMP frame
that is followed by transmissions in zero or more power save multi-poll downlink transmission times
(PSMP-DTTs) and then by transmissions in zero or more power save multi-poll uplink transmission times
(PSMP-UTTs). The schedule of the PSMP-DTTs and PSMP-UTTs is defined in the PSMP frame.
power save multi-poll (PSMP) session: The relationship between an AP and one or more STAs that exists
while any TS exists that uses the PSMP mechanism with the same service period.
160
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
power save multi-poll uplink transmission time (PSMP-UTT): A period of time described by a PSMP
frame during which a non-access-point (non-AP) station (STA) can transmit.
power save multi-poll uplink transmission time (PSMP-UTT) spacing: The period of time between the
end of one PSMP-UTT and the start of the following PSMP-UTT within the same PSMP sequence.
power save (PS) station (STA): A station that is in power save mode.
pre-robust security network association (pre-RSNA): The type of association used by a pair of stations
(STAs) if the procedure for establishing authentication or association between them did not include the 4-
way handshake.
pre-robust security network association (pre-RSNA) STA: A STA that is not able to create robust
security network associations (RSNAs).
primary 20 MHz channel: In a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz very high throughput (VHT)
basic service set (BSS), the 20 MHz channel that is used to transmit 20 MHz physical layer (PHY) protocol
data units (PPDUs). In a VHT BSS, the primary 20 MHz channel is also the primary channel.
primary 40 MHz channel: In an 80 MHz, 160 MHz, or 80+80 MHz very high throughput (VHT) basic
service set (BSS), the 40 MHz channel that is used to transmit 40 MHz physical layer (PHY) protocol data
units (PPDUs).
primary 80 MHz channel: In a 160 MHz or 80+80 MHz very high throughput (VHT) basic service set
(BSS), the 80 MHz channel that is used to transmit 80 MHz physical layer (PHY) protocol data units
(PPDUs).
primary access category (AC): The AC associated with the enhanced distributed channel access function
(EDCAF) that gains channel access.
Protected Dual of Public Action frame: An Action frame with the category value specified in 9.4.1.11
(Table 9-47). For each Protected Dual of Public Action frame, there is a dual Action frame in a category that
is specified with “No” in the “Robust” column of Table 9-47.
quality-of-service management frame (QMF): A Management frame that is transmitted using the QMF
service.
quality-of-service management frame (QMF) access point (AP): A quality-of-service AP that
implements the QMF service.
quality-of-service management frame (QMF) policy: A policy defining the access category of
Management frames. QMF stations (STAs) transmit their Management frames using the access category
defined by the policy.
quality-of-service management frame (QMF) service: A service in which the enhanced distributed
channel access (EDCA) access category with which a Management frame is sent is determined according to
a configured policy.
quality-of-service management frame (QMF) station (STA): A quality-of-service STA that implements
the QMF service.
quality-of-service (QoS) frame: A frame containing the QoS Control field.
161
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
quasi-omni antenna pattern: A directional multi-gigabit (DMG) antenna operating mode with the widest
beamwidth attainable.
receive sector sweep (RXSS): Reception of Sector Sweep (SSW) frames via different sectors, in which a
sweep is performed between consecutive receptions.
received signal-to-noise indicator (RSNI): An indication of the signal-to-noise plus interference ratio of a
received frame.
resource information container (RIC): A sequence of elements that include resource request and response
parameters.
reverse direction (RD) initiator: A station (STA) that is a transmit opportunity (TXOP) holder that
transmits a medium access control (MAC) protocol data unit (MPDU) in which the reverse direction grant/
more physical layer protocol data unit (RDG/More PPDU) subfield is equal to 1.
reverse direction (RD) responder: A station (STA) that is not the RD initiator and whose medium access
control (MAC) address matches the value of the Address 1 field of a received MAC protocol data unit
(MPDU) in which the RDG/More PPDU subfield is equal to 1.
robust Action frame: An Action frame with a category value specified in 9.4.1.11 (Table 9-47 with “Yes”
in the “Robust” column).
robust Management frame: A Management frame that is eligible for protection.
robust security network association (RSNA): The type of association used by a pair of stations (STAs) if
the procedure to establish authentication or association between them includes the 4-way handshake or FT
protocol. Note that existence of an RSNA between two STAs does not of itself provide robust security.
Robust security is provided when all STAs in the network use RSNAs.
robust security network association (RSNA) capable (RSNA-capable): Pertains to a station (STA) that is
able to create RSNAs.
robust security network association (RSNA) key management: Key management that includes the 4-way
handshake, the group key handshake, authenticated mesh peering exchange, mesh group key handshake, and
the PeerKey handshake. If fast basic service set (BSS) transition (FT) is enabled, the FT 4-way handshake
and FT authentication sequence are also included.
robust security network (RSN): A security network that allows only the creation of robust security
network associations (RSNAs). An RSN can be identified by the indication in the RSN element (RSNE) of
Beacon frames that the group cipher suite specified is not wired equivalent privacy (WEP).
scheduled service period (SP): An SP that is scheduled by a quality-of-service (QoS) access point (AP) or
a personal basic service set (PBSS) control point (PCP).
secondary 20 MHz channel: In a 40 MHz very high throughput (VHT) basic service set (BSS), the 20 MHz
channel adjacent to the primary 20 MHz channel that together form the 40 MHz channel of the 40 MHz
VHT BSS. In an 80 MHz VHT BSS, the 20 MHz channel adjacent to the primary 20 MHz channel that
together form the primary 40 MHz channel of the 80 MHz VHT BSS. In a 160 MHz or 80+80 MHz VHT
BSS, the 20 MHz channel adjacent to the primary 20 MHz channel that together form the primary 40 MHz
channel of the 160 MHz or 80+80 MHz VHT BSS. In a VHT BSS, the secondary 20 MHz channel is also
the secondary channel.
162
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
secondary 40 MHz channel: In an 80 MHz very high throughput (VHT) basic service set (BSS), the 40
MHz channel adjacent to the primary 40 MHz channel that together form the 80 MHz channel of the 80
MHz VHT BSS. In a 160 MHz or 80+80 MHz VHT BSS, the 40 MHz channel adjacent to the primary 40
MHz channel that together form the primary 80 MHz channel.
secondary 80 MHz channel: In a 160 MHz or 80+80 MHz very high throughput (VHT) basic service set
(BSS), the 80 MHz channel not including the primary 20 MHz channel, that together with the primary 80
MHz channel form the 160 MHz or 80+80 MHz channel of the 160 MHz or 80+80 MHz VHT BSS.
secondary access category (AC): An AC that is not associated with the enhanced distributed channel
access function (EDCAF) that gains channel access.
NOTE—Traffic associated with a secondary AC can be included in a multi-user (MU) physical layer (PHY) protocol
data unit (MU PPDU) that includes traffic associated with the primary AC. There could be multiple secondary ACs at a
given time.
secondary channel: A 20 MHz channel associated with a primary channel used by high-throughput (HT)
stations (STAs) for the purpose of creating a 40 MHz channel or used by very high throughput (VHT) STAs
for the purpose of creating the primary 40 MHz channel.
sector: A transmit or receive antenna pattern corresponding to a sector identifier (ID).
security network: A basic service set (BSS) in which the station (STA) starting the BSS provides
information about the security capabilities and configuration of the BSS by including the robust security
network element (RSNE) in Beacon frames.
self-protected action frame: An Action frame that is not eligible for protection by the robust management
frame service. The protection on each Self-protected Action frame is provided by the protocol that uses the
frame.
service interval (SI): The interval between the starts of two successive scheduled service periods (SPs).
service period (SP): A period of time during which one or more downlink individually addressed frames
are transmitted to a quality-of-service (QoS) station (STA) and/or one or more transmission opportunities
(TXOPs) are granted to the same STA. SPs are either scheduled or unscheduled.
NOTE—A non-access-point (non-AP) STA can have at most one nongroupcast with retries SP (non-GCR-SP) active at
any time.
shared bands: Radio frequency bands in which dissimilar services are permitted.
signaling and payload protected (SPP) aggregate medium access control (MAC) service data unit
(A-MSDU): An A-MSDU that is protected with counter mode (CTR) with cipher-block chaining message
authentication code (CBC-MAC) protocol (CCMP) or Galois/counter mode (GCM) protocol (GCMP) and
that includes the A-MSDU Present field (bit 7 of the QoS Control field) in the construction of the additional
authentication data (AAD).
sounding physical layer (PHY) protocol data unit (PPDU): A PPDU that is intended by the transmitting
station (STA) to enable the receiving STA to estimate the channel between the transmitting STA and the
receiving STA. The Not Sounding field in the High Throughput SIGNAL field (HT-SIG) is equal to 0 in
sounding PPDUs.
source directional multi-gigabit (DMG) station (STA): A DMG STA identified by the source association
identifier (AID) field contained in a Grant frame or Extended Schedule element that caused the allocation of
a service period (SP) or contention based access period (CBAP).
163
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
space-time block coding (STBC) beacon: A beacon that is transmitted using the basic STBC modulation
and coding scheme (MCS) to enable discovery of the basic service set (BSS) by high-throughput (HT)
stations (STAs) that support the HT STBC feature in order to extend the range of the BSS.
space-time block coding (STBC) delivery traffic indication map (DTIM): An STBC beacon
transmission that is a DTIM Beacon frame.
space-time block coding (STBC) frame: A frame that is transmitted in a physical layer (PHY) protocol
data unit (PPDU) that has a nonzero value of the TXVECTOR STBC parameter, or a frame that is received
in a PPDU that has a nonzero value of the RXVECTOR STBC parameter.
spatial sharing (SPSH): Use of a frequency channel by multiple stations (STAs) that are located in the
same vicinity, and whose directional transmissions might overlap in time.
staggered preamble: A physical layer (PHY) preamble in a sounding PHY protocol data unit (PPDU) that
is not a null data packet (NDP) and that includes one or more Data Long Training fields (DLTFs) and one or
more Extension Long Training fields (ELTFs).
staggered sounding: The use of a sounding physical layer (PHY) protocol data unit (PPDU) that is not a
null data packet (NDP) and that includes one or more Data Long Training fields (DLTFs) and one or more
Extension Long Training fields (ELTFs).
station (STA) 2G4: A STA that is operating on a channel that belongs to any operating class that has a value
of 25 or 40 for the entry in the “Channel spacing” column and that has a value of 2.407 or 2.414 for the entry
in the “Channel starting frequency” column of any of the tables found in E.1.
station (STA) 5G: A STA that is operating on a channel that belongs to any operating class that has a value
of 20 or 40 for the entry in the “Channel spacing” column and that has a value of 5 for the entry in the
“Channel starting frequency” column of any of the tables found in E.1.
station-to-station link (STSL): A direct link established between two non-access-point (non-AP) stations
(STAs) while associated to a common access point (AP), that was not established using tunneled direct-link
setup (TDLS).
station-to-station link (STSL) master key security association (SMKSA): The context resulting from a
successful STSL master key (SMK) handshake.
station-to-station link (STSL) master key (SMK): A random value generated by an access point (AP)
during an SMK handshake. It is used for deriving an STSL transient key (STK).
station-to-station link (STSL) master key (SMK) handshake: A key management protocol between two
parties that creates a new SMK.
station-to-station link (STSL) transient key security association (STKSA): The context resulting from a
successful 4-way STSL transient key (STK) exchange.
station-to-station link (STSL) transient key (STK): A concatenation of session keys derived from the
STSL master key (SMK). Its components are an STSL key confirmation key (SKCK), an STSL key
encryption key (SKEK), and a temporal key (TK), which is used to protect information exchanged over the
link.
subscription service provider (SSP) roaming: The act when a station (STA) uses an SSP’s IEEE 802.11
infrastructure, with which the terminal has no direct agreement, based on a subscription and formal
agreement with the STA’s own SSP.
164
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
successful transmission: A transmission and the reception of its expected acknowledgment or a
transmission for which no acknowledgment is expected.
sweep: A sequence of transmissions, separated by a short beamforming interframe space (SBIFS) interval,
in which the antenna configuration at the transmitter or receiver is changed between transmissions.
synchronization access point (AP) (S-AP): An AP that provides synchronization and other services to an
AP cluster or personal basic service set (PBSS) control point (PCP).
synchronization personal basic service set (PBSS) control point (PCP) (S-PCP): A PCP that provides
synchronization and other services to an access point (AP) cluster or PCP cluster.
television very high throughput 2W (TVHT_2W): Two contiguous basic channel units (BCUs) in
television white spaces (TVWS).
television very high throughput 2W+2W (TVHT_2W+2W): Two noncontiguous frequency segments,
each of which comprises two contiguous basic channel units (BCUs) in television white spaces (TVWS).
television very high throughput 4W (TVHT_4W): Four contiguous basic channel units (BCUs) in
television white spaces (TVWS).
television very high throughput (TVHT) basic service set (BSS): A set of stations (STAs) that consists of
a geolocation database dependent (GDD) enabling STA operating in television white spaces (TVWS) and
one or more of its GDD STAs.
television very high throughput W (TVHT_W): One basic channel unit in television white spaces
(TVWS).
television very high throughput W+W (TVHT_W+W): Two noncontiguous basic channel units (BCUs)
in television white spaces (TVWS).
temporal encryption key: The portion of a pairwise transient key (PTK) or group temporal key (GTK) used
directly or indirectly to encrypt data in medium access control (MAC) protocol data units (MPDUs).
temporal key (TK): Temporal key integrity protocol (TKIP) only: The combination of temporal encryption
key and a message integrity code (MIC) key. Non-TKIP only: A temporal encryption key.
time priority Management frame: a Management frame that is transmitted using specific frame type
channel access rules.
traffic indication map (TIM) broadcast: A service that enables a non-access-point (non-AP) station
(STA) to request periodic transmission of a TIM frame by the AP. TIM frames have shorter duration than
Beacon frames and can be transmitted at a higher physical layer (PHY) rate, which allows the STA to save
additional power while periodically checking for buffered traffic in standby mode, relative to the power
consumed if the station (STA) were to periodically wake up to receive a Beacon frame.
traffic stream identifier (TSID): Any of the identifiers usable by higher layer entities to distinguish
medium access control (MAC) service data units (MSDUs) to MAC entities for parameterized quality of
service (QoS) [i.e., the traffic stream (TS) with a particular traffic specification (TSPEC)] within the MAC
data service. The TSID is assigned to an MSDU in the layers above the MAC.
transition security network (TSN): A security network that allows the creation of pre-robust security
network associations (pre-RSNAs) as well as RSNAs. A TSN is identified by the indication in the robust
165
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
security network element (RSNE) of Beacon frames that the group cipher suite in use is wired equivalent
privacy (WEP).
transmission opportunity (TXOP) holder: A quality-of-service (QoS) station (STA) that has either been
granted a TXOP by the hybrid coordinator (HC) or successfully contended for a TXOP.
transmission opportunity (TXOP) responder: A station (STA) that transmits a frame in response to a
frame received from a TXOP holder during a frame exchange sequence, but that does not acquire a TXOP in
the process.
transmit power: The effective isotropic radiated power (EIRP) when referring to the operation of an
orthogonal frequency division multiplexing (OFDM) physical layer (PHY) in a country where so regulated.
transmit sector sweep (TXSS): Transmission of multiple sector sweep (SSW) or directional multi-gigabit
(DMG) Beacon frames via different sectors, in which a sweep is performed between consecutive
transmissions.
transmit sector sweep (TXSS) contention based access period (CBAP): A CBAP that is available to all
stations (STAs) in an extended centralized personal basic service set (PBSS) control point (PCP) or access
point (AP) cluster outside which TXSSs in the data transfer interval (DTI) can be prohibited.
transmitted basic service set identifier (BSSID): The BSSID included in the medium access control
(MAC) header transmitter address field of a Beacon frame when the multiple BSSID capability is supported.
trigger-enabled access category (AC): A quality-of-service (QoS) station (STA) AC where frames of
subtype QoS Data and QoS Null from the STA that map to the AC trigger an unscheduled service period
(SP) if one is not in progress.
tunneled direct-link setup (TDLS): A protocol that uses a specific Ethertype encapsulation to TDLS
frames through an access point (AP) to establish a TDLS direct link.
tunneled direct-link setup (TDLS) direct link: Direct link between two non-access-point (non-AP)
stations (STAs) that has been established using the TDLS protocol.
tunneled direct-link setup (TDLS) initiator station (STA): A STA that transmits a TDLS Setup Request
frame or a TDLS Discovery Request frame.
tunneled direct-link setup (TDLS) peer power save mode (PSM): A PSM that is based on periodically
scheduled service periods (SPs), which can be used between two stations (STAs) that have set up a TDLS
direct link.
tunneled direct-link setup (TDLS) peer power save mode (PSM) initiator: A station (STA) that
transmits a TDLS Peer PSM Request frame.
tunneled direct-link setup (TDLS) peer power save mode (PSM) responder: A station (STA) that
transmits a TDLS Peer PSM Response frame.
tunneled direct-link setup (TDLS) peer station (STA): A STA with a TDLS direct link.
tunneled direct-link setup (TDLS) peer unscheduled automatic power save delivery (U-APSD) [TDLS
peer U-APSD (TPU)]: A power save mode based on unscheduled service periods that can be used between
two stations (STAs) that have set up a TDLS direct link.
166
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
tunneled direct-link setup (TDLS) peer unscheduled automatic power save delivery (U-APSD) [TDLS
peer U-APSD (TPU)] buffer station (STA): A TDLS peer STA that buffers traffic for a TPU sleep STA.
tunneled direct-link setup (TDLS) peer unscheduled automatic power save delivery (U-APSD) [TDLS
peer U-APSD (TPU)] sleep station (STA): A TDLS STA that entered power save mode on a TDLS direct
link and that is using TPU for the delivery of buffered traffic.
tunneled direct-link setup (TDLS) power save mode (PSM): TDLS peer PSM or peer unscheduled
automatic power save delivery (U-APSD).
tunneled direct-link setup (TDLS) responder station (STA): A STA that receives or is the intended
recipient of a TDLS Setup Request frame or TDLS Discovery Request frame.
TVHT_2W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
a) A Clause 22 TVHT_2W very high throughput (VHT) PPDU (TX_VECTOR parameter
CH_BANDWIDTH set to TVHT_2W and TXVECTOR parameter FORMAT set to VHT)
transmitted using the TVHT_2W transmit spectral mask defined in 22.3.17.1
b) A Clause 22 TVHT_2W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_2W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W
transmit spectral mask defined in 22.3.17.1
c) A Clause 22 TVHT_W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W
and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_2W transmit
spectral mask defined in 22.3.17.1
d) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W
transmit spectral mask defined in 22.3.17.1
TVHT_2W+2W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
a) A Clause 22 TVHT_2W+2W very high throughput (VHT) PPDU (TX_VECTOR parameter
CH_BANDWIDTH set to TVHT_2W+2W and TXVECTOR parameter FORMAT set to VHT)
transmitted using the TVHT_2W+2W transmit spectral mask defined in 22.3.17.1
b) A Clause 22 TVHT_2W+2W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_2W+2W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W+2W
transmit spectral mask defined in 22.3.17.1
c) A Clause 22 TVHT_2W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_2W and TXVECTOR parameter FORMAT set to VHT) transmitted using the
TVHT_2W+2W transmit spectral mask defined in 22.3.17.1
d) A Clause 22 TVHT_2W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_2W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W+2W
transmit spectral mask defined in 22.3.17.1
e) A Clause 22 TVHT_W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W
and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_2W+2W transmit
spectral mask defined in 22.3.17.1
f) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W+2W
transmit spectral mask defined in 22.3.17.1
167
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TVHT_4W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
a) A Clause 22 TVHT_4W very high throughput (VHT) PPDU (TX_VECTOR parameter
CH_BANDWIDTH set to TVHT_4W and TXVECTOR parameter FORMAT set to VHT)
transmitted using the TVHT_4W transmit spectral mask defined in 22.3.17.1
b) A Clause 22 TVHT_4W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_4W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_4W
transmit spectral mask defined in 22.3.17.1
c) A Clause 22 TVHT_2W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_2W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_4W
transmit spectral mask defined in 22.3.17.1
d) A Clause 22 TVHT_2W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_2W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_4W
transmit spectral mask defined in 22.3.17.1
e) A Clause 22 TVHT_W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W
and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_4W transmit
spectral mask defined in 22.3.17.1
f) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_4W
transmit spectral mask defined in 22.3.17.1
TVHT_MODE_1 physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A
Clause 22 TVHT_W VHT PPDU or TVHT_W NON_HT PPDU.
TVHT_MODE_2C physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A
Clause 22 TVHT_2W VHT PPDU or TVHT_2W NON_HT PPDU.
TVHT_MODE_2N physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A
Clause 22 TVHT_W+W VHT PPDU or TVHT_W+W NON_HT PPDU.
TVHT_MODE_4C physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A
Clause 22 TVHT_4W VHT PPDU or TVHT_4W NON_HT PPDU.
TVHT_MODE_4N physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A
Clause 22 TVHT_2W+2W VHT PPDU or TVHT_2W+2W NON_HT PPDU.
TVHT_W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
a) A Clause 22 TVHT_W very high throughput (VHT) PPDU (TX_VECTOR parameter
CH_BANDWIDTH set to TVHT_W and TXVECTOR parameter FORMAT set to VHT)
transmitted using the TVHT_W transmit spectral mask defined in 22.3.17.1
b) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_W
transmit spectral mask defined in 22.3.17.1
TVHT_W+W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs:
a) A Clause 22 TVHT_W+W very high throughput (VHT) PPDU (TX_VECTOR parameter
CH_BANDWIDTH set to TVHT_W+W and TXVECTOR parameter FORMAT set to VHT)
transmitted using the TVHT_W+W transmit spectral mask defined in 22.3.17.1
168
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) A Clause 22 TVHT_W+W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_W+W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_W+W
transmit spectral mask defined in 22.3.17.1
c) A Clause 22 TVHT_W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W
and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_W+W transmit
spectral mask defined in 22.3.17.1
d) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to
TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter
NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_W+W
transmit spectral mask defined in 22.3.17.1
unscheduled service period (SP): The period that is started when a quality-of-service (QoS) station (STA)
transmits a trigger frame to the QoS access point (AP).
uplink: A unidirectional link from a non-access point (non-AP) station (STA) to an access point (AP) or a
unidirectional link from a non-AP source directional multi-gigabit (DMG) STA to a non-AP destination
DMG STA.
user: An individual station or group of stations (STAs) identified by a single receive address (RA) in the
context of single-user multiple input, multiple output (SU-MIMO) or multi-user multiple input, multiple
output (MU-MIMO).
vendor organizationally unique identifier (OUI): An OUI that is not the IEEE 802.11 OUI (00-0F-AC)
very high throughput (VHT) basic service set (BSS): A BSS in which a Beacon frame transmitted by a
VHT station (STA) includes the VHT Operation element.
very high throughput (VHT) beamformee: A VHT station (STA) that receives a VHT physical layer
(PHY) protocol data unit (PPDU) that was transmitted using a beamforming steering matrix and that
supports the VHT transmit beamforming feedback mechanism.
very high throughput (VHT) beamformer: A VHT station (STA) that transmits a VHT physical layer
(PHY) protocol data unit (PPDU) using a beamforming steering matrix.
very high throughput (VHT) modulation and coding scheme (VHT-MCS): A specification of the VHT
physical layer (PHY) parameters that consists of modulation order (e.g., BPSK, QPSK, 16-QAM, 64-QAM,
256-QAM) and forward error correction (FEC) coding rate (e.g., 1/2, 2/3, 3/4, 5/6) and that is used in a VHT
PHY protocol data unit (PPDU).
very high throughput (VHT) multi-user (MU) physical layer (PHY) protocol data unit (PPDU): A
VHT PPDU with a format that is capable of carrying up to four PHY service data units (PSDUs) for up to
four users and is transmitted using the downlink multi-user multiple input, multiple output (DL-MU-MIMO)
technique.
very high throughput (VHT) physical layer (PHY) protocol data unit (PPDU): A PPDU transmitted
with the TXVECTOR parameter FORMAT equal to VHT.
very high throughput (VHT) single medium access control (MAC) protocol data unit (VHT single
MPDU): An MPDU that is the only MPDU in an aggregate MPDU (A-MPDU) carried in a VHT physical
layer (PHY) protocol data unit (PPDU) and that is carried in an A-MPDU subframe with the EOF subfield of
the MPDU delimiter field equal to 1.
169
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
very high throughput (VHT) single-user-only (SU-only) beamformee: A VHT beamformee that does not
receive VHT multi-user (MU) physical layer (PHY) protocol data units (PPDUs).
very high throughput (VHT) single-user-only (SU-only) beamformer: A VHT beamformer that does not
transmit VHT multi-user (MU) physical layer (PHY) protocol data units (PPDUs).
very high throughput (VHT) single-user (SU) physical layer (PHY) protocol data unit (PPDU): A
VHT PPDU transmitted with the TXVECTOR parameters FORMAT equal to VHT and GROUP_ID equal
to 0 or 63.
white space map (WSM): Information on identified available frequencies that is obtained from a
geolocation database (GDB) and that is used by IEEE 802.11 stations (STAs).
wired equivalent privacy (WEP): A deprecated cryptographic data confidentiality algorithm specified by
this standard.
wireless network management (WNM) sleep mode: An extended power save mode for non-access-point
(non-AP) stations (STAs) whereby a non-AP STA need not listen for every delivery traffic indication map
(DTIM) Beacon frame and does not perform group temporal key/integrity group temporal key (GTK/IGTK)
updates.
3.3 Definitions specific to IEEE 802.11 operation in some regulatory domains
ISO 3166-1 defines the international two-letter designation for country names, and these designations are
included [in square brackets] at the end of each definition that has clear attribution to a regulatory domain.
contact verification signal (CVS): A signal sent by a geolocation database dependent (GDD) enabling
station (STA) to validate the list of available frequencies and to verify that the receiving GDD STA is within
reception range of the master white space device (WSD) [US].
personal/portable station (STA): A STA that uses network communications at unspecified locations [US].
television band device (TVBD): An intentional radiator that operates on an unlicensed basis on available
channels in the broadcast television frequency bands [US].
white space device (WSD): An entity that employs cognitive facilities to use white space spectrum without
causing harmful interference to protected services [EU].
3.4 Abbreviations and acronyms
3GPP 3rd Generation Partnership Project
40MC forty MHz capable
802.x LAN IEEE 802-based local area networks such as IEEE Std 802.3 and IEEE Std 802.11
AA authenticator address
AAA authentication, authorization, and accounting
AAD additional authentication data
A-BFT association beamforming training
AC access category
ACI access category index
Ack acknowledgment
ACM admission control mandatory
170
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ACU admission control unit
ADDBA add block acknowledgment
ADDTS add traffic stream
AES advanced encryption standard
AES-128-CMAC advanced encryption standard (with 128-bit key) cipher-based message
authentication code
AFC automatic frequency control
AGC automatic gain control
AID association identifier
AIFS arbitration interframe space
AIFSN arbitration interframe space number
AKM authentication and key management
AKMP authentication and key management protocol
A-MPDU aggregate MAC protocol data unit
AMPE authenticated mesh peering exchange
A-MSDU aggregate MAC service data unit
ANIPI average noise plus interference power indicator
ANonce authenticator nonce
ANPI average noise power indicator
ANQP access network query protocol
AP access point
APSD automatic power save delivery
ARP Address Resolution Protocol
AS authentication server
ASEL antenna selection
ASN.1 Abstract Syntax Notation One
ASRA additional step required for access
ATI announcement transmission interval
ATIM announcement traffic indication message
AV audio video
AWV antenna weight vector
BA block acknowledgment
BAR block acknowledgment request
BC beam combining
BCC binary convolutional code
BCU basic channel unit
BF beamforming
BHI beacon header interval
BIP broadcast/multicast integrity protocol
BPSK binary phase shift keying
BRP beam refinement protocol
BRPIFS beam refinement protocol interframe space
BSA basic service area
BSS basic service set
BSSID basic service set identifier
BT bit time
171
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
BTI beacon transmission interval
BU bufferable unit
BW bandwidth
CAP controlled access phase
CAQ channel availability query
CBAP contention based access period
CBC cipher-block chaining
CBC-MAC cipher-block chaining message authentication code
CBP contention based protocol
CCA clear channel assessment
CCK complementary code keying
CCM CTR with CBC-MAC
CCMP CTR with CBC-MAC Protocol
CCSR centralized coordination service root
CCSS centralized coordination service set
CF contention free
CFP contention free period
CID Company ID
C-MPDU coded MPDU
CP contention period
C-PSDU coded PSDU
CRC cyclic redundancy code
CS carrier sense
CSD cyclic shift diversity
CSI channel state information
CSM channel schedule management
CSMA/CA carrier sense multiple access with collision avoidance
CTR counter mode
CTS clear to send
CTS1 clear to send 1
CTS2 clear to send 2
CVS contact verification signal
CW contention window
DA destination address
DBPSK differential binary phase shift keying
DCF distributed coordination function
DCLA dc level adjustment
DEI drop eligibility indicator
DELBA delete block acknowledgment
DELTS delete traffic stream
DFS dynamic frequency selection
DFT discrete Fourier transform
DIFS distributed (coordination function) interframe space
DLL data link layer
DL-MU-MIMO downlink multi-user multiple input, multiple output
DLS direct-link setup
172
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DLTF Data Long Training field
DMG directional multi-gigabit
DMS directed multicast service
DMSID directed multicast service identifier
DN destination network
DO DFS owner
Dp desensitization
DQPSK differential quadrature phase shift keying
DR data rate
DS distribution system
DSAF distribution system access function
DSCP differentiated services code point
DSE dynamic station enablement
DSM distribution system medium
DSS distribution system service
DSSS direct sequence spread spectrum
DST daylight saving time
DTI data transfer interval
DTIM delivery traffic indication map
DTP dynamic tone pairing
EAP Extensible Authentication Protocol (IETF RFC 3748 [B42])
EAPOL Extensible Authentication Protocol over LANs (IEEE Std 802.1X-2010)
EAS emergency alert system
EBR expedited bandwidth request
ECAPC extended centralized AP or PCP cluster
ECS extended channel switching
ED energy detection
EDCA enhanced distributed channel access
EDCAF enhanced distributed channel access function
EDT eastern daylight time
EHCC extended hyperbolic congruence code
EIFS extended interframe space
EIRP equivalent isotropically radiated power
ELTF Extension Long Training field
EOF end-of-frame
EOSP end of service period
EPD EtherType Protocol Discrimination (IEEE Std 802-2014)
ERP extended rate PHY
ERP-CCK extended rate PHY using CCK modulation
ERP-DSSS extended rate PHY using DSSS modulation
ERP-DSSS/CCK extended rate PHY using DSSS or CCK modulation
ERP-OFDM extended rate PHY using OFDM modulation
ESA extended service area
ESP estimated service parameters
ESR emergency services reachable
ESS extended service set
173
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
EST eastern standard time
EVM error vector magnitude
FCS frame check sequence
FD-AF full-duplex amplify-and-forward
FEC forward error correction
FER frame error ratio
FFC finite field cryptography
FFE finite field element
FFT Fast Fourier Transform
FIFO first in first out
FMS flexible multicast service
FMSID flexible multicast stream identifier
FOV field of view
FSM finite state machine
FST fast session transfer
FSTS fast session transfer session
FT fast BSS transition
FTAA fast BSS transition authentication algorithm
FTE fast BSS transition element
FTM fine timing measurement
FTO fast BSS transition originator
GANN gate announcement
GAS generic advertisement service
GATS group addressed transmission service
GCM Galois/counter mode
GCMP Galois/Counter Mode Protocol
GCR groupcast with retries
GCR-A groupcast with retries active
GCR-SP groupcast with retries service period
GDB geolocation database
GDD geolocation database dependent
GFSK Gaussian frequency shift key or keying
GI guard interval
GID group identifier
GMK group master key
GNonce group nonce
GP grant period
GPRS general packet radio service
GPS Global Positioning System
GQMF group addressed quality-of-service Management frame
GTK group temporal key
GTKSA group temporal key security association
HC hybrid coordinator
HCC hyperbolic congruence code
HCCA HCF controlled channel access
HCF hybrid coordination function
174
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
HD-DF half-duplex decode-and-forward
HEC header error check
HELD HTTP-enabled location delivery
HEMM HCCA, EDCA mixed mode
HESSID homogenous extended service set identifier
HIPERLAN high-performance radio local area network
HPA high power amplifier
HR/DSSS high rate direct sequence spread spectrum using the long preamble and header
HR/DSSS/short high rate direct sequence spread spectrum using the optional short preamble and
header mode
HT high-throughput
HTC high-throughput control
HT-GF-STF high-throughput Greenfield Short Training field
HT-SIG high-throughput SIGNAL field
HT-STF high-throughput Short Training field
HTTP hyptertext transfer protocol
HTTPS hyptertext transfer protocol secure
HWMP hybrid wireless mesh protocol
HWMP SN hybrid wireless mesh protocol sequence number
IBSS independent basic service set
ICMP Internet Control Message Protocol
ICV integrity check value
IDFT inverse discrete Fourier transform
IFFT inverse Fast Fourier Transform
IFS interframe space
IGTK integrity group temporal key
IGTKSA integrity group temporal key security association
IMp intermodulation protection
INonce initiator nonce
IPI idle power indicator
IPN IGTK packet number
IQMF individually addressed quality-of-service Management frame
I/Q in phase and quadrature
ISM industrial, scientific, and medical
ISS initiator sector sweep
IUT implementation under test
IV initialization vector
KCK EAPOL-Key confirmation key
KDE key data encapsulation
KDF key derivation function
KEK EAPOL-Key encryption key
LAN local area network
LBIFS long beamforming interframe space
LCI location configuration information
LDPC low-density parity check
LFSR linear feedback shift register
175
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
LGR legendre symbol
LLC logical link control
L-LTF non-HT Long Training field
LME layer management entity
LNA low noise amplifier
LP low power
LPD LLC Protocol Discrimination (IEEE Std 802-2014)
LRC long retry count
LSB least significant bit
L-SIG non-HT SIGNAL field
L-STF non-HT Short Training field
LTF Long Training field
MAC medium access control
MAC_I initiator mac address
MAC_P peer mac address
MAF MCCA access fraction
MBCA mesh beacon collision avoidance
MBIFS medium beamforming interframe space
MBSS mesh basic service set
MCCA MCF controlled channel access
MCCAOP MCF controlled channel access opportunity
MCF mesh coordination function
MCS modulation and coding scheme
MDE Mobility Domain element
MDID mobility domain identifier
MFB MCS feedback
MFPC management frame protection capable
MFPR management frame protection required
MFSI MCS feedback sequence identifier
MGTK mesh group temporal key
MIB management information base
MIC message integrity code
MID multiple sector identifier
MIDC multiple sector identifier capture
MIH media-independent handover
MIMO multiple input, multiple output
MLME MAC sublayer management entity
MLPP multi-level precedence and preemption
MME Management MIC element
MMPDU MAC management protocol data unit
MMS multiple MAC sublayers
MMSL multiple MAC sublayers link
MM-SME multiple MAC station management entity
MPDU MAC protocol data unit
MPM mesh peering management
MRQ MCS request
176
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MSB most significant bit
MSDU MAC service data unit
MSGCF MAC state generic convergence function
MSI MRQ sequence identifier
MSK master session key
MTK mesh temporal key
MU multi-user
MU-MIMO multi-user multiple input, multiple output
N/A not applicable
NAI network access identifier
NAS network access server
NAV network allocation vector
NCC network channel control
NDP null data packet
NonERP nonextended rate PHY
NSS number of spatial streams
NTP Network Time Protocol (IETF RFC 1305 [B27])
OBSS overlapping basic service set
OCB outside the context of a BSS
OCT on-channel tunneling
OFDM orthogonal frequency division multiplexing
OI organization identifier
OSI Open Systems Interconnection (ISO/IEC 7498-1:1994)
OUI organizationally unique identifier
PAE port access entity (IEEE Std 802.1X-2010)
PBAC protected block ack agreement capable
PBSS personal basic service set
PC point coordinator
PCF point coordination function
PCP PBSS control point
PCPS PBSS control point service
PCO phased coexistence operation
PDU protocol data unit
PER packet error ratio
PERR path error
PHB per-hop behavior
PHY physical layer
PHYCS PHY carrier sense
PHYED PHY energy detection
PICS protocol implementation conformance statement
PIFS point (coordination function) interframe space
PLME physical layer management entity
PLW PSDU length word
PMK pairwise master key
PMKID pairwise master key identifier
PMK-R0 pairwise master key, first level
177
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PMK-R1 pairwise master key, second level
PMKSA pairwise master key security association
PN packet number
PN pseudonoise (code sequence)
PNonce peer nonce
PP polling period
PP A-MSDU payload protected aggregate MAC service data unit
PPDU PHY protocol data unit
PREP path reply
PREQ path request
PRF pseudorandom function
PRNG pseudorandom number generator
PS power save (mode)
PSAP public safety answering point
PSDU PHY service data unit
PSF PHY Signaling field
PSK preshared key
PSM power save mode
PSMP power save multi-poll
PSMP-DTT power save multi-poll downlink transmission time
PSMP-UTT power save multi-poll uplink transmission time
PTI peer traffic indication
PTK pairwise transient key
PTKSA pairwise transient key security association
PTP TSPEC peer-to-peer traffic specification
PWE password element of an ECC group
PXU proxy update
PXUC proxy update confirmation
QAB quieting adjacent BSS
QACM QMF access category mapping
QAM quadrature amplitude modulation
QBPSK quadrature binary phase shift keying
QLDRC QoS long drop-eligible retry counter
QLRC QoS long retry counter
QMF quality-of-service Management frame
QoS quality of service
QPSK quadrature phase shift keying
QSDRC QoS short drop-eligible retry counter
QSRC QoS short retry counter
R0KH PMK-R0 key holder in the Authenticator
R0KH-ID PMK-R0 key holder identifier in the Authenticator
R1KH PMK-R1 key holder in the Authenticator
R1KH-ID PMK-R1 key holder identifier in the Authenticator
RA receiver address or receiving station address
RADIUS remote authentication dial-in user service (IETF RFC 2865 [B33])
RANN root announcement
178
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RAV resource allocation vector
RCPI received channel power indicator
RD reverse direction
RDE RIC Data element
RDG reverse direction grant
RDS relay DMG STA
REDS relay endpoint DMG STA
RF radio frequency
RFC request for comments
RIC resource information container
RIFS reduced interframe space
RLAN radio local area network
RLQP registered location query protocol
RLS relay link setup
RLSS registered location secure server
ROC relay operation type change
RPI receive power indicator
RRB remote request broker
RSC receive sequence counter
RSN robust security network
RSNA robust security network association
RSNE Robust Security Network element
RSNI received signal-to-noise indicator
RSPI receiver service period initiated
RSS responder sector sweep
RSSI receive signal strength indicator
RTS request to send
RTT round trip time
RX receive or receiver
RXASSI receive antenna selection sounding indication
RXASSR receive antenna selection sounding request
RXSS receive sector sweep
S0KH PMK-R0 key holder in the Supplicant
S0KH-ID PMK-R0 key holder identifier in the Supplicant
S1KH PMK-R1 key holder in the Supplicant
S1KH-ID PMK-R1 key holder identifier in the Supplicant
SA source address
SAE simultaneous authentication of equals
SAP service access point
S-AP synchronization access point
S-APSD scheduled automatic power save delivery
SA Query security association query
SBIFS short beamforming interframe space
SC single carrier
SCA secondary channel above
SCB secondary channel below
179
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SCN no secondary channel
SCS stream classification service
SCSID stream classification service identifier
SDL specification and description language
SDU service data unit
SEMM SPCA-EDCA mixed mode
SFD start frame delimiter
SKCK STSL key confirmation key
SKEK STSL key encryption key
SI service interval
SIFS short interframe space
SLRC station long retry count
SLS sector-level sweep
SM spatial multiplexing
SME station management entity
SMK STSL master key
SMKSA STSL master key security association
SMT station management
SNAP Sub-Network Access Protocol
SNonce supplicant nonce
SNR signal-to-noise ratio
SP service period
SPA supplicant address
SPCA service period channel access
S-PCP synchronization PBSS control point
SPP A-MSDU signaling and payload protected aggregate MAC service data unit
SPR service period request
SPSH spatial sharing
SQ signal quality (PN code correlation strength)
SRC short retry count
SS station service
SSID service set identifier
SSP subscription service provider
SSPN subscription service provider network
SSRC station short retry count
SSW sector sweep
STA station
STBC space-time block coding
STF Short Training field
STK STSL transient key
STKSA STSL transient key security association
STSL station-to-station link
STT selective translation table
SU single-user
SU-MIMO single-user multiple input, multiple output
SYNC synchronization
180
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TA transmitter address or transmitting station address
TAI Temps Atomique International (International Atomic Time)
TBTT target beacon transmission time
TC traffic category
TCLAS traffic classification
TDDTI time division data transfer interval
TDLS tunneled direct-link setup
TFS traffic filtering service
TID traffic identifier
TIE Timeout Interval element
TIM traffic indication map
TK temporal key
TKIP temporal key integrity protocol
TLV type/length/value
TMPTT target measurement pilot transmission time
TOA time of arrival
TOD time of departure
TPA transmission time-point adjustment
TPC transmit power control
TPK TDLS PeerKey
TPKSA TDLS PeerKey security association
TPU TDLS peer U-APSD
TRN-R receive training
TRN-T transmit training
TRQ training request
TS traffic stream
TSC TKIP sequence counter
TSF timing synchronization function
TSID traffic stream identifier
TSN transition security network
TSPEC traffic specification
TTAK TKIP-mixed transmit address and key
TTL time to live
TTTT target TIM transmission time
TU time unit
TVHT television very high throughput
TVWS television white spaces
TX transmit or transmitter
TXASSI transmit antenna selection sounding indication
TXASSR transmit antenna selection sounding request
TXE transmit enable
TXOP transmission opportunity
TXSS transmit sector sweep
U-APSD unscheduled automatic power save delivery
UCT unconditional transition
UESA unauthenticated emergency service accessible
181
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ULS Universal Licensing System
U-NII unlicensed national information infrastructure
UP user priority
UPSIM unscheduled power save indication map
URI Uniform Resource Identifier
URL Universal Resource Locator
URN Uniform Resource Name
UTC Coordinated Universal Time
VHT very high throughput
VLAN virtual local area network
VoIP voice over Internet Protocol (IP)
WEP wired equivalent privacy
WLAN wireless local area network
WM wireless medium
WNM wireless network management
WSM white space map
3.5 Abbreviations and acronyms in some regulatory domains
ISO 3166-1 defines the international two-letter designation for country names, and these designations are
included [in square brackets] at the end of each abbreviation that has clear attribution to a regulatory
domain.
PLMR/CRS private land mobile radio/cellular radio service [US]
TVBD television band device [US]
WSD white space device [EU]
182
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4. General description
4.1 General description of the architecture
This clause presents the concepts and terminology used within this standard. Specific terms are defined in
Clause 3. Illustrations convey key IEEE 802.11 concepts and the interrelationships of the architectural
components. IEEE Std 802.11 uses an architecture to describe functional components of an IEEE 802.11
LAN. The architectural descriptions are not intended to represent any specific physical implementation of
IEEE Std 802.11.
4.2 How wireless local area networks (WLANs) are different
4.2.1 Introduction
Wireless networks have fundamental characteristics that make them significantly different from traditional
wired LANs.
4.2.2 Wireless station (STA)
In the design of wired LANs it is implicitly assumed that an address is equivalent to a physical location. In
wireless networks, this is not always the case. In IEEE Std 802.11, the addressable unit is a station (STA).
Physical and operational characteristics are defined by modifiers that are placed in front of the term STA.
For example, in the case of location and mobility, the addressable units are the fixed STA, the portable STA,
and the mobile STA. The STA is an addressable destination, but not (in general) a fixed location.
A STA might take on multiple distinct characteristics, each of which shape its function. For example, a
single addressable unit might simultaneously be a portable STA, a quality-of-service (QoS) STA, a
dependent STA, and a hidden STA.
4.2.3 Media impact on design and performance
The PHYs used in IEEE Std 802.11 are fundamentally different from wired media. Thus IEEE 802.11
PHYs:
a) Use a medium that has neither absolute nor readily observable boundaries outside of which STAs
with PHY transceivers are known to be unable to receive network frames
b) Are unprotected from other signals that are sharing the medium
c) Communicate over a medium significantly less reliable than wired PHYs
d) Have dynamic topologies
e) Lack full connectivity, and therefore the assumption normally made that every STA can hear every
other STA is invalid (i.e., STAs might be “hidden” from each other)
f) Have time-varying and asymmetric propagation properties
g) Might experience interference from logically disjoint IEEE 802.11 networks operating in
overlapping areas
Because of limitations on wireless PHY ranges, WLANs intended to cover reasonable geographic distances
can be built from basic coverage building blocks. When providing QoS services, the MAC endeavors to
provide QoS “service guarantees” within the limitations of the medium properties identified above. In other
words, particularly in unlicensed spectrum, true guarantees are often not possible. However, gradations of
service are always possible; and in sufficiently controlled environments, QoS guarantees are possible.
183
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.2.4 The impact of handling mobile STAs
One of the requirements of IEEE Std 802.11 is to handle mobile as well as portable STAs. A portable STA
is one that is moved from location to location, but that is used only while at a fixed location. Mobile STAs
actually access the LAN while in motion.
For technical reasons, it is not sufficient to handle only portable STAs. Propagation effects blur the
distinction between portable and mobile STAs; stationary STAs often appear to be mobile due to
propagation effects.
Mobile STAs typically are battery powered. Hence power management is an important consideration. For
example, it cannot be presumed that a STA’s receiver is always powered on.
4.2.5 Interaction with other IEEE 802® layers
IEEE Std 802.11 is required to appear to higher layers [logical link control (LLC)] as a general-purpose
IEEE 802 LAN. This requires that the IEEE 802.11 network handle STA mobility within the MAC sublayer.
To meet reliability assumptions (that LLC makes about lower layers), it is necessary for IEEE Std 802.11 to
incorporate functionality that is untraditional for MAC sublayers.
In a robust security network association (RSNA), IEEE Std 802.11 provides functions to protect Data
frames, IEEE Std 802.1X-2010 provides authentication and a Controlled Port, and IEEE Std 802.11 and
IEEE Std 802.1X-2010 collaborate to provide key management. All STAs in an RSNA have a
corresponding IEEE 802.1X™ entity that handles these services. This standard defines how an RSNA
utilizes IEEE Std 802.1X-2010 to access these services. Within IEEE Std 802.11, EAPOL PDUs are carried
as MSDUs within one or more Data frames, as described in IEEE Std 802.1X-2010, Clause 12. Within this
standard, Data frames used for this purpose are generally referred to as EAPOL-Key frames, EAPOL-Key
request frames, and EAPOL-Start frames.
When used to support applications that have QoS requirements, each IEEE 802.11 LAN provides a link
within an end-to-end QoS environment that can be established between, and managed by, higher layer
entities. To handle QoS traffic in a manner comparable to other IEEE 802 LANs, the IEEE 802.11 QoS
facility requires the IEEE 802.11 MAC sublayers to incorporate functionality that is not traditional for MAC
sublayers. In addition, it might be necessary for certain higher layer management entities to be “WLAN
aware” at least to the extent of understanding that the available bandwidth and other QoS characteristics of a
WLAN are subject to frequent, and sometimes substantial, dynamic changes due to causes other than traffic
load and are outside the direct control of network management entities.
4.2.6 Interaction with non-IEEE-802 protocols
An RSNA utilizes non-IEEE-802 protocols for its authentication and key management (AKM) services.
Some of these protocols are defined by other standards organizations, such as the Internet Engineering Task
Force (IETF).
4.3 Components of the IEEE 802.11 architecture
4.3.1 General
The IEEE 802.11 architecture consists of several components that interact to provide a WLAN that supports
STA mobility transparently to upper layers.
The basic service set (BSS) is the basic building block of an IEEE 802.11 LAN. Figure 4-1 shows two BSSs,
each of which has two STAs that are members of the BSS.
184
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is useful to think of each oval depicting a BSS as the coverage area within which the member STAs of the
BSS can remain in communication. In the case of transmissions such as in a directional multi-gigabit
(DMG) BSS, the individual coverage area of a transmission from one member STA to another can be
thought of as a cone and hence is referred to as a directional transmission. The collection of all possible
directional transmissions by a member STA defines the coverage area. (The concept of area, while not
precise, is often good enough.) This area is called the Basic Service Area (BSA). If a STA moves out of its
BSA, it can no longer directly communicate with other STAs present in the BSA.
Figure 4-1—BSSs
4.3.2 The independent BSS (IBSS)
The IBSS is the most basic type of IEEE 802.11 LAN. Since the BSSs shown in Figure 4-1 are simple and
lack other components (contrast this with Figure 4-2), the two can be taken to be representative of two
IBSSs.
This mode of operation is possible when IEEE 802.11 STAs are able to communicate directly. Because this
type of IEEE 802.11 LAN is often formed without preplanning, for only as long as the LAN is needed.
4.3.3 The personal BSS (PBSS)
Similar to the IBSS, the PBSS is a type of IEEE 802.11 LAN in which STAs communicate directly with
each other.
In contrast to the IBSS, in the PBSS one STA assumes the role of the PBSS control point (PCP). The PCP
provides the basic timing for the PBSS through DMG Beacon and Announce frames as well as allocation of
service periods and contention based access periods.
A PBSS can be established only by DMG STAs. Not every DMG BSS is a PBSS. A DMG BSS can be a
PBSS, an infrastructure BSS, or an IBSS.
4.3.4 STA membership in a BSS is dynamic
A STA’s membership in a BSS is dynamic (STAs turn on, turn off, come within range, and go out of range).
To become a member of an infrastructure BSS or an IBSS, a STA joins the BSS using the synchronization
procedure described in 11.1.4.5. To start a new mesh BSS or to become a member of a mesh BSS, a STA
starts the transmission of Beacons and performs the synchronization maintenance procedure described in
14.13. To access all of the services of an infrastructure BSS, a STA becomes “associated.” These
185
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
associations are dynamic and involve the use of the distribution system service (DSS), which is described
in 4.4.4. A mesh STA does not become associated as there is no central entity in a mesh BSS (MBSS).
Instead, a mesh STA peers with other mesh STAs.
4.3.5 Distribution system (DS) concepts
4.3.5.1 Overview
PHY limitations determine the direct station-to-station distance that is supported. For some networks this
distance is sufficient; for other networks, increased coverage is required.
Instead of existing independently, an infrastructure BSS might also form a component of an extended form
of network that is built with multiple BSSs. The architectural component used to interconnect infrastructure
BSSs is the DS.
IEEE Std 802.11 logically separates the WM from the distribution system medium (DSM). Each logical
medium is used for different purposes, by a different component of the architecture. The IEEE 802.11
definitions neither preclude, nor demand, that the multiple media be either the same or different.
Recognizing that the multiple media are logically different is key to understanding the flexibility of the
architecture. The IEEE 802.11 LAN architecture is specified independently of the physical characteristics of
any specific implementation.
The DS enables mobile device support by providing the logical services necessary to handle address to
destination mapping and seamless integration of multiple BSSs.
An access point (AP) is any entity that has STA functionality and a distribution system access function
(DSAF), which enables access to the DS, via the WM for associated STAs.
Figure 4-2 adds the DS, DSM and AP components to the IEEE 802.11 architecture picture.
Figure 4-2—DSs and APs
Data move between a BSS and the DS via the DSAF in an AP. An AP contains a STA and is addressable on
the WM using its STA address. The addresses used by an AP for communication on the WM and on the
DSM are not necessarily the same.
186
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Data sent to the AP’s STA address by one of the STAs associated with it are always received at the
uncontrolled port for processing by the IEEE 802.1X port access entity. In addition, if the controlled port is
authorized, these frames conceptually transit the DS.
4.3.5.2 Extended service set (ESS): the large coverage network
The DS and infrastructure BSSs allow IEEE Std 802.11 to create a wireless network of arbitrary size and
complexity. IEEE Std 802.11 refers to this type of network as the ESS. An ESS is the union of the
infrastructure BSSs with the same SSID connected by a DS. The ESS does not include the DS.
The key concept is that the ESS appears the same to an LLC layer as an IBSS. STAs within an ESS can
communicate and mobile STAs might move from one BSS to another (within the same ESS) transparently to
LLC.
Owing to its distributed nature, a mesh BSS (MBSS) has no central entity like the AP of an infrastructure
BSS. Instead, an MBSS forms a single set of independent mesh STAs. This set is indivisible and cannot be
further unified. The ESS concept does not apply to the MBSS. However, it is possible to use a Mesh BSS as
all or part of the DS that connects an ESS.
Nothing is assumed by IEEE Std 802.11 about the relative physical locations of the BSSs in Figure 4-3.
Figure 4-3—ESS
All of the following are possible
a) The BSSs partially overlap. This is commonly used to arrange coverage within a physical volume.
b) The BSSs could be physically disjoint. Logically there is no limit to the distance between BSSs.
c) The BSSs are physically collocated. This could be done to provide redundancy.
d) One (or more) IBSSs or ESSs are physically present in the same location as one (or more) ESSs.
This could arise for a number of reasons. Some examples are when an IBSS is operating in a
location that also has an ESS, when physically overlapping IEEE 802.11 networks have been set up
by different organizations, and when two or more different access and security policies are needed in
the same location.
187
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.6 Area concepts
For wireless PHYs, well-defined coverage areas simply do not exist. Propagation characteristics are
dynamic and unpredictable. Small changes in position or direction might produce dramatic differences in
signal strength. Similar effects occur whether a STA is stationary or mobile (as moving objects might impact
station-to-station propagation).
Figure 4-4 shows a signal strength map for a simple square room with a standard metal desk and an open
doorway. This figure is a static snapshot; the propagation patterns change dynamically as STAs and objects
in the environment move. The dark (solid) blocks in the lower left are a metal desk and there is a doorway at
the top right of the figure. The figure indicates relative differences in field strength with different intensities
and indicates the variability of field strength even in a static environment. The difference between the
greatest signal strength and the least signal strength in this figure is 50 dB.
Figure 4-4—A representative signal intensity map
While the architecture diagrams show sharp boundaries for BSSs, this is an artifact of the pictorial
representation, not a physical reality. Because dynamic three-dimensional field strength pictures are difficult
to draw, well-defined shapes are used by IEEE 802.11 architectural diagrams to represent the coverage of a
BSS.
Further description difficulties arise when attempting to describe collocated coverage areas. Consider
Figure 4-5, in which STA 6 could belong to BSS 2 or BSS 3.
While the concept of sets of STAs is correct, it is often convenient to talk about areas. For many topics the
concept of area is sufficient. Volume is a more precise term than area, though still not technically correct.
For historical reasons and convenience, this standard uses the common term area.
188
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 4-5—Collocated coverage areas
4.3.7 Integration with non-IEEE-802.11 LANs
To integrate the IEEE 802.11 architecture with a non-IEEE-802.11 LAN, including a traditional wired LAN,
a final logical architectural component is introduced—a portal.
A portal is the logical point at which the integration service is provided. All data from or to non-IEEE-
802.11 LANs enter or leave the IEEE 802.11 architecture via a portal. The integration service is responsible
for any addressing changes or other logical mappings that might be required when MSDUs pass between the
DS and the integrated LAN. It is possible for one device to offer both the functions of an AP and a portal.
For example, a portal to a wired IEEE 802 LAN is shown in Figure 4-6.
BSS 1 IEEE Std 802.11 Components
STA 1
STA 2
AP
DS
AP
IEEE 802 LAN Portal STA 3
STA 4
BSS 2
Figure 4-6—Connecting to other IEEE 802 LANs
189
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.8 Robust security network association (RSNA)
The following features are defined for an RSNA:
— Enhanced authentication mechanisms for STAs
— Key management algorithms
— Cryptographic key establishment
— Enhanced data cryptographic encapsulation mechanisms, such as counter mode with cipher-block
chaining message authentication code protocol (CCMP), Galois/counter mode protocol (GCMP),
and, optionally, temporal key integrity protocol (TKIP).
— Fast basic service set (BSS) transition (FT) mechanism
— Enhanced cryptographic encapsulation mechanisms for robust Management frames
An RSNA might rely on components external to the IEEE 802.11 architecture.
The first component is an IEEE 802.1X port access entity (PAE). PAEs are present on all STAs in an RSNA
and control the forwarding of data to and from the medium access control (MAC). An AP always
implements the Authenticator PAE and Extensible Authentication Protocol (EAP) Authenticator roles, and a
non-AP STA always implements the Supplicant PAE and EAP peer roles. In an IBSS or PBSS, each STA
implements both the Authenticator PAE and Supplicant PAE roles and both EAP Authenticator and EAP
peer roles.
A second component is the Authentication Server (AS). The AS authenticates the elements of the RSNA
itself, i.e., the STAs provide material that the RSNA elements use to authenticate each other. The AS
communicates through the IEEE 802.1X Authenticator with the IEEE 802.1X Supplicant on each STA,
enabling the STA to be authenticated to the AS and vice versa. An RSNA depends upon the use of an EAP
method that supports mutual authentication of the AS and the STA, such as those that meet the requirements
in IETF RFC 4017. In certain applications, the AS might be integrated into the same physical device as the
AP, or into a STA in an IBSS or PBSS.
In some applications, there is no need for a PAE or AS, and a STA and AP, or two IBSS STAs, or two mesh
STAs in an MBSS, might authenticate each other using a password.
An RSNA using fast BSS transition relies on an external protocol to distribute keys between the pairwise
master key (PMK) R0 key holder (R0KH) and PMK-R1 key holder (R1KH) Authenticator components. The
requirements for this protocol are described in 13.2.2.
4.3.9 Centralized coordination service set (CCSS) and extended centralized AP or PCP
clustering (ECAPC)
AP or PBSS control point (PCP) clustering is a protocol between a DMG synchronization AP or DMG
synchronization PCP (S-AP or S-PCP) and other APs and PCPs within the cluster, known as member APs
and PCPs. This protocol is used to improve spatial sharing and interference mitigation among the DMG
BSSs of the S-AP or S-PCP and member APs and PCPs. AP or PCP clustering allows an AP or PCP within
a cluster to schedule transmissions in nonoverlapping time periods with respect to other APs and PCPs that
are in the same cluster. There are two types of clustering:
— In decentralized AP or PCP clustering, there is a single S-AP or S-PCP in the BSA of the S-AP or
S-PCP.
— In centralized AP or PCP clustering, there can be multiple S-APs in the BSA of any one S-AP and
all S-APs are coordinated via a single centralized coordination service set (CCSS).
190
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A CCSS comprises a centralized coordination service root (CCSR) and a set of one or more synchronization
APs that while operating are stationary with respect to their local environment and are connected to the
CCSR via, for instance, one of the following:
— The DS to an AP (or beyond, to a STA associated to the AP)
— A combination of distribution service, portal, and external network
The CCSR provides coordination services for the CCSS, such as selecting the target beacon transmission
time of S-APs within the CCSS to minimize interference. The CCSR might logically reside within an S-AP
or in another entity as long as it has a globally administered MAC address. A CCSS is suited to an area and
a frequency band having the following propagation characteristics:
— The BSAs of the S-APs within the CCSS cover the area, and
— Transmissions within the area are isolated to a high degree.
An extended centralized AP or PCP cluster (ECAPC) comprises a single CCSS and an accompanying set of
centralized AP or PCP clusters. Each S-AP of one of the centralized AP or PCP clusters is inside the CCSS.
The ECAPC also includes all STAs in the BSSs of the S-APs and member APs and PCPs of the centralized
AP or PCP clusters. An example is shown in Figure 4-7, in which:
— STA3a and STA3b are two STAs coordinated by a one MM-SME component.
— STA4a and STA4b are two STAs coordinated by a second MM-SME component.
— The CCSR happens to be located in an external network.
Centralized
External Network Coordination
Service Root
Portal
DS1
S-AP
S-AP Centralized
STA1 CCSS AP or PCP
STA2
BSS1 cluster ECAPC
STA5 BSS2 (excluding
DS2 DS1, DS2
PCP and
AP external
STA4b STA4a network)
STA3a STA3b BSS4
BSS3 STA8
STA6
STA7
Figure 4-7—CCSS and ECAPC
191
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The CCSS might contain whole ESSs, subsets of ESSs, or some combination of them.
Decentralized AP or PCP clustering can be employed without establishing a CCSS, CCSR, or ECAPC.
4.3.10 QoS BSS
The IEEE 802.11 QoS facility provides MAC enhancements to support LAN applications with QoS
requirements. The QoS enhancements are available to QoS STAs associated with a QoS access point or PCP
in a QoS BSS. A subset of the QoS enhancements is available for use between STAs that are members of the
same QoS IBSS.
Similarly, a subset of the QoS enhancements is available for use between neighbor peer mesh STAs. A mesh
BSS is one type of QoS BSS and it is described in 4.3.20.
A QoS STA that is a non-DMG STA might associate with a non-QoS access point in a non-QoS BSS, to
provide the non-QoS MAC data service, for example, when there is no QoS BSS with which to associate.
As a mesh STA does not implement the necessary service, the mesh STA does not associate with any access
point.
A DMG STA is a QoS STA. A DMG BSS is a QoS BSS.
The enhancements that distinguish QoS STAs from non-QoS STAs and QoS APs from non-QoS APs are
collectively termed the QoS facility. Which of the QoS-specific mechanisms a QoS STA supports might
vary among QoS implementations, as well as between QoS STAs and QoS APs, over ranges specified in
subsequent clauses. All service primitives, frame formats, coordination function and frame exchange rules,
and management interface functions except for the block acknowledgment (block ack) function, direct-link
setup (DLS), and automatic power save delivery (APSD) are part of the core QoS facility. A QoS STA or
QoS AP implements those core QoS facility necessary for its QoS functions to interoperate with other QoS
STAs. Functions such as the block ack, DLS, and APSD are separate from the core QoS facility; and the
presence of these functions is indicated by STAs separately from the core QoS facility.
For infrastructure BSS and IBSS, this standard provides four mechanisms for the support of applications
with QoS requirements.
The first mechanism, designated the enhanced distributed channel access (EDCA), delivers traffic based on
differentiating user priorities (UPs). This differentiation is achieved by varying the following for different
UP values:
— Amount of time a STA senses the channel to be idle before backoff or transmission, or
— The length of the contention window to be used for the backoff, or
— The duration a STA transmits after it acquires the channel.
These transmissions might also be subject to certain channel access restrictions in the form of admission
control. A DMG STA uses EDCA only within a contention based access period (CBAP). Details of EDCA
are provided in 10.22.2 and, for DMG STAs, additional details are provided in 10.36.4, 10.36.5, and
10.36.6.3.
The second mechanism, designated the hybrid coordination function (HCF) controlled channel access
(HCCA), which is not applicable to DMG STAs, allows for the reservation of transmission opportunities
(TXOPs) with the hybrid coordinator (HC). A STA requests the HC for TXOPs, both for its own
transmissions as well as for transmissions from the AP to itself.17 The request is initiated by the station
17
In the case of downlink traffic streams (TSs).
192
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
management entity (SME) of the STA. The HC, which is collocated at the AP, either accepts or rejects the
request based on an admission control policy. If the request is accepted, the HC schedules TXOPs for both
STAs (both the AP and the non-AP STA). For transmissions from the non-AP STA, the HC polls the STA
based on the parameters supplied by the STA at the time of its request. For transmissions to the STA, the AP
directly obtains TXOPs from the collocated HC and delivers the queued frames to the STA, again based on
the parameters supplied by the STA. Details of the mechanism are provided in 10.22.3 and 11.4. This
mechanism might be used for applications such as voice and video, which need periodic service from the
HC. If the application constraints dictate the use of this mechanism, the application initiates this mechanism
by using the management service primitives.
The third mechanism, designated the service period (SP) access or service period channel access (SPCA), is
applicable only to DMG STAs and allows for the reservation of channel time by the AP or PCP. A non-AP
and non-PCP STA requests SPs from an AP or PCP. These SPs can be used for transmission to any other
STA in the BSS. The request is initiated by the SME of the non-AP and non-PCP STA. The AP or PCP
either accepts or rejects the request based on an admission control policy. If the request is accepted, the AP
or PCP uses the Extended Schedule element to schedule SPs for communication between the source and
destination DMG STAs indicated within the request. Details of this mechanism are provided in 10.36.6.2,
10.36.6.4, 10.36.6.6, and 11.4.
The fourth mechanism, designated as dynamic allocation, is applicable only to DMG STAs and allows for
near-real-time reservation of channel time with an AP or PCP. This type of access is used in addition to the
service period and contention based access period mechanisms. An AP or PCP can poll a STA and receive
requests for channel time allocation. Based on the received requests, the AP or PCP can accept a request and
immediately allocate (within the same beacon interval) channel time for the STA to communicate with
another STA by using a Grant frame. Details of this mechanism are provided in 10.36.7, 10.36.8, and
10.36.9.
The AP of a QoS BSS might allow non-QoS STAs to associate. All individually addressed frames that are
sent to non-QoS STAs by an AP do not use the frame formats associated with the QoS facility.
A QoS STA associated in a non-QoS BSS acts as a non-QoS STA.
4.3.11 Wireless LAN radio measurements
4.3.11.1 General
Wireless LAN (WLAN) radio measurements enable STAs to understand the radio environment in which
they exist. WLAN radio measurements enable STAs to observe and gather data on radio link performance
and on the radio environment. A STA can choose to make measurements locally, request a measurement
from another STA, or be requested by another STA to make one or more measurements and return the
results. Radio measurement data is made available to STA management and upper protocol layers where it
might be used for a range of applications. The measurements enable adjustment of STA operation to better
suit the radio environment. The radio measurement service includes measurements that extend the
capability, reliability, and maintainability of WLANs by providing standard measurements across vendors,
and the service provides the resulting measurement data to upper layers in the communications stack.
In addition to featuring standard measurements and delivering measurement information to upper layers,
there are applications that require quantifiable radio environment measurements in order to attain the
necessary performance levels. These applications include VoIP, video over IP, location based applications,
as well as applications requiring mitigation of harsh radio environments (multifamily dwellings, airplanes,
factories, municipalities, etc.). Radio measurements address most of the existing issues in using unlicensed
radio spectrum to meet the requirements of these emerging technologies.
193
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
To address the mobility requirements of technologies, such as VoIP and video streaming, radio
measurements, such as Channel Load request/report and the Neighbor request/report, can be used to collect
transition information, which can drastically speed up handoffs between BSSs within the same ESS. By
accessing and using this information, the STAs (either in APs or in non-AP STAs) can make intelligent
decisions about the most effective way to utilize the available spectrum, power, and bandwidth for their
communications.
The request/report measurements are as follows:
— Beacon
— Frame
— Channel Load
— Noise Histogram
— STA Statistics
— LCI (location configuration information)
— Neighbor Report
— Link Measurement
— Transmit Stream/Category Measurement
The request-only mechanism is as follows:
— Measurement Pause
The report-only mechanism is as follows:
— measurement pilot
These measurement mechanisms provide the capability for a STA to manage and query its radio
environment, and to make appropriate assessments about its health and efficiency. It is the first step in
making WLAN smart and capable of making appropriate decisions for fast transition, for mesh connectivity,
and for managing the radio environment for all wireless devices.
4.3.11.2 Beacon
The Beacon request/report pair enables a STA to request from another STA a list of APs whose beacons it
can receive on a specified channel or channels. The Beacon report request/response provides a means for a
requesting STA to obtain received beacon, probe response, and measurement pilot information from a
responding STA.
4.3.11.3 Measurement pilot
The Measurement Pilot frame provides a subset of the information provided in a Beacon frame, is smaller
than a Beacon, and is transmitted more often than a Beacon. The purpose of the Measurement Pilot frame is
to assist a STA with scanning.
4.3.11.4 Frame
The Frame request/report pair returns a picture of all of the channel traffic and a count of all of the frames
received at the measuring STA. For each unique Transmitter Address, the STA reports the Transmitter
Address, number of frames received from this transmitter, average power level (RCPI) for these frames, and
BSSID of the transmitter.
194
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.11.5 Channel load
The Channel Load request/report pair returns the channel utilization measurement as observed by the
measuring STA.
4.3.11.6 Noise histogram
The Noise Histogram request/report pair returns a power histogram measurement of non-IEEE-802.11 noise
power by sampling the channel when virtual carrier sense indicates idle and the STA is neither transmitting
nor receiving a frame.
4.3.11.7 STA statistics
The STA Statistics request/report pair returns groups of values for STA counters and for BSS Average
Access Delay. The STA counter group values include transmitted fragment counts, group addressed
transmitted frame counts, failed counts, retry counts, multiple retry counts, frame duplicate counts, Request
to Send (RTS) success counts, RTS failure counts, Acknowledgment (Ack) failure counts, received
fragment counts, group addressed received frame counts, FCS error counts, and transmitted frame counts.
BSS Average Access Delay group values include AP average access delay, average access delay for each
access category, associated STA count, and channel utilization.
4.3.11.8 Location
The Location request/report pair returns a requested location in terms of latitude, longitude, and altitude. It
includes types of altitude such as floors. A requested location can be the location of the requester (e.g.,
“Where am I?”) or the location of the reporting STA (e.g., “Where are you?”) or the location of another
STA.
4.3.11.9 Measurement pause
The Measurement Pause request is defined, but no report comes back from this request. The measurement
pause permits the inclusion of a quantified delay between the execution of individual measurements that are
provided in a series within a Measurement Request frame. The measurement pause used as the last
measurement in a frame provides control of the measurement period when Measurement Request frames are
to be repeated.
4.3.11.10 Neighbor report
The neighbor report request is sent to an AP, which returns a neighbor report containing information about
known neighbor APs that are candidates for a service set transition. Neighbor reports contain information
from dot11RMNeighborReportTable concerning neighbor APs. This request/report pair enables a STA to
gain information about the neighbors of the associated AP to be used as potential roaming candidates.
4.3.11.11 Link measurement
The link measurement request/report exchange provides measurements of the RF characteristics of a STA-
to-STA link. This measurement indicates the instantaneous quality of a link.
4.3.11.12 Transmit stream/category measurement
When two QoS STAs have an ongoing traffic stream between them, the Transmit Stream/Category
Measurement request/report pair enables either STA to query the other about the conditions of the stream.
The transmit stream/category measurement report provides the transmit-side performance metrics for the
measured traffic stream. Trigger conditions included in the Transmit Stream/Category Measurement request
195
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
can initiate triggered Transmit Stream/Category Measurement reports upon detection of the trigger
condition.
4.3.12 Operation in licensed frequency bands
4.3.12.1 General
IEEE 802.11 devices can operate on frequencies that are licensed by national regulatory bodies. Although
this standard has been generalized so that it is independent of license type, band, and country of operation,
only the bands and associated regulations listed in Annex D have been specifically considered.
4.3.12.2 Dynamic STA enablement (DSE) in licensed bands
The DSE operating procedures are used to automate the channel provisioning and regulatory controls
needed for unregistered IEEE 802.11 STAs to operate as dependent STAs in licensed spectrum.18
4.3.12.3 Contention based protocol (CBP) in nonexclusively licensed bands
The granting of licenses on a nonexclusive, uncoordinated basis in the same area leads to the possibility of
overlapping networks. When overlapping networks cause co-channel interference, regulations, such as those
governing the 3650 MHz band in the United States, require the use of a CBP “by which a transmitter
provides reasonable opportunities for other transmitters to operate.”19 IEEE 802.11 carrier sense multiple
access with collision avoidance (CSMA/CA) is suitable for this purpose in most situations.
4.3.12.4 Using DSE STA identification to resolve interference
When CSMA/CA is not able to sufficiently sense the presence of another licensee’s STA (i.e., a hidden
STA) or if a secondary licensee causes inference to a primary licensee, the secondary licensee is obliged to
resolve complaints that result from interference caused by any STA under its control (including dependent
STAs). In order to facilitate the interference resolution processes, all STAs operating in nonexclusively
licensed spectrum use the DSE STA and location information procedures.
The STA identification and location information procedures are tied because, by default, registered STAs
broadcast their actual location as their unique identifier. Dependent STAs broadcast the location of the STA
that has enabled them as well as a unique code selected by the licensee. This method puts a victim of the
interference in contact with the party responsible for rectifying the problem, and, at the same time, it protects
the privacy of the dependent STA’s operator.
4.3.12.5 Further coexistence enhancements in nonexclusively licensed bands
While not explicitly required to meet specific rules, a number of optional IEEE 802.11 mechanisms, when
used together, are able to meet general requirements for spectrum sharing, incumbent detection, and other
cognitive radio functions in licensed bands. The specific mechanisms for each band are detailed in E.2.
4.3.13 High-throughput (HT) STA
The IEEE 802.11 HT STA provides PHY and MAC features that can support a throughput of 100 Mb/s and
greater, as measured at the MAC data service access point (SAP). An HT STA supports HT features as
18In some licensed frequency bands, wireless equipment can be owned and operated by individuals who do not hold a license. In such
instances, devices are permitted to operate only if they are either communicating with, or receiving permission to transmit from, a STA
that is maintained by a licensed operator. The Japanese 4.9 GHz band and the U.S. 4.94–4.99 GHz public safety band are examples in
which IEEE 802.11 STAs operate under such arrangements.
19
Definition of CBP from FCC 05-56, Report and Order and Memorandum Opinion and Order, clause 58.
196
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
identified in Clause 10 and Clause 19. An HT STA operating in the 5 GHz band supports transmission and
reception of frames that are compliant with mandatory PHY specifications as defined in Clause 17. An HT
STA operating in the 2.4 GHz band supports transmission and reception of frames that are compliant with
mandatory PHY specifications as defined in Clause 16 and Clause 18. An HT STA is also a QoS STA. The
HT features are available to HT STAs associated with an HT AP. A subset of the HT features is available for
use between two HT STAs that are members of the same IBSS. Similarly, a subset of the HT features is
available for use between two HT STAs that have established mesh peering (see 9.4.2.56 for details).
An HT STA has PHY features consisting of the modulation and coding scheme (MCS) set described in
19.3.5 and physical layer (PHY) protocol data unit (PPDU) formats described in 19.1.4. Some PHY features
that distinguish an HT STA from a non-HT STA are referred to as multiple input, multiple output (MIMO)
operation; spatial multiplexing (SM); spatial mapping (including transmit beamforming); space-time block
coding (STBC); low-density parity check (LDPC) encoding; and antenna selection (ASEL). The allowed
PPDU formats are non-HT format, HT-mixed format, and HT-greenfield format (see 19.1.4). The PPDUs
can be transmitted with 20 MHz bandwidth and might be transmitted with 40 MHz bandwidth.
An HT STA has MAC features that include frame aggregation, some block ack features, power save multi-
poll (PSMP) operation, reverse direction (RD), and protection mechanisms supporting coexistence with
non-HT STAs.
4.3.14 Very high throughput (VHT) STA
The IEEE 802.11 VHT STA operates in frequency bands below 6 GHz excluding the 2.4 GHz band.
A VHT STA is an HT STA that, in addition to features supported as an HT STA, supports VHT features
identified in Clause 9, Clause 10, Clause 11, Clause 14, Clause 17, and Clause 21.
The main PHY features in a VHT STA that are not present in an HT STA are the following:
— Mandatory support for 40 MHz and 80 MHz channel widths
— Mandatory support for VHT single-user (SU) PPDUs
— Optional support for 160 MHz and 80+80 MHz channel widths
— Optional support for VHT sounding protocol to support beamforming
— Optional support for VHT multi-user (MU) PPDUs
— Optional support for VHT-MCSs 8 and 9
The main MAC features in a VHT STA that are not present in an HT STA are the following:
— Mandatory support for the A-MPDU padding of a VHT PPDU
— Mandatory support for VHT single MPDU
— Mandatory support for responding to a bandwidth indication (provided by the RXVECTOR
parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT) in a non-
HT and non-HT duplicate RTS frame
— Optional support for MPDUs of up to 11 454 octets
— Optional support for A-MPDU pre-end-of-frame (pre-EOF) padding (see 9.7.1) of up to 1 048 575
octets
— Optional support for VHT link adaptation
Most VHT features, among other benefits, increase the maximum throughput achievable between two VHT
STAs over that achievable using HT features alone. The VHT features are available to VHT STAs
associated with a VHT AP. A subset of the VHT features is available for use between two VHT STAs that
are members of the same IBSS. Similarly, a subset of the VHT features is available for use between two
197
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
VHT STAs that have established mesh peering. A subset of the VHT features is available for use between
two VHT STAs that have established a TDLS link.
The support for VHT transmit beamforming sounding and VHT MU PPDUs in a VHT AP and more than
one VHT STA within a VHT BSS enables the optional use of downlink MU multiple input, multiple output
(DL-MU-MIMO). With DL-MU-MIMO the AP can create up to four A-MPDUs, each carrying MPDUs
destined for an associated MU beamformee capable STA. The AP uses group identifiers (GIDs) to signal
potential recipient STAs. The AP transmits the A-MPDUs simultaneously in separate space-time streams
such that each recipient STA is able to demodulate the space-time streams carrying its A-MPDU. The
simultaneous transmission of A-MPDUs in a single VHT MU PPDU provides a means to increase aggregate
throughput over that achieved by sending the A-MPDUs in separate SU PPDUs.
The use of certain HT features, such as reduced interframe space (RIFS), is not permitted for VHT STAs.
4.3.15 Television very high throughput (TVHT) STA
The IEEE 802.11 TVHT STA operates in television white spaces (TVWS) bands.
A TVHT STA supports all mandatory features of a VHT STA as mandatory features except for HT-mixed
format PPDUs and 20 MHz, 40 MHz, and 80 MHz channel widths. A TVHT STA supports all optional
features of a VHT STA as optional features except for HT-greenfield format PPDUs, 160 MHz or 80+80
MHz channel widths, more than 4 spatial streams, and Short GI (which is mandatory).
The 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz channel widths and more than 4 spatial streams
are not used in STAs operating as TVHT STAs. The features and behaviors of VHT STAs specified in
Clause 6, Clause 8, Clause 9, Clause 10, Clause 11, Clause 14, and Annex G apply to TVHT STAs as well,
unless stated otherwise.
For Clause 6, Clause 8, Clause 9, Clause 10, Clause 11, and Clause 14, the following replacements are
applied for TVHT STAs:
— “TVHT_W/TVHT_2W” replaces “20/40 MHz”.
— “TVHT_W/TVHT_2W/TVHT_4W” replaces “20/40/80/160 MHz”.
— “TVHT_W”, “TVHT_2W”, and “TVHT_4W” replace “20 MHz”, “40 MHz”, and “80 MHz,”
respectively.
— “TVHT_W” replaces “CBW20”.
— “TVHT_2W” replaces “CBW40”.
— “TVHT_4W” replaces “CBW80” and “CBW80+80”.
— “secondaryTVHT_2W” replaces “secondary40”.
— “TVHT STA” replaces “VHT STA”.
— “TVHT AP” replaces “VHT AP”.
— “TVHT BSS” replaces “VHT BSS”.
— “TVHT-MCS” replaces “VHT-MCS”.
— “TVHT Operation” replaces “VHT Operation”.
— “dot11TVHTOptionImplemented” replaces “dot11VHTOptionImplemented”.
— “dot11TVHTControlFieldOptionImplemented” replaces both “dot11VHTControlFieldOption-
Implemented” and “dot11HTControlFieldSupported”.
— “dot11TVHTShortGIOptionIn4WActivated” replaces “dot11VHTShortGIOptionIn80Activated”.
— “dot11TVHTSUBeamformerOptionImplemented” replaces “dot11VHTSUBeamformerOption-
Implemented”.
198
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— “dot11TVHTSUBeamformeeOptionImplemented” replaces “dot11VHTSUBeamformeeOption-
Implemented”.
— “dot11TVHTMUBeamformerOptionImplemented” replaces “dot11VHTMUBeamformerOption-
Implemented”.
— “dot11TVHTMUBeamformeeOptionImplemented” replaces “dot11VHTMUBeamformeeOption-
Implemented”.
— “dot11TVHTTXOPPowerSaveOptionImplemented” replaces
“dot11VHTTXOPPowerSaveOptionImplemented”.
— “dot11TVHTOBSSScanCount” replaces “dot11VHTOBSSScanCount”.
— “dot11TVHTExtendedNSSBWCapable” replaces “dot11VHTExtendedNSSBWCapable”.
— Reference to 9.4.1.50 replaces reference to 9.4.1.49.
— Reference to 9.4.1.52 replaces reference to 9.4.1.51.
— Reference to 9.4.2.172 replaces reference to 9.4.2.159.
— Reference to 11.43 replaces reference to 11.40.1
— Reference to Clause 22 and its subclauses replace reference to Clause 21 and its subclauses.
For Annex G, the following replacements are applied for TVHT STAs:
— “TVHT” replaces “VHT”.
— “tvht” replaces “vht”.
The main PHY features in a TVHT STA that are not present in a VHT STA are the following:
— Mandatory support for TVHT_W channel width.
— Optional support for TVHT_W+W channel width.
— Optional support for TVHT_2W channel width.
— Optional support for TVHT_4W channel width.
— Optional support for TVHT_2W+2W channel width.
These TVHT features are available to TVHT STAs associated with a TVHT AP. A subset of the TVHT
features is available for use between two TVHT STAs that are members of the same IBSS.
4.3.16 STA transmission of Data frames outside the context of a BSS
In addition to defining procedures for STA communication within a BSS, this standard also defines
procedures for a STA that is not a member of a BSS to transmit Data frames. Such Data frames are defined
as being transmitted outside the context of a BSS (OCB). A STA transmits a Data frame outside the context
of a BSS only if dot11OCBActivated is true.
NOTE—The specific frame subtypes that a STA is allowed to send when it has dot11OCBActivated true are specified in
11.21.
When dot11OCBActivated is true, a Data frame can be sent to either an individual or a group destination
MAC address. This type of communication is possible only between STAs that are able to communicate
directly over the wireless medium. It allows immediate communication, avoiding the latency associated with
establishing a BSS. When dot11OCBActivated is true, a STA is not a member of a BSS and it does not
utilize the IEEE 802.11 authentication, association, or data confidentiality services. This capability is
particularly well suited for use in rapidly varying communication environments such as those involving
mobile STAs in which the interval over which the communication exchanges take place is of very short
duration (e.g., on the order of tens or hundreds of milliseconds). Since IEEE 802.11 MAC sublayer
authentication services are not used when dot11OCBActivated is true, any required authentication services
199
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
are provided by the station management entity (SME) or by applications outside of the MAC sublayer, such
as those described in the IEEE 1609 [B21] family of standards.
A STA whose MIB does not include dot11OCBActivated operates as if the attribute is false.
Communication of Data frames when dot11OCBActivated is true might take place in a frequency band that
is dedicated for its use, and such a band might require licensing depending on the regulatory domain (see
Annex E). A STA for which dot11OCBActivated is true initially transmits and receives on a channel known
in advance, either through regulatory designation or some other out-of-band communication. A STA’s SME
determines PHY parameters, as well as any changes in the operating channel, e.g., using information
obtained via out-of-band communication or over-the-air frame exchange. When dot11OCBActivated is true,
a sending STA sets the BSSID field to the wildcard BSSID value (see 9.2.4.3.4).
The Vendor Specific frame (see 9.6.6) provides one means for STAs to exchange management information
prior to communicating Data frames outside the context of a BSS.
4.3.17 Tunneled direct-link setup
Tunneled direct-link setup (TDLS) is characterized by the use of signaling frames that are encapsulated in
Data frames so that the signaling frames are transmitted through an AP transparently. Therefore, unlike with
DLS, the AP does not need to be direct-link aware, nor does it have to support the same set of capabilities
that are used on the direct link, in order for TDLS to be used. To allow a STA to enter a TDLS power save
mode, TDLS provides two power save mechanisms: TDLS peer unscheduled automatic power save delivery
(U-APSD) (TPU) and TDLS peer power save mode (PSM). TDLS allows STAs to use the TDLS PeerKey
(TPK) handshake to provide data confidentiality and message authentication. STAs that set up a TDLS
direct link remain associated with the AP and transmit frames directly to the other TDLS peer STA.
4.3.18 Wireless network management
4.3.18.1 Overview
Wireless network management (WNM) enables STAs to exchange information for the purpose of improving
the overall performance of the wireless network. STAs use WNM protocols to exchange operational data so
that each STA is aware of the network conditions, allowing STAs to be more cognizant of the topology and
state of the network. WNM protocols provide a means for STAs to be aware of the presence of collocated
interference, and enable STAs to manage RF parameters based on network conditions.
In addition to providing information on network conditions, WNM also provides a means to exchange
location information, provide support for the multiple BSSID capability on the same wireless infrastructure,
support efficient delivery of group addressed frames, and enable a WNM sleep mode in which a STA can
sleep for long periods of time without receiving frames from the AP.
The WNM service includes the following:
— BSS max idle period management
— BSS transition management
— Channel usage
— Collocated interference reporting
— Diagnostic reporting
— Directed multicast service (DMS)
— Event reporting
— Flexible multicast service (FMS)
200
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Location services
— Multicast diagnostic reporting
— Multiple BSSID capability
— Proxy Address Resolution Protocol (ARP)
— QoS traffic capability
— SSID list
— Triggered STA statistics
— TIM broadcast
— Timing measurement
— Traffic filtering service
— U-APSD coexistence
— WNM notification
— WNM sleep mode
4.3.18.2 BSS max idle period management
BSS max idle period management enables an AP to indicate a time period during which the AP does not
disassociate a STA due to nonreceipt of frames from the STA. This supports improved STA power saving
and AP resource management.
4.3.18.3 BSS transition management
BSS transition management enables an AP to request non-AP STAs to transition to a specific AP, or to
indicate to a non-AP STA a set of preferred APs, due to network load balancing or BSS Termination.
4.3.18.4 Channel usage
Channel usage information is provided by the AP to the non-AP STA to recommend channels for BSSs that
are not infrastructure BSSs or an off-channel TDLS direct link. The non-AP STAs can use the channel usage
information as part of channel selection processing for a BSS that is not an infrastructure BSS or an off-
channel TDLS direct link.
4.3.18.5 Collocated interference reporting
Collocated interference reporting enables the requesting STA to obtain information on interference due to
collocated radios at the reporting STA. The requesting STA can use that information to schedule its
transmissions to minimize the effects of the interference.
4.3.18.6 Diagnostic reporting
Diagnostic requests enable a STA to request a non-AP STA to report information that might be helpful in
diagnosing and resolving problems with the WLAN network. Diagnostic reports include information on
hardware, configuration, and STA capabilities.
4.3.18.7 Directed multicast service (DMS)
The DMS enables a non-AP STA to request the AP to transmit group addressed frames destined to the
requesting STA as individually addressed frames.
201
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.18.8 Event reporting
Event requests enable a STA to request a non-AP STA to send particular real-time event reports. The types
of events include transition, RSNA, WNM log, and peer-to-peer link events. A transition event is
transmitted after a non-AP STA successfully completes a BSS transition. Transition events are used to
diagnose transition performance problems. An RSNA event report describes the type of Authentication used
for the RSNA. RSNA events are used to diagnose security and authentication performance problems. A
WNM log event report enables a non-AP STA to transmit a set of WNM log event messages to the
requesting STA. WNM log event reports are used to access the contents of a STA’s WNM log. A peer-to-
peer link event report enables a non-AP STA to inform the requesting STA that a peer-to-peer link has been
established. peer-to-peer link event reports are used to monitor the use of peer-to-peer links in the network.
4.3.18.9 Flexible multicast service (FMS)
The flexible multicast service enables a non-AP STA to request an alternate delivery traffic indication map
(DTIM) delivery interval for one or more sets of group addressed streams that the non-AP STA receives.
This enables the non-AP STA to wake up at the alternate DTIM interval rather than every DTIM and enables
significant power saving when a non-AP STA receives group addressed traffic. The FMS also enables a
STA to establish a data rate and delivery interval for group addressed traffic higher than the minimum data
rate available.
Delivery of group addressed data to power saving STAs using a DTIM beacon is described in 11.2.3.4.
4.3.18.10 Location services
Location Configuration Request and Response frames enable STAs to configure a collection of location
related parameters for Location Track Notification frames. The AP can indicate that it can provide location
data to support applications such as emergency services. Location services also provide the ability for STAs
to exchange location information using Radio Measurement Request and Radio Measurement Report
frames. The protocol supports exchange-by-value and exchange-by-reference mechanisms. The location
value can be exchanged in geospatial (LCI) and civic formats. The location reference is a URL that defines
from where the location value is retrieved.
4.3.18.11 Multicast Diagnostic report
Multicast Diagnostic reports enable a non-AP STA to report statistics for multicast traffic it received from a
transmitting STA. This can be used by an AP to measure quality of multicast reception by a non-AP STA.
4.3.18.12 Multiple BSSID capability
The Multiple BSSID capability enables the advertisement of information for BSSIDs using a single Beacon
or Probe Response frame instead of multiple Beacon and Probe Response frames, each corresponding to a
single BSSID. The Multiple BSSID capability also enables the indication of buffered frames for multiple
BSSIDs using a single TIM element in a single beacon.
4.3.18.13 Proxy ARP
The Proxy ARP capability enables an AP to indicate that the non-AP STA does not receive ARP frames.
The Proxy ARP capability enables the non-AP STA to remain in power save for longer periods of time.
4.3.18.14 QoS traffic capability
QoS traffic capability procedures enable the QoS STA to indicate that it is capable of transmitting traffic
belonging to the corresponding user priority (UP) from applications that require generation of such traffic.
202
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The QoS Traffic Capability might be used for example as an input to estimate the blocking probability of a
voice application based on the number of voice capable non-AP STAs.
4.3.18.15 SSID list
The SSID List element enables the non-AP STA to request information on a list of SSIDs. This is intended
to reduce the number of Probe Request frames sent by the non-AP STA.
4.3.18.16 Triggered STA statistics
The Triggered STA Statistics reporting capability enables generation of a STA statistics report (see 4.3.11.9)
when the statistics of interest reach a predefined threshold.
4.3.18.17 TIM broadcast
The TIM broadcast protocol defines a mechanism to enable a STA to receive an indication of buffered
individually addressed traffic, independent of the Beacon frame, reducing the wake time of the STA.
4.3.18.18 Timing measurement
Timing Measurement frames allow a recipient STA to accurately measure the offset of its clock relative to a
clock in the sending STA. With the regular transfer of Timing Measurement frames from one STA to
another, it is possible for the recipient STA to track changes in the offset of its clock with respect to the
sending STA over time and thus detect and compensate for any drift between the clocks.
4.3.18.19 Fine timing measurement
Fine timing measurement allows a STA to accurately measure the round trip time (RTT) between it and
another STA. With the regular transfer of Fine Timing Measurement frames it is possible for the recipient
STA to track changes in its relative location with other STAs in the environment.
4.3.18.20 Traffic filtering service
The traffic filtering service enables an AP to determine if MSDUs and Management frames destined for a
STA match a specific set of traffic filters that are enabled at the AP per the request of the STA. Individually
addressed frames that do not match any of the traffic filters in the set are discarded. Individually addressed
frames that do match at least one of the set of the enabled traffic filters are delivered to the STA. The STA
can also negotiate to have a notification frame sent prior to the delivery of the frame matching the traffic
filter.
4.3.18.21 U-APSD coexistence
The U-APSD coexistence capability enables the non-AP STA to indicate a requested transmission duration
to the AP for use of U-APSD service periods. Use of the transmission duration enables the AP to transmit
frames during the service period and improve the likelihood that the non-AP STA receives the frames when
the non-AP STA is experiencing interference. The U-APSD coexistence capability reduces the likelihood
that the AP transmits frames during the service period that are not received successfully.
4.3.18.22 WNM notification
WNM notification provides a mechanism for a STA to notify another STA of a management event. One
event is defined: firmware update notification.
203
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.18.23 WNM sleep mode
WNM sleep mode is an extended power save mode for non-AP STAs in which a non-AP STA need not
listen for every DTIM Beacon frame, and need not perform GTK/IGTK updates. WNM sleep mode enables
a non-AP STA to signal to an AP that it might sleep for a specified length of time. This enables a non-AP
STA to reduce power consumption and remain associated while the non-AP STA has no traffic to send to or
receive from the AP.
4.3.19 Subscription service provider network (SSPN) interface
An AP can interact with external networks using a SSPN interface for the purpose of authenticating users
and provisioning services, as shown in Figure 4-8. The exchange of authentication and provisioning
information between the SSPN and the AP passes transparently through the portal. The protocol used to
exchange this information is outside the scope of this standard. The logical SSPN interface provides the
means for an AP to consult an SSPN for authenticating and authorizing a specific non-AP STA and to report
statistics and status information to the SSPN. Authentication and provisioning information for non-AP STAs
received from the SSPN are stored in the AP management information base (MIB) and are used to limit
layer-2 services provided to that non-AP STA. Detailed interactions describing the SSPN interface are
provided in 11.25.5.
BSS1
802.11 MAC/PHY ESS
STA1
STA2
AP
DS
Portal SSPN
AP
Interface
802.x LAN
STA3
STA4
AAA & Data 802.11 MAC/PHY
Connection
BSS2
SSPN = DN
Figure 4-8—SSPN interface service architecture
The SSPN interface provides the non-AP STA access to the services provisioned in the SSPN via the
currently associated BSS. Services might include virtual local area network (VLAN) mapping and tunnel
establishment that are transparent to the non-AP STA and outside the scope of this standard. The SSPN
interface also allows the non-AP STA to access services in destination networks (DNs) other than the SSPN.
An example of a DN other than SSPN is the provision of Internet access via the IEEE 802 LAN, or an
intermediary network that connects the IEEE 802.11 infrastructure and the SSPN.
NOTE—The SSPN Interface Service is not supported in an IBSS.
204
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.20 Mesh BSS
4.3.20.1 General
The IEEE 802.11 mesh facility provides MAC enhancements to support wireless LAN mesh topologies. The
mesh facilities are available to mesh STAs that belong to a mesh BSS (MBSS). Only the mesh discovery
service is available to a mesh STA that has not become a member of an MBSS. The enhancements that
distinguish mesh STAs from nonmesh STAs are collectively termed the “mesh facility.” The mesh-specific
mechanisms vary among implementations.
4.3.20.2 Overview of the mesh BSS
A mesh BSS is an IEEE 802.11 LAN consisting of autonomous STAs. Inside the mesh BSS, all STAs
establish wireless links with neighbor STAs to mutually exchange MSDUs. Further, using the multi-hop
capability, MSDUs and Management frames can be transferred between STAs that are not in direct
communication with each other over a single instance of the wireless medium. From the data delivery point
of view, it appears as if all STAs in a mesh BSS are directly connected at the MAC layer even if the STAs
are not within range of each other. The multi-hop capability enhances the range of the STAs and benefits
wireless LAN deployments.
STAs in a mesh BSS might be sources, sinks, or propagators of traffic; some mesh STAs might propagate
traffic for other STAs, but do not act as a source or sink of traffic. As described in 4.3.20.4, a mesh BSS
might have interfaces to external networks and can be a DSM for infrastructure BSSs.
Within a mesh BSS, STAs utilize the mesh coordination function (MCF) to access the channel. MCF is
based on the core QoS facility described in 4.3.10, and a mesh BSS is categorized as one type of QoS BSS.
MCF is specified in 10.23.
4.3.20.3 Mesh STA
A STA that belongs to a mesh BSS is termed a “mesh station” (mesh STA). Mesh STAs are QoS STAs that
support mesh services, i.e., they participate in formation and operation of a mesh basic service set (MBSS).
A mesh STA implements a subset of the QoS functionality:
— Use of QoS frame format
— EDCA (as a part of MCF)
— Block acknowledgment (optional)
— No acknowledgment (optional)
— Use of TSPEC, TCLAS, and TCLAS Processing elements to establish DMS or GCR agreements
(optional)
A mesh BSS does not incorporate the full hybrid coordinator (HC) and BSS QoS functionality. MBSSs do
not incorporate the following:
— HCCA
— Traffic stream (TS) management
— Admission control
— Automatic power save delivery (APSD)
— Direct-link setup (DLS)
— Tunneled direct-link setup (TDLS)
205
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.20.4 IEEE 802.11 components and mesh BSS
Example mesh and infrastructure BSSs are illustrated in Figure 4-9. Only mesh STAs participate in mesh
functionalities such as formation of the mesh BSS, path selection, and forwarding. Accordingly, a mesh
STA is not a member of an IBSS or an infrastructure BSS. Consequently, mesh STAs do not communicate
with nonmesh STAs.
infrastructure
BSS 18
STA 19
STA 20
STA 18 DS
Mesh
AP AP infrastructure Gate
BSS 13
STA 13
Mesh
STA 9
STA 14 STA 15
Mesh
STA 11
Mesh
Portal infrastructure STA 10
Non-802.11 BSS 17
LAN STA 21
Mesh
STA 22 STA 12
STA 33
infrastructure STA 17 STA 8
BSS 25 Mesh
mesh
STA 26
AP BSS 2
STA 27
Portal Mesh
Gate
STA 25
AP
DS collocated DS
with
DS Mesh
Mesh Gate
Mesh
Gate Gate
Mesh Mesh Mesh
STA 1 STA 5 STA 2
Mesh
STA 16
Mesh Mesh Mesh
Mesh
STA 3 STA 6
mesh
STA 4 STA 7
BSS 1
Figure 4-9—Example MBSS containing mesh STAs, mesh gates, APs, and portals
However, instead of existing independently, an MBSS might also access the distribution system (DS). The
MBSS interconnects with other BSSs through the DS. Then, mesh STAs can communicate with nonmesh
STAs. Therefore, a logical architectural component is introduced in order to integrate the MBSS with the
DS—the mesh gate. Data move between an MBSS and the DS via one or more mesh gates. Thus, the mesh
gate is the logical point at which MSDUs from an MBSS enter the IEEE 802.11 DS, via the DSAF. Once an
206
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MBSS contains a mesh gate that connects it to the IEEE 802.11 DS, the MBSS can be integrated with other
infrastructure BSSs too, given that their APs connect to the same DS. Several mesh gates are shown in
Figure 4-9 connecting different MBSSs to the DS.
When an MBSS accesses the IEEE 802.11 DS through its mesh gate, the MBSS can be integrated with a
non-IEEE-802.11 LAN. To integrate the IEEE 802.11 DS to which this MBSS connects, the DS needs to
contain a portal. See 4.3.7. Consequently, mesh gate and portal are different entities. The portal integrates
the IEEE 802.11 architecture with a non-IEEE-802.11 LAN (e.g., a traditional wired LAN), whereas the
mesh gate integrates the MBSS with the IEEE 802.11 DS.
It is possible for one device to offer any combination of the functions of an AP, a portal, and a mesh gate; see
14.11.5. An example device combining the functions of an AP and a mesh gate is shown in Figure 4-10. The
implementation of such collocated entities is beyond the scope of this standard. The configuration of a mesh
gate that is collocated with an access point allows the utilization of the mesh BSS as a distribution system
medium. In this case, two different entities (mesh STA and access point) exist in the collocated device and
the mesh BSS is hidden to STAs that associate to the access point. The mesh STA collocation is outlined in
14.11.5, which states that the usage of a distinct MAC address for each collocated STA avoids ambiguities.
infrastructure
BSS 25
STA 26 STA 27
STA 25
AP
DS
Mesh Gate
Mesh
STA 5
Mesh
STA 2
Mesh
STA 4 Mesh Mesh
STA 6 STA 7
mesh
BSS 1
Figure 4-10—Example device consisting of mesh STA and AP STA
to connect an MBSS and an infrastructure BSS
4.3.20.5 Introduction to mesh functions
4.3.20.5.1 General
A mesh BSS is formed and operated by the set of services called mesh services. Mesh services are provided
by the following major mesh facilities:
— Mesh discovery
— Mesh peering management
207
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Mesh security
— Mesh beaconing and synchronization
— Mesh coordination function
— Mesh power management
— Mesh channel switching
— Three address, four address, and extended address frame formats
— Mesh path selection and forwarding
— Interworking with external networks
— Intra-mesh congestion control
— Emergency service support in mesh BSS
4.3.20.5.2 Mesh discovery
A mesh STA performs either active scanning or passive scanning to discover an operating mesh BSS. Each
mesh STA transmits Beacon frames periodically and responds with Probe Response frames when a Probe
Request frame is received, so that neighbor mesh STAs can perform mesh discovery appropriately. The
identification of the mesh BSS is given by the Mesh ID element contained in the Beacon and the Probe
Response frames. The details for the mesh discovery facility are described in 14.2.
4.3.20.5.3 Mesh peering management (MPM)
Within a mesh BSS, direct communication between neighbor mesh STAs is allowed only when they are peer
mesh STAs. After mesh discovery, two neighbor mesh STAs agree to establish a mesh peering to each other,
and, after successfully establishing the mesh peering, they become peer mesh STAs. A mesh STA can
establish a mesh peering with multiple neighbor mesh STAs. The mesh peering management (MPM)
facilitates the mesh peering establishment and closure of the mesh peerings. The details of MPM are
described in 14.3.
4.3.20.5.4 Mesh security
In an MBSS, mesh link security protocols are used to authenticate a pair of mesh STAs and to establish
session keys between them. Mesh authentication protocols establish a shared, common pairwise master key
(PMK), and authenticate a peer mesh STA. The authenticated mesh peering exchange protocol relies on the
existence of the PMK between the two mesh STAs to establish an authenticated peering and derive session
keys. The details of mesh security are described in 12.4, 14.3.3, 14.5, and 14.6.
4.3.20.5.5 Mesh beaconing and synchronization
In order to assist mesh discovery, mesh power management, and synchronization in a mesh BSS, all mesh
STAs periodically transmit Beacon frames. Synchronization in a mesh BSS is maintained by the MBSS’s
active synchronization method. The default synchronization method is the neighbor offset synchronization
method. Mesh beacon collision avoidance (MBCA) mitigates collisions of Beacon frames among hidden
nodes. The details of mesh beaconing and synchronization are described in 14.13.
4.3.20.5.6 Mesh coordination function (MCF)
A mesh STA uses the mesh coordination function (MCF) for channel access. MCF consists of EDCA
(contention based channel access defined in 10.23.2) and MCCA (controlled channel access defined in
10.23.3). MCCA is a reservation based channel access method and aims to optimize the efficiency of frame
exchanges in a mesh BSS.
208
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.20.5.7 Mesh power management
A mesh STA can manage the activity level of its links per mesh peering. A mesh STA sets the activity level
of each of its mesh peerings to either active mode, light sleep mode, or deep sleep mode. The mesh STA
performs mesh power management mode tracking for each of its neighbor peer mesh STAs, and delivers the
frames based on the rules defined in 14.14.
4.3.20.5.8 Mesh channel switching
When a mesh STA switches the operating channel, it uses the channel switching protocol defined in 11.9.8
and 11.10. The channel switching protocol enables the propagation of channel switch notifications
throughout the mesh BSS, prior to the channel switch execution.
4.3.20.5.9 Frame addressing in an MBSS
Three address, four address, and extended address frame formats enable the distribution of MSDUs over
multiple instances of the wireless medium within a mesh BSS and integration to the ESS. Frame format
details are described in Clause 9 and 9.3.5.
4.3.20.5.10 Mesh path selection and forwarding
Mesh path selection enables path discovery over multiple instances of the wireless medium within a mesh
BSS. The overview of the mesh path selection framework is described in 14.8. The hybrid wireless mesh
protocol (HWMP) is defined as the default path selection protocol for the mesh BSS. HWMP provides both
proactive path selection and reactive path selection. The details of HWMP are described in 14.10. The path
selection protocol uses link metrics in the assessment of a mesh path to the destination. The airtime link
metric is the default link metric. It is defined in 14.9.
Once the mesh path of a particular pair of the source mesh STA and the destination mesh STA is found
through the mesh path selection function, mesh STAs propagate the data by the forwarding function. The
details of the forwarding function are described in 10.35.
As a result of the mesh path selection and forwarding, MSDUs are transmitted among all of the mesh STAs
in a mesh BSS, even if the mesh STAs are not neighbor STAs of each other. Figure 4-11 depicts the MSDU
transfer within a mesh BSS.
4.3.20.5.11 Interworking with the DS
A mesh BSS might contain one or more mesh gates that connect to one or more distribution systems. A
mesh gate can announce its presence in the mesh BSS by sending Gate Announcement frames. Alternatively
a mesh gate can announce its presence in the mesh BSS by sending HWMP Path Selection frames with the
RANN element or the PREQ element indicating mesh gate announcement, when it is configured as a root
mesh STA. Typically a mesh gate announces its presence when it is collocated with a portal or it has access
to a portal. Gate announcements allow mesh STAs to select the appropriate mesh gate and build a path
toward it. Note that, when multiple mesh gates that have access to the same DS are present in the mesh BSS,
proper configuration is necessary.
When a mesh gate has access to IEEE 802 STAs outside the mesh BSS, the mesh gate acts as a proxy for the
IEEE 802 STAs outside the MBSS. Such a mesh gate is called a proxy mesh gate. The details of the proxy
functionality are described in 14.11.3.
The details of the mesh BSS interworking are described in 14.11.
209
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MSDU source MSDU MSDU destination
MAC SAP
Mesh Mesh
STA 4 STA 6
Mesh Mesh
STA 1 STA 7
Mesh
STA 5
Mesh
Mesh STA 2 Mesh
STA 8
STA 3
Mesh
mesh BSS Mesh STA 10
(MBSS) STA 9 Mesh
STA 11
Figure 4-11—MAC data transport over an MBSS
4.3.20.5.12 Intra-mesh congestion control
Intra-mesh congestion control is used to provide flow control over the multi-hop communication. Intra-mesh
congestion control is useful to mitigate wasteful wireless medium utilization caused by buffer overflow at
mesh STAs. Intra-mesh congestion control consists of three main mechanisms: local congestion monitoring
and congestion detection, congestion control signaling, and local rate control. The details of the intra-mesh
congestion control are described in 14.12.
4.3.20.5.13 Emergency service support in mesh BSS
Depending on regulations, emergency services support might be mandated over the mesh network. In this
case the Beacon and Probe Response frames inform whether a mesh STA supports emergency services,
advertising to other mesh STAs that mesh peering for emergency services is possible. If a mesh STA
subsequently requires emergency services, an emergency indication is then set within the Mesh Peering
Open frame. Mesh STAs that support emergency services, accept peering from other mesh STAs requiring
emergency services, transferring frames to an emergency server (such as a PSAP).
4.3.21 DMG STA
The IEEE 802.11 DMG STA provides PHY and MAC features that can support a throughput of 1 Gb/s and
greater, as measured at the MAC data service access point (SAP). A DMG STA supports DMG features as
identified in Clause 10, Clause 11, and Clause 20. A DMG STA operates in a DMG BSS and supports
transmission and reception of frames that are compliant with PHY specifications as defined in Clause 20. A
DMG STA is also a QoS STA. The basic channel access of a DMG STA (see 10.36) allows it to operate in
an Infrastructure BSS, in an IBSS, and in a PBSS. Certain DMG features such as service period allocation
are available only to DMG STAs that are associated with an AP or with a PCP, while other DMG features
such as EDCA operation in a PBSS do not require association. A DMG STA supports beamforming (BF) as
described in 10.38 and 20.10 and GCM encryption as described in 12.5.5.
A DMG STA supports the PHY signaling as described in 20.4, 20.5, 20.6, and 20.7. At a minimum, a DMG
STA supports the mandatory modulation and coding scheme (MCS) and PHY protocol data unit (PPDU)
formats described in 20.4 and 20.6. A DMG STA has PHY features that include a low-density parity check
210
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(LDPC) encoding, a preamble making use of Golay sequences, and beamforming. The PPDUs are always
transmitted with the same channel spacing as described in Annex E.
A DMG STA supports MAC features that provide channel access in an environment in which transmissions
use a directional antenna pattern. A DMG STA has MAC features that include frame aggregation, block ack
features, service periods, contention based access periods, DMG protected period, AP or PCP clustering,
dynamic channel time management, reverse direction, spatial sharing, beamforming, and operation (fast
session transfer) in a multi-band device. A DMG STA is not a mesh STA. A DMG STA does not use any of
the following: HCCA, power save multi-poll (PSMP), DLS, TDLS, HT-delayed block ack, GCR.
4.3.22 DMG relay
The IEEE 802.11 DMG relay function allows a source relay endpoint DMG STA (REDS) to transmit frames
to a destination REDS with the assistance of another DMG STA, the relay DMG STA (RDS), as shown in
Figure 4-12. Relaying can improve the reliability of communication in a DMG BSS in the case the direct
link between the source REDS and the destination REDS has poor quality or is disrupted. Following the
DMG relay setup procedures, a source REDS can discover and select an appropriate RDS to act as the relay
for a particular destination REDS, prior to Data frame transmission using the relay. A relay operating as a
link switching type of relay uses the RDS to forward frames between the source and destination REDS if the
direct link between the REDS is disrupted. In a link cooperation of relay operation, the RDS simultaneously
repeats the transmission of frames between the source and destination REDS, which can possibly increase
the signal quality received at the destination REDS.
STA 2 (RDS)
Relay links
STA 5 (REDS)
STA 1 (REDS) STA 4
STA 3
Figure 4-12—DMG relay in a DMG BSS
4.3.23 Robust audio video (AV) streaming
Robust AV streaming improves AV streaming performance when using IEEE Std 802.11 for consumer and
enterprise applications.
4.3.23.1 Groupcast with retries (GCR)
The GCR service allows a STA to request greater reliability for one or more group addressed streams that
the STA receives. Greater reliability is provided via unsolicited retries or the block ack mechanism. A non-
AP STA can request delivery so that the AP transmits the frames via EDCA within GCR service periods
when all associated non-AP STAs are in active mode or the awake state of the PS mode.
211
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.23.2 Stream classification service (SCS)
SCS enables the establishment of a classification using layer 2 and/or layer 3 signaling to match incoming
unicast MSDUs. Once classified, unicast MSDUs matching the classification are assigned to an access
category and are tagged with their drop eligibility. When intra-access category prioritization is enabled (see
4.3.23.5), SCS allows MSDUs matching the classification to be assigned to the primary or alternate transmit
queues so that finer grained prioritization can be applied.
4.3.23.3 Overlapping BSS (OBSS) management
The objective of OBSS management is to facilitate cooperative sharing of the medium between APs that
operate in the same channel and that are able to receive or obtain frames from each other, including Beacon
frames. These frames might be received directly or via associated STAs that support the Beacon request
capability (see 11.11.10).
OBSS management provides the means to
— Provide additional information for channel selection
— Extend the admission control mechanism to a distributed environment
— Enable the coordination of scheduled TXOPs between OBSSs
OBSS management enables stationary and portable APs to provide to neighboring APs information for the
selection of a channel and for the cooperative sharing of that channel. The main component of OBSS
management is the QLoad report that provides information on
— The reporting AP’s overlap situation
— The reporting AP’s QoS traffic load
— The total QoS traffic load of BSSs directly overlapping the reporting AP’s BSS
This information might be used to aid an AP when searching for a channel and also when sharing a channel
in an overlap situation.
To coordinate the TXOPs of overlapping HCCA APs, OBSS management provides a means for an AP to
advertise its TXOP allocations so another AP might schedule its own TXOPs to avoid those already
scheduled.
4.3.23.4 Interworking with IEEE 802.1Q™ Stream Reservation Protocol (SRP)
Support for SRP from IEEE Std 802.1Q enables integration of the TSPEC ADDTS request/response
protocol with IEEE 802.1Q SRP to enable end-to-end SRP reservations when one or more IEEE 802.11
links are part of a path from IEEE 802.1Q Talker to IEEE 802.1Q Listener.
4.3.23.5 Intra-access category prioritization
Intra-access category prioritization provides six transmit queues that map to four enhanced distributed
channel access functions (EDCAFs) to enable differentiation between traffic streams that are in the same
access category in order for finer grained prioritization to be applied between individual AV streams or
voice streams.
212
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.3.24 Operation under geolocation database (GDB) control
Regulators designate television broadcast bands for the deployment of dynamic sharing technologies.
Different schemes result in different times that elapse from the moment an authorized database is told to
change access to a particular slice of spectrum and the time that sharing radios are required to change their
operations.
One current system design allows the GDBs to utilize a fully populated map of all protected services, and
the databases have precalculated maps that are effective on timescales of one to two days.
Another system design allows the protected services to negotiate with controllers of unlicensed devices so
that both can share available broadcast channels and facilitate response times of less than an hour where
necessary and even within minutes if desired.
Another system design has the GDB fully control all white space devices by requiring them to tell the
database their intended location and emissions footprint and receive permission before any broadcast band
transmission starts. Any change of intended frequencies or powers is told to the database, and permission is
received before the change takes place.
The architectural role of components depends on the security and timeliness requirements in particular
regulatory domains. Figure 4-13 shows two infrastructure BSSs in which APs are geolocation database
dependent (GDD) enabling STAs and the other STAs are GDD dependent STAs.
AP1 STA1
GDD enabling STA GDD dependent STA
GDB1
Registered Location Secure STA2
Server GDD dependent STA
RLSS
AP2 STA3
GDD dependent STA
GDD enabling STA
GDB2
Outside scope of IEEE Std 802.11 Scope of IEEE Std 802.11
Figure 4-13—Multiple APs and multiple GDBs
In most regulatory domains, GDD enabling STAs are required to
— Securely communicate with GDBs
— Maintain the white space maps (WSMs) and other information received from GDBs
— Create and transmit a contact verification signal to inform GDD dependent STAs that the map they
received is still valid
213
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A registered location query protocol (RLQP) is provided to share the WSMs and current channel use among
GDD enabling STAs in a neighborhood. GDD dependent STAs can query both their GDD enabling STA and
the registered location secure server (RLSS) about WSMs and channel utilization. In some regulatory
domains, a RLSS can provide GDBs with the current channel use information for all of the BSSs and IBSSs
that communicate with it. In some regulatory domains, the RLSS communicates with controllers of other
white space systems to coordinate emissions footprints of their services. By accessing and using this
information, the STAs can make intelligent decisions about the most effective way to utilize the available
spectrum, power, and bandwidth for their communications.
The specific mechanisms are as follows:
— Channel availability query, used to obtain one or more WSMs of available channels for an area or a
geolocation
— Channel schedule management, used to obtain start and ending times for each available white space
channel
— Contact verification signal, used by a GDD dependent STA to verify it is still receiving frames from
its GDD enabling STA
— GDD enablement, the procedure where a GDD enabling STA forms a network and maintains the
network under the control of a GDB
— Network channel control, used to inform a local channel controller that has a view of nearby
transmitters and their emissions footprints
— WSM, used to retrieve the available white space channels and their transmit power restrictions
The use of the mechanisms in a particular regulatory domain depends on the specific regulatory
requirements. Table 4-1 gives a view of the use of specific mechanisms to meet regulatory requirements in
terms of daily, hourly, and minute timescales. Implementers are referred to the regulatory sources in
Table D.1 for further information. Operation in countries within defined regional regulatory domains might
be subject to additional or alternative national regulations.
Table 4-1—GDD mechanisms and timescales
Daily consultation Hourly consultation
Mechanism Minute responsiveness
required required
Channel availability query Informative Informative Not applicable
Channel schedule Informative Informative Not applicable
management
Contact verification signal Required to be secure Might be secure Loss of consecutive
signals requires action
GDD enablement Required Required Required
Network channel control Informative Informative Not applicable
WSM Required for GDD Required for GDD Required for GDD
enabling STA, might be enabling STA, might be enabling STA, might be
translated for GDD translated for GDD translated for GDD
dependent STA dependent STA dependent STA
These mechanisms allow a BSS to manage and query its radio environment and a GDB to control the radio
environment for all wireless services.
214
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.4 Logical service interfaces
4.4.1 General
IEEE Std 802.11 explicitly does not specify the details of implementations. Instead, IEEE Std 802.11
specifies services to aid understanding how the architectural components are logically organized. The
services are associated with different components of the architecture. There are three categories of
IEEE 802.11 service—the station service (SS), the PCP service (PCPS), and the distribution system service
(DSS). These categories of service are used by the IEEE 802.11 MAC sublayer.
The complete set of IEEE 802.11 architectural services are as follows:
a) Authentication
b) Association
c) Deauthentication
d) Disassociation
e) Distribution
f) Integration
g) Data confidentiality
h) Reassociation
i) MSDU delivery
j) DFS
k) TPC
l) Higher layer timer synchronization (QoS facility only)
m) QoS traffic scheduling (QoS facility only)
n) Radio measurement
o) DSE
This set of services is divided into three groups: the SS, the PCPS, and the DSS. The SS is part of every
STA. The PCPS is provided by the PCP of a PBSS. The DSS is provided by the DS.
4.4.2 SS
The service provided by STAs is known as the SS.
The SS is present in every IEEE 802.11 STA (including APs, as APs include STA functionality). The SS is
specified for use by MAC sublayer entities. All STAs provide the SS.
The SS is as follows:
a) Authentication (not used when dot11OCBActivated is true)
b) Deauthentication (not used when dot11OCBActivated is true)
c) Data confidentiality (not used when dot11OCBActivated is true)
d) MSDU delivery
e) DFS
f) TPC
g) Higher layer timer synchronization (QoS facility only)
h) QoS traffic scheduling (QoS facility only)
215
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
i) Radio measurement
j) DSE
4.4.3 PBSS control point service (PCPS)
The service provided by the PCP of a PBSS is known as the PCPS. Since each STA within a PBSS can
operate as a PCP, each STA in the PBSS is capable of providing the PCPS, if it becomes the PCP of the
PBSS. Non-PCP STAs do not provide the PCPS.
The services that comprise the PCPSs are the following:
a) Association
b) Disassociation
c) Reassociation
d) QoS traffic scheduling
The PCPS is specified for use by MAC sublayer entities.
4.4.4 DSS
The service provided by the DS is known as the DSS. IEEE Std 802.11 explicitly does not specify the details
of DS implementation structure. Instead, IEEE Std 802.11 specifies the services that are provided by a DS
implementation. A DS can be created from many different technologies including current IEEE 802 wired
LANs. IEEE Std 802.11 does not constrain the DS to be either data link or network layer based. Nor does
IEEE Std 802.11 constrain a DS to be either centralized or distributed in nature.
This service is represented in the IEEE 802.11 architecture by arrows within APs and mesh gates, indicating
that the service is used to cross media and possibly address space logical boundaries. An AP and a mesh gate
are logical entities, and the functions described might be shared by one or more physical entities.
The services that comprise the DSS are as follows:
a) Association (not mesh facility)
b) Disassociation (not mesh facility)
c) Distribution
d) Integration
e) Reassociation (not mesh facility)
f) QoS traffic scheduling (QoS facility only)
g) DSE
h) Interworking with the DS (mesh facility only)
DSSs are specified for use by MAC sublayer entities.
Figure 4-14 combines the components from previous figures with the three types of services to show the
IEEE 802.11 architecture for infrastructure BSS and PBSS.
216
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IEEE Std 802.11 Components
BSS 1
802.11 MAC/PHY
STA 1
SS STA 2
BSS 3
AP ESS
STA 6 DSS
Y
H
P
/
DS
SS C
A
M
1
1
.
2
0
8 DSS
DSS AP
STA 5 Portal
PCP STA 3 SS
PCPS
STA 4
802.11 MAC/PHY
BSS 2
802.x LAN
Figure 4-14—IEEE 802.11 architecture for infrastructure BSS and PBSS
4.5 Overview of the services
4.5.1 General
There are many services specified by IEEE Std 802.11. Six of the services are used to support medium
access control (MAC) service data unit (MSDU) delivery between STAs. Three of the services are used to
control IEEE 802.11 LAN access and confidentiality. Two of the services are used to provide spectrum
management. One of the services provides support for LAN applications with QoS requirements. Another of
the services provides support for higher layer timer synchronization. One of the services is used for radio
measurement.
This subclause presents the services, an overview of how each service is used, and a description of how each
service relates to other services and the IEEE 802.11 architecture. The services are presented in an order
designed to help build an understanding of the operation of an IEEE 802.11 network. As a result, the
services that comprise the SS and DSS are intermixed in order (rather than being grouped by category). The
services that comprise the PCPS are a subset of the services provided by the SS and DSS.
Each of the services is supported by one or more MAC frame types. Some of the services are supported by
MAC management PDUs, which are transported in MAC Management frames. The MSDU delivery service
is supported by MAC Data frames. All of these frames gain access to the WM via the IEEE 802.11 MAC
sublayer medium access method specified in Clause 10.
The IEEE 802.11 MAC sublayer uses four types of frame—Data, Management, Extension, and Control (see
Clause 9). Data frames are handled by the MAC data plane (see Figure 5-1).
217
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAC Management frames and MAC Extension frames (see 9.3.4) are handled via the MAC management
plane.
MAC Control frames are used to support the delivery of IEEE 802.11 Data, Management, and Extension
frames.
The examples here assume an ESS environment. The differences among the ESS, the PBSS, and the IBSS
environments are discussed separately in 4.7.
4.5.2 Distribution of MSDUs within a DS
4.5.2.1 Distribution
This is the primary service used by IEEE 802.11 STAs. It is conceptually invoked by every data message to
or from an IEEE 802.11 STA operating in an ESS (when the frame is sent via the DS). Distribution is via
the DSS.
Refer to the ESS in Figure 4-15 and consider an MSDU being sent from STA 1 to STA 4. One or more
frames containing the MSDU are sent from STA 1 and received by STA 2 (the “input” AP). The AP gives a
MAC service tuple containing the MSDU to the DSS. It is the job of the distribution service to deliver the
MAC service tuple within the DS in such a way that it arrives at the appropriate DS destination for the
intended recipient. In this example, the MAC service tuple is distributed to STA 3 (the “output” AP) and
STA 3 accesses the WM to send one or more frames containing the MSDU to STA 4 (the intended
destination).
Integration
Distribution System Portal
Non‐802.11
network
802.1X Port 802.1X Port
Filtering (Optional) Filtering (Optional)
Data Link MAC Sublayer
Layer MAC Sublayer
STA2 STA3
Physical
PHY PHY
Layer
APs
Non‐AP
STA STA4
Non‐AP
STA1 STA Non‐AP
STA
Figure 4-15—IEEE 802.11 Infrastructure model
218
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The previous example was a case in which the AP that invoked the distribution service was different from
the AP that received the distributed MAC service tuple. If the MSDU had been intended for a STA that was
a member of the same BSS as the sending STA, then the “input” and “output” APs for the MAC service
tuple would have been the same.
If a MAC service tuple with a group addressed destination is provided to the DS, the DS is responsible for
delivering that MAC service tuple to all appropriate APs in the ESS, including the “input” AP, to allow the
AP to send frame(s) containing the MSDU to other associated non-AP STAs in its BSS. Generally, the DS
will deliver the MAC service tuple to all the APs in the ESS. Optionally, an implementation-specific or
higher layer filtering may be applied to restrict the delivery to a known subset of the APs in the ESS; such
filtering is beyond the scope of this standard.
How the MAC service tuple is distributed within the DS is not specified by IEEE Std 802.11. All IEEE Std
802.11 is required to do is to provide the DS with enough information for the DS to be able to determine the
“output” point that corresponds to the intended recipient. The necessary information is provided to the DS
by the three association related services (association, reassociation, and disassociation).
In all the examples above, the distribution service was logically invoked. Whether the MAC service tuple
actually had to traverse the physical DSM or not is a DS implementation matter and is not specified by this
standard.
While IEEE Std 802.11 does not specify DS implementations, it does recognize and support the use of the
WM as one possible DSM. This is specifically supported by the IEEE 802.11 frame formats. (Refer to
Clause 9 for details.) A mesh BSS might form an entire DS or a part of a DS using the WM, as shown in
Figure 4-9. Mesh services are used to form a mesh BSS and distribute MSDUs. Clause 14 defines how mesh
BSSs are formed and how MSDUs are distributed through a mesh BSS.
4.5.2.2 Integration
When the distribution service determines that the intended recipient of an MSDU is a member of an
integrated LAN, the “output” point of the DS is a portal instead of an AP.
MAC service tuples that are distributed to a portal cause the DS to invoke the Integration function
(conceptually after the distribution service). The Integration function is responsible for accomplishing
whatever is needed to deliver a MAC service tuple from the DSM to the integrated LAN media (including
any required media or address space translations). Integration is one of the services in the DSS.
MSDUs received from an integrated LAN (via a portal) by the DS for an IEEE 802.11 STA invoke the
Integration function before the MAC service tuple is distributed by the distribution service.
The details of an Integration function are dependent on a specific DS implementation and are outside the
scope of this standard.
4.5.2.3 QoS traffic scheduling
QoS traffic scheduling provides intra-BSS QoS frame transfers under the HCF, using either contention
based or controlled channel access. At each TXOP, a traffic scheduling entity at the STA selects a frame for
transmission, from the set of frames at the heads of a plurality of traffic queues, based on requested UP and/
or parameter values in the traffic specification (TSPEC) for the requested MSDU. Additional information is
available in 10.22.
219
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.5.3 Services that support the distribution service and the PCP service
4.5.3.1 General
The primary purpose of a MAC sublayer is to transfer MSDUs between MAC sublayer entities. The
information required for the distribution service to operate is provided by the association services. Before an
MSDU can be handled by the distribution service, a STA is “associated.”
To understand the concept of association, it is necessary first to understand the concept of mobility.
4.5.3.2 Mobility types
The three transition types of significance to this standard that describe the mobility of STAs within a
network are as follows:
a) No-transition: In this type, two subclasses that are usually indistinguishable are identified:
1) Static—no motion.
2) Local movement—movement within the PHY range of the communicating STAs, i.e.,
movement within a basic service area (BSA).
b) BSS-transition: This type is defined as a STA movement from one BSS in one ESS to another BSS
within the same ESS. A fast BSS transition is a BSS transition that establishes the state necessary for
data connectivity before the reassociation rather than after the reassociation.
c) ESS-transition: This type is defined as STA movement from a BSS in one ESS to a BSS in a
different ESS. This case is supported only in the sense that the STA might move. Maintenance of
upper-layer connections cannot be guaranteed by IEEE Std 802.11; in fact, disruption of service is
likely to occur.
The FT protocol provides a mechanism for a STA to perform a BSS transition between access points (APs)
in a robust security network (RSN) or when quality-of-service (QoS) admission control is enabled in the
ESS.
The different association services support the different categories of mobility.
4.5.3.3 Association
To deliver an MSDU within a DS, the distribution service needs to know which AP to access for the given
IEEE 802.11 STA. This information is provided to the DS by the concept of association. Association is
necessary, but not sufficient, to support BSS-transition mobility. Association is sufficient to support no-
transition mobility. Association is one of the services in the DSS.
Before a STA is allowed to send an MSDU via an AP, it first becomes associated with the AP. The act of
becoming associated invokes the association service, which provides the STA to AP mapping to the DS.
How the information provided by the association service is stored and managed within the DS is not
specified by this standard.
Within a robust security network (RSN), association is handled differently. In an RSNA, the IEEE 802.1X
Port determines when to allow data traffic across an IEEE 802.11 link. A single IEEE 802.1X Port maps to
one association, and each association maps to an IEEE 802.1X Port. An IEEE 802.1X Port consists of an
IEEE 802.1X Controlled Port and an IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port is
blocked from passing general data traffic between two STAs until an IEEE 802.1X authentication procedure
completes successfully over the IEEE 802.1X Uncontrolled Port. Once the AKM completes successfully,
data protection is enabled to prevent unauthorized access, and the IEEE 802.1X Controlled Port unblocks to
allow protected data traffic. IEEE 802.1X Supplicants and Authenticators exchange protocol information via
220
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the IEEE 802.1X Uncontrolled Port. It is expected that most other protocol exchanges use the IEEE 802.1X
Controlled Ports. However, a given protocol might need to bypass the authorization function and make use
of the IEEE 802.1X Uncontrolled Port.
NOTE—See IEEE Std 802.1X-2010 for a discussion of Controlled Port and Uncontrolled Port.
At any given instant, a STA is associated with no more than one AP. This allows the DS to determine a
unique answer to the question, “Which AP is serving STA X?” Once an association is completed, a STA can
make full use of a DS (via the AP) to communicate. Association is always initiated by the non-AP STA, not
the AP.
An AP might be associated with many STAs at the same time.
A STA learns what APs are present and what operational capabilities are available from each of those APs
and then invokes the association service to establish an association. For details of how a STA learns about
what APs are present, see 11.1.4.
4.5.3.4 Reassociation
Association is sufficient for no-transition MSDU delivery between IEEE 802.11 STAs. Additional
functionality is needed to support BSS-transition mobility. The additional required functionality is provided
by the reassociation service. Reassociation is one of the services in the DSS.
The reassociation service is invoked to “move” a current association from one AP to another. This keeps the
DS informed of the current mapping between AP and STA as the STA moves from BSS to BSS within an
ESS. Reassociation also enables changing association attributes of an established association while the STA
remains associated with the same AP. Reassociation is always initiated by the non-AP STA.
Only the fast BSS transition facility can move an RSNA during reassociation. Therefore, if FT is not used,
the old RSNA is deleted and a new RSNA is constructed.
4.5.3.5 Disassociation
The disassociation service is invoked when an existing association is to be terminated. Disassociation is one
of the services in the DSS.
In an ESS, this tells the DS to void existing association information. Attempts to send MSDUs via the DS to
a disassociated STA will be unsuccessful.
The disassociation service can be invoked by either party in an association (non-AP STA or AP).
Disassociation is a notification, not a request. Disassociation cannot be refused by the receiving STA except
when management frame protection is negotiated and the message integrity check fails.
An AP can disassociate STAs to enable the AP to be removed from a network for service or for other
reasons.
STAs attempt to disassociate when they leave a network. However, the MAC protocol does not depend on
STAs invoking the disassociation service. (MAC management is designed to accommodate loss of
communication with an associated STA.)
221
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.5.4 Access control and data confidentiality services
4.5.4.1 General
Two services are required for IEEE Std 802.11 to provide functionality equivalent to that which is inherent
to wired LANs. The design of wired LANs assumes the physical attributes of wire. In particular, wired LAN
design assumes the physically closed and controlled nature of wired media. The physically open medium
nature of an IEEE 802.11 LAN violates those assumptions.
In a WLAN that does not support RSNA, two services, authentication and data confidentiality, are defined.
IEEE 802.11 authentication is used instead of the wired media physical connection. WEP encryption was
defined to provide the data confidentiality aspects of closed wired media.
An RSNA uses the IEEE 802.1X authentication service along with enhanced data cryptographic
encapsulation mechanisms, such as TKIP, CCMP, and GCMP, to provide access control. The IEEE 802.11
station management entity (SME) provides key management via an exchange of EAPOL-Key frames. Data
confidentiality and data integrity are provided by RSN key management together with the enhanced data
cryptographic encapsulation mechanisms.
4.5.4.2 Authentication
IEEE 802.11 authentication operates at the link level between IEEE 802.11 STAs. IEEE Std 802.11 does not
provide either end-to-end (MSDU origin to MSDU destination) or user-to-user authentication.
IEEE Std 802.11 attempts to control LAN access via the authentication service. IEEE 802.11 authentication
is an SS. This service might be used by all STAs to establish their identity to STAs with which they
communicate, in both ESSs and IBSSs. If a mutually acceptable level of authentication has not been
established between two STAs, an association is not established.
IEEE Std 802.11 defines four IEEE 802.11 authentication methods: Open System authentication, Shared
Key authentication, FT authentication, and simultaneous authentication of equals (SAE). Open System
authentication admits any STA to the DS. Shared Key authentication relies on WEP to demonstrate
knowledge of a WEP encryption key. FT authentication relies on keys derived during the initial mobility
domain association to authenticate the stations as defined in Clause 13. SAE authentication uses finite field
cryptography to prove knowledge of a shared password. The IEEE 802.11 authentication mechanism also
allows definition of new authentication methods.
An RSNA might support SAE authentication. An RSNA also supports authentication based on IEEE
Std 802.1X-2010, or preshared keys (PSKs) after Open System authentication. IEEE 802.1X authentication
utilizes the EAP to authenticate STAs and the AS with one another. This standard does not specify an EAP
method that is mandatory to implement. See 12.6.5 for a description of the IEEE 802.1X authentication and
PSK usage within an IEEE 802.11 IBSS.
In an RSNA, IEEE 802.1X Supplicants and Authenticators exchange protocol information via the
IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port is blocked from passing general data
traffic between two STAs until an IEEE 802.1X authentication procedure completes successfully over the
IEEE 802.1X Uncontrolled Port.
SAE authentication or Open System IEEE 802.11 authentication is used by non-DMG STAs in an RSN for
infrastructure BSS. SAE authentication, Open System IEEE 802.11 authentication, or no IEEE 802.11
authentication is used in an RSN for IBSS. SAE authentication is used in an MBSS. An RSNA disallows the
use of Shared Key IEEE 802.11 authentication. In an RSN for DMG BSS, Open System IEEE 802.11
authentication is not used (12.2.4).
222
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA might be authenticated with many other STAs at the same time.
Because the IEEE 802.1X authentication process could be time-consuming (depending on the authentication
protocol in use), the authentication service can be invoked independently of the association service.
This type of preauthentication is typically done by a STA while it is already associated with an AP (with
which it previously authenticated). IEEE Std 802.11 does not require that STAs preauthenticate with APs.
However, authentication is required before an association establishment is complete.
If the authentication is left until reassociation time, this might impact the speed with which a STA
reassociates between APs, limiting BSS-transition mobility performance. The use of preauthentication takes
the authentication service overhead out of the time-critical reassociation process.
SAE authentication is performed prior to association and a STA can take advantage of the fact that it can be
IEEE 802.11 authenticated to many APs simultaneously by completing the SAE protocol with any number
of APs while still being associated to another AP. RSNA security can be established after association using
the resulting shared key.
4.5.4.3 Deauthentication
The deauthentication service is invoked when an existing Open System, Shared Key, or SAE authentication
is to be terminated. Deauthentication is an SS.
In an ESS, because authentication is a prerequisite for association, the act of deauthentication causes the
STA to be disassociated. The deauthentication service can be invoked by either authenticated party (non-AP
STA or AP). Deauthentication is not a request; it is a notification. The association at the transmitting STA is
terminated when the STA sends a deauthentication notice to an associated STA. Deauthentication, and if
associated, disassociation cannot be refused by the receiving STA except when management frame
protection is negotiated and the message integrity check fails.
In an RSN ESS, Open System IEEE 802.11 authentication is required. In an RSN ESS, deauthentication
results in termination of any association for the deauthenticated STA. It also results in the IEEE 802.1X
Controlled Port for that STA being disabled and deletes the pairwise transient key security association
(PTKSA). The deauthentication notification is provided to IEEE Std 802.1X-2010 via the MAC layer.
In an RSNA, deauthentication also deletes any related pairwise transient key security association (PTKSA),
group temporal key security association (GTKSA), station-to-station link (STSL) master key security
association (SMKSA), STSL transient key security association (STKSA), TPK security association
(TPKSA), integrity group temporal key security association (IGTKSA), mesh GTKSA, and mesh TKSA
that exist in the STA and closes the associated IEEE 802.1X Controlled Port. If pairwise master key security
association (PMKSA) caching is not enabled, deauthentication also deletes the PMKSA or mesh PMKSA.
In an RSN IBSS, Open System authentication is optional, but a STA is required to recognize
Deauthentication frames. Deauthentication results in the IEEE 802.1X Controlled Port for that STA being
disabled and deletes the PTKSA.
4.5.4.4 Data confidentiality
In a wired LAN, only those STAs physically connected to the wire can send or receive LAN traffic. With a
wireless shared medium, there is no physical connection, and all STAs and certain other RF devices in or
near the LAN might be able to send, receive, and/or interfere with the LAN traffic. A STA receives traffic
that is within range and transmits to any other STA within range. Thus, the connection of a single wireless
link (without data confidentiality) to an existing wired LAN might seriously degrade the security level of the
wired LAN.
223
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
To bring the security of the WLAN up to the level implicit in wired LAN design, IEEE Std 802.11 provides
the ability to protect the contents of frames. This functionality is provided by the data confidentiality service.
Data confidentiality is an SS.
IEEE Std 802.11 provides several cryptographic algorithms to protect data traffic, including: WEP, TKIP,
CCMP, and GCMP. WEP and TKIP are based on the ARC420 algorithm, and CCMP and GCMP are based
on the advanced encryption standard (AES). A means is provided for STAs to select the algorithm(s) to be
used for a given association.
IEEE Std 802.11 provides the following security protocols for protection of individually addressed robust
Management frames: CCMP and GCMP. This standard does not provide data confidentiality for group
addressed robust Management frames, except for certain Action frames related to mesh operation, as
indicated in Table 9-47.
IEEE Std 802.11 provides one security protocol, CCMP, for protection of individually addressed and group
addressed Data frames between mesh STAs.
The default data confidentiality state for all IEEE 802.11 STAs is “in the clear,” i.e., without protection. If
the data confidentiality service is not invoked, all frames are sent unprotected. If this policy is unacceptable
to the sender, it does not send Data frames; and if the policy is unacceptable to the receiver, it discards any
received Data frames. Unprotected Data frames and unprotected robust Management frames received at a
STA configured for mandatory data confidentiality, as well as protected Data frames and protected robust
Management frames using a key not available at the receiving STA, are discarded without an indication to
LLC (or without indication to distribution services in the case of “To DS” frames received at an AP). These
frames are acknowledged on the WM [if received without frame check sequence (FCS) error] to avoid
wasting WM bandwidth on retries of frames that are being discarded.
4.5.4.5 Key management
The enhanced data confidentiality, data authentication, and replay protection mechanisms require fresh
cryptographic keys and corresponding security associations. The procedures defined in this standard provide
fresh keys by means of protocols called the 4-way handshake, FT 4-way handshake, FT protocol, FT
resource request protocol, and group key handshake.
4.5.4.6 Data origin authenticity
The data origin authenticity mechanism defines a means by which a STA that receives a Data or protected
robust Management frame can determine which STA transmitted the MAC protocol data unit (MPDU). This
feature is required in an RSNA to prevent one STA from masquerading as a different STA.
Data origin authenticity is applicable only to individually addressed Data frames, and individually addressed
robust Management frames. The protocols do not guarantee data origin authenticity for group addressed
frames, as this cannot be accomplished using symmetric keys and public key methods are too
computationally expensive.
4.5.4.7 Replay detection
The replay detection mechanism defines a means by which a STA that receives a Data or protected robust
Management frame from another STA can detect whether the received frame is an unauthorized
20
Details of the ARC4 algorithm are available from RSA Security, Inc. Contact RSA Security, 174 Middlesex Turnpike, Bedford, MA
01730 (http://www.rsasecurity.com/), for algorithm details and the uniform ARC4 license terms that RSA offers to anyone wishing to
use ARC4 for the purpose of implementing the IEEE 802.11 WEP option. If necessary, contact the IEEE Standards Department
Intellectual Property Rights Administrator for details on how to communicate with RSA.
224
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
retransmission. This replay protection mechanism is provided for Data frames for STAs that use enhanced
data cryptographic encapsulation mechanisms. The replay protection mechanism is also provided for robust
Management frames for STAs that use CCMP, GCMP, and broadcast/multicast integrity protocol (BIP).
4.5.4.8 Fast BSS transition
The FT mechanism defines a means for a STA to set up security and QoS parameters prior to reassociation
to a new AP. This mechanism allows time-consuming operations to be removed from the time-critical
reassociation process.
4.5.4.9 Robust management frame protection
Robust Management frames are a set of Management frames that can be protected by the management frame
protection service.
Management frame protection protocols in an infrastructure BSS or IBSS apply to robust Management
frames after RSNA PTK establishment for protection of individually addressed frames is completed and
after delivery of the IGTK to protect group addressed frames. Robust management frame protection is
implemented by CCMP, GCMP, BIP, and the SA Query procedure.
Management frame protection protocols in an MBSS apply to individually addressed frames after
establishment of the RSNA MTK, and to group addressed frames indicated as “Group Addressed Privacy”
in Table 9-47. Robust management frame protection is implemented with CCMP and GCMP.
4.5.5 Spectrum management services
4.5.5.1 General
Two services are required to satisfy requirements in some regulatory domains (see Annex D and Annex E)
for operation in the 5 GHz band. These services are called transmit power control (TPC) and dynamic
frequency selection (DFS).
4.5.5.2 TPC
Regulations that apply to the 5 GHz band in certain regulatory domains require RLANs operating in the 5
GHz band to use transmitter power control, involving specification of a regulatory maximum transmit power
and a mitigation requirement for each allowed channel. The TPC service is used to satisfy this regulatory
requirement.
The TPC service provides for the following:
— Association of STAs with an AP based on the STAs’ power capability
— Specification of regulatory and local maximum transmit power levels for the current channel
— Selection of a transmit power for each transmission in a channel within constraints imposed by
regulatory requirements
— Adaptation of transmit power based on a range of information, including path loss and link margin
estimates
4.5.5.3 DFS
Regulations that apply to the 5 GHz band in certain regulatory domains require RLANs operating in the 5
GHz band to avoid co-channel operation with radar systems and to provide uniform utilization of available
channels. The DFS service is used to satisfy these regulatory requirements.
225
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DFS service provides for the following:
— Association of STAs with an AP based on the STAs’ supported channels.
— Quieting the current channel so it can be tested for the presence of radar with less interference from
other STAs.
— Testing channels for radar before using a channel and while operating in a channel.
— Discontinuing operations after detecting radar in the current channel to avoid interference with
radar.
— Detecting radar in the current and other channels based on regulatory requirements.
— Requesting and reporting of measurements in the current and other channels.
— Selecting and advertising a new channel to assist the migration of a BSS after radar is detected.
4.5.6 Traffic differentiation and QoS support
4.5.6.1 General
IEEE Std 802.11 uses a shared medium and provides differentiated control of access to the medium to
handle data transfers with QoS requirements. The QoS facility (per MSDU traffic category and
TSPEC negotiation) allows an IEEE 802.11 LAN to become part of a larger network providing end-to-end
QoS delivery or to function as an independent network providing transport on a per-link basis with specified
QoS commitments. The specifications regarding the integration and operability of the QoS facility with any
other end-to-end QoS delivery mechanism like Resource Reservation Protocol (RSVP) are beyond the scope
of this standard.
4.5.6.2 Quality-of-service management frame support
When the quality-of-service management frame (QMF) service is enabled, some Management frames might
be transmitted using an access category other than the access category assigned to voice traffic (access
category AC_VO, see 9.4.2.29) in order to improve the quality of service of other traffic streams. This is
achievable by the use of a QMF policy. A QMF policy defines the access categories of different
Management frames. Only QoS STAs are able to implement QMF policy. A non-AP QMF STA uses the
default QMF policy or the QMF policy accepted from a peer QMF STA to transmit Management frames to
that peer QMF STA. A QMF AP sets its own QMF policy for the transmission of QMFs to its associated
STAs. A QMF STA uses access category AC_VO to transmit Management frames to STAs that do not
support the QMF service.
4.5.7 Support for higher layer timer synchronization
Some applications, e.g., the transport and rendering of audio or video streams, require synchronized timers
shared among different STAs. Greater accuracy (in terms of jitter bounds) or finer timer granularity than that
provided by a BSS timing synchronization function (TSF) might be an additional requirement. In support of
such applications, this standard defines a MAC service that enables layers above the MAC to accurately
synchronize application-dependent timers shared among STAs. The service is usable by more than one
application at a time.
226
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Although the timer synchronization methods and accuracy requirements are application-dependent and are
beyond the scope of this standard, they rely on an indication from each MAC that is provided essentially
simultaneously, via group addressed transmissions, to the STAs. The MAC accomplishes this by indicating
the occurrence of the end of the last symbol of particular Data frames; the Data frames of interest are
identified by their MAC header Address 1 field when it contains a group address previously registered with
the MAC. The last symbol is observed21 on the WM by STAs within a BSS while the delay between the
observation and the delivery of the indication is known within a MAC by design (and communicated to the
application by implementation dependent means). The common reference point in time provided by the end
of last symbol indication is the essential building block upon which a variety of application-dependent timer
synchronization methods might be based.
4.5.8 Radio measurement service
The Radio measurement service provides the following:
— The ability to request and report radio measurements in supported channels.
— The ability to perform radio measurements in supported channels.
— An interface for upper layer applications to retrieve radio measurements using MLME primitives
and/or MIB access.
— Information about neighbor APs.
4.5.9 Interworking with external networks
The interworking service allows non-AP STAs to access services provided by an external network according
to the subscription or other characteristics of that external network. An IEEE 802.11 non-AP STA might
have a subscription relationship with an external network, e.g., with an SSPN.
An overview of the interworking functions addressed in this standard is provided below:
— Network discovery and selection
— Discovery of suitable networks through the advertisement of access network type, roaming
consortium and venue information, via Management frames
— Selection of a suitable IEEE 802.11 infrastructure using advertisement services (e.g., access
network query protocol (ANQP) or an IEEE 802.21™ Information Server) in the BSS or in an
external network reachable via the BSS.
— Selection of an SSPN or external network with its corresponding IEEE 802.11 infrastructure
— Emergency services
— Emergency Call and Network Alert support at the link level
— QoS mapping distribution
— SSPN interface service between the AP and the SSPN
The generic advertisement service (GAS), described in 4.5.10, provides both support for a STA’s network
discovery and selection, and support for a conduit for communication by a non-AP STA with other
information resources in a network before joining the wireless LAN.
The interworking service supports emergency services by providing methods for users to access emergency
services via the IEEE 802.11 infrastructure, advertising that emergency services are supported (see 11.25.6)
and identifying that a traffic stream is used for emergency services.
21
The synchronization indication (observed time) within the BSS varies slightly due to propagation.
227
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The interworking service provides QoS mapping for SSPNs and other external networks. Since each SSPN
or other external network might have its own layer-3 end-to-end packet marking practice (e.g., differentiated
services code point (DSCP) usage conventions), a means to remap the layer-3 service levels to a common
over-the-air service level is necessary. The QoS Map service provides STAs a mapping of network-layer
QoS packet marking to over-the-air QoS frame marking (i.e., user priority).
The SSPN Interface service supports service provisioning and transfer of user permissions from the SSPN to
the AP. The method and protocol by which these permissions are transferred from the SSPN are outside the
scope of this standard.
4.5.10 Generic advertisement service (GAS)
GAS provides functionality that enables STAs to discover the availability of information related to desired
network services, e.g., information about services such as provided in an IBSS, local access services,
available subscription service providers (SSPs) and/or SSPNs or other external networks. GAS uses a
generic container to advertise network services’ information over an IEEE 802.11 network. Public Action
frames are used to transport this information.
While the specification of network services information is outside the scope of this standard, in an
infrastructure BSS there is a need for STAs to query for information on network services provided by SSPNs
or other external networks beyond an AP, before they associate with the wireless LAN. The exchange of
information can also be performed after associating to the BSS.
In an IBSS/PBSS, GAS functionality enables a STA to access the availability and information related to
desired services provided by other STAs in the IBSS/PBSS. Exchange of information using GAS can be
performed either prior to joining an IBSS/PBSS or after joining the IBSS/PBSS.
There are a number of reasons why providing information to a STA in a preassociated state is beneficial:
— It supports more informed decision making about an IEEE 802.11 infrastructure or PBSS with
which to associate. This is generally more efficient than requiring a non-AP and non-PCP STA to
associate with an AP or PCP before discovering the information and then deciding whether to stay
associated.
— It is possible for the non-AP and non-PCP STA to query multiple networks in parallel.
— The non-AP STA can discover information about APs that are not part of the same administrative
group as the AP with which it is associated, supporting the selection of an AP belonging to a
different IEEE 802.11 infrastructure that has an appropriate SSP roaming agreement in place.
4.6 Multiple logical address spaces
Just as the IEEE 802.11 architecture allows for the possibility that the WM, DSM, and an integrated non-
IEEE-802.11 LAN might all be different physical media, it also allows for the possibility that each of these
components might be operating within different address spaces. IEEE Std 802.11 only uses and specifies the
use of the WM address space.
Each IEEE 802.11 PHY operates in a single medium—the WM. The IEEE 802.11 MAC operates in a single
address space. MAC addresses are used on the WM in the IEEE 802.11 architecture. Therefore, it is
unnecessary for the standard to explicitly specify that its addresses are “WM addresses.” This is assumed
throughout this standard.
IEEE Std 802.11 has chosen to use the IEEE 802 48-bit address space (see 9.2.4.3.2). Thus IEEE 802.11
addresses are compatible with the address space used by the IEEE 802 LAN family.
228
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The IEEE 802.11 choice of address space implies that for many instantiations of the IEEE 802.11
architecture, the non-IEEE-802.11 LAN MAC address space and the IEEE 802.11 MAC address space
might be the same. In those situations where a DS that uses MAC level IEEE 802 addressing is appropriate,
all three of the logical address spaces used within a system could be identical. While this is a common case,
it is not the only combination allowed by the architecture. The IEEE 802.11 architecture allows for all three
logical address spaces to be distinct.
A multiple address space example is one in which the DS implementation uses network layer addressing. In
this case, the WM address space and the DS address space are different.
Note that IEEE 802.11 STAs within a single ESS share the same address space, fulfilling the transparency
requirement from the definition of the DS. The DSS uses this same address space, even in the case where the
DSM uses a different address space.
The ability of the architecture to handle multiple logical media and address spaces is key to the ability of
IEEE Std 802.11 to be independent of the DS implementation and to interface cleanly with network layer
mobility approaches. The implementation of the DS is unspecified and is beyond the scope of this standard.
4.7 Differences among ESS, PBSS, and IBSS LANs
In 4.3.2 the concept of the IBSS LAN was introduced, and in 4.3.3 the concept of the PBSS LAN was
introduced. In an IBSS or PBSS, a STA communicates directly with one or more other STAs.
Consider the full IEEE 802.11 architecture as shown in Figure 4-16.
IEEE Std 802.11 Components
BSS 1
802.11 MAC/PHY
STA 1
SS STA 2
BSS 3
AP ESS
STA 6 DSS
Y
H
P
/
DS
SS C
A
M
1
1
.
2
0
8 DSS
DSS AP
STA 5 Portal
PCP STA 3 SS
PCPS
STA 4
802.11 MAC/PHY
BSS 2
802.x LAN
Figure 4-16—IEEE 802.11 architecture (again)
229
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An IBSS consists of STAs that are directly connected. Thus there is (by definition) only one BSS. Further,
because there is no physical DS, there is no portal, integrated non-IEEE-802.11 LAN, or DSS. The logical
picture reduces to Figure 4-17.
IEEE Std 802.11 Independent BSS
IEEE Std 802.11 MAC/PHY
STA 1 STA 2
SS
Figure 4-17—Logical architecture of an IBSS
An important difference between the IBSS and the PBSS is that, within the PBSS, Beacons are not
transmitted by every STA and instead only a single STA, namely the PCP, is responsible for DMG Beacon
frame transmission. Within the IBSS, all STAs are responsible for Beacon frame transmission. When
compared to the infrastructure BSS, the PBSS does not provide certain DSSs as described in 4.4.3.
There can be more than one PBSS in the same BSA. One of the STAs within each PBSS assumes the role of
the PCP. The logical picture of the PBSS reduces to Figure 4-18.
IEEE Std 802.11 Personal BSS
IEEE Std 802.11 MAC/PHY
STA 1/PCP SS STA 2
Figure 4-18—Logical architecture of a PBSS
Only the minimum two STAs are shown in Figure 4-17. An IBSS can have an arbitrary number of members.
In an IBSS only Class 1 and Class 2 frames are allowed because there is no DS in an IBSS.
The services that apply to an IBSS are the SSs. A QoS IBSS supports operation under the HCF using TXOPs
gained through the EDCA mechanism. The parameters that control differentiation of the delivery of MSDUs
with different priority using EDCA are fixed. A QoS IBSS has no HC and does not support polled TXOP
operation and setting up of TSPEC.
The services that apply to the PBSS are the SSs and the PCPSs as described in 4.4.3. A PBSS supports
operation under the HCF using TXOPs gained through the EDCA mechanism. In a PBSS, the EDCA
230
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
mechanism is used only within CBAPs. The parameters that control differentiation of traffic classes using
EDCA can be configured by the PCP in a PBSS. The PCP of a PBSS has no HC, but can support TSPEC
setup, DMG TSPEC setup, and service periods.
In an IBSS each STA enforces its own security policy. In an infrastructure BSS or a PBSS, an AP or a PCP,
respectively, can enforce a uniform security policy across all STAs.
4.8 Differences between ESS and MBSS LANs
In 4.3.20, the concept of the MBSS LAN was introduced. It was noted that using the multi-hop capability it
appears as if all mesh STAs are directly connected at the MAC layer even if the STAs are not within range
of each other. This is different from an IBSS, where STAs cannot communicate if they are not within range
of each other.
Unlike the IBSS, an MBSS might have access to the DS. An MBSS connects through one or more mesh
gates to the DS. Since in an MBSS it appears as if all mesh STAs are directly connected at the MAC layer,
the MBSS can be used as a DSM. APs, a portal, and mesh gates might use the MBSS as a DSM to provide
the DSS. Thus, different infrastructure BSSs can unite over the MBSS to form an ESS for example.
An AP identifies the infrastructure BSS that it forms. This is different from the MBSS where no such central
entity exists. Whereas infrastructure BSSs need the ESS and thus the DS to unite, the MBSS appears the
same to an LLC layer without the need for access to a DS. However, if an MBSS has one or more mesh gates
providing access to the DS, the MBSS might exist in disjointed areas and yet form a single network.
4.9 Reference model
4.9.1 General
This standard presents the architectural view, emphasizing the separation of the system into two major parts:
the MAC of the data link layer (DLL) and the PHY. These layers are intended to correspond closely to the
lowest layers of the ISO/IEC basic reference model of Open Systems Interconnection (OSI) (ISO/IEC 7498-
1:1994). The layers and sublayers described in this standard are shown in Figure 4-19.
There is an interface between the IEEE 802.1X Supplicant/Authenticator and the SME not shown in
Figure 4-19. This interface is described in IEEE Std 802.1X-2010.
4.9.2 Interworking reference model
The MAC state generic convergence function (MSGCF) provides services to higher layer protocols based on
MAC state machines and interactions between the layers.
Interworking functions might require correlating information from multiple management entities. It is the
function of the MSGCF to correlate information for higher layer entities. The MSGCF observes the
interactions between the MLME and SME, and between the PLME and SME. After correlation of lower-
layer MLME and PLME events, the MSGCF might synthesize indications to higher layer entities.
Figure 4-20 shows an entity, the MSGCF, defined in 6.4, that has access to all management information
through exposure to the MAC sublayer and PHY management entities, and provides management
information to higher level entities, such as Mobility Managers, supporting heterogeneous medium mobility.
An example of how the MSGCF interfaces to these higher layer entities, is provided by the media-
independent handover (MIH) interface, as defined in IEEE Std 802.21-2008.
231
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
802.1X
Authenticator /
802.1X
Supplicant
MAC SAP
RSNA Key
MAC Sublayer Management
Management
Data Link MAC Sublayer Entity
Layer MLME SAP
MLME-PLME
PHY SAP SAP
Station
Management
Entity
PHY Sublayer
Physical
PHY Sublayer Management PLME SAP
Layer
Entity
Figure 4-19—Portion of the ISO/IEC basic reference model covered in this standard
MSGCF SAP
MAC State Generic 802.1X
802.1X Authenticator
Convergence Function
/ Supplicant
MAC SAP
MSGCF-SME SAP
MAC Sublayer RSNA Key
Management Management
Data Link MAC Sublayer Entity MLME SAP
Layer
MLME-PLME
PHY SAP SAP
Station
PHY Sublayer Management
Physical
PHY Sublayer Management PLME SAP Entity
Layer
Entity
Figure 4-20—Interworking reference model
The MSGCF is designed to provide the status of the connection of a non-AP STA to a set of BSSs
comprising a single ESS. Figure 4-21 illustrates the concept of an ESS Link. This reflects the state of a
connection to an ESS independent of any particular access point. In Figure 4-21, STA3 is associated with
either AP1 or AP2. The state of the ESS Link is up when STA3 is associated with any of the APs comprising
an ESS.
232
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
802.x LAN
Portal
DS
AP1
STA1
AP2
STA2
STA3
BSS1
BSS2
ESS
Figure 4-21—ESS link illustration
4.9.3 Reference model for supporting multiple MAC sublayers
An MM-SME function interfaces with the SMEs of the coordinating STAs. STAs managed under the MM-
SME share the same antennas and PHY and optionally unify power management. The reference model for
supporting multiple MAC sublayers is shown in Figure 4-22.
802.1X 802.1X 802.1X
SME SME SME MM-
MAC 1 SAP STA 1 MAC 2 SAP MAC n SAP SME
STA 2 STA n
MAC Sublayer MAC Sublayer MAC Sublayer
MAC Sublayer MAC Sublayer MAC Sublayer
Management Entity Management Entity Management Entity
PHY SAP MLME-PLME SAP PLME SAP
PHY
Figure 4-22—Reference model for supporting multiple MAC sublayers
An MM-SME coordinates the management of multiple MAC sublayers. Each MAC sublayer has a separate
MAC SAP and MLME SAP. A MAC SAP together with its corresponding MLME SAP is identified by a
MAC address.
Even when coordinated by an MM-SME, each MAC retains its single MAC address, and each STA contains
a single MAC; therefore, the MM-SME coordinates multiple STAs as well as multiple MACs.
233
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Multiple STAs coordinated by an MM-SME have a single PHY that is shared by the multiple MAC
sublayers. Transmission attempts of different MAC sublayers can collide internally if the STAs share a
single PHY, and a backoff procedure is invoked in this case. Since multiple STAs coordinated by the same
MM-SME share the PHY, the STAs cannot directly exchange frames with each other.
NOTE—The multiple MAC reference model shown in Figure 4-22 defines how multiple STAs can share the same
physical layer entity. If this model is used in conjunction with the reference model for multi-band operation (see 4.9.4),
the multiple MAC reference model applies within each physical layer entity contained in the multi-band device whereas
the multi-band operation reference model applies to different physical layers.
The MM-SME accesses each of the MLME SAPs of the coordinated STAs separately to deliver MLME
SAP primitives. STAs that are coordinated by the same MM-SME can establish a multiple MAC sublayers
link (MMSL) with a peer STA. The set of all MMSLs between a pair of STAs creates an MMSL cluster.
An MM-SME controls the power management mode, DMG antenna configuration, and other parameters
and states of the coordinated STAs to eliminate unnecessary duplication of functions. A change in the power
management mode of the STAs coordinated by an MM-SME is signaled to a peer STA via any one of the
STAs’ MAC sublayer. Also, a beamforming link established between STAs can be used by all of the MAC
sublayers of any of the STAs coordinated by the same MM-SME. For these purposes, a Multiple MAC
Sublayers (MMS) element is used.
The MMS element contains multiple MAC addresses of the MACs coordinated by the same MM-SME. The
element can be included in any frame that advertises the MM-SME capabilities, such as Probe Request and
Probe Response frames and Information Request and Information Response frames, and the frames that
establish communication agreements, such as Association, ADDTS Request, ADDTS Response,
BlockAckReq and BlockAck.
4.9.4 Reference model for multi-band operation
The reference model of a device that is multi-band capable (see 11.33) and that supports transparent fast
session transfer (FST) is shown in Figure 4-23. The reference model of a device that is multi-band capable
and that supports nontransparent FST is shown in Figure 4-24.
802.1X
Authenticator / Multi-band Management
Supplicant
RSNA Key
Management
802.1X
MAC SAP
Transparent FST Entity
MAC Sublayer MAC Sublayer
Management Entity Management Entity
MAC Sublayer MAC Sublayer
MLME-PLME SAP PHY SAP PHY SAP MLME-PLME SAP
PHY Management PHY Management
SME PHY PHY SME
Entity Entity
STA 1 STA 2
(e.g., in 2.4 GHz) (e.g., in 60 GHz)
Figure 4-23—Reference model for a multi-band capable device (transparent FST)
234
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Multi-band Management
802.1X 802.1X
MAC SAP MAC SAP
MAC Sublayer 802.1X MAC Sublayer 802.1X
MAC Sublayer MAC Sublayer
Management Entity Authenticator / Management Entity Authenticator /
Supplicant Supplicant
PHY SAP MLME-PLME SAP PHY SAP MLME-PLME SAP
RSNA Key RSNA Key
Management Management
PHY Management PHY Management
PHY PHY
Entity Entity
SME SME
STA 1 STA 2
(e.g., in 2.4 GHz) (e.g., in 60 GHz)
Figure 4-24—Reference model for a multi-band capable device (nontransparent FST)
A multi-band capable device can manage operation over more than one frequency band/channel. The
operation across the different frequency bands/channels can be simultaneous or nonsimultaneous.
A multi-band capable device can also support multiple MAC sublayers; in this case, it is coordinated by an
MM-SME.
NOTE—For simplicity, Figure 4-23 and Figure 4-24 depict the reference model when there is a one-to-one mapping
between PHYs and MACs. However, the reference model for a multi-band capable device can be applied in conjunction
with the reference model for STAs that support multiple MAC sublayers (see 4.9.3).
An FST session is the state resulting from the operation of the FST session setup protocol.
The SME of a multi-band capable device contains a multi-band management entity that is responsible for
coordinating the setup, configuration, teardown, and transfer of FST sessions from a band/channel to
another band/channel supported by the multi-band capable device. If using nontransparent FST, the multi-
band management entity can employ a combination of the source and destination MAC addresses in both the
old and new band/channel to configure the routing of MSDUs and MLME primitives within the STA. If
using transparent FST, in addition to the MAC addresses, the multi-band management entity can employ the
TID of an FST session for this routing.
The multi-band procedures (see 11.33) allow a pair of multi-band capable devices to discover, synchronize,
(de)authenticate, (re)associate, disassociate, and manage resources with each other on any common band/
channel that is supported by both STAs.
When used in the context of FST, the term “session” refers to non-PHY state information that is kept in a
pair of STAs that communicate directly (i.e., excludes forwarding) and that is available prior to and
following a session transfer. This state information is different depending if transparent or nontransparent is
used. For transparent FST, a shared multi-band management entity has access to the local information within
each SME; and in this case the state information includes block ack agreements, TSs, association state,
RSNA, security keys, sequence counter, and PN counter. For nontransparent FST, the function of the multi-
band management entity is restricted to coordinating the setup and teardown of a session transfer with no
access to other local information within each SME. Therefore, with nontransparent FST, any information
local to an SME needs to be reestablished for the new band/channel, and this can be done either prior to or
following the session transfer (see 11.33).
235
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
By using the on-channel tunneling (OCT) multi-band procedure described in 11.33.4, the SME of a multi-
band capable device can instruct one of its MLMEs to use the OCT services provided by another MLME of
the same multi-band capable device to communicate with a peer MLME of a peer multi-band capable
device. This enables the SMEs of a pair of multi-band capable devices to provide a seamless FST, including
performing (de)authentication and (re)association across bands/channels. The MLMEs that use the OCT
services provided by another MLME within the same multi-band capable device to communicate are
referred to as being over-the-WM disabled with respect to each other. Following an FST, two peer over-the-
WM disabled MLMEs can become over-the-WM enabled with respect to each other.
As described in 5.1.5, a MAC address is not unique within the multi-band capable device when transparent
FST is intended to be used. When transparent FST is used, a single MAC SAP at each peer is presented to
the higher layers of that peer for all of the frequency bands/channels that are identified by the same MAC
address at that peer. When nontransparent FST is used, different MAC SAPs are presented to higher layers
since different MAC addresses are used prior to and following an FST. Therefore, when nontransparent FST
is used, higher layers are responsible for managing the session transition between different frequency bands/
channels.
Each MAC SAP is controlled by a separate and independent RSNA key management entity and
IEEE 802.1X Authenticator/Supplicant, unless if transparent FST is used in which case the multi-band
management entity is responsible for coordinating with each of the SMEs to ensure that a single RSNA key
management entity and IEEE 802.1X Authenticator/Supplicant are shared among the MACs and that a
single IEEE 802.1X entity is controlled.
4.10 IEEE Std 802.11 and IEEE Std 802.1X-2010
4.10.1 General
An RSNA relies on IEEE Std 802.1X-2010 to provide authentication services and uses the IEEE 802.11 key
management scheme defined in 12.7. The IEEE 802.1X access control mechanisms apply to the association
between a STA and an AP and to the relationship between the IBSS STA and STA peer. The AP’s SME
performs the Authenticator and, optionally, the Supplicant and AS roles. In an infrastructure BSS, a non-AP
STA’s SME performs the Supplicant role. In an IBSS the SME takes on both the Supplicant and
Authenticator roles and might take on the AS role.
4.10.2 IEEE 802.11 usage of IEEE Std 802.1X-2010
IEEE Std 802.11 depends upon IEEE Std 802.1X-2010 to control the flow of MAC service data units
(MSDUs) between the DS and STAs by use of the IEEE 802.1X Controlled/Uncontrolled Port model.
IEEE 802.1X EAPOL PDUs are transmitted in one or more IEEE 802.11 Data frames and passed via
the IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port is blocked from passing general data
traffic between two STAs until an IEEE 802.1X authentication procedure completes successfully over the
IEEE 802.1X Uncontrolled Port. It is the responsibility of both the Supplicant and the Authenticator to
implement port blocking. Each association between a pair of STAs creates a unique pair of IEEE 802.1X
Ports, and authentication takes place relative to those ports alone.
IEEE Std 802.11 depends upon IEEE Std 802.1X-2010 and the 4-way handshake, FT 4-way handshake, FT
protocol, FT resource request protocol, and group key handshake, described in Clause 12 and Clause 13, to
establish and change cryptographic keys. Keys are established after authentication has completed. Keys
might change for a variety of reasons, including expiration of an IEEE 802.1X authentication timer, key
compromise, danger of compromise, or policy.
236
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.10.3 Infrastructure functional model overview
4.10.3.1 General
This subclause summarizes the system setup and operation of an RSN, in three cases: when a password or
PSK is used during IEEE 802.11 authentication, when an IEEE 802.1X AS is used after Open System
authentication, and when a PSK is used after Open System authentication. In an RSN, an AP includes an
Authenticator, and each associated STA includes a Supplicant.
4.10.3.2 AKM operations with AS
The following AKM operations are carried out when an IEEE 802.1X AS is used:
a) Prior to any use of IEEE Std 802.1X-2010, IEEE Std 802.11 assumes that the Authenticator and AS
have established a secure channel. The security of the channel between the Authenticator and the AS
is outside the scope of this standard.
Authentication credentials are distributed to the Supplicant and AS prior to association.
b) A STA discovers the AP’s security policy through passively monitoring Beacon frames or through
active probing (shown in Figure 4-25). If IEEE 802.1X authentication is used, the EAP
authentication process starts when the Authenticator sends the EAP-Request (shown in Figure 4-26)
or the Supplicant sends the EAPOL-Start frame. EAP messages pass between the Supplicant and AS
via the Authenticator and Supplicant’s Uncontrolled Ports. This is shown in Figure 4-26.
STA AP
IEEE Std 802.11 probe request
IEEE Std 802.11 probe response (security parameters)
IEEE Std 802.11 open system authentication request
IEEE Std 802.11 open system authentication response
IEEE Std 802.11 association request (security parameters)
IEEE Std 802.11 association response
IEEE Std 802.1X controlled port blocked
Figure 4-25—Establishing the IEEE 802.11 association
237
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) The Supplicant and AS authenticate each other and generate a PMK. The PMK is sent from the AS
to the Authenticator over the secure channel. See Figure 4-26.
Supplicant Authenticator AS
IEEE 802.1X EAP Request
IEEE 802.1X EAP Response
Access Request (EAP Request)
EAP Authentication Protocol
Exchange
Accept / EAP Success /
Key Material
IEEE 802.1X EAP Success
IEEE 802.1X
Controlled Port
Blocked for STA
Figure 4-26—IEEE 802.1X EAP authentication
A 4-way handshake or FT 4-way handshake utilizing EAPOL-Key frames is initiated by the Authenticator
to do the following:
— Confirm that a live peer holds the PMK.
— Confirm that the PMK is current.
— In the case of fast BSS transition, derive PMK-R0s and PMK-R1s.
— Derive a fresh pairwise transient key (PTK) from the PMK or, in the case of fast BSS transition,
from the PMK-R1.
— Install the pairwise encryption and integrity keys.
— Transport the group temporal key (GTK) and GTK sequence number from Authenticator to
Supplicant and install the GTK and GTK sequence number in the STA and, if not already installed,
in the AP.
— If management frame protection is negotiated, transport the IGTK and the IGTK packet number
(IPN) from the Authenticator to the Supplicant and install these values in the STA and, if not already
installed, in the AP.
— Verify that the RSN capabilities negotiated are valid as defined in 9.4.2.25.4.
— Confirm the cipher suite selection.
Installing the PTK, and where applicable the GTK and, if management frame protection is negotiated, the
IGTK, causes the MAC to encrypt and decrypt all subsequent MSDUs irrespective of their path through the
controlled or uncontrolled ports.
Upon successful completion of the 4-way handshake, the Authenticator and Supplicant have
authenticated each other; and the IEEE 802.1X Controlled Ports are unblocked to permit general data traffic.
See Figure 4-27.
238
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Supplicant Authenticator
Key (PMK) is known Key (PMK) is known
Generate SNonce Generate ANonce
Message 1: EAPOL-Key(ANonce, Individual)
Derive PTK
Message 2: EAPOL-Key(SNonce, Individual, MIC)
Derive PTK
If needed
Generate GTK and IGTK
Message 3: EAPOL-Key(Install PTK, Individual,
MIC, Encrypted (GTK, IGTK))
Message 4: EAPOL-Key(Individual, MIC)
Install PTK, GTK. Install PTK, GTK.
IGTK IGTK
IEEE 802.1X Controlled port
unblocked
Figure 4-27—Establishing pairwise and group keys
If the Authenticator later changes the GTK, it sends the new GTK and GTK sequence number to the
Supplicant using the group key handshake to allow the Supplicant to continue to receive group addressed
frames and, optionally, to transmit and receive individually addressed frames. EAPOL-Key frames are used
to carry out this exchange. See Figure 4-28.
When management frame protection is negotiated, the Authenticator also uses the group key handshake with
all associated STAs to change the IGTK. The Authenticator encrypts the GTK and IGTK values in the
EAPOL-Key frame as described in 12.7.
4.10.3.3 AKM operations with a password or PSK
The following AKM operations are carried out when authentication is accomplished using a Password or
PSK:
— A STA discovers the AP’s security policy through passively monitoring the Beacon frames or
through active probing. After discovery the STA performs SAE authentication using Authentication
frames with the AP (see Figure 4-29).
— Upon the successful conclusion of SAE, both the STA and AP generate a PMK. The STA then
associates to an AP and negotiates security policy. The AKM in the Association Request and
Response frames is confirmed to be the AKM of SAE or of fast BSS transition.
— The PMK generated by SAE is used in a 4-way handshake using EAPOL-Key frames, just as with
IEEE 802.1X authentication when an AS is present. See Figure 4-27.
239
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The GTK and GTK sequence number are sent from the Authenticator to the Supplicant just as in the
AS case. See Figure 4-27 and Figure 4-28.
Supplicant Authenticator
Generate GTK, IGTK
Encrypt GTK, IGTK with KEK
Message 1: EAPOL-Key(Encrypted GTK,
Encrypted IGTK, Group, MIC)
Install GTK, IGTK
Message 2: EAPOL-Key(Group, MIC)
Figure 4-28—Delivery of subsequent group keys
STA AP
IEEE Std 802.11 Probe Request
IEEE Std 802.11 Probe Response (Security Parameters)
IEEE Std 802.11 SAE Authentication (Commit Message)
IEEE Std 802.11 SAE Authentication (Commit Message)
IEEE Std 802.11 SAE Authentication (Confirm Message)
IEEE Std 802.11 SAE Authentication (Confirm Message)
Figure 4-29—Example using SAE authentication
4.10.3.4 Alternate operations with PSK
The following AKM operations represent an alternate operation of using a PSK. This operation has security
vulnerabilities when used with a low-entropy key and is recommended to be used only after taking that into
account. When this operation is carried out, the PMK is a PSK:
— A STA discovers the AP’s security policy through passively monitoring Beacon frames or through
active probing (shown in Figure 4-25). A STA associates with an AP and negotiates a security
policy. The PMK is the PSK.
— The 4-way handshake using EAPOL-Key frames is used, just as with IEEE 802.1X authentication,
when an AS is present. See Figure 4-27.
240
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The GTK and GTK sequence number are sent from the Authenticator to the Supplicant just as in the
AS case. See Figure 4-27 and Figure 4-28.
— If management frame protection is negotiated, the IGTK and IGTK packet number are sent from the
Authenticator to the Supplicant just as in the AS case. See Figure 4-27 and Figure 4-28.
4.10.3.5 Disassociation
Disassociation initiated by either STA in an RSNA causes the deletion of the PTKSA at both ends and the
deletion of the GTKSA in a non-AP STA. The controlled and uncontrolled ports created for this association
are also deleted.
4.10.4 IBSS functional model description
4.10.4.1 General
This subclause summarizes the system setup and operation of an RSNA in an IBSS. An IBSS RSNA is
specified in 12.6.11.
4.10.4.2 Key usage
In an IBSS the individually addressed Data frames between two STAs are protected with a pairwise key.
The key is part of the PTK, which is derived during a 4-way handshake. In an IBSS the 4-way handshake
can follow IEEE 802.11 authentication of one STA to another. Such authentication might be used by the
peer to cause deletion of the PTKSA and Block the Controlled Port, resetting any previous handshake.
In an IBSS group addressed Data frames are protected by a key, e.g., named B1, that is generated by the
STA transmitting the group addressed frame. To allow other STAs to decrypt group addressed frames, B1 is
sent to all of the other STAs in the IBSS. B1 is sent in an EAPOL-Key frame, encrypted under the EAPOL-
Key encryption key (KEK) portion of the PTK, and protected from modification by the EAPOL-Key
confirmation key (KCK) portion of the PTK.
In an IBSS the SME responds to Deauthentication frames from a STA by deleting the PTKSA associated
with that STA.
4.10.4.3 Sample IBSS 4-way handshakes
In this example (see Figure 4-30), there are three STAs: S1, S2, S3. The group addressed frames sent by S1
are protected by B1; similarly B2 for S2, and B3 for S3.
For STAs S2 and S3 to decrypt group addressed frames from S1, B1 is sent to S2 and S3. This is done using
the 4-way handshake initially and using the group key handshake for GTK updates.
The 4-way handshake from S1 to S2 allows S1 to send group addressed frames to S2, but does not allow S2
to send group addressed frames to S1 because S2 has a different transmit GTK. Therefore, S2 needs to
initiate a 4-way handshake to S1 to allow S1 to decrypt S2’s group addressed frames. Similarly, S2 also
needs to initiate a 4-way handshake to S3 to enable S3 to receive group addressed frames from S2.
In a similar manner S3 needs to complete the 4-way handshake with S1 and S2 to deliver B3 to S1 and S2.
In this example, there are six 4-way handshakes. In general, N Supplicants require N(N–1) 4-way
handshakes.
241
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 4-30—Sample 4-way handshakes in an IBSS
NOTE—In principle the KCK and KEK from a single 4-way handshake can be used for the group key handshake in both
directions, but using two 4-way handshakes means the Authenticator key state machine does not need to be different
between IBSS and ESS.
The group key handshake can be used to send the GTKs to the correct STAs. The 4-way handshake is used
to derive the pairwise key and to send the initial GTK. Because in an IBSS there are two 4-way handshakes
between any two Supplicants and Authenticators, the pairwise key used between any two STAs is from the
4-way handshake initiated by the STA Authenticator with the higher MAC address (see 12.7.1 for the notion
of address comparison). The KCK and KEK used for a group key handshake are the KCK and KEK derived
by the 4-way handshake initiated by the same Authenticator that is initiating the group key handshake.
In an IBSS a secure link exists between two STAs when both 4-way handshakes have completed
successfully. The Supplicant and Authenticator 4-way handshake state machines interact so the IEEE
802.1X variable portValid is not set to 1 until both 4-way handshakes complete.
If a fourth STA comes within range and its SME decides to initiate a security association with the three
peers, its Authenticator initiates 4-way handshakes with each of the other three Supplicants. Similarly, the
original three STA Authenticators in the IBSS need to initiate 4-way handshakes to the fourth STA
Supplicant. A STA learns that a peer STA is RSNA-enabled and the peer’s security policy (e.g., whether the
Authentication and Key Management Protocol (AKMP) is SAE, PSK, or IEEE 802.1X authentication) from
the Beacon or Probe Response frame. The initiation might start for a number of reasons:
a) The fourth STA receives a Beacon or Probe Response frame from a MAC address with which it has
not completed a 4-way handshake.
b) An SME receives an MLME-PROTECTEDFRAMEDROPPED.indication primitive from a MAC
address with which it has not completed a 4-way handshake. This could be a group addressed Data
frame transmitted by any of the STAs. In order to set up a security association to the peer STA, an
SME that does not know the security policy of the peer can send a Probe Request frame to the peer
STA to find its security policy before setting up a security association to the peer STA.
c) An SME receives message 1 of the 4-way handshake sent to a STA because the initiator received a
broadcast Data frame, Beacon frame, or Probe Response frame from that STA. In order to set up a
security association to the peer STA, a STA that received a 4-way handshake but does not know the
security policy of the peer can send a Probe Request frame to the peer STA to find its security policy
before setting up a security association to the peer STA.
242
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.10.4.4 IBSS IEEE 802.1X example
When IEEE 802.1X authentication is used, each STA needs to include an IEEE 802.1X Authenticator and
AS. A STA learns that a peer STA is RSNA-enabled and the peer’s security policy (e.g., whether the AKMP
is PSK or IEEE 802.1X authentication) from the Beacon or Probe Response frame.
Each Supplicant sends an EAPOL-Start frame to every other STA to which it intends to authenticate, and
each STA’s Authenticator responds with the identity of the credential it intends to use.
The EAPOL-Start and EAP-Request/Identity messages are initiated when a protected Data frame (indicated
via an MLME-PROTECTEDFRAMEDROPPED.indication primitive), an IEEE 802.1X message, Beacon
frame, or Probe Response frame is received from a MAC address with which the STA has not completed
IEEE 802.1X authentication. In order to set up a security association to the peer STA, an SME that does not
know the security policy of the peer can send a Probe Request frame to the peer STA to find its security
policy before setting up a security association to the peer STA.
Although Figure 4-31 shows the two IEEE 802.1X exchanges serialized, they might occur interleaved.
S1 S2
EAPOL-Start
Request/Identity
EAP-Response/Identity
EAP Authentication
EAP Success
4-way handshake
EAPOL-Start
Request/Identity
EAP-Response/Identity
EAP Authentication
EAP Success
4-way handshake
Figure 4-31—Example using IEEE 802.1X authentication
243
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.10.5 PBSS functional model description
This subclause summarizes the system setup and operation of an RSNA in a PBSS.
If a non-PCP STA chooses to associate with the PCP of the PBSS, the non-PCP STA establishes an RSNA
with the PCP following the infrastructure functional model as specified in 4.10.3.
If a non-PCP STA wants to establish an RSNA with the PCP without association or if the non-PCP STA
wants to establish an RSNA with another non-PCP STA, it can directly initiate an RSNA authentication with
the peer STA, followed by a 4-way handshake. One difference between this model and the IBSS functional
model is that only one RSNA authentication and one 4-way handshake are performed between two STAs. If
both STAs initiate an RSNA setup at the same time, the RSNA setup initiated by the STA with the lower
MAC address is carried through, while the RSNA setup initiated by the STA with the higher MAC address
is terminated.
Figure 4-32 shows an example of the RSNA setup in a PBSS. An initiator STA discovers a peer STA’s
RSNA policies through the DMG Beacons from the peer STA if the peer STA is the PCP or through the
Probe Response or Information Response frames from the peer STA. In this example, the initiator STA does
not associate with the peer STA. The initiator STA performs RSNA authentication with the peer STA to
derive a PMK. A 4-way handshake is then started to complete the RSNA setup.
Initiator STA Peer STA
Unassociated Unassociated
DMG Beacon (DMG Privacy = 1)
Probe/Information Request
Probe/Information Response (RSN IE)
RSNA Authentication
Message 1
Message 2 (RSN IE)
Message 3 (RSN IE, GTK)
Message 4
RSNA RSNA
established established
Figure 4-32—Example of RSNA setup in a PBSS
244
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4.10.6 Authenticator-to-AS protocol
The Authenticator-to-AS authentication definition is out of the scope of this standard, but, to provide
security assurances, the protocol needs to support the following functions:
a) Mutual authentication between the Authenticator and AS
b) A channel for the Supplicant/AS authentication
c) The ability to pass the generated key from the AS to the Authenticator in a manner that provides
authentication of the key source, preserves integrity of the key transfer, and preserves data
confidentiality of the key from all other parties
Suitable protocols include, but are not limited to, remote authentication dial-in user service (RADIUS)
(IETF RFC 2865 [B33]) and Diameter (IETF RFC 3588 [B40]).
4.10.7 PMKSA caching
The Authenticator and Supplicant can cache PMKSAs, which include the IEEE 802.1X state. A PMKSA
can be deleted from the cache for any reason and at any time.
The STA can supply a list of PMK identifiers in the (Re)Association Request frame. Each key identifier
names a PMKSA; the PMKSA can contain a single PMK. The Authenticator specifies the selected PMK
identifier in message 1 of the 4-way handshake. The selection of the key identifiers to be included within the
(Re)Association Request frame and message 1 of the 4-way handshake is out of the scope of this standard.
4.10.8 Protection of group addressed robust Management frames
When management frame protection is negotiated, all group addressed robust Management frames are
encapsulated using the procedures defined in 11.13. This service provides integrity protection of group
addressed robust Management frames using BIP.
245
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
5. MAC service definition
5.1 Overview of MAC services
5.1.1 Data service
5.1.1.1 General
This service provides peer LLC sublayer entities with the ability to exchange MSDUs. To support this
service, the local MAC uses the underlying PHY-level services to transport an MSDU to a peer MAC entity,
where it is delivered to the peer LLC sublayer. Such asynchronous MSDU transport is performed on a
connectionless basis. By default, MSDU transport is on a best-effort basis. However, the QoS facility uses a
traffic identifier (TID) to specify differentiated services on a per-MSDU basis. The QoS facility also permits
more synchronous behavior to be supported on a connection-oriented basis using TSPECs. There are no
guarantees that the submitted MSDU will be delivered successfully. Group addressed transport is part of the
data service provided by the MAC. Due to the characteristics of the WM, group addressed MSDUs might
experience a lower QoS, compared to that of individually addressed MSDUs. All STAs support the data
service, but only QoS STAs in a QoS BSS differentiate their MSDU delivery according to the designated
traffic category or traffic stream (TS) of individual MSDUs. QoS STAs that support the QMF service
differentiate their MMPDU delivery according to the MMPDU’s access category. The access category of
each MMPDU is designated by the transmitter’s current QMF policy.
Because operation of certain functions of the MAC can cause reordering of some MSDUs, as discussed in
more detail below, in non-QoS STAs, there are two service classes within the data service. By selecting a
class, each LLC sublayer entity initiating the transfer of MSDUs is able to control whether MAC entities are
or are not allowed to reorder those MSDUs.
There are two service classes available in a QoS STA: QoSAck and QoSNoAck. The service classes are
used to signal if the MSDU is to be transmitted with or without using the MAC-level acknowledgment.
In QoS STAs either associated in a BSS or having membership in an IBSS, the MAC uses a set of rules that
tends to cause higher UP MSDUs in a BSS to be sent before lower UP MSDUs in the BSS. The MAC
sublayer entities determine the UPs for MSDUs based on the TID values provided with those MSDUs. If
a TSPEC has been provided for a TS, via the MAC sublayer management entity, the MAC attempts to
deliver MSDUs belonging to that TS in accordance with the QoS parameter values contained in the TSPEC.
In a BSS with some STAs supporting the QoS facility and others not supporting the QoS facility, in
delivering an MSDU to a non-QoS STA, the QoS STA uses the access category (AC) corresponding to the
UP of the MSDU.
5.1.1.2 Determination of UP
The QoS facility supports eight priority values, referred to as UPs. The values a UP may take are the integer
values from 0 to 7 and are identical to the IEEE 802.1D™ priority tags. An MSDU with a particular UP is
said to belong to a traffic category (TC) with that UP. The UP is provided with each MSDU at the medium
access control service access point (MAC SAP) either directly, in the UP parameter, or indirectly, in a
TSPEC or SCS Descriptor element designated by the UP parameter.
5.1.1.3 Interpretation of priority parameter in MAC service primitives
The value of the priority parameter in the MAC service primitives (see 5.2) may be a noninteger value of
either Contention or ContentionFree or may be any integer value in the range 0 to 15.
When the priority parameter has an integer value, it is used in the TID subfields that appear in certain frames
that are used to deliver and to control the delivery of QoS data across the WM.
246
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Priority parameter and TID subfield values 0 to 7 are interpreted as UPs for the MSDUs. Outgoing MSDUs
with UP values 0 to 7 are handled by MAC entities at STAs in accordance with the UP.
Priority parameter and TID subfield values 8 to 15 specify TIDs that are also TS identifiers (TSIDs) and
select the TSPEC for the TS designated by the TID. Outgoing MSDUs with priority parameter values 8 to 15
are handled by MAC entities at STAs in accordance with the UP value determined from the UP subfield as
well as other parameter values in the selected TSPEC. When an MSDU arrives with a priority value between
8 and 15 and for which there is no TSPEC defined, then the MSDU shall be sent with priority parameter set
to 0.
The noninteger values of the priority parameter are allowed at all non-QoS STAs. The use of priority value
of ContentionFree is deprecated at QoS STAs. The integer values of the priority parameter (i.e., TID) are
supported only at QoS STAs that are in a QoS BSS. A range of 0 to 15 is supported by QoS STAs associated
in a QoS BSS; whereas a range of 0 to 7 is supported by QoS STAs that are members of a QoS IBSS. If a
QoS STA is associated in a non-QoS BSS, the STA is functioning as a non-QoS STA, so the priority value is
always Contention or ContentionFree.
At QoS STAs associated in a QoS BSS, MSDUs with a priority of Contention are considered equivalent to
MSDUs with TID 0, and those with a priority of ContentionFree are delivered using the contention free
delivery if a point coordinator (PC) is present in the AP. If a PC is not present, MSDUs with a priority of
ContentionFree shall be delivered using an UP of 0. At STAs associated in a non-QoS BSS, all MSDUs with
an integer priority are considered equivalent to MSDUs with a priority of Contention.
The received individually addressed frames at a QoS STA may be as follows:
a) Non-QoS subtypes, in which case the STA shall assign to them a priority of Contention, if they are
received during the contention period (CP), or ContentionFree, if they are received during the
contention free period (CFP).
b) QoS subtypes, in which case the STA shall infer the UP value from the TID in the QoS Control field
directly for TID values between 0 and 7. For TID values between 8 and 15 the STA shall extract the
UP value in the UP subfield of the TS Info field in the associated TSPEC or from the UP field in the
associated TCLAS (traffic classification) element, as applicable.
QoS APs deliver the UP with the received MSDUs to the DS.
5.1.1.4 Interpretation of service class parameter in MAC service primitives in a STA
In QoS STAs, the value of the service class parameter in the MAC service primitive (see 5.2) may be a
noninteger value of QoSAck or QoSNoAck.
When an MSDU is received from the MAC SAP with one of the following service class indications, and the
recipient STA is a QoS STA:
— QoSAck, the MSDU is transmitted using one or more QoS Data frame(s) with the Ack Policy
subfield in the QoS Control field set to Normal Ack or Implicit Block Ack Request, PSMP Ack, or
Block Ack.
— QoSNoAck, the MSDU is transmitted using one or more QoS Data frame(s) with the Ack Policy
subfield in the QoS Control field set to No Ack.
When an MSDU is received from the MAC SAP and the recipient STA is not a QoS STA, the MSDU is
transmitted using one or more non-QoS Data frame(s).
When a QoS Data frame is received from another STA, the service class parameter in the
MA-UNITDATA.indication primitive is set to
— QoSAck, if the frame is a QoS Data frame with the Ack Policy subfield in the QoS Control field
equal to either Normal Ack or Block Ack.
247
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— QoSAck, if the frame was delivered via the DMS or the GCR block ack retransmission policy.
— QoSNoAck, if the frame is a QoS Data frame with the Ack Policy subfield in the QoS Control field
equal to No Ack. This service class is also used when the DA parameter is a group address unless the
frame was delivered via DMS or the GCR block ack retransmission policy.
When a non-QoS Data frame is received from a STA, the service class parameter in the
MA-UNITDATA.indication primitive is set to
— QoSAck, if the frame is an individually addressed frame and is acknowledged by the STA.
— QoSNoAck, if the frame is a group addressed frame and is not acknowledged by the STA.
5.1.2 Security services
Security services in IEEE Std 802.11 are provided by the authentication service and the CCMP, GCMP, and
BIP mechanisms. The scope of the security services provided is limited to station-to-station data and robust
Management frame transmissions. When CCMP or GCMP is used, the data confidentiality service is
provided for Data frames and individually addressed robust Management frames. For the purposes of this
standard, CCMP, GCMP, and BIP are viewed as logical services located within the MAC sublayer as shown
in the reference model, Figure 4-19 (in 4.9). Actual implementations of CCMP, GCMP, and BIP are
transparent to the LLC sublayer and other layers above the MAC sublayer.
The security services provided by CCMP and GCMP in IEEE Std 802.11 are as follows:
a) Data Confidentiality;
b) Authentication; and
c) Access control in conjunction with layer management.
BIP provides message integrity and access control for group addressed robust Management frames.
During the authentication exchange, both parties exchange authentication information as described in
Clause 12 and Clause 13.
The MAC sublayer security services provided by CCMP, GCMP, and BIP rely on information from non
MAC sublayer management or system entities. Management entities communicate information to CCMP,
GCMP, and BIP through a set of MAC sublayer management entity (MLME) interfaces and MIB attributes;
in particular, the decision tree for CCMP, GCMP, and BIP defined in 12.9 is driven by MIB attributes.
The use of WEP for confidentiality, authentication, or access control is deprecated. The WEP algorithm is
unsuitable for the purposes of this standard.
The use of TKIP is deprecated. The TKIP algorithm is unsuitable for the purposes of this standard.
A STA that has associated with management frame protection enabled shall not use pairwise cipher suite
selectors WEP-40, WEP-104, TKIP, or “Use group cipher suite.”
A mesh STA with dot11MeshSecurityActivated equal to true shall not use the pairwise cipher suite selectors
WEP-40, WEP-104, or TKIP.
5.1.3 MSDU ordering
The services provided by the MAC sublayer permit, and might in certain cases require, the reordering of
MSDUs.
In a non-QoS STA, the MAC does not intentionally reorder MSDUs except as might be necessary to
improve the likelihood of successful delivery based on the current operational (“power management,” FMS,
DMS) mode of the designated recipient STA(s). The sole effect of this reordering (if any), for the set of
248
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MSDUs received at the MAC service interface of any single STA, is a change in the delivery order of group
addressed MSDUs, relative to individually addressed MSDUs, originating from a single source STA
address.
If a higher layer protocol using the data service cannot tolerate this possible reordering, the optional
StrictlyOrdered service class can be used. MSDUs transferred between any pair of STAs using the
StrictlyOrdered service class are not subject to the relative reordering that is possible when the
ReorderableGroupAddressed service class is used. However, the ability to receive MSDUs sent using the
StrictlyOrdered service class precludes simultaneous use of the MAC power management facilities at that
STA. Note that the use of the StrictlyOrdered service class is obsolete and the StrictlyOrdered service class
might be removed in a future revision of the standard.
The MSDUs are reordered, not only to improve the likelihood of successful delivery based on the current
operational mode of the designated recipient STA(s), but also to honor the priority parameters, specified in
the MA-UNITDATA.request primitive, of the individual MSDUs. The effects of this reordering (if any), for
the set of MSDUs received at the MAC service interface of any single STA, are:
a) A change in the delivery order of group addressed MSDUs, relative to individually addressed
MSDUs, and
b) The reordering of MSDUs with different TID values, originating from a single source STA address.
There shall be no reordering of individually addressed MSDUs with the same TID value and addressed to
the same destination.
STAs operating in a non-QoS BSS shall follow the reordering rules as defined for a non-QoS STA.
In order for the MAC to operate properly, this standard assumes that the DS meets the MSDU (“object”)
reordering requirements of IEEE Std 802.1AC™-2012 [B22].
Operational restrictions that provide the appropriate ordering of MSDUs are specified in 10.8.
When MSDU or A-MSDU reordering is performed, the information in the MAC service tuple(s) for the
MSDU(s) shall be maintained and reordered as a unit.
5.1.4 MSDU format
Logical Link Control (LLC) sublayer entities use the MAC sublayer service to exchange PDUs with peer
LLC sublayer entities. These PDUs are termed MAC sublayer SDUs (MSDUs) when sent to the MAC
sublayer. There are two LLC sublayer protocols used (see IEEE Std 802-2014); LLC Protocol
Discrimination (LPD) (see ISO/IEC 8802-2:1998) and EtherType Protocol Discrimination (EPD) (see
IEEE Std 802.3-2012). LPD is used for transmission of all IEEE 802.11 MSDUs with the exception of the
5.9 GHz bands where EPD is used (see E.2.3 and E.2.4).
When LPD is used, in order to achieve interoperability, implementers are recommended to apply the
procedures described in ISO/IEC Technical Report 11802-5:1997 (previously known as IEEE Std 802.1H-
1997 [B24]), along with a selective translation table (STT) that handles a few specific network protocols,
with specific attention to the operations required when passing MSDUs to or from LANs or operating
system components that use the Ethernet frame format (EPD). Note that such translations might be required
in a STA.
249
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
5.1.5 MAC data service architecture
5.1.5.1 General
The MAC data plane architecture (i.e., processes that involve transport of all or part of an MSDU) is shown
in Figure 5-1 when transparent FST is not being used and shown in Figure 5-2 when transparent FST is
being used.
The dotted line box labeled “Role-specific behaviors” is replaced by one of several options, depending on
the role of the STA. See the following subclauses
During transmission, an MSDU goes through some or all of the following processes: MSDU rate limiting,
aggregate MSDU (A-MSDU) aggregation, frame delivery deferral during power save mode, sequence
number assignment, integrity protection, fragmentation, encryption, frame formatting, and aggregate MAC
protocol data unit (A-MPDU) aggregation. When transparent FST is used, an MSDU first goes through an
additional transparent FST entity that contains a demultiplexing process that forwards the MSDU down to
the selected TX MSDU Rate Limiting process, and thence MAC data plane processing as described in the
previous sentence. IEEE Std 802.1X-2010 may block the MSDU at the Controlled Port before the preceding
processing occurs. Otherwise, at some point, the Data frames that contain all or part of the MSDU are
queued per AC/TS.
During reception, a received Data frame goes through processes of possible A-MPDU deaggregation,
MPDU header and cyclic redundancy code (CRC) validation, duplicate removal, decryption, possible
reordering if the block ack mechanism is used, replay detection, defragmentation, integrity checking,
possible A-MSDU deaggregation, and possible MSDU rate limiting. Then, one or more MSDUs are
delivered to the MAC SAP or to the DS via the DSAF. When transparent FST is used, MSDUs originating
from different PHY SAPs go through a final step of a transparent FST entity that contains a multiplexing
process before delivering the MSDU. The IEEE 802.1X Controlled/Uncontrolled Ports discard any received
MSDU if the Controlled Port is not enabled and if the MSDU does not represent an IEEE 802.1X frame.
When transparent FST is used, the same security keys, sequence counter, and PN counter are used by the
MAC data plane to encrypt the MPDU prior to and following an FST, and the same security keys are used to
check the integrity and perform the protection of MSDUs. When nontransparent FST is used, independent
RSNAs, security keys, sequence counters, and PN counters have to be established for each MAC data plane
to be used prior to and following an FST. When transparent FST is used, a single MAC SAP at each peer is
presented to the higher layers of that peer for all of the frequency bands/channels that are identified by the
same MAC address at that peer. When nontransparent FST is used, different MAC SAPs are presented to
higher layers since different MAC addresses are used prior to and following an FST.
250
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Local
802.1X Higher
Upper
PAE Layer
Layers
Entities
LPD/EPD LPD/EPD LLC
sublayer
() ()
802.11
For AP role specific behavior
this connection is not present
Role-
specific
behavior
(M) – MAC SAP
(U) – Uncontrolled port
(C) - Controlled port
(U) (C)
IEEE 802.1X
Controlled and Uncontrolled Port
Filtering (optional)
(M)
RX/TX MSDU
Rate Limiting
A-MSDU
Aggregation (TX) / De-aggregation (RX)
PS Defer Queuing
(AP or IBSS STA (null)
only)
MSDU Flow - Transmitting
MSDU Flow – Receiving
Sequence Number
(null)
Assignment
MSDU Integrity
and Protection
(optional)
Fragmentation (TX) /
Defragmentation (RX)
Packet Number Replay Detection
Assignment (optional)
Block Ack
The ‘MPDU
(null) Buffering and
Reordering
Decryption and
Integrity
MPDU (optional)’ and
Encryption (TX) / Decryption (RX) ‘Block Ack
and Integrity (optional) Buffering and
Reordering’
Duplicate
(null) processes may
Detection
be performed in
(null)
Block Ack either order (RX)
Scoreboarding
Address 1 address
(null)
filtering
MPDU Header + CRC
Creation (TX) / Validation (RX)
A-MPDU
Aggregation (TX) / De-aggregation (RX)
Figure 5-1—MAC data plane architecture
251
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Local
802.1X Higher
Upper
PAE Layer
Layers
Entities
LPD/EPD LPD/EPD LLC
sublayer
() ()
802.11
For AP role specific behavior
this connection is not present
Role-
specific
behavior
(U) (C)
IEEE 802.1X
Controlled and Uncontrolled Port
Filtering (optional)
(M)
Transparent FST Entity
(M) (M)
RX/TX MSDU RX/TX MSDU
Rate Limiting Rate Limiting
A-MSDU A-MSDU
Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX)
PS Defer Queuing PS Defer Queuing
(AP or IBSS STA (null) (AP or IBSS STA (null)
only) only)
MSDU Flow - Transmitting
MSDU Flow – Receiving
Same
Sequence Number security Sequence Number
(null) (null)
Assignment keys Assignment
and
MSDU Integrity Sequence MSDU Integrity
and Protection counter and Protection
(optional) (optional)
Fragmentation (TX) / Fragmentation (TX) /
Defragmentation (RX) Defragmentation (RX)
Packet Number Replay Detection Packet Number Replay Detection
Assignment (optional) Assignment (optional)
Same
Block Ack security Block Ack
(null) Buffering and keys (null) Buffering and
Reordering and Reordering
PN
MPDU MPDU
counters
Encryption (TX) / Decryption (RX) Encryption (TX) / Decryption (RX)
and Integrity (optional) and Integrity (optional)
Duplicate Duplicate
(null) (null)
Detection Detection
Block Ack Block Ack
(null) (null)
Scoreboarding Scoreboarding
Address 1 address Address 1 address
(null) (null)
filtering filtering
MPDU Header + CRC MPDU Header + CRC
Creation (TX) / Validation (RX) Creation (TX) / Validation (RX)
A-MPDU A-MPDU
Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX)
PHY in channel 1 PHY in channel 2
Figure 5-2—MAC data plane architecture (transparent FST)
252
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
5.1.5.2 Non-AP STA role
The MAC data plane architecture of a non-AP STA is completed by replacing the role-specific behavior
block with that shown in Figure 5-3. The function of this block in a non-AP STA is to perform destination
address filtering as described in 10.2.8.
NOTE—In implementations, the DA address filtering function may be done “lower in the stack.” It is shown in the role-
specific behavior block location for simplicity, and any implementation choice needs to provide equivalent behavior.
DA address
filtering
Figure 5-3—Role-specific behavior block for non-AP STA
5.1.5.3 AP role
In an AP, the MAC data plane architecture includes distribution system access in its role-specific behavior
block, as shown in Figure 5-4.This block provides access to the DS for associated non-AP STAs as
described in 4.5.2.1.
NOTE—This behavior block indicates that there is no access through the controlled port to or from the local upper-lay-
ers (the LLC sublayer) at an AP. Any such access is logically achieved in the architecture via transition of the DS and
Portal to an integrated LAN. In actual implementations, this is likely to be optimized, and data frames appear to be deliv-
ered directly to one or more local LLC sublayer entities on the same physical device as the AP. Such optimization is
effectively distributing the functions of the DS and Portal, and it is the responsibility of the implementation to ensure the
logical behavior of these entities is maintained.
Other APs/Mesh Gates/
Portal in the ESS
DSAF
(C) (DSS) * Distribution
System (DS)
* - DSS service may
conceptually be provided
by the “recursive” use of a
network stack
Figure 5-4—Role-specific behavior block for AP
5.1.5.4 Mesh STA role
The MAC data plane architecture of a mesh STA is completed by replacing the role-specific behavior block
with that shown in Figure 5-5. The function of this block in a mesh STA is described in Figure 10.35. This
role is not applicable when transparent FST is used, and does not apply to Figure 5-2.
253
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Path selection function
(Local address or
Mesh forwarding)
Figure 5-5—Role-specific behavior block for mesh STA
5.1.5.5 Mesh gate role
The MAC data plane architecture of a mesh gate is completed by replacing the role-specific behavior block
with that shown in Figure 5-6. The function of this block in a mesh gate is described in 14.11. This role is
not applicable when transparent FST is used, and does not apply to Figure 5-2.
To local
LLC sublayer
Other APs/Mesh Gates/
Portal in the ESS
DSAF
Path selection
function
(C) (DSS) * Distribution
(Local address,
DS, or Mesh System (DS)
forwarding)
* - DSS service may
conceptually be provided
by the “recursive” use of a
network stack
Figure 5-6—Role-specific behavior block for mesh gate
5.2 MAC data service specification
5.2.1 General
The IEEE 802.11 MAC supports the following service primitives as defined in ISO/IEC 8802-2:1998:
— MA-UNITDATA.request
— MA-UNITDATA.indication
— MA-UNITDATA-STATUS.indication
IEEE Std 802.11 places restrictions and semantics on the parameter values for these primitives, as described
in 5.2.2 to 5.2.4.
5.2.2 MA-UNITDATA.request
5.2.2.1 Function
This primitive requests a transfer of an MSDU from a local LLC sublayer entity to a single peer LLC
sublayer entity, or multiple peer LLC sublayer entities in the case of group addresses.
254
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
5.2.2.2 Semantics of the service primitive
The parameters of the primitive are as follows:
MA-UNITDATA.request(
source address,
destination address,
routing information,
data,
priority,
service class
)
The source address (SA) parameter specifies an individual MAC sublayer address of the sublayer entity
from which the MSDU is being transferred.
The destination address (DA) parameter specifies either an individual or a group MAC sublayer entity
address.
The routing information parameter specifies the route for the data transfer (a null value indicates source
routing is not to be used). For IEEE Std 802.11, the routing information parameter shall be null.
The data parameter specifies the MSDU to be transmitted by the MAC sublayer entity. The length of the
MSDU shall be less than or equal to the value shown in Table 9-19.
The priority parameter specifies the requested priority of the data unit transfer. The allowed values of
priority are described in 5.1.1.3.
The service class parameter specifies the requested service class of the data unit transfer. The allowed values
of service class are described in 5.1.1.4 and 5.1.3.
5.2.2.3 When generated
This primitive is generated by the LLC sublayer entity when an MSDU is to be transferred to a peer LLC
sublayer entity or entities.
5.2.2.4 Effect of receipt
On receipt of this primitive, the MAC sublayer entity determines whether it is able to fulfill the request
according to the requested parameters. A request that cannot be fulfilled according to the requested
parameters is discarded, and this action is indicated to the LLC sublayer entity using an MA-UNITDATA-
STATUS.indication primitive that describes why the MAC was unable to fulfill the request. If the request
can be fulfilled according to the requested parameters, the MAC sublayer entity properly formats a frame
and passes it to the lower layers for transfer to a peer MAC sublayer entity or entities (see 5.1.4), and
indicates this action to the LLC sublayer entity using an MA-UNITDATA-STATUS.indication primitive
with transmission status set to Successful.
At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an MA-UNITDATA.request
primitive having an individually addressed destination address and a priority of Contention or
ContentionFree, the AP’s MAC sublayer shall perform rate limiting to enforce the resource utilization limit
in dot11NonAPStationMaxAuthBestEffortRate in the dot11InterworkingEntry identified by the destination
MAC address of the frame to be transmitted. The specific mechanism to perform rate limiting is outside the
scope of this standard.
— If the rate limiting mechanism does not discard the frame, then dot11NonAPStationBestEffort-
MSDUCount shall be incremented by 1 and dot11NonAPStationBestEffortOctetCount shall be
incremented by the number of octets in the MSDU.
255
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedBestEffort-
MSDUCount shall be incremented by 1 and dot11NonAPStationDroppedBestEffortOctetCount
shall be incremented by the number of octets in the MSDU.
At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an MA-UNITDATA.request
primitive having an individually addressed destination address for which the priority is an integer in the
range 0 to 7, then the AP’s MAC sublayer shall derive the access category from the priority using the
mapping in Table 10-1. The AP’s MAC sublayer shall retrieve the MIB variables listed below from the
dot11InterworkingEntry identified by the destination MAC address of the frame to be transmitted and
perform the following operations:
— If the access category is AC_VO, then the AP’s MAC sublayer shall perform rate limiting to enforce
the resource utilization limit in dot11NonAPStationMaxAuthVoiceRate; the specific mechanism to
perform rate limiting is outside the scope of this standard. If the rate limiting mechanism does not
discard the frame, then dot11NonAPStationVoiceMSDUCount shall be incremented by 1 and
dot11NonAPStationVoiceOctetCount shall be incremented by the number of octets in the MSDU. If
the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedVoiceMSDU-
Count shall be incremented by 1 and dot11NonAPStationDroppedVoiceOctetCount shall be
incremented by the number of octets in the MSDU.
— If the access category is AC_VI, then the AP’s MAC sublayer shall perform rate limiting to enforce
the resource utilization limit in dot11NonAPStationMaxAuthVideoRate; the specific mechanism to
perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not
discard the frame, then dot11NonAPStationVideoMSDUCount shall be incremented by 1 and
dot11NonAPStationVideoOctetCount shall be incremented by the number of octets in the MSDU. If
the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedVideoMSDU-
Count shall be incremented by 1 and dot11NonAPStationDroppedVideoOctetCount shall be
incremented by the number of octets in the MSDU.
— If the access category is AC_BE, then the AP’s MAC sublayer shall perform rate limiting to enforce
the resource utilization limit in dot11NonAPStationMaxAuthBestEffortRate; the specific
mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting
mechanism does not discard the frame, then dot11NonAPStationBestEffortMSDUCount shall be
incremented by 1 and dot11NonAPStationBestEffortOctetCount shall be incremented by the
number of octets in the MSDU. If the rate limiting mechanism discards the frame, then
dot11NonAPStationDroppedBestEffortMSDUCount shall be incremented by 1 and
dot11NonAPStationDroppedBestEffortOctetCount shall be incremented by the number of octets in
the MSDU.
— If the access category is AC_BK, then the AP’s MAC sublayer shall perform rate limiting to enforce
the resource utilization limit in dot11NonAPStationMaxAuthBackgroundRate; the specific
mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting
mechanism does not discard the frame, then dot11NonAPStationBackgroundMSDUCount shall be
incremented by 1 and dot11NonAPStationBackgroundOctetCount shall be incremented by the
number of octets in the MSDU. If the rate limiting mechanism discards the frame, then
dot11NonAPStationDroppedBackgroundMSDUCount shall be incremented by 1 and
dot11NonAPStationDroppedBackgroundOctetCount shall be incremented by the number of octets
in the MSDU.
At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an MA-UNITDATA.request
primitive having an individually addressed destination address whose priority is an integer in the range 8 to
15, then the AP’s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in
dot11NonAPStationAuthMaxHCCAHEMMRate; the specific mechanism to perform rate limiting is outside
the scope of this standard.
— If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationHCCAHEMM-
MSDUCount shall be incremented by 1, and dot11NonAPStationHCCAHEMMOctetCount shall be
incremented by the number of octets in the MSDU.
256
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedHCCAHEMM-
MSDUCount shall be incremented by 1 and dot11NonAPStationDroppedHCCAHEMMOctetCount
shall be incremented by the number of octets in the MSDU.
5.2.3 MA-UNITDATA.indication
5.2.3.1 Function
This primitive defines the transfer of an MSDU from the MAC sublayer entity to the LLC sublayer entity, or
entities in the case of group addresses. In the absence of error, the contents of the data parameter are
logically complete and unchanged relative to the data parameter in the associated MA-UNITDATA.request
primitive.
5.2.3.2 Semantics of the service primitive
The parameters of the primitive are as follows:
MA-UNITDATA.indication(
source address,
destination address,
routing information,
data,
reception status,
priority,
service class
)
The SA parameter is an individual address as specified by the SA field of the incoming frame.
The DA parameter is either an individual or a group address as specified by the DA field of the incoming
frame.
The routing information parameter specifies the route that was used for the data transfer. The MAC sublayer
entity shall set this field to null.
The data parameter specifies the MSDU as received by the local MAC entity.
The reception status parameter indicates the success or failure of the received frame. The MAC always
reports “success” because all failures of reception are discarded without generating MA-
UNITDATA.indication primitive.
The priority parameter specifies the receive processing priority that was used for the data unit transfer. The
allowed values of priority are described in 5.1.1.3.
The service class parameter specifies the receive service class that was used for the data unit transfer. The
allowed values of service class are described in 5.1.1.4 and 5.1.3.
5.2.3.3 When generated
The MA-UNITDATA.indication primitive is passed from the MAC sublayer entity to the LLC sublayer
entity or entities to indicate the arrival of a frame at the local MAC sublayer entity. Frames are reported only
if they are validly formatted at the MAC sublayer, received without error, received with valid (or null)
security and integrity information, and their destination address designates the local MAC sublayer entity.
257
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
5.2.3.4 Effect of receipt
The effect of receipt of this primitive by the LLC sublayer is dependent on the content of the MSDU.
At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of a frame with the Type subfield
equal to Data having a group DA, the AP’s MAC sublayer shall discard the frame if
dot11NonAPStationAuthSourceMulticast is false in the dot11InterworkingEntry identified by the source
MAC address of the received frame. If dot11NonAPStationAuthSourceMulticast is true, the AP’s MAC
sublayer shall perform rate limiting to enforce the resource utilization limit in
dot11NonAPStationAuthMaxSourceMulticastRate in the dot11InterworkingEntry identified by the source
MAC address of the received frame. The specific mechanism to perform rate limiting is outside the scope of
this standard.
— If the rate limiting mechanism does not discard the frame, then dot11NonAPStationMulticast-
MSDUCount shall be incremented by 1 and dot11NonAPStationMulticastOctetCount shall be
incremented by the number of octets in the MSDU.
— If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedMulticast-
MSDUCount. shall be incremented by 1 and dot11NonAPStationDroppedMulticastOctetCount.
shall be incremented by the number of octets in the MSDU.
At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an individually addressed frame
with the Type subfield equal to Data and a priority of Contention or ContentionFree, then the AP’s MAC
sublayer shall perform rate limiting to enforce the resource utilization limit in
dot11NonAPStationMaxAuthBestEffortRate in the dot11InterworkingEntry identified by the source MAC
address of the received frame. The specific mechanism to perform rate limiting is outside the scope of this
standard.
— If the rate limiting mechanism does not discard the frame, then dot11NonAPStationBestEffort-
MSDUCount shall be incremented by 1 and dot11NonAPStationBestEffortOctetCount shall be
incremented by the number of octets in the MSDU.
— If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedBestEffort-
MSDUCount shall be incremented by 1 and dot11NonAPStationDroppedBestEffortOctetCount
shall be incremented by the number of octets in the MSDU.
At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an individually addressed frame
with the Type subfield equal to Data, for which the priority is an integer in the range 0 to 7, then the AP’s
MAC sublayer shall derive the access category from the priority using the mapping in Table 10-1. The AP’s
MAC sublayer shall retrieve the MIB variables from the dot11InterworkingEntry identified by the source
MAC address of the received frame and perform the following operations:
— If the access category is AC_VO, then the AP’s MAC sublayer shall perform rate limiting to enforce
the resource utilization limit in dot11NonAPStationMaxAuthVoiceRate; the specific mechanism to
perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not
discard the frame, then dot11NonAPStationVoiceMSDUCount shall be incremented by 1 and
dot11NonAPStationVoiceOctetCount shall be incremented by the number of octets in the MSDU. If
the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedVoiceMSDU-
Count shall be incremented by 1 and dot11NonAPStationDroppedVoiceOctetCount shall be
incremented by the number of octets in the MSDU.
— If the access category is AC_VI, then the AP’s MAC sublayer shall perform rate limiting to enforce
the resource utilization limit in dot11NonAPStationMaxAuthVideoRate; the specific mechanism to
perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not
discard the frame, then dot11NonAPStationVideoMSDUCount shall be incremented by 1 and
dot11NonAPStationVideoOctetCount shall be incremented by the number of octets in the MSDU. If
the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedVideoMSDU-
Count shall be incremented by 1 and dot11NonAPStationDroppedVideoOctetCount shall be
incremented by the number of octets in the MSDU.
258
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— If the access category is AC_BE, then the AP’s MAC sublayer shall perform rate limiting to enforce
the resource utilization limit in dot11NonAPStationMaxAuthBestEffortRate; the specific
mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting
mechanism does not discard the frame, then dot11NonAPStationBestEffortMSDUCount shall be
incremented by 1 and dot11NonAPStationBestEffortOctetCount shall be incremented by the
number of octets in the MSDU. If the rate limiting mechanism discards the frame, then
dot11NonAPStationDroppedBestEffortMSDUCount shall be incremented by 1 and
dot11NonAPStationDroppedBestEffortOctetCount shall be incremented by the number of octets in
the MSDU.
— If the access category is AC_BK, then the AP’s MAC sublayer shall perform rate limiting to enforce
the resource utilization limit in dot11NonAPStationMaxAuthBackgroundRate; the specific
mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting
mechanism does not discard the frame, then dot11NonAPStationBackgroundMSDUCount shall be
incremented by 1 and dot11NonAPStationBackgroundOctetCount shall be incremented by the
number of octets in the MSDU. If the rate limiting mechanism discards the frame, then
dot11NonAPStationDroppedBackgroundMSDUCount shall be incremented by 1 and
dot11NonAPStationDroppedBackgroundOctetCount shall be incremented by the number of octets
in the MSDU.
At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an individually addressed frame
with the Type subfield equal to Data for which the priority is an integer in the range 8 to 15, the AP’s MAC
sublayer shall perform rate limiting to enforce the resource utilization limit in
dot11NonAPStationAuthMaxHCCAHEMMRate; the specific mechanism to perform rate limiting is outside
the scope of this standard.
— If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationHCCAHEMM-
MSDUCount shall be incremented by 1, and dot11NonAPStationHCCAHEMMOctetCount shall be
incremented by the number of octets in the MSDU.
— If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedHCCAHEMM-
MSDUCount shall be incremented by 1 and dot11NonAPStationDroppedHCCAHEMMOctetCount
shall be incremented by the number of octets in the MSDU.
5.2.4 MA-UNITDATA-STATUS.indication
5.2.4.1 Function
This primitive has local significance and provides the LLC sublayer with status information for the
corresponding preceding MA-UNITDATA.request primitive.
5.2.4.2 Semantics of the service primitive
The parameters of the primitive are as follows:
MA-UNITDATA-STATUS.indication(
source address,
destination address,
transmission status,
provided priority,
provided service class
)
The SA parameter is an individual MAC sublayer entity address as specified in the associated MA-
UNITDATA.request primitive.
259
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DA parameter is either an individual or group MAC sublayer entity address as specified in the
associated MA-UNITDATA.request primitive.
The transmission status parameter is used to pass status information back to the local requesting LLC
sublayer entity. IEEE Std 802.11 specifies the following values for transmission status:
a) Successful.
b) Undeliverable (excessive data length).
c) Undeliverable (non-null source routing).
d) Undeliverable: unsupported priority (for priorities other than Contention or ContentionFree at a non-
QoS STA; or for priorities other than Contention, ContentionFree, or an integer in the range 0 to 15
at a QoS STA).
e) Undeliverable: unsupported service class (for service classes other than
ReorderableGroupAddressed or StrictlyOrdered for non-QoS STAs and service classes other than
QoSAck or QoSNoAck for QoS STAs).
f) Unavailable priority (for ContentionFree when no PC or HC is available, or an integer in the range 1
to 15 at a STA that is associated in a non-QoS BSS, or an integer in the range 8 to 15 at a STA that
is a member of an IBSS, in which case the MSDU is transmitted with a provided priority of
Contention).
g) Undeliverable: unavailable service class (for StrictlyOrdered service when the STA’s power
management mode is other than “active” for non-QoS STAs; QoS STAs do not return this value as
they do not provide the StrictlyOrdered service).
h) Undeliverable (no BSS available).
i) Undeliverable (cannot encrypt with a null key).
j) In a STA in which dot11RejectUnadmittedTraffic is true, Undeliverable: unadmitted traffic (for a
requested priority in the range 0 to 7 because there is no admitted TS for this priority and admission
control is required for the AC).
k) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified
by dot11NonAPStationMaxAuthVoiceRate in the dot11InterworkingTable for the non-AP STA
identified by the destination address of the MA-UNITDATA.request primitive).
l) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified
by dot11NonAPStationMaxAuthVideoRate in the dot11InterworkingTable for the non-AP STA
identified by the destination address of the MA-UNITDATA.request primitive).
m) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified
by dot11NonAPStationMaxAuthBestEffortRate in the dot11InterworkingTable for the non-AP STA
identified by the destination address of the MA-UNITDATA.request primitive).
n) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified
by dot11NonAPStationAuthMaxBackgroundRate in the dot11InterworkingTable for the non-AP
STA identified by the destination address of the MA-UNITDATA.request primitive).
o) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified
by dot11NonAPStationAuthMaxHCCAHEMMRate in the dot11InterworkingTable for the non-AP
STA identified by the destination address of the MA-UNITDATA.request primitive).
If the transmission status parameter is Successful, the provided priority parameter specifies the priority used
for the associated data unit transfer (Contention, ContentionFree, or an integer in the range 0 to 15);
otherwise the provided priority parameter is not present.
If the transmission status parameter is Successful, the provided service class parameter specifies the class of
service for the associated data unit transfer; otherwise the provided service class parameter is not present. In
non-QoS STAs, the value of this parameter is ReorderableGroupAddressed or StrictlyOrdered. In QoS
STAs, it is QoSAck or QoSNoAck.
260
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
5.2.4.3 When generated
The MA-UNITDATA-STATUS.indication primitive is passed from the MAC sublayer entity to the LLC
sublayer entity to indicate the status of the service provided for the corresponding MA-UNITDATA.request
primitive.
5.2.4.4 Effect of receipt
The effect of receipt of this primitive by the LLC sublayer is dependent upon the type of operation employed
by the LLC sublayer entity.
261
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6. Layer management
6.1 Overview of management model
Both the MAC sublayer and PHY conceptually include management entities, called MLME and PLME,
respectively. These entities provide the layer management service interfaces through which layer
management functions are invoked.
In order to provide correct MAC operation, an SME is present within each STA. The SME is a layer-
independent entity that resides in a separate management plane or resides “off to the side.” Some of the
functions of the SME are specified in this standard. Typically this entity is responsible for such functions as
the gathering of layer-dependent status from the various layer management entities (LMEs), and similarly
setting the value of layer-specific parameters. The SME typically performs such functions on behalf of
general system management entities and would implement standard management protocols. Figure 4-19 (in
4.9) depicts the relationship among management entities.
The various entities within this model interact in various ways. Certain of these interactions are defined
explicitly within this standard, via a SAP across which defined primitives are exchanged. This definition
includes the GET and SET operations between MLME, PLME and SME as well as other individually
defined service primitives, represented as double arrows within Figure 6-1. Other interactions are not
defined explicitly within this standard, such as the interfaces between the MAC and MLME and between the
PLME and PHY; the specific manner in which these MAC and PHY LMEs are integrated into the overall
MAC sublayer and PHY is not specified within this standard. A STA includes only one instance of a PHY
entity.
MLME
MAC MIB MLME-GET/SET
MAC
PLME-GET/SET
Station
Management
Entity
PHY MIB PLME-GET/SET
PHY
PLME
Figure 6-1—GET and SET operations
The management SAPs within this model are the following:
— SME-MLME SAP
— SME-PLME SAP
— MLME-PLME SAP
The latter two SAPs support identical primitives, and in fact might be viewed as a single SAP (called the
PLME SAP) that is used either directly by MLME or by SME. In this fashion, the model reflects what is
anticipated to be a common implementation approach in which PLME functions are controlled by the
MLME (on behalf of SME).
262
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.2 Generic management primitives
The management information specific to each layer is represented as a MIB for that layer. The MLME and
PLME are viewed as “containing” the MIB for that layer. The generic model of MIB-related management
primitives exchanged across the management SAPs is to allow the SAP user-entity to either GET the value
of a MIB attribute, or to SET the value of a MIB attribute. The invocation of a SET.request primitive might
require that the layer entity perform certain defined actions.
Figure 6-1 depicts these generic primitives.
The GET and SET primitives are represented as REQUESTs with associated CONFIRM primitives. These
primitives are prefixed by MLME or PLME depending upon whether the MAC sublayer or PHY
management SAP is involved. In the following, XX denotes MLME or PLME:
XX-GET.request(MIBattribute)
Requests the value of the given MIBattribute.
XX-GET.confirm(status, MIBattribute, MIBattributevalue)
Returns the appropriate MIB attribute value if status = “success,” otherwise returns an error indica-
tion in the Status field. Possible error status values include “invalid MIB attribute” and “attempt to
get write-only MIB attribute.”
XX-SET.request(MIBattribute, MIBattributevalue)
Requests that the indicated MIB attribute be set to the given value. If this MIBattribute implies a
specific action, then this requests that the action be performed.
XX-SET.confirm(status, MIBattribute)
If status = “success,” this confirms that the indicated MIB attribute was set to the requested value;
otherwise it returns an error condition in status field. If this MIBattribute implies a specific action,
then this confirms that the action was performed. Possible error status values include “invalid MIB
attribute” and “attempt to set read-only MIB attribute.”
Additionally, there are certain requests that can be invoked across a given SAP that do not involve the
setting or getting of a specific MIB attribute. One of these is supported by each SAP, as follows:
— XX-RESET.request: where XX is MLME or PLME as appropriate
This service is used to initialize the management entities, the MIBs, and the datapath entities. It might
include a list of attributes for items to be initialized to nondefault values.
Other SAP-specific primitives are identified in 6.3.
6.3 MLME SAP interface
6.3.1 Introduction
The services provided by the MLME to the SME are specified in this subclause. These services are
described in an abstract way (following the model described in ITU-T Recommendation X.210 [B54]) and
do not imply any particular implementation or exposed interface. MLME SAP primitives are of the general
form ACTION.request primitive followed by ACTION.confirm primitive (for an exchange initiated by the
SAP client) and ACTION.indication primitive followed by ACTION.response primitive (for an exchange
initiated by the MLME). The SME uses the services provided by the MLME through the MLME SAP.
263
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.2 Power management
6.3.2.1 Introduction
This mechanism supports the process of establishment and maintenance of the power management mode of
a STA.
6.3.2.2 MLME-POWERMGT.request
6.3.2.2.1 Function
This primitive requests a change in the power management mode.
6.3.2.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-POWERMGT.request(
PowerManagementMode,
ReceiveDTIMs
)
Name Type Valid range Description
PowerManagementMode Enumeration ACTIVE, An enumerated type that describes the
POWER_SAVE requested power management mode of the STA.
ReceiveDTIMs Boolean true, false Non-DMG BSS: When true, this parameter
causes the STA to awaken to receive all DTIM
frames. When false, the STA is not required to
awaken for every DTIM Beacon frame.
DMG BSS: Not applicable
6.3.2.2.3 When generated
This primitive is generated by the SME to implement the power-saving strategy of an implementation.
6.3.2.2.4 Effect of receipt
This request sets the STA’s power management parameters. The MLME subsequently issues an MLME-
POWERMGT.confirm primitive that reflects the results of the power management change request.
6.3.2.3 MLME-POWERMGT.confirm
6.3.2.3.1 Function
This primitive confirms the change in power management mode.
6.3.2.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-POWERMGT.confirm(
ResultCode
)
264
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates the result of the
NOT_SUPPORTED MLME-POWERMGT.request
primitive.
6.3.2.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-POWERMGT.request primitive to
establish a new power management mode. It is not generated until the change has completed as defined in
11.2.3.
6.3.2.3.4 Effect of receipt
The SME is notified of the change of power management mode.
6.3.3 Scan
6.3.3.1 Introduction
This mechanism supports the process of determining the characteristics of the available BSSs.
6.3.3.2 MLME-SCAN.request
6.3.3.2.1 Function
This primitive requests a survey of potential BSSs that the STA can later elect to try to join.
6.3.3.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SCAN.request(
BSSType,
BSSID,
SSID,
ScanType,
ProbeDelay,
ChannelList,
MinChannelTime,
MaxChannelTime,
RequestInformation,
SSID List,
ChannelUsage,
AccessNetworkType,
HESSID,
MeshID,
DiscoveryMode,
VendorSpecificInfo
)
265
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
BSSType Enumeration INFRASTRUCTURE, Determines whether infrastructure BSS,
PERSONAL, PBSS, IBSS, MBSS, or all, are included
INDEPENDENT, in the scan.
MESH, ANY_BSS
BSSID MACAddress Any valid individual or Identifies a specific or wildcard BSSID.
broadcast MAC address
SSID Octet string 0–32 octets Specifies the desired SSID or the wildcard
SSID.
ScanType Enumeration ACTIVE, Indicates either active or passive
PASSIVE scanning.
ProbeDelay Integer N/A Delay (in microseconds) to be used prior
to transmitting a Probe frame during
active scanning.
ChannelList Set of integers Each channel is selected Specifies a list of channels that are
from the valid channel examined when scanning for a BSS.
range for the appropriate
PHY and carrier set.
MinChannelTime Integer N/A The minimum time (in TU) to spend on
each channel when scanning.
MaxChannelTime Integer MinChannelTime The maximum time (in TU) to spend on
each channel when scanning.
RequestInformation A list of As defined in 9.4.2.10 This parameter is optionally present if
(Extended) and 9.4.2.11. dot11RadioMeasurementActivated is true
Element IDs and is placed in a Probe Request frame to
request that the responding STA include
the requested information in the Probe
Response frame.
SSID List A set of SSID As defined in 9.4.2.2. One or more SSID elements that are
Element optionally present when
dot11SSIDListActivated is true.
ChannelUsage A set of Channel As defined in 9.4.2.86 Specifies request types for the Channel
Usage element Usage request.
AccessNetworkTyp As defined in 0 to 15 Specifies the target specific access
e Table 9-214 network type or the wildcard access
network type. This field is present when
dot11InterworkingServiceActivated is
true.
HESSID MAC Address Any valid individual Specifies the target specific HESSID
MAC address or the network identifier or the wildcard network
broadcast MAC address identifier. This field is present when
dot11InterworkingServiceActivated is
true.
Mesh ID Octet string 0–32 octets Only present if BSSType = MESH or
BSSType = ANY_BSS. Specifies the
target Mesh ID or wildcard Mesh ID.
DiscoveryMode Integer 0–1 Indicates, if equal to 1, that a DMG
Beacon frame is transmitted during active
scanning with the Discovery Mode field
set to 1 and, if equal to 0, that a DMG
Beacon frame is not transmitted during
active scanning. Present only when
dot11DMGOptionImplemented is true.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
266
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.3.2.3 When generated
This primitive is generated by the SME for a STA to determine if there are other BSSs that it can join.
6.3.3.2.4 Effect of receipt
This request initiates the scan process when the current frame exchange sequence is completed.
6.3.3.3 MLME-SCAN.confirm
6.3.3.3.1 Function
This primitive returns the descriptions of the set of BSSs detected by the scan process.
6.3.3.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SCAN.confirm(
BSSDescriptionSet,
BSSDescriptionFromMeasurementPilotSet,
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
BSSDescriptionSet Set of N/A The BSSDescriptionSet is returned to
BSSDescriptions indicate the results of the scan request. It
is a set containing zero or more instances
of a BSSDescription.
BSSDescriptionFrom Set of N/A The
MeasurementPilotSet BSSDescriptionFrom BSSDescriptionFromMeasurementPilotS
MeasurementPilots et is returned to indicate the results of the
scan request derived from measurement
pilots. It is a set containing zero or more
instances of a
BSSDescriptionFromMeasurementPilot.
Present if
dot11RMMeasurementPilotActivated is
nonzero; otherwise not present.
ResultCode Enumeration SUCCESS, Indicates the result of the MLME-
NOT_SUPPORTED SCAN.confirm primitive.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
Each BSSDescription consists of the parameters shown in the following table, in which the term peer STA
refers to the STA transmitting the Beacon frame or Probe Response frame from which the BSSDescription
was determined and the term local STA refers to the STA performing the scan, and in which the “IBSS
adoption” column indicates whether
a) This parameter is adopted by a STA that is joining an IBSS.
b) This parameter is adopted by a STA that is a member of an IBSS that receives a beacon from a STA
that is a member of the same IBSS and that has a timestamp value that is greater than the local TSF
value (see 11.1.5).
267
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description IBSS adoption
BSSID MACAddress N/A The BSSID of the found BSS Adopt
or the MAC address of the
found mesh STA.
SSID Octet string 0–32 octets The SSID of the found BSS. Adopt
BSSType Enumeration INFRASTRUCTUR The type of the found BSS. Adopt
E,
PERSONAL,
INDEPENDENT,
MESH
Beacon Period Integer N/A The beacon period (in TU) of Adopt
the found BSS if the BSSType
is not MESH, or of the found
mesh STA if the BSSType =
MESH.
DTIM Period Integer As defined in 9.4.2.6 The DTIM period (in beacon Adopt
periods) of the BSS if the
BSSType is not MESH, or of
the mesh STA if the BSSType
= MESH.
Timestamp Integer N/A The timestamp of the received Adopt
frame (Probe Response/
Beacon) from the found BSS.
Local Time Integer N/A The value of the local STA’s Do not adopt
TSF timer at the start of
reception of the first octet of
the timestamp field of the
received frame (Probe
Response or Beacon) from the
found BSS.
PHY Parameter Set As defined in As defined in frame The parameter sets relevant to Adopt
frame format format or according the PHY from the received
or according to the relevant PHY Beacon or Probe Response
to the relevant clause. frame. If no PHY Parameter
PHY clause. Set element is present in the
received frame, this parameter
contains the channel number
on which the frame was
received. Valid channel
numbers are defined in the
relevant PHY clause.
CF Parameter Set CF Parameter As defined in 9.4.2.5 The parameter set for the CF Do not adopt
Set element periods, if found BSS supports
CF mode.
IBSS Parameter IBSS As defined in 9.4.2.7 The parameter set for the Adopt
Set Parameter Set IBSS, if found BSS is an IBSS.
element
CapabilityInformat Capability As defined in 9.4.1.4 The advertised capabilities of Do not adopt
ion Information the BSS.
field
BSSBasicRateSet Set of integers Non-DMG BSS: 1- Non-DMG BSS: The set of Adopt
127 excluding values data rates (in units of 500 kb/s)
from Table 9-78, for that all STAs in the BSS are
each member of the able to use for communication.
set All STAs in the BSS are able to
receive and transmit at each of
the data rates listed in the set.
DMG BSS: Empty.
268
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description IBSS adoption
OperationalRateSe Non-DMG Non-DMG BSS: 1- Non-DMG BSS: The set of Do not adopt
t BSS: Set of 127 excluding values data rates (in units of 500 kb/s)
integers from Table 9-78, for that the peer STA is able to use
each member of the for communication within the
DMG BSS: set BSS. The peer STA is able to
Set of receive at each of the data rates
numbers DMG BSS: 0-24, 9.1, listed in the set. This set is a
or 12.1-12.6, for each superset of the rates contained
member of the set in the BSSBasicRateSet
parameter.
DMG BSS: The set of MCS
indexes that the peer STA uses
for communication within the
BSS.
Country As defined in As defined in the The information required to Adopt
the Country Country element identify the regulatory domain
element in which the peer STA is
located and to configure its
PHY for operation in that
regulatory domain.
Present if TPC functionality is
required, as specified in 11.8,
or
dot11MultiDomainCapability
Activated is true or
dot11RadioMeasurementActiv
ated is true; otherwise not
present.
IBSS DFS Integer 1–255 The time interval that is used Adopt
Recovery Interval for DFS recovery.
Present if DFS functionality is
required, as specified in 11.9
and
BSSType = INDEPENDENT;
otherwise not present.
RSN RSNE As defined in A description of the cipher Do not adopt
9.4.2.25 suites and AKM suites
supported in the BSS.
Load BSS Load As defined in The values from the BSS Load Do not adopt
element 9.4.2.28 element if such an element was
present in the Probe Response
or Beacon frame, else null.
EDCAParameterSe EDCA As defined in The values from the EDCA Adopt
t Parameter Set 9.4.2.29 Parameter Set element if such
element an element was present in the
Probe Response or Beacon
frame, else null.
QoSCapability QoS As defined in The values from the QoS Adopt
Capability 9.4.2.35 Capability element if such an
element element was present in the
Probe Response or Beacon
frame, else null.
AP Channel Report AP Channel As defined in The values from the AP Adopt
Report 9.4.2.36 Channel Report element if
element such an element was present in
the probe response or Beacon
frame, else null.
269
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description IBSS adoption
BSS Average BSS Average As defined in The values from the BSS Adopt
Access Delay Access Delay 9.4.2.39 Average Access Delay element
element if such an element was present
in the probe response or
Beacon frame, else null.
Antenna Antenna As defined in The values from the Antenna Adopt
element 9.4.2.40 element if such an element was
present in the probe response
or Beacon frame, else null.
BSS Available BSS As defined in The values from the BSS Adopt
Admission Available 9.4.2.43 Available Admission Capacity
Capacity Admission element if such an element was
Capacity present in the probe response
element or Beacon frame, else null.
BSS AC Access BSS AC As defined in The values from the BSS AC Adopt
Delay Access Delay 9.4.2.44 Access Delay element if such
element an element was present in the
probe response or Beacon
frame, else null.
Measurement Pilot Measurement As defined in The values from the Adopt
Transmission Pilot 9.4.2.42 Measurement Pilot
Information Transmission Transmission element if such
element an element was present in the
probe response or Beacon
frame, else null.
Multiple BSSID As defined in As defined in The values from the Multiple Do not adopt
Multiple 9.4.2.46 BSSID element if such an
BSSID element was present in the
element probe response or Beacon
frame, else null.
RM Enabled RM Enabled As defined in The values from the RM Adopt
Capabilities Capabilities 9.4.2.45 Enabled Capabilities element if
element such an element was present in
the probe response or Beacon
frame, else null.
RCPIMeasurement Integer As defined in The RCPI of the received Adopt
9.4.2.38 frame.
RSNIMeasurement Integer As defined in The RSNI of the received Adopt
9.4.2.41 frame.
Requested Set of As defined in Elements requested by the Adopt
elements elements 9.4.1.36 Request element or Extended
Request element of the Probe
Request frame.
DSERegisteredLoc DSE As defined in The information from the DSE Adopt
ation Registered 9.4.2.52 Registered Location element, if
Location such a field is present in the
element Probe Response or Beacon
frame, else null. Present if DSE
functionality is required, as
specified in 11.12, or
dot11LCIDSERequired is true;
otherwise not present.
270
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description IBSS adoption
HT Capabilities As defined in As defined in The values from the HT Do not adopt
frame format 9.4.2.56 Capabilities element if such an
element was present in the
Probe Response or Beacon
frame, else null.
The parameter is optionally
present if
dot11HighThroughputOptionI
mplemented is true; otherwise
not present.
HT Operation As defined in As defined in The values from the HT Adopt
frame format 9.4.2.57 Operation element if such an
element was present in the
Probe Response or Beacon
frame, else null.
The parameter is optionally
present if
dot11HighThroughputOptionI
mplemented is true; otherwise
not present.
BSSMembershipS Set of integers A value from The set of features that are Adopt
electorSet Table 9-78 for each supported by all STAs joining
member of the set this BSS.
Extended As defined in As defined in Specifies the parameters within Do not adopt
Capabilities frame format 9.4.2.27 the Extended Capabilities
element that are supported by
the MAC entity.
20/40 BSS As defined in As defined in Specifies the parameters within Do not adopt
Coexistence frame format 9.4.2.60 the 20/40 BSS Coexistence
element that are indicated by
the MAC entity.
The parameter is present if
dot112040BSSCoexistence-
ManagementSupport is true.
Overlapping BSS As defined in As defined in Specifies the parameters within Adopt
Scan Parameters frame format 9.4.2.59 the Overlapping BSS Scan
Parameters element that are
indicated by the MAC entity.
This parameter is optionally
present if
dot11FortyMHzOptionImplem
ented is true and is not present
if
dot11FortyMHzOptionImplem
ented is false.
FMSDescriptor FMS As defined in The values from the FMS Do not adopt
Descriptor 9.4.2.75 Descriptor element if such an
element element was present in the
Probe Response or Beacon
frame, else null.
QoSTrafficCapabil QoS Traffic As defined in The values from the QoS Do not adopt
ity Capability 9.4.2.78 Traffic Capability element if
element such an element was present in
the Probe Response or Beacon
frame, else null.
ChannelUsage A set of As defined in Specifies parameters for the Do not adopt
Channel 9.4.2.86 Channel Usage.
Usage
element
271
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description IBSS adoption
TimeAdvertisemen Time As defined in The values from the Time Do not adopt
t Advertisemen 9.4.2.61 Advertisement element if such
t element an element was present in the
Probe Response or Beacon
frame, else null.
TimeZone Time Zone As defined in The values from the Time Zone Do not adopt
element 9.4.2.87 element if such an element was
present in the Probe Response
or Beacon frame, else null.
MeshID Mesh ID As defined in The value of MeshID element Do not adopt
element 9.4.2.99 if such element was present in
the probe response or Beacon
frame, else null.
MeshConfiguratio Mesh As defined in The values from the Mesh Do not adopt
n Configuration 9.4.2.98 Configuration element if such
element an element was present in the
probe response or Beacon
frame, else null.
Mesh Awake Mesh Awake As defined in The values from the Mesh Do not adopt
Window Window 9.4.2.104 Awake Window element if
element such an element was present in
the Probe Response or Beacon
frame, else null.
BeaconTiming Beacon As defined in The values from the Beacon Do not adopt
Timing 9.4.2.105 Timing element if such an
element element was present in the
Probe Response or Beacon
frame, else null.
MCCAOP MCCAOP As defined in frame The values from the Beacon Do not adopt
Advertisement Advertisemen format Timing element if such an
Overview t Overview element was present in the
element Probe Response or Beacon
frame, else null.
MCCAOP MCCAOP As defined in frame The values from the Beacon Do not adopt
Advertisement Advertisemen format Timing element if such an
t element was present in the
Probe Response or Beacon
frame, else null.
QMFPolicy QMF Policy As defined in The values from the QMF Do not adopt
element 9.4.2.120 Policy element if such an
element was present in the
Probe Response or Beacon
frame, else null.
QLoad Report As defined in As defined in The values from the QLoad Do not adopt.
frame format 9.4.2.123 Report element if such an
element was present in the
Probe Response frame, else
null.
Sector Sweep As defined in As defined in 9.3.4.2 The values from the Sector Adopt
frame format Sweep field from the DMG
Beacon frame, else null.
The parameter is present only
if
dot11DMGOptionImplemente
d is true.
272
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description IBSS adoption
Beacon Interval As defined in As defined in 9.3.4.2 The values from the Beacon Adopt
Control frame format Interval Control field from the
DMG Beacon frame, else null.
The parameter is present only
if
dot11DMGOptionImplemente
d is true.
DMG Parameters As defined in As defined in 9.3.4.2 The values from the DMG Adopt
frame format Parameters field from the
DMG Beacon frame, else null.
The parameter is present only
if
dot11DMGOptionImplemente
d is true.
Clustering Control As defined in As defined in 9.3.4.2 The values from the Clustering Do not adopt
frame format Control field from the DMG
Beacon frame, else null.
The parameter is present only
if
dot11DMGOptionImplemente
d is true.
DMG Capabilities As defined in As defined in The values from the DMG Do not adopt
frame format 9.4.2.128 Capabilities element if such an
element was present in the
Probe Response or DMG
Beacon frame, else null.
The parameter is optionally
present only if
dot11DMGOptionImplemente
d is true.
DMG Operation As defined in As defined in The values from the DMG Adopt
frame format 9.4.2.128 Operation element if such an
element was present in the
Probe Response or DMG
Beacon frame, else null.
The parameter is optionally
present only if
dot11DMGOptionImplemente
d is true.
Extended Schedule As defined in As defined in The values from the Extended Adopt
frame format 9.4.2.132 Schedule element if such an
element was present in the
Probe Response or DMG
Beacon frame, else null.
The parameter is optionally
present only if
dot11DMGOptionImplemente
d is true.
Next DMG ATI As defined in As defined in The values from the Next Adopt
frame format 9.4.2.135 DMG ATI element if such an
element was present in the
Probe Response or DMG
Beacon frame, else null.
The parameter is optionally
present only if
dot11DMGOptionImplemente
d is true.
273
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description IBSS adoption
DMG BSS As defined in As defined in The values from the DMG BSS Adopt
Parameter Change frame format 9.4.2.127 Parameter Change element if
such an element was present in
the Probe Response or DMG
Beacon frame, else null.
The parameter is optionally
present only if
dot11DMGOptionImplemente
d is true.
Multi-band As defined in As defined in The values from the Multi- Adopt
frame format 9.4.2.138 band element if such an
element was present in the
Probe Response or DMG
Beacon frame, else null.
The Multi-band element is
optionally present if
dot11MultibandImplemented
is true.
DMG Wakeup As defined in As defined in The values from the DMG Adopt
Schedule frame format 9.4.2.131 Wakeup Schedule element if
such an element was present in
the Probe Response or DMG
Beacon frame, else null.
The parameter is optionally
present only if
dot11DMGOptionImplemente
d is true.
Antenna Sector ID As defined in As defined in The values from the Antenna Adopt
Pattern frame format 9.4.2.157 Sector ID Pattern element if
such an element was present in
the Probe Response or DMG
Beacon frame, else null.
The parameter is optionally
present only if
dot11DMGOptionImplemente
d is true.
Relay Capabilities As defined in As defined in The values from the Relay Do not adopt
frame format 9.4.2.148 Capabilities element if such an
element was present in the
Probe Response or DMG
Beacon frame, else null.
The parameter is optionally
present only if
dot11RelayActivated is true.
VHT Capabilities As defined in As defined in The values from the VHT Do not adopt
frame format 9.4.2.158 Capabilities element. The
parameter is present if
dot11VHTOptionImplemented
is true and a VHT Capabilities
element was present in the
Probe Response or Beacon
frame from which the
BSSDescription was
determined. The parameter is
not present otherwise.
274
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description IBSS adoption
VHT Operation As defined in As defined in The values from the VHT Adopt
frame format 9.4.2.159 Operation element. The
parameter is present if
dot11VHTOptionImplemented
is true and a VHT Operation
element was present in the
Probe Response or Beacon
frame from which the
BSSDescription was
determined. The parameter is
not present otherwise.
TVHT Operation As defined in As defined in The values from the TVHT Adopt
frame format 9.4.2.172 Operation element if such an
element was present in the
Probe Response or Beacon
frame; otherwise, null. The
parameter is optionally present
only if
dot11TVHTOptionImplemente
d is true.
Each BSSDescriptionFromMeasurementPilot consists of the following parameters, in which the term peer
STA refers to the STA transmitting the Measurement Pilot frame from which the BSSDescription was
determined and the term local STA refers to the STA performing the scan:
Name Type Valid range Description
BSSID MACAddress N/A The BSSID of the found BSS.
BSS Type Enumeration INFRASTRUCT The type of the found BSS.
URE
Local Time Integer N/A The value of the local STA’s TSF timer at the
start of reception of the first octet of the
timestamp field of the received frame from the
found BSS.
Condensed Capability Condensed As defined in The advertised condensed capabilities of the
Information Capability 9.6.8.3 BSS.
Information
field
Condensed Country Condensed As defined in Together with the Operating Class, the
String Country String 9.6.8.3 information required to identify the regulatory
field domain in which the peer STA is located and to
configure its PHY for operation in that
regulatory domain.
Operating Class Operating Class The field is Together with the Condensed Country String,
field defined in the information required to identify the
9.6.8.3, valid regulatory domain in which the peer STA is
values for the located and to configure its PHY for operation
field are defined in that regulatory domain.
in Annex E.
Channel Channel field The field is The operating channel of the BSS indicated in
defined in the received frame
9.6.8.3, valid
values for the
field are defined
in Annex E.
Measurement Pilot Measurement As defined in The Measurement Pilot interval of the BSS
Interval Pilot Interval 9.6.8.3 indicated in the received frame
field
275
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Multiple BSSID element Multiple BSSID As defined in Indicates that the BSS is within a multiple
element 9.4.2.46 BSSID set (see 11.11.14). The range of BSSIDs
is determined by the BSSID and Multiple
BSSID element.
PHY Type Integer As defined in The dot11PHYType of the received frame.
Annex C
RCPIMeasurement Integer As defined in The RCPI of the received frame.
9.4.2.38
RSNIMeasurement Integer As defined in The RSNI of the received frame.
9.4.2.41
6.3.3.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-SCAN.request primitive to ascertain the
operating environment of the STA.
6.3.3.3.4 Effect of receipt
The SME is notified of the results of the scan procedure.
6.3.4 Synchronization
6.3.4.1 Introduction
This mechanism supports the process of selection of a peer in the authentication process.
6.3.4.2 MLME-JOIN.request
6.3.4.2.1 Function
This primitive requests synchronization with a BSS, of which type is infrastructure or independent.
6.3.4.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-JOIN.request(
SelectedBSS,
JoinFailureTimeout,
NAVSyncDelay,
OperationalRateSet,
Capability Information,
HT Capabilities,
VHT Capabilities,
Extended Capabilities,
20/40 BSS Coexistence,
InterworkingInfo,
AdvertisementProtocolInfo,
VendorSpecificInfo
)
276
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
SelectedBSS BSSDescription N/A The BSSDescription of the BSS to join.
The SelectedBSS is a member of the set
of descriptions that was returned as a
result of an MLME-SCAN.request
primitive.
JoinFailureTimeout Integer 1 The time limit, in units of beacon
intervals, after which the join procedure is
terminated.
NAVSyncDelay Integer N/A Delay (in microseconds) to be used prior
to transmitting when changing from doze
to awake state, if no frame is detected by
which the network allocation vector
(NAV) can be set.
OperationalRateSet Non-DMG BSS: Set Non-DMG BSS: a Non-DMG BSS: The set of data rates (in
of integers value in units of 500 kb/s) that the STA is able to
dot11SupportedData use for communication within the BSS.
DMG BSS: Set of RatesRxTable, for The STA is able to receive at each of the
numbers each member of the data rates listed in the set. This set is a
set superset of the rates contained in the
BSSBasicRateSet parameter of the
DMG BSS: 0-24, SelectedBSS parameter.
9.1, or 12.1-12.6, for DMG BSS: The set of MCS indexes that
each member of the the STA uses for communication within
set the BSS.
CapabilityInformatio Capability As defined in 9.4.1.4 The capabilities to be advertised for the
n Information field BSS.
HT Capabilities As defined in frame As defined in The HT capabilities to be advertised for
format HT 9.4.2.56; the HT- the BSS. The parameter is present if
Capabilities element MCSs in the element dot11HighThroughputOptionImplemente
are present in d is true; otherwise, this parameter is not
dot11SupportedMC present.
SRxTable and the
highest supported
data rate in the
element does not
exceed
dot11HighestSuppor
tedDataRate
VHT Capabilities As defined in VHT As defined in Specifies the parameters in the VHT
Capabilities element 9.4.2.158; the VHT- Capabilities element that are supported by
MCSs in the element the STA. The parameter is present if
are present in dot11VHTOptionImplemented is true and
dot11VHTRxVHTM not present otherwise.
CSMap/
dot11VHTTxVHTM
CSMap and the
highest supported
rates in the element
do not exceed
dot11VHTRxHighes
tDataRateSupported/
dot11VHTTxHighes
tDataRateSupported
Extended As defined in frame As defined in Specifies the parameters within the
Capabilities format 9.4.2.27 Extended Capabilities element that are
supported by the MAC entity.
277
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
20/40 BSS As defined in frame As defined in Specifies the parameters within the 20/40
Coexistence format 9.4.2.60 BSS Coexistence element that are
indicated by the MAC entity.
The parameter is present if
dot112040BSSCoexistence-
ManagementSupport is true.
InterworkingInfo As defined in frame As defined in Specifies the Interworking capabilities of
format Interworking STA. This field is present when
element in 9.4.2.92 dot11InterworkingServiceActivated is
true.
AdvertisementProtoc Integer or Sequence As defined in Identifies zero or more Advertisement
olInfo of integers Advertisement Protocols and advertisement control to be
Protocol element in used in the BSSs. This field is present
Table 9-215 when dot11InterworkingServiceActivated
is true.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.4.2.3 When generated
This primitive is generated by the SME for a STA to establish synchronization with a BSS.
6.3.4.2.4 Effect of receipt
This primitive initiates a synchronization procedure once the current frame exchange sequence is complete.
The MLME synchronizes its timing with the specified BSS based on the information provided in the
SelectedBSS parameter. The MLME subsequently issues an MLME-JOIN.confirm primitive that reflects
the results.
If the MLME of a non-DMG STA receives an MLME-JOIN.request primitive with the SelectedBSS
parameter containing a BSSBasicRateSet parameter that contains any unsupported rates, the MLME
response in the resulting MLME-JOIN.confirm primitive shall contain a ResultCode parameter that is not
set to the value SUCCESS.
If the MLME of an HT STA receives an MLME-JOIN.request primitive with the SelectedBSS parameter
containing a Basic HT-MCS Set field in the HT Operation parameter that contains any unsupported MCSs,
the MLME response in the resulting MLME-JOIN.confirm primitive shall contain a ResultCode parameter
that is not set to the value SUCCESS.
If the MLME of a VHT STA receives an MLME-JOIN.request primitive with a SelectedBSS parameter
containing a Basic VHT-MCS And NSS Set field in the VHT Operation parameter that contains any
unsupported tuple, the MLME response in the resulting MLME-JOIN.confirm primitive
shall contain a ResultCode parameter that is not set to the value SUCCESS.
If the MLME of a DMG STA receives an MLME-JOIN.request primitive with the SelectedBSS parameter
containing a BSSBasicRateSet parameter that is not empty, or with the OperationalRateSet parameter
containing any unsupported MCSs, the MLME response in the resulting MLME-JOIN.confirm primitive
shall contain a ResultCode parameter that is not set to the value SUCCESS.
6.3.4.3 MLME-JOIN.confirm
6.3.4.3.1 Function
This primitive confirms synchronization with a BSS.
278
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.4.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-JOIN.confirm(
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates the result of the MLME-
JOIN_FAILURE_TI JOIN.request primitive.
MEOUT
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.4.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-JOIN.request primitive to establish
synchronization with a BSS.
6.3.4.3.4 Effect of receipt
The SME is notified of the results of the synchronization procedure.
6.3.5 Authenticate
6.3.5.1 Introduction
This mechanism supports the process of establishing an authentication relationship with a peer MAC entity.
6.3.5.2 MLME-AUTHENTICATE.request
6.3.5.2.1 Function
This primitive requests authentication with a specified peer MAC entity.
6.3.5.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-AUTHENTICATE.request(
PeerSTAAddress,
AuthenticationType,
AuthenticateFailureTimeout,
Content of FT Authentication elements,
Content of SAE Authentication frame,
Multi-band local,
Multi-band peer,
VendorSpecificInfo
)
279
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual MAC Specifies the address of the peer MAC
address entity with which to perform the
authentication process.
AuthenticationType Enumeration OPEN_SYSTEM, Specifies the type of authentication
SHARED_KEY, algorithm to use during the
FAST_BSS_TRANSITION, authentication process.
SAE
AuthenticateFailureT Integer 1 Specifies a time limit (in TU) after
imeout which the authentication procedure is
terminated.
Content of FT Sequence of As defined in 13.8 The set of elements to be included in
Authentication elements the first message of the FT
elements authentication sequence, as described
in 13.8.2. Present if
dot11FastBSSTransitionActivated is
true; otherwise not present.
Content of SAE Sequence of As defined in 9.4.1.38, The set of elements and fields to be
Authentication frame elements and 9.4.1.39, 9.4.1.40, 9.4.1.41, included in the SAE Commit message
fields 9.4.1.42, and 9.4.1.43 or SAE Confirm message. Present if
AuthenticationType indicates SAE
authentication; otherwise not present.
Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within the
element Multi-band element that are supported
by the local MAC entity. The
parameter is present if
dot11MultibandImplemented is true
and is absent otherwise.
Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within the
element Multi-band element that identify the
remote (peer) MAC entity. This
parameter is present if OCT is being
used and is absent otherwise.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.5.2.3 When generated
This primitive is generated by the SME for a STA to establish authentication with a specified peer MAC
entity in order to permit Class 2 frames, or mesh peering Management frames for AMPE utilizing SAE
authentication, to be exchanged between the two STAs. During the authentication procedure, the SME
might generate additional MLME-AUTHENTICATE.request primitives.
6.3.5.2.4 Effect of receipt
This primitive initiates an authentication procedure. In the case that a response is received from the
responder STA, the MLME subsequently issues an MLME-AUTHENTICATE.confirm primitive that
reflects the results.
6.3.5.3 MLME-AUTHENTICATE.confirm
6.3.5.3.1 Function
This primitive reports the results of an authentication attempt with a specified peer MAC entity.
280
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.5.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-AUTHENTICATE.confirm(
PeerSTAAddress,
AuthenticationType,
ResultCode,
Content of FT Authentication elements,
Content of SAE Authentication frame,
Multi-band local,
Multi-band peer,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual MAC Specifies the address of the peer MAC
address entity with which the authentication
process was attempted. This value
matches the peerSTAAddress parameter
specified in the corresponding MLME-
AUTHENTICATE.request primitive.
AuthenticationType Enumeration OPEN_SYSTEM, Specifies the type of authentication
SHARED_KEY algorithm that was used during the
FAST_BSS_TRANSITION, authentication process. This value
SAE matches the AuthenticationType
parameter specified in the corresponding
MLME-AUTHENTICATE.request
primitive.
ResultCode Enumeration SUCCESS, REFUSED, Indicates the result of the MLME-
ANTI-CLOGGING AUTHENTICATE.request primitive.
TOKEN REQUIRED,
FINITE CYCLIC GROUP
NOT SUPPORTED,
AUTHENTICATION
REJECTED, AUTH
FAILURE TIMEOUT
Content of FT Sequence of As defined in 13.8 The set of elements included in the
Authentication elements second message of the FT authentication
elements sequence, as described in 13.8.3. Present
if dot11FastBSSTransitionActivated is
true; otherwise not present.
Content of SAE Sequence of As defined in 9.4.1.38, The set of elements to be included in the
Authentication frame elements 9.4.1.39, 9.4.1.40, 9.4.1.41, SAE Commit message or SAE Confirm
9.4.1.42, and 9.4.1.43 message. Present if AuthenticationType
indicates SAE authentication; otherwise
not present.
Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within the Multi-
element band element that identify the local MAC
entity. This parameter is present if OCT is
being used and is absent otherwise.
Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within the Multi-
element band element that are supported by the
remote (peer) MAC entity. This
parameter is present if OCT is being used
and is absent otherwise.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
281
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.5.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-AUTHENTICATE.request primitive to
authenticate with a specified peer MAC entity.
6.3.5.3.4 Effect of receipt
The SME is notified of the results of the authentication procedure.
6.3.5.4 MLME-AUTHENTICATE.indication
6.3.5.4.1 Function
This primitive indicates receipt of a request from a specific peer MAC entity to establish an authentication
relationship with the STA processing this primitive.
6.3.5.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-AUTHENTICATE.indication(
PeerSTAAddress,
AuthenticationType,
Content of FT Authentication elements,
Content of SAE Authentication frame,
Multi-band local,
Multi-band peer,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual MAC Specifies the address of the peer MAC
address entity with which the authentication
relationship was established.
AuthenticationType Enumeration OPEN_SYSTEM, Specifies the type of authentication
SHARED_KEY, algorithm that was used during the
FAST_BSS_ authentication process.
TRANSITION, SAE
Content of FT Sequence of As defined in 13.8 The set of elements included in the
Authentication elements first message of the FT authentication
elements sequence, as described in 13.8.2.
Present if
dot11FastBSSTransitionActivated is
true; otherwise not present.
Content of SAE Sequence of As defined in 9.4.1.38, The set of elements to be included in
Authentication frame elements 9.4.1.39, 9.4.1.40, 9.4.1.41, the SAE Commit message or SAE
9.4.1.42, and 9.4.1.43 Confirm message. Present if
AuthenticationType indicates SAE
authentication; otherwise not present.
Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within the
element Multi-band element that identify the
local MAC entity. This parameter is
present if OCT is being used and is
absent otherwise.
282
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within the
element Multi-band element that are supported
by the remote (peer) MAC entity. This
parameter is present if OCT is being
used and is absent otherwise.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.5.4.3 When generated
This primitive is generated by the MLME as a result of the receipt of an authentication request from a
specific peer MAC entity.
6.3.5.4.4 Effect of receipt
The SME is notified of the receipt of the authentication request.
6.3.5.5 MLME-AUTHENTICATE.response
6.3.5.5.1 Function
This primitive is used to send a response to a specific peer MAC entity that requested authentication with the
STA that issued this primitive.
6.3.5.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-AUTHENTICATE.response(
PeerSTAAddress,
ResultCode,
Content of FT Authentication elements,
Content of SAE Authentication frame,
Multi-band local,
Multi-band peer,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC
MAC address entity from which the authentication
request was received.
ResultCode Enumeration SUCCESS, Indicates the result response to the
REFUSED, ANTI- authentication request from the peer
CLOGGING MAC entity.
TOKEN
REQUIRED,
FINITE CYCLIC
GROUP NOT
SUPPORTED,
AUTHENTICATIO
N REJECTED
Content of FT Sequence of elements As defined in 13.8 The set of elements to be included in the
Authentication second message of the FT authentication
elements sequence, as described in 13.8.3. Present
if dot11FastBSSTransitionActivated is
true; otherwise not present.
283
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Content of SAE Sequence of elements As defined in The set of elements to be included in the
Authentication frame 9.4.1.38, 9.4.1.39, SAE Commit message or SAE Confirm
9.4.1.40, 9.4.1.41, message. Present if the
9.4.1.42, and AuthenticationType of the MLME-
9.4.1.43 AUTHENTICATE.indication primitive
that generated this response indicated
SAE authentication; otherwise not
present.
Multi-band local Multi-band element As defined in Specifies the parameters within the Multi-
9.4.2.138 band element that are supported by the
local MAC entity. The parameter is
present if dot11MultibandImplemented is
true and is absent otherwise.
Multi-band peer Multi-band element As defined in Specifies the parameters within the Multi-
9.4.2.138 band element that identify the remote
(peer) MAC entity. This parameter is
present if OCT is being used and is absent
otherwise.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.5.5.3 When generated
This primitive is generated by the SME of a STA as a response to an MLME-AUTHENTICATE.indication
primitive.
6.3.5.5.4 Effect of receipt
This primitive initiates transmission of a response to the specific peer MAC entity that requested
authentication.
6.3.6 Deauthenticate
6.3.6.1 Introduction
This mechanism supports the process of invalidating an authentication relationship with a peer MAC entity.
6.3.6.2 MLME-DEAUTHENTICATE.request
6.3.6.2.1 Function
This primitive requests that the authentication relationship with a specified peer MAC entity be invalidated.
6.3.6.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DEAUTHENTICATE.request(
PeerSTAAddress,
ReasonCode,
VendorSpecificInfo
)
284
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC
MAC address entity with which to perform the
deauthentication process.
ReasonCode Reason Code field As defined in 9.4.1.7 Specifies the reason for initiating the
deauthentication procedure.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.6.2.3 When generated
This primitive is generated by the SME for a STA to invalidate authentication with a specified peer MAC
entity in order to prevent the exchange of Class 2 frames, or mesh peering Management frames for AMPE
utilizing SAE authentication, between the two STAs. During the deauthentication procedure, the SME might
generate additional MLME-DEAUTHENTICATE.request primitives.
6.3.6.2.4 Effect of receipt
This primitive initiates a deauthentication procedure. The MLME subsequently issues an MLME-
DEAUTHENTICATE.confirm primitive that reflects the results.
6.3.6.3 MLME-DEAUTHENTICATE.confirm
6.3.6.3.1 Function
This primitive reports the results of a deauthentication attempt with a specified peer MAC entity.
6.3.6.3.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-DEAUTHENTICATE.confirm(
PeerSTAAddress
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC
MAC address entity with which the deauthentication
process was attempted.
6.3.6.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-DEAUTHENTICATE.request primitive
to invalidate the authentication relationship with a specified peer MAC entity.
6.3.6.3.4 Effect of receipt
The SME is notified of the results of the deauthentication procedure.
6.3.6.4 MLME-DEAUTHENTICATE.indication
6.3.6.4.1 Function
This primitive reports the invalidation of an authentication relationship with a specific peer MAC entity.
285
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.6.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DEAUTHENTICATE.indication(
PeerSTAAddress,
ReasonCode,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC
MAC address entity with which the authentication
relationship was invalidated.
ReasonCode Reason Code field As defined in 9.4.1.7 Specifies the reason the deauthentication
procedure was initiated.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.6.4.3 When generated
This primitive is generated by the MLME as a result of the invalidation of an authentication relationship
with a specific peer MAC entity.
6.3.6.4.4 Effect of receipt
The SME is notified of the invalidation of the specific authentication relationship.
6.3.7 Associate
6.3.7.1 Introduction
The following primitives describe how a STA becomes associated with an AP.
6.3.7.2 MLME-ASSOCIATE.request
6.3.7.2.1 Function
This primitive requests association with a specified peer MAC entity that is within an AP.
6.3.7.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ASSOCIATE.request(
PeerSTAAddress,
ListenInterval,
Supported Channels,
RSN,
QoSCapability,
Content of FT Authentication elements,
SupportedOperatingClasses,
SM Power Save,
QoSTrafficCapability,
TIMBroadcastRequest,
EmergencyServices,
286
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DMG Capabilities,
Multi-band local,
Multi-band peer,
MMS,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC
MAC address entity with which to perform the
association process.
ListenInterval Integer 0 Specifies how often the STA awakens and
listens for the next Beacon frame, if it
enters power save mode.
Supported Channels As defined in the As defined in the The list of channels in which the STA is
Supported Channels Supported Channels capable of operating.
element element Present if DFS functionality is required,
as specified in 11.9; otherwise not
present.
RSN RSNE As defined in A description of the cipher suites and
9.4.2.25 AKM suites selected by the STA.
QoSCapability QoS Capability As defined in Specifies the parameters within the QoS
element 9.4.2.35 Capability element that are supported by
the MAC entity. The parameter is present
if dot11QosOptionImplemented is true;
otherwise not present.
Content of FT Sequence of elements As defined in 13.4 The set of elements to be included in the
Authentication initial mobility domain association
elements request, as described in 13.4. Present if
dot11FastBSSTransitionActivated is true;
otherwise not present.
SupportedOperating As defined in the As defined in Specifies the supported operating classes
Classes Supported Operating 9.4.2.54 capabilities of the STA. This parameter is
Classes element present if
dot11ExtendedChannelSwitchActivated
is true.
SM Power Save Integer As defined in Indicates the spatial multiplexing power
Table 9-162 save mode that is in operation
immediately after association.
QoS Traffic As defined in the As defined in Specifies the QoS Traffic Capability flags
Capability QoS Traffic 9.4.2.78 of the non-AP STA. This parameter is
Capability optionally present if
element dot11ACStationCountActivated is true
and is not present otherwise.
TIMBroadcastReque As defined in the As defined in Specifies the proposed service parameters
st TIM Broadcast 9.4.2.83 for TIM Broadcast. This parameter is
Request element optionally present if
dot11TIMBroadcastActivated is true and
is not present otherwise.
EmergencyServices Boolean true, false Specifies that the non-AP STA intends to
associate for the purpose of
unauthenticated access to emergency
services. The parameter is optionally be
present if
dot11InterworkingServiceActivated is
true and is not present otherwise.
287
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DMG Capabilities DMG Capabilities As defined in Specifies the parameters within the DMG
element 9.4.2.128 Capabilities element that are supported by
the MAC entity. The parameter is present
if dot11DMGOptionImplemented is true
and is absent otherwise.
Multi-band local Multi-band element As defined in Specifies the parameters within the Multi-
9.4.2.138 band element that are supported by the
local MAC entity. The parameter is
present if dot11MultibandImplemented is
true and is absent otherwise.
Multi-band peer Multi-band element As defined in Specifies the parameters within the Multi-
9.4.2.138 band element that identify the remote
(peer) MAC entity. The parameter is
present if OCT is being used and is absent
otherwise.
MMS Multiple MAC As defined in Specifies the parameters within the
Sublayers element 9.4.2.153 Multiple MAC Sublayers element that are
supported by the MAC entity. The
parameter is present if
dot11MultipleMACActivated is true and
is absent otherwise.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
Additional parameters needed to perform the association procedure are not included in the primitive
parameter list since the MLME already has that data (maintained as internal state).
6.3.7.2.3 When generated
This primitive is generated by the SME when a STA wishes to establish association with an AP or PCP.
6.3.7.2.4 Effect of receipt
This primitive initiates an association procedure. In the case that a response is received from the responder
STA, the MLME subsequently issues an MLME-ASSOCIATE.confirm primitive that reflects the results.
6.3.7.3 MLME-ASSOCIATE.confirm
6.3.7.3.1 Function
This primitive reports the results of an association attempt with a specified peer MAC entity that is in an AP
or PCP.
6.3.7.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ASSOCIATE.confirm(
ResultCode,
CapabilityInformation,
AssociationID,
EDCAParameterSet,
RCPI of Request,
RSNI of Request,
RCPI of Response,
RSNI of Response,
288
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RMEnabledCapabilities,
Content of FT Authentication elements,
SupportedOperatingClasses,
Extended Capabilities,
20/40 BSS Coexistence,
TimeoutInterval,
BSSMaxIdlePeriod,
TIMBroadcastResponse,
QosMapSet,
QMFPolicy,
DMG Capabilities,
Multi-band local,
Multi-band peer,
MMS,
VendorSpecificInfo
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates the result of the MLME-
REFUSED_REASON_UNSPECIFIED, ASSOCIATE.request primitive.
REFUSED_NOT_AUTHENTICATED,
REFUSED_CAPABILITIES_MISMATCH,
REFUSED_EXTERNAL_REASON,
REFUSED_AP_OUT_OF_MEMORY,
REFUSED_BASIC_RATES_MISMATCH,
REJECTED_EMERGENCY_SERVICES_
NOT_SUPPORTED,
REFUSED_TEMPORARILY
Capability- Capability As defined in 9.4.1.4 Specifies the operational
Information Information capabilities advertised by the AP
field or PCP.
AssociationID Integer Non-DMG: 1–2007 If the association request result
DMG: 1–254 was SUCCESS, then
AssociationID specifies the
association ID value assigned by
the AP or PCP.
EDCAParameter EDCA As defined in 9.4.2.29 Specifies the EDCA parameter set
Set Parameter Set that the STA should use. The
element parameter is present if
dot11QosOptionImplemented is
true; otherwise not present.
RCPI of Request Integer As defined in 9.4.2.38 Indicates the RCPI value
contained in the received
Association Response frame. This
value represents the RCPI that the
AP or PCP measured at the time it
received the corresponding
Association Request frame. The
element is optionally present if
dot11RMRCPIMeasurementActiv
ated is true; otherwise not present.
289
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
RSNI of Request Integer As defined in 9.4.2.41 Indicates the RSNI value
contained in the received
Association Response frame. This
value represents the RSNI that the
AP or PCP measured at the time it
received the corresponding
Association Request frame. The
element is optionally present if
dot11RMRSNIMeasurementActi
vated is true; otherwise not
present.
RCPI of Integer As defined in 9.4.2.38 The RCPI value represents the
Response measured RCPI of the
corresponding Association
Response frame. The element is
optionally present if
dot11RMRCPIMeasurementActiv
ated is true; otherwise not present.
RSNI of Integer As defined in 9.4.2.41 RSNI at the time the
Response corresponding Association
Response frame was receive. The
element is optionally present if
dot11RMRSNIMeasurementActi
vated is true; otherwise not
present.
RMEnabledCapa RM Enabled As defined in 9.4.2.45 Specifies the RM enabled
bilities Capabilities capabilities advertised by the AP
element or PCP. The element is present if
dot11RadioMeasurementActivate
d is true; otherwise not present.
Content of FT Sequence of As defined in 13.4 The set of elements included in
Authentication elements the initial mobility domain
elements association response, as described
in 13.4. Present if
dot11FastBSSTransitionActivated
is true; otherwise not present.
SupportedOperat As defined in As defined in 9.4.2.54 Specifies the supported operating
ingClasses the Supported classes capabilities of the STA.
Operating This parameter is present if
Classes dot11ExtendedChannelSwitchAct
element ivated is true; otherwise not
present.
Extended As defined in As defined in 9.4.2.27 Specifies the parameters within
Capabilities frame format the Extended Capabilities element
that are supported by the MAC
entity.
20/40 BSS As defined in As defined in 9.4.2.60 Specifies the parameters within
Coexistence frame format the 20/40 BSS Coexistence
element that are indicated by the
MAC entity.
The parameter is present if
dot112040BSSCoexistence-
ManagementSupport is true.
TimeoutInterval Timeout As defined in 9.4.2.49 This parameter is present when
Interval ResultCode is
element, as REFUSED_TEMPORARILY.
defined in
frame format
290
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
BSSMaxIdlePeri As defined in As defined in 9.4.2.79 Indicates the BSS max idle period
od BSS Max Idle parameters of the AP or PCP.
Period This parameter is present if
element dot11WirelessManagementImple
mented is true and is not present
otherwise.
TIMBroadcastRe As defined in As defined in 9.4.2.84 Specifies the service parameters
sponse TIM for TIM Broadcast. This
Broadcast parameter is optionally present if
Response dot11TIMBroadcastActivated is
element true and the TIM Broadcast
Request element is present in the
corresponding Association
Request frame; this parameter is
not present otherwise.
QoSMapSet As defined in As defined in 9.4.2.95 Specifies the QoS Map the non-
frame format AP and non-PCP STA should use.
QMFPolicy QMF Policy As defined in 9.4.2.120 The values from the QMF Policy
element element if such an element was
present in the Association
Response frame; otherwise, null.
DMG DMG As defined in 9.4.2.128 Specifies the parameters within
Capabilities Capabilities the DMG Capabilities element
element that are supported by the MAC
entity. The parameter is present if
dot11DMGOptionImplemented is
true and is absent otherwise.
Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within
element the Multi-band element that
identify the local MAC entity.
The parameter is present if OCT
is being used and is absent
otherwise.
Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within
element the Multi-band element that are
supported by the remote (peer)
MAC entity. This parameter is
present if OCT is being used and
is absent otherwise.
MMS Multiple As defined in 9.4.2.153 Specifies the parameters within
MAC the Multiple MAC Sublayers
Sublayers element that are supported by the
element MAC entity. The parameter is
present if
dot11MultipleMACActivated is
true and is absent otherwise.
VendorSpecificIn A set of As defined in 9.4.2.26 Zero or more elements.
fo elements
6.3.7.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-ASSOCIATE.request primitive or receipt
of an Association Response frame from the peer MAC entity to associate with a specified peer MAC entity
that is in an AP or PCP.
6.3.7.3.4 Effect of receipt
The SME is notified of the results of the association procedure.
291
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.7.4 MLME-ASSOCIATE.indication
6.3.7.4.1 Function
This primitive indicates that a specific peer MAC entity is requesting association with the local MAC entity,
which is in an AP or PCP.
6.3.7.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ASSOCIATE.indication(
PeerSTAAddress,
CapabilityInformation,
ListenInterval,
SSID,
OperationalRateSet,
BSSMembershipSelectorSet,
RSN,
QoSCapability,
RCPI,
RSNI,
RMEnabledCapabilities,
Content of FT Authentication elements,
SupportedOperatingClasses,
DSERegisteredLocation,
HT Capabilities,
Extended Capabilities,
20/40 BSS Coexistence,
QoSTrafficCapability,
TIMBroadcastRequest,
EmergencyServices,
DMG Capabilities,
Multi-band local,
Multi-band peer,
MMS,
VHT Capabilities,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC entity
MAC address from which the association was received.
Capability- Capability As defined in 9.4.1.4 Specifies the operational capability definitions
Information Information field provided by the peer MAC entity as part of the
association request.
ListenInterval Integer 0 Specifies the listen interval provided by the peer
MAC entity as part of the association request.
SSID Octet string 0–32 octets Specifies the SSID provided by the peer MAC
entity as part of the association request.
292
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
OperationalRateSet Non-DMG BSS: Non-DMG BSS: 1- The set of data rates (in units of 500 kb/s) that the
Set of integers 127 excluding values STA that is requesting association is able to use
from Table 9-78 for for communication within the BSS. The STA is
DMG BSS: Set of each member of the able to receive at each of the data rates listed in
numbers set the set. This set is a superset of the rates
contained in the BSSBasicRateSet parameter.
DMG BSS: 0-24,
9.1, or 12.1-12.6, for DMG BSS: The set of MCS indexes that the AP
each member of the or PCP uses for communication within the BSS.
set
BSSMembershipSel Set of integers A value from The set of features that the STA that is requesting
ectorSet Table 9-78, for each association is able to use for communication
member of the set
RSN RSNE As defined in A description of the cipher suites and AKM
9.4.2.25 suites selected by the STA.
QoSCapability QoS Capability As defined in Specifies the parameters within the
element 9.4.2.35 QoSCapability that are supported by the peer
MAC entity. The parameter is optionally present
if dot11QosOptionImplemented is true;
otherwise not present.
RCPI Integer As defined in The RCPI value represents the measured RCPI of
9.4.2.38 the corresponding Association Request frame.
The element is optionally present if
dot11RMRCPIMeasurementActivated is true;
otherwise not present.
RSNI Integer As defined in The RSNI value represents the measured RSNI at
9.4.2.41 the time the corresponding Association Request
frame was received. The element is optionally
present if dot11RMRSNIMeasurementActivated
is true; otherwise not present.
RMEnabledCapabil RM Enabled As defined in Specifies the RM enabled capabilities advertised
ities Capabilities 9.4.2.45 by the AP or PCP. The element is present if
element dot11RadioMeasurementActivated is true;
otherwise not present.
Content of FT Sequence of As defined in 13.4 The set of elements included in the initial
Authentication elements mobility domain association, as described in
elements 13.4. Present if
dot11FastBSSTransitionActivated is true;
otherwise not present.
SupportedOperating As defined in the As defined in Indicates the supported operating classes
Classes Supported 9.4.2.54 capabilities of the AP or PCP. This parameter is
Operating Classes present if
element dot11ExtendedChannelSwitchActivated is true;
otherwise not present.
DSERegisteredLoc As defined in the As defined in Indicates the DSE registered location including
ation DSE Registered 9.4.2.52 the dependent enablement identifier assigned by
Location element the enabling STA. This parameter is optionally
present if dot11LCIDSERequired is true;
otherwise not present.
HT Capabilities As defined in As defined in Specifies the parameters within the HT
frame format 9.4.2.56 Capabilities element that are supported by the
MAC entity.
The parameter is optionally present if
dot11HighThroughputOptionImplemented is
true; otherwise not present.
Extended As defined in As defined in Specifies the parameters within the Extended
Capabilities frame format 9.4.2.27 Capabilities element that are supported by the
MAC entity.
293
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
20/40 BSS As defined in As defined in Specifies the parameters within the 20/40 BSS
Coexistence frame format 9.4.2.60 Coexistence element that are indicated by the
MAC entity.
The parameter is present if
dot112040BSSCoexistenceManagementSupport
is true.
QoS Traffic As defined in the As defined in Specifies the QoS Traffic Capability flags of the
Capability QoS Traffic 9.4.2.78 non-AP and non-PCP STA. This parameter is
Capability element optionally present if
dot11ACStationCountActivated is true and is not
present otherwise.
TIMBroadcastRequ As defined in TIM As defined in Specifies the proposed service parameters for
est Broadcast Request 9.4.2.83 TIM Broadcast. This parameter is optionally
element present if dot11TIMBroadcastActivated is true
and is not present otherwise.
EmergencyServices Boolean true, false Specifies the setting of the UESA field received
from the non-AP and non-PCP STA, if an
Interworking element was present in the
Association Request frame. The parameter is
present if dot11InterworkingServiceActivated is
true; otherwise not present.
DMG Capabilities DMG Capabilities As defined in Specifies the parameters within the DMG
element 9.4.2.128 Capabilities element that are supported by the
MAC entity. The parameter is present if
dot11DMGOptionImplemented is true and is
absent otherwise.
Multi-band local Multi-band As defined in Specifies the parameters within the Multi-band
element 9.4.2.138 element that identify the local MAC entity. The
parameter is present if OCT is being used and is
absent otherwise.
Multi-band peer Multi-band As defined in Specifies the parameters within the Multi-band
element 9.4.2.138 element that are supported by the remote (peer)
MAC entity. This parameter is present if OCT is
being used and is absent otherwise.
MMS Multiple MAC As defined in Specifies the parameters within the Multiple
Sublayers element 9.4.2.153 MAC Sublayers element that are supported by
the MAC entity. The parameter is present if
dot11MultipleMACActivated is true and is
absent otherwise.
VHT Capabilities As defined in As defined in Specifies the parameters in the VHT Capabilities
VHT Capabilities 9.4.2.158 element that are supported by the STA. The
element parameter is present if
dot11VHTOptionImplemented is true and the
VHT Capabilities element is present in the
Association Request frame received from the
STA. The parameter is not present otherwise.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.7.4.3 When generated
This primitive is generated by the MLME as a result of the receipt of an association request from a specific
peer MAC entity.
6.3.7.4.4 Effect of receipt
The SME is notified of the receipt of the association request.
294
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.7.5 MLME-ASSOCIATE.response
6.3.7.5.1 Function
This primitive is used to send a response to a specific peer MAC entity that requested an association with the
STA that issued this primitive, which is in an AP or PCP.
6.3.7.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ASSOCIATE.response(
PeerSTAAddress,
ResultCode,
AssociationID,
RCPI,
RSNI,
RMEnabledCapabilities,
Content of FT Authentication elements,
SupportedOperatingClasses,
TimeoutInterval,
BSSMaxIdlePeriod,
TIMBroadcastResponse,
QoSMapSet,
Multi-band peer,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual MAC address Specifies the address of the
peer MAC entity from which
the association request was
received.
ResultCode Enumeration SUCCESS, Indicates the result response to
REFUSED_REASON_UNSPECIFIED, the association request from the
REFUSED_CAPABILITIES_MISMATC peer MAC entity.
H, REFUSED_EXTERNAL_REASON,
REFUSED_AP_OUT_OF_MEMORY,
REFUSED_BASIC_RATES_MISMATC
H,
REJECTED_EMERGENCY_SERVICE
S_NOT_SUPPORTED,
REFUSED_TEMPORARILY
AssociationID Integer Non-DMG: 1–2007 If the association request result
DMG: 1–254 was SUCCESS, then
AssociationID specifies the
association ID value assigned
to the peer MAC entity by the
AP or PCP.
RCPI Integer As defined in 9.4.2.38 The RCPI value represents the
measured RCPI of the
corresponding Association
Request frame. The element is
optionally present if
dot11RMRCPIMeasurementAc
tivated is true; otherwise not
present.
295
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
RSNI Integer As defined in 9.4.2.41 The RSNI value represents the
measured RSNI at the time the
corresponding Association
Request frame was received.
The element is optionally
present if
dot11RMRSNIMeasurementAc
tivated is true; otherwise not
present.
RMEnabledCapabil RM Enabled As defined in 9.4.2.45 Specifies the RM enabled
ities Capabilities capabilities advertised by the
element AP or PCP. The element is
present if
dot11RadioMeasurementActiv
ated is true; otherwise not
present.
Content of FT Sequence of As defined in 13.4 The set of elements to be
Authentication elements included in the initial mobility
elements domain association response, as
described in 13.4. Present if
dot11FastBSSTransitionActivat
ed is true; otherwise not
present.
SupportedOperating As defined in the As defined in 9.4.2.54 Indicates the supported
Classes Supported operating classes capabilities of
Operating the AP or PCP. This parameter
Classes element is present if
dot11ExtendedChannelSwitch
Activated is true.
TimeoutInterval Timeout Interval As defined in 9.4.2.49 This parameter is present when
element, as ResultCode is
defined in frame REFUSED_TEMPORARILY.
format
BSSMaxIdlePeriod As defined in As defined in 9.4.2.79 Indicates the BSS max idle
BSS Max Idle period parameters of the AP or
Period element PCP. This parameter is present
if
dot11WirelessManagementImp
lemented is true and is not
present otherwise.
TIMBroadcastResp As defined in As defined in 9.4.2.84 Specifies the service
onse TIM Broadcast parameters for TIM Broadcast.
Response This parameter is optionally
element present if
dot11TIMBroadcastActivated
is true and the TIM Broadcast
Request element is present in
the corresponding Association
Request frame; this parameter
is not present otherwise.
QoSMapSet As defined in As defined in 9.4.2.95 Specifies the QoS Map the non-
frame format AP and non-PCP STA should
use.
Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within
element the Multi-band element that
identify the remote (peer) MAC
entity. The parameter is present
if OCT is being used and is
absent otherwise.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
296
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Additional parameters needed to perform the association response procedure are not included in the
primitive parameter list since the MLME already has that data (maintained as internal state).
6.3.7.5.3 When generated
This primitive is generated by the SME of a STA that is in an AP or PCP as a response to an MLME-
ASSOCIATE.indication primitive.
6.3.7.5.4 Effect of receipt
This primitive initiates transmission of an AssociationResponse to the specific peer MAC entity that
requested association.
6.3.8 Reassociate
6.3.8.1 Introduction
The following primitives describe how a STA becomes associated with another AP or PCP.
6.3.8.2 MLME-REASSOCIATE.request
6.3.8.2.1 Function
This primitive requests a change in association to a specified new peer MAC entity that is in an AP or PCP.
6.3.8.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-REASSOCIATE.request(
NewPCPorAPAddress,
ListenInterval,
Supported Channels
RSN,
QoSCapability,
Content of FT Authentication elements,
SupportedOperatingClasses,
SM Power Save,
QoSTrafficCapability,
TIMBroadcastRequest,
FMSRequest,
DMSRequest,
EmergencyServices,
DMG Capabilities,
Multi-band local,
Multi-band peer,
MMS,
VendorSpecificInfo
)
297
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
NewPCPorAPAddr MACAddress Any valid individual Specifies the address of the peer MAC
ess MAC address entity with which to perform the
reassociation process.
ListenInterval Integer 0 Specifies how often the STA awakens and
listens for the next Beacon frame, if it
enters power save mode.
Supported Channels As defined in the As defined in the The list of channels in which the STA is
Supported Channels Supported Channels capable of operating.
element element Present if DFS functionality is required, as
specified in 11.9; otherwise not present.
RSN RSNE As defined in A description of the cipher suites and
9.4.2.25 AKM suites selected by the STA.
QoSCapability QoS Capability As defined in Specifies the parameters within the QoS
element 9.4.2.35 Capability element that are supported by
the MAC entity. The parameter is present if
dot11QosOptionImplemented is true;
otherwise not present.
Content of FT Sequence of elements As defined in 13.8 The set of elements to be included in the
Authentication third message of the FT authentication
elements sequence, as described in 13.8.4. Present if
dot11FastBSSTransitionActivated is true;
otherwise not present.
SupportedOperating As defined in the As defined in Specifies the supported operating classes
Classes Supported Operating 9.4.2.54 of the STA. This parameter is present if
Classes element dot11ExtendedChannelSwitchActivated is
true.
SM Power Save Integer As defined in Indicates the spatial multiplexing power
Table 9-162 save mode that is in operation immediately
after reassociation.
QoS Traffic As defined in the As defined in Specifies the QoS Traffic Capability flags
Capability QoS Traffic 9.4.2.78 of the non-AP and non-PCP STA. This
Capability element parameter is optionally present if
dot11ACStationCountActivated is true and
is not present otherwise.
TIMBroadcastRequ As defined in TIM As defined in Specifies the proposed service parameters
est Broadcast Request 9.4.2.83 for TIM Broadcast. This parameter is
element optionally present if
dot11TIMBroadcastActivated is true and is
not present otherwise.
FMSRequest As defined in FMS As defined in Specifies the proposed multicast
Request element 9.4.2.76 parameters for FMS Request. This
parameter is optionally present if
dot11FMSActivated is true and is not
present otherwise.
DMSRequest Sequence of DMS As defined in Specifies the proposed multicast
Request elements 9.4.2.88 parameters for DMS Request. This
parameter is optionally present if
dot11DMSActivated is true and is not
present otherwise.
EmergencyServices Boolean true, false Specifies that the non-AP and non-PCP
STA intends to reassociate for the purpose
of unauthenticated access to emergency
services. The parameter shall only be
present if
dot11InterworkingServiceActivated is true.
298
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DMG Capabilities DMG Capabilities As defined in Specifies the parameters within the DMG
element 9.4.2.128 Capabilities element that are supported by
the MAC entity. The parameter is present if
dot11DMGOptionImplemented is true and
is absent otherwise.
Multi-band local Multi-band element As defined in Specifies the parameters within the Multi-
9.4.2.138 band element that are supported by the
local MAC entity. The parameter is present
if dot11MultibandImplemented is true and
is absent otherwise.
Multi-band peer Multi-band element As defined in Specifies the parameters within the Multi-
9.4.2.138 band element that identify the remote
(peer) MAC entity. The parameter is
present if OCT is being used and is absent
otherwise.
MMS Multiple MAC As defined in Specifies the parameters within the
Sublayers element 9.4.2.153 Multiple MAC Sublayers element that are
supported by the MAC entity. The
parameter is present if
dot11MultipleMACActivated is true and is
absent otherwise.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
Additional parameters needed to perform the reassociation procedure are not included in the primitive
parameter list since the MLME already has that data (maintained as internal state).
6.3.8.2.3 When generated
This primitive is generated by the SME for a STA to change association to a specified new peer MAC entity
that is in an AP or PCP.
6.3.8.2.4 Effect of receipt
This primitive initiates a reassociation procedure. In the case that a response is received from the responder
STA, the MLME subsequently issues an MLME-REASSOCIATE.confirm primitive that reflects the results.
6.3.8.3 MLME-REASSOCIATE.confirm
6.3.8.3.1 Function
This primitive reports the results of a reassociation attempt with a specified peer MAC entity that is in an AP
or PCP.
6.3.8.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-REASSOCIATE.confirm(
ResultCode,
CapabilityInformation,
AssociationID,
EDCAParameterSet,
RCPI of Request,
RSNI of Request,
RCPI of Response,
299
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RSNI of Response,
RMEnabledCapabilities,
Content of FT Authentication elements,
SupportedOperatingClasses,
Extended Capabilities,
20/40 BSS Coexistence,
TimeoutInterval,
BSSMaxIdlePeriod,
TIMBroadcastResponse,
FMSResponse,
DMSResponse,
QoSMapSet,
QMFPolicy,
DMG Capabilities,
Multi-band local,
Multi-band peer,
MMS,
VendorSpecificInfo
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates the result of the MLME-
REFUSED_REASON_UNSPE REASSOCIATE.request primitive.
CIFIED,
REFUSED_NOT_AUTHENTI
CATED,
REFUSED_CAPABILITIES_M
ISMATCH,
REFUSED_EXTERNAL_REA
SON,
REFUSED_AP_OUT_OF_ME
MORY,
REFUSED_BASIC_RATES_MI
SMATCH,
REJECTED_EMERGENCY_S
ERVICES_NOT_SUPPORTED,
REFUSED_TEMPORARILY
Capability- Capability As defined in 9.4.1.4 Specifies the operational capabilities
Information Information advertised by the AP or PCP.
field
AssociationID Integer Non-DMG: 1–2007 If the association request result was
DMG: 1–254 SUCCESS, then AssociationID specifies
the association ID value assigned by the
AP or PCP.
EDCAParameterSet EDCA As defined in 9.4.2.29 Specifies the EDCA parameter set that
Parameter the STA should use. The parameter is
Set element present if dot11QosOptionImplemented
is true; otherwise not present.
RCPI of Request Integer As defined in 9.4.2.38 Indicates the RCPI value contained in the
received Reassociation Response frame.
This value represents the RCPI that the
AP or PCP measured at the time it
received the corresponding Reassociation
Request frame. The element is optionally
present if
dot11RMRCPIMeasurementActivated is
true; otherwise not present.
300
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
RSNI of Request Integer As defined in 9.4.2.41 Indicates the RSNI value contained in the
received Reassociation Response frame.
This value represents the RSNI that the
AP or PCP measured at the time it
received the corresponding Reassociation
Request frame. The element is optionally
present if
dot11RMRSNIMeasurementActivated is
true; otherwise not present.
RCPI of Response Integer As defined in 9.4.2.38 The RCPI value represents the measured
RCPI of the corresponding Reassociation
Response frame. The element is
optionally present if
dot11RMRCPIMeasurementActivated is
true; otherwise not present.
RSNI of Response Integer As defined in 9.4.2.41 RSNI at the time the corresponding
Reassociation Response frame was
received. The element is optionally
present if
dot11RMRSNIMeasurementActivated is
true; otherwise not present.
RMEnabledCapabil RM Enabled As defined in 9.4.2.45 Specifies the RM enabled capabilities
ities Capabilities advertised by the AP or PCP. The
element element is present if
dot11RadioMeasurementActivated is
true; otherwise not present.
Content of FT Sequence of As defined in 13.8 The set of elements included in the fourth
Authentication elements message of the FT authentication
elements sequence, as described in 13.8.5. This
includes an optional response to a
resource request (RIC). Present if
dot11FastBSSTransitionActivated is true;
otherwise not present.
SupportedOperating As defined in As defined in 9.4.2.54 Specifies the supported operating classes
Classes the of the STA. This parameter is present if
Supported dot11ExtendedChannelSwitchActivated
Operating is true; otherwise not present.
Classes
element
Extended As defined in As defined in 9.4.2.27 Specifies the parameters within the
Capabilities frame format Extended Capabilities element that are
supported by the MAC entity.
20/40 BSS As defined in As defined in 9.4.2.60 Specifies the parameters within the 20/40
Coexistence frame format BSS Coexistence element that are
indicated by the MAC entity.
The parameter is present if
dot112040BSSCoexistenceManagement
Support is true.
TimeoutInterval Timeout As defined in 9.4.2.49 This parameter is present when
Interval ResultCode is
element, as REFUSED_TEMPORARILY.
defined in
frame format
BSSMaxIdlePeriod As defined in As defined in 9.4.2.79 Indicates the BSS max idle period
BSS Max parameters of the AP or PCP. This
Idle Period parameter is present if
element dot11WirelessManagementImplemented
is true and is not present otherwise.
301
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
TIMBroadcastResp As defined in As defined in 9.4.2.84 Specifies the service parameters for TIM
onse TIM Broadcast. This parameter is optionally
Broadcast present if dot11TIMBroadcastActivated
Response is true and the TIM Broadcast Request
element element is present in the corresponding
Association Request frame; this
parameter is not present otherwise.
FMSResponse As defined in As defined in 9.4.2.77 Specifies the multicast parameters for
FMS FMS Response. This parameter is
Response optionally present if dot11FMSActivated
element is true and the FMS Request element is
present in the corresponding Association
Request frame; this parameter is not
present otherwise.
DMSResponse Sequence of As defined in 9.4.2.89 Specifies the multicast parameters for
DMS DMS Response. This parameter is
Response optionally present if dot11DMSActivated
elements is true and the DMS Request element is
present in the corresponding Association
Request frame; this parameter is not
present otherwise.
QoSMapSet As defined in As defined in 9.4.2.95 Specifies the QoS Map the non-AP and
frame format non-PCP STA should use.
QMFPolicy QMF Policy As defined in 9.4.2.120 Describes the QMF policy of the AP. This
element parameter is present when
dot11QMFActivated is true and is not
present otherwise.
DMG Capabilities DMG As defined in 9.4.2.128 Specifies the parameters within the DMG
Capabilities Capabilities element that are supported
element by the MAC entity. The parameter is
present if dot11DMGOptionImplemented
is true and is absent otherwise.
Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within the
element Multi-band element that identify the local
MAC entity. The parameter is present if
OCT is being used and is absent
otherwise.
Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within the
element Multi-band element that are supported by
the remote (peer) MAC entity. This
parameter is present if OCT is being used
and is absent otherwise.
MMS Multiple As defined in 9.4.2.153 Specifies the parameters within the
MAC Multiple MAC Sublayers element that
Sublayers are supported by the MAC entity. The
element parameter is present if
dot11MultipleMACActivated is true and
is absent otherwise.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.8.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-REASSOCIATE.request primitive to
reassociate with a specified peer MAC entity that is in an AP or PCP.
302
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.8.3.4 Effect of receipt
The SME is notified of the results of the reassociation procedure.
6.3.8.4 MLME-REASSOCIATE.indication
6.3.8.4.1 Function
This primitive indicates that a specific peer MAC entity is requesting reassociation with the local MAC
entity, which is in an AP or PCP.
6.3.8.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-REASSOCIATE.indication(
PeerSTAAddress,
CurrentAPAddress,
CapabilityInformation,
ListenInterval,
SSID,
OperationalRateSet,
BSSMembershipSelectorSet,
RSN,
QoSCapability,
RCPI,
RSNI,
RMEnabledCapabilities,
Content of FT Authentication elements,
SupportedOperatingClasses,
DSERegisteredLocation,
HT Capabilities,
Extended Capabilities,
20/40 BSS Coexistence,
QoSTrafficCapability,
TIMBroadcastRequest,
FMSRequest,
DMSRequest,
EmergencyServices,
DMG Capabilities,
Multi-band local,
Multi-band peer,
MMS,
VHT Capabilities,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC
MAC address entity from which the reassociation request
was received.
CurrentAPAddress MACAddress Any valid individual Specifies the address of the AP or PCP with
MAC address which the peer STA is currently associated.
303
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Capability- Capability As defined in 9.4.1.4 Specifies the operational capability
Information Information field definitions provided by the peer MAC
entity as part of the reassociation
request.
ListenInterval Integer 0 Specifies the listen interval provided by the
peer MAC entity as part of the reassociation
request.
SSID Octet string 0–32 octets Specifies the desired SSID provided by the
peer MAC entity as part of the reassociation
request.
OperationalRateSet Non-DMG BSS: Set Non-DMG BSS: 1- The set of data rates (in units of 500 kb/s)
of integers 127 excluding values that the STA that is requesting association is
from Table 9-78 for able to use for communication within the
DMG BSS: Set of each member of the BSS. The STA is able to receive at each of
numbers set the data rates listed in the set. This set is a
superset of the rates contained in the
DMG BSS: 0-24, BSSBasicRateSet parameter.
9.1, or 12.1-12.6, for
each member of the DMG BSS: The set of MCS indexes that the
set AP or PCP uses for communication within
the BSS.
BSSMembershipSe Set of integers A value from The set of features that the STA that is
lectorSet Table 9-78, for each requesting association is able to use for
member of the set communication
RSN RSNE As defined in A description of the cipher suites and AKM
9.4.2.25 suites selected by the STA.
QoSCapability QoS Capability As defined in Specifies the parameters within the QoS
element 9.4.2.35 Capability that are supported by the peer
MAC entity. The parameter is present if
dot11QosOptionImplemented is true;
otherwise not present.
RCPI Integer As defined in The RCPI value represents the measured
9.4.2.38 RCPI of the corresponding Reassociation
Request frame. The element is optionally
present if
dot11RMRCPIMeasurementActivated is
true; otherwise not present.
RSNI Integer As defined in The RSNI value represents the measured
9.4.2.41 RSNI at the time the corresponding
Reassociation Request frame was received.
The element is optionally present if
dot11RMRSNIMeasurementActivated is
true; otherwise not present.
RMEnabledCapabi RM Enabled As defined in Specifies the RM enabled capabilities
lities Capabilities element 9.4.2.45 advertised by the AP or PCP. The element
is present if
dot11RadioMeasurementActivated is true;
otherwise not present.
Content of FT Sequence of elements As defined in 13.8 The set of elements included in the third
Authentication message of the FT authentication sequence,
elements as described in 13.8.4. Present if
dot11FastBSSTransitionActivated is true;
otherwise not present.
SupportedOperatin As defined in the As defined in Specifies the supported operating classes of
gClasses Supported Operating 9.4.2.54 the STA. This parameter is present if
Classes element dot11ExtendedChannelSwitchActivated is
true; otherwise not present.
304
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DSERegisteredLoc As defined in the As defined in Indicates the DSE registered location
ation DSE Registered 9.4.2.52 including the dependent enablement
Location element identifier assigned by the enabling STA.
This parameter is optionally present if
dot11LCIDSERequired is true; otherwise
not present.
HT Capabilities As defined in frame As defined in Specifies the parameters within the HT
format 9.4.2.56 Capabilities element that are supported by
the MAC entity.
The parameter is optionally present if
dot11HighThroughputOptionImplemented
is true.
Extended As defined in frame As defined in Specifies the parameters within the
Capabilities format 9.4.2.27 Extended Capabilities element that are
supported by the MAC entity.
20/40 BSS As defined in frame As defined in Specifies the parameters within the 20/40
Coexistence format 9.4.2.60 BSS Coexistence element that are indicated
by the MAC entity.
The parameter is present if
dot112040BSSCoexistenceManagementSu
pport is true.
QoS Traffic As defined in the As defined in Specifies the QoS Traffic Capability flags
Capability QoS Traffic 9.4.2.78 of the non-AP and non-PCP STA. This
Capability element parameter is optionally present if
dot11ACStationCountActivated is true and
is not present otherwise.
TIMBroadcastReq As defined in TIM As defined in Specifies the proposed service parameters
uest Broadcast Request 9.4.2.83 for TIM Broadcast. This parameter is
element optionally present if
dot11TIMBroadcastActivated is true and is
not present otherwise.
FMSRequest As defined in FMS As defined in Specifies the proposed multicast parameters
Request element 9.4.2.76 for FMS Request. This parameter is
optionally present if dot11FMSActivated is
true and is not present otherwise.
DMSRequest Sequence of DMS As defined in Specifies the proposed multicast parameters
Request elements 9.4.2.88 for DMS Request. This parameter is
optionally present if dot11DMSActivated is
true and is not present otherwise.
EmergencyService Boolean true, false Specifies the setting of the UESA field
s received from the non-AP and non-PCP
STA, if an Interworking element was
present in the Reassociation Request frame.
The parameter is present if
dot11InterworkingServiceActivated is true;
otherwise not present.
DMG Capabilities DMG Capabilities As defined in Specifies the parameters within the DMG
element 9.4.2.128 Capabilities element that are supported by
the MAC entity. The parameter is present if
dot11DMGOptionImplemented is true and
is absent otherwise.
Multi-band local Multi-band element As defined in Specifies the parameters within the Multi-
9.4.2.138 band element that identify the local MAC
entity. The parameter is present if
dot11MultibandImplemented is true and is
absent otherwise.
305
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Multi-band peer Multi-band element As defined in Specifies the parameters within the Multi-
9.4.2.138 band element that are supported by the
remote (peer) MAC entity. This parameter
is present if OCT is being used and is absent
otherwise.
MMS Multiple MAC As defined in Specifies the parameters within the
Sublayers element 9.4.2.153 Multiple MAC Sublayers element that are
supported by the MAC entity. The
parameter is present if
dot11MultipleMACActivated is true and is
absent otherwise.
VHT Capabilities As defined in VHT As defined in Specifies the parameters in the VHT
Capabilities element 9.4.2.158 Capabilities element that are supported by
the STA. The parameter is present if
dot11VHTOptionImplemented is true and
the VHT Capabilities element is present in
the Reassociation Request frame received
from the STA. The parameter is not present
otherwise.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.8.4.3 When generated
This primitive is generated by the MLME as a result of the establishment of a reassociation with a specific
peer MAC entity that resulted from a reassociation procedure that was initiated by that specific peer MAC
entity.
6.3.8.4.4 Effect of receipt
The SME is notified of the establishment of the reassociation.
6.3.8.5 MLME-REASSOCIATE.response
6.3.8.5.1 Function
This primitive is used to send a response to a specific peer MAC entity that requested a reassociation with
the STA that issued this primitive, which is in an AP or PCP.
6.3.8.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-REASSOCIATE.response(
PeerSTAAddress,
ResultCode,
AssociationID,
RCPI,
RSNI,
RMEnabledCapabilities,
Content of FT Authentication elements,
SupportedOperatingClasses,
TimeoutInterval,
BSSMaxIdlePeriod,
TIMBroadcastResponse,
FMSResponse,
306
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DMSResponse,
QoSMapSet,
Multi-band peer,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual MAC address Specifies the address of the
peer MAC entity from which
the reassociation request was
received.
ResultCode Enumeration SUCCESS, Indicates the result response to
REFUSED_REASON_UNSPECIFIED, the reassociation request from
REFUSED_CAPABILITIES_MISMATC the peer MAC entity.
H, REFUSED_EXTERNAL_REASON,
REFUSED_AP_OUT_OF_MEMORY,
REFUSED_BASIC_RATES_MISMATC
H
REJECTED_EMERGENCY_SERVICE
S_NOT_SUPPORTED,
REFUSED_TEMPORARILY
AssociationID Integer Non-DMG: 1–2007 If the reassociation request
DMG: 1–254 result was SUCCESS, then
AssociationID specifies the
association ID value assigned
to the peer MAC entity by the
AP or PCP.
RCPI Integer As defined in 9.4.2.38 The RCPI value represents the
measured RCPI of the
corresponding Reassociation
Request frame. The
element is optionally present if
dot11RMRCPIMeasurementAc
tivated is true; otherwise not
present.
RSNI Integer As defined in 9.4.2.41 The RSNI value represents the
measured RSNI at the time the
corresponding Reassociation
Request frame was received.
The element is optionally
present if
dot11RMRSNIMeasurementAc
tivated is true; otherwise not
present.
RMEnabledCapabil RM Enabled As defined in 9.4.2.45 Specifies the RM enabled
ities Capabilities capabilities advertised by the
element AP or PCP. The element is
present if
dot11RadioMeasurementActiv
ated is true; otherwise not
present.
Content of FT Sequence of As defined in 13.8 The set of elements to be
Authentication elements included in the fourth message
elements of the FT authentication
sequence, as described in
13.8.5. This includes an
optional response to a resource
request (RIC). Present if
dot11FastBSSTransitionActivat
ed is true; otherwise not
present.
307
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
SupportedOperating As defined in As defined in 9.4.2.54 Specifies the supported
Classes the Supported operating classes of the STA.
Operating This parameter is present if
Classes dot11ExtendedChannelSwitch
element Activated is true.
TimeoutInterval Timeout As defined in 9.4.2.49 This parameter is present when
Interval ResultCode is
element, as REFUSED_TEMPORARILY.
defined in
frame format
BSSMaxIdlePeriod As defined in As defined in 9.4.2.79 Indicates the BSS max idle
BSS Max Idle period parameters of the AP or
Period PCP. This parameter is present
element if
dot11WirelessManagementImp
lemented is true and is not
present otherwise.
TIMBroadcastResp As defined in As defined in 9.4.2.84 Specifies the service
onse TIM parameters for TIM Broadcast.
Broadcast This parameter is optionally
Response present if
element dot11TIMBroadcastActivated
is true and the TIM Broadcast
Request element is present in
the corresponding Association
Request frame; this parameter
is not present otherwise.
FMSResponse As defined in As defined in 9.4.2.77 Specifies the multicast
FMS parameters for FMS Response.
Response This parameter is optionally
element present if dot11FMSActivated
is true and the FMS Request
element is present in the
corresponding Association
Request frame; this parameter
is not present otherwise.
DMSResponse Sequence of As defined in 9.4.2.89 Specifies the multicast
DMS parameters for DMS Response.
Response This parameter is optionally
elements present if dot11DMSActivated
is true and the DMS Request
element is present in the
corresponding Association
Request frame; this parameter
is not present otherwise.
QoSMapSet As defined in As defined in 9.4.2.95 Specifies the QoS Map the non-
frame format AP and non-PCP STA should
use.
Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within
element the Multi-band element that
identify the remote (peer) MAC
entity. The parameter is present
if OCT is being used and is
absent otherwise.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
Additional parameters needed to perform the reassociation response procedure are not included in the
primitive parameter list since the MLME already has that data (maintained as internal state).
308
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.8.5.3 When generated
This primitive is generated by the SME of a STA that is in an AP or PCP as a response to an MLME-
REASSOCIATE.indication primitive.
6.3.8.5.4 Effect of receipt
This primitive initiates transmission of a response to the specific peer MAC entity that requested
reassociation.
6.3.9 Disassociate
6.3.9.1 MLME-DISASSOCIATE.request
6.3.9.1.1 Function
This primitive requests disassociation with a specified peer MAC entity.
6.3.9.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DISASSOCIATE.request(
PeerSTAAddress,
ReasonCode,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC
MAC address entity with which to perform the
disassociation process.
ReasonCode Reason Code field As defined in 9.4.1.7 Specifies the reason for initiating the
disassociation procedure.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.9.1.3 When generated
This primitive is generated by the SME for a STA to disassociate from a STA with which it has an
association.
6.3.9.1.4 Effect of receipt
This primitive initiates a disassociation procedure. The MLME subsequently issues an
MLME-DISASSOCIATE.confirm primitive that reflects the results.
6.3.9.2 MLME-DISASSOCIATE.confirm
6.3.9.2.1 Function
This primitive reports the results of a disassociation procedure with a specific peer MAC entity.
309
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.9.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DISASSOCIATE.confirm()
6.3.9.2.3 When generated
This primitive is generated by the MLME as a result of an MLME-DISASSOCIATE.request primitive to
disassociate with a specified peer MAC entity.
6.3.9.2.4 Effect of receipt
The SME is notified of the results of the disassociation procedure.
6.3.9.3 MLME-DISASSOCIATE.indication
6.3.9.3.1 Function
This primitive reports disassociation with a specific peer MAC entity.
6.3.9.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DISASSOCIATE.indication(
PeerSTAAddress,
ReasonCode,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC
MAC address entity with which the association
relationship was invalidated.
ReasonCode Reason Code field As defined in Specifies the reason the disassociation
9.4.1.7 procedure was initiated.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.9.3.3 When generated
This primitive is generated by the MLME as a result of the invalidation of an association relationship with a
specific peer MAC entity.
6.3.9.3.4 Effect of receipt
The SME is notified of the invalidation of the specific association relationship.
6.3.10 Reset
6.3.10.1 Introduction
This mechanism supports the process of resetting the MAC.
310
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.10.2 MLME-RESET.request
6.3.10.2.1 Function
This primitive requests that the MAC entity be reset.
6.3.10.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RESET.request(
STAAddress,
SetDefaultMIB
)
Name Type Valid range Description
STAAddress MACAddress Any valid individual Specifies the MAC address that is to be used by the
MAC address MAC entity that is being reset. This value can be
used to provide a locally administered STA address.
SetDefaultMIB Boolean true, false If true, all MIB attributes are set to their default
values. The default values are implementation
dependent.
If false, the MAC is reset, but all MIB attributes
retain the values that were in place prior to the
generation of the MLME-RESET.request primitive.
6.3.10.2.3 When generated
This primitive is generated by the SME to reset the MAC to initial conditions. The MLME-RESET.request
primitive shall be used prior to use of the MLME-START.request primitive.
6.3.10.2.4 Effect of receipt
This primitive sets the MAC to initial conditions, clearing all internal variables to the default values. MIB
attributes can be reset to their implementation dependent default values by setting the SetDefaultMIB flag to
true.
If dot11OCBActivated is true and if the SetDefaultMIB parameter is false, MAC operation shall resume in
less than 2 TU after the STAAddress parameter is changed.
6.3.11 Start
6.3.11.1 Introduction
This mechanism supports the process of creating a new BSS or becoming a member of an MBSS.
6.3.11.2 MLME-START.request
6.3.11.2.1 Function
This primitive requests that the MAC entity start a new BSS or become a member of an MBSS.
6.3.11.2.2 Semantics of the service primitive
The primitive parameters are as follows:
311
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-START.request(
SSID,
BSSType,
BeaconPeriod,
DTIMPeriod,
CF parameter set,
PHY parameter set,
IBSS parameter set,
NAVSyncDelay,
CapabilityInformation,
BSSBasicRateSet,
OperationalRateSet,
Country,
IBSS DFS Recovery Interval,
EDCAParameterSet,
DSERegisteredLocation,
HT Capabilities,
HT Operation,
BSSMembershipSelectorSet,
Extended Capabilities,
20/40 BSS Coexistence,
Overlapping BSS Scan Parameters,
MultipleBSSID,
InterworkingInfo,
AdvertisementProtocolInfo,
RoamingConsortiumInfo,
Mesh ID,
Mesh Configuration,
QMFPolicy,
DMG Capabilities,
Multi-band,
MMS,
DMG Operation,
Clustering Control,
CBAP Only,
PCP Association Ready,
VHT Capabilities,
VHT Operation,
VendorSpecificInfo
)
Name Type Valid range Description
SSID Octet string 0–32 octets The SSID of the BSS.
BSSType Enumeration INFRASTRUCTURE, The type of the BSS.
INDEPENDENT,
MESH, PERSONAL
Beacon Period Integer 1 The beacon period (in TU) of the BSS if the
BSSType is not MESH, or of the mesh STA
if the BSSType is MESH.
DTIM Period Integer As defined in 9.4.2.6 The DTIM Period (in beacon periods) of the
BSS if the BSSType is not MESH, or of the
mesh STA if the BSSType is MESH.
CF parameter set CF Parameter As defined in 9.4.2.5 The parameter set for CF periods, if the BSS
Set element supports CF mode.
312
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PHY parameter sets DSSS As defined in 9.4.2.4 The parameter sets relevant to the PHY.
Parameter Set
element
IBSS parameter set IBSS As defined in 9.4.2.7 The parameter set for the IBSS, if BSS is an
Parameter Set IBSS.
element
NAVSyncDelay Integer N/A Delay (in microseconds) to be used, while
the STA is a member of this BSS, prior to
transmitting when changing from doze to
awake state, if no frame is detected by which
the NAV can be set.
CapabilityInformation Capability As defined in 9.4.1.4 The capabilities to be advertised for the BSS.
Information
field
BSSBasicRateSet Set of integers Non-DMG BSS: a value Non-DMG BSS: The set of data rates (in
in both units of 500 kb/s) that all STAs in the BSS
dot11SupportedDataRat are able to use for communication. All STAs
esRxTable and in the BSS including the STA that is creating
dot11SupportedDataRat the BSS, are able to receive and transmit at
esTxTable for each each of the data rates listed in the set.
member of the set
DMG BSS: Empty.
OperationalRateSet Non-DMG Non-DMG BSS: a value Non-DMG BSS: The set of data rates (in
BSS: Set of in units of 500 kb/s) that the STA is able to use
integers dot11SupportedDataRat for communication within the BSS. The STA
esRxTable for each is able to receive at each of the data rates
DMG BSS: member of the set listed in the set. This set is a superset of the
Set of numbers rates contained in the BSSBasicRateSet
DMG BSS: 0-24, 9.1, or parameter.
12.1-12.6, for each
member of the set DMG BSS: The set of MCS indexes that the
STA uses for communication within the BSS.
Country As defined in As defined in the The information required to identify the
the Country Country element regulatory domain in which the STA is
element located and to configure its PHY for
operation in that regulatory domain.
Present if TPC functionality is required, as
specified in 11.8 or
dot11MultiDomainCapabilityActivated is
true; otherwise not present.
IBSS DFS Recovery Integer 1–255 The time interval that is used for DFS
Interval recovery.
Present if DFS functionality is required, as
specified in 11.9 and BSSType =
INDEPENDENT; otherwise not present.
EDCAParameterSet EDCA As defined in 9.4.2.29 The initial EDCA parameter set values to be
(QoS only) Parameter Set used in the BSS. The parameter is present if
element dot11QosOptionImplemented is true;
otherwise not present.
DSERegisteredLocati As defined in As defined in 9.4.2.52 The information for the DSE Registered
on the DSE Location element. The parameter is present if
Registered dot11LCIDSERequired is true.
Location
element
313
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
HT Capabilities As defined in As defined in 9.4.2.56; The HT capabilities to be advertised for the
frame format the HT-MCSs in the BSS. The parameter is present if
HT element are present in dot11HighThroughputOptionImplemented is
Capabilities dot11SupportedMCSRx true; otherwise, this parameter is not present.
element Table and the highest
supported data rate in
the element does not
exceed
dot11HighestSupported
DataRate
HT Operation As defined in As defined in 9.4.2.57; The additional HT capabilities to be
frame format the HT-MCSs in the advertised for the BSS.
HT Operation element are present in The parameter is present if
element both dot11HighThroughputOptionImplemented is
dot11SupportedMCSRx true; otherwise, this parameter is not present.
Table and
dot11SupportedMCSTx
Table
BSSMembershipSelec Set of integers A value from Table 9- The set of features that are supported by all
torSet 78 for each member of STAs joining this BSS, and by the STA that
the set is creating the BSS.
Extended Capabilities As defined in As defined in 9.4.2.27 Specifies the parameters within the Extended
frame format Capabilities element that are supported by
the MAC entity.
20/40 BSS As defined in As defined in 9.4.2.60 Specifies the parameters within the 20/40
Coexistence frame format BSS Coexistence element that are indicated
by the MAC entity.
The parameter is present if
dot112040BSSCoexistence-
ManagementSupport is true.
Overlapping BSS As defined in As defined in 9.4.2.59 Specifies the parameters within the
Scan Parameters frame format Overlapping BSS Scan Parameters element
that are indicated by the MAC entity.
This parameter is optionally present if
dot11FortyMHzOptionImplemented is true;
otherwise, it is not present.
MultipleBSSID As defined in As defined in Multiple This element is optionally present when
Multiple BSSID Element in dot11RMMeasurementPilotActivated is a
BSSID 9.4.2.46 value between 2 and 7 and the AP is a
Element in member of a multiple BSSID set (see
9.4.2.46 11.11.14) with two or more members, or if
dot11MultiBSSIDActivated is true.
InterworkingInfo As defined in As defined in Specifies the Interworking capabilities of
frame format Interworking element in STA. This field is present when
9.4.2.92 dot11InterworkingServiceActivated is true.
AdvertisementProtoco Integer or As defined in Identifies zero or more Advertisement
lInfo Sequence of Advertisement Protocol Protocols and advertisement control to be
integers element in Table 9-215 used in the BSSs. This field is present when
dot11InterworkingServiceActivated is true.
RoamingConsortiumI As defined in As defined in roaming Specifies identifying information for SSPs
nfo frame format consortium element in whose security credentials can be used to
9.4.2.96 authenticate with the AP. This field is
optionally present when
dot11InterworkingServiceActivated is true.
Mesh ID Octet string 0–32 octets The value of MeshID. This element is
present if the BSSType = MESH; otherwise
not present.
314
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Mesh As defined in As defined in 9.4.2.98 Specifies the configuration of the mesh STA.
Configuration frame format This element is present if the BSSType =
MESH; otherwise not present.
QMFPolicy QMF Policy As defined in 9.4.2.120 This element is present when
element dot11QMFActivated is true and BSSType =
INFRASTRUCTURE or MESH, and it is not
present otherwise. The element is provided
by the SME to signal to the MLME the QMF
policy to be used for this BSS.
DMG Capabilities DMG As defined in 9.4.2.128 Specifies the parameters within the DMG
Capabilities Capabilities element that are supported by
element the MAC entity.
The parameter is present if
dot11DMGOptionImplemented is true and is
absent otherwise.
Multi-band Multi-band As defined in 9.4.2.138 Specifies the parameters within the Multi-
element band element that are supported by the MAC
entity.
The parameter is present if
dot11MultibandImplemented is true and is
absent otherwise.
MMS Multiple MAC As defined in 9.4.2.153 Specifies the parameters within the Multiple
Sublayers MAC Sublayers element that are supported
element by the MAC entity.
The parameter is present if
dot11MultipleMACActivated is true and is
absent otherwise.
DMG Operation DMG As defined in 9.4.2.128 Specifies the parameters within the DMG
Operation Operation element that are supported by the
element MAC entity.
The parameter is present if
dot11DMGOptionImplemented is true and is
absent otherwise.
Clustering Control Clustering As defined in 9.3.4.2 Specifies the parameters within the
Control field Clustering Control field that are supported by
the MAC entity.
The parameter is present if
dot11ClusteringActivated is true and is
absent otherwise.
CBAP Only Integer 0 or 1 Specifies the setting of the CBAP Only field
as defined in 9.3.4.2
PCP Association Integer 0 or 1 Specifies the setting of the PCP Association
Ready Ready field as defined in 9.3.4.2
VHT Capabilities As defined in As defined in 9.4.2.158; Specifies the parameters in the VHT
VHT the VHT-MCSs in the Capabilities element that are supported by
Capabilities element are present in the STA. The parameter is present if
element dot11VHTRxVHTMCS dot11VHTOptionImplemented is true and
Map/ not present otherwise.
dot11VHTTxVHTMCS
Map and the highest
supported data rates in
the element do not
exceed
dot11VHTRxHighestDa
taRateSupported/
dot11VHTTxHighestDa
taRateSupported
315
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
VHT Operation As defined in As defined in 9.4.2.159; Provides additional information for operating
VHT the VHT-MCSs in the the VHT BSS. The parameter is present if
Operation element are present in dot11VHTOptionImplemented is true and
element both not present otherwise.
dot11VHTRxVHTMCS
Map and
dot11VHTTxVHTMCS
Map
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.11.2.3 When generated
This primitive is generated by the SME to start an infrastructure BSS (with the MAC entity within an AP),
an IBSS (with the MAC entity acting as the first STA in the IBSS), or an MBSS (with the MAC entity acting
as the first mesh STA in the MBSS) or to become a member of an existing MBSS or a PBSS (with the MAC
entity within a PCP). In an MBSS, this primitive starts the process of mesh beaconing.
The MLME-START.request primitive in an MBSS shall be generated before any synchronization or mesh
peering have been attempted.
The MLME-START.request primitive shall not be used after successful use of the MLME-START.request
primitive or successful use of the MLME-JOIN.request primitive without generating an intervening MLME-
RESET.request primitive.
6.3.11.2.4 Effect of receipt
This primitive initiates the BSS initialization procedure once the current frame exchange sequence is
complete. The MLME subsequently issues an MLME-START.confirm primitive that reflects the results of
the creation procedure.
If the MLME of a non-DMG STA receives an MLME-START.request primitive with a BSSBasicRateSet
parameter containing any unsupported rates, the MLME response in the resulting MLME-START.confirm
primitive shall contain a ResultCode parameter that is not set to the value SUCCESS.
If the MLME of an HT STA receives an MLME-START.request primitive with the Basic HT-MCS Set field
of the HT Operation parameter containing any unsupported MCSs, the MLME response in the resulting
MLME-START.confirm primitive shall contain a ResultCode parameter that is not set to the value
SUCCESS.
If the MLME of a VHT STA receives an MLME-START.request primitive with a Basic VHT-MCS And
NSS Set field in the VHT Operation parameter containing any unsupported tuple, the
MLME response in the resulting MLME-START.confirm primitive shall contain a ResultCode parameter
that is not set to the value SUCCESS.
If the MLME of a DMG STA receives an MLME-START.request primitive with a BSSBasicRateSet
parameter containing any rates, or with the OperationalRateSet parameter containing any unsupported
MCSs, the MLME response in the resulting MLME-START.confirm primitive shall contain a ResultCode
parameter that is not set to the value SUCCESS.
316
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.11.3 MLME-START.confirm
6.3.11.3.1 Function
This primitive reports the results of a BSS creation procedure or a procedure to become a member of an
MBSS.
6.3.11.3.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-START.confirm(
ResultCode
)
Name Type Valid range resetDescription
ResultCode Enumeration SUCCESS, Indicates the result of the
BSS_ALREADY_STARTED_OR_JOINED, MLME-START.request
RESET_REQUIRED_BEFORE_ START, primitive.
NOT_SUPPORTED
6.3.11.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-START.request primitive to create a new
BSS or to become a member of an MBSS.
6.3.11.3.4 Effect of receipt
The SME is notified of the results of the BSS creation procedure or a procedure to become a member of an
MBSS.
6.3.12 Stop
6.3.12.1 General
This mechanism supports the process of terminating an existing BSS.
6.3.12.2 MLME-STOP.request
6.3.12.2.1 Function
This primitive requests that the MAC entity stop a BSS previously started by using an MLME-
START.request primitive
6.3.12.2.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-STOP.request(
SSID
)
Name Type Valid range Description
SSID Octet string 0–32 octets The SSID of the BSS to be stopped.
317
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.12.2.3 When generated
This primitive is generated by the SME to terminate an infrastructure BSS (with the MAC entity within an
AP) or a PBSS (with the MAC entity within the PCP). The MLME-STOP.request primitive shall be
generated only after successful use of an MLME-START.confirm primitive.
The MLME-STOP termination procedure does not reset the MAC to initial conditions. An MLME-
RESET.request primitive shall be issued prior to use of the MLME-START.request primitive and
subsequent to the use of an MLME-STOP.request primitive.
The SME should notify associated non-AP STAs of imminent infrastructure BSS termination before issuing
the MLME-STOP.request primitive. This can be done with the BSS transition management procedure, using
the Termination information.
6.3.12.2.4 Effect of receipt
This primitive initiates the termination of the BSS. All services provided by the AP to an infrastructure BSS,
including Beacon and Probe Response frame transmissions and access to the DS, are stopped by the
termination. All STAs in an infrastructure BSS are deauthenticated by the termination. In a PBSS, all of the
services provided by the PCP, including DMG Beacons, are stopped by the termination. All of the STAs in a
PBSS have their RSNA unestablished by the termination.
6.3.13 Protocol layer model for spectrum management and radio measurement
The layer management extensions for measurement, TPC, and channel switching assume a certain partition
of functionality between the MLME and SME. This partitioning assumes that policy decisions (e.g.,
regarding measurement and channel switching) reside in the SME, while the protocol for measurement,
switch timing, and the associated frame exchanges resides within the MLME (see Figure 6-2).
SME
Channel Switch Measurement
Decision Policy
MREQUEST
MREPORT
MEASURE
CHANNEL
SWITCH
&
MLME
Channel Switch Measurement Measurement
Timing Protocol Frames
MAC Timing
PLME
Figure 6-2—Layer management model
318
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The informative diagrams within this subclause further illustrate the protocol layer model adopted.
Figure 6-3 and Figure 6-4 depict the measurement process for a peer STA to accept and reject a
measurement request, respectively. Figure 6-5 illustrates the TPC adaptation process. Lastly, Figure 6-6
depicts the management process for a channel switch using a Channel Switch Announcement frame.
Note that these diagrams are intended as examples and do not depict all possible protocol scenarios, e.g.,
a measurement request may result in more than one Measurement Report frame as described in 11.9.7
and 11.11.
IEEE802.11 STA IEEE802.11 STA
SME MLME MLME SME
Decision to request
measurement from
peer STA
Measurement/Radio Measurement
MLME‐MREQUEST.request Request frame MLME‐MREQUEST.indication
Decision to accept
measurement request
from peer STA
MLME‐MEASURE.request
Measurement process
MLME‐MEASURE.confirm
Compile
measurement report
Measurement/Radio Measurement
MLME‐MREPORT.confirm Report frame MLME‐MREPORT.request
Measurement request
completed
Figure 6-3—Measurement request—accepted
319
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IEEE802.11 STA IEEE802.11 STA
SME MLME MLME SME
Decision to request
measurement from
peer STA
Measurement/Radio Measurement
MLME‐MREQUEST.request Request frame MLME‐MREQUEST.indication
Decision to reject
measurement request
from peer STA as refuse or
incapable
Measurement/Radio Measurement
MLME‐MREPORT.confirm Report frame MLME‐MREPORT.request
Measurement request
completed
Figure 6-4—Measurement request—rejected
IEEE802.11 STA IEEE802.11 STA
SME MLME MLME SME
Decision to adapt
transmit power
MLME‐TPCADAPT.request TPC Request frame
TPC Protocol
TPC Report frame
TPC Protocol
MLME‐TPCADAPT.confirm
Figure 6-5—TPC adaptation
320
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IEEE 802.11 STA IEEE 802.11 STA
SME MLME MLME SME
Decision
to switch
channel
Channel Switch
MLME - CHANNEL Announcement frame MLME- CHANNEL
SWITCH.request (multiple) SWITCH.indication
Decision
to follow
switch
MLME- CHANNEL
SWITCH.response
Channel switch Channel switch
via PLME via PLME
MLME - CHANNEL
SWITCH.confirm
Channel
switch
complete
Figure 6-6—Channel switching
6.3.14 Measurement request
6.3.14.1 Introduction
This set of primitives supports the signaling of measurement requests between peer SMEs.
6.3.14.2 MLME-MREQUEST.request
6.3.14.2.1 Function
This primitive requests the transmission of a measurement request to a peer entity.
6.3.14.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MREQUEST.request(
Peer MAC Address,
Dialog Token,
Measurement Request Set,
Number of Repetitions,
Measurement Category,
VendorSpecificInfo
)
321
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity to
or group MAC which the measurement request is
address transmitted.
Dialog Token Integer 1–255 The dialog token to identify the
measurement transaction.
Measurement Set of measurement Set of measurement A set of measurement requests, each
Request Set requests, each as requests, each as containing a measurement token,
defined in the defined in 9.4.2.21 measurement request mode, measurement
Measurement type, and measurement request.
Request element
format
Number of Integer 0 – 65 535 The number of times the Measurement
Repetitions Request Set is to be repeated. The
parameter is present if Measurement
Category is Radio Measurement and
dot11RadioMeasurementActivated is
true; otherwise not present.
Measurement Enumeration SPECTRUM Indicates whether the contents of the
Category MANAGEMENT, or Measurement Report Set parameter is a
RADIO set of Spectrum Management requests or
MEASUREMENT a set of Radio Measurement requests. The
parameter is present if
dot11RadioMeasurementActivated is
true; otherwise not present.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.14.2.3 When generated
This primitive is generated by the SME to request that a Measurement Request frame be sent to a peer entity
to initiate one or more measurements.
6.3.14.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Measurement Request frame containing the set of
Measurement Request elements specified. This frame is then scheduled for transmission.
6.3.14.3 MLME-MREQUEST.indication
6.3.14.3.1 Function
This primitive indicates that a Measurement Request frame has been received requesting the measurement
of one or more channels.
6.3.14.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MREQUEST.indication(
Peer MAC Address,
Dialog Token,
Measurement Request Set,
Number of Repetitions,
322
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Measurement Category,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity from
MAC address which the measurement request was
received.
Dialog Token Integer 1–255 The dialog token to identify the
measurement transaction.
Measurement Set of measurement Set of measurement A set of measurement requests, each
Request Set requests, each as requests, each as containing a Measurement Token,
defined in the defined in 9.4.2.21 Measurement Request Mode,
Measurement Measurement Type, and Measurement
Request element Request.
format
Number of Integer 0 – 65 535 The number of times the Measurement
Repetitions Request Set is to be repeated. The
parameter is present if Measurement
Category is Radio Measurement and
dot11RadioMeasurementActivated is
true; otherwise not present.
Measurement Enumeration SPECTRUM Indicates whether the contents of the
Category MANAGEMENT, or Measurement Report Set parameter is a
RADIO set of Spectrum Management requests or
MEASUREMENT a set of Radio Measurement requests. The
parameter is present if
dot11RadioMeasurementActivated is
true; otherwise not present.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.14.3.3 When generated
This primitive is generated by the MLME when a valid Measurement Request frame is received.
6.3.14.3.4 Effect of receipt
On receipt of this primitive, the SME either rejects the request or commences the requested measurements.
6.3.15 Channel measurement
6.3.15.1 Introduction
This set of primitives supports the requesting and reporting of measurement data.
6.3.15.2 MLME-MEASURE.request
6.3.15.2.1 Function
This primitive is generated by the SME to request that the MLME initiate specified measurements.
6.3.15.2.2 Semantics of the service primitive
The primitive parameters are as follows:
323
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-MEASURE.request(
Dialog Token,
Measurement Request Set
)
Name Type Valid range Description
Dialog Token Integer 0–255 The dialog token to identify the
measurement transaction.
Measurement Set of measurement Set of measurement A set of measurement requests, each
Request Set requests, each as requests, each as containing a Measurement Token,
defined in the defined in 9.4.2.21 Measurement Request Mode,
Measurement Measurement Type, and Measurement
Request element Request.
6.3.15.2.3 When generated
This primitive is generated by the SME to request that the MLME initiate the specified measurements.
6.3.15.2.4 Effect of receipt
On receipt of this primitive, the MLME commences the measurement process.
6.3.15.3 MLME-MEASURE.confirm
6.3.15.3.1 Function
This primitive reports the result of a measurement.
6.3.15.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MEASURE.confirm(
Dialog Token,
Measurement Report Set,
)
Name Type Valid range Description
Dialog Token Integer 0–255 The dialog token to identify the
measurement transaction.
Measurement Set of measurement Set of measurement reports, A set of measurement reports,
Report Set reports, each as each as defined in 9.4.2.22 each containing a Measurement
defined in the Token, Measurement Report
Measurement Report Mode, Measurement Type, and
element Measurement Report.
6.3.15.3.3 When generated
This primitive is generated by the MLME to report the results when a measurement set completes.
6.3.15.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the result code and, if appropriate, stores the channel
measurements pending communication to the requesting entity or for local use.
324
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.16 Measurement report
6.3.16.1 Introduction
This set of primitives supports the signaling of measurement reports.
6.3.16.2 MLME-MREPORT.request
6.3.16.2.1 Function
This primitive supports the signaling of measurement reports between peer SMEs.
6.3.16.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MREPORT.request(
Peer MAC Address,
Dialog Token,
Measurement Report Set,
Measurement Category,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity to
MAC address which the measurement report is sent.
Dialog Token Integer 0–255 The dialog token to identify the
measurement transaction. Set to 0 for an
autonomous report.
Measurement Report Set of measurement Set of measurement A set of measurement reports, each
Set reports, each as reports, each as containing a Measurement Token,
defined in the defined in 9.4.2.22 Measurement Report Mode,
Measurement Report Measurement Type, and Measurement
element format Report.
Measurement Enumeration SPECTRUM Indicates whether the Measurement
Category MANAGEMENT, or Report Set is a set of Spectrum
RADIO Management or Radio Measurement
MEASUREMENT reports. The parameter is present if
dot11RadioMeasurementActivated is
true; otherwise not present.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.16.2.3 When generated
This primitive is generated by the SME to request that a frame be sent to a peer entity to report the results of
measuring one or more channels.
6.3.16.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Measurement Report frame containing the set of
measurement reports. This frame is then scheduled for transmission.
325
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.16.3 MLME-MREPORT.indication
6.3.16.3.1 Function
This primitive indicates that a Measurement Report frame has been received from a peer entity. This
management report is either a response to an earlier measurement request (e.g., MLME-
MREQUEST.request primitive) or an autonomous report.
6.3.16.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MREPORT.indication(
Peer MAC Address,
Dialog Token,
Measurement Report Set,
Measurement Category,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity from
MAC address which the Measurement Report frame was
received.
Dialog Token Integer 0–255 The dialog token to identify the
measurement transaction. Set to 0 for an
autonomous report.
Measurement Set of measurement Set of measurement A set of measurement reports, each
Report Set reports, each as reports, each as containing a Measurement Token,
defined in the defined in 9.4.2.22 Measurement Report Mode, Measurement
Measurement Report Type, and Measurement Report.
element format
Measurement Enumeration SPECTRUM Indicates whether the Measurement
Category MANAGEMENT, or Report Set is a set of Spectrum
RADIO Management or Radio Measurement
MEASUREMENT reports. The parameter is present if
dot11RadioMeasurementActivated is true;
otherwise not present.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.16.3.3 When generated
This primitive is generated by the MLME when a valid Measurement Report frame is received.
6.3.16.3.4 Effect of receipt
On receipt of this primitive, measurement data might be available for SME processes, such as channel
selection.
326
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.17 Channel switch
6.3.17.1 MLME-CHANNELSWITCH.request
6.3.17.1.1 Function
This primitive requests a switch to a new operating channel.
6.3.17.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELSWITCH.request(
Mode,
Channel Number,
Secondary Channel Offset,
Channel Switch Count,
Mesh Channel Switch Parameters,
Wide Bandwidth Channel Switch,
New Transmit Power Envelope,
VendorSpecificInfo
)
Name Type Valid range Description
Mode Integer 0, 1 Channel switch mode, as defined for the
Channel Switch Announcement element.
Channel Number Integer As defined in Specifies the new channel number.
17.3.8.4.3
Secondary Channel Integer As in Table 9-80 Specifies the position of secondary
Offset channel in relation to the primary
channel.
The parameter is present if
dot11FortyMHzOperationImplemented is
true; otherwise, the parameter is not
present.
Channel Switch As defined in As defined in Specifies the time period until the channel
Count 9.4.2.19 9.4.2.19 switch event, as described in 9.4.2.19
Mesh Channel As defined in As defined in Specifies MBSS Channel Switch
Switch 9.4.2.103 9.4.2.103 Parameters used by a mesh STA. This
Parameters parameter is present if the
dot11MeshActivated is true; otherwise,
the parameter is not present.
Wide Bandwidth As defined in As defined in Specifies channel parameters used when
Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than
40 MHz. The parameter is present if
dot11VHTOptionImplemented is true and
switching to a channel width wider than
40 MHz; otherwise, the parameter is not
present.
New Transmit Power Set of New Transmit N/A Specifies power parameters used for the
Envelope Power Envelope BSS after the channel switch. Optionally
elements present if dot11VHTOptionImplemented
is true.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
327
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.17.1.3 When generated
This primitive is generated by the SME to schedule a channel switch and announce this switch to peer
entities in the BSS.
6.3.17.1.4 Effect of receipt
On receipt of this primitive, the MLME schedules the channel switch event and announces this switch to
other STAs in the BSS using the Channel Switch Announcement frame or element. The MLME sets the
timing of the frame transmission taking into account the activation delay.
6.3.17.2 MLME-CHANNELSWITCH.confirm
6.3.17.2.1 Function
This primitive reports the result of a request to switch channel.
6.3.17.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELSWITCH.confirm(
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Reports the result of a channel
UNSPECIFIED FAILURE switch request.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.17.2.3 When generated
This primitive is generated by the MLME when a channel switch request completes. Possible unspecified
failure causes include an inability to schedule a channel switch announcement.
6.3.17.2.4 Effect of receipt
The SME is notified of the results of the channel switching procedure.
6.3.17.3 MLME-CHANNELSWITCH.indication
6.3.17.3.1 Function
This primitive indicates that a channel switch announcement has been received from a peer entity.
6.3.17.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELSWITCH.indication(
Peer MAC Address,
Mode,
Channel Number,
Secondary Channel Offset,
328
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Channel Switch Count,
Mesh Channel Switch Parameters,
Wide Bandwidth Channel Switch,
New Transmit Power Envelope,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity from
MAC address which the Measurement Report frame
was received.
Mode Integer 0, 1 Channel switch mode, as defined for the
Channel Switch Announcement element.
Channel Number Integer As defined in Specifies the new channel number.
17.3.8.4.3
Secondary Channel Integer As in Table 9-80 Specifies the position of secondary
Offset channel in relation to the primary
channel.
The parameter is optionally present if
dot11FortyMHzOperationImplemented is
true; otherwise not present.
Channel Switch As defined in As defined in Specifies the time period until the channel
Count 9.4.2.19 9.4.2.19 switch event, as described in 9.4.2.19
Mesh Channel As defined in As defined in Specifies MBSS Channel Switch
Switch 9.4.2.103 9.4.2.103 Parameters used by a mesh STA. This
Parameters parameter is present if the
dot11MeshActivated is true; otherwise,
the parameter is not present.
Wide Bandwidth As defined in As defined in Specifies channel parameters used when
Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than
40 MHz. The parameter is present if
dot11VHTOptionImplemented is true and
switching to a channel width wider than
40 MHz; otherwise, the parameter is not
present.
New Transmit Power Set of New Transmit N/A Specifies power parameters used for the
Envelope Power Envelope BSS after the channel switch. Optionally
elements present if dot11VHTOptionImplemented
is true.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.17.3.3 When generated
This primitive is generated by the MLME when a valid Channel Switch Announcement frame is received.
6.3.17.3.4 Effect of receipt
On receipt of this primitive, the SME decides whether to accept the switch.
6.3.17.4 MLME-CHANNELSWITCH.response
6.3.17.4.1 Function
This primitive is used to schedule an accepted channel switch.
329
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.17.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELSWITCH.response(
Mode,
Channel Number,
Secondary Channel Offset,
Channel Switch Count,
Mesh Channel Switch Parameters,
Wide Bandwidth Channel Switch,
New Transmit Power Envelope,
VendorSpecificInfo
)
Name Type Valid range Description
Mode Integer 0, 1 Channel switch mode, as defined for the
Channel Switch Announcement element.
Channel Number Integer As defined in Specifies the new channel number.
17.3.8.4.3
Secondary Channel Integer As in Table 9-80 Specifies the position of secondary channel
Offset in relation to the primary channel.
The parameter is optionally present if
dot11FortyMHzOperationImplemented is
true; otherwise not present.
Channel Switch As defined in As defined in Specifies the time period until the channel
Count 9.4.2.19 9.4.2.19 switch event, as described in 9.4.2.19
Mesh Channel As defined in As defined in Specifies MBSS Channel Switch
Switch 9.4.2.103 9.4.2.103 Parameters used by a mesh STA. This
Parameters parameter is present if the
dot11MeshActivated is true; otherwise, the
parameter is not present.
Wide Bandwidth As defined in As defined in Specifies channel parameters used when
Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40
MHz. The parameter is present if
dot11VHTOptionImplemented is true and
switching to a channel width wider than 40
MHz; otherwise, the parameter is not
present.
New Transmit Power Set of New Transmit N/A Specifies power parameters used for the
Envelope Power Envelope BSS after the channel switch. Optionally
elements present if dot11VHTOptionImplemented is
true.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.17.4.3 When generated
This primitive is generated by the SME to schedule an accepted channel switch request.
6.3.17.4.4 Effect of receipt
On receipt of this primitive, the MLME schedules the channel switch.
330
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.18 TPC request
6.3.18.1 Introduction
This set of primitives supports the adaptation of transmit power between peer entities as described in 11.8.7.
6.3.18.2 MLME-TPCADAPT.request
6.3.18.2.1 Function
This primitive supports the adaptation of transmit power between peer entities as specified in 11.8.7.
6.3.18.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TPCADAPT.request(
Peer MAC Address,
Dialog Token,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity to
or group MAC which the TPC request is sent.
address
Dialog Token Integer 1–255 The dialog token to identify the TPC
transaction.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.18.2.3 When generated
This primitive is generated by the SME to request that a TPC Request frame be sent to a peer entity to
request that entity to report transmit power and link margin information.
6.3.18.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TPC Request frame. This frame is then scheduled for
transmission.
6.3.18.3 MLME-TPCADAPT.confirm
6.3.18.3.1 Function
This primitive reports the result of the TPC adaptation procedure.
6.3.18.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TPCADAPT.confirm(
ResultCode
Transmit Power,
Link Margin,
331
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Rate,
VendorSpecificInfo
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Reports the outcome of a request
UNSPECIFIED FAILURE to send a TPC Request frame.
Transmit Power Integer –127 to 127 Value of the Transmit Power
field of the TPC Report element
of the TPC Report frame.
Link Margin Integer –127 to 127 Value of the Link Margin field
of the TPC Report element of
the TPC Report frame.
Rate Integer As defined in 9.4.2.3 The rate at which the TPC
Request frame was sent.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.18.3.3 When generated
This primitive is generated by the MLME when the TPC adaptation procedure completes.
6.3.18.3.4 Effect of receipt
The SME is notified of the results of the TPC adaptation procedure.
6.3.19 SetKeys
6.3.19.1 MLME-SETKEYS.request
6.3.19.1.1 Function
This primitive causes the keys identified in the parameters of the primitive to be set in the MAC and enabled
for use.
6.3.19.1.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-SETKEYS.request(
Keylist
)
Name Type Valid range Description
Keylist A set of SetKeyDescriptors N/A The list of keys to be used by the MAC.
Each SetKeyDescriptor consists of the following parameters:
Name Type Valid range Description
Key Bit string N/A The temporal key value
Length Integer N/A The number of bits in the Key to be used.
332
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Key ID Integer 0–3 shall be used Key identifier
with WEP, TKIP,
CCMP, and
GCMP;
4–5 with BIP; and
6–4095 are
reserved
Key Type Integer Group, Pairwise, Defines whether this key is a group key,
PeerKey, IGTK pairwise key, PeerKey, or Integrity Group
key.
Address MACAddress Any valid This parameter is valid only when the Key
individual MAC Type value is Pairwise, when the Key Type
address value is Group and the STA is in IBSS, or
when the Key Type value is PeerKey.
Receive Sequence Count 8 octets N/A Value to which the RSC(s) is initialized.
Cipher Suite Selector 4 octets As defined in The cipher suite required for this
9.4.2.25 association.
6.3.19.1.3 When generated
This primitive is generated by the SME at any time when one or more keys are to be set in the MAC.
6.3.19.1.4 Effect of receipt
Receipt of this primitive causes the MAC to apply the keys as follows, subject to the MLME-
SETPROTECTION.request primitive:
— The MAC uses the key information (as defined by the Key Type, Key ID, Address and Cipher Suite
Selector parameters) for the transmission of subsequent frames to which the key applies (as defined
by the Key Type, Key ID and Address elements).
— The MAC installs the key with the associated Key ID such that received frames for the cipher suite
indicated by the Cipher Suite Selector, of the appropriate type, and containing the matching Key ID
are processed using that key and its associated state information, subject to validation based on the
Receive Sequence Count.
6.3.20 DeleteKeys
6.3.20.1 MLME-DELETEKEYS.request
6.3.20.1.1 Function
This primitive causes the keys identified in the parameters of the primitive to be deleted from the MAC and
thus disabled for use.
6.3.20.1.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-DELETEKEYS.request(
Keylist
)
Name Type Valid range Description
Keylist A set of N/A The list of keys to be deleted from the
DeleteKeyDescriptors MAC.
333
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Each DeleteKeyDescriptor consists of the following parameters:
Name Type Valid range Description
Key ID Integer 0–3 shall be used Key identifier.
with WEP, TKIP,
CCMP, and
GCMP;
4–5 with BIP; and
6–4095 are reserved
Key Type Integer Group, Pairwise, Defines whether this key is a group key,
PeerKey, IGTK pairwise key, PeerKey, or Integrity Group
key.
Address MACAddress Any valid individual This parameter is valid only when the Key
MAC address Type value is Pairwise, or when the Key
Type value is Group and is from an IBSS
STA, or when the Key Type value is
PeerKey.
6.3.20.1.3 When generated
This primitive is generated by the SME at any time when keys for a security association are to be deleted in
the MAC.
6.3.20.1.4 Effect of receipt
Receipt of this primitive causes the MAC to delete all the temporal keys identified by each
DeleteKeyDescriptor in the Keylist (as defined by the Key Type, Key ID and Address elements), and to
cease using them.
6.3.21 MIC (michael) failure event
6.3.21.1 MLME-MICHAELMICFAILURE.indication
6.3.21.1.1 Function
This primitive reports that a MIC failure event was detected.
6.3.21.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MICHAELMICFAILURE.indication (
Count,
Address,
Key Type,
Key ID,
TSC
)
334
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Count Integer 1 or 2 The current number of MIC failure
events.
Address MACAddress Any valid individual The source MAC address of the frame.
MAC address
Key Type Integer Group, Pairwise, The key type that the received frame
PeerKey used.
Key ID Integer 0–3 Key identifier.
TSC 6 octets N/A The TSC value of the frame that
generated the MIC failure.
6.3.21.1.3 When generated
This primitive is generated by the MAC when it has detected a MIC failure.
6.3.21.1.4 Effect of receipt
The SME is notified that the MAC has detected a MIC failure; see 12.5.2.4.
6.3.22 EAPOL
6.3.22.1 MLME-EAPOL.request
6.3.22.1.1 Function
This primitive is generated by the SME when the SME has an EAPOL-Key frame to send.
6.3.22.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EAPOL.request (
Source Address,
Destination Address,
Data
)
Name Type Valid range Description
Source Address MACAddress N/A The MAC sublayer address from which the
EAPOL PDU is being sent.
Destination Address MACAddress N/A The MAC sublayer entity address to which
the EAPOL PDU is being sent.
Data EAPOL PDU (as N/A The EAPOL PDU to be transmitted.
defined in IEEE Std
802.1X-2010 Clause
11)
6.3.22.1.3 When generated
This primitive is generated by the SME when the SME has a EAPOL-Key frame to send.
6.3.22.1.4 Effect of receipt
The MAC sends this EAPOL-Key frame.
335
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.22.2 MLME-EAPOL.confirm
6.3.22.2.1 Function
This primitive indicates that this EAPOL-Key frame has been transmitted by the MAC.
6.3.22.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EAPOL.confirm (
ResultCode
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates whether the EAPOL-Key frame
TRANSMISSION_FAILURE has been transmitted to the target STA.
6.3.22.2.3 When generated
This primitive is generated by the MAC as a result of an MLME-EAPOL.request primitive being generated
to send an EAPOL-Key frame.
6.3.22.2.4 Effect of receipt
The SME is always notified whether this EAPOL-Key frame has been transmitted to the IEEE 802.11 MAC.
This primitive communicates that the frame has been transmitted; see the procedures in 12.5.2.4.1.
6.3.23 MLME-PEERKEY-START
6.3.23.1 MLME-PEERKEY-START.request
6.3.23.1.1 Function
This primitive is generated by the SME to start a PeerKey handshake with a peer.
6.3.23.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-PEERKEY-START.request (
PeerSTAAddress,
RSN
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC entity
MAC address with which to perform the PeerKey
handshake process.
RSN RSNE As defined in A description of the cipher suites supported
9.4.2.25 by initiator STA.
336
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.23.1.3 When generated
This primitive is generated by the SME for a STA to initiate a PeerKey handshake with a specified peer
MAC entity in order to create a secure link between the two STAs.
6.3.23.1.4 Effect of receipt
This primitive initiates the SMK handshake as part of PeerKey handshake by sending an EAPOL-Key
frame.
6.3.24 SetProtection
6.3.24.1 MLME-SETPROTECTION.request
6.3.24.1.1 Function
This primitive indicates whether protection is required for frames sent to and received from the indicated
MAC address.
6.3.24.1.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-SETPROTECTION.request(
Protectlist
)
Name Type Valid range Description
Protectlist A set of protection N/A The list of how each key is being used
elements currently.
Each Protectlist consists of the following parameters:
Name Type Valid range Description
Address MACAddress Any valid individual This parameter is valid only when the Key
MAC address Type value is Pairwise or when the Key
Type value is Group and is from an IBSS
STA or PeerKey.
ProtectType Enumeration None, Rx, Tx, The protection value for this MAC.
Rx_Tx
Key Type Integer Group, Pairwise, Defines whether this key is a group key,
PeerKey, IGTK pairwise key, PeerKey, or Integrity Group
key.
6.3.24.1.3 When generated
This primitive is generated by the SME when protection is required for frames sent to and received from the
indicated MAC address.
6.3.24.1.4 Effect of receipt
Receipt of this primitive causes the MAC to set the protection and to protect Data frames as indicated in the
ProtectType parameter of the Protectlist parameter:
— None: Specifies that Data frames to and from the MAC address are not protected.
337
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Rx: Specifies that Data frames from the MAC address are protected (i.e., any Data frames without
protection received from the MAC address are discarded) but Data frames to the MAC address are
not protected.
— Tx: Specifies that Data frames to the MAC address are protected but Data frames from the MAC
address are not protected.
— Rx_Tx: Specifies that Data frames to and from the MAC address are protected.
Once Data frames are protected to and/or from the specified MAC address, the MLME-
SETPROTECTION.request primitive is used to reset the prior setting. Invocation of the MLME-
SETPROTECTION.request primitive with a ProtectType of None deletes a protection state.
6.3.25 MLME-PROTECTEDFRAMEDROPPED
6.3.25.1 MLME- PROTECTEDFRAMEDROPPED.indication
6.3.25.1.1 Function
This primitive notifies the SME that a frame has been dropped because a temporal key was unavailable.
6.3.25.1.2 Semantics of the service primitive
This primitive has two parameters, the MAC addresses of the two STAs.
The primitive parameters are as follows:
MLME-PROTECTEDFRAMEDROPPED.indication (
Address1,
Address2
)
Name Type Valid range Description
Address1 MACAddress Any valid individual MAC address of TA.
MAC address
Address2 MACAddress Any valid individual MAC address of RA.
MAC address
6.3.25.1.3 When generated
This primitive is generated by the MAC when a frame is dropped because no temporal key is available for
the frame.
6.3.25.1.4 Effect of receipt
The SME is notified that a frame was dropped. The SME can use this information in an IBSS to initiate a
security association to the peer STA.
6.3.26 TS management interface
6.3.26.1 General
This mechanism supports the process of adding, modifying, or deleting a TS in a BSS using the procedures
defined in 11.4.
338
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The primitives used for this mechanism are called TS Management primitives, which include MLME-
ADDTS.xxx, MLME-DELTS.xxx, and MLME-ADDTSRESERVE.xxx primitives, where xxx denotes
request, confirm, indication, or response. Each primitive contains parameters that correspond to a QoS
Action frame. Requests and responses may cause the transmission of the corresponding QoS Action frames.
Confirms and indications are issued upon the receipt of the appropriate QoS Action frame.
Table 6-1 defines which primitives are supported by which type of STA.
Table 6-1—Supported TS management primitives
Primitive Request Confirm Indication Response
ADDTS (in the DMG STA DMG STA DMG STA DMG STA
context of non-AP QoS STA non-AP QoS STA HC HC
establishing a TS)
ADDTS (in the Non-AP and non-PCP Non-AP and non-PCP DMG AP or PCP DMG AP or
context of DMG STA DMG STA PCP
requesting an
allocation)
DELTS DMG STA DMG STA DMG STA —
non-AP QoS STA non-AP QoS STA non-AP QoS STA
HC HC HC
ADDTSRESERVE HC HC non-AP QoS STA non-AP QoS
STA
6.3.26.2 MLME-ADDTS.request
6.3.26.2.1 Function
This primitive requests addition (or modification) of a TS. It requests the HC or PCP to admit the new or
changed TS.
6.3.26.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDTS.request (
DialogToken,
TSPEC,
TCLAS,
TCLASProcessing,
U-APSD Coexistence,
EBR,
IntraAccessCategoryPriority,
HigherLayerStreamID,
STAAddress,
DMG TSPEC,
Multi-band,
U-PID,
MMS,
VendorSpecificInfo
)
339
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DialogToken Integer 0–127 Identifies the ADDTS
transaction.
TSPEC As defined in TSPEC element As defined in 9.4.2.30 with Specifies the TSID, traffic
with the exception of the the exception of the surplus characteristics, and QoS
surplus bandwidth allowance, bandwidth allowance, requirements of the TS of
minimum PHY rate, and minimum PHY rate, and concern.
maximum and minimum SIs, maximum and minimum SIs,
which are optionally specified which are optionally specified
TCLAS TCLAS element As defined in 9.4.2.31 Zero or more TCLAS
elements.
Specifies the rules and
parameters by which an
MSDU may be classified
to the specified TS.
TCLASProcessing TCLAS Processing element As defined in 9.4.2.33 Specifies how the TCLAS
elements are to be
processed when there are
multiple TCLAS
elements.
U-APSD U-APSD Coexistence As defined in 9.4.2.91. Indicates the coexistence
Coexistence element parameters for requested
transmission during a U-
APSD service period.
EBR Expedited Bandwidth As defined in 9.4.2.94 Specifies the precedence
Request element level of the TS request.
This element is optionally
present when
dot11EBRActivated is
true.
IntraAccessCategor Intra-Access Category As defined in 9.4.2.121 Specifies the intra-AC
yPriority Priority element priorities the STA should
use.
HigherLayerStream Higher Layer Stream ID As defined in 9.4.2.125 Identifies the higher layer
ID element stream.
STAAddress MACAddress Specifies the MAC
address of the peer STA
for a PTP TSPEC.
DMG TSPEC DMG TSPEC element As defined in 9.4.2.134 Specifies the
characteristics and QoS
(scheduling) requirements
of the DMG allocation
request.
Multi-band Multi-band element As defined in 9.4.2.138 Specifies the frequency
band and channel number
where the TSID is to be
established. The
parameter is absent if the
TSID is intended to be
established on the same
frequency band and
channel where the
ADDTS Request frame is
transmitted.
340
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
U-PID U-PID element As defined in 9.4.2.154 This parameter is
optionally present and
specifies the parameters of
the LLC for the purpose of
(de)multiplexing of
frames associated with the
TSID.
MMS Multiple MAC Sublayers As defined in 9.4.2.153 This parameter is
element optionally present and
specifies the parameters of
an MMSL cluster
establishment.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.26.2.3 When generated
This primitive is generated by the SME to request the addition of a new (or modification of an existing) TS
in order to support parameterized QoS transport of the MSDUs belonging to this TS when a higher layer
protocol or mechanism signals the STA to initiate such an addition (or modification).
6.3.26.2.4 Effect of receipt
The STA operates according to the procedures defined in 11.4.
6.3.26.3 MLME-ADDTS.confirm
6.3.26.3.1 Function
This primitive reports the results of a TS addition (or modification) attempt.
6.3.26.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDTS.confirm(
ResultCode,
DialogToken,
TSDelay,
TSPEC,
Schedule,
TCLAS,
TCLASProcessing,
EBR,
HigherLayerStreamID,
STAAddress,
DMG TSPEC,
Multi-band,
U-PID,
MMS,
VendorSpecificInfo
)
341
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates the results of the
REJECTED_WITH_SUGGESTED_CHA corresponding MLME-
NGES, ADDTS.request primitive.
REJECTED_FOR_DELAY_PERIOD,
REJECTED_WITH_SUGGESTED_BSS_
TRANSITION,
REQUESTED_TCLAS_NOT_SUPPORTE
D, TCLAS_RESOURCES_EXHAUSTED,
REJECTED_HOME_WITH_
SUGGESTED_CHANGES,
REJECTED_FOR_SSP_PERMISSIONS,
SUCCESS_STA_IN_PS_MODE,
REJECT_U-PID_SETTING
DialogToken Integer As defined in the corresponding MLME- Identifies the ADDTS
ADDTS.request primitive transaction.
TSDelay Integer 0 When the result code is
REJECTED_FOR_DELAY_
PERIOD, provides the
amount of time a STA should
wait before attempting
another ADDTS Request
frame.
TSPEC TSPEC As defined in 9.4.2.30 Specifies the TS information,
element traffic characteristics, and
QoS requirements of the TS.
Schedule Schedule As defined in 9.4.2.34 Specifies the schedule
element information, service start
time, SI, and the specification
interval.
TCLAS TCLAS As defined in 9.4.2.31 Zero or more TCLAS
element elements.
Specifies the rules and
parameters by which an
MSDU may be classified to
the specified TS.
TCLASProcessing TCLAS As defined in 9.4.2.33 Specifies how the TCLAS
Processing elements are to be processed
element when there are multiple
TCLAS elements.
EBR Expedited As defined in 9.4.2.94 Specifies the precedence level
Bandwidth of the TS request.
Request This element is optionally
element present when
dot11EBRActivated is true.
HigherLayerStream Higher Layer As defined in 9.4.2.125 Identifies the higher layer
ID Stream ID stream.
element
STAAddress MACAddres Specifies the MAC address of
s the peer STA for a PTP
TSPEC.
DMG TSPEC DMG As defined in 9.4.2.134 Specifies the characteristics
TSPEC and QoS (scheduling)
element requirements of the DMG
allocation request.
342
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency band
element and channel number where
the TSID is to be established.
The parameter is absent if the
TSID is intended to be
established on the same
frequency band and channel
where the ADDTS Request
frame is transmitted.
U-PID U-PID As defined in 9.4.2.154 This parameter is optionally
element present and specifies the
parameters of the LLC for the
purpose of (de)multiplexing
of frames associated with the
TSID.
MMS Multiple As defined in 9.4.2.153 This parameter is optionally
MAC present and specifies the
Sublayers parameters of an MMSL
element cluster establishment.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
For the ResultCode value of SUCCESS received by a non-DMG STA, the TSPEC and the optional TCLAS
parameters describe the characteristics of the TS that has been created (or modified); and the specified
(nonzero) parameters [with the exception of Service Start Time, Medium Time, and any possibly
unspecified minimum set of parameters (see 10.22.4.3) in the TSPEC in ADDTS Request frame] exactly
match those of the matching MLME-ADDTS.request primitive.
For other values of ResultCode received by a non-DMG STA, no new TS has been created. In the case of
REJECTED_WITH_ SUGGESTED_CHANGES, the TSPEC represents an alternative proposal by the HC
based on information about the current status of the MAC entity. In the case of
REJECTED_HOME_WITH_SUGGESTED_CHANGES, the TSPEC represents an alternative proposal by
the HC based on information received from the SSPN interface. A TS is not created with this definition. If
the suggested changes are acceptable to the STA, it is the responsibility of the STA to set up the TS with the
suggested changes.
In the case of REJECTED_WITH_SUGGESTED_BSS_TRANSITION, non-AP STA should retry TS setup
process with the newly associated AP once the transition is done.
If this is the result of a modification of an existing TS, the status of that TS remains unchanged.
For the ResultCode value of SUCCESS or SUCCESS_STA_IN_PS_MODE received by a DMG STA, the
DMG TSPEC and the optional TCLAS parameters describe the characteristics of the allocation or TS that
has been created (or modified); and the specified (nonzero) parameters [with the exception of Maximum
Allocation in the DMG TSPEC in the ADDTS Request frame] exactly match those of the matching MLME-
ADDTS.request primitive.
For other values of ResultCode received by a DMG STA, no new allocation or TS has been created. In the
case of REJECTED_WITH_SUGGESTED_CHANGES or REJECT_U-PID_SETTING, then the DMG
TSPEC, Multi-band, and U-PID parameters represent an alternative proposal by the peer STA. In such
cases, an allocation or TS has not been created. If the suggested changes are acceptable to the STA, it is the
responsibility of the STA to set up the allocation or TS with the suggested changes.
If this failure is the result of a modification of an existing allocation or TS, the status of that allocation or TS
remains unchanged.
343
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.26.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-ADDTS.request primitive indicating the
results of that request.
This primitive is generated when the STA receives a response in the form of an ADDTS Response frame in
the corresponding QoS Action frame from the HC or DMG STA.
6.3.26.3.4 Effect of receipt
The SME is notified of the results of the TS addition (or modification) procedure.
The SME should operate according to the procedures defined in 11.4.
6.3.26.4 MLME-ADDTS.indication
6.3.26.4.1 Function
This primitive reports to the DMG STA’s SME or the HC’s SME the request for adding (or modifying) a
TS.
6.3.26.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDTS.indication (
DialogToken,
STAAddress,
TSPEC,
TCLAS,
TCLASProcessing,
U-APSD Coexistence,
EBR,
IntraAccessCategoryPriority,
HigherLayerStreamID,
DMG TSPEC,
Multi-band,
U-PID,
MMS,
VendorSpecificInfo
)
Name Type Valid range Description
DialogToken Integer As defined in the Identifies the ADDTS transaction.
received ADDTS
Request frame
STAAddress MACAddress Contains the MAC address of the STA
that initiated the
MLME-ADDTS.request primitive.
344
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
TSPEC As defined in the As defined in Specifies the TSID, traffic
TSPEC element, with 9.4.2.30 with the characteristics, and QoS requirements of
the exception of the exception of the the TS.
surplus bandwidth surplus bandwidth
allowance, minimum allowance, minimum
PHY rate, and PHY rate, and
maximum and maximum and
minimum SIs, which minimum SIs, which
are optionally are optionally
specified specified
TCLAS TCLAS element As defined in 9.4.2.31 Zero or more TCLAS elements.
Specifies the rules and parameters by
which an MSDU may be classified to the
specified TS.
TCLASProcessing TCLAS Processing As defined in 9.4.2.33 Specifies how the TCLAS elements are
element to be processed when there are multiple
TCLAS elements.
U-APSD Coexistence U-APSD As defined in Indicates the coexistence parameters for
Coexistence element 9.4.2.91 requested transmission during a U-APSD
service period.
EBR Expedited Bandwidth As defined in Specifies the precedence level of the TS
Request element 9.4.2.94 request.
This element is optionally present when
dot11EBRActivated is true.
IntraAccessCategory Intra-Access As defined in Specifies the intra-AC priorities the STA
Priority Category Priority 9.4.2.121 should use.
element
HigherLayerStreamI Higher Layer Stream As defined in Identifies the higher layer stream.
D ID element 9.4.2.125
DMG TSPEC DMG TSPEC As defined in Specifies the characteristics (scheduling)
element 9.4.2.134 and QoS requirements of the DMG
allocation request.
Multi-band Multi-band element As defined in Specifies the frequency band and
9.4.2.138 channel number where the TSID is to be
established. The parameter is absent if
the TSID is intended to be established on
the same frequency band and channel
where the ADDTS Request frame is
transmitted.
U-PID U-PID element As defined in This parameter is optionally present and
9.4.2.154 specifies the parameters of the LLC for
the purpose of (de)multiplexing of
frames associated with the TSID.
MMS Multiple MAC As defined in This parameter is optionally present and
Sublayers element 9.4.2.153 specifies the parameters of an MMSL
cluster establishment.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
The TCLAS is optional at the discretion of the STA that originated the request.
345
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.26.4.3 When generated
This primitive is generated by the MLME as a result of receipt of a request to add (or modify) a TS by a
specified STA in the form of an ADDTS Request frame.
6.3.26.4.4 Effect of receipt
The SME is notified of the request for a TS addition (or modification) by a specified STA.
This primitive solicits an MLME-ADDTS.response primitive from the SME that reflects the results of
admission control at the HC or DMT STA on the TS requested to be added (or modified).
The SME should operate according to the procedures defined in 11.4.
The SME generates an MLME-ADDTS.response primitive within a dot11ADDTSResponseTimeout.
6.3.26.5 MLME-ADDTS.response
6.3.26.5.1 Function
This primitive responds to the request for a TS addition (or modification) by a specified STA’s MAC entity.
6.3.26.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDTS.response(
ResultCode,
DialogToken,
STAAddress,
TSDelay,
TSPEC,
Schedule,
TCLAS,
TCLASProcessing,
EBR,
HigherLayerStreamID,
DMG TSPEC,
Multi-band,
U-PID,
MMS,
VendorSpecificInfo
)
346
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ResultCode Enumeration SUCCESS, REJECTED_WITH_ Indicates the results of the
SUGGESTED_CHANGES, corresponding MLME-
REJECTED_FOR_DELAY_PERIOD, ADDTS.indication primitive.
REJECTED_WITH_SUGGESTED_
BSS_TRANSITION,
REQUESTED_TCLAS_NOT_
SUPPORTED,
TCLAS_RESOURCES_
EXHAUSTED,
REJECTED_HOME_WITH_
SUGGESTED_CHANGES,
REJECTED_FOR_SSP_
PERMISSIONS,
SUCCESS_STA_IN_PS_MODE,
REJECT_U-PID_SETTING
DialogToken Integer As defined in the corresponding DialogToken of the matching
MLME-ADDTS.indication MLME-ADDTS.indication
primitive.
STAAddress MACAddress Contains the STA address of
the matching MLME-
ADDTS.indication primitive.
TSDelay Integer 0 When the result code is
REJECTED_FOR_DELAY_
PERIOD, provides the amount
of time a STA should wait
before attempting another
ADDTS request.
TSPEC TSPEC element As defined in 9.4.2.30 Specifies the QoS parameters
of the TS.
Schedule Schedule As defined in 9.4.2.34 Specifies the schedule
element information, service start time,
SI, and the specification
interval.
TCLAS TCLAS As defined in 9.4.2.31 Zero or more TCLAS
element elements.
Specifies the rules and
parameters by which an MSDU
may be classified to the
specified TS.
TCLASProcessing TCLAS As defined in 9.4.2.33 Specifies how the TCLAS
Processing elements are to be processed
element when there are multiple
TCLAS elements.
EBR Expedited As defined in 9.4.2.94 Specifies the precedence level
Bandwidth of the TS request.
Request This element is optionally
element present when
dot11EBRActivated is true.
HigherLayerStream Higher Layer As defined in 9.4.2.125 Identifies the higher layer
ID Stream ID stream.
element
DMG TSPEC DMG TSPEC As defined in 9.4.2.134 Specifies the characteristics
element (scheduling) and QoS
requirements of the DMG
allocation request.
347
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency band
element and channel number where the
TSID is to be established. The
parameter is absent if the TSID
is intended to be established on
the same frequency band and
channel where the ADDTS
Request frame is transmitted.
U-PID U-PID element As defined in 9.4.2.154 This parameter is optionally
present and specifies the
parameters of the LLC for the
purpose of (de)multiplexing of
frames associated with the
TSID.
MMS Multiple MAC As defined in 9.4.2.153 This parameter is optionally
Sublayers present and specifies the
element parameters of an MMSL
cluster establishment.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
The DialogToken and STAAddress parameters contain the values from the matching MLME-
ADDTS.indication primitive.
If a non-DMG STA receives a result code of SUCCESS, the TSPEC and (optional) TCLAS parameters
contain the values from the matching MLME-ADDTS-indication.
If a DMG STA receives a result code of SUCCESS or SUCCESS_STA_IN_PS_MODE, the DMG TSPEC
and (optional) TCLAS parameters contain the values from the matching MLME-ADDTS.indication
primitive.
If a non-DMG STA receives a result code of REJECTED_WITH_SUGGESTED_CHANGES or
REJECTED_HOME_WITH_ SUGGESTED_CHANGES, the TSPEC and TCLAS parameters represent an
alternative proposed TS either based on information local to the MAC entity or using additional information
received across the SSPN interface. The TS, however, is not created. The TSID and direction values within
the TSPEC are as in the matching MLME-ADDTS.indication primitive. The difference may lie in the QoS
(e.g., minimum data rate, mean data rate, and delay bound) values, as a result of admission control
performed at the SME of the HC on the TS requested to be added (or modified) by the STA. If sufficient
bandwidth is not available, the QoS values may be reduced. In one extreme, the minimum data rate, mean
data rate, and delay bound may be all set to 0, indicating that no QoS is to be provided to this TS.
If a DMG STA receives a result code of REJECTED_WITH_SUGGESTED_CHANGES or REJECT_U-
PID_SETTING, then the DMG TSPEC, TCLAS, Multi-band, and U-PID parameters represent an
alternative proposal for the allocation or TS. The allocation or TS, however, has not been created. The
allocation ID value within the DMG TSPEC is as in the matching MLME-ADDTS.indication primitive. The
difference might lie in the other parameter values, as a result of admission control performed at the SME of
the peer STA on the allocation or TS requested to be added (or modified). If sufficient bandwidth is not
available, the QoS values might be reduced.
If the result code is REJECTED_WITH_SUGGESTED_BSS_TRANSITION, the non-AP STA should
initiate a transition query as defined in 11.24.7. Once the transition is completed, the STA should retry TS
setup process, as defined in 11.4.4.
348
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.26.5.3 When generated
This primitive is generated by the SME at the HC or DMG STA as a result of an MLME-ADDTS.indication
primitive to initiate addition (or modification) of a TS with a specified peer MAC entity or entities.
6.3.26.5.4 Effect of receipt
This primitive approves addition (or modification) of a TS requested by a specified STA’s MAC entity, with
or without altering the TSPEC.
This primitive causes the MAC entity at the HC or DMG STA to send an ADDTS Response frame to the
requesting STA containing the specified parameters.
6.3.26.6 MLME-DELTS.request
6.3.26.6.1 Function
This primitive requests deletion of a TS with a specified peer MAC.
This primitive may be generated by one of the following:
— DMG STA
— Non-AP STA
— PCP
— HC
6.3.26.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DELTS.request(
STAAddress,
TSInfo,
ReasonCode,
STAAddress,
DMG Allocation Info,
Multi-band,
VendorSpecificInfo
)
Name Type Valid range Description
STAAddress MACAddress Specifies the MAC address
of the STA that initiated
this TS.
Present only at the HC.
TSInfo TS Info field As defined in 9.4.2.30 Specifies the TS to be
deleted. Not present when
DMG Allocation Info is
present.
ReasonCode Enumeration STA_LEAVING, END_TS, Indicates the reason why
UNKNOWN_TS, TIMEOUT, the TS is being deleted.
SERVICE_CHANGE_PRECLUDES_TS
STAAddress MACAddress Specifies the MAC address
of the peer STA for the
PTP TSPEC.
349
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DMG Allocation DMG As defined in 9.4.2.134 Specifies the DMG
Info Allocation Info allocation to be deleted.
field Not present when TSInfo
is present.
Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency
element band and channel number
where the TS is to be
deleted. The parameter is
absent if the TS is intended
to be deleted on the same
frequency band and
channel where the DELTS
is transmitted.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.26.6.3 When generated
This primitive is generated by the SME to initiate deletion of a TS when a higher layer protocol or
mechanism signals the STA to initiate such a deletion.
6.3.26.6.4 Effect of receipt
This primitive initiates a TS deletion procedure.
This primitive causes the local MAC entity to send out a DELTS frame containing the specified parameters.
If this primitive was generated at the HC, the frame is sent to the specified STA’s MAC address. If this
primitive was generated at the non-AP STA that is a non-DMG STA, the frame is sent to its HC. A DMG
STA sends the frame to the specified STA’s MAC address. In any of these cases, the DELTS frame does not
solicit a response from the recipient frame other than an acknowledgment to receipt of the frame.
6.3.26.7 MLME-DELTS.indication
6.3.26.7.1 Function
This primitive reports the deletion of a TS by a specified peer MAC entity or deletion of the TS due to an
inactivity timeout (HC or PCP only).
6.3.26.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DELTS.indication(
STAAddress,
TSInfo,
ReasonCode,
DMG Allocation Info,
Multi-band,
VendorSpecificInfo
)
350
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
STAAddress MACAddress Specifies the MAC address of
the STA for which the TS is
being deleted.
Present only at the HC.
TSInfo TS Info field As defined in 9.4.2.30 Specifies the TS information
of the TS of concern. Not
present when DMG
Allocation Info is present.
ReasonCode Enumeration STA_LEAVING, END_TS, Indicates the reason why the
UNKNOWN_TS, TIMEOUT, TS is being deleted.
SERVICE_CHANGE_PRECLUDES_TS
DMG Allocation DMG As defined in 9.4.2.134 Specifies the DMG allocation
Info Allocation Info under consideration. Not
field present when TSInfo is
present.
Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency band
element and channel number for the
TS under consideration. The
parameter is absent if the TS
is intended to be deleted on
the same frequency band and
channel where the DELTS is
transmitted.
VendorSpecificIn A set of As defined in 9.4.2.26 Zero or more elements.
fo elements
6.3.26.7.3 When generated
This primitive is generated by the MLME when it receives a DELTS frame from the specified peer MAC
entity.
This primitive may also be generated by the MLME at the DMG STA or HC as a result of inactivity of a
particular TS. Inactivity results when a period equal to the inactivity interval in the TSPEC for the TS
elapses
— Without arrival of an MSDU belonging to that TS at the MAC entity of the DMG STA or HC via an
MA-UNITDATA.request primitive when the DMG STA or HC is the source STA of that TS or
— Without reception of an MSDU belonging to that TS by the MAC entity of the DMG STA or HC
when the DMG STA or HC is not the source STA of that TS.
This primitive is generated after any other state concerning the TSID/direction within the MAC has been
deleted.
6.3.26.7.4 Effect of receipt
The SME is notified of the initiation of a TS deletion by a specified peer MAC entity.
6.3.26.8 MLME-ADDTSRESERVE.request
6.3.26.8.1 Function
This primitive request is used by the SME at the AP to start the AP-initiated TS setup procedure.
351
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.26.8.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDTSRESERVE.request (
TSPEC,
HigherLayerStreamID,
Schedule,
VendorSpecificInfo
)
Name Type Valid range Description
TSPEC TSPEC element As defined in 9.4.2.30 Specifies the QoS
parameters of the TS.
HigherLayerStreamID Higher Layer Stream ID As defined in 9.4.2.125 Stream identifier assigned
element by a higher layer protocol.
Schedule Schedule element As defined in 9.4.2.34 Specifies the schedule
information, service start
time, SI, and the
specification interval.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.26.8.3 When generated
This primitive is generated by the SME at the AP to start the AP-initiated TS setup procedure. If the
parameter validation on the parameters used in this primitive succeeds, an ADDTS Reserve Request frame
is transmitted from the AP to a non-AP STA.
6.3.26.8.4 Effect of receipt
The STA operates according to the procedures defined in 11.4.4.3.
6.3.26.9 MLME-ADDTSRESERVE.confirm
6.3.26.9.1 Function
This primitive is an indication to the SME that is generated by the MLME as a result of receiving an ADDTS
Reserve Response frame from the non-AP STA to which the AP sent a corresponding ADDTS Reserve
Request frame.
6.3.26.9.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDTSRESERVE.confirm (
ResultCode,
StreamID,
VendorSpecificInfo
)
352
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ResultCode Enumeration SUCCESS, FAILURE Indicates the results of the
corresponding MLME-
ADDTSReserve.request
primitive.
StreamID Higher Layer Stream ID As defined in 9.4.2.125 Stream identifier specified in
element the corresponding MLME-
ADDTSReserve.request
primitive.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.26.9.3 When generated
This primitive is generated by the MLME as a result of receiving an ADDTS Reserve Response frame from
the non-AP STA to which the AP sent a corresponding ADDTS Reserve Request action.
6.3.26.9.4 Effect of receipt
The SME is notified of the results of the AP-initiated TS setup procedure.
6.3.26.10 MLME-ADDTSRESERVE.indication
6.3.26.10.1 Function
This primitive reports to the non-AP STA’s SME the initiation of AP-initiated TS setup procedure.
6.3.26.10.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDTSRESERVE.indication (
APAddress,
TSPEC,
Schedule,
HigherLayerStreamID,
VendorSpecificInfo
)
Name Type Valid range Description
APAddress MAC Address — Contains the MAC address
of the AP initiating the TS
setup procedure.
TSPEC TSPEC element As defined in 9.4.2.30 Specifies the QoS
parameters of the TS.
Schedule Schedule element As defined in 9.4.2.34 Specifies the schedule
information, service start
time, SI, and the
specification interval.
HigherLayerStreamID Higher Layer Stream ID As defined in 9.4.2.125 Stream identifier in the
element received ADDTS Reserve
Request frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
353
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.26.10.3 When generated
This primitive is generated by the MLME at the non-AP STA as a result of the receipt of an ADDTS
Reserve Request frame from the AP to which the non-AP STA is associated.
6.3.26.10.4 Effect of receipt
The SME is notified of the receipt of the ADDTS Reserve Request frame from the AP. This primitive
solicits the SME to participate in the AP-initiated TS setup procedure.
The SME should operate according to the procedures defined in 11.4.4.3.
6.3.26.11 MLME-ADDTSRESERVE.response
6.3.26.11.1 Function
This primitive is used by a non-AP STA to indicate to the HC the completion of an AP-initiated TS setup
procedure.
6.3.26.11.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDTSRESERVE.response (
HigherLayerStreamID,
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
HigherLayerStreamID Higher Layer Stream ID As defined in 9.4.2.125 Stream identifier specified in
element the corresponding MLME-
ADDTSReserve.indication
primitive.
ResultCode Enumeration SUCCESS, FAILURE Indicates the result of the
AP-initiated TS setup
procedure.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.26.11.3 When generated
This primitive is generated by the SME at the non-AP STA to indicate to an HC that the non-AP STA has
setup a TS in response to a higher layer protocol.
6.3.26.11.4 Effect of receipt
The STA operates according to the procedures defined in 11.4.4.3.
6.3.27 Management of direct links
6.3.27.1 Introduction
This subclause describes the management procedures associated with direct links.
354
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.27.2 MLME-DLS.request
6.3.27.2.1 Function
This primitive requests the setup of a direct link with a specified peer MAC entity.
6.3.27.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DLS.request(
PeerMACAddress,
DLSTimeoutValue,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA
MAC address that is the intended immediate recipient of
the data flow.
DLSTimeoutValue Integer 0 Specifies a time limit (in seconds) after
which the direct link is terminated if there
are no frame exchange sequences with the
peer. A value of 0 implies that the direct
link is never to be terminated based on a
timeout.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.27.2.3 When generated
This primitive is generated by the SME to set up a direct link with another STA.
6.3.27.2.4 Effect of receipt
This primitive initiates a DLS procedure. In the case that a response is received from the responder STA, the
MLME subsequently issues an MLME-DLS.confirm primitive that reflects the results.
6.3.27.3 MLME-DLS.confirm
6.3.27.3.1 Function
This primitive reports the results of a DLS attempt with a specified peer MAC entity.
6.3.27.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DLS.confirm(
PeerMACAddress,
ResultCode,
CapabilityInformation,
DLSTimeoutValue,
OperationalRateSet,
HT Capabilities,
355
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
VHT Capabilities
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual MAC Specifies the MAC address of the
address STA that is the intended immediate
recipient of the data flow.
ResultCode Enumeration SUCCESS, Indicates the results of the
DLS_NOT_ALLOWED, corresponding MLME-DLS.request
NOT_PRESENT, primitive.
NOT_QOS_STA,
REFUSED
CapabilityInformati Capability As defined in 9.4.1.4 Specifies the capabilities of the peer
on Information field MAC entity.
DLSTimeoutValue Integer 0 Specifies a time limit (in seconds)
after which the direct link is
terminated if there are no frame
exchange sequences with the peer.
A value of 0 implies that the direct
link is never to be terminated based on
a timeout.
OperationalRateSet Set of integers Non-DMG BSS: 1-127 Non-DMG BSS: The set of data rates
excluding values from (in units of 500 kb/s) that the peer
Table 9-78 for each member STA is able to use for direct link
of the set communication. The peer STA is able
to receive at each of the data rates
listed in the set.
HT Capabilities As defined in As defined in 9.4.2.56 Specifies the parameters within the
frame format HT Capabilities element that are
supported by the peer MAC entity.
The parameter is optionally present if
dot11HighThroughputOptionImpleme
nted is true; otherwise not present.
VHT Capabilities As defined in As defined in 9.4.2.158 Specifies the parameters in the VHT
VHT Capabilities element that are
Capabilities supported by the peer MAC entity.
element The parameter is optionally present if
dot11VHTOptionImplemented is true
and not present otherwise.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.27.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-DLS.request primitive to establish a
direct link with a specified peer MAC entity.
6.3.27.3.4 Effect of receipt
The SME is notified of the results of the DLS procedure.
6.3.27.4 MLME-DLS.indication
6.3.27.4.1 Function
This primitive reports the establishment of a direct link with a specified peer MAC entity.
356
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.27.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DLS.indication(
PeerMACAddress,
CapabilityInformation,
DLSTimeoutValue,
OperationalRateSet,
HT Capabilities,
VHT Capabilities
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that is
MAC address the sender of the data flow.
CapabilityInformati Capability As defined in 9.4.1.4 Specifies the operational capability definitions
on Information field to be used by the peer MAC entity.
DLSTimeoutValue Integer 0 Specifies a time limit (in seconds) after which
the direct link is terminated if there are no
frame exchange sequences with the peer. A
value of 0 implies that the direct link is never
to be terminated based on a timeout.
OperationalRateSet Set of integers Non-DMG BSS: 1- Non-DMG BSS: The set of data rates (in units
127 excluding values of 500 kb/s) that the peer STA is able to use for
from Table 9-78 for direct link communication. The peer STA is
each member of the able to receive at each of the data rates listed in
set the set.
HT Capabilities As defined in As defined in Specifies the parameters within the HT
frame format 9.4.2.56 Capabilities element that are supported by peer
the MAC entity.
The parameter is optionally present if
dot11HighThroughputOptionImplemented is
true; otherwise not present.
VHT Capabilities As defined in As defined in Specifies the parameters in the VHT
VHT 9.4.2.158 Capabilities element that are supported by the
Capabilities peer MAC entity. The parameter is optionally
element present if dot11VHTOptionImplemented is
true and not present otherwise.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.27.4.3 When generated
This primitive is generated by the MLME as result of the establishment of a direct link with a specific peer
MAC entity that resulted from a DLS procedure that was initiated by that specific peer MAC entity.
6.3.27.4.4 Effect of receipt
The SME is notified of the establishment of the DLS.
6.3.27.5 MLME-DLS.response
6.3.27.5.1 Function
This primitive responds to the request for establishment of a direct link.
357
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.27.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DLS.response(
PeerMACAddress,
ResultCode,
DLSTimeoutValue,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that is
MAC address the sender of the data flow.
ResultCode Enumeration SUCCESS, Indicates the results of the corresponding
DLS_NOT_ALLOW MLME-DLS.indication primitive.
ED, REFUSED
DLSTimeoutValue Integer 0 Specifies a time limit (in seconds) after which
the direct link is terminated if there are no
frame exchange sequences with the peer.
A value of 0 implies that the direct link is
never to be terminated based on a timeout.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.27.5.3 When generated
This primitive is generated by the SME as a result of an MLME-DLS.indication primitive to initiate
establishment of a direct link.
6.3.27.5.4 Effect of receipt
This primitive causes the MAC entity to send a DLS Response frame to the requesting STA containing the
specified parameters.
6.3.27.6 MLME-DLS-TEARDOWN.request
6.3.27.6.1 Function
When initiated by a non-AP STA, this primitive requests the teardown of the direct link with a specified peer
MAC entity. When initiated by an AP, this primitive requests the teardown of direct link between two
specified MAC entities.
6.3.27.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DLS-TEARDOWN.request(
PeerMACAddress1,
PeerMACAddress2,
ReasonCode,
VendorSpecificInfo
)
358
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress1 MACAddress Any valid individual MAC Specifies the MAC address of the STA
address that is the intended immediate recipient
of the teardown.
PeerMACAddress2 MACAddress Any valid individual MAC Specifies the MAC address of the STA
address with which the DLS is being torn down.
This parameter is applicable only at the
AP.
ReasonCode Enumeration STA_LEAVING, Indicates the reason why the direct link is
END_DLS, being torn down.
PEERKEY_MISMATCH,
UNKNOWN_DLS,
TIMEOUT,
PEER_INITIATED,
AP_INITIATED
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.27.6.3 When generated
This primitive is generated by the SME for tearing down a direct link with another STA.
6.3.27.6.4 Effect of receipt
This primitive initiates a direct-link teardown procedure. The MLME subsequently issues an MLME-DLS-
TEARDOWN.confirm primitive that reflects the results.
6.3.27.7 MLME-DLS-TEARDOWN.indication
6.3.27.7.1 Function
This primitive indicates the teardown of an already established direct link with a specific peer MAC entity.
6.3.27.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DLS-TEARDOWN.indication(
PeerMACAddress,
ReasonCode,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual MAC Specifies the MAC address of the STA
address that is the sender of the data flow.
ReasonCode Enumeration STA_LEAVING, Indicates the reason why the direct link is
END_DLS, being torn down.
PEERKEY_MISMATCH,
UNKNOWN_DLS,
TIMEOUT,
PEER_INITIATED,
AP_INITIATED
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
359
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.27.7.3 When generated
This primitive is generated by the MLME as result of the teardown of a direct link with a specific peer MAC
entity that resulted from a direct link teardown procedure that was initiated either by that specific peer MAC
entity or by the local MAC entity.
6.3.27.7.4 Effect of receipt
The SME is notified of the teardown of the DLS.
6.3.28 Higher layer synchronization support
6.3.28.1 Introduction
This mechanism supports the process of synchronization among higher layer protocol entities residing
within different wireless STAs. The actual synchronization mechanism in the higher layer is out of the scope
of this standard. In principle, the MLME indicates the transmission/reception of frames with a specific group
address in the Address 1 field of a Data frame.
6.3.28.2 MLME-HL-SYNC.request
6.3.28.2.1 Function
This primitive requests activation of the synchronization support mechanism.
6.3.28.2.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-HL-SYNC.request(
GroupAddress
)
Name Type Valid range Description
GroupAddress MACAddress A group MAC Specifies the group MAC address to which the
address synchronization frames are addressed. A
synchronization frame is a Data frame with
higher layer synchronization information.
6.3.28.2.3 When generated
This primitive is generated by the SME when a higher layer protocol initiates a synchronization process.
6.3.28.2.4 Effect of Receipt
This request activates the synchronization support mechanism at the STA. The MLME issues an MLME-
HL-SYNC.indication primitive when a higher layer synchronization frame, which is a Data frame with the
specified group address in Address 1 field, is received or transmitted.
360
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.28.3 MLME-HL-SYNC.indication
6.3.28.3.1 Function
This primitive indicates the last symbol on air of a higher layer synchronization frame, whether transmitted
or received by the MAC.
6.3.28.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-HL-SYNC.indication(
SourceAddress,
SequenceNumber
)
Name Type Valid range Description
SourceAddress MACAddress Any valid individual Specifies the SA of the STA that transmitted
MAC address the higher layer synchronization frame.
SequenceNumber Integer As defined in Specifies the sequence number of the higher
9.2.4.4.2 layer synchronization frame received or
transmitted.
6.3.28.3.3 When generated
This primitive is generated by the MLME when the reception or transmission of a higher layer
synchronization frame is detected, as indicated by the PHY-RXEND.indication or PHY-TXEND.confirm
primitives generated by the PHY. The higher layer synchronization frame is identified by the group MAC
address registered by an earlier MLME-HL-SYNC.request primitive in the Address 1 field of a Data frame.
6.3.28.3.4 Effect of receipt
The SME is notified of the reception or transmission of a higher layer synchronization frame.
6.3.29 Block Ack
6.3.29.1 General
This mechanism supports the initiation (or modification) and termination of block ack.
The primitives used for this mechanism are called block ack primitives, which include MLME-ADDBA.xxx
and MLME-DELBA.xxx primitives, where xxx denotes request, confirm, indication, or response. Each
primitive contains parameters that correspond to a Block Ack Action frame body. Requests and responses
may cause these frames to be sent. Confirms and indications are emitted when an appropriate Block Ack
Action frame is received.
6.3.29.2 MLME-ADDBA.request
6.3.29.2.1 Function
This primitive requests the initiation (or modification) of block ack with a peer MAC entity.
6.3.29.2.2 Semantics of the service primitive
The primitive parameters are as follows:
361
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-ADDBA.request(
PeerSTAAddress,
DialogToken,
TID,
BlockAckPolicy,
BufferSize,
BlockAckTimeout,
BlockAckStartingSequenceControl,
GCRGroupAddress,
Multi-band,
TCLAS,
ADDBA Extension,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with
which to perform the block ack initiation (or
modification).
DialogToken Integer 0–255 Identifies the ADDBA transaction.
TID Integer 0–15 Specifies the TID of the data.
BlockAckPolicy Enumeration Immediate, Specifies the block ack policy.
Delayed
BufferSize Integer 0–1023 Specifies the number of MPDUs that can be held
in its buffer.
BlockAckTimeout Integer 0 – 65 535 Specifies the number of TUs without a frame
exchange between peers after which the block
ack agreement is considered to be torn down.
BlockAckStartingS Block Ack As defined in Specifies the value of the Block Ack Starting
equenceControl Starting 9.3.1.8 Sequence Control subfield.
Sequence
Control subfield
GCRGroupAddress GCR Group As defined in Specifies the group address for which a block ack
Address element 9.4.2.126 agreement is requested. If the element is present,
a GCR Group Address element is included in the
transmitted ADDBA Request frame.
Multi-band Multi-band As defined in Specifies the frequency band and channel number
element 9.4.2.138 where the block ack agreement is to be
established. The parameter is absent if the block
ack agreement is intended to be established on
the same frequency band and channel where the
ADDBA Request frame is transmitted.
TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the
9.4.2.31 rules and parameters by which an MSDU might
be classified to the specified TID.
ADDBA Extension ADDBA As defined in Specifies additional parameters associated with
Extension 9.4.2.139 the block ack agreement.
element
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.29.2.3 When generated
This primitive is generated by the SME to request initiation (or modification) of block ack with the specified
peer MAC entity.
362
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.29.2.4 Effect of receipt
The STA sends the ADDBA Request frame to the specified peer MAC entity.
6.3.29.3 MLME-ADDBA.confirm
6.3.29.3.1 Function
The primitive reports the results of initiation (or modification) of the block ack attempt with the specified
peer MAC entity.
6.3.29.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDBA.confirm(
PeerSTAAddress,
DialogToken,
TID,
ResultCode,
BlockAckPolicy,
BufferSize,
BlockAckTimeout,
GCRGroupAddress,
Multi-band,
TCLAS,
ADDBA Extension,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with
which the block ack initiation (or modification)
was attempted. This value matches the
PeerSTAAddress parameter specified in MLME-
ADDBA.request primitive.
DialogToken Integer 0–255 Identifies the ADDBA transaction. This value
matches the DialogToken parameter specified in
MLME-ADDBA.request primitive.
TID Integer 0–15 Specifies the TID of the data. This value matches
the TID specified in MLME-ADDBA.request
primitive.
ResultCode Enumeration SUCCESS, Indicates the result of the corresponding MLME-
REFUSED ADDBA.request primitive.
BlockAckPolicy Enumeration Immediate, Specifies the block ack policy.
Delayed
BufferSize Integer 0–1023 Specifies the maximum number of MPDUs in the
block for the specified TID.
BlockAckTimeout Integer 0 – 65 535 Specifies the number of TUs without a frame
exchange between peers after which the block
ack agreement is considered to be torn down.
GCRGroupAddress GCR Group As defined in Specifies the group address for which a block ack
Address element 9.4.2.126 agreement was requested.
363
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Multi-band Multi-band As defined in Specifies the frequency band and channel number
element 9.4.2.138 where the block ack initiation was attempted. The
parameter is absent if the block ack agreement is
intended was attempted to be established on the
same frequency band and channel where the
ADDBA Request frame is transmitted.
TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the
9.4.2.31 rules and parameters by which an MSDU might
be classified to the specified TID.
ADDBA Extension ADDBA As defined in Specifies additional parameters associated with
Extension 9.4.2.139 the block ack agreement.
element
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.29.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-ADDBA.request primitive to indicate the
results of that request.
6.3.29.3.4 Effect of receipt
The SME is notified of the results of the block ack initiation (or modification).
6.3.29.4 MLME-ADDBA.indication
6.3.29.4.1 Function
This primitive reports the initiation (or modification) of block ack by a peer MAC entity.
6.3.29.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDBA.indication(
PeerSTAAddress,
DialogToken,
TID,
BlockAckPolicy,
BufferSize,
BlockAckTimeout,
GCRGroupAddress,
Multi-band,
TCLAS,
ADDBA Extension,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity that
requested the block ack initiation (or
modification).
DialogToken Integer 0–255 Identifies the ADDBA transaction.
TID Integer 0–15 Specifies the TID of the data.
364
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
BlockAckPolicy Enumeration Immediate, Specifies the block ack policy.
Delayed
BufferSize Integer 0–1023 Specifies the number of MPDUs that can be held
in peerSTAAddress buffer.
BlockAckTimeout Integer 0 – 65 535 Specifies the number of TUs without a frame
exchange between peers after which the block
ack agreement is considered to be torn down.
GCRGroupAddress GCR Group As defined in Specifies the group address for which a block ack
Address element 9.4.2.126 agreement is requested. This element is present if
a GCR Group Address element was included in
the transmitted ADDBA Request frame.
Multi-band Multi-band As defined in Specifies the frequency band and channel number
element 9.4.2.138 where the block ack agreement is to be
established. The parameter is absent if the block
ack agreement is intended to be established on
the same frequency band and channel where the
ADDBA Request frame is transmitted.
TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the
9.4.2.31 rules and parameters by which an MSDU might
be classified to the specified TID.
ADDBA Extension ADDBA As defined in Specifies additional parameters associated with
Extension 9.4.2.139 the block ack agreement.
element
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.29.4.3 When generated
This primitive is generated by the MLME as a result of receipt of a block ack initiation (or modification) by
the specified peer MAC entity in the form of an ADDBA Request frame.
6.3.29.4.4 Effect of receipt
The SME is notified of the initiation (or modification) of the block ack by the specified peer MAC entity.
6.3.29.5 MLME-ADDBA.response
6.3.29.5.1 Function
The primitive responds to the initiation (or modification) by a specified peer MAC entity.
6.3.29.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ADDBA.response(
PeerSTAAddress,
DialogToken,
TID,
ResultCode,
BlockAckPolicy,
BufferSize,
BlockAckTimeout,
GCRGroupAddress,
Multi-band,
365
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TCLAS,
ADDBA Extension,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity that
attempted the block ack initiation (or
modification). This value matches the
PeerSTAAddress parameter specified in MLME-
ADDBA.indication primitive.
DialogToken Integer 0–255 Identifies the ADDBA transaction. This value
matches the DialogToken parameter specified in
MLME-ADDBA.indication primitive.
TID Integer 0–15 Specifies the TID of the data. This value matches
the TID specified in MLME-ADDBA.indication
primitive.
ResultCode Enumeration SUCCESS, Indicates the result of the corresponding MLME-
REFUSED ADDBA.indication primitive.
BlockAckPolicy Enumeration Immediate, Specifies the block ack policy. Undefined when
Delayed the result code is REFUSED.
BufferSize Integer 0–1023 Specifies the maximum number of MPDUs in the
block for the specified TID. Undefined when the
result code is REFUSED.
BlockAckTimeout Integer 0 – 65 535 Specifies the number of TUs without a frame
exchange between peers after which the block
ack agreement is considered to be torn down.
GCRGroupAddress GCR Group As defined in Specifies the group address for which a block ack
Address element 9.4.2.126 agreement was requested.
Multi-band Multi-band As defined in Specifies the frequency band and channel number
element 9.4.2.138 where the block ack agreement is intended to be
established. The parameter is absent if the block
ack agreement is intended to be established on
the same frequency band and channel where the
ADDBA Response frame is transmitted.
TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the
9.4.2.31 rules and parameters by which an MSDU might
be classified to the specified TID.
ADDBA Extension ADDBA As defined in Specifies additional parameters associated with
Extension 9.4.2.139 the block ack agreement.
element
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.29.5.3 When generated
This primitive is generated by the MLME as a result of an MLME-ADDBA.indication primitive to initiate
block ack by the specified peer MAC entity.
6.3.29.5.4 Effect of receipt
The primitive causes the MAC entity to send an ADDBA Response frame to the specified peer MAC entity.
366
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.29.6 MLME-DELBA.request
6.3.29.6.1 Function
This primitive requests the deletion of block ack with a peer MAC entity.
6.3.29.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DELBA.request(
PeerSTAAddress,
Direction,
TID,
ReasonCode,
Multi-band,
TCLAS,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with
which to perform the block ack deletion.
Direction Enumeration Originator, Specifies if the MAC entity initiating the MLME-
Recipient DELBA.request primitive is the originator or the
recipient of the data stream that uses the Block
Ack.
TID Integer 0–15 Specifies the TID of the MSDUs for which this
block ack agreement has been set up.
ReasonCode Enumeration STA_LEAVING, Indicates the reason why the block ack agreement
END_BA, is being deleted.
UNKNOWN_BA,
TIMEOUT
Multi-band Multi-band As defined in Specifies the frequency band and channel number
element 9.4.2.138 where the block ack agreement is to be deleted.
The parameter is absent if the block ack
agreement to be deleted is established on the
same frequency band and channel where the
DELBA frame is transmitted.
TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the
9.4.2.31 rules and parameters by which an MSDU might
be classified to the specified TID.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.29.6.3 When generated
This primitive is generated by the SME to request deletion of block ack with the specified peer MAC entity.
6.3.29.6.4 Effect of receipt
The STA sends the DELBA frame to the specified peer MAC entity.
367
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.29.7 MLME-DELBA.indication
6.3.29.7.1 Function
This primitive reports the deletion of block ack by a peer MAC entity.
6.3.29.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DELBA.indication(
PeerSTAAddress,
Direction,
TID,
ReasonCode,
Multi-band,
TCLAS,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with
which to perform the block ack deletion.
Direction Enumeration Originator, Specifies if the MAC entity initiating the MLME-
Recipient DELBA.request primitive is the originator or the
recipient of the data stream that uses block ack.
TID Integer 0–15 Specifies the TID of the MSDUs for which this
block ack agreement has been set up.
ReasonCode Enumeration STA_LEAVING, Indicates the reason why the block ack agreement
END_BA, is being deleted.
UNKNOWN_BA,
TIMEOUT
Multi-band Multi-band As defined in Specifies the frequency band and channel number
element 9.4.2.138 where block ack agreement is to be deleted. The
parameter is absent if the block ack deletion
refers to the same frequency band and channel
where the DELBA frame is transmitted.
TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the
9.4.2.31 rules and parameters by which an MSDU might
be classified to the specified TID.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.29.7.3 When generated
This primitive is generated by the MLME as a result of receipt of a block ack deletion by the specified peer
MAC entity in the form of a DELBA frame.
6.3.29.7.4 Effect of receipt
The SME is notified of the deletion of the block ack by the specified peer MAC entity.
368
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.30 Schedule element management
6.3.30.1 Introduction
This subclause describes the management procedures associated with the QoS Schedule element.
The primitives defined are MLME-SCHEDULE.request and MLME-SCHEDULE.indication.
6.3.30.2 MLME-SCHEDULE.request
6.3.30.2.1 Function
This primitive requests transmission of a Schedule frame. It is valid at the HC.
6.3.30.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SCHEDULE.request(
STAAddress,
Schedule,
VendorSpecificInfo
)
Name Type Valid range Description
STAAddress MACAddress Any valid individual MAC address of the STA to which the
address Schedule frame shall be sent.
Schedule Schedule As defined in Specifies the schedule for the STA,
element 9.4.2.34 including the SI (minimum and
maximum), TXOP duration (minimum
and maximum), and specification interval.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.30.2.3 When generated
This primitive is generated by the SME at the HC to send the schedule information, in the form of a
Schedule frame, to a specified STA when the schedule information for the STA is changed.
6.3.30.2.4 Effect of receipt
This primitive causes the MAC entity at the HC to send a Schedule frame to the STA specified in the
primitive containing the specified Schedule parameters.
6.3.30.3 MLME-SCHEDULE.indication
6.3.30.3.1 Function
This primitive reports the reception of a new schedule by the STA in the form of a Schedule frame.
369
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.30.3.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-SCHEDULE.indication(
Schedule,
VendorSpecificInfo
)
Name Type Valid range Description
Schedule Schedule As defined in Specifies the schedule for the STA, including the
element 9.4.2.34 SI (minimum and maximum), TXOP duration
(minimum and maximum), and specification
interval.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.30.3.3 When generated
This primitive is generated by the MLME as a result of receipt of a new schedule in the form of a Schedule
frame.
6.3.30.3.4 Effect of receipt
The SME is notified of the receipt of QoS schedule in the form of a Schedule frame. The new Schedule
parameters overwrite the previously stored values.
6.3.31 Vendor-specific action
6.3.31.1 Introduction
This set of primitives supports the signaling of (Protected) Vendor Specific frames among peer SMEs.
6.3.31.2 MLME-VSPECIFIC.request
6.3.31.2.1 Function
This primitive requests transmission of a Vendor Specific frame.
6.3.31.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-VSPECIFIC.request(
PeerMACAddress,
Protected,
Organization Identifier,
VendorSpecificContent
)
370
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer MAC entity or
MAC address or any group of entities to which the Vendor
valid group MAC Specific frame is sent.
address
Protected Boolean true, false Specifies whether the request is sent
using a robust Management frame.
If true, the request is sent using a
Protected Vendor Specific frame.
If false, the request is sent using a
Vendor Specific frame.
Organization Identifier As defined in As defined in Contains a public value assigned by
9.4.1.32 9.4.1.32 the IEEE to identify the organization
that has defined the content of the
particular vendor-specific action.
VendorSpecificContent Determined by the Determined by the Vendor-specific content.
entity to whom the entity to whom the
Organization Organization
Identifier is Identifier is
registered registered
6.3.31.2.3 When generated
This primitive is generated by the SME to request that a Vendor Specific frame be sent.
6.3.31.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Vendor Specific frame containing the set of elements
and vendor-specific fields. The STA then attempts to transmit the frame.
6.3.31.3 MLME-VSPECIFIC.indication
6.3.31.3.1 Function
This primitive indicates that a Vendor Specific frame has been received from a peer entity.
6.3.31.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-VSPECIFIC.indication(
PeerMACAddress,
Protected,
Organization Identifier,
RCPI,
VendorSpecificContent
)
371
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MACAddress Any valid The address of the peer MAC entity from
individual MAC which the Vendor Specific frame was
address received.
Protected Boolean true, false Specifies whether the request was received
using a robust Management frame.
If true, the request was received using a
Protected Vendor Specific frame.
If false, the request was received using a
Vendor Specific frame.
Organization Identifier As defined in As defined in Contains a public value assigned by the
9.4.1.32 9.4.1.32 IEEE to identify the organization that has
defined the content of the particular vendor-
specific action.
RCPI As defined in As defined in Present when dot11OCBActivated is true.
9.4.2.38 9.4.2.38 RCPI is the measured value of received
channel power on the received Vendor
Specific frame.
VendorSpecificContent Determined by the Determined by the Vendor-specific content.
entity to whom the entity to whom the
Organization Organization
Identifier is Identifier is
registered registered
6.3.31.3.3 When generated
This primitive is generated by the MLME when a valid Vendor Specific frame is received.
6.3.31.3.4 Effect of receipt
On receipt of this primitive, the vendor specific content can be made available for SME processes.
6.3.32 Neighbor report request
6.3.32.1 General
The following MLME primitives support the signaling of neighbor report requests.
6.3.32.2 MLME-NEIGHBORREPREQ.request
6.3.32.2.1 Function
This primitive requests that a Neighbor Report Request frame be sent to the AP with which the STA is
associated. It is valid only at a radio measurement capable STA.
6.3.32.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-NEIGHBORREPREQ.request(
DialogToken,
SSID,
LCI Measurement Request,
Location Civic Measurement Request,
VendorSpecificInfo
)
372
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DialogToken Integer 1–255 The dialog token to identify the neighbor report
transaction.
SSID As defined in the As defined in the Optional SSID element to request a neighbor list for a
SSID element SSID element specific SSID.
LCI As defined in As defined in Optional element included to request LCI information
Measurement 9.6.7.6 9.6.7.6 in Neighbor Report elements
Request
Location Civic As defined in As defined in Optional element included to request location civic
Measurement 9.6.7.6 9.6.7.6 information in Neighbor Report elements
Request
VendorSpecificI A set of As defined in Zero or more elements.
nfo elements 9.4.2.26
6.3.32.2.3 When generated
This primitive is generated by the SME to request that a Neighbor Report Request frame be sent to the AP
with which the STA is associated to request a neighbor report.
6.3.32.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Neighbor Report Request frame. The STA then
attempts to transmit this to the AP with which it is associated.
6.3.32.3 MLME-NEIGHBORREPREQ.indication
6.3.32.3.1 Function
This primitive indicates that a Neighbor Report Request frame was received. It is valid only at a radio
measurement capable AP.
6.3.32.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-NEIGHBORREPREQ.indication(
PeerSTAAddress,
DialogToken,
SSID,
LCI Measurement Request,
Location Civic Measurement Request,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddres MACAddress Any valid The address of the STA’s MAC entity from which a
s individual MAC Neighbor Report Request frame was received.
address
DialogToken Integer 1–255 The dialog token in the Neighbor Report Request frame
that was received.
SSID As defined in the As defined in the Optional SSID element to request a neighbor list for a
SSID element SSID element specific SSID.
373
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
LCI As defined in As defined in Optional element included to request LCI information
Measurement 9.6.7.6 9.6.7.6 in Neighbor Report elements
Request
Location Civic As defined in As defined in Optional element included to request location civic
Measurement 9.6.7.6 9.6.7.6 information in Neighbor Report elements
Request
VendorSpecificI A set of As defined in Zero or more elements.
nfo elements 9.4.2.26
6.3.32.3.3 When generated
This primitive is generated by the MLME when a valid Neighbor Report Request frame is received.
6.3.32.3.4 Effect of receipt
On receipt of this primitive, the SME operates according to the procedure in 11.11.10.3.
6.3.33 Neighbor report response
6.3.33.1 General
The following MLME primitives support the signaling of neighbor report responses.
6.3.33.2 MLME-NEIGHBORREPRESP.request
6.3.33.2.1 Function
This primitive requests that a neighbor report response be sent. This may be in response to an MLME-
NEIGHBORREPREQ.indication primitive or an autonomous request. It is valid only at a radio
measurement capable AP.
6.3.33.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-NEIGHBORREPRESP.request(
PeerSTAAddress,
DialogToken,
NeighborListSet,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the STA’s MAC entity to which a
individual Neighbor Report Response frame is to be sent.
MAC address
DialogToken Integer 0–255 The dialog token to identify the neighbor report
transaction. Set to the value received in the
corresponding MLME-
NEIGHBORREPREQ.indication primitive or to 0 for
an autonomous report.
374
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
NeighborListSet Set of Neighbor As defined in A set of Neighbor List elements, each representing a
List elements 9.4.2.37 neighboring AP being reported as defined in the
each as defined Neighbor Report element format.
in the Neighbor
Report element
format
VendorSpecificInf A set of As defined in Zero or more elements.
o elements 9.4.2.26
6.3.33.2.3 When generated
This primitive is generated by the SME to request a neighbor report be sent. This may be in response to an
earlier MLME-NEIGHBORREPREQ.indication primitive or a request to transmit an autonomous report.
6.3.33.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Neighbor Report Response frame. The STA then
attempts to transmit this to the STA indicated by the PeerSTAAddress parameter.
6.3.33.3 MLME-NEIGHBORREPRESP.indication
6.3.33.3.1 Function
This primitive indicates that a neighbor report response has been received. This may be in response to an
earlier neighbor report request (MLME-NEIGHBORREPREQ.request primitive) or an autonomous report.
It is valid only at a radio measurement capable STA.
6.3.33.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-NEIGHBORREPRESP.indication(
PeerSTAAddress,
DialogToken,
NeighborListSet,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the AP from which the Neighbor
individual MAC Report Response frame was received.
address
DialogToken Integer 0–255 The Dialog Token received in the Neighbor
Report Response frame to identify the neighbor
report transaction.
NeighborListSet Set of Neighbor As defined in A set of Neighbor List elements derived from the
List elements, 9.4.2.37 MIB table dot11RMNeighborReportTable, each
each as defined in representing a neighboring AP being reported as
the Neighbor defined in the Neighbor Report element format.
Report element
format
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
375
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.33.3.3 When generated
This primitive is generated by the MLME when a valid Neighbor Report Response frame is received.
6.3.33.3.4 Effect of receipt
The SME is notified of the receipt of the neighbor report data.
6.3.34 Link Measure Request
6.3.34.1 General
The following primitives support the measurement of link path loss and the estimation of link margin
between peer entities.
6.3.34.2 MLME-LINKMEASURE.request
6.3.34.2.1 Function
This primitive supports the measurement of link path loss and the estimation of link margin between peer
entities.
NOTE—The layer management model used assumes that the handling of a received Link Measurement Request frame is
entirely within the MLME. Correspondingly there are no MLME-SME primitives specified for the peer side of a link
measurement request transaction.
6.3.34.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-LINKMEASURE.request(
PeerMACAddress,
DialogToken,
Transmit Power,
Max Transmit Power,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAdd MACAddress Any valid The address of the peer MAC entity to which the Link
ress individual MAC Measure Request shall be sent.
address
DialogToken Integer 1–255 The dialog token to identify the Link Measure
transaction.
Transmit Integer As defined in The transmit power to be used when transmitting the
Power 9.6.7.4 Link Measurement Request frame and included in the
frame body. See 9.6.7.4.
Max Transmit Integer As defined in The maximum transmit power to be used by the
Power 9.6.7.4 transmitting STA on its operating channel. See 9.6.7.5.
VendorSpecifi A set of As defined in Zero or more elements.
cInfo elements 9.4.2.26
6.3.34.2.3 When generated
This primitive is generated by the SME to request that a Link Measurement Request frame be sent to the
peer entity to request that entity to report transmit power and link margin information.
376
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.34.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Link Measurement Request frame. The STA then
attempts to transmit this to the STA indicated in the PeerMACAddress parameter.
6.3.34.3 MLME-LINKMEASURE.confirm
6.3.34.3.1 Function
This primitive reports the result of a Link Measurement request.
6.3.34.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-LINKMEASURE.confirm(
ResultCode,
DialogToken,
TransmitPower,
LinkMargin,
RCPI of Request,
RSNI of Request,
RCPI of Report,
RSNI of Report,
ReceiveAntennaID,
TransmitAntennaID,
VendorSpecificInfo
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates the result of the corresponding
UNSPECIFIED FAILURE MLME-LINKMEASURE.request
primitive.
DialogToken Integer As defined in the The dialog token to identify the link
corresponding MLME-LINK- measurement transaction.
MEASURE.request primitive
TransmitPower As defined in the As defined in the TPC Report The contents of the Transmit Power field
TPC Report element of the received Link Measurement
element Report frame. Present if
ResultCode = SUCCESS; otherwise not
present.
LinkMargin As defined in the As defined in the TPC Report The contents of the Link Margin field of
TPC Report element the received Link Measurement Report
element frame. Present if ResultCode =
SUCCESS; otherwise not present.
RCPI of Request Integer As defined in 9.4.2.38 Indicates the RCPI value contained in the
corresponding Link Measurement Report
frame received at the requesting STA.
Present if ResultCode = SUCCESS;
otherwise not present.
RSNI of Request Integer As defined in 9.4.2.41 Indicates the RSNI value contained in the
corresponding Link Measurement Report
frame received at the requesting STA.
Present if ResultCode = SUCCESS;
otherwise not present
377
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
RCPI of Report Integer As defined in 9.4.2.38 The RCPI level of the corresponding
Link Measurement Report frame
received at the requesting STA. Present if
ResultCode = SUCCESS; otherwise not
present.
RSNI of Report Integer As defined in 9.4.2.41 The RSNI of the corresponding Link
Measurement Report frame received at
the requesting STA. Present if
ResultCode = SUCCESS; otherwise not
present.
Receive Integer 0–255 The Antenna ID corresponding to the
Antenna ID antenna on which the Link Measurement
Request frame was received at the
reporting STA. Antenna ID is defined in
9.4.2.29.
Transmit Integer 0–255 The Antenna ID corresponding to the
Antenna ID antenna used to transmit the Link
Measurement Report frame. Antenna ID
is defined in 9.4.2.29.
VendorSpecificI A set of As defined in 9.4.2.26 Zero or more elements.
nfo elements
6.3.34.3.3 When generated
This primitive is generated by the MLME when a valid Link Measurement Report frame is received from
the requested STA.
6.3.34.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the ResultCode and may use the reported data.
6.3.35 MLME SAP interface for resource request
6.3.35.1 MLME-RESOURCE-REQUEST.request
6.3.35.1.1 Function
This primitive is used to perform the over-the-air resource request of an FT resource request protocol. The
over-the-air resource request is performed using Authentication frames, with an authentication algorithm
number corresponding to FT authentication and an authentication algorithm sequence number of 3 or 4.
6.3.35.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RESOURCE-REQUEST.request(
PeerMACAddress,
Contents of FT Authentication elements,
VendorSpecificInfo
)
378
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the AP that is
MAC address the intended immediate recipient of the
resource request.
Content of FT Sequence of As defined in 13.8 The set of elements to be included in the FT
Authentication elements elements Confirm frame, as described in 13.8.4.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.35.1.3 When generated
This primitive is generated by the SME to send the third frame of the over-the-air FT resource request
protocol. The third frame is an Authentication frame, with an number corresponding to FT authentication
and an Authentication algorithm sequence number of 3.
6.3.35.1.4 Effect of receipt
Upon receipt of this primitive, the MLME constructs the appropriate Authentication frame and causes it to
be transmitted to the peer MAC address.
6.3.35.2 MLME-RESOURCE-REQUEST.indication
6.3.35.2.1 Function
This primitive is used to enact the security and QoS resource request with a specified peer MAC entity.
6.3.35.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RESOURCE-REQUEST.indication(
PeerMACAddress,
Content of FT Authentication elements,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that
MAC address was the sender of the resource request.
Content of FT Sequence of As defined in 13.8 The set of elements included in the FT
Authentication elements elements Confirm frame, as described in 13.8.4.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.35.2.3 When generated
This primitive is generated by the MLME at an AP to indicate that the third frame of the over-the-air FT
resource request protocol has been received. The third frame is an Authentication frame, with an
authentication algorithm number corresponding to FT authentication and an authentication algorithm
sequence number of 3.
6.3.35.2.4 Effect of receipt
Upon receipt of this primitive, the SME examines the Transition element and RSNE contents and responds
to the peer MAC address using the MLME-RESOURCE-REQUEST.response primitive.
379
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.35.3 MLME-RESOURCE-REQUEST.response
6.3.35.3.1 Function
This primitive is used to enact the security and QoS resource request protocol with a specified peer MAC
entity.
6.3.35.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RESOURCE-REQUEST.response(
PeerMACAddress,
Content of FT Authentication elements,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that
MAC address is the intended immediate recipient of the
resource response.
Content of FT Sequence of As defined in 13.8 The set of elements to be included in the FT
Authentication elements elements Ack frame, as described in 13.8.5. This
includes an optional response to a resource
request (RIC).
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.35.3.3 When generated
This primitive is generated by the SME at an AP to cause the transmission of the fourth frame in the over-
the-air FT resource request protocol. The fourth frame is an Authentication frame, with an authentication
algorithm number corresponding to FT authentication and an authentication algorithm sequence number
of 4.
6.3.35.3.4 Effect of receipt
Upon receipt of this primitive, the MLME constructs the appropriate Authentication frame and causes it to
be transmitted to the peer MAC address.
6.3.35.4 MLME-RESOURCE-REQUEST.confirm
6.3.35.4.1 Function
This primitive is used to enact the security and QoS resource request protocol with a specified peer MAC
entity.
6.3.35.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RESOURCE-REQUEST.confirm(
PeerMACAddress,
Content of FT Authentication elements,
VendorSpecificInfo
)
380
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the AP that
MAC address was the sender of the resource response.
Content of FT Sequence of As defined in 13.8 The set of elements included in the FT Ack
Authentication elements elements frame, as described in 13.8.5. This includes
an optional response to a resource request
(RIC).
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.35.4.3 When generated
This primitive is generated by the MLME on receipt of the fourth frame in the FT resource request protocol.
6.3.35.4.4 Effect of receipt
Upon receipt of this primitive, the SME examines the content of the message and completes its processing of
the resource request.
6.3.35.5 MLME-RESOURCE-REQUEST-LOCAL.request
6.3.35.5.1 Function
This primitive is used to enact the over-the-DS FT resource request protocol for a specified peer MAC
entity. The over-the-DS FT resource request protocol is performed by communication between the STA and
the SME of the target AP, bypassing the MAC of the target AP. This MLME function is used to allow the
MAC of the target AP to process the resource requests.
6.3.35.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RESOURCE-REQUEST-LOCAL.request(
MACAddress,
Content of Resource Descriptor(s)
)
Name Type Valid range Description
MACAddress MACAddress Any valid individual Specifies the MAC address of the STA that
MAC address is making the resource request.
Content of Resource Sequence of As defined in 13.11.2 Specifies the resource(s) that are being
Descriptor(s) elements requested.
6.3.35.5.3 When generated
This primitive is generated by the SME at a target AP upon receiving an over-the-DS resource request to
request resources within the local MAC.
6.3.35.5.4 Effect of receipt
Upon receipt of this primitive, the MAC checks for resource availability and allocates resources as
requested.
381
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.35.6 MLME-RESOURCE-REQUEST-LOCAL.confirm
6.3.35.6.1 Function
This primitive is used to respond to a local resource request for resources from the SME.
6.3.35.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RESOURCE-REQUEST-LOCAL.confirm(
MACAddress,
Content of Resource Descriptor(s),
ResultCode
)
Name Type Valid range Description
MACAddress MACAddress Any valid individual Specifies the MAC address of the STA that
MAC address is making the resource request.
Content of Resource Sequence of As defined in 13.11.2 Specifies the resource(s) that were allocated
Descriptor(s) elements or could have been allocated.
ResultCode Enumeration SUCCESS, Indicates the result of the outcome of a
REFUSED, resource request.
UNSPECIFIED
FAILURE
6.3.35.6.3 When generated
This primitive is generated by the MAC in response to a local resource request for resources via MLME-
RESOURCE-REQUEST-LOCAL.request primitive.
6.3.35.6.4 Effect of receipt
Upon receipt of this primitive, the SME prepares a success or failure response to be sent to the STA via the
current AP.
6.3.36 MLME SAP interface for remote requests
6.3.36.1 MLME-REMOTE-REQUEST.request
6.3.36.1.1 Function
This primitive is used by the SME of a non-AP STA (to send over-the-DS requests) and the SME of an AP
(to send over-the-DS responses) to request the MAC to send an FT Action frame.
6.3.36.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-REMOTE-REQUEST.request(
PeerMACAddress,
Content of FT Action Frame
)
382
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that
MAC address is the destination of the Action frame
Content of FT Action Sequence of As defined in 9.6.9 The Action frame to send to the STA.
Frame octets
6.3.36.1.3 When generated
This primitive is generated by the SME to send an FT Action frame to a specific peer MAC entity.
6.3.36.1.4 Effect of receipt
Upon receipt of this primitive, the MAC forwards the Action frame to the STA identified in the Action
frame.
6.3.36.2 MLME-REMOTE-REQUEST.indication
6.3.36.2.1 Function
This primitive is used by the MAC to indicate to the SME the reception of an FT Action frame.
6.3.36.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-REMOTE-REQUEST.indication(
PeerMACAddress,
Contents of FT Action Frame
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that
MAC address issued the Action frame.
Content of FT Action Sequence of As defined in 9.6.9 The Action frame received from the STA.
Frame octets
6.3.36.2.3 When generated
This primitive is generated by the MAC as a result of the receipt of an FT Action frame from a specific peer
MAC entity.
6.3.36.2.4 Effect of receipt
Upon receipt of this primitive, the remote request broker (RRB) in the SME of the current AP forwards the
Action frame to the target AP identified in the Action frame.
6.3.37 Extended channel switch announcement
6.3.37.1 General
The following MLME primitives support the signaling of extended channel switch announcement.
383
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.37.2 MLME-EXTCHANNELSWITCH.request
6.3.37.2.1 Function
This primitive requests that a (Protected) Extended Channel Switch Announcement frame be sent by an AP
or mesh STA.
6.3.37.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EXTCHANNELSWITCH.request(
Mode,
OperatingClass,
ChannelNumber,
ChannelSwitchCount,
Protected,
Mesh Channel Switch Parameters,
New Country,
Wide Bandwidth Channel Switch,
New Transmit Power Envelope,
VendorSpecificInfo
)
Name Type Valid range Description
Mode Integer 0,1 Channel switch mode, as defined for the
Extended Channel Switch Announcement
element.
OperatingClass Integer As defined in Specifies the new operating class.
Annex E
ChannelNumber Integer As defined in Specifies the new channel number.
Annex E
ChannelSwitchCo As defined in As defined in Specifies the time period until the channel switch
unt 9.4.2.53 9.4.2.53 event, as described in 9.4.2.53
Protected Boolean true, false Specifies whether the request is sent using a
robust Management frame.
If true, the request is sent using the Protected
Extended Channel Switch Announcement frame.
If false, the request is sent using the Extended
Channel Switch Announcement frame.
Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Parameters
Switch 9.4.2.103 9.4.2.103 used by a mesh STA. This parameter is present if
Parameters the dot11MeshActivated is true; otherwise, the
parameter is not present.
New Country As defined in As defined in Specifies the country, operating class table and
9.4.2.9 9.4.2.9 operating classes used for the BSS after the
channel switch. Optionally present if
dot11VHTOptionImplemented is true.
Wide Bandwidth As defined in As defined in Specifies channel parameters used when
Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz.
The parameter is present if
dot11VHTOptionImplemented is true and
switching to a channel width wider than 40 MHz;
otherwise, the parameter is not present.
384
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
New Transmit Set of New N/A Specifies power parameters used for the BSS
Power Envelope Transmit Power after the channel switch. Optionally present if
Envelope elements dot11VHTOptionImplemented is true.
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
6.3.37.2.3 When generated
This primitive is generated by the STA management entity (SME) to request that a (Protected) Extended
Channel Switch Announcement frame be sent to a STA that is associated to the AP or to peer mesh STAs in
the MBSS.
6.3.37.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs and transmits a (Protected) Extended Channel Switch
Announcement frame.
6.3.37.3 MLME-EXTCHANNELSWITCH.confirm
6.3.37.3.1 Function
This primitive reports the result of a request to switch channel.
6.3.37.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EXTCHANNELSWITCH.confirm(
VendorSpecificInfo
)
Name Type Valid range Description
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
6.3.37.3.3 When generated
This primitive is generated by the MLME when an extended channel switch request completes. Possible
unspecified failure causes include an inability to schedule an extended channel switch announcement.
6.3.37.3.4 Effect of receipt
The SME is notified of the results of the extended channel switching procedure.
6.3.37.4 MLME-EXTCHANNELSWITCH.indication
6.3.37.4.1 Function
This primitive indicates that a (Protected) Extended Channel Switch Announcement frame was received
from an AP or from a peer mesh STA.
385
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.37.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EXTCHANNELSWITCH.indication(
Peer MAC Address,
Mode,
OperatingClass,
ChannelNumber,
ChannelSwitchCount,
Protected,
Mesh Channel Switch Parameters,
New Country,
Wide Bandwidth Channel Switch,
New Transmit Power Envelope,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC MACAddress Any valid The address of the peer MAC entity from which
Address individual MAC the Extended Channel Switch Announcement
address frame was received.
Mode Integer 0, 1 Channel switch mode, as defined for the Channel
Switch Announcement element.
OperatingClass Integer As defined in Specifies the new operating class.
Annex E
ChannelNumber Integer As defined in Specifies the new channel number.
Annex E
ChannelSwitchCo As defined in As defined in Specifies the time period until the channel switch
unt 9.4.2.53 9.4.2.53 event, as described in 9.4.2.53
Protected Boolean true, false Specifies whether the request was received using
a robust Management frame.
If true, the request was received using the
Protected Extended Channel Switch
Announcement frame.
If false, the request was received using the
Extended Channel Switch Announcement frame.
Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Parameters
Switch 9.4.2.103 9.4.2.103 used by a mesh STA. This parameter is present if
Parameters the dot11MeshActivated is true; otherwise, the
parameter is not present.
New Country As defined in As defined in Specifies the country, operating class table and
9.4.2.9 9.4.2.9 operating classes used for the BSS after the
channel switch. Optionally present if
dot11VHTOptionImplemented is true.
Wide Bandwidth As defined in As defined in Specifies channel parameters used when
Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz.
The parameter is present if
dot11VHTOptionImplemented is true and
switching to a channel width wider than 40 MHz;
otherwise, the parameter is not present.
New Transmit Set of New N/A Specifies power parameters used for the BSS
Power Envelope Transmit Power after the channel switch. Optionally present if
Envelope elements dot11VHTOptionImplemented is true.
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
386
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.37.4.3 When generated
This primitive is generated by the MLME when a valid (Protected) Extended Channel Switch
Announcement frame is received.
6.3.37.4.4 Effect of receipt
On receipt of this primitive, the SME decides whether to accept the switch request.
6.3.37.5 MLME-EXTCHANNELSWITCH.response
6.3.37.5.1 Function
This primitive is used to schedule an accepted extended channel switch.
6.3.37.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EXTCHANNELSWITCH.response(
Mode,
OperatingClass,
ChannelNumber,
ChannelSwitchCount,
Mesh Channel Switch Parameters,
New Country,
Wide Bandwidth Channel Switch,
New Transmit Power Envelope,
VendorSpecificInfo
)
Name Type Valid range Description
Mode Integer 0, 1 Channel switch mode, as defined for the Channel
Switch Announcement element.
OperatingClass Integer As defined in Specifies the new operating class.
Annex E
ChannelNumber Integer As defined in Specifies the new channel number.
Annex E
ChannelSwitchCo As defined in As defined in Specifies the time period until the channel switch
unt 9.4.2.53 9.4.2.53 event, as described in 9.4.2.53
Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Parameters
Switch 9.4.2.103 9.4.2.103 used by a mesh STA. This parameter is present if
Parameters the dot11MeshActivated is true; otherwise, the
parameter is not present.
New Country As defined in As defined in Specifies the country, operating class table and
9.4.2.9 9.4.2.9 operating classes used for the BSS after the
channel switch. Optionally present if
dot11VHTOptionImplemented is true.
Wide Bandwidth As defined in As defined in Specifies channel parameters used when
Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz.
The parameter is present if
dot11VHTOptionImplemented is true and
switching to a channel width wider than 40 MHz;
otherwise, the parameter is not present.
387
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
New Transmit Set of New N/A Specifies power parameters used for the BSS
Power Envelope Transmit Power after the channel switch. Optionally present if
Envelope elements dot11VHTOptionImplemented is true.
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
6.3.37.5.3 When generated
This primitive is generated by the SME to schedule an accepted extended channel switch request.
6.3.37.5.4 Effect of receipt
On receipt of this primitive, the MLME schedules the extended channel switch.
6.3.38 DSE power constraint announcement
6.3.38.1 General
The following MLME primitives support the signaling of DSE power constraint to dependent STAs.
6.3.38.2 MLME-DSETPC.request
6.3.38.2.1 Function
This primitive requests that a (Protected) DSE Power Constraint frame be sent by an enabling STA.
6.3.38.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DSETPC.request(
RequesterSTAAddress,
ResponderSTAAddress,
DSELocalPowerConstraint,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
RequesterSTAAdd MACAddress Any valid Specifies the address of the MAC entity of the
ress individual MAC enabling STA.
address
ResponderSTAAd MACAddress Any valid Specifies the address of the MAC entity that
dress individual MAC initiates the enablement process.
address
DSELocalPowerC Integer 0–255 Specifies the local power constraint, as described
onstraint in the DSE Power Constraint frame (see
9.6.8.10).
388
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Protected Boolean true, false Specifies whether the request is sent using a
robust Management frame.
If true, the request is sent using the Protected
DSE Power Constraint frame.
If false, the request is sent using the DSE Power
Constraint frame.
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
6.3.38.2.3 When generated
This primitive is generated by the SME to request that a (Protected) DSE Power Constraint Announcement
frame be sent to a dependent STA.
6.3.38.2.4 Effect of receipt
Upon receipt of this primitive, the MLME constructs a (Protected) DSE Power Constraint Announcement
frame. The enabling STA then schedules this frame for transmission.
6.3.38.3 MLME-DSETPC.confirm
6.3.38.3.1 Function
This primitive reports the results of a request to send a (Protected) DSE Power Constraint Announcement
frame.
6.3.38.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DSETPC.confirm(
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates the result of MLME-DSETPC.request
REFUSED primitive.
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
6.3.38.3.3 When generated
This primitive is generated by the MLME when a DSE power constraint announcement completes.
6.3.38.3.4 Effect of receipt
The SME is notified of the results of the DSE power constraint procedure.
389
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.38.4 MLME-DSETPC.indication
6.3.38.4.1 Function
This primitive indicates that a DSE Power Constraint Announcement frame was received from an enabling
STA.
6.3.38.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DSETPC.indication(
RequesterSTAAddress,
ResponderSTAAddress,
DSELocalPowerConstraint,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
RequesterSTAAddr MACAddress Any valid Specifies the address of the peer MAC entity that
ess individual MAC initiated the enablement process.
address
ResponderSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity that
ress individual MAC is the enabling STA.
address
DSELocalPowerCo Integer 0–255 Specifies the local power constraint, as described
nstraint in the DSE Power Constraint frame (see
9.6.8.10).
Protected Boolean true, false Specifies whether the request was received using
a robust Management frame.
If true, the request was received using the
Protected DSE Power Constraint frame.
If false, the request was received using the DSE
Power Constraint frame.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.38.4.3 When generated
This primitive is generated by the MLME when a valid (Protected) DSE Power Constraint Announcement
frame is received.
6.3.38.4.4 Effect of receipt
On receipt of this primitive, the SME performs the DSE power constraint procedure (see 11.12.5).
6.3.38.5 MLME-DSETPC.response
6.3.38.5.1 Function
This primitive is used to report the result of the DSE power constraint procedure.
390
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.38.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DSETPC.response(
RequesterSTAAddress,
ResponderSTAAddress,
ResultCode,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
RequesterSTAAddr MACAddress Any valid Specifies the address of the MAC entity of the
ess individual MAC enabling STA.
address
ResponderSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity that
ress individual MAC initiates the enabling process.
address
ResultCode Enumeration SUCCESS, Reports the result of a DSE power constraint
REFUSED procedure.
Protected Boolean true, false Specifies whether the response is sent using a
robust Management frame.
If true, the response is sent using the Protected
DSE Power Constraint frame.
If false, the response is sent using the DSE Power
Constraint frame.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.38.5.3 When generated
This primitive is generated by the SME to schedule a response to DSE power constraint announcement.
6.3.38.5.4 Effect of receipt
On receipt of this primitive, the MLME schedules the transmission of a (Protected) DSE power constraint
result to the enabling STA that sent the DSE power constraint announcement.
6.3.39 Enablement
6.3.39.1 General
This mechanism supports the process of establishing an enablement relationship with a peer MAC entity.
6.3.39.2 MLME-ENABLEMENT.request
6.3.39.2.1 Function
This primitive requests enablement with a specified peer MAC entity.
6.3.39.2.2 Semantics of the service primitive
The primitive parameters are as follows:
391
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-ENABLEMENT.request(
RequesterSTAAddress,
ResponderSTAAddress,
EnablementTimeLimit,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
RequesterSTAAdd MACAddress Any valid Specifies the address of the MAC entity that
ress individual MAC initiates the enablement process.
address
ResponderSTAAd MACAddress Any valid Specifies the address of the MAC entity of the
dress individual MAC enabling STA.
address
EnablementTimeL Integer >0 Specifies a time limit (in TU) after which the
imit enablement process is terminated.
Protected Boolean true, false Specifies whether the request is sent using a
robust Management frame.
If true, the request is sent using the Protected
DSE Enablement frame.
If false, the request is sent using the DSE
Enablement frame.
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
6.3.39.2.3 When generated
This primitive is generated by the SME for a STA to establish enablement with a specified peer MAC entity.
During the enablement procedure, the SME can generate additional MLME-ENABLEMENT.request
primitives.
6.3.39.2.4 Effect of receipt
This primitive initiates an enablement procedure. In the case that a response is received from the responder
STA, the MLME subsequently issues an MLME-ENABLEMENT.confirm primitive that reflects the results.
6.3.39.3 MLME-ENABLEMENT.confirm
6.3.39.3.1 Function
This primitive reports the results of an enablement attempt with a specified peer MAC entity.
6.3.39.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ENABLEMENT.confirm(
RequesterSTAAddress,
ResponderSTAAddress,
ResultCode,
Protected,
392
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
EnablementIdentifier,
VendorSpecificInfo
)
Name Type Valid range Description
RequesterSTAAddr MACAddress Any valid Specifies the address of the MAC entity that
ess individual MAC initiated the enablement process. This value
address matches the RequesterSTAAddress parameter
specified in the corresponding MLME-
ENABLEMENT.request primitive.
ResponderSTAAdd MACAddress Any valid Specifies the address of the peerMAC entity with
ress individual MAC which the enablement process was
address attempted.This value matches the
ResponderSTAAddress parameter specified in
the corresponding MLME-
ENABLEMENT.request primitive.
ResultCode Enumeration SUCCESS, Indicates the result of MLME-
REFUSED, ENABLEMENT.request primitive.
TOO_MANY_SI
MULTANEOUS_
REQUESTS
EnablementIdentifi Integer 0 – 65 535 Specifies the dependent enablement identifier.
er
Protected Boolean true, false Specifies whether the response was received
using a robust Management frame.
If true, the response was received using the
Protected DSE Enablement frame.
If false, the response was received using the DSE
Enablement frame.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.39.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-ENABLEMENT.request primitive for
enablement with a specified peer MAC entity.
6.3.39.3.4 Effect of receipt
The SME is notified of the results of the enablement procedure.
6.3.39.4 MLME-ENABLEMENT.indication
6.3.39.4.1 Function
This primitive indicates receipt of a request from a specific peer MAC entity to establish an enablement
relationship with the STA processing this primitive.
6.3.39.4.2 Semantics of the service primitive
The primitive parameters are as follows:
393
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-ENABLEMENT.indication(
RequesterSTAAddress,
ResponderSTAAddress,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
RequesterSTAAddr MACAddress Any valid Specifies the address of the peer MAC entity that
ess individual MAC initiated the enablement process.
address
ResponderSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity that
ress individual MAC is the enabling STA.
address
Protected Boolean true, false Specifies whether the request was sent using a
robust Management frame.
If true, the request was sent using the Protected
DSE Enablement frame.
If false, the request was sent using the DSE
Enablement frame.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.39.4.3 When generated
This primitive is generated by the MLME as a result of the receipt of an enablement request from a specific
peer MAC entity.
6.3.39.4.4 Effect of receipt
The SME is notified of the receipt of this enablement request.
6.3.39.5 MLME-ENABLEMENT.response
6.3.39.5.1 Function
This primitive is used to send a response to a specified peer MAC entity that requested enablement with the
STA that issued this primitive.
6.3.39.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ENABLEMENT.response(
RequesterSTAAddress,
ResponderSTAAddress,
ResultCode,
EnablementIdentifier,
Protected,
VendorSpecificInfo
)
394
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
RequesterSTAAddr MACAddress Any valid Specifies the address of the MAC entity that
ess individual MAC initiated the enablement process.
address
ResponderSTAAdd MACAddress Any valid Specifies the address of the peerMAC entity that
ress individual MAC is the enabling STA.
address
ResultCode Enumeration SUCCESS, Indicates the result response to the enablement
REFUSED, request from the peer MAC entity.
TOO_MANY_SI
MULTANEOUS_
REQUESTS
EnablementIdentifi Integer 0-65 535 Specifies the dependent enablement identifier.
er
Protected Boolean true, false Specifies whether the response is sent using a
robust Management frame.
If true, the response is sent using the Protected
DSE Enablement frame.
If false, the response is sent using the DSE
Enablement frame.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.39.5.3 When generated
This primitive is generated by the SME of a STA as a response to an MLME-ENABLEMENT.indication
primitive.
6.3.39.5.4 Effect of receipt
This primitive initiates transmission of a response to the specific peer MAC entity that requested
enablement.
6.3.40 Deenablement
6.3.40.1 MLME-DEENABLEMENT.request
6.3.40.1.1 Function
This primitive requests that the enablement relationship with a specified peer MAC entity be invalidated.
6.3.40.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DEENABLEMENT.request(
RequesterSTAAddress,
ResponderSTAAddress,
ReasonCode,
Protected,
VendorSpecificInfo
)
395
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
RequesterSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity that
ress individual MAC requests the deenablement process.
address
ResponderSTAAd MACAddress Any valid Specifies the address of the MAC entity that
dress individual MAC becomes deenabled in the process.
address
ReasonCode Reason Result As defined in Specifies the reason code for initiating the
Code field 9.6.8.5 deenablement process.
Protected Boolean true, false Specifies whether the request is sent using a
robust Management frame.
If true, the request is sent using the Protected
DSE Deenablement frame.
If false, the request is sent using the DSE
Deenablement frame.
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
6.3.40.1.3 When generated
This primitive is generated by the SME for a STA to invalidate enablement with a specified peer MAC
entity in order to prevent the exchange of (Protected dual of) Public Action frames between the two STAs.
During the deenablement procedure, the SME can generate additional MLME-DEENABLEMENT.request
primitives.
6.3.40.1.4 Effect of receipt
This primitive initiates a deenablement procedure.
6.3.40.2 MLME-DEENABLEMENT.indication
6.3.40.2.1 Function
This primitive reports the invalidation of an enablement relationship with a specified peer MAC entity.
6.3.40.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DEENABLEMENT.indication(
RequesterSTAAddress,
ResponderSTAAddress,
ReasonCode,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
RequesterSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity with
ress individual MAC which the enablement relationship was
address invalidated.
ResponderSTAAd MACAddress Any valid Specifies the address of the MAC entity with
dress individual MAC which the enablement relationship was
address invalidated.
396
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ReasonCode Reason Result As defined in Specifies the reason the deenablement procedure
Code field 9.6.8.5 was initiated.
Protected Boolean true, false Specifies whether the request was received using
a robust Management frame.
If true, the request was received using the
Protected DSE Deenablement frame.
If false, the request was received using the DSE
Deenablement frame.
VendorSpecificInf A set of elements As defined in Zero or more elements.
o 9.4.2.26
6.3.40.2.3 When generated
This primitive is generated by the MLME as a result of the invalidation of an enablement relationship with a
specific peer MAC entity.
6.3.40.2.4 Effect of receipt
The SME is notified of the invalidation of the specific enablement relationship.
6.3.41 SA Query support
6.3.41.1 MLME-SA-QUERY.request
6.3.41.1.1 Function
This primitive requests that a SA Query Request frame be sent to a specified peer STA to which the STA is
associated.
6.3.41.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SA-QUERY.request(
PeerSTAAddress,
TransactionIdentifier,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTA Address MAC Address Any valid individual Specifies the address of the peer
MAC Address MAC entity for the SA Query
TransactionIdentifier 2 octets As defined in 9.6.10.2 The Transaction Identifier to
identify the SA Query Request and
Response transaction
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.41.1.3 When generated
This primitive is generated by the SME to request that a SA Query Request frame be sent to a specified peer
STA with which the STA is associated.
397
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.41.1.4 Effect of receipt
On receipt of this primitive, the MLME constructs a SA Query Request frame. The STA then attempts to
transmit this to the peer STA with which it is associated.
6.3.41.2 MLME-SA-QUERY.confirm
6.3.41.2.1 Function
This primitive reports the result of a SA Query procedure.
6.3.41.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SA-QUERY.confirm(
PeerSTAAddress,
TransactionIdentifier,
VendorSpecificInfo
)
Name Type Valid Range Description
PeerSTA Address MAC Address Any valid individual Specifies the address of the peer
MAC Address MAC entity for the SA Query
TransactionIdentifier 2 octets As defined in 9.6.10.2 The Transaction Identifier to
identify the SA Query Request and
Response transaction
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.41.2.3 When generated
This primitive is generated by the MLME as a result of the receipt of a valid SA Query Response frame.
6.3.41.2.4 Effect of receipt
On receipt of this primitive, the SME may use the response as a sign of liveness of the peer STA.
6.3.41.3 MLME-SA-QUERY.indication
6.3.41.3.1 Function
This primitive indicates that a SA Query Request frame was received from a STA.
6.3.41.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SA-QUERY.indication(
PeerSTAAddress,
TransactionIdentifier,
VendorSpecificInfo
)
398
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTA Address MAC Address Any valid individual Specifies the address of the peer
MAC Address MAC entity for the SA Query
TransactionIdentifier 2 octets As defined in 9.6.10.2 The Transaction Identifier to
identify the SA Query Request and
Response transaction
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.41.3.3 When generated
This primitive is generated by the MLME when a valid SA Query Request frame is received.
6.3.41.3.4 Effect of receipt
On receipt of this primitive, the SME operates according to the procedure in 11.3.
6.3.41.4 MLME-SA-QUERY.response
6.3.41.4.1 Function
This primitive is generated in response to an MLME-SA-QUERY.indication primitive requesting a SA
Query Response frame be sent to a STA.
6.3.41.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SA-QUERY.response(
PeerSTAAddress,
TransactionIdentifier,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTA Address MAC Address Any valid individual Specifies the address of the peer
MAC Address MAC entity for the SA Query
TransactionIdentifier 2 octets As defined in 9.6.10.2 The Transaction Identifier to iden-
tify the SA Query Request and
Response transaction
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.41.4.3 When generated
This primitive is generated by the SME, in response to an MLME-SA-QUERY.indication primitive,
requesting a SA Query Response frame be sent to a STA.
6.3.41.4.4 Effect of receipt
On receipt of this primitive, the MLME constructs a SA Query Response frame. The STA then attempts to
transmit this to the STA indicated by the PeerSTAAddress parameter.
399
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.42 Get TSF timer
6.3.42.1 General
This mechanism is used to request the current value of the TSF timer that the STA maintains.
6.3.42.2 MLME-GETTSFTIME.request
6.3.42.2.1 Function
This primitive is generated by the SME to request that the MLME returns the value of its TSF timer. The
value returned in TSFtime (as specified in 6.3.42.3.2) is the value of the TSF timer at the instant the MLME-
GETTSFTIME.request primitive is received.
6.3.42.2.2 Semantics of the service primitive
This primitive has no parameters.
6.3.42.2.3 When generated
This primitive is generated by the SME to request the value of the TSF timer from the MLME.
6.3.42.2.4 Effect of receipt
The MLME issues an MLME-GETTSFTIME.confirm primitive.
6.3.42.3 MLME-GETTSFTIME.confirm
6.3.42.3.1 Function
This primitive is generated by the MLME to report to the SME the result of a request to get the value of the
TSF timer.
6.3.42.3.2 Semantics of the service primitive
This primitive uses the following parameters:
MLME-GETTSFTIME.confirm(
ResultCode,
TSFtime
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Reports the outcome of an MLME-
FAILURE GETTSFTIME.request primitive
TSFtime Integer 0 – (264 –1) The value of the TSF timer. Present if ResultCode is
SUCCESS; otherwise not present.
6.3.42.3.3 When generated
This primitive is generated by the MLME to report to the SME the result of an MLME-
GETTSFTIME.request primitive.
400
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.42.3.4 Effect of receipt
The SME is notified of the result of an MLME-GETTSFTIME.request primitive and, if successful, has the
value of the TSF timer at the instant the MLME-GETTSFTIME.request primitive was received by the
MLME. If the result of an MLME-GETTSFTIME.request primitive is failure, the TSFtime parameter is not
included in the MLME-GETTSFTIME.confirm primitive.
NOTE—The TSF timer value can be used, along with other information, by the SME to compute an offset between an
external time standard such as a version of Coordinated Universal Time (UTC) from a Global Positioning System (GPS)
unit and the TSF timer.
6.3.43 Timing Advertisement
6.3.43.1 General
The Timing Advertisement primitives are used to communicate timing and other information from the
higher layers or the SME of one STA to the higher layers or SME of other STAs.
6.3.43.2 MLME-TIMING-ADVERTISEMENT.request
6.3.43.2.1 Function
This primitive is generated by the SME to request that the MLME generate a Timing Advertisement frame
to transmit timing and, optionally, higher layer information.
6.3.43.2.2 Semantics of the service primitive
This primitive provides the following parameters:
MLME-TIMING-ADVERTISEMENT.request(
PeerMACAddress,
Capability Information,
Country,
Power Constraint,
Time Advertisement,
Extended Capabilities,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual or The address of the peer MAC entity or group of
group MAC address entities to which the Timing Advertisement frame
is sent.
Capability As defined in As defined in 9.4.1.4 The announced capabilities of the STA.
Information 9.4.1.4
Country As defined in As defined in 9.4.2.9 The information required to identify the
9.4.2.9 regulatory domain in which the STA is located
and to configure its PHY for operation in that
regulatory domain. Present only when TPC
functionality is required, as specified in 11.8 or
when dot11MultiDomainCapabilityActivated is
true.
Power Constraint As defined in As defined in 9.4.2.14 Optional. The Power Constraint element contains
9.4.2.14 the information necessary to allow a STA to
determine the local maximum transmit power in
the current channel.
401
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Time As defined in As defined in 9.4.2.61 Timing announced by the STA.
Advertisement 9.4.2.61
Extended As defined in As defined in 9.4.2.27 Optional. The Extended Capabilities element
Capabilities 9.4.2.27 might be present if any of the fields in this
element are nonzero.
VendorSpecificInf A set of As defined in 9.4.2.26 Zero or more elements.
o elements
6.3.43.2.3 When generated
This primitive is generated by the SME to request that the MLME generates a Timing Advertisement frame
for transmission.
6.3.43.2.4 Effect of receipt
Upon the receipt of this primitive, the MLME attempts to transmit a Timing Advertisement frame to the
specified MAC address, using the procedures defined in 11.22.
6.3.43.3 MLME-TIMING-ADVERTISEMENT.indication
6.3.43.3.1 Function
This primitive is generated by the MLME to indicate to the SME the reception of a Timing Advertisement
frame.
6.3.43.3.2 Semantics of the service primitive
This primitive provides the following parameters:
MLME-TIMING-ADVERTISEMENT.indication(
Timestamp,
Capability Information,
Local Time,
Country,
Power Constraint,
Time Advertisement,
Extended Capabilities,
RCPI,
Source MAC address,
VendorSpecificInfo
)
Name Type Valid range Description
Timestamp Integer N/A The timestamp of the received frame.
Capability As defined in 9.4.1.4 As defined in The announced capabilities of the STA.
Information 9.4.1.4
Local Time Integer N/A Local Time is the value of a station’s TSF timer at
the start of reception of the first octet of the
timestamp field of the received Timing
Advertisement frame.
402
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Country As defined in 9.4.2.9 As defined in The information required to identify the
9.4.2.9 regulatory domain in which the STA is located
and to configure its PHY for operation in that
regulatory domain. Present only when TPC
functionality is required, as specified in 11.8 or
when dot11MultiDomainCapabilityActivated is
true.
Power As defined in As defined in The Power Constraint element contains the
Constraint 9.4.2.14 9.4.2.14 information necessary to allow a STA to
determine the local maximum transmit power in
the current channel.
Time As defined in As defined in Timing announced by the STA.
Advertisement 9.4.2.61 9.4.2.61
Extended As defined in As defined in The Extended Capabilities element might be
Capabilities 9.4.2.27 9.4.2.27 present if any of the fields in this element are
nonzero.
RCPI Integer as defined in As defined in RCPI is the measured value of received channel
9.4.2.38 9.4.2.38 power on the received Timing Advertisement
frame.
Source MAC As defined in As defined in The SA field of the MAC header from the
Address 9.2.4.3.6 9.2.4.3.6 received Timing Advertisement frame.
VendorSpecific A set of elements As defined in Zero or more elements.
Info 9.4.2.26
6.3.43.3.3 When generated
This primitive is generated by the MLME when a Timing Advertisement frame is received.
6.3.43.3.4 Effect of receipt
Upon the receipt of this primitive, the SME is notified that a Timing Advertisement frame has been received.
6.3.44 TDLS Discovery
6.3.44.1 General
The following MLME primitives support the signaling of TDLS Discovery.
6.3.44.2 MLME-TDLSDISCOVERY.request
6.3.44.2.1 Function
This primitive requests that a TDLS Discovery Request frame be sent through the AP path.
6.3.44.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSDISCOVERY.request(
DestinationAddress,
TDLSDiscoveryRequest
)
403
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DestinationAddress MAC Any valid Specifies the DA to which a TDLS Discovery
Address individual MAC Request frame is transmitted.
Address
TDLSDiscoveryRequest Sequence of As defined in Specifies the proposed service parameters for
octets TDLS Discovery the TDLS Discovery Request frame.
Request frame
6.3.44.2.3 When generated
This primitive is generated by the SME to request that a TDLS Discovery Request frame be sent through the
AP.
6.3.44.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Discovery Request frame. The STA then
attempts to transmit this frame.
6.3.44.3 MLME-TDLSDISCOVERY.confirm
6.3.44.3.1 Function
This primitive is generated when a valid TDLS Discovery Response frame is received.
6.3.44.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSDISCOVERY.confirm(
TDLSPeerSTAAddress,
TDLSDiscoveryResponse
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer
Address individual MAC STA from which a TDLS Discovery Response
Address frame was received.
TDLSDiscoveryResponse Sequence of As defined in Specifies the service parameters contained in
octets TDLS the received TDLS Discovery Response frame.
Discovery
Response frame
6.3.44.3.3 When generated
This primitive is generated when a valid TDLS Discovery Response frame is received.
6.3.44.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the MLME-TDLSDISCOVERY.confirm primitive and may
use the reported data.
404
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.44.4 MLME-TDLSDISCOVERY.indication
6.3.44.4.1 Function
This primitive indicates that a TDLS Discovery Request frame was received from a TDLS peer STA.
6.3.44.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSDISCOVERY.indication(
TDLSPeerSTAAddress,
TDLSDiscoveryRequest
)
Name Type Valid range Description
TDLSPeerSTAAddress MACAddress Any valid Specifies the MAC address of the TDLS peer STA
individual MAC from which a TDLS Discovery Request frame was
Address received.
TDLSDiscoveryRequest Sequence of As defined in Specifies the proposed service parameters of the
octets TDLS TDLS Discovery Request frame.
Discovery
Request frame
6.3.44.4.3 When generated
This primitive is generated by the MLME when a valid TDLS Discovery Request frame is received.
6.3.44.4.4 Effect of receipt
On receipt of this primitive, the SME operates according to the procedure in 11.23.
6.3.44.5 MLME-TDLSDISCOVERY.response
6.3.44.5.1 Function
This primitive requests that a TDLS Discovery Response frame be sent directly to the TDLS peer STA from
which a TDLS Discovery Request frame was received.
6.3.44.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSDISCOVERY.response(
TDLSPeerSTAAddress,
TDLSDiscoveryResponse
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer
Address individual MAC STA to which a TDLS Discovery Response
Address frame is transmitted.
TDLSDiscoveryResponse Sequence of As defined in Specifies the proposed service parameters for
octets TDLS Discovery the TDLS Discovery Response frame.
Response frame
405
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.44.5.3 When generated
This primitive is generated by the SME to request that a TDLS Discovery Response frame be sent to the
TDLS peer STA from which a TDLS Discovery Request frame was received.
6.3.44.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Discovery Response frame. The STA then
attempts to transmit this frame to the TDLS peer STA.
6.3.45 TDLS direct-link establishment
6.3.45.1 General
The following MLME primitives support the signaling of tunneled direct-link setup. Figure 6-7 depicts the
TDLS direct-link establishment process. The figure is an example of only the basic procedure and is not
meant to be exhaustive of all possible uses of the protocol.
6.3.45.2 MLME-TDLSSETUPREQUEST.request
6.3.45.2.1 Function
This primitive requests that a TDLS Setup Request frame be sent to a candidate TDLS responder STA.
6.3.45.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSSETUPREQUEST.request(
TDLSResponderAddress,
TDLSSetupRequest
)
Name Type Valid range Description
TDLSResponderAddress MAC Address Any valid Specifies the MAC address of the STA to
individual MAC which the TDLS Setup Request frame is
Address transmitted.
TDLSSetupRequest Sequence of As defined in Specifies the proposed service parameters for
octets TDLS Setup the TDLS Setup.
Request frame
6.3.45.2.3 When generated
This primitive is generated by the SME to request that a TDLS Setup Request frame be sent to a candidate
TDLS responder STA.
6.3.45.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Setup Request frame. The STA then attempts to
transmit this frame to the candidate TDLS responder STA.
406
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IEEE 802.11 initiating STA IEEE 802.11 peer STA
SME MLME MLME SME
MLME -TDLSPOTENTIAL
PEERSTA.request
MLME -TDLSPOTENTIAL
PEERSTA.indication
MLME-- TDLSSETUP TDLS Setup MLME-- TDLSSETUP
REQUEST.request Request frame REQUEST.indication
ProcessTDLS
Process TDLS
SetupRequest
Setup Request
Action
MLME-- DLSSETUP TDLS Setup MLME-- TDLSSETUP
RESPONSE.indication Response frame RESPONSE.request
Process TDLS
Process TDLS
Setup Response
Action
MLME-- TDLSSETUP TDLS Setup MLME-- TDLSSETUP
CONFIRM.request Confirm frame CONFIRM.indication
Figure 6-7—TDLS direct-link establishment
6.3.45.3 MLME-TDLSSETUPREQUEST.indication
6.3.45.3.1 Function
This primitive indicates that a TDLS Setup Request frame was received.
6.3.45.3.2 Semantics of the service primitive
The primitive parameters are as follows:
407
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-TDLSSETUPREQUEST.indication(
TDLSInitiatorAddress,
TDLSSetupRequest
)
Name Type Valid range Description
TDLSInitiatorAddress MACAddress Any valid Specifies the MAC address of the TDLS
individual MAC initiator STA from which a TDLS Setup
Address Request frame was received.
TDLSSetupRequest Sequence of octets As defined in Specifies the proposed service parameters
TDLS Setup for the TDLS Setup.
Request frame
6.3.45.3.3 When generated
This primitive is generated by the MLME when a valid TDLS Setup Request frame is received.
6.3.45.3.4 Effect of receipt
On receipt of this primitive, the SME operates according to the procedure in 11.23.
6.3.45.4 MLME-TDLSSETUPRESPONSE.request
6.3.45.4.1 Function
This primitive requests that a TDLS Setup Response frame be sent to the TDLS initiator STA.
6.3.45.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSSETUPRESPONSE.request(
TDLSInitiatorAddress,
TDLSSetupResponse
)
Name Type Valid range Description
TDLSInitiatorAddress MAC Address Any valid Specifies the MAC address of the TDLS
individual MAC initiator STA to which a TDLS Setup
Address Response frame is transmitted.
TDLSSetupResponse Sequence of octets As defined in Specifies the proposed service parameters
TDLS Setup for the TDLS Setup.
Response frame
6.3.45.4.3 When generated
This primitive is generated by the SME to request that a TDLS Setup Response frame be sent to the TDLS
initiator STA.
6.3.45.4.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Setup Response frame. The STA then attempts to
transmit this to the TDLS initiator STA.
408
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.45.5 MLME-TDLSSETUPRESPONSE.indication
6.3.45.5.1 Function
This primitive indicates that a TDLS Setup Response frame was received from the TDLS responder STA.
6.3.45.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSSETUPRESPONSE.indication(
TDLSResponderAddress,
TDLSSetupResponse
)
Name Type Valid range Description
TDLSResponderAddre MACAddress Any valid Specifies the MAC address of the TDLS
ss individual MAC responder STA from which a TDLS Setup
Address Response frame was received.
TDLSSetupResponse Sequence of As defined in Specifies the proposed service parameters for
octets TDLS Setup the TDLS Setup.
Response frame
6.3.45.5.3 When generated
This primitive is generated by the MLME when a valid TDLS Setup Response frame is received.
6.3.45.5.4 Effect of receipt
On receipt of this primitive, the SME operates according to the procedure in 11.23.
6.3.45.6 MLME-TDLSSETUPCONFIRM.request
6.3.45.6.1 Function
This primitive requests that a TDLS Setup Confirm frame be sent to the TDLS responder STA.
6.3.45.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSSETUPCONFIRM.request(
TDLSResponderAddress,
TDLSSetupConfirm
)
Name Type Valid range Description
TDLSResponderAddress MAC Address Any valid Specifies the MAC address of the TDLS
individual MAC responder STA to which a TDLS Setup
Address Confirm frame is transmitted.
TDLSSetupConfirm Sequence of As defined in Specifies the proposed service parameters for
octets TDLS Setup the TDLS Setup.
Confirm frame
409
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.45.6.3 When generated
This primitive is generated by the SME to request that a TDLS Setup Confirm frame be sent to the TDLS
responder STA.
6.3.45.6.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Setup Confirm frame. The STA then attempts to
transmit this to the TDLS responder STA.
6.3.45.7 MLME-TDLSSETUPCONFIRM.indication
6.3.45.7.1 Function
This primitive indicates that a TDLS Setup Confirm frame was received from the TDLS initiator STA.
6.3.45.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSSETUPCONFIRM.indication(
TDLSInitiatorAddress,
TDLSSetupConfirm
)
Name Type Valid range Description
TDLSInitiatorA MACAddress Any valid Specifies the MAC address of the TDLS initiator
ddress individual MAC STA from which a TDLS Setup Confirm frame was
Address received.
TDLSSetupCon Sequence of octets As defined in Specifies the proposed service parameters for the
firm TDLS Setup TDLS setup.
Confirm frame
6.3.45.7.3 When generated
This primitive is generated by the MLME when a valid TDLS Setup Confirm frame is received.
6.3.45.7.4 Effect of receipt
On receipt of this primitive, the SME operates according to the procedure in 11.23.
6.3.45.8 MLME-TDLSPOTENTIALPEERSTA.request
6.3.45.8.1 Function
This primitive requests information about a potential TDLS peer STA.
6.3.45.8.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-TDLSPOTENTIALPEERSTA.request(
MACAddress
)
410
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid Range Description
MACAddress MAC Address Any valid Specifies the MAC address of the potential
individual MAC TDLS peer STA.
Address
6.3.45.8.3 When generated
This primitive is generated by the SME to request the MLME to provide information about a potential TDLS
peer STA.
6.3.45.8.4 Effect of receipt
On receipt of this primitive, the MLME responds with the requested information about the identified STA.
6.3.45.9 MLME-TDLSPOTENTIALPEERSTA.confirm
6.3.45.9.1 Function
This primitive informs the SME about a potential TDLS peer STA.
6.3.45.9.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPOTENTIALPEERSTA.confirm(
MACAddress,
RSSI
)
Name Type Valid range Description
MACAddress MAC Address Any valid Specifies the MAC address of the STA for
individual MAC which information is requested.
Address
RSSI Integer –1 to RSSI Max Specifies the RSSI from the STA. –1
indicates that the STA is not present.
6.3.45.9.3 When generated
This primitive is generated by the MLME to indicate to the SME that a potential TDLS peer STA has been
detected.
6.3.45.9.4 Effect of receipt
On receipt of this primitive, the SME may attempt to set up a TDLS direct link by issuing an MLME-
TDLSSETUPREQUEST.request primitive to the MLME.
411
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.46 TDLS direct-link teardown
6.3.46.1 General
The following MLME primitives support the signaling of tunneled direct-link setup. Figure 6-8 depicts the
TDLS direct-link teardown process. The figure is an example of only the basic procedure and is not meant to
be exhaustive of all possible uses of the protocol.
IEEE 802.11 initiating STA IEEE 802.11 peer STA
SME MLME MLME SME
MLME- TDLS TDLS Teardown frame MLME- TDLS
TEARDOWN.request TEARDOWN.indication
Figure 6-8—TDLS direct-link teardown
6.3.46.2 MLME-TDLSTEARDOWN.request
6.3.46.2.1 Function
This primitive requests that a TDLS Teardown frame be sent to the TDLS peer STA.
6.3.46.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSTEARDOWN.request(
TDLSPeerSTAAddress,
TDLSTeardown
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Address Any valid Specifies the MAC address of the TDLS peer
individual MAC STA to which a TDLS Teardown frame is
Address transmitted.
TDLSTeardown Sequence of As defined in Specifies the proposed service parameters for
octets TDLS Teardown the TDLS teardown.
frame
6.3.46.2.3 When generated
This primitive is generated by the SME to request that a TDLS Teardown frame be sent to the TDLS peer
STA.
412
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.46.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Teardown frame. The STA then attempts to
transmit this frame to the TDLS peer STA.
6.3.46.3 MLME-TDLSTEARDOWN.indication
6.3.46.3.1 Function
This primitive indicates that a TDLS Teardown frame was received from a TDLS peer STA.
6.3.46.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSTEARDOWN.indication(
TDLSPeerSTAAddress,
TDLSTeardown
)
Name Type Valid range Description
TDLSPeerSTAA MACAddress Any valid The MAC address of the TDLS peer STA from
ddress individual MAC which a TDLS Teardown frame was received.
Address
TDLSTeardown Sequence of As defined in Specifies the proposed service parameters for the
octets TDLS Teardown TDLS teardown.
frame
6.3.46.3.3 When generated
This primitive is generated by the MLME when a valid TDLS Teardown frame is received.
6.3.46.3.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.23.
6.3.47 TDLS peer U-APSD (TPU)
6.3.47.1 General
The following MLME primitives support the signaling of TPU. Figure 6-9 depicts the TPU process. The
figure is an example of only the basic procedure and is not meant to be exhaustive of all possible uses of the
protocol.
413
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IEEE 802.11 initiating STA IEEE 802.11 peer STA
SME MLME MLME SME
MLME- TDLS Peer Traffic Indication frame MLME-
TDLSPTI.request TDLSPTI.indication
Process TDLS
Peer Traffic Indication
Action
MLME- TDLS Peer Traffic Response frame MLME-
TDLSPTI.confirm TDLSPTI.response
Figure 6-9—TPU
6.3.47.2 MLME-TDLSPTI.request
6.3.47.2.1 Function
This primitive requests that a TDLS Peer Traffic Indication frame be sent to a TDLS peer STA.
6.3.47.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPTI.request(
TDLSPeerSTAAddress,
TDLSPTI
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Address Any valid Specifies the address of the MAC entity with
individual MAC which to perform the TPU process.
Address
TDLSPTI Sequence of As defined in Specifies the proposed service parameters for
octets TDLS Peer the TPU.
Traffic Indication
frame
414
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.47.2.3 When generated
This primitive is generated by the SME to request that a TDLS Peer Traffic Indication frame be sent to the
TDLS peer STA.
6.3.47.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Peer Traffic Indication frame. The STA then
attempts to transmit this to the TDLS peer STA.
6.3.47.3 MLME-TDLSPTI.confirm
6.3.47.3.1 Function
This primitive reports the result of an MLME-TDLSPTI.request primitive to trigger an unscheduled SP from
a candidate TDLS peer STA. This primitive is generated after transmitting a Peer Traffic Indication frame
when this frame contains a PTI Control field, and after receiving a Peer Traffic Response frame otherwise.
6.3.47.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPTI.confirm(
TDLSPeerSTAAddress,
TDLSPTR
)
Name Type Valid range Description
TDLSPeerSTAA MAC Address Any valid individual MAC Specifies the MAC address of the peer
ddress Address MAC entity with which to perform the TPU
process.
TDLSPTR Sequence of As defined in TDLS Peer Specifies the proposed service parameters
octets Traffic Response frame for the TPU.
6.3.47.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-TDLSPTI.request primitive and indicates
the results of the request.
This primitive is generated when the STA successfully receives a TDLS Peer Traffic Response frame from
the TDLS peer STA or when an unspecified failure occurs.
6.3.47.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the results of the MLME-TDLSPTI.request primitive and
may use the reported data.
6.3.47.4 MLME-TDLSPTI.indication
6.3.47.4.1 Function
This primitive indicates that a TDLS Peer Traffic Indication frame was received from a TDLS peer STA.
415
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.47.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPTI.indication(
TDLSPeerSTAAddress,
TDLSPTI
)
Name Type Valid range Description
TDLSPeerSTAA MACAddress Any valid The MAC address of the non-AP STA MAC entity
ddress individual MAC from which a TDLS Peer Traffic Indication frame was
Address received.
TDLSPTI Sequence of As defined in Specifies the proposed service parameters for the TPU.
octets TDLS Peer
Traffic Indication
frame
6.3.47.4.3 When generated
This primitive is generated by the MLME when a valid TDLS Peer Traffic Indication frame is received.
6.3.47.4.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure as specified in 11.2.3.15.
6.3.47.5 MLME-TDLSPTI.response
6.3.47.5.1 Function
This primitive requests that a TDLS Peer Traffic Response frame be sent to the TDLS peer STA.
6.3.47.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPTI.response(
PeerSTAAddress,
TDLSPTR
)
Name Type Valid range Description
PeerSTAAddress MAC Any valid Specifies the address of the peer MAC entity
Address individual MAC with which to perform the TPU.
Address
TDLSPTR Sequence of As defined in Specifies the proposed service parameters for the
octets TDLS Peer TPU.
Traffic Response
frame
6.3.47.5.3 When generated
This primitive is generated by the SME to request that a TDLS Peer Traffic Response frame be sent to the
TDLS peer STA.
416
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.47.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Peer Traffic Response frame. The STA then
attempts to transmit this to the TDLS peer STA.
6.3.48 TDLS channel switching
6.3.48.1 General
The following MLME primitives support the signaling of a TDLS channel switch. Figure 6-10 depicts the
TDLS channel switching process. The figure is an example of only the basic procedure and is not meant to
be exhaustive of all possible uses of the protocol.
IEEE 802.11 initiating STA IEEE 802.11 peer STA
SME MLME MLME SME
MLME- TDLS TDLS Channel Switch MLME- TDLS
CHANNELSWITCH.request Request frame CHANNELSWITCH.indication
Process TDLS
Channel Switch Request
Action
MLME- TDLS TDLS Channel Switch MLME- TDLS
CHANNELSWITCH.confirm Response frame CHANNELSWITCH.response
Figure 6-10—TDLS channel switching
6.3.48.2 MLME-TDLSCHANNELSWITCH.request
6.3.48.2.1 Function
This primitive requests that a TDLS Channel Switch Request frame be sent to the TDLS peer STA.
6.3.48.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSCHANNELSWITCH.request(
TDLSPeerSTAAddress,
TDLSChannelSwitchRequest
)
417
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
TDLSPeerSTAAddress MAC Any valid Specifies the address of the TDLS peer MAC
Address individual MAC entity to which a TDLS Channel Switch Request
Address frame is transmitted.
TDLSChannelSwitchRequest Sequence As defined in Specifies the proposed service parameters for the
of octets TDLS Channel TDLS Channel Switch.
Switch Request
frame
6.3.48.2.3 When generated
This primitive is generated by the SME to request that a TDLS Channel Switch Request frame be sent to the
TDLS peer STA.
6.3.48.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Channel Switch Request frame. The STA then
attempts to transmit this to the TDLS peer STA.
6.3.48.3 MLME-TDLSCHANNELSWITCH.confirm
6.3.48.3.1 Function
This primitive reports the result of an MLME-TDLSCHANNELSWITCH.request primitive to switch a
channel with a TDLS peer STA.
6.3.48.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSCHANNELSWITCH.confirm(
TDLSPeerSTAAddress,
TDLSChannelSwitchResponse
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Any valid individual MAC Specifies the MAC address of the TDLS
Address Address peer STA from which a TDLS Channel
Switch Response frame was received.
TDLSChannelSwitchRes Sequence of As defined in TDLS Specifies the proposed service
ponse octets Channel Switch Response parameters for the TDLS Channel
frame Switch.
6.3.48.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-TDLSCHANNELSWITCH.request
primitive and indicates the results of the request.
This primitive is generated when the STA successfully receives a TDLS Channel Switch Response frame
from the TDLS peer STA.
6.3.48.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the results of the MLME-TDLSCHANNEL-
SWITCH.request primitive and may use the reported data.
418
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.48.4 MLME-TDLSCHANNELSWITCH.indication
6.3.48.4.1 Function
This primitive indicates that a TDLS Channel Switch Request frame was received from a TDLS peer STA.
6.3.48.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSCHANNELSWITCH.indication(
TDLSPeerSTAAddress,
TDLSChannelSwitchRequest
)
Name Type Valid range Description
TDLSPeerSTAAddres MACAddress Any valid Specifies the MAC address of the TDLS peer
s individual MAC STA from which a TDLS Channel Switch
Address Request frame was received.
TDLSChannelSwitch Sequence of As defined in Specifies the proposed service parameters for the
Request octets TDLS Channel TDLS Channel Switch.
Switch Request
frame
6.3.48.4.3 When generated
This primitive is generated by the MLME when a valid TDLS Channel Switch Request frame is received.
6.3.48.4.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.23.
6.3.48.5 MLME-TDLSCHANNELSWITCH.response
6.3.48.5.1 Function
This primitive requests that a TDLS Channel Switch Response frame be sent to the TDLS peer STA.
6.3.48.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSCHANNELSWITCH.response(
TDLSPeerSTAAddress,
TDLSChannelSwitchResponse
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Address Any valid Specifies the MAC address of the TDLS peer
individual MAC STA to which a TDLS Channel Switch Response
Address frame is transmitted.
TDLSChannelSwitchRe Sequence of As defined in Specifies the proposed service parameters for the
sponse octets TDLS Channel TDLS Channel Switch.
Switch Response
frame
419
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.48.5.3 When generated
This primitive is generated by the SME to request that a TDLS Channel Switch Response frame be sent to
the TDLS peer STA.
6.3.48.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Channel Switch Response frame. The STA then
attempts to transmit this frame to the TDLS peer STA.
6.3.49 TDLS peer PSM
6.3.49.1 General
The following MLME primitives support the management of TDLS peer PSM. Figure 6-11 depicts the
TDLS peer PSM process. The figure is an example of only the basic procedure and is not meant to be
exhaustive of all possible uses of the protocol.
IEEE 802.11 initiating STA IEEE 802.11 peer STA
SME MLME MLME SME
MLME -TDLS TDLS Peer PSM Request frame MLME- TDLS
PEERPSM.request PEERPSM.indication
Process TDLS
Peer PSM Request
Action
MLME- TDLS TDLS Peer PSM Response frame MLME- TDLS
PEERPSM.confirm PEERPSM.response
Figure 6-11—TDLS peer PSM
6.3.49.2 MLME-TDLSPEERPSM.request
6.3.49.2.1 Function
This primitive requests that a TDLS Peer PSM Request frame be sent to the TDLS peer STA.
420
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.49.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPEERPSM.request(
TDLSPeerSTAAddress,
TDLSPeerPSMRequest
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer
Address individual MAC STA to which a TDLS Peer PSM Request frame
Address is transmitted.
TDLSPeerPSMRequest Sequence of As defined in Specifies the proposed service parameters for the
octets TDLS Peer PSM TDLS peer PSM.
Request frame
6.3.49.2.3 When generated
This primitive is generated by the SME to request that a TDLS Peer PSM Request frame be sent to the
TDLS peer STA.
6.3.49.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Peer PSM Request frame. The STA then
attempts to transmit this to the TDLS peer STA.
6.3.49.3 MLME-TDLSPEERPSM.confirm
6.3.49.3.1 Function
This primitive reports the result of an MLME-TDLSPEERPSM.request primitive to initiate power save
mode based on scheduled service periods with a TDLS peer STA.
6.3.49.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPEERPSM.confirm(
TDLSPeerSTAAddress,
TDLSPeerPSMResponse
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Any valid individual MAC Specifies the MAC address of the TDLS
Address Address peer STA from which a TDLS Peer
PSM Response frame was received.
TDLSPeerPSMResponse Sequence of As defined in TDLS Peer Specifies the proposed service
octets PSM Response frame parameters for the TDLS peer PSM.
6.3.49.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-TDLSPEERPSM.request primitive and
indicates the results of the request.
421
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This primitive is generated when the STA successfully receives a TDLS Peer PSM Response frame from the
TDLS peer STA or when an unspecified failure occurs.
6.3.49.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the results of the MLME-TDLSPEERPSM.request primitive
and may use the reported data.
6.3.49.4 MLME-TDLSPEERPSM.indication
6.3.49.4.1 Function
This primitive indicates that a TDLS Peer PSM Request frame was received from a TDLS peer STA.
6.3.49.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPEERPSM.indication(
TDLSPeerSTAAddress,
TDLSPeerPSMRequest
)
Name Type Valid range Description
TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer
Address individual STA MAC entity from which a TDLS Peer PSM
MAC Address Request frame was received.
TDLSPeerPSMRequest Sequence of As defined in Specifies the proposed service parameters for the
octets TDLS Peer TDLS peer PSM.
PSM Request
frame
6.3.49.4.3 When generated
This primitive is generated by the MLME when a valid TDLS Peer PSM Request frame is received.
6.3.49.4.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.14.
6.3.49.5 MLME-TDLSPEERPSM.response
6.3.49.5.1 Function
This primitive requests that a TDLS Peer PSM Response frame be sent to the TDLS peer STA.
6.3.49.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TDLSPEERPSM.response(
TDLSPeerSTAAddress,
TDLSPeerPSMResponse
)
422
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer
Address individual MAC STA to which a TDLS Peer PSM Response frame
Address is transmitted.
TDLSPeerPSMResponse Sequence of As defined in Specifies the proposed service parameters for the
octets TDLS Peer PSM TDLS peer PSM.
Response frame
6.3.49.5.3 When generated
This primitive is generated by the SME to request that a TDLS Peer PSM Response frame be sent to the
TDLS peer STA.
6.3.49.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TDLS Peer PSM Response frame. The STA then
attempts to transmit this to the TDLS peer STA.
6.3.50 Event request
6.3.50.1 General
This set of primitives supports the exchange of Event Request and Event Report frames. The informative
diagram shown in Figure 6-12 illustrates the Event Request and Event Report process and is not meant to be
exhaustive of all possible protocol uses.
6.3.50.2 MLME-EVLREQUEST.request
6.3.50.2.1 Function
This primitive requests the transmission of an event request to a peer entity.
6.3.50.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EVLREQUEST.request(
Peer MAC Address,
Dialog Token,
Event Request Set,
Destination URI,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC event request is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the event transaction.
Event Request Set Set of event Set of event A set of event elements describing the requested
elements elements event.
Destination URI Destination URI Destination URI The Destination URI element as defined in
element element 9.4.2.90.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
423
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA A STA B
SME MLME MLME SME
MLME- Event Log MLME-EVL
EVLREQUEST.request Request frame REQUEST.indication
MLME-EVLOG.request
Process Event Log
Action
MLME-EVLOG.confirm
MLME- Event Log MLME-
EVLREPORT.indication Report frame EVLREPORT.request
Figure 6-12—Event protocol exchange
6.3.50.2.3 When generated
This primitive is generated by the SME to request that an Event Request frame be sent to a peer entity to
initiate one or more transactions.
6.3.50.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs an Event Request frame containing the set of event
elements specified. This frame is then scheduled for transmission.
6.3.50.3 MLME-EVLREQUEST.indication
6.3.50.3.1 Function
This primitive indicates that an Event Request frame requesting an event transaction has been received.
6.3.50.3.2 Semantics of the service primitive
The primitive parameters are as follows:
424
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-EVLREQUEST.indication(
Peer MAC Address,
Dialog Token,
Event Request Set,
Destination URI,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual MAC the event request was received.
Address
Dialog Token Integer 1–255 The dialog token to identify the event transaction.
Event Request Set Set of event Set of event A set of event elements describing the requested
elements elements event.
Destination URI Destination URI Destination URI The Destination URI element as defined in
element element 9.4.2.90.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.50.3.3 When generated
This primitive is generated by the MLME when a valid Event Request frame is received.
6.3.50.3.4 Effect of receipt
On receipt of this primitive, the SME either rejects the request or commences the event transaction.
6.3.51 Event report
6.3.51.1 General
This set of primitives supports the signaling of event reports.
6.3.51.2 MLME-EVLREPORT.request
6.3.51.2.1 Function
This primitive supports the signaling of event reports between peer SMEs.
6.3.51.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EVLREPORT.request(
Peer MAC Address,
Dialog Token,
Event Report Set,
VendorSpecificInfo
)
425
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC event report is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the event transaction.
Event Report Set Set of event Set of event A set of event elements describing the response
elements elements to the event request.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.51.2.3 When generated
This primitive is generated by the SME to request that an Event Report frame be sent to a peer entity to
report the results of one or more transactions.
6.3.51.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs an Event Report frame containing the set of event
elements. This frame is then scheduled for transmission.
6.3.51.3 MLME-EVLREPORT.indication
6.3.51.3.1 Function
This primitive indicates that an Event Report frame has been received from a peer entity.
6.3.51.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EVLREPORT.indication(
Peer MAC Address,
Dialog Token,
Event Report Set,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual MAC the event report was received.
Address
Dialog Token Integer 1–255 The dialog token to identify the event transaction.
Event Report Set Set of event Set of event A set of event elements describing the response
elements elements to the event request.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.51.3.3 When generated
This primitive is generated by the MLME when a valid Event Report frame is received.
6.3.51.3.4 Effect of receipt
On receipt of this primitive, the event data can be made available for SME processes.
426
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.52 Event
6.3.52.1 General
This set of primitives supports the requesting and reporting of event data.
6.3.52.2 MLME-EVLOG.request
6.3.52.2.1 Function
This primitive is generated by the SME to request that the MLME identify specific events.
6.3.52.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EVLOG.request(
Dialog Token,
Event Request Set
)
Name Type Valid range Description
Dialog Token Integer 1–255 The dialog token to identify the event transaction.
Event Request Set Set of event Set of event A set of event elements describing the response
elements elements to the event request.
6.3.52.2.3 When generated
This primitive is generated by the SME to request that the MLME initiate the specified event.
6.3.52.2.4 Effect of receipt
On receipt of this primitive, the MLME commences the identification of events.
6.3.52.3 MLME-EVLOG.confirm
6.3.52.3.1 Function
This primitive reports the result of an event.
6.3.52.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-EVLOG.confirm(
Dialog Token,
Event Report Set
)
Name Type Valid range Description
Dialog Token Integer 1–255 The dialog token to identify the event transaction.
Event Report Set Set of event Set of event A set of event report elements describing the
report elements report elements reported event.
427
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.52.3.3 When generated
This primitive is generated by the MLME to report the results when event identification completes.
6.3.52.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the result and, if appropriate, stores the events pending
communication to the requesting entity or for local use.
6.3.53 Diagnostic request
6.3.53.1 General
This set of primitives supports the initiation of diagnostics between peer SMEs. The informative diagram
shown in Figure 6-13 depicts the diagnostic reporting process and is not meant to be exhaustive of all
possible protocol uses.
STA A STA B
SME MLME MLME SME
MLME- MLME-
DIAGREQUEST.request Diagnostic Request frame DIAGREQUEST.indication
Process
Diagnostic
Action
MLME- Diagnostic Report frame MLME-
DIAGREPORT.indication DIAGREPORT.request
Figure 6-13—Diagnostic protocol exchange
6.3.53.2 MLME-DIAGREQUEST.request
6.3.53.2.1 Function
This primitive requests the transmission of a Diagnostic Request frame to a peer entity.
6.3.53.2.2 Semantics of the service primitive
The primitive parameters are as follows:
428
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-DIAGREQUEST.request(
Peer MAC Address,
Dialog Token,
Diagnostic Request Set,
Destination URI,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC diagnostic request is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the diagnostic
transaction.
Diagnostic Request Set of diagnostic Set of diagnostic A set of diagnostic elements describing the
Set elements elements requested diagnostics.
Destination URI Destination URI Destination URI The Destination URI element as defined in
element element 9.4.2.90.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.53.2.3 When generated
This primitive is generated by the SME to request that a Diagnostic Request frame be sent to a peer entity to
initiate one or more diagnostic transactions.
6.3.53.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Diagnostic Request frame containing the set of
diagnostic elements specified. This frame is then scheduled for transmission.
6.3.53.3 MLME-DIAGREQUEST.indication
6.3.53.3.1 Function
This primitive indicates that a Diagnostic Request frame requesting a Diagnostic transaction has been
received.
6.3.53.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DIAGREQUEST.indication(
Peer MAC Address,
Dialog Token,
Diagnostic Request Set,
Destination URI,
VendorSpecificInfo
)
429
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual MAC the diagnostic request was received.
Address
Dialog Token Integer 1–255 The dialog token to identify the diagnostic
transaction.
Diagnostic Request Set of diagnostic Set of diagnostic A set of diagnostic elements describing the
Set elements elements requested diagnostics.
Destination URI Destination URI Destination URI The Destination URI element as defined in
element element 9.4.2.90.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.53.3.3 When generated
This primitive is generated by the MLME when a valid Diagnostic Request frame is received.
6.3.53.3.4 Effect of receipt
On receipt of this primitive, the SME either rejects the request or commences the diagnostic transaction.
6.3.54 Diagnostic report
6.3.54.1 MLME-DIAGREPORT.request
6.3.54.1.1 Function
This primitive supports the signaling of diagnostic reports between peer SMEs.
6.3.54.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DIAGREPORT.request(
Peer MAC Address,
Dialog Token,
Diagnostic Report Set,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual MAC the diagnostic report was received.
Address
Dialog Token Integer 1–255 The dialog token to identify the diagnostic
transaction.
Diagnostic Report Set of diagnostic Set of diagnostic A set of diagnostic elements describing the
Set elements elements results of the requested diagnostics.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.54.1.3 When generated
This primitive is generated by the SME to request that a Diagnostic Report frame be sent to a peer entity to
report the results of one or more diagnostic transactions.
430
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.54.1.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Diagnostic Report frame containing the set of
diagnostic elements. This frame is then scheduled for transmission.
6.3.54.2 MLME-DIAGREPORT.indication
6.3.54.2.1 Function
This primitive indicates that a Diagnostic Report frame has been received from a peer entity.
6.3.54.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-DIAGREPORT.indication(
Peer MAC Address,
Dialog Token,
Diagnostic Report Set,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC diagnostic report is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the diagnostic
transaction.
Diagnostic Report Set of diagnostic Set of diagnostic A set of diagnostic elements describing the
Set elements elements results of the requested diagnostics.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.54.2.3 When generated
This primitive is generated by the MLME when a valid Diagnostic Report frame is received.
6.3.54.2.4 Effect of receipt
On receipt of this primitive, the diagnostic data can be made available for SME processes.
6.3.55 Location configuration request
6.3.55.1 General
This set of primitives supports the exchange of location configuration parameter information between peer
SMEs. The informative diagram shown in Figure 6-14 depicts the location configuration request and
response process and is not meant to be exhaustive of all possible protocol uses.
431
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA A STA B
SME MLME MLME SME
MLME- MLME-
Location Configuration LOCATIONCFG
LOCATIONCFG
Request frame .indication
.request
Process Location
Configuration Action
MLME- MLME-
LOCATIONCFG Location Configuration LOCATIONCFG
.confirm Response frame .response
Figure 6-14—Location configuration request and response protocol exchange
6.3.55.2 MLME-LOCATIONCFG.request
6.3.55.2.1 Function
This primitive requests the transmission of a Location Configuration Request frame to a peer entity.
6.3.55.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-LOCATIONCFG.request(
Peer MAC Address,
Dialog Token,
Location Parameters,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC location configuration request is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the location
transaction.
Location Location Location A Location Parameters element containing one or
Parameters Parameters Parameters more subelements describing the STA location
element element information. See 9.4.2.71.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
432
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.55.2.3 When generated
This primitive is generated by the SME to request that a Location Configuration Request frame be sent to a
peer entity to convey location configuration information.
6.3.55.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Location Configuration Request frame containing the
set of Location Parameters elements specified. This frame is then scheduled for transmission.
6.3.55.3 MLME-LOCATIONCFG.confirm
6.3.55.3.1 Function
This primitive reports the result of a location configuration request.
6.3.55.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-LOCATIONCFG.confirm(
Dialog Token,
Peer MAC Address,
Location Parameters,
VendorSpecificInfo
)
Name Type Valid range Description
Dialog Token Integer 1–255 The dialog token to identify the location
transaction.
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC location configuration response is sent.
Address
Location Location Location A Location Parameters element containing one or
Parameters Parameters Parameters more subelements describing the STA location
element element information. See 9.4.2.71.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.55.3.3 When generated
This primitive is generated by the MLME when transmission of the Location Configuration Request frame
is acknowledged, when (re)transmission of the Location Configuration Request frame fails, or when a
failure reason is unspecified.
6.3.55.3.4 Effect of receipt
No effect of receipt is specified.
6.3.55.4 MLME-LOCATIONCFG.indication
6.3.55.4.1 Function
This primitive indicates that a Location Configuration Request frame has been received requesting a
location transaction.
433
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.55.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-LOCATIONCFG.indication(
Peer MAC Address,
Dialog Token,
Location Parameters,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual MAC the location configuration request was received.
Address
Dialog Token Integer 1–255 The dialog token to identify the location
transaction.
Location Location Location A Location Parameters element containing one or
Parameters Parameters Parameters more subelements describing the STA location
element element information. See 9.4.2.71.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.55.4.3 When generated
This primitive is generated by the MLME when a valid Location Configuration Request frame is received.
6.3.55.4.4 Effect of receipt
On receipt of this primitive, the SME either rejects the request or commences the location transaction.
6.3.55.5 MLME-LOCATIONCFG.response
6.3.55.5.1 Function
This primitive requests the transmission of location information to a peer entity, in response to a received
Location Configuration Request frame.
6.3.55.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-LOCATIONCFG.response(
Peer MAC Address,
Dialog Token,
Location Parameters,
VendorSpecificInfo
)
434
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC location request is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the location
transaction.
Location Location Location A location parameters element containing one or
Parameters Parameters Parameters more subelements describing the STA location
element element information. See 9.4.2.71.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.55.5.3 When generated
This primitive is generated by the SME to request that a Location Configuration Response frame be sent to a
peer entity to convey location configuration information.
6.3.55.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Location Configuration Response frame containing the
set of location parameters elements specified. This frame is then scheduled for transmission.
6.3.56 Location track notification
6.3.56.1 General
This set of primitives supports the location track notification from one SME to one or more receiving SMEs.
The informative diagram in Figure 6-15 depicts the location track notification process, is not meant to be
exhaustive of all possible protocol uses.
STA A STA B
SME MLME MLME SME
MLME-
Location Track MLME-LOCATIONTRACKNOTIF
LOCATIONTRACKNOTIF
.request Notification frame .indication
Figure 6-15—Location track notification protocol exchange
6.3.56.2 MLME-LOCATIONTRACKNOTIF.request
6.3.56.2.1 Function
This primitive requests the transmission of Location Configuration Request frame to a peer entity.
6.3.56.2.2 Semantics of the service primitive
The primitive parameters are as follows:
435
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-LOCATIONTRACKNOTIF.request(
Peer MAC Address,
Location Parameters,
Measurement Report,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual or location track notification is sent.
group addressed
MAC Address
Location Location Location A location parameters element containing one or
Parameters Parameters Parameters more subelements describing the STA location
element element information. See 9.4.2.71.
Measurement Measurement Measurement A Measurement Report element contains the
Report Report element Report element beacon measurement information. See 9.4.2.22.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.56.2.3 When generated
This primitive is generated by the SME to request that a Location Track Notification frame be sent to a peer
entity to help convey location information.
6.3.56.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Location Track Notification frame containing the set of
location parameters elements specified. This frame is then scheduled for transmission.
6.3.56.3 MLME-LOCATIONTRACKNOTIF.indication
6.3.56.3.1 Function
This primitive indicates that a Location Track Notification frame has been received.
6.3.56.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-LOCATIONTRACKNOTIF.indication(
Peer MAC Address,
Location Parameters,
Measurement Report,
VendorSpecificInfo
)
436
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual or the location track notification was received.
group addressed
MAC Address
Location Location Location A location parameters element containing one or
Parameters Parameters Parameters more subelements describing the STA location
element element information. See 9.4.2.71.
Measurement Measurement Measurement A Measurement Report element contains the
Report Report element Report element beacon measurement information. See 9.4.2.22.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.56.3.3 When generated
This primitive is generated by the MLME when a valid Location Track Notification frame is received.
6.3.56.3.4 Effect of receipt
On receipt of this primitive, the SME uses the information contained within the notification.
6.3.57 Timing measurement
6.3.57.1 General
The following set of primitives supports exchange of timing measurement information from one SME to
another. The informative diagram in Figure 6-16 depicts various points in time that are of interest to the
timing measurement procedure.
STA A STA B
SME MLME MLME SME
t1
MLME-TIMINGMSMT.request
t2
t3
MLME-TIMINGMSMT
t4 .indication
MLME-TIMINGMSMT.confirm
Figure 6-16—Timing measurement primitives and timestamps capture
NOTE 1—In Figure 6-16, t1 and t3 correspond to the point in time at which the start of the preamble for the transmitted
frame appears at the transmit antenna connector. An implementation may capture a timestamp during the transmit
processing earlier or later than the point at which it actually occurs and offset the value to compensate for the time
difference.
NOTE 2—In Figure 6-16, t2 and t4 correspond to the point in time at which the start of the preamble for the incoming
frame arrives at the receive antenna connector. Because time is needed to detect the frame and synchronize with its
logical structure, an implementation determines when the start of the preamble for the incoming frame arrived at the
receive antenna connector by capturing a timestamp some time after it occurred and compensating for the delay by
subtracting an offset from the captured value.
437
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.57.2 MLME-TIMINGMSMT.request
6.3.57.2.1 Function
This primitive requests the transmission of Timing Measurement frame to a peer entity.
6.3.57.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMINGMSMT.request(
Peer MAC Address,
Dialog Token,
Follow Up Dialog Token,
t1,
Max t1 Error,
t4,
Max t4 Error,
VendorSpecific
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual Timing Measurement frame is sent.
addressed MAC
Address
Dialog Token Integer 1–255 The dialog token to identify the Timing
Measurement frame.
Follow Up Dialog Integer 0–255 The dialog token of a Timing Measurement
Token frame which the current frame follows, or 0 if
there is no such frame. See 11.24.5.
t1 Integer 0–(232–1) The value of t1 (see Figure 6-16) for the Timing
Measurement frame identified by the Follow Up
Dialog Token, in units of 10 ns, or null if the
Follow Up Dialog Token is 0.
Max t1 Error Integer 0–255 The maximum error in the t1 value in units of 10
ns; see 9.6.15.3, or null if the Follow Up Dialog
Token is 0.
t4 Integer 0–(232–1) The value of t4 (see Figure 6-16) for the Timing
Measurement frame identified by the Follow Up
Dialog Token, in units of 10 ns, or null if the
Follow Up Dialog Token is 0.
Max t4 Error Integer 0–255 The maximum error in the t4 value in units of 10
ns, or null if the Follow Up Dialog Token is 0.
VendorSpecific A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.57.2.3 When generated
This primitive is generated by the SME to request that a Timing Measurement frame be sent to a peer entity.
6.3.57.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Timing Measurement frame with the specified
parameters. This frame is then scheduled for transmission.
438
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.57.3 MLME-TIMINGMSMT.confirm
6.3.57.3.1 Function
This primitive indicates that a Timing Measurement frame has been received by the peer STA to which it
was sent.
6.3.57.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMINGMSMT.confirm(
Peer MAC Address,
Dialog Token,
t1,
Max t1 Error,
t4,
Max t4 Error
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which
individual acknowledges the receipt of the Timing
addressed MAC Measurement frame.
Address
Dialog Token Integer 1–255 The dialog token to identify the Timing
Measurement frame.
t1 32-bit unsigned 0 – (232–1) The value of t1 (see Figure 6-16) for the Timing
Integer Measurement frame identified by the Dialog
Token, in units of 10 ns, or null if the Dialog
Token is 0.
Max t1 Error Integer 0–255 The maximum error in the t1 value in units of 10
ns; see 9.6.15.3, or null if the Dialog Token is 0.
t4 32-bit unsigned 0 – (232–1) The value of t4 (see Figure 6-16) for the Timing
Integer Measurement frame identified by the Dialog
Token, in units of 10 ns, or null if the Dialog
Token is 0.
Max t4 Error Integer 0–255 The maximum error in the t4 value in units of 10
ns, or null if the Dialog Token is 0.
6.3.57.3.3 When generated
This primitive is generated by the MLME when an Ack frame corresponding to the Timing Measurement
frame is received from the peer STA.
6.3.57.3.4 Effect of receipt
On receipt of this primitive, the SME uses the information contained within the notification.
439
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.57.4 MLME-TIMINGMSMT.indication
6.3.57.4.1 Function
This primitive indicates that a Timing Measurement frame has been received and the corresponding Ack
frame has been transmitted.
6.3.57.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMINGMSMT.indication(
Peer MAC Address,
Dialog Token,
Follow Up Dialog Token,
t1,
Max t1 Error,
t4,
Max t4 Error,
t2,
Max t2 Error,
t3,
Max t3 Error,
VendorSpecific
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual the Timing Measurement frame was sent.
addressed MAC
Address
Dialog Token Integer 1–255 The dialog token to identify the Timing
Measurement frame.
Follow Up Dialog Integer 1–255 The dialog token of a Timing Measurement frame
Token which the current frame follows, or 0 if there is no
such frame. See 11.24.5.
t1 32-bit unsigned 0 – (232–1) The value of t1 (see Figure 6-16) for the Timing
integer Measurement frame identified by the Follow Up
Dialog Token, contained in the Timing
Measurement frame identified by the Dialog
Token, in units of 10 ns, or null if the Follow Up
Dialog Token is 0.
Max t1 Error Integer 0–255 The maximum error in the t1 value in units of 10
ns; see 9.6.15.3, or null if the Follow Up Dialog
Token is 0.
t4 32-bit unsigned 0 – (232–1) The value of t4 (see Figure 6-16) for the Timing
integer Measurement frame identified by the Follow Up
Dialog Token, contained in the Timing
Measurement frame identified by the Dialog
Token, in units of 10 ns, or null if the Follow Up
Dialog Token is 0.
Max t4 Error Integer 0–255 The maximum error in the t4 value in units of 10
ns, or null if the Follow Up Dialog Token is 0.
440
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
t2 32-bit unsigned 0 – (232–1) The value of t2 (see Figure 6-16) for the Timing
Integer Measurement frame identified by the Dialog
Token, in units of 10 ns, or null if the Dialog Token
is 0.
Max t2 Error Integer 0–255 The maximum error in the t2 value in units of 10
ns, or null if the Dialog Token is 0.
t3 32-bit unsigned 0 – (232–1) The value of t3 (see Figure 6-16) for the Timing
integer Measurement frame identified by the Dialog
Token, in units of 10 ns, or null if the Dialog Token
is 0.
Max t3 Error Integer 0–255 The maximum error in the t3 value in units of 10
ns, or null if the Dialog Token is 0.
VendorSpecific A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.57.4.3 When generated
This primitive is generated by the MLME when a valid Timing Measurement frame is received.
6.3.57.4.4 Effect of receipt
On receipt of this primitive, the SME uses the information contained within the notification.
6.3.58 Fine timing measurement (FTM)
6.3.58.1 General
The following set of primitives supports exchange of FTM information from one SME to another. The
informative diagram in Figure 6-17 depicts various points in time that are of interest to the FTM procedure.
STA A STA B
SME MLME Antenna Antenna MLME SME
t1
MLME-FINETIMINGMSMT
.request t2
MLME-FINETIMINGMSMT
.indication
MLME-FINETIMINGMSMT t3
.confirm
t4
Figure 6-17—Fine timing measurement primitives and timestamps capture
NOTE 1—In Figure 6-17, t1 and t3 correspond to the point in time at which the start of the preamble for the transmitted
frame appears at the transmit antenna connector. An implementation may capture a timestamp during the transmit
processing earlier or later than the point at which it actually occurs and offset the value to compensate for the time
difference.
NOTE 2—In Figure 6-17, t2 and t4 correspond to the point in time at which the start of the preamble for the incoming
frame arrives at the receive antenna connector. Because time is needed to detect the frame and synchronize with its
logical structure, an implementation determines when the start of the preamble for the incoming frame arrived at the
441
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
receive antenna connector by capturing a timestamp some time after it occurred and compensating for the delay by
subtracting an offset from the captured value.
NOTE 3—In the MLME-FINETIMINGMSMT.request primitive the t1, Max t1 Error Exponent, t4 and Max t4 Error
Exponent parameters are set to the values in the prior MLME-FINETIMINGMSMT.confirm primitive for that Peer
MAC Address and with a Dialog Token parameter equal to the Follow Up Dialog Token parameter in the request, or 0 if
there was none. In the MLME-FINETIMIMGMSMT.confirm primitive the t1, Max t1 Error Exponent, t4 and Max t4
Error Exponent parameters are set to the values determined for the Fine Timing Measurement frame and its
acknowledgment. This primitive is not issued if no acknowledgment is received. In the MLME-
FINETIMINGMSMT.indication primitive the t1, Max t1 Error Exponent, t4 and Max t4 Error Exponent parameters are
set to the values in the Fine Timing Measurement frame and the t2, Max t2 Error Exponent, t3 and Max t3 Error
Exponent parameters are set to the values determined for the Fine Timing Measurement frame and its acknowledgment.
6.3.58.2 MLME-FINETIMINGMSMT.request
6.3.58.2.1 Function
This primitive requests the transmission of a Fine Timing Measurement frame to a peer entity.
6.3.58.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FINETIMINGMSMT.request(
Peer MAC Address,
Dialog Token,
Follow Up Dialog Token,
t1,
Max t1 Error Exponent,
t4,
Max t4 Error Exponent,
FTM Synchronization Information,
LCI Report,
Location Civic Report,
Fine Timing Measurement Parameters,
VendorSpecific
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual Fine Timing Measurement frame is sent.
addressed MAC
Address
Dialog Token Integer 0–255 The dialog token to identify the Fine Timing
Measurement frame. A value of 0 indicates the
end of the FTM session.
Follow Up Dialog Integer 0–255 The dialog token of a Fine Timing Measurement
Token frame which the current frame follows, or 0 if
there is no such frame. See 11.24.6.
t1 Integer 0–(248–1) The value of t1 (see Figure 6-17) for the Fine
Timing Measurement frame identified by the
Follow Up Dialog Token, in units of picoseconds,
or null if the Follow Up Dialog Token is 0.
Max t1 Error Integer 0–31 The maximum error in the t1 value. This is
Exponent represented using a function of the Max t1 Error
Exponent parameter as defined in Equation (9-4),
or is null if the Follow Up Dialog Token is 0.
442
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
48
t4 Integer 0–(2 –1) The value of t4 (see Figure 6-17) for the Fine
Timing Measurement frame identified by the
Follow Up Dialog Token, in units of picoseconds,
or null if the Follow Up Dialog Token is 0.
Max t4 Error Integer 0–31 The maximum error in the t4 value. This is
Exponent represented using a function of the Max t4 Error
Exponent parameter as defined in Equation (9-4),
or is null if the Follow Up Dialog Token is 0.
FTM As defined in As defined in Optional element to report synchronization
Synchronization 9.4.2.173 9.4.2.173 information of sender
Information
LCI Report As defined in As defined in Optional element to report LCI information of
9.6.8.33 9.6.8.33 sender
Location Civic As defined in As defined in Optional element to report location civic
Report 9.6.8.33 9.6.8.33 information of sender
Fine Timing As defined in As defined in Optional element containing the proposed FTM
Measurement 9.4.2.168 9.4.2.168 configuration
Parameters
VendorSpecific A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.58.2.3 When generated
This primitive is generated by the SME to request that a Fine Timing Measurement frame be sent to a peer
entity.
6.3.58.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Fine Timing Measurement frame with the specified
parameters. This frame is then scheduled for transmission.
6.3.58.3 MLME-FINETIMINGMSMT.confirm
6.3.58.3.1 Function
This primitive indicates that a Fine Timing Measurement frame has been received by the peer STA to which
it was sent.
6.3.58.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FINETIMINGMSMT.confirm(
Peer MAC Address,
Dialog Token,
t1,
Max t1 Error Exponent,
t4,
Max t4 Error Exponent
)
443
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which
individual acknowledges the receipt of the Fine Timing
addressed MAC Measurement frame.
Address
Dialog Token Integer 0–255 The dialog token to identify the Fine Timing
Measurement frame. A value of 0 indicates the
end of the FTM session.
t1 48-bit unsigned 0–(248–1) The value of t1 (see Figure 6-17) for the Fine
Integer Timing Measurement frame identified by the
Dialog Token, in units of picoseconds, or null if
the Dialog Token is 0.
Max t1 Error Integer 0–31 The maximum error in the t1 value. This is
Exponent represented using a function of the Max t1 Error
Exponent parameter as defined in Equation (9-4),
or is null if the Dialog Token is 0.
t4 48-bit unsigned 0–(248–1) The value of t4 (see Figure 6-17) for the Fine
Integer Timing Measurement frame identified by the
Dialog Token, in units of picoseconds, or null if
the Dialog Token is 0.
Max t4 Error Integer 0–31 The maximum error in the t4 value. This is
Exponent represented using a function of the Max t4 Error
Exponent parameter as defined in Equation (9-4),
or is null if the Dialog Token is 0.
6.3.58.3.3 When generated
This primitive is generated by the MLME when an Ack frame corresponding to the Fine Timing
Measurement frame is received from the peer STA.
6.3.58.3.4 Effect of receipt
On receipt of this primitive, the SME uses the information contained within the notification.
6.3.58.4 MLME-FINETIMINGMSMT.indication
6.3.58.4.1 Function
This primitive indicates that a Fine Timing Measurement frame has been received and the corresponding
Ack frame has been transmitted.
6.3.58.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FINETIMINGMSMT.indication(
Peer MAC Address,
Dialog Token,
Follow Up Dialog Token,
t1,
Max t1 Error Exponent,
t4,
Max t4 Error Exponent,
t2,
Max t2 Error Exponent
t3,
444
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Max t3 Error Exponent,
FTM Synchronization Information,
LCI Report,
Location Civic Report,
Fine Timing Measurement Parameters,
VendorSpecific
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual the Fine Timing Measurement frame was sent.
addressed MAC
Address
Dialog Token Integer 0–255 The dialog token to identify the Fine Timing
Measurement frame. A value of 0 indicates the
end of the FTM session.
Follow Up Dialog Integer 0–255 The dialog token of a Fine Timing Measurement
Token frame which the current frame follows, or 0 if
there is no such frame. See 11.24.6.
t1 48-bit unsigned 0–(248–1) The value of t1 (see Figure 6-17) for the Fine
integer Timing Measurement frame identified by the
Follow Up Dialog Token, contained in the Fine
Timing Measurement frame identified by the
Dialog Token, in units of picoseconds, or null if
the Follow Up Dialog Token is 0.
Max t1 Error Integer 0–31 The maximum error in the t1 value. This is
Exponent represented using a function of the Max t1 Error
Exponent parameter as defined in Equation (9-4),
or is null if the Follow Up Dialog Token is 0.
t4 48-bit unsigned 0–(248–1) The value of t4 (see Figure 6-17) for the Fine
integer Timing Measurement frame identified by the
Follow Up Dialog Token, contained in the Fine
Timing Measurement frame identified by the
Dialog Token, in units of picoseconds, or null if
the Follow Up Dialog Token is 0.
Max t4 Error Integer 0–31 The maximum error in the t4 value. This is
Exponent represented using a function of the Max t4 Error
Exponent parameter as defined in Equation (9-4),
or is null if the Follow Up Dialog Token is 0.
t2 48-bit unsigned 0–(248–1) The value of t2 (see Figure 6-17) for the Fine
Integer Timing Measurement frame identified by the
Dialog Token, in units of picoseconds, or null if
the Dialog Token is 0.
Max t2 Error Integer 0–31 The maximum error in the t2 value. This is
Exponent represented using a function of the Max t2 Error
Exponent parameter defined in Equation (9-4), or
is null if the Dialog Token is 0.
t3 48-bit unsigned 0–(248–1) The value of t3 (see Figure 6-17) for the Fine
integer Timing Measurement frame identified by the
Dialog Token, in units of picoseconds, or null if
the Dialog Token is 0.
Max t3 Error Integer 0–31 The maximum error in the t3 value. This is
Exponent represented using a function of the Max t3 Error
Exponent parameter defined in Equation (9-4), or
is null if the Dialog Token is 0.
FTM As defined in As defined in Optional element to report synchronization
Synchronization 9.4.2.173 9.4.2.173 information of sender
Information
445
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
LCI Report As defined in As defined in Optional element to report LCI information of
9.6.8.33 9.6.8.33 sender
Location Civic As defined in As defined in Optional element to report location civic
Report 9.6.8.33 9.6.8.33 information of sender
Fine Timing As defined in As defined in Optional element containing the proposed FTM
Measurement 9.4.2.168 9.4.2.168 configuration
Parameters
VendorSpecific A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.58.4.3 When generated
This primitive is generated by the MLME when a valid Fine Timing Measurement frame is received.
6.3.58.4.4 Effect of receipt
On receipt of this primitive, the SME uses the information contained within the notification.
6.3.59 BSS transition management
6.3.59.1 BSS transition management procedure
The informative diagram shown in Figure 6-18 depicts the BSS transition management procedure and is not
meant to be exhaustive of all possible protocol uses.
6.3.59.2 MLME-BTMQUERY.request
This set of primitives supports the signaling of BSS Transition Management Query frames between non-AP
STAs and an AP.
6.3.59.2.1 Function
This primitive requests transmission of a BSS Transition Management Query frame to the AP with which
the STA is associated.
6.3.59.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BTMQUERY.request(
Peer MAC Address,
DialogToken,
BSSTransitionQueryReason,
BSSTransitionCandidateListEntries,
VendorSpecificInfo
)
446
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
AP Non-AP STA
SME MLME MLME SME
Decision to request or
provide BSS transition
candidate AP list
MLME-BTMQUERY BSS Transition Management
.indication MLME-BTMQUERY
Query frame (optional)
.request
Decision to send autonomous BSS
Transition Request or triggered by
BSS Transition Query
BSS Transition Management MLME-BTM.indication
MLME-BTM.request Request frame
STA roaming evaluation
and decision
BSS Transition Management MLME-BTM.response
MLME-BTM.confirm
Response frame (optional)
STA reassociation
or Fast BSS
Transition
STA reassociation
Figure 6-18—BSS transition management request—accepted
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC BSS Transition Management Query frame is sent.
Address
DialogToken Integer 1–255 The dialog token to identify this BSS transition
management transaction.
BSSTransitionQuery Integer 0–255 As defined in 9.6.14.8.
Reason
BSSTransitionCandi Set of Neighbor Set of Neighbor Contains the description of candidate BSS
dateListEntries Report Elements Report Elements transition APs and their capabilities as described
as defined in the in 9.4.2.37.
Neighbor
Report Element
in 9.4.2.37
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
447
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.59.2.3 When generated
This primitive is generated by the SME to request that a BSS Transition Management Query frame be sent to
the AP with which the STA is associated to initiate a BSS transition management procedure.
6.3.59.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a BSS Transition Management Query frame. The STA
then attempts to transmit the frame to the AP with which it is associated.
6.3.59.3 MLME-BTMQUERY.indication
6.3.59.3.1 Function
This primitive indicates that a BSS Transition Management Query frame was received from a non-AP STA.
6.3.59.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BTMQUERY.indication(
Peer MAC Address,
DialogToken,
BSSTransitionQueryReason,
BSSTransitionCandidateListEntries,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which a BSS Transition Management Query
Address frame was received.
DialogToken Integer 1–255 The dialog token to identify the BSS transition
management transaction received in the BSS
Transition Management Query frame.
BSSTransitionQuery Integer 0–255 The BSS Transition Query Reason Code in the
Reason BSS Transition Management Query frame that
was received.
BSSTransitionCandi Set of Neighbor Set of Neighbor Contains the description of candidate BSS
dateListEntries Report Elements Report Elements transition APs and their capabilities as described
as defined in the in 9.4.2.37.
Neighbor
Report Element
in 9.4.2.37
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.59.3.3 When generated
This primitive is generated by the MLME when a valid BSS Transition Management Query frame is
received.
6.3.59.3.4 Effect of receipt
On receipt of this primitive, the SME shall operate according to the procedure in 11.24.7.
448
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.59.4 MLME-BTM.request
6.3.59.4.1 Function
This primitive requests transmission of a BSS Transition Management Request frame to a non-AP STA.
6.3.59.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BTM.request(
Peer MAC Address
DialogToken,
RequestMode,
DisassociationTimer,
ValidityInterval,
BSSTerminationDuration,
SessionInformationURL,
BSSTransitionCandidateListEntries,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC BSS Transition Management Request frame is
Address sent.
DialogToken Integer 1–255 The dialog token to identify the BSS transition
management transaction. Set to 0 for an
autonomous BSS Transition Management
Request frame.
RequestMode Integer As specified in Contains RequestMode for the BSS Transition
9.6.14.10 Management Request frame.
DisassociationTimer Integer 0 – 65 535 Specifies the number of TBTTs until the AP
disassociates the non-AP STA. A value of 0
indicates time of disassociation has not yet been
determined and a value of 1 indicates
disassociation shall occur before the next TBTT.
ValidityInterval Integer 1–255 Specifies the number of beacon transmission
times (TBTTs) until this recommendation of this
BSS transition candidate list is no longer valid.
BSSTerminationDura BSS BSS Contains the BSS Termination Duration
tion Termination Termination subelement (see 9.4.2.37) for the current BSS and
Duration Duration is
subelement subelement present only when the BSS Termination Included
field is 1 in the Request mode field.
SessionInformationU URL n/a Optionally contains a URL formatted per IETF
RL RFC 3986 where additional information
pertaining to the user’s accounting session is
found.
BSSTransitionCandi Set of Neighbor Set of Neighbor Contains the description of candidate BSS
dateListEntries Report Elements Report Elements transition APs and their capabilities as described
as defined in the in 9.4.2.37.
Neighbor
Report Element
in 9.4.2.37
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
449
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.59.4.3 When generated
This primitive is generated by the SME to request that a BSS Transition Management Request frame be sent
to an associated non-AP STA. This request is sent either following the reception of an MLME-
BTMQUERY.indication primitive or may be sent autonomously.
6.3.59.4.4 Effect of receipt
On receipt of this primitive, the MLME constructs a BSS Transition Management Request frame. The STA
then attempts to transmit this frame to the indicated non-AP STA.
6.3.59.5 MLME-BTM.indication
6.3.59.5.1 Function
This primitive indicates that a BSS Transition Management Request frame was received from the AP with
which the STA is associated.
6.3.59.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BTM.indication(
PeerMACAddress,
DialogToken,
RequestMode,
DisassociationTimer,
ValidityInterval,
BSSTerminationDuration,
SessionInformationURL,
BSSTransitionCandidateListEntries,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid The address of the MAC entity from which a BSS
individual MAC Transition Management Request frame was
Address received.
DialogToken Integer 1–255 The dialog token to identity the BSS transition
management transaction as received in the BSS
Transition Management Request frame.
RequestMode Integer As specified in Contains the RequestMode for the BSS
9.6.14.10 Transition Management Request frame.
Disassociation Integer 0 – 65 535 Specifies the number of TBTTs until the AP
Timer disassociates the non-AP STA. A value of 0
indicates time of disassociation has not been
determined yet and a value of 1 indicates
disassociation shall occur before the next TBTT.
ValidityInterval Integer 1–255 Specifies the number of beacon transmission
times (TBTTs) until this recommendation of this
BSS transition candidate list is no longer valid.
BSSTerminationDura BSS BSS Contains the BSS Termination Duration
tion Termination Termination subelement (see 9.4.2.37) for the current BSS and
Duration Duration is present only when the BSS Termination
subelement subelement Included field is 1 in the Request mode field.
450
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
SessionInformationU URL n/a Optionally contains a URL formatted per IETF
RL RFC 3986 where additional information
pertaining to the user’s accounting session may
be found.
BSSTransitionCandi Set of Neighbor Set of Neighbor Contains the description of candidate BSS
dateListEntries Report Elements Report Elements transition APs and their capabilities as described
as defined in the in 9.4.2.37.
Neighbor
Report Element
in 9.4.2.37
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.59.5.3 When generated
This primitive is generated by the MLME when a valid BSS Transition Management Request frame is
received.
6.3.59.5.4 Effect of receipt
On receipt of this primitive the SME shall operate according to the procedure in 11.24.7.
6.3.59.6 MLME-BTM.response
6.3.59.6.1 Function
This primitive requests transmission of a BSS Transition Management Response frame to the AP with which
the STA is associated.
6.3.59.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BTM.response(
Peer MAC Address
DialogToken,
BTMStatusCode,
BSSTerminationDelay,
TargetBSSID,
BSSTransitionCandidateListEntries,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC BSS Transition Management Query frame is sent.
Address
DialogToken Integer 1–255 The dialog token to identify the BSS transition
management transaction.
BTMStatusCode Integer 0–255 As defined in 9.6.14.10.
BSSTerminationDelay Integer 0–255 As defined in 9.6.14.10.
TargetBSSID MACAddress Any valid The BSSID of the BSS that the STA decided to
individual MAC transition to. Field shall be null if STA decided
Address not to transition.
451
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
BSSTransitionCandida Set of Neighbor Set of Neighbor Contains the description of candidate BSS
teListEntries Report Elements Report Elements transition APs and their capabilities as described
as defined in the in 9.4.2.37.
Neighbor
Report Element
in 9.4.2.37
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.59.6.3 When generated
This primitive is generated by the SME to request that a BSS Transition Management Response frame be
sent to the AP with which the STA is associated.
6.3.59.6.4 Effect of receipt
On receipt of this primitive, the MLME constructs a BSS Transition Management Response frame. The non-
AP STA then attempts to transmit this to the AP with which it is associated.
6.3.59.7 MLME-BTM.confirm
6.3.59.7.1 Function
This primitive reports the results of a BSS Transition Management attempt with a specified peer MAC entity
that is within an AP.
6.3.59.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BTM.confirm(
Peer MAC Address,
DialogToken,
BSSTransitionQueryReason,
BTMStatusCode,
BSSTerminationDelay,
TargetBSSID,
BSSTransitionCandidateListEntries,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MAC Address Any valid The address of the non-AP STA MAC entity
individual MAC from which a BSS Transition Management
Address Response frame was received.
DialogToken Integer 1–255 The dialog token to identify the BSS transition
management transaction as received in the BSS
Transition Management Response frame.
BTMStatusCode Integer 0–255 As defined in 9.6.14.10.
BSSTerminationDelay Integer 0–255 As defined in 9.6.14.10.
TargetBSSID MACAddress Any valid The BSSID of the BSS that the STA indicated to
individual MAC transition to as received in the BSS Transition
Address Management Response frame.
452
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
BSSTransitionCandida Set of Neighbor Set of Neighbor Contains the BSS Transition Candidate List
teListEntries Report Elements Report Elements Entries in the received BSS Transition
as defined in the Management Response frame.
Neighbor
Report Element
in 9.4.2.37
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.59.7.3 When generated
This primitive is generated by the MLME when transmission of the BSS Transition Management Request
frame is acknowledged, when (re)transmission of the BSS Transition Management Request frame fails, or
when a failure reason is unspecified.
6.3.59.7.4 Effect of receipt
On receipt of this primitive, the SME shall operate according to the procedure in 11.24.7.
6.3.60 FMS setup
6.3.60.1 General
The following MLME primitives support the signaling of FMS setup. The informative diagram shown in
Figure 6-19 depicts the FMS setup process and is not meant to be exhaustive of all possible protocol uses.
STA A STA B
SME MLME MLME SME
MLME-FMS MLME-FMS
.request FMS Request frame .indication
Process FMS Action
MLME-FMS
MLME-FMS.confirm
FMS Response frame .response
Figure 6-19—FMS setup protocol exchange
453
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.60.2 MLME-FMS.request
6.3.60.2.1 Function
This primitive requests that an FMS Request frame be sent to the AP with which the non-AP STA is
associated.
6.3.60.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FMS.request(
PeerSTAAddress,
DialogToken,
FMSRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with
individual MAC which to perform the FMS process.
Address
Dialog Token Integer 1–255 The dialog token to identify the FMS transaction.
FMSRequest FMS Request As defined in Specifies the proposed service parameters for the
element 9.4.2.76 FMS.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.60.2.3 When generated
This primitive is generated by the SME to request that an FMS Request frame be sent to the AP with which
the STA is associated.
6.3.60.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs an FMS Request frame. The STA then attempts to
transmit this to the AP with which it is associated.
6.3.60.3 MLME-FMS.confirm
6.3.60.3.1 Function
This primitive reports the result of an FMS procedure.
6.3.60.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- FMS.confirm(
Peer MAC Address,
Dialog Token,
FMSResponse,
VendorSpecificInfo
)
454
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC location response is sent.
Address
Dialog Token Integer 0–255 The dialog token to identify the FMS transaction.
FMSResponse FMS Response As defined in Specifies service parameters for the FMS.
element 9.4.2.77
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.60.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-FMS.request primitive and indicates the
results of the request. This primitive is generated when the STA receives an FMS Response frame from the
AP.
6.3.60.3.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.16.
6.3.60.4 MLME-FMS.indication
6.3.60.4.1 Function
This primitive indicates that an FMS Request frame was received from a non-AP STA.
6.3.60.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- FMS.indication(
PeerSTAAddress,
DialogToken,
FMSRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which an FMS Request frame was received.
Address
Dialog Token Integer 1–255 The dialog token to identify the FMS transaction.
FMSRequest FMS Request As defined in Specifies the proposed service parameters for the
element 9.4.2.76 FMS.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.60.4.3 When generated
This primitive is generated by the MLME when a valid FMS Request frame is received.
6.3.60.4.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.16.
455
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.60.5 MLME-FMS.response
6.3.60.5.1 Function
This primitive is either generated in response to a received FMS Request frame or autonomously by the AP
and requests the transmission of an FMS Response frame.
6.3.60.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FMS.response(
PeerSTAAddress,
FMSResponse,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which an FMS Request frame was received.
Address
Dialog Token Integer 0–255 The dialog token to identify the FMS transaction.
FMSResponse FMS Response As defined in Specifies service parameters for the FMS.
element 9.4.2.77
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.60.5.3 When generated
This primitive is generated by the SME to request that an FMS Response frame be sent to a peer entity to
convey FMS information.
6.3.60.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs an FMS Response frame. The STA then attempts to
transmit this to the non-AP STA indicated by the PeerSTAAddress parameter.
6.3.61 Collocated Interference request
6.3.61.1 General
This set of primitives supports the exchange of collocated interference information between peer SMEs. The
informative diagram shown in Figure 6-20 depicts the Collocated Interference request and response process
and is not meant to be exhaustive of all possible protocol uses.
456
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA A STA B
SME MLME MLME SME
MLME- MLME-
Collocated Interference
CLINTERFERENCE CLINTERFERENCE
Request frame
REQUEST.request REQUEST.indication
Measurement
process
MLME- MLME-
CLINTERFERENCE Collocated Interference CLINTERFERENCE
REPORT.indication Response frame REPORT.request
Figure 6-20—Collocated interference protocol exchange
6.3.61.2 MLME-CLINTERFERENCEREQUEST.request
6.3.61.2.1 Function
This primitive requests the transmission of Collocated Interference Request frame to a peer entity.
6.3.61.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CLINTERFERENCEREQUEST.request(
Peer MAC Address,
Dialog Token,
Request Info,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC collocated interference request is sent.
Address, or the
group MAC
address
457
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Dialog Token Integer 1–255 The dialog token to identify the collocated
interference transaction.
Request Info Integer As defined in Specifies the requested information.
the Collocated
Interference
Request frame,
see 9.6.14.13
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.61.2.3 When generated
This primitive is generated by the SME to request that a Collocated Interference Request frame be sent to a
peer entity.
6.3.61.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Collocated Interference Request frame. This frame is
then scheduled for transmission.
6.3.61.3 MLME-CLINTERFERENCEREQUEST.indication
6.3.61.3.1 Function
This primitive indicates that a Collocated Interference Request frame has been received requesting a
Collocated Interference report.
6.3.61.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CLINTERFERENCEREQUEST.indication(
Peer MAC Address,
Dialog Token,
Request Info,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual MAC the Collocated Interference request was received.
Address or the
group MAC
address
Dialog Token Integer 1–255 The dialog token to identify the collocated
interference transaction.
Request Info Integer As defined in Specifies the requested information.
the Collocated
Interference
Request frame,
see 9.6.14.13
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
458
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.61.3.3 When generated
This primitive is generated by the MLME when a valid Collocated Interference Request frame is received.
6.3.61.3.4 Effect of receipt
On receipt of this primitive, the SME either rejects the request or commences the Collocated Interference
reporting procedure as described in 11.24.9.
6.3.62 Collocated Interference report
6.3.62.1 General
This set of primitives supports the exchange of collocated interference information between peer SMEs.
6.3.62.2 MLME-CLINTERFERENCEREPORT.request
6.3.62.2.1 Function
This primitive requests the transmission of Collocated Interference Report to a peer entity, in response to a
received Collocated Interference Request frame.
6.3.62.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CLINTERFERENCEREPORT.request(
Peer MAC Address,
Dialog Token,
Collocated Interference Report,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the
individual MAC Collocated Interference Report is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the collocated
interference transaction.
Collocated Collocated As defined in Specifies the collocated interference
Interference Report Interference 9.4.2.85 characteristics.
Report elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.62.2.3 When generated
This primitive is generated by the SME to request that a Collocated Interference Report frame be sent to a
peer entity to convey collocated interference information.
6.3.62.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Collocated Interference Report frame. This frame is
then scheduled for transmission.
459
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.62.3 MLME-CLINTERFERENCEREPORT.indication
6.3.62.3.1 Function
This primitive indicates that a Collocated Interference Report frame has been received.
6.3.62.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CLINTERFERENCEREPORT.indication(
Peer MAC Address,
Dialog Token,
Collocated Interference Report,
VendorSpecificInfo
)
Name Type Valid range Description
Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which
individual MAC the location response was received.
Address
Dialog Token Integer 1–255 The dialog token to identify the location
transaction.
Collocated Collocated As defined in Specifies the collocated interference
Interference Report Interference 9.4.2.85 characteristics.
Report elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.62.3.3 When generated
This primitive is generated by the MLME when a valid Collocated Interference Report frame is received.
6.3.63 TFS setup
6.3.63.1 General
This set of primitives supports the exchange of the signaling of TFS setup between peer SMEs. The
informative diagram shown in Figure 6-21 depicts the TFS request and response process and is not meant to
be exhaustive of all possible protocol uses.
460
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
AP Non-AP STA
SME MLME MLME SME
MLME-
TFS.indication TFS Request frame
MLME-TFS.request
Process TFS
TFS Operation
Request Action
MLME-TFS.response TFS Response frame MLME-TFS.confirm
Figure 6-21—TFS request and response exchange
6.3.63.2 MLME-TFS.request
6.3.63.2.1 Function
This primitive requests that a TFS Request frame be sent to the AP with which the STA is associated.
6.3.63.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TFS.request(
PeerSTAAddress,
DialogToken,
TFSRequest,
VendorSpecific
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity for
individual MAC TFS.
Address
DialogToken Integer 0–255 The dialog token to identify the TFS Request and
Response transaction.
TFSRequest A set of TFS As defined in Specifies the proposed service parameters for the
Request the TFS Request TFS. One or more TFS Request elements.
elements element
VendorSpecific A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.63.2.3 When generated
This primitive is generated by the SME to request that a TFS Request frame be sent to the AP with which the
STA is associated.
461
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.63.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TFS Request frame. The STA then attempts to transmit
this to the AP with which it is associated.
6.3.63.3 MLME-TFS.confirm
6.3.63.3.1 Function
This primitive reports the result of a TFS procedure.
6.3.63.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TFS.confirm(
PeerSTAAddress,
DialogToken,
TFSResponse,
VendorSpecific
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity from which
individual MAC the TFS Response frame is received.
Address
DialogToken Integer 0–255 The dialog token to identify the TFS Request and
Response transaction.
TFSResponse A set of TFS As defined in Specifies service parameters for the TFS. One or
Response the TFS more TFS Response elements.
elements Response
element
VendorSpecific A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.63.3.3 When generated
This primitive is generated by the MLME when the STA receives a TFS Response frame from the AP.
6.3.63.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the result and may use the reported data. The SME should
operate according to the procedure in 11.24.12.
6.3.63.4 MLME-TFS.indication
6.3.63.4.1 Function
This primitive indicates that a TFS Request frame was received from a non-AP STA.
462
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.63.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TFS.indication(
PeerSTAAddress,
DialogToken,
TFSRequest,
VendorSpecific
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which a TFS Request frame was received.
Address
DialogToken Integer 0–255 The dialog token to identify the TFS Request and
Response transaction.
TFSRequest A set of TFS As defined in Specifies the proposed service parameters for the
Request the TFS Request TFS. One or more TFS Request elements.
elements element
VendorSpecific A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.63.4.3 When generated
This primitive is generated by the MLME when a valid TFS Request frame is received.
6.3.63.4.4 Effect of receipt
On receipt of this primitive the SME should operate according to the procedure in 11.24.12.
6.3.63.5 MLME-TFS.response
6.3.63.5.1 Function
This primitive is generated in response to an MLME-TFS.indication primitive requesting a TFS Response
frame be sent to a non-AP STA.
6.3.63.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TFS.response(
PeerSTAAddress,
DialogToken,
TFSResponse,
VendorSpecific
)
463
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which a TFS Request frame was received.
Address
DialogToken Integer 0–255 The dialog token to identify the TFS Request and
Response transaction.
TFSResponse A set of TFS As defined in Specifies service parameters for the TFS. One or
Response 9.4.2.81 more TFS Response elements.
elements
VendorSpecific A set of As defined in Zero or more elements.
elements. 9.4.2.26
6.3.63.5.3 When generated
This primitive is generated by the SME in response to an MLME-TFS.indication primitive requesting a TFS
Response be sent to a non-AP STA.
6.3.63.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TFS Response frame. The STA then attempts to
transmit this to the non-AP STA indicated by the PeerSTAAddress parameter.
6.3.64 WNM sleep mode request
6.3.64.1 General
This set of primitives supports the exchange of sleep mode parameter information between peer SMEs. The
informative diagram shown in Figure 6-22 depicts the sleep mode request and response process and is not
meant to be exhaustive of all possible protocol uses.
AP Non-AP STA
SME MLME MLME SME
MLME-SLEEPMODE WNM Sleep Mode Request
MLME-SLEEPMODE
.indication frame
.request
Process WNM sleep
mode request
MLME-SLEEPMODE WNM Sleep Mode Response MLME-SLEEPMODE
.response frame .confirm
Figure 6-22—WNM sleep mode request and response exchange
464
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.64.2 MLME-SLEEPMODE.request
6.3.64.2.1 Function
This primitive requests that a WNM Sleep Mode Request frame be sent to the AP with which the STA is
associated.
6.3.64.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SLEEPMODE.request(
PeerSTAAddress,
DialogToken,
SleepMode,
TFSRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the
individual MAC WNM Sleep Mode Request frame is to be sent.
Address
DialogToken Integer 0–255 The dialog token to identify the WNM sleep
mode request and response transaction.
SleepMode As defined in As defined in Specifies the proposed WNM sleep mode service
the WNM Sleep the WNM Sleep parameters for the WNM Sleep Mode Request
Mode Mode frame.
element element
TFSRequest A set of TFS As defined in Specifies the proposed TFS service parameters
Request 9.4.2.80 for the WNM Sleep Mode Request frame.
elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.64.2.3 When generated
This primitive is generated by the SME to request that a WNM Sleep Mode Request frame be sent to the AP
with which the STA is associated.
6.3.64.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a WNM Sleep Mode Request frame. The STA then
attempts to transmit this to the AP with which it is associated.
6.3.64.3 MLME-SLEEPMODE.indication
6.3.64.3.1 Function
This primitive indicates that a WNM Sleep Mode Request frame was received from a non-AP STA.
465
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.64.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SLEEPMODE.indication(
PeerSTAAddress,
DialogToken,
SleepMode,
TFSRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the peer MAC entity from which
individual MAC the WNM Sleep Mode Request frame is received.
Address
DialogToken Integer 0–255 The dialog token to identify the WNM sleep
mode request and response transaction.
SleepMode As defined in As defined in Specifies the proposed WNM sleep mode service
the WNM Sleep the WNM Sleep parameters for the WNM Sleep Mode Request
Mode Mode frame.
element element
TFSRequest A set of TFS As defined in Specifies the proposed TFS service parameters
Request 9.4.2.80 for the WNM Sleep Mode Request frame.
elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.64.3.3 When generated
This primitive is generated by the MLME when a valid WNM Sleep Mode Request frame is received.
6.3.64.3.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.18.
6.3.64.4 MLME-SLEEPMODE.response
6.3.64.4.1 Function
This primitive requests the transmission of sleep mode information to a peer entity, in response to a received
WNM Sleep Mode Request frame.
6.3.64.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SLEEPMODE.response(
PeerSTAAddress,
DialogToken,
SleepMode,
TFSResponse,
VendorSpecificInfo
)
466
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the
individual MAC WNM Sleep Mode Response frame is to be sent.
Address
DialogToken Integer 0–255 The dialog token to identify the WNM sleep
mode request and response transaction.
SleepMode As defined in As defined in Specifies the proposed WNM sleep mode service
the WNM Sleep the WNM Sleep parameters for the WNM Sleep Mode Response
Mode Mode frame.
element element
TFSResponse A set of TFS As defined in Specifies the proposed TFS service parameters
Request 9.4.2.81 for the WNM Sleep Mode Response frame.
elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.64.4.3 When generated
This primitive is generated by the SME to request that a WNM Sleep Mode Response frame be sent to a peer
entity to convey WNM sleep mode information.
6.3.64.4.4 Effect of receipt
On receipt of this primitive, the MLME constructs a WNM Sleep Mode Response frame containing the
WNM Sleep Mode elements specified. This frame is then scheduled for transmission.
6.3.64.5 MLME-SLEEPMODE.confirm
6.3.64.5.1 Function
This primitive reports the result of a request to send a WNM Sleep Mode Response frame.
6.3.64.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SLEEPMODE.confirm(
PeerSTAAddress,
DialogToken,
SleepMode,
TFSResponse,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity from which
individual MAC the WNM Sleep Mode Response frame is
Address received.
DialogToken Integer 0–255 The dialog token to identify the WNM sleep
mode request and response transaction.
SleepMode As defined in As defined in Specifies the proposed WNM sleep mode service
the WNM Sleep the WNM Sleep parameters for the WNM Sleep Mode Response
Mode Mode frame.
element element
467
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
TFSResponse A set of TFS As defined in Specifies the proposed TFS service parameters
Request the TFS for the WNM Sleep Mode Response frame.
elements Response
element
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.64.5.3 When generated
This primitive is generated by the MLME when the STA receives a WNM Sleep Mode Response frame
from the AP.
6.3.64.5.4 Effect of receipt
No effect of receipt is specified.
6.3.65 TIM broadcast setup
6.3.65.1 General
The following MLME primitives support the signaling of TIM Broadcast Setup. The informative diagram
shown in Figure 6-23 depicts the TIM Broadcast setup process and is not meant to be exhaustive of all
possible protocol uses.
STA A STA B
SME MLME MLME SME
MLME- MLME-
TIMBROADCAST TIM Broadcast Request frame TIMBROADCAST
.request .indication
Process TIM Broadcast
Action
MLME- MLME-
TIMBROADCAST TIM Broadcast Response TIMBROADCAST
.confirm frame .response
Figure 6-23—TIM broadcast setup protocol exchange
468
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.65.2 MLME-TIMBROADCAST.request
6.3.65.2.1 Function
This primitive requests that a TIM Broadcast Request frame be sent to the AP with which the non-AP STA
is associated.
6.3.65.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMBROADCAST.request(
PeerSTAAddress,
Dialog Token,
TIMBroadcastRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with
individual MAC which to perform the TIM Broadcast process.
Address
Dialog Token Integer 1–255 The dialog token to identify the TIM Broadcast
request and response transaction.
TIMBroadcastRequ As defined in As defined in Specifies the proposed service parameters for the
est TIM Broadcast 9.4.2.83 TIM Broadcast.
Request element
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.65.2.3 When generated
This primitive is generated by the SME to request that a TIM Broadcast Request frame be sent to the AP
with which the STA is associated.
6.3.65.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TIM Broadcast Request frame. The STA then attempts
to transmit this to the AP with which it is associated.
6.3.65.3 MLME-TIMBROADCAST.confirm
6.3.65.3.1 Function
This primitive reports the result of a TIM Broadcast procedure.
6.3.65.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMBROADCAST.confirm(
PeerSTAAddress,
Dialog Token,
TIMBroadcastResponse,
VendorSpecificInfo
)
469
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with
individual MAC which to perform the TIM Broadcast process.
Address
Dialog Token Integer 0–255 The dialog token to identify the TIM Broadcast
request and response transaction.
TIMBroadcastResp As defined in As defined in Specifies service parameters for the TIM
onse TIM Broadcast 9.4.2.84 Broadcast.
Response
element
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.65.3.3 When generated
This primitive is generated by the MLME when the STA receives a TIM Broadcast Response frame from the
AP.
6.3.65.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the results in the TIMBroadcastResponse element and may
use the reported data.
6.3.65.4 MLME-TIMBROADCAST.indication
6.3.65.4.1 Function
This primitive indicates that a TIM Broadcast Request frame was received from a non-AP STA.
6.3.65.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMBROADCAST.indication(
PeerSTAAddress,
Dialog Token,
TIMBroadcastRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which a TIM Broadcast Request frame was
Address received.
Dialog Token Integer 1–255 The dialog token to identify the TIM Broadcast
request and response transaction.
TIMBroadcastRequ As defined in As defined in Specifies the proposed service parameters for the
est TIM Broadcast 9.4.2.83 TIM Broadcast.
Request element
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.65.4.3 When generated
This primitive is generated by the MLME when a valid TIM Broadcast Request frame is received.
470
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.65.4.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.17.
6.3.65.5 MLME-TIMBROADCAST.response
6.3.65.5.1 Function
This primitive is generated in response to an MLME-TIMBROADCAST.indication primitive requesting a
TIM Broadcast Response frame be sent to a non-AP STA.
6.3.65.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMBROADCAST.response(
PeerSTAAddress,
Dialog Token,
TIMBroadcastResponse,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which a TIM Broadcast Request frame was
Address received.
Dialog Token Integer 0–255 The dialog token to identify the TIM Broadcast
request and response transaction.
TIM Broadcast As defined in As defined in Specifies service parameters for the TIM
Response TIM Broadcast 9.4.2.84 Broadcast.
Response
element
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.65.5.3 When generated
This primitive is generated by the SME in response to an MLME-TIMBROADCAST.indication primitive
requesting a TIM Broadcast Response be sent to a non-AP STA.
6.3.65.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TIM Broadcast Response frame. The STA then
attempts to transmit this to the non-AP STA indicated by the PeerSTAAddress parameter.
6.3.66 QoS traffic capability update
6.3.66.1 General
The MLME-QOSTRAFFICCAPUPDATE.request and MLME-QOSTRAFFICCAPUPDATE.indication
primitives provide the transport of QoS Traffic Capability information from a non-AP STA to the AP with
which the STA is associated. The informative diagram shown in Figure 6-24 depicts the QoS traffic
capability update process.
471
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NON-AP STA AP
SME MLME MLME SME
MLME-QOSTRAFFIC QoS Traffic Capability Update MLME-QOSTRAFFIC
CAPUPDATE.request frame CAPUPDATE.indication
Figure 6-24—QoS traffic capability update protocol exchange
6.3.66.2 MLME-QOSTRAFFICCAPUPDATE.request
6.3.66.2.1 Function
This primitive requests that a QoS Traffic Capability Update frame be sent to the AP with which the STA is
associated.
6.3.66.2.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-QOSTRAFFICCAPUPDATE.request(
QoSTrafficCapability,
VendorSpecificInfo
)
Name Type Valid range Description
QoS Traffic Bit field as As defined in Specifies the QoS Traffic Capability flags of the
Capability defined in 9.6.14.23 non-AP STA. This parameter is present if
9.6.14.23 dot11WirelessManagementImplemented is true
and dot11QoSTrafficCapabilityActivated is true,
and it is not present otherwise.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.66.2.3 When generated
This primitive is generated by the SME to request that a QoS Traffic Capability Update frame be sent to the
AP with which the STA is associated.
6.3.66.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a QoS Traffic Capability Update frame. The STA then
attempts to transmit this to the AP with which it is associated.
472
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.66.3 MLME-QOSTRAFFICCAPUPDATE.indication
6.3.66.3.1 Function
This primitive indicates that a QoS Traffic Capability Update frame was received from a non-AP STA.
6.3.66.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QOSTRAFFICCAPUPDATE.indication(
PeerSTAAddress,
QoS Traffic Capability,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which a QoS Traffic Capability Update
Address frame was received.
QoS Traffic Bit field as As defined in Specifies the QoS Traffic Capability flags of the
Capability defined in 9.6.14.23 non-AP STA. This parameter is present if
9.6.14.23 dot11WirelessManagementImplemented is true
and dot11QoSTrafficCapabilityActivated is true,
and it is not present otherwise.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.66.3.3 When generated
This primitive is generated by the MLME when a valid QoS Traffic Capability Update frame is received.
6.3.66.3.4 Effect of receipt
On receipt of this primitive the SME should operate according to the procedure in 11.24.10.
6.3.67 Channel Usage request
6.3.67.1 General
The following MLME primitives support the signaling of Channel Usage request. Figure 6-25 depicts the
Channel Usage request process. The figure illustrates the basic protocol and is only an example and
therefore is not meant to be exhaustive of all possible protocol uses.
473
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA A STA B
SME MLME MLME SME
MLME- MLME-
CHANNELUSAGE CHANNELUSAGE
.request Channel Usage Request frame .indication
Process Channel
Usage request
MLME- MLME-
CHANNELUSAGE CHANNELUSAGE
.confirm Channel Usage Response frame .response
Figure 6-25—Channel usage request protocol exchange
6.3.67.2 MLME-CHANNELUSAGE.request
6.3.67.2.1 Function
This primitive requests the transmission of a Channel Usage Request frame be sent to an AP.
6.3.67.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELUSAGE.request(
PeerSTAAddress,
Dialog Token,
ChannelUsage,
SSID,
SupportedOperatingClasses,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with
individual MAC which to perform the Channel Usage process.
Address
Dialog Token Integer 1–255 The dialog token to identify the Channel Usage
request and response transaction.
ChannelUsage A set of Channel As defined in Specifies request types for the Channel Usage
Usage element 9.4.2.86 request.
474
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
SSID Octet string 0–32 octets Specifies the desired SSID or the wildcard SSID.
SupportedOperating As defined in As defined in Specifies the Supported Operating Classes
Classes Supported 9.4.2.54 information for the Channel Usage Request.
Operating
Classes
element
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.67.2.3 When generated
This primitive is generated by the SME to request that a Channel Usage Request frame be sent to the BSS
which is advertising the SSID passed down in this primitive.
6.3.67.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Channel Usage Request frame. The STA then attempts
to transmit this to the BSS which is advertising the SSID included in this primitive request. When wild card
SSID is passed down, the MLME-CHANNELREQUEST.request primitive shall be transmitted to all BSSs
in the current scan list as determined by the most recent MLME-SCAN.request primitive.
6.3.67.3 MLME-CHANNELUSAGE.confirm
6.3.67.3.1 Function
This primitive reports the result of a Channel Usage procedure.
6.3.67.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELUSAGE.confirm(
PeerSTAAddress,
Dialog Token,
ChannelUsage,
SSID,
Country String,
Power Constraint,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with
individual MAC which to perform the Channel Usage process.
Address
Dialog Token Integer 1–255 The dialog token to identify the Channel Usage
request and response transaction.
ChannelUsage A set of Channel As defined in Specifies parameters for the Channel Usage.
Usage element 9.4.2.86
475
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
SSID Octet string 0–32 octets Specifies the SSID or the wildcard SSID used in
the request.
Country String Octet string 3 octets Specifies Country strings.
Power Constraint An element As defined in Zero or one Power Constraint element.
9.4.2.14
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.67.3.3 When generated
This primitive is generated when the STA receives a Channel Usage Response frame from the AP.
6.3.67.3.4 Effect of receipt
On receipt of this primitive the SME should operate according to the procedure in 11.24.15.
6.3.67.4 MLME-CHANNELUSAGE.indication
6.3.67.4.1 Function
This primitive indicates that a Channel Usage Request frame was received from a non-AP STA.
6.3.67.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELUSAGE.indication(
PeerSTAAddress,
Dialog Token,
ChannelUsage,
SSID,
SupportedOperatingClasses,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which a Channel Usage Request frame was
Address received.
Dialog Token Integer 0–255 The dialog token to identify the Channel Usage
request and response transaction.
ChannelUsage A set of Channel As defined in Specifies request types for the Channel Usage
Usage element 9.4.2.86 request.
SSID Octet string 0–32 octets Specifies the desired SSID or the wildcard SSID.
SupportedOperating As defined in As defined in Specifies the Supported Operating Classes
Classes Supported 9.4.2.54 information for the Channel Usage Request.
Operating
Classes
element
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
476
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.67.4.3 When generated
This primitive is generated by the MLME when a valid Channel Usage Request frame is received.
6.3.67.4.4 Effect of receipt
On receipt of this primitive the SME should operate according to the procedure in 11.24.15.
6.3.67.5 MLME-CHANNELUSAGE.response
6.3.67.5.1 Function
This primitive is generated in response to an MLME-CHANNELUSAGE.indication primitive requesting a
Channel Usage Response frame be sent to a non-AP STA.
6.3.67.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELUSAGE.response(
PeerSTAAddress,
Dialog Token,
ChannelUsage,
SSID,
Country String,
Power Constraint,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity
individual MAC from which a Channel Usage Request frame was
Address received.
Dialog Token Integer 0–255 The dialog token to identify the Channel Usage
request and response transaction.
ChannelUsage A set of Channel As defined in Specifies parameters for the Channel Usage.
Usage elements 9.4.2.86
SSID Octet string 0–32 octets Specifies the desired SSID or the wildcard SSID.
Country String Octet string 3 octets Specifies Country strings.
Power Constraint An element As defined in Zero or one Power Constraint element.
9.4.2.14
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.67.5.3 When generated
This primitive is generated by the SME in response to an MLME-CHANNELUSAGE.indication primitive
requesting a Channel Usage Response be sent to a non-AP STA.
6.3.67.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Channel Usage Response frame. The STA then
attempts to transmit this to the non-AP STA indicated by the PeerSTAAddress parameter.
477
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.68 DMS or GCR request and response procedure
6.3.68.1 General
The following MLME primitives support the signaling of DMS or GCR request and response procedure.
The informative diagram shown in Figure 6-26 depicts the DMS or GCR request and response process and
is not meant to be exhaustive of all possible protocol uses.
STA AP
SME MLME MLME SME
MLME- MLME-GATS
DMS Request frame .indication
GATS.request
Process DMS or GCR
request
MLME- MLME-GATS
DMS Response frame .response
GATS.confirm
AP may terminate a granted
DMS or GCR service at any
time
MLME-GATS- MLME-GATS-
TERM.indication DMS Response frame TERM.request
Figure 6-26—DMS or GCR setup protocol exchange
6.3.68.2 MLME-GATS.request
6.3.68.2.1 Function
This primitive requests the transmission of a DMS Request frame be sent to an AP or peer mesh STA.
6.3.68.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GATS.request(
PeerSTAAddress,
Dialog Token,
DMSRequest,
VendorSpecificInfo
)
478
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddres MAC Address Any valid Specifies the address of the peer MAC entity with
s individual which to perform the DMS or GCR process.
MAC Address
Dialog Token Integer 1–255 The dialog token to identify the DMS or GCR
request and
response transaction.
DMSRequest Sequence of As defined in Specifies group addressed frames and parameters
DMS Request 9.4.2.88 for the requested DMS or GCR stream.
elements
VendorSpecific A set of As defined in Zero or more elements.
Info elements 9.4.2.26
6.3.68.2.3 When generated
This primitive is generated by the SME to request that a DMS Request frame be sent to the AP with which
the STA is associated or peer mesh STA.
6.3.68.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a DMS Request frame. The STA then attempts to
transmit this to the AP with which the STA is associated or peer mesh STA.
6.3.68.3 MLME-GATS.confirm
6.3.68.3.1 Function
This primitive reports the result of a DMS or GCR procedure.
6.3.68.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GATS.confirm(
PeerSTAAddress,
Dialog Token,
DMSResponse,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual MAC with which to perform the DMS or GCR process.
Address
Dialog Token Integer 1–255 The dialog token to identify the DMS or GCR
request and response transaction.
DMSResponse Sequence of DMS As defined in Specifies the status returned by the AP or peer
Response 9.4.2.89 mesh STA responding to the STA’s requested
elements DMS or GCR stream.
VendorSpecificIn A set of elements As defined in Zero or more elements.
fo 9.4.2.26
6.3.68.3.3 When generated
This primitive is generated when the STA receives a DMS Response frame from the AP or peer mesh STA.
479
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.68.3.4 Effect of receipt
On receipt of this primitive the SME should operate according to the procedure in 11.24.16.
6.3.68.4 MLME-GATS.indication
6.3.68.4.1 Function
This primitive indicates that a DMS Request frame was received from a non-AP STA or peer mesh STA.
6.3.68.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GATS.indication(
PeerSTAAddress,
Dialog Token,
DMSRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA or peer mesh
individual MAC STA MAC entity from which a DMS Request
Address frame was received.
Dialog Token Integer 1–255 The dialog token to identify the DMS or GCR
request and response transaction.
DMSRequest Sequence of As defined in Specifies group addressed frames for the
DMS Request 9.4.2.88 requested DMS or GCR stream.
elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.68.4.3 When generated
This primitive is generated by the MLME when a valid DMS Request frame is received.
6.3.68.4.4 Effect of receipt
On receipt of this primitive the SME should operate according to the procedure in 11.24.16.
6.3.68.5 MLME-GATS.response
6.3.68.5.1 Function
This primitive is generated in response to an MLME-GATS.indication primitive requesting a DMS
Response frame be sent to a non-AP STA or peer mesh STA.
480
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.68.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GATS.response(
PeerSTAAddress,
Dialog Token,
DMSResponse,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA or peer mesh
individual MAC STA MAC entity from which a DMS Request
Address frame was received.
Dialog Token Integer 1–255 The Dialog Token to identify the DMS or GCR
request and response transaction.
DMSResponse Sequence of As defined in Specifies the status returned by the AP or peer
DMS Response 9.4.2.89 mesh STA responding to the STA’s requested
elements DMS or GCR stream.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.68.5.3 When generated
This primitive is generated by the SME in response to an MLME-GATS.indication primitive requesting a
DMS Response be sent to a non-AP STA or peer mesh STA.
6.3.68.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a DMS Response frame. The STA then attempts to
transmit this to the non-AP STA or peer mesh STA indicated by the PeerSTAAddress parameter.
6.3.68.6 MLME-GATS-TERM.request
6.3.68.6.1 Function
This primitive requests the transmission of a DMS Response frame to terminate a granted DMS or GCR
service.
6.3.68.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GATS-TERM.request(
PeerSTAAddress,
Dialog Token,
DMSResponse,
VendorSpecificInfo
)
481
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid The address of the non-AP STA or peer mesh
individual MAC STA MAC entity from which a DMS Request
Address frame was received.
Dialog Token Integer 0 Set to 0 for an autonomous DMS Response
frame.
DMSResponse Sequence of As defined in Specifies the requested DMS or GCR stream that
DMS Response 9.4.2.89 is canceled by the AP or peer mesh STA.
elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.68.6.3 When generated
This primitive is generated by the SME to terminate DMS or GCR service.
6.3.68.6.4 Effect of receipt
On receipt of this primitive, the MLME constructs a DMS Response frame. The STA then attempts to
transmit this to the non-AP STA or peer mesh STA indicated by the PeerSTAAddress parameter.
6.3.68.7 MLME-GATS-TERM.indication
6.3.68.7.1 Function
This primitive is generated by the MLME when a valid unsolicited DMS Response frame is received.
6.3.68.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GATS-TERM.indication(
PeerSTAAddress,
Dialog Token,
DMSResponse,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual MAC with which to perform the DMS or GCR process.
Address
Dialog Token Integer 0 Set to 0 for an autonomous DMS Response
frame.
DMSResponse Sequence of DMS As defined in Specifies the requested DMS or GCR stream that
Response 9.4.2.89 is canceled by the AP or peer mesh STA.
elements
VendorSpecificIn A set of elements As defined in Zero or more elements.
fo 9.4.2.26
6.3.68.7.3 When generated
This primitive is generated when the STA receives an unsolicited DMS Response frame from the AP or peer
mesh STA.
482
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.68.7.4 Effect of receipt
On receipt of this primitive the SME should operate according to the procedure in 11.24.16.
6.3.69 Timing measurement request
6.3.69.1 General
The following set of primitives supports triggering a Timing Measurement procedure or stopping an
ongoing Timing Measurement procedure.
6.3.69.2 MLME-TIMINGMSMTRQ.request
6.3.69.2.1 Function
This primitive requests the transmission of a Timing Measurement Request frame to a peer entity.
6.3.69.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMINGMSMTRQ.request(
Peer MAC Address,
Trigger,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the
individual MAC Timing Measurement Request frame is sent.
Address
Trigger Integer 0–1 The trigger to identify the action.
VendorSpecificIn A set of elements As defined in Zero or more elements.
fo 9.4.2.26
6.3.69.2.3 When generated
This primitive is generated by the SME to request that a Timing Measurement Request frame be sent to a
peer entity.
6.3.69.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Timing Measurement Request frame with the specified
parameters. This frame is then scheduled for transmission.
6.3.69.3 MLME-TIMINGMSMTRQ.indication
6.3.69.3.1 Function
This primitive indicates that a Timing Measurement Request frame has been received and the corresponding
Ack frame has been transmitted.
483
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.69.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TIMINGMSMTRQ.indication(
Peer MAC Address,
Trigger,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the
individual MAC Timing Measurement Request frame is sent.
Address
Trigger Integer 0–1 The trigger to identify the action.
VendorSpecificIn A set of elements As defined in Zero or more elements.
fo 9.4.2.26
6.3.69.3.3 When generated
This primitive is generated by the MLME when a valid Timing Measurement Request frame is received.
6.3.69.3.4 Effect of receipt
On receipt of this primitive, the SME uses the information contained within the notification.
6.3.70 Fine timing measurement request
6.3.70.1 General
The following set of primitives supports triggering a FTM procedure or stopping an ongoing FTM
procedure.
6.3.70.2 MLME-FINETIMINGMSMTRQ.request
6.3.70.2.1 Function
This primitive requests the transmission of a Fine Timing Measurement Request frame to a peer entity.
6.3.70.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FINETIMINGMSMTRQ.request(
Peer MAC Address,
Trigger,
LCI Request,
Location Civic Request,
Fine Timing Measurement Parameters,
Vendor Specific
)
484
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the
individual MAC Fine Timing Measurement Request frame is sent.
Address
Trigger Integer 0–1 The trigger to identify the action.
LCI Request As defined in As defined in Optional element to request LCI information of
9.6.8.32 9.6.8.32 sender
Location Civic As defined in As defined in Optional element to request location civic
Request 9.6.8.32 9.6.8.32 information of sender
Fine Timing As defined in As defined in Optional element containing the requested FTM
Measurement 9.4.2.168 9.4.2.168 configuration
Parameters
VendorSpecific A set of elements As defined by Zero or more elements
9.4.2.26
6.3.70.2.3 When generated
This primitive is generated by the SME to request that a Fine Timing Measurement Request frame be sent to
a peer entity.
6.3.70.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Fine Timing Measurement Request frame with the
specified parameters. This frame is then scheduled for transmission.
6.3.70.3 MLME-FINETIMINGMSMTRQ.indication
6.3.70.3.1 Function
This primitive indicates that a Fine Timing Measurement Request frame has been received and the
corresponding Ack frame has been transmitted.
6.3.70.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FINETIMINGMSMTRQ.indication(
Peer MAC Address,
Trigger,
LCI Request,
Location Civic Request,
Fine Timing Measurement Parameters,
Vendor Specific
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the
individual MAC Fine Timing Measurement Request frame is sent.
Address
Trigger Integer 0–1 The trigger to identify the action.
LCI Request As defined in As defined in Optional element to request LCI information of
9.6.8.32 9.6.8.32 sender
Location Civic As defined in As defined in Optional element to request location civic
Request 9.6.8.32 9.6.8.32 information of sender
485
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Fine Timing As defined in As defined in Optional element containing the requested FTM
Measurement 9.4.2.168 9.4.2.168 configuration
Parameters
VendorSpecific A set of elements As defined by Zero or more elements
9.4.2.26
6.3.70.3.3 When generated
This primitive is generated by the MLME when a valid Fine Timing Measurement Request frame is
received.
6.3.70.3.4 1 Effect of receipt
On receipt of this primitive, the SME uses the information contained within the notification.
6.3.71 WNM notification request
6.3.71.1 General
This set of primitives supports the exchange of WNM Notification Request and Response frames between
peer SMEs.
6.3.71.2 MLME-WNMNOTIFICATIONREQUEST.request
6.3.71.2.1 Function
This primitive requests the transmission of a WNM Notification Request frame to a peer entity.
6.3.71.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-WNMNOTIFICATIONREQUEST.request(
Peer MAC Address,
Dialog Token,
Type,
Optional Subelements,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which
individual MAC the WNM Notification Request frame is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the WNM
notification transaction.
Type Integer 1–255 The type of WNM notification.
Optional Set subelements As defined in A set of subelements describing the notification.
Subelements 9.6.14.29
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
486
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.71.2.3 When generated
This primitive is generated by the SME to request that a WNM Notification Request frame be sent to a peer
entity to initiate a WNM notification.
6.3.71.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a WNM Notification Request frame containing the
elements specified. This frame is then scheduled for transmission.
6.3.71.3 MLME-WNMNOTIFICATIONREQUEST indication
6.3.71.3.1 Function
This primitive indicates that a WNM Notification Request frame has been received.
6.3.71.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-WNMNOTIFICATIONREQUEST.indication(
Peer MAC Address,
Dialog Token,
Type,
Optional Subelements,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity from which
individual MAC the WNM notification request was received.
Address
Dialog Token Integer 1–255 The dialog token to identify the WNM
notification transaction.
Type Integer 1–255 The type of WNM notification request.
Optional Set subelements As defined in A set of subelements describing the
Subelements 9.6.14.29 notification.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.71.3.3 When generated
This primitive is generated by the MLME when a valid WNM Notification Request frame is received.
6.3.71.3.4 Effect of receipt
On receipt of this primitive, the SME replies to the request.
487
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.72 WNM notification response
6.3.72.1 MLME-WNMNOTIFICATIONRESPONSE.request
6.3.72.1.1 Function
This primitive supports the signaling of the WNM Notification Response frame between peer SMEs.
6.3.72.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-WNMNOTIFICATIONRESPONSE.request(
Peer MAC Address,
Dialog Token,
Response Status,
Optional Subelements,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which
individual MAC the WNM Notification Response frame is sent.
Address
Dialog Token Integer 1–255 The dialog token to identify the WNM
notification transaction.
Response Status Integer 1–255 The response status of the WNM notification.
Optional Set subelements As defined in A set of subelements describing the results of
Subelements 9.6.14.30 the WNM notification.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.72.1.3 When generated
This primitive is generated by the SME to request that a WNM Notification Response frame be sent to a peer
entity to report the results of the WNM notification.
6.3.72.1.4 Effect of receipt
On receipt of this primitive, the MLME constructs a WNM Notification Response frame containing the
indicated fields. This frame is then scheduled for transmission.
6.3.72.2 MLME-WNMNOTIFICATIONRESPONSE.indication
6.3.72.2.1 Function
This primitive indicates that a WNM Notification Response frame has been received from a peer entity.
6.3.72.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-WNMNOTIFICATIONRESPONSE.indication(
Peer MAC Address,
Dialog Token,
Response Status,
488
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Optional Subelements,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity from which
individual MAC the WNM Notification Response frame was
Address received.
Dialog Token Integer 1–255 The dialog token to identify the WNM
notification transaction.
Response Status Integer 1–255 The response status of the WNM notification.
Optional Set subelements As defined in A set of subelements describing the results of
Subelements 9.6.14.30 the WNM notification.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.72.2.3 When generated
This primitive is generated by the MLME when a valid WNM Notification Response frame is received.
6.3.72.2.4 Effect of receipt
On receipt of this primitive, the WNM notification can be made available for SME processes.
6.3.73 Network discovery and selection support
6.3.73.1 General
This set of primitives supports the process of GAS.
6.3.73.2 MLME-GAS.request
6.3.73.2.1 Function
This primitive requests the information of a specific advertisement service from another STA and requests
the STA to provide GAS.
6.3.73.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GAS.request(
PeerSTAAddress,
DialogToken,
AdvertisementProtocolID,
Query,
QueryFailureTimeout,
Protected,
Multi-band,
VendorSpecificInfo
)
489
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MacAddress Any valid Specifies the address of the peer MAC entity to
individual which query is transmitted.
MacAddress
DialogToken Integer 0–255 The dialog token to identify the GAS transaction.
AdvertisementProt Integer or As defined in This contains an Advertisement Protocol ID (see
ocolID Sequence of Table 9-215 9.4.2.93), which might be IEEE 802.11 assigned
integers or vendor specified.
Query String N/A Query string formatted using protocol identified
in AdvertisementProtocolID. E.g., if the
AdvertisementProtocolID value is 1, then Query
is formatted as defined in IEEE Std 802.21-2008.
QueryFailureTimeo Integer >1 The time limit, in units of beacon intervals, after
ut which the GAS Query procedure is terminated.
Protected Boolean true, false Specifies whether the request is sent using a
robust Management frame.
If true, the request is sent using a Protected Dual
of Public Action frame. Otherwise, the request is
sent using a Public Action frame.
Multi-band Multi-band As defined in Specifies the frequency band and channel number
element 9.4.2.138 to which the GAS transaction applies. The
parameter is absent if the GAS transaction
applies to the same frequency band and channel
where the frame is transmitted.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.73.2.3 When generated
This primitive is generated by the SME to request a specific Advertisement Service from another STA.
6.3.73.2.4 Effect of receipt
The STA operates according to the procedures defined in 11.25.3.
6.3.73.3 MLME-GAS.confirm
6.3.73.3.1 Function
This primitive reports the status code and Query Response from an Advertisement Server to the requesting
STA.
6.3.73.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GAS.confirm(
PeerSTAAddress,
DialogToken,
ResultCode,
ResponseInfo,
Protected,
Multi-band,
VendorSpecificInfo
)
490
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MacAddress Any valid individual MacAddress Specifies the address of the
peer MAC entity to which
query is transmitted.
DialogToken Integer 0–255 The dialog token to identify
the GAS transaction.
ResultCode Enumeration SUCCESS, Indicates the result response
NO_OUTSTANDING_GAS_REQUEST, to the GAS request from the
GAS_ADVERTISEMENT_PROTOCOL_ peer MAC entity.
NOT_SUPPORTED,
GAS_QUERY_RESPONSE_
OUTSTANDING,
GAS_QUERY_RESPONSE_TOO_LARGE
,
SERVER_UNREACHABLE,
GAS_QUERY_TIMEOUT,
GAS_RESPONSE_NOT_RECEIVED_
FROM_SERVER
ResponseInfo String N/A Query Response string
formatted using protocol
identified in
AdvertisementProtocolID.
E.g., if the
AdvertisementProtocolID
value is 1, then Query is
formatted as defined in IEEE
Std 802.21-2008.
Protected Boolean true, false Specifies whether the
response was received in a
robust Management frame.
If true, the response was
received using a Protected
Dual of Public Action frame.
Otherwise, the response was
received using a Public
Action frame.
Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency band
element and channel number to which
the GAS transaction applies.
The parameter is absent if the
GAS transaction applies to
the same frequency band and
channel where the frame is
transmitted.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
The mapping of Status Code received in the GAS Response frame is mapped to the corresponding Result
Code in Table 9-46.
6.3.73.3.3 When generated
This primitive is generated by the MLME as a response to the MLME-GAS.request primitive indicating the
result of that request.
The primitive is generated when the requesting STA receives a query response in a (Protected) GAS Initial
Response frame or one or more (Protected) GAS Comeback Response frames.
491
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.73.3.4 Effect of receipt
The STA operates according to the procedures defined in 11.25.3.
6.3.73.4 MLME-GAS.indication
6.3.73.4.1 Function
This primitive reports to the STA’s SME about the GAS Request.
6.3.73.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GAS.indication(
PeerSTAAddress,
DialogToken,
AdvertisementProtocolID,
Query,
Protected,
Multi-band,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MacAddress Any valid Specifies the address of the peer MAC entity
individual MAC from which the query message was received.
address
DialogToken Integer 0–255 The dialog token to identify the GAS transaction.
AdvertisementProt Integer or As defined in This contains an Advertisement Protocol ID (see
ocolID Sequence of Table 9-215 9.4.2.93), which might be IEEE 802.11 assigned
integers or vendor specified.
Query String N/A Query string formatted using protocol identified
in AdvertisementProtocolID. E.g., if the
AdvertisementProtocolID value is 1, then Query
is formatted as defined in IEEE Std 802.21-2008.
Protected Boolean true, false Specifies whether the request was received in a
robust Management frame.
If true, the request was received in a Protected
Dual of Public Action frame. Otherwise, the
request was received in a Public Action frame.
Multi-band Multi-band As defined in Specifies the frequency band and channel number
element 9.4.2.138 to which the GAS transaction applies. The
parameter is absent if the GAS transaction
applies to the same frequency band and channel
where the frame is transmitted.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
492
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.73.4.3 When generated
This primitive is generated by the MLME as a result of receipt of a GAS request from STA.
6.3.73.4.4 Effect of receipt
The SME is notified of the request from the STA.
The SME operates according to the procedures defined in 11.25.3.
The SME generates an MLME-GAS.response primitive within a dot11GASResponseTimeout.
6.3.73.5 MLME-GAS.response
6.3.73.5.1 Function
This primitive responds to the request for an advertisement service by a specified STA MAC entity.
6.3.73.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GAS.response(
PeerSTAAddress,
DialogToken,
ResultCode,
ResponseInfo,
Protected,
Multi-band,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MacAddress Any valid individual MAC address Specifies the address of the
peer MAC entity to which
query response information
is transmitted.
DialogToken Integer 0–255 The dialog token to identify
the GAS transaction.
ResultCode Enumeration SUCCESS, Indicates the result response
NO_OUTSTANDING_GAS_REQUEST, to the GAS-request from the
GAS_ADVERTISEMENT_PROTOCOL_ peer MAC entity. See
NOT_SUPPORTED, Table 9-46.
GAS_QUERY_RESPONSE_
OUTSTANDING,
GAS_QUERY_RESPONSE_TOO_LARGE,
SERVER_UNREACHABLE,
GAS_QUERY_TIMEOUT,
GAS_RESPONSE_NOT_RECEIVED_
FROM_SERVER
493
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ResponseInfo String N/A Query Response string
formatted using protocol
identified in
AdvertisementProtocolID.
E.g., if the
AdvertisementProtocolID
value is 1, then Query is
formatted as defined in
IEEE Std 802.21-2008.
Protected Boolean true, false Specifies whether the
response is sent using a
robust Management frame.
If true, the response is sent
using a Protected Dual of
Public Action frame.
Otherwise, the response is
sent using a Public Action
frame.
Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency
element band and channel number
where the GAS transaction
applies. The parameter is
absent if the GAS
transaction applies to the
same frequency band and
channel where the frame is
transmitted.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.73.5.3 When generated
This primitive is generated by the MLME as a result of an MLME-GAS.indication primitive.
6.3.73.5.4 Effect of receipt
This primitive causes the MAC entity at the STA to send a (Protected) GAS Initial Response frame to the
requesting STA and optionally one or more (Protected) GAS Comeback Response frames.
6.3.74 QoS Map element management
6.3.74.1 General
The QoS Map element is provided to non-AP STAs in (Re)Association Response frames. However, if the
SME of an AP detects a change of the QoS Map information while one or more non-AP STAs are associated
to the BSS, then the AP may transmit an unsolicited QoS Map element to associated STAs. The AP’s SME
invokes the MLME-QOS-MAP.request primitive to cause individually addressed frames containing a QoS
Map element to be transmitted to associated STAs. The AP’s SME invokes the MLME-QOS-MAP.request
primitive to transmit individually addressed frames containing a QoS Map element to associated STAs.
When a non-AP STA receives such unsolicited QoS Map information, its MLME generates an MLME-
QOS-MAP.indication primitive to the STA’s SME. In turn, the SME should take appropriate action, e.g.,
initiate an ADDTS or DELTS if admission control changes are necessary.
494
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.74.2 MLME-QOS-MAP.request
6.3.74.2.1 Function
This primitive is used by an AP to transmit an unsolicited QoS Map Configure frame to a specified non-AP
STA MAC entity. The specified non-AP STA MAC address is an individual MAC address.
6.3.74.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QOS-MAP.request(
Non-APSTAAddress,
QoSMapSet,
IntraAccessCategoryPriority,
VendorSpecificInfo
)
Name Type Valid range Description
Non- MacAddress Any valid Specifies the address of the peer MAC entity
APSTAAddress individual MAC from which query message is received.
address
QoSMapSet As defined in As defined in Specifies the QoS Map information the non-AP
frame format 9.4.2.95 STA should use.
IntraAccessCategor Intra-Access As defined in Specifies the intra-AC priorities the STA should
yPriority Category Priority 9.4.2.121 use. The parameter is present if
element dot11SCSActivated is true; otherwise not
present.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.74.2.3 When generated
This primitive is generated by the MLME at the AP as a result of any change in the AP QoS Map
configurations.
6.3.74.2.4 Effect of receipt
This primitive causes the MAC entity at the AP to send a QoS Map element in a QoS Map Configure frame
to the non-AP STA.
6.3.74.3 MLME-QOS-MAP.indication
6.3.74.3.1 Function
This primitive reports the QoS mapping information sent from the AP to the non-AP STA.
6.3.74.3.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-QOS-MAP.indication(
QoSMapSet,
IntraAccessCategoryPriority,
VendorSpecificInfo
)
495
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
QoSMapSet As defined in As defined in Specifies the QoS Map information to be used by
frame format 9.4.2.95 the non-AP STA.
IntraAccessCatego Intra-Access As defined in Specifies the intra-AC priorities the STA should
ryPriority Category Priority 9.4.2.121 use.
element
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.74.3.3 When generated
This primitive is generated when the non-AP STA receives a QoS Map element in an unsolicited QoS Map
Configure frame from the AP.
The SME of the non-AP STA should use the information to decide proper actions. For example, an ADDTS
or DELTS procedure should be activated if the QoS Map information indicates a change in the admission
control.
6.3.74.3.4 Effect of receipt
The non-AP STA operates according to the procedures defined in 11.25.9.
6.3.75 Mesh peering management
6.3.75.1 Introduction
The following primitives facilitate the mesh peering management protocol and authenticated mesh peering
exchange protocol.
6.3.75.2 MLME-MESHPEERINGMANAGEMENT.request
6.3.75.2.1 Function
This primitive requests that the MAC entity establish, confirm, or close a mesh peering with the specified
peer MAC entity by sending a mesh peering Management frame to the peer MAC entity. The mesh peering
management procedures are specified in 14.3.
6.3.75.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHPEERINGMANAGEMENT.request(
PeerMACAddress,
MeshPeeringMgmtFrameContent,
VendorSpecificInfo
)
496
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MAC Address Valid individual MAC Specifies the address of the peer MAC
address entity to which the Mesh Peering
Management frame is to be sent.
MeshPeeringMgmtFra Sequence of As defined in 9.6.16.2, The contents of the Action field of the
meContent octets 9.6.16.3, or 9.6.16.4 Mesh Peering Open, Mesh Peering
Confirm, or Mesh Peering Close frame to
send to the peer MAC entity.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.75.2.3 When generated
This primitive is generated by the SME to request that a mesh peering Management frame be sent to the
specified mesh STA.
6.3.75.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a mesh peering Management frame containing the
information specified. The frame is scheduled for transmission.
6.3.75.3 MLME-MESHPEERINGMANAGEMENT.confirm
6.3.75.3.1 Function
This primitive reports the results of a request to send a mesh peering Management frame.
6.3.75.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHPEERINGMANAGEMENT.confirm(
PeerMACAddress,
MeshPeeringMgmtFrameContent,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACA MAC Address Valid individual MAC address Specifies the address of the peer MAC
ddress entity to which the Mesh Peering
Management frame was sent.
MeshPeerin Sequence of As defined in 9.6.16.2, The contents of the Action field of the Mesh
gMgmtFram octets 9.6.16.3, or 9.6.16.4 Peering Open, Mesh Peering Confirm, or
eContent Mesh Peering Close frame received from
the peer MAC entity.
VendorSpec A set of As defined in 9.4.2.26 Zero or more elements.
ificInfo elements
6.3.75.3.3 When generated
This primitive is generated as a result of an MLME-MESHPEERINGMANAGEMENT.request primitive
with a specified MAC peer.
497
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.75.3.4 Effect of receipt
The SME is notified of the results of the mesh peering management protocol request.
6.3.75.4 MLME-MESHPEERINGMANAGEMENT.indication
6.3.75.4.1 Function
This primitive indicates to the SME that the MLME has received a mesh peering Management frame from a
peer MAC entity.
6.3.75.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHPEERINGMANAGEMENT.indication(
PeerMACAddress,
MeshPeeringMgmtFrameContent,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Valid individual MAC Specifies the address of the peer MAC
address entity from which the Mesh Peering
Management frame was received.
MeshPeeringMgm Sequence of As defined in 9.6.16.2, The contents of the Action field of the
tFrameContent octets 9.6.16.3, or 9.6.16.4 Mesh Peering Open, Mesh Peering
Confirm, or Mesh Peering Close frame
received from the peer MAC entity.
VendorSpecificInf A set of As defined in 9.4.2.26 Zero or more elements.
o elements
6.3.75.4.3 When generated
This primitive is generated by the MLME as a result of the receipt of a mesh peering Management frame
from a peer MAC entity.
6.3.75.4.4 Effect of receipt
The SME is notified of the reception of a mesh peering Management frame and is provided the contents of
the frame.
6.3.75.5 MLME-MESHPEERINGMANAGEMENT.response
6.3.75.5.1 Function
This primitive is used to send a response to a mesh peering Management frame to the specified peer MAC
entity.
6.3.75.5.2 Semantics of the service primitive
The primitive parameters are as follows:
498
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-MESHPEERINGMANAGEMENT.response(
PeerMACAddress,
ResultCode,
MeshPeeringMgmtFrameContent,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACA MAC Address Valid individual MAC address Specifies the address of the peer MAC
ddress entity to which the Mesh Peering
Management frame is to be sent.
ResultCode Enumeration SUCCESS, Reports the result response to the mesh
INVALID_PARAMETERS peering Management frame from the peer
MAC entity.
MeshPeerin Sequence of As defined in 9.6.16.2, The contents of the Action field of the Mesh
gMgmtFram octets 9.6.16.3, or 9.6.16.4 Peering Open, Mesh Peering Confirm, or
eContent Mesh Peering Close frame to send to the
peer MAC entity.
VendorSpec A set of As defined in 9.4.2.26 Zero or more elements.
ificInfo elements
6.3.75.5.3 When generated
This primitive is generated by the SME as a response to an MLME-
MESHPEERINGMANAGEMENT.indication primitive.
6.3.75.5.4 Effect of receipt
This primitive indicates scheduling for transmission of a Mesh Peering frame containing the indicated
response.
6.3.76 Mesh power management
6.3.76.1 Introduction
The following primitives describe how a mesh entity changes its mesh power management mode for a mesh
peering.
6.3.76.2 MLME-MESHPOWERMGT.request
6.3.76.2.1 Function
This primitive requests a change in the mesh STAs mesh power management mode for the mesh peering.
6.3.76.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHPOWERMGT.request(
PeerMACAddress,
Mesh Power Management Mode
)
499
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid Range Description
PeerMACAd- MAC Valid individual MAC Specifies the address of the peer MAC entity to
dress Address address which the mesh power management mode is
changed.
Mesh Power Enumeration ACTIVE_MODE, Specifies the mesh power management mode that
Management LIGHT_SLEEP_MODE, the local mesh STA is using for the mesh peering.
Mode DEEP_SLEEP_MODE
6.3.76.2.3 When generated
The primitive is generated when the mesh entity wishes to change the mesh power management mode of a
mesh peering.
6.3.76.2.4 Effect of receipt
This primitive initiates the local mesh STA’s mesh power management mode change of the mesh peering.
The MLME subsequently issues an MLME-MESHPOWERMGT.confirm primitive that reflects the results.
6.3.76.3 MLME-MESHPOWERMGT.confirm
6.3.76.3.1 Function
This primitive reports the result of a mesh power management mode change attempt.
6.3.76.3.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-MESHPOWERMGT.confirm(
PeerMACAddress
)
Name Type Valid Range Description
PeerMAC MAC Valid individual MAC Specifies the address of the peer MAC entity
Address Address address to which the mesh power management mode
is changed.
6.3.76.3.3 When generated
This primitive is generated as a result of an MLME-MESHPOWERMGT.request primitive.
6.3.76.3.4 Effect of receipt
The SME is notified of the results of the mesh power management mode change for a mesh peering
procedure.
6.3.77 Mesh neighbor offset synchronization
6.3.77.1 Introduction
This mechanism manages the neighbor offset synchronization method with the specified neighbor STA.
500
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.77.2 MLME-MESHNEIGHBOROFFSETSYNCSTART.request
6.3.77.2.1 Function
This primitive requests to start the neighbor offset synchronization method with the specified neighbor STA.
6.3.77.2.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-MESHNEIGHBOROFFSETSYNCSTART.request(
PeerMACAddress
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual with which to start the neighbor offset
MAC address synchronization method.
6.3.77.2.3 When generated
This primitive is generated by the SME to start the neighbor offset synchronization method with the
specified neighbor STA.
6.3.77.2.4 Effect of receipt
On receipt of this primitive, the MLME commences the neighbor offset synchronization method and the
calculation of the TSF timer offset value. The MLME subsequently issues an MLME-
MESHNEIGHBOROFFSETSYNCSTART.confirm primitive that reflects the results of this request.
6.3.77.3 MLME-MESHNEIGHBOROFFSETSYNCSTART.confirm
6.3.77.3.1 Function
This primitive reports the results of a mesh neighbor offset synchronization request.
6.3.77.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHNEIGHBOROFFSETSYNCSTART.confirm(
PeerMACAddress,
TSFOffsetValue
)
Name Type Valid range Description
PeerMACAddress MAC Address Valid individual MAC address Specifies the address of the peer MAC
entity to which the neighbor offset
synchronization is requested.
TSFOffsetValue Integer –263 to (263–1) Indicates the TSF offset value with the
specified neighbor STA, expressed in
2s complement in µs.
501
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.77.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-
MESHNEIGHBOROFFSETSYNCSTART.request primitive and report the TSF offset value.
6.3.77.3.4 Effect of receipt
The SME is notified of the results of the mesh neighbor offset synchronization request.
6.3.77.4 MLME-MESHNEIGHBOROFFSETCALCULATE.request
6.3.77.4.1 Function
This primitive requests a calculation result of the TSF timer offset value for the specified neighbor STA.
6.3.77.4.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-MESHNEIGHBOROFFSETCALCULATE.request(
PeerMACAddress
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual with which to report the TSF offset value.
MAC address
6.3.77.4.3 When generated
This primitive is generated by the SME to order a calculation of the TSF timer offset value with the specified
neighbor STA.
6.3.77.4.4 Effect of receipt
On receipt of this primitive, the MLME receives a Beacon or Probe Response frame and calculates the TSF
timer offset value from the received frame. The MLME tries to receive a Beacon frame immediately after
the issue of MLME-MESHNEIGHBOROFFSETCALCULATE.request primitive even if the mesh STA
does not listen to the Beacon frame from the specified neighbor STA regularly (i.e., in deep sleep mode
toward the specified neighbor STA). The MLME subsequently issues an MLME-
MESHNEIGHBOROFFSETCALCULATE.confirm primitive that reflects the results of this request.
6.3.77.5 MLME-MESHNEIGHBOROFFSETCALCULATE.confirm
6.3.77.5.1 Function
This primitive reports the results of a mesh neighbor offset calculation request.
6.3.77.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHNEIGHBOROFFSETCALCULATE.confirm(
PeerMACAddress,
TSFOffsetValue
)
502
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MAC Address Valid individual MAC address Specifies the address of the peer MAC
entity to which the Neighbor Offset
Measure is requested.
TSFOffsetValue Integer –263 to (263–1) Indicates the TSF offset value with the
specified neighbor STA, expressed in
2s complement in µs.
6.3.77.5.3 When generated
This primitive is generated by the MLME as a result of an MLME-
MESHNEIGHBOROFFSETCALCULATE.request primitive to report a TSF offset value.
6.3.77.5.4 Effect of receipt
The SME is notified of the results of the mesh neighbor offset calculation request.
6.3.77.6 MLME-MESHNEIGHBOROFFSETSYNCSTOP.request
6.3.77.6.1 Function
This primitive requests to stop the neighbor offset synchronization method with the specified neighbor STA.
6.3.77.6.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-MESHNEIGHBOROFFSETSYNCSTOP.request(
PeerMACAddress
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual with which to stop the neighbor offset
MAC address synchronization method.
6.3.77.6.3 When generated
This primitive is generated by the SME to stop the maintenance of the neighbor offset synchronization
method with the specified neighbor STA.
6.3.77.6.4 Effect of receipt
On receipt of this primitive, the MLME stops the neighbor offset synchronization method with the specified
peer. The MLME subsequently issues an MLME-MESHNEIGHBOROFFSETSYNCSTOP.confirm
primitive that reflects the results of this request.
6.3.77.7 MLME-MESHNEIGHBOROFFSETSYNCSTOP.confirm
6.3.77.7.1 Function
This primitive reports the results of a neighbor offset synchronization method stop request.
503
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.77.7.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-MESHNEIGHBOROFFSETSYNCSTOP.confirm(
PeerMACAddress
)
Name Type Valid range Description
PeerMACAddress MAC Address Valid individual MAC address Specifies the address of the peer
MAC entity to which the Neighbor
Offset Stop is requested.
6.3.77.7.3 When generated
This primitive is generated by the MLME as a result of an MLME-
MESHNEIGHBOROFFSETSYNCSTOP.request primitive.
6.3.77.7.4 Effect of receipt
The SME is notified of the results of the mesh neighbor offset synchronization stop request.
6.3.78 Mesh TBTT adjustment
6.3.78.1 Introduction
The following primitives describe how a mesh STA requests a TBTT adjustment from a neighboring peer
mesh STA.
6.3.78.2 MLME-MESHTBTTADJUSTMENT.request
6.3.78.2.1 Function
This primitive requests transmission of a TBTT Adjustment Request frame.
6.3.78.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHTBTTADJUSTMENT.request(
PeerMACAddress,
BeaconTiming,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual to which the TBTT Adjustment Request is
MAC address sent.
BeaconTiming A set of As defined in A set of Beacon Timing elements of the mesh
Beacon 9.4.2.105 STA.
Timing
elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
504
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.78.2.3 When generated
This primitive is generated by the SME to request that a TBTT Adjustment Request frame be sent to a peer
entity to request the adjustment of the peer entity’s TBTT.
6.3.78.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a TBTT Adjustment Request frame containing the
Beacon Timing elements. This frame is then scheduled for transmission. The MLME subsequently issues an
MLME-MESHTBTTADJUSTMENT.confirm primitive that reflects the result of this request.
6.3.78.3 MLME-MESHTBTTADJUSTMENT.confirm
6.3.78.3.1 Function
This primitive reports the result of a mesh TBTT adjustment request.
6.3.78.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHTBTTADJUSTMENT.confirm(
PeerMACAddress,
ResultCode,
BeaconTiming,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual MAC Specifies the address of the peer
address MAC entity from which the TBTT
Adjustment Response is received.
ResultCode Enumeration SUCCESS, Indicates the result of the TBTT
REFUSED_REASON_ adjustment request.
UNSPECIFIED,
CANNOT_FIND_
ALTERNATIVE_TBTT
BeaconTiming A set of As defined in 9.4.2.105 A set of Beacon Timing elements
Beacon Timing of the responding mesh STA.
elements Present only when such an element
was present in the TBTT
Adjustment Response frame.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.78.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-MESHTBTTADJUSTMENT.request
primitive to indicate the result of that request.
6.3.78.3.4 Effect of receipt
The SME is notified of the result of the mesh TBTT adjustment request.
505
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.78.4 MLME-MESHTBTTADJUSTMENT.indication
6.3.78.4.1 Function
This primitive indicates that a specific peer MAC entity is requesting adjustment of the TBTT.
6.3.78.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHTBTTADJUSTMENT.indication(
PeerMACAddress,
BeaconTiming,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC
MAC address entity from which the TBTT Adjustment
request was received.
BeaconTiming A set of Beacon As defined in 9.4.2.105 A set of Beacon Timing elements of the
Timing elements requesting mesh STA.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.78.4.3 When generated
This primitive is generated by the MLME as a result of the receipt of a TBTT Adjustment Request frame
from the specified peer MAC entity.
6.3.78.4.4 Effect of receipt
The SME is notified of the receipt of the TBTT adjustment request by the specified peer MAC entity. The
mesh STA that received this primitive subsequently processes the TBTT scanning and adjustment procedure
described in 14.13.4.4.3, and responds with the MLME-MESHTBTTADJUSTMENT.response primitive.
6.3.78.5 MLME-MESHTBTTADJUSTMENT.response
6.3.78.5.1 Function
This primitive is used to send a response to the specified peer MAC entity that requested a TBTT adjustment
from the mesh STA that issued this primitive.
6.3.78.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHTBTTADJUSTMENT.response(
PeerMACAddress,
Status Code,
BeaconTiming,
VendorSpecificInfo
)
506
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual MAC Specifies the address of the peer
address MAC entity to which the TBTT
Adjustment Response is sent.
Status Code As defined in SUCCESS, Indicates the result response to the
frame format REFUSED_REASON_ TBTT adjustment request from the
UNSPECIFIED, peer mesh STA.
CANNOT_FIND_
ALTERNATIVE_TBTT
BeaconTiming A set of As defined in 9.4.2.105 A set of Beacon Timing elements
Beacon Timing of the mesh STA. Present only
elements when the STA could not find an
alternative TBTT.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.78.5.3 When generated
This primitive is generated by the SME of a mesh STA as response to an MLME-
MESHTBTTADJUSTMENT.indication primitive.
6.3.78.5.4 Effect of receipt
This primitive initiates the transmission of a TBTT Adjustment Response frame to the peer MAC entity that
requested the TBTT adjustment.
On receipt of this primitive, the MLME constructs a TBTT Adjustment Response frame. This frame is then
scheduled for transmission.
6.3.79 MCCA management interface
6.3.79.1 Introduction
The following primitives describe how a mesh entity manages its MCCA operation.
6.3.79.2 MLME-ACTIVATEMCCA.request
6.3.79.2.1 Function
This primitive requests that the MAC entity activate MCCA.
6.3.79.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ACTIVATEMCCA.request(
MCCAScanDuration,
MAFLimit,
MCCAAdvertPeriodMax,
MCCAMaxTrackStates,
MCCACWmin,
MCCACWmax,
MCCAAIFSN
)
507
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
MCCAScanDu Integer 0 – 65 535 Specifies the duration in TUs that the mesh STA
ration shall not initiate or accept MCCA Setup Request
frames.
MAFLimit Integer 0–255 Specifies the maximum MCCA access fraction
allowed at the mesh STA. This number is always
a multiple of (1/255) of the DTIM Interval.
MCCAAdvert Integer 0–255 Specifies the maximum interval that a mesh STA
PeriodMax with dot11MCCAActivated equal to true waits
for an MCCAOP advertisement. It is expressed in
number of DTIM intervals.
MCCAMaxTra Integer dot11MCCAMinTrackStates Specifies the total number of MCCAOP
ckStates – 65 535 reservations that the MAC entity is able to track.
MCCACWmin Integer 0–15 Specifies the value of the minimum size of the
contention window that the MAC entity uses for
channel access during an MCCAOP.
MCCACWma Integer 0–63 Specifies the value of the maximum size of the
x contention that the MAC entity uses for channel
access during an MCCAOP.
MCCAAIFSN Integer 0–15 Specifies the value of the AIFSN that the MAC
entity uses for channel access during an
MCCAOP.
6.3.79.2.3 When generated
This primitive is generated by the SME to start the use of MCCA.
6.3.79.2.4 Effect of receipt
This primitive sets dot11MCCAActivated to true and initializes the MCCA parameters.
6.3.79.3 MLME-MCCASETUP.request
6.3.79.3.1 Function
This primitive requests that the MAC entity set up an MCCAOP reservation.
6.3.79.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCASETUP.request(
MCCAOPDuration,
MCCAOPPeriodicity,
MCCAOPOffset,
MCCAOPResponder,
VendorSpecificInfo
)
Name Type Valid range Description
MCCAOPDuration Integer 0 – 65 535 Specifies the MCCAOP Duration of the
needed MCCAOPs as described in
9.4.2.106.2.
MCCAOPPeriodicity Integer 0–255 Specifies the MCCAOP Periodicity of the
needed MCCAOPs as described in
9.4.2.106.2.
508
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
MCCAOPOffset Integer 0 – 16 777 215 Specifies the MCCAOP offset of the needed
MCCAOPs as described in 9.4.2.106.2.
MCCAOPResponder MAC address Any valid Specifies the MAC address of the intended
individual or MCCAOP responder.
group MAC
address
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.79.3.3 When generated
This primitive is generated by the SME to start an MCCAOP setup procedure.
6.3.79.3.4 Effect of receipt
This primitive causes the transmission of an MCCA Setup Request frame to the MCCAOP responder
provided that the conditions for the transmission are met. In the case that a response is received from the
responder STA, the MLME subsequently issues an MLME-MCCASETUP.confirm primitive that reflects
the results.
6.3.79.4 MLME-MCCASETUP.confirm
6.3.79.4.1 Function
This primitive is generated by the MLME to report the result of an MLME-MCCASETUP.request primitive,
which was issued in order to establish an MCCAOP reservation with the peer MAC entity specified in
MCCAOPResponder.
6.3.79.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCASETUP.confirm(
MCCAOPParameters,
MCCAOPID,
MCCAOPResponder,
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
MCCAOPParameters MCCAOP See 9.4.2.106.2 The MCCAOP reservation
Reservation parameters.
MCCAOPID Integer 0–254 MCCAOP reservation ID of the
MCCAOP reservation.
MCCAOPResponder MAC address Any valid individual or group Specifies the MAC address of the
MAC address intended MCCAOP responder.
509
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Indicates the result of the MLME-
INVALID_PARAMETERS, MCCASETUP.request primitive.
MCCAOP_RESERVATION_C
ONFLICT,
MAF_LIMIT_EXCEEDED,
MCCA_TRACK_LIMIT_EX
CEEDED
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.79.4.3 When generated
This primitive is generated by the MLME as a result of an MLME-MCCASETUP.request primitive to
establish an MCCAOP reservation with the peer mesh STA identified in MCCAOPResponder or upon
receipt of an MCCA Setup Reply frame from the peer mesh STA identified in MCCAOPResponder.
6.3.79.4.4 Effect of receipt
The SME is notified of the results of the MCCAOP setup procedure.
6.3.79.5 MLME-MCCASETUP.indication
6.3.79.5.1 Function
This primitive indicates the receipt of an MCCA Setup Request frame from the peer MAC entity specified in
MCCAOPOwner.
6.3.79.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCASETUP.indication(
MCCAOPParameters,
MCCAOPID,
MCCAOPOwner,
VendorSpecificInfo
)
Name Type Valid range Description
MCCAOPParameters MCCAOP See 9.4.2.106.2 The MCCAOP reservation parameters.
Reservation
MCCAOPID Integer 0–254 MCCAOP reservation ID of the
MCCAOP reservation.
MCCAOPOwner MAC address Any valid individual Specifies the MAC address of the
MAC address MCCAOP owner.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.79.5.3 When generated
This primitive is generated by the MLME as result of the receipt of an MCCA Setup Request frame from the
peer MAC entity specified in MCCAOPOwner.
510
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.79.5.4 Effect of receipt
The SME is notified of the request to establish an MCCAOP reservation with the peer MAC entity specified
in MCCAOPOwner.
6.3.79.6 MLME-MCCASETUP.response
6.3.79.6.1 Function
This primitive is used to send a response to the peer MAC entity specified in MCCAOPOwner that
requested the set up of the MCCAOP reservation.
6.3.79.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCASETUP.response(
MCCAOPParameters,
MCCAOPID,
MCCAOPOwner,
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
MCCAOPParameters MCCAOP See 9.4.2.106.2 The MCCAOP reservation
Reservation parameters.
MCCAOPID Integer 0–254 MCCAOP reservation ID of the
MCCAOP reservation.
MCCAOPOwner MAC address Any valid individual MAC Specifies the MAC address of the
address MCCAOP owner.
ResultCode Enumeration SUCCESS, Indicates the result of the MLME-
INVALID_PARAMETERS, MCCASETUP.request primitive.
MCCAOP_RESERVATION_C
ONFLICT,
MAF_LIMIT_EXCEEDED,
MCCA_TRACK_LIMIT_EX
CEEDED
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.79.6.3 When generated
This primitive is generated by the SME of a STA as a response to an MLME-MCCASETUP.indication
primitive.
6.3.79.6.4 Effect of receipt
This primitive initiates transmission of a response to the peer MAC entity specified in the MCCAOPOwner
that requested the set up of an MCCAOP reservation.
511
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.79.7 MLME-MCCAADVERTISEMENT.request
6.3.79.7.1 Function
This primitive requests that the MAC entity request an MCCAOP advertisement from the specified peer
MAC entity by sending an MCCA Advertisement Request frame to the peer MAC entity.
6.3.79.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCAADVERTISEMENT.request(
PeerMACAddress,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC address Any valid Specifies the MAC address of the peer MAC
individual that sends the Advertisement.
MAC address
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.79.7.3 When generated
This primitive is generated by the SME to request an MCCAOP advertisement from the specified peer MAC
entity.
6.3.79.7.4 Effect of receipt
This primitive causes the transmission of an MCCA Advertisement Request frame to the specified peer
MAC entity. In the case that a response is received from the responder STA, the MLME subsequently issues
an MLME-MCCAADVERTISEMENT.confirm primitive that reflects the results.
6.3.79.8 MLME-MCCAADVERTISEMENT.confirm
6.3.79.8.1 Function
This primitive reports the result of an MLME-MCCAADVERTISEMENT.request primitive.
6.3.79.8.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCAADVERTISEMENT.confirm(
MCCAOPAdvertisement,
PeerMACAddress,
ResultCode,
VendorSpecificInfo
)
512
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
MCCAOPAdvertise MCCAOP See 9.4.2.109 One or more MCCAOP
ment Advertisement Advertisement elements.
PeerMACAddress MAC address Any valid individual MAC Specifies the MAC address of the
address transmitter of the MCCAOP
advertisement.
ResultCode Enumeration SUCCESS, REFUSED Indicates the result of the
MLME-
MCCAADVERTISEMENT.request
primitive.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.79.8.3 When generated
This primitive is generated by the MLME as a result of an MLME-MCCAADVERTISEMENT.request
primitive.
6.3.79.8.4 Effect of receipt
The SME is notified of the results of the MCCA Advertisement Request frame.
6.3.79.9 MLME-MCCAADVERTISEMENT.indication
6.3.79.9.1 Function
This primitive reports that an MCCA Advertisement Request frame has been received from the specified
peer MAC entity.
6.3.79.9.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCAADVERTISEMENT.indication(
PeerMACAddress,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC address Any valid individual Specifies the MAC address of the
MAC address transmitter of the MCCA Advertisement
Request frame.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.79.9.3 When generated
This primitive is generated by the MLME upon receipt of an MCCA Advertisement Request frame from the
specified peer MAC entity.
6.3.79.9.4 Effect of receipt
The SME is notified of the request to advertise its MCCAOP reservations.
513
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.79.10 MLME-MCCAADVERTISEMENT.response
6.3.79.10.1 Function
This primitive requests that the MAC entity respond to the MCCAOP advertisement request from the
specified peer MAC entity by sending an MCCA Advertisement frame to the peer MAC entity.
6.3.79.10.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCAADVERTISEMENT.response(
MCCAOPAdvertisement,
PeerMACAddress,
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
MCCAOPAdvertise MCCAOP See 9.4.2.109 One or more MCCAOP
ment Advertisement Advertisement elements.
PeerMACAddress MAC address Any valid individual MAC Specifies the MAC address of the
address transmitter of the MCCA
Advertisement frame.
ResultCode Enumeration SUCCESS, REFUSED Indicates the result of the
MLME-
MCCAADVERTISEMENT.respon
se primitive.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.79.10.3 When generated
This primitive is generated by the SME of a STA as a response to an MLME-
MCCAADVERTISEMENT.indication procedure.
6.3.79.10.4 Effect of receipt
This primitive initiates transmission of a response to the specified peer MAC entity that requested
advertisement of the MCCAOP reservations.
6.3.79.11 MLME-MCCATEARDOWN.request
6.3.79.11.1 Function
This primitive requests that the MAC entity tear down an MCCAOP reservation.
6.3.79.11.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCATEARDOWN.request(
MCCAOPID,
PeerMACAddress,
VendorSpecificInfo
)
514
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
MCCAOPID Integer 0–255 Specifies the MCCAOP reservation ID of the
MCCAOP reservation to be torn down.
PeerMACAddress MAC address Any valid Specifies the MAC address of the peer MAC
individual for the MCCAOP reservation.
MAC address
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.79.11.3 When generated
This primitive is generated by the SME to start an MCCAOP teardown procedure.
6.3.79.11.4 Effect of receipt
This primitive causes the teardown MCCAOP reservation identified by means of the MCCAOP reservation
ID in MCCAOPID, and the transmission of an MCCA Teardown frame to the peer MAC entity in Peer-
MACAddress.
6.3.79.12 MLME-MCCATEARDOWN.indication
6.3.79.12.1 Function
This primitive reports that an MCCA Teardown frame has been received from the specified peer MAC
entity.
6.3.79.12.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MCCATEARDOWN.indication(
MCCAOPID,
PeerMACAddress,
VendorSpecificInfo
)
Name Type Valid range Description
MCCAOPID Integer 0–255 MCCAOP reservation ID of the
MCCAOP reservation to be torn down.
PeerMACAddress MAC address Any valid individual Specifies the MAC address of the peer
MAC address MAC for the MCCAOP reservation.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.79.12.3 When generated
This primitive is generated by the MLME as result of receipt of a MCCA Teardown frame.
6.3.79.12.4 Effect of receipt
The SME is notified of the request to start an MCCAOP teardown procedure.
515
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.80 MBSS congestion control
6.3.80.1 Introduction
The following primitives describe how a mesh STA manages its congestion control operation.
6.3.80.2 MLME-MBSSCONGESTIONCONTROL.request
6.3.80.2.1 Function
This primitive requests that the MAC entity notify the peer MAC entity on the congestion level or requests
to traffic generation by transmitting a Congestion Control Notification frame to the specified peer MAC
entity.
6.3.80.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- MBSSCONGESTIONCONTROL.request(
PeerMACAddress,
CongestionNotification,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual to which the Congestion Control Notification
MAC address frame is sent.
CongestionNotification A set of As defined in Congestion notification information generated
Congestion 9.4.2.101 by the mesh STA.
Notification
elements
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.80.2.3 When generated
The SME generates this primitive to request that the MAC notify its peer MAC about the current congestion
level.
6.3.80.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Congestion Control Notification frame. This frame is
then scheduled for transmission.
6.3.80.3 MLME-MBSSCONGESTIONCONTROL.indication
6.3.80.3.1 Function
This primitive indicates that a congestion notification has been received.
6.3.80.3.2 Semantics of the service primitive
The primitive parameters are as follows:
516
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME- MBSSCONGESTIONCONTROL.indication(
PeerMACAddress,
CongestionNotification,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC
MAC address entity from which the Congestion Control
Notification frame was received.
CongestionNotification A set of As defined in 9.4.2.101 Congestion notification information
Congestion contained in the received Congestion
Notification Control Notification frame.
elements
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.80.3.3 When generated
This primitive is generated by the MLME as a result of the receipt of a Congestion Control Notification
frame from a specific peer MAC entity.
6.3.80.3.4 Effect of receipt
The SME is notified of the results of the receipt of the congestion control notification from the specified peer
MAC entity. The mesh STA that received this primitive subsequently activates the local rate control as
described in 14.12.
6.3.81 MBSS proxy update
6.3.81.1 Introduction
The following primitives describe how a mesh STA reports the proxy update information to another mesh
STA in the MBSS.
6.3.81.2 MLME-MBSSPROXYUPDATE.request
6.3.81.2.1 Function
This primitive requests that the MAC entity inform a destination mesh STA about its proxy information by
transmitting a Proxy Update frame to the specified peer MAC entity.
6.3.81.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- MBSSPROXYUPDATE.request(
PeerMACAddress,
ProxyUpdate,
VendorSpecificInfo
)
517
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual to which the Proxy Update frame is sent.
MAC address
ProxyUpdate A set of PXU As defined in A set of proxy information available at the
elements 9.4.2.116 mesh STA.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.81.2.3 When generated
This primitive is generated by the SME to request that a Proxy Update frame be sent to the specified peer
MAC entity.
6.3.81.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Proxy Update frame containing the PXU element. This
frame is then scheduled for transmission. In the case that a response is received from the responder STA, the
MLME subsequently issues an MLME- MBSSPROXYUPDATE.confirm primitive that reflects the results
of this request.
6.3.81.3 MLME-MBSSPROXYUPDATE.confirm
6.3.81.3.1 Function
This primitive reports the results of a proxy update request.
6.3.81.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- MBSSPROXYUPDATE.confirm(
PeerMACAddress,
ProxyUpdateConfirmation,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual MAC Specifies the address of the peer
address MAC entity from which the Proxy
Update Confirmation frame is
received.
ProxyUpdateConfirm A set of As defined in 9.4.2.117 A set of proxy update confirmation
ation PXUC information from the peer MAC
elements entity to which the Proxy Update
frame was sent.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.81.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-MBSSPROXYUPDATE.request
primitive.
518
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.81.3.4 Effect of receipt
The SME is notified of the results of the MBSS proxy update request.
6.3.81.4 MLME-MBSSPROXYUPDATE.indication
6.3.81.4.1 Function
This primitive indicates that an update of the proxy information has been received from a specific peer MAC
entity.
6.3.81.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- MBSSPROXYUPDATE.indication(
PeerMACAddress,
ProxyUpdate,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC
MAC address entity from which the update of the proxy
information was received.
ProxyUpdate A set of As defined in 9.4.2.116 A set of proxy information received from
PXU elements the peer mesh STA.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.81.4.3 When generated
This primitive is generated by the MLME as a result of the receipt of a Proxy Update frame from a specific
peer MAC entity.
6.3.81.4.4 Effect of receipt
The SME is notified of the results of the receipt of the proxy update request by the specified peer MAC
entity. The mesh STA that received this primitive subsequently updates the proxy information as described
in 14.11.4.3.
6.3.81.5 MLME-MBSSPROXYUPDATE.response
6.3.81.5.1 Function
This primitive is used to send a response to a specific peer MAC entity that sent an update of the proxy
information to the mesh STA that issued this primitive.
519
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.81.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- MBSSPROXYUPDATE.response(
PeerMACAddress,
ProxyUpdateConfirmation,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual MAC Specifies the address of the peer
address MAC entity to which the Proxy
Update Confirmation frame is sent.
ProxyUpdateConfirm A set of As defined in 9.4.2.117 A set of proxy update confirmation
ation PXUC information to be sent to the peer
elements MAC entity.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.81.5.3 When generated
This primitive is generated by the SME of a STA as a response to an MLME-
MBSSPROXYUPDATE.indication primitive.
6.3.81.5.4 Effect of receipt
This primitive initiates transmission of a response to the specific peer MAC entity that sent an update of the
proxy information.
On receipt of this primitive, the MLME constructs a Proxy Update Confirmation frame. The frame contains
one or more PXUC elements. This frame is then scheduled for transmission.
6.3.82 MBSS mesh gate announcement
6.3.82.1 Introduction
The following primitives describe how a mesh STA announces mesh gate reachability.
6.3.82.2 MLME-MBSSGATEANNOUNCEMENT.request
6.3.82.2.1 Function
This primitive requests that the MAC entity update the mesh gate information by transmitting a Gate
Announcement frame to the specified MAC entity.
6.3.82.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- MBSSGATEANNOUNCEMENT.request(
PeerMACAddress,
GateAnnouncement,
VendorSpecificInfo
)
520
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the MAC entity to
group MAC which the Gate announcement frame is sent.
address
GateAnnouncement GANN As defined in A set of gate announcement information to be
element 9.4.2.111 sent through a Gate Announcement frame.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
6.3.82.2.3 When generated
This primitive is generated by the SME to request that a Gate Announcement frame be sent to the specified
MAC entity.
6.3.82.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Gate Announcement frame containing the GANN
element. This frame is then scheduled for transmission following the interval specified by
dot11MeshGateAnnouncementInterval.
6.3.82.3 MLME-MBSSGATEANNOUNCEMENT.indication
6.3.82.3.1 Function
This primitive indicates that a mesh gate announcement has been received from the specific peer MAC
entity.
6.3.82.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- MBSSGATEANNOUNCEMENT.indication(
PeerMACAddress,
GateAnnouncement,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC
MAC address entity from which the gate announcement
was received.
GateAnnouncement GANN As defined in 9.4.2.111 A set of gate announcement information
element contained in the received Gate
Announcement frame.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.82.3.3 When generated
This primitive is generated by the MLME as a result of the receipt of a Gate Announcement frame from a
specific peer MAC entity.
521
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.82.3.4 Effect of receipt
The SME is notified of the reachability to a mesh gate in the mesh BSS. The mesh STA received this
primitive subsequently triggers an MBSSGATEANNOUNCEMENT.request primitive as described in
14.11.2.
6.3.83 Mesh link metric
6.3.83.1 Introduction
Subclause 6.3.83 describes the management procedures associated with mesh link metric reporting.
6.3.83.2 MLME-MESHLINKMETRICREAD.request
6.3.83.2.1 Function
This primitive requests to read a link metric value between the local MAC entity and a specific peer MAC
entity.
6.3.83.2.2 Semantics of the service primitive
The primitive parameter is as follows:
MLME-MESHLINKMETRICREAD.request(
PeerMACAddress
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual for which the link metric value is read
MAC address
6.3.83.2.3 When generated
This primitive is generated by the SME to read the link metric value for the mesh link to the specified peer
MAC entity.
6.3.83.2.4 Effect of receipt
On receipt of this primitive, the MLME reports the link metric value. The MLME subsequently issues an
MLME-MESHLINKMETRICREAD.confirm primitive that reflects the results of this request.
6.3.83.3 MLME-MESHLINKMETRICREAD.confirm
6.3.83.3.1 Function
This primitive reports the results of a link metric read request.
6.3.83.3.2 Semantics of the service primitive
The primitive parameters are as follows:
522
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME- MESHLINKMETRICREAD.confirm(
LinkMetricValue,
VendorSpecificInfo
)
Name Type Valid range Description
LinkMetricValue Mesh Link As defined in 9.4.2.100 The link metric value for the mesh
Metric Report link to the specified peer MAC
element entity.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.83.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-MESHLINKMETRICREAD.request
primitive to request a link metric value.
6.3.83.3.4 Effect of receipt
The SME is notified of the results of the link metric read request.
6.3.83.4 MLME-MESHLINKMETRICREPORT.request
6.3.83.4.1 Function
This primitive requests that the MAC entity either transmit a link metric to or request a link metric from the
specified peer MAC entity.
6.3.83.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-MESHLINKMETRICREPORT.request(
PeerMACAddress,
LinkMetricRequestFlag,
MeshLinkMetricReport,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual to which the Mesh Link Metric Report is sent.
MAC address
LinkMetricRequestFlag Enumeration REPORT_ON Indicates whether the mesh STA requests a
LY, link metric report from the peer MAC entity.
REPORT_AN
D_REQUEST
MeshLinkMetricReport Mesh Link As defined in A metric value computed for the
Metric Report 9.4.2.100 corresponding link.
element
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
523
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.83.4.3 When generated
This primitive is generated by the SME to request that a Mesh Link Metric Report frame be sent to a peer
MAC entity in order to report a link metric value and to request a mesh link metric report from the
peer MAC entity if LinkMetricRequestFlag is equal to REPORT_AND_REQUEST.
6.3.83.4.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Mesh Link Metric Report frame.The Request subfield
in the Flags field of the Mesh Link Metric Report element is set depending on the parameter given by the
LinkMetricRequestFlag. If LinkMetricRequestFlag is equal to REPORT_ONLY, the Request subfield is set
to 0. If LinkMetricRequestFlag is equal to REPORT_AND_REQUEST, the Request subfield is set to 1.
This frame is then scheduled for transmission.
6.3.83.5 MLME-MESHLINKMETRICREPORT.indication
6.3.83.5.1 Function
This primitive indicates that a Mesh Link Metric Report frame has been received from a peer MAC entity.
This Mesh Link Metric Request Report can be in response to an earlier MLME-
MESHLINKMETRICREPORT.request primitive with LinkMetricRequestFlag equal to
REPORT_AND_REQUEST.
6.3.83.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME- MESHLINKMETRICREPORT.indication(
PeerMACAddress,
LinkMetricRequestFlag,
MeshLinkMetricReport,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC
MAC address entity from which the Mesh Link Metric
Report frame was received.
LinkMetricRequestFlag Enumeration REPORT_ONLY, Indicates whether the peer MAC entity
REPORT_AND_ requests a link metric report.
REQUEST
MeshLinkMetricReport Mesh Link As defined in 9.4.2.100 A metric value reported from the
Metric Report specified peer MAC entity.
element
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
6.3.83.5.3 When generated
This primitive is generated by the MLME as a result of the receipt of a Mesh Link Metric Report frame from
a specific peer MAC entity.
524
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.83.5.4 Effect of receipt
The SME is notified of the receipt of the link metric report from the specified peer MAC entity. When
LinkMetricRequestFlag is equal to REPORT_AND_REQUEST, the mesh STA responds with a Mesh Link
Metric Report frame.
6.3.84 HWMP mesh path selection
6.3.84.1 Introduction
The following primitives describe how a mesh STA establishes and maintains a mesh path to a specified
peer MAC entity.
6.3.84.2 MLME-HWMPMESHPATHSELECTION.request
6.3.84.2.1 Function
This primitive requests that the MAC entity establish or maintain a mesh path to the specified peer MAC
entity by transmitting an HWMP Mesh Path Selection frame to the specified peer MAC entity.
6.3.84.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-HWMPMESHPATHSELECTION.request(
PeerMACAddress,
RootAnnouncement,
PathRequest,
PathReply,
PathError,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity
individual or to which the HWMP Mesh Path Selection
group MAC frame is sent.
address
RootAnnouncement RANN As defined in A set of RANN elements generated by the
element 9.4.2.112 mesh STA. Present if the mesh STA is
configured as a root mesh STA using the
proactive RANN mechanism
[dot11MeshHWMProotMode = rann (4)], and
as described in 14.10.12; otherwise not
present.
PathRequest PREQ As defined in A set of PREQ elements generated by the
element 9.4.2.113 mesh STA. Present as described in 14.10.9.
PathReply PREP As defined in A set of PREP elements generated by the mesh
element 9.4.2.114 STA. Present as described in 14.10.10.
PathError PERR As defined in A set of PERR elements generated by the
element 9.4.2.115 mesh STA. Present as described in 14.10.11.
VendorSpecificInfo A set of As defined in Zero or more elements.
elements 9.4.2.26
525
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.84.2.3 When generated
This primitive is generated by the SME to request that an HWMP Mesh Path Selection frame be sent to a
specified peer entity.
6.3.84.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs an HWMP Mesh Path Selection frame. This frame is then
scheduled for transmission.
6.3.84.3 MLME-HWMPMESHPATHSELECTION.indication
6.3.84.3.1 Function
This primitive indicates that an HWMP Mesh Path Selection frame has been received from the specified
peer MAC entity.
6.3.84.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-HWMPMESHPATHSELECTION.indication(
PeerMACAddress,
RootAnnouncement,
PathRequest,
PathReply,
PathError,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC
MAC address entity from which the HWMP Mesh
Path Selection frame was received.
RootAnnouncement RANN As defined in 9.4.2.112 A set of RANN elements contained in the
element received frame. Present only when such
an element was present in the received
frame.
PathRequest PREQ As defined in 9.4.2.113 A set of PREQ elements contained in the
element received frame. Present only when such
an element was present in the received
frame.
PathReply PREP As defined in 9.4.2.114 A set of PREP elements contained in the
element received frame. Present only when such
an element was present in the received
frame.
PathError PERR As defined in 9.4.2.115 A set of PERR elements contained in the
element received frame. Present only when such
an element was present in the received
frame.
VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements.
elements
526
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.84.3.3 When generated
This primitive is generated by the MLME as a result of the receipt of an HWMP Mesh Path Selection frame
from a specific peer MAC entity.
6.3.84.3.4 Effect of receipt
The SME is notified of the results of the receipt of the HWMP Mesh Path Selection from the specified peer
MAC entity. The mesh STA received this primitive subsequently activates path selection procedures
described in 14.10.
6.3.85 QMF policy
6.3.85.1 Introduction
The following MLME primitives support the signaling of QMF policy.
6.3.85.2 MLME-QMFPOLICY.request
6.3.85.2.1 Function
This primitive requests the transmission of an unsolicited QMF Policy frame to a peer entity.
6.3.85.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QMFPOLICY.request (
Peer STA Address,
QMFPolicy,
VendorSpecificInfo
)
Name Type Valid range Description
Peer STA MAC Address Any valid individual The address of the peer MAC entity to which the
Address MAC Address QMF policy is sent.
QMFPolicy QMF Policy As defined in This parameter describes the QMF policy the peer
element 9.4.2.120 STA is required to use.
VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements.
ficInfo elements
6.3.85.2.3 When generated
This primitive is generated by the SME to request that a QMF Policy frame be sent to a peer entity to
communicate QMF policy information.
6.3.85.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a QMF Policy frame. This frame is then scheduled for
transmission.
527
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.85.3 MLME-QMFPOLICY.indication
6.3.85.3.1 Function
This primitive indicates that an unsolicited QMF Policy frame has been received from a peer entity.
6.3.85.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QMFPOLICY.indication (
Peer STA Address,
QMFPolicy,
VendorSpecificInfo
)
Name Type Valid range Description
Peer STA MAC Address Any valid individual The address of the peer MAC from which the QMF
Address MAC Address policy was received.
QMFPolicy QMF Policy As defined in This parameter describes the QMF policy the peer
element 9.4.2.120 STA is requiring to be used.
VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements.
ficInfo elements
6.3.85.3.3 When generated
This primitive is generated by the MLME when a valid QMF Policy frame with dialog token equal to 0 is
received from a peer entity.
6.3.85.3.4 Effect of receipt
The SME is notified of the receipt of a QMF policy.
6.3.85.4 MLME-QMFPOLICYCHANGE.request
6.3.85.4.1 Function
This primitive supports the change of QMF Policy between peer STAs. The SME requests the transmission
of a QMF Policy Change frame in order to request a change in the QMF policy the STA uses to transmit to
the peer STA.
6.3.85.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QMFPOLICYCHANGE.request (
Peer STA Address,
Dialog Token,
QMFPolicy,
VendorSpecificInfo
)
528
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Peer STA MAC Address Any valid individual The address of the peer MAC entity to which the
Address MAC Address QMF policy change request is sent.
Dialog Integer 1–255 The dialog token to identify the QMF policy
Token change transaction.
QMFPolicy QMF Policy As defined in This parameters describes the QMF policy the STA
element 9.4.2.120 is requesting to use.
VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements.
ficInfo elements
6.3.85.4.3 When generated
This primitive is generated by the SME when a STA wishes to request a change of the QMF policy it uses to
transmit Management frames to a peer entity.
6.3.85.4.4 Effect of receipt
On receipt of this primitive, the MLME constructs a QMF Policy Change frame containing the set of QMF
policy parameters. This frame is then scheduled for transmission.
6.3.85.5 MLME-QMFPOLICYCHANGE.confirm
6.3.85.5.1 Function
This primitive reports the results of a policy change attempt with a peer QMF STA.
6.3.85.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QMFPOLICYCHANGE.confirm (
Peer STA Address,
Dialog Token,
Result Code,
VendorSpecificInfo
)
Name Type Valid range Description
Peer STA MAC Address Any valid individual The address of the peer MAC entity from which the
Address MAC Address QMF policy was received.
Dialog Integer 1–255 The dialog token to identify the QMF policy
Token change transaction.
Result Code Enumeration SUCCESS, Reports the receipt of a QMF Policy frame and the
REJECT result of the QMF policy change at the peer SME or
if no matching response is received within
dot11QMFPolicyChangeTimeout TU.
VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements.
ficInfo elements
529
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.85.5.3 When generated
This primitive is generated by the MLME as a result of receipt of a QMF Policy frame with a dialog token
that matches the dialog token from the MLME-QMFPOLICYCHANGE.request primitive.
6.3.85.5.4 Effect of receipt
The SME is notified of the results of the QMF policy change procedure.
6.3.85.6 MLME-QMFPOLICYCHANGE.indication
6.3.85.6.1 Function
This primitive indicates that a QMF Policy Change frame has been received from a peer entity.
6.3.85.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QMFPOLICYCHANGE.indication (
Peer STA Address,
Dialog Token,
QMFPolicy,
VendorSpecificInfo
)
Name Type Valid range Description
Peer STA MAC Address Any valid individual The address of the peer MAC entity from which the
Address MAC Address QMF policy change request was received.
Dialog Integer 1–255 The dialog token to identify the QMF policy
Token change transaction.
QMFPolicy QMF Policy As defined in This parameter describes the QMF policy the peer
element 9.4.2.120 STA is requesting to use.
VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements.
ficInfo elements
6.3.85.6.3 When generated
This primitive is generated by the MLME when a valid QMF Policy Change frame is received from a peer
entity.
6.3.85.6.4 Effect of receipt
On receipt of this primitive, the parameters of the QMF Policy Change frame are provided to the SME to be
processed.
6.3.85.7 MLME-QMFPOLICYCHANGE.response
6.3.85.7.1 Function
This primitive requests the transmission of a QMF Policy frame with no QMF Policy field to a peer entity, in
response to a received QMF Policy Change frame.
530
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.85.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QMFPOLICYCHANGE.response (
Peer STA Address,
Dialog Token,
Result Code,
VendorSpecificInfo
)
Name Type Valid range Description
Peer STA MAC Address Any valid individual The address of the peer MAC entity to which the
Address MAC Address QMF Policy frame is sent in response to a QMF
policy change request.
Dialog Integer 1–255 The dialog token identifying the QMF policy
Token change transaction.
Result Code Enumeration SUCCESS, Reports the outcome of the transaction.
REJECT
VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements.
ficInfo elements
6.3.85.7.3 When generated
This primitive is generated by the SME to request that a QMF Policy frame be transmitted to a peer entity to
convey the results of the QMF policy change procedure.
6.3.85.7.4 Effect of receipt
On receipt of this primitive, the MLME constructs a QMF Policy frame containing the set of QMF Policy
elements specified. This frame is then scheduled for transmission.
6.3.85.8 MLME-QMFPOLICYSET.request
6.3.85.8.1 Function
This primitive directs the setting of a specific QMF policy in the local MLM.
6.3.85.8.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QMFPOLICYSET.request (
Peer STA address,
QMFPolicy
)
Name Type Valid range Description
Peer STA MAC Address Any valid individual The address of the peer STA for which the QMF
Address MAC address policy is to be used. If this parameter is null, the
QMF policy applies to all transmissions.
QMFPolicy QMF Policy As defined in This parameter describes the QMF policy the
element 9.4.2.120 MLME is directed to use for all QMFs transmitted
to the Peer STA Address.
531
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.85.8.3 When generated
This primitive is generated by the SME to set the MLME’s QMF policy for a peer STA.
6.3.85.8.4 Effect of receipt
On receipt of this primitive, the MLME uses the supplied set of QMF policy parameters in future transmis-
sions to the peer.
6.3.86 SCS request and response procedure
6.3.86.1 General
The following MLME primitives support the signaling of the SCS request and response procedure. The
informative diagram shown in Figure 6-27 depicts the SCS request and response process and is not meant to
be exhaustive of all possible protocol uses.
Non-AP STA AP
SME MLME MLME SME
MLME- MLME-
SCS.request SCS Request frame SCS.indication
Process SCS request
MLME- MLME-
SCS.confirm SCS Response frame SCS.response
AP might decide to terminate
a granted SCS at any time
MLME-SCS- MLME-SCS-
TERM.indication SCS Response frame TERM.request
Figure 6-27—Example SCS setup and termination protocol exchange
6.3.86.2 MLME-SCS.request
6.3.86.2.1 Function
This primitive requests transmission of an SCS Request frame to an AP.
6.3.86.2.2 Semantics of the service primitive
The primitive parameters are as follows:
532
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-SCS.request(
PeerSTAAddress,
DialogToken,
SCSRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual Specifies the address of the
MAC address peer MAC entity with which
to perform the SCS process.
DialogToken Integer 1–255 The dialog token to identify
the SCS request and
response transaction.
SCSRequest SCS Descriptor element SCS Descriptor Specifies frame classifiers
element, as defined in and priority for the requested
9.4.2.122 SCS stream.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.86.2.3 When generated
This primitive is generated by the SME to request that a SCS Request frame be sent to the AP with which the
STA is associated.
6.3.86.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a SCS Request frame. The STA then attempts to transmit
this frame to the AP with which the STA is associated.
6.3.86.3 MLME-SCS.confirm
6.3.86.3.1 Function
This primitive reports the result of a SCS procedure.
6.3.86.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SCS.confirm(
PeerSTAAddress,
DialogToken,
SCSResponse,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC Specifies the address of the
address peer MAC entity with
which to perform the SCS
process.
DialogToken Integer 1–255 The dialog token to identify
the SCS request and
response transaction.
533
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
SCSResponse SCS Status duple SCS Status duple, as defined Specifies the status returned
in 9.6.19.3 by the AP responding to the
STA’s requested SCSID.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.86.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-SCS.request primitive and indicates the
results of the request.
This primitive is generated when the STA receives a SCS Response frame from the AP.
6.3.86.3.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.27.2.
6.3.86.4 MLME-SCS.indication
6.3.86.4.1 Function
This primitive indicates that an SCS Request frame was received from a non-AP STA.
6.3.86.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SCS.indication(
PeerSTAAddress,
DialogToken,
SCSRequest,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual The address of the non-AP
MAC address STA MAC entity from
which an SCS Request
frame was received.
DialogToken Integer 1–255 The dialog token to identify
the SCS request and
response transaction.
SCSRequest SCS Descriptor element SCS Descriptor Specifies frame classifiers
element, as defined in and priority for the requested
9.4.2.122 SCS stream.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.86.4.3 When generated
This primitive is generated by the MLME when a valid SCS Request frame is received.
6.3.86.4.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.27.2.
534
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.86.5 MLME-SCS.response
6.3.86.5.1 Function
This primitive is generated in response to an MLME-SCS.indication primitive requesting an SCS Response
frame be sent to a non-AP STA.
6.3.86.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SCS.response(
PeerSTAAddress,
DialogToken,
SCSResponse,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual The address of the non-AP
MAC address STA MAC entity from
which a SCS Request frame
was received.
DialogToken Integer 1–255 The dialog token to identify
the SCS request and
response transaction.
SCSResponse SCS Status duple SCS Status duple, as Specifies the status returned
defined in 9.6.19.3 by the AP responding to the
STA’s requested SCSID.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.86.5.3 When generated
This primitive is generated by the SME in response to an MLME-SCS.indication primitive requesting an
SCS Response frame be sent to a non-AP STA.
6.3.86.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a SCS Response frame. The STA then attempts to
transmit this frame to the non-AP STA indicated by the PeerSTAAddress parameter.
6.3.86.6 MLME-SCS-TERM.request
6.3.86.6.1 Function
This primitive requests the transmission of a SCS Response frame to a non-AP STA to terminate an
established SCS stream.
6.3.86.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SCS-TERM.request(
PeerSTAAddress,
DialogToken,
SCSResponse,
VendorSpecificInfo
)
535
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual The address of the non-AP
MAC address STA MAC entity to which
the SCS Response frame is
to be sent.
DialogToken Integer 0 Set to 0 for an autonomous
SCS Response frame.
SCSResponse SCS Status duple SCS Status duple, as Specifies the requested
defined in 9.6.19.3 SCSID that is canceled by
the AP.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.86.6.3 When generated
This primitive is generated by the SME to terminate an SCS stream.
6.3.86.6.4 Effect of receipt
On receipt of this primitive, the MLME constructs an SCS Response frame. The STA then attempts to
transmit this frame to the non-AP STA indicated by the PeerSTAAddress parameter.
6.3.86.7 MLME-SCS-TERM.indication
6.3.86.7.1 Function
This primitive is generated by the MLME when a valid unsolicited SCS Response frame is received.
6.3.86.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-SCS-TERM.indication(
ResultCode,
DialogToken,
SCSResponse,
VendorSpecificInfo
)
Name Type Valid range Description
ResultCode Enumeration SUCCESS, FAILURE Indicates the result of the
MLME-SCS-TERM.request
primitive.
DialogToken Integer 0 Set to 0 for an autonomous
SCS Response frame.
SCSResponse SCS Status duple SCS Status duple, as Specifies the requested
defined in 9.6.19.3 SCSID that is canceled by
the AP.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
536
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.86.7.3 When generated
This primitive is generated when the STA receives an unsolicited SCS Response frame from the AP.
6.3.86.7.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 11.27.2.
6.3.87 QLoad report management
6.3.87.1 General
The QLoad report management primitives support the process of QLoad reporting between APs as described
in 11.28.2.
6.3.87.2 MLME-QLOAD.request
6.3.87.2.1 Function
This primitive is used by an AP to transmit a QLoad Request frame to a specified AP.
6.3.87.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QLOAD.request(
PeerMACAddress,
DialogToken,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity to which the
QLoad Request frame is
sent.
DialogToken Integer 1–255 Specifies a number unique to
the MLME-QLOAD.request
primitive.
Protected Boolean true, false If true, the request is sent
using the Protected QLoad
Request frame. If false, the
request is sent using the
QLoad Request frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.87.2.3 When generated
This primitive is generated by the SME at an AP to request the transmission of a QLoad Request frame to
the AP indicated by the PeerMACAddress parameter.
537
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.87.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a QLoad Request frame if the Protected parameter is false
or a Protected QLoad Request frame if the Protected parameter is true. The AP then attempts to transmit this
frame to the AP indicated by the PeerMACAddress parameter.
6.3.87.3 MLME-QLOAD.confirm
6.3.87.3.1 Function
This primitive reports the result of a request to send a QLoad Request frame.
6.3.87.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QLOAD.confirm(
PeerMACAddress,
DialogToken,
Protected,
QLoadReport,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual MAC The address of the peer
address MAC entity to which the
QLoad Request frame was
sent.
DialogToken Integer 0–255 Specifies a number unique to
the QLoad Report request
and response transaction or 0
when an unsolicited report
was sent.
Protected Boolean true, false If true, the response was sent
using the Protected QLoad
Report frame. If false, the
response was sent using the
QLoad Report frame.
QLoadReport Set of reports, each Set of reports, each as Set of reports, each as
as defined in the defined in the QLoad Report defined in the QLoad Report
QLoad Report element element.
element
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.87.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-QLOAD.request primitive indicating the
results of that request. This primitive is generated when the STA receives a response in the form of a QLoad
Report frame in the corresponding Robust AV Streaming Action frame.
6.3.87.3.4 Effect of receipt
The SME is notified of the results of the QLoad request procedure.
The SME should operate according to the procedures defined in 11.28.2.
538
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.87.4 MLME-QLOAD.indication
6.3.87.4.1 Function
This primitive indicates that a QLoad Request frame has been received.
6.3.87.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QLOAD.indication(
PeerMACAddress,
DialogToken,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity from which the
QLoad Request frame was
received.
DialogToken Integer 1–255 Specifies a number unique to
the MLME-QLOAD.request
primitive.
Protected Boolean true, false If true, the request was sent
using the Protected QLoad
Request frame. If false, the
request was sent using the
QLoad Request frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.87.4.3 When generated
This primitive is generated by the MLME when a valid (Protected) QLoad Request frame is received.
6.3.87.4.4 Effect of receipt
On receipt of this primitive, the SME either rejects the request or commences the transaction as described in
11.28.2.
6.3.87.5 MLME-QLOAD.response
6.3.87.5.1 Function
This primitive is used by an AP to transmit a QLoad Report frame to a specified AP in response to a QLoad
Request frame.
6.3.87.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QLOAD.response(
PeerMACAddress,
DialogToken,
Protected,
539
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
QLoadReport,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity to which the
QLoad Report frame is sent.
DialogToken Integer 0–255 The dialog token of the
matching MLME-
QLOAD.indication
primitive or 0 when sending
an unsolicited report.
Protected Boolean true, false If true, the response is sent
using the Protected QLoad
Report frame. If false, the
response is sent using the
QLoad Report frame.
QLoadReport Set of reports, each as Set of reports, each as Set of reports, each as
defined in the QLoad defined in the QLoad defined in the QLoad Report
Report element Report element element.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.87.5.3 When generated
This primitive is generated by the SME at an AP in response to the reception of a QLoad Request frame
from the AP indicated by the PeerMACAddress parameter.
6.3.87.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a QLoad Report frame if the Protected parameter is false
or a Protected QLoad Report frame if the Protected parameter is true. The AP then attempts to transmit this
frame to the other AP indicated by the PeerMACAddress parameter.
6.3.88 HCCA TXOP advertisement management
6.3.88.1 General
The TXOP advertisement management primitives support the process of TSPEC schedule negotiation
between APs, as described in 11.28.
6.3.88.2 MLME-TXOPADVERTISEMENT.request
6.3.88.2.1 Function
This primitive is used by an AP to transmit an HCCA TXOP advertisement to a specified AP.
6.3.88.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TXOPADVERTISEMENT.request(
PeerMACAddress,
DialogToken,
Protected,
ActiveTXOPReservations,
540
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PendingTXOPReservations,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity to which the
TXOP Advertisement frame
is sent.
DialogToken Integer 0–255 Specifies a number unique to
the
TXOPAdvertisement.request
primitive.
Protected Boolean true, false If true, the request is sent
using the Protected HCCA
TXOP Advertisement frame.
If false, the request is sent
using the HCCA TXOP
Advertisement frame.
ActiveTXOPReservations TXOP Reservation As defined in 9.4.1.44 Specifies the HCCA TXOPs
that have been created.
PendingTXOPReservations TXOP Reservation As defined in 9.4.1.44 Specifies the HCCA TXOPs
that are in the process of
being created.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.88.2.3 When generated
This primitive is generated by the SME at an AP to request a (Protected) HCCA TXOP Advertisement frame
be sent to the AP indicated by the PeerMACAddress parameter.
6.3.88.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs an HCCA TXOP Advertisement frame if the Protected
parameter is false or constructs a Protected HCCA TXOP Advertisement frame if the Protected parameter is
true. This frame is then scheduled for transmission.
6.3.88.3 MLME-TXOPADVERTISEMENT.confirm
6.3.88.3.1 Function
This primitive reports the result of a request to perform HCCA TXOP negotiation.
6.3.88.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TXOPADVERTISEMENT.confirm(
ResultCode,
PeerMACAddress,
DialogToken,
Protected,
AlternateSchedule,
AvoidanceRequest,
VendorSpecificInfo
)
541
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ResultCode Enumeration SUCCESS, Reports the outcome of a
TS_SCHEDULE_ request to send a TXOP
CONFLICT advertisement. Indicates the
results of the corresponding
MLME-
TXOPADVERTISE.request
primitive.
PeerMACAddress MACAddress Any valid individual MAC The address of the peer
address MAC entity from which the
Scheduled TXOP Response
frame was received.
DialogToken Integer 0–255 The dialog token to identify
the scheduled TXOP
advertisement and scheduled
TXOP response transaction.
Protected Boolean true, false If true, the response was sent
using the Protected HCCA
TXOP Response frame. If
false, the response was sent
using the HCCA TXOP
Response frame.
AlternateSchedule TXOP Reservation As defined in 9.4.1.44 Specifies an alternate TXOP
when status code is not
SUCCESS.
AvoidanceRequest TXOP Reservation As defined in 9.4.1.44 Specifies a TXOP to avoid
when status code is not
SUCCESS.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.88.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-TXOPADVERTISEMENT.request
primitive indicating the results of that request. This primitive is generated when the STA receives a response
in the form of an HCCA TXOP Response frame in the corresponding Public Action frame, or when the STA
receives a response in the form of a Protected HCCA TXOP Response frame in the corresponding frame.
6.3.88.3.4 Effect of receipt
On receipt of this primitive, the SME performs the behavior defined in 11.28.3.
6.3.88.4 MLME-TXOPADVERTISEMENT.indication
6.3.88.4.1 Function
This primitive indicates that an HCCA TXOP Advertisement frame has been received from a peer entity.
6.3.88.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TXOPADVERTISEMENT.indication(
PeerMACAddress,
DialogToken,
Protected,
ActiveTXOPReservations,
542
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PendingTXOPReservations,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity from which the
HCCA TXOP
Advertisement frame was
sent.
DialogToken Integer 0–255 Specifies a number unique to
the MLME-
TXOPADVERTISEMENT.r
equest primitive.
Protected Boolean true, false If true, the request was sent
using the Protected HCCA
TXOP Request frame. If
false, the request was sent
using the HCCA TXOP
Request frame.
ActiveTXOPReservations TXOP Reservation As defined in 9.4.1.44 Specifies the HCCA TXOPs
that have been created.
PendingTXOPReservations TXOP Reservation As defined in 9.4.1.44 Specifies the HCCA TXOPs
that are in the process of
being created.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.88.4.3 When generated
This primitive is generated by the MLME when a valid HCCA TXOP Advertisement frame is received.
6.3.88.4.4 Effect of receipt
On receipt of this primitive, the SME performs the behavior defined in 11.28.3.
6.3.88.5 MLME-TXOPADVERTISEMENT.response
6.3.88.5.1 Function
This primitive is used by an AP to transmit an HCCA TXOP Response frame to a specified AP.
6.3.88.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-TXOPADVERTISEMENT.response(
PeerMACAddress,
DialogToken,
Protected,
StatusCode,
ScheduleConflict,
AlternateSchedule,
AvoidanceRequest,
VendorSpecificInfo
)
543
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity to which the
HCCA TXOP Response
frame is sent.
DialogToken Integer 0–255 The dialog token to identify
the TXOP advertisement and
TXOP response transaction.
Protected Boolean true, false If true, the response is sent
using the Protected HCCA
TXOP Response frame. If
false, the response is sent
using the HCCA TXOP
Response frame.
StatusCode Enumeration SUCCESS, The result of checking the
TS_SCHEDULE_ TXOP reservation from the
CONFLICT (as defined corresponding TXOP
in 9.4.1.9) advertisement.
ScheduleConflict Integer 1–number of TXOP The TXOP reservation from
reservations the HCCA TXOP
Advertisement frame that
conflicts with an existing or
in-progress schedule.
AlternateSchedule TXOP Reservation As defined in 9.4.1.44 Specifies an alternate TXOP
when status code is not
SUCCESS.
AvoidanceRequest TXOP Reservation As defined in 9.4.1.44 Specifies a TXOP to avoid
when status code is not
SUCCESS.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.88.5.3 When generated
This primitive is generated by the SME at an AP to request the sending of an HCCA TXOP Response frame
to another AP indicated by the PeerMACAddress parameter.
6.3.88.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs an HCCA TXOP Response frame if the Protected
parameter is false or constructs a Protected HCCA TXOP Response frame if the Protected parameter is true.
The AP then attempts to transmit this frame to the AP indicated by the PeerMACAddress parameter.
6.3.89 GCR group membership management
6.3.89.1 General
The group membership primitives support the process of group membership requesting and reporting
between an AP and its associated STAs as described in 11.24.16.3.2.
6.3.89.2 MLME-GROUP-MEMBERSHIP.request
6.3.89.2.1 Function
This primitive is used by an AP to initiate a Group Membership Request frame to a specified associated
STA.
544
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.89.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GROUP-MEMBERSHIP.request(
PeerMACAddress,
DialogToken,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity to which the
Group Membership Request
frame is to be sent.
DialogToken Integer 0–255 Specifies a number unique to
the MLME-GROUP-
MEMBERSHIP.request
primitive.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.89.2.3 When generated
This primitive is generated by the SME at an AP to request the sending of a Group Membership Request
frame to the associated STA indicated by the PeerMACAddress parameter.
6.3.89.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Group Membership Request frame. The AP then
attempts to transmit this frame to the STA indicated by the PeerMACAddress parameter.
6.3.89.3 MLME-GROUP-MEMBERSHIP.confirm
6.3.89.3.1 Function
This primitive reports the result of a request for a STA’s group membership.
6.3.89.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GROUP-MEMBERSHIP.confirm(
GroupAddress,
VendorSpecificInfo
)
Name Type Valid range Description
GroupAddress MAC Address Any valid MAC address that Zero or more MAC
has the Individual/Group addresses that correspond to
Address bit set the contents of the
dot11GroupAddressesTable
of the STA that responded to
the group address request.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
545
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.89.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-GROUP-MEMBERSHIP.request
primitive indicating the results of that request.
This primitive is generated when the STA receives a response in the form of a Group Membership Response
frame in the corresponding robust Action frame from the associated STA.
6.3.89.3.4 Effect of receipt
The SME is notified of the results of the group membership request procedure.
The SME should operate according to the procedures defined in 11.24.16.3.2.
6.3.89.4 MLME-GROUP-MEMBERSHIP.indication
6.3.89.4.1 Function
This primitive indicates that a Group Membership Request frame has been received from a peer entity.
6.3.89.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GROUP-MEMBERSHIP.indication(
PeerMACAddress,
DialogToken,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity from which the
Group Membership Request
frame was sent.
DialogToken Integer 0–255 Specifies a number unique to
the MLME-GROUP-
MEMBERSHIP primitive.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.89.4.3 When generated
This primitive is generated by the MLME when a valid Group Membership Request frame is received.
6.3.89.4.4 Effect of receipt
On receipt of this primitive, the SME performs the behavior defined in 11.24.16.3.2.
6.3.89.5 MLME-GROUP-MEMBERSHIP.response
6.3.89.5.1 Function
This primitive responds to the request for the contents of the group address table by a specified STA’s MAC
entity.
546
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.89.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GROUP-MEMBERSHIP.response(
PeerMACAddress,
DialogToken,
GroupAddress,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity to which the
Group Membership
Response frame is sent.
DialogToken Integer 0–255 Specifies a number unique to
the MLME-GROUP-
MEMBERSHIP primitive.
GroupAddress MAC Address Any valid MAC address Zero or more MAC
that has the Individual/ addresses that correspond to
Group Address bit set the contents of the
dot11GroupAddressesTable
of the STA that is
responding to the group
address request.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.89.5.3 When generated
This primitive is generated by the MLME as a result of an MLME-GROUP-MEMBERSHIP.indication
primitive.
6.3.89.5.4 Effect of receipt
On receipt of this primitive, the SME performs the behavior defined in 11.24.16.3.2.
6.3.90 AP PeerKey management
6.3.90.1 General
The AP PeerKey management primitives support the AP PeerKey protocol to provide session identification
and data confidentiality for an AP-to-AP connection, as described in 12.11.
6.3.90.2 MLME-APPEERKEY.request
6.3.90.2.1 Function
This primitive is used by an AP to transmit a public key to a specified AP and to request the peer’s public
key.
6.3.90.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-APPEERKEY.request(
547
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PeerMACAddress,
RequestType,
Group,
PublicKey,
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity to which the
Public Key frame is sent.
RequestType Integer As defined in Table 9- Specifies the type of request.
321
Group Finite Cyclic Group As defined in 9.4.1.41 Specifies cyclic group from
field which the public key was
generated.
PublicKey Scalar field As defined 9.4.1.40 The public key of the AP
sending this Public Key
frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.90.2.3 When generated
This primitive is generated by the SME at an AP to request the sending of a Public Key frame to another AP
indicated by the PeerMACAddress parameter.
6.3.90.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Public Key frame. The AP then attempts to transmit this
frame to the AP indicated by the PeerMACAddress parameter.
6.3.90.3 MLME-APPEERKEY.indication
6.3.90.3.1 Function
This primitive indicates that a Public Key frame has been received from a peer entity.
6.3.90.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-APPEERKEY.indication(
PeerMACAddress,
RequestType,
Group,
PublicKey,
548
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
VendorSpecificInfo
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the peer
MAC address MAC entity from which the
Public Key frame has been
received.
RequestType Integer As defined in Table 9- Specifies the type of request.
321
Group Finite Cyclic Group 9.4.1.41 Specifies cyclic group from
field which the public key was
generated.
PublicKey Scalar field 9.4.1.40 The public key of the AP
that sent this Public Key
frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.90.3.3 When generated
This primitive is generated by the MLME when a valid Public Key frame is received.
6.3.90.3.4 Effect of receipt
On receipt of this primitive, the SME performs the behavior defined in 12.11.
6.3.91 On-channel Tunneling operation
6.3.91.1 General
On-channel tunneling (OCT) primitives are used as part of multi-band operation (see 11.33). OCT frames
are used to transport Management frames between peer MLME entities of multi-band capable devices.
The operation of the OCT is illustrated in Figure 6-28.
Multi-band capable device Multi-band capable device
SME NT-MLME TR-MLME TR-MLME NT-MLME SME
MLME-
OCTunnel.req
(tunneled MMPDU)
On-channel Tunnel Request
frame MLME-
OCTunnel.ind
(tunneled MMPDU)
Figure 6-28—Operation of OCT
An initiator MLME of a STA that might not be currently enabled to transmit generates an MLME-
OCTunnel.request primitive to a local MLME entity of a STA that is enabled to transmit. This request
carries the contents of a Management frame and replaces transmission over-the-WM of that frame.
549
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The recipient MLME generates the MLME-OCTunnel.indication primitive to the local MLME entity
identified in the On-channel Tunnel Request frame.
The direct MLME-to-MLME primitive exchange should be viewed as shorthand for an exchange through
the SMEs and multi-band entity, i.e., an MLME addresses another local MLME entity by sending that
primitive through its SME and the multi-band entity to the SME of the MLME entity of a STA that is
enabled to transmit, which reflects that primitive to the appropriate recipient.
6.3.91.2 MLME-OCTunnel.request
6.3.91.2.1 Function
This primitive requests transmission of an On-channel Tunnel Request frame.
6.3.91.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-OCTunnel.request(
PeerSTAAddress,
OCT MMPDU,
Multi-band peer
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC Specifies the MAC address of the STA
address to which the On-channel Tunnel
Request frame is transmitted.
OCT MMPDU OCT MMPDU As defined in the On-channel The OCT MMPDU carries the
structure Tunnel Request frame format MMPDU to be tunneled to the specified
(see 9.6.21.7) MLME entity of the specified STA.
Multi-band peer Multi-band As defined in the Multi-band The Multi-band element identifies the
element element format (see 9.4.2.138) peer MLME entity that should receive
the OCT MMPDU.
6.3.91.2.3 When generated
This primitive is generated by another MLME to request that an On-channel Tunnel Request frame be sent
to another STA.
6.3.91.2.4 Effect on receipt
On receipt of this primitive, the MLME constructs and attempts to transmit an On-channel Tunnel Request
frame.
6.3.91.3 MLME-OCTunnel.indication
6.3.91.3.1 Function
This primitive indicates that an On-channel Tunnel Request frame was received.
6.3.91.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-OCTunnel.indication(
550
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PeerSTAAddress,
OCT MMPDU,
Multi-band local
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC Specifies the MAC address of the STA
address from which the On-channel Tunnel
Request frame was received.
OCT MMPDU OCT MMPDU As defined in the On-channel The OCT MMPDU carries the
structure Tunnel Request frame format MMPDU that is being tunneled to the
(see 9.6.21.7) local MLME entity.
Multi-band local Multi-band As defined in the Multi-band The Multi-band element identifies the
element element format (see 9.4.2.138) local MLME entity that should receive
the OCT MMPDU.
6.3.91.3.3 When generated
This primitive is generated by the MLME to notify another MLME when a valid On-channel Tunnel
Request frame is received.
6.3.91.3.4 Effect on receipt
The recipient of this primitive is an MLME entity in a multi-band device.
On receipt of this primitive, the MLME retrieves the tunneled frame and processes it as though it were
received over-the-WM.
6.3.92 Multi-band operation
6.3.92.1 General
This subclause describes the management procedures associated with the multi-band operation mechanism.
6.3.92.2 MLME-FST-SETUP.request
6.3.92.2.1 Function
This primitive requests transmission of an FST Setup Request frame.
6.3.92.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-SETUP.request(
FSTResponderAddress,
FSTSetupRequest
)
551
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
FSTResponderAddress MAC Address Any valid individual Specifies the MAC address of the
MAC address STA to which the FST Setup Request
frame is transmitted.
FSTSetupRequest FST Setup As defined in the FST Specifies the parameters of the FST
Request Action Setup Request frame Setup.
field format
6.3.92.2.3 When generated
This primitive is generated by the SME to request that an FST Setup Request frame be sent to another STA.
6.3.92.2.4 Effect on receipt
On receipt of this primitive, the MLME constructs and attempts to transmit an FST Setup Request frame.
6.3.92.3 MLME-FST-SETUP.indication
6.3.92.3.1 Function
This primitive indicates that an FST Setup Request frame was received.
6.3.92.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-SETUP.indication(
FSTInitiatorAddress,
FSTSetupRequest
)
Name Type Valid range Description
FSTInitiatorAddress MAC Address Any valid individual Specifies the MAC address of the
MAC address STA from which the FST Setup
Request frame was received.
FSTSetupRequest FST Setup Request As defined in FST Setup Specifies the parameters of the FST
Action field Request frame Setup.
6.3.92.3.3 When generated
This primitive is generated by the MLME when a valid FST Setup Request frame is received.
6.3.92.3.4 Effect on receipt
On receipt of this primitive, the SME operates according to the procedure in 11.33.
6.3.92.4 MLME-FST-SETUP.response
6.3.92.4.1 Function
This primitive requests that an FST Setup Response frame be transmitted to the FST initiator STA.
6.3.92.4.2 Semantics of the service primitive
The primitive parameters are as follows:
552
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-FST-SETUP.response(
FSTInitiatorAddress,
FSTSetupResponse
)
Name Type Valid range Description
FSTInitiatorAddress MAC Address Any valid Specifies the MAC address of the STA to
individual MAC which the FST Setup Response frame is
address transmitted.
FSTSetupResponse FST Setup Response As defined in Specifies the parameters of the FST Setup.
Action field FST Setup
Response frame
6.3.92.4.3 When generated
This primitive is generated by the SME to request that an FST Setup Response frame is be transmitted to the
FST initiator STA.
6.3.92.4.4 Effect on receipt
On receipt of this primitive, the MLME constructs and attempts to transmit an FST Setup Response frame.
6.3.92.5 MLME-FST-SETUP.confirm
6.3.92.5.1 Function
This primitive indicates that an FST Setup Response frame was received.
6.3.92.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-SETUP.confirm(
FSTResponderAddress,
FSTSetupResponse
)
Name Type Valid range Description
FSTResponderAddress MAC Address Any valid Specifies the MAC address of the STA from
individual MAC which the FST Setup Response frame was
address received.
FSTSetupResponse FST Setup As defined in Specifies the parameters of the FST Setup.
Response Action FST Setup
field Response frame
6.3.92.5.3 When generated
This primitive is generated by the MLME when a valid FST Setup Response frame is received.
6.3.92.5.4 Effect on receipt
On receipt of this primitive, the SME operates according to the procedure in 11.33.
553
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.92.6 MLME-FST-ACK.request
6.3.92.6.1 Function
This primitive requests transmission of an FST Ack Request frame.
6.3.92.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-ACK.request(
FSTResponderAddress,
FSTAckRequest
)
Name Type Valid range Description
FSTResponderAddress MAC Address Any valid Specifies the MAC address of the STA to
individual MAC which the FST Ack Request frame is
address transmitted.
FSTAckRequest FST Ack Request As defined in Specifies the parameters of the FST Ack
Action field FST Ack Request.
Request frame
6.3.92.6.3 When generated
This primitive is generated by the SME to request that an FST Ack Request frame be sent to another STA.
6.3.92.6.4 Effect on receipt
On receipt of this primitive, the MLME constructs and attempts to transmit an FST Ack Request frame.
6.3.92.7 MLME-FST-ACK.indication
6.3.92.7.1 Function
This primitive indicates that an FST Ack Request frame was received.
6.3.92.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-ACK.indication(
FSTInitiatorAddress,
FSTAckRequest
)
Name Type Valid range Description
FSTInitiatorAddress MAC Address Any valid Specifies the MAC address of the STA from
individual MAC which the FST Ack Request frame was
address received.
FSTAckRequest FST Ack Request As defined in Specifies the parameters of the FST Ack
Action field FST Ack Request.
Request frame
554
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.92.7.3 When generated
This primitive is generated by the MLME when a valid FST Ack Request frame is received.
6.3.92.7.4 Effect on receipt
On receipt of this primitive, the MLME operates according to the procedure in 11.33.
6.3.92.8 MLME-FST-ACK.response
6.3.92.8.1 Function
This primitive requests that an FST Ack Response frame be transmitted to the FST initiator STA.
6.3.92.8.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-ACK.response(
FSTInitiatorAddress,
FSTAckResponse
)
Name Type Valid range Description
FSTInitiatorAddress MAC Address Any valid Specifies the MAC address of the STA to
individual MAC which the FST Ack Response frame is
address transmitted.
FSTAckResponse FST Ack Response As defined in Specifies the parameters of the FST Ack
Action field FST Ack Response.
Response frame
6.3.92.8.3 When generated
This primitive is generated by the SME to request that an FST Ack Response frame be transmitted to the
FST initiator STA.
6.3.92.8.4 Effect on receipt
On receipt of this primitive, the MLME constructs and attempts to transmit an FST Ack Response frame.
6.3.92.9 MLME-FST-ACK.confirm
6.3.92.9.1 Function
This primitive indicates that an FST Ack Response frame was received.
6.3.92.9.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-ACK.confirm(
FSTResponderAddress,
FSTAckResponse
)
555
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
FSTResponderAddress MAC Address Any valid Specifies the MAC address of the STA
individual MAC from which the FST Ack Response
address frame was received.
FSTAckResponse FST Ack Response As defined in FST Specifies the parameters of the FST
Action field Ack Response Ack Response.
frame
6.3.92.9.3 When generated
This primitive is generated by the MLME when a valid FST Ack Response frame is received.
6.3.92.9.4 Effect on receipt
On receipt of this primitive, the MLME operates according to the procedure in 11.33.
6.3.92.10 MLME-FST-TEARDOWN.request
6.3.92.10.1 Function
This primitive requests that an FST Teardown frame be transmitted to the FST initiator STA.
6.3.92.10.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-TEARDOWN.request(
FSTPeerSTAAddress,
FSTTeardown
)
Name Type Valid range Description
FSTPeerSTAAddress MAC Address Any valid individual Specifies the MAC address of the STA to
MAC address which the FST Teardown frame is
transmitted.
FSTTeardown FST Teardown As defined in FST Specifies the parameters of the FST
Action field Teardown frame teardown.
6.3.92.10.3 When generated
This primitive is generated by the SME to request that an FST Teardown frame be transmitted to the FST
peer STA.
6.3.92.10.4 Effect on receipt
On receipt of this primitive, the MLME constructs and attempts to transmit an FST Teardown frame.
6.3.92.11 MLME-FST-TEARDOWN.indication
6.3.92.11.1 Function
This primitive indicates that an FST Teardown frame was received.
556
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.92.11.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-TEARDOWN.indication(
FSTPeerSTAAddress,
FSTAckResponse
)
Name Type Valid range Description
FSTPeerSTAAddress MAC Address Any valid Specifies the MAC address of the STA from
individual MAC which the FST Teardown frame was
address received.
FSTTeardown FST Teardown As defined in FST Specifies the parameters of the FST
Action field Teardown frame teardown.
6.3.92.11.3 When generated
This primitive is generated by the MLME when a valid FST Teardown frame is received.
6.3.92.11.4 Effect on receipt
On receipt of this primitive, the MLME operates according to the procedure in 11.33.
6.3.92.12 MLME-FST-INCOMING.request
6.3.92.12.1 Function
This primitive announces an incoming FST from another band/channel. This primitive does not result in the
transmission of a frame.
6.3.92.12.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-FST-INCOMING.request(
FSTInitiatorAddress,
FSTResponderAddress,
FSTSetupRequest,
FSTSetupResponse,
FSTIsInitiator
)
Name Type Valid range Description
FSTInitiatorAddress MAC Address Any valid individual Specifies the MAC address of the STA
MAC address that is the FST initiator.
FSTResponderAddress MAC Address Any valid individual Specifies the MAC address of the STA
MAC address that is the FST responder.
FSTSetupRequest FST Setup As defined in FST Specifies the parameters of the last FST
Request Action Setup Request frame Setup Request frame exchanged between
field the initiator and responder.
557
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
FSTSetupResponse FST Setup As defined in FST Specifies the parameters of the last FST
Response Action Setup Response Setup Response frame exchanged
field frame between the initiator and responder.
FSTIsInitiator Boolean true, false Indicates the role that the STA performs
in the FST. Set to true if the STA
performs in the role of initiator STA, and
set to false otherwise.
6.3.92.12.3 When generated
This primitive is generated by the SME to announce that an FST session is being transferred from another
band/channel.
6.3.92.12.4 Effect on receipt
On receipt of this primitive, the MLME is notified of an incoming FST session. The MLME does not
transmit a frame as a result of this primitive.
6.3.93 DMG relay operation
6.3.93.1 General
This subclause describes the management procedures associated with DMG relay.
6.3.93.2 MLME-RELAY-SEARCH.request
6.3.93.2.1 Function
This primitive requests a list of relay DMG STAs (RDSs) in the BSS.
6.3.93.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RELAY-SEARCH.request(
DestinationMACAddress
)
Name Type Valid range Description
DestinationMACAddress MACAddress Any valid individual Specifies the MAC address of the non-
MAC address AP and non-PCP STA that is the
intended immediate recipient of the data
flow.
6.3.93.2.3 When generated
This primitive is generated by the SME at a non-AP and non-PCP STA to transmit a request to the PCP/AP
for a list of RDSs in the BSS.
6.3.93.2.4 Effect on receipt
This primitive initiates a relay search procedure. The MLME subsequently issues an MLME-RELAY-
SEARCH.confirm primitive that reflects the results.
558
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.93.3 MLME-RELAY-SEARCH.confirm
6.3.93.3.1 Function
This primitive reports a list of RDSs in the BSS.
6.3.93.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RELAY-SEARCH.confirm(
RelayCapableSTAInfo,
ResultCode
)
Name Type Valid range Description
RelayCapableSTAInfo As defined in frame As defined in As described in 9.4.1.45
(zero or more) format 9.4.1.45
ResultCode Enumeration SUCCESS, Indicates the results of the corresponding
REFUSED MLME-RELAY-SEARCH.request
primitive.
6.3.93.3.3 When generated
This primitive is generated when a valid Relay Search Response frame is received.
6.3.93.3.4 Effect on receipt
The SME is notified of the results of the relay search procedure.
6.3.93.4 MLME-RELAY-SEARCH.indication
6.3.93.4.1 Function
This primitive reports to the SME the request for obtaining a list of RDSs in the BSS.
6.3.93.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RELAY-SEARCH.indication(
SourceMACAddress
)
Name Type Valid range Description
SourceMACAddress MACAddress Any valid individual Specifies the MAC address of the non-AP
MAC address and non-PCP STA that is the intended
immediate recipient of the data flow.
6.3.93.4.3 When generated
This primitive is generated by the MLME as a result of the receipt of a request to obtain a list of RDSs in the
BSS. The receipt of the request resulted from a relay search procedure that was initiated by the STA
indicated by the source MAC address specified in the primitive.
559
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.93.4.4 Effect on receipt
The SME is notified of a request by a specified non-AP and non-PCP STA to obtain a list of RDSs in the
BSS.
6.3.93.5 MLME-RELAY-SEARCH.response
6.3.93.5.1 Function
This primitive is used to provide the results of a Relay Search Request.
6.3.93.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RELAY-SEARCH.response(
PeerMACAddress,
RelayCapableSTAInfo,
StatusCode
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual The address of the MAC entity to which
MAC address the Relay Search Response frame was
sent.
RelayCapableSTAInfo As defined in As defined in 9.4.1.45 As described in 9.4.1.45
(zero or more) frame format
StatusCode As defined in As defined in 9.4.1.9 As described in 9.4.1.9
frame format
6.3.93.5.3 When generated
This primitive is generated by the SME to provide the results of a Relay Search Request.
6.3.93.5.4 Effect on receipt
On receipt of this primitive, the MLME constructs and attempts to transmit a Relay Search Response frame.
6.3.93.6 MLME-RLS.request
6.3.93.6.1 Function
This primitive requests the set up of a relay link with a specified peer MAC entity via a specified relay MAC
entity.
6.3.93.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RLS.request(
DestinationMACAddress,
RelayMACAddress,
DestinationCapabilityInformation,
RelayCapabilityInformation,
RelayTransferParameterSet
)
560
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DestinationMACAddress MACAddress Any valid Specifies the MAC address of the
individual non-AP and non-PCP STA that is the
MAC address intended immediate recipient of the
data flow.
RelayMACAddress MACAddress Any valid Specifies the MAC address of the
individual selected RDS.
MAC address
DestinationCapabilityInformation As defined in As defined in Indicates the Relay Capability
frame format frame format Information field within the Relay
Capabilities element of the target
destination relay endpoint DMG STA
(REDS).
RelayCapabilityInformation As defined in As defined in Indicates the Relay Capability
frame format frame format Information field within the Relay
Capabilities element of the selected
RDS.
RelayTransferParameterSet As defined in As defined in Specifies the parameters for the relay
frame format frame format operation.
6.3.93.6.3 When generated
This primitive is generated by the SME at a non-AP and non-PCP STA to set up a relay link with another
non-AP and non-PCP STA.
6.3.93.6.4 Effect on receipt
This primitive initiates a relay link setup procedure.
6.3.93.7 MLME-RLS.confirm
6.3.93.7.1 Function
This primitive reports the results of a relay link setup attempt with a specified peer MAC entity.
6.3.93.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RLS.confirm(
PeerMACAddress,
RelayMACAddress,
ResultCode
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the non-
MAC address AP and non-PCP STA from which the
frame was received.
RelayMACAddress MACAddress Any valid individual Specifies the MAC address of the
MAC address selected RDS
ResultCode Enumeration SUCCESS, REFUSED Indicates the results of the corresponding
MLME-RLS.request primitive.
561
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.93.7.3 When generated
This primitive is generated when a valid RLS Response frame is received.
6.3.93.7.4 Effect on receipt
The SME is notified of the results of the relay link setup procedure.
6.3.93.8 MLME-RLS.indication
6.3.93.8.1 Function
This primitive reports the establishment of a relay link with a specified peer MAC entity.
6.3.93.8.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RLS.indication(
SourceMACAddress,
RelayMACAddress,
SourceCapabilityInformation,
RelayCapabilityInformation,
RelayTransferParameterSet
)
Name Type Valid range Description
SourceMACAddress MACAddress Any valid Specifies the MAC address of the STA
individual that is the intended immediate recipient
MAC address of the data flow.
RelayMACAddress MACAddress Any valid Specifies the MAC address of the
individual selected RDS
MAC address
SourceCapabilityInformation As defined in As defined in Specifies the operational capability
frame format frame format definitions to be used by the peer MAC
entity.
RelayCapabilityInformation As defined in As defined in Indicates the Relay Capability
frame format frame format Information field within the Relay
Capabilities element of the selected RDS
RelayTransferParameterSet As defined in As defined in Specifies the parameters for the relay
frame format frame format operation
6.3.93.8.3 When generated
This primitive is generated by the MLME as a result of the establishment of a relay link with a specific peer
MAC entity, and that resulted from a relay link setup procedure that was initiated by that specific source
MAC entity.
6.3.93.8.4 Effect on receipt
The SME is notified of the establishment of the relay link setup.
562
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.93.9 MLME-RLS.response
6.3.93.9.1 Function
This primitive is used to provide the results of an RLS Request.
6.3.93.9.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RLS.response(
PeerMACAddress,
DestinationStatusCode,
RelayStatusCode
)
Name Type Valid range Description
PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the peer
MAC address STA.
DestinationStatusCode As defined in As defined in 9.4.1.9 As described in 9.4.1.9
frame format
RelayStatusCode As defined in As defined in 9.4.1.9 As described in 9.4.1.9
frame format
6.3.93.9.3 When generated
This primitive is generated by the SME to provide the results of a RLS Request.
6.3.93.9.4 Effect on receipt
On receipt of this primitive, the MLME constructs and attempts to transmit an RLS Response frame.
6.3.93.10 MLME-RLS-TEARDOWN.request
6.3.93.10.1 Function
This primitive requests the teardown of the relay link with a specified peer MAC entity.
6.3.93.10.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RLS-TEARDOWN.request(
DestinationMACAddress,
RelayMACAddress,
Reason
)
Name Type Valid range Description
DestinationMACAddress MACAddress Any valid individual Specifies the MAC address of the non-
MAC address AP and non-PCP STA that is the
intended immediate recipient of the data
flow.
RelayMACAddress MACAddress Any valid individual Specifies the MAC address of the
MAC address selected RDS.
Reason Enumeration REQUESTED Indicates the reason why the relay link is
being torn down.
563
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.93.10.3 When generated
This primitive is generated by the SME for tearing down a relay link with another non-AP and non-PCP
STA.
6.3.93.10.4 Effect on receipt
This primitive initiates a relay link teardown procedure. The MLME subsequently issues an MLME-RLS-
TEARDOWN.confirm primitive that reflects the results.
6.3.93.11 MLME-RLS-TEARDOWN.indication
6.3.93.11.1 Function
This primitive indicates the teardown of an already established relay link with a specific peer MAC entity.
6.3.93.11.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-RLS-TEARDOWN.indication(
SourceMACAddress,
Reason
)
Name Type Valid range Description
SourceMACAddress MACAddress Any valid individual Specifies the MAC address of the non-
MAC address AP and non-PCP STA that is the
intended immediate recipient of the data
flow.
Reason Enumeration REQUESTED Indicates the reason why the relay link is
being torn down.
6.3.93.11.3 When generated
This primitive is generated by the MLME as result of the teardown of a relay link with a specific peer MAC
entity, and that resulted from a relay link teardown procedure that was initiated either by that specific peer
MAC entity or by the local MAC entity.
6.3.93.11.4 Effect on receipt
The SME is notified of the relay link teardown.
6.3.94 Quieting adjacent BSS operation
6.3.94.1 General
This subclause describes the management procedure associated with the QAB operation.
The primitives defined are MLME-QAB.request, MLME-QAB.confirm, MLME-QAB.indication, and
MLME-QAB.response primitive.
564
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.94.2 MLME-QAB.request
6.3.94.2.1 Function
This primitive requests transmission of a (protected) QAB Request frame.
6.3.94.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QAB.request(
DialogToken,
RequesterAP Address,
ResponderAP Address,
QuietPeriodRequest,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
DialogToken Integer 1–255 The dialog token to identify the QAB
transaction.
RequesterAP Address MACAddress Any valid The address of the MAC entity from
individual MAC which the (protected) QAB Request
address frame was sent.
ResponderAP Address MACAddress Any valid The address of the peer MAC entity to
individual MAC which the (protected) QAB request was
address sent.
QuietPeriodRequest A set of information As described in As described in 9.4.2.150.
subfields 9.4.2.150
Protected Boolean true, false Specifies whether the request is sent
using a robust Management frame.
If true, the request is sent using the
Protected QAB Request frame.
If false, the request is sent using the
QAB Request frame.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.94.2.3 When generated
This primitive is generated by the STA management entity (SME) to request that a (Protected) QAB frame
be sent by a STA.
6.3.94.2.4 Effect on receipt
On receipt of this primitive, the MLME constructs and transmits a (Protected) QAB Request frame.
6.3.94.3 MLME-QAB.confirm
6.3.94.3.1 Function
This primitive reports the result of a transmission of a QAB Request frame.
565
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.94.3.2 Semantics of the service primitive
The primitive parameters as follows:
MLME-QAB.confirm(
DialogToken,
RequesterAP Address,
ResponderAP Address,
QuietPeriodResponse,
ResultCode,
VendorSpecificInfo
)
Name Type Valid range Description
DialogToken Integer 1–255 The dialog token to identify the
QAB transaction.
RequesterAP Address MACAddress Any valid individual The address of the MAC entity to
MAC address which the (protected) QAB
Response frame was addressed.
ResponderAP Address MACAddress Any valid individual The address of the peer MAC entity
MAC address from which the (protected) QAB
Response was received.
QuietPeriodResponse A set of information As described in As described in 9.4.2.151.
subfields 9.4.2.151
ResultCode Enumeration SUCCESS Reports the result of an QAB
request.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.94.3.3 When generated
This primitive is generated by the MLME when a QAB request completes. Possible unspecified failure
causes include an inability to provide the Quiet Period Request element.
6.3.94.3.4 Effect on receipt
The SME is notified of the results of the QAB request procedure.
6.3.94.4 MLME-QAB.indication
6.3.94.4.1 Function
This primitive indicates that a (Protected) QAB Request frame was received.
6.3.94.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QAB.indication(
DialogToken
PeerMACAddress,
QuietPeriodRequest,
Protected,
VendorSpecificInfo
)
566
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
DialogToken Integer 1–255 The dialog token to identify the QAB
transaction.
PeerMACAddress MACAddress Any valid The address of the peer MAC entity from
individual MAC which the QAB Request frame was
address received.
QuietPeriodRequest A set of information As described in As described in 9.4.2.150.
subfields 9.4.2.150
Protected Boolean true, false Specifies whether the request was
received using a robust Management
frame.
If true, the request was received using
the Protected QAB Request frame.
If false, the request was received using
the QAB Request frame.
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.94.4.3 When generated
This primitive is generated by the MLME when a valid (Protected) QAB Request frame is received.
6.3.94.4.4 Effect on receipt
On receipt of this primitive, the SME decides whether to schedule quiet periods as requested.
6.3.94.5 MLME-QAB.response
6.3.94.5.1 Function
This primitive is used to provide the results of a QAB Request.
6.3.94.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-QAB.response(
DialogToken,
RequesterAP Address,
ResponderAP Address,
QuietPeriodResponse,
VendorSpecificInfo
)
Name Type Valid range Description
DialogToken Integer 1–255 The dialog token to identify the QAB
transaction.
RequesterAP Address MACAddress Any valid individual The address of the MAC entity to
MAC address which the (protected) QAB Response
frame was sent.
ResponderAP Address MACAddress Any valid individual The address of the peer MAC entity
MAC address from which the (protected) QAB
Response was sent.
567
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
QuietPeriodResponse A set of information As described in As described in 9.4.2.151.
subfields 9.4.2.151
VendorSpecificInfo A set of elements As defined in Zero or more elements.
9.4.2.26
6.3.94.5.3 When generated
This primitive is generated by the SME to provide the results of a QAB Request.
6.3.94.5.4 Effect on receipt
On receipt of this primitive, the MLME provides the results of a QAB Request.
6.3.95 DMG beamforming
6.3.95.1 General
This subclause describes the management procedures associated with DMG beamforming.
6.3.95.2 MLME-BF-TRAINING.request
6.3.95.2.1 Function
This primitive requests that beamforming training occur with a peer STA.
6.3.95.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BF-TRAINING.request(
PeerSTAAddress,
RequestBRP
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer
MAC address MAC entity with which to perform
beamforming training.
RequestBRP Boolean true, false If true, the beam refinement protocol
(BRP) is performed as part of the
beamforming training.
If false, only sector-level sweep
(SLS) is performed.
6.3.95.2.3 When generated
This primitive is generated by the SME to request that beamforming training be performed with a peer STA.
6.3.95.2.4 Effect on receipt
On receipt of this primitive, the MLME invokes the MAC sublayer beamforming training procedures
defined in 10.38.
568
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.95.3 MLME-BF-TRAINING.confirm
6.3.95.3.1 Function
This primitive reports the outcome of a requested beamforming training procedure.
6.3.95.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BF-TRAINING.confirm(
PeerSTAAddress,
ResultCode
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer
MAC address MAC entity with which
beamforming training was performed
or attempted.
ResultCode Enumeration SUCCESS, BF- Indicates the result of the
TIMEOUT beamforming procedure.
6.3.95.3.3 When generated
This primitive is generated by the MLME to report the result of beamforming training with a peer STA.
6.3.95.3.4 Effect on receipt
The SME is notified of the result of the procedure.
6.3.95.4 MLME-BF-TRAINING.indication
6.3.95.4.1 Function
This primitive indicates that beamforming training with a peer STA, and at the request of that peer, has
completed.
6.3.95.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-BF-TRAINING.indication(
PeerSTAAddress,
ResultCode
)
Name Type Valid range Description
PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer
MAC address MAC entity with which
beamforming training was
performed.
ResultCode Enumeration SUCCESS, BF- Indicates the result of the
TIMEOUT beamforming procedure.
569
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.95.4.3 When generated
This primitive is generated by the MLME to indicate successful completion of a beamforming training
procedure requested by a peer STA.
6.3.95.4.4 Effect on receipt
The SME is notified of the result of the procedure.
6.3.96 PN event report
6.3.96.1 General
This subclause describes the management procedures associated with PN event report.
6.3.96.2 MLME-PN-EXHAUSTION.indication
6.3.96.2.1 Function
This primitive indicates that the PN associated with a temporal key exceeds the threshold that is defined in
dot11PNExhaustionThresholdLow and dot11PNExhaustionThresholdHigh.
6.3.96.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-PN-EXHAUSTION.indication(
Key ID,
Key Type,
Address
)
Name Type Valid range Description
Key ID Integer N/A Key identifier.
Key Type Integer Group, Pairwise, Defines whether this key is a group key, pairwise
PeerKey, IGTK key, PeerKey, or Integrity Group key.
Address MAC address Any valid individual This parameter is valid only when the Key Type
MAC address value is Pairwise, or when the Key Type value is
Group and is from an IBSS STA, or when the Key
Type value is PeerKey.
6.3.96.2.3 When generated
This primitive is generated by the MLME when the PN associated with a temporal key exceeds the threshold
that is defined in dot11PNExhaustionThresholdLow and dot11PNExhaustionThresholdHigh.
6.3.96.2.4 Effect of receipt
On receipt of this primitive, the SME deletes the temporal key associated with the PN.
570
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.96.3 MLME-PN-WARNING.indication
6.3.96.3.1 Function
This primitive indicates that the PN associated with a temporal key exceeds the threshold that is defined in
dot11PNWarningThresholdLow and dot11PNWarningThresholdHigh.
6.3.96.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-PN-WARNING.indication(
Key ID,
Key Type,
Address
)
Name Type Valid range Description
Key ID Integer N/A Key identifier.
Key Type Integer Group, Pairwise, Defines whether this key is a group key,
PeerKey, IGTK pairwise key, PeerKey, or Integrity Group
key
Address MAC address Any valid This parameter is valid only when the Key
individual MAC Type value is Pairwise, or when the Key
address Type value is Group and is from an IBSS
STA, or when the Key Type value is
PeerKey.
6.3.96.3.3 When generated
This primitive is generated by the MLME when the PN associated with a temporal key exceeds the threshold
that is defined in dot11PNWarningThresholdLow and dot11PNWarningThresholdHigh.
6.3.96.3.4 Effect of receipt
On receipt of this primitive, the SME can create a new temporal key before the PN space is exhausted.
6.3.97 Channel Availability Query
6.3.97.1 Introduction
The following MLME primitives support the signaling of channel availability query process for the channel
query requests and responses.
6.3.97.2 MLME-CHANNELAVAILABILITYQUERY.request
6.3.97.2.1 Function
This primitive requests that a (Protected) Channel Availability Query frame be sent to a specified peer MAC
entity.
6.3.97.2.2 Semantics of the service primitive
The primitive parameters are as follows:
571
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-CHANNELAVAILABILITYQUERY.request (
PeerSTAAddress,
ChannelAvailabilityQuery,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual The address of the peer MAC entity
MAC address to which the Channel Availability
Query frame is sent.
ChannelAvailabilityQ A set of As defined in 9.6.8.25 Specifies the parameters of channel
uery information query.
subfields
Protected Boolean true, false Specifies whether the request is sent
using a robust Management frame.
If true, the request is sent using the
Protected Channel Availability
Query frame.
If false, the request is sent using the
Channel Availability Query frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.97.2.3 When generated
This primitive is generated by the SME to request channel query procedure with a specified peer MAC
entity.
6.3.97.2.4 Effect of receipt
This primitive initiates a channel query procedure. The MLME subsequently issues a MLME-
CHANNELAVAILABILITYQUERY.confirm primitive that reflects the results.
6.3.97.3 MLME-CHANNELAVAILABILITYQUERY.confirm
6.3.97.3.1 Function
This primitive reports the results of a channel query attempt with a specified peer MAC entity.
6.3.97.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELAVAILABILITYQUERY.confirm (
PeerSTAAddress,
ResultCode,
ChannelAvailabilityQuery,
Protected,
VendorSpecificInfo
)
572
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual The address of the peer MAC entity
MAC address from which the response to the Channel
Availability Query frame was received.
ResultCode Enumeration SUCCESS, Indicates the result of MLME-
SUCCESS_MULTIPL CHANNELAVAILABILITYQUERY.r
E, REFUSED, equest primitive.
DEVICE_VERIFICAT
ION_FAILURE
ChannelAvailabilityQ A set of As defined in 9.6.8.25 Specifies the parameters of channel
uery information fields query.
Protected Boolean true, false Specifies whether the response was
received using a robust Management
frame.
If true, the response was received using
the Protected Channel Availability
Query frame.
If false, the response was received
using the Channel Availability Query
frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.97.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-
CHANNELAVAILABILITYQUERY.request primitive and indicates the results of a channel availability
query procedure.
6.3.97.3.4 Effect of receipt
The SME is notified of the results of the channel query procedure.
6.3.97.4 MLME-CHANNELAVAILABILITYQUERY.indication
6.3.97.4.1 Function
This primitive indicates that a (Protected) Channel Availability Query frame was received from a peer STA.
6.3.97.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELAVAILABILITYQUERY.indication (
PeerSTAAddress,
ChannelAvailabilityQuery,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual The address of the peer MAC entity
MAC address from which the Channel Availability
Query frame was received.
ChannelAvailabilityQ A set of information As defined in 9.6.8.25 Specifies the parameters of channel
uery subfields query.
573
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Protected Boolean true, false Specifies whether the request was
received using a robust Management
frame.
If true, the request was received using
the Protected Channel Availability
Query frame.
If false, the request was received using
the Channel Availability Query frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.97.4.3 When generated
This primitive is generated by the MLME as a result of the receipt of a channel query request from a specific
peer MAC entity.
6.3.97.4.4 Effect of receipt
The SME is notified of the receipt of this channel query request.
6.3.97.5 MLME-CHANNELAVAILABILITYQUERY.response
6.3.97.5.1 Function
This primitive is used to send a response to a specified peer MAC entity that requested channel query with
the STA that issued this primitive.
6.3.97.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELAVAILABILITYQUERY.response (
PeerSTAAddress,
ResultCode,
ChannelAvailabilityQuery,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual The address of the peer MAC entity to
MAC address which the Channel Availability Query
frame with the response is sent.
ResultCode Enumeration SUCCESS, Indicates the result response of the
SUCCESS_MULTIP channel availability query from the peer
LE, REFUSED, MAC entity.
DEVICE_VERIFICA
TION_FAILURE
ChannelAvailability A set of information As defined in 9.6.8.25 Specifies the parameters of channel
Query subfields query.
574
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
Protected Boolean true, false Specifies whether the response is sent
using a robust Management frame.
If true, the response is sent using the
Protected Channel Availability Query
frame.
If false, the response is sent using the
Channel Availability Query frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.97.5.3 When generated
This primitive is generated by the SME of a STA as a response to an MLME-
CHANNELAVAILABILITYQUERY.indication primitive.
6.3.97.5.4 Effect of receipt
Upon receipt of this primitive, the MLME constructs the Channel Availability Query frame as the response.
This frame is then scheduled for transmission to the peer MAC address.
6.3.98 Channel schedule management
6.3.98.1 Introduction
The following MLME primitives support the signaling of channel schedule management.
6.3.98.2 MLME-CHANNELSCHEDULEMANAGEMENT.request
6.3.98.2.1 Function
This primitive requests that a (Protected) Channel Schedule Management frame be sent.
6.3.98.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELSCHEDULEMANAGEMENT.request (
PeerSTAAddress,
ReasonResultCode,
ChannelScheduleManagementMode,
DeviceIdentification,
ChannelSchedule,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity to
MAC address which the Channel Schedule
Management frame is sent.
ReasonResultCode An enumerated As defined in 9.6.8.26
value for the Reason Result
Code field
575
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ChannelScheduleMa An enumerated As defined in 9.6.8.26
nagementMode value for the Channel
Schedule Management
Mode field
DeviceIdentification Device As defined in 9.4.4.2.2 The Device Identification Information
Identification parameter indicates the regulatory
Information identification of the STA that is
requesting the schedule information.
ChannelSchedule A set of Channel As defined in 9.4.4.2.4 The Channel Schedule parameter
Schedule indicates the channels for which the
Descriptors schedule information is requested.
Protected Boolean true, false Specifies whether the request is sent
using a robust Management frame.
If true, the request is sent using the
Protected Channel Schedule
Management frame.
If false, the request is sent using the
Channel Schedule Management frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.98.2.3 When generated
This primitive is generated by the SME to request that a (Protected) Channel Schedule Management frame
be sent by a STA.
6.3.98.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs and schedules transmission of a (Protected) Channel
Schedule Management frame.
6.3.98.3 MLME-CHANNELSCHEDULEMANAGEMENT.confirm
6.3.98.3.1 Function
This primitive reports the result of a channel schedule management query.
6.3.98.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELSCHEDULEMANAGEMENT.confirm (
PeerSTAAddress,
ReasonResultCode,
ChannelScheduleManagementMode,
DeviceIdentification,
ChannelSchedule,
Protected,
VendorSpecificInfo
)
576
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity from
MAC address which the Channel Schedule Management
frame was received.
ReasonResultCode An enumerated As defined in 9.6.8.26
value for the Reason Result
Code field
ChannelScheduleMa An enumerated As defined in 9.6.8.26
nagementMode value for the Channel
Schedule Management
Mode field
DeviceIdentification Device As defined in 9.4.4.2.2 The Device Identification Information
Identification parameter indicates the regulatory
Information identification of the STA that is requesting
the schedule information.
ChannelSchedule A set of Channel As defined in 9.4.4.2.4 The Channel Schedule parameter indicates
Schedule the channels for which the schedule
Descriptors information is provided.
Protected Boolean true, false Specifies whether the response is sent
using a robust Management frame. If true,
the response is sent using the Protected
Channel Schedule Management frame. If
false, the response is sent using the
Channel Schedule Management Public
Action frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.98.3.3 When generated
This primitive is generated by the MLME when a channel schedule request completes. Possible unspecified
failure causes include an inability to provide the channel schedule information.
6.3.98.3.4 Effect of receipt
The SME is notified of the results of the channel schedule management procedure.
6.3.98.4 MLME-CHANNELSCHEDULEMANAGEMENT.indication
6.3.98.4.1 Function
This primitive indicates that a (Protected) Channel Schedule Management frame was received from a peer
STA.
6.3.98.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELSCHEDULEMANAGEMENT.indication (
PeerSTAAddress,
ReasonResultCode,
ChannelScheduleManagementMode,
DeviceIdentification,
ChannelSchedule,
Protected,
VendorSpecificInfo
)
577
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity from
MAC address which the Channel Schedule Management
frame was received.
ReasonResultCode An enumerated As defined in 9.6.8.26
value for the Reason Result
Code field
ChannelScheduleMa An enumerated As defined in 9.6.8.26
nagementMode value for the Channel
Schedule Management
Mode field
DeviceIdentification Device As defined in 9.4.4.2.2 The Device Identification Information
Identification parameter indicates the regulatory
Information identification of the STA that is requesting
the schedule information.
ChannelSchedule A set of Channel As defined in 9.4.4.2.4 The Channel Schedule parameter indicates
Schedule the channels for which the schedule
Descriptors information is requested.
Protected Boolean true, false Specifies whether the request was received
using a robust Management frame.
If true, the request was received using the
Protected Channel Schedule Management
frame.
If false, the request was received using the
Channel Schedule Management frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.98.4.3 When generated
This primitive is generated by the MLME when a valid (Protected) Channel Schedule Management frame is
received.
6.3.98.4.4 Effect of receipt
On receipt of this primitive, the SME decides whether to provide the channel schedule information.
6.3.98.5 MLME-CHANNELSCHEDULEMANAGEMENT.response
6.3.98.5.1 Function
This primitive is used to provide channel schedule information on channel availability.
6.3.98.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CHANNELSCHEDULEMANAGEMENT.response (
PeerSTAAddress,
ReasonResultCode,
ChannelScheduleManagementMode,
DeviceIdentification,
ChannelSchedule,
Protected,
VendorSpecificInfo
)
578
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity to
MAC address which the Channel Schedule
Management frame is sent.
ReasonResultCode An enumerated As defined in 9.6.8.26
value for the Reason Result
Code field
ChannelScheduleMa An enumerated As defined in 9.6.8.26
nagementMode value for the Channel
Schedule
Management Mode
field
DeviceIdentification Device As defined in The Device Identification Information
Identification 9.4.4.2.2 parameter indicates the regulatory
Information identification of the STA that is
requesting the schedule information.
ChannelSchedule A set of Channel As defined in The Channel Schedule parameter
Schedule 9.4.4.2.4 indicates the channels for which the
Descriptors schedule information is provided.
Protected Boolean true, false Specifies whether the response is sent
using a robust Management frame. If true,
the response is sent using the Protected
Channel Schedule Management Public
Action frame. If false, the response is sent
using the Channel Schedule Management
Public Action frame.
VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements.
6.3.98.5.3 When generated
This primitive is generated by the SME to provide the channel schedule information.
6.3.98.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs an appropriate response in a (Protected) Channel
Schedule Management frame and schedules the transmission of the frame to the peer MAC entity.
6.3.99 Contact verification signal
6.3.99.1 Introduction
The following MLME primitives support the signaling of the contact verification signal (CVS).
6.3.99.2 MLME-CVS.request
6.3.99.2.1 Function
This primitive requests that a Contact Verification Signal frame be sent by a STA to a specified peer MAC
entity in order to validate a WSM.
6.3.99.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CVS.request (
PeerSTAAddress,
Protected,
ContactVerificationSignal
)
579
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC
individual MAC entity with which to perform the
Address contact verification signal process.
Protected Boolean true, false Specifies whether the request is sent
using a robust Management frame.
If true, the request is sent using the
Protected Contact Verification Signal
frame.
If false, the request is sent using the
Contact Verification Signal frame.
ContactVerificationSignal Contact Verification As defined in Specifies the service parameters for
Signal element 9.6.8.27 the Contact Verification Signal frame.
6.3.99.2.3 When generated
This primitive is generated by the SME to request that a Protected Contact Verification Signal frame be sent
by a STA to a specified peer MAC entity.
6.3.99.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a Protected Contact Verification Signal frame. This frame
is then scheduled for transmission.
6.3.99.3 MLME-CVS.indication
6.3.99.3.1 Function
This primitive indicates that a Contact Verification Signal frame was received from a specific peer MAC
entity.
6.3.99.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-CVS.indication (
PeerSTAAddress,
Protected,
ContactVerificationSignal
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid The address of the peer MAC entity
individual MAC from which a Contact Verification
Address Signal frame was received.
Protected Boolean true, false Specifies whether the request is sent
using a robust Management frame.
If true, the request is sent using the
Protected Contact Verification
Signal frame.
If false, the request is sent using the
Contact Verification Signal frame.
ContactVerificationSignal Contact Verification As defined in Specifies the service parameters for
Signal element 9.6.8.27 the Contact Verification Signal
frame.
580
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.99.3.3 When generated
This primitive is generated by the MLME when a valid Protected Contact Verification Signal frame is
received.
6.3.99.3.4 Effect of receipt
On receipt of this primitive, the SME is notified of the receipt of the Contact Verification Signal frame.
6.3.100 GDD Enablement
6.3.100.1 Introduction
The following MLME primitives support the signaling of GDD enablement.
6.3.100.2 MLME-GDDENABLEMENT.request
6.3.100.2.1 Function
This primitive requests that a (Protected) GDD Enablement Request frame be sent to a peer entity.
6.3.100.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GDDENABLEMENT.request (
PeerSTAAddress,
DialogToken,
Protected,
DeviceClass,
DeviceID
)
Name Type Valid range Description
PeerSTAAddress MAC address Any individual valid Specifies the address of the peer MAC
MAC address entity with which to perform the GDD
enablement process.
DialogToken Integer 1–255 The dialog token to identify the event
transaction.
Protected Boolean true, false Specifies whether the request is sent
using a robust Management frame.
If true, the request is sent using the
Protected GDD Enablement Request
frame.
If false, the request is sent using the
GDD Enablement Request frame.
DeviceClass DeviceClass As defined in 9.4.4.2.1 Specifies the service parameters for the
GDD Enablement Request frame.
DeviceID Device As defined in 9.4.4.2.2 Specifies the service parameters for the
Identification GDD Enablement Request frame.
Information
6.3.100.2.3 When generated
This primitive is generated by the SME to request that a (Protected) GDD Enablement Request frame be sent
to the peer entity.
581
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.100.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a (Protected) GDD Enablement Request frame. This
frame is then scheduled for transmission.
6.3.100.3 MLME-GDDENABLEMENT.confirm
6.3.100.3.1 Function
This primitive reports the result of an MLME-GDDENABLEMENT.request primitive to initiate GDD
enablement.
6.3.100.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GDDENABLEMENT.confirm (
PeerSTAAddress,
DialogToken,
Protected,
ResultCode,
WSM
)
Name Type Valid range Description
PeerSTAAddress MAC address Any individual valid MAC Specifies the address of the peer MAC
address entity with which to perform the GDD
enablement process.
DialogToken Integer 1–255 The dialog token to identify the event
transaction.
Protected Boolean true, false Specifies whether the response is sent using
a robust Management frame.
If true, the response is sent using the
Protected GDD Enablement Response
frame.
If false, the response is sent using the GDD
Enablement Response frame.
ResultCode Enumeration SUCCESS, REFUSED, Indicates the result response to the GDD
ENABLEMENT DENIED, Enablement Request frame from the peer
ENABLEMENT Denied due entity.
to restriction from GDB
WSM WSM element As defined in 9.4.1.57 Specifies the service parameters for the
white space map.
6.3.100.3.3 When generated
This primitive is generated by the MLME as a result of an MLME-GDDENABLEMENT.request primitive
and indicates the results of the request.
This primitive is generated when the STA successfully receives a GDD Enablement Response frame from
the peer entity or when an unspecified failure occurs.
6.3.100.3.4 Effect of receipt
On receipt of this primitive, the SME evaluates the results of the MLME-GDDENABLEMENT.request
primitive and may use the reported data.
582
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.100.4 MLME-GDDENABLEMENT.indication
6.3.100.4.1 Function
This primitive indicates that a (Protected) GDD Enablement Request frame was received from a peer entity.
6.3.100.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GDDENABLEMENT.indication (
PeerSTAAddress,
DialogToken,
Protected,
DeviceClass,
DeviceID
)
Name Type Valid range Description
PeerSTAAddress MAC address Any individual valid The address of the peer entity from which a
MAC address GDD Enablement Request frame was
received.
DialogToken Integer 1–255 The dialog token to identify the event
transaction.
Protected Boolean true, false Specifies whether the request is sent using
a robust Management frame.
If true, the request is sent using the
Protected GDD Enablement Request frame.
If false, the request is sent using the GDD
Enablement Request frame.
DeviceClass DeviceClass As defined in 9.4.4.2.1 Specifies the service parameters for the
GDD Enablement Request frame.
DeviceID Device As defined in 9.4.4.2.2 Specifies the service parameters for the
Identification GDD Enablement Request frame.
Information
6.3.100.4.3 When generated
This primitive is generated by the MLME when a valid (Protected) GDD Enablement Request frame is
received.
6.3.100.4.4 Effect of receipt
On receipt of this primitive, the SME operates according to the procedure in 11.44.1.
6.3.100.5 MLME-GDDENABLEMENT.response
6.3.100.5.1 Function
This primitive indicates that a (Protected) GDD Enablement Response frame be sent to the peer entity.
6.3.100.5.2 Semantics of the service primitive
MLME-GDDENABLEMENT.response (
PeerSTAAddress,
DialogToken,
583
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Protected,
ResultCode,
WSM
)
Name Type Valid range Description
PeerSTAAddress MAC address Any individual valid MAC The address of the peer entity from which a
address GDD Enablement Request frame was
received.
DialogToken Integer 1–255 The dialog token to identify the event
transaction.
Protected Boolean true, false Specifies whether the response is sent
using a robust Management frame.
If true, the response is sent using the
Protected GDD Enablement Response
frame.
If false, the response is sent using the GDD
Enablement Response frame.
ResultCode Enumeration SUCCESS, REFUSED, Indicates the result response to the GDD
ENABLEMENT DENIED, Enablement Request frame from the peer
ENABLEMENT Denied due entity.
to restriction from GDB
WSM WSM element As defined in 9.4.1.57 Specifies the service parameters for the
white space map.
6.3.100.5.3 When generated
This primitive is generated by the SME to request that a GDD Enablement Response frame be sent to the
peer entity.
6.3.100.5.4 Effect of receipt
On receipt of this primitive, the MLME constructs a GDD Enablement Response frame. This frame is then
scheduled for transmission.
6.3.101 Network channel control management
6.3.101.1 Introduction
The following MLME primitives support the signaling of network channel control management.
6.3.101.2 MLME-NETWORKCHANNELCONTROL.request
6.3.101.2.1 Function
This primitive requests that a (Protected) Network Channel Control Public Action frame be sent by a STA to
a specified peer MAC entity.
6.3.101.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-NETWORKCHANNELCONTROL.request (
PeerSTAAddress,
DialogToken,
NetworkChannelControl,
584
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual or The address of the peer MAC
group MAC Address entity to which the Network
Channel Control frame is
transmitted.
DialogToken Integer 0–255 The dialog token to identify the
network channel control
transaction.
NetworkChannelCon A set of information As defined in 9.6.8.30 Specifies the parameters of
trol subfields network channel control.
Protected Boolean true, false Specifies whether the request is
sent using a robust Management
frame.
If true, the request is sent using the
Protected Network Channel
Control frame.
If false, the request is sent using
the Network Channel Control
frame.
VendorSpecificInfo A set of vendor As defined in 9.4.2.26 Zero or more elements.
specific elements
6.3.101.2.3 When generated
This primitive is generated by the SME to request that a (Protected) Network Channel Control Public Action
frame be sent by a STA to the specified peer MAC entity.
6.3.101.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a (Protected) Network Channel Control Public Action
frame. This frame is then scheduled for transmission.
6.3.101.3 MLME-NETWORKCHANNELCONTROL.confirm
6.3.101.3.1 Function
This primitive reports the result of a request to network channel control.
6.3.101.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-NETWORKCHANNELCONTROL.confirm (
PeerSTAAddress,
DialogToken,
NetworkChannelControl,
Protected,
VendorSpecificInfo
)
585
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC The address of the peer MAC entity
address from which the response in a
Network Channel Control frame is
received.
DialogToken Integer 0–255 The dialog token to identify the
network channel control transaction.
NetworkChannelC A set of As defined in 9.6.8.30 Specifies the parameters of network
ontrol information channel control.
subfields
Protected Boolean true, false Specifies whether the response is
sent using a robust Management
frame. If true, the response is sent
using the Protected Network
Channel Control Public Action
frame. If false, the response is sent
using the Network Channel Control
Public Action frame.
VendorSpecificInfo A set of vendor As defined in 9.4.2.26 Zero or more elements.
specific elements
6.3.101.3.3 When generated
This primitive is generated by the MLME when a network channel control request completes. Possible
unspecified failure causes include an inability to schedule a Network Channel Control Public Action frame.
6.3.101.3.4 Effect of receipt
The SME is notified of the results of the network channel control procedure.
6.3.101.4 MLME-NETWORKCHANNELCONTROL.indication
6.3.101.4.1 Function
This primitive indicates that a (Protected) Network Channel Control Public Action frame was received from
a STA.
6.3.101.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-NETWORKCHANNELCONTROL.indication (
PeerSTAAddress,
DialogToken,
NetworkChannelControl,
Protected,
VendorSpecificInfo
)
586
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity from
MAC address which the Network Channel Control frame
was received.
DialogToken Integer 0–255 The dialog token to identify the network
channel control transaction.
NetworkChannelC A set of As defined in 9.6.8.30 Specifies the parameters of network channel
ontrol information control.
subfields
Protected Boolean true, false Specifies whether the request was received
using a robust Management frame.
If true, the request was received using the
Protected Network Channel Control Public
Action frame.
If false, the request was received using the
Network Channel Control Public Action
frame.
VendorSpecificInfo A set of vendor As defined in 9.4.2.26 Zero or more elements.
specific elements
6.3.101.4.3 When generated
This primitive is generated by the MLME when a valid (Protected) Network Channel Control Public Action
frame is received.
6.3.101.4.4 Effect of receipt
On receipt of this primitive, the SME decides whether to accept the network channel control request.
6.3.101.5 MLME-NETWORKCHANNELCONTROL.response
6.3.101.5.1 Function
This primitive is generated by the SME to schedule the transmission of a network channel control response.
6.3.101.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-NETWORKCHANNELCONTROL.response (
PeerSTAAddress,
DialogToken,
NetworkChannelControl,
Protected,
VendorSpecificInfo
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual or The address of the peer MAC
group MAC address entity to which the response in a
Network Channel Control frame
is transmitted.
DialogToken Integer 0–255 The dialog token to identify the
network channel control
transaction.
587
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
NetworkChannelCo A set of information As defined in 9.6.8.30 Specifies the parameters of
ntrol subfields network channel control.
Protected Boolean true, false Specifies whether the response is
sent using a robust Management
frame. If true, the response is sent
using the Protected Network
Channel Control Public Action
frame. If false, the response is
sent using the Network Channel
Control Public Action frame.
VendorSpecificInfo A set of vendor specific As defined in 9.4.2.26 Zero or more elements.
elements
6.3.101.5.3 When generated
This primitive is generated by the SME to request that a network channel control response be sent to the peer
entity.
6.3.101.5.4 Effect of receipt
On receipt of this primitive, the MLME schedules the response to the specific peer MAC entity that has
requested a network channel control response.
6.3.102 White space map (WSM)
6.3.102.1 Introduction
The following MLME primitives support the signaling of the WSM.
6.3.102.2 MLME-WSM.request
6.3.102.2.1 Function
This primitive requests that a White Space Map Announcement frame be sent by a GDD enabling STA in
order to provide a WSM to a GDD dependent STA.
6.3.102.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-WSM.request (
PeerSTAAddress,
WhiteSpaceMap
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual Specifies the address of the peer MAC
MAC Address entity with which to perform the WSM
process.
WhiteSpaceMap White Space Map As defined in 9.4.2.170 Specifies the service parameters for the
element WSM.
588
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.102.2.3 When generated
This primitive is generated by the SME to request that a White Space Map Announcement frame be sent by
a GDD enabling STA to a specified peer MAC entity.
6.3.102.2.4 Effect of receipt
On receipt of this primitive, the MLME constructs a White Space Map Announcement frame. This frame is
then scheduled for transmission.
6.3.102.3 MLME-WSM.indication
6.3.102.3.1 Function
This primitive indicates receipt of a request of a White Space Map Announcement frame.
6.3.102.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-WSM.indication (
PeerSTAAddress,
WhiteSpaceMap
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC The address of the peer MAC
Address entity from which a WSM was
received.
WhiteSpaceMap White Space Map As defined in 9.4.2.170 Specifies the service parameters
element for the WSM.
6.3.102.3.3 When generated
This primitive is generated by the MLME when a valid White Space Map Announcement frame is received.
6.3.102.3.4 Effect of receipt
On receipt of this primitive, the SME is notified of the receipt of White Space Map Announcement frame.
6.3.103 Estimated Throughput (ESTT)
6.3.103.1 General
The following set of MLME primitives support the transport of an estimate of the achievable throughput for
a potential or an existing link between two STAs.
6.3.103.2 MLME-ESTIMATED-THROUGHPUT.request
6.3.103.2.1 Function
This primitive is generated by the SME to request that the MLME provide an estimated throughput for a
potential or existing association.
589
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.103.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-ESTIMATED-THROUGHPUT.request (
PeerSTAAddress,
AverageMSDUSizeOutbound,
AverageMSDUSizeInbound
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC Specifies the MAC address of the
Address STA for which throughput is to be
estimated assuming an association
to that STA if an association with
that STA does not currently exist.
AverageMSDUSizeI An ordered set of –1 to 7920, for each member of A set of integers providing an
nbound integers the set estimate of the average number of
octets per MSDU expected to be
delivered to the wireless medium
to this STA by the STA
corresponding to the
PeerMACAddress to this STA,
specified per access category in the
order AC_VO, AC_VI, AC_BE,
AC_BK. A value of –1 means that
the size is unspecified, a value of 0
means that no MSDUs are
expected to be delivered for this
access category.
AverageMSDUSizeO An ordered set of –1 to 7920, for each member of A set of integers providing an
utbound integers the set estimate of the average number of
octets per MSDU expected to be
delivered to the wireless medium
by this STA to the STA
corresponding to the
PeerMACAddress, specified per
access category in the order
AC_VO, AC_VI, AC_BE,
AC_BK. A value of –1 means that
the size is unspecified, a value of 0
means that no MSDUs are
expected to be delivered for this
access category.
6.3.103.2.3 When generated
This primitive is generated by the SME to request that the MLME provide an estimate of throughput for
MSDUs sent between this STA and the STA which corresponds to the PeerMACAddress provided in the
parameter list.
6.3.103.2.4 Effect of receipt
On receipt of this primitive, the MLME generates a set of estimates of throughput for MSDUs sent between
the STA which corresponds to the PeerMACAddress provided in the parameter list and this STA.
590
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.103.3 MLME-ESTIMATED-THROUGHPUT.confirm
6.3.103.3.1 Function
This primitive reports the result of a request to provide a set of estimated throughput values for a potential or
existing link.
6.3.103.3.2 Semantics of the service primitive
The primitive uses the following parameters:
MLME-ESTIMATED-THROUGHPUT.confirm (
PeerSTAAddress,
EstimatedThroughputOutbound,
EstimatedThroughputInbound
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC Specifies the MAC address of the
Address STA for which throughput is to be
estimated assuming a link with that
STA if a link with that STA does
not currently exist.
EstimatedThrough An ordered set of Non-negative real numbers The estimated throughput in the
putOutbound Real Numbers direction from the STA
corresponding to the
PeerMACAddress to this STA with
units of MSDU bits per second,
specified per access category in the
order AC_VO, AC_VI, AC_BE,
AC_BK. A value of 0 means no
estimate is available.
EstimatedThrough An ordered set of Non-negative real numbers The estimated throughput in the
putInbound Real Numbers direction from this STA to the STA
corresponding to the
PeerMACAddress with units of
MSDU bits per second, specified
per access category in the order
AC_VO, AC_VI, AC_BE,
AC_BK. A value of 0 means no
estimate is available.
6.3.103.3.3 When generated
This primitive is generated by the MLME to provide a set of estimates of throughput for MSDUs sent
between the STA which corresponds to the PeerMACAddress indicated in the parameter list and this STA.
6.3.103.3.4 Effect of receipt
On receipt of this primitive, the SME may use the reported estimates to make link, association and
forwarding decisions.
6.3.104 Get authentication/association state
6.3.104.1 General
This mechanism is used to obtain authentication/association state.
591
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.104.2 MLME-GETAUTHASSOCSTATE.request
6.3.104.2.1 Function
This primitive is generated by the SME to request that the MLME return the authentication/association state
with respect to a given peer STA.
6.3.104.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GETAUTHASSOCSTATE.request (
PeerSTAAddress,
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC Specifies the address of the peer
address MAC entity whose authentication/
association state is requested
6.3.104.2.3 When generated
This primitive is generated by the SME to request the authentication/association state from the MLME.
6.3.104.2.4 Effect of receipt
The MLME issues an MLME-GETAUTHASSOCSTATE.confirm primitive.
6.3.104.3 MLME-GETAUTHASSOCSTATE.confirm
6.3.104.3.1 Function
This primitive is generated by the MLME to report to the SME the result of a request to get the
authentication/association state.
6.3.104.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MLME-GETAUTHASSOCSTATE.confirm (
PeerSTAAddress,
AuthAssocState
)
Name Type Valid range Description
PeerSTAAddress MAC Address Any valid individual MAC Specifies the address of the peer
address MAC entity whose authentication/
association state was requested
AuthAssocState Integer 1-4 See 11.3.1 and 14.3.2
6.3.104.3.3 When generated
This primitive is generated by the MLME to report the authentication/association state to the SME.
592
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.3.104.3.4 Effect of receipt
The SME is notified of the result of an MLME-GETAUTHASSOCSTATR.request primitive.
6.4 MAC state generic convergence function (MSGCF)
6.4.1 Overview of the convergence function
The MSGCF provides an abstraction of a link between a non-AP STA and an ESS (an ESS-link) to its higher
layer entity. The MSGCF provides control of an ESS-link and generates events based on the state of an ESS-
link. A non-AP STA that transitions between two APs in the same ESS can operate transparently to the LLC
sublayer, and does not change state in the state machine defined within 6.4.
This clause defines interactions between the MSGCF and MLME and PLME through the MLME SAP and
PLME SAP respectively, as well as with the SME via the MSGCF-SME SAP. The detailed manner in which
the SAPs are implemented is not specified within this standard.
6.4.2 Overview of convergence function state machine
The convergence function maintains information on the state of the ESS, using the state machine shown in
Figure 6-29. Because Figure 6-29 is defined in terms of ESS connectivity, it is not affected by changes in
association provided that the transition was an intra-ESS transition.
ESS_CONNECTED
MSGCF-ESS-LINK-DOWN.indication
MSGCF-ESS-LINK-UP.indication
ESS_DISENGAGING
ESS_DISCONNECTED
STANDBY
Figure 6-29—MSGCF state machine
593
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.3 Convergence function state list
6.4.3.1 ESS_CONNECTED
In the ESS_CONNECTED state, a non-AP STA has completed all layer 2 setup activities and is able to send
Class 3 frames to peer LLC entities. A non-AP STA remains in this state as long as it is possible to send
Class 3 frames through any AP within an ESS. A non-AP STA does not leave this state upon successful intra-
ESS transitions.
6.4.3.2 ESS_DISCONNECTED
In the ESS_DISCONNECTED state, a non-AP STA is unable to send Class 3 frames to peer LLC entities.
Higher layer network protocols are unavailable. In this state, a non-AP STA may use GAS to perform network
discovery and selection.
6.4.3.3 ESS_DISENGAGING
In the ESS_DISENGAGING state, the non-AP STA’s SME anticipates that links to all APs within the ESS
will be lost in a defined time interval, but the non-AP STA is still able to send Class 3 frames to peer LLC
entities. The predictive failure of the link might be due to explicit disassociation by the peer, the imminent
invalidation of cryptographic keys because of usage limits (such as sequence counter exhaustion), or
predictive signal strength algorithms. In this state, it is recommended that a non-AP STA also initiate a search
to find a new ESS.
6.4.3.4 STANDBY
In the STANDBY state, the non-AP STA is powered down and unable to communicate with any other STAs.
6.4.4 Convergence function state transitions
6.4.4.1 Transitions to ESS_CONNECTED
6.4.4.1.1 From ESS_DISCONNECTED
To make this transition, a non-AP STA will have completed the network selection process and the relevant
procedures to attach to the ESS, including IEEE 802.11 authentication, IEEE 802.11 association, and, if
required, IEEE 802.11 RSN procedures. When this transition is completed, the MSGCF sends an MSGCF-
ESS-LINK-UP.indication primitive to higher layers.
6.4.4.1.2 From ESS_DISENGAGING
To make this transition, the SME cancels a previous event that predicted an ESS link failure. This might be
due to network parameters indicating renewed link strength or a successful renewal of an expiring RSN SA.
When this transition is complete, the MSGCF sends an MSGCF-ESS-LINK-EVENT-
ROLLBACK.indication primitive to indicate that a prior link failure predictive event is no longer valid. If the
transition was due to network parameters crossing a threshold, the MSGCF also sends an MSGCF-ESS-
LINK-THRESHOLD-REPORT.indication primitive to higher layers.
594
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.4.2 Transitions to ESS_ DISCONNECTED
6.4.4.2.1 From ESS_CONNECTED
This transition indicates that administrative action was taken to shut down the link, a sudden loss of signal
strength or that RSN keys expired and could not be renewed. At the conclusion of this transition, the MSGCF
sends an MSGCF-ESS-LINK-DOWN.indication primitive to higher layer protocols.
6.4.4.2.2 From ESS_DISENGAGING
This transition indicates that the predictive link failure event has occurred. At the conclusion of this transition,
the MSGCF issues an MSGCF-ESS-LINK-DOWN.indication primitive to higher layer protocols.
6.4.4.2.3 From STANDBY
This transition occurs when the non-AP STA is powered on and initialized. No event is issued by the MSGCF.
6.4.4.3 Transitions to ESS_DISENGAGING
6.4.4.3.1 From ESS_CONNECTED
When the parameters as defined in Table 6-7 change or imminent action is taken to bring down the link, the
SME may predict an imminent link failure and initiate a transition. Upon completion of this transition, the
MSGCF issues an MSGCF-ESS-LINK-GOING-DOWN event. If the cause of the transition was the
degradation of network parameters beyond the thresholds stored in the MIB, an MSGCF-ESS-LINK-
THRESHOLD-REPORT.indication primitive is also issued to higher layers.
6.4.4.4 Transitions to STANDBY
6.4.4.4.1 From ESS_DISCONNECTED
When the non-AP STA has disconnected from an ESS, it may be administratively powered off to extend
battery life. No events are issued by the MSGCF upon completion of this transition.
6.4.5 Convergence function informational events
Informational events may occur in any state. When they occur, the SME updates the convergence function
MIB with new parameters. Informational events do not cause state changes in Figure 6-29. Informational
events are generated when new potential ESS links are discovered, when the network parameter thresholds
are set or read, and when higher layer protocols issue commands to the non-AP STA through the MSGCF-
ESS-LINK-COMMAND.request primitive.
6.4.6 MAC state generic convergence SAP
The MAC state generic convergence SAP is the interface between the convergence function and higher layer
protocols. It presents a standardized interface for higher layer protocols to access the state of the MAC,
whether that state information is available in the MLME, PLME, or SME.
Some events on the MAC state generic convergence SAP require event identifiers for use as a dialog token
in event sequencing and rollback. The EventID is an unsigned integer that is initialized to 1 when the non-AP
STA leaves the STANDBY state.
595
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.7 ESS status reporting
6.4.7.1 MSGCF-ESS-LINK-UP.indication
6.4.7.1.1 Function
This event is triggered when a new ESS has been made available for sending frames.
6.4.7.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-UP.indication(
ESSIdentifier
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier composed of the string value of the
SSID element concatenated with the value of the
HESSID if it is in use. The HESSID is encoded in
upper-case ASCII characters with the octet values
separated by dash characters, as described in IETF
RFC 3580 [B39].
6.4.7.1.3 When generated
This primitive is generated when the ESS link to a network of APs is available to exchange Data frames. The
generation of this primitive may vary depending on the contents of dot11WEPDefaultKeysTable and
dot11WEPKeyMappingsTable and the setting of dot11RSNAOptionImplemented.
If there are no entries in the dot11WEPDefaultKeysTable, no entry for the current AP in
dot11WEPKeyMappingsTable, and dot11RSNAOptionImplemented is false, then the network does not use
encryption. This event is generated upon receipt of an MLME-ASSOCIATE.confirm primitive with a result
code of success.
If there are entries in the dot11WEPDefaultKeysTable, or an entry for the current AP in
dot11WEPKeyMappingsTable, or dot11RSNAOptionImplemented is true, then the network requires the use
of encryption on the link. Before declaring that the link is ready to exchange Data frames, the convergence
function receives an MLME-ASSOCIATE.confirm primitive with a result code of success and the SME emits
an MLME-SETKEYS.request primitive. The latter primitive is used to determine that a WEP key is available,
or that the RSN 4-way handshake has completed.
This event is not triggered by MLME-REASSOCIATE.confirm primitives because MLME-
REASSOCIATE.confirm primitives are defined as transitions within the same ESS.
The MLME-ASSOCIATE.confirm primitive may be issued upon AP transitions. It is the objective of the
MSGCF to generate this event only upon the initial connection to an IEEE 802.11 network, when the MSGCF
state machine moves into the ESS_CONNECTED state.
6.4.7.1.4 Effect of receipt
This event is made available to higher layer protocols by the convergence function. Actions taken by higher
layers are outside of scope of this standard, but may include router discovery, IP configuration, and other
higher layer protocol operations.
596
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.7.2 MSGCF-ESS-LINK-DOWN.indication
6.4.7.2.1 Function
This event is triggered to indicate that the connection to an ESS is no longer available for sending frames.
6.4.7.2.2 Semantics of the service primitive
The event’s parameters are as follows:
MSGCF-ESS-LINK-DOWN.indication (
ESSIdentifier,
ReasonCode
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier composed of the string value
of the SSID element concatenated with the
value of the HESSID if it is in use.
ReasonCode Enumerated EXPLICT_DISCONNECT, Reason code, drawn from Table 6-2.
KEY_EXPIRATION,
LOW_POWER,
VENDOR_SPECIFIC
Table 6-2—Reason codes for network down
Name Description
EXPLICIT_DISCONNECT An explicit disconnection operation (disassociation or deauthentication)
was initiated by the non-AP STA or the non-AP STA’s current serving AP
(the AP with which the STA is associated) and the non-AP STA was
unable to (re)associate with an alternate AP in the same ESS.
KEY_EXPIRATION Keys used by an RSN SA have expired due to time or traffic limitations, or
TKIP countermeasures have invalidated the key hierarchy.
LOW_POWER If the SME reports that the interface was shut down to conserve power,
that event may be reported to higher level protocols.
VENDOR_SPECIFIC Vendor-specific usage.
6.4.7.2.3 When generated
This event is generated when the SME declares that connectivity to an ESS is lost. It may be generated in the
case of an explicit disconnection from the link peer, received as an MLME-DEAUTHENTICATE.indication
or an MLME-DISASSOCIATE.indication primitive. The SME should wait for a period of
dot11ESSDisconnectFilterInterval before declaring connectivity lost to confirm that a non-AP STA is unable
to (re)associate with any alternate AP within the ESS.
6.4.7.2.4 Effect of receipt
This event is made available to higher layer protocols by the convergence function. Actions taken by those
higher layers are outside the scope of this standard, but may include removing entries from routing and
forwarding tables, and attempting to initiate handover of open application connections to network interfaces
that are still active.
597
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.7.3 MSGCF-ESS-LINK-GOING-DOWN.indication
6.4.7.3.1 Function
This event is triggered to indicate the expectation that the connection to an ESS will no longer be available
for sending frames in the near future.
6.4.7.3.2 Semantics of the service primitive
The event parameters are as follows:
MSGCF-ESS-LINK-GOING-DOWN.indication(
ESSIdentifier,
EventID,
TimeInterval,
ReasonCode
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier composed of the string value of
the SSID element concatenated with the
value of the HESSID if it is in use.
EventID Integer N/A An integer used to identify the event that is
used in the case of event rollback.
TimeInterval Integer N/A Time Interval, in time units, in which the link
is expected to go down. Connectivity is
expected to be available at least for time
specified by TimeInterval.
Reason Code Enumerated EXPLICT_DISCONNECT, Indicates the reason the link is expected to go
KEY_EXPIRATION, down, drawn from Table 6-3.
LOW_POWER, VENDOR_
SPECIFIC
Table 6-3—Reason codes for ESS link down
Name Description
EXPLICIT_DISCONNECT An explicit disconnection operation (Disassociation or
Deauthentication) was initiated by the non-AP STA or the non-AP
STA’s current serving AP.
KEY_EXPIRATION Keys used by an RSN SA have expired due to time or traffic
limitations, or TKIP countermeasures have invalidated the key
hierarchy.
LOW_POWER If the SME reports that the interface is going to be shut down to
conserve power, that event may be reported to higher level protocols.
VENDOR_SPECIFIC Vendor-specific usage.
598
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.7.3.3 When generated
This notification is generated by the MSGCF when the ESS link is currently established and is expected to
go down within the specified time interval. The network can be expected to go down because of an event
whose timing is well understood, such as an explicit disconnection event observed on the MLME SAP. It can
also be expected as the result of a predictive algorithm that monitors link quality. The details of such a
predictive algorithm used are beyond the scope of this standard.
The convergence function should attempt to deliver this event at least dot11ESSLinkDownTimeInterval time
units before the link is predicted to go down. Different higher layer network protocols might need different
levels of advance notice, and might configure dot11ESSLinkDownTimeInterval accordingly.
Not all thresholds in the dot11MACStateParameterTable are supported by every PHY. In the case when a
threshold parameter is not supported it is not applied.
6.4.7.3.4 Effect of receipt
This event is made available to higher layer protocols by the convergence function. Actions taken by those
higher layers are outside the scope of this standard, but may include beginning preparations for handover.
6.4.7.4 MSGCF-ESS-LINK-EVENT-ROLLBACK.indication
6.4.7.4.1 Function
This event is used to indicate that specific previous reports or events are no longer valid and should be
disregarded.
6.4.7.4.2 Semantics of the service primitive
The event parameters are as follows:
MSGCF-ESS-LINK-EVENT-ROLLBACK.indication(
ESSIdentifier,
EventID
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of the
string value of the SSID element used to identify
the network, concatenated with the value of the
HESSID if it is in use.
EventID Integer N/A An integer used to identify the event that is used
in the case of event rollback.
6.4.7.4.3 When generated
This event is generated when a previous predictive event is no longer valid within its expiration time.
The MSGCF-ESS-LINK-EVENT-ROLLBACK.indication primitive is used in conjunction with the
MSGCF-ESS-LINK-GOING-DOWN.indication primitive. The MSGCF-ESS-LINK-EVENT-
ROLLBACK.indication primitive is issued when the prediction of link failure is no longer valid. Algorithms
used to determine that link failure predictions are beyond the scope of this standard.
599
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.7.4.4 Effect of receipt
This event is made available to higher layer protocols by the convergence function to cancel any actions
begun by the previous event. Actions taken by those higher layers are outside the scope of this standard, but
may include canceling any handover procedures started by the MSGCF-ESS-LINK-GOING-DOWN event.
6.4.7.5 MSGCF-ESS-LINK-DETECTED.indication
6.4.7.5.1 Function
This event reports on the presence of a new ESS.
6.4.7.5.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-DETECTED.indication(
ESSIdentifier,
ESSDescription
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of the
string value of the SSID used to identify the
network, concatenated with the value of the
HESSID if it is in use.
ESSDescription As defined in N/A A set of information about the ESS.
Table 6-4
Table 6-4—ESS description
Name Syntax Description
SSID String The SSID used by the ESS.
InformationServic As described in Table 6-5 A set of values indicating the type of information
eSupport services supported on this network.
TriggerSupport As described in Table 6-5 A set of values indicating the support for the types of
triggers that can be used to propose that the station
take action.
RSN As defined in 9.4.2.25 The RSN configuration of the ESS.
Interworking As defined in 9.4.2.92 Interworking configuration of the ESS.
Table 6-5—Trigger support values
Name Description
MIH_CS_ES_Support This network supports the IEEE 802.21 MIH Command Service and
Event Service.
Vendor_Specific_Trigger_Support This network supports a vendor-specific trigger service.
600
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.7.5.3 When generated
Support for MIH is indicated by the presence or absence of the relevant Advertisement Protocol IDs in the
Advertisement Protocol element.To maintain the list of detected networks, the SME issues recurring MLME-
SCAN.request primitives to the MLME. The SME may schedule these requests to avoid interruption of user
traffic. Responses to these requests, received in the MLME-SCAN.confirm primitives, contain a list of
detected networks. Each network is stored in dot11MACStateESSLinkDetectedTable. This table holds a list
of networks, organized by Network Identifier. Each entry in the table contains a list of BSSIDs within the
network, as well as indications of support for MIH. Support for MIH is indicated by the presence or absence
of the relevant Advertisement Protocol IDs in the Advertisement Protocol element. Each entry in the table is
held for at least dot11ESSLinkDetectionHoldInterval time units. When a non-AP STA has not observed an
ESS for longer than dot11ESSLinkDetectionHoldInterval, it may be removed from the table.
This event is generated when a new entry is made into the dot11MACStateESSLinkDetectedTable.
Modifications to existing entries in the list, such as an update to the BSSID list, do not trigger this event.
6.4.7.5.4 Effect of receipt
This event is made available to higher layer protocols by the convergence function. Actions taken by those
higher layers are outside the scope of this standard.
6.4.7.6 MSGCF-ESS-LINK-SCAN.request
6.4.7.6.1 Function
This function is used by higher layer protocols to request that the SME perform a scan operation for available
ESSs.
6.4.7.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-SCAN.request(
SSID,
HESSID,
AccessNetworkType
)
Name Type Valid range Description
SSID Octet string 0–32 octets Specific or wildcard.
HESSID As defined in As defined in The HESSID to search for. It can be set to all 1s
9.4.2.92 9.4.2.92 for use as a wildcard to match all available
HESSID values.
AccessNetworkType As defined in As defined in This may be a specific value to match one type of
9.4.2.92 9.4.2.92 networks, or all 1s to match all access network
types.
6.4.7.6.3 When generated
This request is generated when higher protocol layers request a list of available ESSs.
6.4.7.6.4 Effect of receipt
The SME generates a corresponding MLME-SCAN.request primitive to find available networks.
601
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.7.7 MSGCF-ESS-LINK-SCAN.confirm
6.4.7.7.1 Function
This function reports information on available ESSs to higher protocol layers.
6.4.7.7.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-SCAN.confirm(
ESSIdentifiers,
ESSDescriptions
)
Name Type Valid range Description
ESSIdentifiers Set of Strings N/A An identifier for the network composed of the
string value of the SSID used to identify the
network, concatenated with the value of the
HESSID if it is in use.
ESSDescriptions Set of N/A A set of information about each discovered ESS.
ESSDescriptions,
as defined in
Table 6-4
6.4.7.7.3 When generated
This primitive is generated when scan results are available for reporting to higher protocol layers, in response
to an MSGCF-ESS-LINK-SCAN.request primitive.
6.4.7.7.4 Effect of receipt
This event is made available to higher layer protocols by the convergence function. Actions taken by those
higher layers are outside the scope of this standard.
6.4.8 Network configuration
6.4.8.1 MSGCF-ESS-LINK-CAPABILITY.request
6.4.8.1.1 Function
This primitive requests a list of the capabilities supported by a network.
6.4.8.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-CAPABILITY.request(
ESSIdentifier
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of the
string value of the SSID element used to identify
the network, concatenated with the value of the
HESSID if it is in use.
602
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.8.1.3 When generated
This primitive is issued to service higher layer protocols by reporting on the capabilities of a particular
network.
6.4.8.1.4 Effect of receipt
The convergence function retrieves the capabilities and reports them via the MSGCF-ESS-LINK-
CAPABILITY.confirm primitive.
6.4.8.2 MSGCF-ESS-LINK-CAPABILITY.confirm
6.4.8.2.1 Function
This primitive reports the convergence function capabilities of the network to higher layer protocols.
6.4.8.2.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-CAPABILITY.confirm(
ESSIdentifier,
EssLinkParameterSet,
ReasonCode
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of
the string value of the SSID element used to
identify the network, concatenated with the
value of the HESSID if it is in use.
EventCapability As defined in N/A list of supported events.
Set Table 6-6
ReasonCode Enumerated SUCCESS, An error code, if applicable.
UNKNOWN_NETWORK,
UNKNOWN_CAPABILITIES
Table 6-6—Event Capability Set
Name Type Valid range Description
NonAPSTAMacAddress MacAddress Any valid The MAC address of the non-AP STA that
individual MAC is reporting the new network.
Address
ESS-Link-Up Boolean true, false Indicates whether the MSGCF-ESS-LINK-
UP.indication primitive as defined in
6.4.7.1 is supported.
ESS-Link-Down Boolean true, false Indicates whether the MSGCF-ESS-LINK-
DOWN.indication primitive as defined in
6.4.7.2 is supported.
ESS-Link-Going-Down Boolean true, false Indicates whether the MSGCF-ESS-LINK-
GOING-DOWN primitive as defined in
6.4.7.3 is supported.
603
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 6-6—Event Capability Set (continued)
Name Type Valid range Description
ESS-Link-Event- Boolean true, false Indicates whether the MSGCF-ESS-LINK-
Rollback EVENT-ROLLBACK.indication primitive
as defined in 6.4.7.4 is supported.
ESS-Link-Detected Boolean true, false Indicates whether the MSGCF-ESS-LINK-
DETECTED.indication primitive as
defined in 6.4.7.5 is supported.
ESS-Link-Threshold- Boolean true, false Indicates whether the MSGCF-ESS-LINK-
Report THRESHOLD-REPORT.indication
primitive as defined in 6.4.9.1 is supported.
ESS-Link-Command Boolean true, false Indicates whether the MSGCF-ESS-LINK-
COMMAND.request primitive as defined
in 6.4.10.1 is supported.
6.4.8.2.3 When generated
This primitive is generated in response to the MSGCF-ESS-LINK-CAPABILITY.request primitive to report
whether specific events are supported.
6.4.8.2.4 Effect of receipt
This event is made available to higher layer protocols by the convergence function.
6.4.8.3 MSGCF-ESS-LINK-PARAMETERS.request
6.4.8.3.1 Function
This primitive sets thresholds for reporting of network events.
6.4.8.3.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-PARAMETERS.request(
ESSIdentifier,
EssLinkParameterSet
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of the
string value of the SSID element used to identify
the network, concatenated with the value of the
HESSID if it is in use.
ESSLinkParamete As defined in N/A The EssLinkParameterSet is used to configure
rSet Table 6-7 when event reports are sent to higher protocol
layers.
The ESSLinkParameterSet parameter is defined in Table 6-7. It may include any or all of the parameters in
Table 6-7.
604
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 6-7—ESS Link Parameter Set
Name Type Valid range Description
PeakOperationalRat Integer As defined in The integer representing the target peak
e 9.4.2.3 modulation data rate used for Data frame
transmission.
MinimumOperation Integer As defined in The integer encoding of the target minimum
alRate 9.4.2.3 modulation data rate used in Data frame
transmission.
NetworkDowntimeI Integer 0 – 65 535 Target advance warning time interval, in TUs, for
nterval MSGCF-ESS-LINK-GOING-DOWN events.
DataFrameRSSI Integer –100 to 40 The received signal strength in dBm of received
Data frames from the network. This may be time-
averaged over recent history by a vendor-specific
smoothing function.
BeaconRSSI Integer –100 to 40 The received signal strength in dBm of Beacon
frames received on the channel. This may be time-
averaged over recent history by a vendor-specific
smoothing function.
BeaconSNR Integer 0–100 The signal-to-noise ratio of the received Data
frames, in dB. This may be time-averaged over
recent history by a vendor-specific smoothing
function.
DataFrameSNR Integer 0–100 The signal-to-noise ratio of the received Beacon
frames, in dB. This may be time-averaged over
recent history by a vendor-specific smoothing
function.
DataThroughput Integer 0 – 65 535 The data throughput in megabits per second,
rounded to the nearest megabit. This may be time-
averaged over recent history by a vendor-specific
smoothing function.
MissedBeaconRate Real N/A The rate at which beacons have not been received
in missed beacons per second. This may be time-
averaged over recent history by a vendor-specific
smoothing function.
FrameErrorRate Real N/A The frame error rate of the network in errors per
second. This may be time-averaged over recent
history by a vendor-specific smoothing function.
VendorSpecific Vendor As defined by Additional vendor-specific parameters may be
Specific 9.4.2.26 included in this event.
6.4.8.3.3 When generated
This event is generated when higher protocol layers wish to set the performance parameters for a network.
Higher protocol layers are responsible for ensuring that the set of configured network parameters is consistent
with all subscribers to those higher layer protocols.
6.4.8.3.4 Effect of receipt
Parameters supplied in the event are stored in the MIB, either in the dot11MACStateConfigTable or the
dot11MACStateParameterTable.
605
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.8.4 MSGCF-ESS-LINK-PARAMETERS.confirm
6.4.8.4.1 Function
This primitive indicates whether network parameters were accepted.
6.4.8.4.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-PARAMETERS.confirm(
ESSIdentifier,
EssLinkParameterSet,
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of
the string value of the SSID element used to
identify the network, concatenated with the
value of the HESSID if it is in use.
EssLinkParamete As defined in N/A The EssLinkParameterSet is used to
rSet Table 6-7 configure when event reports are sent to
higher protocol layers.
6.4.8.4.3 When generated
This primitive is generated in response to the MSGCF-ESS-LINK-PARAMETERS.request primitive and is
used to indicate whether the parameter set was accepted.
6.4.8.4.4 Effect of receipt
The SME is notified of the new parameter set.
6.4.8.5 MSGCF-GET-ESS-LINK-PARAMETERS.request
6.4.8.5.1 Function
This primitive retrieves the current network parameters for a specific network.
6.4.8.5.2 Semantics of the service primitive
The primitive parameter is as follows:
MSGCF-GET-ESS-LINK-PARAMETERS.request(
ESSIdentifier
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of
the string value of the SSID element used
to identify the network, concatenated with
the value of the HESSID if it is in use.
6.4.8.5.3 When generated
This primitive is used by higher layers to retrieve the currently stored parameters for a network.
606
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.8.5.4 Effect of receipt
The SME retrieves the network parameters and makes them available through the MSGCF-GET-ESS-LINK-
PARAMETERS.confirm primitive.
6.4.8.6 MSGCF-GET-ESS-LINK-PARAMETERS.confirm
6.4.8.6.1 Function
This primitive reports the current network parameters.
6.4.8.6.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-GET-ESS-LINK-PARAMETERS.confirm(
ESSIdentifier,
EssLinkParameterSet,
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of
the string value of the SSID element used to
identify the network, concatenated with the
value of the HESSID if it is in use.
EssLinkParamet As defined N/A The EssLinkParameterSet is used to
erSet 6.4.8.3 configure when event reports are sent to
higher protocol layers.
6.4.8.6.3 When generated
This primitive is generated by the MSGCF as a result of the MSGCF-GET-ESS-LINK-
PARAMETERS.request primitive.
6.4.8.6.4 Effect of receipt
The higher layer protocols are notified of the current network parameters.
6.4.9 Network events
6.4.9.1 MSGCF-ESS-LINK-THRESHOLD-REPORT.indication
6.4.9.1.1 Function
This event reports that the layer 2 network performance has crossed a threshold set by the operations
described in Table 6-5.
6.4.9.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-THRESHOLD-REPORT.indication(
ESSIdentifier,
EssLinkParameterSet,
ThresholdCrossingDirectionSet
)
607
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed of
the string value of the SSID element used to
identify the network, concatenated with the
value of the HESSID if it is in use.
EssLinkParame As defined in Table 6-7 N/A A list of EssLinkParameterSets and their
terSet current values that have crossed preset
thresholds for alerts.
ThresholdCross Set of ThresholdCrossing UPWARD, Whether the parameter has crossed the
ingDirectionSet Directions, one for each DOWNWARD threshold while rising or falling.
value in the
EssLinkParameterSet
6.4.9.1.3 When generated
The convergence function is responsible for monitoring network performance. If the monitored parameters
cross the configured threshold, this event is generated to inform higher layer protocols.
6.4.9.1.4 Effect of receipt
This event is made available to higher layer protocols by the convergence function. Actions taken by those
higher layers are outside the scope of this standard, but may include preparations for handover or assessing
whether handover should be imminent.
6.4.10 Network command interface
6.4.10.1 MSGCF-ESS-LINK-COMMAND.request
6.4.10.1.1 Function
This primitive requests that a STA take action for a network.
6.4.10.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MSGCF-ESS-LINK-COMMAND.request(
ESSIdentifier,
CommandType
)
Name Type Valid range Description
ESSIdentifier String N/A An identifier for the network, composed
of the string value of the SSID element
used to identify the network,
concatenated with the value of the
HESSID if it is in use.
CommandType Enumerated DISCONNECT, Type of command to perform on the link
LOW_POWER, as described in the following subclauses.
POWER_UP,
POWER_DOWN, SCAN
6.4.10.1.3 When generated
This primitive is generated by a higher layer protocol.
608
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.4.10.1.4 Effect of receipt
The convergence function issues commands to the SME to implement the requested action on behalf of higher
layers.
When the DISCONNECT command type is specified, the higher layer is requesting that the STA disconnect
from its peer. When the SME on a non-AP STA receives this command, the SME issues an MLME-
DEAUTHENTICATE.request primitive to disconnect from the network, and the SME refrains from
reconnecting to that network.
When the POWER_DOWN command type is specified, the SME powers down the non-AP STA. Before
doing so, it may choose to notify the AP.
When the POWER_UP command type is specified, the SME starts the non-AP STA.
When the LOW_POWER command type is specified, the higher layer is requesting that the interface be
placed in a low power mode. This action is accomplished by issuing an MLME-POWERMGT.request
primitive with the PowerManagementMode parameter set to POWER_SAVE.
When the SCAN command type is specified, the higher layer is requesting that the STA search for networks.
This action is accomplished by issuing an MLME-SCAN.request primitive. Detected networks are made
available in the dot11MACStateESSLinkDetectedTable, as well as through the MSGCF-ESS-LINK-
DETECTED.indication primitive.
6.4.11 MAC state SME SAP—mobility management
6.4.11.1 MSSME-ESS-LINK-GOING-DOWN.indication
6.4.11.1.1 Function
This primitive indicates that the SME is predicting a link failure.
6.4.11.1.2 Semantics of the service primitive
The primitive parameters are as follows:
MSSME-ESS-LINK-GOING-DOWN.indication(
ESSIdentifier,
TimeInterval,
ReasonCode
)
Name Type Valid range Description
NonAPSTAMac MacAddress Any valid individual MAC The MAC address of the non-AP STA that
Address Address is reporting that an ESS is expected to go
down.
ESSIdentifier String N/A An identifier for the network, composed of
the string value of the SSID element used
to identify the network, concatenated with
the value of the HESSID if it is in use.
609
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Valid range Description
TimeInterval Integer N/A Time Interval, in time units, in which the
link is expected to go down. Connectivity
is expected to be available at least for time
specified by TimeInterval.
Reason Code Enumerated EXPLICIT_DISCONNECT, Indicates the reason the link is expected to
LINK_PARAMETER_DEG go down.
RADATION,
KEY_EXPIRATION,
LOW_POWER,
QOS_UNAVAILABLE,
VENDOR_SPECIFIC
6.4.11.1.3 When generated
This notification is generated by the SME when the network connection is currently established and is
expected to go down. The details of the predictive algorithm used are beyond the scope of this standard. One
method of implementing this function would be to generate this indication when link quality is fading and no
better AP can be found.
6.4.11.1.4 Effect of receipt
This indication is received by the MSGCF and is used to generate the MSGCF-ESS-LINK-DOWN.indication
primitive due to link parameter degradation.
6.5 PLME SAP interface
6.5.1 General
The PHY management service interface consists of the generic PLMEGET and PLMESET primitives on
PHY MIB attributes, as described previously, together with the PLME-RESET and PLME-
CHARACTERISTICS primitives and the following specific primitives.
6.5.2 PLME-RESET.request
6.5.2.1 Function
This primitive is a request by the SME to reset the PHY. The PHY is always reset to the receive state to
avoid accidental data transmission.
6.5.2.2 Semantics of the service primitive
This primitive has no parameters.
6.5.2.3 When generated
This primitive is generated at any time to reset the PHY.
6.5.2.4 Effect of receipt
Receipt of this primitive by the PHY causes the PHY entity to reset both the transmit and the receive state
machines and places the PHY into the receive state.
610
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.5.3 PLME-CHARACTERISTICS.request
6.5.3.1 Function
This primitive is a request by the SME to provide the PHY operational characteristics.
6.5.3.2 Semantics of the service primitive
This primitive has no parameters.
6.5.3.3 When generated
This primitive is generated by the SME, at initialization time, to request the PHY entity to provide its
operational characteristics.
6.5.3.4 Effect of receipt
The effect of receipt of this primitive by the PHY entity is the generation of a PLME-CHARACTERISTICS.
confirm primitive that conveys its operational characteristics.
6.5.4 PLME-CHARACTERISTICS.confirm
6.5.4.1 Function
This primitive provides the PHY operational parameters.
6.5.4.2 Semantics of the service primitive
The primitive provides the following parameters:
PLME-CHARACTERISTICS.confirm(
aSlotTime,
aSIFSTime,
aSignalExtension,
aCCATime,
aCCAMidTime,
aRxPHYStartDelay,
aRxTxTurnaroundTime,
aTxPHYDelay,
aRxPHYDelay,
aRxTxSwitchTime,
aTxRampOnTime,
aAirPropagationTime,
aMACProcessingDelay,
aPreambleLength,
aRIFSTime,
aSymbolLength,
aSTFOneLength,
aSTFTwoLength,
aLTFOneLength,
aLTFTwoLength,
aPHYHeaderLength,
aPHYSigTwoLength,
aPHYServiceLength,
aPHYConvolutionalTailLength,
611
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
aPSDUMaxLength,
aPPDUMaxTime,
aIUSTime,
aDTT2UTTTime,
aCWmin,
aCWmax,
aMaxCSIMatricesReportDelay
aMaxTODError,
aMaxTOAError,
aTxPHYTxStartRFDelay,
aTxPHYTxStartRMS,
aMaxTODFineError,
aMaxTOAFineError
)
The values assigned to the parameters are as specified in the PLME SAP interface specification contained
within each PHY subclass of this standard. Not all parameters are used by all PHYs defined within this
standard.
Name Type Description
aSlotTime integer The Slot Time (in microseconds) that the MAC uses for defining IFSs. See
10.3.7.
aSIFSTime integer The nominal time (in microseconds) that the MAC and PHY require in
order to receive the last symbol of a frame on the WM, process the frame,
and respond with the first symbol on the WM of the earliest possible
response frame. See 10.3.7.
aSignalExtension integer Duration (in microseconds) of the signal extension (i.e., a period of no
transmission) that is included at the end of certain PPDU formats; see 19.3.2
and 10.3.8.
aCCATime integer For Clause 15 through Clause 18 PHYs and Clause 20 PHYs, the maximum
time (in microseconds) the CCA mechanism has available to assess the
medium to determine whether the medium is busy or idle.
For Clause 19 and Clause 21 PHYs, the maximum time (in microseconds)
that the CCA mechanism has available to detect the start of a valid IEEE
802.11 transmission within the primary channel and to assess the energy on
the medium within the primary, secondary, secondary40 (Clause 21 PHY
only), and secondary80 (Clause 21 PHY only) channels that fall inside the
operating channel, in order to determine the values of the STATE and
channel-list parameters of the PHY-CCA.indication primitive.
aCCAMidTime integer For Clause 21 PHYs, the maximum time (in microseconds) the CCA
mechanism has available to assess the medium to determine whether an
IEEE 802.11 transmission is present on a nonprimary channel.
aRxPHYStartDelay integer The delay, in microseconds, from the start of the PPDU at the receiver’s
antenna to the issuance of the PHY-RXSTART.indication primitive.
aRxTxTurnaroundTime integer The maximum time (in microseconds) that the PHY requires to change from
receiving to transmitting the start of the first symbol. See 10.3.7.
aTxPHYDelay integer The nominal time (in microseconds) that the PHY uses to deliver a symbol
from the MAC interface to the air interface.
aRxPHYDelay integer The nominal time (in microseconds) that the PHY uses to deliver the last bit
of a received frame from end of the last symbol on the WM to the MAC.
aRxTxSwitchTime integer The nominal time (in microseconds) that the PHY takes to switch from
Receive to Transmit.
aTxRampOnTime integer The maximum time (in microseconds) that the PHY takes to turn the
Transmitter on.
612
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Description
aAirPropagationTime integer Twice the propagation time (in microseconds) for a signal to cross the
maximum distance between the most distant allowable STAs that are slot
synchronized.
aMACProcessingDelay integer The maximum time (in microseconds) available for the MAC to issue a
PHY-TXSTART.request primitive pursuant to a PHY-RXEND.indication
primitive (for response after SIFS) or PHY-CCA.indication(IDLE)
primitive (for response at any slot boundary following a SIFS). This
constraint on MAC performance is defined as a PHY-specific parameter
because of its use, along with other PHY-specific time delays, in calculating
the two PHY characteristics of primary concern to the MAC: aSlotTime and
aSIFSTime. See 10.3.7.
aPreambleLength integer The current PHY’s preamble length (in microseconds). If the actual value of
the length of the modulated preamble is not an integer number of
microseconds, the value is rounded up to the next higher value.
aRIFSTime integer Value of the reduced interframe space (in microseconds), which is the time
by which multiple transmissions from a single transmitter may be separated,
when no SIFS-separated response transmission is expected. See 10.3.2.3.2
aSymbolLength integer The current PHY’s Symbol length (in microseconds). If the actual value of
the length is not an integer number of µs, the value is rounded up to the next
higher value.
aSTFOneLength integer Length of the non-HT-STF (L-STF) for HT-mixed format, and the HT-
greenfield STF (HT-GF-STF) for HT-greenfield format (in microseconds)
aSTFTwoLength integer Length of the HT-STF (in microseconds)
aLTFOneLength integer Length of the First HT-LTF (in microseconds)
aLTFTwoLength integer Length of the Additional HT-LTFs (in microseconds)
aPHYHeaderLength integer The current PHY’s header length (in microseconds), excluding
aPHYSigTwoLength if present. If the actual value of the length of the
modulated header is not an integer number of microseconds, the value is
rounded up to the next higher value.
aPHYSigTwoLength integer Length of the HT SIGNAL field (HT-SIG) (in microseconds).
aPHYServiceLength integer The length of the PHY SERVICE field (in number of bits).
aPHYConvolutionalTail integer The length of the sequence of convolutional code tail bits (in number of
Length bits).
aPSDUMaxLength integer The maximum number of octets in a PSDU that can be conveyed by a
PPDU.
aPPDUMaxTime integer The maximum duration of a PPDU in milliseconds.
aIUSTime integer The minimum time between the end of a PSMP-UTT and the start of the
following PSMP-UTT in the same PSMP sequence.
aDTT2UTTTime integer The minimum time between the end of a PSMP-DTT and the start of the
PSMP-UTT addressed to the same STA.
aCWmin integer The minimum size of the CW, in units of aSlotTime.
aCWmax integer The maximum size of the CW, in units of aSlotTime.
aMaxCSIMatricesReport integer The maximum time (in milliseconds) between the reception of a frame
Delay containing a CSI Feedback Request or an null data packet (NDP)
announcement and the transmission of the first CSI frame containing
channel state information measured from the received Sounding Complete
frame. See 10.32.2.4.4.
aMaxTODError Integer An estimate of the maximum error (in 10 ns units) in the
TX_START_OF_FRAME_OFFSET value in the PHY-
TXSTART.confirm(TXSTATUS) primitive. The estimated maximum error
includes any error due to implementation component and environmental
(including temperature) variability.
aMaxTOAError Integer An estimate of the maximum error (in 10 ns units) in the
RX_START_OF_FRAME_OFFSET value in the PHY-
RXSTART.indication(RXVECTOR) primitive. The estimated maximum
error includes any error due to implementation component and
environmental (including temperature) variability.
613
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Name Type Description
aTxPHYTxStartRFDelay Integer The delay (in units of 0.5 ns) between a PHY-TXSTART.request primitive
being issued and the first frame energy sent by the transmitting port, for the
current channel.
aTxPHYTxStartRMS Integer The RMS time of departure error (in units of 0.5 ns), where the time of
departure error equals the difference between TIME_OF_DEPARTURE and
the time of departure measured by a reference entity using a clock
synchronized to the start time and mean frequency of the local PHY entity’s
clock.
aMaxTODFineError Integer An estimate of the maximum error (in units of picoseconds) in the
TX_START_OF_FRAME_OFFSET value in the PHY-
TXSTART.confirm(TXSTATUS) primitive. The estimated maximum error
includes any error due to implementation component and environmental
(including temperature) variability.
aMaxTOAFineError Integer An estimate of the maximum error (in units of picoseconds) in the
RX_START_OF_FRAME_OFFSET value in the PHY-
RXSTART.indication(RXVECTOR) primitive. The estimated maximum
error includes any error due to implementation component and
environmental (including temperature) variability.
6.5.4.3 When generated
This primitive is issued by the PHY entity in response to a PLME-CHARACTERISTICS.request primitive.
6.5.4.4 Effect of receipt
The receipt of this primitive provides the operational characteristics of the PHY entity.
6.5.5 PLME-TXTIME.request
6.5.5.1 Function
This primitive is a request for the PHY to calculate the time required to transmit onto the WM a PPDU
containing a specified length PSDU, and using a specified format, data rate, and signaling.
6.5.5.2 Semantics of the service primitive
This primitive provides the following parameter:
PLME-TXTIME.request(
TXVECTOR
)
The TXVECTOR represents a list of parameters that the MAC sublayer provides to the local PHY entity in
order to transmit a PSDU. The minimum required PHY parameters are listed in 8.3.4.4.
6.5.5.3 When generated
This primitive is issued by the MAC sublayer to the PHY entity when the MAC sublayer needs to determine
the time required to transmit a particular PSDU.
6.5.5.4 Effect of receipt
The effect of receipt of this primitive by the PHY entity is to generate a PHY-TXTIME.confirm primitive
that conveys the required transmission time.
614
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6.5.6 PLME-TXTIME.confirm
6.5.6.1 Function
This primitive indicates the time required to transmit the PPDU described in the corresponding PLME-
TXTIME.request primitive.
When the TXVECTOR parameter FORMAT in the corresponding PLME-TXTIME.request primitive is
VHT, the primitive also provides the number of octets, per user, required to fill the PPDU.
6.5.6.2 Semantics of the service primitive
This primitive provides the following parameter:
PLME-TXTIME.confirm(
TXTIME
PSDU_LENGTH[]
)
The TXTIME represents the time, in microseconds, required to transmit the PPDU described in the
corresponding PLME-TXTIME.request primitive. If the calculated time includes a fractional microsecond, a
non-DMG STA rounds the TXTIME value to the next higher integer. A DMG STA does not round the
TXTIME value up or down (see 20.12.3).
The PSDU_LENGTH[] parameter is an array of size TXVECTOR parameter NUM_USERS. Each value in
the array indicates the number of octets required to fill the PPDU for the user represented by that array
index. The parameter is present only when the TXVECTOR FORMAT parameter is VHT.
6.5.6.3 When generated
This primitive is issued by the local PHY entity in response to a PLME-TXTIME.request primitive.
6.5.6.4 Effect of receipt
The receipt of this primitive provides the MAC sublayer with the PPDU transmission time.
615
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
7. DS SAP specification
7.1 Introduction
The DS SAP is the interface between the DS SAP service users and the DS SAP service provider. The DS
SAP service users are the connected APs, mesh gates, and the portal. The DS SAP service provider is the
DS. Figure 7-1 shows the location of the DS in the IEEE 802.11 architecture. The DS SAP is indicated in
this Figure by the lines connecting the DS to its service users. In Figure 7-1, the DS has four users, two APs,
a mesh gate, and a portal, so the DS is shown passing behind the MAC/PHYs of the STAs.
DSAF DSAF DSAF Portal
MAC MAC Mesh
MAC MAC MAC MAC
PHY PHY PHY PHY DS PHY PHY
802.11 Medium 802.11 Medium 802.11 Medium 802.3 Medium
Non‐AP STAs AP1 AP2 Mesh Gate Portal
‐ DS SAP
Figure 7-1—DS architecture
The DS SAP interface specification describes the primitives required to get MAC service tuples in and out
of the DS and update the DS’s mapping of STAs to APs or to mesh gates. Describing the DS itself or the
functions thereof is out of scope of this annex.
The DS SAP actions are as follows:
a) Accept MSDUs (as part of MAC service tuples) from APs, mesh gates, and the portal.
b) Deliver MSDUs (as part of MAC service tuples) to APs, mesh gates, or the portal.
c) Accept STA-to-AP mapping updates from the APs.
d) Accept STA-to-mesh gate mapping updates from the mesh gates.
When the DS delivers the MAC service tuples to an AP, the AP then determines when and how to deliver
the MAC service tuples to the AP’s MAC (via the MAC SAP). When the DS delivers the MAC service
tuples to a mesh gate, the mesh gate then determines when and how to deliver the MAC service tuples to the
mesh gate’s MAC (via the MAC SAP).
7.2 SAP primitives
7.2.1 General
The DS SAP service interface primitives are as follows:
a) DS-UNITDATA.request
b) DS-UNITDATA.indication
c) DS-STA-NOTIFY.request
616
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
7.2.2 MSDU transfer
7.2.2.1 General
The DS-UNITDATA primitives accept and deliver IEEE 802.11 MAC service tuples, including all of the
parameters and data as defined in 5.2.2.2.
7.2.2.2 DS-UNITDATA.request
7.2.2.2.1 Function
This primitive requests distribution of a MAC service tuple across the DS.
7.2.2.2.2 Semantics of the service primitive
The primitive parameters are as follows:
DS-UNITDATA.request(
MAC service tuple,
SourceType
)
Name Type Valid range Description
MAC service tuple IEEE 802.11 Any valid data unit Specifies the MAC service tuple to be
MSDU according to 5.2.2.2, distributed via the DS.
including data and all
parameters
SourceType Enumeration SRC_AP, Specifies the type of entity that is requesting
SRC_MESH_GATE, distribution of a MAC service tuple.
SRC_PORTAL
7.2.2.2.3 When generated
This primitive is generated by an AP, mesh gate, or portal to submit a MAC service tuple to the DS for
distribution.
7.2.2.2.4 Effect of receipt
This primitive initiates distribution of the MAC service tuple through the DS. An individually addressed
MAC service tuple from an AP, mesh gate, or portal is distributed through the DS to the corresponding AP,
mesh gate, or portal. A group addressed MAC service tuple from an AP is distributed to all APs, mesh gates,
and the portal, including the originating entity. A group addressed MAC service tuple from a portal is
distributed to all APs and mesh gates.
7.2.2.3 DS-UNITDATA.indication
7.2.2.3.1 Function
This primitive indicates delivery of a MAC service tuple from the DS to an AP, mesh gate, or portal.
617
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
7.2.2.3.2 Semantics of the service primitive
The primitive parameters are as follows:
DS-UNITDATA.indication(
MAC service tuple
)
Name Type Valid range Description
MAC service tuple IEEE 802.11 Any valid data unit Specifies the MAC service tuple that is being
MSDU according to 5.2.2.2, delivered by the DS.
including data and all
parameters
7.2.2.3.3 When generated
This primitive is generated by the DS to deliver a MAC service tuple to an AP, mesh gate, or portal.
7.2.2.3.4 Effect of receipt
This primitive delivers a MAC service tuple to an AP, mesh gate, or portal.
7.2.3 Mapping updates
7.2.3.1 General
The DS-STA-NOTIFY primitive is used to maintain the STA-to-AP and mesh STA-to-mesh gate mapping
data of the DS.
7.2.3.2 DS-STA-NOTIFY.request
7.2.3.2.1 Function
This primitive requests an update to the DS’s STA-to-AP map or mesh STA-to-mesh gate map.
7.2.3.2.2 Semantics of the service primitive
The primitive parameters are as follows:
DS-STA-NOTIFY.request(
STAAddress,
UpdateType
)
Name Type Valid range Description
STAAddress MACAddress Any valid individual When generated by an AP, specifies the
MAC address address of the STA whose association
status with the AP has changed.
When generated by a mesh gate, specifies
the address of the mesh STA whose
reachability status through the mesh gate
has changed.
UpdateType Enumeration ADD, MOVE, Specifies the DS mapping update
DELETE operation to be performed.
618
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
7.2.3.2.3 When generated
This primitive is generated by an AP or mesh gate to update the DS’s STA-to-AP map or mesh STA-to-
mesh gate map.
7.2.3.2.4 Effect of receipt
When generated by an AP, this primitive updates the DS’s STA-to-AP map, which controls to which AP the
DS delivers MAC service tuples that are destined for a given STA.
When generated by a mesh gate, this primitive updates the DS’s mesh STA-to-mesh gate map, which
controls to which mesh gate the DS delivers MAC service tuples that are destined for a given mesh STA.
The mesh STA-to-mesh gate map can be incomplete.
There are many mechanisms to implement this mapping update for the cases of ADD and MOVE. One
example mechanism, in the case where the DS is an IEEE 802 LAN, is to use an IEEE 802.2™ XID null
frame.
619
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8. PHY service specification
8.1 Scope
The PHY services provided to the MAC are described in this clause. Different PHYs are defined as part of
this standard. Each PHY can consist of the following protocol functions:
a) A function that defines a method of mapping the MPDUs into a framing format suitable for sending
and receiving user data and management information between two or more STAs.
b) A function that defines the characteristics of, and method of transmitting and receiving data through,
a WM between two or more STAs.
8.2 PHY functions
The protocol reference model for the IEEE 802.11 architecture is shown in Figure 4-19 (in 4.9). Most PHY
definitions contain two functional entities: the PHY function and the layer management function.
The PHY service is provided to the MAC entity at the STA through a SAP, called the PHYSAP, as shown in
Figure 4-19.
8.3 Detailed PHY service specifications
8.3.1 Scope and field of application
The services provided by the PHY to the MAC are specified in this subclause. These services are described in
an abstract way and do not imply any particular implementation or exposed interface.
8.3.2 Overview of the service
The function of the PHY is to provide a mechanism for transferring MPDUs between two or more STAs.
8.3.3 Overview of interactions
The primitives associated with communication between the MAC sublayer and the PHY fall into two basic
categories:
a) Service primitives that support MAC peer-to-peer interactions;
b) Service primitives that have local significance and support sublayer-to-sublayer interactions.
8.3.4 Basic service and options
8.3.4.1 PHY SAP peer-to-peer service primitives
Table 8-1 indicates the primitives for peer-to-peer interactions.
Table 8-1—PHY SAP peer-to-peer service primitives
Primitive Request Indication Confirm
PHY-DATA X X X
620
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.4.2 PHY SAP inter-(sub)layer service primitives
Table 8-2 indicates the primitives for sublayer-to-sublayer interactions.
Table 8-2—PHY SAP inter-(sub)layer service primitives
Primitive Request Indication Confirm
PHY-TXSTART X X
PHY-TXEND X X
PHY-CCARESET X X
PHY-CCA X
PHY-RXSTART X
PHY-RXEND X
PHY-CONFIG X X
PHY-TXBUSY X
PHY-TXHEADEREND X
8.3.4.3 PHY SAP service primitives parameters
Table 8-3 shows the parameters used by one or more of the PHY SAP service primitives.
Table 8-3—PHY SAP service primitive parameters
Parameter Associated primitive Value
DATA PHY-DATA.request Octet value X'00'–X'FF'
PHY-DATA.indication
TXVECTOR PHY-TXSTART.request A set of parameters
STATE PHY-CCA.indication (BUSY, [channel-list])
(IDLE)
RXVECTOR PHY-RXSTART.indication A set of parameters
PHY-RXEND.indication
RXERROR PHY-RXEND.indication NoError, FormatViolation,
CarrierLost, UnsupportedRate,
Filtered
IPI-STATE PHY-CCARESET.request IPI-ON, IPI-OFF
PHY-CCARESET.confirm
IPI-REPORT PHY-CCA.indication A set of IPI values for the preceding
PHY-CCARESET.confirm time interval
PHYCONFIG_VECTOR PHY-CONFIG A set of parameters
TXSTATUS PHY-TXSTART.confirm A set of parameters
STATE PHY-TXBUSY.indication IDLE, BUSY
621
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.4.4 Vector descriptions
Several service primitives include a parameter vector. This vector is a list of parameters that may vary
depending on the PHY type. Table 8-4 lists the minimum parameter values required by the MAC or PHY in
each of the parameter vectors.
Table 8-4—Vector descriptions
Parameter Associated vector Value
DATARATE TXVECTOR, RXVECTOR PHY dependent. The name of the field used to
specify the Tx data rate and report the Rx data rate
may vary for different PHYs.
LENGTH TXVECTOR, RXVECTOR PHY dependent
ACTIVE_RXCHAIN_SET PHYCONFIG_VECTOR The ACTIVE_RXCHAIN_SET parameter
indicates which receive chains of the available
receive chains are active.
OPERATING_CHANNEL PHYCONFIG_VECTOR The operating channel the PHY is configured use.
SECONDARY_CHANNEL PHYCONFIG_VECTOR Enumerated type:
_OFFSET SECONDARY_CHANNEL_NONE indicates
operation in 20 MHz HT STAs.
SECONDARY_CHANNEL_ABOVE indicates
operation in 40 MHz with the secondary
channel above the primary.
SECONDARY_CHANNEL_BELOW indicates
operation in 40 MHz with the secondary
channel below the primary.
ANT_CONFIG PHYCONFIG_VECTOR Indicates which antenna configuration(s) is to be
used when receiving packets and which
configuration is to be used when switching
configurations during the reception of a packet.
Values are implementation dependent.
GROUP_ID_MANAGEME PHYCONFIG_VECTOR Specifies membership status and STA position for
NT each of the group IDs as described in 9.6.23.3
PARTIAL_AID_LIST_GID PHYCONFIG_VECTOR Includes the list of partial AIDs, of which the STA
00 is an intended recipient, associated with group ID 0.
The settings of the PARTIAL_AID are specified in
10.20).
PARTIAL_AID_LIST_GID PHYCONFIG_VECTOR Includes the list of partial AIDs, of which the STA
63 is an intended recipient, associated with group ID
63. The settings of the PARTIAL_AID are specified
in 10.20).
LISTEN_TO_GID00 PHYCONFIG_VECTOR When true, indicates to the PHY not to filter out
PPDUs with GROUP_ID field equal to the value 0.
LISTEN_TO_GID63 PHYCONFIG_VECTOR When true, indicates to the PHY not to filter out
PPDUs with GROUP_ID field equal to the value
63.
The Clause 19 PHY TXVECTOR and RXVECTOR contain additional parameters related to the operation
of the Clause 19 PHY modes of operation as described in 19.2. In certain modes of operation, the
622
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DATARATE parameter is replaced by MCS, CH_BANDWIDTH and GI_TYPE values. The mapping from
these values to data rate is defined in 19.5.
The Clause 21 PHY TXVECTOR and RXVECTOR contain additional parameters related to the operation
of the Clause 21 PHY modes of operation as described in 21.2. In certain modes of operation, the
DATARATE parameter is replaced by MCS, CH_BANDWIDTH, NUM_STS, STBC and GI_TYPE values.
The mapping from these values to data rate is defined 21.5, where VHT-MCS is MCS and NSS is
NUM_STS / (STBC + 1).
8.3.5 PHY SAP detailed service specification
8.3.5.1 Introduction
Subclause 8.3.5 describes the services provided by each PHY primitive.
8.3.5.2 PHY-DATA.request
8.3.5.2.1 Function
This primitive defines the transfer of an octet of data from the MAC sublayer to the local PHY entity.
8.3.5.2.2 Semantics of the service primitive
The primitive provides the following parameter:
PHY-DATA.request(
DATA
USER_INDEX
)
The DATA parameter is an octet of value X'00' to X'FF'.
The USER_INDEX parameter (typically identified as u for a VHT STA; see NOTE 1 at the end of
Table 21-1) is present for a VHT MU PPDU and indicates the index of the user in the TXVECTOR to which
the accompanying DATA octet applies; otherwise, this parameter is not present.
8.3.5.2.3 When generated
This primitive is generated by the MAC sublayer to transfer an octet of data to the PHY entity. This
primitive can be issued only following a transmit initialization response (a PHY-TXSTART.confirm
primitive) from the PHY.
8.3.5.2.4 Effect of receipt
The receipt of this primitive by the PHY entity causes the PHY transmit state machine to transmit an octet of
data. When the PHY entity receives the octet, it issues a PHY-DATA.confirm primitive to the MAC
sublayer.
8.3.5.3 PHY-DATA.indication
8.3.5.3.1 Function
This primitive indicates the transfer of data from the PHY to the local MAC entity.
623
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.5.3.2 Semantics of the service primitive
The primitive provides the following parameter:
PHY-DATA.indication(
DATA
)
The DATA parameter is an octet of value X'00' to X'FF'.
8.3.5.3.3 When generated
The PHY-DATA.indication primitive is generated by a receiving PHY entity to transfer the received octet of
data to the local MAC entity. The time between receipt of the last bit of the last provided octet from the WM
and the receipt of this primitive by the MAC entity is aRxPHYDelay.
8.3.5.3.4 Effect of receipt
The effect of receipt of this primitive by the MAC is unspecified.
8.3.5.4 PHY-DATA.confirm
8.3.5.4.1 Function
This primitive is issued by the PHY to the local MAC entity to confirm the transfer of data from the MAC
entity to the PHY.
8.3.5.4.2 Semantics of the service primitive
The semantics of the primitive are as follows:
PHY-DATA.confirm
This primitive has no parameters.
8.3.5.4.3 When generated
This primitive is issued by the PHY to the MAC entity the transfer of data from the MAC entity to the PHY
has completed. The PHY issues this primitive in response to every PHY-DATA.request primitive issued by
the MAC sublayer.
8.3.5.4.4 Effect of receipt
The receipt of this primitive by the MAC causes the MAC to start the next MAC entity request.
8.3.5.5 PHY-TXSTART.request
8.3.5.5.1 Function
This primitive is a request by the MAC sublayer to the local PHY entity to start the transmission of a PSDU.
8.3.5.5.2 Semantics of the service primitive
The primitive provides the following parameter:
624
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PHY-TXSTART.request(
TXVECTOR
)
The TXVECTOR represents a list of parameters that the MAC sublayer provides to the local PHY entity in
order to transmit a PSDU. The minimum required PHY parameters are listed in 8.3.4.4.
8.3.5.5.3 When generated
This primitive is issued by the MAC sublayer to the PHY entity when the MAC sublayer needs to begin the
transmission of a PSDU.
8.3.5.5.4 Effect of receipt
The effect of receipt of this primitive by the PHY entity is to start the local transmit state machine.
The behavior expected by the MAC pursuant to the issuance of PHY-TXSTART.request primitive is shown
in Figure 10-19 (in 10.3.7) and Figure 10-26.
8.3.5.6 PHY-TXSTART.confirm
8.3.5.6.1 Function
This primitive is issued by the PHY to the local MAC entity to confirm the start of a transmission and to
indicate parameters related to the start of the transmission. The PHY issues this primitive in response to
every PHY-TXSTART.request primitive issued by the MAC sublayer.
8.3.5.6.2 Semantics of the service primitive
The semantics of the primitive are as follows:
PHY-TXSTART.confirm(
TXSTATUS
)
The TXSTATUS represents a list of parameters that the local PHY entity provides to the MAC sublayer
related to the transmission of an MPDU. The required PHY parameters are listed in 8.3.4.3.
8.3.5.6.3 When generated
This primitive is issued by the PHY to the MAC entity once all of the following conditions are met:
— The PHY has received a PHY-TXSTART.request primitive from the MAC entity.
— The PHY is ready to begin accepting outgoing data octets from the MAC.
If dot11TODImplemented and dot11TODActivated are both true or dot11TimingMsmtActivated is true; and
the parameter TIME_OF_DEPARTURE_REQUESTED in the TXVECTOR specified in the PHY-
TXSTART.request is true, then the PHY shall include the TIME_OF_DEPARTURE corresponding to the
time when the first frame energy is sent by the transmitting port and TIME_OF_DEPARTURE_ClockRate
parameters in the TXSTATUS vector (See Table 15-3).
If dot11TimingMsmtActivated is true, then the PHY shall include TX_START_OF_FRAME_OFFSET in
the TXSTATUS vector (See Table 15-3).
625
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.5.6.4 Effect of receipt
The receipt of this primitive by the MAC entity causes the MAC to start the transfer of data octets.
Parameters in the TXSTATUS vector may be included in transmitted frames so that recipients on multiple
channels can compensate for differences in the transmit time of the frames, and so to determine the time
differences of air propagation times between transmitter and pairs of recipients and hence to compute the
location of the transmitter via multilateration. See Annex P. In addition, the TXSTATUS vector may include
the TX_START_OF_FRAME_OFFSET.
8.3.5.7 PHY-TXEND.request
8.3.5.7.1 Function
This primitive is a request by the MAC sublayer to the local PHY entity that the current transmission of the
PSDU be completed.
8.3.5.7.2 Semantics of the service primitive
The semantics of the primitive are as follows:
PHY-TXEND.request
This primitive has no parameters.
8.3.5.7.3 When generated
This primitive is generated when the MAC sublayer has received the last PHY-DATA.confirm primitive
from the local PHY entity for the PSDU currently being transferred.
8.3.5.7.4 Effect of receipt
The effect of receipt of this primitive by the local PHY entity is to stop the transmit state machine.
8.3.5.8 PHY-TXEND.confirm
8.3.5.8.1 Function
This primitive is issued by the PHY to the local MAC entity to confirm the completion of a transmission.
The PHY issues this primitive in response to every PHY-TXEND.request primitive issued by the MAC
sublayer.
8.3.5.8.2 Semantics of the service primitive
The semantics of the primitive are as follows:
PHY-TXEND.confirm
This primitive has no parameters.
8.3.5.8.3 When generated
This primitive is issued by the PHY to the MAC entity when the PHY has received a PHY-TXEND.request
primitive immediately after transmitting the end of the last bit of the last data octet indicating that the
symbol containing the last data octet has been transferred and any Signal Extension has expired.
626
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.5.8.4 Effect of receipt
The receipt of this primitive by the MAC entity provides the time reference for the contention backoff protocol.
8.3.5.9 PHY-TXHEADEREND.indication
8.3.5.9.1 Function
This primitive indicates the transmission completion of the PHY header to the local MAC entity.
8.3.5.9.2 Semantics of the service primitive
The semantics of the primitive are as follows:
PHY-TXHEADEREND.indication
This primitive has no parameters.
8.3.5.9.3 When generated
The PHY-TXHEADEREND.indication primitive is generated by a transmitter PHY entity at the end of
transmission of the last symbol containing the PHY header.
8.3.5.9.4 Effect of receipt
The receipt of this primitive by the MAC entity causes the MAC to record the time when this primitive is
received only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding
PHY-TXSTART.request primitive.
8.3.5.10 PHY-CCARESET.request
8.3.5.10.1 Function
This primitive is a request by the MAC sublayer to the local PHY entity to reset the PHY to the state
appropriate for the end of a received frame and to turn IPI reporting on and off by means of the IPI-STATE
parameter.
8.3.5.10.2 Semantics of the service primitive
The primitive provides the following parameter:
PHY-CCARESET.request(
IPI-STATE
)
The IPI-STATE parameter is present if dot11RadioMeasurementActivated is true. The IPI-STATE
parameter can be one of two values: IPI-ON or IPI-OFF. The parameter value is IPI-ON when the MAC
sublayer is requesting the PHY entity to report IPI values when the PHY is neither receiving nor transmitting
an MPDU. IPI-ON turns on IPI reporting in the PHY entity. IPI-OFF turns off IPI reporting in the PHY
entity.
627
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.5.10.3 When generated
This primitive is generated by the MAC sublayer for the local PHY entity at the end of a NAV and at a time
indicated in 10.3.2.1 after each MAC slot boundary, which is described in 10.3.7 and 10.22.2.4. This request
can be used by some PHY implementations that may synchronize antenna diversity with slot timings.
8.3.5.10.4 Effect of receipt
The effect of receipt of this primitive by the PHY entity is to reset the PHY to the state appropriate for the
end of a received frame and to initiate a new CCA evaluation cycle. If IPI-STATE parameter is IPI-ON, the
PHY entity collects IPI values when it is not transmitting or receiving and provides those values to the MAC
sublayer using the IPI-REPORT parameter.
8.3.5.11 PHY-CCARESET.confirm
8.3.5.11.1 Function
This primitive is issued by the PHY to the local MAC entity to confirm that the PHY has reset the CCA state
machine and to provide observed IPI values when IPI reporting is turned on.
8.3.5.11.2 Semantics of the service primitive
The primitive provides the following parameters:
PHY-CCARESET.confirm(
IPI-STATE,
IPI-REPORT
)
The IPI-STATE parameter is present if dot11RadioMeasurementActivated is true. The IPI-STATE
parameter can be one of two values: IPI-ON or IPI-OFF. The IPI-STATE value shall be set to the value of
IPI-STATE received by the PHY entity in the most recent PHY-CCARESET.request primitive.
The IPI-REPORT parameter is present if dot11RadioMeasurementActivated is true and if IPI reporting was
turned on prior to the receipt of the latest PHY-CCARESET.request primitive. The IPI-REPORT parameter
provides a set of IPI values for a time interval. The set of IPI values are recent values observed by the PHY
entity since the generation of the most recent PHY-TXEND.confirm, PHY-RXEND.indication, PHY-
CCARESET.confirm, or PHY-CCA.indication primitive, whichever occurred latest.
8.3.5.11.3 When generated
This primitive is issued by the PHY to the MAC entity when the PHY has received a PHY-CCA-
RESET.request primitive.
8.3.5.11.4 Effect of receipt
The effect of receipt of this primitive by the MAC is unspecified.
8.3.5.12 PHY-CCA.indication
8.3.5.12.1 Function
This primitive is an indication by the PHY to the local MAC entity of the current state of the medium and to
provide observed IPI values when IPI reporting is turned on.
628
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.5.12.2 Semantics of the service primitive
The primitive provides the following parameters:
PHY-CCA.indication(
STATE,
IPI-REPORT,
channel-list
)
The STATE parameter can be one of two values: BUSY or IDLE. The parameter value is BUSY if the
assessment of the channel(s) by the PHY determines that the channel(s) are not available. Otherwise, the
value of the parameter is IDLE.
The IPI-REPORT parameter is present if dot11RadioMeasurementActivated is true and if IPI reporting has
been turned on by the IPI-STATE parameter. The IPI-REPORT parameter provides a set of IPI values for a
time interval. The set of IPI values may be used by the MAC sublayer for radio measurement purposes. The
set of IPI values are recent values observed by the PHY entity since the generation of the most recent PHY-
TXEND.confirm, PHY-RXEND.indication, PHY-CCARESET.confirm, or PHY-CCA.indication primitive,
whichever occurred latest.
When STATE is IDLE or when, for the type of PHY in operation, CCA is determined by a single channel,
the channel-list parameter is absent. Otherwise, it carries a set indicating which channels are busy. The
channel-list parameter in a PHY-CCA.indication primitive generated by a VHT STA contains at most a
single element. Table 8-5 defines the members of this set.
Table 8-5—The channel-list parameter elements
channel-list element Meaning
primary In an HT STA that is not a VHT STA, indicates that the primary 20 MHz
channel is busy.
In a VHT STA, indicates that the primary 20 MHz channel is busy
according to the rules specified in 21.3.18.5.3.
In a TVHT STA, indicates that the primary channel is busy according to
the rules specified in 22.3.18.6.3.
secondary In an HT STA that is not a VHT STA, indicates that the secondary channel
is busy.
In a VHT STA, indicates that the secondary 20 MHz channel is busy
according to the rules specified in 21.3.18.5.4.
In a TVHT STA, indicates that the secondary channel is busy according to
the rules specified in 22.3.18.6.4.
secondary40 Indicates that the secondary 40 MHz channel is busy according to the rules
specified in 21.3.18.5.4.
In a TVHT STA, indicates that the secondary TVHT_2W channel is busy
according to the rules specified in 22.3.18.6.4.
secondary80 Indicates that the secondary 80 MHz channel is busy according to the rules
specified in 21.3.18.5.4.
The relationship of the channel-list parameter elements to the 40 MHz, 80 MHz, and 160 MHz BSS
operating channel is illustrated by example in Figure 8-1. The relationship of the channel-list parameter
elements to the 80+80 MHz BSS operating channel is illustrated by example in Figure 8-2.
629
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
secondary80
secondary40
secondary
primary
40 MHz
80 MHz
160 MHz
Figure 8-1—The channel-list parameter element for 40 MHz, 80 MHz,
and 160 MHz channel width
secondary80
secondary40
secondary
primary
80+80 MHz
Figure 8-2—The channel-list parameter element for 80+80 MHz channel width
For a TVHT STA, the relationship of the channel-list parameter elements to the TVHT_W, TVHT_2W, and
TVHT_W+W BSS operating channel is illustrated in Figure 8-3.
NOTE–This channel not present
for TVHT_W
1 BCU 1 BCU
f[MHz]
0-n BCUs:
0 for TVHT_2W
1-n for TVHT_W+W,
where n depends on operating class
primary: any single BCU channel
secondary: the non-primary TVHT_W channel
Figure 8-3—TVHT channel-list parameter element and channel bandwidth for TVHT_W,
TVHT_2W, and TVHT_W+W
630
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For a TVHT STA, the relationship of the channel-list parameter elements to the TVHT_4W and
TVHT_2W+2W BSS operating channel is illustrated in Figure 8-4.
1 BCU 1 BCU 1 BCU 1 BCU
f [MHz]
TVHT_2W 0-n BCUs:
0 for TVHT_4W
1-n for TVHT_2W+2W,
where n depends on operating class
primary: any single BCU channel
secondary: the non-primary TVHT_W channel in the same TVHT_2W channel group
secondary40: the TVHT_2W channel group that does not contain the primaryTVHT_W
Figure 8-4—TVHT channel-list parameter element and channel bandwidth for TVHT_4W
and TVHT_2W+2W
8.3.5.12.3 When generated
For Clause 15 to Clause 20 PHYs, this primitive is generated within aCCATime of the occurrence of a
change in the status of the primary channel from channel idle to channel busy or from channel busy to
channel idle or when the elements of the channel-list parameter change. For Clause 21 and Clause 22 PHYS,
this primitive is generated when the status of the channel(s) changes from channel idle to channel busy or
from channel busy to channel idle or when the elements of the channel-list parameter change. This includes
the period of time when the PHY is receiving data. The timing of PHY-CCA.indication primitives related to
transitions on secondary channel(s) is PHY specific. Refer to specific PHY clauses for details about CCA
behavior for a given PHY.
NOTE—For the VHT PHY, the timing information is omitted here and is defined in 21.3.18.5.
If the STA is an HT STA but not a VHT STA and the operating channel width is 20 MHz, the PHY
maintains the channel busy indication until the period indicated by the LENGTH field has expired, where
the LENGTH field is
— In a valid SIG field if the format of the PPDU is NON_HT
— In a valid HT-SIG field if the format of the PPDU is HT_MF or HT_GF
If the STA is an HT STA but not a VHT STA and the operating channel width is 40 MHz, the PHY
maintains the channel busy indication until the period indicated by the LENGTH field has expired, where
the LENGTH field is
— In a valid SIG field if the format of the PPDU is NON_HT and the PPDU is received in the primary
channel
— In a valid HT-SIG field if the format of the PPDU is HT_MF or HT_GF provided that the PPDU is
either a 20 MHz PPDU received in the primary channel or a 40 MHz PPDU
8.3.5.12.4 Effect of receipt
The effect of receipt of this primitive by the MAC is unspecified.
631
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.5.13 PHY-RXSTART.indication
8.3.5.13.1 Function
This primitive is an indication by the PHY to the local MAC entity that the PHY has received a valid start of
a PPDU, including a valid PHY header.
NOTE—This primitive is not generated until the PHY has determined the PPDU format (e.g., a VHT PPDU, which
starts with an HT PHY header).
8.3.5.13.2 Semantics of the service primitive
The primitive provides the following parameter:
PHY-RXSTART.indication(
RXVECTOR
)
The RXVECTOR represents a list of parameters that the PHY provides the local MAC entity upon receipt of
a valid PHY header. The required parameters are listed in 8.3.4.4.
8.3.5.13.3 When generated
This primitive is generated by the local PHY entity to the MAC sublayer when the PHY has successfully
validated the PHY header at the start of a new PPDU.
After generating a PHY-RXSTART.indication primitive, the PHY is expected to maintain physical medium
busy status (not generating a PHY-CCA.indication(IDLE) primitive) during the period required by that PHY
to transfer a frame of the indicated LENGTH at the indicated DATARATE. This physical medium busy
condition should be maintained even if a PHY-RXEND.indication(CarrierLost) primitive or a
PHY-RXEND.indication(FormatViolation) primitive is generated by the PHY prior to the end of this period.
8.3.5.13.4 Effect of receipt
The effect of receipt of this primitive by the MAC is unspecified.
8.3.5.14 PHY-RXEND.indication
8.3.5.14.1 Function
This primitive is an indication by the PHY to the local MAC entity that the PPDU currently being received
is complete.
8.3.5.14.2 Semantics of the service primitive
The primitive provides the following parameters:
PHY-RXEND.indication(
RXERROR,
RXVECTOR
)
The RXERROR parameter can convey NoError or one or more values indicating an error condition. A
number of error conditions may occur after the PHY’s receive state machine has detected what appears to be
a valid preamble and SFD. The following describes the parameter returned for each of those error
conditions.
632
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— NoError. This value is used to indicate that no error occurred during the receive process in the PHY.
— FormatViolation. This value is used to indicate that the format of the received PPDU was in error.
— CarrierLost. This value is used to indicate that during the reception of the incoming PSDU, the
carrier was lost and no further processing of the PSDU can be accomplished.
— UnsupportedRate. This value is used to indicate that during the reception of the incoming PPDU, a
nonsupported date rate was detected.
— Filtered. This value is used to indicate that during the reception of the PPDU, the PPDU was filtered
out due to a condition set in the PHYCONFIG_VECTOR.
NOTE—The filtered condition might occur in a VHT STA due to GROUP_ID or PARTIAL_AID filtering in
the PHY.
The RXVECTOR represents a list of parameters that the PHY provides the local MAC entity. RXVECTOR
is an included parameter only when dot11RadioMeasurementActivated is true. The required parameters are
listed in 8.3.4.4.
8.3.5.14.3 When generated
This primitive is generated by the PHY for the local MAC entity to indicate that the receive state machine
has completed a reception with or without errors. When a Signal Extension is present, the primitive is
generated at the end of the Signal Extension.
In the case of an RXERROR value of NoError, the MAC uses the PHY-RXEND.indication primitive as
reference for channel access timing, as shown in Figure 10-19 (in 10.3.7) and Figure 10-26.
8.3.5.14.4 Effect of receipt
The effect of receipt of this primitive is for the MAC to begin inter-frame space processing, as described in
10.3.7 and 10.22.2.4.
8.3.5.15 PHY-CONFIG.request
8.3.5.15.1 Function
This primitive is a request by the MAC sublayer to the local PHY entity to configure the PHY.
8.3.5.15.2 Semantics of the service primitive
The primitive provides the following parameter:
PHY-CONFIG.request(
PHYCONFIG_VECTOR
)
8.3.5.15.3 When generated
This primitive is generated by the MAC sublayer for the local PHY entity when it desires to change the
configuration of the PHY.
8.3.5.15.4 Effect of receipt
The effect of receipt of this primitive by the PHY is to apply the parameters provided with the primitive and
to configure the PHY for future operation.
633
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.3.5.16 PHY-CONFIG.confirm
8.3.5.16.1 Function
This primitive is issued by the PHY to the local MAC entity to confirm that the PHY has applied the
parameters provided in the PHY-CONFIG.request primitive.
8.3.5.16.2 Semantics of the service primitive
The semantics of the primitive are as follows:
PHY-CONFIG.confirm
This primitive has no parameters.
8.3.5.16.3 When generated
This primitive is issued by the PHY to the MAC entity when the PHY has received and successfully applied
the parameters in the PHY-CONFIG.request primitive.
8.3.5.16.4 Effect of receipt
The effect of the receipt of this primitive by the MAC is unspecified.
8.3.5.17 PHY-TXBUSY.indication
8.3.5.17.1 Function
This primitive is an indication by the PHY to the local MAC entity(ies) of the current transmission state of
the PHY.
8.3.5.17.2 Semantics of the service primitive
The primitive provides the following parameter:
PHY-TXBUSY.indication (STATE)
The STATE parameter can be one of two values: BUSY or IDLE. The parameter value is BUSY if the PHY
is transmitting a PPDU and thus not available to respond with a PHY-TXSTART.confirm primitive to a
PHY-TXSTART.request primitive. Otherwise, the value of the parameter is IDLE.
8.3.5.17.3 When generated
The primitive is generated when the PHY issues a PHY-TXSTART.confirm primitive to one of the MAC
entities coordinated by an MM-SME, and it is generated to all coordinated MAC entities except to the one to
which it responds with the PHY-TXSTART.confirm primitive. The STATE of the primitive is set to BUSY.
This primitive is generated within aTxPHYDelay of the occurrence of a change in the state of the PHY
transmit state machine to the RX state. In this case, the STATE of the primitive is set to IDLE.
8.3.5.17.4 Effect of receipt
The effect of receipt of this primitive by the MAC is unspecified if the STATE of the primitive is set to
IDLE. The effect of receipt of this primitive by the MAC is specified in 10.22.2.11 if the STATE of the
primitive is set to BUSY.
634
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8.4 PHY management
The MIB comprises the managed objects, attributes, actions, and notifications required to manage a STA.
The definition of these managed objects, attributes, actions, and notifications, as well as their structure, is
presented in Annex C.
635
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9. Frame formats
9.1 General requirements
The format of the MAC frames is specified in this clause. A STA shall be able to properly construct a subset
of the frames specified in this clause for transmission and to decode a (potentially different) subset of the
frames specified in this clause upon validation following reception. The particular subset of these frames
that a STA constructs and decodes is determined by the functions supported by that particular STA. A STA
shall be able to validate every received frame using the frame check sequence (FCS) and to interpret certain
fields from the MAC headers of all frames.
A STA shall transmit frames using only the frame formats described in Clause 9.
9.2 MAC frame formats
9.2.1 Basic components
Each frame consists of the following basic components:
a) A MAC header, which comprises frame control, duration, address, optional sequence control
information, optional QoS Control information (QoS Data frames only), and optional HT Control
fields (+HTC frames only);
b) A variable-length frame body, which contains information specific to the frame type and subtype;
c) An FCS, which contains a 32-bit CRC based on ITU-T V.42 [B53].
9.2.2 Conventions
Structures defined in the MAC sublayer are described as a sequence of components (e.g., fields, subfields,
elements and subelements) in specific order. Each figure and table in Clause 9 depicts the components as
they appear in the MAC frame and in the order in which they are passed to the physical layer (PHY), from
left to right and then from top to bottom.
In figures, all bits within fields are numbered, from 0 to k, where the length of the field is k + 1 bits. Bits
within numeric fields that are longer than a single bit are depicted in increasing order of significance, i.e.,
with the lowest numbered bit having the least significance. The octet boundaries within a field can be
obtained by taking the bit numbers of the field modulo 8. Octets within numeric fields that are longer than a
single octet are depicted in increasing order of significance, from lowest numbered bit to highest numbered
bit. The octets in fields longer than a single octet are sent to the PHY in order from the octet containing the
lowest numbered bits to the octet containing the highest numbered bits.
Any field containing a CRC is an exception to this convention and is transmitted commencing with the
coefficient of the highest-order term.
MAC addresses are assigned as ordered sequences of bits. The Individual/Group bit is always transferred
first and is bit 0 of the first octet.
Organizationally unique identifiers (OUIs), Company IDs (CIDs), and Organization Identifiers are specified
in two forms: an ordered sequence of octets, and a numeric form. Treating the OUI, CID, or Organization
Identifier as an ordered sequence of octets, the leftmost octet is always transferred first. This is equivalent to
transmitting the most significant octet of the numeric form first.
Values specified in decimal are coded in natural binary unless otherwise stated. The values in Table 9-1 are
in binary, with the bit assignments shown in the table. Values in other tables are shown in decimal notation.
636
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An ASCII or UTF-8 string a sequence of ASCII-encoded octets without a terminating null.
For evaluation purposes a nonce is interpreted as a sequence of octets with the most significant octet first
and the most significant bit of an octet first.
Reception, in references to frames or fields within frames (e.g., received Beacon frames or a received
Duration/ID field), applies to MPDUs indicated from the PHY without error and validated by FCS within
the MAC sublayer. Without further qualification, reception by the MAC sublayer implies that the frame
contents are valid, and that the protocol version is supported (see 9.2.4.1.2), with no implication regarding
frame addressing or regarding whether the frame type or other fields in the MAC header are meaningful to
the MAC entity that has received the frame.
A frame that contains the HT Control field is referred to as a +HTC frame. A Control Wrapper frame is a
+HTC frame.
A QoS Data frame that is transmitted by a mesh STA is referred to as a mesh Data frame.
NOTE—Subclause 9.2.4.1.4 constrains the setting of the From DS and To DS subfields in mesh Data frames.
Parentheses enclosing portions of names or acronyms are used to designate a set of related names that vary
based on the inclusion of the parenthesized portion. For example,
— QoS +CF-Poll frame refers to the three QoS data subtypes that include “+CF-Poll”: the QoS Data
+CF-Poll frame, subtype 1010; QoS Data +CF-Ack +CF-Poll frame, subtype 1011; and QoS CF-
Ack +CF-Poll frame, subtype 1111.
— QoS CF-Poll frame refers specifically to the QoS CF-Poll frame, subtype 1110.
— QoS (+)CF-Poll frame refers to all four QoS data subtypes with CF-Poll: the QoS CF-Poll frame,
subtype 1110; the QoS CF-Ack +CF-Poll frame, subtype 1111; the QoS Data +CF-Poll frame,
subtype 1010; and the QoS Data +CF-Ack +CF-Poll frame, subtype 1011.
— QoS (+)Null frame refers to all three QoS data subtypes with “no data”: the QoS Null (no data)
frame, subtype 1100; the QoS CF-Poll (no data) frame, subtype 1110; and the QoS CF-Ack +CF-
Poll frame, subtype 1111.
— QoS +CF-Ack frame refers to the three QoS data subtypes that include “+CF-Ack”: the QoS Data
+CF-Ack frame, subtype 1001; QoS Data +CF-Ack +CF-Poll frame, subtype 1011; and QoS CF-
Ack +CF-Poll frame, subtype 1111.
— Whereas (QoS) CF-Poll frame refers to the QoS CF-Poll frame, subtype 1110, and the CF-Poll
frame, subtype 0110.
Reserved fields and subfields are set to 0 upon transmission and are ignored upon reception.
9.2.3 General frame format
The MAC frame format comprises a set of fields that occur in a fixed order in all frames. Figure 9-1 depicts
the general MAC frame format. The first three fields (Frame Control, Duration/ID, and Address 1) and the
last field (FCS) in Figure 9-1 constitute the minimal frame format and are present in all frames, including
reserved types and subtypes. The fields Address 2, Address 3, Sequence Control, Address 4, QoS Control,
HT Control, and Frame Body are present only in certain frame types and subtypes. Each field is defined in
9.2.4. The format of each of the individual subtypes of each frame type is defined in 9.3. The components of
management frame bodies are defined in 9.4. The formats of Action frames are defined in 9.6.
The Frame Body field is of variable size, constrained as defined in 9.2.4.7.1.
637
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Octets: 2 2 6 0 or 6 0 or 6 0 or 2 0 or 6 0 or 2 0 or 4 variable 4
Frame Duration Address Address Address Sequence Address QoS HT Frame
Control /ID 1 2 3 Control 4 Control Control Body FCS
MAC header
Figure 9-1—MAC frame format
9.2.4 Frame fields
9.2.4.1 Frame Control field
9.2.4.1.1 General
The first three subfields of the Frame Control field are Protocol Version, Type, and Subtype. The remaining
subfields of the Frame Control field depend on the setting of the Type and Subtype subfields.
When the value of the Type subfield is not equal to 1 or the value of the Subtype subfield is not equal to 6,
the remaining subfields within the Frame Control field are To DS, From DS, More Fragments, Retry, Power
Management, More Data, Protected Frame, and +HTC/Order. In this case, the format of the Frame Control
field is illustrated in Figure 9-2.
B0 B1 B2 B3 B4 B7 B8 B9 B10 B11 B12 B13 B14 B15
Protocol Type Subtype To From More Retry Power More Protected +HTC/
Version DS DS Frag- Management Data Frame Order
ments
Bits: 2 2 4 1 1 1 1 1 1 1 1
Figure 9-2—Frame Control field when Type is not equal to 1 or Subtype is not equal to 6
When the value of the Type subfield is equal to 1 and the value of the Subtype subfield is equal to 6, the
remaining subfields within the Frame Control field are the following: Control Frame Extension, Power
Management, More Data, Protected Frame, and +HTC/Order. In this case, the format of the Frame Control
field is illustrated in Figure 9-3.
B0 B1 B2 B3 B4 B7 B8 B11 B12 B13 B14 B15
Protocol Type Subtype Control Frame Power More Protected +HTC/
Version Extension Management Data Frame Order
Bits: 2 2 4 4 1 1 1 1
Figure 9-3—Frame Control field when Type is equal to 1 and Subtype is equal to 6
9.2.4.1.2 Protocol Version subfield
The Protocol Version subfield is 2 bits in length and is invariant in size and placement across all revisions of
this standard. For this standard, the value of the protocol version is 0. All other values are reserved. The
revision level is incremented only when a fundamental incompatibility exists between a new revision and
the prior edition of the standard. See 10.27.2.
9.2.4.1.3 Type and Subtype subfields
The Type subfield is 2 bits in length, and the Subtype subfield is 4 bits in length. The Type and Subtype
subfields together identify the function of the frame. There are three frame types: control, data, and
638
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
management. Each of the frame types has several defined subtypes. In Data frames, the most significant bit
(MSB) of the Subtype subfield, B7, is defined as the QoS subfield. Table 9-1 defines the valid combinations
of type and subtype. (The numeric values in Table 9-1 are shown in binary.)
Table 9-1—Valid type and subtype combinations
Type value Type Subtype value
Subtype description
B3 B2 description B7 B6 B5 B4
00 Management 0000 Association Request
00 Management 0001 Association Response
00 Management 0010 Reassociation Request
00 Management 0011 Reassociation Response
00 Management 0100 Probe Request
00 Management 0101 Probe Response
00 Management 0110 Timing Advertisement
00 Management 0111 Reserved
00 Management 1000 Beacon
00 Management 1001 ATIM
00 Management 1010 Disassociation
00 Management 1011 Authentication
00 Management 1100 Deauthentication
00 Management 1101 Action
00 Management 1110 Action No Ack
00 Management 1111 Reserved
01 Control 0000–0011 Reserved
01 Control 0100 Beamforming Report Poll
01 Control 0101 VHT NDP Announcement
01 Control 0110 Control Frame Extension
01 Control 0111 Control Wrapper
01 Control 1000 Block Ack Request (BlockAckReq)
01 Control 1001 Block Ack (BlockAck)
01 Control 1010 PS-Poll
01 Control 1011 RTS
01 Control 1100 CTS
01 Control 1101 Ack
01 Control 1110 CF-End
01 Control 1111 CF-End +CF-Ack
10 Data 0000 Data
10 Data 0001 Data +CF-Ack
10 Data 0010 Data +CF-Poll
639
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-1—Valid type and subtype combinations (continued)
Type value Type Subtype value
Subtype description
B3 B2 description B7 B6 B5 B4
10 Data 0011 Data +CF-Ack +CF-Poll
10 Data 0100 Null (no data)
10 Data 0101 CF-Ack (no data)
10 Data 0110 CF-Poll (no data)
10 Data 0111 CF-Ack +CF-Poll (no data)
10 Data 1000 QoS Data
10 Data 1001 QoS Data +CF-Ack
10 Data 1010 QoS Data +CF-Poll
10 Data 1011 QoS Data +CF-Ack +CF-Poll
10 Data 1100 QoS Null (no data)
10 Data 1101 Reserved
10 Data 1110 QoS CF-Poll (no data)
10 Data 1111 QoS CF-Ack +CF-Poll (no data)
11 Extension 0000 DMG Beacon
11 Extension 0001–1111 Reserved
Each Subtype subfield bit position is used to indicate a specific modification of the basic Data frame
(subtype 0). Frame Control bit 4 is set to 1 in data subtypes that include +CF-Ack, bit 5 is set to 1 in data
subtypes that include +CF-Poll, bit 6 is set to 1 in data subtypes that contain no Frame Body field, and bit 7
is set to 1 in the QoS data subtypes, which have QoS Control fields in their MAC headers.
The Control Frame Extension subtype is used to increase the subtype space by reusing bits B8–B11. These
additional Control frames are defined in Table 9-2.
Table 9-2—Control Frame Extension
Type value Subtype value Control Frame Extension value
Description
B3 B2 B7 B6 B5 B4 B11 B10 B9 B8
01 0110 0000 Reserved
01 0110 0001 Reserved
01 0110 0010 Poll
01 0110 0011 SPR
01 0110 0100 Grant
01 0110 0101 DMG CTS
01 0110 0110 DMG DTS
01 0110 0111 Grant Ack
01 0110 1000 SSW
640
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-2—Control Frame Extension (continued)
Type value Subtype value Control Frame Extension value
Description
B3 B2 B7 B6 B5 B4 B11 B10 B9 B8
01 0110 1001 SSW-Feedback
01 0110 1010 SSW-Ack
01 0110 1011–1111 Reserved
9.2.4.1.4 To DS and From DS subfields
The meaning of the combinations of values for the To DS and From DS subfields in Data frames are shown
in Table 9-3.
Table 9-3—To/From DS combinations in Data frames
To DS and
Meaning
From DS values
To DS = 0 A Data frame from one STA to another STA within the same IBSS or the same PBSS, a Data
From DS = 0 frame direct from one non-AP STA to another non-AP STA within the same infrastructure
BSS, or a Data frame outside the context of a BSS.
This is the only valid combination for Data frames transmitted by an IBSS or PBSS STA, or
outside the context of a BSS.
To DS = 1 A Data frame destined for the DS or being sent by a STA associated with an AP to the Port
From DS = 0 Access Entity in that AP.
To DS = 0 A Data frame exiting the DS or being sent by the Port Access Entity in an AP, or a group
From DS = 1 addressed mesh Data frame with the Mesh Control field present using the three-address MAC
header format.
This is the only valid combination for Data frames transmitted by an AP and group addressed
Data frames transmitted by a mesh STA.
To DS = 1 A Data frame using the four-address MAC header format. This standard defines procedures
From DS = 1 for using this combination of field values only in a mesh BSS.
This is the only valid combination for individually addressed Data frames transmitted by a
mesh STA.
The meanings of the combinations of values of the management frame To DS and From DS subfields are
shown in Table 9-4.
In Control frames, To DS and From DS, when present, are both zero.
NOTE—In Control frames of subtype Control Frame Extension, the To DS and From DS subfields are not defined, and
their bit positions are part of the Control Frame Extension field (see 9.2.4.1.3, Table 9-2).
641
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-4—To/From DS combinations in Management frames
To DS and
Meaning
From DS values
To DS = 0 All non-QMF Management frames.
From DS = 0
To DS = 1 All QMF Management frames.
From DS = 0
To DS = 0 This combination is reserved.
From DS = 1
To DS = 1 This combination is reserved.
From DS = 1
9.2.4.1.5 More Fragments subfield
The More Fragments subfield is 1 bit in length and is set to 1 in all Data or Management frames that have
another fragment of the current MSDU or current MMPDU to follow. It is set to 0 in all other frames in
which the More Fragments subfield is present.
NOTE—In Control frames of subtype Control Frame Extension, the More Fragments subfield is not present, and its bit
position is part of the Control Frame Extension field (see 9.2.4.1.3, Table 9-2).
9.2.4.1.6 Retry subfield
The Retry subfield is 1 bit in length and is set to 1 in any Data or Management frame that is a retransmission
of an earlier frame, except as specified in 10.24.3. It is set to 0 in all other frames in which the Retry subfield
is present. A receiving STA uses this indication to aid in the process of eliminating duplicate frames.
NOTE—In Control frames of subtype Control Frame Extension, the Retry subfield is not present, and its bit
position is part of the Control Frame Extension field (see 9.2.4.1.3, Table 9-2).
9.2.4.1.7 Power Management subfield
The Power Management subfield is 1 bit in length and is used to indicate the power management mode of a
STA. The value of this subfield is either reserved (as defined below) or remains constant in each frame from
a particular STA within a frame exchange sequence (see Annex G). The value indicates the mode of the
STA after the successful completion of the frame exchange sequence.
In an infrastructure BSS or PBSS, the following applies:
— The Power Management subfield is valid only in frame exchanges as described in 11.2.3 and 11.2.7.
In such exchanges, a value of 1 indicates that the STA will be in PS mode. A value of 0 indicates
that the STA will be in active mode.
— The Power Management subfield is reserved in all Management frames transmitted by a STA to an
AP or PCP with which it is not associated.
— The Power Management subfield is reserved in all frames transmitted by the AP.
In an IBSS, the Power Management subfield is valid only in certain frames as described in 11.2.4.4. In such
frames, a value of 1 indicates that the STA will be in PS mode. A value of 0 indicates that the STA will be in
active mode.
642
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In an MBSS, the Power Management subfield is valid only in frame exchanges as described per the mesh
power management mode transitions rules in 14.14. In such exchanges, the value indicates the STA’s power
management mode (see 14.14).
9.2.4.1.8 More Data subfield
The More Data subfield is 1 bit in length and is used differently by a non-DMG STA and by a DMG STA.
A non-DMG STA uses the More Data subfield to indicate to a STA in PS mode that more BUs are buffered
for that STA at the AP. The More Data subfield is valid in individually addressed Data or Management
frames transmitted by an AP to a STA in PS mode. A value of 1 indicates that at least one additional
buffered BU is present for the same STA.
A non-DMG STA optionally sets the More Data subfield to 1 in individually addressed data type frames
transmitted by a CF-Pollable STA to the PC in response to a CF-Poll to indicate that the STA has at least one
additional buffered MSDU available for transmission in response to a subsequent CF-Poll.
An AP optionally sets the More Data subfield to 1 in Ack frames to a non-DMG STA from which it has
received a frame that contains a QoS Capability element in which the More Data Ack subfield is equal to 1
and that has one or more ACs that are delivery enabled and that is in PS mode to indicate that the AP has a
pending transmission for the STA.
A TDLS peer STA optionally sets the More Data subfield to 1 in Ack frames to a STA that has TDLS peer
PSM enabled and that has the More Data Ack subfield equal to 1 in the QoS Capability element of its
transmitted TDLS Setup Request frame or TDLS Setup Response frame to indicate that it has a pending
transmission for the STA.
The More Data subfield is 1 in individually addressed frames transmitted by a mesh STA to a peer mesh
STA that is either in light sleep mode or in deep sleep mode for the corresponding mesh peering, when
additional BUs remain to be transmitted to this peer mesh STA.
The More Data subfield is set to 1 in individually addressed frames transmitted by a VHT AP to a VHT STA
when both support the VHT TXOP power save feature (as determined from their VHT Capabilities
elements) to indicate that at least one additional buffered BU is present for the STA. See 11.2.3.19.
A non-DMG STA sets the More Data subfield to 0 in all other individually addressed frames.
A non-DMG STA sets the More Data subfield to 1 in non-GCR-SP group addressed frames transmitted by
the AP when additional group addressed bufferable units (BUs) that are not part of an active GCR-SP
remain to be transmitted by the AP during this beacon interval. The More Data subfield is set to 0 in non-
GCR-SP group addressed frames transmitted by the AP when no more group addressed BUs that are not part
of an active GCR-SP remain to be transmitted by the AP during this beacon interval and in all group
addressed frames transmitted by non-AP STAs.
The More Data subfield is set to 1 in GCR-SP group addressed frames transmitted by the AP when
additional group addressed BUs that are part of an active GCR-SP remain to be transmitted by the AP during
this GCR-SP. The More Data subfield is set to 0 in GCR-SP group addressed frames transmitted by the AP
when no more group addressed BUs that are part of an active GCR-SP remain to be transmitted by the AP
during this GCR-SP.
The More Data subfield is 1 in group addressed frames transmitted by a mesh STA when additional group
addressed BUs remain to be transmitted. The More Data subfield is 0 in group addressed frames transmitted
by a mesh STA when no more group addressed BUs remain to be transmitted.
643
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A DMG STA sets the More Data subfield as follows:
— In individually addressed frames, it is set to 1 to indicate that the STA has MSDUs or A-MSDUs
buffered for transmission to the frame’s recipient during the current SP or TXOP.
— It is set to 1 in group addressed frames transmitted by the AP when additional group addressed BUs
remain to be transmitted by the AP during this beacon interval. The More Data subfield is set to 0 in
group addressed frames transmitted by the AP when no more group addressed BUs remain to be
transmitted by the AP during this beacon interval.
A DMG STA does not set the More Data bit to 1 if it does not have any MSDUs or A-MSDUs buffered for
transmission to the frame’s recipient during the current SP or TXOP.
9.2.4.1.9 Protected Frame subfield
The Protected Frame subfield is 1 bit in length. The Protected Frame subfield is set to 1 if the Frame Body
field contains information that has been processed by a cryptographic encapsulation algorithm. The
Protected Frame subfield is reserved in Control frames of subtype Control Frame Extension. When the
Protected Frame subfield is equal to 1, the Frame Body field is protected utilizing the cryptographic
encapsulation algorithm and expanded as defined in Clause 12. The Protected Frame subfield is set to 0 in
Data frames of subtype Null, CF-Ack (no data), CF-Poll (no data), CF-Ack +CF-Poll (no data), QoS Null
(no data), QoS CF-Poll (no data), and QoS CF-Ack +CF-Poll (no data) (see, for example, 12.5.2.2 and
12.5.3.1 that show that the frame body needs to be 1 octet or longer to apply the encapsulation).
9.2.4.1.10 +HTC/Order subfield
The +HTC/Order subfield is 1 bit in length. It is used for two purposes:
— It is set to 1 in a non-QoS Data frame transmitted by a non-QoS STA to indicate that the frame
contains an MSDU, or fragment thereof, that is being transferred using the StrictlyOrdered service
class.
— It is set to 1 in a QoS Data or Management frame transmitted with a value of HT_GF, HT_MF, or
VHT for the FORMAT parameter of the TXVECTOR to indicate that the frame contains an HT
Control field.
Otherwise, the +HTC/Order subfield is set to 0.
NOTE—The +HTC/Order subfield is always set to 0 for frames transmitted by a DMG STA.
9.2.4.2 Duration/ID field
The Duration/ID field is 16 bits in length. The contents of this field vary with frame type and subtype, with
whether the frame is transmitted during the CFP, and with the QoS capabilities of the sending STA. The
contents of the field are defined as follows:
a) In Control frames of subtype PS-Poll, the Duration/ID field carries the association identifier (AID)
of the STA that transmitted the frame in the 14 least significant bits (LSB), and the 2 most
significant bits (MSB) both set to 1.
b) In frames transmitted by the PC and non-QoS STAs, during the CFP, the Duration/ID field is set to
a fixed value of 32 768.
c) In all other frames sent by non-QoS STAs and Control frames sent by QoS STAs, the Duration/ID
field contains a duration value as defined for each frame type in 9.3.
d) In Data and Management frames sent by QoS STAs, the Duration/ID field contains a duration value
as defined for each frame type in 9.2.5.
See 10.27.3 on the processing of this field in received frames.
644
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The encoding of the Duration/ID field is given in Table 9-5.
Table 9-5—Duration/ID field encoding
Bits 0–13 Bit 14 Bit 15 Usage
0–32 767 0 Duration value (in microseconds) within all frames except:
— PS-Poll frames transmitted during the CP
— frames transmitted during the CFP using the HCF
0 0 1 Fixed value under point coordination function (PCF) within
frames transmitted during the CFP.
1–16 383 0 1 Reserved
0 1 1 Reserved
1–2007 1 1 AID in PS-Poll frames.
2008–16 383 1 1 Reserved
See also 9.7.3 on the setting of the Duration/ID field of MAC headers of MPDUs in an A-MPDU.
9.2.4.3 Address fields
9.2.4.3.1 General
There are four address fields in the MAC frame format. These fields are used to indicate the basic service set
identifier (BSSID), source address (SA), destination address (DA), transmitting STA address (TA), and
receiving STA address (RA). Certain frames might not contain some of the address fields.
Certain address field usage is specified by the relative position of the address field (1–4) within the MAC
header, independent of the type of address present in that field. For example, receiver address matching is
always performed on the contents of the Address 1 field in received frames, and the receiver address of CTS
and Ack frames is always obtained from the Address 2 field in the corresponding RTS frame, or from the
frame being acknowledged.
9.2.4.3.2 Address representation
Each Address field contains a 48-bit address as defined in Clause 8 of IEEE Std 802-2014.
9.2.4.3.3 Address designation
A MAC sublayer address is one of the following two types:
a) Individual address. The address assigned to a particular STA on the network.
b) Group address. A multidestination address, which might be in use by one or more STAs on a given
network. The two kinds of group addresses are as follows:
1) Multicast-group address. An address associated by higher level convention with a group of
logically related STAs.
2) Broadcast address. A distinguished, predefined group address that always denotes the set of all
STAs on a given LAN. All 1s are interpreted to be the broadcast address. This group is
predefined for each communication medium to consist of all STAs actively connected to that
medium; it is used to broadcast to all of the active STAs on that medium.
645
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The address space is also partitioned into locally administered and universal (globally administered)
addresses. The nature of a body and the procedures by which it administers these universal (globally
administered) addresses is beyond the scope of this standard. See IEEE Std 802-2014 for more information.
9.2.4.3.4 BSSID field
The BSSID field is a 48-bit field of the same format as an IEEE 802 MAC address. When
dot11OCBActivated is false, the value of this field uniquely identifies each BSS. The value of this field, in
an infrastructure BSS, is the MAC address currently in use by the STA in the AP of the BSS.
The value of this field in a PBSS is the MAC address of the PCP.
The value of this field in an IBSS is a locally administered IEEE MAC address formed from a 46-bit random
number generated according to the procedure defined in 11.1.4. The Individual/Group bit of the address is
set to 0. The Universal/Local bit of the address is set to 1. This mechanism is used to provide a high
probability of selecting a unique BSSID.
The value of all 1s is used to indicate the wildcard BSSID. The wildcard value is not used in the BSSID field
except where explicitly permitted in this standard. When dot11OCBActivated is true, the wildcard value is
used in the BSSID field. When dot11OCBActivated is false and the BSSID field contains the wildcard
value, the Address 1 (DA) field is also set to all 1s to indicate the broadcast address.
9.2.4.3.5 DA field
The DA field contains an IEEE MAC individual or group address that identifies the MAC entity or entities
intended as the final recipient(s) of the MSDU (or fragment thereof) or A-MSDU, as defined in 9.3.2.1,
contained in the frame body field.
9.2.4.3.6 SA field
The SA field contains an IEEE MAC individual address that identifies the MAC entity from which the
transfer of the MSDU (or fragment thereof) or A-MSDU, as defined in 9.3.2.1, contained in the frame body
field was initiated. The Individual/Group bit is always transmitted as a 0 in the source address.
9.2.4.3.7 RA field
The RA field contains an IEEE MAC individual or group address that identifies the intended immediate
recipient STA(s), on the WM, for the information contained in the frame body field.
9.2.4.3.8 TA field
The TA field contains an IEEE MAC address that identifies the STA that has transmitted, onto the WM, the
MPDU contained in the frame body field. If the Individual/Group bit is 0, then the TA field is the individual
address of the STA; otherwise, the TA field is a bandwidth signaling TA, indicating that the frame carries
additional information in the scrambling sequence (see 9.3.1.2, 10.7.6.6, and 10.7.11).
9.2.4.4 Sequence Control field
9.2.4.4.1 Sequence Control field structure
The Sequence Control field is 16 bits in length and consists of two subfields, the Sequence Number and the
Fragment Number. The format of the Sequence Control field is illustrated in Figure 9-4. The Sequence
Control field is not present in Control frames.
646
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B3 B4 B15
Fragment Number Sequence Number
Bits: 4 12
Figure 9-4—Sequence Control field
9.2.4.4.2 Sequence Number field
Each MSDU, A-MSDU, or MMPDU is assigned a sequence number. See 10.3.2.11. Sequence numbers are
not assigned to Control frames, as the Sequence Control field is not present in those frames.
The Sequence Number field in Data frames is a 12-bit field indicating the sequence number of the MSDU or
A-MSDU.
The Sequence Number field in QMFs comprises the QMF Sequence Number subfield and the AC Index
(ACI) subfield. The QMF Sequence Number subfield is a 10-bit subfield indicating the sequence number of
the frame. The ACI subfield is a 2-bit subfield indicating the ACI of the frame. The format of the Sequence
Number field in QMFs is shown in Figure 9-5.
B4 B13 B14 B15
QMF Sequence Number ACI
Bits: 10 2
Figure 9-5—Sequence Number field in QMFs
The value of the ACI subfield represents the ACI of the frame as defined in 9.4.2.29.
The Sequence Number field in Management frames that are not QMFs is a 12-bit field indicating the
sequence number of the frame.
Each fragment of an MSDU or MMPDU contains a copy of the sequence number assigned to that MSDU or
MMPDU. The sequence number remains constant in all retransmissions of an MSDU, MMPDU, or
fragment thereof, except when the MSDU is delivered via both DMS and group addressed delivery via
NoAck, GCR unsolicited retry, or GCR block ack retransmission policies. In such cases, the sequence
numbers assigned to the MSDUs (re)transmitted using group addressed delivery need not match the
sequence number of the corresponding individually addressed A-MSDUs delivered via DMS.
9.2.4.4.3 Fragment Number field
The Fragment Number field is a 4-bit field indicating the number of each fragment of an MSDU or
MMPDU. The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU and is
incremented by one for each successive fragment of that MSDU or MMPDU. The fragment number is set to
0 in the only fragment of an A-MSDU. The fragment number remains constant in all retransmissions of the
fragment.
9.2.4.5 QoS Control field
9.2.4.5.1 QoS Control field structure
The QoS Control field is a 16-bit field that identifies the TC or TS to which the frame belongs as well as
various other QoS-related, A-MSDU related, and mesh-related information about the frame that varies by
647
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
frame type, subtype, and type of transmitting STA. The QoS Control field is present in all Data frames in
which the QoS subfield of the Subtype subfield is equal to 1 (see 9.2.4.1.3).
When not transmitted within a DMG PPDU, each QoS Control field comprises five or eight subfields, as
defined for the particular sender (HC or non-AP STA) and frame type and subtype. The usage of these
subfields and the various possible layouts of the QoS Control field are described 9.2.4.5.2 to 9.2.4.5.12 and
illustrated in Table 9-6.
See 10.13.1 for constraints on the contents of the QoS Control field when present in an A-MPDU.
Table 9-6—QoS Control field
Applicable frame Bits Bits 11-
Bit 4 Bits 5-6 Bit 7 Bits 8 Bit 9 Bit 10
(sub) types 0–3 15
QoS CF-Poll and QoS CF-
Ack
Ack +CF-Poll frames sent TID EOSP Reserved TXOP Limit
Policy
by HC
QoS Data +CF-Poll and TID EOSP Ack A-MSDU TXOP Limit
QoS Data +CF-Ack +CF- Policy Present
Poll frames sent by HC
QoS Data and QoS Data TID EOSP Ack A-MSDU AP PS Buffer State
+CF-Ack frames sent by Policy Present
HC
QoS Null frames sent by Ack
TID EOSP Reserved AP PS Buffer State
HC Policy
QoS Data and QoS Data TID 0 Ack A-MSDU TXOP Duration Requested
+CF-Ack frames sent by Policy Present
non-AP STAs that are not a
TID 1 Ack A-MSDU Queue Size
TPU buffer STA or a TPU
Policy Present
sleep STA in a nonmesh
BSS
QoS Null frames sent by Ack
TID 0 Reserved TXOP Duration Requested
non-AP STAs that are not a Policy
TPU buffer STA or a TPU
sleep STA in a nonmesh Ack
TID 1 Reserved Queue Size
BSS Policy
QoS Data and QoS Data
+CF-Ack frames sent by Ack A-MSDU
TID EOSP Reserved
TPU buffer STAs in a Policy Present
nonmesh BSS
QoS Null frames sent by
Ack
TPU buffer STAs in a TID EOSP Reserved Reserved
Policy
nonmesh BSS
QoS Data and QoS Data
+CF-Ack frames sent by Reserv Ack A-MSDU
TID Reserved
TPU sleep STAs in a ed Policy Present
nonmesh BSS
QoS Null frames sent by
Reserv Ack
TPU sleep STAs in a TID Reserved Reserved
ed Policy
nonmesh BSS
Mesh
Mesh
All frames sent by mesh Ack A-MSDU Power
TID EOSP Control RSPI Reserved
STAs in a mesh BSS Policy Present Save
Present
Level
648
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The format of the QoS Control field for MPDUs transmitted within a DMG PPDU is provided in Table 9-7.
Data subtypes not shown in the table are not transmitted within a DMG PPDU.
Table 9-7—QoS Control field for frames transmitted within a DMG PPDU
Applicable
Bits Bits Bits
frame Bit 4 Bit 7 Bit 8 Bit 9 Bit 14 Bit 15
0–3 5–6 10–13
(sub-)types
QoS Data TID EOSP Ack A-MSDU A-MSDU RDG/ Buffered Reserved AC
Policy Present Type More AC Constraint
PPDU
QoS Null TID EOSP Ack Reserved Reserved RDG/ Buffered Reserved AC
Policy More AC Constraint
PPDU
9.2.4.5.2 TID subfield
The TID subfield identifies the TC or TS to which the corresponding MSDU (or fragment thereof) or
A-MSDU in the Frame Body field belongs. The TID subfield also identifies the TC or TS of traffic for
which a TXOP is being requested, through the setting of TXOP duration requested or queue size. The
encoding of the TID subfield depends on the access policy (see 9.4.2.30) and is shown in Table 9-8.
Additional information on the interpretation of the contents of this field appears in 5.1.1.3.
Table 9-8—TID subfield
Allowed values in bits 0–3
Access policy Usage
(TID subfield)
EDCA UP for either TC or TS, regardless of whether admission 0–7
control is required
HCCA, SPCA TSID 8–15
HEMM,
TSID, regardless of the access mechanism used 8–15
SEMM
In QoS Data +CF-Poll frames, the TID subfield in the QoS Control field indicates the TID of the data. In
QoS (+)CF-Poll frames of subtype Null, the TID subfield in the QoS Control field indicates the TID for
which the poll is intended. The requirement to respond to that TID is nonbinding, and a STA can respond
with any frame (see 10.22.3.5.1). For STAs where dot11OCBActivated is true, traffic streams are not used
and the TID always corresponds to a TC.
9.2.4.5.3 EOSP (end of service period) subfield
The EOSP subfield is 1 bit in length and is used by the HC to indicate the end of the current service period
(SP) and by a DMG STA to indicate the end of the current SP or the end of the current allocated CBAP with
individually addressed destination AID. The HC sets the EOSP subfield to 1 in its transmission and
retransmissions of the SP’s final frame to end an SP and sets it to 0 otherwise. To end an SP allocation or a
CBAP allocation with individually addressed destination AID, the DMG STA sets the EOSP subfield to 1 in
its final frame transmission and retransmissions within the allocation; otherwise, the DMG STA sets the
EOSP subfield to 0.
649
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The mesh STA uses the EOSP subfield to indicate the end of the current mesh peer service period in which
it operates as the owner. The mesh STA sets the EOSP subfield to 1 in its transmission and retransmissions
of the mesh peer service period’s final frame to end a mesh peer service period, and sets it to 0 otherwise.
See 14.14.9.4 for details.
If dot11RobustAVStreamingImplemented is true, then the HC sets the EOSP subfield to 1 in a GCR-SP
group addressed frame in order to indicate that no more GCR-SP frames of that group address are to be
transmitted by the AP until the next scheduled SP for this GCR-SP stream.
NOTE—As GCR-A frames are sent outside of any SP, the EOSP subfield is set to 0 in a group addressed frame
delivered using the GCR-A procedures described in 11.24.16.3.8.
9.2.4.5.4 Ack Policy subfield
The Ack Policy subfield is 2 bits in length and identifies the acknowledgment policy that is followed upon
the delivery of the MPDU. The interpretation of these 2 bits is given in Table 9-9.
Table 9-9—Ack Policy subfield in QoS Control field of QoS Data frames
Bits in QoS Control field
Meaning
Bit 5 Bit 6
0 0 Normal Ack or Implicit Block Ack Request.
In a frame that is a non-A-MPDU frame or VHT single MPDU:
The addressed recipient returns an Ack or QoS +CF-Ack frame after a short
interframe space (SIFS) period, according to the procedures defined in 10.3.2.9 and
10.22.3.5. A non-DMG STA sets the Ack Policy subfield for individually addressed
QoS Null (no data) frames to this value.
Otherwise:
The addressed recipient returns a BlockAck frame, either individually or as part of an
A-MPDU starting a SIFS after the PPDU carrying the frame, according to the
procedures defined in 10.3.2.9, 10.24.7.5, 10.24.8.3, 10.28.3, 10.28.4, and 10.32.3.
1 0 No Ack
The addressed recipient takes no action upon receipt of the frame. More details are
provided in 10.25.
The Ack Policy subfield is set to this value in all individually addressed frames in
which the sender does not require acknowledgment. The Ack Policy subfield is also
set to this value in all group addressed frames that use the QoS frame format except
with a TID for which a block ack agreement exists.
This value of the Ack Policy subfield is not used for QoS Data frames with a TID for
which a block ack agreement exists.
The Ack Policy subfield for group addressed QoS Null (no data) frames is set to this
value.
650
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-9—Ack Policy subfield in QoS Control field of QoS Data frames (continued)
Bits in QoS Control field
Meaning
Bit 5 Bit 6
0 1 No explicit acknowledgment or PSMP Ack.
When bit 6 of the Frame Control field (see 9.2.4.1.3) is set to 1:
There might be a response frame to the frame that is received, but it is neither the Ack
frame nor any Data frame of subtype +CF-Ack.
The Ack Policy subfield for QoS CF-Poll and QoS CF-Ack +CF-Poll Data frames is
set to this value.
When bit 6 of the Frame Control field (see 9.2.4.1.3) is set to 0:
The acknowledgment for a frame indicating PSMP Ack when it appears in a PSMP
downlink transmission time (PSMP-DTT) is to be received in a later PSMP uplink
transmission time (PSMP-UTT).
The acknowledgment for a frame indicating PSMP Ack when it appears in a PSMP-
UTT is to be received in a later PSMP-DTT.
NOTE—Bit 6 of the Frame Control field (see 9.2.4.1.3) indicates the absence of a
data Frame Body field. When equal to 1, the QoS Data frame contains no Frame Body
field, and any response is generated in response to a QoS CF-Poll or QoS CF-Ack
+CF-Poll frame, but does not signify an acknowledgment of data. When set to 0, the
QoS Data frame contains a Frame Body field, which is acknowledged as described in
10.29.2.7.
1 1 Block Ack
The addressed recipient takes no action upon the receipt of the frame except for
recording the state. The recipient can expect a BlockAckReq frame or implicit block
ack request in the future to which it responds using the procedure described in 10.24.
9.2.4.5.5 TXOP Limit subfield
The TXOP Limit subfield is an 8-bit field that is present in QoS Data frames of subtypes that include CF-
Poll and specifies the time limit on a TXOP granted by a QoS (+)CF-Poll frame from an HC in an
infrastructure BSS. In QoS Data frames with subtypes that include CF-Poll, the addressed STA is granted a
TXOP that begins a SIFS after this frame and lasts no longer than the number of 32 s periods specified by
the TXOP Limit subfield value. The range of time values is 32 s to 8160 s. A TXOP Limit subfield value
of 0 indicates that only one MPDU or one QoS Null frame is to be transmitted immediately following the
QoS (+)CF-Poll frame.
9.2.4.5.6 Queue Size subfield
The Queue Size subfield is an 8-bit field that indicates the amount of buffered traffic for a given TC or TS at
the STA sending this frame. The Queue Size subfield is present in QoS Data frames sent by non-AP STAs
with bit 4 of the QoS Control field equal to 1. The AP might use information contained in the Queue Size
subfield to determine the TXOP duration assigned to the STA.
The queue size value is the total size, rounded up to the nearest multiple of 256 octets and expressed in units
of 256 octets, of all MSDUs and A-MSDUs buffered at the STA (excluding the MSDU or A-MSDU of the
present QoS Data frame) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the
value in the TID subfield of this QoS Control field. A queue size value of 0 is used solely to indicate the
absence of any buffered traffic in the queue used for the specified TID. A queue size value of 254 is used for
all sizes greater than 64 768 octets. A queue size value of 255 is used to indicate an unspecified or unknown
size.
651
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.2.4.5.7 TXOP Duration Requested subfield
The TXOP Duration Requested subfield is present in QoS Data frames sent by STAs associated in
a nonmesh BSS with bit 4 of the QoS Control field equal to 0. The TXOP Duration Requested subfield is an
8-bit field that indicates the duration, in units of 32 s, that the sending STA determines it needs for its next
TXOP for the specified TID. A value of 0 indicates that no TXOP is requested for the specified TID in the
current SP. A nonzero value represents a requested TXOP duration in the range 32 s to 8 160 s in
increments of 32 s. See 10.22.3.5.2.
9.2.4.5.8 AP PS Buffer State subfield
The AP PS Buffer State subfield, defined in Figure 9-6, is an 8-bit field that indicates the PS buffer state at
the AP for a STA. The AP PS Buffer State subfield is further subdivided into three subfields: Buffer State
Indicated, Highest-Priority Buffered AC, and AP Buffered Load.
B8 B9 B10 B11 B12 B15
Reserved Buffer State Highest Priority QoS AP
Indicated Buffered AC Buffered Load
Bits: 1 1 2 4
Figure 9-6—QoS AP PS Buffer State subfield
The Buffered State Indicated subfield is 1 bit in length and is used to indicate whether the AP PS buffer state
is specified. A value of 1 indicates that the AP PS buffer state is specified.
The Highest-Priority Buffered AC subfield is 2 bits in length and is used to indicate the AC of the highest
priority traffic remaining that is buffered at the AP, excluding the MSDU or A-MSDU of the present frame.
The AP Buffered Load subfield is 4 bits in length and is used to indicate the total buffer size, rounded up to
the nearest multiple of 4096 octets and expressed in units of 4096 octets, of all MSDUs and A-MSDUs
buffered at the QoS AP (excluding the MSDU or A-MSDU of the present QoS Data frame). An AP Buffered
Load field value of 15 indicates that the buffer size is greater than 57 344 octets. An AP Buffered Load
subfield value of 0 is used solely to indicate the absence of any buffered traffic for the indicated highest
priority buffered AC when the Buffer State Indicated bit is 1.
When the Buffered State Indicated subfield is equal to 0, the Highest-Priority Buffered AC subfield and the
AP Buffered Load subfield are reserved.
9.2.4.5.9 A-MSDU Present subfield
The A-MSDU Present subfield is 1 bit in length and indicates the presence of an A-MSDU. The A-MSDU
Present subfield is set to 1 to indicate that the Frame Body field contains an entire A-MSDU as defined in
9.3.2.2. The A-MSDU Present subfield is set to 0 to indicate that the Frame Body field contains an MSDU or
fragment thereof as defined in 9.3.2.1.
NOTE—A DMG STA, when the A-MSDU Present subfield is set to 1, can use one of two A-MSDU formats in the
Frame Body. The specific A-MSDU format present is indicated by the A-MSDU Type subfield.
9.2.4.5.10 Mesh Control Present subfield
The Mesh Control Present subfield is 1 bit in length, and indicates the presence of a Mesh Control field in
the frame body. When the Mesh Control Present subfield is 1, the Frame Body field contains a Mesh Control
field as defined in 9.2.4.7.3. The mesh STA sets the Mesh Control Present subfield to 1 in the mesh Data
frame containing an unfragmented MSDU, an A-MSDU, or the first fragment of an MSDU.
652
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.2.4.5.11 Mesh Power Save Level subfield
The Mesh Power Save Level subfield is 1 bit in length and indicates whether the mesh STA’s peer-specific
mesh power management mode will be deep sleep mode or light sleep mode after the successful completion
of the frame exchange sequence.
When the Power Management subfield in the Frame Control field in the frame is 1, the following applies:
In individually addressed mesh Data frames, a value of 0 indicates that the mesh STA’s peer-specific mesh
power management mode for the recipient mesh STA will be light sleep mode (see 14.14.8.4). In
individually addressed mesh Data frames, a value of 1 indicates that the mesh STA’s peer-specific mesh
power management mode for the recipient mesh STA will be deep sleep mode (see 14.14.8.5).
In group addressed mesh Data frames, a value of 0 indicates that none of the peer-specific mesh power
management modes of the mesh STA will be deep sleep mode. In group addressed mesh Data frames, a
value of 1 indicates that at least one of the peer-specific mesh power management modes of the mesh STA is
deep sleep mode.
The Mesh Power Save Level subfield is reserved if the Power Management subfield in the Frame Control
field is 0.
9.2.4.5.12 Receiver Service Period Initiated (RSPI) subfield
The Receiver Service Period Initiated (RSPI) subfield is 1 bit in length. The subfield is set to 0 to indicate
that the mesh peer service period, of which the receiver of this frame is the owner, is not initiated. The
subfield is set to 1 to indicate that the mesh peer service period, of which the receiver of this frame is the
owner, is initiated. The use of the RSPI subfield is described in 14.14.9.2. The RSPI subfield is reserved in
group addressed frames.
9.2.4.5.13 A-MSDU Type subfield
The A-MSDU Type subfield is 1 bit in length and indicates the type of A-MSDU present in the Frame Body.
When the A-MSDU Type subfield is set to 0, the Frame Body field contains a Basic A-MSDU as defined in
9.3.2.2.2. When the A-MSDU Type subfield is set to 1, the Frame Body field contains a Short A-MSDU as
defined in 9.3.2.2.3. The A-MSDU Type subfield is reserved if the A-MSDU Present subfield is set to 0.
9.2.4.5.14 RDG/More PPDU subfield
The RDG/More PPDU subfield of the QoS Control field for DMG frames is interpreted differently
depending on whether it is transmitted by an reverse direction (RD) initiator or an RD responder, as defined
in Table 9-11.
9.2.4.5.15 AC Constraint subfield
The AC Constraint subfield of the QoS Control field for DMG frames indicates whether the mapped AC of
an RD Data frame is constrained to a single AC, as defined in Table 9-10.
9.2.4.5.16 Buffered AC subfield
The Buffered AC subfield is a 4-bit bitmap that indicates buffered traffic for four ACs as defined in
Figure 9-7. At least one BU for the indicated AC is buffered if the related subfield is set to 1. The Buffered
AC subfield is reserved except in QoS Data frames and QoS Null frames. A non-AP and non-PCP STA can
use information contained in the Buffered AC subfield to determine the ACs for which BU are buffered
for it.
653
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B10 B11 B12 B13
BU for AC_VO BU for AC_VI BU for AC_BE BU for AC_BK
Bits: 1 1 1 1
Figure 9-7—Buffered AC subfield
9.2.4.6 HT Control field
9.2.4.6.1 General
The HT Control field is always present in a Control Wrapper frame and is present in QoS Data and
Management frames as determined by the +HTC/Order subfield of the Frame Control field as defined in
9.2.4.1.10.
NOTE—The only control frame subtype for which HT Control field is present is the Control Wrapper frame. A Control
frame that is described as +HTC (e.g., an RTS+HTC, CTS+HTC, BlockAck+HTC or BlockAckReq+HTC frame)
implies the use of the Control Wrapper frame to carry that Control frame.
The format of the 4-octet HT Control field is shown in Figure 9-8.
B0 B1 B29 B30 B31
VHT HT Control Middle AC RDG/More
Constraint PPDU
Bits 1 29 1 1
Figure 9-8—HT Control field
The HT Control field has two forms, the HT variant and the VHT variant. The two forms differ in the format
of the HT Control Middle subfield, described in 9.2.4.6.2 for the HT variant and in 9.2.4.6.3 for the VHT
variant and in the value of the VHT subfield.
The VHT subfield of the HT Control field indicates whether the HT Control Middle subfield is the VHT
Variant or the HT Variant. The VHT subfield is set to 1 to indicate that the HT Control Middle subfield is
the VHT Variant and is set to 0 to indicate that the HT Control Middle subfield is the HT Variant.
The AC Constraint subfield of the HT Control field indicates whether the mapped AC of an RD Data frame
is constrained to a single AC, as defined in Table 9-10.
Table 9-10—AC Constraint subfield values
Value Description
0 The response to a reverse direction grant (RDG) contains Data frames from any TID;
see 10.28.4.
1 The response to an RDG contains Data frames only from the same AC as the last Data
frame received from the RD initiator; see 10.28.4.
NOTE—The AC of the last Data frame received from the RD initiator is determined directly from the TID of the
received frame if the TID is between 0 and 7 inclusive or from the UP field of the TSPEC identified by the TID of
the received frame if the TID is between 8 and 15 inclusive.
654
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The RDG/More PPDU subfield of the HT Control field is interpreted differently depending on whether it is
transmitted by an RD initiator or an RD responder, as defined in Table 9-11.
Table 9-11—RDG/More PPDU subfield values
Role of
Value Interpretation of value
transmitting STA
0 Not an RD No reverse grant
responder
RD responder The PPDU carrying the frame is the last transmission by the
RD responder
1 RD initiator An RDG is present
RD responder The PPDU carrying the frame is followed by another PPDU
9.2.4.6.2 HT variant
The format of the HT Control Middle subfield of the HT variant HT Control field is shown in Figure 9-9.
B1 B15 B16 B17 B18 B19 B20 B21 B22 B23 B24 B25 B28 B29
Link HT NDP
Calibration Calibration CSI/
Adaptation Position Sequence Reserved Steering Announce Reserved DEI
Control ment
Bits: 15 2 2 2 2 1 4 1
Figure 9-9—HT Control Middle subfield of the HT variant HT Control field
The format of the Link Adaptation Control subfield of the HT variant HT Control field is defined in
Figure 9-10.
B1 B2 B5 B6 B8 B9 B15
TRQ MAI MFSI MFB/ASELC
Bits: 1 4 3 7
Figure 9-10—Link Adaptation Control subfield
655
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The subfields of the Link Adaptation Control subfield are defined in Table 9-12.
Table 9-12—Subfields of Link Adaptation Control subfield
Subfield Meaning Definition
TRQ Training request Set to 1 to request the responder to transmit a sounding PPDU.
Set to 0 to indicate that the responder is not requested to transmit a sounding
PPDU.
See 10.32.2 and 10.34.2.
MAI MCS request Set to 14 (indicating ASELI) to indicate that the MFB/ASELC subfield is
(MRQ) or ASEL interpreted as ASELC. Otherwise, the MAI subfield is interpreted as shown
indication in Figure 9-11, and the MFB/ASELC subfield is interpreted as MCS
feedback (MFB).
MFSI MCS feedback Set to the received value of MSI contained in the frame to which the MFB
sequence identifier information refers.
Set to 7 for unsolicited MFB.
MFB/ASELC MCS feedback When the MAI subfield is equal to the value ASELI, this subfield is
and antenna interpreted as defined in Figure 9-12 and Table 9-14.
selection
command/data Otherwise, this subfield contains recommended MFB.
A value of 127 indicates that no feedback is present.
The structure of the MAI subfield of the Link Adaptation Control subfield is defined in Figure 9-11. The
subfields of the MAI subfield are defined in Table 9-13.
B0 B1 B3
MRQ MSI
Bits: 1 3
Figure 9-11—MAI subfield
Table 9-13—Subfields of the MAI subfield
Subfield Meaning Definition
MRQ MCS request Set to 1 to indicate that MFB is requested.
Set to 0 to indicate that no MFB is requested.
MSI MRQ sequence identifier When the MRQ subfield is equal to 1, the MSI subfield contains a
sequence number in the range 0 to 6 that identifies the specific
request.When the MRQ subfield is equal to 0, the MSI subfield is
reserved.
656
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The ASELC subfield of the Link Adaptation Control subfield contains the ASEL Command and ASEL Data
subfields, as shown in Figure 9-12. The encoding of these subfields is shown in Table 9-14.
B0 B2 B3 B6
ASEL Command ASEL Data
Bits: 3 4
Figure 9-12—ASELC subfield
Table 9-14—ASEL Command and ASEL Data subfields
Interpretation of ASEL
ASEL Command ASEL Data
Command
0 Transmit Antenna Selection Number of remaining sounding PPDUs to be transmitted
Sounding Indication (TXASSI) 0 to 15
See NOTE
1 Transmit Antenna Selection 0 when the command is Transmit ASEL Sounding Request
Sounding Request (TXASSR) A number in the range 1 to 15, the number being the
or Transmit ASEL Sounding number of the first sounding PPDU to be transmitted when
Resumption the command is Transmit ASEL Sounding Resumption,
where 0 corresponds to the first sounding PPDU in the
original ASEL training sequence
2 Receive Antenna Selection Number of remaining sounding PPDUs to be received
Sounding Indication (RXASSI) 0 to 15
See NOTE
3 Receive Antenna Selection Number of sounding PPDUs required
Sounding Request (RXASSR) 0 to 15
4 Sounding Label Sequence number of the sounding PPDU corresponding to
a channel state information (CSI) frame in ASEL feedback
0 to 15
5 No Feedback Due to ASEL A number in the range 0 to 15, the number being the
Training Failure or Stale number of the first sounding PPDU that was not received
Feedback properly, where 0 corresponds to the first sounding PPDU
in the ASEL training sequence, or 0 if no sounding PPDUs
were received properly, or 0 if this is a request for a full
retraining sequence
6 Transmit Antenna Selection Number of remaining sounding PPDUs to be transmitted
Sounding Indication requesting 0 to 15
feedback of explicit CSI
(TXASSI-CSI) See NOTE
7 Reserved Reserved
NOTE—If the HT variant HT Control field is carried in a sounding PPDU, then the value of the ASEL Data field
contains the remaining number of sounding frames following the current one. If null data packet (NDP) sounding
frame is used, then the value in the ASEL Data field contains the number of NDPs following a non-NDP+HTC. The
HT NDP Announcement subfield in the HT Control field is set to 1 to indicate NDP sounding.
657
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Calibration Position and Calibration Sequence subfields of the HT variant HT Control field are
defined in Table 9-15.
Table 9-15—Calibration control subfields
Subfield Meaning Definition
Calibration Position in calibration sounding Set to 0 indicates this is not a calibration frame.
Position exchange sequence Set to 1 indicates calibration start.
Set to 2 indicates sounding response.
Set to 3 indicates sounding complete.
Calibration Calibration sequence identifier The field is included in each frame within the calibration
Sequence procedure and its value is unchanged for the frame
exchanges during one calibration procedure.
See 10.32.2.4.3.
The Calibration Sequence subfield identifies an instance of the calibration procedure. The subfield is
included in each frame within a calibration procedure, and its value is unchanged for frames within the same
calibration procedure.
The CSI/Steering subfield of the HT variant HT Control field indicates the type of feedback, as shown in
Table 9-16.
Table 9-16—CSI/Steering subfield values
Value Definition
0 No feedback required
1 CSI
2 Noncompressed beamforming
3 Compressed beamforming
The HT NDP Announcement subfield of the HT variant HT Control field indicates that an NDP will be
transmitted after the frame (according to the rules described in 10.34). It is set to 1 to indicate that an NDP
will follow; otherwise, it is set to 0.
The DEI subfield of the HT Control field is 1 bit in length and is set by the transmitting STA to indicate the
suitability of the corresponding MSDU or A-MSDU to be discarded if there are insufficient resources at the
receiving STA. See 10.9 and 11.27.2. In a Management frame, the DEI subfield is reserved.
658
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.2.4.6.3 VHT variant
The format of the HT Control Middle subfield of the VHT variant HT Control field is shown in Figure 9-13.
B1 B2 B3 B5 B6 B8 B9 B23 B24 B26 B27 B28 B29
Reserved MRQ MSI/ MFSI/ MFB GID-H Coding FB Tx Unsolicited
STBC GID-L Type Type MFB
Bits: 1 1 3 3 15 3 1 1 1
Figure 9-13—HT Control Middle subfield of the VHT variant HT Control field
The subfields of VHT variant HT Control field are defined in Table 9-17.
Table 9-17—VHT variant HT Control field subfields
Subfield Meaning Definition
MRQ VHT-MCS Set to 1 to request VHT-MCS feedback (solicited MFB); otherwise,
feedback request set to 0.
MSI/STBC MRQ sequence If the Unsolicited MFB subfield is 0 and the MRQ subfield is 1, the
identifier/STBC MSI/STBC subfield contains a sequence number in the range 0 to 6
indication that identifies the specific MCS feedback request.
If the Unsolicited MFB subfield is 0 and the MRQ subfield is 0, the
MSI/STBC subfield is reserved.
If the Unsolicited MFB subfield is 1 and the MFB does not contain the
value representing “no feedback is present,” the MSI/STBC field
contains the Compressed MSI and STBC Indication subfields as
shown in Figure 9-14.
The STBC Indication subfield indicates whether the estimate in the
MFB subfield is computed based on a PPDU using STBC encoding:
Set to 0 if the PPDU was not STBC encoded
Set to 1 if the PPDU was STBC encoded
The Compressed MSI subfield contains a sequence number that
identifies the specific MCS feedback request. It is in the range 0 to 3 if
STBC Indication equals 0 or in the range 0 to 2 if STBC Indication
equals 1.
Otherwise, the MSI/STBC subfield is reserved.
MFSI/GID-L MFB sequence If the Unsolicited MFB subfield is 0, the MFSI/GID-L subfield
identifier/LSBs of contains the received value of MSI contained in the frame to which the
group ID MFB information refers.
If the Unsolicited MFB subfield is 1, the MFB does not contain the
value representing “no feedback is present,” and the MFB is estimated
from a VHT MU PPDU, then the MFSI/GID-L subfield contains the
lowest 3 bits of group ID of that PPDU from which the MFB was
estimated (bit 0 of the group ID appears in the lowest numbered bit of
the field MFSI/GID-L). If the unsolicited MFB is estimated from an
SU PPDU, the MFSI/GID-L subfield is set to all 1s.
Otherwise, this subfield is reserved.
MFB NUM_STS, VHT- MFB subfield is interpreted as defined in Table 9-18. This subfield
MCS, BW and contains the recommended MFB. The combination of VHT-MCS=15
SNR feedback and NUM_STS=7 indicates that no feedback is present.
659
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-17—VHT variant HT Control field subfields (continued)
Subfield Meaning Definition
GID-H MSBs of group ID If the Unsolicited MFB subfield is 1, the MFB does not contain the
value representing “no feedback is present,” and the unsolicited MFB
is estimated from a VHT MU PPDU, then the GID-H subfield contains
the highest 3 bits of group ID of the PPDU from which the unsolicited
MFB was estimated (bit 3 of the group ID appears in the lowest
numbered bit of the field GID-H). If the unsolicited MFB is estimated
from an SU PPDU, the GID-H subfield is set to all 1s.
Otherwise, this subfield is reserved.
Coding Type Coding type of the If the Unsolicited MFB subfield is 1 and the MFB does not contain the
measured PPDU value representing “no feedback is present,” the Coding Type subfield
contains the Coding information (0 for BCC and 1 for LDPC) of the
PPDU from which the unsolicited MFB was estimated.
Otherwise, this subfield is reserved.
FB Tx Type Transmission type If the Unsolicited MFB subfield is 1, the MFB does not contain the
of the measured value representing “no feedback is present,” and FB Tx Type subfield
PPDU is 0, then the unsolicited MFB is estimated from a VHT PPDU with
RXVECTOR parameter BEAMFORMED equal to 0.
If the Unsolicited MFB subfield is 1, the MFB does not contain the
value representing “no feedback is present,” and the FB Tx Type
subfield is 1, then the unsolicited MFB is estimated from a VHT
PPDU with RXVECTOR parameter BEAMFORMED equal to 1.
Otherwise, this subfield is reserved.
Unsolicited MFB Unsolicited VHT- Set to 1 if the MFB is not a response to an MRQ.
MCS feedback Set to 0 if the MFB is a response to an MRQ.
indicator
The format of the MSI/STBC subfield when the Unsolicited subfield is 1 is shown in Figure 9-14.
B3 B4 B5
Compressed MSI STBC Indication
Bits: 2 1
Figure 9-14—MSI/STBC subfield when the Unsolicited MFB subfield is 1
The format of the MFB subfield in the VHT variant HT Control field is shown in Figure 9-15.
B9 B11 B12 B15 B16 B17 B18 B23
NUM_STS VHT-MCS BW SNR
Bits: 3 4 2 6
Figure 9-15—MFB subfield in the VHT variant HT Control field
660
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The subfields of the MFB subfield in the VHT variant HT Control field are defined in Table 9-18.
Table 9-18—MFB subfield in the VHT variant HT Control field
Subfield Meaning Definition
NUM_STS Recommended Indicates the recommended NUM_STS as defined in 10.31.3.
NUM_STS The NUM_STS subfield contains an unsigned integer representing the
number of space-time streams minus 1.
VHT-MCS Recommended Indicates the recommended VHT-MCS as defined in 10.31.3.
VHT-MCS The VHT-MCS subfield contains an unsigned integer in the range 0 to 9
representing a VHT-MCS Index value (defined in 21.5).
BW Bandwidth of the If the Unsolicited MFB subfield is 1, the BW subfield indicates the
recommended bandwidth for which the recommended VHT-MCS is intended, as
VHT-MCS defined in 10.31.3:
For a VHT STA:
Set to 0 for 20 MHz
Set to 1 for 40 MHz
Set to 2 for 80 MHz
Set to 3 for 160 MHz and 80+80 MHz.
For a TVHT STA:
Set to 0 for TVHT_W
Set to 1 for TVHT_2W and TVHT_W+W
Set to 2 for TVHT_4W and TVHT_2W+2W
The value 3 is reserved.
If the Unsolicited MFB subfield is 0, the BW subfield is reserved.
SNR Average SNR Indicates the average SNR, which is an SNR averaged over data
subcarriers and space-time streams.
The SNR is averaged over all of the space-time streams and data
subcarriers and is encoded as a 6-bit 2s complement number of
SNR_average – 22, where SNR_average is the sum of the values of
SNR per frequency tone (in decibels) per space-time stream divided by
the product of the number of space-time streams, as indicated in the
NUM_STS subfield, and the number of frequency tones represented in
the bandwidth in which the MFB was estimated. This encoding covers
the SNR range from –10 dB to 53 dB in 1 dB steps.
9.2.4.7 Frame Body field
9.2.4.7.1 General
The Frame Body is a variable-length field that contains information specific to individual frame types and
subtypes. The minimum length of the frame body is 0 octets. The maximum length of the frame body is
constrained or affected by the following:
— The maximum MMPDU, MSDU, A-MSDU, and MPDU sizes supported by the recipient(s) for the
PPDU format in use, as specified in Table 9-19
— The maximum PPDU duration (e.g., HT_MF L-SIG L_LENGTH, HT_GF, VHT, TVHT, or DMG
aPPDUMaxTime (see Table 9-19); any nonzero TXOP limit; any regulatory constraints (e.g., CS4-
msBehavior))
— The fields present in the MAC header (e.g., QoS Control, Address 4, HT Control)
— The presence of security encapsulation (e.g., TKIP, CCMP or GCMP Header and MIC)
— The presence of Mesh Control fields (see 9.2.4.7.3)
661
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 1—In an A-MSDU, the Mesh Control field is located in the A-MSDU Subframe Header (see Figure 9-56). In an
MMPDU, the Mesh Control field is located within the MMPDU (see 9.6.18). Such Mesh Control fields need to be taken
into account if a maximum A-MSDU or MMPDU size constraint applies as well as if a maximum MPDU size constraint
applies.
NOTE 2—TKIP is not allowed with A-MSDUs (see 12.2.6) or MMPDUs (see 12.5.4.1) and, therefore, need not be
taken into account if a maximum A-MSDU or MMPDU size constraint applies.
Table 9-19—Maximum data unit sizes (in octets) and durations (in microseconds)
Non-HT non-VHT
non-DMG PPDU
HT PPDU VHT PPDU DMG PPDU
and non-HT
duplicate PPDU
MMPDU size 2304 2304 See NOTE 1 2304
MSDU size 2304 2304 2304 7920
A-MSDU size 3839 or 3839 or 7935 See NOTE 3 7935
(see also
4065 Table 9-162)
(see NOTE 2)
(HT STA, see also
Table 9-162),
or
N/A (non-HT STA,
see also 10.12)
MPDU size See NOTE 4 See NOTE 5 3895 or 7991 or See NOTE 5
11 454
(see also
Table 9-249)
PSDU size 212–1 216–1 4 692 480 (~222.16) 218–1
(see NOTE 7) (see Table 15-5, (see Table 19-25) (see Table 21-29) (see Table 20-32)
Table 16-4,
Table 17-21,
Table 18-5)
PPDU duration See NOTE 6 5484 (HT_MF; see 5484 2000
(see NOTE 7) 10.26.4) or 10 000 (see Table 21-29) (see Table 20-32)
(HT_GF; see
Table 19-25)
NOTE 1—No direct constraint on the maximum MMPDU size; indirectly constrained by the maximum MPDU size
(see 9.3.3.2).
NOTE 2—Indirect constraint from the maximum PSDU size: 212–1 octets minus the minimum QoS Data frame
overhead (26 octets for the MAC header and 4 octets for the FCS).
NOTE 3—No direct constraint on the maximum A-MSDU size; indirectly constrained by the maximum MPDU size.
NOTE 4—No direct constraint on the maximum MPDU size; indirectly constrained by the maximum MSDU/
MMPDU or (for HT STAs only) A-MSDU size.
NOTE 5—No direct constraint on the maximum MPDU size; indirectly constrained by the maximum A-MSDU size.
NOTE 6—No direct constraint on the maximum duration, but an L_LENGTH value above 2332 might not be
supported by some receivers (see last NOTE in 10.26.4).
NOTE 7—The values for maximum PSDU size and maximum PPDU duration are informative only. References to the
normative requirements are provided.
662
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.2.4.7.2 Overhead for encryption
The overhead for encryption is described in Clause 12. When the Mesh Control field is present in the frame
body, the Mesh Control field is encrypted as a part of data.
9.2.4.7.3 Mesh Control field
The Mesh Control field is present in a mesh Data frame containing an unfragmented MSDU or the first
fragment of a fragmented MSDU and is present in a Multihop Action frame transmitted by a mesh STA.
In mesh Data frames, when the Mesh Control Present subfield in the QoS Control field is 1, the Mesh
Control field is prepended to the MSDU and located as follows:
— When the frame body contains an MSDU (or a fragment thereof) and the frame is not encrypted, the
Mesh Control field is located in the first octets of the frame body.
— When the frame body contains an MSDU (or a fragment thereof) and the frame is encrypted, the
Mesh Control field is located in the first octets of the encrypted data portion.
— When the frame body contains an A-MSDU, the Mesh Control field is located in the A-MSDU
subframe header as shown in Figure 9-56.
In the Multihop Action frame, the Mesh Control field is present as specified in 9.6.18.
The Mesh Control field is of variable length (6, 12, or 18 octets). The structure of the Mesh Control field is
defined in Figure 9-16.
Mesh Sequence Mesh
Mesh Flags Mesh TTL Number Address Extension
Octets: 1 1 4 0, 6, or 12
Figure 9-16—Mesh Control field
The Mesh Flags subfield is 1 octet in length and contains the Address Extension Mode subfield. The
structure of the Mesh Flags subfield is shown in Figure 9-17.
B0 B1 B2 B7
Address Extension
Mode Reserved
Bits Bits: 2 6
Figure 9-17—Mesh Flags subfield
The Address Extension Mode subfield indicates the contents of the Mesh Address Extension subfield.
Table 9-20 defines valid values for the Address Extension Mode and describes the corresponding contents
of the Mesh Address Extension subfield.
The Mesh TTL subfield is 1 octet in length and contains an unsigned integer corresponding to the remaining
number of hops the MSDU/MMPDU is forwarded. How the Mesh TTL is used in both individually and
group addressed frames is described in 10.35.3 and 10.35.4.
663
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-20—Valid values for the Address Extension Mode subfield
Address Mesh Address
Address
extension Address extension mode Extension Applicable
extension mode
mode description subfield length frame types
name
value (octets)
0 None No Mesh Address Extension 0 Data, Management
subfield (Multihop Action,
group addressed)
1 Address4 Mesh Address Extension 6 Management
subfield contains Address 4 (Multihop Action,
individually addressed),
Data (proxied, group
addressed)
2 Address5&6 Mesh Address Extension 12 Data (proxied,
subfield contains Address 5 individually addressed)
and Address 6
3 Reserved — —
The Mesh Sequence Number subfield is 4 octets in length and contains an unsigned integer sequence
number counter value. Source mesh STAs assign mesh sequence numbers from a single modulo 232 counter,
starting at 0 and incrementing by 1 for each MSDU or MMPDU that is transmitted with a Mesh Control
field. Usage of the Mesh Sequence Number is described in 10.35.6.
NOTE—It is believed that a 32-bit sequence number is sufficient as the rollover would occur after a period of 5 days
assuming a source continuously transmitting at a rate of 104 frames per second.
The Mesh Address Extension subfield, shown in Figure 9-18, is 6 or 12 octets in length and is present only
when the Address Extension Mode subfield of the Mesh Flags subfield is a nonzero nonreserved value. The
Mesh Address Extension subfield provides additional address fields for mesh address extension as defined
in Table 9-20. The interpretation of the extended Address fields is described in 9.3.5.
Address 4 Address 5 Address 6
Octets: 0 or 6 0 or 6 0 or 6
Figure 9-18—Mesh Address Extension subfield
The Address 4 subfield is present when the Address Extension Mode subfield in the Mesh Flags subfield is
1. It carries a fourth address that is not included as a part of the MAC header for these frames.
The Address 5 subfield and Address 6 subfield are present when the Address Extension Mode subfield in the
Mesh Flags subfield is 2. It carries the addresses of source and destination end station of the end-to-end
IEEE 802 communication in cases which either (or both) of the end stations are not mesh STAs at the
beginning or end of a single mesh path. (See Figure 9-64.)
NOTE—This is useful, for example, when the end stations of IEEE 802 communication are nonmesh, external STAs
that communicate over a mesh BSS via proxy mesh gates.
Details on the usage of these optional address fields are given in 14.10.8.4.
664
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.2.4.8 FCS field
The FCS field is a 32-bit field containing a 32-bit CRC. The FCS is calculated over all of the fields of the
MAC header and the Frame Body field. These are referred to as the calculation fields.
The FCS is calculated using the following standard generator polynomial of degree 32:
G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
The FCS is the 1s complement of the sum (modulo 2) of the following:
a) The remainder of xk (x31 + x30 + x29 + …+ x2 + x + 1) divided (modulo 2) by G(x), where k is the
number of bits in the calculation fields, and
b) The remainder after multiplication of the contents (treated as a polynomial) of the calculation fields
by x32 and then division by G(x).
The FCS field is transmitted commencing with the coefficient of the highest-order term.
As a typical implementation, at the transmitter, the initial remainder of the division is preset to all 1s and is
then modified by division of the calculation fields by the generator polynomial G(x). The 1s complement of
this remainder is transmitted, with the highest-order bit first, as the FCS field.
At the receiver, the initial remainder is preset to all 1s and the serial incoming bits of the calculation fields
and FCS, when divided by G(x), results (in the absence of transmission errors) in a unique nonzero
remainder value. The unique remainder value is the polynomial:
x31 + x30 + x26 + x25 + x24 + x18 + x15 + x14 + x12 + x11 + x10 + x8 + x6 + x5 + x4 + x3 + x + 1
9.2.5 Duration/ID field (QoS STA)
9.2.5.1 General
The value in the Duration/ID field within Poll, SPR, Grant, Grant Ack, DMG CTS, DMG DTS, SSW, SSW-
Feedback, and SSW-Ack frames transmitted by a DMG STA are described in 9.3.1.11 to 9.3.1.19. The value
in the Duration/ID field within DMG Beacon frames transmitted by a DMG STA is described in 9.3.4.2.
The value in the Duration/ID field in a frame transmitted by a QoS STA is defined in 9.2.5.2 to 9.2.5.8.
All times are calculated in microseconds. If a calculated duration includes a fractional microsecond, that
value inserted in the Duration/ID field is rounded up to the next higher integer. If a calculated duration
results in a negative value, the value of the Duration/ID field is 0.
9.2.5.2 Setting for single and multiple protection under enhanced distributed channel
access (EDCA)
In transmissions under EDCA by a STA that initiates a TXOP, there are two classes of duration settings:
single protection and multiple protection. In single protection, the value of the Duration/ID field of the frame
can set a network allocation vector (NAV) value at receiving STAs that protects up to the end of any
following Data, Management, or response frame plus any additional overhead frames as described below. In
multiple protection, the value of the Duration/ID field of the frame can set a NAV that protects up to the
estimated end of a sequence of multiple frames.
665
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The STA selects between single and multiple protection when it transmits the first frame of a TXOP. All
subsequent frames transmitted by the STA in the same TXOP use the same class of duration settings. A STA
always uses multiple protection in a TXOP that includes:
— Frames that have the RDG/More PPDU subfield equal to 1
— PSMP frames
— VHT NDP Announcement frames or Beamforming Report Poll frames
The Duration/ID field is determined as follows:
a) Single protection settings.
1) In an RTS frame that is not part of a dual clear-to-send (CTS) exchange, the Duration/ID field
is set to the estimated time, in microseconds, required to transmit the pending frame, plus one
CTS frame, plus one Ack or BlockAck frame if required, plus any NDPs required, plus explicit
feedback if required, plus applicable IFSs.
2) In all CTS frames sent by STAs as the first frame in the exchange under EDCA and with the
receiver address (RA) matching the MAC address of the transmitting STA, the Duration/ID
field is set to one of the following:
i) If there is a response frame, the estimated time required to transmit the pending frame,
plus one SIFS, plus the response frame (Ack or BlockAck), plus any NDPs required, plus
explicit feedback if required, plus an additional SIFS
ii) If there is no response frame, the time required to transmit the pending frame, plus one
SIFS
3) In a BlockAckReq frame, the Duration/ID field is set to the estimated time required to transmit
one Ack or BlockAck frame, as applicable, plus one SIFS.
4) In a BlockAck frame that is not sent in response to a BlockAckReq frame or an implicit block
ack request, the Duration/ID field is set to the estimated time required to transmit an Ack frame
plus a SIFS.
5) In Management frames, non-QoS Data frames (i.e., with bit 7 of the Frame Control field equal
to 0), and individually addressed Data frames with the Ack Policy subfield equal to Normal
Ack only, the Duration/ID field is set to one of the following:
i) If the frame is the final fragment of the TXOP, the estimated time required for the
transmission of one Ack frame (including appropriate IFSs)
ii) Otherwise, the estimated time required for the transmission of one Ack frame, plus the
time required for the transmission of the following frame and its response if required, plus
applicable IFSs.
6) In individually addressed QoS Data frames with the Ack Policy subfield equal to No Ack or
Block Ack, for Action No Ack frames, and for group addressed frames, the Duration/ID field is
set to one of the following:
i) If the frame is the final fragment of the TXOP, 0
ii) Otherwise, the estimated time required for the transmission of the following frame and its
response frame, if required (including appropriate IFSs)
b) Multiple protection settings. The Duration/ID field is set to a value D as follows:
1) If TTXOP = 0 and TEND_NAV = 0, then D = TSINGLE-MSDU – TPPDU
2) Else if TTXOP = 0 and TEND_NAV > 0, then D = max(0, TEND-NAV –TPPDU)
3) Else if TEND-NAV = 0, then min T PENDING T TXOP – T PPDU D T TXOP – T PPDU
4) Else T END – NAV – T PPDU D T TXOP – REMAINING – T PPDU
666
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
TSINGLE-MSDU is the estimated time required for the transmission of the allowed frame
exchange sequence defined in 10.22.2.8 (for a TXOP limit of 0), including
applicable IFSs
TPENDING is the estimated time required for the transmission of
— Pending MPDUs of the same AC
— Any associated immediate response frames
— Any HT NDP, VHT NDP, or Beamforming Report Poll frame
transmissions and explicit feedback response frames
— Applicable IFSs
— Any RDG
TTXOP is the duration given by dot11EDCATableTXOPLimit (dot11QAP-
EDCATableTXOPLimit for the AP) for that AC
TTXOP-REMAINING is TTXOP less the time already used time within the TXOP
TEND-NAV is the remaining duration of any NAV set by the TXOP holder, or 0 if no
NAV has been established
TPPDU is the time required for transmission of the current PPDU
The estimated time required for transmission of a VHT Compressed Beamforming frame response is
determined by assuming the following:
— All feedback segments (as defined in 10.34.5.3) are transmitted, even if a Beamforming Report Poll
frame is used and not all of the bits in the included Feedback Segment Retransmission Bitmap field
are equal to 1.
— The subfield values of the VHT MIMO Control field are as follows:
— The Feedback Type, Nr Index, and Channel Width fields are as specified in 10.34.5.
— The Nc Index field is as specified in 10.34.5 if the Feedback Type field is MU, or to the greatest
value allowed by 10.34.5 if the Feedback Type field is SU.
— The Grouping field indicates no grouping.
— The Codebook Information field has the value 1.
NOTE 1—Estimated times might prove to be inexact, if the TXOP responder has a choice of PHY options (e.g., BCC v.
LDPC, use of STBC, use of short GI, PHY header/preamble format options) or MAC options (e.g., use of HT Control).
Heuristics such as the TXOP responder’s previous choices and channel conditions might be used to minimize the
inexactitude.
NOTE 2—If a TXOP includes the transmission of a VHT Compressed Beamforming frame by the TXOP responder, the
TXOP holder can, if the duration estimates prove excessive, indicate truncation of the TXOP by using a CF-End frame,
provided that the remaining duration of the TXOP after the transmission of the last frame can accommodate the CF-End
frame (see 10.22.2.9).
9.2.5.3 Setting for QoS CF-Poll frames
Within a Data frame containing QoS CF-Poll, the Duration/ID field value is set to one of the following:
a) One SIFS plus the TXOP limit, if the TXOP limit is nonzero, or
b) The time required for the transmission of one MPDU of nominal MSDU size and the associated Ack
frame plus two SIFSs, if the TXOP limit is 0.
667
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.2.5.4 Setting for frames sent by a TXOP holder under HCCA
Within a frame sent by a TXOP holder under hybrid coordination function (HCF) controlled channel access
(HCCA), to provide NAV protection for the entire controlled access phase (CAP), the Duration/ID field is
set to one of the following values:
a) In an RTS frame
1) If the pending frame is the final frame, the time required to transmit the pending frame, plus
one CTS frame, plus one Ack frame if required, plus three SIFSs
2) If the pending frame is not the final frame in the TXOP, the remaining duration of the TXOP
b) In a CTS frame
1) If the pending frame is the sole frame in the TXOP, one of the following:
i) If there is a response frame, the time required to transmit the pending frame, plus one
SIFS, plus the response frame (Ack or BlockAck), plus an additional SIFS
ii) If there is no response frame, the time required to transmit the pending frame, plus one
SIFS
2) If the pending frame is not the final frame in the TXOP, the remaining duration of the TXOP
c) Otherwise
1) If the frame is a nonfinal frame in a TXOP with multiple frame exchanges, the remaining
duration of the TXOP
2) If the frame is the sole or final frame in the TXOP, the actual remaining time needed for this
frame exchange sequence
9.2.5.5 Settings within a PSMP sequence
Within a PSMP frame the Duration/ID field is set to a value that is no less than the time required to complete
all PSMP-DTT and PSMP-UTT periods described in the frame.
Within the PSMP-DTT and PSMP-UTT of a PSMP sequence, the Duration/ID field is set to the Duration/ID
value of the preceding PSMP frame minus the time between the end of the PSMP frame and the end of the
PPDU carrying the frame.
NOTE—In other words, all frames transmitted within a PSMP sequence locate the same NAV endpoint.
9.2.5.6 Settings within a dual CTS sequence
Within a frame (“Frame1”) (excluding a second CTS (CTS2) transmission, as defined in 10.3.2.8) sent by a
QoS STA that is not a TXOP holder in a PPDU that contains an immediate response or that is sent by an RD
responder, the Duration/ID field is set to the Duration/ID value from the frame(s) (“Frames2”) that elicited
the response or that carried the RDG minus the time interval between the end of the PPDU that carried
Frame1 and the end of the PPDU that carries Frames2.
Within a frame (“Frame1”) (excluding a CTS2 transmission, as defined in 10.3.2.8) sent by a QoS STA that
is a TXOP holder, the Duration/ID field is set according to the rules in the following subclauses:
— 9.2.5.2 rule b) for multiple protection if Frame1 is not a QoS +CF-Poll frame and the TXOP holder
is not operating under HCCA or PSMP
— 9.2.5.3 if Frame1 is a QoS +CF-Poll frame and the TXOP holder is not operating under HCCA or
PSMP
— 9.2.5.4 if the TXOP holder is operating under HCCA
— 9.2.5.5. if the TXOP holder is operating under PSMP
668
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Within the CTS2 of a dual CTS exchange, defined in 10.3.2.8, the Duration/ID field is set to the value of the
Duration/ID field of the RTS frame that initiated the exchange minus the time required to transmit the first
clear-to-sent (CTS1), CTS2, and the applicable IFSs.
9.2.5.7 Setting for control response frames
This subclause describes how to set the Duration/ID field for CTS, Ack, and BlockAck frames transmitted
by a QoS STA.
In a CTS frame that is not part of a dual CTS sequence transmitted in response to an RTS frame, the
Duration/ID field is set to the value obtained from the Duration/ID field of the RTS frame that elicited the
response minus the time, in microseconds, between the end of the PPDU carrying the RTS frame and the end
of the PPDU carrying the CTS frame.
In an Ack frame, the Duration/ID field is set to the value obtained from the Duration/ID field of the frame
that elicited the response minus the time, in microseconds between the end of the PPDU carrying the frame
that elicited the response and the end of the PPDU carrying the Ack frame.
In a BlockAck frame transmitted in response to a BlockAckReq frame or transmitted in response to a frame
containing an implicit block ack request, the Duration/ID field is set to the value obtained from the Duration/
ID field of the frame that elicited the response minus the time, in microseconds between the end of the
PPDU carrying the frame that elicited the response and the end of the PPDU carrying the BlockAck frame.
9.2.5.8 Setting for other response frames
In any frame transmitted by a STA that is not the TXOP holder and is not specified by 9.2.5.1 to 9.2.5.7, the
Duration/ID field is set to the value obtained from the Duration/ID field of the frame that elicited the
response minus the time, in microseconds, between the end of the PPDU carrying the frame that elicited the
response and the end of the PPDU carrying the frame.
9.3 Format of individual frame types
9.3.1 Control frames
9.3.1.1 Format of Control frames
In the following descriptions, “immediately previous” frame means a frame whose reception concluded
within the SIFS preceding the start of the current frame.
The subfields within the Frame Control field of Control frames are set as illustrated in Figure 9-19.
B0 B1 B2 B3 B4 B7 B8 B9 B10 B11 B12 B13 B14 B15
Power
To From More Protected +HTC
Protocol Type Retry Man- More
Subtype DS DS Frag Frame /Order
Version (Control) (0) age- Data
(0) (0) (0) (0) (0)
ment
Bits: 2 2 4 1 1 1 1 1 1 1 1
Figure 9-19—Frame Control field subfield values within Control frames
669
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.3.1.2 RTS frame format
The frame format for the RTS frame is as defined in Figure 9-20.
Figure 9-20—RTS frame
The RA field value of the RTS frame is the address of the STA, on the WM, that is the intended immediate
recipient of the pending individually addressed Data, Management, or Control frame.
The TA field value is the address of the STA transmitting the RTS frame or the bandwidth signaling TA of
the STA transmitting the RTS frame. In an RTS frame transmitted by a VHT STA in a non-HT or non-HT
duplicate format and where the scrambling sequence carries the TXVECTOR parameters
CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT (see 10.3.2.6), the TA field is
a bandwidth signaling TA.
For all RTS frames sent by non-QoS STAs, the duration value is the time, in microseconds, required to
transmit the pending Data or Management frame, plus one CTS frame, plus one Ack frame, plus three SIFSs.
If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher
integer. For RTS frames sent by QoS STAs, see 9.2.5.
9.3.1.3 CTS frame format
The frame format for the CTS frame is as defined in Figure 9-21.
Figure 9-21—CTS frame
When the CTS frame is a response to an RTS frame, the value of the RA field of the CTS frame is set to the
address from the TA field of the RTS frame with the Individual/Group bit forced to the value 0. When the
CTS frame is the first frame in a frame exchange, the RA field is set to the MAC address of the transmitter.
For all CTS frames transmitted by a non-QoS STA in response to RTS frames, the duration value is the
value obtained from the Duration field of the immediately previous RTS frame, minus the time, in
microseconds, required to transmit the CTS frame and its SIFS. If the calculated duration includes a
fractional microsecond, that value is rounded up to the next higher integer.
At a non-QoS STA, if the CTS frame is the first frame in the exchange and the pending Data or Management
frame requires acknowledgment, the duration value is the time, in microseconds, required to transmit the
pending Data or Management frame, plus two SIFSs plus one Ack frame. At a non-QoS STA, if the CTS
frame is the first frame in the exchange and the pending Data or Management frame does not require
acknowledgment, the duration value is the time, in microseconds, required to transmit the pending Data or
Management frame, plus one SIFS. If the calculated duration includes a fractional microsecond, that value is
rounded up to the next higher integer.
670
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For other CTS frame transmissions by a QoS STA, the duration value is set as defined in 9.2.5.
A CTS-to-self frame is a CTS frame in which the RA field is equal to the transmitter’s MAC address.
A CTS-to-AP frame is a CTS frame that is not transmitted in response to an RTS frame and in which the RA
field is equal to the MAC address of the AP with which the STA is associated.
9.3.1.4 Ack frame format
The frame format for the Ack frame is as defined in Figure 9-22.
Figure 9-22—Ack frame
The value of the RA field of the Ack frame is the nonbandwidth signaling TA from the Address 2 field of the
immediately previous individually addressed Data, Management, BlockAckReq, BlockAck, or PS-Poll
frames.
For Ack frames sent by non-QoS STAs, if the More Fragments bit was equal to 0 in the Frame Control field
of the immediately previous individually addressed Data or Management frame, the duration value is set to
0. In other Ack frames sent by non-QoS STAs, the duration value is the value obtained from the Duration/ID
field of the immediately previous Data, Management, BlockAckReq, or BlockAck frame minus the time, in
microseconds, required to transmit the Ack frame and its SIFS. If the calculated duration includes a
fractional microsecond, that value is rounded up to the next higher integer.
In all other Ack frames, the duration value is specified by 9.2.5.
9.3.1.5 PS-Poll frame format
The frame format for the PS-Poll frame is as defined in Figure 9-23.
Octets: 2 2 6 6 4
Frame
Control ID BSSID(RA) TA FCS
MAC header
Figure 9-23—PS-Poll frame
The BSSID is the address of the STA contained in the AP. The TA field value is the address of the STA
transmitting the frame or a bandwidth signaling TA. In a PS-Poll frame transmitted by a VHT STA in a non-
HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameter
CH_BANDWIDTH_IN_NON_HT, the TA field value is a bandwidth signaling TA. The ID field contains
the AID value assigned to the STA transmitting the frame by the AP in the (Re)Association Response frame
that established that STA’s current association, with the two MSBs set to 1.
671
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.3.1.6 CF-End frame format
The frame format for the CF-End frame is as defined in Figure 9-24.
Figure 9-24—CF-End frame
When transmitted by a non-DMG STA, the Duration field is set to 0. When transmitted by a DMG STA, the
Duration field is set to the time required to complete the CF-End truncation sequence of which it is part (see
10.36.8): Duration = (i – 1) × (TXTIME(CF-End) + SIFS), where i is in the range 1 to 3 and indicates the
order of the CF-End frame in the truncation sequence in the reverse direction (i.e., i=1 corresponds to the
last CF-End frame in the sequence).
When transmitted by a non-DMG STA, the RA field is the broadcast group address. When transmitted by a
DMG STA, the RA field is the MAC address of the STA that is the intended immediate recipient of the
individually addressed Data or Management frame, or the broadcast group address.
When transmitted by a non-DMG STA, the BSSID (TA) field is the address of the STA contained in the AP
except that the Individual/Group bit of the BSSID (TA) field is set to 1 in a CF-End frame transmitted by a
VHT STA to a VHT AP in a non-HT or non-HT duplicate format to indicate that the scrambling sequence
carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT. When transmitted by a DMG STA,
the TA field is the MAC address of the STA transmitting the frame.
9.3.1.7 CF-End +CF-Ack frame format
The frame format for the CF-End +CF-Ack frame is as defined in Figure 9-25.
Figure 9-25—CF-End +CF-Ack frame
The BSSID field is the address of the STA contained in the AP. The RA field is the broadcast group address.
The Duration field is set to 0.
9.3.1.8 BlockAckReq frame format
9.3.1.8.1 Overview
The frame format of the BlockAckReq frame is defined in Figure 9-26.
672
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Octets: 2 2 6 6 2 variable 4
Frame BAR
Control Duration RA TA BAR Control Information FCS
MAC header
Figure 9-26—BlockAckReq frame
The Duration field value is set as defined in 9.2.5.
The RA field of the BlockAckReq frame is the address of the recipient STA.
The TA field value is the address of the STA transmitting the BlockAckReq frame or a bandwidth signaling
TA. In a BlockAckReq frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and
where the scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the
TA field value is a bandwidth signaling TA.
The BAR (for block acknowledgment request) Control field is shown in Figure 9-27.
B0 B1 B2 B3 B4 B11 B12 B15
BAR Ack Compressed
Multi-TID GCR Reserved TID_INFO
Policy Bitmap
Bits: 1 1 1 1 8 4
Figure 9-27—BAR Control field
For BlockAckReq frames sent under Delayed and HT-delayed agreements, the BAR Ack Policy subfield of
the BAR Control field has the meaning shown in Table 9-21. For BlockAckReq frames sent under other
types of agreement, the BAR Ack Policy subfield is reserved.
Table 9-21—BAR Ack Policy subfield
Value Meaning
0 Normal Acknowledgment.
The BAR Ack Policy subfield is set to this value when the sender requires immediate acknowledgment.
The addressee returns an Ack frame.
See 10.29.2.7.
The value 0 is not used in frames transmitted by a DMG STA.
1 No Acknowledgment.
The addressee sends no immediate response upon receipt of the frame.
The BAR Ack Policy subfield is set to this value when the sender does not require immediate
acknowledgment.
The value 1 is not used in a Basic BlockAckReq frame outside a PSMP sequence.
The value 1 is not used in an Multi-TID BlockAckReq frame.
The values of the Multi-TID, Compressed Bitmap, and GCR subfields determine which of four possible
BlockAckReq frame variants is represented, as indicated in Table 9-22.
673
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-22—BlockAckReq frame variant encoding
Multi-TID Compressed Bitmap GCR
BlockAckReq frame variant
subfield value subfield value subfield value
0 0 0 Basic BlockAckReq
0 1 0 Compressed BlockAckReq
1 0 0 Extended Compressed BlockAckReq
1 1 0 Multi-TID BlockAckReq
0 0 1 Reserved
0 1 1 GCR BlockAckReq
1 0 1 Reserved
1 1 1 Reserved
DMG STAs use only the Compressed BlockAckReq variant and the Extended Compressed BlockAckReq
variant.
The meaning of the TID_INFO subfield of the BAR Control field depends on the BlockAckReq frame
variant type. The meaning of this subfield is explained within the subclause for each of the BlockAckReq
frame variants.
The meaning of the BAR Information field of the BlockAckReq frame depends on the BlockAckReq frame
variant type. The meaning of this field is explained within the subclause for each of the BlockAckReq frame
variants.
NOTE—Reference to “a BlockAckReq” frame without any other qualification from other subclauses applies to any of
the variants, unless specific exclusions are called out.
9.3.1.8.2 Basic BlockAckReq variant
The use of the basic BlockAckReq variant is obsolete. Consequently, this subclause might be removed in a
later revision of the standard.
The TID_INFO subfield of the BAR Control field of the Basic BlockAckReq frame contains the TID for
which a Basic BlockAck frame is requested.
The BAR Information field of the Basic BlockAckReq frame contains the Block Ack Starting Sequence
Control subfield, as shown in Figure 9-28. The Starting Sequence Number subfield of the Block Ack
Starting Sequence Control subfield contains the sequence number of the first MSDU for which this Basic
BlockAckReq frame is sent. The Fragment Number subfield is set to 0.
B0 B3 B4 B15
Fragment Number Starting Sequence
(0) Number
Bits: 4 12
Figure 9-28—Block Ack Starting Sequence Control subfield
674
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.3.1.8.3 Compressed BlockAckReq variant
The TID_INFO subfield of the BAR Control field of the Compressed BlockAckReq frame contains the TID
for which a BlockAck frame is requested.
The BAR Information field of the Compressed BlockAckReq frame contains the Block Ack Starting
Sequence Control subfield, as shown in Figure 9-28. The Starting Sequence Number subfield of the Block
Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for
which this BlockAckReq frame is sent. The Fragment Number subfield of the Block Ack Starting Sequence
Control subfield is set to 0.
9.3.1.8.4 Extended Compressed BlockAckReq variant
The TID_INFO subfield of the BAR Control field of the Extended Compressed BlockAckReq frame
contains the TID for which a BlockAck frame is requested.
The BAR Information field of the Extended Compressed BlockAckReq frame contains the Block Ack
Starting Sequence Control subfield, as shown in Figure 9-28 8-21. The Starting Sequence Number subfield
of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or
A-MSDU for which this BlockAckReq frame is sent. The Fragment Number subfield of the Block Ack
Starting Sequence Control subfield is set to 0.
9.3.1.8.5 Multi-TID BlockAckReq variant
The TID_INFO subfield of the BAR Control field of the Multi-TID BlockAckReq frame determines the
number of TIDs present in the Multi-TID BlockAckReq frame as given by TID_INFO + 1, e.g., a value of 2
in the TID_INFO subfield means that three TID values are present in the Multi-TID BlockAckReq frame’s
BAR Information field.
The BAR Information field of the Multi-TID BlockAckReq frame comprises multiple sets of Per TID Info
subfields and Block Ack Starting Sequence Control subfields, as shown in Figure 9-29. The Per TID
Info subfield is shown in Figure 9-30. The Block Ack Starting Sequence Control subfield is shown in
Figure 9-28. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield
contains the sequence number of the first MSDU or A-MSDU for which this BlockAckReq frame is sent.
The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0.
Octets: 2 2
Per TID
Info Block Ack Starting Sequence Control
Repeat for each TID
Figure 9-29—BAR Information field (Multi-TID BlockAckReq)
B0 B11 B12 B15
Reserved TID Value
Bits: 12 4
Figure 9-30—Per TID Info subfield
675
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.3.1.8.6 GCR BlockAckReq variant
The TID_INFO subfield of the BAR Control field of the GCR BlockAckReq frame is set to 0.
The BAR Information field of the GCR BlockAckReq frame contains the Block Ack Starting Sequence
Control subfield and GCR Group Address subfield, as shown in Figure 9-31. The Block Ack Starting
Sequence Control subfield is shown in Figure 9-28. The Starting Sequence Number subfield of the Block
Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for
which this BlockAckReq frame is sent. The Fragment Number subfield of the Block Ack Starting Sequence
Control subfield is set to 0.
B0 B15 B16 B63
Block Ack Starting Sequence Control GCR Group Address
Bits: 16 48
Figure 9-31—BAR Information field format (GCR BlockAckReq)
The GCR Group Address subfield contains the MAC address of the group for which reception status is being
requested.
9.3.1.9 BlockAck frame format
9.3.1.9.1 Overview
The frame format of the BlockAck frame is defined in Figure 9-32.
Octets: 2 2 6 6 2 variable 4
Frame Control Duration RA TA BA BA FCS
Control Information
MAC header
Figure 9-32—BlockAck frame
The Duration field value is set as defined in 9.2.5.
The RA field of the BlockAck frame is the address of the recipient STA that requested the Block Ack.
The TA field value is the address of the STA transmitting the BlockAck frame or a bandwidth signaling TA
in the context of HT-delayed Block Ack. In a BlockAck frame transmitted in the context of HT-delayed
Block Ack by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence
carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field value is a bandwidth
signaling TA.
The BA Control field is defined in Figure 9-33.
676
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3 B4 B11 B12 B15
BA Ack Multi- Compressed
Policy TID Bitmap GCR Reserved TID_INFO
Bits: 1 1 1 1 8 4
Figure 9-33—BA Control field
For BlockAck frames sent under Delayed and HT-delayed agreements, the BA Ack Policy subfield of the
BA Control field has the meaning shown in Table 9-23. For BlockAck frames sent under other types of
agreement, the BA Ack Policy subfield is reserved.
Table 9-23—BA Ack Policy subfield
Value Meaning
0 Normal Acknowledgment.
The BA Ack Policy subfield is set to this value when the sender requires immediate acknowledgment.
The addressee returns an Ack frame.
The value 0 is not used for data sent under HT-delayed Block Ack during a PSMP sequence.
The value 0 is not used in frames transmitted by DMG STAs.
1 No Acknowledgment.
The addressee sends no immediate response upon receipt of the frame.
The BA Ack Policy is set to this value when the sender does not require immediate acknowledgment.
The value 1 in a Compressed BlockAck frame indicates HT-delayed block ack. HT-delayed block ack
is obsolete and this value might be reserved in a later revision of the standard.
The value 1 is not used in a Basic BlockAck frame outside a PSMP sequence.
The value 1 is not used in an Multi-TID BlockAck frame.
The values of the Multi-TID, Compressed Bitmap, and GCR subfields of the BA Control field determine
which of the BlockAck frame variants is represented, as indicated in the Table 9-24.
Table 9-24—BlockAck frame variant encoding
Multi-TID Compressed Bitmap GCR
BlockAck frame variant
subfield value subfield value subfield value
0 0 0 Basic BlockAck
0 1 0 Compressed BlockAck
1 0 0 Extended Compressed
BlockAck
1 1 0 Multi-TID BlockAck
0 0 1 Reserved
0 1 1 GCR BlockAck
1 0 1 Reserved
1 1 1 Reserved
677
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—Reference to “a BlockAck” frame without any other qualification from other subclauses applies to any of the
variants, unless specific exclusions are called out.
The GCR field indicates whether the BlockAck frame was sent in response to a GCR BlockAckReq frame.
The GCR field is set to 1 when the BlockAck frame is sent in response to a GCR BlockAckReq frame and
set to 0 otherwise.
The meaning of the TID_INFO subfield of the BA Control field depends on the BlockAck frame variant
type. The meaning of this subfield is explained within the subclause for each of the BlockAck frame
variants.
The meaning of the BA Information field depends on the BlockAck frame variant type. The meaning of this
field is explained within the subclause for each of the BlockAck frame variants.
9.3.1.9.2 Basic BlockAck variant
The use of the basic BlockAck variant is obsolete. This subclause might be removed in a later revision of the
standard.
The TID_INFO subfield of the BA Control field of the Basic BlockAck frame contains the TID for which
this BlockAck frame is sent.
The BA Information field of the Basic BlockAck frame comprises the Block Ack Starting Sequence Control
subfield and the Block Ack Bitmap subfield, as shown in Figure 9-34. The format of the Block Ack Starting
Sequence Control subfield is shown in Figure 9-28. The Starting Sequence Number subfield of the Block
Ack Starting Sequence Control subfield contains the sequence number of the first MSDU for which this
Basic BlockAck frame is sent and is set to the same value as in the immediately previously received Basic
BlockAckReq frame.
Block Ack Starting Sequence Control Block Ack Bitmap
Octets: 2 128
Figure 9-34—BA Information field (BlockAck)
The Block Ack Bitmap subfield is 128 octets in length and is used to indicate the received status of up to
64 MSDUs. Bit position n of the Block Ack Bitmap field, if equal to 1, acknowledges receipt of an MPDU
with an MPDU sequence control value equal to (SSC + n), where SSC is the value of the Block Ack Starting
Sequence Control subfield. Bit position n of the Block Ack Bitmap field, if equal to 0, indicates that an
MPDU with MPDU sequence control value equal to (SSC + n) has not been received. Each of the MPDU
Sequence Control field and Block Ack Starting Sequence Control subfield values are treated as a 16-bit
unsigned integer. For unused fragment numbers of an MSDU, the corresponding bits in the bitmap are set
to 0.
9.3.1.9.3 Compressed BlockAck variant
The TID_INFO subfield of the BA Control field of the Compressed BlockAck frame contains the TID for
which this BlockAck frame is sent.
The BA Information field of the Compressed BlockAck frame comprises the Block Ack Starting Sequence
Control subfield and the Block Ack Bitmap subfield, as shown in Figure 9-35. The Starting Sequence
Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the
first MSDU or A-MSDU for which this BlockAck frame is sent. The value of this subfield is defined in
10.24.7.5. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0.
678
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Block Ack Starting Sequence Control Block Ack Bitmap
Octets: 2 8
Figure 9-35—BA Information field (Compressed BlockAck)
The Block Ack Bitmap subfield of the BA Information field of the Compressed BlockAck frame is 8 octets
in length and is used to indicate the received status of up to 64 entries, where each entry represents an
MSDU or an A-MSDU. Each bit that is equal to 1 in the compressed Block Ack Bitmap field acknowledges
the successful reception of a single MSDU or A-MSDU in the order of sequence number, with the first bit of
the Block Ack Bitmap field corresponding to the MSDU or A-MSDU with the sequence number that
matches the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Control
subfield.
9.3.1.9.4 Multi-TID BlockAck variant
The TID_INFO subfield of the BA Control field of the Multi-TID BlockAck frame contains the number of
TIDs, less one, for which information is reported in the BA Information field. For example, a value of 2 in
the TID_INFO subfield means that information for three TIDs is present.
The BA Information field of the Multi-TID BlockAck frame comprises one or more instances of the Per TID
Info, Block Ack Starting Sequence Control, and the Block Ack Bitmap subfields, as shown in Figure 9-36.
The Per TID Info subfield is shown in Figure 9-30, and the Block Ack Starting Sequence Control subfield is
shown in Figure 9-28.
Octets: 2 2 8
Per TID Info Block Ack Starting Sequence Control Block Ack Bitmap
Repeat for each TID
Figure 9-36—BA Information field (Multi-TID BlockAck)
The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield is the
sequence number of the first MSDU or A-MSDU for which this BlockAck frame is sent. The value of this
subfield is defined in 10.24.7.5. The Fragment Number subfield of the Block Ack Starting Sequence Control
subfield is set to 0. The first instance of the Per TID Info, Block Ack Starting Sequence Control, and Block
Ack Bitmap subfields that is transmitted corresponds to the lowest TID value, with subsequent instances
ordered by increasing values of the Per TID Info subfield.
The Block Ack Bitmap subfield of the BA Information field of the Multi-TID BlockAck frame contains an
8-octet block ack bitmap. Each bit that is equal to 1 in the Block Ack Bitmap subfield acknowledges the
successful reception of a single MSDU or A-MSDU in the order of sequence number with the first bit of the
Block Ack Bitmap subfield corresponding to the MSDU or A-MSDU with the sequence number that
matches the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Control
subfield.
9.3.1.9.5 Extended Compressed BlockAck variant
The TID_INFO subfield of the BA Control field of the Compressed BlockAck frame contains the TID for
which a BlockAck frame is requested.
679
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The BA Information field of the Extended Compressed BlockAck frame is shown in Figure 9-37. The
Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the
sequence number of the first MSDU or A-MSDU for which this BlockAck frame is sent. The value of this
subfield is defined in 10.24.7.5. The Fragment Number subfield of the Block Ack Starting Sequence Control
subfield is set to 0.
Block Ack Starting Sequence Control Block Ack Bitmap RBUFCAP
Octets: 2 8 1
Figure 9-37—BA Information field (Extended Compressed BlockAck)
The Block Ack Bitmap subfield of the BA Information field of the Extended Compressed BlockAck frame
is 8 octets in length and is used to indicate the received status of up to 64 entries, where each entry represents
an MSDU or an A-MSDU. Each bit that is set to 1 in the Block Ack Bitmap subfield acknowledges the
successful reception of a single MSDU or A-MSDU in the order of sequence number. The first bit of the
Block Ack Bitmap subfield corresponds to the MSDU or A-MSDU with the sequence number that matches
the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield.
The RBUFCAP field contains an unsigned integer that is the number of MPDU buffers available to store
received MPDUs at the time of transmission of the Extended Compressed BlockAck frame (10.39).
9.3.1.9.6 GCR Block Ack variant
The TID_INFO subfield of the BA Control field of the GCR BlockAck frame contains the TID for which
this BlockAck frame is sent.
The BA Information field of the GCR BlockAck frame comprises the Block Ack Starting Sequence Control,
GCR Group Address, and the Block Ack Bitmap subfields, as shown in Figure 9-38. The Block Ack Starting
Sequence Control subfield is shown in Figure 9-28. The Starting Sequence Number subfield of the Block
Ack Starting Sequence Control subfield contains the sequence number of the first A-MSDU for which this
BlockAck frame is sent. The value of this subfield is defined in 10.24.10. The Fragment Number subfield of
the Block Ack Starting Sequence Control subfield is set to 0.
Block Ack Starting Sequence Control GCR Group Address Block Ack Bitmap
Octets: 2 6 8
Figure 9-38—BA Information field format (GCR BlockAck)
The GCR Group Address subfield is set to the value from the Group Address subfield of the GCR BAR
Information field in the BlockAckReq frame to which the BlockAck frame is sent in response.
The Block Ack Bitmap subfield is 8 octets in length and is used to indicate the received status of up to
64 entries, where each entry represents an MSDU or an A-MSDU. Each bit that is equal to 1 in the Block
Ack Bitmap subfield acknowledges the successful reception of a single MSDU or A-MSDU in the order of
sequence number, with the first bit of the Block Ack Bitmap subfield corresponding to the MSDU or
A-MSDU with the sequence number that matches the value of the Starting Sequence Number subfield of the
Block Ack Starting Sequence Control subfield.
9.3.1.10 Control Wrapper frame
The format of the Control Wrapper frame is shown in Figure 9-39.
680
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Frame Duration/ Address Carried Frame HT Carried
Control ID 1 Control Control Frame FCS
Octets: 2 2 6 2 4 variable 4
Figure 9-39—Control Wrapper frame
The Control Wrapper frame is used to wrap any other Control frame (i.e., excluding the Control Wrapper
frame) together with an HT Control field.
The Frame Control field is defined in 9.3.1. The value of the subtype field is the value from Table 9-1 of
9.2.4.1.3 that corresponds to Control Wrapper frame.
The value of the Duration/ID field of the Control Wrapper frame is generated by following the rules for the
Duration/ID field of the Control frame that is being wrapped.
The value of the Address 1 field of the Control Wrapper frame is generated by following the rules for the
Address 1 field of the Control frame that is being wrapped.
The Carried Frame Control field contains the value of the Frame Control field of the wrapped Control frame.
The HT Control field is defined in 9.2.4.6.
The Carried Frame field contains the fields that follow the Address 1 field of the Control frame that is being
wrapped, excluding the FCS field.
The FCS field is defined in 9.2.4.8.
9.3.1.11 Poll frame format
The format of the Poll frame is shown in Figure 9-40.
Frame Duration RA TA Response FCS
Control Offset
Octets: 2 2 6 6 2 4
Figure 9-40—Poll frame format
The Duration field is set to include the duration, in microseconds, of the remaining Poll frame transmissions
(see 10.36.7.2), plus all appropriate IFSs (10.3.2.3), plus the duration of the SPR frame transmissions.
The RA field contains the MAC address of the STA being polled.
The TA field contains the MAC address of the AP or PCP.
The Response Offset field indicates the offset, in units of 1 µs, beginning SIFS after the end of the Poll
frame when the SPR frame in response to this Poll frame is transmitted.
9.3.1.12 Service period request (SPR) frame format
The format of the SPR frame is shown in Figure 9-41.
681
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Frame Duration RA TA Dynamic BF Control FCS
Control Allocation Info
Octets: 2 2 6 6 5 2 4
Figure 9-41—SPR frame format
When an SPR frame is sent in response to a Poll frame (see 10.36.7), the Duration field in the SPR frame is
set to the value of the Duration field contained in the Poll frame, minus the value of the Response Offset
field contained in the Poll frame multiplied by its unit as specified in 9.3.1.11, minus SIFS, minus the time
taken to transmit the SPR frame. When the SPR frame is not sent in response to a Poll frame (see 10.36.9
and 11.4.13) and transmitted within an SP or a TXOP allocation, the Duration field is set to the time left in
the allocation excluding the SPR transmission time. In all other cases, the Duration field is set to 0.
The RA field contains the MAC address of the AP or PCP.
The TA field contains the MAC address of the STA transmitting the SP request.
The Dynamic Allocation Info field is defined in 9.5.2.
The BF Control field is defined in 9.5.5.
9.3.1.13 Grant frame format
The format of the Grant frame is shown in Figure 9-42.
Frame Control Duration RA TA Dynamic BF Control FCS
Allocation Info
Octets: 2 2 6 6 5 2 4
Figure 9-42—Grant frame format
For individually addressed Grant frames:
— If the Grant frame is used to obtain a TXOP, the Duration/ID field is set to a value subject to the
TXOP limit as described in 10.22.2.8. In all other cases within a CBAP, the Duration/ID field is set
to the value equal of Duration/ID field of the immediately preceding frame minus TXTIME(Grant
frame) minus aSIFSTime.
— If the Grant frame is sent within an SP, the value of the Duration/ID field is set according to the rules
in 10.36.7, 10.36.8, and 10.36.9 as appropriate depending on the Grant frame usage.
— If the Grant frame is sent within an ATI, the value the Duration/ID is set according to the rules in
10.36.3.
For group addressed Grant frames, the Duration/ID field is set to a value that is equal to the time between
PHY-TXEND.indication primitive of the Grant frame and the start of the allocation as indicated by the value
of the Allocation Duration subfield within the Dynamic Allocation Info field.
The RA field contains the MAC address of the STA receiving the SP grant.
The TA field contains the MAC address of the STA that has transmitted the Grant frame.
The Dynamic Allocation Info field is defined in 9.5.2.
The BF Control field is defined in 9.5.5.
682
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.3.1.14 DMG CTS frame format
The frame format for the DMG CTS frame is as defined in Figure 9-43.
Frame Control Duration RA TA FCS
Octets: 2 2 6 6 4
Figure 9-43—DMG CTS frame format
When the DMG CTS frame is a response to an RTS frame, the value of the RA field of the DMG CTS frame
is set to the address from the TA field of the RTS frame. When the DMG CTS frame is the first frame in a
frame exchange, the RA field is set to the MAC address of the transmitter.
A DMG CTS-to-self frame is a DMG CTS frame in which the RA field is equal to the transmitter’s MAC
address.
For DMG CTS frames other than DMG CTS-to-self frames, the Duration field is set to the value of the
Duration field of the immediately previous RTS frame, minus the time, in microseconds, required to
transmit the DMG CTS frame and its SIFS interval. For DMG CTS-to-self frames, the Duration field is set
to the remaining duration of the TXOP or SP. If the calculated duration includes a fractional microsecond,
that value is rounded up to the next higher integer.
For DMG CTS frames other than DMG CTS-to-self frames, the TA field is the MAC address of the STA
transmitting the DMG CTS frame. For DMG CTS-to-self frames, the TA field is set to the individual
address of the recipient or the group address of the recipients of the frame that the DMG STA intends to
transmit after the DMG CTS-to-self frame.
9.3.1.15 DMG DTS frame format
The frame format for the DMG Denial to Send (DTS) frame is as defined in Figure 9-44.
Frame Control Duration RA NAV-SA NAV-DA FCS
Octets: 2 2 6 6 6 4
Figure 9-44—DMG DTS frame format
The Duration field is set to the value of the transmitting STA’s NAV – (TXTIME(DMG DTS) + SIFS) or
the remaining time in the SP at the end of the DMG DTS frame transmission, whichever is smaller. The
transmitting STA’s NAV is the value of its NAV at the start of the DMG DTS frame transmission.
The RA field of the frame is copied from the TA field of the immediately previous RTS frame to which the
DMG DTS frame is a response.
The NAV-SA and the NAV-DA fields contain the MAC addresses of the source DMG STA and the
destination DMG STA, respectively, whose exchange of an RTS and DMG CTS frame caused the last
update to the NAV at the transmitting STA.
9.3.1.16 Sector sweep (SSW) frame format
The frame format for the SSW frame is as defined in Figure 9-45.
683
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Frame Duration RA TA SSW SSW FCS
Control Feedback
Octets: 2 2 6 6 3 3 4
Figure 9-45—SSW frame format
The Duration field is set to the time until the end of the current SSW slot when the SSW frame is transmitted
within an association beamforming training (A-BFT). Otherwise, it is set to the time until the end of the
SSW frame transmission that has the CDOWN subfield within the SSW field equal to 0, plus MBIFS, or
until the end of the current allocation (see 10.38), whichever comes first.
The RA field contains the MAC address of the STA that is the intended receiver of the sector sweep.
The TA field contains the MAC address of the transmitter STA of the sector sweep frame.
The SSW field is defined in 9.5.1.
The SSW Feedback field is defined in 9.5.3.
9.3.1.17 Sector sweep feedback (SSW-Feedback) frame format
The format of the SSW-Feedback frame is shown in Figure 9-46.
Frame Duration RA TA SSW BRP Beamformed FCS
Control Feedback Request Link
Maintenance
Octets: 2 2 6 6 3 4 1 4
Figure 9-46—SSW-Feedback frame format
The Duration field is set to 0 when the SSW-Feedback frame is transmitted within an association
beamforming training (A-BFT). When transmitted within a DTI, the Duration field is set to one of the
following:
a) If a BRP phase is requested through the BRP Request field, the Duration field is set to the time, in
microseconds, required to transmit an SSW-Ack frame plus 2×MBIFS (10.38.3.1).
b) If a BRP phase is not requested, the Duration field is set to the time, in microseconds, required to
transmit an SSW-Ack frame, plus MBIFS (10.38.3.1) or the time until the end of the current
allocation, whichever comes earlier.
The RA field contains the MAC address of the STA that is the intended destination of the SSW-Feedback
frame.
The TA field contains the MAC address of the STA transmitting the SSW-Feedback frame.
The SSW Feedback field is defined in 9.5.3.
The BRP Request field is defined in 9.5.4.
The Beamformed Link Maintenance field is defined in 9.5.6.
9.3.1.18 Sector sweep Ack (SSW-Ack) frame format
The format of the SSW-Ack frame is shown in Figure 9-47.
684
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Frame Duration RA TA SSW BRP Beamformed FCS
Control Feedback Request Link
Maintenance
Octets: 2 2 6 6 3 4 1 4
Figure 9-47—SSW-Ack frame format
The Duration field is set to the value of the Duration field of the immediately preceding SSW-Feedback
frame, minus MBIFS, minus the time required to transmit the SSW-Ack frame.
The RA field contains the MAC address of the STA that is the intended destination of the SSW-Ack frame.
The TA field contains the MAC address of the STA transmitting the SSW-Ack frame.
The SSW Feedback field is defined in 9.5.3.
The BRP Request field is defined in 9.5.4.
The Beamformed Link Maintenance field is defined in 9.5.6.
9.3.1.19 Grant Ack frame format
The format of the Grant Ack frame is shown in Figure 9-48. The Grant Ack frame is sent as a response to the
reception of a Grant frame.
Frame Control Duration RA TA Reserved BF Control FCS
Octets: 2 2 6 6 5 2 4
Figure 9-48—Grant Ack frame format
The Duration field is set to the value obtained from the Duration/ID field of the immediately previous Grant
frame minus the time, in microseconds, required to transmit the Grant Ack frame and its SIFS interval.
The RA field of the Grant Ack frame is copied from the Address 2 field of the immediately previous Grant
frame.
The TA field contains the MAC address of the STA that has transmitted the Grant Ack frame.
The BF Control field is defined in 9.5.5.
9.3.1.20 VHT NDP Announcement frame format
The frame format of the VHT NDP Announcement frame is shown in Figure 9-49.
Sounding
Frame Duration RA TA Dialog STA Info 1 … STA Info n FCS
Control
Token
Octets: 2 2 6 6 1 2 2 4
Figure 9-49—VHT NDP Announcement frame format
The Duration field is set as defined in 9.2.5.
685
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The VHT NDP Announcement frame contains at least one STA Info field. If the VHT NDP Announcement
frame contains only one STA Info field, then the RA field is set to the address of the STA that can provide
feedback (see 10.34.5.2). If the VHT NDP Announcement frame contains more than one STA Info field,
then the RA field is set to the broadcast address.
The TA field is set to the address of the STA transmitting the VHT NDP Announcement frame or the
bandwidth signaling TA of the STA transmitting the VHT NDP Announcement frame. In a VHT NDP
Announcement frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the
scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field is
set to a bandwidth signaling TA.
The format of the Sounding Dialog Token field is shown in Figure 9-50.
B0 B1 B2 B7
Reserved Sounding Dialog
Token Number
Bits: 2 6
Figure 9-50—Sounding Dialog Token field
The Sounding Dialog Token Number subfield in the Sounding Dialog Token field contains a value selected
by the beamformer to identify the VHT NDP Announcement frame.
The format of the STA Info field is shown in Figure 9-51.
B0 B11 B12 B13 B15
AID12 Feedback Type Nc Index
Bits: 12 1 3
Figure 9-51—STA Info field
The subfields in the STA Info field are described in Table 9-25.
Table 9-25—STA Info subfields
Field Description
AID12 Contains the 12 least significant bits of the AID of a STA expected to process the
following VHT NDP and prepare the sounding feedback. Equal to 0 if the STA is
an AP, mesh STA, or STA that is a member of an IBSS.
Feedback Type Indicates the type of feedback requested.
Set to 0 for SU.
Set to 1 for MU.
Nc Index If the Feedback Type field indicates MU, then Nc Index indicates the number of
columns, Nc, in the Compressed Beamforming Feedback Matrix subfield minus 1:
Set to 0 to request Nc = 1
Set to 1 to request Nc = 2
…
Set to 7 to request Nc = 8
Reserved if the Feedback Type field indicates SU.
686
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.3.1.21 Beamforming Report Poll frame format
The Beamforming Report Poll frame is shown in Figure 9-52.
Frame Duration RA TA Feedback Segment FCS
Control Retransmission Bitmap
Octets: 2 2 6 6 1 4
Figure 9-52—Beamforming Report Poll frame format
The Duration field is set as defined in 9.2.5.
The RA field is set to the address of the intended recipient.
The TA field is set to the address of the STA transmitting the Beamforming Report Poll or a bandwidth
signaling TA. In a Beamforming Report Poll frame transmitted by a VHT STA in a non-HT or non-HT
duplicate format and where the scrambling sequence carries the TXVECTOR parameter
CH_BANDWIDTH_IN_NON_HT, the TA field is set to a bandwidth signaling TA.
The Feedback Segment Retransmission Bitmap field indicates the requested feedback segments of a VHT
Compressed Beamforming report (see 10.34.5.3). If the bit in position n (n=0 for LSB and n=7 for MSB) is
1, then the feedback segment with the Remaining Feedback Segments subfield in the VHT MIMO Control
field equal to n is requested. If the bit in position n is 0, then the feedback segment with the Remaining
Feedback Segments subfield in the VHT MIMO Control field equal to n is not requested.
9.3.2 Data frames
9.3.2.1 Format of Data frames
The format of a Data frame is defined in Figure 9-53. The Frame Control, Duration, Address 1, Address 2,
Address 3, and Sequence Control fields are present in all data frame subtypes. The presence of the Address
4 field is determined by the setting of the To DS and From DS subfields of the Frame Control field (see
below). The QoS Control field is present when the QoS subfield of the Subtype subfield is set to 1.
Octets:
2 2 6 6 6 2 0 or 6 0 or 2 0 or 4 variable 4
Frame Address Address Address Sequence Address QoS HT Frame
Duration FCS
Control 1 2 3 Control 4 Control Control Body
MAC header
Figure 9-53—Data frame
NOTE—The maximum frame body size shown in Figure 9-53 is for GCMP encryption of a maximum-size A-MSDU
(note that TKIP encryption is not allowed in this case and any Mesh Control fields are part of the A-MSDU subframes).
The corresponding maximum for CCMP encryption is 7951 octets. The maximum frame body size if A-MSDUs are not
used is 2346 octets for GCMP encryption of a maximum-size MSDU, 2338 octets for CCMP encryption of a maximum-
size MSDU and 2342 octets for TKIP encryption of a maximum-size MSDU, including in both cases an 18-octet Mesh
Control field. The frame body size might in all cases be greater if a vendor-specific cipher suite is used.
687
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Data frames with a value of 1 in the QoS subfield of the Subtype subfield are collectively referred to as QoS
Data frames. Each of these data subtypes contains QoS in their names, and this frame format is
distinguished by the presence of a QoS Control field in the MAC header.
A QoS STA always uses QoS Data frames for data transmissions to other QoS STAs. A QoS STA uses
frames with the QoS subfield of the Subtype subfield set to 0 for data transmissions to non-QoS STAs. A
non-QoS STA always uses frames with the QoS subfield of the Subtype subfield set to 0 for data
transmissions to other STAs. All STAs use frames with the QoS subfield of the Subtype subfield set to 0 for
nonconcealed GCR broadcast Data frames unless a transmitting STA knows that all STAs in a BSS have
QoS capability, in which case the transmitting STAs use QoS Data frames. All STAs use frames with the
QoS subfield of the Subtype subfield set to 0 for nonconcealed GCR group addressed Data frames unless it is
known to the transmitter that all STAs in the BSS that are members of the multicast group have QoS
capability, in which case STAs use QoS Data frames. APs where dot11RobustAVStreamingImplemented is
true or mesh STAs where dot11MeshGCRImplemented is true use frames with the QoS subfield of the
Subtype subfield set to 1 for concealed GCR frames, as described in 11.24.16.3.5.
The content of the address fields of Data frames are dependent upon the values of the To DS and From DS
subfields in the Frame Control field and whether the Frame Body field contains either an MSDU
(or fragment thereof) or an entire A-MSDU, as determined by the A-MSDU Present subfield of the QoS
Control field (see 9.2.4.5.9). The content of the address fields transmitted by nonmesh STAs is defined in
Table 9-26. The content of the address fields transmitted by mesh STAs is defined in 9.3.5. Where the
content of a field is shown as not applicable (N/A), the field is omitted. Note that Address 1 always holds the
receiver address of the intended receiver (or, in the case of group addressed frames, receivers), and that
Address 2 always holds the address of the STA that is transmitting the frame.
Table 9-26—Address field contents
Address 3 Address 4
To From MSDU and MSDU and
Address 1 Address 2 Basic Basic
DS DS Short Short
A-MSDU A-MSDU
A-MSDU A-MSDU
case case
case case
0 0 RA = DA TA = SA BSSID BSSID N/A N/A
0 1 RA = DA TA = BSSID SA BSSID N/A N/A
1 0 RA = BSSID TA = SA DA BSSID N/A N/A
1 1 RA TA DA BSSID SA BSSID
A STA uses the contents of the Address 2 field to direct the acknowledgment if an acknowledgment is
necessary.
The DA field contains the destination of the MSDU (or fragment thereof) or A-MSDU in the Frame Body
field.
The SA field contains the address of the MAC entity that initiated the MSDU (or fragment thereof) or
A-MSDU in the Frame Body field.
When a Data frame carries an MSDU (or fragment thereof), the DA and SA values related to that MSDU are
carried in the Address 1, Address 2, Address 3, and Address 4 fields (according to the setting of the To DS
and From DS subfields) as defined in Table 9-26.
688
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When a Data frame carries an A-MSDU, the DA and SA values related to each MSDU carried by the
A-MSDU are carried within the A-MSDU. Zero, one, or both of these fields are present in the Address 1 and
Address 2 fields as indicated in Table 9-26.
The RA field is the individual address of the STA that is the immediate intended receiver of the frame or the
group address of the STAs that are the immediate intended receivers of the frame.
The TA field is the address of the STA that is transmitting the frame.
The BSSID of the Data frame is determined as follows:
a) If the STA is contained within an AP or is associated with an AP, the BSSID is the address currently
in use by the STA contained in the AP.
b) If the STA is a member of an IBSS, the BSSID is the BSSID of the IBSS.
c) If the STA is transmitting a Data frame when dot11OCBActivated is true, the BSSID is the wildcard
BSSID.
d) If the STA is a member of an MBSS, the BSSID is the address of the transmitter and is equal to the
Data frame’s TA.
e) If the STA participates in a PBSS, the BSSID is the address of the STA contained in the PCP of the
PBSS.
The Sequence Control field is defined in 9.2.4.4.
The QoS Control field is defined in 9.2.4.5. The presence of the QoS Control field is determined by the
Subtype subfield of the Frame Control field, as specified in 9.2.4.1.3.
The HT Control field is defined in 9.2.4.6. The presence of the HT Control field is determined by the +HTC/
Order subfield of the Frame Control field, as specified in 9.2.4.1.10.
The frame body consists of either:
— The MSDU (or a fragment thereof), the Mesh Control field (present if the frame is transmitted by a
mesh STA and the Mesh Control Present subfield of the QoS Control field is 1, otherwise absent),
and a security header and trailer (present if the Protected Frame subfield in the Frame Control field
is 1, otherwise absent)
— The A-MSDU and a security header and trailer (present if the Protected Frame subfield in the Frame
Control field is 1, otherwise absent)
The presence of an A-MSDU in the frame body is indicated by setting the A-MSDU Present subfield of the
QoS Control field to 1, as shown in Table 9-6.
For Data frames of subtype Null (no data), CF-Ack (no data), CF-Poll (no data), and CF-Ack +CF-Poll (no
data) and for the corresponding QoS data frame subtypes, the Frame Body field is null (i.e., has a length of 0
octets); these subtypes are used for MAC control purposes. For Data frames of subtypes Data, Data +CF-
Ack, Data +CF-Poll, and Data +CF-Ack +CF-Poll, the Frame Body field contains all of, or a fragment of, an
MSDU after any encapsulation for security. For Data frames of subtypes QoS Data, QoS Data +CF-Ack,
QoS Data +CF-Poll, and QoS Data +CF-Ack +CF-Poll, the Frame Body field contains an MSDU (or
fragment thereof) or A-MSDU after any encapsulation for security. For Data frames of subtype QoS Data
that are transmitted by a mesh STA, the Frame Body field also contains a Mesh Control field, as described in
9.2.4.7.3.
The maximum length of the Frame Body field can be determined from the maximum MSDU length plus the
length of the Mesh Control field (if present) plus any overhead from encapsulation for encryption (i.e., it is
always possible to send a maximum length MSDU, with any encapsulations provided by the MAC layer
689
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
within a single Data frame). When the frame body carries an A-MSDU, the size of the frame body field is
limited by:
— The PHY’s maximum PHY service data unit (PSDU) length
— If A-MPDU aggregation is used by a non-VHT and non-DMG STA, a maximum MPDU length of
4095 octets (see 9.7)
Within all Data frames sent by STAs during the CFP under PCF, the Duration field is set to 32 768. Within
all Data frames sent by the QoS STA, the Duration field contains a duration value as defined in 9.2.5. Within
all Data frames sent during the CP by non-QoS STAs, the Duration field is set according to the following
rules:
— If the Address 1 field contains a group address, the duration value is set to 0.
— If the More Fragments bit is 0 in the Frame Control field of a frame and the Address 1 field contains
an individual address, the duration value is set to the time, in microseconds, required to transmit one
Ack frame, plus one SIFS.
— If the More Fragments bit is 1 in the Frame Control field of a frame and the Address 1 field contains
an individual address, the duration value is set to the time, in microseconds, required to transmit the
next fragment of this Data frame, plus two Ack frames, plus three SIFSs.
The duration value calculation for the Data frame is based on the rules in 10.7 that determine the data rate at
which the Control frames in the frame exchange sequence are transmitted. If the calculated duration includes
a fractional microsecond, that value is rounded up to the next higher integer. All STAs process Duration
field values less than or equal to 32 767 from valid Data frames (without regard for the RA, DA, and/or
BSSID address values that might be present in these frames) to update their NAV settings as appropriate
under the coordination function rules.
NOTE 1—The QoS Data and QoS Null subtypes are the only Data subtypes transmitted by a DMG STA.
NOTE 2—The HT Control field is not present in frames transmitted by a DMG STA.
9.3.2.2 Aggregate MSDU (A-MSDU) format
9.3.2.2.1 General
An A-MSDU is a sequence of A-MSDU subframes as shown in Figure 9-54. Each A-MSDU subframe
consists of an A-MSDU subframe header followed by an MSDU and 0 to 3 octets of padding as shown in
Figure 9-55 (in 9.3.2.2.2) and Figure 9-57 (in 9.3.2.2.3).
A-MSDU subframe 1 A-MSDU subframe 2 … A-MSDU subframe n
Figure 9-54—A-MSDU structure
Two A-MSDU subframe formats are defined: the Basic A-MSDU subframe described in 9.3.2.2.2 and the
Short A-MSDU subframe described in 9.3.2.2.3. Unless otherwise noted, in this standard, the term
A-MSDU applies to both the Basic A-MSDU and the Short A-MSDU. The Basic A-MSDU uses only the
Basic A-MSDU subframe format, while the Short A-MSDU uses only the Short A-MSDU subframe format.
9.3.2.2.2 Basic A-MSDU subframe format
The structure of a Basic A-MSDU subframe is shown in Figure 9-55.
In the Basic A-MSDU subframe, each A-MSDU subframe (except the last) is padded so that its length is a
multiple of 4 octets. The last A-MSDU subframe has no padding.
690
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Octets: 6 6 2 variable 0–3
DA SA Length MSDU Padding
A-MSDU subframe header
Figure 9-55—Basic A-MSDU subframe structure
The A-MSDU subframe header contains three fields: DA, SA, and Length. The order of these fields and the
bits within these fields are the same as the IEEE 802.3™ frame format. The DA and SA fields of the
A-MSDU subframe header contain the values passed in the MA-UNITDATA.request and MA-
UNITDATA.indication primitives. The Length field contains the length in octets of the MSDU.
An A-MSDU contains only MSDUs whose DA and SA parameter values map to the same receiver address
(RA) and transmitter address (TA) values. The rules for determining RA and TA are independent of whether
the frame body carries an A-MSDU.
NOTE—It is possible to have different DA and SA parameter values in A-MSDU subframe headers of the same
A-MSDU as long as they all map to the same Address 1 and Address 2 parameter values.
The MPDU containing the A-MSDU is carried in any of the following data frame subtypes: QoS Data,
QoS Data +CF-Ack, QoS Data +CF-Poll, QoS Data +CF-Ack +CF-Poll. The A-MSDU structure is
contained in the frame body of a single MPDU. If encrypted, the MPDU is encrypted as a single unit.
NOTE—The value of TID present in the QoS Control field of the MPDU carrying the A-MSDU indicates the TID for all
MSDUs in the A-MSDU. Because this value of TID is common to all MSDUs in the A-MSDU, only MSDUs delivered
to the MAC by an MA-UNITDATA.request primitive with an integer priority parameter that maps to the same TID can
be aggregated together using A-MSDU.
When mesh Data frames are aggregated, the A-MSDU subframe header includes Mesh DA, Mesh SA,
Length, and Mesh Control. The A-MSDU subframe structure for Mesh Data is defined in Figure 9-56.
Octets: 6 6 2 6 or 18 0–2304 0-3
Mesh DA Mesh SA Length Mesh Control MSDU Padding
A-MSDU subframe header
Figure 9-56—A-MSDU subframe structure for Mesh Data
The Mesh DA and Mesh SA fields contain the addresses of the destination mesh STA and the source mesh
STA, respectively, determined in 9.3.5.
The Length field contains the length in octets of the MSDU.
The format of the Mesh Control field is described in 9.2.4.7.3.
NOTE—It is possible to have different Mesh DA, Mesh SA, and Mesh Control in subframe headers of the same
A-MSDU as long as they all map to the same Address 1 and Address 2 values.
9.3.2.2.3 Short A-MSDU subframe format
The Short A-MSDU subframe is shown in Figure 9-57. In the Short A-MSDU subframe, each A-MSDU
subframe (except the last) is padded so that its length excluding the A-MSDU subframe header is a multiple
of 4 octets. The last A-MSDU subframe has no padding.
691
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Octets: 2 0–7920 0-3
Length MSDU Padding
A-MSDU subframe header
Figure 9-57—Short A-MSDU subframe structure
The Short A-MSDU subframe header consists of a Length field that contains the length in octets of the
MSDU.
NOTE—The Short A-MSDU subframe format is not transmitted by non-DMG STAs.
9.3.3 Management frames
9.3.3.1 Terminology of Management frames and MMPDUs
References in this standard to a “ frame”, where corresponds to one of the Management
frame subtypes, are to be understood as being to a “ MMPDU, where the MMPDU is carried in the
frame body of one or more Management frames with the Subtype field value corresponding to , plus
information from the MPDU headers (the Management frame subtype and the addresses)”.
9.3.3.2 Format of Management frames
The format of a Management frame is defined in Figure 9-58. The Frame Control, Duration, Address 1,
Address 2, Address 3, and Sequence Control fields are present in all management frame subtypes. In an
MMPDU carried in one or more non-VHT PPDUs, the maximum MMPDU size is specified in Table 9-19.
In an MMPDU carried in one or more PPDU(s), all of which are VHT PPDU(s), the maximum MMPDU
size specified in Table 9-19 is the maximum MPDU size supported by the recipient(s) less the shortest
management frame MAC header and FCS.
NOTE—In an MMPDU carried in one or more PPDUs, all of which are VHT PPDUs, the presence of encryption
overhead (i.e., the MMPDU is transmitted in robust Management frames) or an HT Control field might cause an
MMPDU to be fragmented that would not otherwise need to be fragmented.
Octets: 2 2 6 6 6 2 0 or 4 variable 4
Frame Duration Address 1 Address 2 Address 3 Sequence HT Frame FCS
Control Control Control Body
MAC header
Figure 9-58—Management frame format
A STA uses the contents of the Address 1 field to perform the address matching for receive decisions. In the
case where the Address 1 field contains a group address and the frame subtype is other than Beacon or the
frame subtype Action, Category Multihop Action (Multihop Action frame), the Address 3 field also is
validated to verify that the group addressed frame originated from a STA in the BSS of which the receiving
STA is a member or from a mesh STA to which mesh peering is maintained. Details of addressing and
forwarding of the group addressed frame in an MBSS are defined in 10.35.4. When the Address 1 field
contains a group address and the frame subtype is either Probe Request or Action with Category Public, a
wildcard BSSID value matches all receiving STA’s BSSIDs. If the frame subtype is Beacon, other address
matching rules apply, as specified in 11.1.3.7. Frames of subtype Probe Request with a group address in the
Address 1 field are additionally processed as described in 11.1.4.3.2 for non-DMG STAs and 11.1.4.3.3 for
692
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DMG STAs. If the frame subtype is Action, the Category is Public, and the Action is 20/40 BSS
Coexistence Management, then additional address matching rules for receive decisions apply as specified in
11.16 and 11.18.
The address fields for all Management frames except Multihop Action frames are as follows:
a) The Address 1 field of the Management frame is the RA (=DA) and is determined as the destination
of the frame.
b) The Address 2 field of the Management frame is the TA (=SA) and is determined as the address of
the STA transmitting the frame.
c) The Address 3 field of the Management frame is set and determined as follows:
1) In Probe Request frames, the Address 3 field is the BSSID. The BSSID is either a specific
BSSID as described in item 4) below or the wildcard BSSID as defined in the procedures
specified in 11.1.4.
2) In Public Action frames, the Address 3 field is the BSSID. The BSSID value is set according to
11.20.
3) If dot11OCBActivated is true, the Address 3 field is the wildcard BSSID.
4) Otherwise:
i) If the STA is contained within an AP or is associated with an AP, the Address 3 field is the
BSSID. The BSSID is the address currently in use by the STA contained in the AP.
ii) If the STA is contained within an AP or is transmitting the Management frame to an AP,
the Address 3 field is the BSSID. The BSSID is the address currently in use by the STA
contained in the AP.
iii) If the STA is transmitting the Management frame to one or more members of an IBSS, the
Address 3 field is the BSSID of the IBSS.
iv) If the STA is a mesh STA, the Address 3 field is the TA.
The address fields for Multihop action frames are described in 9.3.5.
Within a PBSS, the BSSID field of a Management frame is set to the MAC address in use by the STA
contained in the PCP of the PBSS.
Within all Management frames sent by STAs during the CFP under PCF, the Duration field is set to the
value 32 768. Within all Management frames sent by the QoS STA, the Duration field contains a duration
value as defined in 9.2.5. Within all Management frames sent during the CP by non-QoS STAs, the Duration
field is set according to the following rules:
— If the DA field contains a group address, the duration value is set to 0.
— If the More Fragments bit is 0 in the Frame Control field of a frame and the DA field contains an
individual address, the duration value is set to the time, in microseconds, required to transmit one
Ack frame, plus one SIFS.
— If the More Fragments bit is 1 in the Frame Control field of a frame, and the DA field contains an
individual address, the duration value is set to the time, in microseconds, required to transmit the
next fragment of this Management frame, plus two Ack frames, plus three SIFSs.
The duration value calculation for the Management frame is based on the rules in 10.7 that determine the
data rate at which the Control frames in the frame exchange sequence are transmitted. If the calculated
duration includes a fractional microsecond, that value is rounded up to the next higher integer. All STAs
process Duration field values less than or equal to 32 767 from valid Management frames to update their
NAV settings as appropriate under the coordination function rules.
693
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The HT Control field is defined in 9.2.4.6. The presence of the HT Control field is determined by the +HTC/
Order subfield of the Frame Control field, as specified in 9.2.4.1.10.
A Management frame is an IQMF when both
— The RA of the Management frame corresponds to an individual MAC address; and
— The To DS subfield is set to 1 and the From DS subfield of the Frame Control field is set to 0.
A Management frame is a GQMF when both
— The RA of the Management frame corresponds to a group MAC address; and
— The To DS subfield is set to 1 and the From DS subfield of the Frame Control field is set to 0.
The frame body consists of the fields followed by the elements defined for each management frame subtype.
All fields and elements are mandatory unless stated otherwise and appear in the specified, relative order.
STAs that encounter an element ID they do not recognize in the frame body of a received Management
frame ignore that element and continue to parse the remainder of the management frame body (if any) for
additional elements with recognizable element IDs. See 10.27.7. Unused element ID codes are reserved.
Gaps might exist in the ordering of fields and elements within frames. The order that remains is ascending.
9.3.3.3 Beacon frame format
The frame body of a Beacon frame contains the information shown in Table 9-27.
Table 9-27—Beacon frame body
Order Information Notes
1 Timestamp
2 Beacon interval
3 Capability
Information
4 Service Set If dot11MeshActivated is true, the SSID element is the wildcard
Identifier (SSID) value as described in 9.4.2.2.
5 Supported Rates and
BSS Membership
Selectors
6 DSSS Parameter Set The element is optionally present.
The DSSS Parameter Set element is present within Beacon frames
generated by STAs using Clause 15, Clause 16, and Clause 18
PHYs.
The element is present within Beacon frames generated by STAs
using a Clause 19 PHY in the 2.4 GHz band.
7 CF Parameter Set The CF Parameter Set element is present only within Beacon
frames generated by APs supporting a PCF.
This element is not present if dot11HighThroughputOption-
Implemented is true and the Dual CTS Protection field of the HT
Operation element is 1.
8 IBSS Parameter Set The IBSS Parameter Set element is present only within Beacon
frames generated by IBSS STAs.
9 Traffic indication The TIM element is present only within Beacon frames generated
map (TIM) by APs or mesh STAs.
694
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-27—Beacon frame body (continued)
Order Information Notes
10 Country The Country element is present if
dot11MultiDomainCapabilityActivated is true or
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
11 Power Constraint The Power Constraint element is present if
dot11SpectrumManagementRequired is true and is optionally
present if dot11RadioMeasurementActivated is true.
12 Channel Switch Channel Switch Announcement element is optionally present if
Announcement dot11SpectrumManagementRequired is true.
13 Quiet The Quiet element is optionally present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
14 IBSS DFS IBSS DFS element is present if
dot11SpectrumManagementRequired is true in an IBSS.
15 TPC Report The TPC Report element is present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
16 ERP The ERP element is present within Beacon frames generated by
STAs using extended rate PHYs (ERPs) defined in Clause 18 and
is optionally present in other cases.
17 Extended Supported The Extended Supported Rates and BSS Membership Selectors
Rates and BSS element is present if there are more than eight supported rates, and
Membership it is optional otherwise.
Selectors
18 RSN The RSNE is present within Beacon frames generated by STAs
that have dot11RSNAActivated equal to true.
19 BSS Load The BSS Load element is present if dot11QosOption-
Implemented and dot11QBSSLoadImplemented are both true.
20 EDCA Parameter The EDCA Parameter Set element is present if
Set dot11QosOptionImplemented is true, and dot11MeshActivated is
false, and the QoS Capability element is not present.
21 QoS Capability The QoS Capability element is present if dot11QosOption-
Implemented is true, and dot11MeshActivated is false, and EDCA
Parameter Set element is not present.
22 AP Channel Report If dot11RMAPChannelReportActivated is true, one AP Channel
Report element is present for each operating class that has at least
1 channel to report.
23 BSS Average Access The BSS Average Access Delay element is present if
Delay dot11RMBSSAverageAccessDelayActivated is true and the value
of the AP Average Access Delay field is not equal to 255
(measurement not available); otherwise, the BSS Average Access
Delay element is optionally present if
dot11RMBSSAverageAccessDelayActivated is true.
24 Antenna The Antenna element is present if
dot11RMAntennaInformationActivated is true and the value of
the Antenna ID field is not equal to 0 (unknown antenna);
otherwise, the Antenna element is optionally present if
dot11RMAntennaInformationActivated is true.
695
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-27—Beacon frame body (continued)
Order Information Notes
25 BSS Available The BSS Available Admission Capacity element is present if
Admission Capacity dot11RMBSSAvailableAdmissionCapacityActivated is true with
the following exceptions: 1) when Available Admission Capacity
Bitmask equals 0 (Available Admission Capacity List contains no
entries), or 2) when the BSS Load element is present and the
Available Admission Capacity Bitmask states that only AC_VO is
present in the Available Admission Capacity List field.
26 BSS AC Access The BSS AC Access Delay element is present if
Delay dot11RMBSSAverageAccessDelayActivated is true and at least
one field of the element is not equal to 255 (measurement not
available); otherwise, the BSS AC Access Delay element is
optionally present if dot11RMBSSAverageAccessDelayActivated
is true.
27 Measurement Pilot The Measurement Pilot Transmission element is present if
Transmission dot11RMMeasurementPilotActivated is a value between 2 and 7.
28 Multiple BSSID One or more Multiple BSSID elements are present if
dot11RMMeasurementPilotActivated is a value between 2 and 7
and the AP is a member of a multiple BSSID set (see 11.11.14)
with two or more members, or if dot11MultiBSSIDActivated is
true,
or if dot11InterworkingServiceActivated is true and the AP is a
member of a multiple BSSID set with two or more members and
at least one dot11GASAdvertisementID exists.
29 RM Enabled RM Enabled Capabilities element is present if
Capabilities dot11RadioMeasurementActivated is true.
30 Mobility Domain The Mobility Domain element (MDE) is present if
dot11FastBSSTransitionActivated is true.
31 DSE registered The DSE Registered Location element is present if
location dot11LCIDSERequired is true.
32 Extended Channel The Extended Channel Switch Announcement element is
Switch optionally present if dot11ExtendedChannelSwitchActivated is
Announcement true.
33 Supported Operating The Supported Operating Classes element is present if
Classes dot11ExtendedChannelSwitchActivated is true.
The Supported Operating Classes element is optionally present if
dot11TVHTOptionImplemented is true.
34 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
35 HT Operation The HT Operation element is included by an AP and a mesh STA
when dot11HighThroughputOptionImplemented is true.
36 20/40 BSS The 20/40 BSS Coexistence element is optionally present when
Coexistence the dot112040BSSCoexistenceManagementSupport is true.
37 Overlapping BSS The Overlapping BSS Scan Parameters element is optionally
Scan Parameters present if dot11FortyMHzOptionImplemented is true.
38 Extended The Extended Capabilities element is present if any of the fields in
Capabilities this element are nonzero.
39 FMS Descriptor The FMS Descriptor element is present if dot11FMSActivated is
true.
40 QoS Traffic The QoS Traffic Capability element is optionally present if
Capability dot11ACStationCountActivated is true.
696
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-27—Beacon frame body (continued)
Order Information Notes
41 Time Advertisement The Time Advertisement element is present every
dot11TimeAdvertisementDTIMInterval if
dot11UTCTSFOffsetActivated is true.
42 Interworking The Interworking element is present if
dot11InterworkingServiceActivated is true.
43 Advertisement Advertisement Protocol element is present if
Protocol dot11InterworkingServiceActivated is true and at least one
dot11GASAdvertisementID MIB attribute exists.
44 Roaming The Roaming Consortium element is present if
Consortium dot11InterworkingServiceActivated is true and the
dot11RoamingConsortiumTable has at least one entry.
45 Emergency Alert One or more Emergency Alert Identifier elements are present if
Identifier dot11EASActivated is true and there are one or more EAS
message(s) active in the network.
46 Mesh ID The Mesh ID element is present if dot11MeshActivated is true.
47 Mesh Configuration The Mesh Configuration element is present if
dot11MeshActivated is true.
48 Mesh Awake The Mesh Awake Window element is optionally present if
Window dot11MeshActivated is true.
49 Beacon Timing The Beacon Timing element is optionally present if both
dot11MeshActivated and dot11MBCAActivated are true.
50 MCCAOP The MCCAOP Advertisement Overview element is optionally
Advertisement present if both dot11MeshActivated and dot11MCCAActivated
Overview are true.
51 MCCAOP One or more MCCAOP Advertisement elements are optionally
Advertisement present if both dot11MeshActivated and dot11MCCAActivated
are true.
52 Mesh Channel The Mesh Channel Switch Parameters element is present when
Switch Parameters dot11MeshActivated is true and either Channel Switch
Announcement element or Extended Channel Switch
Announcement element is present.
53 QMF Policy Indicates the QMF policy parameters of the transmitting STA. The
QMF Policy element is present when dot11QMFActivated is true
and the transmitting STA is an AP or a mesh STA. This element is
not present otherwise.
54 QLoad Report The QLoad Report element is present every
dot11QLoadReportIntervalDTIM DTIMs if
dot11QLoadReportActivated is true.
55 HCCA TXOP The HCCA TXOP Update Count element is present if both
Update Count dot11PublicHCCATXOPNegotiationActivated is true and an HC
is collocated with the AP.
56 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
57 VHT Capabilities The VHT Capabilities element is present when the
dot11VHTOptionImplemented is true.
58 VHT Operation The VHT Operation element is present when the
dot11VHTOptionImplemented is true; otherwise, it is not present.
697
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-27—Beacon frame body (continued)
Order Information Notes
59 Transmit Power One Transmit Power Envelope element is present for each distinct
Envelope element value of the Local Maximum Transmit Power Unit Interpretation
subfield that is supported for the BSS if both of the following
conditions are met:
— dot11VHTOptionImplemented or
dot11ExtendedSpectrumManagementImplemented is true;
— Either dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
Otherwise, this parameter is not present.
60 Channel Switch The Channel Switch Wrapper element is optionally present if
Wrapper element dot11VHTOptionImplemented or
dot11ExtendedSpectrumManagementImplemented is true and at
least one of a Channel Switch Announcement element or an
Extended Channel Switch Announcement element is also present
in the Beacon frame and the Channel Switch Wrapper element
contains at least one subelement.
61 Extended BSS Load The Extended BSS Load element is optionally present if
element dot11QosOptionImplemented, dot11QBSSLoadImplemented, and
dot11VHTOptionImplemented are true.
62 Quiet Channel Either one Quiet Channel element containing an AP Quiet Mode
field equal to 0 or, in an infrastructure BSS, one or more Quiet
Channel elements each containing an AP Quiet Mode field equal
to 1 are optionally present if dot11VHTOptionImplemented is
true, and either dot11SpectrumManagementRequired or
dot11RadioMeasurementActivated is true.
63 Operating Mode The Operating Mode Notification element is optionally present if
Notification dot11OperatingModeNotificationImplemented is true.
64 Reduced Neighbor The Reduced Neighbor Report element is optionally present if
Report dot11TVHTOptionImplemented is true.
65 TVHT Operation The TVHT Operation element is present for a TVHT STA when
the dot11TVHTOptionImplemented is true; otherwise it is not
present.
66 Estimated Service The Estimated Service Parameters element is present if
Parameters dot11EstimatedServiceParametersOptionImplemented is true.
67 Future Channel The Future Channel Guidance element is optionally present if
Guidance dot11FutureChannelGuidanceActivated is true.
Last Vendor Specific One or more vendor-specific elements are optionally present.
These elements follow all other elements.
9.3.3.4 ATIM frame format
The frame body of an ATIM frame is null.
9.3.3.5 Disassociation frame format
The frame body of a Disassociation frame contains the information shown in Table 9-28.
698
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-28—Disassociation frame body
Order Information
1 Reason code
Last – 1 One or more vendor-specific elements are optionally present.
Last The Management MIC element (MME) is present when management frame
protection is enabled at the AP and the frame is a group addressed frame.
NOTE—The MME appears after all fields that it protects. Therefore, it appears last in the frame
body to protect the frames as specified in 12.5.4.
9.3.3.6 Association Request frame format
The frame body of an Association Request frame contains the information shown in Table 9-29.
Table 9-29—Association Request frame body
Order Information Notes
1 Capability Information
2 Listen Interval
3 SSID
4 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true.
Membership Selectors
5 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors
and BSS Membership element is present if there are more than eight supported rates, and
Selectors it is optional otherwise. This element is not present if
dot11DMGOptionImplemented is true.
6 Power Capability The Power Capability element is present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
7 Supported Channels The Supported Channels element is present if
dot11SpectrumManagementRequired is true and
dot11ExtendedChannelSwitchActivated is false.
8 RSN The RSNE is present if dot11RSNAActivated is true.
9 QoS Capability The QoS Capability element is present if
dot11QosOptionImplemented is true.
10 RM Enabled Capabilities RM Enabled Capabilities element is present if
dot11RadioMeasurementActivated is true.
11 Mobility Domain The Mobility Domain element (MDE) is present in an Association
Request frame if dot11FastBSSTransitionActivated is true and if
the frame is being sent to an AP that advertised its FT capability in
the MDE in its Beacon or Probe Response frame (i.e., AP also has
dot11FastBSSTransitionActivated equal to true).
12 Supported Operating Classes The Supported Operating Classes element is present if
dot11ExtendedChannelSwitchActivated is true.
13 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
699
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-29—Association Request frame body (continued)
Order Information Notes
14 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when
dot112040BSSCoexistenceManagementSupport is true.
15 Extended Capabilities The Extended Capabilities element is present if any of the fields in
this element are nonzero.
16 QoS Traffic Capability The QoS Traffic Capability element is present if
dot11QoSTrafficCapabilityActivated is true.
17 TIM Broadcast Request The TIM Broadcast Request element is present if
dot11TIMBroadcastActivated is true.
18 Interworking The Interworking element is present if
dot11InterworkingServiceActivated is true and the non-AP STA is
requesting unauthenticated access to emergency services (see
11.3.5).
19 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
20 DMG Capabilities The DMG Capabilities element is present if
dot11DMGOptionImplemented is true.
21 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if
dot11MultipleMACActivated is true.
22 VHT Capabilities The VHT Capabilities element is present when the
dot11VHTOptionImplemented is true.
23 Operating Mode Notification The Operating Mode Notification element is optionally present if
dot11OperatingModeNotificationImplemented is true.
Last Vendor Specific One or more vendor-specific elements are optionally present.
These elements follow all other elements.
9.3.3.7 Association Response frame format
The frame body of an Association Response frame contains the information shown in Table 9-30.
Table 9-30—Association Response frame body
Order Information Notes
1 Capability Information
2 Status code
3 AID
4 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true.
Membership Selectors
5 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors
and BSS Membership element is present if there are more than eight supported rates and
Selectors is optionally present otherwise. This element is not present if
dot11DMGOptionImplemented is true.
6 EDCA Parameter Set The EDCA Parameter Set Element is present if
dot11QosOptionImplemented is true; otherwise not present.
700
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-30—Association Response frame body (continued)
Order Information Notes
7 RCPI The RCPI element is present if
dot11RMRCPIMeasurementActivated is true.
8 RSNI The RSNI element is present if
dot11RMRSNIMeasurementActivated is true.
9 RM Enabled Capabilities RM Enabled Capabilities element is present if
dot11RadioMeasurementActivated is true.
10 Mobility Domain An MDE is present in an Association Response frame when
dot11FastBSSTransitionActivated is true and this frame is a
response to an Association Request frame that contained an MDE
(i.e., an FT initial mobility domain association exchange).
11 Fast BSS Transition A Fast BSS Transition element (FTE) is present in an Association
Response frame when dot11FastBSSTransitionActivated is true,
dot11RSNAActivated is true, and this frame is a response to an
Association Request frame that contained an MDE (i.e., an FT
initial mobility domain association exchange in an RSN).
12 DSE registered location The DSE Registered Location element is present if
dot11LCIDSERequired is true.
13 Timeout Interval (Association A Timeout Interval element (TIE) containing the Association
Comeback time) Comeback time is present when dot11RSNAActivated is true,
dot11RSNAProtectedManagementFramesActivated is true, and
the association request is rejected with a status code
REFUSED_TEMPORARILY.
14 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
15 HT Operation The HT Operation element is included by an AP when
dot11HighThroughputOptionImplemented is true.
16 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when
the dot112040BSSCoexistenceManagementSupport is true.
17 Overlapping BSS Scan The Overlapping BSS Scan Parameters element is optionally
Parameters present if dot11FortyMHzOptionImplemented is true.
18 Extended Capabilities The Extended Capabilities element is present if any of the fields in
this element are nonzero.
19 BSS Max Idle Period The BSS Max Idle Period element is present if
dot11WirelessManagementImplemented is true.
20 TIM Broadcast Response The TIM Broadcast Response element is present if
dot11TIMBroadcastActivated is true and the TIM Broadcast
Request element is present in the Association Request frame that
elicited this Association Response frame.
21 QoS Map The QoS Map element is present if dot11QosMapActivated is true
and the QoS Map field in the Extended Capabilities element of the
corresponding Association Request frame is 1.
22 QMF Policy The QMF Policy element is present if dot11QMFActivated is true
and the QMFActivated subfield is 1 in the Extended Capabilities
element in the Association Request frame that elicited this
Association Response frame.
23 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
701
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-30—Association Response frame body (continued)
Order Information Notes
24 DMG Capabilities The DMG Capabilities element is present if
dot11DMGOptionImplemented is true.
25 DMG Operation The DMG Operation element is present if
dot11DMGOptionImplemented is true.
26 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if
dot11MultipleMACActivated is true.
27 Neighbor Report One or more Neighbor Report elements is present if the Reason
Code is
REJECTED_WITH_SUGGESTED_BSS_TRANSITION.
27 VHT Capabilities The VHT Capabilities element is present when the
dot11VHTOptionImplemented is true.
28 VHT Operation The VHT Operation element is present when the
dot11VHTOptionImplemented is true; otherwise, it is not present.
29 Operating Mode Notification The Operating Mode Notification element is optionally present if
dot11OperatingModeNotificationImplemented is true.
30 Future Channel Guidance The Future Channel Guidance element is optionally present if
dot11FutureChannelGuidanceActivated is true.
Last Vendor Specific One or more vendor-specific elements are optionally present.
These elements follow all other elements.
9.3.3.8 Reassociation Request frame format
The frame body of a Reassociation Request frame contains the information shown in Table 9-31.
Table 9-31—Reassociation Request frame body
Order Information Notes
1 Capability Information
2 Listen Interval
3 Current AP address
4 SSID
5 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true.
Membership Selectors
6 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors
and BSS Membership element is present if there are more than eight supported rates, and
Selectors it is optional otherwise. This element is not present if
dot11DMGOptionImplemented is true.
7 Power Capability The Power Capability element is present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
8 Supported Channels The Supported Channels element is present if
dot11SpectrumManagementRequired is true and
dot11ExtendedChannelSwitchActivated is false.
702
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-31—Reassociation Request frame body (continued)
Order Information Notes
9 RSN The RSNE is present if dot11RSNAActivated is true; otherwise
not present.
10 QoS Capability The QoS Capability element is present if
dot11QosOptionImplemented is true.
11 RM Enabled Capabilities RM Enabled Capabilities element is present if
dot11RadioMeasurementActivated is true.
12 Mobility Domain The MDE is present in a Reassociation Request frame if
dot11FastBSSTransitionActivated is true and the frame is being
sent to an AP that advertised its FT Capability in the MDE in its
Beacon or Probe Response frame (i.e., AP also has
dot11FastBSSTransitionActivated is true).
13 Fast BSS Transition An FTE is present in a Reassociation Request frame if
dot11FastBSSTransitionActivated is true and
dot11RSNAAuthenticationSuiteSelected is 00-0F-AC:3, 00-0F-
AC:4, or 00-0F-AC:9 (i.e., part of a fast BSS transition in an
RSN).
14 Resource information The set of elements that formulate a RIC-Request is optionally
container (RIC) present in a Reassociation Request frame if
— dot11FastBSSTransitionActivated is true,
— The FT resource request protocol is not used,
— The frame is being sent to an AP that advertised its FT
capability in the MDE in its Beacon or Probe Response frame
(i.e., AP also has dot11FastBSSTransitionActivated is true),
and
— Either dot11RSNAAuthenticationSuiteSelected is 00-0F-
AC:3, 00-0F-AC:4, or 00-0F-AC:9 (i.e., part of a fast BSS
transition in an RSN) or dot11RSNAActivated is false (i.e.,
not in an RSN).
15 Supported Operating Classes The Supported Operating Classes element is present if
dot11ExtendedChannelSwitchActivated is true.
16 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
17 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when
dot112040BSSCoexistenceManagementSupport is true.
18 Extended Capabilities The Extended Capabilities element is present if any of the fields in
this element are nonzero.
19 QoS Traffic Capability The QoS Traffic Capability element is present if
dot11QoSTrafficCapabilityActivated is true.
20 TIM Broadcast Request The TIM Broadcast Request element is present if
dot11TIMBroadcastActivated is true.
21 FMS Request The FMS Request element is optionally present if
dot11FMSActivated is true.
22 DMS Request The DMS Request element is optionally present if
dot11DMSActivated is true.
23 Interworking The Interworking element is present if
dot11InterworkingServiceActivated is true and the non-AP STA is
requesting unauthenticated access to emergency services (see
11.3.5).
703
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-31—Reassociation Request frame body (continued)
Order Information Notes
24 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
25 DMG Capabilities The DMG Capabilities element is present if
dot11DMGOptionImplemented is true.
26 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if
dot11MultipleMACActivated is true.
27 VHT Capabilities The VHT Capabilities element is present when the
dot11VHTOptionImplemented is true.
28 Operating Mode Notification The Operating Mode Notification element is optionally present if
dot11OperatingModeNotificationImplemented is true.
Last Vendor Specific One or more vendor-specific elements are optionally present.
These elements follow all other elements.
9.3.3.9 Reassociation Response frame format
The frame body of a Reassociation Response frame contains the information shown in Table 9-32.
Table 9-32—Reassociation Response frame body
Order Information Notes
1 Capability Information
2 Status code
3 AID
4 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true.
Membership Selectors
5 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors
and BSS Membership element is present if there are more than eight supported rates, and
Selectors it is optional otherwise. This element is not present if
dot11DMGOptionImplemented is true.
6 EDCA Parameter Set The EDCA Parameter Set Element is present if
dot11QosOptionImplemented is true; otherwise not present.
7 RCPI The RCPI element is present if
dot11RMRCPIMeasurementActivated is true.
8 RSNI The RSNI element is present if
dot11RMRSNIMeasurementActivated is true.
9 RM Enabled Capabilities RM Enabled Capabilities element is present if
dot11RadioMeasurementActivated is true.
10 RSN An RSNE is present in a Reassociation Response frame if
dot11FastBSSTransitionActivated is true, dot11RSNAActivated
is true, and this frame is a response to a Reassociation Request
frame that contained an FTE (i.e., part of a fast BSS transition in
an RSN).
704
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-32—Reassociation Response frame body (continued)
Order Information Notes
11 Mobility Domain An MDE is present in a Reassociation Response frame if
dot11FastBSSTransitionActivated is true and this frame is a
response to a Reassociation Request frame that contained an MDE
(i.e., either an FT initial mobility domain association exchange or
part of a fast BSS transition).
12 Fast BSS Transition An FTE is present in a Reassociation Response frame if
dot11FastBSSTransitionActivated is true, dot11RSNAActivated
is true, and this frame is a response to a Reassociation Request
frame that contained an MDE (i.e., either an FT initial mobility
domain association exchange or part of a fast BSS transition in an
RSN).
13 RIC The set of elements that formulate a RIC-Response is present in a
Reassociation Response frame if
dot11FastBSSTransitionActivated is true and this frame is a
response to a Reassociation Request frame that contained a RIC-
Request.
14 DSE registered location The DSE Registered Location element is present if
dot11LCIDSERequired is true.
15 Timeout Interval (Association A TIE containing the Association Comeback time is present when
Comeback time) dot11RSNAActivated is true,
dot11RSNAProtectedManagementFramesActivated is true, and
the reassociation is rejected with status code
REFUSED_TEMPORARILY.
16 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
17 HT Operation The HT Operation element is included by an AP when
dot11HighThroughputOptionImplemented is true.
18 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when
dot112040BSSCoexistenceManagementSupport is true.
19 Overlapping BSS Scan The Overlapping BSS Scan Parameters element is optionally
Parameters present if dot11FortyMHzOptionImplemented is true.
20 Extended Capabilities The Extended Capabilities element is present if any of the fields in
this element are nonzero.
21 BSS Max Idle Period The BSS Max Idle Period element is present if
dot11WirelessManagementImplemented is true.
22 TIM Broadcast Response The TIM Broadcast Response element is present if
dot11TIMBroadcastActivated is true and the TIM Broadcast
Request element is present in the Reassociation Request frame
that elicited this Reassociation Response frame.
23 FMS Response The FMS Response element is present if dot11FMSActivated is
true and the FMS Request element is present in the Reassociation
Request frame that elicited this Reassociation Response frame.
24 DMS Response The DMS Response element is present if dot11DMSActivated is
true and the DMS Request element is present in the Reassociation
Request frame that elicited this Reassociation Response frame.
25 QoS Map The QoS Map element is present if dot11QosMapActivated is true
and the QoS Map field in the Extended Capabilities element of the
corresponding Reassociation Request frame is 1.
705
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-32—Reassociation Response frame body (continued)
Order Information Notes
26 QMF Policy The QMF Policy element is present if dot11QMFActivated is true
and the QMFActivated subfield is 1 in the Extended Capabilities
element in the Reassociation Request that elicited this
Reassociation Response frame.
27 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
28 DMG Capabilities The DMG Capabilities element is present if
dot11DMGOptionImplemented is true.
29 DMG Operation The DMG Operation element is present if
dot11DMGOptionImplemented is true.
30 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if
dot11MultipleMACActivated is true.
31 Neighbor Report One or more Neighbor Report elements is present if the Reason
Code is
REJECTED_WITH_SUGGESTED_BSS_TRANSITION.
31 VHT Capabilities The VHT Capabilities element is present when the
dot11VHTOptionImplemented is true.
32 VHT Operation The VHT Operation element is present when the
dot11VHTOptionImplemented is true; otherwise, it is not present.
33 Operating Mode Notification The Operating Mode Notification element is optionally present if
dot11OperatingModeNotificationImplemented is true.
34 Future Channel Guidance The Future Channel Guidance element is optionally present if
dot11FutureChannelGuidanceActivated is true.
Last Vendor Specific One or more vendor-specific elements are optionally present.
These elements follow all other elements.
9.3.3.10 Probe Request frame format
The frame body of a Probe Request frame contains the information shown in Table 9-33.
Table 9-33—Probe Request frame body
Order Information Notes
1 SSID If dot11MeshActivated is true, the SSID element is the wildcard
value as described in 9.4.2.2.
2 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true.
Membership Selectors
3 Request The Request element is optionally present if
dot11RadioMeasurementActivated is true.
The Request element is optionally present if
dot11MultiDomainCapabilityActivated is true or if
dot11EstimatedServiceParametersOptionImplemented is true.
706
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-33—Probe Request frame body (continued)
Order Information Notes
4 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors
and BSS Membership element is present if there are more than eight supported rates and
Selectors is optionally present otherwise. This element is not present if
dot11DMGOptionImplemented is true.
5 DSSS Parameter Set The element is optionally present.
The DSSS Parameter Set element is present within Probe Request
frames generated by STAs using Clause 15, Clause 16, or
Clause 18 PHYs if dot11RadioMeasurementActivated is true.
The DSSS Parameter Set element is present within Probe Request
frames generated by STAs using a Clause 19 PHY in the 2.4 GHz
band if dot11RadioMeasurementActivated is true.
The DSSS Parameter Set element is optionally present within
Probe Request frames generated by STAs using Clause 15,
Clause 16, or Clause 18 PHYs if
dot11RadioMeasurementActivated is false.
The DSSS Parameter Set element is optionally present within
Probe Request frames generated by STAs using a Clause 19 PHY
in the 2.4 GHz band if dot11RadioMeasurementActivated is false.
6 Supported Operating Classes The Supported Operating Classes element is present if
dot11ExtendedChannelSwitchActivated is true.
The Supported Operating Classes element is optionally present if
dot11TVHTOptionImplemented is true.
7 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
8 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when
dot112040BSSCoexistenceManagementSupport is true.
9 Extended Capabilities The Extended Capabilities element is present if any of the fields in
this element are nonzero.
10 SSID List The SSID List element is optionally present if
dot11SSIDListActivated is true.
11 Channel Usage The Channel Usage element is optionally present if
dot11ChannelUsageActivated is true.
12 Interworking The Interworking element is present if
dot11InterworkingServiceActivated is true.
13 Mesh ID The Mesh ID element is present if dot11MeshActivated is true.
14 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
15 DMG Capabilities The DMG Capabilities element is present if
dot11DMGOptionImplemented is true.
16 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if
dot11MultipleMACActivated is true.
17 VHT Capabilities The VHT Capabilities element is present when the
dot11VHTOptionImplemented is true.
18 Estimated Service Parameters The Estimated Service Parameters element is optionally present if
dot11EstimatedServiceParametersOptionImplemented is true.
707
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-33—Probe Request frame body (continued)
Order Information Notes
19 Extended Request The Extended Request element is optionally present if
dot11RadioMeasurementActivated is true.
Last Vendor Specific One or more vendor-specific elements are optionally present.
These elements follow all other elements.
9.3.3.11 Probe Response frame format
The frame body of a Probe Response frame contains the information shown in Table 9-34. See additional
details and procedures in 11.1.4.
Table 9-34—Probe Response frame body
Order Information Notes
1 Timestamp
2 Beacon interval
3 Capability Information
4 SSID If dot11MeshActivated is true, the SSID element is the wildcard
value as described in 9.4.2.2.
5 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true.
Membership Selectors
6 DSSS Parameter Set The element is optionally present.
The DSSS Parameter Set element is present within Probe Response
frames generated by STAs using Clause 15, Clause 16, and
Clause 18 PHYs.
The DSSS Parameter Set element is present within Probe Response
frames generated by STAs using a Clause 19 PHY in the 2.4 GHz
band.
7 CF Parameter Set The CF Parameter Set element is present only within Probe
Response frames generated by APs supporting a PCF.
8 IBSS Parameter Set The IBSS Parameter Set element is present only within Probe
Response frames generated by IBSS STAs.
9 Country The Country element is
present if dot11MultiDomainCapabilityActivated is true or
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
10 Power Constraint The Power Constraint element is present if
dot11SpectrumManagementRequired is true and is optionally
present if dot11RadioMeasurementActivated is true.
11 Channel Switch The Channel Switch Announcement element is optionally present if
Announcement dot11SpectrumManagementRequired is true.
12 Quiet The Quiet element is optionally present if
dot11SpectrumManagementRequired is true or if
dot11RadioMeasurementActivated is true.
13 IBSS DFS The IBSS DFS element is present if
dot11SpectrumManagementRequired is true in an IBSS.
708
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-34—Probe Response frame body (continued)
Order Information Notes
14 TPC Report The TPC Report element is present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
15 ERP The ERP element is present within Probe Response frames
generated by STAs using ERPs and is optionally present otherwise.
16 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors
and BSS Membership element is present if there are more than eight supported rates, and
Selectors it is optionally present otherwise. This element is not present if
dot11DMGOptionImplemented is true.
17 RSN The RSNE is present if dot11RSNAActivated is true; otherwise not
present.
18 BSS Load The BSS Load element is present if dot11QosOption-Implemented
and dot11QBSSLoadImplemented are both true.
19 EDCA Parameter Set The EDCA Parameter Set element is present if
dot11QosOptionImplemented is true and dot11MeshActivated is
false.
20 Measurement Pilot The Measurement Pilot Transmission element is present if
Transmission dot11RMMeasurementPilotActivated is between 2 and 7.
21 Multiple BSSID One or more Multiple BSSID elements are present if
dot11RMMeasurementPilotActivated is between 2 and 7 and the
AP is a member of a multiple BSSID set (see 11.11.14) with two or
more members, or if dot11MultiBSSIDActivated is true, or if
dot11InterworkingServiceActivated is true and the AP is a member
of a multiple BSSID set with two or more members and at least one
dot11GASAdvertisementID MIB attribute exists.
22 RM Enabled Capabilities The RM Enabled Capabilities element is present if
dot11RadioMeasurementActivated is true.
23 AP Channel Report If dot11RMAPChannelReportActivated is true, one AP Channel
Report element is optionally present for each operating class that
has at least 1 channel to report.
24 BSS Average Access Delay The BSS Average Access Delay element is optionally present if
dot11RMBSSAverageAccessDelayActivated is true and the value
of the AP Average Access Delay field is not equal to 255
(measurement not available).
25 Antenna The Antenna element is optionally present if
dot11RMAntennaInformationActivated is true and the value of the
Antenna ID field is not equal to 0 (unknown antenna).
26 BSS Available Admission The BSS Available Admission Capacity element is optionally
Capacity present if dot11RMBSSAvailableAdmissionCapacityActivated is
true with the following exceptions: 1) when Available Admission
Capacity Bitmask equals 0 (Available Admission Capacity List
contains no entries), or 2) when the BSS Load element is present
and the Available Capacity Bitmask equals 256 (Available
Admission Capacity List contains only the AC_VO entry).
27 BSS AC Access Delay The BSS AC Access Delay element is optionally present if
dot11RMBSSAverageAccessDelayActivated is true and at least one
field of the element is not equal to 255 (measurement not
available).
28 Mobility Domain The MDE is present if dot11FastBSSTransitionActivated is true.
709
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-34—Probe Response frame body (continued)
Order Information Notes
29 DSE registered location The DSE Registered Location element is present if
dot11LCIDSERequired is true.
30 Extended Channel Switch The Extended Channel Switch Announcement element is optionally
Announcement present if dot11ExtendedChannelSwitchActivated is true.
31 Supported Operating Classes The Supported Operating Classes element is present if
dot11ExtendedChannelSwitchActivated is true.
The Supported Operating Classes element is optionally present if
dot11TVHTOptionImplemented is true.
32 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
33 HT Operation The HT Operation element is included by an AP and a mesh STA
when dot11HighThroughputOptionImplemented is true.
34 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when
dot112040BSSCoexistenceManagementSupport is true.
35 Overlapping BSS Scan The Overlapping BSS Scan Parameters element is optionally
Parameters present if dot11FortyMHzOptionImplemented is true.
36 Extended Capabilities The Extended Capabilities element is present if any of the fields in
this element are nonzero.
37 QoS Traffic Capability The QoS Traffic Capability element is optionally present if
dot11ACStationCountActivated is true.
38 Channel Usage The Channel Usage element is present if the Channel Usage
element is present in the Probe Request frame and
dot11ChannelUsageActivated is true.
39 Time Advertisement The Time Advertisement element is present if
dot11UTCTSFOffsetActivated is true.
40 Time Zone The Time Zone element is present if dot11UTCTSFOffsetActivated
is true.
41 Interworking The Interworking element is present if
dot11InterworkingServiceActivated is true.
42 Advertisement Protocol Advertisement Protocol element is present if
dot11InterworkingServiceActivated is true and at least one
dot11GASAdvertisementID exists.
43 Roaming Consortium The Roaming Consortium element is present if
dot11InterworkingServiceActivated is true and the
dot11RoamingConsortiumTable has at least one entry.
44 Emergency Alert Identifier One or more Emergency Alert Identifier elements are present if
dot11EASActivated is true and there are one or more EAS
message(s) active in the network.
45 Mesh ID The Mesh ID element is present if dot11MeshActivated is true.
46 Mesh Configuration The Mesh Configuration element is present if dot11MeshActivated
is true.
47 Mesh Awake Window The Mesh Awake Window element is optionally present if
dot11MeshActivated is true.
48 Beacon Timing The Beacon Timing element is optionally present if both
dot11MeshActivated and dot11MBCAActivated are true.
710
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-34—Probe Response frame body (continued)
Order Information Notes
49 MCCAOP Advertisement The MCCAOP Advertisement Overview element is optionally
Overview present if both dot11MeshActivated and dot11MCCAActivated are
true.
50 MCCAOP Advertisement One or more MCCAOP Advertisement elements are optionally
present if both dot11MeshActivated and dot11MCCAActivated are
true.
51 Mesh Channel Switch The Mesh Channel Switch Parameters element is present if
Parameters dot11MeshActivated is true and either Channel Switch
Announcement element or Extended Channel Switch
Announcement element is present.
52 QMF Policy The QMF Policy element is present if dot11QMFActivated is true
and the QMFActivated subfield is 1 in the Extended Capabilities
element in the Probe Request that elicited this Probe Response
frame.
53 QLoad Report The QLoad Report element is present if
dot11QLoadReportActivated is true.
54 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
55 DMG Capabilities The DMG Capabilities element is present if
dot11DMGOptionImplemented is true.
56 DMG Operation The DMG Operation element is present if
dot11DMGOptionImplemented is true.
57 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if
dot11MultipleMACActivated is true.
58 Antenna Sector ID Pattern The Antenna Sector ID Pattern element is optionally present if
dot11DMGOptionImplemented is true.
59 VHT Capabilities The VHT Capabilities element is present when the
dot11VHTOptionImplemented is true.
60 VHT Operation The VHT Operation element is present when the
dot11VHTOptionImplemented is true; otherwise, it is not present.
61 Transmit Power Envelope One Transmit Power Envelope element is present for each distinct
element value of the Local Maximum Transmit Power Unit Interpretation
subfield that is supported for the BSS if both of the following
conditions are met:
— dot11VHTOptionImplemented or
dot11ExtendedSpectrumManagementImplemented is true;
— Either dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
Otherwise, this parameter is not present.
62 Channel Switch Wrapper The Channel Switch Wrapper element is optionally present if
element dot11VHTOptionImplemented or
dot11ExtendedSpectrumManagementImplemented is true and at
least one of a Channel Switch Announcement element or an
Extended Channel Switch Announcement element is also present in
the Probe Response frame and the Channel Switch Wrapper
element contains at least one subelement.
63 Extended BSS Load element The Extended BSS Load element is optionally present if
dot11QosOptionImplemented, dot11QBSSLoadImplemented and
dot11VHTOptionImplemented are true.
711
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-34—Probe Response frame body (continued)
Order Information Notes
64 Quiet Channel Either one Quiet Channel element containing an AP Quiet Mode
field equal to 0 or, in an infrastructure BSS, one or more Quiet
Channel elements each containing an AP Quiet Mode field equal to
1 are optionally present if dot11VHTOptionImplemented is true,
and either dot11SpectrumManagementRequired or
dot11RadioMeasurementActivated is true.
65 Operating Mode Notification The Operating Mode Notification element is optionally present if
dot11OperatingModeNotificationImplemented is true.
66 Reduced Neighbor Report The Reduced Neighbor Report element is optionally present if
dot11TVHTOptionImplemented is true.
67 TVHT Operation The TVHT Operation element is present for a TVHT STA when the
dot11TVHTOptionImplemented is true; otherwise it is not present.
68 Estimated Service Parameters The Estimated Service Parameters element is optionally present if
dot11EstimatedServiceParametersOptionImplemented is true.
69 Relay Capabilities The Relay Capabilities element is present if dot11RelayActivated is
true; otherwise not present.
Last–1 Vendor Specific One or more vendor-specific elements are optionally present. These
elements follow all other elements, except the Requested elements.
Last Requested elements Elements requested by the Request element or Extended Request
element(s) of the Probe Request frame are present if
dot11MultiDomainCapabilityActivated or
dot11EstimatedServiceParametersOptionImplemented is true. See
11.1.4.3.2 and 11.46.
9.3.3.12 Authentication frame format
The frame body of an Authentication frame contains the information shown in Table 9-35. FT authentication
is used when FT support is advertised by the AP and dot11FastBSSTransitionActivated is true in the STA.
SAE authentication is used when dot11MeshActiveAuthenticationProtocol is sae (1).
Table 9-35—Authentication frame body
Order Information Notes
1 Authentication algorithm
number
2 Authentication transaction
sequence number
3 Status code The status code information is reserved in certain Authentication
frames as defined in Table 9-36.
4 Challenge text A Challenge Text element is present only in certain
Authentication frames as defined in Table 9-36.
5 RSN An RSNE is present only in certain Authentication frames as
defined in Table 9-36.
6 Mobility Domain An MDE is present only in certain Authentication frames as
defined in Table 9-36.
712
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-35—Authentication frame body (continued)
Order Information Notes
7 Fast BSS Transition An FTE is present only in certain Authentication frames as
defined in Table 9-36.
8 Timeout Interval A TIE containing the reassociation deadline interval is present
(reassociation deadline) only in certain Authentication frames as defined in Table 9-36.
9 RIC A resource information container, containing a variable number of
elements, is present only in certain Authentication frames as
defined in Table 9-36.
10 Finite Cyclic Group An unsigned integer indicating a finite cyclic group as described
in 12.4.4. This is present only in certain Authentication frames as
defined in Table 9-36.
11 Anti-Clogging Token A random bit string used for anti-clogging purposes as described
in 12.4.6. This is present only in certain Authentication frames as
defined in Table 9-36.
12 Send-Confirm A binary encoding of an integer used for anti-replay purposes as
described in 12.4.7.5. This is present only in certain
Authentication frames as defined in Table 9-36.
13 Scalar An unsigned integer encoded as described in 12.4.7.4. This is
present only in certain Authentication frames as defined in
Table 9-36.
14 Finite field element A Finite field element field from a finite field encoded as
described in 12.4.7.4. This is present is present only in certain
Authentication frames as defined in Table 9-36.
15 Confirm An unsigned integer encoded as described in 12.4.7.5. This is
present only in certain Authentication frames as defined in
Table 9-36.
16 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
17 Neighbor Report One or more Neighbor Report elements are present only in certain
Authentication frames as defined in Table 9-36.
Last Vendor Specific One or more vendor-specific elements are optionally present.
These elements follow all other elements.
Table 9-36—Presence of fields and elements in Authentication frames
Authentication
Authentication
transaction Status code Presence of fields 4 onwards
algorithm
sequence number
Open System 1 Reserved Not present
Open System 2 Not Not present
REJECTED_WITH_SUGGE
STED_BSS_TRANSITION
Open System 2 REJECTED_WITH_SUGGE One or more Neighbor Report
STED_BSS_TRANSITION element(s) is present
Shared Key 1 Reserved Not present
Shared Key 2 Any The Challenge text element is
present
713
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-36—Presence of fields and elements in Authentication frames (continued)
Authentication
Authentication
transaction Status code Presence of fields 4 onwards
algorithm
sequence number
Shared Key 3 Reserved The Challenge text element is
present
Shared Key 4 Any Not present
FT 1 Reserved The Mobility Domain element is
present.
The Fast BSS Transition element
and RSNEs are present if
dot11RSNAActivated is true.
FT 2 Not The Mobility Domain element is
REJECTED_WITH_SUGGE present if the Status Code field is 0.
STED_BSS_TRANSITION
The Fast BSS Transition element
and RSNEs are present if the Status
Code field is 0 and
dot11RSNAActivated is true.
FT 2 REJECTED_WITH_SUGGE One or more Neighbor Report
STED_BSS_TRANSITION element(s) is present
FT 3 Reserved The Mobility Domain element is
present.
The Fast BSS Transition element
and RSNEs are present if
dot11RSNAActivated is true.
The RIC element is optionally
present.
FT 4 Any The Mobility Domain element is
present if the Status Code field is 0.
The Fast BSS Transition element
and RSNEs are present if
dot11RSNAActivated is true.
The RIC element is optionally
present if the Status Code field is 0.
The TIE (reassociation deadline) is
present if a RIC element is present.
SAE 1 Any Scalar is present if the Status Code
field is zero.
Element is present if the Status
Code field is zero.
Anti-Clogging Token is present if
status is 76 or if frame is in
response to a previous rejection
with Status 76.
Finite Cyclic Group is present if the
Status Code field is zero or 76.
714
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-36—Presence of fields and elements in Authentication frames (continued)
Authentication
Authentication
transaction Status code Presence of fields 4 onwards
algorithm
sequence number
SAE 2 Not Send-Confirm is present. Confirm
REJECTED_WITH_SUGGE is present.
STED_BSS_TRANSITION
SAE 2 REJECTED_WITH_SUGGE One or more Neighbor Report
STED_BSS_TRANSITION element(s) are present
9.3.3.13 Deauthentication
The frame body of a Deauthentication frame contains the information shown in Table 9-37.
Table 9-37—Deauthentication frame body
Order Information
1 Reason code
Last – 1 One or more vendor-specific elements are optionally present.
Last The Management MIC element (MME) is present when management frame
protection is enabled at the AP and the frame is a group addressed frame.
NOTE—The MME appears after all fields that it protects. Therefore, it appears last in the frame
body to protect the frames as specified in 12.5.4.
9.3.3.14 Action frame format
The frame body of an Action frame contains the information shown in Table 9-38.
Table 9-38—Action frame body
Order Information
1 Action
Last – 2 One or more vendor-specific elements are optionally present.
These elements are absent when the Category subfield of the Action field is Vendor-Specific,
Vendor-Specific Protected, or Self-protected or when the Category subfield of the Action field is
VHT and the VHT Action subfield of the Action field is VHT Compressed Beamforming.
Last – 1 The Management MIC element (MME) is present when management frame protection is enabled
at the AP, the frame is a group addressed robust Action frame, and the category of the Action
frame does not support group addressed privacy as indicated by Table 9-47.
Last The Authenticated Mesh Peering Exchange element is present in a Self-protected Action frame if
dot11MeshSecurityActivated, dot11ProtectedQLoadReportActivated, or
dot11ProtectedTXOPNegotiationActivated is true and a PMK exists between the sender and
recipient of this frame; otherwise not present.
NOTE—The MME appears after any fields that it protects. Therefore, it appears last in the frame body to protect
the frames as specified in 12.5.4.
715
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.3.3.15 Action No Ack frame format
The frame body of an Action No Ack frame contains the information shown in Table 9-39.
Table 9-39—Action No Ack frame body
Order Information
1 Action
Last One or more vendor-specific elements are optionally present. This element follows all
other elements.
NOTE—The selection of Action or Action No Ack is made per frame that uses these formats.
Unless specified as allowing the use of the Action No Ack management frame subtype, a frame described as
an “Action frame” uses only the Action subtype.
9.3.3.16 Timing Advertisement frame format
The frame body of a Timing Advertisement frame contains the information shown in Table 9-40.
Table 9-40—Timing Advertisement frame body
Order Information Notes
1 Timestamp See 9.4.1.10 for Timestamp format.
2 Capability
Information
3 Country The Country element is present if dot11MultiDomainCapabilityActivated
is true or dot11SpectrumManagementRequired is true.
4 Power Constraint The Power Constraint element is optionally present if the Country
element is present; otherwise not present.
5 Time Advertisement The Time Advertisement element is optionally present. See 9.4.2.61.
6 Extended Capabilities The Extended Capabilities element is present.
Last Vendor specific One or more vendor-specific elements are optionally present. These
elements follow all other elements.
9.3.4 Extension frames
9.3.4.1 Format of Extension frames
The format of Extension frames is defined in Figure 9-59. The MAC header of an Extension frame starts
with the Frame Control field followed by the Duration field. The MAC header of different Extension frames
can have different number and types of fields following the Duration field.
716
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Octets: 2 2 variable variable ... variable variable 4
Frame Frame
Control Duration ... Body FCS
MAC header
Figure 9-59—Extension frame format
9.3.4.2 DMG Beacon
The format of the DMG Beacon frame is shown in Figure 9-60.
In addition to supporting functions such as network synchronization (see 11.1), the DMG Beacon frame can
also be used as a training frame for beamforming (see 10.38).
Frame Control Duration BSSID Frame FCS
Body
Octets: 2 2 6 Variable 4
Figure 9-60—DMG Beacon frame format
The Duration field is set to the time remaining until the end of the beacon transmission interval (BTI).
The BSSID field contains the BSSID.
The Frame Body field of the DMG Beacon frame contains the elements listed in Table 9-41.
Table 9-41—DMG Beacon frame body
Order Information Notes
1 Timestamp See 9.4.1.10
2 Sector Sweep See 9.5.1
3 Beacon Interval See 9.4.1.3
4 Beacon Interval Control See Figure 9-61.
5 DMG Parameters See 9.4.1.47
6 Clustering Control Optional. See Figure 9-62 and Figure 9-63.
7 DMG Capabilities The DMG Capabilities element is optionally present.
8 Extended Schedule The Extended Schedule element is optionally present.
9 RSN The RSNE is optionally present if dot11RSNAActivated is true.
10 Multiple BSSID One or more Multiple BSSID elements are optionally present if
dot11MultiBSSIDActivated is true.
11 DMG Operation The DMG Operation element is optionally present.
12 Next DMG ATI The Next DMG ATI element is optionally present.
717
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-41—DMG Beacon frame body (continued)
Order Information Notes
13 DMG BSS Parameter The DMG BSS Parameter Change element is optionally present.
Change
14 Multi-band Zero or more Multi-band elements are present if
dot11MultibandImplemented is true.
15 Awake Window The Awake Window element is optionally present. If present, this
element specifies the characteristics of the awake window of a CBAP
(see 11.2.7).
16 DMG Wakeup Schedule The DMG Wakeup Schedule element is optionally present (see
11.2.7.3.3.
17 UPSIM The UPSIM element is optionally present (see 11.2.7.2.2).
18 SSID The SSID element is optionally present.
19 IBSS Parameter Set The IBSS Parameter Set element is present only within DMG Beacon
frames generated by IBSS STAs.
20 Country The Country element is optionally present if
dot11MultiDomainCapabilityActivated is true or
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
21 BSS Load The BSS Load element is optionally present if
dot11QosOptionImplemented and dot11QBSSLoadImplemented are
both true.
22 EDCA Parameter Set The EDCA Parameter Set element is optionally present.
23 Power Constraint The Power Constraint element is optionally present if
dot11SpectrumManagementRequired is true and is optionally present if
dot11RadioMeasurementActivated is true.
24 Channel Switch The Channel Switch Announcement element is optionally present if
Announcement dot11SpectrumManagementRequired is true.
25 Neighbor Report The Neighbor Report element is optionally present.
26 Quiet The Quiet element is optionally present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
27 QoS Capability The QoS Capability element is optionally present.
28 Extended Channel The Extended Channel Switch Announcement element is optionally
Switch Announcement present if dot11ExtendedChannelSwitchActivated is true.
29 BSS Average Access The BSS Average Access Delay element is optionally present.
Delay
30 RM Enabled The RM Enabled Capabilities element is optionally present if
Capabilities dot11RadioMeasurementActivated is true.
31 Nontransmitted BSSID The Nontransmitted BSSID Capability element is optionally present.
Capability
32 SSID List The SSID List element is optionally present if dot11SSIDListActivated is
true.
33 Interworking The Interworking element is optionally present if
dot11InterworkingServiceActivated is true.
718
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-41—DMG Beacon frame body (continued)
Order Information Notes
34 Advertisement Protocol The Advertisement Protocol element is optionally present if
dot11InterworkingServiceActivated is true and at least one
dot11GASAdvertisementID exists.
35 Roaming Consortium The Roaming Consortium element is optionally present if
dot11InterworkingServiceActivated is true and the
dot11RoamingConsortiumTable has at least one entry.
36 STA Availability The STA Availability element is optionally present.
37 Next PCP List The Next PCP List element is optionally present.
38 PCP Handover The PCP Handover element is optionally present.
39 Antenna Sector ID The Antenna Sector ID Pattern element is optionally present.
Pattern
Last Vendor Specific One or more vendor-specific elements are optionally present. These
elements follow all other elements.
The format of the Beacon Interval Control field is shown in Figure 9-61.
B0 B1 B2 B5 B6 B7 B9 B10 B13 B14
CC Discovery Next ATI A-BFT
FSS IsResponderTXSS
Present Mode Beacon Present Length
Bits: 1 1 4 1 3 4 1
B15 B18 B19 B20 B26 B27 B30 B31 B36 B37 B42 B43 B44 B47
Next Fragmented TXSS N BIs A-BFT N PCP
A-BFT in Association Reserved
A-BFT TXSS Span A-BFT Count Ant Ready
Bits: 4 1 7 4 6 6 1 4
Figure 9-61—Beacon Interval Control field
The CC Present subfield is set to 1 to indicate that the Clustering Control field is present in the DMG
Beacon. Otherwise, the Clustering Control field is not present.
The Discovery Mode subfield is set to 1 if the STA is generating the DMG Beacon following the procedure
described in 11.1.3.4. Otherwise, this subfield is set to 0.
The Next Beacon subfield indicates the number of beacon intervals following the current beacon interval
during which the DMG Beacon frame will not be present.
The ATI Present subfield is set to 1 to indicate that the announcement transmission interval (ATI) is present
in the current beacon interval. Otherwise, the ATI is not present.
The A-BFT Length subfield specifies the size of the A-BFT following the BTI and is defined in units of a
sector sweep slot (10.38.5). The value of this field is in the range 1 to 8, with the value being equal to the bit
representation plus 1.
719
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The FSS subfield specifies the number of SSW frames allowed per sector sweep slot minus one (10.38.5).
The range of this subfield is 0 to 15. For example, when the number of SSW frames allowed per sector
sweep is 5, the subfield contains the value 4.
The IsResponderTXSS subfield is set to 1 to indicate the A-BFT following the BTI is used for responder
transmit sector sweep (TXSS). This field is set to 0 to indicate responder receive sector sweep (RXSS).
When this subfield is set to 0, the FSS subfield specifies the length of a complete receive sector sweep by the
STA sending the DMG Beacon frame.
The Next A-BFT subfield indicates the number of beacon intervals during which the A-BFT is not be
present. A value of 0 indicates that the A-BFT immediately follows this BTI.
The Fragmented TXSS subfield is set to 1 to indicate the TXSS is a fragmented sector sweep and is set to 0
to indicate the TXSS is a complete sector sweep.
The TXSS Span subfield indicates the number of beacon intervals it takes for the STA sending the DMG
Beacon frame to complete the TXSS phase. This subfield is always greater than or equal to 1.
The N BIs A-BFT subfield indicates the interval, in number of beacon intervals, at which the STA sending
the DMG Beacon frame allocates an A-BFT. A value of 1 indicates that every beacon interval contains an
A-BFT.
The A-BFT Count subfield indicates the number of A-BFTs since the STA sending the DMG Beacon frame
last switched RX DMG antennas for an A-BFT. A value of 0 indicates that the DMG antenna used in the
forthcoming A-BFT differs from the DMG antenna used in the last A-BFT. This subfield is reserved if the
value of the Number of RX DMG Antennas field within the STA’s DMG Capabilities element is 1.
The N A-BFT in Ant subfield indicates how many A-BFTs the STA sending the DMG Beacon frame
receives from each DMG antenna in the DMG antenna receive rotation. This subfield is reserved if the value
of the Number of RX DMG Antennas field within the STA’s DMG Capabilities element is 1.
The PCP Association Ready subfield is set to 1 to indicate that the PCP is ready to receive Association
Request frames from non-PCP STAs and is set to 0 otherwise. This subfield is reserved when transmitted by
a non-PCP STA.
The DMG Parameters field is defined in 9.4.1.47.
If the value of Discovery Mode field is 0, the Clustering Control field is formatted as shown in Figure 9-62.
If the value of the Discovery Mode field is 1, the Clustering Control field is formatted as shown in
Figure 9-63.
B0 B7 B8 B55 B56 B57 B58 B62 B63
Beacon SP Cluster
Duration Cluster ID Member Role ClusterMaxMem Reserved
Bits: 8 48 2 5 1
Figure 9-62—Clustering Control field format if the Discovery Mode field is 0
720
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B47 B48 B63
A-BFT Responder Address Reserved
Bits: 48 16
Figure 9-63—Clustering Control field format if the Discovery Mode field is 1
If ECAPC Policy Enforced field is set to 0, the Beacon SP Duration subfield indicates the duration, in units
of 8 µs, of the Beacon SPs in the cluster. If ECAPC Policy Enforced field is set to 1, the Beacon SP Duration
subfield indicates the maximum duration, in units of 8 µs, of the beacon header interval (BHI) of the BSS,
and the minimum duration of Beacon SPs in the cluster (see 10.37.2.2).
The cluster to which the transmitter of the Clustering Control field belongs is identified by the Cluster ID
subfield. The MAC address of the S-AP or synchronization PCP (S-PCP) is the Cluster ID of the cluster.
The Cluster Member Role subfield identifies the role that the transmitting STA assumes within the cluster.
A value of 0 means that the STA is currently not participating in clustering. A value of 1 means that the STA
acts as the S-AP or S-PCP of the cluster. A value of 2 means that the STA participates in the cluster, but not
as the S-AP or S-PCP. The value 3 is reserved.
The ClusterMaxMem subfield defines the maximum number of PCPs and/or APs, including the S-AP or S-
PCP, that can participate in the cluster. The value of the ClusterMaxMem subfield is computed in relation to
the beacon interval value (10.38.2). The value 0 is reserved. Values 8 and above are reserved if the ECAPC
Policy Enforced field is set to 0. The value 1 is assigned to the S-AP or S-PCP.
The A-BFT Responder Address subfield contains the MAC address of the STA that is allowed to transmit
during the A-BFT, if present, that follows the BTI.
9.3.5 Frame addressing in an MBSS
Mesh Data frames and Multihop Action frames enable multihop MSDU and MMPDU forwarding in an
MBSS using the Mesh Control field described in 9.2.4.7.3.
Table 9-42 shows the valid combinations of address fields in mesh Data frames and Multihop Action frames
along with the corresponding value of the Address Extension Mode subfield in the Mesh Control field.
Table 9-42—Valid address field usage for Mesh Data and Multihop Action frames
Address
Supported From Address Address Address Address Address Address
To DS extension
frames DS 1 2 3 4 5 6
mode
Mesh Data 1 1 None RA TA DA = SA = Not Not
(individually Mesh DA Mesh SA Present Present
addressed)
Mesh Data 0 1 None DA TA SA = Not Not Not
(group Mesh SA Present Present Present
addressed)
Mesh Data 1 1 Address5&6 RA TA Mesh DA Mesh SA DA SA
(proxied,
individually
addressed)
721
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-42—Valid address field usage for Mesh Data and Multihop Action frames (continued)
Address
Supported From Address Address Address Address Address Address
To DS extension
frames DS 1 2 3 4 5 6
mode
Mesh Data 0 1 Address4 DA TA Mesh SA SA Not Not
(proxied, Present Present
group
addressed)
Multihop 0 0 Address4 RA TA DA = SA = Not Not
Action Mesh DA Mesh SA Present Present
(individually
addressed)
Multihop 0 0 None DA TA SA = Not Not Not
Action (group Mesh SA Present Present Present
addressed)
NOTE 1—To DS and From DS subfields are located in the Frame Control field (see 9.2.4.1.4). The Address Extension
Mode subfield is located in the Mesh Flags subfield in the Mesh Control field (see 9.2.4.7.3). Address 1, Address 2, and
Address 3 fields are located in the MAC header (see 9.2.3). The Address 4 field is located in the MAC header if both To
DS and From DS subfields are 1; otherwise, the Address 4 field is located in the Mesh Address Extension subfield of the
Mesh Control field (see 9.2.3 and 9.2.4.7.3). Address 5 and Address 6 fields are located in the Mesh Control field if they
are present (see 9.2.4.7.3).
NOTE 2—Values for the Address Extension Mode subfield are defined in see Table 9-20.
In individually addressed Mesh Data and Multihop Action frames, Address 1 and Address 2 correspond to
the mesh STA receiver address (RA) and the mesh STA transmitter address (TA) for a particular mesh link.
Address 3 and Address 4 correspond to the destination mesh STA and the source mesh STA of a mesh path.
The Address Extension Mode subfield in the Mesh Control field indicates the presence of an optional Mesh
Address Extension subfield in the Mesh Control field. When the Extension Mode subfield equals
“Address5&6” (see Table 9-20), the Mesh Control field includes Address 5 and Address 6 that correspond
to the end-to-end destination address (DA) and source address (SA) of STAs that communicate over the
mesh path, for instance, external STAs that communicate over the mesh BSS via proxy mesh gates (see
Figure 9-64).
NOTE—The forwarding of individually addressed mesh Data frames uses only mesh STA addresses in fields Address 1,
Address 2, Address 3, and Address 4. This allows intermediate mesh STAs to forward mesh Data frames without
necessarily having any knowledge of the addresses of the source and destination end stations, which might be external
addresses. Thus, proxy information only needs to be maintained by proxy mesh gates and by source mesh STAs.
The term source mesh STA refers to the first mesh STA on a mesh path. A source mesh STA is either a mesh
STA that is the initial source of an MSDU/MMPDU or a mesh STA that receives an MSDU/MMPDU from
a mesh path or from a STA outside the mesh BSS and translates and forwards the MSDU/MMPDU on the
mesh path. The address of the source mesh STA is referred to as the Mesh SA.
The term destination mesh STA refers to the final mesh STA on a mesh path. A destination mesh STA is
either a mesh STA that is the final destination of an MSDU/MMPDU or a mesh STA that receives an
MSDU/MMPDU from a mesh path and translates and forwards the MSDU/MMPDU on another mesh path
or to a STA outside of the mesh BSS. The address of the destination mesh STA is referred to as the Mesh
DA.
In group addressed mesh Data frames, Address 1 and Address 2 correspond to the group address and the
mesh STA transmitter address (TA). Address 3 corresponds to the mesh source address (mesh SA) of the
group addressed mesh Data frame. The Address Extension Mode indicates the presence of an optional
722
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
address extension field Address 4 in the Mesh Control field that corresponds to the source address (SA) of
external STAs that communicate over the mesh BSS via proxy mesh gates.
NOTE—The reason for not using the four-address MAC header format for group addressed traffic is to avoid
interactions with existing implementations. Earlier revisions of this standard defined the four-address MAC header
format without defining procedures for its use. As a result there is a large number of deployed devices that use the four-
address frame format in ways that would affect and be affected by mesh traffic if four-address group addressed frames
were to be used.
Figure 9-64 illustrates the addressing of a mesh Data frame that contains an MSDU transmitted and
forwarded on a mesh path from a mesh STA collocated with a portal (STA 1) to a mesh STA collocated with
an AP (STA 2) where the source is a STA outside of the mesh BSS (STA 33) that is reachable via the portal
and the destination is an IEEE 802.11 STA associated with the AP (STA 22).
SA mesh SA TA RA mesh DA DA
STA 33 link Portal Gate Mesh Mesh Mesh Mesh Gate AP
mesh mesh mesh
DS
STA 1 STA 4 STA 6 STA 2 STA 17 link STA 22
802.x LAN
link link link DS
infrastructure BSS
mesh BSS (MBSS)
mesh path
end to end 802 communication
Figure 9-64—Example addressing for a mesh Data frame
Details on how these address mappings work in forwarding processing are described in 10.35.3 and 10.35.4
9.4 Management and Extension frame body components
9.4.1 Fields that are not elements
9.4.1.1 Authentication Algorithm Number field
The Authentication Algorithm Number field indicates a single authentication algorithm. The length of the
Authentication Algorithm Number field is 2 octets. The Authentication Algorithm Number field is
illustrated in Figure 9-65. The following values are defined for authentication algorithm number:
Authentication algorithm number = 0: Open System
Authentication algorithm number = 1: Shared Key
Authentication algorithm number = 2: Fast BSS Transition
Authentication algorithm number = 3: Simultaneous Authentication of Equals (SAE)
Authentication algorithm number = 65 535: vendor specific use
NOTE—The use of this value implies that a Vendor Specific element is included with more information.
All other values of authentication algorithm number are reserved.
Authentication Algorithm Number
Octets: 2
Figure 9-65—Authentication Algorithm Number field
723
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.1.2 Authentication Transaction Sequence Number field
The Authentication Transaction Sequence Number field indicates the current state of progress through a
multistep transaction. The length of the Authentication Transaction Sequence Number field is 2 octets. The
Authentication Transaction Sequence Number field is illustrated in Figure 9-66.
Authentication Transaction Sequence Number
Octets: 2
Figure 9-66—Authentication Transaction Sequence Number field
9.4.1.3 Beacon Interval field
The Beacon Interval field represents the number of time units (TUs) between target beacon transmission
times (TBTTs). The length of the Beacon Interval field is 2 octets. The Beacon Interval field is illustrated in
Figure 9-67.
Beacon Interval
Octets: 2
Figure 9-67—Beacon Interval field
A value of 0 in the Beacon Interval field transmitted by a DMG STA indicates that the TBTT of the next BTI
is unknown.
9.4.1.4 Capability Information field
The Capability Information field contains a number of subfields that are used to indicate requested or
advertised optional capabilities.
The length of the Capability Information field is 2 octets. The format of the Capability Information field is
defined in Figure 9-68 when transmitted by a non-DMG STA and in Figure 9-69 when transmitted by a
DMG STA.
B0 B1 B2 B3 B4 B5 B6 B7
ESS IBSS CF Pollable CF-Poll Privacy Short Reserved Reserved
Request Preamble
B8 B9 B10 B11 B12 B13 B14 B15
Spectrum QoS Short Slot APSD Radio Reserved Delayed Immediate
Management Time Measurement Block Ack Block Ack
Figure 9-68—Capability Information field (non-DMG STA)
724
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B7 B8 B9 B10 B11 B12 B13 B15
Triggered
DMG Parameters Spectrum Unscheduled Reserved Radio Reserved
Management Measurement
PS
Bits: 8 1 1 2 1 3
Figure 9-69—Capability Information field (DMG STA)
A DMG STA sets the Triggered Unscheduled PS subfield to 1 within the Capability Information field when
it transmits a Capability Information field in which the Reverse Direction subfield is equal to 1 and is
capable of delivering a BU as an RD responder on receipt of a PPDU containing an RDG MPDU with the
Power Management subfield set to 1 and sets it to 0 otherwise.
Each Capability Information subfield is interpreted according to the management frame subtype, as defined
in this subclause.
An AP sets the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Response
frames. Otherwise, the ESS and IBSS subfields are reserved. An IBSS STA sets the ESS subfield to 0 and
the IBSS subfield to 1 in transmitted Beacon or Probe Response frames. A mesh STA sets the ESS and IBSS
subfields to 0 in transmitted Beacon or Probe Response frames.
A non-AP STA sets the QoS, CF-Pollable, and CF-Poll Request subfields in (Re)Association Request
frames according to Table 9-43. A mesh STA sets the CF-Pollable and CF-Poll Request subfields to 0.
Table 9-43—Non-AP STA usage of QoS, CF-Pollable, and CF-Poll Request
CF-Poll
QoS CF-Pollable Meaning
request
0 0 0 STA is not CF-Pollable
0 0 1 STA is CF-Pollable, not requesting to be placed on the CF-Polling list
0 1 0 STA is CF-Pollable, requesting to be placed on the CF-Polling list
0 1 1 STA is CF-Pollable, requesting never to be polled
1 0 0 QoS STA requesting association in a QoS BSS
1 0 1 Reserved
1 1 0 Reserved
1 1 1 Reserved
An AP sets the CF-Pollable and CF-Poll Request subfields in Beacon and Probe Response frames according
to Table 9-44. A non-QoS AP sets the CF-Pollable and CF-Poll Request subfield values in (Re)Association
Response frames equal to the values in the last Beacon or Probe Response frame that it transmitted.
An AP sets the Privacy subfield to 1 within transmitted Beacon, Probe Response, (Re)Association Response
frames if data confidentiality is required for all Data frames exchanged within the BSS. If data
confidentiality is not required, the Privacy subfield is set to 0.
In an RSNA, a non-AP STA in an infrastructure BSS sets the Privacy subfield to 0 within transmitted
(Re)Association Request frames. The Privacy subfield is reserved in (Re)Association Request frames.
725
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-44—AP usage of QoS, CF-Pollable, and CF-Poll Request
CF-Poll
QoS CF-Pollable Meaning
Request
0 0 0 No PC at non-QoS AP
0 0 1 PC at non-QoS AP for delivery only (no polling)
0 1 0 PC at non-QoS AP for delivery and polling
0 1 1 Reserved
1 0 0 QoS AP (HC) does not use CFP for delivery of individually addressed
Data frames
1 0 1 QoS AP (HC) uses CFP for delivery, but does not send CF-Polls to
non-QoS STAs
1 1 0 QoS AP (HC) uses CFP for delivery, and sends CF-Polls to non-QoS
STAs
1 1 1 Reserved
A STA within an infrastructure BSS sets the Privacy subfield to 1 in DLS Request and DLS Response
frames if encryption is required for all Data frames exchanged. If encryption is not required, the Privacy
subfield is set to 0.
An IBSS STA sets the Privacy subfield to 1 in transmitted Beacon or Probe Response frames if data
confidentiality is required for all Data frames exchanged within the IBSS. If data confidentiality is not
required, An IBSS STA sets the Privacy subfield to 0 within these Management frames.
A mesh STA sets the Privacy subfield to 1 in transmitted Beacon or Probe Response frames if data
confidentiality is required for all Data frames exchanged within the MBSS. If data confidentiality is not
required, a mesh STA sets the Privacy subfield to 0 within these Management frames.
A STA that includes the RSNE in Beacon and Probe Response frames sets the Privacy subfield to 1 in any
frame that includes the RSNE.
An AP sets the Short Preamble subfield to 1 in transmitted Beacon, Probe Response, Association Response,
and Reassociation Response frames to indicate that the use of the short preamble, as described in 16.2.2.3, is
allowed within this BSS; an IBSS STA sets the Short Preamble subfield to 1 in transmitted Beacon when
dot11ShortPreambleOptionImplemented is true. Otherwise an AP or an IBSS STA sets the Short Preamble
subfield to 0.
A mesh STA sets the Short Preamble subfield to 1 when dot11ShortPreambleOptionImplemented is true.
Otherwise, a mesh STA sets the Short Preamble subfield to 0.
An ERP STA sets dot11ShortPreambleOptionImplemented to true as all ERP STAs support both long and
short preamble formats.
A STA sets the Short Preamble subfield to 1 in transmitted Association Request and Reassociation Request
frames and in DLS Request and DLS Response frames when dot11ShortPreambleOptionImplemented is
true. Otherwise, a STA sets the Short Preamble subfield to 0.
A STA sets the Spectrum Management subfield in the Capability Information field to 1 if
dot11SpectrumManagementRequired is true; otherwise, it is set to 0.
726
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA sets the QoS subfield to 1 within the Capability Information field when
dot11QosOptionImplemented is true and sets it to 0 otherwise.
A STA sets the Short Slot Time subfield to 1 in transmitted Association Request, Reassociation Request,
DLS Request, and DLS Response frames when dot11ShortSlotTimeOptionImplemented and
dot11ShortSlotTimeOptionActivated are true. Otherwise, the STA sets the Short Slot Time subfield to 0.
An AP sets the Short Slot Time subfield in transmitted Beacon, Probe Response, Association Response, and
Reassociation Response frames to indicate the currently used slot time value within this BSS. See 11.1.3.2.
See 10.3.2.13 for the operation of aSlotTime.
For IBSS and MBSS, the Short Slot Time subfield is set to 0.
An AP sets the APSD subfield to 1 within the Capability Information field when
dot11APSDOptionImplemented is true and sets it to 0 otherwise. A non-AP STA always sets this subfield
to 0.
A STA sets the Delayed Block Ack subfield to 1 within the Capability Information field when
dot11DelayedBlockAckOptionImplemented is true and sets it to 0 otherwise.
A STA sets the Immediate Block Ack subfield to 1 within the Capability Information field when
dot11ImmediateBlockAckOptionImplemented is true and sets it to 0 otherwise.
A STA sets the Radio Measurement subfield in the Capability Information field to 1 when
dot11RadioMeasurementActivated is true and sets it to 0 otherwise.
The DMG Parameters field is defined in 9.4.1.47.
9.4.1.5 Current AP Address field
The Current AP Address field is the MAC address of the AP with which the STA is currently associated. The
length of the Current AP Address field is 6 octets. The Current AP Address field is illustrated in Figure 9-70.
Current AP Address
Octets: 6
Figure 9-70—Current AP Address field
9.4.1.6 Listen Interval field
The Listen Interval field is used to indicate to the AP how often a STA in power save mode wakes to listen
to Beacon frames. The value of this field is the ListenInterval parameter of the MLME-
ASSOCIATE.request or MLME-REASSOCIATE.request primitive, in units of Beacon Interval. The length
of the Listen Interval field is 2 octets. The Listen Interval field is illustrated in Figure 9-71.
NOTE—The value 0 might be used by a STA that never enters power save mode.
Listen Interval
Octets: 2
Figure 9-71—Listen Interval field
An AP uses the listen interval in determining the lifetime of frames that it buffers for a STA.
727
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.1.7 Reason Code field
This Reason Code field is used to indicate the reason that an unsolicited notification Management frame of
type Disassociation, Deauthentication, DELTS, DELBA, DLS Teardown, or Mesh Peering Close was
generated. It is contained in the Mesh Channel Switch Parameters element to indicate the reason for the
channel switch. It is contained in the PERR element to indicate the reason for the path error. The length of
the Reason Code field is 2 octets. The Reason Code field is illustrated in Figure 9-72.
Reason Code
Octets: 2
Figure 9-72—Reason Code field
The reason codes are defined in Table 9-45.
Table 9-45—Reason codes
Reason
Name Meaning
code
0 Reserved
1 UNSPECIFIED_REASON Unspecified reason
2 INVALID_AUTHENTICATION Previous authentication no longer valid
3 LEAVING_NETWORK_DEAUT Deauthenticated because sending STA is leaving (or has left)
H IBSS or ESS
4 REASON_INACTIVITY Disassociated due to inactivity
5 NO_MORE_STAS Disassociated because AP is unable to handle all currently
associated STAs
6 INVALID_CLASS2_FRAME Class 2 frame received from nonauthenticated STA
7 INVALID_CLASS3_FRAME Class 3 frame received from nonassociated STA
8 LEAVING_NETWORK_DISASS Disassociated because sending STA is leaving (or has left)
OC BSS
9 NOT_AUTHENTICATED STA requesting (re)association is not authenticated with
responding STA
10 UNACCEPTABLE_POWER_CA Disassociated because the information in the Power Capability
PABILITY element is unacceptable
11 UNACCEPTABLE_SUPPORTED Disassociated because the information in the Supported
_CHANNELS Channels element is unacceptable
12 BSS_TRANSITION_DISASSOC Disassociated due to BSS transition management
13 REASON_INVALID_ELEMENT Invalid element, i.e., an element defined in this standard for
which the content does not meet the specifications in Clause 9
14 MIC_FAILURE Message integrity code (MIC) failure
15 4WAY_HANDSHAKE_TIMEOU 4-way handshake timeout
T
16 GK_HANDSHAKE_TIMEOUT Group key handshake timeout
17 HANDSHAKE_ELEMENT_MIS Element in 4-way handshake different from (Re)Association
MATCH Request/Probe Response/Beacon frame
728
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-45—Reason codes (continued)
Reason
Name Meaning
code
18 REASON_INVALID_GROUP_CI Invalid group cipher
PHER
19 REASON_INVALID_PAIRWISE Invalid pairwise cipher
_CIPHER
20 REASON_INVALID_AKMP Invalid AKMP
21 UNSUPPORTED_RSNE_VERSI Unsupported RSNE version
ON
22 INVALID_RSNE_CAPABILITIE Invalid RSNE capabilities
S
23 802_1_X_AUTH_FAILED IEEE 802.1X authentication failed
24 REASON_CIPHER_OUT_OF_P Cipher suite rejected because of the security policy
OLICY
25 TDLS_PEER_UNREACHABLE TDLS direct-link teardown due to TDLS peer STA
unreachable via the TDLS direct link
26 TDLS_UNSPECIFIED_REASON TDLS direct-link teardown for unspecified reason
27 SSP_REQUESTED_DISASSOC Disassociated because session terminated by SSP request
28 NO_SSP_ROAMING_AGREEM Disassociated because of lack of SSP roaming agreement
ENT
29 BAD_CIPHER_OR_AKM Requested service rejected because of SSP cipher suite or
AKM requirement
30 NOT_AUTHORIZED_THIS_LO Requested service not authorized in this location
CATION
31 SERVICE_CHANGE_ TS deleted because QoS AP lacks sufficient bandwidth for this
PRECLUDES_TS QoS STA due to a change in BSS service characteristics or
operational mode (e.g., an HT BSS change from 40 MHz
channel to 20 MHz channel)
32 UNSPECIFIED_QOS_REASON Disassociated for unspecified, QoS-related reason
NOT_ENOUGH_BANDWIDTH Disassociated because QoS AP lacks sufficient bandwidth for
33
this QoS STA
34 MISSING_ACKS Disassociated because excessive number of frames need to be
acknowledged, but are not acknowledged due to AP
transmissions and/or poor channel conditions
35 EXCEEDED_TXOP Disassociated because STA is transmitting outside the limits of
its TXOPs
36 STA_LEAVING Requesting STA is leaving the BSS (or resetting)
37 END_TS Requesting STA is no longer using the stream or session
END_BA
END_DLS
38 UNKNOWN_TS Requesting STA received frames using a mechanism for which
UNKNOWN_BA a setup has not been completed
39 TIMEOUT Requested from peer STA due to timeout
45 PEERKEY_MISMATCH Peer STA does not support the requested cipher suite
729
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-45—Reason codes (continued)
Reason
Name Meaning
code
46 PEER_INITIATED In a DLS Teardown frame: The teardown was initiated by the
DLS peer
In a Disassociation frame: Disassociated because authorized
access limit reached
47 AP_INITIATED In a DLS Teardown frame: The teardown was initiated by the
AP
In a Disassociation frame: Disassociated due to external
service requirements
REASON_INVALID_FT_ACTIO
48 Invalid FT Action frame count
N_FRAME_COUNT
49 REASON_INVALID_PMKID Invalid pairwise master key identifier (PMKID)
50 REASON_INVALID_MDE Invalid MDE
51 REASON_INVALID_FTE Invalid FTE
52 MESH-PEERING-CANCELED Mesh peering canceled for unknown reasons
53 MESH-MAX-PEERS The mesh STA has reached the supported maximum number of
peer mesh STAs
54 MESH-CONFIGURATION- The received information violates the Mesh Configuration
POLICY-VIOLATION policy configured in the mesh STA profile
55 MESH-CLOSE-RCVD The mesh STA has received a Mesh Peering Close frame
requesting to close the mesh peering.
56 MESH-MAX-RETRIES The mesh STA has resent dot11MeshMaxRetries Mesh
Peering Open frames, without receiving a Mesh Peering
Confirm frame.
57 MESH-CONFIRM-TIMEOUT The confirmTimer for the mesh peering instance times out.
58 MESH-INVALID-GTK The mesh STA fails to unwrap the GTK or the values in the
wrapped contents do not match
59 MESH-INCONSISTENT- The mesh STA receives inconsistent information about the
PARAMETERS mesh parameters between mesh peering Management frames
60 MESH-INVALID-SECURITY- The mesh STA fails the authenticated mesh peering exchange
CAPABILITY because due to failure in selecting either the pairwise
ciphersuite or group ciphersuite
61 MESH-PATH-ERROR-NO- The mesh STA does not have proxy information for this
PROXY-INFORMATION external destination.
62 MESH-PATH-ERROR-NO- The mesh STA does not have forwarding information for this
FORWARDING-INFORMATION destination.
63 MESH-PATH-ERROR- The mesh STA determines that the link to the next hop of an
DESTINATION- active path in its forwarding information is no longer usable.
UNREACHABLE
64 MAC-ADDRESS-ALREADY- The Deauthentication frame was sent because the MAC
EXISTS-IN-MBSS address of the STA already exists in the mesh BSS. See 11.3.6.
65 MESH-CHANNEL-SWITCH- The mesh STA performs channel switch to meet regulatory
REGULATORY- requirements.
REQUIREMENTS
730
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-45—Reason codes (continued)
Reason
Name Meaning
code
66 MESH-CHANNEL-SWITCH- The mesh STA performs channel switching with unspecified
UNSPECIFIED reason.
67–65 535 Reserved
9.4.1.8 AID field
In infrastructure BSS operation, the AID field contains a value assigned by an AP or PCP during association.
The field represents the 16-bit ID of a STA. In mesh BSS operation, the AID field is a value that represents the
16-bit ID of a neighbor peer mesh STA. An AID value is assigned by a mesh STA that receives and accepts a
Mesh Peering Open frame to the transmitter of the Mesh Peering Open frame during the mesh peering
establishment process (see 14.3.1). The length of the AID field is 2 octets. The AID field is illustrated in
Figure 9-73.
Association ID (AID)
Octets: 2
Figure 9-73—AID field
A non-DMG STA assigns the value of the AID in the range of 1 to 2007; the 5 MSBs of the AID field are
reserved.
A DMG STA assigns the value of the AID field in the range 1 to 254. The value 255 is reserved as the
broadcast AID, and the value 0 corresponds to the AP or PCP. The 8 MSBs of the AID field are reserved.
9.4.1.9 Status Code field
The Status Code field is used in a response Management frame to indicate the success or failure of a
requested operation. The length of the Status Code field is 2 octets. The Status Code field is illustrated in
Figure 9-74.
Status Code
Octets: 2
Figure 9-74—Status Code field
If an operation is successful, then the status code is set to SUCCESS (0). A status code of
SUCCESS_POWER_SAVE_MODE also indicates a successful operation. If an operation results in failure,
the status code indicates a failure cause. The failure cause codes are defined in Table 9-46.
731
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-46—Status codes
Status code Name Meaning
0 SUCCESS Successful.
1 REFUSED, Unspecified failure.
REFUSED_REASON_UNSPECIFIED
2 TDLS_REJECTED_ALTERNATIVE_ TDLS wakeup schedule rejected but alternative schedule
PROVIDED provided.
3 TDLS_REJECTED TDLS wakeup schedule rejected.
4 Reserved.
5 SECURITY_DISABLED Security disabled.
6 UNACCEPTABLE_LIFETIME Unacceptable lifetime.
7 NOT_IN_SAME_BSS Not in same BSS.
8–9 Reserved.
10 REFUSED_CAPABILITIES_ Cannot support all requested capabilities in the
MISMATCH Capability Information field.
11 DENIED_NO_ASSOCIATION_EXIS Reassociation denied due to inability to confirm that
TS association exists.
12 DENIED_OTHER_REASON Association denied due to reason outside the scope of
this standard.
13 UNSUPPORTED_AUTH_ALGORIT Responding STA does not support the specified
HM authentication algorithm.
14 TRANSACTION_SEQUENCE_ERRO Received an Authentication frame with authentication
R transaction sequence number out of expected sequence.
15 CHALLENGE_FAILURE Authentication rejected because of challenge failure.
16 REJECTED_SEQUENCE_TIMEOUT Authentication rejected due to timeout waiting for next
frame in sequence.
17 DENIED_NO_MORE_STAS Association denied because AP is unable to handle
additional associated STAs.
18 REFUSED_BASIC_RATES_ Association denied due to requesting STA not supporting
MISMATCH all of the data rates in the BSSBasicRateSet parameter,
the Basic HT-MCS Set field of the HT Operation
parameter, or the Basic VHT-MCS and NSS Set field in
the VHT Operation parameter.
19 DENIED_NO_SHORT_PREAMBLE_ Association denied due to requesting STA not supporting
SUPPORT the short preamble option.
20 Reserved.
21 Reserved.
22 REJECTED_SPECTRUM_MANAGE Association request rejected because Spectrum
MENT_REQUIRED Management capability is required.
23 REJECTED_BAD_POWER_CAPABI Association request rejected because the information in
LITY the Power Capability element is unacceptable.
24 REJECTED_BAD_SUPPORTED_CH Association request rejected because the information in
ANNELS the Supported Channels element is unacceptable.
25 DENIED_NO_SHORT_SLOT_TIME_ Association denied due to requesting STA not supporting
SUPPORT the Short Slot Time option.
732
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-46—Status codes (continued)
Status code Name Meaning
26 Reserved.
27 DENIED_NO_HT_SUPPORT Association denied because the requesting STA does not
support HT features.
28 R0KH_UNREACHABLE R0KH unreachable.
29 DENIED_PCO_TIME_NOT_SUPPOR Association denied because the requesting STA does not
TED support the phased coexistence operation (PCO)
transition time required by the AP.
30 REFUSED_TEMPORARILY Association request rejected temporarily; try again later.
31 ROBUST_MANAGEMENT_POLICY Robust management frame policy violation.
_VIOLATION
32 UNSPECIFIED_QOS_FAILURE Unspecified, QoS-related failure.
33 DENIED_INSUFFICIENT_BANDWI Association denied because QoS AP or PCP has
DTH insufficient bandwidth to handle another QoS STA.
34 DENIED_POOR_CHANNEL_CONDI Association denied due to excessive frame loss rates and/
TIONS or poor conditions on current operating channel.
35 DENIED_QOS_NOT_SUPPORTED Association (with QoS BSS) denied because the
requesting STA does not support the QoS facility.
36 Reserved.
37 REQUEST_DECLINED The request has been declined.
38 INVALID_PARAMETERS The request has not been successful as one or more
parameters have invalid values.
39 REJECTED_WITH_SUGGESTED_ The allocation or TS has not been created because the
CHANGES request cannot be honored; however, a suggested
TSPEC/DMG TSPEC is provided so that the initiating
STA can attempt to set another allocation or TS with the
suggested changes to the TSPEC/DMG TSPEC.
40 STATUS_INVALID_ELEMENT Invalid element, i.e., an element defined in this standard
for which the content does not meet the specifications in
Clause 9.
41 STATUS_INVALID_GROUP_CIPHE Invalid group cipher.
R
42 STATUS_INVALID_PAIRWISE_CIP Invalid pairwise cipher.
HER
43 STATUS_INVALID_AKMP Invalid AKMP.
44 UNSUPPORTED_RSNE_VERSION Unsupported RSNE version.
45 INVALID_RSNE_CAPABILITIES Invalid RSNE capabilities.
46 STATUS_CIPHER_OUT_OF_POLIC Cipher suite rejected because of security policy.
Y
47 REJECTED_FOR_DELAY_PERIOD The TS or allocation has not been created; however, the
HC or PCP might be capable of creating a TS or
allocation, in response to a request, after the time
indicated in the TS Delay element.
48 DLS_NOT_ALLOWED Direct link is not allowed in the BSS by policy.
49 NOT_PRESENT The Destination STA is not present within this BSS.
733
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-46—Status codes (continued)
Status code Name Meaning
50 NOT_QOS_STA The Destination STA is not a QoS STA.
51 DENIED_LISTEN_INTERVAL_TOO Association denied because the listen interval is too
_LARGE large.
52 STATUS_INVALID_FT_ACTION_F Invalid FT Action frame count.
RAME_COUNT
53 STATUS_INVALID_PMKID Invalid pairwise master key identifier (PMKID).
54 STATUS_INVALID_MDE Invalid MDE.
55 STATUS_INVALID_FTE Invalid FTE.
56 REQUESTED_TCLAS_NOT_ Requested TCLAS processing is not supported by the AP
SUPPORTED or PCP.
57 INSUFFICIENT_TCLAS_ The AP or PCP has insufficient TCLAS processing
PROCESSING_RESOURCES resources to satisfy the request.
58 TRY_ANOTHER_BSS The TS has not been created because the request cannot
be honored; however, the HC or PCP suggests that the
STA transition to a different BSS to set up the TS.
59 GAS_ADVERTISEMENT_ GAS Advertisement Protocol not supported.
PROTOCOL_NOT_SUPPORTED
60 NO_OUTSTANDING_GAS_ No outstanding GAS request.
REQUEST
61 GAS_RESPONSE_NOT_ GAS Response not received from the Advertisement
RECEIVED_FROM _SERVER Server.
62 GAS_QUERY_TIMEOUT STA timed out waiting for GAS Query Response.
63 GAS_QUERY_RESPONSE_ GAS Response is larger than query response length limit.
TOO_ LARGE
64 REJECTED_HOME_WITH_ Request refused because home network does not support
SUGGESTED_CHANGES request.
65 SERVER_UNREACHABLE Advertisement Server in the network is not currently
reachable.
66 Reserved.
67 REJECTED_FOR_SSP_ Request refused due to permissions received via SSPN
PERMISSIONS interface.
68 REFUSED_UNAUTHENTICATED_A Request refused because the AP or PCP does not support
CCESS_NOT_SUPPORTED unauthenticated access.
69-71 Reserved.
72 INVALID_RSNE Invalid contents of RSNE.
73 U_APSD_COEXISTANCE_NOT_SU U-APSD coexistence is not supported.
PPORTED
74 U_APSD_COEX_MODE_NOT_SUPP Requested U-APSD coexistence mode is not
ORTED supported.
75 BAD_INTERVAL_WITH_U_APS Requested Interval/Duration value cannot be
D_COEX supported with U-APSD coexistence.
76 ANTI_CLOGGING_TOKEN_REQUI Authentication is rejected because an Anti-Clogging
RED Token is required.
734
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-46—Status codes (continued)
Status code Name Meaning
77 UNSUPPORTED_FINITE_CYCLIC_ Authentication is rejected because the offered finite
GROUP cyclic group is not supported.
78 CANNOT_FIND_ALTERNATIVE_ The TBTT adjustment request has not been successful
TBTT because the STA could not find an alternative TBTT.
79 TRANSMISSION_FAILURE Transmission failure.
80 REQUESTED_TCLAS_NOT_ Requested TCLAS Not Supported.
SUPPORTED
81 TCLAS_RESOURCES_EXHAUSTED TCLAS Resources Exhausted.
82 REJECTED_WITH_SUGGESTED_ Rejected with Suggested BSS transition.
BSS_TRANSITION
83 REJECT_WITH_SCHEDULE Reject with recommended schedule.
84 REJECT_NO_WAKEUP_SPECIFIED Reject because no wakeup schedule specified.
85 SUCCESS_POWER_SAVE_MODE Success, the destination STA is in power save mode.
86 PENDING_ADMITTING_FST_SESSI FST pending, in process of admitting FST session.
ON
87 PERFORMING_FST_NOW Performing FST now.
88 PENDING_GAP_IN_BA_WINDOW FST pending, gap(s) in block ack window.
89 REJECT_U-PID_SETTING Reject because of U-PID setting.
90–91 Reserved.
92 REFUSED_EXTERNAL_REASON (Re)Association refused for some external reason.
93 REFUSED_AP_OUT_OF_MEMORY (Re)Association refused because of memory limits at the
AP.
94 REJECTED_EMERGENCY_ (Re)Association refused because emergency services are
SERVICES_NOT_SUPPORTED not supported at the AP.
95 QUERY_RESPONSE_ GAS query response not yet received.
OUTSTANDING
96 REJECT_DSE_BAND Reject since the request is for transition to a frequency
band subject to DSE procedures and FST Initiator is a
dependent STA.
97 TCLAS_PROCESSING_ Requested TCLAS processing has been terminated by
TERMINATED the AP.
98 TS_SCHEDULE_CONFLICT The TS schedule conflicts with an existing schedule; an
alternative schedule is provided.
99 DENIED_WITH_SUGGESTED_BAN The association has been denied; however, one or more
D_AND_CHANNEL Multi-band elements are included that can be used by the
receiving STA to join the BSS.
100 MCCAOP_RESERVATION_ The request failed due to a reservation conflict.
CONFLICT
101 MAF_LIMIT_EXCEEDED The request failed due to exceeded MAF limit.
102 MCCA_TRACK_LIMIT_EXCEEDED The request failed due to exceeded MCCA track limit.
103 DENIED_DUE_TO_SPECTRUM_MA Association denied because the information in the
NAGEMENT Spectrum Management field is unacceptable.
735
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-46—Status codes (continued)
Status code Name Meaning
104 DENIED_VHT_NOT_SUPPORTED Association denied because the requesting STA does not
support VHT features.
105 ENABLEMENT DENIED Enablement denied.
106 RESTRICTION FROM Enablement denied due to restriction from an authorized
AUTHORIZED GDB GDB.
107 AUTHORIZATION DEENABLED Authorization deenabled.
108–65 535 Reserved.
9.4.1.10 Timestamp field
This field represents the value of the timing synchronization function (TSF) timer (see 11.1 and 11.22) of a
frame’s source. The length of the Timestamp field is 8 octets. The Timestamp field is illustrated in Figure 9-75.
Timestamp
Octets: 8
Figure 9-75—Timestamp field
9.4.1.11 Action field
The Action field provides a mechanism for specifying extended management actions. The format of the
Action field is shown in Figure 9-76.
Category Action Details
Octets: 1 variable
Figure 9-76—Action field
The Category field is set to one of the nonreserved values shown in the “Code” column of Table 9-47.
Action frames of a given category are referred to as Action frames. For example, frames
in the QoS category are called QoS Action frames.
The Action Details field contains the details of the action. The details of the actions allowed in each category
are described in the appropriate subclause referenced in Table 9-47.
Table 9-47—Category values
Group
Code Meaning See subclause Robust addressed
privacy
0 Spectrum Management 9.6.2 Yes No
1 QoS 9.6.3 Yes No
2 DLS 9.6.4 Yes No
736
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-47—Category values (continued)
Group
Code Meaning See subclause Robust addressed
privacy
3 Block Ack 9.6.5 Yes No
4 Public 9.6.8 No No
5 Radio Measurement 9.6.7 See No
NOTE 1
6 Fast BSS Transition 9.6.9 Yes No
7 HT 9.6.12 No No
8 SA Query 9.6.10 Yes No
9 Protected Dual of Public 9.6.11 Yes No
Action
10 WNM 9.6.14 Yes No
11 Unprotected WNM 9.6.15 No No
12 TDLS 9.6.13 — No
See
NOTE 2
13 Mesh 9.6.17 Yes Yes
14 Multihop 9.6.18 Yes Yes
15 Self-protected 9.6.16 No No
16 DMG 9.6.20 Yes No
17 Reserved (used by the Wi- — — —
Fi Alliance® a)
18 Fast Session Transfer 9.6.21 Yes No
19 Robust AV Streaming 9.6.19 Yes No
20 Unprotected DMG 9.6.22 No No
21 VHT 9.6.23 No No
21–125 Reserved — — —
126 Vendor-specific Protected 9.6.6 Yes No
127 Vendor-specific 9.6.6 No No
128–255 Error — — —
NOTE 1—Radio Measurement frames are robust, except for Link Measurement Request
and Link Measurement Report frames in a DMG BSS.
NOTE 2—TDLS Action fields are always transported encapsulated within a Data frame
(see 11.23.1), so the question of whether these frames are robust is not applicable.
a
See http://www.wi-fi.org.
737
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.1.12 Dialog Token field
The Dialog Token field is used for matching action responses with action requests when there are multiple,
concurrent action requests. The length of the Dialog Token field is 1 octet. The Dialog Token field is
illustrated in Figure 9-77. See 10.27.5.
Dialog Token
Octets: 1
Figure 9-77—Dialog Token fixed field
9.4.1.13 DLS Timeout Value field
The DLS Timeout Value field is used in the DLS Request frame to indicate the timeout value for the direct
link. The length of the DLS Timeout Value field is 2 octets. The DLS Timeout Value field is illustrated in
Figure 9-78. See 11.7.2.4.
DLS Timeout Value
Octets: 2
Figure 9-78—DLS Timeout Value fixed field
9.4.1.14 Block Ack Parameter Set field
The Block Ack Parameter Set field is used in ADDBA Request and ADDBA Response frames to signal the
parameters for setting up a Block Ack. The length of the Block Ack Parameter Set field is 2 octets. The
Block Ack Parameter Set field is illustrated in Figure 9-79.
B0 B1 B2 B5 B6 B15
A-MSDU Block Ack Policy TID Buffer Size
Supported
Bits: 1 1 4 10
Figure 9-79—Block Ack Parameter Set fixed field
The A-MSDU Supported subfield is set to 1 by a STA to indicate that it supports an A-MSDU carried in a
QoS Data frame sent under this block ack agreement. It is set to 0 otherwise.
The Block Ack Policy subfield is set to 1 for Immediate Block Ack and 0 for Delayed Block Ack.
The TID subfield contains the value of the TC or TS for which the BlockAck frame is being requested.
The Buffer Size subfield indicates the number of buffers available for this particular TID.22 When the
A-MSDU Supported field is equal to 0 as indicated by the STA transmitting the Block Ack Parameter Set
field, each buffer is capable of holding a number of octets equal to the maximum size of an MSDU. When
the A-MSDU Supported field is equal to 1 as indicated by the STA, each buffer is capable of holding a
number of octets equal to the maximum size of an A-MSDU that is supported by the STA.
22
For buffer size, the recipient of data advertises a single scalar number that is the number of fragment buffers of the maximum MSDU
or A-MSDU size (indicated by the A-MSDU Supported field) available for the block ack agreement that is being negotiated. Every
buffered MPDU that is associated with this block ack agreement consumes one of these buffers regardless of whether the frame
contains a whole MSDU (or a fragment thereof) or an A-MSDU. For example, ten maximum-size unfragmented MSDUs consumes the
same amount of buffer space at the recipient as ten smaller fragments of a single MSDU of maximum size.
738
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In an ADDBA Request frame, the Buffer Size subfield provides guidance for the frame receiver to decide its
reordering buffer size. If the Buffer Size subfield is equal to 0, it implies that the originator of the block ack
has no information to specify its value.
In an ADDBA Response frame, when the Status Code field is equal to SUCCESS, the Buffer Size subfield is
set to a value of at least 1.
9.4.1.15 Block Ack Timeout Value field
The Block Ack Timeout Value field is used in the ADDBA Request and Response frames to indicate the
timeout value for Block Ack. The length of the Block Ack Timeout Value field is 2 octets. The Block Ack
Timeout Value field is illustrated in Figure 9-80.
Block Ack Timeout Value
Octets: 2
Figure 9-80—Block Ack Timeout Value fixed field
The Block Ack Timeout Value field contains the duration, in TUs, after which the block ack setup is
terminated, if there are no frame exchanges (see 11.5.4) within this duration using this block ack agreement.
A value of 0 disables the timeout.
9.4.1.16 DELBA Parameter Set field
The DELBA Parameter Set field is used in a DELBA frame to terminate an already set up Block Ack. The
length of the DELBA Parameter Set field is 2 octets. The DELBA Parameter Set field is illustrated in
Figure 9-81.
B0 B10 B11 B12 B15
Reserved Initiator TID
Bits: 11 1 4
Figure 9-81—DELBA Parameter Set field
The Initiator subfield indicates if the originator or the recipient of the data is sending this frame. It is set to 1
to indicate the originator and is set to 0 to indicate the recipient. The TID subfield indicates the TSID or the
UP for which the block ack has been originally set up.
9.4.1.17 QoS Info field
The QoS Info field is 1 octet in length and contains capability information bits. The contents of the field are
dependent on whether the STA is contained within an AP.
The format of the QoS Info field, when sent by the AP, is defined in Figure 9-82.
B0 B3 B4 B5 B6 B7
EDCA Parameter Q-Ack Queue Request TXOP Request Reserved
Set Update Count
Bits: 4 1 1 1 1
Figure 9-82—QoS Info field when sent by an AP
739
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The EDCA Parameter Set Update Count subfield is described in 10.2.4.2.
APs set the Q-Ack subfield to 1 when dot11QAckOptionImplemented is true and set it to 0 otherwise.
APs set the Queue Request subfield to 1 if they can process a nonzero Queue Size subfield in the QoS
Control field in QoS Data frames and set it to 0 otherwise.
APs set the TXOP Request subfield to 1 if they can process a nonzero TXOP Duration Requested subfield in
the QoS Control field in QoS Data frames and set it to 0 otherwise.
The format of the QoS Info field, when sent by the non-AP STA, is defined in Figure 9-83.
B0 B1 B2 B3 B4 B5 B6 B7
AC_VO AC_VI AC_BK AC_BE Q-Ack Max SP More Data
U-APSD U-APSD U-APSD U-APSD Length Ack
Flag Flag Flag Flag
Bits: 1 1 1 1 1 1 1
Figure 9-83—QoS Info field when set by a non-AP STA
Each of the ACs U-APSD Flag subfields is 1 bit in length and set to 1 in (Re)Association Request frames to
indicate that the corresponding AC (AC_BE, AC_BK, AC_VI, or AC_VO) is both trigger-enabled and
delivery-enabled. It is set to 0 in (Re)Association Request frames to indicate that the corresponding AC is
neither trigger-enabled nor delivery-enabled. A TSPEC as described in 11.2.3.5 is to be used to make a
particular AC exclusively either trigger-enabled or delivery-enabled. These subfields are set to 0 when the
APSD subfield in the Capability Information field received from the AP with which the non-AP STA is
associating is equal to 0.
Non-AP STAs set the Q-Ack subfield to 1 when dot11QAckOptionImplemented is true and set it to 0
otherwise.
The Max SP Length subfield is 2 bits in length and indicates the maximum number of buffered BUs the STA
is prepared to receive during any SP triggered by the STA. This subfield is reserved when the APSD
subfield in the Capability Information field is equal to 0. If the APSD subfield in the Capability Information
field is equal to 1, the settings of the values in the Max SP Length subfield are defined in Table 9-48.
Table 9-48—Settings of the Max SP Length subfield
Bit 5 Bit 6 Usage
0 0 The STA is prepared to receive all buffered BUs.
1 0 The STA is prepared to receive a maximum of two BUs per SP.
0 1 The STA is prepared to receive a maximum of four BUs per SP.
1 1 The STA is prepared to receive a maximum of six BUs per SP.
Non-AP STAs set the More Data Ack subfield to 1 to indicate that they can process Ack frames with the
More Data bit in the Frame Control field equal to 1 and remain in the awake state. Non-AP STAs set the
More Data Ack subfield to 0 otherwise. For APs, the More Data Ack subfield is reserved.
740
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.1.18 Measurement Pilot Interval field
The Measurement Pilot Interval field represents the number of time units (TUs) between target measurement
pilot transmission times (TMPTTs). The length of the Measurement Pilot Interval field is 1 octet. The Mea-
surement Pilot Interval field is illustrated in Figure 9-84.
B0 B7
Measurement Pilot Interval
Octets: 1
Figure 9-84—Measurement Pilot Interval fixed field
9.4.1.19 Max Transmit Power field
The Max Transmit Power field is a 2s complement signed integer and is 1 octet in length, providing an upper
limit, in units of dBm, on the transmit power as measured at the output of the antenna connector to be used
by that AP on the current channel. See 11.11.13. The Max Transmit Power field is illustrated in Figure 9-85.
B0 B7
Max Transmit Power
Octets: 1
Figure 9-85—Max Transmit Power field
9.4.1.20 Transmit Power Used field
The Transmit Power Used field is a 2s complement signed integer and is 1 octet in length. It is less than or
equal to the Max Transmit Power and indicates the actual power used as measured at the output of the
antenna connector, in units of dBm, by a STA when transmitting the frame containing the Transmit Power
Used field. The Transmit Power Used value is determined any time prior to sending the frame in which it is
contained and has a tolerance of ±5 dB. The Transmit Power Used field is illustrated in Figure 9-86.
B0 B7
Transmit Power Used
Octets: 1
Figure 9-86—Transmit Power Used field
9.4.1.21 Channel Width field
The Channel Width field is used in a Notify Channel Width frame (see 9.6.12.2) to indicate the channel
width on which the sending STA is able to receive. The length of the field is 1 octet. The Channel Width
field is illustrated in Figure 9-87.
Channel Width
Octets: 1
Figure 9-87—Channel Width fixed field
741
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If a STA transmitting or receiving this field is operating in an operating class that includes a value of
PrimaryChannelLowerBehavior or PrimaryChannelUpperBehavior in the behavior limits set as specified in
Annex E, then the values of the Channel Width field are defined in Table 9-49. If a STA transmitting or
receiving this field is operating in an operating class that does not include a value of
PrimaryChannelLowerBehavior or PrimaryChannelUpperBehavior in the behavior limits set as specified in
Annex E, then this field is reserved.
Table 9-49—Settings of the Channel Width field
Value Meaning
0 20 MHz channel width
1 Any channel width in the STA’s Supported Channel Width Set subfield
2–255 Reserved
9.4.1.22 Operating Class and Channel field
The Operating Class and Channel field is used in the Location Indication Channels subelement of the
Location Parameters element and in the Channel Usage element. The Operating Class and Channel field
indicates an operating class and channel. The format of the field is defined in Figure 9-88.
Operating Class Channel
Octets: 1 1
Figure 9-88—Operating Class and Channel field
The Operating Class field indicates an operating class value as defined in Annex E. The operating class is
interpreted in the context of the country specified in the Beacon frame.
The Channel field indicates a channel number, which is interpreted in the context of the indicated operating
class. Channel numbers are defined in Annex E.
9.4.1.23 SM Power Control field
The SM Power Control field is used in an SM Power Save frame (see 9.6.12.3) by a STA to communicate
changes in its SM power-saving state. The field is 1 octet in length and is illustrated in Figure 9-89.
B0 B1 B2 B7
SM Power Save Enabled SM Mode Reserved
Bits: 1 1 6
Figure 9-89—SM Power Control fixed field
The SM Power Save Enabled subfield indicates whether SM power saving is enabled at the STA. A value of
1 indicates enabled, and a value of 0 indicates disabled.
742
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SM Mode subfield indicates the mode of operation. A value of 1 indicates dynamic SM power save
mode, a value of 0 indicates static SM power save mode. The modes are described in 11.2.6.
9.4.1.24 PCO Phase Control field
The PCO Phase Control field is used in a Set PCO Phase frame (see 9.6.12.5) to indicate the phase of PCO
operation (see 11.17). The length of the field is 1 octet. The PCO Phase Control field is illustrated in
Figure 9-90.
PCO Phase Control
Octets: 1
Figure 9-90—PCO Phase Control fixed field
The PCO Phase Control field indicates the current PCO phase. The values of the PCO Phase Control field
are defined in Table 9-50.
Table 9-50—Settings of the PCO Phase Control field
Value Meaning
0 20 MHz phase
1 40 MHz phase
2–255 Reserved
9.4.1.25 PSMP Parameter Set field
The PSMP Parameter Set field is used in a PSMP frame (see 9.6.12.4) to define the number of PSMP STA
Info fields held in the PSMP frame, to indicate whether the PSMP sequence is to be followed by another
PSMP sequence, and to indicate the duration of the PSMP sequence.
The PSMP Parameter Set field is 2 octets in length. The structure of the PSMP Parameter Set field is defined
in Figure 9-91.
B0 B4 B5 B6 B15
N_STA More PSMP PSMP Sequence Duration
Bits: 5 6 10
Figure 9-91—PSMP Parameter Set fixed field
The N_STA subfield indicates the number of STA Info fields present in the PSMP frame that contains the
PSMP Parameter Set field.
The More PSMP subfield, when set to 1, indicates that the current PSMP sequence will be followed by
another PSMP sequence. A value of 0 indicates that there will be no PSMP sequence following the current
PSMP sequence.
743
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PSMP Sequence Duration subfield indicates the duration of the current PSMP sequence that is
described by the PSMP frame, in units of 8 µs, relative to the end of the PSMP frame. Therefore, this field
can describe a PSMP sequence with a duration of up to 8.184 ms. The next PSMP sequence within the
current PSMP burst starts a SIFS after the indicated duration.
9.4.1.26 PSMP STA Info field
The PSMP STA Info field is used by the PSMP frame (see 9.6.12.4). The PSMP STA Info field defines the
allocation of time to the downlink (PSMP-DTT) and/or uplink (PSMP-UTT) associated with a single RA.
There are two variants of the structure for the individually addressed and group addressed cases. The length
of the PSMP STA Info field is 8 octets.
The structure of the STA Info field is defined in Figure 9-92 and Figure 9-93.
B0 B1 B2 B12 B13 B20 B21 B63
STA_INFO PSMP-DTT PSMP-DTT PSMP Group
Type
(=1) Start Offset Duration Address ID
Bits: 2 11 8 43
Figure 9-92—PSMP STA Info fixed field (group addressed)
B0 B1 B2 B12 B13 B20 B21 B36 B37 B47 B48 B57 B58 B63
STA_INFO
PSMP-DTT PSMP-DTT PSMP-UTT PSMP-UTT
Type Start Offset Duration STA_ID Start Offset Duration Reserved
(=2)
Bits: 2 11 8 16 11 10 6
Figure 9-93—PSMP STA Info fixed field (individually addressed)
The STA_INFO Type subfield indicates the format of the remainder of the structure. When the STA_INFO
Type subfield is equal to 1, the PSMP STA Info field is structured as defined in Figure 9-92 and supports the
transmission of group addressed data by the AP. When the STA_INFO Type subfield is equal to 2, the
PSMP STA Info field is structured as defined in Figure 9-93 and supports the exchange of data with a single
STA. STA_INFO Type subfield values 0 and 3 are reserved.
The PSMP-DTT Start Offset subfield indicates the start of the PSMP-DTT for the destination identified by
the PSMP STA Info field, relative to the end of the PSMP frame, in units of 4 µs. This subfield locates the
start of the first PPDU containing downlink data for this destination.
The PSMP-DTT Duration subfield indicates the duration of the PSMP-DTT for the destination identified by
the PSMP STA Info field, in units of 16 µs. This subfield locates the end of the last PPDU containing
downlink data for this destination relative to the PDMP-DTT start offset.
If no PSMP-DTT is scheduled for a STA, but a PSMP-UTT is scheduled for that STA, the PSMP-DTT
Duration subfield is set to 0, and the PSMP-DTT Start Offset subfield is reserved.
The PSMP Group Address ID (B21 to B63) subfield contains the 43 least significant bits (LSBs) of a 48 bit
MAC address. Use of this subfield is described in 10.29.2.8. B63 contains the LSB of the group address
(considering the Individual/Group bit to be the most significant bit (MSB)).
The STA_ID subfield contains the AID of the STA to which the PSMP STA Info field is directed.
744
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PSMP-UTT Start Offset subfield indicates the start of the PSMP-UTT. The offset is specified relative to
the end of the PSMP frame. It is specified in units of 4 µs. The first PSMP-UTT is scheduled to begin after a
SIFS from the end of the last PSMP-DTT described in the PSMP.
The PSMP-UTT Duration subfield indicates the maximum length of a PSMP-UTT for a STA. PSMP-UTT
duration is specified in units of 4 µs. All transmissions by the STA within the current PSMP sequence lie
within the indicated PSMP-UTT.
If no PSMP-UTT is scheduled for a STA, but a PSMP-DTT is scheduled for that STA, the PSMP-UTT Start
Offset and PSMP-UTT Duration subfields are both set to 0.
9.4.1.27 MIMO Control field
The MIMO Control field is used to manage the exchange of MIMO channel state or transmit beamforming
feedback information. It is used in the CSI (see 9.6.12.6), Noncompressed Beamforming (see 9.6.12.7), and
Compressed Beamforming (see 9.6.12.8) frames.
The MIMO Control field is 6 octets in length and is defined in Figure 9-94.
B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B13 B14 B15 B16 B47
MIMO
Remaining
Nc Nr Control Grouping Coefficient Codebook Matrix Reserved Sounding
Index Index Channel (Ng) Size Information Timestamp
Width Segment
Bits: 2 2 1 2 2 2 3 2 32
Figure 9-94—MIMO Control field
The subfields of the MIMO Control field are defined in Table 9-51.
Table 9-51—Subfields of the MIMO Control field
Subfield Description
Nc Index Indicates the number of columns in a matrix minus one:
Set to 0 for Nc = 1
Set to 1 for Nc = 2
Set to 2 for Nc = 3
Set to 3 for Nc = 4
Nr Index Indicates the number of rows in a matrix minus one:
Set to 0 for Nr = 1
Set to 1 for Nr = 2
Set to 2 for Nr = 3
Set to 3 for Nr = 4
MIMO Control Channel Indicates the width of the channel in which a measurement was made:
Width Set to 0 for 20 MHz
Set to 1 for 40 MHz
Grouping (Ng) Number of carriers grouped into one:
Set to 0 for Ng = 1 (No grouping)
Set to 1 for Ng = 2
Set to 2 for Ng = 4
The value 3 is reserved
745
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-51—Subfields of the MIMO Control field (continued)
Subfield Description
Coefficient Size Indicates the number of bits in the representation of the real and imaginary parts of
each element in the matrix.
For CSI feedback:
Set to 0 for Nb = 4
Set to 1 for Nb = 5
Set to 2 for Nb = 6
Set to 3 for Nb = 8
For noncompressed beamforming feedback:
Set 0 for Nb = 4
Set 1 for Nb = 2
Set 2 for Nb = 6
Set 3 for Nb = 8
Codebook Information Indicates the size of codebook entries:
Set to 0 for 1 bit for , 3 bits for
Set to 1 for 2 bits for , 4 bits for
Set to 2 for 3 bits for , 5 bits for
Set to 3 for 4 bits for , 6 bits for
Remaining Matrix Segment Contains the remaining segment number for the associated measurement report.
Valid range: 0 to 7.
Set to 0 for the last segment of a segmented report or the only segment of an
unsegmented report.
Sounding Timestamp Contains the lower 4 octets of the TSF timer value sampled at the instant that the
MAC received the PHY-CCA.indication(IDLE) primitive that corresponds to the
end of the reception of the sounding packet that was used to generate feedback
information contained in the frame.
9.4.1.28 CSI Report field
The CSI Report field is used by the CSI frame (see 9.6.12.6) to carry explicit channel state information to a
transmit HT beamformer, as described in 10.32.3.
The CSI Matrix subfields in the CSI Report field shown in Table 9-52 and Table 9-53 are matrices whose
elements are taken from the CHAN_MAT parameter of RXVECTOR (see Table 19-1).
Table 9-52—CSI Report field (20 MHz)
Size
Field Meaning
(bits)
SNR in receive chain 1 8 Signal-to-noise ratio in the first receive chain
of the STA sending the report.
...
SNR in receive chain Nr 8 Signal-to-noise ratio in the Nr’th receive
chain of the STA sending the report.
CSI Matrix for carrier –28 3+2× Nb×Nc×Nr CSI matrix (see Figure 9-95)
...
746
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-52—CSI Report field (20 MHz) (continued)
Size
Field Meaning
(bits)
CSI Matrix for carrier –1 3+2× Nb×Nc×Nr CSI matrix
CSI Matrix for carrier 1 3+2× Nb×Nc×Nr CSI matrix
...
CSI Matrix for carrier 28 3+2× Nb×Nc×Nr CSI matrix
The structure of the field depends on the value of the MIMO Control Channel Width subfield. The CSI
Report field for 20 MHz has the structure defined in Table 9-52 where
Nb is the number of bits determined by the Coefficients Size field of the MIMO Control field
Nc is the number of columns in a CSI matrix determined by the Nc Index field of the MIMO Control
field
Nr is the number of rows in a CSI matrix determined by the Nr Index field of the MIMO Control field
The CSI Report field for 40 MHz has the structure defined in Table 9-53.
Table 9-53—CSI Report field (40 MHz)
Size
Field Meaning
(bits)
SNR in receive chain 1 8 Signal-to-noise ratio in the first receive chain of
the STA sending the report.
...
SNR in receive chain Nr 8 Signal-to-noise ratio in the Nr’th receive chain
of the STA sending the report.
CSI Matrix for carrier –58 3+2× Nb×Nc×Nr CSI matrix (see Figure 9-95)
...
CSI Matrix for carrier –2 3+2× Nb×Nc×Nr CSI matrix
CSI Matrix for carrier 2 3+2× Nb×Nc×Nr CSI matrix
...
CSI Matrix for carrier 58 3+2× Nb×Nc×Nr CSI matrix
The signal-to-noise ratio (SNR) values in Table 9-52 and Table 9-53 are encoded as an 8-bit 2s complement
value of 4 × (SNR_average – 22), where SNR_average is the decibel representation of linearly averaged
values over the tones represented. This encoding covers the SNR range from –10 dB to 53.75 dB in 0.25 dB
steps.
Grouping is a method that reduces the size of the CSI Report field by reporting a single value for each group
of Ng adjacent subcarriers. With grouping, the size of the CSI Report field is Nr 8+Ns (3+2 Nb Nc Nr)
bits, where the number of subcarriers sent, Ns, is a function of Ng and whether matrices for 40 MHz
or 20 MHz are sent. The value of Ns and the specific carriers for which matrices are sent are shown in
Table 9-54. If the size of the CSI Report field is not an integer multiple of 8 bits, up to 7 0s are appended to
the end of the report to make its size an integer multiple of 8 bits.
747
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-54—Number of matrices and carrier grouping
Grouping
BW Ns Carriers for which matrices are sent
Ng
1 56 All data and pilot carriers: –28, –27,…–2, –1, 1, 2,…27, 28
–28,–26,–24,–22,–20,–18,–16,–14,–12,–10,–8,–6,–4,–2,–1,
20 MHz 2 30
1,3,5,7,9,11,13,15,17,19,21,23,25,27,28
4 16 –28,–24,–20,–16,–12,–8,–4,–1,1,5,9,13,17,21,25,28
1 114 All data and pilot carriers: –58, –57, …, –3, –2, 2, 3,…, 57, 58
–58,–56,–54,–52,–50,–48,–46,–44,–42,–40,–38,–36,–34,–32,–30,
–28,–26,–24,–22,–20,–18,–16,–14,–12,–10,–8,–6,–4,–2,
2 58
40 MHz 2,4,6,8,10,12,14,16,18,20,22,24,26,28,
30,32,34,36,38,40,42,44,46,48,50,52,54,56,58
–58,–54,–50,–46,–42,–38,–34,–30,–26,–22,–18,–14,–10,–6, –2,
4 30
2,6,10,14,18,22,26,30,34,38,42,46,50,54,58
The CSI matrix Heff for a single carrier has the structure defined in Figure 9-95. The encoding rules for the
elements of the Heff matrix are given in 19.3.12.3.2.
For each subcarrier include
{
Carrier Matrix Amplitude of 3 bits
For each of Nr rows in each CSI matrix in order: (1, …, Nr)
{
Include Nc complex coefficients of CSI matrix Heff in order: (1, …, Nc);
each element of Heff includes the real part of the element (Nb bits) and
imaginary part of the element (Nb bits) in that order
}
}
Figure 9-95—CSI matrix coding
When operating with a 40 MHz channel width, CSI feedback with a bandwidth of 20 MHz corresponds to
the tones in the primary 20 MHz channel.
9.4.1.29 Noncompressed Beamforming Report field
The Noncompressed Beamforming Report field is used by the Noncompressed Beamforming frame to carry
explicit feedback in the form of noncompressed beamforming feedback matrices V for use by a transmit HT
beamformer to determine steering matrices Q, as described in 10.32.3 and 19.3.12.3.
The structure of the field is dependent on the value of the MIMO Control Channel Width subfield. The
Noncompressed Beamforming Report field for 20 MHz has the structure defined in Table 9-55 where
Nb is the number of bits determined by the Coefficients Size field of the MIMO Control field
Nc is the number of columns in a beamforming feedback matrix determined by the Nc Index field of
the MIMO Control field
Nr is the number of rows in a beamforming feedback matrix determined by the Nr Index field of the
MIMO Control field
748
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-55—Noncompressed Beamforming Report field (20 MHz)
Size
Field Meaning
(bits)
SNR for space-time stream 1 8 Average signal-to-noise ratio in the STA
sending the report for space-time stream 1.
...
SNR for space-time stream Nc 8 Average signal-to-noise ratio in the STA
sending the report for space-time stream Nc.
Beamforming Feedback Matrix for carrier –28 2× Nb×Nc×Nr Beamforming feedback matrix V
(see Figure 9-96)
...
Beamforming Feedback Matrix for carrier –1 2× Nb×Nc×Nr Beamforming feedback matrix V
Beamforming Feedback Matrix for carrier 1 2× Nb×Nc×Nr Beamforming feedback matrix V
...
Beamforming Feedback Matrix for carrier 28 2× Nb×Nc×Nr Beamforming feedback matrix V
The Noncompressed Beamforming Report field for 40 MHz has the structure defined in Table 9-56.
Table 9-56—Noncompressed Beamforming Report field (40 MHz)
Size
Field Meaning
(bits)
SNR for space-time stream 1 8 Average signal-to-noise ratio in the STA
sending the report for space-time stream 1.
...
SNR for space-time stream Nc 8 Average signal-to-noise ratio in the STA
sending the report for space-time stream Nc.
Beamforming Feedback Matrix for carrier –58 2× Nb×Nc×Nr Beamforming feedback matrix V
(see Figure 9-96)
...
Beamforming Feedback Matrix for carrier –2 2× Nb×Nc×Nr Beamforming feedback matrix V
Beamforming Feedback Matrix for carrier 2 2× Nb×Nc×Nr Beamforming feedback matrix V
...
Beamforming Feedback Matrix for carrier 58 +2× Nb×Nc×Nr Beamforming feedback matrix V
The SNR values in Table 9-55 and Table 9-56 are encoded as an 8-bit 2s complement value of 4 ×
(SNR_average – 22), where SNR_average is the sum of the values of SNR per tone (in decibels) divided by
the number of tones represented. This encoding covers the SNR range from –10 dB to 53.75 dB in 0.25 dB
steps. The SNR in space-time stream i corresponds to the SNR associated with the column i of the
beamforming feedback matrix V. Each SNR corresponds to the predicted SNR at the HT beamformee when
the HT beamformer applies the matrix V.
749
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Grouping is a method that reduces the size of the Noncompressed Beamforming Report field by reporting a
single value for each group of Ng adjacent subcarriers. With grouping, the size of the Noncompressed
Beamforming Report field is Nc +Ns (2 Nb Nc Nr) bits. The number of subcarriers sent, Ns, is a
function of Ng and whether matrices for 40 MHz or 20 MHz are sent. The value of Ns and the specific
carriers for which matrices are sent is shown in Table 9-54. If the size of the Noncompressed Beamforming
Report field is not an integer multiple of 8 bits, up to 7 0s are appended to the end of the report to make its
size an integer multiple of 8 bits.
A beamforming feedback matrix V for a single carrier has the structure defined in Figure 9-96.
For each subcarrier include
{
For each of Nr rows in the
Noncompressed beamforming feedback matrix in order: (1, …, Nr)
{
Include Nc complex coefficients of the Noncompressed beamforming feedback
matrix V in order: (1, …, Nc ); each element of V includes the real
part of the element (Nb bits) and imaginary part of the element (Nb bits)
in that order
}
}
Figure 9-96—V matrix coding (noncompressed beamforming)
Encoding rules for elements of the V matrix are given in 19.3.12.3.5.
When operating with a 40 MHz channel width, noncompressed feedback with a bandwidth of 20 MHz
corresponds to the tones in the primary 20 MHz channel.
9.4.1.30 Compressed Beamforming Report field
The Compressed Beamforming Report field is used by the Compressed Beamforming frame (see 9.6.12.8)
to carry explicit feedback information in the form of angles representing compressed beamforming feedback
matrices V for use by a transmit HT beamformer to determine steering matrices Q, as described in 10.32.3
and 19.3.12.3.
The size of the Compressed Beamforming Report field depends on the values in the MIMO Control field.
The Compressed Beamforming Report field contains the channel matrix elements indexed, first, by matrix
angles in the order shown in Table 9-57 and, second, by data subcarrier index from lowest frequency to
highest frequency. The explanation on how these angles are generated from the beamforming feedback
matrix V is given in 19.3.12.3.6.
Table 9-57—Order of angles in the Compressed Beamforming Report field
Size of V Number of angles The order of angles in the Quantized Beamforming Feedback
(Nr × Nc) (Na) Matrices Information field
2×1 2 11, 21
2×2 2 11, 21
3×1 4 11, 21, 21, 31
750
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-57—Order of angles in the Compressed Beamforming Report field (continued)
Size of V Number of angles The order of angles in the Quantized Beamforming Feedback
(Nr × Nc) (Na) Matrices Information field
3×2 6 11, 21, 21, 31, 22, 32
3×3 6 11, 21, 21, 31, 22, 32
4×1 6 11, 21, 31, 21, 31, 41
4×2 10 11, 21, 31, 21, 31, 41, 22, 32, 32, 42
4×3 12 11, 21, 31, 21, 31, 41, 22, 32, 32, 42, 33, 43
4×4 12 11, 21, 31, 21, 31, 41, 22, 32, 32, 42, 33, 43
The angles are quantized as defined in Table 9-58. All angles are transmitted LSB to MSB.
Table 9-58—Quantization of angles
Quantized Quantized
k - + -------------- radians k - + -------
= ------------- = ------------
b +1 b +2 b –1 b radians
2 2 2 2
where where
b b
k = 0 1 2 –1 k = 0 1 2 –1
b is the number of bits used to quantize b is the number of bits used to quantize
(defined by the Codebook Information field of (defined by the Codebook Information field of
the MIMO Control field; see 9.4.1.27); the MIMO Control field; see 9.4.1.27)
The Compressed Beamforming Report field for 20 MHz has the structure defined in Table 9-59, where Na is
the number of angles used for beamforming feedback matrix V (see Table 9-57).
Table 9-59—Compressed Beamforming Report field (20 MHz)
Size
Field Meaning
(bits)
SNR in space-time stream 1 8 Average signal-to-noise ratio in the STA
sending the report for space-time stream 1
...
SNR in space-time stream Nc 8 Average signal-to-noise ratio in the STA
sending the report for space-time stream Nc
Beamforming Feedback Matrix V for carrier –28 Na×(b +b )/2 Beamforming feedback matrix V
...
Beamforming Feedback Matrix V for carrier –1 Na×(b +b )/2 Beamforming feedback matrix V
751
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-59—Compressed Beamforming Report field (20 MHz) (continued)
Size
Field Meaning
(bits)
Beamforming Feedback Matrix V for carrier 1 Na×(b +b )/2 Beamforming feedback matrix V
...
Beamforming Feedback Matrix V for carrier 28 Na×(b +b )/2 Beamforming feedback matrix V
The Compressed Beamforming Report field for 40 MHz has the structure defined in Table 9-60, where Na is
the number of angles used for beamforming feedback matrix V (see Table 9-57).
Table 9-60—Compressed Beamforming Report field (40 MHz)
Size
Field Meaning
(bit)
SNR in space-time stream 1 8 Average signal-to-noise ratio in the STA
sending the report for space-time stream 1
...
SNR in space-time stream Nc 8 Average signal-to-noise ratio in the STA
sending the report for space-time stream Nc
Beamforming Feedback Matrix V for carrier –58 Na×(b +b )/2 Beamforming feedback matrix V
Beamforming Feedback Matrix V for Na×(b +b )/2 Beamforming feedback matrix V
carrier –58 + Ng
...
Beamforming Feedback Matrix V for carrier –2 Na×(b +b )/2 Beamforming feedback matrix V
Beamforming Feedback Matrix V for carrier 2 Na×(b +b )/2 Beamforming feedback matrix V
Beamforming Feedback Matrix V for Na×(b +b )/2 Beamforming feedback matrix V
carrier 2 + Ng
...
Beamforming Feedback Matrix V for carrier 58 Na×(b +b )/2 Beamforming feedback matrix V
The SNR values in Table 9-59 and Table 9-60 are encoded as an 8-bit 2s complement value of 4 ×
(SNR_average – 22), where SNR_average is the sum of the values of SNR per tone (in decibels) divided by
the number of tones represented. This encoding covers the SNR range from –10 dB to 53.75 dB in 0.25 dB
steps. Each SNR value per tone in stream i (before being averaged) corresponds to the SNR associated with
the column i of the beamforming feedback matrix V determined at the HT beamformee. Each SNR
corresponds to the predicted SNR at the HT beamformee when the HT beamformer applies the matrix V.
Grouping is a method that reduces the size of the Compressed Beamforming Report field by reporting a
single value for each group of Ng adjacent subcarriers. With grouping, the size of the Compressed
Beamforming Report field is Nc×8+Ns×(Na×(b +b )/2) bits, where the number of subcarriers sent, Ns, is
a function of Ng and whether matrices for 40 MHz or 20 MHz are sent. The value of Ns and the specific
carriers for which matrices are sent is defined in Table 9-54. If the size of the Compressed Beamforming
Report field is not an integer multiple of 8 bits, up to 7 0s are appended to the end of the report to make its
size an integer multiple of 8 bits.
752
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
See Figure 9-97 and Figure 9-98 for examples of this encoding.
Bits b1..b5 b6..b8 b9..b13 b14..b16 … b441..b445 b446..b448
Data 11(–28) 21(–28) 11(–27) 21(–27) … 11(28) 21(28)
Conditions:
— 2×2V
— b = 3, b = 5
— No grouping
— 20 MHz width
— The matrix V is encoded using 8 bits per tone.
Figure 9-97—First example of Compressed Beamforming Report field encoding
Bits b1..b4 b5..b8 … b27..b28 b29..b30 b31..b34 … b59..b60 … b871..b874 … b899..b900
Data 11(–58) 21(–58) … 32(–58) 42(–58) 11(–54) … 42(–54) … 11(58) … 42(58)
Conditions:
— 4×2V
— b = 2, b = 4
— 4 tone grouping
— 40 MHz width
— The matrix V is encoded using 30 bits per tone.
Figure 9-98—Second example of Compressed Beamforming Report field encoding
When operating with a 40 MHz channel width, compressed feedback with a bandwidth of 20 MHz
corresponds to the tones in the primary 20 MHz channel.
9.4.1.31 Antenna Selection Indices field
The Antenna Selection Indices field is used within the Antenna Selection Indices Feedback frame to carry
ASEL feedback, as described in 10.33.
The Antenna Selection Indices field is 1 octet in length and illustrated in Figure 9-99.
Antenna Selection Indices
Octets: 1
Figure 9-99—Antenna Selection Indices fixed field
Bits 0 to 7 in the Antenna Selection Indices field correspond to antennas with indices 0 to 7, respectively. A
value of 1 in a bit indicates the corresponding antenna is selected, and the value of 0 indicates the
corresponding antenna is not selected.
9.4.1.32 Organization Identifier field
The Organization Identifier field contains a public unique identifier assigned by the IEEE. The order of the
Organization Identifier field is described in 9.2.2. The IEEE has assigned organizationally unique identifiers
753
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
both of 24-bit length (OUI and CID) and longer length. In the latter case specific OUI values are shared over
multiple organizations, e.g., using 36-bit length identifiers (OUI-36) (see IEEE Registration Authority
[B19], [B20]). The length of the Organization Identifier field (j) is the minimum number of octets required
to contain the entire organizationally unique identifier (see Figure 9-100), and the first 3 octets contain the
OUI or CID portion of the identifier. Thus, the Organization Identifier field is 3 octets in length if the
organizationally unique identifier is an OUI, or 5 octets in length if the organizationally unique identifier is
an OUI-36.
Organization Identifier
Octets: j
Figure 9-100—Organization Identifier field
If the length of the organizationally unique identifier is not an integer number of octets, the least significant
bits of the last octet are specified by the organization identified.
NOTE—For example, for the organizationally unique identifier 0x0050C24A4, the Organization Identifier field would
contain 0x0050C24A4y where y represents the four least significant bits of the fifth octet of the field. The value of y is
specified by the organization whose identifier is 0x0050C24A4.
9.4.1.33 Rate Identification field
The Rate Identification field is 4 octets in length and contains the rate identification information for a frame
that is not the current frame transmitted or received by a STA. This information allows services to exchange
frame rate information prior to use of the frames that use the rate specified by the Rate Identification field.
The contents of the field is defined in Figure 9-101.
Mask MCS Index Rate
Octets: 1 1 2
Figure 9-101—Identification field format
The Mask field specifies which other fields in the Rate Identification field are used by a STA. The format of
the Mask field is shown in Figure 9-102.
B0 B2 B3 B4 B5 B7
MCS Selector Rate Type Reserved
Bits: 3 2 3
Figure 9-102—Mask field format
The MCS Selector field value 0 indicates that the MCS Index field is reserved. The MCS Selector field
value 1 indicates the MCS Index field specifies an index value that is taken from Table 19-27 to Table 19-30
and Table 19-36 to Table 19-38 in 19.5. The MCS Selector field value 2 indicates the MCS Index field spec-
ifies an index value that is taken from Table 19-31 to Table 19-35 and Table 19-40 to Table 19-41 in 19.5.
The MCS Selector field value 3 indicates that the MCS Index field specifies values that are taken from
Table 21-30 to Table 21-37, indicating a VHT-MCS for a 20 MHz channel width.
The MCS Selector field value 4 indicates that the MCS Index field specifies values that are taken from
Table 21-38 to Table 21-45, indicating a VHT-MCS for a 40 MHz channel width.
754
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In frames transmitted by a TVHT STA, the MCS Selector field value 4 indicates that the MCS Index field
specifies values that are taken from Table 22-26 to Table 22-29, indicating a TVHT MCS for a TVHT_W
channel width.
The MCS Selector field value 5 indicates that the MCS Index field specifies values that are taken from
Table 21-46 to Table 21-53, indicating a VHT-MCS for an 80 MHz channel width.
In frames transmitted by a TVHT STA, the MCS Selector field value 5 indicates that the MCS Index field
specifies values that are taken from Table 22-30 to Table 22-33, indicating a TVHT MCS for a TVHT_2W
or TVHT_W+W channel width.
The MCS Selector field value 6 indicates that the MCS Index field specifies values that are taken from
Table 21-54 to Table 21-61, indicating a VHT-MCS for a 160 MHz or 80+80 MHz channel width.
In frames transmitted by a TVHT STA, the MCS Selector field value 6 indicates that the MCS Index field
specifies values that are taken from Table 22-34 to Table 22-37, indicating a TVHT MCS for a TVHT_4W
or TVHT_2W+2W channel width.
The MCS Selector field value 7 is reserved.
The Rate Type field set to 0 indicates the Rate field is reserved. The Rate Type field set to 1 indicates the
Rate field specifies a data rate that is in the basic rate set. The Rate Type field set to 2 indicates the Rate field
specifies a data rate that is not in the basic rate set.
If MCS Selector is 1 or 2, the MCS Index field is a 1 octet unsigned integer that specifies the row index for
one of the MCS parameter tables in 19.5.
If MCS Selector is 3, 4, 5, or 6, the MCS Index field format is as shown in Figure 9-103. The NSS subfield
indicates the number of spatial streams, and the VHT-MCS Index Row subfield indicates a value from the
“VHT-MCS Index” column of Table 21-30 to Table 21-61 in 21.5 or from the “MCS Index” column of
Table 22-26 to Table 22-37 in 22.5 that corresponds to the channel width and NSS values.
B0 B2 B3 B6 B7
VHT-MCS
NSS Index Row Reserved
Bits 3 4 1
Figure 9-103—MCS Index field format when the MCS Selector field is 3, 4, 5, or 6
The Rate field contains a 2-octet unsigned integer that specifies the PHY rate in 0.5 Mb/s units.
9.4.1.34 GAS Query Response Fragment ID field
A GAS Query Fragment Response ID field is used by the STA to indicate when a GAS Query Response
spans multiple MMPDUs. STAs responding to GAS request use this field to inform the requesting STA of
the GAS fragment number of the transmitted frames as well as identifying the last GAS fragment of the
Query Response. Requesting STAs use this field to determine if any fragments of the Query Response are
missing. The maximum value permitted in the GAS Query Response Fragment ID is 127. The More GAS
Fragments field is set to 1 in GAS Query Response fragments of GAS Comeback Response frames that have
another GAS fragment of the current query response to follow; otherwise, it is set to 0. The format of GAS
Query Response Fragment ID is shown in Figure 9-104.
755
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B6 B7
GAS Query Response
Fragment ID More GAS Fragments
Bits: 7 1
Figure 9-104—GAS Query Response Fragment ID field
9.4.1.35 Venue Info field
The Venue Info field is a 2-octet field. It contains Venue Group and Venue Type subfields. The format of
Venue Info subfield is shown in Figure 9-105.
Venue Group Venue Type
Octets: 1 1
Figure 9-105—Venue Info field format
The Venue Group and Venue Type subfields are both 1-octet values selected from Table 9-61 and
Table 9-62, respectively. The entries in Table 9-61 and Table 9-62 are drawn from the International Build-
ing Code’s Use and Occupancy Classifications [B48].
Table 9-61—Venue group codes and descriptions
Venue group code Venue group description
0 Unspecified
1 Assembly
2 Business
3 Educational
4 Factory and Industrial
5 Institutional
6 Mercantile
7 Residential
8 Storage
9 Utility and Miscellaneous
10 Vehicular
11 Outdoor
12–255 Reserved
756
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-62—Venue type assignments
Venue group code Venue type code Venue description
0 0 Unspecified
0 1–255 Reserved
1 0 Unspecified Assembly
1 1 Arena
1 2 Stadium
1 3 Passenger Terminal (e.g., airport, bus, ferry, train station)
1 4 Amphitheater
1 5 Amusement Park
1 6 Place of Worship
1 7 Convention Center
1 8 Library
1 9 Museum
1 10 Restaurant
1 11 Theater
1 12 Bar
1 13 Coffee Shop
1 14 Zoo or Aquarium
1 15 Emergency Coordination Center
1 16–255 Reserved
2 0 Unspecified Business
2 1 Doctor or Dentist office
2 2 Bank
2 3 Fire Station
2 4 Police Station
2 6 Post Office
2 7 Professional Office
2 8 Research and Development Facility
2 9 Attorney Office
2 10–255 Reserved
3 0 Unspecified Educational
3 1 School, Primary
3 2 School, Secondary
3 3 University or College
3 4–255 Reserved
4 0 Unspecified Factory and Industrial
4 1 Factory
4 2–255 Reserved
757
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-62—Venue type assignments (continued)
Venue group code Venue type code Venue description
5 0 Unspecified Institutional
5 1 Hospital
5 2 Long-Term Care Facility (e.g., Nursing home, Hospice, etc.)
5 3 Alcohol and Drug Rehabilitation Center
5 4 Group Home
5 5 Prison or Jail
5 6–255 Reserved
6 0 Unspecified Mercantile
6 1 Retail Store
6 2 Grocery Market
6 3 Automotive Service Station
6 4 Shopping Mall
6 5 Gas Station
6 6–255 Reserved
7 0 Unspecified Residential
7 1 Private Residence
7 2 Hotel or Motel
7 3 Dormitory
7 4 Boarding House
7 5–255 Reserved
8 0 Unspecified Storage
8 1–255 Reserved
9 0 Unspecified Utility and Miscellaneous
9 1–255 Reserved
10 0 Unspecified Vehicular
10 1 Automobile or Truck
10 2 Airplane
10 3 Bus
10 4 Ferry
10 5 Ship or Boat
10 6 Train
10 7 Motor Bike
10 8–255 Reserved
11 0 Unspecified Outdoor
11 1 Muni-mesh Network
11 2 City Park
11 3 Rest Area
758
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-62—Venue type assignments (continued)
Venue group code Venue type code Venue description
11 4 Traffic Control
11 5 Bus Stop
11 6 Kiosk
11 7–255 Reserved
9.4.1.36 Target Channel
The Target Channel field specifies the channel number of the target channel. The length of the Target
Channel field is 1 octet. The Target Channel field is illustrated in Figure 9-106.
Target Channel
Octets: 1
Figure 9-106—Target Channel field format
9.4.1.37 Operating Class
The Operating Class field specifies the operating class for the channel field included in the same frame. The
length of the Operating Class field is 1 octet. Operating classes are defined in Annex E. The Operating Class
field is illustrated in Figure 9-107.
Operating Class
Octets: 1
Figure 9-107—Operating Class field format
9.4.1.38 Send-Confirm field
The Send-Confirm field is used with SAE authentication as an anti-replay counter as specified in 12.4. See
Figure 9-108.
Send-Confirm
Octets: 2
Figure 9-108—Send-Confirm field
9.4.1.39 Anti-Clogging Token field
The Anti-Clogging Token field is used with SAE authentication for denial-of-service protection as specified
in 12.4. See Figure 9-109.
Anti-Clogging Token
Octets: variable
Figure 9-109—Anti-Clogging Token field
759
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.1.40 Scalar field
The Scalar field is used with SAE authentication to communicate cryptographic material as specified in
12.4. See Figure 9-110.
Scalar
Octets: variable
Figure 9-110—Scalar field
9.4.1.41 Finite field element (FFE) field
The FFE field is used with SAE authentication to communicate an element in a finite field as specified in
12.4. See Figure 9-111.
FFE
Octets: variable
Figure 9-111—FFE field
9.4.1.42 Confirm field
The Confirm field is used with SAE authentication to authenticate and prove possession of a cryptographic
key as specified in 12.4. See Figure 9-112.
Confirm
Octets: variable
Figure 9-112—Confirm field
9.4.1.43 Finite Cyclic Group field
The Finite Cyclic Group is used in SAE to indicate which cryptographic group to use in the SAE exchange
as specified in 12.4. See Figure 9-113.
Finite Cyclic Group
Octets: 2
Figure 9-113—Finite Cyclic Group field
9.4.1.44 TXOP Reservation field
The format of the TXOP Reservation field is shown in Figure 9-114.
Duration Service Interval Start Time
Octets: 1 1 4
Figure 9-114—TXOP Reservation field format
760
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Duration subfield specifies the duration of the TXOP in units of 32 µs.
The Service Interval subfield contains an 8-bit unsigned integer that specifies the service interval (SI) of the
reservation in units of milliseconds.
The Start Time subfield is the offset from the next TBTT to the start of the first SP and indicates the
anticipated start time, expressed in microseconds, of the first TXOP after the TBTT.
9.4.1.45 Relay Capable STA Info field
The format of the Relay Capable STA Info field is defined in Figure 9-115.
B0 B7 B8 B23
AID Relay Capabilities Information
Bits: 8 16
Figure 9-115—Relay Capable STA Info field
The AID subfield contains the AID of the relay capable STA that is associated with the AP or PCP.
The Relay Capability Information subfield is defined in 9.4.2.148.
9.4.1.46 Band ID field
The Band ID field is 1 octet in length and is defined in Table 9-63.
Table 9-63—Band ID field
Band ID value Meaning
0 TV white spaces
1 Sub-1 GHz (excluding TV white spaces)
2 2.4 GHz
3 3.6 GHz
4 4.9 and 5 GHz
5 60 GHz
6–255 Reserved
9.4.1.47 DMG Parameters field
The format of the DMG Parameters field is shown in Figure 9-116.
761
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3 B4 B5 B6 B7
ECAPC Policy
BSS Type CBAP Only CBAP Source DMG Privacy Enforced Reserved
Bits: 2 1 1 1 1 2
Figure 9-116—DMG Parameters
If the BSS Type field is transmitted as part of a DMG Beacon frame that has the Discovery Mode field
within the Beacon Interval Control field (see Figure 9-61) equal to 0, then the BSS Type subfield is defined
in Table 9-64 for specific types of frame cited below. An AP sets the BSS Type subfield to 3 within
transmitted DMG Beacon, Probe Response, or (Re)Association Response frames. A PCP sets the BSS Type
subfield to 2 within transmitted DMG Beacon, Probe Response, or (Re)Association Response frames. An
IBSS STA or a STA that is not a member of a BSS sets the BSS Type subfield to 1 within transmitted DMG
Beacon or Probe Response frames. The BSS Type subfield is reserved for all other types of frame.
Table 9-64—The BSS Type subfield when the Discovery mode field is 0
Subfield value BSS Type Transmitted by DMG STA
3 Infrastructure BSS AP
2 PBSS PCP
1 IBSS Any non-AP and non-PCP DMG STA
0 Reserved
If the BSS Type field is transmitted as part of a DMG Beacon frame that has the Discovery Mode field
within the Beacon Interval Control field (see Figure 9-61) equal to 1, the BSS Type subfield is defined in
Table 9-65. Depending on the role of the STA that responds to the DMG Beacon frame (identified by the
“Responding STA role” column of Table 9-65), the behavior is different and is defined in 10.38.5.2.
Table 9-65—The BSS Type subfield when the Discovery mode field is 1
Subfield value Responding STA role Applicable BSS types
3 AP Infrastructure BSS
2 PCP PBSS
1 Non-AP STA PBSS, IBSS
0 Any Infrastructure BSS, PBSS, IBSS
The CBAP Only, CBAP Source, and ECAPC Policy Enforced subfields are valid only when transmitted
within a DMG Beacon, Probe Response, or (Re)Association Response frames and are set as follows:
— The CBAP Only subfield indicates the type of link access provided by the STA sending the DMG
Beacon frame in the data transfer interval (DTI) (see 10.36.2) of the beacon interval. The CBAP
Only subfield is set to 1 when the entirety of the DTI portion of the beacon interval is allocated as a
CBAP. The CBAP Only subfield is set to 0 when the allocation of the DTI portion of the beacon
interval is provided through the Extended Schedule element.
762
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The CBAP Source subfield is valid only if the CBAP Only subfield is 1. The CBAP Source subfield
is set to 1 to indicate that the AP or PCP has higher priority to transmit during the CBAP than non-
AP and non-PCP STAs. The CBAP Source subfield is set to 0 otherwise.
— The ECAPC Policy Enforced subfield is set to 1 to indicate that medium access policies specific to
the centralized AP or PCP cluster are required as defined in 10.37.3.4. The ECAPC Policy Enforced
subfield is set to 0 to indicate that medium access policies specific to the centralized AP or PCP
cluster are not required.
The DMG Privacy subfield is set to 1 if dot11RSNAActivated is true. Otherwise, this subfield is set to 0.
9.4.1.48 VHT MIMO Control field
The VHT MIMO Control field is included in every VHT Compressed Beamforming frame (see 9.6.23.2).
The VHT MIMO Control field is defined in Figure 9-117.
B0 B2 B3 B5 B6 B7 B8 B9 B10 B11 B12 B14 B15 B16 B17 B18 B23
Remaining First Sounding
Nc Nr Channel Codebook Feedback Dialog
Index Index Width Grouping Information Type Feedback Feedback Reserved Token
Segments Segment
Number
Bits: 3 3 2 2 1 1 3 1 2 6
Figure 9-117—VHT MIMO Control field
The subfields of the VHT MIMO Control field are defined in Table 9-66.
Table 9-66—Subfields of the VHT MIMO Control field
Subfield Description
Nc Index Indicates the number of columns, Nc, in the compressed beamforming feedback matrix
minus 1:
Set to 0 for Nc = 1
Set to 1 for Nc = 2
…
Set to 7 for Nc = 8
Nr Index Indicates the number of rows, Nr, in the compressed beamforming feedback matrix minus
1:
Set to 0 for Nr = 1
Set to 1 for Nr = 2
…
Set to 7 for Nr = 8
Channel Width Indicates the width of the channel in which the measurement to create the compressed
beamforming feedback matrix was made:
Set to 0 for 20 MHz
Set to 1 for 40 MHz
Set to 2 for 80 MHz
Set to 3 for 160 MHz or 80+80 MHz
Grouping Indicates the subcarrier grouping, Ng, used for the compressed beamforming feedback
matrix:
Set to 0 for Ng = 1 (No grouping)
Set to 1 for Ng = 2
Set to 2 for Ng = 4
The value 3 is reserved
763
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-66—Subfields of the VHT MIMO Control field (continued)
Subfield Description
Codebook Indicates the size of codebook entries:
Information If Feedback Type is SU:
Set to 0 for 2 bits for ψ, 4 bits for
Set to 1 for 4 bits for ψ, 6 bits for
If Feedback Type is MU:
Set to 0 for 5 bits for ψ, 7 bits for
Set to 1 for 7 bits for ψ, 9 bits for
Feedback Type Indicates the feedback type:
Set to 0 for SU
Set to 1 for MU
Remaining Indicates the number of remaining feedback segments for the associated VHT Compressed
Feedback Segments Beamforming frame:
Set to 0 for the last feedback segment of a segmented report or the only feedback
segment of an unsegmented report.
Set to a value between 1 and 6 for a feedback segment that is neither the first nor the last
of a segmented report.
Set to a value between 1 and 7 for a feedback segment that is not the last feedback
segment of a segmented report.
In a retransmitted feedback segment, the field is set to the same value associated with the
feedback segment in the original transmission.
First Feedback Set to 1 for the first feedback segment of a segmented report or the only feedback segment
Segment of an unsegmented report; set to 0 if it is not the first feedback segment or if the VHT
Compressed Beamforming Report field and MU Exclusive Beamforming Report field are
not present in the frame.
In a retransmitted feedback segment, the field is set to the same value associated with the
feedback segment in the original transmission.
Sounding Dialog The sounding dialog token from the VHT NDP Announcement frame soliciting feedback
Token Number
In a VHT Compressed Beamforming frame not carrying all or part of a VHT Compressed Beamforming
report (see 10.34.5 for a description of such a case), the Nc Index, Nr Index, Channel Width, Grouping,
Codebook Information, Feedback Type and Sounding Dialog Token Number subfields are reserved, the
First Feedback Segment subfield is set to 0 and the Remaining Feedback Segments subfield is set to 7.
9.4.1.49 VHT Compressed Beamforming Report field
The VHT Compressed Beamforming Report field is used by the VHT Compressed Beamforming feedback
(see 9.6.23.2) to carry explicit feedback information in the form of angles representing compressed
beamforming feedback matrices V for use by a transmit beamformer to determine steering matrices Q, as
described in 10.32.3 and 19.3.12.3.
The size of the VHT Compressed Beamforming Report field depends on the values in the VHT MIMO
Control field. The VHT Compressed Beamforming Report field contains VHT Compressed Beamforming
Report information or successive (possibly zero-length) portions thereof in the case of segmented VHT
Compressed Beamforming feedback (see 10.34.5). VHT Compressed Beamforming Report information is
always included in the VHT Compressed Beamforming feedback.
The VHT Compressed Beamforming Report information contains the channel matrix elements indexed,
first, by matrix angles in the order shown in Table 9-67 and, second, by data subcarrier index from lowest
frequency to highest frequency. The explanation on how these angles are generated from the beamforming
feedback matrix V is given in 19.3.12.3.6. In Table 9-67,
764
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Nc is the number of columns in a compressed beamforming feedback matrix determined by the Nc
Index field of the VHT MIMO Control field,
Nr is the number of rows in a compressed beamforming feedback matrix determined by the Nr
Index field of the VHT MIMO Control field.
Table 9-67—Order of angles in the Compressed Beamforming Feedback Matrix subfield
Size of V Number of The order of angles in the Compressed Beamforming Feedback Matrix
(Nr × Nc) angles (Na) subfield
2×1 2 11, ψ21
2×2 2 11, ψ21
3×1 4 11, 21, ψ21, ψ31
3×2 6 11, 21, ψ21, ψ31, 22, ψ32
3×3 6 11, 21, ψ21, ψ31, 22, ψ32
4×1 6 11, 21, 31, ψ21, ψ31, ψ41
4×2 10 11, 21, 31, ψ21, ψ31, ψ41, 22, 32, ψ32, ψ42
4×3 12 11, 21, 31, ψ21, ψ31, ψ41, 22, 32, ψ32, ψ42, 33, ψ43
4×4 12 11, 21, 31, ψ21, ψ31, ψ41, 22, 32, ψ32, ψ42, 33, ψ43
5×1 8 11, 21, 31, 41, ψ21, ψ31, ψ41, ψ51
5×2 14 11, 21, 31, 41, ψ21, ψ31, ψ41, ψ51, 22, 32, 42, ψ32, ψ42, ψ52
5×3 18 11, 21, 31, 41, ψ21, ψ31, ψ41, ψ51, 22, 32, 42, ψ32, ψ42, ψ52, 33, 43,
ψ43, ψ53
5×4 20 11, 21, 31, 41, ψ21, ψ31, ψ41, ψ51, 22, 32, 42, ψ32, ψ42, ψ52, 33, 43,
ψ43, ψ53, 44, ψ54
5×5 20 11, 21, 31, 41, ψ21, ψ31, ψ41, ψ51, 22, 32, 42, ψ32, ψ42, ψ52, 33, 43,
ψ43, ψ53, 44, ψ54
6×1 10 11, 21, 31, 41, 51, ψ21, ψ31, ψ41, ψ51, ψ61
6×2 18 11, 21, 31, 41, 51, ψ21, ψ31, ψ41, ψ51, ψ61, 22, 32, 42, 52, ψ32, ψ42,
ψ52, ψ62
6×3 24 11, 21, 31, 41, 51, ψ21, ψ31, ψ41, ψ51, ψ61, 22, 32, 42, 52, ψ32, ψ42,
ψ52, ψ62, 33, 43, 53, ψ43, ψ53, ψ63
6×4 28 11, 21, 31, 41, 51, ψ21, ψ31, ψ41, ψ51, ψ61, 22, 32, 42, 52, ψ32, ψ42,
ψ52, ψ62, 33, 43, 53, ψ43, ψ53, ψ63, 44, 54, ψ54, ψ64
6×5 30 11, 21, 31, 41, 51, ψ21, ψ31, ψ41, ψ51, ψ61, 22, 32, 42, 52, ψ32, ψ42,
ψ52, ψ62, 33, 43, 53, ψ43, ψ53, ψ63, 44, 54, ψ54, ψ64, 55, ψ65
6×6 30 11, 21, 31, 41, 51, ψ21, ψ31, ψ41, ψ51, ψ61, 22, 32, 42, 52, ψ32, ψ42,
ψ52, ψ62, 33, 43, 53, ψ43, ψ53, ψ63, 44, 54, ψ54, ψ64, 55, ψ65
7×1 12 11, 21, 31, 41, 51, 61, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71
7×2 22 11, 21, 31, 41, 51, 61, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, 22, 32, 42, 52,
62, ψ32, ψ42, ψ52, ψ62, ψ72
7×3 30 11, 21, 31, 41, 51, 61, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, 22, 32, 42, 52,
62, ψ32, ψ42, ψ52, ψ62, ψ72, 33, 43, 53, 63, ψ43, ψ53, ψ63, ψ73
765
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-67—Order of angles in the Compressed Beamforming Feedback Matrix subfield
Size of V Number of The order of angles in the Compressed Beamforming Feedback Matrix
(Nr × Nc) angles (Na) subfield
7×4 36 11, 21, 31, 41, 51, 61, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, 22, 32, 42, 52,
62, ψ32, ψ42, ψ52, ψ62, ψ72, 33, 43, 53, 63, ψ43, ψ53, ψ63, ψ73, 44,
54, 64, ψ54, ψ64, ψ74
7×5 40 11, 21, 31, 41, 51, 61, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, 22, 32, 42, 52,
62, ψ32, ψ42, ψ52, ψ62, ψ72, 33, 43, 53, 63, ψ43, ψ53, ψ63, ψ73, 44,
54, 64, ψ54, ψ64, ψ74, 55, 65, ψ65, ψ75
7×6 42 11, 21, 31, 41, 51, 61, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, 22, 32, 42, 52,
62, ψ32, ψ42, ψ52, ψ62, ψ72, 33, 43, 53, 63, ψ43, ψ53, ψ63, ψ73, 44,
54, 64, ψ54, ψ64, ψ74, 55, 65, ψ65, ψ75, 66, ψ76
7×7 42 11, 21, 31, 41, 51, 61, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, 22, 32, 42, 52,
62, ψ32, ψ42, ψ52, ψ62, ψ72, 33, 43, 53, 63, ψ43, ψ53, ψ63, ψ73, 44,
54, 64, ψ54, ψ64, ψ74, 55, 65, ψ65, ψ75, 66, ψ76
8×1 14 11, 21, 31, 41, 51, 61, 71, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, ψ81
8×2 26 11, 21, 31, 41, 51, 61, 71, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, ψ81, 22, 32,
42, 52, 62, 72, ψ32, ψ42, ψ52, ψ62, ψ72, ψ82
8×3 36 11, 21, 31, 41, 51, 61, 71, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, ψ81, 22, 32,
42, 52, 62, 72, ψ32, ψ42, ψ52, ψ62, ψ72, ψ82, 33, 43, 53, φ63, 73,
ψ43, ψ53, ψ63, ψ73, ψ83
8×4 44 11, 21, 31, 41, 51, 61, 71, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, ψ81, 22, 32,
42, 52, 62, 72, ψ32, ψ42, ψ52, ψ62, ψ72, ψ82, 33, 43, 53, 63, 73,
ψ43, ψ53, ψ63, ψ73, ψ83, 44, 54, 64, 74, ψ54, ψ64, ψ74, ψ84
8×5 50 11, 21, 31, 41, 51, 61, 71, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, ψ81, 22, 32,
42, 52, 62, 72, ψ32, ψ42, ψ52, ψ62, ψ72, ψ82, 33, 43, 53, 63, 73,
ψ43, ψ53, ψ63, ψ73, ψ83, 44, 54, 64, 74, ψ54, ψ64, ψ74, ψ84, 55, 65,
75, ψ65, ψ75, ψ85
8×6 54 11, 21, 31, 41, 51, 61, 71, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, ψ81, 22, 32,
42, 52, 62, 72, ψ32, ψ42, ψ52, ψ62, ψ72, ψ82, 33, 43, 53, 63, 73,
ψ43, ψ53, ψ63, ψ73, ψ83, 44, 54, 64, 74, ψ54, ψ64, ψ74, ψ84, 55, 65,
75, ψ65, ψ75, ψ85, 66, 76, ψ76, ψ86
8×7 56 11, 21, 31, 41, 51, 61, 71, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, ψ81, 22, 32,
42, 52, 62, 72, ψ32, ψ42, ψ52, ψ62, ψ72, ψ82, 33, 43, 53, 63, 73,
ψ43, ψ53, ψ63, ψ73, ψ83, 44, 54, 64, 74, ψ54, ψ64, ψ74, ψ84, 55, 65,
75, ψ65, ψ75, ψ85, 66, 76, ψ76, ψ86, 77, ψ87
8×8 56 11, 21, 31, 41, 51, 61, 71, ψ21, ψ31, ψ41, ψ51, ψ61, ψ71, ψ81, 22, 32,
42, 52, 62, 72, ψ32, ψ42, ψ52, ψ62, ψ72, ψ82, 33, 43, 53, 63, 73,
ψ43, ψ53, ψ63, ψ73, ψ83, 44, 54, 64, 74, ψ54, ψ64, ψ74, ψ84, 55, 65,
75, ψ65, ψ75, ψ85, 66, 76, ψ76, ψ86, 77, ψ87
The beamforming feedback matrix V is formed by the beamformee as follows. The beamformer transmits an
NDP with NSTS,NDP space-time streams, where NSTS,NDP takes a value between 2 and 8. Based on this NDP,
the beamformee estimates the N RX BFEE N STS NDP channel, and based on that channel it determines a
Nr×Nc orthonormal matrix V, where Nr and Nc satisfy Equation (9-1).
Nr = N STS NDP Nc min(N STS NDP N RX BFEE) (9-1)
Further restrictions on Nc are described in 10.34.5.
766
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The angles are quantized as defined in Table 9-68.
Table 9-68—Quantization of angles
Quantized Quantized
k k
= -------------- + -------------- radians = ------------- + ------- radians
b +1 b +2 b –1 b
2 2 2 2
where where
b b
k = 0 1 2 –1 k = 0 1 2 –1
b is the number of bits used to quantize b is the number of bits used to quantize
(defined by the Codebook Information (defined by the Codebook Information
field of the VHT MIMO Control field field of the VHT MIMO Control field
(see 9.4.1.48) (see 9.4.1.48)
The VHT Compressed Beamforming Report information has the structure and order defined in Table 9-69,
where Na is the number of angles used for the compressed beamforming feedback matrix subfield (see
Table 9-67).
Table 9-69—VHT Compressed Beamforming Report information
Size
Field Meaning
(bits)
Average SNR of Space-Time Stream 1 8 Signal-to-noise ratio at the
beamformee for space-time stream 1
averaged over all data subcarriers.
See Table 9-71.
... … …
Average SNR of Space-Time Stream Nc 8 Signal-to-noise ratio at the
beamformee for space-time stream
Nc averaged over all data subcarriers.
See Table 9-71.
Compressed Beamforming Feedback Matrix V for Na×(b +b )/2 Compressed beamforming feedback
subcarrier k = scidx(0) matrix as defined in Table 9-67
Compressed Beamforming Feedback Matrix V for Na×(b +b )/2 Compressed beamforming feedback
subcarrier k = scidx(1) matrix as defined in Table 9-67
Compressed Beamforming Feedback Matrix V for Na×(b +b )/2 Compressed beamforming feedback
subcarrier k = scidx(2) matrix as defined in Table 9-67
... … …
Compressed Beamforming Feedback Matrix V for Na×( b +b )/2 Compressed beamforming feedback
subcarrier k = scidx(Ns – 1) matrix as defined in Table 9-67
NOTE—scidx() is defined in Table 9-70.
767
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Ns is the number of subcarriers for which the Compressed Beamforming Feedback Matrix subfield is sent
back to the beamformer. A beamformee might choose to reduce Ns by using a method referred to as
grouping, in which only a single Compressed Beamforming Feedback Matrix is reported for each group of
Ng adjacent subcarriers. Ns is a function of the Channel Width and Grouping subfields in the VHT MIMO
Control field (see 9.4.1.48). Table 9-70 lists Ns, the exact subcarrier indices and their order for which the
Compressed Beamforming Feedback Matrix subfield is sent back. No padding is present between angles in
the VHT Compressed Beamforming Report information, even if they correspond to different subcarriers. If
the size of the VHT Compressed Beamforming Report information is not an integer multiple of 8 bits, up to
seven zeros are appended to the end of the field to make its size an integer multiple of 8 bits.
Table 9-70—Subcarriers for which a Compressed Beamforming Feedback Matrix subfield
is sent back
Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield
Ng Ns
Width is sent: scidx(0), scidx(1), …, scidx(Ns-1)
–28, –27, –26, –25, –24, –23, –22, –20, –19, –18, –17, –16, –15, –14, –13, –12,
–11, –10, –9, –8, –6, –5, –4, –3, –2, –1, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15,
1 52 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 28
NOTE—Pilot subcarriers (±21, ±7) and DC subcarrier (0) are skipped
20 MHz
–28, –26, –24, –22, –20, –18, –16, –14, –12, –10, –8, –6, –4, –2, –1, 1, 2, 4, 6, 8,
2 30
10, 12, 14, 16, 18, 20, 22, 24, 26, 28
4 16 –28, –24, –20, –16, –12, –8, –4, –1, 1, 4, 8, 12, 16, 20, 24, 28
–58, –57, –56, –55, –54, –52, –51, –50, –49, –48, –47, –46, –45, –44, –43, –42,
–41, –40, –39, –38, –37, –36, –35, –34, –33, –32, –31, –30, –29, –28, –27, –26,
–24, –23, –22, –21, –20, –19, –18, –17, –16, –15, –14, –13, –12, –10, –9, –8, –7,
1 108 –6, –5, –4, –3, –2, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,
22, 23, 24, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44,
45, 46, 47, 48, 49, 50, 51, 52, 54, 55, 56, 57, 58
40 MHz NOTE—Pilot subcarriers (±53, ±25, ±11) and DC subcarriers (0, ±1) are skipped.
–58, –56, –54, –52, –50, –48, –46, –44, –42, –40, –38, –36, –34, –32, –30, –28,
2 58 –26, –24, -22, –20, –18, –16, –14, –12, –10, –8, –6, –4,–2, 2, 4, 6, 8, 10, 12, 14,
16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58
–58, –54, –50, –46, –42, –38, –34, –30, –26, –22, –18, –14, –10, –6,–2, 2, 6, 10,
4 30
14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58
–122, –121, –120, –119, –118, –117, –116, –115, –114, –113, –112, –111, –110,
–109, –108, –107, –106, –105, –104, –102, –101, –100, –99, –98, –97, –96, –95,
–94, –93, –92, –91, –90, –89, –88, –87, –86, –85, –84, –83, –82, –81, –80, –79,
–78, –77, –76, –74, –73, –72, –71, –70, –69, –68, –67, –66, –65, –64, –63, –62,
–61, –60, –59, –58, –57, –56, –55, –54, –53, –52, –51, –50, –49, –48, –47, –46,
–45, –44, –43, –42, –41, –40, –38, –37, –36, –35, –34, –33, –32, –31, –30, –29,
–28, –27, –26, –25, –24, –23, –22, –21, –20, –19, –18, –17, –16, –15, –14, –13,
–12, –10, –9, –8, –7, –6, –5, –4, –3, –2, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16,
80 MHz 1 234 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38,
40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61,
62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 76, 77, 78, 79, 80, 81, 82, 83, 84,
85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 104, 105,
106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121,
122
NOTE—Pilot subcarriers (±103, ±75, ±39, ±11) and DC subcarriers (0, ±1) are
skipped.
768
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-70—Subcarriers for which a Compressed Beamforming Feedback Matrix subfield
is sent back (continued)
Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield
Ng Ns
Width is sent: scidx(0), scidx(1), …, scidx(Ns-1)
–122, –120, –118, –116, –114, –112, –110, –108, –106, –104, –102, –100, –98,
–96, –94, –92, –90, –88, –86, –84, –82, –80, –78, –76, –74, –72, –70, –68, –66,
–64, –62, –60, –58, –56, –54, –52, –50, –48, –46, –44, –42, –40, –38, –36, –34,
2 122 –32, –30, –28, –26, –24, –22, –20, –18, –16, –14, –12, –10, –8, –6, –4, –2, 2, 4, 6,
8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50,
80 MHz 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94,
96, 98, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122
–122, –118, –114, –110, –106, –102, –98, –94, –90, –86, –82, –78, –74, –70, –66,
–62, –58, –54, –50, –46, –42, –38, –34, –30, –26, –22, –18, –14, –10, –6, –2, 2, 6,
4 62
10, 14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58, 62, 66, 70, 74, 78, 82, 86, 90, 94,
98, 102, 106, 110, 114, 118, 122
–250, –249, –248, –247, –246, –245, –244, –243, –242, –241, –240, –239, –238,
–237, –236, –235, –234, –233, –232, –230, –229, –228, –227, –226, –225, –224,
–223, –222, –221, –220, –219, –218, –217, –216, –215, –214, –213, –212, –211,
–210, –209, –208, –207, –206, –205, –204, –202, –201, –200, –199, –198, –197,
–196, –195, –194, –193, –192, –191, –190, –189, –188, –187, –186, –185, –184,
–183, –182, –181, –180, –179, –178, –177, –176, –175, –174, –173, –172, –171,
–170, –169, –168, –166, –165, –164, –163, –162, –161, –160, –159, –158, –157,
–156, –155, –154, –153, –152, –151, –150, –149, –148, –147, –146, –145, –144,
–143, –142, –141, –140, –138, –137, –136, –135, –134, –133, –132, –131, –130,
–126, –125, –124, –123, –122, –121, –120, –119, –118, –116, –115, –114, –113,
–112, –111, –110, –109, –108, –107, –106, –105, –104, -103, –102, –101, –100,
–99, –98, –97, –96, –95, –94, –93, –92, –91, –90, –88, –87, –86, –85, –84, –83,
–82, –81, –80, –79, –78, –77, –76, –75, –74, –73, –72, –71, –70, –69, –68, –67,
–66, –65, –64, –63, –62, –61, –60, –59, –58, –57, –56, –55, –54, –52, –51, –50,
–49, –48, –47, –46, –45, –44, –43, –42, –41, –40, –39, –38, –37, –36, –35, –34,
–33, –32, –31, –30, –29, –28, –27, –26, –24, –23, –22, –21, –20, –19, –18, –17,
160 MHz 1 468 –16, –15, –14, –13, –12, –11, –10, –9, –8, –7, –6, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
16, 17, 18, 19, 20, 21, 22, 23, 24, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38,
39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 54, 55, 56, 57, 58, 59, 60, 61,
62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83,
84, 85, 86, 87, 88, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104,
105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 118, 119, 120, 121,
122, 123, 124, 125, 126, 130, 131, 132, 133, 134, 135, 136, 137, 138, 140, 141,
142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157,
158, 159, 160, 161, 162, 163, 164, 165, 166, 168, 169, 170, 171, 172, 173, 174,
175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190,
191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 204, 205, 206, 207,
208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223,
224, 225, 226, 227, 228, 229, 230, 232, 233, 234, 235, 236, 237, 238, 239, 240,
241, 242, 243, 244, 245, 246, 247, 248, 249, 250
NOTE—Pilot subcarriers (±231, ±203, ±167, ±139, ±117, ±89, ±53, ±25), DC
subcarriers (0, ±1, ±2, ±3, ±4, ±5) and subcarriers ±127, ±128, ±129 are skipped.
769
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-70—Subcarriers for which a Compressed Beamforming Feedback Matrix subfield
is sent back (continued)
Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield
Ng Ns
Width is sent: scidx(0), scidx(1), …, scidx(Ns-1)
–250, –248, –246, –244, –242, –240, –238, –236, –234, –232, –230, –228, –226,
–224, –222, –220, –218, –216, –214, –212, –210, –208, –206, –204, –202, –200,
–198, –196, –194, –192, –190, –188, –186, –184, –182, –180, –178, –176, –174,
–172, –170, –168, –166, –164, –162, –160, –158, –156, –154, –152, –150, –148,
–146, –144, –142, –140, –138, –136, –134, –132, –130, –126, –124, –122, –120,
–118, –116, –114, –112, –110, -108, –106, –104, –102, –100, –98, –96, –94, –92,
–90, –88, –86, –84, –82, –80, –78, –76, –74, –72, –70, –68, –66, –64, –62, –60,
–58, –56, –54, –52, –50, –48, –46, –44, –42, –40, –38, –36, –34, –32, –30, –28,
2 244 –26, –24, –22, –20, –18, –16, –14, –12, –10, –8, –6, 6, 8, 10, 12, 14, 16, 18, 20,
22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64,
66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104,
106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 130, 132, 134, 136, 138,
140, 142, 144, 146, 148, 150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170,
172, 174, 176, 178, 180, 182, 184, 186, 188, 190, 192, 194, 196, 198, 200, 202,
160 MHz
204, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, 230, 232, 234,
236, 238, 240, 242, 244, 246, 248, 250
NOTE—DC subcarriers 0, ±2, ±4 and ±128 are skipped.
–250, –246, –242, –238, –234, –230, –226, –222, –218, –214, –210, –206, –202,
–198, –194, –190, –186, –182, –178, –174, –170, –166, –162, –158, –154, –150,
–146, –142, –138, –134, –130, –126, –122, –118, –114, –110, –106, –102, –98,
–94, –90, –86, –82, –78, –74, –70, –66, –62, –58, –54, –50, –46, –42, –38, –34,
4 124 –30, –26, –22, –18, –14, –10, –6, 6, 10, 14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54,
58, 62, 66, 70, 74, 78, 82, 86, 90, 94, 98, 102, 106, 110, 114, 118, 122, 126, 130,
134, 138, 142, 146, 150, 154, 158, 162, 166, 170, 174, 178, 182, 186, 190, 194,
198, 202, 206, 210, 214, 218, 222, 226, 230, 234, 238, 242, 246, 250
NOTE—DC subcarriers ±2 are skipped.
770
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-70—Subcarriers for which a Compressed Beamforming Feedback Matrix subfield
is sent back (continued)
Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield
Ng Ns
Width is sent: scidx(0), scidx(1), …, scidx(Ns-1)
–122(L), –121(L), –120(L), –119(L), –118(L), –117(L), –116(L), –115(L),
–114(L), –113(L), –112(L), –111(L), –110(L), –109(L), –108(L), –107(L),
–106(L), –105(L), -104(L), –102(L), –101(L), –100(L), –99(L), –98(L), –97(L),
–96(L), –95(L), –94(L), –93(L), –92(L), –91(L), –90(L), –89(L), –88(L), –87(L),
–86(L), –85(L), –84(L), –83(L), –82(L), –81(L), –80(L), –79(L), –78(L), –77(L),
–76(L), –74(L), –73(L), –72(L), –71(L), –70(L), –69(L), –68(L), –67(L), –66(L),
–65(L), –64(L), –63(L), –62(L), –61(L), –60(L), –59(L), –58(L), –57(L), –56(L),
–55(L), –54(L), –53(L), –52(L), –51(L), –50(L), –49(L), –48(L), –47(L), –46(L),
–45(L), –44(L), –43(L), –42(L), –41(L), –40(L), –38(L), –37(L), –36(L), –35(L),
–34(L), –33(L), –32(L), –31(L), –30(L), –29(L), –28(L), –27(L), –26(L), –25(L),
–24(L), –23(L), –22(L), –21(L), –20(L), –19(L), –18(L), –17(L), –16(L), –15(L),
–14(L), –13(L), –12(L), –10(L), –9(L), –8(L), –7(L), –6(L), –5(L), –4(L), –3(L),
–2(L), 2(L), 3(L), 4(L), 5(L), 6(L), 7(L), 8(L), 9(L), 10(L), 12(L), 13(L), 14(L),
15(L), 16(L), 17(L), 18(L), 19(L), 20(L), 21(L), 22(L), 23(L), 24(L), 25(L),
26(L), 27(L), 28(L), 29(L), 30(L), 31(L), 32(L), 33(L), 34(L), 35(L), 36(L),
37(L), 38(L), 40(L), 41(L), 42(L), 43(L), 44(L), 45(L), 46(L), 47(L), 48(L),
49(L), 50(L), 51(L), 52(L), 53(L), 54(L), 55(L), 56(L), 57(L), 58(L), 59(L),
60(L), 61(L), 62(L), 63(L), 64(L), 65(L), 66(L), 67(L), 68(L), 69(L), 70(L),
71(L), 72(L), 73(L), 74(L), 76(L), 77(L), 78(L), 79(L), 80(L), 81(L), 82(L),
83(L), 84(L), 85(L), 86(L), 87(L), 88(L), 89(L), 90(L), 91(L), 92(L), 93(L),
94(L), 95(L), 96(L), 97(L), 98(L), 99(L), 100(L), 101(L), 102(L), 104(L), 105(L),
106(L), 107(L), 108(L), 109(L), 110(L), 111(L), 112(L), 113(L), 114(L), 115(L),
116(L), 117(L), 118(L), 119(L), 120(L), 121(L), 122(L), –122(H), –121(H),
–120(H), –119(H), –118(H), –117(H), –116(H), –115(H), –114(H), –113(H),
–112(H), –111(H), –110(H), –109(H), –108(H), –107(H), –106(H), –105(H),
–104(H), -102(H), -101(H), –100(H), –99(H), –98(H), –97(H), –96(H), –95(H),
80+80 –94(H), –93(H), –92(H), –91(H), –90(H), –89(H), –88(H), –87(H), –86(H),
1 468
MHz –85(H), –84(H), –83(H), -82(H), –81(H), –80(H), –79(H), –78(H), –77(H),
–76(H), –74(H), –73(H), –72(H), –71(H), –70(H), –69(H), –68(H), –67(H),
–66(H), –65(H), –64(H), –63(H), –62(H), –61(H), –60(H), –59(H), –58(H),
–57(H), –56(H), –55(H), –54(H), –53(H), –52(H), –51(H), –50(H), –49(H),
–48(H), –47(H), –46(H), –45(H), –44(H), –43(H), –42(H), –41(H), –40(H),
–38(H), –37(H), –36(H), –35(H), –34(H), –33(H), –32(H), –31(H), –30(H),
–29(H), –28(H), –27(H), –26(H), –25(H), –24(H), –23(H), –22(H), –21(H),
–20(H), –19(H), –18(H), –17(H), –16(H), –15(H), –14(H), –13(H), –12(H),
–10(H), –9(H), –8(H), –7(H), –6(H), –5(H), –4(H), –3(H), –2(H), 2(H), 3(H),
4(H), 5(H), 6(H), 7(H), 8(H), 9(H), 10(H), 12(H), 13(H), 14(H), 15(H), 16(H),
17(H), 18(H), 19(H), 20(H), 21(H), 22(H), 23(H), 24(H), 25(H), 26(H), 27(H),
28(H), 29(H), 30(H), 31(H), 32(H), 33(H), 34(H), 35(H), 36(H), 37(H), 38(H),
40(H), 41(H), 42(H), 43(H), 44(H), 45(H), 46(H), 47(H), 48(H), 49(H), 50(H),
51(H), 52(H), 53(H), 54(H), 55(H), 56(H), 57(H), 58(H), 59(H), 60(H), 61(H),
62(H), 63(H), 64(H), 65(H), 66(H), 67(H), 68(H), 69(H), 70(H), 71(H), 72(H),
73(H), 74(H), 76(H), 77(H), 78(H), 79(H), 80(H), 81(H), 82(H), 83(H), 84(H),
85(H), 86(H), 87(H), 88(H), 89(H), 90(H), 91(H), 92(H), 93(H), 94(H), 95(H),
96(H), 97(H), 98(H), 99(H), 100(H), 101(H), 102(H), 104(H), 105(H), 106(H),
107(H), 108(H), 109(H), 110(H), 111(H), 112(H), 113(H), 114(H), 115(H),
116(H), 117(H), 118(H), 119(H), 120(H), 121(H), 122(H)
NOTE 1—Subcarrier x(L) denotes subcarrier index x in the frequency segment
lower in frequency, and subcarrier x(H) denotes subcarrier index x in the
frequency segment higher in frequency.
NOTE 2—Pilot subcarriers (±103, ±75, ±39, ±11) and DC subcarriers (0, ±1) are
skipped in each frequency segment.
771
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-70—Subcarriers for which a Compressed Beamforming Feedback Matrix subfield
is sent back (continued)
Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield
Ng Ns
Width is sent: scidx(0), scidx(1), …, scidx(Ns-1)
–122(L), –120(L), –118(L), –116(L), –114(L), –112(L), –110(L), –108(L),
–106(L), -104(L), –102(L), –100(L), –98(L), –96(L), –94(L), –92(L), –90(L),
–88(L), –86(L), –84(L), –82(L), –80(L), –78(L), –76(L), –74(L), –72(L), –70(L),
–68(L), –66(L), –64(L), –62(L), –60(L), –58(L), –56(L), –54(L), –52(L), –50(L),
–48(L), –46(L), –44(L), –42(L), –40(L), –38(L), –36(L), –34(L), –32(L), –30(L),
–28(L), –26(L), –24(L), –22(L), –20(L), –18(L), –16(L), –14(L), –12(L), –10(L),
–8(L), –6(L), –4(L), –2(L), 2(L), 4(L), 6(L), 8(L), 10(L), 12(L), 14(L), 16(L),
18(L), 20(L), 22(L), 24(L), 26(L), 28(L), 30(L), 32(L), 34(L), 36(L), 38(L),
40(L), 42(L), 44(L), 46(L), 48(L), 50(L), 52(L), 54(L), 56(L), 58(L), 60(L),
62(L), 64(L), 66(L), 68(L), 70(L), 72(L), 74(L), 76(L), 78(L), 80(L), 82(L),
84(L), 86(L), 88(L), 90(L), 92(L), 94(L), 96(L), 98(L), 100(L), 102(L), 104(L),
106(L), 108(L), 110(L), 112(L), 114(L), 116(L), 118(L), 120(L), 122(L),
2 244 –122(H), –120(H), –118(H), –116(H), –114(H), –112(H), –110(H), –108(H),
–106(H), –104(H), –102(H), –100(H), –98(H), –96(H), –94(H), –92(H), –90(H),
–88(H), –86(H), –84(H), –82(H), –80(H), –78(H), –76(H), –74(H), –72(H),
–70(H), –68(H), –66(H), –64(H), –62(H), –60(H), –58(H), –56(H), –54(H),
–52(H), –50(H), –48(H), –46(H), –44(H), –42(H), –40(H), –38(H), –36(H),
–34(H), –32(H), –30(H), –28(H), –26(H), –24(H), –22(H), –20(H), –18(H),
80+80 –16(H), –14(H), –12(H), –10(H), –8(H), –6(H), -4(H), –2(H), 2(H), 4(H), 6(H),
MHz 8(H), 10(H), 12(H), 14(H), 16(H), 18(H), 20(H), 22(H), 24(H), 26(H), 28(H),
30(H), 32(H), 34(H), 36(H), 38(H), 40(H), 42(H), 44(H), 46(H), 48(H), 50(H),
52(H), 54(H), 56(H), 58(H), 60(H), 62(H), 64(H), 66(H), 68(H), 70(H), 72(H),
74(H), 76(H), 78(H), 80(H), 82(H), 84(H), 86(H), 88(H), 90(H), 92(H), 94(H),
96(H), 98(H), 100(H), 102(H), 104(H), 106(H), 108(H), 110(H), 112(H), 114(H),
116(H), 118(H), 120(H), 122(H)
–122(L), –118(L), –114(L), –110(L), –106(L), –102(L), –98(L), –94(L), –90(L),
–86(L), –82(L), –78(L), –74(L), –70(L), –66(L), –62(L), –58(L), –54(L), –50(L),
–46(L), –42(L), –38(L), –34(L), –30(L), –26(L), –22(L), –18(L), –14(L), –10(L),
–6(L), –2(L), 2(L), 6(L), 10(L), 14(L), 18(L), 22(L), 26(L), 30(L), 34(L), 38(L),
42(L), 46(L), 50(L), 54(L), 58(L), 62(L), 66(L), 70(L), 74(L), 78(L), 82(L),
86(L), 90(L), 94(L), 98(L), 102(L), 106(L), 110(L), 114(L), 118(L), 122(L),
4 124 –122(H), –118(H), –114(H), –110(H), –106(H), –102(H), –98(H), –94(H),
–90(H), -86(H), –82(H), –78(H), –74(H), –70(H), –66(H), –62(H), –58(H),
–54(H), –50(H), –46(H), –42(H), –38(H), –34(H), –30(H), –26(H), –22(H),
–18(H), –14(H), –10(H), –6(H), –2(H), 2(H), 6(H), 10(H), 14(H), 18(H), 22(H),
26(H), 30(H), 34(H), 38(H), 42(H), 46(H), 50(H), 54(H), 58(H), 62(H), 66(H),
70(H), 74(H), 78(H), 82(H), 86(H), 90(H), 94(H), 98(H), 102(H), 106(H),
110(H), 114(H), 118(H), 122(H)
772
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Average SNR of Space-Time Stream i subfield in the Table 9-69 is an 8-bit 2s complement integer
whose definition is shown in Table 9-71.
Table 9-71—Average SNR of Space-Time Stream i subfield
Average SNR of Space-Time Stream i subfield AvgSNRi
–128 10 dB
–127 –9.75 dB
–126 –9.5 dB
… …
+126 53.5 dB
+127 53.75 dB
The AvgSNRi in Table 9-71 is found by computing the SNR per subcarrier in decibels for the subcarriers
identified in Table 9-70, and then computing the arithmetic mean of those values. Each SNR value per tone
in stream i (before being averaged) corresponds to the SNR associated with the column i of the beamforming
feedback matrix V determined at the beamformee. Each SNR corresponds to the predicted SNR at the
beamformee when the beamformer applies all columns of the matrix V.
A STA with a 40 MHz, 80 MHz, or 160 MHz operating channel width and sending feedback for a 20 MHz
channel width includes only subcarriers corresponding to the primary 20 MHz channel in the Compressed
Feedback Beamforming Matrix subfield.
A STA with an 80 MHz or 160 MHz operating channel width and sending feedback for a 40 MHz channel
width includes only subcarriers corresponding to the primary 40 MHz channel in the Compressed Feedback
Beamforming Matrix subfield.
A STA with a 160 MHz or 80+80 MHz operating channel width and sending feedback for an 80 MHz
channel width includes only subcarriers corresponding to the primary 80 MHz channel in the Compressed
Feedback Beamforming Matrix subfield.
NOTE—Multi-bit fields are transmitted LSB first according to the bit-ordering specification detailed in 9.2.2.
9.4.1.50 TVHT Compressed Beamforming Report field
The format of the TVHT Compressed Beamforming Report field is the same as the VHT Compressed
Beamforming Report field in 9.4.1.49 except for the following modifications.
The subcarriers for which Compressed Feedback Beamforming Matrix subfield is sent in Table 9-70 for
40 MHz are used for each basic channel unit (BCU) in TVHT_MODE_1 and TVHT_MODE_2N. See tone
location description in Table 22-9.
For TVHT_MODE_2C with 6 MHz and 8 MHz channelization, the subcarriers for which Compressed
Feedback Beamforming Matrix subfield is sent in the Lower BCU are based on subtracting 72 from the
values shown in Table 9-70 and for the Upper BCU by adding 72.
773
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For TVHT_MODE_2C with 7 MHz channelization, the subcarriers for which Compressed Feedback
Beamforming Matrix subfield is sent in the Lower BCU are based on subtracting 84 from the values shown
in Table 9-70 and for the Upper BCU by adding 84.
For TVHT_MODE_4C with 6 MHz and 8 MHz channelization, the subcarriers for which Compressed
Feedback Beamforming Matrix subfield is sent in the lowest, second to lowest, second to highest, and
highest BCUs are based on subtracting 216, subtracting 72, adding 72, and adding 216 from the values
shown in Table 9-70, respectively.
For TVHT_MODE_4C with 7 MHz channelization, the subcarriers for which Compressed Feedback Beam-
forming Matrix subfield is sent in the lowest, second to lowest, second to highest, and highest BCUs are
based on subtracting 252, subtracting 84, adding 84, and adding 252 from the values shown in Table 9-70,
respectively.
For TVHT_MODE_4N channelization, the subcarriers for which Compressed Feedback Beamforming
Matrix subfield is sent in each of the two noncontiguous frequency segments are as described for
TVHT_MODE_2C.
A STA with a TVHT_2W, TVHT_4W, TVHT_W+W, or TVHT_2W+2W operating channel width and
sending feedback for a TVHT_W channel width includes a representation of the compressed beamforming
feedback matrices of the subcarriers corresponding to the primary TVHT_W channel in the Compressed
Feedback Beamforming Matrix subfield.
A STA with a TVHT_4W or TVHT_2W+2W operating channel width and sending feedback for a
TVHT_2W channel width includes a representation of the compressed beamforming feedback matrices of
the subcarriers corresponding to the primary TVHT_2W channel in the Compressed Feedback
Beamforming Matrix subfield.
9.4.1.51 MU Exclusive Beamforming Report field
The MU Exclusive Beamforming Report field is used by the VHT Compressed Beamforming feedback (see
9.6.23.2) to carry explicit feedback information in the form of delta SNRs. The information in the VHT
Compressed Beamforming Report field and the MU Exclusive Beamforming Report field can be used by the
transmit MU beamformer to determine steering matrices Q, as described in 10.32.3, 19.3.12.3, and 21.3.11.
The size of the MU Exclusive Beamforming Report field depends on the values in the VHT MIMO Control
field. The MU Exclusive Beamforming Report field contains MU Exclusive Beamforming Report
information or successive (possibly zero-length) portions thereof in the case of segmented VHT Compressed
Beamforming feedback (see 10.34.5). The MU Exclusive Beamforming Report information is included in
the VHT Compressed Beamforming feedback if the Feedback Type subfield in the VHT MIMO Control
field indicates MU (see 9.4.1.48).
The MU Exclusive Beamforming Report information consists of Delta SNR subfields for each space-time
stream (1 to Nc) of a subset of the subcarriers typically spaced 2Ng apart, where Ng is signaled in the
Grouping subfield of the VHT MIMO Control field, starting from the lowest frequency subcarrier and
continuing to the highest frequency subcarrier. No padding is present between SNR k i in the MU
Exclusive Beamforming Report field, even if they correspond to different subcarriers. The subset of
subcarriers included is determined by the values of the Channel Width and Grouping subfields of the VHT
MIMO Control field as listed in Table 9-73. For each subcarrier included, the deviation in dB of the SNR of
that subcarrier for each column of V relative to the average SNR of the corresponding space-time stream is
computed using Equation (9-2).
774
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
2
Hk Vk i
SNR k i = min(max(round(10 log 10 ---------------------- – SNR i) – 8) 7) (9-2)
N
where
k is the subcarrier index in the range sscidx(0), …, sscidx(Ns'–1)
i is the space-time stream index in the range 1, …, Nc
Hk is the estimated MIMO channel for subcarrier k
Vk i is column i of the beamforming matrix V for subcarrier k
N is the average noise plus interference power, measured at the beamformee, that was used to
calculate SNR i
SNR i is the average SNR of space-time stream i reported in the VHT Compressed Beamforming
Report information (Average SNR in Space-Time Stream i field)
Each Delta SNR subfield contains the SNR k i computed using Equation (9-2) and quantized to 4 bits in
the range –8 dB to 7 dB with 1 dB granularity. The structure of the MU Exclusive Beamforming Report field
is shown in Table 9-72.
Table 9-72—MU Exclusive Beamforming Report information
Size
Field Meaning
(Bits)
Delta SNR for space-time stream 1 for 4 SNR sscidx as defined in Equation (9-2)
0 1
subcarrier k = sscidx(0)
… … …
Delta SNR for space-time stream Nc for 4 SNR sscidx as defined in Equation (9-2)
0 Nc
subcarrier k = sscidx(0)
Delta SNR for space-time stream 1 for 4 SNR sscidx as defined in Equation (9-2)
1 1
subcarrier k = sscidx(1)
… … …
Delta SNR for space-time stream Nc for 4 SNR sscidx as defined in Equation (9-2)
1 Nc
subcarrier k = sscidx(1)
… … …
Delta SNR for space-time stream 1 for 4 SNR sscidx as defined in Equation (9-2)
Ns' – 1 1
subcarrier k = sscidx(Ns’–1)
… … …
Delta SNR for space-time stream Nc for 4 SNR sscidx as defined in Equation (9-2)
Ns' – 1 Nc
subcarrier k = sscidx(Ns’–1)
NOTE—sscidx() is defined in Table 9-73.
775
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In Table 9-72, Ns' is the number of subcarriers for which the Delta SNR subfield is sent back to the
beamformer. Table 9-73 shows Ns', the exact subcarrier indices and their order for which the Delta SNR is
sent back.
Table 9-73—Number of subcarriers and subcarrier mapping
Channel Subcarriers for which the Delta SNR subfield is sent: sscidx(0), sscidx(1), …
Ng Ns'
Width sscidx(Ns'–1)
–28, –26, –24, –22, –20, –18, –16, –14, –12, –10, –8, –6, –4, –2, –1, 1, 2, 4, 6, 8, 10,
1 30
12, 14, 16, 18, 20, 22, 24, 26, 28
20 MHz
2 16 –28, –24, –20, –16, –12, –8, –4, –1, 1, 4, 8, 12, 16, 20, 24, 28
4 10 –28, –20, –12, –4, –1, 1, 4, 12, 20, 28
–58, –56, –54, –52, –50, –48, –46, –44, –42, –40, –38, –36, –34, –32, –30, –28, –26,
1 58 –24, –22, –20, –18, –16, –14, –12, –10, –8, –6, –4,–2, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20,
22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58
40 MHz
–58, –54, –50, –46, –42, –38, –34, –30, –26, –22, –18, –14, –10, –6,–2, 2, 6, 10, 14,
2 30
18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58
4 16 –58, –50, –42, –34, –26, –18, –10, –2, 2, 10, 18, 26, 34, 42, 50, 58
–122, –120, –118, –116, –114, –112, –110, –108, –106, –104, –102, –100, –98, –96,
–94, –92, –90, –88, –86, –84, –82, –80, –78, –76, –74, –72, –70, –68, –66, –64, –62,
–60, –58, –56, –54, –52, –50, –48, –46, –44, –42, –40, –38, –36, –34, –32, –30, –28,
1 122 –26, –24, –22, –20, –18, –16, –14, –12, –10, –8, –6, –4, –2, 2, 4, 6, 8, 10, 12, 14, 16,
18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62,
64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104,
106, 108, 110, 112, 114, 116, 118, 120, 122
80 MHz
–122, –118, –114, –110, –106, –102, –98, –94, –90, –86, –82, –78, –74, –70, –66,
–62, –58, –54, –50, –46, –42, –38, –34, –30, –26, –22, –18, –14, –10, –6, –2, 2, 6, 10,
2 62
14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58, 62, 66, 70, 74, 78, 82, 86, 90, 94, 98,
102, 106, 110, 114, 118, 122
–122, –114, –106, –98, –90, –82, –74, –66, –58, –50, –42, –34, –26, –18, –10, –2, 2,
4 32
10, 18, 26, 34, 42, 50, 58, 66, 74, 82, 90, 98, 106, 114, 122
–250, –248, –246, –244, –242, –240, –238, –236, –234, –232, –230, –228, –226,
–224, –222, –220, –218, –216, –214, –212, –210, –208, –206, –204, –202, –200,
–198, –196, –194, –192, –190, –188, –186, –184, –182, –180, –178, –176, –174,
–172, –170, –168, –166, –164, –162, –160, –158, –156, –154, –152, –150, –148,
–146, –144, –142, –140, –138, –136, –134, –132, –130, –126, –124, –122, –120,
–118, –116, –114, –112, –110, –108, –106, –104, –102, –100, –98, –96, –94, –92,
–90, –88, –86, –84, –82, –80, –78, –76, –74, –72, –70, –68, –66, –64, –62, –60, –58,
–56, –54, –52, –50, –48, –46, –44, –42, –40, –38, –36, –34, –32, –30, –28, –26, –24,
160 MHz 1 244 –22, –20, –18, –16, –14, –12, –10, –8, –6, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28,
30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74,
76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104, 106, 108, 110, 112, 114,
116, 118, 120, 122, 124, 126, 130, 132, 134, 136, 138, 140, 142, 144, 146, 148, 150,
152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182, 184,
186, 188, 190, 192, 194, 196, 198, 200, 202, 204, 206, 208, 210, 212, 214, 216, 218,
220, 222, 224, 226, 228, 230, 232, 234, 236, 238, 240, 242, 244, 246, 248, 250
NOTE—Subcarriers 0, ±2, ±4 and ±128 are skipped.
776
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-73—Number of subcarriers and subcarrier mapping (continued)
Channel Subcarriers for which the Delta SNR subfield is sent: sscidx(0), sscidx(1), …
Ng Ns'
Width sscidx(Ns'–1)
–250, –246, –242, –238, –234, –230, –226, –222, –218, –214, –210, –206, –202,
–198, –194, –190, –186, –182, –178, –174, –170, –166, –162, –158, –154, –150,
–146, –142, –138, –134, –130, –126, –122, –118, –114, –110, –106, –102, –98, –94,
–90, –86, –82, –78, –74, –70, –66, –62, –58, –54, –50, –46, –42, –38, –34, –30, –26,
2 124 –22, –18, –14, –10, –6, 6, 10, 14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58, 62, 66, 70,
74, 78, 82, 86, 90, 94, 98, 102, 106, 110, 114, 118, 122, 126, 130, 134, 138, 142, 146,
150, 154, 158, 162, 166, 170, 174, 178, 182, 186, 190, 194, 198, 202, 206, 210, 214,
160 MHz 218, 222, 226, 230, 234, 238, 242, 246, 250
NOTE—Subcarriers ±2 are skipped.
–250, –242, –234, –226, –218, –210, –202, –194, –186, –178, –170, –162, –154,
–146, –138, –130, –126, –118, –110, –102, –94, –86, –78, –70, –62, –54, –46, –38,
4 64
–30, –22, –14, -6, 6, 14, 22, 30, 38, 46, 54, 62, 70, 78, 86, 94, 102, 110, 118, 126, 130,
138, 146, 154, 162, 170, 178, 186, 194, 202, 210, 218, 226, 234, 242, 250
–122(L), –120(L), –118(L), –116(L), –114(L), –112(L), –110(L), –108(L), –106(L),
–104(L), –102(L), –100(L), –98(L), –96(L), –94(L), –92(L), –90(L), –88(L), –86(L),
–84(L), –82(L), –80(L), –78(L), –76(L), –74(L), –72(L), –70(L), –68(L), –66(L),
–64(L), –62(L), –60(L), –58(L), –56(L), –54(L), –52(L), –50(L), –48(L), –46(L),
–44(L), –42(L), –40(L), –38(L), –36(L), –34(L), –32(L), –30(L), –28(L), –26(L),
–24(L), –22(L), –20(L), –18(L), –16(L), –14(L), –12(L), –10(L), –8(L), –6(L), –4(L),
–2(L), 2(L), 4(L), 6(L), 8(L), 10(L), 12(L), 14(L), 16(L), 18(L), 20(L), 22(L), 24(L),
26(L), 28(L), 30(L), 32(L), 34(L), 36(L), 38(L), 40(L), 42(L), 44(L), 46(L), 48(L),
50(L), 52(L), 54(L), 56(L), 58(L), 60(L), 62(L), 64(L), 66(L), 68(L), 70(L), 72(L),
74(L), 76(L), 78(L), 80(L), 82(L), 84(L), 86(L), 88(L), 90(L), 92(L), 94(L), 96(L),
98(L), 100(L), 102(L), 104(L), 106(L), 108(L), 110(L), 112(L), 114(L), 116(L),
1 244 118(L), 120(L), 122(L), –122(H), –120(H), –118(H), –116(H), –114(H), –112(H),
–110(H), –108(H), –106(H), –104(H), –102(H), –100(H), –98(H), –96(H), –94(H),
–92(H), –90(H), –88(H), –86(H), –84(H), –82(H), –80(H), –78(H), –76(H), –74(H),
–72(H), –70(H), –68(H), –66(H), –64(H), –62(H), –60(H), –58(H), –56(H), –54(H),
–52(H), –50(H), –48(H), –46(H), –44(H), –42(H), –40(H), –38(H), –36(H), –34(H),
–32(H), –30(H), –28(H), –26(H), –24(H), –22(H), –20(H), –18(H), –16(H), –14(H),
80+80 –12(H), –10(H), –8(H), –6(H), –4(H), –2(H), 2(H), 4(H), 6(H), 8(H), 10(H), 12(H),
MHz 14(H), 16(H), 18(H), 20(H), 22(H), 24(H), 26(H), 28(H), 30(H), 32(H), 34(H), 36(H),
38(H), 40(H), 42(H), 44(H), 46(H), 48(H), 50(H), 52(H), 54(H), 56(H), 58(H), 60(H),
62(H), 64(H), 66(H), 68(H), 70(H), 72(H), 74(H), 76(H), 78(H), 80(H), 82(H), 84(H),
86(H), 88(H), 90(H), 92(H), 94(H), 96(H), 98(H), 100(H), 102(H), 104(H), 106(H),
108(H), 110(H), 112(H), 114(H), 116(H), 118(H), 120(H), 122(H)
–122(L), –118(L), –114(L), –110(L), –106(L), –102(L), –98(L), –94(L), –90(L),
–86(L), –82(L), –78(L), –74(L), –70(L), –66(L), –62(L), –58(L), –54(L), –50(L),
–46(L), –42(L), –38(L), –34(L), –30(L), –26(L), –22(L), –18(L), –14(L), –10(L),
–6(L), –2(L), 2(L), 6(L), 10(L), 14(L), 18(L), 22(L), 26(L), 30(L), 34(L), 38(L),
42(L), 46(L), 50(L), 54(L), 58(L), 62(L), 66(L), 70(L), 74(L), 78(L), 82(L), 86(L),
90(L), 94(L), 98(L), 102(L), 106(L), 110(L), 114(L), 118(L), 122(L), –122(H),
2 124
–118(H), –114(H), –110(H), –106(H), –102(H), –98(H), –94(H), –90(H), –86(H),
–82(H), –78(H), –74(H), –70(H), –66(H), –62(H), –58(H), –54(H), –50(H), –46(H),
–42(H), –38(H), –34(H), –30(H), –26(H), –22(H), –18(H), –14(H), –10(H), –6(H),
–2(H), 2(H), 6(H), 10(H), 14(H), 18(H), 22(H), 26(H), 30(H), 34(H), 38(H), 42(H),
46(H), 50(H), 54(H), 58(H), 62(H), 66(H), 70(H), 74(H), 78(H), 82(H), 86(H), 90(H),
94(H), 98(H), 102(H), 106(H), 110(H), 114(H), 118(H), 122(H)
777
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-73—Number of subcarriers and subcarrier mapping (continued)
Channel Subcarriers for which the Delta SNR subfield is sent: sscidx(0), sscidx(1), …
Ng Ns'
Width sscidx(Ns'–1)
–122(L), –114(L), –106(L), –98(L), –90(L), –82(L), –74(L), –66(L), –58(L), –50(L),
-42(L), –34(L), –26(L), –18(L), –10(L), –2(L), 2(L), 10(L), 18(L), 26(L), 34(L),
42(L), 50(L), 58(L), 66(L), 74(L), 82(L), 90(L), 98(L), 106(L), 114(L), 122(L), –
80+80
4 64 122(H), –114(H), –106(H), –98(H), –90(H), –82(H), –74(H), –66(H), –58(H), –
MHz
50(H), –42(H), –34(H), –26(H), –18(H), –10(H), –2(H), 2(H), 10(H), 18(H), 26(H),
34(H), 42(H), 50(H), 58(H), 66(H), 74(H), 82(H), 90(H), 98(H), 106(H), 114(H),
122(H)
NOTE 1—sscidx() is defined in Table 9-72.
NOTE 2—Subcarrier x(L) denotes subcarrier index x in the frequency segment lower in frequency, and subcarrier x(H)
denotes subcarrier index x in the frequency segment higher in frequency.
9.4.1.52 TVHT MU Exclusive Beamforming Report field
See Table 9.4.1.51 with the following modifications.
For each BCU in TVHT_MODE_1 and TVHT_MODE_2N, the subcarriers used in the Delta SNR subfield
are defined in Table 9-73 for 40 MHz. See the tone location description in Table 22-9.
For TVHT_MODE_2C with 6 MHz and 8 MHz channelization, the subcarriers for which Delta SNR
subfield is sent in the Lower BCU are based on subtracting 72 from the values shown in Table 9-73 and for
the Upper BCU by adding 72.
For TVHT_MODE_2C with 7 MHz channelization, the subcarriers for which Delta SNR subfield is sent in
the Lower BCU are based on subtracting 84 from the values shown in Table 9-73 and for the Upper BCU by
adding 84.
For TVHT_MODE_4C with 6 MHz and 8 MHz channelization, the subcarriers for which Delta SNR
subfield is sent in the lowest, second to lowest, second to highest, and highest BCUs are based on
subtracting 216, subtracting 72, adding 72, and adding 216 from the values shown in Table 9-73,
respectively.
For TVHT_MODE_4C with 7 MHz channelization, the subcarriers for which Delta SNR subfield is sent in
the lowest, second to lowest, second to highest, and highest BCUs are based on subtracting 252, subtracting
84, adding 84, and adding 252 from the values shown in Table 9-73, respectively.
For TVHT_MODE_4N channelization, the subcarriers for which Delta SNR subfield is sent in each of the
two noncontiguous frequency segments are as described for TVHT_MODE_2C.
9.4.1.53 Operating Mode field
The Operating Mode field is present in the Operating Mode Notification frame (see 9.6.23.4) and Operating
Mode Notification element (see 9.4.2.166).
778
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Operating Mode field is shown in Figure 9-118.
B0 B1 B2 B3 B4 B6 B7
Channel Width 160/80+80 BW No LDPC Rx NSS Rx NSS Type
Bits: 2 1 1 3 1
Figure 9-118—Operating Mode field
The STA transmitting this field indicates its current operating channel width and the number of spatial
streams it can receive using the settings defined in Table 9-74.
Table 9-74—Subfield values of the Operating Mode field
Subfield Description
Channel Width If the Rx NSS Type subfield is 0, indicates the supported channel width:
In a VHT STA, see Table 9-75
In a TVHT STA:
Set to 0 for TVHT_W
Set to 1 for TVHT_2W and TVHT_W+W
Set to 2 for TVHT_4W and TVHT_2W+2W
The value of 3 is reserved.
Reserved if the Rx NSS Type subfield is 1.
160/80+80 BW This subfield, combined with the Channel Width subfield, the Supported Channel Width
Set subfield and the Supported VHT-MCS and NSS Set subfield indicates whether 80+80
MHz and 160 MHz operation is supported.
In a VHT STA, see Table 9-75.
In a TVHT STA, this field is reserved.
In a STA with dot11VHTExtendedNSSBWCapable either equal to false or not present, this
field is set to 0.
No LDPC Set to 1 to indicate that the STA transmitting this field prefers not to receive LDPC-
encoded PPDUs; set to 0 otherwise.
779
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-74—Subfield values of the Operating Mode field (continued)
Subfield Description
Rx NSS If the Rx NSS Type subfield is 0, the value of this field, combined with other information
described in 9.4.2.158.3, indicates the maximum number of spatial streams that the STA
can receive.
If the Rx NSS Type subfield is 1, the value of this field, indicates the maximum number of
spatial streams that the STA can receive as a beamformee in an SU PPDU using a
beamforming steering matrix derived from a VHT Compressed Beamforming report with
Feedback Type subfield indicating MU in the corresponding VHT Compressed
Beamforming frame sent by the STA.
Set to 0 for NSS = 1
Set to 1 for NSS = 2
…
Set to 7 for NSS = 8
NOTE—In a STA with dot11VHTExtendedNSSBWCapable equal to true, NSS might be
further modified per Table 9-75.
Rx NSS Type Set to 0 to indicate that the Rx NSS subfield carries the maximum number of spatial
streams that the STA can receive in any PPDU.
Set to 1 to indicate that the Rx NSS subfield carries the maximum number of spatial
streams that the STA can receive as a beamformee in an SU PPDU using a beamforming
steering matrix derived from a VHT Compressed Beamforming report with the Feedback
Type subfield indicating MU in the corresponding VHT Compressed Beamforming frame
sent by the STA.
NOTE—An AP always sets this field to 0.
Table 9-75—Setting of the Channel Width subfield and 160/80+80 BW subfield at a VHT STA
transmitting the Operating Mode field
NSS Support of STA transmitting the Location of
Transmitted VHT Capabilities of
Operating Mode field as a function of Location of secondary
Operating Mode STA transmitting the
the PPDU bandwidth (×Max VHT NSS) 160 MHz 80 MHz
field Operating Mode field
(see requirements R1 and R2) center center
frequency if frequency if
BSS BSS
160/ Supported Extended 80
Channel 20 40 80 160 bandwidth bandwidth
80+80 Channel NSS BW +80
width MHz MHz MHz MHz is 160 MHz is 80+80
BW Width Set Support MHz
MHz
0 0 0-2 0-3 1
1 0 0-2 0-3 1 1
2 0 0-2 0-3 1 1 1
2 1 0 1 1 1 1 1/2 CCFS2
780
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-75—Setting of the Channel Width subfield and 160/80+80 BW subfield at a VHT STA
transmitting the Operating Mode field (continued)
NSS Support of STA transmitting the Location of
Transmitted VHT Capabilities of
Operating Mode field as a function of Location of secondary
Operating Mode STA transmitting the
the PPDU bandwidth (×Max VHT NSS) 160 MHz 80 MHz
field Operating Mode field
(see requirements R1 and R2) center center
frequency if frequency if
BSS BSS
160/ Supported Extended 80
Channel 20 40 80 160 bandwidth bandwidth
80+80 Channel NSS BW +80
width MHz MHz MHz MHz is 160 MHz is 80+80
BW Width Set Support MHz
MHz
2 1 0 2 1 1 1 1/2 1/2 CCFS2 CCFS2
2 1 0 3 1 1 1 3/4 3/4 CCFS2 CCFS2
2 1 1 0 1 1 1 1 CCFS1
2 1 1 1 1 1 1 1 1/2 CCFS1 CCFS2
2 1 1 2 1 1 1 1 3/4 CCFS1 CCFS2
2 1 1 3 2 2 2 2 1 CCFS1 CCFS1
2 1 2 0 1 1 1 1 1 CCFS1 CCFS1
2 1 2 3 2 2 2 1 1 CCFS1 CCFS1
R1: NSS support shall be rounded down to the nearest integer.
R2: The maximum NSS support shall be 8.
NOTE 1—Max VHT NSS is defined per MCS in 9.4.2.158.3.
NOTE 2—1/2× or 3/4× Max VHT NSS support might end up being 0, indicating no support.
NOTE 3—Any other combination than the ones listed in this table is reserved.
NOTE 4—CCFS1 refers to the value of the Channel Center Frequency Segment 1 field of the most recently transmitted
VHT Operation element.
NOTE 5—CCFS2 refers to the value of the Channel Center Frequency Segment 2 field of the most recently transmitted
HT Operation element.
NOTE 6—CCFS1 is nonzero when the current BSS bandwidth is 160 MHz or 80+80 MHz and the NSS support is at least
Max VHT NSS. CCFS2 is zero in this case.
NOTE 7—CCFS2 is nonzero when the current BSS bandwidth is 160 MHz or 80+80 MHz and the NSS support is less
than Max VHT NSS. CCFS1 is zero in this case.
NOTE 8—At most one of CCFS1 and CCFS2 is nonzero.
NOTE 9—A supported multiple of Max VHT NSS applies to both transmit and receive.
NOTE 10—Some combinations of Supported Channel Width Set and Extended NSS BW support might not occur in
practice.
NOTE 11—2× Max VHT NSS support might be used for HT PPDUs (at 20 or 40 MHz PPDU bandwidth).
781
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.1.54 Membership Status Array field
The Membership Status Array field is used in the Group ID Management frame (see 9.6.23.3). The length of
the field is 8 octets. An 8 octet Membership Status Array field (indexed by the group ID) consists of a 1-bit
Membership Status subfield for each of the 64 group IDs, as shown in Figure 9-119.
B0 B1 B63
Membership Status Membership Status … Membership Status
In Group ID 0 In Group ID 1 In Group ID 63
Bits: 1 1 1
Figure 9-119—Membership Status Array field
Within the 8 octet Membership Status Array field, the 1-bit Membership Status subfield for each group ID is
set as follows:
— Set to 0 if the STA is not a member of the group
— Set to 1 if STA is a member of the group
The Membership Status subfields for group ID 0 (transmissions to AP) and group ID 63 (downlink SU
transmissions) are reserved.
9.4.1.55 User Position Array field
The User Position Array field is used in the Group ID Management frame (see 9.6.23.3). The length of the
field is 16 octets. A 16 octet User Position Array field (indexed by the Group ID) consists of a 2-bit User
Position subfield for each of the 64 group IDs, as shown in Figure 9-120.
B0 B1 B2 B3 B126 B127
User Position In User Position In User Position In
Group ID 0 Group ID 1 … Group ID 63
Bits: 2 2 2
Figure 9-120—User Position Array field
If the Membership Status subfield for a particular group ID is 1, then the corresponding User Position
subfield in the User Position Array field contains the group ID’s User Position.
If the Membership Status subfield for a group ID is 0 (meaning the STA is not a member of that group), then
the corresponding User Position subfield in the User Position Array field is reserved.
The User Position subfields for group ID 0 (transmissions to AP) and group ID 63 (downlink SU
transmissions) are reserved.
9.4.1.56 Device Location Information Body field
A Device Location Information Body field includes the location configuration information (LCI), which
contains latitude, longitude, and altitude information.
782
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The format of the Device Location Information Body field is shown in Figure 9-121.
B0 B5 B6 B39 B40 B45 B46 B79
Latitude Latitude Longitude Longitude
Uncertainty Uncertainty
Bits: 6 34 6 34
B80 B83 B84 B89 B90 B119
Altitude Type Altitude Altitude
Uncertainty
Bits: 4 6 30
B120 B122 B123 B124 B125 B126 B127
Datum RegLoc RegLoc DSE Dependent STA Version
Agreement
Bits: 3 1 1 1 2
Figure 9-121—Device Location Information Body field format
The fields within the Device Location Information Body field are as defined in section 2.2 of IETF
RFC 6225 except as defined in 9.4.2.52, and RegLoc Agreement and RegLoc DSE are set to 0.
9.4.1.57 WSM Type field and WSM Information field
The WSM Type field is set to a number that identifies the type of WSM information and the frequency band
where the following WSM Information field is applicable. The values of WSM Types are shown in Table 9-
76. A WSM Type field value of 1 indicates the WSM Information field of the WSM element contains
available frequency information for operation in the TVWS. Other values are reserved.
Table 9-76—WSM Type definition
Name WSM Type
Reserved 0
TV band WSM 1
Reserved 2–255
The WSM Information field indicates the available channel information as defined in 9.4.4.2.5.
The WSM Information field corresponding to a TV band WSM is shown in Table 9-269.
783
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2 Elements
9.4.2.1 General
Elements are defined to have a common general format consisting of a 1 octet Element ID field, a 1 octet
Length field, an optional 1 octet Element ID Extension field, and a variable-length element-specific
Information field. Each element is identified by the contents of the Element ID and, when present, Element
ID Extension fields as defined in this standard. An Extended Element ID is a combination of an Element ID
and an Element ID Extension for those elements that have a defined Element ID Extension. The Length field
specifies the number of octets following the Length field. See Figure 9-122. The presence of the Element ID
Extension field is determined by the Element ID field.
Element ID Length Element ID Information
Extension
Octets: 1 1 0 or 1 variable
Figure 9-122—Element format
The set of valid elements is defined in Table 9-77.
Table 9-77—Element IDs
Element ID
Element Element ID Extensible
Extension
SSID (see 9.4.2.2) 0 N/A
Supported Rates and BSS Membership Selectors 1 N/A
(see 9.4.2.3)
Reserved 2
DSSS Parameter Set (see 9.4.2.4) 3 N/A
CF Parameter Set (see 9.4.2.5) 4 N/A
TIM (see 9.4.2.6) 5 N/A
IBSS Parameter Set (see 9.4.2.7) 6 N/A
Country (see 9.4.2.9) 7 N/A
Reserved 8
Reserved 9
Request (see 9.4.2.10) 10 N/A
BSS Load (see 9.4.2.28) 11 N/A
EDCA Parameter Set (see 9.4.2.29) 12 N/A
TSPEC (see 9.4.2.30) 13 N/A In a non-DMG BSS:
no
In a DMG BSS: yes
TCLAS (see 9.4.2.31) 14 N/A
Schedule (see 9.4.2.34) 15 N/A
Challenge text (see 9.4.2.8) 16 N/A
Reserved 17–31 N/A
Power Constraint (see 9.4.2.14) 32 N/A
784
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-77—Element IDs (continued)
Element ID
Element Element ID Extensible
Extension
Power Capability (see 9.4.2.15) 33 N/A
TPC Request (see 9.4.2.16) 34 N/A
TPC Report (see 9.4.2.17) 35 N/A
Supported Channels (see 9.4.2.18) 36 N/A
Channel Switch Announcement (see 9.4.2.19) 37 N/A
Measurement Request (see 9.4.2.21) 38 N/A Subelements, for
formats using
9.4.2.21.4 to
9.4.2.21.12.
Measurement Report (see 9.4.2.22) 39 N/A Subelements, for
formats using
9.4.2.22.4 to
9.4.2.22.11.
Quiet (see 9.4.2.23) 40 N/A
IBSS DFS (see 9.4.2.24) 41 N/A
ERP (see 9.4.2.12) 42 N/A Yes
TS Delay (see 9.4.2.32) 43 N/A
TCLAS Processing (see 9.4.2.33) 44 N/A
HT Capabilities (see 9.4.2.56) 45 N/A Yes
QoS Capability (see 9.4.2.35) 46 N/A
Reserved 47
RSN (see 9.4.2.25) 48 N/A Yes
Reserved 49
Extended Supported Rates and BSS Membership 50 N/A
Selectors (see 9.4.2.13)
AP Channel Report (see 9.4.2.36) 51 N/A
Neighbor Report (see 9.4.2.37) 52 N/A Subelements
RCPI (see 9.4.2.38) 53 N/A Yes
Mobility Domain (MDE) (see 9.4.2.47) 54 N/A No
Fast BSS Transition (FTE) (see 9.4.2.48) 55 N/A
Timeout Interval (see 9.4.2.49) 56 N/A
RIC Data (RDE) (see 9.4.2.50) 57 N/A
DSE Registered Location (see 9.4.2.52) 58 N/A
Supported Operating Classes (see 9.4.2.54) 59 N/A
Extended Channel Switch Announcement 60 N/A
(see 9.4.2.53)
HT Operation (see 9.4.2.57) 61 N/A Yes
Secondary Channel Offset (see 9.4.2.20) 62 N/A
785
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-77—Element IDs (continued)
Element ID
Element Element ID Extensible
Extension
BSS Average Access Delay (see 9.4.2.39) 63 N/A Yes
Antenna (see 9.4.2.40) 64 N/A Yes
RSNI (see 9.4.2.41) 65 N/A Yes
Measurement Pilot Transmission (see 9.4.2.42) 66 N/A Subelements
BSS Available Admission Capacity 67 N/A Yes
(see 9.4.2.43)
BSS AC Access Delay (see 9.4.2.44) 68 N/A Yes
Time Advertisement (see 9.4.2.61) 69 N/A Yes
RM Enabled Capabilities (see 9.4.2.45) 70 N/A Yes
Multiple BSSID (see 9.4.2.46) 71 N/A Subelements
20/40 BSS Coexistence (see 9.4.2.60) 72 N/A Yes
20/40 BSS Intolerant Channel Report 73 N/A
(see 9.4.2.58)
Overlapping BSS Scan Parameters (see 9.4.2.59) 74 N/A
RIC Descriptor (see 9.4.2.51) 75 N/A
Management MIC (see 9.4.2.55) 76 N/A
Event Request (see 9.4.2.67) 78 N/A Subelements
Event Report (see 9.4.2.68) 79 N/A
Diagnostic Request (see 9.4.2.69) 80 N/A Subelements
Diagnostic Report (see 9.4.2.70) 81 N/A Subelements
Location Parameters (see 9.4.2.71) 82 N/A Subelements
Nontransmitted BSSID Capability (see 9.4.2.72) 83 N/A
SSID List (see 9.4.2.73) 84 N/A
Multiple BSSID-Index (see 9.4.2.74) 85 N/A
FMS Descriptor (see 9.4.2.75) 86 N/A
FMS Request (see 9.4.2.76) 87 N/A Subelements
FMS Response (see 9.4.2.77) 88 N/A Subelements
QoS Traffic Capability (see 9.4.2.78) 89 N/A Yes
BSS Max Idle Period (see 9.4.2.79) 90 N/A Yes
TFS Request (see 9.4.2.80) 91 N/A Subelements
TFS Response (see 9.4.2.81) 92 N/A Subelements
WNM Sleep Mode (see 9.4.2.82) 93 N/A Yes
TIM Broadcast Request (see 9.4.2.83) 94 N/A Yes
TIM Broadcast Response (see 9.4.2.84) 95 N/A Yes
Collocated Interference Report (see 9.4.2.85) 96 N/A Yes
Channel Usage (see 9.4.2.86) 97 N/A Subelements
786
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-77—Element IDs (continued)
Element ID
Element Element ID Extensible
Extension
Time Zone (see 9.4.2.87) 98 N/A Yes
DMS Request (see 9.4.2.88) 99 N/A Subelements
DMS Response (see 9.4.2.89) 100 N/A Subelements
Link Identifier (see 9.4.2.62) 101 N/A Yes
Wakeup Schedule (see 9.4.2.63) 102 N/A Yes
Channel Switch Timing (see 9.4.2.64) 104 N/A Yes
PTI Control (see 9.4.2.65) 105 N/A Yes
TPU Buffer Status (see 9.4.2.66) 106 N/A Yes
Interworking (see 9.4.2.92) 107 N/A
Advertisement Protocol (see 9.4.2.93) 108 N/A
Expedited Bandwidth Request (see 9.4.2.94) 109 N/A
QoS Map (see 9.4.2.95) 110 N/A Yes
Roaming Consortium (see 9.4.2.96) 111 N/A Yes
Emergency Alert Identifier (see 9.4.2.97) 112 N/A
Mesh Configuration (see 9.4.2.98 113 N/A Yes
Mesh ID (see 9.4.2.99 114 N/A
Mesh Link Metric Report (see 9.4.2.100) 115 N/A
Congestion Notification (see 9.4.2.101) 116 N/A Yes
Mesh Peering Management (see 9.4.2.102) 117 N/A Yes
Mesh Channel Switch Parameters (see 9.4.2.103) 118 N/A Yes
Mesh Awake Window (see 9.4.2.104) 119 N/A Yes
Beacon Timing (see 9.4.2.105) 120 N/A
MCCAOP Setup Request (see 9.4.2.106) 121 N/A Yes
MCCAOP Setup Reply (see 9.4.2.107) 122 N/A
MCCAOP Advertisement (see 9.4.2.109) 123 N/A Yes
MCCAOP Teardown (see 9.4.2.110) 124 N/A Yes
GANN (see 9.4.2.111) 125 N/A Yes
RANN (see 9.4.2.112) 126 N/A Yes
Extended Capabilities (see 9.4.2.27) 127 N/A Yes
Reserved 128–129
PREQ (see 9.4.2.113) 130 N/A Yes
PREP (see 9.4.2.114) 131 N/A Yes
PERR (see 9.4.2.115) 132 N/A Yes
Reserved 133–136
PXU (see 9.4.2.116) 137 N/A Yes
PXUC (see 9.4.2.117) 138 N/A Yes
787
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-77—Element IDs (continued)
Element ID
Element Element ID Extensible
Extension
Authenticated Mesh Peering Exchange 139 N/A
(see 9.4.2.118)
MIC (see 9.4.2.119) 140 N/A
Destination URI (see 9.4.2.90) 141 N/A Yes
U-APSD Coexistence (see 9.4.2.91) 142 N/A Subelements
DMG Wakeup Schedule (see 9.4.2.131) 143 N/A Yes
Extended Schedule (see 9.4.2.132) 144 N/A Yes
STA Availability (see 9.4.2.133) 145 N/A Yes
DMG TSPEC (see 9.4.2.134) 146 N/A Yes
Next DMG ATI (see 9.4.2.135) 147 N/A Yes
DMG Capabilities (see 9.4.2.128) 148 N/A Yes
Reserved 149–150
DMG Operation (see 9.4.2.129 151 N/A Yes
DMG BSS Parameter Change (see 9.4.2.127) 152 N/A Yes
DMG Beam Refinement (see 9.4.2.130) 153 N/A Yes
Channel Measurement Feedback (see 154 N/A Yes
9.4.2.136)
Reserved 155–156
Awake Window (see 9.4.2.137) 157 N/A Yes
Multi-band (see 9.4.2.138) 158 N/A Yes
ADDBA Extension (see 9.4.2.139) 159 N/A Yes
NextPCP List (see 9.4.2.140) 160 N/A Yes
PCP Handover (see 9.4.2.141) 161 N/A Yes
DMG Link Margin (see 9.4.2.142) 162 N/A Yes
Switching Stream (see 9.4.2.144) 163 N/A Yes
Session Transition (see 9.4.2.145) 164 N/A Yes
Dynamic Tone Pairing Report (see 9.4.2.146) 165 N/A Yes
Cluster Report (see 9.4.2.147) 166 N/A Yes
Relay Capabilities (see 9.4.2.148) 167 N/A Yes
Relay Transfer Parameter Set (see 9.4.2.149) 168 N/A Yes
BeamLink Maintenance (see 9.4.2.152) 169 N/A Yes
Multiple MAC Sublayers (see 9.4.2.153) 170 N/A Yes
U-PID (see 9.4.2.154) 171 N/A Yes
DMG Link Adaptation Acknowledgment 172 N/A Yes
(see 9.4.2.143)
Reserved 173
788
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-77—Element IDs (continued)
Element ID
Element Element ID Extensible
Extension
MCCAOP Advertisement Overview (see 174 N/A Yes
9.4.2.108)
Quiet Period Request (see 9.4.2.150) 175 N/A Yes
Reserved 176
Quiet Period Response (see 9.4.2.151) 177 N/A Yes
Reserved 178–180
QMF Policy (see 9.4.2.120) 181 N/A
ECAPC Policy (see 9.4.2.155) 182 N/A Yes
Cluster Time Offset (see 9.4.2.156) 183 N/A Yes
Intra-Access Category Priority (see 9.4.2.121) 184 N/A Yes
SCS Descriptor (see 9.4.2.122) 185 N/A Subelements
QLoad Report (see 9.4.2.123) 186 N/A Subelements
HCCA TXOP Update Count (see 9.4.2.124) 187 N/A No
Higher Layer Stream ID (see 9.4.2.125) 188 N/A Yes
GCR Group Address (see 9.4.2.126) 189 N/A No
Antenna Sector ID Pattern (see 9.4.2.157) 190 N/A Yes
VHT Capabilities (see 9.4.2.158) 191 N/A Yes
VHT Operation (see 9.4.2.159) 192 N/A Yes
Extended BSS Load (see 9.4.2.160) 193 N/A Yes
Wide Bandwidth Channel Switch (see 9.4.2.161) 194 N/A Yes
Transmit Power Envelope (see 9.4.2.162) 195 N/A Yes
Channel Switch Wrapper (see 9.4.2.163) 196 N/A Subelements
AID (see 9.4.2.164) 197 N/A
Quiet Channel (see 9.4.2.165) 198 N/A Yes
Operating Mode Notification (see 9.4.2.166) 199 N/A Yes
UPSIM (see 9.4.2.167) 200 N/A Yes
Reduced Neighbor Report (see 9.4.2.171) 201 N/A Yes
TVHT Operation (see 9.4.2.172) 202 N/A Yes
Reserved 203
Device Location (see 9.4.2.169) 204 N/A Yes
White Space Map (see 9.4.2.170) 205 N/A Yes
Fine Timing Measurement Parameters (see 206 N/A Yes
9.4.2.168)
Reserved 207–220
Vendor Specific (see 9.4.2.26) 221 N/A
Reserved 222–254
789
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-77—Element IDs (continued)
Element ID
Element Element ID Extensible
Extension
Reserved for elements using the Element ID 255 0–8
Extension field
FTM Synchronization Information 255 9 Yes
Extended Request 255 10
Estimated Service Parameters (see 9.4.2.174) 255 11 Yes
Future Channel Guidance 255 14
Reserved for elements using the Element ID 255 12–255
Extension field
The frame body components specified for many management subtypes result in elements ordered by
ascending values of the Element ID field and then the Element ID Extension field (when present), with the
exception of the MIC Management element (9.4.2.55). If present, the MIC Management element appears at
the end of the robust management frame body. See 10.27.6 on the parsing of elements.
A “Yes” in the Extensible column of an element listed in Table 9-77 indicates that the Length of the element
might be extended in future revisions or amendments of this standard. See 10.27.8. When the Extensible
column of an element is set to “Subelements,” then the element might be extended in future revisions or
amendments of this standard by defining additional subelements. See 10.27.9.
The element is not extensible otherwise (i.e., if not marked as “Yes” or “Subelements”).
9.4.2.2 SSID element
The SSID element indicates the identity of an ESS or IBSS. See Figure 9-123.
Element ID Length SSID
Octets: 1 1 0–32
Figure 9-123—SSID element format
The Element ID and Length fields are defined in 9.4.2.1.
The length of the SSID field is between 0 and 32 octets. A SSID field of length 0 is used within Probe
Request frames to indicate the wildcard SSID. The wildcard SSID is also used in Beacon and Probe
Response frames transmitted by mesh STAs.
When the UTF-8 SSID subfield of the Extended Capabilities element is equal to 1 in the frame that includes
the SSID element, or the Extended Capabilities of the source of the SSID information is known to include
the UTF-8 SSID capability based on a previously received Extended Capabilities element, the SSID is
interpreted using UTF-8 encoding. Otherwise, the character encoding of the octets in this SSID element is
unspecified.
9.4.2.3 Supported Rates and BSS Membership Selectors element
The Supported Rates and BSS Membership Selectors element specifies up to eight rates in the
OperationalRateSet parameter, as described in the MLME-JOIN.request and MLME-START.request
790
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
primitives, and zero or more BSS membership selectors. The Information field is encoded as 1 to 8 octets,
where each octet describes a single supported rate or BSS membership selector (see Figure 9-124).
Element ID Length Supported Rates
Octets: 1 1 1–8
Figure 9-124—Supported Rates and BSS Membership Selectors element format
The Element ID and Length fields are defined in 9.4.2.1.
Within Beacon, Probe Response, Association Response, Reassociation Response, Mesh Peering Open, and
Mesh Peering Confirm frames, each rate contained in the BSSBasicRateSet parameter is encoded as an octet
with the MSB (bit 7) set to 1, and bits 6 to 0 are set to the data rate, if necessary rounded up to the next 500
kb/s, in units of 500 kb/s (e.g., a 2.25 Mb/s rate contained in the BSSBasicRateSet parameter is encoded as
X'85'). Each rate in the OperationalRateSet parameter not contained in the BSSBasicRateSet parameter is
encoded with the MSB set to 0, and bits 6 to 0 are set in the same way as for a rate contained in the
BSSBasicRateSet parameter (e.g., a 2 Mb/s rate not contained in the BSSBasicRateSet parameter is encoded
as X'04').
Within Beacon, Probe Response, Association Response, Reassociation Response, Mesh Peering Open, and
Mesh Peering Confirm frames, each BSS membership selector contained in the BSSMembershipSelectorSet
parameter is encoded as an octet with the MSB (bit 7) set to 1, and bits 6 to 0 are set to the encoded value for
the selector as found in Table 9-78 (e.g., an HT PHY BSS membership selector contained in the
BSSMembershipSelectorSet parameter is encoded as X'FF'). A BSS membership selector that has the MSB
(bit 7) set to 1 in the Supported Rates and BSS Membership Selectors element is defined to be basic.
The MSB of each octet in the Supported Rates field in other management frame types is ignored by
receiving STAs.
The valid values for BSS membership selectors and their associated features are shown in Table 9-78.
NOTE—Because the BSS membership selector and supported rates are carried in the same field, the BSS membership
selector value cannot match the value corresponding to any valid supported rate. This allows any value to be determined
as either a supported rate or a BSS membership selector.
Table 9-78—BSS membership selector value encoding
Value Feature Interpretation
127 HT PHY Support for the mandatory features of Clause 19 is required in order
to join the BSS that was the source of the Supported Rates and BSS
Membership Selectors element or Extended Supported Rates and
BSS Membership Selectors element containing this value.
126 VHT PHY Support for the mandatory features of Clause 21 is required in order
to join the BSS that was the source of the Supported Rates and BSS
Membership Selectors element or Extended Supported Rates and
BSS Membership Selectors element containing this value.
See 11.1.4.6.
791
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.4 DSSS Parameter Set element
The DSSS Parameter Set element contains information to allow channel number identification for STAs.
See Figure 9-125.
Element ID Length Current Channel
Octets: 1 1 1
Figure 9-125—DSSS Parameter Set element format
The Element ID and Length fields are defined in 9.4.2.1.
The Current Channel field is set to dot11CurrentChannel (see 15.4.4.3, 16.3.6.3, 17.3.8.4.2 and 19.3.15 for
values).
9.4.2.5 CF Parameter Set element
The PCF mechanism is obsolete. Consequently, this subclause might be removed in a later revision of the
standard.
The CF Parameter Set element contains the set of parameters necessary to support the PCF. See
Figure 9-126.
Element ID Length CFP Count CFP Period CFP MaxDuration CFP DurRemaining
Octets: 1 1 1 1 2 2
Figure 9-126—CF Parameter Set element format
The Element ID and Length fields are defined in 9.4.2.1.
The CFPCount field indicates how many delivery traffic indication maps (DTIMs) (including the current
frame) appear before the next CFP start. A CFPCount of 0 indicates that the current DTIM marks the start of
the CFP.
The CFPPeriod field indicates the number of DTIM intervals between the start of CFPs. The value is an
integer number of DTIM intervals.
The CFPMaxDuration field indicates the maximum duration, in TU, of the CFP that might be generated by
this PCF. This value is used by STAs to set their NAV at the TBTT of Beacon frames that begin CFPs.
The CFPDurRemaining field indicates the maximum time, in TU, remaining in the present CFP and is set to
0 in CFP Parameter elements of Beacon frames transmitted during the CP. The value of CFPDurRemaining
is referenced to the immediately previous TBTT. This value is used by all STAs to update their NAVs
during CFPs.
9.4.2.6 TIM element
The TIM element contains four fields: DTIM Count, DTIM Period, Bitmap Control, and Partial Virtual
Bitmap. See Figure 9-127.
792
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Element ID Length DTIM Count DTIM Period Bitmap Control Partial Virtual Bitmap
Octets: 1 1 1 1 1 1–251
Figure 9-127—TIM element format
The Element ID and Length fields are defined in 9.4.2.1.
The Length field for this element is constrained as described below.
The DTIM Count field indicates how many Beacon frames (including the current frame) appear before the
next DTIM. A DTIM count of 0 indicates that the current TIM is a DTIM. The DTIM Count field is a
single octet. When a TIM element is included in a TIM frame, the DTIM Count field is reserved.
The DTIM Period field indicates the number of beacon intervals between successive DTIMs. If all TIMs are
DTIMs, the DTIM Period field has the value 1. The DTIM Period value 0 is reserved. The DTIM period
field is a single octet.
The Bitmap Control field is a single octet. Bit 0 of the field contains the traffic indication virtual bitmap bit
associated with AID 0. This bit is set to 1 in TIM elements with a value of 0 in the DTIM Count field when
one or more group addressed MSDUs/MMPDUs are buffered at the AP or the mesh STA. The remaining 7
bits of the field form the Bitmap Offset.
The traffic indication virtual bitmap, maintained by the AP or the mesh STA that generates a TIM, consists
of 2008 bits, and it is organized into 251 octets such that bit number N (0 N 2007) in the bitmap
corresponds to bit number (N mod 8) in octet number N / 8 where the low-order bit of each octet is bit
number 0, and the high order bit is bit number 7. Each bit in the traffic indication virtual bitmap corresponds
to traffic buffered for a specific neighbor peer mesh STA within the MBSS that the mesh STA is prepared to
deliver23 or for a STA within the BSS that the AP is prepared to deliver at the time the Beacon frame is
transmitted. Bit number N indicates the status of buffered, individually addressed MSDUs/MMPDUs for the
STA whose AID is N. It is determined as follows:
— If the STA is not using APSD, and any individually addressed MSDUs/MMPDUs for that STA are
buffered and the AP or the mesh STA is prepared to deliver them, then bit number N in the traffic
indication virtual bitmap is 1.
— If the STA is using APSD, and any individually addressed MSDUs/MMPDUs for that STA are
buffered in at least one nondelivery-enabled AC (if there exists at least one nondelivery-enabled
AC), then bit number N in the traffic indication virtual bitmap is 1.
— If the STA is using APSD, all ACs are delivery-enabled, and any individually addressed MSDUs/
MMPDUs for that STA are buffered in any AC, then bit number N in the traffic indication virtual
bitmap is 1.
— Otherwise, bit number N in the traffic indication virtual bitmap is 0.
A PC might decline to set bits in the TIM for CF-Pollable STAs it does not intend to poll (see 11.2.3.7).
When dot11MultiBSSIDActivated is false, the Partial Virtual Bitmap field consists of octets numbered N1
to N2 of the traffic indication virtual bitmap, where N1 is the largest even number such that bits numbered 1
to (N1 8) – 1 in the traffic indication virtual bitmap are all 0 and N2 is the smallest number such that bits
numbered (N2 + 1) 8 to 2007 in the traffic indication virtual bitmap are all 0. In this case, the Bitmap
Offset subfield value contains the number N1/2, and the Length field is set to (N2 – N1) + 4.
NOTE—The bit numbered 0 in the traffic indication virtual bitmap need not be included in the Partial Virtual Bitmap
field even if that bit is set.
23
How the AP or mesh STA determines the traffic is prepared to deliver is outside the scope of this standard.
793
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In the event that all bits other than bit 0 in the traffic indication virtual bitmap are 0, the Partial Virtual
Bitmap field is encoded as a single octet equal to 0, the Bitmap Offset subfield is 0, and the Length field is 4.
When dot11MultiBSSIDActivated is true, the Partial Virtual Bitmap field of the TIM element is constructed
as follows, where the maximum possible number of BSSIDs is an integer power of 2, n = log2 (maximum
possible number of BSSIDs), k is the number of actually supported nontransmitted BSSIDs, and k (2n – 1).
— The bits 1 to k of the bitmap are used to indicate that one or more group addressed frames are
buffered for each AP corresponding to a nontransmitted BSSID. The AIDs from 1 to k are not
allocated to a STA. The AIDs from (k + 1) to (2n – 1) are reserved and set to 0. The remaining AIDs
are shared by the BSSs corresponding to the transmitted BSSID and all nontransmitted BSSIDs.
— When the DTIM Count field is 0 for a BSS that has a nontransmitted BSSID, and one or more group
addressed frames are buffered at the AP for this BSS, the corresponding bits from bit 1 to bit k is set
to 1.
— Each bit starting from bit 2n in the traffic indication virtual bitmap corresponds to individually
addressed traffic buffered for a specific STA within any BSS corresponding to a transmitted or
nontransmitted BSSID at the time the Beacon frame is transmitted. The correspondence is based on
the AID of the STA.
— Based upon its knowledge of the capability of associated stations to support the multiple BSSID
capability, as indicated by the corresponding field in the Extended Capabilities element and the
content of the traffic indication virtual bitmap, an AP encodes the Partial Virtual Bitmap and the
Bitmap Control field of the TIM element using one of the two following methods. Specifically, an
AP uses Method B when it determines that the bit for each associated non-AP STA in the traffic
indication virtual bitmap that is reconstructed by each non-AP STA from the received TIM element
encoded using Method B is set correctly. Otherwise, an AP uses Method A.
Method A and Method B are described as follows:
a) Method A: The Partial Virtual Bitmap field consists of octets numbered 0 to N2 of the traffic
indication virtual bitmap, where N2 is the smallest number such that bits numbered (N2 + 1) × 8 to
2007 in the traffic indication virtual bitmap are all 0. If such a value N2 does not exist, that is, when
not all bits in the last octet of the traffic indication virtual bitmap are equal to 0, N2 = 250. When
using this method, the Bitmap Offset subfield value always contains the number 0, and the Length
field is N2 + 4.
b) Method B: The Partial Virtual Bitmap field consists of a concatenation of octets numbered 0 to
N0 – 1 and octets numbered N1 to N2 of the traffic indication virtual bitmap, where N0 is the
smallest positive integer such that N0 × 8 – 2n < 8. If N0 is an odd number, then N1 is the largest odd
number such that N0 < N1and each of the bits N0 × 8 to (N1 × 8 – 1) is equal to 0. When N0 is an
even number, N1 is the largest even number such that N0 < N1 and each of the bits N0 × 8 to
(N1 × 8 – 1) is equal to 0. If such a value N1 > N0 does not exist, N1 = N0. Additionally, N2 is the
smallest integer value for which the values for bit (N2+1) × 8 to 2007 in the traffic indication virtual
bitmap are all 0. If such a value N2 does not exist, that is, when not all bits in the last octet of the
traffic indication virtual bitmap are equal to 0, N2 = 250. When using this method, the Bitmap Offset
subfield contains the value of (N1 – N0)/2, and the Length field is N0 + N2 – N1 + 4.
NOTE—When N1 = N0, Method B reduces to Method A.
For both Method A and Method B, when there are no frames buffered for any BSS corresponding to a
transmitted or nontransmitted BSSID supported, the Partial Virtual Bitmap field is encoded as a single octet
equal to 0, the Bitmap Offset subfield is 0, and the Length field is 4. When there are no buffered individually
addressed frames for any BSS corresponding to a transmitted or nontransmitted BSSID, but there are
buffered group addressed frames for one or more of the BSSs, the Partial Virtual Bitmap field consists of the
octets number 0 to N0 – 1 where N0 is the smallest positive integer such that (N0 × 8 – 2n < 8). In this case,
the Bitmap Offset subfield value contains the number 0, and the Length field is N0+3.
794
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.7 IBSS Parameter Set element
The IBSS Parameter Set element contains the set of parameters necessary to support an IBSS. See
Figure 9-128.
Element ID Length ATIM Window
Octets: 1 1 2
Figure 9-128—IBSS Parameter Set element format
The Element ID and Length fields are defined in 9.4.2.1.
The ATIM Window field contains the ATIM window length in TU.
9.4.2.8 Challenge Text element
The Challenge Text element contains the challenge text within Authentication exchanges. See Figure 9-129.
Element ID Length Challenge Text
Octets: 1 1 1–253
Figure 9-129—Challenge Text element format
The Element ID and Length fields are defined in 9.4.2.1.
The content of the Challenge Text field is dependent upon the authentication algorithm and the transaction
sequence number as specified in 12.3.3.2.
9.4.2.9 Country element
The Country element contains the information required to allow a STA to identify the regulatory domain in
which the STA is located and to configure its PHY for operation in that regulatory domain. The format of
this element is as shown in Figure 9-130.
Element ID Length Country String Triplet Padding (if
needed)
Octets: 1 1 3 Q×3 0 or 1
Figure 9-130—Country element format
The Element ID and Length fields are defined in 9.4.2.1. The length of the element is variable, as the
element contains the variable-length Triplet field.
The Country String field is 3 octets in length. The AP and mesh STA set this field to the value contained in
dot11CountryString before transmission in a Beacon or Probe Response frame. Upon reception of this
element, a STA sets the value of the dot11CountryString to the value contained in this field. The three octets
of the Country String have additional structure as defined by dot11CountryString (see Annex C).
If dot11OperatingClassesRequired is false, then the Triplet field is a single Subband Triplet Sequence field,
as shown in Figure 9-131, that is composed of Q Subband Triplet fields, where Q is one or more. The format
of the Subband Triplet field is shown in Figure 9-132.
795
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
One or more
Subband
Triplet
Octets: 3
Figure 9-131—Subband Triplet Sequence format
Maximum
First Channel Number of Transmit
Number Channels
Power Level
Octets: 1 1 1
Figure 9-132—Subband Triplet field
If dot11OperatingClassesRequired is true, then the Triplet field is composed of zero or more Subband
Triplet fields followed by one or more Operating/Subband Sequences, as shown in Figure 9-133. Each
Operating/Subband Sequence is composed of one Operating Triplet field followed by one Subband Triplet
Sequence field, as shown in Figure 9-134. Each Subband Triplet Sequence field is composed of zero or
more Subband Triplet fields. If dot11OperatingClassesRequired is true, the number of triplets in the Triplet
M
field is Q = N + 1 + P(m) , where N is the total number of Subband Triplet fields and M is the total
m=1
number of Operating/Subband Sequences contained in Country element and P(m) is the number of Subband
Triplet fields making up Operating/Subband Sequence field m.
Zero or more One or more indexed by
m = 1 2 M; M 1
Operating/Subband
Subband Triplet Sequence
Octets: 3 3
Figure 9-133—Triplet field if dot11OperaratingClassRequired is true
Operating Triplet
Subband Triplet Sequence
Operating made up of P(m) Subband
Extension Operating Coverage Triplet fields, where P(m) 0
Class Class
Identifier
Octets: 1 1 1 3P(m)
Figure 9-134—Format of m-th Operating/Subband Sequence field
The number Q of Subband fields or Operating triplet fields in the element is determined by the Length field.
An operating class for an 80+80 MHz channel width is expressed by two consecutive Operating/Subband
Sequences, where the first Operating/Subband Sequence field contains an Operating Triplet field indicating
an 80 MHz Channel Spacing with an 80+ behavior limit and the second Operating/Subband Sequence field
contains an Operating Triplet field indicating an 80 MHz Channel Spacing without an 80+ behavior limit.
796
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Operating/Subband Sequence fields that contain an Operating Class field for which the “Channel Spacing
(MHz)” column in the appropriate table in Annex E equals 80 or 160 contain zero Subband Triplet fields.
NOTE 1—Any Operating Triplet field indicating 80 MHz, 160 MHz, and 80+80 MHz can be omitted from the Country
element (see 10.21.3).
NOTE 2—The Transmit Power Envelope element is always used for TPC for 80 MHz, 160 MHz, or 80+80 MHz
operating classes instead of Subband Triplet fields (see 11.40.1).
The first octet in each Subband Triplet field or Operating Triplet field contains an unsigned integer and
identifies the type of field. If the integer has a value less than or equal to 200, then the field is a Subband
Triplet field. If the integer has a value of 201 or greater, then the field is an Operating Triplet field.
The minimum length of the element is 8 octets.
The First Channel Number field indicates the lowest channel number in the Subband Triplet field. No
channel is indicated by more than one pair of First Channel Number and Number of Channels fields within a
Subband Triplet Sequence field. [For example, the (First Channel Number, Number of Channels) pairs (2,4)
and (5,2) in 2.4 GHz each indicate channel 5, therefore are not used within the same Subband Triplet
Sequence field.] The First Channel Numbers are monotonically increasing within a Subband Triplet
Sequence field. The First Channel Number and the Number of Channels pairs in a Country element are used
to describe channels only in the band on which the frame containing the element is transmitted.
The Number of Channels subfield of the subelement is 1 octet in length. Outside the 2.4 GHz band, the
channel numbers that are included in a group of channels are separated by the BSS bandwidth. For Subband
Triplet fields that are not within an Operating/Subband Sequence field, the BSS bandwidth is 20 MHz. For
Subband Triplet fields that are within an Operating/Subband Sequence field, the BSS bandwidth is as
indicated by the operating class in the same Operating/Subband Sequence field. In the 2.4 GHz band, the
channel numbers that are included in a group of channels are separated by 5 MHz (for both 20 and 40 MHz
BSS bandwidth), except that channel 14 is treated as if it were 5 MHz above channel 13.
NOTE—For example, the channels 1 to 11 in the 2.4 GHz band can be represented using one Subband Triplet subfield
with First Channel Number = 1 and Number of Channels = 11. The channels 36, 40, 44 and 48 with 20 MHz BSS
bandwidth in the 5 GHz band can be represented using one Subband Triplet subfield with First Channel Number = 36
and Number of Channels = 4. The six channels 183, 184, 185, 187, 188 and 189 (but not 186) with 10 MHz BSS
bandwidth can be represented using three Subband Triplet subfields: one with First Channel Number = 183 and Number
of Channels = 4, one with First Channel Number = 184 and Number of Channels = 1 and one with First Channel Number
= 188 and Number of Channels = 1.
The Maximum Transmit Power Level field is a signed number and is 1 octet in length. The Maximum
Transmit Power Level field indicates the maximum power, in dBm, allowed to be transmitted. As the
method of measurement for maximum transmit power level differs by regulatory domain, the value in this
field is interpreted according to the regulations applicable for the domain identified by the Country String.
An operating class is an index into a set of values for radio equipment sets of rules. The Operating Class
field is 1 octet in length.
A coverage class is an index into a set of values for aAirPropagationTime. The Coverage Class field is
reserved in a DMG BSS. The Coverage Class field is 1 octet in length.
The Coverage Class field of the Operating Triplet field specifies the aAirPropagationTime characteristic
used in BSS operation, as shown in Table 9-79. The characteristic aAirPropagationTime describes variations
in actual propagation time that are accounted for in a BSS and, together with maximum transmit power
level, allow control of BSS diameter.
The Padding field is 0 or 1 octet in length. The Padding field is used to add, if needed, a single octet (with
the value 0) to the Country element so that its length is evenly divisible by 2.
797
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-79—Coverage Class field parameters
Coverage class aAirPropagationTime
value (µs)
0–31 n 3 , where n is the
value of the coverage
class
32–255 Reserved
9.4.2.10 Request element
This element is placed in a Probe Request frame or Information Request frame to request that the responding
STA include the requested information in the Probe Response frame or Information Response frame,
respectively. The format of the element is as shown in Figure 9-135.
Element ID Length Requested Element IDs
Octets: 1 1 variable
Figure 9-135—Request element
The Element ID and Length fields are defined in 9.4.2.1.
The Requested Element IDs are the list of elements that are requested to be included in the Probe Response
or Information Response frame. The Requested Element IDs are listed in order of increasing element ID.
The Requested Element IDs within a Request element transmitted in an Information Request frame do not
include an element ID that corresponds to an element that will be included in the Information Response
frame even in the absence of the Request element, as shown in Table 9-390. A given element ID is included
at most once among the Requested Element IDs.
NOTE—Some implementations might unnecessarily include in a Probe Request frame a Request element that contains
the element ID of an element that will be included in the Probe Response frame even in the absence of the element ID in
the Request element; see the notes in Table 9-34. Some implementations might include in a Probe Request frame a
Request element that contains the element ID of an element that will not be included in the Probe Response frame even
in the presence of the element ID in the Request element.
The Request element does not support Extended Element IDs.
See 11.1.4.3.5 for additional requirements.
9.4.2.11 Extended Request element
This element is placed in a Probe Request frame or Information Request frame to request that the responding
STA include the requested information in the Probe Response frame or Information Response frame,
respectively. The format of the element is as shown in Figure 9-136.
Element ID Length Element ID Requested Requested Element ID
Extension Element ID Extensions
Octets: 1 1 1 1 variable
Figure 9-136—Extended Request element
The Element ID, Element ID Extension, and Length fields are defined in 9.4.2.1.
798
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Requested Element ID field contains one of the Element IDs used to indicate an extended element.
The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that,
combined with the value of the Requested Element ID field, identify elements that are requested to be
included in the Probe Response or Information Response frame. The values in this field are listed in
increasing order. The requested elements within an Extended Request element transmitted in a Probe
Request frame do not identify an element that will be included in the Probe Response frame even in the
absence of the Request element, or will be excluded from the Probe Response frame even in the presence of
the Extended Request element as described by the notes in Table 9-34. The requested elements within an
Extended Request element transmitted in an Information Request frame do not identify an element that will
be included in the Information Response frame even in the absence of the Extended Request element, as
shown in Table 9-390. A given element ID extension value is included at most once in the Requested
Element ID Extensions field.
See 11.1.4.3.5 for additional requirements.
9.4.2.12 ERP element
The ERP element contains information on the presence of Clause 15 or Clause 16 STAs in the BSS that are
not capable of Clause 18 (ERP-OFDM) data rates. It also contains the requirement of the ERP element
sender (AP, IBSS STA, or mesh STA) as to the use of protection mechanisms to optimize BSS performance
and as to the use of long or short Barker preambles. See Figure 9-137 for a definition of the frame element.
The ERP element has the form shown in Figure 9-137.
Length ERP
Element ID (1) Parameters
Octets: 1 1 1
Figure 9-137—ERP element
The Element ID and Length fields are defined in 9.4.2.1.
The ERP Parameters field is defined in Figure 9-138.
B0 B1 B2 B3 B7
NonERP_Present Use_Protection Barker_Preamble_Mode Reserved
Bits: 1 1 1 5
Figure 9-138—ERP Parameters field
Recommended behavior for setting the Use_Protection bit is contained in 10.26.
9.4.2.13 Extended Supported Rates and BSS Membership Selectors element
The Extended Supported Rates and BSS Membership Selectors element specifies the rates in the
OperationalRateSet parameter, as described in the MLME-JOIN.request and MLME-START.request
primitives, and zero or more BSS membership selectors, where these are not carried in the Supported Rates
and BSS Membership Selectors element. The Information field is encoded as 1 to 255 octets, where each
octet describes a single supported rate or BSS membership selector (see Figure 9-139).
799
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Extended Supported
Element ID Length Rates
Octets: 1 1 1–255
Figure 9-139—Extended Supported Rates and BSS Membership Selectors element format
The Element ID and Length fields are defined in 9.4.2.1.
The format and interpretation of each octet of the Extended Supported Rates field is the same as that of an
octet in the Supported Rates field in a Supported Rates and BSS Membership Selectors element (see
9.4.2.3).
9.4.2.14 Power Constraint element
The Power Constraint element contains the information necessary to allow a STA to determine the local
maximum transmit power in the current channel. The format of the Power Constraint element is shown in
Figure 9-140.
Local Power
Element ID Length
Constraint
Octets: 1 1 1
Figure 9-140—Power Constraint element format
The Element ID and Length fields are defined in 9.4.2.1.
The Local Power Constraint field is coded as an unsigned integer in units of decibels. The local maximum
transmit power for a channel is thus defined as the maximum transmit power level specified for the channel
in the Country element minus the local power constraint specified for the channel (from the MIB) in the
Power Constraint element.
The Power Constraint element is included in Beacon frames, as described in 9.3.3.3, and Probe Response
frames, as described in 9.3.3.11. The use of Power Constraint elements is described in 11.8.5.
9.4.2.15 Power Capability element
The Power Capability element specifies the minimum and maximum transmit powers with which a STA is
capable of transmitting in the current channel. The format of the Power Capability element is shown in
Figure 9-141.
Minimum Maximum
Element ID Length Transmit Power Transmit Power
Capability Capability
Octets: 1 1 1 1
Figure 9-141—Power Capability element format
The Element ID and Length fields are defined in 9.4.2.1.
800
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Minimum Transmit Power Capability field is set to the nominal minimum transmit power with which
the STA is capable of transmitting in the current channel, with a tolerance ± 5 dB. The field is coded as a
signed integer in units of decibels relative to 1 mW. Further interpretation of this field is defined in 11.8.4.
The Maximum Transmit Power Capability field is set to the nominal maximum transmit power with which
the STA is capable of transmitting in the current channel, with a tolerance ± 5 dB. The field is coded as a
signed integer in units of decibels relative to 1 mW. Further interpretation of this field is defined in 11.8.4.
The Power Capability element is included in Association Request frames, as described in 9.3.3.6;
Reassociation Request frames, as described in 9.3.3.8; and Mesh Peering Open frame, as described in
9.6.16.2.2. The use of Power Capability elements is described in 11.8.2.
9.4.2.16 TPC Request element
The TPC Request element contains a request for a STA to report transmit power and link margin
information using a TPC Report element. The format of the TPC Request element is shown in Figure 9-142.
Element ID Length
Octets: 1 1
Figure 9-142—TPC Request element format
The Element ID and Length fields are defined in 9.4.2.1.
The TPC Request element is included in TPC Request frames, as described in 9.6.2.4. The use of TPC
Request elements and frames is described in 11.8.7.
9.4.2.17 TPC Report element
The TPC Report element contains transmit power and link margin information sent in response to a TPC
Request element or a Link Measurement Request frame. A TPC Report element is included in a Beacon
frame or Probe Response frame without a corresponding request. The format of the TPC Report element is
shown in Figure 9-143.
Element ID Length Transmit Power Link Margin
Octets: 1 1 1 1
Figure 9-143—TPC Report element format
The Element ID and Length fields are defined in 9.4.2.1.
The Transmit Power field is set to the transmit power used to transmit the frame containing the TPC Report
element. The field is coded as a 2s complement signed integer in units of decibels relative to 1 mW. The
maximum tolerance for the transmit power value reported in the TPC Response element is ± 5 dB. This
tolerance is defined as the difference, in decibels, between the reported power value and the actual EIRP of
the STA (when transmitting 1500 octet frames or maximum MPDU sized-frames, whichever is smaller).
The Link Margin field contains the link margin for the receive time and for the receive rate of the frame
containing the TPC Request element or the Link Measurement Request frame. The field is coded as a 2s
801
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
complement signed integer in units of decibels. The Link Margin field is reserved when a TPC Report
element is included in a Beacon frame or Probe Response frame. The method used to measure the link
margin is beyond the scope of this standard.
The TPC Report element is included in TPC Report frames, as described in 9.6.2.5; Link Measurement
Report frames, as described in 9.6.7.5; Beacon frames, as described in 9.3.3.3; and Probe Response frames,
as described in 9.3.3.11. The use of TPC Report elements and frames is described in 11.8.7.
9.4.2.18 Supported Channels element
The Supported Channels element contains a list of channel subbands (from those channels defined in
17.3.8.4.3) in which a STA is capable of operating. The format of the Supported Channels element is shown
in Figure 9-144.
One (first channel, number of
channels) tuple for each subband
First Channel Number of
Element ID Length
Number Channels
Octets: 1 1 1 1
Figure 9-144—Supported Channels element format
The Element ID and Length fields are defined in 9.4.2.1.
The First Channel Number field is set to the first channel (as defined in 17.3.8.4.3) in a subband of supported
channels.
The Number of Channels field is set to the number of channels in a subband of supported channels.
The Supported Channels element is included in Association Request frames, as described in 9.3.3.6;
Reassociation Request frames, as described in 9.3.3.8; and Mesh Peering Open frame, as described in
9.6.16.2.2. The use of the Supported Channels element is described in 11.9.2 and 11.9.8.
9.4.2.19 Channel Switch Announcement element
The Channel Switch Announcement element is used by an AP, IBSS STA, mesh STA, or PCP to advertise
when it is changing to a new channel and the channel number of the new channel. The format of the Channel
Switch Announcement element is shown in Figure 9-145.
Channel Switch New Channel Channel Switch
Element ID Length Mode Number Count
Octets: 1 1 1 1 1
Figure 9-145—Channel Switch Announcement element format
The Element ID and Length fields are defined in 9.4.2.1.
The Channel Switch Mode field indicates any restrictions on transmission until a channel switch. An AP or
IBSS STA sets the Channel Switch Mode field to either 0 or 1 on transmission. In an MBSS, the Channel
Switch Mode field is reserved. See 11.9.9.
The New Channel Number field is set to the number of the channel to which the STA is moving (as defined
in 17.3.8.4.3).
802
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For nonmesh STAs, the Channel Switch Count field either is set to the number of TBTTs until the STA
sending the Channel Switch Announcement element switches to the new channel or is set to 0. A value of 1
indicates that the switch occurs immediately before the next TBTT. A value of 0 indicates that the switch
occurs at any time after the frame containing the element is transmitted.
For mesh STAs, the Channel Switch Count field is encoded as an octet with bits 6 to 0 set to the time, in
units of 2 TU when the MSB (bit 7) is 0, or in units of 100 TU when the MSB (bit 7) is 1, until the mesh
STA sending the Channel Switch Announcement element switches to the new channel. A value of 0 for bits
6 to 0 indicates that the switch occurs at any time after the frame containing the element is transmitted. For
example, a 200 TU channel switch time is encoded as X'82' and a 10 TU channel switch time is encoded as
X'05'.
The Channel Switch Announcement element is included in Channel Switch Announcement frames, as
described in 9.6.2.6, and can be included in Beacon frames, as described in 9.3.3.3, and Probe Response
frames, as described in 9.3.3.11. The use of Channel Switch Announcement elements and frames is
described in 11.9.8.
9.4.2.20 Secondary Channel Offset element
The Secondary Channel Offset element is used by an AP, IBSS STA or mesh STA when changing to a new
40 MHz or wider channel. The format of the Secondary Channel Offset element is shown in Figure 9-146.
The Secondary Channel Offset element is included in Channel Switch Announcement frames, as described
in 9.6.2.6.
Element ID Length Secondary Channel Offset
Octets: 1 1 1
Figure 9-146—Secondary Channel Offset element format
The Element ID and Length fields are defined in 9.4.2.1.
The Secondary Channel Offset field of the Secondary Channel Offset element represents the position of the
secondary channel relative to the primary channel. The values of the Secondary Channel Offset field are
defined in Table 9-80.
Table 9-80—Values of the Secondary Channel Offset field
Value Name Description
0 SCN - no secondary channel Indicates that no secondary channel is present.
1 SCA - secondary channel above Indicates that the secondary channel is above the primary channel.
2 Reserved.
3 SCB - secondary channel below Indicates that the secondary channel is below the primary channel.
4–255 Reserved.
803
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.21 Measurement Request element
9.4.2.21.1 General
The Measurement Request element contains a request that the receiving STA undertake the specified
measurement action. The Measurement Request element is included in Measurement Request frames, as
described in 9.6.2.2, or Radio Measurement Request frames, as described in 9.6.7.2. Measurement types 0,
1, and 2 are defined for spectrum management and are included only in Measurement Request frames. The
use of Measurement Request elements for spectrum management is described in 11.9.7. All other
measurement types are included only in Radio Measurement Request frames. The use of Measurement
Request elements for radio measurement is described in 11.11.
The format of the Measurement Request element is shown in Figure 9-147.
Element ID Length Measurement Measurement Measurement Measurement
Token Request Mode Type Request
Octets: 1 1 1 1 1 variable
Figure 9-147—Measurement Request element format
The Element ID and Length fields are defined in 9.4.2.1.
The value of the Length field is variable and depends on the length of the Measurement Request field. The
minimum value of the Length field is 3 (based on a minimum length for the Measurement Request field of
0 octets).
The Measurement Token is set to a nonzero number that is unique among the Measurement Request
elements in a particular Measurement Request frame.
The Measurement Request Mode field (shown in Figure 9-148) is a bit field with the following bits defined:
— The Parallel bit (bit 0) is used to request that more than one measurement is to be started in parallel.
Parallel is set to 1 to request that the measurement is to start at the same time as the measurement
described by the next Measurement Request element in the same Measurement Request frame.
Parallel is set to 0 if the measurements are to be performed in sequence. The Parallel bit is reserved
when Enable is 1, in the last or only Measurement Request element in the frame, or when the value
of the Measurement Type field is 0, 1, or 2 (spectrum management measurements). See 11.11.6.
— The Enable bit (bit 1) is used to differentiate between a request to make a measurement and a request
to control the measurement requests and triggered or autonomous reports generated by the
destination STA. The Enable bit is further described in Table 9-81.
— Request bit (bit 2) is described in Table 9-81.
— Report bit (bit 3) is described in Table 9-81.
— The Duration Mandatory bit (bit 4) indicates whether the measurement duration contained within
the measurement request is interpreted as mandatory by the STA receiving the request. A value of 0
indicates that the duration requested is a maximum duration, and the requesting STA accepts
measurement results taken over any shorter duration. A value of 1 indicates that the duration
requested is a mandatory duration. The Duration Mandatory bit is reserved when the Enable bit is 1,
or when the value of the Measurement Type field is 0, 1, 2, 8, or 255. See 11.11.4.
— All other bits are reserved.
804
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3 B4 B5 B7
Duration
Parallel Enable Request Report Reserved
Mandatory
Bits: 1 1 1 1 1 3
Figure 9-148—Measurement Request Mode field
The use of the Enable, Request, and Report bits is summarized in Table 9-81. See 11.9.7 and 11.11.6 for the
description of how a STA handles requests to enable or disable measurement requests and autonomous
reports. See 11.11.8 for a description of the use of the Enable and Report bits in triggered reporting.
Table 9-81—Summary of use of Enable, Request, and Report bits
Bits
Meaning of bits
Enable Request Report
0 Reserved Reserved The transmitting STA is requesting that the destination STA make a
measurement of type indicated in the Measurement Type field.
When Enable bit is 0, Request and Report bits are reserved.
1 0 0 The transmitting STA is requesting that the destination STA not send any
measurement requests or reports of the type indicated in the Measurement
Type field.
1 1 0 The transmitting STA is indicating to the destination STA that it can accept
measurement requests and is requesting the destination STA not send
autonomous or triggered measurement reports of the type indicated in the
Measurement Type field.
NOTE—This setting corresponds to the default STA behavior.
1 0 1 The transmitting STA is requesting that the destination STA not send
measurement requests and indicating it accepts autonomous or triggered
measurement reports of the type indicated in the Measurement Type field.
1 1 1 The transmitting STA is indicating to the destination STA that it can accept
measurement requests and can accept autonomous or triggered
measurement reports of the type indicated in the Measurement Type field.
The Measurement Type field is set to a number that identifies a type of measurement request or
measurement report. The measurement types that have been allocated for measurement requests are shown
in Table 9-82 and measurement reports are shown in Table 9-107 (in 9.4.2.22).
Table 9-82—Measurement type definitions for measurement requests
Measurement
Name
type
Basic 0
Clear Channel Assessment (CCA) 1
Receive Power Indication (RPI) Histogram 2
Channel Load 3
Noise Histogram 4
805
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-82—Measurement type definitions for measurement requests (continued)
Measurement
Name
type
Beacon 5
Frame 6
STA Statistics 7
LCI 8
Transmit Stream/Category Measurement 9
Multicast Diagnostics 10
Location Civic 11
Location Identifier 12
Directional Channel Quality 13
Directional Measurement 14
Directional Statistics 15
Fine Timing Measurement Range 16
Reserved 17–254
Measurement Pause 255
When the Enable bit is 0, the Measurement Request field contains the specification of a single measurement
request corresponding to the measurement type, as described in 9.4.2.21.2 to 9.4.2.21.12. When the Enable
bit is 1, the Measurement Request field is present only when requesting a triggered measurement.
References in this standard to a ‘ request’, where corresponds to one of the Measurement
Types in Table 9-82 is equivalent to (according to context) a) ‘a Measurement Request frame or Radio
Measurement Request frame carrying a Measurement Request element with the measurement type field
equal to ’ or b) ‘a Measurement Request element with the measurement type field equal to ’.
9.4.2.21.2 Basic request
The Measurement Request field corresponding to a Basic request is shown in Figure 9-149. See 11.9.7.
Channel Measurement Measurement
Number Start Time Duration
Octets: 1 8 2
Figure 9-149—Measurement Request field format for a Basic request
The Channel Number field is set to the channel number for which the measurement request applies where
the channel number is a value from the “Channel set” column in Table E-4, in a row having the same value
in the “Channel spacing (MHz)” column as the width of the primary channel.
The Measurement Start Time field is set to the TSF timer at the time (± 32 s) at which the requested Basic
request measurement starts. A value of 0 indicates it starts immediately.
The Measurement Duration field is set to the duration of the requested measurement, expressed in TUs.
806
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.21.3 CCA request (Clear channel access request)
The Measurement Request field corresponding to a CCA request is shown in Figure 9-150.
Channel Measurement Measurement
Number Start Time Duration
Octets: 1 8 2
Figure 9-150—Measurement Request field format for a CCA request
The Channel Number field is set to the channel number for which the measurement request where the
channel number is a value from the “Channel set” column in Table E-4, in a row having the same value in
the “Channel spacing (MHz)” column as the width of the primary channel.
The Measurement Start Time field is set to the TSF at the time (± 32 s) at which the requested CCA request
measurement starts. A value of 0 indicates it starts immediately.
The Measurement Duration field is set to the duration of the requested measurement, expressed in TUs.
9.4.2.21.4 RPI histogram request (Received power indicator histogram request)
The Measurement Request field corresponding to an RPI Histogram request is shown in Figure 9-151.
Channel Measurement Measurement
Number Start Time Duration
Octets: 1 8 2
Figure 9-151—Measurement Request field format for an RPI Histogram request
The Channel Number field is set to the channel number for which the measurement request where the
channel number is a value from the “Channel set” column in Table E-4, in a row having the same value in
the “Channel spacing (MHz)” column as the width of the primary channel.
The Measurement Start Time field is set to the TSF at the time (± 32 s) at which the requested RPI
Histogram request measurement starts. A value of 0 indicates it starts immediately.
The Measurement Duration field is set to the duration of the requested measurement, expressed in TUs.
9.4.2.21.5 Channel Load request
The Measurement Request field corresponding to a Channel Load request is shown in Figure 9-152.
Operating Channel Randomization Measurement Optional
Class Number Interval Duration Subelements
Octets: 1 1 2 2 variable
Figure 9-152—Measurement Request field format for Channel Load request
If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the
operating class that identifies the channel set for which the measurement request applies. The Country,
Operating Class, and Channel Number fields together specify the channel frequency and spacing for which
the measurement request applies. Valid operating classes are listed in Annex E, excluding operating classes
that encompass a primary channel but do not identify the location of the primary channel. The Channel
807
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Number field indicates the channel number for which the measurement request applies. Channel number is
defined within an operating class as shown in Annex E.
NOTE—Examples of operating classes that encompass a primary channel but do not identify the location of the primary
channel are operating classes with a value of 80 or 160 in the “Channel Spacing (MHz)” column in the applicable table
in Annex E.
If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel
Switch subelement indicate the channel for which the measurement request applies, and the Operating Class
field and Channel Number field together specify the primary channel and primary 40 MHz channel within
the channel identified by the Wide Bandwidth Channel Switch subelement.
The Randomization Interval field specifies the upper bound of the random delay to be used prior to making
the measurement, in units of TUs. See 11.11.3.
The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement,
in units of TUs. See 11.11.4.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-83.
Table 9-83—Optional subelement IDs for Channel Load request
Subelement ID Name Extensible
0 Reserved
1 Channel Load Reporting Yes
2–162 Reserved
163 Wide Bandwidth Channel Switch Yes
164–220 Reserved
221 Vendor Specific
222–255 Reserved
The Channel Load Reporting subelement indicates the condition for issuing a Channel Load report. The
Channel Load Reporting subelement data field format is shown in Figure 9-153 and contains a 1-octet
Reporting Condition subfield and a 1-octet Channel Load Reference Value subfield. The Reporting
Condition subfield is described in Table 9-84. The Channel Load Reference value is a Channel Load value
as defined in 11.11.9.3 and is the reference value for the indicated reporting condition.
Reporting Channel Load
Condition Reference Value
Octets: 1 1
Figure 9-153—Channel Load Reporting data field format
808
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-84—Reporting Condition subfield for Channel Load report
Condition for report to be issued Reporting Condition
Report to be issued after each measurement (default, used when the Channel 0
Load Reporting subelement is not included in the Channel Load request).
Report to be issued when the measured Channel Load is greater than or equal to 1
the reference value.
Report to be issued when the measured Channel Load is less than or equal to the 2
reference value.
Reserved 3–255
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or
80+80 MHz BSS bandwidth.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements might be included in the list of optional subelements.
9.4.2.21.6 Noise Histogram request
The Measurement Request field corresponding to a Noise Histogram request is shown in Figure 9-154.
Operating Channel Randomization Measurement Optional
Class Number Interval Duration Subelements
Octets: 1 1 2 2 variable
Figure 9-154—Measurement Request field format for Noise Histogram request
If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the
operating class that identifies the channel set for which the measurement request applies. The Country,
Operating Class, and Channel Number fields together specify the channel frequency and spacing for which
the measurement request applies. Valid operating classes are listed in Annex E, excluding operating classes
that encompass a primary channel but do not identify the location of the primary channel. The Channel
Number field indicates the channel number for which the measurement request applies. Channel number is
defined within an operating class as shown in Annex E.
If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel
Switch subelement indicate the channel for which the measurement request applies, and the Operating Class
and Channel Number together specify the primary channel and primary 40 MHz channel within the channel
identified by the Wide Bandwidth Channel Switch subelement.
The Randomization Interval field specifies the upper bound of the random delay to be used prior to making
the measurement, in units of TUs. See 11.11.3.
The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement,
in units of TUs. See 11.11.4.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
809
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Subelement ID field values for the defined subelements are shown in Table 9-85.
Table 9-85—Optional subelement IDs for Noise Histogram request
Subelement ID Name Extensible
0 Reserved
1 Noise Histogram Reporting Yes
2–162 Reserved
163 Wide Bandwidth Channel Switch Yes
164–220 Reserved
221 Vendor Specific
222–255 Reserved
The Noise Histogram Reporting subelement indicates the condition for issuing a Noise Histogram report.
The Noise Histogram Reporting subelement data field format is shown in Figure 9-155 and contains a 1-
octet Reporting Condition subfield and a 1-octet ANPI Reference Value subfield. The Reporting Condition
subfield is described in Table 9-86. The ANPI Reference Value is an ANPI value as defined in 11.11.9.4 and
is the reference value for the indicated reporting condition.
Reporting ANPI
Condition Reference Value
Octets: 1 1
Figure 9-155—Noise Histogram Reporting data field format
Table 9-86—Reporting Condition subfield for Noise Histogram report
Reporting
Condition for report to be issued
Condition
Report to be issued after each measurement (default, used when Noise Histogram Reporting 0
subelement is not included in a Noise Histogram request).
Noise Histogram report to be issued when measured ANPI is greater than or equal to the 1
reference value.
Noise Histogram report to be issued when measured ANPI is less than or equal to the 2
reference value.
Reserved 3–255
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or
80+80 MHz BSS bandwidth.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements might be included in the list of optional subelements.
810
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.21.7 Beacon request
The Measurement Request field corresponding to a Beacon request is shown in Figure 9-156.
Operating Channel Randomization Measurement
Class Number Interval Duration
Octets: 1 1 2 2
Measurement BSSID Optional
Mode Subelements
Octets: 1 6 variable
Figure 9-156—Measurement Request field format for Beacon request
If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the
operating class that identifies the channel set for which the measurement request applies. The Country,
Operating Class, and Channel Number fields together specify the channel frequency and spacing for which
the measurement request applies. Valid operating classes are listed in Annex E.
For operating classes that encompass a primary channel but do not identify the location of the primary
channel, the Channel Number field value is either 0 or 255; otherwise, the Channel Number field value is 0,
255, or the channel number for which the measurement request applies and is defined within an operating
class as shown in Annex E.
For operating classes that identify the location of the primary channel, a Channel Number field value of 0
indicates a request to make iterative measurements for all supported channels in the operating class where
the measurement is permitted on the channel and the channel is valid for the current regulatory domain.
For operating classes that encompass a primary channel but do not identify the location of the primary
channel, a Channel Number field value of 0 indicates a request to make iterative measurements for all
primary channel positions within all requested and supported channels where the measurement is permitted
on the channel and the channel is valid for the current regulatory domain.
For operating classes that identify the location of the primary channel, a Channel Number field value of 255
indicates a request to make iterative measurements for all supported channels in the current operating class
listed in the latest AP Channel Report received from the serving AP.
A request frame is a request to make iterative measurements for all primary channel positions in all channels
listed in the frame’s AP Channel Report subelement when all of the following pertain:
— The operating class indicated by the Operating Class field in that frame encompasses a primary
channel.
— The frame does not identify the location of that primary channel.
— The value of the frame’s Channel Number field is 255.
— The channel is supported.
— The measurement is permitted on the channel.
— The channel is permitted in the current regulatory domain.
If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel
Switch subelement indicate the channel for which the measurement request applies, and the Operating Class
and Channel Number fields together specify the primary channel and primary 40 MHz channel within the
channel identified by the Wide Bandwidth Channel Switch subelement.
811
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Randomization Interval field specifies the upper bound of the random delay to be used prior to making
the measurement, in units of TUs. See 11.11.3.
The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement,
in units of TUs. See 11.11.4.
Measurement Mode indicates the mode to be used for the measurement. The valid measurement modes are
listed in Table 9-87. The procedures for each mode are described in 11.11.9.1.
Table 9-87—Measurement Mode definitions for Beacon request
Mode Value
Passive 0
Active 1
Beacon Table 2
Reserved 3–255
The BSSID field indicates the BSSID of the BSS(s) for which a beacon report is requested. When requesting
beacon reports for all BSSs on the channel, the BSSID field contains the wildcard BSSID; otherwise the
BSSID field contains a specific BSSID for a single BSS.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-88.
Table 9-88—Optional subelement IDs for Beacon request
Subelement ID Name Extensible
0 SSID
1 Beacon Reporting Yes
2 Reporting Detail Yes
3–9 Reserved
10 Request
11 Extended Request
12–50 Reserved
51 AP Channel Report
52–162 Reserved
163 Wide Bandwidth Channel Switch Yes
164–220 Reserved
221 Vendor Specific
222–255 Reserved
812
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SSID subelement indicates the ESS(s) or IBSS(s) for which a beacon report is requested. When SSID is
not included in a Beacon request, the default “wildcard SSID” is used; otherwise the SSID is included in the
Beacon request and contains a specific SSID for a single ESS or IBSS. The wildcard SSID is used to
represent all possible SSIDs. The SSID element is described in 9.4.2.2.
The Beacon Reporting subelement indicates the condition for issuing a Beacon report. The Beacon
Reporting subelement is optionally present in a Beacon request for repeated measurements; otherwise it is
not present. The Beacon Reporting subelement data field format is shown in Figure 9-157 and contains a 1-
octet Reporting Condition subfield and a 1-octet Threshold/Offset Reference subfield. The Reporting
Condition subfield is described in Table 9-89. The Threshold/Offset Reference subfield contains either the
threshold value or the offset value to be used for conditional reporting. For Reporting Condition subfield 1
and 2, the threshold value is a logarithmic function of the received signal power, as defined 9.4.2.38. For
Reporting Condition subfield 3 and 4, the threshold value is a logarithmic function of the signal-to-noise
ratio, as described in 9.4.2.41. For Reporting Condition subfield 5 to 10, the offset value is an 8-bit 2s
complement integer in units of 0.5 dBm. The indicated reporting condition applies individually to each
measured Beacon, Measurement Pilot, or Probe Response frame. Reporting conditions are further described
in 11.11.9.1.
Reporting Threshold/Offset
Condition Reference
Octets: 1 1
Figure 9-157—Beacon Reporting data field format
Table 9-89—Reporting Condition subfield for Beacon report
Condition for report to be issued in Repeated Measurement Reporting Condition
Report to be issued after each measurement (default, used when the Beacon 0
Reporting subelement is not included in a Beacon request).
The measured RCPI level is greater than the threshold value contained in the 1
Threshold/Offset Reference.
The measured RCPI level is less than the threshold value contained in the Threshold/ 2
Offset Reference.
The measured RSNI level is greater than the threshold value contained in the 3
Threshold/Offset Reference.
The measured RSNI level is less than the threshold value contained in the Threshold/ 4
Offset Reference.
The measured RCPI level is greater than a threshold defined by an offset from the 5
serving AP’s reference RCPI, where the offset value is contained in the Threshold/
Offset Reference.
The measured RCPI level is less than a threshold defined by an offset from the 6
serving AP’s reference RCPI, where the offset value is contained in the Threshold/
Offset Reference.
The measured RSNI level is greater than a threshold defined by an offset from the 7
serving AP’s reference RSNI, where the offset value is contained in the Threshold/
Offset Reference.
The measured RSNI level is less than a threshold defined by an offset from the 8
serving AP’s reference RSNI, where the offset value is contained in the Threshold/
Offset Reference.
813
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-89—Reporting Condition subfield for Beacon report (continued)
Condition for report to be issued in Repeated Measurement Reporting Condition
The measured RCPI level is in a range bound by the serving AP’s reference RCPI 9
and an offset from the serving AP’s reference RCPI, where the offset value is
contained in the Threshold/Offset Reference.
The measured RSNI level is in a range bound by the serving AP’s reference RSNI 10
and an offset from the serving AP’s reference RSNI, where the offset value is
contained in the Threshold/Offset Reference.
Reserved 11–255
The Reporting Detail subelement contains a 1-octet Reporting Detail data field that defines the level of
detail per AP to be reported to the requesting STA. The Reporting Detail values are defined in Table 9-90.
Table 9-90—Reporting Detail values
Level of detail requested Reporting Detail
No fixed-length fields or elements 0
All fixed-length fields and any requested elements in the Request element if present 1
All fixed-length fields and elements (default, used when Reporting Detail subelement 2
is not included in a Beacon request)
Reserved 3–255
The indicated reporting detail applies individually to each measured Beacon, Measurement Pilot, or Probe
Response frame. If the Reporting Detail equals 1, a Request element is optionally present in the optional
subelements field. If included, the Request element lists the Element IDs of the elements requested to be
reported in the Reported Frame Body of the Beacon report.
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161) with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80
MHz BSS bandwidth.
The Request, Extended Request, AP Channel Report, and Vendor Specific subelements have the same
format as their corresponding elements (see 9.4.2.10, 9.4.2.11, 9.4.2.36, and 9.4.2.26, respectively). Multiple
AP Channel Report and Vendor Specific subelements can be included in the list of optional subelements. An
AP Channel Report subelement containing an operating class with an 80+ behavior limit (as defined in
Annex E) is interpreted in conjunction with following AP Channel Report elements as defined in 11.11.9.1.
If one or more AP Channel Report elements are included, they indicate that iterative measurements are
requested first on the channel(s) indicated by the Operating Class and Channel Number fields included in the
Beacon request, and second on the channel(s) indicated by the Operating Class and Channel List fields of
each AP Channel Report element included in the Beacon request. The procedures for iterative measurements
on multiple channels are described in 11.11.9.1.
9.4.2.21.8 Frame request
The Measurement Request field corresponding to a Frame request is shown Figure 9-158.
814
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Frame
Operating Channel Randomization Measurement Request MAC Optional
Class Number Interval Duration Address subelements
Type
Octets: 1 1 2 2 1 6 variable
Figure 9-158—Measurement Request field format for Frame request
If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the
operating class that identifies the channel set for which the measurement request applies. The Country,
Operating Class, and Channel Number fields together specify the channel frequency and spacing for which
the measurement request applies. Valid operating classes are listed in Annex E, excluding operating classes
that encompass a primary channel but do not identify the location of the primary channel. The Channel
Number field indicates the channel number for which the measurement request applies. Channel number is
defined within an operating class as shown in Annex E.
If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel
Switch subelement indicate the channel for which the measurement request applies, and the Operating Class
and Channel Number fields together specify the primary channel and primary 40 MHz channel within the
channel identified by the Wide Bandwidth Channel Switch subelement.
The Randomization Interval field specifies the upper bound of the random delay to be used prior to making
the measurement, in units of TUs. See 11.11.3.
The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement,
in units of TUs. See 11.11.4.
The Frame Request Type indicates which subelements are requested in the Frame report. The value of 1
signifies that a Frame Count Report is requested. The values 0 and 2 to 255 are reserved.
If the MAC Address field is the broadcast address, then all Data or Management frames are counted toward
the Frame report generated in response to this Frame request. For other MAC addresses, only frames
matching this MAC address as the Transmitter Address are counted toward the Frame report generated in
response to this Frame request.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-91.
Table 9-91—Optional subelement IDs for Frame request
Subelement ID Name Extensible
0–162 Reserved
163 Wide Bandwidth Yes
Channel Switch
164–220 Reserved
221 Vendor Specific
222–255 Reserved
815
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or
80+80 MHz BSS bandwidth.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.21.9 STA Statistics request
The Measurement Request field corresponding to a STA Statistics request is shown in Figure 9-159.
Peer MAC Randomization Measurement Group Identity Optional
Address Interval Duration Subelements
Octets: 6 2 2 1 variable
Figure 9-159—Measurement Request field format for STA Statistics request
The Peer MAC Address field is the RA or TA MAC address for the frame statistics of this measurement.
The Randomization Interval field specifies the upper bound of the random delay to be used prior to making
the measurement, in units of TUs. See 11.11.3.
The Measurement Duration field is set to the duration of the requested measurement in TUs except when
triggered reporting is used. When triggered reporting is used, the measurement duration is 0.
Group Identity indicates the requested statistics group according to Table 9-92.
Table 9-92—Group Identity for a STA Statistics request
Statistics Group Name Group Identity
STA Counters from dot11CountersTable 0
STA Counters from dot11MacStatistics group 1
QoS STA Counters for UP0 from dot11QosCountersTable 2
QoS STA Counters for UP1 from dot11QosCountersTable 3
QoS STA Counters for UP2 from dot11QosCountersTable 4
QoS STA Counters for UP3 from dot11QosCountersTable 5
QoS STA Counters for UP4 from dot11QosCountersTable 6
QoS STA Counters for UP5 from dot11QosCountersTable 7
QoS STA Counters for UP6 from dot11QosCountersTable 8
QoS STA Counters for UP7 from dot11QosCountersTable 9
BSS Average Access Delays as described in 9.4.2.39 and 9.4.2.44 10
STA Counters from dot11CountersGroup3 (A-MSDU) 11
STA Counters from dot11CountersGroup3 (A-MPDU) 12
STA Counters from dot11CountersGroup3 (BlockAckReq, Channel Width, PSMP) 13
STA Counters from dot11CountersGroup3 (RD, dual CTS, L-SIG TXOP protection) 14
816
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-92—Group Identity for a STA Statistics request (continued)
Statistics Group Name Group Identity
STA Counters from dot11CountersGroup3 (beamforming and STBC) 15
RSNA Counters 16
Reserved 17–255
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-93.
Table 9-93—Optional subelement IDs for STA Statistics request
Subelement ID Name Extensible
0 Reserved
1 Triggered Reporting
2–220 Reserved
221 Vendor Specific
222–255 Reserved
The Triggered Reporting subelement is used to specify trigger conditions and thresholds for triggered STA
Statistics measurements. It is present when setting up triggered reporting from STA Counters, QoS STA
Counters, or RSNA Counters; see 11.11.9.5.
The format of the Triggered Reporting subelement for STA Counters is shown in Figure 9-160. The fields
marked as optional are only present if the appropriate bit in the STA Counter Trigger Condition field is 1.
STA Counter dot11FailedCount dot11FCS
Measurement ErrorCount
Count Trigger Timeout Trigger Threshold Threshold
Condition (optional)
(optional)
Octets: 4 2 2 0 or 4 0 or 4
dot11Multiple dot11Frame dot11RTS dot11Ack
dot11RetryCount
RetryCount DuplicateCount FailureCount FailureCount Threshold
Threshold Threshold Threshold Threshold
(optional) (optional) (optional) (optional) (optional)
Octets: 0 or 4 0 or 4 0 or 4 0 or 4 0 or 4
Figure 9-160—Triggered Reporting subelement for STA Counters
The value in the Measurement Count field specifies the number of MSDUs or MPDUs transmitted and/or
received by the STA that are to be used to determine if one or more of the trigger conditions have been met.
The Trigger Timeout field contains a value in units of 100 TUs during which a measuring STA does not
generate further triggered STA Statistics reports after a trigger condition has been met.
817
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The STA Counter Trigger Condition field specifies trigger values used when requesting triggered STA
Statistics reporting. The format of the STA Counter Trigger Condition field is shown in Figure 9-161.
B0 B1 B2 B3
dot11FailedCount dot11FCSError dot11Multiple dot11Frame
Count RetryCount DuplicateCount
Bits 1 1 1 1
B4 B5 B6 B7 B15
dot11RTS dot11Ack dot11RetryCount Reserved
FailureCount FailureCount
Bits 1 1 1 9
Figure 9-161—STA Counter Trigger Condition field
For each bit in the STA Counter Trigger Condition field that is 1, a corresponding threshold value exists
(defined in Figure 9-160) in the Triggered Reporting subelement for STA Counters. With this, the STA
Statistics request indicates that a STA Statistics report be generated when the corresponding STA counter
defined in 9-205 and 9-206 (in 9.4.2.22.9) exceeds the value of the specified threshold, within the total
number of MSDUs or MPDUs indicated in the Measurement Count field. See 11.11.9.5. One or more trigger
conditions are set with specified thresholds. In the triggered STA Statistics request, the value of the Group
Identity field is either 0 or 1. When the Group Identity field value of the triggered STA Statistics request is 0,
B2–B6 in the STA Counter Trigger Condition field are set to 0. When the group identity of the triggered
STA Statistics request is 1, B0 and B1 in the STA Counter Trigger Condition field are set to 0.
The format of the Triggered Reporting subelement for QoS STA Counters is shown in Figure 9-162. The
fields marked as optional are only present if the appropriate bit in the QoS STA Counter Trigger Condition
subfield is 1.
dot11QoSFailed dot11QoSRetry
Measurement QoS STA Count Count
Trigger Timeout Counter Trigger
Count Condition Threshold Threshold
(optional) (optional)
Octets: 4 2 2 0 or 4 0 or 4
dot11QoSMultiple dot11QoSFrame dot11QoSRTSC dot11QoSAck dot11QoSDisca
ount
RetryCount DuplicateCount Failure FailureCount rdedCount
Threshold Threshold Threshold Threshold
(optional) (optional) Threshold (optional) (optional)
(optional)
Octets: 0 or 4 0 or 4 0 or 4 0 or 4 0 or 4
Figure 9-162—Triggered Reporting subelement for QoS STA Counters
The UP of the QoS STA Counters for triggered QoS Statistics measurement is determined by the group
identity of the Measurement Request field for a STA Statistics request as defined in 9-92.
The value in the Measurement Count field specifies the number of MSDUs or MPDUs transmitted and/or
received by the STAs that are to be used to determine if one or more of the trigger conditions have been met.
The Trigger Timeout field contains a value in units of 100 TUs during which a measuring STA does not
generate further triggered STA Statistics reports after a trigger condition has been met.
818
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The QoS STA Counter Trigger Condition field specifies reporting triggers when requesting triggered STA
Statistics reporting. The format of the QoS STA Counter Trigger Condition field is shown in Figure 9-163.
B0 B1 B2 B3
dot11QoS dot11QoS dot11QoSMultiple dot11QoSFrame
FailedCount RetryCount RetryCount DuplicateCount
Bits: 1 1 1 1
B4 B5 B6 B7-B15
dot11QoSRTS dot11QoSAck dot11QoS
Reserved
FailureCount FailureCount DiscardedCount
Bits: 1 1 1 9
Figure 9-163—QoS STA Counter Trigger Condition field
For each bit in the QoS STA Counter Trigger Condition field that is 1, a corresponding threshold value
exists (defined in Figure 9-162) in the Triggered Reporting subelement for QoS STA Counters. With this,
the STA Statistics request indicates that a STA Statistics report be generated when the corresponding QoS
STA counter defined in Figure 9-207 (in 9.4.2.22.9) exceeds the value of the specified threshold, within the
total number of MSDUs or MPDUs indicated in the Measurement Count field. See 11.11.9.5. One or more
trigger conditions are set with specified thresholds.
The format of the Triggered Reporting subelement for RSNA Counters is shown in Figure 9-164. The fields
marked as optional are only present if the appropriate bit in the RSNA Trigger Condition subfield is 1.
dot11RSNAStats dot11RSNA
Measurement Trigger RSNA Counter CMACICVErrors StatsCMACRepla
Count Timeout Trigger Condition Threshold ys Threshold
(optional) (optional)
Octets: 4 2 2 0 or 4 0 or 4
dot11RSNA
StatsRobustMgmt dot11RSNAStats dot11RSNAStats dot11RSNAStats dot11RSNAStats
TKIPICVErrors TKIPReplays CCMPDecryptErr CCMPReplays
CCMPReplays Threshold Threshold ors Threshold Threshold
Threshold
(optional) (optional) (optional) (optional) (optional)
Octets: 0 or 4 0 or 4 0 or 4 0 or 4 0 or 4
Figure 9-164—Triggered Reporting subelement for RSNA Counters
The value in the Measurement Count field specifies the number of MPDUs transmitted and/or received by
the STA that are to be used to determine if one or more of the trigger conditions have been met.
The Trigger Timeout field contains a value in units of 100 TUs during which a measuring STA does not
generate further triggered STA Statistics reports after a trigger condition has been met.
The RSNA Counter Trigger Condition field specifies reporting triggers when requesting triggered STA
Statistics reporting. The format of the RSNA Trigger Condition field is shown in Figure 9-165.
819
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3
dot11RSNAStats
dot11RSNAStats dot11RSNA RobustMgmt dot11RSNAStats
CMACICVErrors StatsCMACReplays TKIPICVErrors
CCMPReplays
Bits: 1 1 1 1
B4 B5 B6 B7 B15
dot11RSNAStats dot11RSNAStats dot11RSNAStats
TKIPReplays CCMPDecryptErrors CCMPReplays Reserved
Bits: 1 1 1 9
Figure 9-165—RSNA Trigger Condition field
For each bit in the RSNA Trigger Condition field that is 1, a corresponding threshold value exists (defined in
Figure 9-164) in the Triggered Reporting subelement for RSNA Counters. With this, the STA Statistics
request indicates that a STA Statistics report be generated when the corresponding RSNA counter defined in
Figure 9-209 (in 9.4.2.22.9) exceeds the value of the specified threshold, within the total number of MPDUs
indicated in the Measurement Count field. See 11.11.9.5. One or more trigger conditions are set with
specified thresholds.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.21.10 LCI request (Location configuration information request)
The Measurement Request field corresponding to an LCI request is shown in Figure 9-166.
Location Subject Optional
Subelements
Octets: 1 variable
Figure 9-166—Measurement Request field format for LCI request
The Location Subject field of an LCI request is a single octet. See Table 9-94.
Table 9-94—Location Subject field definition
Value Location Subject
0 Location Subject Local
1 Location Subject Remote
2 Location Subject Third Party
3–255 Reserved
The term Local refers to the location of the requesting STA, and Remote refers to the location of the
reporting STA.
820
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—A measurement request with its Location Subject value Location Subject Local is used by a requesting STA to
obtain its own location, asking “Where am I?” The Measurement Request with its Location Subject value Location
Subject Remote is used by a requesting STA to obtain the location of the reporting STA, asking “Where are you?”
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-95.
Table 9-95—Optional subelement IDs for LCI request
Subelement ID Name Extensible
0 Reserved
1 Azimuth Request Yes
2 Originator Requesting STA MAC
Address
3 Target MAC Address
4 Maximum Age Yes
5–220 Reserved
221 Vendor Specific
222–255 Reserved
The Azimuth Request subelement is present when requesting azimuth information. The Azimuth Request
subelement is as shown in Figure 9-167.
Subelement ID Length Azimuth Request
Octets: 1 1 1
Figure 9-167—Azimuth Request subelement format
The Subelement ID field is defined in Table 9-95.
The Length field is defined in 9.4.3.
The Azimuth Request field of an Azimuth Request subelement is shown in Figure 9-168.
B0 B3 B4 B5 B7
Azimuth Azimuth
Resolution Reserved
Requested Type
Bits: 4 1 3
Figure 9-168—Azimuth Request field
821
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Azimuth Resolution Requested is the number of valid most significant bits requested for the fixed-point
value of Azimuth, reported in integer degrees. Values above 9 are reserved.
Azimuth Type (bit 4) is set to 1 to request a report of the Azimuth of radio reception and is set to 0 to request
a report of the Azimuth of front surface of the reporting STA.
NOTE—A geographic feature is an abstraction of a real-world phenomenon; it is a geographic feature if it is associated
with a location relative to the Earth. The designation of a horizontal plane is relative to the Earth. The designation of the
“front surface” of a station is arbitrary, but refers to an orientable surface (possessing a centerline) of the station. It is
common to use a direction cosine matrix to convert from one coordinate system to another, i.e., body-centered
coordinates to earth-centered coordinates.
The Originator Requesting STA MAC Address subelement contains the MAC address of the STA request-
ing the Location Information and it is present whenever the Location Subject field is set to 2. The format of
the Originator Requesting STA MAC Address subelement is shown in Figure 9-169.
Originator
Subelement ID Length Requesting STA
MAC Address
Octets: 1 1 6
Figure 9-169—Originator Requesting STA MAC Address subelement format
The Target MAC Address subelement contains the MAC address of the STA whose Location Information is
requested and it is present whenever the Location Subject field is set to 2. The format of the Target MAC
address subelement is shown in Figure 9-170.
Target MAC
Subelement ID Length Address
Octets: 1 1 6
Figure 9-170—Target MAC Address subelement format
The Maximum Age subelement indicates the maximum age of the requested LCI. The format of the
Maximum Age subelement is defined in Figure 9-171. The absence of a Maximum Age subelement
indicates that an LCI determined at or after the LCI request is received is requested.
Subelement ID Length Maximum Age
Octets: 1 1 2
Figure 9-171—Format of Maximum Age subelement
The Length field is defined in 9.4.3.
The Maximum Age field of a Maximum Age subelement indicates the maximum elapsed time between
when an LCI is determined and when an LCI request is received, within which the LCI satisfies the LCI
request. The Maximum Age field is encoded as an unsigned integer with units of 0.1 s. The value of 0 is
reserved. The value of 65 535 indicates that any LCI age is acceptable.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
822
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.21.11 Transmit Stream/Category Measurement request
The Transmit Stream/Category Measurement applies to TIDs for traffic streams associated with TSPECs
and also to TIDs for traffic categories for QoS traffic without TSPECs. The Measurement Request field cor-
responding to a Transmit Stream/Category Measurement request is shown in Figure 9-172.
Randomization Measurement Peer STA Traffic Bin 0 Range Optional
Interval Duration Address Identifier Subelements
Octets: 2 2 6 1 1 variable
Figure 9-172—Measurement Request field format for Transmit Stream/Category
Measurement Request
The Randomization Interval field is set to the maximum random delay in the measurement start time, in
units of TUs. The use of the Randomization Interval field is described in 11.11.3. When requesting a
triggered Transmit Stream/Category Measurement, the randomization interval is not used and the
Randomization Interval field is reserved. See 11.11.9.8.
The Measurement Duration is set to the duration of the requested measurement, in units of TUs except when
setting up a triggered QoS measurement, when it is not used and is set to 0.
The Peer STA Address contains a MAC address indicating the RA in the MSDUs to be measured.
The Traffic Identifier field contains the TID subfield as shown in Figure 9-173.
B0 B3 B4 B7
Reserved TID
Bits: 4 4
Figure 9-173—Traffic Identifier field
The TID subfield indicates the TC or TS for which traffic is to be measured.
Bin 0 Range indicates the delay range of the first bin (Bin 0) of the Transmit Delay Histogram, in units of
TUs. The Bin 0 Range value is used to calculate the delay ranges of the other 5 bins making up the
histogram. The delay range for each bin increases in a binary exponential fashion as described in
9.4.2.22.11.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-96.
823
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-96—Optional subelement IDs for Transmit Stream/Category
Measurement Request
Subelement ID Name Extensible
0 Reserved
1 Triggered Reporting Yes
2–220 Reserved
221 Vendor Specific
222–255 Reserved
The Triggered Reporting subelement is used to specify measurement trigger thresholds. It is present only if
requesting triggered transmit stream/category measurement reporting. The Triggered Reporting subelement
format is shown in Figure 9-174.
Subelement ID Length Triggered Reporting
Octets: 1 1 6
Figure 9-174—Triggered Reporting subelement format
The Subelement ID field is defined in Table 9-96.
The Length field is defined in 9.4.3.
The Triggered Reporting field is as shown in Figure 9-175.
Consecutive
Trigger Average Error Error Delay Measurement Trigger
Conditions Threshold Threshold Count Timeout
Threshold
Octets: 1 1 1 1 1 1
Figure 9-175—Triggered Reporting field
Trigger Conditions is a bit-field that specifies reporting triggers when requesting a triggered transmit stream/
category measurement. The format of the Trigger Conditions bit-field is shown in Figure 9-176.
B0 B1 B2 B3 B7
Average Consecutive Delay Reserved
Bits: 1 1 1 5
Figure 9-176—Trigger Conditions bit-field
— Average is set to 1 to request that a Transmit Stream/Category Measurement report be generated
when the number of MSDUs for the TC or TS given by the TID that are discarded out of the number
of preceding MSDUs specified in Measurement Count is greater than or equal to the value given in
Average Error Threshold. MSDUs discarded due to the number of transmit attempts exceeding
824
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11ShortRetryLimit or dot11LongRetryLimit, or due to the MSDU lifetime having been reached,
are counted.
— Consecutive is set to 1 to request that a Transmit Stream/Category Measurement report be generated
when the number of MSDUs for the TC or TS given by the TID that are discarded in succession is
greater than or equal to the value given in Consecutive Error Threshold. MSDUs discarded due to
the number of transmit attempts exceeding dot11ShortRetryLimit or dot11LongRetryLimit, or due
to the MSDU lifetime having been reached, are counted.
— Delay is set to 1 to request that a Transmit Stream/Category Measurement report be generated when
the number of consecutive MSDUs for the TC or TS given by the TID that experience a transmit
delay greater than or equal to the value specified in the Delay Threshold subfield is greater than or
equal to the value given in Delayed MSDU Count. Delay is measured from the time the MSDU is
passed to the MAC until the point at which the entire MSDU has been successfully transmitted,
including receipt of the final Ack frame from the peer STA if the QoSAck service class is being
used.
The Average Error Threshold field contains a value representing the number of discarded MSDUs to be used
as the threshold value for the Average trigger condition. The field is reserved if the Average Error Threshold
subfield of the Trigger Conditions bit-field is 0.
The Consecutive Error Threshold field contains a value representing the number of discarded MSDUs to be
used as the threshold value for the consecutive trigger condition. The field is reserved if the Consecutive
Error Threshold subfield of the Trigger Conditions bit-field is 0.
The Delay Threshold field contains two subfields as shown in Figure 9-177. The Delay Threshold field is
reserved if the Delay Threshold subfield of the Trigger Conditions bit-field is 0.
B0 B1 B2 B7
Delayed MSDU
Range Delayed MSDU Count
Bits: 2 6
Figure 9-177—Delay Threshold subfield
Delayed MSDU Range contains a value representing the MSDU transmit delay at or above which an MSDU
is counted toward the Delayed MSDU Count threshold. Delayed MSDU Range is encoded as a value
representing the lower bound of a bin in the Transmit Delay Histogram as shown in Table 9-97. The
Transmit Delay Histogram is defined in 9.4.2.22.11.
Table 9-97—Delayed MSDU Range Definitions
Delayed MSDU Range Condition
0 Transmit Delay = Lower Bound of Bin 2
1 Transmit Delay = Lower Bound of Bin 3
2 Transmit Delay = Lower Bound of Bin 4
3 Transmit Delay = Lower Bound of Bin 5
Delayed MSDU Count contains a value representing the number of MSDUs to be used as the threshold
value for the delay trigger condition.
825
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Measurement Count field contains a number of MSDUs. This value is used to calculate an average
discard count for the average trigger condition. It is also used in place of measurement duration in
determining the scope of the reported results when a report is triggered; see 11.11.9.8.
The Trigger Timeout field contains a value, in units of 100 TU, during which a measuring STA does not
generate further triggered transmit stream/category measurement reports after a trigger condition has been
met. See 11.11.9.8.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.21.12 Measurement Pause request
The Measurement Request field corresponding to a Measurement Pause request is shown in Figure 9-178.
The Measurement Pause request cannot be processed in parallel with any other measurement request. See
11.11.9.7.
Pause Time Optional
Subelements
Octets: 2 variable
Figure 9-178—Measurement Request field format for Measurement Pause request
The Pause Time field contains a number between 1 and 65 535 representing the time period for which
measurements are suspended or paused. The time unit for the Pause Time is 10 TUs. The Pause Time value
0 is reserved. Measurement Pause requests are used to provide time delays between the execution times of
Measurement Request elements in a Measurement Request frame.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-98.
Table 9-98—Optional subelement IDs for Measurement Pause request
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Mul-
tiple Vendor Specific subelements are optionally present in the list of optional subelements.
826
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.21.13 Multicast Diagnostics request
The Measurement Request field corresponding to a Multicast Diagnostics request is shown in Figure 9-179.
The response to a Multicast Diagnostics request is a Multicast Diagnostics report.
Randomization Measurement Group MAC Multicast Triggered Optional
Reporting
Interval Duration Address (optional) Subelements
Octets: 2 2 6 0 or 5 variable
Figure 9-179—Measurement Request field format for a Multicast Diagnostics request
The Randomization Interval field is the upper limit of random delay before the measurement begins,
expressed in TUs. The use of the Randomization Interval field is described in 11.12.3. When requesting a
triggered multicast diagnostic report, the Randomization Interval field is reserved.
The Measurement Duration field is the duration of the requested measurement, expressed in TUs. When
requesting a triggered multicast diagnostic report, the Measurement Duration field is reserved.
A Group MAC Address field with the LSB of the first octet set to 1 contains the MAC address of the group
addressed frames to which the measurement request relates. A Group MAC Address field with the LSB of
the first octet set to 0 indicates that all group addressed frames, apart from the broadcast MAC address, are
requested.
The Multicast Triggered Reporting field is used to specify trigger conditions and thresholds. It is present
only when requesting triggered multicast diagnostic reporting. The format of Multicast Triggered Reporting
subelement is as shown in Figure 9-180.
Subelement ID Length Multicast Trigger Inactivity Reactivation
Condition Timeout Delay
Octets: 1 1 1 1 1
Figure 9-180—Multicast Triggered Reporting subelement format
The Multicast Trigger Condition field specifies reporting triggers for triggered management diagnostic
reporting. The format of the Multicast Trigger Condition field is shown in Figure 9-181.
B0 B1 B7
Inactivity
Timeout Reserved
Request
Bits: 1 7
Figure 9-181—Multicast Trigger Condition field
The Inactivity Timeout Request field is 1 to request that a multicast triggered report be generated when no
group addressed frames with the monitored group address are received in a time equal to the value given in
the Inactivity Timeout field. The Inactivity Timeout Request field is 0 when a multicast reception timeout is
not requested.
The Inactivity Timeout field contains a time value in units of 100 TUs to be used as the threshold value for
the inactivity timeout trigger condition.
827
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Reactivation Delay field contains a value in units of 100 TUs during which a measuring STA does not
generate further multicast triggered reports after a trigger condition has been met.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-99.
Table 9-99—Optional subelement IDs for STA Multicast Diagnostics request
Subelement ID Name Extensible
0 Reserved
1 Multicast Triggered Reporting
2–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
The use of Multicast Diagnostics request is defined in 11.11.19.
9.4.2.21.14 Location Civic request
The Measurement Request field corresponding to a Location Civic request is shown in Figure 9-182. The
response to a Location Civic request is a Location Civic report.
Location
Location Civic Location Location Optional
Subject Type Service Interval Service Interval Subelements
Units
Octets: 1 1 1 2 variable
Figure 9-182—Location Civic Request field format
The Location Subject field is a single octet and is defined in Table 9-94.
The Civic Location Type field contains the format of location information in the Location Civic report, as
indicated in Table 9-100.
When the Civic Location Type value is Vendor Specific, a Vendor Specific subelement is included in the
Optional Subelements field that identifies the Organization Identifier corresponding to the Civic Location
Type field.
828
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-100—Civic Location Type field values
Civic Location Type
Name Description
field value
0 IETF RFC 4776 Starting at the country code field (i.e., excluding the
GEOCONF_CIVIC/ OPTION_GEOCONF_CIVIC,
N/option-len and what fields); includes all
subsequent RFCs that define additional civic
address Types
1 Vendor Specific
2–255 Reserved
The Location Service Interval Units field contains the units for the Location Service Interval field, as
indicated in Table 9-101.
Table 9-101—Location Service Interval Units
Location Service
Description
Interval Units value
0 Seconds
1 Minutes
2 Hours
3–255 Reserved
The Location Service Interval field is the time interval, expressed in the units indicated in the Location
Service Interval Units field, at which the STA requests to receive Location Civic reports. A Location Service
Interval of 0 indicates that only a single Location Civic report is requested.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-102.
Table 9-102—Optional subelement IDs for Location Civic request
Subelement ID Name Extensible
0 Reserved
1 Originator Requesting STA MAC Address
2 Target MAC Address
3–220 Reserved
221 Vendor Specific
222–255 Reserved
829
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Originator Requesting STA MAC Address subelement contains the MAC address of the STA
requesting for the Location Information and it is present whenever the Location Subject field is set to 2. The
format of the Originator Requesting STA MAC Address subelement is shown in Figure 9-169.
The Target MAC Address subelement contains the MAC address of the STA whose Location Information is
requested and it is present whenever the Location Subject field is set to 2. The format of the Target MAC
address subelement is shown in Figure 9-170.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
9.4.2.21.15 Location Identifier request
The Measurement Request field corresponding to a Location Identifier request is shown in Figure 9-183.
The response to a Location Identifier request is a Location Identifier report.
Location Location Location Optional
Service Interval
Subject Units Service Interval Subelements
Octets: 1 1 2 variable
Figure 9-183—Location Identifier request field format
The Location Subject field is a single octet and is defined in Table 9-94.
The Location Service Interval Units field is defined in Table 9-101.
The Location Service Interval field is the time interval, expressed in the units indicated in the Location
Service Interval Units field, at which the STA requests to receive Location Identifier reports. A Location
Service Interval of 0 indicates that only a single Location Identifier report is requested.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-103.
Table 9-103—Optional subelement IDs for Location Identifier request
Subelement ID Name Extensible
0 Reserved
1 Originator Requesting STA MAC Address
2 Target MAC Address
3–220 Reserved
221 Vendor Specific
222–255 Reserved
The Originator Requesting STA MAC Address subelement contains the MAC address of the STA
requesting the Location Information and it is present whenever the Location Subject field is set to 2. The
format of the Originator Requesting STA MAC Address subelement is shown in Figure 9-169.
830
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Target MAC Address subelement contains the MAC address of the STA whose Location Information is
requested and it is present whenever the Location Subject field is set to 2. The format of the Target MAC
address subelement is shown in Figure 9-170.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
9.4.2.21.16 Directional Channel Quality request
The Measurement Request field corresponding to a Directional Channel Quality request is shown in
Figure 9-184. This Measurement Request is transmitted from a Requesting STA to a Requested STA to
perform measurements toward a Target STA.
Operating Class Channel Number AID Reserved Measurement Method
Octets: 1 1 1 1 1
Measurement Start Time Measurement Duration Number of Time Optional Subelements
Blocks
Octets: 8 2 1 Variable
Figure 9-184—Measurement Request field format for Directional Channel Quality request
The Operating Class field indicates the channel set for which the measurement request applies. Operating
Class and Channel Number together specify the channel frequency and spacing for which the measurement
request applies. Valid values of Operating Class are shown in Annex E.
Channel Number field indicates the channel number for which the measurement request applies. Channel
Number is defined within an Operating Class as shown in Annex E.
The AID field indicates the Target STA.
The Measurement Method field indicates the method that is to be used by the Requested STA to carry out
this measurement request and report back in the measurement report. If this field is set to 0, it indicates
ANIPI. If this field is set to 1, it indicates RSNI. Other values are reserved.
The Measurement Start Time field is set to the TSF timer at the time at which the requested measurement
starts. A value of 0 indicates that the measurement starts immediately.
The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement,
in units of TUs. See 11.11.4.
The Number of Time Blocks field indicates the number of time blocks within the Measurement Duration.
The ratio (Measurement Duration/Number of Time Blocks) provides the duration of an individual
measurement unit.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-104.
831
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-104—Optional subelement IDs for Directional Channel Quality request
Subelement ID Name Extensible
0 Reserved
1 Directional Channel Quality Reporting Yes
2–220 Reserved
221 Vendor Specific
222–255 Reserved
The Directional Channel Quality Reporting subelement indicates the condition for issuing a Directional
Channel Quality report. Directional Channel Quality Reporting subelement data field format is shown in
Figure 9-185 and contains a 1-octet Reporting Condition subfield and a 1-octet Directional Channel Quality
Reference Value subfield. The Reporting Condition subfield is described in Table 9-105. The Directional
Channel Quality Reference value is a Directional Channel Quality value and is the reference value for the
indicated reporting condition.
Reporting Directional Channel
Condition Quality Reference Value
Octets: 1 1
Figure 9-185—Directional Channel Quality Reporting data field format
Table 9-105—Reporting Condition subfield for Directional Channel Quality report
Reporting
Condition for report to be issued
condition
Report to be issued after each measurement (default, used when Directional Channel 0
Quality Reporting subelement is not included in Directional Channel Quality Request).
Report to be issued when measured ANIPI or RSNI is greater than or equal to the reference 1
value.
Report to be issued when measured ANIPI or RSNI is less than or equal to the reference 2
value.
Reserved 3–255
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements can be included in the list of Optional Subelements.
9.4.2.21.17 Directional Measurement request
The Measurement Request field corresponding to a Directional Measurement request is shown in
Figure 9-186. This Measurement Request is transmitted from a Requesting STA to a Requested STA to
perform directional channel measurements in all sectored receiving directions.
832
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Measurement
Operating Channel Measurement Duration Measurement
Class Number Start Time Method
per Direction
Octets 1 1 8 2 1
Figure 9-186—Measurement Request field format for Directional Measurement request
Operating Class field indicates the channel set for which the measurement request applies. Operating Class
and Channel Number together specify the channel frequency and spacing for which the measurement
request applies. Valid values of Operating Class are shown in Annex E.
Channel Number field indicates the channel number for which the measurement request applies. Channel
Number is defined within an Operating Class as shown in Annex E.
The Measurement Start Time field is set to the TSF timer at the time at which the requested measurement
starts. A value of 0 indicates that the measurement starts immediately.
The Measurement Duration per Direction field is set to the preferred or mandatory duration of the requested
measurement in each receiving direction, in units of TUs.
The Measurement Method field indicates the method that is to be used by the Requested STA to carry out
this measurement request and report back in the measurement report. If this field is set to 0, it indicates
ANIPI. If this field is set to 1, it indicates RCPI. If the field is set to 2, it indicates Channel Load. Other
values are reserved.
9.4.2.21.18 Directional Statistics request
The Measurement Request field corresponding to a Directional Statistics request is shown in Figure 9-187.
This Measurement Request is transmitted from a Requesting STA to a Requested STA to perform
directional channel measurements in all sectored receiving directions.
Measurement Directional
Operating Channel Measurement Measurement
Class Number Start Time Duration per Method Statistics
Direction Bitmap
Octets 1 1 8 2 1 1
Figure 9-187—Measurement Request field format for Directional Statistics request
Operating Class field indicates the channel set for which the measurement request applies. Operating Class
and Channel Number together specify the channel frequency and spacing for which the measurement
request applies. Valid values of Operating Class are shown in Annex E.
Channel Number field indicates the channel number for which the measurement request applies. Channel
Number is defined within an Operating Class as shown in Annex E.
The Measurement Start Time field is set to the TSF timer at the time at which the requested measurement
starts. A value of 0 indicates that the measurement starts immediately.
The Measurement Duration per Direction field is set to the preferred or mandatory duration of the requested
measurement in each receiving direction, in units of TUs.
833
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Measurement Method field indicates the method that is to be used by the Requested STA to carry out
this measurement request and report back in the measurement report. If this field is set to 0, it indicates
ANIPI. If this field is set to 1, it indicates RCPI. If the field is set to 2, it indicates Channel Load. Other
values are reserved.
The Directional Statistics Bitmap field format is shown in Figure 9-188. The Maximum field set to 1
indicates that the maximum measurement result among all directions is expected in the measurement report.
The Minimum field set to 1 indicates that the minimum measurement result among all directions is expected
in the measurement report. The Average field set to 1 indicates that the average measurement result among
all directions is expected in the measurement report. The Variance field set to 1 indicates that the variance of
measurement results among all directions is expected in the measurement report. Other bits are reserved.
B0 B1 B2 B3 B4 B7
Maximum Minimum Average Variance Reserved
Bits: 1 1 1 1 4
Figure 9-188—Directional Statistics Bitmap field format
9.4.2.21.19 Fine Timing Measurement Range request
The Measurement Request field corresponding to a Fine Timing Measurement Range request is shown in
Figure 9-189.
Randomization Minimum AP FTM Range
Interval Count Subelements
Octets: 2 1 variable
Figure 9-189—Measurement Request field for a Fine Timing Measurement Range request
The Randomization Interval field specifies the upper bound of the random delay to be used prior to making
the measurement, in units of TUs. See 11.11.3.
The Minimum AP Count field specifies the minimum number of FTM ranges between the requested STA
and the APs listed in the Neighbor Report Subelements field that are requested. The value 0 and values
above 15 are reserved.
The FTM Range Subelements field contains one or more subelements. The subelement format and ordering
of subelements are defined in 9.4.3. The FTM Range subelements are listed in Table 9-106.
The Subelement IDs for subelements in the Fine Timing Measurement Range request are defined in
Table 9-106.
Table 9-106—FTM Range subelement IDs for Fine Timing Measurement Range
request
Subelement ID Name Extensible
0–3 Reserved
4 Maximum Age Yes
5-51 Reserved
834
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-106—FTM Range subelement IDs for Fine Timing Measurement Range
request (continued)
Subelement ID Name Extensible
52 Neighbor Report Subelements
53–220 Reserved
221 Vendor Specific
222–255 Reserved
The FTM Range Subelements field includes a concatenation of at least Minimum AP Count Neighbor
Report subelements. Each Neighbor Report subelement has the same format as the Neighbor Report element
and contains the Wide Bandwidth Channel subelement. See Table 9-106 and Table 9.4.2.37. The Neighbor
Report Subelements field specifies a superset of nearby APs with which the requested STA is requested to
perform the FTM procedure (see 11.11.9.11).
The Maximum Age subelement indicates the maximum age of the requested FTM ranges. The format of the
Maximum Age subelement is defined in Figure 9-190. The absence of a Maximum Age subelement
indicates that FTM ranges determined at or after the Fine Timing Measurement Range request is received
are requested.
Subelement ID Length Maximum Age
Octets: 1 1 2
Figure 9-190—Format of Maximum Age subelement
The Subelement ID field is defined in Table 9-106.
The Length field is defined in 9.4.3.
The Maximum Age field of the Maximum Age subelement indicates the maximum elapsed time between
when FTM ranges are determined and when a Fine Timing Measurement Range request is received, within
which the FTM ranges satisfy the Fine Timing Measurement Range request. The Maximum Age field is
encoded as an unsigned integer with units of 0.1 s. The value 0 is reserved. The value 65 535 indicates that
FTM ranges determined at any time are acceptable.
The Vendor Specific subelement has the same format as the corresponding element (see 9.4.2.26). Multiple
Vendor Specific subelements can be included in the Optional Subelements field.
9.4.2.22 Measurement Report element
9.4.2.22.1 General
The Measurement Report element contains a measurement report. The format of the Measurement Report
element is shown in Figure 9-191. The Measurement Report element is included in Measurement Report
frames, as described in 9.6.2.3, or Radio Measurement Report frames, as described in 9.6.7.3. Measurement
Types 0, 1, and 2 are used for spectrum management and are included only in Measurement Report frames.
All other Measurement Types are included only in Radio Measurement Report frames. The use of
Measurement Report elements and frames for spectrum management is described in 11.9.7. The use of
Measurement Report elements and frames for radio measurement is described in 11.11.
835
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Measurement Measurement Measurement Measurement
Element ID Length Token Report Mode Type Report
Octets: 1 1 1 1 1 variable
Figure 9-191—Measurement Report element format
The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 3.
The Measurement Token field is set to the value of the Measurement Token field in the corresponding
Measurement Request element. If the Measurement Report element is being sent autonomously, then the
Measurement Token is set to 0. If the Measurement Report element is being sent in a Location Track
Notification frame, then the value of the Measurement Token field is set to the same value as the Location
Configuration Request frame Dialog Token field that configured the STA to send the Location Track
Notification frames.
The Measurement Report Mode field (shown in Figure 9-192) is used to indicate the reason for a failed or
rejected measurement request. The Measurement Report Mode is a bit field with the following bits defined:
— Late bit (bit 0) indicates whether this STA is unable to carry out a measurement request because it
received the request after the requested measurement time. The Late bit is set to 1 to indicate the
request was too late. The Late bit is set to 0 to indicate the request was received in time for the
measurement to be executed. The Late bit only applies to spectrum management measurement and is
set to 0 in all measurement report elements for radio measurement types (see Table 9-107).
— Incapable bit (bit 1) indicates whether this STA is incapable of generating a report of the type
specified in the Measurement Type field that was previously requested by the destination STA of
this Measurement Report element. The Incapable bit is set to 1 to indicate the STA is incapable. The
Incapable bit is set to 0 to indicate the STA is capable or the report is autonomous.
— Refused bit (bit 2) indicates whether this STA is refusing to generate a report of the type specified in
the Measurement Type field that was previously requested by the destination STA of this
Measurement Report element. The Refused bit is set to 1 to indicate the STA is refusing. The
Refused bit is set to 0 to indicate the STA is not refusing or the report is autonomous.
— All other bits are reserved.
B0 B1 B2 B3 B7
Late Incapable Refused Reserved
Bits: 1 1 1 5
Figure 9-192—Measurement Report Mode field
No more than one bit is set to 1 within a Measurement Report Mode field. All bits within the Measurement
Mode field are set to 0 if the results of a successful measurement request or an autonomous measurement are
being reported.
The Measurement Type field is set to a number that identifies the measurement report. The Measurement
Types that have been allocated are shown in Table 9-107.
836
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-107—Measurement Type field definitions for measurement reports
Name Measurement Type
Basic 0
CCA 1
RPI Histogram 2
Channel Load 3
Noise Histogram 4
Beacon 5
Frame 6
STA Statistics 7
LCI 8
Transmit Stream/Category Measurement 9
Multicast Diagnostics 10
Location Civic 11
Location Identifier 12
Directional Channel Quality 13
Directional Measurement 14
Directional Statistics 15
Fine Timing Measurement Range 16
Reserved 17–255
The Measurement Report field is not present when the Late bit is equal to 1, the Incapable bit is equal to 1,
or the Refused bit is equal to 1. Otherwise, it contains a single measurement report, as described in
9.4.2.22.2 to 9.4.2.22.11.
References in this standard to a ‘ report’, where corresponds to one of the Measurement
Types in Table 9-107 is equivalent to (according to context) a) ‘a Measurement Report frame or Radio
Measurement Report frame carrying a Measurement Report element with the Measurement Type field equal
to ’ or b) ‘a Measurement Report element with the Measurement Type field equal to ’.
9.4.2.22.2 Basic report
The format of the Measurement Report field corresponding to a Basic report is shown in Figure 9-193.
Channel Measurement Measurement Map (see
Number Start Time Duration Figure 9-194)
Octets: 1 8 2 1
Figure 9-193—Measurement Report field format for a Basic report
837
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Channel Number field is set to the channel number to which the Basic report applies where the Channel
Number is a value from the “Channel set” column in Table E-4, in a row having the same value in the
“Channel spacing (MHz)” column as the width of the primary channel.
The Measurement Start Time field is set to the TSF at the time (± 32 s) at which the Basic report
measurement started.
The Measurement Duration field is set to the duration over which the Basic report was measured, expressed
in TUs.
The Map field is coded as a bit field, as shown in Figure 9-194, and contains the following bits:
— BSS bit, which is set to 1 when at least one valid MPDU was received in the channel during the
measurement period from another BSS. Otherwise, the BSS bit is set to 0.
— OFDM preamble bit, which is set to 1 when at least one sequence of short training symbols, as
defined in 17.3.3, was detected in the channel during the measurement period without a subsequent
valid SIGNAL field (see 17.3.4). This indicates the presence of an OFDM preamble, such as high-
performance RLAN/2 (HIPERLAN/2). Otherwise, the OFDM preamble bit is set to 0.
— Unidentified Signal bit, which is set to 1 when, in the channel during the measurement period, there
is significant power detected that is not characterized as radar, an OFDM preamble, or a valid
MPDU. Otherwise, the Unidentified Signal bit is set to 0. The definition of significant power is
implementation dependent.
— Radar bit, which is set to 1 when radar was detected operating in the channel during the
measurement period. The radar detection algorithm that satisfies regulatory requirements is outside
the scope of this standard. Otherwise, the Radar bit is set to 0.
— Unmeasured bit, which is set to 1 when this channel has not been measured. Otherwise, the
Unmeasured bit is set to 0. When the Unmeasured field is equal to 1, all of the other bit fields are set
to 0.
Orthogonal
frequency division Unidentified
BSS Radar Unmeasured Reserved
multiplexing Signal
(OFDM) Preamble
Bit: 0 1 2 3 4 5-7
Figure 9-194—Map field format
9.4.2.22.3 CCA report
The format of the Measurement Report field corresponding to a CCA report is shown in Figure 9-195.
Channel Measurement Measurement CCA Busy
Number Start Time Duration Fraction
Octets: 1 8 2 1
Figure 9-195—Measurement Report field format for a CCA report
The Channel Number field contains the channel number to which the CCA report applies where the Channel
Number is a value from the “Channel set” column in Table E-4, in a row having the same value in the
“Channel spacing (MHz)” column as the width of the primary channel.
The Measurement Start Time field is set to the TSF at the time (± 32 s) at which the CCA report
measurement started.
838
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Measurement Duration field is set to the duration over which the CCA report was measured, expressed
in TUs.
The CCA Busy Fraction field contains the fractional duration over which CCA indicated the channel was
busy during the measurement duration. The resolution of the CCA busy measurement is in microseconds.
The CCA Busy Fraction value is defined as
255 t busy
--------------------------
-
1024 t MD
where
tbusy is the duration CCA indicated channel was busy ( s)
tMD is the measurement duration (TUs)
9.4.2.22.4 RPI histogram report
The format of the Measurement Report field corresponding to an RPI histogram report is shown in
Figure 9-196.
Channel Measurement Measurement
Number Start Time Duration
Octets: 1 8 2
RPI 0 RPI 1 RPI 2 RPI 3 RPI 4 RPI 5 RPI 6 RPI 7
density density density density density density density density
Octets: 1 1 1 1 1 1 1 1
Figure 9-196—Measurement Report field format for an RPI histogram report
The Channel Number field is set to the channel number to which the RPI histogram report applies where the
Channel Number is a value from the “Channel set” column in Table E-4, in a row having the same value in
the “Channel spacing (MHz)” column as the width of the primary channel.
The Measurement Start Time field is set to the TSF at the time (± 32 s) at which the RPI histogram report
measurement started.
The Measurement Duration field is set to the duration over which the RPI histogram report was measured,
expressed in TUs.
The RPI histogram report contains the RPI densities observed in the channel for the eight RPI levels defined
in Table 9-108. See 11.11.12.
Table 9-108—RPI definitions for an RPI histogram report
RPI Power observed at the antenna (dBm)
0 Power –87
1 –87 < Power –82
2 –82 < Power –77
839
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-108—RPI definitions for an RPI histogram report (continued)
RPI Power observed at the antenna (dBm)
3 –77 < Power –72
4 –72 < Power –67
5 –67 < Power –62
6 –62 < Power –57
7 –57 < Power
The RPI histogram report provides an additional mechanism for a STA to gather information on the state of
a channel from other STAs. The STA might use this information to assist in the choice of new channel, to
help avoid false radar detections, and to assess the general level of interference present on a channel.
9.4.2.22.5 Channel Load report
The format of the Measurement Report field corresponding to a Channel Load report is shown in
Figure 9-197.
Actual
Operating Channel Measurement Optional
Class Number Measurement Duration Channel Load Subelements
Start Time
Octets: 1 1 8 2 1 variable
Figure 9-197—Measurement Report field format for Channel Load report
If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the
operating class that identifies the channel set for which the measurement report applies. The Country,
Operating Class, and Channel Number fields together specify the channel frequency and spacing for which
the measurement report applies. Valid operating classes are listed in Annex E, excluding operating classes
that encompass a primary channel but do not identify the location of the primary channel. The Channel
Number field indicates the channel number for which the measurement report applies. Channel number is
defined within an operating class as shown in Annex E.
NOTE—Examples of operating classes that encompass a primary channel but do not identify the location of the primary
channel are operating classes with a value of 80 or 160 in the “Channel Spacing (MHz)” column of the applicable table
in Annex E.
If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel
Switch subelement indicate the channel for which the measurement report applies, and the Operating Class
and Channel Number fields together specify the primary channel and primary 40 MHz channel within the
channel identified by the Wide Bandwidth Channel Switch subelement.
Actual Measurement Start Time is set to the value of the measuring STA’s TSF timer at the time the
measurement started.
Measurement Duration is set to the duration over which the Channel Load report was measured, in units of
TUs.
840
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Channel Load contains the proportion of measurement duration for which the measuring STA determined
the channel to be busy. Procedure for Channel Load measurement and definition of channel load values are
found in 11.11.9.3.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-109.
Table 9-109—Optional subelement IDs for Channel Load report
Subelement ID Name Extensible
0–162 Reserved
163 Wide Bandwidth Yes
Channel Switch
164–220 Reserved
221 Vendor Specific
222–255 Reserved
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or
80+80 MHz BSS bandwidth.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.22.6 Noise Histogram report
The format of the Measurement Report field of a Noise Histogram report is shown in Figure 9-198.
Operating Channel Actual Measurement Measurement Antenna
Class Number Start Time Duration ID ANPI
Octets: 1 1 8 2 1 1
IPI 0 IPI 1 IPI 2 . . . IPI 8 IPI 9 IPI 10 Optional
Density Density Density Density Density Density subelements
Octets: 1 1 1 5 1 1 1 variable
Figure 9-198—Measurement Report field format for Noise Histogram report
If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the
operating class that identifies the channel set for which the measurement report applies. The Country,
Operating Class, and Channel Number fields together specify the channel frequency and spacing for which
the measurement report applies. Valid operating classes are listed in Annex E, excluding operating classes
that encompass a primary channel but do not identify the location of the primary channel. The Channel
841
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Number field indicates the channel number for which the measurement report applies. Channel number is
defined within an operating class as shown in Annex E.
If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel
Switch subelement indicate the channel for which the measurement report applies, and the Operating Class
and Channel Number together specify the primary channel and primary 40 MHz channel within the channel
identified by the Wide Bandwidth Channel Switch subelement.
Actual Measurement Start Time is set to the value of the measuring STA’s TSF timer at the time the
measurement started.
Measurement Duration is set to the duration over which the Noise Histogram report was measured, in units
of TUs.
Antenna ID is set to the identifying number for the antenna(s) used for this measurement. Antenna ID is
defined in 9.4.2.40.
ANPI is set to the average noise plus interference power value measured during the indicated measurement
duration while the indicated channel is idle as described in 11.11.9.4.
The Noise Histogram report contains the IPI densities, as defined in 11.11.9.4, observed in the channel for
the eleven IPI levels defined in Table 9-110.
Table 9-110—IPI Definitions for a Noise Histogram report
IPI Level IPI Measured Power (dBm)
0 IPI – 92
1 –92 < IPI –89
2 –89 < IPI –86
3 –86 < IPI –83
4 –83 < IPI –80
5 –80 < IPI –75
6 –75 < IPI –70
7 –70 < IPI –65
8 –65 < IPI –60
9 –60 < IPI –55
10 –55 < IPI
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-111.
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161) with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80
MHz BSS bandwidth.
842
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-111—Optional subelement IDs for Noise Histogram report
Subelement ID Name Extensible
0–162 Reserved
163 Wide Bandwidth Yes
Channel Switch
164–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.22.7 Beacon report
The format of the Measurement Report field corresponding to a Beacon report is shown in Figure 9-199.
Actual Reported
Operating Channel Measurement Start Measurement Frame
Class Number Duration
Time Information
Octets: 1 1 8 2 1
Antenna Parent Optional
RCPI RSNI BSSID ID TSF Subelements
Octets: 1 1 6 1 4 variable
Figure 9-199—Measurement Report field format for Beacon report
The Operating Class field indicates the operating class that identifies the channel set of the received Beacon
or Probe Response frame. The Country, Operating Class, and Channel Number fields together specify the
channel frequency and spacing of the received Beacon or Probe Response frame. Valid operating classes are
listed in Annex E.
The Channel Number field indicates the channel number of the received Beacon or Probe Response frame.
Channel number is defined within an operating class as shown in Annex E.
If the PPDU carrying the received frame comprises noncontiguous frequency segments, the Operating Class
and Channel Number fields identify the center frequency of frequency segment 0, and a Wide Bandwidth
Channel Switch subelement is included to identify the center frequency of frequency segment 1 (the other
fields in the subelement indicate 80+80 bandwidth and the same center frequency of frequency segment 0 as
the Operating Class and Channel Number fields); otherwise the Wide Bandwidth Channel Switch
subelement is not included.
Actual Measurement Start Time is set to the value of the measuring STA’s TSF timer at the time the
measurement started.
Measurement Duration is set to the duration over which the Beacon report was measured, in units of TUs.
The Reported Frame Information field contains two subfields as shown in Figure 9-200.
843
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B6 B7
Condensed PHY Reported Frame
Type Type
Bits: 7 1
Figure 9-200—Reported Frame Information field
Condensed PHY Type indicates the physical medium type on which the Beacon, Measurement Pilot, or
Probe Response frame being reported was received. It has an integer value between 0 and 127 coded
according to dot11PHYType.
Reported Frame Type indicates the type of frame reported. A value of 0 indicates a Beacon or Probe
Response frame; a value of 1 indicates a Measurement Pilot frame.
RCPI indicates the received channel power of the Beacon, Measurement Pilot, or Probe Response frame,
which is a logarithmic function of the received signal power, as defined 9.4.2.38.
RSNI indicates the received signal-to-noise indication for the Beacon, Measurement Pilot, or Probe
Response frame, as described in 9.4.2.41.
The BSSID field contains the BSSID from the Beacon, Measurement Pilot, or Probe Response frame being
reported.
The Antenna ID field contains the identifying number for the antenna(s) used for this measurement. Antenna
ID is defined in 9.4.2.40.
The Parent TSF field contains the lower 4 octets of the measuring STA’s TSF timer value at the start of
reception of the first octet of the timestamp field of the reported Beacon, Measurement Pilot, or Probe
Response frame at the time the Beacon, Measurement Pilot, or Probe Response frame being reported was
received.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-112.
Table 9-112—Optional subelement IDs for Beacon report
Subelement ID Name Extensible
0 Reserved
1 Reported Frame Body
2–162 Reserved
163 Wide Bandwidth Yes
Channel Switch
164-220 Reserved
221 Vendor Specific
222–255 Reserved
844
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Reported Frame Body subelement contains the requested fields and elements of the frame body of the
reported Beacon, Measurement Pilot, or Probe Response frame. If the Reporting Detail subelement of the
corresponding Beacon request equals 0, the Reported Frame Body subelement is not included in the Beacon
report. If the Reporting Detail subelement equals 1, all fixed fields and any elements identified in a Request
element or Extended Request element in the corresponding Beacon request are included in the Reported
Frame Body subelement, in the order that they appeared in the reported frame. If the Reporting Detail field
equals 2, all fixed fields and elements are included in the order they appeared in the reported frame.
Reported TIM elements are truncated such that only the first 4 octets of the element are reported and the
element Length field is modified to indicate the truncated length of 4. Reported IBSS dynamic frequency
selection (DFS) elements are truncated so that only the lowest and highest channel number map are reported
and the element Length field is modified to indicate the truncated length of 13. Reported RSNEs are
truncated so that only the first 4 octets of the element are reported and the element Length field is modified
to indicate the truncated length of 4. If the length of the Reported Frame Body subelement would cause the
Measurement Report element to exceed the maximum element size, then the Reported Frame Body
subelement is truncated so that the last element in the Reported Frame Body subelement is a complete
element.
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161) with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80
MHz BSS bandwidth.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.22.8 Frame report
The format of the Measurement Report field corresponding to a Frame report is shown in Figure 9-201.
Actual
Operating Channel Measurement Measurement Optional
Class Number Duration Subelements
Start Time
Octets: 1 1 8 2 variable
Figure 9-201—Measurement Report field format for Frame report
If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the
operating class that identifies the channel set for which the measurement report applies. The Country,
Operating Class, and Channel Number fields together specify the channel frequency and spacing for which
the measurement report applies. Valid operating classes are listed in Annex E, excluding operating classes
that encompass a primary channel but do not identify the location of the primary channel. The Channel
Number field indicates the channel number for which the measurement report applies. Channel number is
defined within an operating class as shown in Annex E.
If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel
Switch subelement indicate the channel for which the measurement report applies, and the Operating Class
and Channel Number fields together specify the primary channel and primary 40 MHz channel within the
channel identified by the Wide Bandwidth Channel Switch subelement.
Actual Measurement Start Time is set to the value of the measuring STA’s TSF timer at the time the
measurement started.
Measurement Duration is set to the duration over which the Frame report was measured, in units of TUs.
845
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-113.
Table 9-113—Optional subelement IDs for Frame report
Subelement ID Name Extensible
0 Reserved
1 Frame Count Report
2–162 Reserved
163 Wide Bandwidth Yes
Channel Switch
164–220 Reserved
221 Vendor Specific
222–255 Reserved
The Frame Count Report subelement is used to report information about frames sent by a transmitter. The
Frame Count Report subelement is as shown in Figure 9-202.
Subelement ID Length Frame Report Entries
Octets: 1 1 n x 19
Figure 9-202—Frame Count Report subelement format
The Subelement ID field is defined in Table 9-113.
The Length field is defined in 9.4.3.
The Frame Report Entries field contains zero or more frame report entries. The structure of a frame report
entry is shown in Figure 9-203.
Transmit BSSID PHY Average Last Last Antenna Frame Count
Address Type RCPI RSNI RCPI ID
Octets: 6 6 1 1 1 1 1 2
Figure 9-203—Frame Report Entry field format
The Transmit Address field contains the Transmitter Address (TA) from the frames being reported.
The BSSID field contains the BSSID from the frames being reported.
PHY Type indicates the physical medium type for the frame(s) being reported. Valid entries are coded
according to dot11PHYType.
846
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Average RCPI indicates the average value for the received channel power of frames received and counted in
this Frame Report Entry field, as described in 11.11.9.2. Average RCPI is a logarithmic function of the
received signal power, as defined 9.4.2.38.
Last RSNI indicates the received signal-to-noise indication of the most recently measured frame counted in
this Frame Report Entry field, as described in 9.4.2.41.
Last RCPI indicates the received channel power of the most recently measured frame counted in this Frame
Report Entry field. Last RCPI is a logarithmic function of the received signal power, as defined in 9.4.2.38.
The Antenna ID field contains the identifying number for the antenna(s) used to receive the most recently
measured frame counted in this Frame Report Entry field. Antenna ID is defined in 9.4.2.40.
Frame Count is a count of the Data and Management frames received with the indicated transmit address
and BSSID during the measurement duration. The value 65 535 indicates a count of 65 535 or more.
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or
80+80 MHz BSS bandwidth.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.22.9 STA Statistics report
The format of the Measurement Report field of a STA Statistics report is shown in Figure 9-204.
Measurement Statistics Optional
Duration Group Identity Group Data Subelements
Octets: 2 1 variable variable
Figure 9-204—Measurement Report field format for STA Statistics report
The STA Statistics report reports the change in the requested Statistics Group Data values measured within
the Measurement Duration. When the Measurement Duration is equal to 0 the current values of the
requested Statistics Group Data is reported, rather than the change.
The Measurement Duration is set to the duration over which the change in Statistics Group Data was
measured and reported, in units of TUs. A Measurement Duration value of 0 indicates a report of the current
values of the Statistics Group Data.
Group Identity indicates the requested statistics group describing the Statistics Group Data according to
Table 9-114.
Statistics Group Data contains the requested statistics from the MIB in Annex C related to the interface on
which the request was received according to Table 9-114. Units used for reporting a statistic or change in
statistic are the units used to define the statistic in Annex C. When Measurement Duration value is nonzero,
the reported data values for statistics that are not counters are the current values of the statistics data at the
end of the Measurement Duration.
847
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-114—Group Identity for a STA Statistics report
Group Statistics Group
Identity Data field length Statistics Returned
Requested (octets)
0 28 dot11Counters Group for the Interface on which the STA Statistics
request was received (with the exception of WEPUndecryptableCount
and those counters listed in Group Identity 1):
dot11TransmittedFragmentCount (Counter32),
dot11GroupTransmittedFrameCount (Counter32),
dot11FailedCount (Counter32),
dot11ReceivedFragmentCount (Counter32),
dot11GroupReceivedFrameCount (Counter32),
dot11FCSErrorCount (Counter32),
dot11TransmittedFrameCount (Counter32)
1 24 dot11MACStatistics Group for the Interface on which the STA Statistics
request was received:
dot11RetryCount (Counter32),
dot11MultipleRetryCount (Counter32),
dot11FrameDuplicateCount (Counter32),
dot11RTSSuccessCount (Counter32),
dot11RTSFailureCount (Counter32),
dot11AckFailureCount (Counter32)
2 52 dot11QosCounters Group for UP0 for the Interface on which the STA
Statistics request was received:
dot11QosTransmittedFragmentCount (Counter32),
dot11QosFailedCount (Counter32),
dot11QosRetryCount (Counter32),
dot11QosMultipleRetryCount (Counter32),
dot11QosFrameDuplicateCount (Counter32),
dot11QosRTSSuccessCount (Counter32),
dot11QosRTSFailureCount (Counter32),
dot11QosAckFailureCount (Counter32),
dot11QosReceivedFragmentCount (Counter32),
dot11QosTransmittedFrameCount (Counter32),
dot11QosDiscardedFrameCount (Counter32),
dot11QosMPDUsReceivedCount (Counter32),
dot11QosRetriesReceivedCount (Counter32)
3 52 dot11QosCounters Group for UP1 for the Interface on which the STA
Statistics request was received:
dot11QosTransmittedFragmentCount (Counter32),
dot11QosFailedCount (Counter32),
dot11QosRetryCount (Counter32),
dot11QosMultipleRetryCount (Counter32),
dot11QosFrameDuplicateCount (Counter32),
dot11QosRTSSuccessCount (Counter32),
dot11QosRTSFailureCount (Counter32),
dot11QosAckFailureCount (Counter32),
dot11QosReceivedFragmentCount (Counter32),
dot11QosTransmittedFrameCount (Counter32),
dot11QosDiscardedFrameCount (Counter32),
dot11QosMPDUsReceivedCount (Counter32),
dot11QosRetriesReceivedCount (Counter32)
848
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-114—Group Identity for a STA Statistics report (continued)
Group Statistics Group
Identity Data field length Statistics Returned
Requested (octets)
4 52 dot11QosCounters Group for UP2 for the Interface on which the STA
Statistics request was received:
dot11QosTransmittedFragmentCount (Counter32),
dot11QosFailedCount (Counter32),
dot11QosRetryCount (Counter32),
dot11QosMultipleRetryCount (Counter32),
dot11QosFrameDuplicateCount (Counter32),
dot11QosRTSSuccessCount (Counter32),
dot11QosRTSFailureCount (Counter32),
dot11QosAckFailureCount (Counter32),
dot11QosReceivedFragmentCount (Counter32),
dot11QosTransmittedFrameCount (Counter32),
dot11QosDiscardedFrameCount (Counter32),
dot11QosMPDUsReceivedCount (Counter32),
dot11QosRetriesReceivedCount (Counter32)
5 52 dot11QosCounters Group for UP3 for the Interface on which the STA
Statistics request was received:
dot11QosTransmittedFragmentCount (Counter32),
dot11QosFailedCount (Counter32),
dot11QosRetryCount (Counter32),
dot11QosMultipleRetryCount (Counter32),
dot11QosFrameDuplicateCount (Counter32),
dot11QosRTSSuccessCount (Counter32),
dot11QosRTSFailureCount (Counter32),
dot11QosAckFailureCount (Counter32),
dot11QosReceivedFragmentCount (Counter32),
dot11QosTransmittedFrameCount (Counter32),
dot11QosDiscardedFrameCount (Counter32),
dot11QosMPDUsReceivedCount (Counter32),
dot11QosRetriesReceivedCount (Counter32)
6 52 dot11QosCounters Group for UP4 for the Interface on which the STA
Statistics request was received:
dot11QosTransmittedFragmentCount (Counter32),
dot11QosFailedCount (Counter32),
dot11QosRetryCount (Counter32),
dot11QosMultipleRetryCount (Counter32),
dot11QosFrameDuplicateCount (Counter32),
dot11QosRTSSuccessCount (Counter32),
dot11QosRTSFailureCount (Counter32),
dot11QosAckFailureCount (Counter32),
dot11QosReceivedFragmentCount (Counter32),
dot11QosTransmittedFrameCount (Counter32),
dot11QosDiscardedFrameCount (Counter32),
dot11QosMPDUsReceivedCount (Counter32),
dot11QosRetriesReceivedCount (Counter32)
849
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-114—Group Identity for a STA Statistics report (continued)
Group Statistics Group
Identity Data field length Statistics Returned
Requested (octets)
7 52 dot11QosCounters Group for UP5 for the Interface on which the STA
Statistics request was received:
dot11QosTransmittedFragmentCount (Counter32),
dot11QosFailedCount (Counter32),
dot11QosRetryCount (Counter32),
dot11QosMultipleRetryCount (Counter32),
dot11QosFrameDuplicateCount (Counter32),
dot11QosRTSSuccessCount (Counter32),
dot11QosRTSFailureCount (Counter32),
dot11QosAckFailureCount (Counter32),
dot11QosReceivedFragmentCount (Counter32),
dot11QosTransmittedFrameCount (Counter32),
dot11QosDiscardedFrameCount (Counter32),
dot11QosMPDUsReceivedCount (Counter32),
dot11QosRetriesReceivedCount (Counter32)
8 52 dot11QosCounters Group for UP6 for the Interface on which the STA
Statistics request was received:
dot11QosTransmittedFragmentCount (Counter32),
dot11QosFailedCount (Counter32),
dot11QosRetryCount (Counter32),
dot11QosMultipleRetryCount (Counter32),
dot11QosFrameDuplicateCount (Counter32),
dot11QosRTSSuccessCount (Counter32),
dot11QosRTSFailureCount (Counter32),
dot11QosAckFailureCount (Counter32),
dot11QosReceivedFragmentCount (Counter32),
dot11QosTransmittedFrameCount (Counter32),
dot11QosDiscardedFrameCount (Counter32),
dot11QosMPDUsReceivedCount (Counter32),
dot11QosRetriesReceivedCount (Counter32)
9 52 dot11QosCounters Group for UP7 for the Interface on which the STA
Statistics request was received:
dot11QosTransmittedFragmentCount (Counter32),
dot11QosFailedCount (Counter32),
dot11QosRetryCount (Counter32),
dot11QosMultipleRetryCount (Counter32),
dot11QosFrameDuplicateCount (Counter32),
dot11QosRTSSuccessCount (Counter32),
dot11QosRTSFailureCount (Counter32),
dot11QosAckFailureCount (Counter32),
dot11QosReceivedFragmentCount (Counter32),
dot11QosTransmittedFrameCount (Counter32),
dot11QosDiscardedFrameCount (Counter32),
dot11QosMPDUsReceivedCount (Counter32),
dot11QosRetriesReceivedCount (Counter32)
850
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-114—Group Identity for a STA Statistics report (continued)
Group Statistics Group
Identity Data field length Statistics Returned
Requested (octets)
10 8 dot11BSSAverageAccessDelay Group (only available at an AP):
dot11STAStatisticsAPAverageAccessDelay (INTEGER),
dot11STAStatisticsAverageAccessDelayBestEffort (INTEGER),
dot11STAStatisticsAverageAccessDelayBackGround (INTEGER),
dot11STAStatisticsAverageAccessDelayVideo (INTEGER),
dot11STAStatisticsAverageAccessDelayVoice (INTEGER),
dot11STAStatisticsStationCount (INTEGER),
dot11STAStatisticsChannelUtilization (INTEGER)
11 40 STA Counters from dot11CountersGroup3 (A-MSDU):
dot11TransmittedAMSDUCount (Counter32),
dot11FailedAMSDUCount (Counter32),
dot11RetryAMSDUCount (Counter32),
dot11MultipleRetryAMSDUCount (Counter32),
dot11TransmittedOctetsInAMSDUCount (Counter64),
dot11AMSDUAckFailureCount (Counter32),
dot11ReceivedAMSDUCount (Counter32),
dot11ReceivedOctetsInAMSDUCount (Counter64)
12 36 STA Counters from dot11CountersGroup3 (A-MPDU):
dot11TransmittedAMPDUCount (Counter32),
dot11TransmittedMPDUsInAMPDUCount (Counter32),
dot11TransmittedOctetsInAMPDUCount (Counter64),
dot11AMPDUReceivedCount (Counter32),
dot11MPDUInReceivedAMPDUCount (Counter32),
dot11ReceivedOctetsInAMPDUCount (Counter64),
dot11AMPDUDelimiterCRCErrorCount (Counter32)
13 36 STA Counters from dot11CountersGroup3 (BlockAckReq, Channel
Width, PSMP):
dot11ImplicitBARFailureCount (Counter32),
dot11ExplicitBARFailureCount (Counter32),
dot11ChannelWidthSwitchCount (Counter32),
dot11TwentyMHzFrameTransmittedCount (Counter32),
dot11FortyMHzFrameTransmittedCount (Counter32),
dot11TwentyMHzFrameReceivedCount (Counter32),
dot11FortyMHzFrameReceivedCount (Counter32),
dot11PSMPUTTGrantDuration (Counter32),
dot11PSMPUTTUsedDuration (Counter32)
14 36 STA Counters from dot11CountersGroup3 (RD, dual CTS, L-SIG TXOP
protection):
dot11GrantedRDGUsedCount (Counter32),
dot11GrantedRDGUnusedCount (Counter32),
dot11TransmittedFramesInGrantedRDGCount (Counter32),
dot11TransmittedOctetsInGrantedRDGCount (Counter64),
dot11DualCTSSuccessCount (Counter32),
dot11DualCTSFailureCount (Counter32),
dot11RTSLSIGSuccessCount (Counter32),
dot11RTSLSIGFailureCount (Counter32)
15 20 STA Counters from dot11CountersGroup3 (beamforming and STBC):
dot11BeamformingFrameCount (Counter32),
dot11STBCCTSSuccessCount (Counter32),
dot11STBCCTSFailureCount (Counter32),
dot11nonSTBCCTSSuccessCount (Counter32),
dot11nonSTBCCTSFailureCount (Counter32)
851
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-114—Group Identity for a STA Statistics report (continued)
Group Statistics Group
Identity Data field length Statistics Returned
Requested (octets)
16 28 dot11RSNAStats Group for the Interface on which the STA Statistics
request was received:
dot11RSNAStatsBIPMICErrors (Counter32)
dot11RSNAStatsCMACReplays (Counter32)
dot11RSNAStatsRobustMgmtCCMPReplays(Counter32)
dot11RSNAStatsTKIPICVErrors (Counter32)
dot11RSNAStatsTKIPReplays (Counter32)
dot11RSNAStatsCCMPDecryptErrors (Counter32)
dot11RSNAStatsCCMPReplays (Counter32)
17–255 Reserved
The format of the Measurement Report field for dot11Counters Group is shown in Figure 9-205.
dot11TransmittedF dot11Group dot11Failed dot11Received dot11Group
Transmitted ReceivedFrame
ragmentCount FrameCount Count FragmentCount Count
Octets: 4 4 4 4 4
dot11FCSError dot11Transmitted
Count FrameCount
Octets: 4 4
Figure 9-205—Measurement Report field format for dot11Counters Group
The format of the Measurement Report field for dot11MACStatistics is shown in Figure 9-206.
dot11RTS
dot11Retry dot11Multiple dot11Frame dot11RTS
Count RetryCount DuplicateCount Success FailureCount
Count
Octets: 4 4 4 4 4
dot11Ack
FailureCount
Octets: 4
Figure 9-206—Measurement Report field format for dot11MACStatistics Group
The format of the Measurement Report field for dot11QosCounters Group for UPx is shown in
Figure 9-207, where x is 0 – 7 and where the listed variables are obtained from the column of the QoS
Counters Table indexed by x + 1. For example, the variables for dot11QosCounters Group for UP2 are from
the third column of the dot11QosCountersTable, obtained from the dot11QosCountersEntry in which
dot11QosCountersIndex is equal to 3.
852
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11Qos
Transmitted dot11Qos dot11Qos dot11Qos dot11Qos
Multiple Frame
Fragment FailedCount RetryCount RetryCount DuplicateCount
Count
Octets: 4 4 4 4 4
dot11Qos
dot11Qos dot11Qos dot11Qos dot11Qos Transmitted
RTS RTS Ack Received
SuccessCount FailureCount FailureCount FragmentCount Frame
Count
Octets: 4 4 4 4 4
dot11Qos dot11Qos dot11Qos
Discarded MPDUs Retries
FrameCount ReceivedCount ReceivedCount
Octets: 4 4 4
Figure 9-207—Measurement Report field format for dot11QosCounters Group for UPx
The format of the Measurement Report field for dot11BSSAverageAccessDelay Group is shown in
Figure 9-208. Non-QoS APs set dot11STAStatisticsAverageAccessDelayBestEffort, dot11STAStatistics-
AverageAccessDelayBackGround, dot11STAStatisticsAverageAccessDelayVideo, and dot11STA-
StatisticsAverageAccessDelayVoice to 255 (not available).
dot11STA
dot11STA dot11STA dot11STA dot11STA
StatisticsAP Statistics Statistics Statistics Statistics
AverageAccess
AverageAccess AverageAccess Delay AverageAccess AverageAccess
Delay DelayBestEffort DelayVideo DelayVoice
BackGround
Octets: 1 1 1 1 1
dot11STA dot11STA
Statistics
Statistics Channel
StationCount
Utilization
Octets: 2 1
Figure 9-208—Measurement Report field format for dot11BSSAverageAccessDelay Group
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-115.
853
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-115—Optional subelement IDs for STA Statistics report
Subelement ID Name Extensible
0 Reserved
1 Reporting Reason
2–220 Reserved
221 Vendor Specific
222–255 Reserved
The format of the Measurement Report field for RSNA Counters Group is shown in Figure 9-209.
dot11RSNAStats
dot11RSNAStats dot11RSNAStatsCM RobustMgmt dot11RSNAStats
CMACICVErrors ACReplays TKIPICVErrors
CCMPReplays
Octets: 4 4 4 4
dot11RSNAStats dot11RSNAStats dot11RSNAStats
TKIPReplays CCMPDecryptErrors CCMPReplays
Octets 4 4 4
Figure 9-209—Measurement Report field format for RSNA Counters Group
The Reporting Reason subelement indicates the reason why the measuring STA sent the STA Statistics
report. It is present if Statistics Group Name is from STA Counters, QoS STA Counters, or RSNA Counters
(see 11.11.9.5).
The Data field of the Reporting Reason subelement for STA Statistics Group Identities 0 or 1 (STA Count-
ers) is shown in Figure 9-210.
B0 B1 B2 B3
dot11FCS dot11Multiple dot11Frame
dot11Failed
Error Retry Duplicate
Bits 1 1 1 1
B4 B5 B6 B7
dot11RTS dot11Ack
dot11Retry Reserved
Failure Failure
Bits 1 1 1 1
Figure 9-210—Data field of the Reporting Reason subelement for STA Counters
The Data field of the Reporting Reason subelement for STA Statistics Group Identity 2 to 9 (QoS STA
Counters) is shown in Figure 9-211.
854
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3
dot11QoS dot11QoS dot11QoSMultiple dot11QoSFrame
Failed Retry Retry Duplicate
Bits 1 1 1 1
B4 B5 B6 B7
dot11QoSRTS dot11QoSAck dot11QoS
Reserved
Failure Failure Discarded
Bits 1 1 1 1
Figure 9-211—Data field of the Reporting Reason subelement for QoS STA Counters
The Data field of the Reporting Reason subelement for STA Statistics Group Identity 16 (RSNA Counters)
is shown in Figure 9-212.
B0 B1 B2 B3
dot11RSNAStats
dot11RSNAStats dot11RSNA dot11RSNAStats
CMACICVErrors StatsCMACReplays RobustMgmt TKIPICVErrors
CCMPReplays
Bits: 1 1 1 1
B4 B5 B6 B7
dot11RSNAStats dot11RSNA dot11RSNAStats Reserved
TKIPReplays StatsTKIPReplays CCMPReplays
Bits: 1 1 1 1
Figure 9-212—Data field of the Reporting Reason subelement for RSNA Counters
In a nontriggered STA Statistics report, all subfields of the Data field of the Reporting Reason subelement
are set to 0.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.22.10 LCI report (Location configuration information report)
An LCI report for a known LCI includes latitude, longitude, altitude, and related information. An unknown
LCI is indicated by the Length field of the LCI subelement being set to 0 and there being no following
subelements. The LCI report field format is shown in Figure 9-213.
LCI Subelement Optional Sublements
Octets: 2 or 18 variable
Figure 9-213—Format of Location Configuration Information Report
The subelements in the LCI report are defined in Table 9-116.
855
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-116—Subelement IDs for LCI Report
Subelement ID Name Extensible
0 LCI
1 Azimuth Report Yes
2 Originator Requesting STA MAC Address
3 Target MAC Address
4 Z Subelements
5 Relative Location Error Yes
6 Usage Rules/Policy Yes
7 Co-Located BSSID List Yes
8–220 Reserved
221 Vendor Specific
222–255 Reserved
The LCI Subelement field contains an LCI subelement. The LCI subelement is formatted as shown in
Figure 9-214.
Subelement ID Length LCI field
(optional)
Octets: 1 1 0 or 16
Figure 9-214—LCI subelement format
The Subelement ID field is equal to the value for LCI in Table 9-116.
The Length field is defined in 9.4.3.
The LCI field is formatted as shown in Figure 9-215.
B0 B5 B6 B39 B40 B45 B46 B79 B80 B83 B84 B89
Latitude Longitude Altitude Altitude
Uncertainty Latitude Uncertainty Longitude Type Uncertainty
Bits: 6 34 6 34 4 6
B90 B119 B120 B122 B123 B124 B125 B126 B127
RegLoc Dependent
Altitude Datum RegLoc DSE Version
Agreement STA
Bits: 30 3 1 1 1 2
Figure 9-215—LCI field format
856
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The definitions of fields within the LCI field are as specified in Section 2.2 of IETF RFC 6225 (July 2011)
or as defined herein. This structure and information fields are based on the LCI format described in IETF
RFC 6225.
NOTE—This example shows how to encode the coordinates of the Sydney Opera House using the encoding defined in
IETF RFC 6225. The building is a polygon with the following (latitude, longitude) coordinates:
(-33.856 625°, +151.215 906°)
(-33.856 299°, +151.215 343°)
(-33.856 326°, +151.214 731°)
(-33.857 533°, +151.214 495°)
(-33.857 720°, +151.214 613°)
(-33.857 369°, +151.215 375°)
Latitude ranges from -33.857 720° to -33.856 299°; longitude ranges from +151.214 495° to +151.215 906°.
For this example, the point that is encoded is chosen by finding the middle of each range, that is (-33.857 009 5°,
+151.215 200 5°), which is encoded as (1110111100010010010011011000001101,
0100101110011011100010111011000011) (2s complement, 9 bits before binary point, 25 after, MSB first).
These values can be derived as 234 – Round (33.857 009 5 × 225) and Round (151.215 200 5 × 225), respectively.
The latitude uncertainty (LatUnc) is given by inserting the difference between the center value and the outer value into
the formula from Section 2.3.2 of IETF RFC 6225. This gives:
LatUnc = 8 – log2(– 33.8570095 – – 33.857720 ) . The result is 18, which is encoded as 010010.
Similarly, longitude uncertainty (LongUnc) is given by the formula:
LongUnc = 8 – log2(151.2152005 – 151.214495) . The result is also 18, which is encoded as 010010.
The top of the building is 67.4 meters above sea level, and a starting altitude of 0 meters above sea level is assumed. At
the GPS coordinates of the Sydney Opera House, the sea level is approximately 22.5 m below the WGS84 ellipsoid.
Therefore, the lowest altitude of the building is –22.5 m, while the highest altitude is (67.4 – 22.5)=44.9 m from the
WGS84 ellipsoid. The middle of the range is (44.9 – 22.5)/2=11.2 m, which is encoded as
000000000000000000101100110011 (22 bits before binary point, 8 after, MSB first).
Altitude uncertainty is given by the height of the building. Since the building is 67.4 m above sea level and basement is
assumed to be at sea level, the uncertainty to be encoded is half of 67.4 m.
Altitude uncertainty (AltUnc) uses the formula from Section 2.4.5 from IETF RFC 6225:
AltUnc = 21 – log2(33.7 – 0) , the result is 15, which is encoded as 001111 (MSB first).
The Altitude Type field is set to 1, indicating that the altitude is specified in meters.
The Datum field is set to 1, indicating WGS84 coordinates.
The RegLoc Agreement field is set to 0 for this example.
The RegLoc DSE field is set to 0 for this example.
The Dependent STA field is set to 0 for this example.
The Version field is set to 1, as that is the only value currently defined in IETF RFC 6225.
The LCI configuration information report for this example is encoded as (where underscores are used as field or octet
delimiters):
010010_1110111100010010010011011000001101_010010_0100101110011011100010111011000011_0001
_001111_000000000000000000101100110011_001_0_0_0_01 (binary, MSB first per field)
010010_1011000001101100100100100011110111_010010_1100001101110100011101100111010010_1000
_111100_110011001101000000000000000000_100_0_0_0_10 (binary, LSB first per field)
01001010_11000001_10110010_01001000_11110111_01001011_00001101_11010001_11011001_1101001
0_10001111_00110011_00110100_00000000_00000000_10000010 (binary, rearranged into octets, with LSB
first per octet)
01010010_10000011_01001101_00010010_11101111_11010010_10110000_10001011_10011011_0100101
1_11110001_11001100_00101100_00000000_00000000_01000001 (binary, MSB first, per octet)
52 83 4d 12 ef d2 b0 8b 9b 4b f1 cc 2c 00 00 41 (order over the PHY SAP, see 8.3.5 and 9.2.2)
857
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The RegLoc Agreement field is set to 1 to report that the STA is operating within a national policy area or an
international agreement area near a national border (see 11.12.3); otherwise, it is 0.
The RegLoc DSE field is set to 1 to report that the enabling STA is enabling the operation of STAs with
DSE; otherwise, it is 0.
The Dependent STA field is set to 1 to report that the STA is operating with the enablement of the enabling
STA whose LCI is being reported; otherwise, it is 0.
The Version field is a 2-bit field defined in IETF RFC 6225, and the use is described in IETF RFC 6225.
The Optional Subelements field contains zero or more subelements with subelement ID greater than or equal
to 1 as listed in Table 9-116. The subelement format and ordering of subelements are defined in 9.4.3.
The Azimuth Report subelement is used to report an azimuth. The Azimuth Report subelement is as shown
in Figure 9-216.
Subelement ID Length Azimuth Report
Octets: 1 1 2
Figure 9-216—Azimuth Report subelement format
The Subelement ID field is defined in Table 9-116.
The Length field is defined in 9.4.3.
The Azimuth Report field of an Azimuth Report subelement contains three subfields as shown in
Figure 9-217.
B0 B1 B2 B3 B6 B7 B15
Reserved Azimuth Azimuth Resolution Azimuth
Type
Bits: 2 1 4 9
Figure 9-217—Azimuth Report subfield
Azimuth Type is set to 1 to report the Azimuth of the bearing of the requester with respect to the responder
and is set to 0 to report the Azimuth of front surface of the reporting STA.
Azimuth Resolution is 4 bits, indicating the number of valid most significant bits in the Azimuth.
Azimuth is a 9-bit unsigned integer value in degrees from true north, of the type defined by the Azimuth
Type field.
The Originator Requesting STA MAC Address subelement contains the MAC address of the STA that
requested the Location Information and it is present whenever the Location Subject field in the
corresponding LCI request was set to 2. The format of the Originator Requesting STA MAC Address
subelement is shown in Figure 9-169.
858
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Target MAC Address subelement contains the MAC address of the STA whose Location Information
was requested and it is present whenever the Location Subject field in the corresponding LCI request was set
to 2. The format of the Target MAC Address subelement is shown in Figure 9-170.
The Z subelement is used to report the floor and location of the STA with respect to the floor level. The
format of the Z subelement is shown in Figure 9-218.
Subelement ID Length STA Floor STA Height STA Height
Info Above Floor Above Floor
Uncertainty
Octets: 1 1 2 3 1
Figure 9-218—Z subelement format
The Subelement ID field is equal to the value for Z in Table 9-116.
The Length field is defined in 9.4.3.
The format of the STA Floor Info field is defined in Figure 9-218.
B0 B1 B2 B15
Expected to STA Floor
Move Number
Bits: 2 14
Figure 9-219—STA Floor Info field format
The Expected to Move field indicates whether the STA is expected to change its location. The value 1
indicates that the STA is expected to change its location. The value 0 indicates that the STA is not expected
to change its location. The value 2 indicates that the STA’s movement patterns are unknown. The value 3 is
reserved.
NOTE—Examples of STAs that are expected to move include a) battery-powered STAs, b) STAs installed within trains/
vehicles, c) STAs installed for temporary events.
The STA Floor Number field indicates the floor number of the STA. A higher value indicates a higher floor,
and the integer approximates the floor number labels used at the venue (e.g., in stairwells and elevators, if
present). The field is encoded as a 2s complement integer with units of 1/16-th of a floor. The value –8 192
indicates an unknown floor number. The value 8 191 indicates the STA’s floor is 8 191/16 floors or more.
The value –8 191 indicates the STA’s floor is –8 191/16 floors or less.
NOTE—For example, a building with floors labeled as Basement 1, Ground, Mezzanine, 1, and 2 might have the floors
identified by STA Floor Number values equal -16, 0, 8, 16 and 32 respectively.
The STA Height Above Floor field indicates the height of the STA above the floor. The field is coded as a 2s
complement integer with units of 1/4096 m. The value –8 388 608 indicates an unknown STA height above
floor. The value –8 388 607 indicates the height of the STA above the floor is –8 388 607/4096 m or less.
The value 8 388 607 indicates the height of the STA above the floor is 8 388 607/4096 m or more.
A STA Height Above Floor Uncertainty value of 0 indicates an unknown STA height above floor
uncertainty. Values 25 or higher are reserved. A value from 1 to 24 indicates that the actual STA height
above floor, a, is bounded according to:
11 – u 11 – u
h–2 a h+2
859
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
h is the value in units of 1/4096 m of the STA Height Above Floor field
u is the value of the STA Height Above Floor Uncertainty field
If the STA Height Above Floor field indicates an unknown STA height above floor, the STA Height Above
Floor Uncertainty field is set to 0.
The Relative Location Error subelement is used to report the location error of STAs with respect to a
reference STA (rather than with respect to an absolute geographic location). The format of the Relative
Location Error subelement is defined in Figure 9-220.
Subelement ID Length Reference STA Relative Location
Error
Octets: 1 1 6 1
Figure 9-220—Relative Location Error subelement format
The Subelement ID field is equal to the value for Relative Location Error in Table 9-116.
The Length field is defined in 9.4.3.
The Reference STA field contains the MAC address of the reference STA.
The format of the Relative Location Error field is defined in Figure 9-221.
B0 B3 B4 B7
Power of Two Power of Two
Horizontal Error Vertical Error
Bits: 4 4
Figure 9-221—Relative Location Error field format
The Power Of Two Horizontal Error field contains an upper bound on the error between the horizontal
location of the Reference STA and the Latitude and Longitude fields in the LCI subelement. The Power Of
p–8
Two Horizontal Error field indicates a relative horizontal error of 2 m, where p is the value of the Power
of Two Horizontal Error field in the range 0 to 13. The value 14 indicates a relative horizontal error of
greater than 32 m. The value 15 indicates an unknown relative horizontal error.
The Power Of Two Vertical Error field contains an upper bound on the error between the vertical location of
the Reference STA and the Altitude field in the LCI subelement. The Power Of Two Vertical Error field
p–8
indicates a relative vertical error of 2 m, where p is the value of the Power Of Two Vertical Error field
in the range 0 to 13. The value 14 indicates a relative vertical error of greater than 32 m. The value 15
indicates an unknown relative vertical error.
The Usage Rules/Policy subelement is used to report the usage rules of the reporting STA and whether
additional STA or neighboring STA location information is available if the additional information can be
transferred more securely. The format of the Usage Rules/Policy subelement is defined in Figure 9-222.
860
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Subelement ID Length Usage Rules/ Retention
Policy Parame- Expires Rela-
ters tive (optional)
Octets: 1 1 1 0 or 2
Figure 9-222—Usage Rules/Policy subelement format
The Subelement ID field is equal to the value for Usage Rules/Policy in Table 9-116.
The Length field is defined in 9.4.3.
The Usage Rules/Policy Parameters field is defined in Figure 9-223.B1
B0 B1 B2 B3 B7
Retransmission Retention Expires STA Location reserved
Allowed Relative Present Policy
Bits: 1 1 1 5
Figure 9-223—Usage Rules/Policy Parameters field format
The Retransmission Allowed field definition is the same as the definition for the retransmission-allowed
element in IETF RFC 4119, except that the “no” and “yes” text encoding specified in IETF RFC 4119 is
replaced by 0 and 1 respectively.
The Retention Expires Relative Present field indicates whether Retention Expires Relative field is present.
The value 1 indicates that the Retention Expires Relative field is present; otherwise the Retention Expires
Relative field is not present. If the Retention Expires Relative field is not present, it indicates that the
retention duration of the LCI report field is unbounded.
The STA Location Policy field indicates whether additional STA or neighboring STA location information
is available if the additional information can be transferred more securely. The security of the transfer is
(from lowest to highest): unassociated, associated without RSNA established, associated with RSNA
established but without management frame protection negotiated, and associated with both RSNA
established and management frame protection negotiated. The additional information might be one or more
of: 1) the STA’s location with reduced uncertainty and 2) the location of additional neighbor APs, if the
STA Location Policy field is carried within a Neighbor Report Response frame. A value of 1 indicates
additional STA or neighboring STA location information is available. A value of 0 indicates no additional
STA or neighboring STA location information is available.
The definition of the Retention Expires Relative field is the same as the definition for the retention-expires
element in IETF RFC 4119, except that the absolute time text encoding specified in IETF RFC 4119 is
replaced by a relative binary encoding: the Retention Expires Relative field is encoded as a number of hours
in the future relative to the time of transmission of the Usage Rules/Policy subelement.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
The Co-Located BSSID List subelement is used to report the list of BSSIDs of the BSSs which share the
same antenna connector with the reporting STA.
The format of the Co-Located BSSID List subelement is shown in Figure 9-224
861
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Subelement MaxBSSID BSSID #1 BSSID #n
ID Length Indicator (optional) ••• (optional)
Octets: 1 1 1 6 6
Figure 9-224—Co-Located BSSID List subelement format
The Subelement ID field is equal to the value for Co-Located BSSID list in Table 9-116.
The Length field is defined in 9.4.3.
The MaxBSSID Indicator field is as defined in 9.4.2.26. When set to a nonzero value, it indicates the
maximum possible number of BSSs, including the reference BSS, which share the same antenna connector
and have the same 48-(MaxBSSID indicator field) MSBs of the BSSIDs. When the BSSIDs of the co-
located BSSs are configured at the reporting STA but not represented by the MaxMBSSID Indicator field,
the BSSID fields are present in the Co-located BSSID List subelement to provide an explicit list of such
BSSID values.
When the MaxBSSID Indicator field is equal to zero, the BSSID fields contain an explicit list of the BSSID
values of the BSSs which share the same antenna connector with the reporting STA.
NOTE—For example, if there are 4 BSSs which share the same antenna connector and their BSSIDs end with 16, 24, 30
and 31, and the range of MAC addresses ending with 16-31 inclusive are not assigned to other BSSs using a different
antenna connector, then this list of 4 BSSIDs can be indicated with a value of 5 in the MaxBSSID Indicator field.
Otherwise, the MaxBSSID Indicator field is set to zero and the BSSIDs are listed separately.
9.4.2.22.11 Transmit Stream/Category Measurement report
The Transmit Stream/Category Measurement applies to TIDs for Traffic Streams associated with TSPECs
and also to TIDs for Traffic Categories for QoS traffic without TSPECs. The format of the Measurement
Report field corresponding to a Transmit Stream/Category Measurement report is shown in Figure 9-225.
Actual
Measurement Measurement Peer STA Traffic Reporting Transmitted
Duration Address Identifier Reason MSDU Count
Start Time
Octets: 8 2 6 1 1 4
MSDU MSDU Failed MSDU QoS Average Average
Discarded Multiple CF-Polls Transmit
Count Count Retry Count Lost Count Queue Delay Delay
Octets: 4 4 4 4 4 4
Bin 0 Optional
Bin 0 Bin 1 Bin 2 Bin 3 Bin 4 Bin 5
Range Subelements
Octets: 1 4 4 4 4 4 4 variable
Figure 9-225—Measurement Report field format for Transmit Stream/
Category Measurement report
Actual Measurement Start Time is set to the TSF at the time at which the measurement started, or for a
triggered Transmit Stream/Category Measurement report, the TSF value at the reporting QoS STA when the
trigger condition was met.
862
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Measurement Duration is set to the duration over which the Transmit Stream/Category Measurement report
was measured, in units of TUs. In a triggered Transmit Stream/Category Measurement report, metrics are
reported over a number of transmitted MSDUs rather than a duration; hence Measurement Duration is set to
0; see 11.11.9.8.
The Peer STA Address contains a MAC address indicating the RA for the measured frames.
The Traffic Identifier field contains the TID subfield as shown in Figure 9-172. The TID subfield indicates
the TC or TS for which traffic was measured.
The Reporting Reason field is a bit field indicating the reason that the measuring QoS STA sent the transmit
stream/category measurement report. The Reporting Reason field is shown in Figure 9-226.
B0 B1 B2 B3 B7
Average Consecutive Delay Trigger Reserved
Trigger Trigger
Bits: 1 1 1 5
Figure 9-226—Reporting Reason field
— The Average Trigger bit set to 1 indicates that the Transmit Stream/Category Measurement report
was generated as a triggered report due to the Average Error trigger.
— The Consecutive Trigger bit set to 1 indicates that the Transmit Stream/Category Measurement
report was generated as a triggered report due to the Consecutive Error trigger.
— The Delay Trigger bit set to 1 indicates that the Transmit Stream/Category Measurement report was
generated as a triggered report due to the delay exceeding the Delay Threshold.
When a Transmit Stream/Category Measurement report is sent as a direct response to a Transmit Stream/
Category Measurement request and not as a triggered Transmit Stream/Category Measurement report, all bit
fields in the Reporting Reason field are set to 0. This is termed a requested Transmit Stream/Category
Measurement report. Within a triggered Transmit Stream/Category Measurement report, more than one bit
field in the Reporting Reason field might be set to 1 if more than one trigger condition was met.
The Transmitted MSDU Count, MSDU Failed Count, MSDU Discarded Count, MSDU Multiple Retry
Count, QoS CF-Polls Lost Count, Average Queue Delay, Average Transmit Delay, and delay histogram
fields relate to transmissions to the QoS STA given in the Peer STA Address field. Metrics are reported over
the Measurement Duration, or for triggered transmit stream/category measurements, over the Measurement
Count. Any counter that increments to a value of 232–1 terminates the measurement.
The Transmitted MSDU Count field contains the number of MSDUs for the TC or the TS specified by the
TID that were successfully transmitted.
The MSDU Discarded Count field contains the number of MSDUs for the TC or the TS specified by the TID
that were discarded due either to the number of transmit attempts exceeding dot11ShortRetryLimit or
dot11LongRetryLimit (as appropriate), or due to the MSDU lifetime having been reached.
The MSDU Failed Count field contains the number of MSDUs for the TC or the TS specified by the TID
that were discarded due to the number of transmit attempts exceeding dot11ShortRetryLimit or
dot11LongRetryLimit (as appropriate).
The MSDU Multiple Retry Count field contains the number of MSDUs for the TC or the TS specified by the
TID that were successfully transmitted after more than one retransmission attempt.
863
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The QoS CF-Polls Lost Count field contains the number of QoS (+)CF-Poll frames that were transmitted
where there was no response from the QoS STA. QoS CF-Polls Lost Count are returned only if the reporting
QoS STA is contained within an AP and the TID is for a TS. This field is set to 0 when QoS CF-Polls Lost
Count is not returned.
Average Queue Delay is the average queuing delay of the frames (MSDUs) that are passed to the MAC for
the indicated peer STA address and the indicated traffic identifier. Queue Delay is expressed in TUs and is
measured from the time the MSDU is passed to the MAC until the point at which the first or only fragment
begins transmission.
Average Transmit Delay is the average delay of the frames (MSDUs) that are successfully transmitted for
the indicated Peer STA Address and TID. Average Transmit Delay is measured from the time the MSDU is
passed to the MAC until the point at which the entire MSDU has been successfully transmitted, including
receipt of the final Ack frame from the peer STA if the QoSAck service class is being used. Average
Transmit delay is expressed in units of TUs.
Bin 0 Range field value indicates the delay range of the first bin (Bin 0) of the Transmit Delay Histogram, in
units of TUs. It is also used to calculate the delay ranges of the other five bins making up the histogram. The
delay range for each bin increases in a binary exponential fashion as follows:
Bin 0 range: 0 Delay < B0 = Bin 0 Range field value
Bin i range: 2i–1 B0 Delay < 2i B0 , for 1 i 4
Bin 5 range: 16 B0 Delay
For example, if Bin 0 Range field value is 10 TUs, the bin delay ranges are as defined in Table 9-117.
Table 9-117—Delay definitions for a Transmit Stream/Category Measurement report
for a Bin 0 Range field value of 10 TU
Measured MSDU Transmit Delay
Bin
(TUs)
0 Delay < 10
1 10 Delay < 20
2 20 Delay < 40
3 40 Delay < 80
4 80 Delay < 160
5 160 Delay
To compute the value reported in Bin i (i.e., Bi for i = 0, 1...5 of the Transmit Delay Histogram), the STA
initializes all bin values to 0. For each MSDU successfully transmitted, the measured MSDU Transmit
Delay determines which bin is to be incremented. If the measured delay has a duration time t within Bin i,
then Bin i is increased by one. MSDU Transmit Delay is measured from the time the MSDU is passed to the
MAC until the point at which the entire MSDU has been successfully transmitted, including receipt of the
final Ack frame from the peer STA if the QoSAck service class is being used. The sum of the values in all
six bins is equal to the value reported in the Transmitted MSDU Count.
864
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-118.
Table 9-118—Optional subelement IDs for Transmit Stream/Category Measurement report
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.22.12 Multicast Diagnostics report
The format of the Measurement Report field of a Multicast Diagnostics report is shown in Figure 9-227.
Multicast Multicast
Measurement Measurement Group MAC
Time Duration Address Reporting Received MSDU
Reason Count
Octets: 8 2 6 1 4
First Sequence Last Sequence Multicast Rate Optional
Number Number Subelements
Octets: 2 2 2 variable
Figure 9-227—Measurement Report field format for a Multicast Diagnostics report
The Measurement Time field is the value of the STA TSF timer at the time the measurement started. In a
triggered Multicast Diagnostics report, this is the TSF value at the reporting STA when the trigger condition
was met. When the reason for sending the report is Performance Measurement and the Multicast Received
MSDU Count is nonzero, the Measurement Time field is the value of the STA TSF timer at the time of the
first group addressed MSDU received during the measurement interval.
The Measurement Duration field specifies the period over which the Multicast Diagnostic report was
generated, in units of TUs.
The Group MAC Address field contains the value from the Group MAC Address field from the Multicast
Diagnostics request to which the report relates.
The Multicast Reporting Reason field indicates the reason why the measuring STA sent the Multicast
Diagnostics report. The Multicast Reporting Reason field is shown in Figure 9-228.
865
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B7
Inactivity Measurement
Reserved
Timeout Trigger Result
Bits: 1 1 6
Figure 9-228—Multicast Reporting Reason field
The subfields of the Multicast Reporting Reason field are defined as follows:
— The Inactivity Timeout Trigger field set to 1 indicates that Multicast Diagnostics report was
generated as a triggered report due to the timeout of the multicast diagnostic timer.
— The Measurement Result field set to 1 indicates that the Multicast Diagnostic report contains the
result of completing a Multicast Diagnostic request that did not contain a Multicast Triggered
Reporting subelement.
All of the bits in the Multicast Reporting Reason field are independent.
The Multicast Received MSDU Count field contains the total number of group addressed MSDUs with the
indicated multicast MAC address that were received during the measurement duration. For a triggered
multicast diagnostics measurement, the Multicast Received MSDU Count field contains the total number of
group addressed MSDUs with the indicated multicast MAC address that were received between the
acceptance of the multicast diagnostics measurement request and the occurrence of the trigger condition.
When the LSB of the first octet of the Multicast MAC address field in the Multicast Diagnostics request is 1,
the twelve LSBs of the First Sequence Number field contain the sequence number of the first frame received
with destination address equal to the value in the Multicast MAC address field during the measurement
period. When the LSB of the first octet of the Multicast MAC address field in the Multicast Diagnostics
request is 0, the twelve LSBs of the First Sequence Number field contain the sequence number of the first
group addressed frame, that does not have the broadcast MAC address as its destination, received during the
measurement period. The four most significant bits of the First Sequence Number field are set to 0.
When the LSB of the first octet of the Multicast MAC address field in the Multicast Diagnostics request is 1,
the twelve LSBs of the Last Sequence Number field contain the sequence number of the last frame received
with destination address equal to the value in the Multicast MAC address field during the measurement
period. When the LSB of the first octet of the Multicast MAC address field in the Multicast Diagnostics
request is 0, the twelve LSBs of the Last Sequence Number field contain the sequence number of the last
group addressed frame, that does not have the broadcast MAC address as its destination, received during the
measurement period. The four most significant bits of the Last Sequence Number field are set to 0.
The First Sequence Number field and the Last Sequence Number field are set to 0 if the Multicast Received
MSDU Count is 0.
The Multicast Rate field specifies the highest data rate, in 0.5 Mb/s units, at which the STA has received a
group addressed frame during the measurement period. The Multicast Rate field is encoded with the MSB
set to 1 to indicate that the data rate is in the basic rate set, and set to 0 to indicate that the data rate is not in
the basic rate set. The remaining 15 bit value is multiplied by 0.5 Mb/s to indicate the data rate. The
Multicast Rate field is 0 by the STA to indicate that it has not received a group addressed frame during the
measurement period.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-119.
866
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-119—Optional subelement IDs for Multicast Diagnostics report
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
The summary of fields used in the STA Multicast Diagnostics report is shown in Table 9-120.
Table 9-120—Summary of fields used in the STA Multicast Diagnostics report
Field Measurement Result Triggered Report
Measurement Time Yes Yes
Measurement Duration Yes Yes
Group MAC Address Yes Yes
Multicast Reporting Reason Yes Yes
Multicast Received MSDU Count Yes Yes
First Sequence Number Yes Yes
Last Sequence Number Yes Yes
Multicast Rate Yes Yes
Optional Subelements Optional Optional
The use of Multicast Diagnostics report is defined in 11.11.19.
9.4.2.22.13 Location Civic report
The Location Civic report includes the location information defined in civic format for the location subject
provided in the Location Civic request, as shown in Figure 9-229.
Civic Location Location Civic Optional
Type Subelement Subelements
Octets: 1 variable variable
Figure 9-229—Location Civic report field format
The Civic Location Type field contains the format of location information in the Civic Location field, as
indicated in Table 9-100.
867
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The subelement IDs of the Location Civic report are defined in Table 9-121.
Table 9-121—Subelement IDs for Location Civic report
Subelement ID Name Extensible
0 Location Civic
1 Originator Requesting STA MAC Address
2 Target MAC Address
3 Location Reference
4 Location Shape
5 Map Image
6 Reserved
7 Co-Located BSSID List Yes
8–220 Reserved
221 Vendor Specific
222–255 Reserved
The Location Civic Subelement field contains a Location Civic subelement. The Location Civic subelement
of the Location Civic report (see Figure 9-229) is formatted according to Figure 9-230.
Subelement ID Length Location Civic
Octets: 1 1 variable
Figure 9-230—Location Civic subelement format
The Subelement ID is equal to Location Civic as defined in Table 9-121.
The Location Civic field contains the location information in the format as indicated in the Civic Location
Type field. When the Civic Location Type field is IETF RFC 4776:
— Location Civic field is formatted according to IETF RFC 4776 starting at the country code field (i.e.,
excluding the GEOCONF_CIVIC/ OPTION_GEOCONF_CIVIC, N/option-len and what fields)
— An unknown civic location is indicated by a subelement Length of 0 and a zero-length Location
Civic field
— The Civic Location field follows the little-endian octet ordering
When the Civic Location Type field is IETF RFC 4776, the Optional Subelements field optionally includes
the Location Reference, Location Shape, Map Image, and Vendor Specific subelements as defined in
Table 9-121.
When the Civic Location Type field value is Vendor Specific, a Vendor Specific subelement is included in
the Optional Subelements field that identifies the Organization Identifier corresponding to the Civic
Location Type field.
868
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Optional Subelements field contains zero or more subelements with subelement ID greater than or equal
to 1 as listed in Table 9-121. The subelement format and ordering of subelements are defined in 9.4.3.
The Originator Requesting STA MAC Address subelement contains the MAC address of the STA that
requested the Location Information and it is present whenever the Location Subject field in the
corresponding Location Civic request was set to 2. The format of the Originator Requesting STA MAC
Address subelement is shown in Figure 9-169.
The Target MAC Address subelement contains the MAC address of the STA whose Location Information
was requested and it is present whenever the Location Subject field in the corresponding Location Civic
request was set to 2. The format of the Target MAC Address subelement is shown in Figure 9-170.
The format of the Location Reference subelement is shown in Figure 9-231.
Subelement ID Length Location
Reference
Octets: 1 1 variable
Figure 9-231—Location Reference subelement format
The Location Reference is an ASCII string that defines a position on a floor from which the relative location
contained in the Location Shape subelement is offset. A Location Reference value of 0 length indicates that
the position of the Location Shape is top north west corner (i.e., 0,0) of the floor plan on which the Location
Shape is defined.
The format of the Location Shape subelement is shown in Figure 9-232.
Location Shape Location Shape
Subelement ID Length
ID Value
Octets: 1 1 1 variable
Figure 9-232—Location Shape subelement format
The Location Shape subelement defines the position in meters, including uncertainty, of the entity being
located. A Shape is specified with respect to either a 2-Dimensional or 3-Dimensional Coordinate Reference
System where each point in the shape defines the direction from the Location Reference starting point. A
positive X-axis value corresponds to an easterly direction relative to the Location Reference; a negative X-
axis value corresponds to a westerly direction relative to the Location Reference; a positive Y-axis value
corresponds to a northerly direction relative to the Location Reference; a negative Y-axis value corresponds
to a southerly direction relative to the Location Reference and the Z-axis value corresponds to the altitude
above the horizontal plane at the Location Reference.
The Location Shape ID field contains a one-octet identifier that defines the shape contained in the
subelement and is one of the values defined in Table 9-122.
The Location Shape Value field contains the location shape value for each corresponding Location Shape
ID. The formats of Location Shape Values are described in the following text.
All shape field value units that are 4-octet single precision floating point values are in meters and are
represented by binary32 floating point values as defined in IEEE Std 754-2008, with the least significant bit
of the fraction occurring in bit 0 of the field.
869
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-122—Location Shape IDs
Location Shape ID Name
0 Reserved
1 2-Dimension Point
2 3-Dimension Point
3 Circle
4 Sphere
5 Polygon
6 Prism
7 Ellipse
8 Ellipsoid
9 Arcband
10–255 Reserved
The format of the 2-Dimension Point Location Shape Value is defined in Figure 9-233.
X-coordinate Y-coordinate
Octets: 4 4
Figure 9-233—2-Dimension Point Location Shape Value format
The X-coordinate field contains a 4-octet single precision floating point value.
The Y-coordinate field contains a 4-octet single precision floating point value.
The format of the 3-Dimension Point Location Shape Value is defined in Figure 9-234.
X-coordinate Y-coordinate Z-coordinate
Octets: 4 4 4
Figure 9-234—3-Dimension Point Location Shape Value format
The X-coordinate field contains a 4-octet single precision floating point value.
The Y-coordinate field contains a 4-octet single precision floating point value.
The Z-coordinate field contains a 4-octet single precision floating point value.
The format of the Circle Location Shape Value is defined in Figure 9-235.
X-coordinate Y-coordinate Radius
Octets: 4 4 4
Figure 9-235—Circle Location Shape Value format
870
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The X-coordinate field contains a 4-octet single precision floating point value.
The Y-coordinate field contains a 4-octet single precision floating point value.
The Radius field contains a 4-octet single precision floating point value.
The format of the Sphere Location Shape Value is defined in Figure 9-236.
X-coordinate Y-coordinate Z-coordinate Radius
Octets: 4 4 4 4
Figure 9-236—Sphere Location Shape Value format
The X-coordinate field contains a 4-octet single precision floating point value.
The Y-coordinate field contains a 4-octet single precision floating point value.
The Z-coordinate field contains a 4-octet single precision floating point value.
The Radius field contains a 4-octet single precision floating point value.
The format of the Polygon Location Shape Value is defined in Figure 9-237.
List of 2-Dimension
Number of Points Points
Octets: 1 variable
Figure 9-237—Polygon Location Shape Value format
The Number of Points field is a 1 octet unsigned integer that specifies the number of points defined in the
polygon. The value 0 is reserved.
The List of 2-Dimension Points is a sequence of 2D Point field values that define the closed polygon.
The format of the Prism Location Shape Value is defined in Figure 9-238.
List of 3-Dimension
Number of Points
Points
Octets: 1 variable
Figure 9-238—Prism Location Shape Value format
The Number of Points field is a 1 octet unsigned integer that specifies the number of points defined in the
prism. The value 0 is reserved.
The List of 3-Dimension Points is a sequence of 3-Dimension Point field values that define the closed prism.
The format of the Ellipse Location Shape Value is defined in Figure 9-239.
871
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
X-coordinate Y-coordinate Angle Semi-Major Axis Semi-Minor Axis
Octets: 4 4 2 4 4
Figure 9-239—Ellipse Location Shape Value format
The X-coordinate field contains a 4-octet single precision floating point value.
The Y-coordinate field contains a 4-octet single precision floating point value.
The Angle field contains a 2-octet unsigned integer between 0 and 359°.
The Semi-Major Axis field contains a 4-octet single precision floating point value.
The Semi-Minor Axis field contains a 4-octet single precision floating point value.
The format of the Ellipsoid Location Shape Value is defined in Figure 9-240.
X- Y- Z- Semi- Semi- Semi-
Angle Vertical
coordinate coordinate coordinate Major Axis Minor Axis Axis
Octets: 4 4 4 2 4 4 4
Figure 9-240—Ellipsoid Location Shape Value format
The X-coordinate field contains a 4-octet single precision floating point value.
The Y-coordinate field contains a 4-octet single precision floating point value.
The Z-coordinate field contains a 4-octet single precision floating point value.
The Angle field contains a 2-octet unsigned integer between 0 and 359°.
The Semi-Major Axis field contains a 4-octet single precision floating point value.
The Semi-Minor Axis field contains a 4-octet single precision floating point value.
The Semi-Vertical Axis field contains a 4-octet single precision floating point value.
The format of the Arcband Location Shape Value is defined in Figure 9-241.
X-coordinate Y-coordinate Inner Radius Outer Radius Start Angle Opening
Angle
Octets: 4 4 4 4 2 2
Figure 9-241—Arcband Location Shape Value format
The X-coordinate field contains a 4-octet single precision floating point value.
The Y-coordinate field contains a 4-octet single precision floating point value.
The Inner Radius field contains a 4-octet single precision floating point value.
872
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Outer Radius field contains a 4-octet single precision floating point value.
The Start Angle field contains a 2-octet unsigned integer between 0 and 359.
The Opening Angle field contains a 2-octet unsigned integer between 0 and 359.
The Map Image subelement contains a map reference that is used in combination with the
Location Reference and Location Shape subelements. The format of the Map Image subelement is shown in
Figure 9-242.
Subelement ID Length Map Type Map URL
Octets: 1 1 1 variable
Figure 9-242—Map Image subelement format
The Map Type field is a 1-octet unsigned integer that defines the type of map referred to by the Map URL
field, as defined in Table 9-123.
Table 9-123—Map Types
Map Type Value Name
0 URL Defined
1 Png
2 Gif
3 Jpeg
4 Svg
5 dxf
6 Dwg
7 Dwf
8 cad
9 Tiff
10 gml
11 Kml
12 Bmp
13 Pgm
14 ppm
15 Xbm
16 Xpm
17 ico
18–255 Reserved
The Map Type field value “URL Defined” indicates the Map URL field value has a file extension, defined
as a mime type and is self-descriptive.
873
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Map URL field is a variable-length field formatted in accordance with IETF RFC 3986 and provides the
location of a floor map.
The Co-Located BSSID List subelement is used to report the list of BSSIDs of the BSSs that share the same
antenna connector with the reporting STA. The Co-Located BSSID List subelement is described in
9.4.2.22.10.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
9.4.2.22.14 Location Identifier report
The Location Identifier report includes an indirect reference to the location information for the location
subject provided in the Location Identifier request, as shown in Figure 9-243.
Zero or more
Expiration TSF Public Identifier URI/ Optional
FQDN Subelement Subelements
Octets: 8 variable variable
Figure 9-243—Location Identifier report field format
The Expiration TSF field is the value of the TSF when the Public Identifier URI/FQDN subelement(s) that
indicate a location object are no longer valid. The Expiration TSF field set to 0 indicates the Public Identifier
URI/FQDN subelement(s) that indicate a location object do not expire.
The Public Identifier URI/FQDN Subelement field contains zero or more Public Identifier URI/FQDN
subelements.
The subelement IDs for the Location Identifier report are shown in Table 9-124.
Table 9-124—Subelement IDs for Location Identifier report
Subelement ID Name Extensible
0 Public Identifier URI/FQDN
1 Originator Requesting STA MAC Address
2 Target MAC Address
3–220 Reserved
221 Vendor Specific
222–255 Reserved
The Public Identifier URI/FQDN subelement of the Location Identifier report (see Figure 9-243) is
formatted according to Figure 9-244.
874
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Subelement ID Length URI/FQDN Public Identifier
Descriptor URI/FQDN
Octets: 1 1 1 variable
Figure 9-244—Public Identifier URI/FQDN subelement format
The Subelement ID is equal to Public Identifier URI/FQDN as defined in Table 9-124.
The URI/FQDN Descriptor field describes the Public Identifier URI/FQDN field. The URI/FQDN
Descriptor field is defined in Table 9-125.
Table 9-125—URI/FQDN Descriptor field values
Value Usage
0 Reserved
1 The uniform resource locator (URI) of the Hypertext
Transfer Protocol (HTTP) enabled location delivery (HELD)
location object [IETF RFC 5985]
2 Fully qualified domain name of D-SLP SUPL server
(excludes port number) [OMA OMA-TS-ULP-V2_0_1] (or
higher version)
3–255 Reserved
The Public Identifier URI/FQDN field contains a URI encoded using UTF-8 and formatted in accordance
with IETF RFC 3986 that points to a location object or an FQDN that identifies a location server.
A Public Identifier URI/FQDN field that points to a location object can be used to return the location value
for the requesting STA. The format of the location value returned when the URI is dereferenced is
dependent on the provider of the URI as indicated by the URI/FQDN Descriptor field. The Public Identifier
URI field confirms the validity of the location estimate to an external agent when a STA forwards a location
estimate to that agent. The protocol used to query the infrastructure for a location report based on the Public
Identifier URI field is beyond the scope of this standard.
A Public Identifier URI/FQDN field that points to a location server can be used to discover the location
server and establish communications with it. The protocol used with the location server is indicated by the
URI/FQDN Descriptor field.
The Optional Subelements field contains zero or more subelements with subelement ID greater than or equal
to 1 as listed in Table 9-124. The subelement format and ordering of subelements are defined in 9.4.3.
The Originator Requesting STA MAC Address subelement contains the MAC address of the STA that
requested the Location Information and it is present whenever the Location Subject field in the
corresponding Location Identifier request was set to 2. The format of the Originator Requesting STA MAC
Address subelement is shown in Figure 9-169.
The Target MAC Address subelement contains the MAC address of the STA whose Location Information
was requested and it is present whenever the Location Subject field in the corresponding Location Identifier
request was set to 2. The format of the Target MAC Address subelement is shown in Figure 9-170.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
875
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.22.15 Directional Channel Quality report
The format of the Measurement Report field of a Directional Channel Quality report is shown in
Figure 9-245.
Operating Channel Measurement Measurement
Class Number AID Reserved Method Start Time
Octets: 1 1 1 1 1 8
Measurement Number of Time Measurement for Measurement for Optional
…
Duration Blocks (N) Time Block 1 Time Block N Subelements
Octets: 2 1 1 1 Variable
Figure 9-245—Measurement report field format for Directional Channel Quality report
Operating Class field indicates the channel set for which the measurement report applies. Operating Class
and Channel Number together specify the channel frequency and spacing for which the measurement report
applies. Valid values of Operating Class are shown in Annex E.
Channel Number field indicates the channel number for which the measurement report applies. Channel
Number is defined within an Operating Class as shown in Annex E.
The AID field indicates the Target STA.
The Measurement Method field indicates the method used by the STA to carry out this measurement request
and the format of the Measurement for Time Block field(s). If this field is set to 0, it indicates that the
Measurement for Time Block fields are expressed in ANIPI. If this field is set to 1, it indicates that the
Measurement for Time Block fields are expressed in RSNI. Other values are reserved.
Measurement Start Time field is set to the value of the measuring STA’s TSF timer at the time the
measurement started.
The Measurement Duration field is set to the duration of the measurement, in units of TUs.
The Number of Time Blocks field indicates the number of time blocks within the measurement duration.
The ratio (Measurement Duration/Number of Time Blocks) provides the duration of an individual
measurement unit.
The Measurement for Time Block fields are set to the ANIPI or average RSNI value measured during each
(Measurement Duration/Number of Time Blocks) measurement units. The measurement units are set in the
report in increasing order of start times. ANIPI is set to the average noise plus interference power value
measured during the indicated Measurement Duration using the same units and accuracy as defined for
ANPI in 11.11.9.4. Average RSNI is set according to 9.4.2.41, where RCPI is defined in 9.4.2.38.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-126.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements can be included in the list of Optional Subelements.
876
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-126—Optional subelement IDs for Directional Channel Quality report
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
9.4.2.22.16 Directional Measurement report
The format of the Measurement Report field of a Directional Measurement report is shown in Figure 9-246.
Measurement
Operating Channel Measurement Duration Measurement Measurement Optional
Class Number Start Time Method Results Subelements
per Direction
Octets 1 1 8 2 1 Variable Variable
Figure 9-246—Measurement Report field format for Directional Measurement report
Operating Class field indicates the channel set for which the measurement report applies. Operating Class
and Channel Number together specify the channel frequency and spacing for which the measurement report
applies. Valid values of Operating Class are shown in Annex E.
Channel Number field indicates the channel number for which the measurement report applies. Channel
Number is defined within an Operating Class as shown in Annex E.
The Measurement Start Time field is set to the value of the measuring STA’s TSF timer at the time the
measurement started.
The Measurement Duration per Direction field is set to the duration of the measurement in each receiving
direction, in units of TUs.
The Measurement Method field indicates the method used by the STA to carry out the measurement request
and the format of values in the Measurement for Direction fields. If this field is set to 0, it indicates that the
values in the Measurement for Direction fields are expressed in ANIPI. If this field is set to 1, it indicates
that the values in the Measurement for Direction fields are expressed in RCPI. If this field is set to 2, it
indicates that the values in the Measurement for Direction fields are expressed in Channel Load. Other
values are reserved. ANIPI is defined in 9.4.2.22.15. RCPI is a logarithmic indication of the received
channel power of the corresponding Link Measurement Request frame, as defined in 9.4.2.38.
The format of the Measurement Results field is shown in Figure 9-247. The Measurement for Direction
fields are set to the format of values specified in the Measurement Method field.
Number of Measurement for Measurement for … Measurement for
Directions Direction 1 Direction 2 Direction N
Octets: 1 Variable Variable … Variable
Figure 9-247—Measurement Results field format
877
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-127.
Table 9-127—Optional subelement IDs for Directional Measurement report
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements can be included in the list of Optional Subelements.
9.4.2.22.17 Directional Statistics report
The format of the Measurement Report field of a Directional Statistics report is shown in Figure 9-248.
Measurement Directional
Operating Channel Measurement Measurement Measurement Optional
Class Number Start Time Duration per Method Statistics Results Subelements
Direction Bitmap
Octets 1 1 8 2 1 1 Variable Variable
Figure 9-248—Measurement Report field format for Directional Statistics report
Operating Class field indicates the channel set for which the measurement report applies. Operating Class
and Channel Number together specify the channel frequency and spacing for which the measurement report
applies. Valid values of Operating Class are shown in Annex E.
Channel Number field indicates the channel number for which the measurement report applies. Channel
Number is defined within an Operating Class as shown in Annex E.
The Measurement Start Time field is set to the value of the measuring STA’s TSF timer at the time the
measurement started.
The Measurement Duration per Direction field is set to the duration of the measurement in each receiving
direction, in units of TUs.
The Measurement Method field indicates the method used by the STA to carry out the measurement request
and the format of values in the Measurement Results field. If this field is set to 0, it indicates that the values
in the Measurement Results field are expressed in ANIPI. If this field is set to 1, it indicates that the values in
the Measurement Results field are expressed in RCPI. If this field is set to 2, it indicates that the values in the
Measurement Results field are expressed in Channel Load. Other values are reserved.
The Directional Statistics Bitmap field format is described in 9.4.2.21.18. When the Maximum field is set, it
indicates that the maximum measurement result among all directions is included in the Measurement Results
field. When the Minimum field is set, it indicates that the minimum measurement result among all directions
is included in the Measurement Results field. If the Average field is set, it indicates that the average
878
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
measurement result among all directions is included in the Measurement Results field. If the Variance field
is set, it indicates that the variance of measurement results among all directions is included in the
Measurement Results field. Other bits are reserved.
The Measurement Results field is set based on the values in the Measurement Method field and the
Directional Statistics Bitmap field. If two or more subfields in the Directional Statistics Bitmap are set to 1,
the corresponding measurement results are included in the Measurement Results field in the same sequence
as they appear in the Directional Statistics Bitmap field.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-128.
Table 9-128—Optional subelement IDs for Directional Statistics report
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements can be included in the list of Optional Subelements.
9.4.2.22.18 Fine Timing Measurement Range report
The format of the Measurement Report field corresponding to a Fine Timing Measurement Range report is
shown in Figure 9-249.
Range Entry Range Entry Error Entry Error Entry Optional Sub-
Count Count elements
Octets: 1 M x 15 1 N x 11 variable
Figure 9-249—Measurement Report field format for a Fine Timing Measurement Range
report
The Range Entry Count field indicates the number of Range Entry fields (i.e., M in Figure 9-249).
The Range Entry field indicates parameters relating to a successful range measurement with a single AP and
is formatted according to Figure 9-250.
Measurement BSSID Range Max Range Reserved
Start Time Error Exponent
Octets: 4 6 3 1 1
Figure 9-250—Range Entry field format
879
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Measurement Start Time field contains the least significant 4 octets of the TSF (synchronized with the
associated AP) at the time (± 32 µs) at which the initial Fine Timing Measurement frame was transmitted
where the timestamps of both the frame and response frame were successfully measured.
The BSSID field contains the BSSID of the AP whose range is being reported.
The Range field indicates the estimated range between the requested STA and the AP using the FTM
procedure, in units of 1/4096 m. A value of 224–1 indicates a range of (224–1)/4096 m or higher. See
11.11.9.11.
The Max Range Error Exponent field contains an upper bound for the error in the value specified in the
Range field. A value of zero indicates an unknown error. A nonzero value indicates a maximum range error
Max Range Error Exponent – 13
of 2 m. The Max Range Error Exponent field has a maximum value of 25. Values
in the range 26–255 are reserved. A value of 25 indicates a maximum range error of 4096 m or higher. For
example, a value of 14 in the Max Range Error Exponent field indicates that the value in the Range field has
a maximum error of ±2 m.
The Error Entry Count field indicates the number of Error Entry fields (i.e., N in Figure 9-249).
The Error Entry field indicates parameters relating to a failed range measurement with a single AP and is
formatted according to Figure 9-251.
Measurement BSSID Error Code
Start Time
Octets: 4 6 1
Figure 9-251—Error Entry field format
The Measurement Start Time field contains the least significant 4 octets of the TSF (synchronized with the
associated AP) at the time (± 32 µs) at which the FTM failure was first detected.
The BSSID field contains the BSSID of the AP whose range was attempted to be measured.
The Error Code field is defined in Table 9-129.
Table 9-129—Error Code field values
Error Code Meaning
0–1 Reserved
2 AP reported “Request incapable”
3 AP reported “Request failed. Do not send new request
for a specified period”
4–7 Reserved
8 Unable to successfully transmit to AP
9–255 Reserved
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
880
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Subelement ID field values for the defined subelements are shown in Table 9-130.
Table 9-130—Optional subelement IDs for Fine Timing Measurement Range report
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements can be included in the list of Optional Subelements.
9.4.2.23 Quiet element
The Quiet element defines an interval during which no transmission occurs in the current channel. This
interval might be used to assist in making channel measurements without interference from other STAs in
the BSS. The format of the Quiet element is shown in Figure 9-252.
Quiet Quiet Quiet Quiet
Element ID Length
Count Period Duration Offset
Octets: 1 1 1 1 2 2
Figure 9-252—Quiet element format
The Element ID and Length fields are defined in 9.4.2.1.
The Quiet Count field is set to the number of TBTTs until the beacon interval during which the next quiet
interval starts. A value of 1 indicates the quiet interval starts during the beacon interval starting at the next
TBTT. A value of 0 is reserved.
The Quiet Period field is set to the number of beacon intervals between the start of regularly scheduled quiet
intervals defined by this Quiet element. A value of 0 indicates that no periodic quiet interval is defined.
The Quiet Duration field is set to the duration of the quiet interval, expressed in TUs.
The Quiet Offset field is set to the offset of the start of the quiet interval from the TBTT specified by the
Quiet Count field, expressed in TUs. The value of the Quiet Offset field is less than one beacon interval.
The Quiet element is optionally present in Beacon frames, as described in 9.3.3.3, and Probe Response
frames, as described in 9.3.3.11. The use of Quiet elements is described in 11.9.3.
9.4.2.24 IBSS DFS element
The IBSS DFS element contains information for DFS operation in an IBSS. The format of the IBSS DFS
element is shown in Figure 9-253.
881
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Channel Map
Element ID Length DFS DFS Recovery (see
Owner Interval
Figure 9-254)
Octets: 1 1 6 1 2×n
Figure 9-253—IBSS DFS element format
The Element ID and Length fields are defined in 9.4.2.1.
The DFS Owner field is set to the individual IEEE MAC address of the STA that is the currently known DFS
Owner in the IBSS.
The DFS Recovery Interval field indicates the time interval that is used for DFS owner recovery, expressed
as an integer number of beacon intervals. The DFS Recovery Interval value is static throughout the lifetime
of the IBSS and is determined by the STA that starts the IBSS.
The Channel Map field shown in Figure 9-254 contains a Channel Number field and a Map field (see
9.4.2.22.2) for each channel supported by the STA transmitting the IBSS DFS element. Note that n in
Figure 9-253 is the number of channels supported by the STA.
Channel Map n tuples, one for each
Number supported channel
Octets: 1 1
Figure 9-254—Channel Map field format
The IBSS DFS element is optionally present in Beacon frames, as described in 9.3.3.3, and Probe Response
frames, as described in 9.3.3.11. The use of IBSS DFS elements is described in 11.9.8.3.
9.4.2.25 RSNE
9.4.2.25.1 General
The RSNE contains the information required to establish an RSNA. The format of the RSNE is defined in
Figure 9-255.
Group Data Pairwise Cipher Pairwise Cipher
Element ID Length Version Cipher Suite Suite Count Suite List
Octets: 1 1 2 0 or 4 0 or 2 0 or (4 × m)
AKM Suite AKM Suite RSN PMKID Group
PMKID List Management
Count List Capabilities Count Cipher Suite
Octets: 0 or 2 0 or (4 × n) 0 or 2 0 or 2 0 or (16 × s) 0 or 4
Figure 9-255—RSNE format
The Element ID and Length fields are defined in 9.4.2.1.
The size of the RSNE is limited by the size of an element, which is 255 octets. Therefore, the number of
pairwise cipher suites, AKM suites, and PMKIDs is limited.
882
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In Figure 9-255, m denotes the pairwise cipher suite count, n the AKM suite count, and s is the PMKID
count.
All fields use the bit convention from 9.2.2. The RSNE contains up to and including the Version field. All
fields after the Version field are optional. If any nonzero-length field is absent, then none of the subsequent
fields is included.
The Version field indicates the version number of the RSN protocol. Version 1 is defined in this standard.
Other values are reserved.
NOTE—The following represent sample elements:
802.1X authentication, CCMP-128 pairwise and group data cipher suites (WEP-40, WEP-104, and TKIP not
allowed):
30, // element id, 48 expressed as hexadecimal value
14, // length in octets, 20 expressed as hexadecimal value
01 00, // Version 1
00 0F AC 04, // CCMP-128 as group data cipher suite
01 00, // pairwise cipher suite count
00 0F AC 04, // CCMP-128 as pairwise cipher suite
01 00, // authentication count
00 0F AC 01 // IEEE 802.1X authentication
00 00 // No capabilities
802.1X authentication, CCMP-128 pairwise and group data cipher suites (WEP-40, WEP-104 and TKIP not
allowed), preauthentication supported:
30, // element id, 48 expressed as hexadecimal value
14, // length in octets, 20 expressed as hexadecimal value
01 00, // Version 1
00 0F AC 04, // CCMP-128 as group data cipher suite
01 00, // pairwise cipher suite count
00 0F AC 04, // CCMP-128 as pairwise cipher suite
01 00, // authentication count
00 0F AC 01 // IEEE 802.1X authentication
01 00 // Preauthentication capabilities
802.1X authentication, Use GTK for pairwise cipher suite, WEP-40 group data cipher suites, optional RSN
Capabilities field omitted:
30, // element id, 48 expressed as hexadecimal value
12, // length in octets, 18 expressed as hexadecimal value
01 00, // Version 1
00 0F AC 01, // WEP-40 as group data cipher suite
01 00, // pairwise cipher suite count
00 0F AC 00, // Use group cipher suite as pairwise cipher suite
01 00, // authentication count
00 0F AC 01 // IEEE 802.1X authentication
802.1X authentication, Use CCMP-128 for pairwise cipher suite, CCMP-128 group data cipher suites,
preauthentication and a PMKID:
30, // element id, 48 expressed as hexadecimal value
26 // length in octets, 38 expressed as hexadecimal value
01 00, // Version 1
00 0F AC 04, // CCMP-128 as group data cipher suite
01 00, // pairwise cipher suite count
00 0F AC 04, // CCMP-128 as pairwise cipher suite
01 00, // authentication count
00 0F AC 01 // IEEE 802.1X authentication
01 00 // Preauthentication capabilities
01 00 // PMKID Count
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 // PMKID
802.1X authentication, CCMP-128 pairwise and group data cipher suites (WEP-40, WEP-104, and TKIP are
not allowed), and management frame protection with AES-128-CMAC as the group management suite
selector.
30, // element id, 48 expressed as hexadecimal value
1A, // length in octets, 26 expressed as hexadecimal value
01 00, // Version 1
883
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
00 0F AC 04, // CCMP-128 as group data cipher suite
01 00, // pairwise cipher suite count
00 0F AC 04, // CCMP-128 as pairwise cipher suite
01 00, // authentication count
00 0F AC 01 // IEEE 802.1X authentication
80 00 // management frame protection is enabled but not required
00 00 // No PMKIDs
00 0F AC 06, // BIP-CMAC-128 as the broadcast/multicast management cipher suite
9.4.2.25.2 Cipher suites
The Group Data Cipher Suite field contains the cipher suite selector used by the BSS to protect group
addressed frames.
The Pairwise Cipher Suite Count field indicates the number of pairwise cipher suite selectors that are
contained in the Pairwise Cipher Suite List field. The value 0 is reserved.
The Pairwise Cipher Suite List field contains a series of cipher suite selectors that indicate the pairwise
cipher suites.
The Group Management Cipher Suite field contains the cipher suite selector used by the BSS to protect
group addressed robust Management frames.
When management frame protection is negotiated, the negotiated pairwise cipher suite is used to protect
individually addressed robust Management frames, and the group management cipher suite is used to protect
group addressed robust Management frames. Use of AES-128-CMAC is not valid as a data cipher suite.
A suite selector has the format shown in Figure 9-256.
OUI Suite Type
Octets: 3 1
Figure 9-256—Suite selector format
The OUI field contains an OUI or CID. The order of the OUI (organizationally unique identifier) field is
described in 9.2.2.
Table 9-131 provides the cipher suite selectors defined by this standard.
Table 9-131—Cipher suite selectors
OUI Suite type Meaning
00-0F-AC 0 Use group cipher suite
00-0F-AC 1 WEP-40
00-0F-AC 2 TKIP
00-0F-AC 3 Reserved
00-0F-AC 4 CCMP-128
00-0F-AC 5 WEP-104
00-0F-AC 6 BIP-CMAC-128
884
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-131—Cipher suite selectors (continued)
OUI Suite type Meaning
00-0F-AC 7 Group addressed traffic not allowed
00-0F-AC 8 GCMP-128
00-0F-AC 9 GCMP-256
00-0F-AC 10 CCMP-256
00-0F-AC 11 BIP-GMAC-128
00-0F-AC 12 BIP-GMAC-256
00-0F-AC 13 BIP-CMAC-256
00-0F-AC 14–255 Reserved
Other OUI or CID Any Vendor-specific
In non-DMG RSNA, the cipher suite selector 00-0F-AC:4 (CCMP-128) is the default group cipher suite for
Data frames when the Group Data Cipher Suite field is not included in the RSNE.
In non-DMG RSNA, the cipher suite selector 00-0F-AC:4 (CCMP-128) is the default pairwise cipher suite
when the Pairwise Cipher Suite List field is not included in the RSNE.
In DMG RSNA, the cipher suite selector 00-0F-AC:8 (GCMP-128) is the default group cipher suite for Data
frames when the Group Data Cipher Suite field is not included in the RSNE.
In DMG RSNA, the cipher suite selector 00-0F-AC:8 (GCMP-128) is the default pairwise cipher suite when
the Pairwise Cipher Suite List field is not included in the RSNE.
In an RSNA with management frame protection enabled, the cipher suite selector 00-0F-AC:6 (BIP-CMAC-
128) is the default group cipher suite for Management frames when the Group Management Cipher Suite
field is not included in the RSNE.
The cipher suite selectors 00-0F-AC:1 (WEP-40) and 00-0F-AC:5 (WEP-104) are only valid as a group
cipher suite in a transition security network (TSN) to allow pre-RSNA STAs to join an IBSS or to associate
with an infrastructure BSS.
Use of any group cipher suite other than TKIP, WEP-104, or WEP-40 with TKIP as the pairwise cipher suite
is not supported.
The cipher suite selector 00-0F-AC:0 (Use group cipher suite) is valid only as the pairwise cipher suite. An
AP specifies the selector 00-0F-AC:0 (Use group cipher suite) for a pairwise cipher suite if it does not
support any pairwise cipher suites. If an AP specifies 00-0F-AC:0 (Use group cipher suite) as the pairwise
cipher selection, this is the only pairwise cipher selection the AP advertises.
If any cipher suite other than TKIP, WEP-104, or WEP-40 is enabled, then the AP supports pairwise keys,
and thus the suite selector 00-0F-AC:0 (Use group cipher suite) is not a valid option.
Table 9-132 indicates the circumstances under which each cipher suite is used.
885
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-132—Cipher suite usage
Cipher suite selector GTK PTK IGTK
Use group cipher suite No Yes No
WEP-40 Yes No No
WEP-104 Yes No No
TKIP Yes Yes No
CCMP-128 Yes Yes No
BIP-CMAC-128 No No Yes
GCMP-128 Yes Yes No
GCMP-256 Yes Yes No
CCMP-256 Yes Yes No
BIP-GMAC-128 No No Yes
BIP-GMAC-256 No No Yes
BIP-CMAC-256 No No Yes
9.4.2.25.3 AKM suites
The AKM Suite Count field indicates the number of AKM suite selectors that are contained in the AKM
Suite List field. The value 0 is reserved.
The AKM Suite List field contains a series of AKM suite selectors. In an IBSS only a single AKM suite
selector is specified because IBSS STAs use the same AKM suite and because there is no mechanism to
negotiate the AKMP in an IBSS (see 12.6.5).
Each AKM suite selector specifies an AKMP. Table 9-133 gives the AKM suite selectors defined by this
standard. An AKM suite selector has the format shown in Figure 9-256.
Table 9-133—AKM suite selectors
Meaning
Suite
OUI
type Key derivation
Authentication type Key management type
type
00-0F-AC 0 Reserved Reserved Reserved
00-0F-AC 1 Authentication negotiated RSNA key management as Defined in
over IEEE Std 802.1X or defined in 12.7 or using 12.7.1.2
using PMKSA caching as PMKSA caching as defined in
defined in 12.6.10.3 12.6.10.3
00-0F-AC 2 PSK RSNA key management as Defined in
defined in 12.7, using PSK 12.7.1.2
00-0F-AC 3 FT authentication negotiated FT key management as Defined in
over IEEE Std 802.1X defined in 12.7.1.7 12.7.1.7.2 using
SHA-256
886
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-133—AKM suite selectors (continued)
Meaning
Suite
OUI
type Key derivation
Authentication type Key management type
type
00-0F-AC 4 FT authentication using PSK FT key management as Defined in
defined in 12.7.1.7 12.7.1.7.2 using
SHA-256
00-0F-AC 5 Authentication negotiated RSNA key management as Defined in
over IEEE Std 802.1X or defined in 12.7 or using 12.7.1.7.2 using
using PMKSA caching as PMKSA caching as defined in SHA-256
defined in 12.6.10.3 12.6.10.3
00-0F-AC 6 PSK RSNA Key Management as Defined in
defined in 12.7 using PSK 12.7.1.7.2 using
SHA-256
00-0F-AC 7 TDLS TPK handshake Defined in
12.7.1.7.2 using
SHA-256
00-0F-AC 8 SAE authentication with RSNA key management as Defined in
SHA-256 or using PMKSA defined in 12.7, PMKSA 12.7.1.7.2 using
caching as defined in caching as defined in SHA-256
12.6.10.3 12.6.10.3 or authenticated
mesh peering exchange as
defined in 14.5
00-0F-AC 9 FT authentication over SAE FT key management defined Defined in
in 12.7.1.7 12.7.1.7.2 using
SHA-256
00-0F-AC 10 APPeerKey Authentication RSNA key management as Defined in
with SHA-256 or using defined in 12.7 or using 12.7.1.7.2 using
PMKSA caching as defined in PMKSA caching as defined in SHA-256
12.6.10.3 12.6.10.3
00-0F-AC 11 Authentication negotiated RSNA key management as Defined in
over IEEE Std 802.1X or defined in 12.7 or using 12.7.1.7.2 using
using PMKSA caching as PMKSA caching as defined in SHA-256
defined in 12.6.10.3 using a 12.6.10.3
Suite B compliant EAP
method supporting SHA-256
00-0F-AC 12 Authentication negotiated RSNA key management as Defined in
over IEEE Std 802.1X or defined in 12.7 or using 12.7.1.7.2 using
using PMKSA caching as PMKSA caching as defined in SHA-384
defined in 12.6.10.3 using a 12.6.10.3
Suite B compliant EAP
method supporting SHA-384
00-0F-AC 13 FT authentication negotiated FT key management as Defined in
over IEEE Std 802.1X defined in 12.7.1.7 12.7.1.7.2 using
SHA-384
00-0F-AC 14–255 Reserved Reserved Reserved
Other OUI or Any Vendor-specific Vendor-specific Vendor-specific
CID
887
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The AKM suite selector value 00-0F-AC:1 (i.e., Authentication negotiated over IEEE Std 802.1X with
RSNA key management as defined in 12.7 or using PMKSA caching as defined in 12.6.10.3) is the default
AKM suite when the AKM Suite List field is not included in the RSNE.
NOTE—The selector value 00-0F-AC:1 specifies only that IEEE Std 802.1X-2010 is used as the authentication
transport. IEEE Std 802.1X-2010 selects the authentication mechanism.
The AKM suite selector value 00-0F-AC:8 (i.e., SAE authentication with SHA-256 or using PMKSA
caching as defined in 12.6.10.3 with SHA-256 key derivation) is used when either a password or PSK is
used with RSNA key management.
NOTE—Selector values 00-0F-AC:1 and 00-0F-AC:8 can simultaneously be enabled by an Authenticator.
The AKM suite selector value 00-0F-AC:2 (PSK) is used when an alternate form of PSK is used with RSNA
key management.
NOTE—Selector values 00-0F-AC:1 and 00-0F-AC:2 can simultaneously be enabled by an Authenticator.
The AKM suite selector value 00-0F-AC:11 is used only with cipher suite selector values 00-0F-AC:8
(GCMP-128) and 00-0F-AC:11 (BIP-GMAC-128). The AKM suite selector value 00-0F-AC:12 is used
only with cipher suite selector values 00-0F-AC:9 (GCMP-256), 00-0F-AC:10 (CCMP-256), 00-0F-AC:13
(BIP-CMAC-256), and 00-0F-AC:12 (BIP-GMAC-256). The AKM suite selector value 00-0F-AC:13 is
used only with cipher suite selector values 00-0F-AC:9 (GCMP-256), 00-0F-AC:10 (CCMP-256), 00-0F-
AC:13 (BIP-CMAC-256), and 00-0F-AC:12 (BIP-GMAC-256).
9.4.2.25.4 RSN capabilities
The RSN Capabilities field indicates requested or advertised capabilities. If the RSN Capabilities field is not
present, the default value of 0 is used for all of the capability subfields.
The length of the RSN Capabilities field is 2 octets. The format of the RSN Capabilities field is as illustrated
in Figure 9-257 and described after the figure.
B0 B1 B2 B3 B4 B5 B6 B7
Management Frame Management Frame
Preauthenti No Pairwise PTKSA Replay GTKSA Replay Protection Required Protection Capable
cation Counter Counter
(MFPR) (MFPC)
Bits: 1 1 2 2 1 1
B8 B9 B10 B11 B12 B13 B14 B15
Extended Key
ID for
Joint Multi- PeerKey SPP A-MSDU SPP A-MSDU
Band RSNA Enabled Capable Required PBAC Individually Reserved
Addressed
Frames
Bits: 1 1 1 1 1 1 2
Figure 9-257—RSN Capabilities field format
— Bit 0: Preauthentication. An AP sets the Preauthentication subfield of the RSN Capabilities field to 1
to signal it supports preauthentication (see 12.6.10.2) and sets the subfield to 0 when it does not
support preauthentication. A non-AP STA sets the Preauthentication subfield to 0.
888
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Bit 1: No Pairwise. If a STA supports WEP default key 0 simultaneously with a pairwise key (see
12.7.1), then the STA sets the No Pairwise subfield of the RSN Capabilities field to 0.
If a STA does not support WEP default key 0 simultaneously with a pairwise key (see 12.7.1), then
the STA sets the No Pairwise subfield of the RSN Capabilities field to 1.
The No Pairwise subfield describes a capability of a non-AP STA. IBSS STAs and APs set the No
Pairwise subfield to 0.
The No Pairwise subfield is set to 1 only in a TSN and when the pairwise cipher suite selected by the
STA is TKIP.
— Bits 2–3: PTKSA Replay Counter. A STA sets the PTKSA Replay Counter subfield of the RSN
Capabilities field to the value contained in dot11RSNAConfigNumberOfPTKSAReplayCounters.
The least significant bit (LSB) of dot11RSNAConfigNumberOfPTKSAReplayCounters is put in
bit 2. See 12.5.2.6 and 12.5.3.4.4. The meaning of the value in the PTKSA/GTKSA/STKSA Replay
Counter subfield is defined in Table 9-134. The number of replay counters per STKSA is the same
as the number of replay counters per PTKSA.
Table 9-134—PTKSA/GTKSA/STKSA replay counters usage
Replay counter value Meaning
0 1 replay counter per PTKSA/GTKSA/STKSA
1 2 replay counters per PTKSA/GTKSA/STKSA
2 4 replay counters per PTKSA/GTKSA/STKSA
3 16 replay counters per PTKSA/GTKSA/STKSA
— Bits 4–5: GTKSA Replay Counter. A STA sets the GTKSA Replay Counter subfield of the RSN
Capabilities field to the value contained in dot11RSNAConfigNumberOfGTKSAReplayCounters.
The LSB of dot11RSNAConfigNumberOfGTKSAReplayCounters is put in bit 4. See 12.5.2.6 and
12.5.3.4.4. The meaning of the value in the GTKSA Replay Counter subfield is defined in Table 9-
134.
— Bit 6: Management Frame Protection Required (MFPR). A STA sets this bit to 1 to advertise that
protection of robust Management frames is mandatory. A STA sets this bit to 1 when
dot11RSNAProtectedManagementFramesActivated is true and
dot11RSNAUnprotectedManagementFramesAllowed is false; otherwise it sets this bit to 0. If a STA
sets this bit to 1, then that STA only allows RSNAs with STAs that provide Management Frame
Protection.
— Bit 7: Management Frame Protection Capable (MFPC). A STA sets this bit to 1 when
dot11RSNAProtectedManagementFramesActivated is true to advertise that protection of robust
Management frames is enabled.
— Bit 8: Joint Multi-band RSNA. A STA sets the Joint Multi-band RSNA subfield to 1 to indicate that
it supports the Joint Multi-band RSNA (12.6.22). Otherwise, this subfield is set to 0.
— Bits 9: PeerKey Enabled. An AP STA sets the PeerKey Enabled subfield of the RSN Capabilities
field to 1 to signal it supports PeerKey handshake (see 12.7.8). Otherwise, this subfield is set to 0.
— Bit 10: SPP A-MSDU Capable. A STA sets the SPP A-MSDU Capable subfield of the RSN
Capabilities field to 1 to signal that it supports signaling and payload protected A-MSDUs (SPP
A-MSDUs) (see 11.19). Otherwise, this subfield is set to 0.
— Bit 11: SPP A-MSDU Required. A STA sets the SPP A-MSDU Required subfield of the RSN
Capabilities field to 1 when it allows only SPP A-MSDUs (i.e., does not send or receive payload
protected A-MSDUs (PP A-MSDUs) (see 11.19). Otherwise, this subfield is set to 0.
— Bit 12: PBAC (protected block ack agreement capable). A STA sets the PBAC subfield of RSN
Capabilities field to 1 to indicate it is PBAC. Otherwise, this subfield is set to 0.
889
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Bit 13: Extended Key ID for Individually Addressed Frames. This subfield is set to 1 to indicate that
the STA supports Key ID values in the range 0 to 1 for a PTKSA and STKSA when the cipher suite
is CCMP or GCMP. A value of 0 indicates that the STA only supports Key ID 0 for a PTKSA and
STKSA.
— Bits 14–15: Reserved. The remaining subfields of the RSN Capabilities field are reserved.
9.4.2.25.5 PMKID
The PMKID Count and List fields are used only in the RSNE in the (Re)Association Request frame to an AP
and in FT authentication sequence frames.
The PMKID Count field indicates the number of PMKIDs that are contained in the PMKID List field. The
PMKID List field contains a series (possibly empty) of PMKIDs that the STA believes to be valid for the
destination AP. The PMKID can refer to
a) A cached PMKSA that has been obtained through preauthentication with the target AP
b) A cached PMKSA from an EAP or SAE authentication
c) A PMKSA derived from a PSK for the target AP
d) A PMK-R0 security association derived as part of an FT initial mobility domain association
e) A PMK-R1 security association derived as part of an FT initial mobility domain association or as
part of a fast BSS transition.
See 12.7.1.3 for the construction of the PMKID, 13.8 for the population of PMKID for fast BSS transitions,
and 12.7.1.7 for the construction of PMKR0Name and PMKR1Name.
NOTE—A STA need not insert a PMKID in the PMKID List field if the STA will not be using that PMKSA.
9.4.2.26 Vendor Specific element
The Vendor Specific element is used to carry information not defined in this standard within a single defined
format, so that reserved element IDs are not usurped for nonstandard purposes and so that interoperability is
more easily achieved in the presence of nonstandard information. The element is in the format shown in
Figure 9-258.
Element ID Length Organization Vendor-specific content
Identifier
Octets: 1 1 j variable
Figure 9-258—Vendor Specific element format
The Element ID and Length fields are defined in 9.4.2.1.
The Organization Identifier field identifies (see 9.4.1.32) the entity that has defined the content of the
particular Vendor Specific element. See 9.4.1.32 for the definition of j.
9.4.2.27 Extended Capabilities element
The Extended Capabilities element carries information about the capabilities of a STA that augment
the capabilities specified in the Capability Information field. The format of this element is shown in
Figure 9-259.
890
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Element ID Length Extended Capabilities
Octets: 1 1 n
Figure 9-259—Extended Capabilities element format
The Element ID and Length fields are defined in 9.4.2.1.
The Extended Capabilities field is a bit field indicating the extended capabilities being advertised by the
STA transmitting the element. The length of the Extended Capabilities field is a variable n. The Extended
Capabilities field is shown in Table 9-135.
Table 9-135—Extended Capabilities field
Bit Information Notes
0 20/40 BSS The 20/40 BSS Coexistence Management Support field indicates support for the
Coexistence 20/40 BSS Coexistence Management frame and its use. The 20/40 BSS
Management Coexistence Management Support field is set to 1 to indicate support for the
Support communication of STA information through the transmission and reception of the
20/40 BSS Coexistence Management frame. The 20/40 BSS Coexistence
Management Support field is set to 0 to indicate a lack of support for the
communication of STA information through the transmission and reception of the
20/40 BSS Coexistence Management frame.
1 Reserved
2 Extended Channel The Extended Channel Switching field is 1 to indicate support for the
Switching communication of channel switching information through the transmission and
reception of the Extended Channel Switch Announcement element and
Management frame, as described in 9.6.8.7. The Extended Channel Switching
field is 0 to indicate a lack of support for extended channel switching.
3 Reserved
4 PSMP Capability This field indicates support for PSMP operation. See 10.29.
Set to 0 if the STA does not support PSMP operation
Set to 1 if the STA supports PSMP operation.
5 Reserved
6 S-PSMP Support Indicates support for scheduled PSMP.
When the PSMP Capability field is equal to 0, the S-PSMP Support field is set to
0.
When the PSMP Capability field is equal to 1, the S-PSMP Support field is
defined as follows:
Set to 0 if STA does not support S-PSMP
Set to 1 if STA supports S-PSMP
7 Event The STA sets the Event field to 1 when dot11EventsActivated is true, and sets it
to 0 otherwise. See 11.24.2.
8 Diagnostics The STA sets the Diagnostics field to 1 when dot11DiagnosticsActivated is true,
and sets it to 0 otherwise. See 11.24.3.
9 Multicast The STA sets the Multicast Diagnostics field to 1 when dot11MulticastDiagnos-
Diagnostics ticsActivated is true, and sets it to 0 otherwise. See 11.24.3.
891
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-135—Extended Capabilities field (continued)
Bit Information Notes
10 Location Tracking The STA sets the Location Tracking field to 1 when
dot11LocationTrackingActivated is true, and sets it to 0 otherwise. See 11.24.4.
11 FMS The STA sets the FMS field to 1 when dot11FMSActivated is true, and sets it to 0
otherwise.
See 11.2.3.16 and 11.24.8.
12 Proxy ARP The AP sets the Proxy ARP Service field to 1 when dot11ProxyARPActivated is
Service true, and sets it to 0 otherwise. See 11.24.14. A non-AP STA sets the Proxy ARP
Service field to 0.
13 Collocated The STA sets the Collocated Interference Reporting field to 1 when
Interference dot11CoLocIntfReportingActivated is true, and sets it to 0 otherwise. See 11.24.9.
Reporting
14 Civic Location The STA sets the Civic Location field to 1 when dot11RMCivicConfigured is
true, and sets it to 0 otherwise. See 11.11.9.9.
15 Geospatial The STA sets the Geospatial Location field to 1 when dot11RMLCIConfigured is
Location true, and sets it to 0 otherwise. See 11.11.9.6.
16 TFS The STA sets the TFS field to 1 when dot11TFSActivated is true, and sets it to 0
otherwise. See 11.24.12.
17 WNM Sleep The STA sets the WNM Sleep Mode field to 1 when
Mode dot11WNMSleepModeActivated is true, and sets it to 0 otherwise. See 11.2.3.18.
18 TIM Broadcast The STA sets the TIM Broadcast field to 1 when dot11TIMBroadcastActivated is
true, and sets it to 0 otherwise. See 11.2.3.17.
19 BSS Transition The STA sets the BSS Transition field to 1 when dot11BSSTransitionActivated is
true, and sets it to 0 otherwise. See 11.24.7.
20 QoS Traffic The STA sets the QoS Traffic Capability field to 1 when
Capability dot11QoSTrafficCapabilityActivated is true, and sets it to 0 otherwise. See
11.24.10.
21 AC Station Count The STA sets the AC Station Count field to 1 when
dot11ACStationCountActivated is true, and sets it to 0 otherwise. See 11.24.11.
22 Multiple BSSID The STA sets the Multiple BSSID field to 1 when dot11MultiBSSIDActivated is
true, and sets it to 0 otherwise. See 11.11.14 and 11.1.3.8.
23 Timing The STA sets the Timing Measurement field to 1 when
Measurement dot11TimingMsmtActivated is true, and sets it to 0 otherwise. See 11.24.5.
24 Channel Usage The STA sets the Channel Usage field to 1 when dot11ChannelUsageActivated is
true and sets it to 0 otherwise. See 11.24.15.
25 SSID List The STA sets the SSID List field to 1 when dot11SSIDListActivated is true, and
sets it to 0 otherwise. See 11.1.4.
26 DMS The STA sets the DMS field to 1 when dot11DMSActivated is true and sets it to 0
otherwise. See 11.24.16.
27 UTC TSF Offset The STA sets the UTC TSF Offset field to 1 when dot11UTCTSFOffsetActivated
is true and sets it to 0 otherwise. See 11.22.3.
892
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-135—Extended Capabilities field (continued)
Bit Information Notes
28 TPU Buffer STA The TPU Buffer STA Support subfield indicates support for the TPU buffer STA
Support function, as defined in 11.2.3.15. When
dot11TDLSPeerUAPSDBufferSTAActivated is true, and to indicate support for
TPU on this link, the TPU Buffer STA Support subfield is set to 1. Otherwise, the
TPU Buffer STA Support subfield is set to 0 to indicate that this capability is not
supported on this link.
29 TDLS Peer PSM The TDLS Peer PSM Support subfield indicates support for TDLS peer PSM, as
Support defined in 11.2.3.14. When dot11TDLSPeerPSMActivated is true, and to indicate
support for TDLS peer PSM on this link, the TDLS Peer PSM Support subfield is
set to 1. Otherwise, the TDLS Peer PSM Support subfield is set to 0 to indicate
that this capability is not supported on this link.
30 TDLS channel When dot11TDLSChannelSwitchingActivated is true, and to indicate that the
switching STA supports TDLS with TDLS Channel Switching on this link as described in
11.23, the TDLS Channel Switching capability subfield is set to 1. Otherwise, the
TDLS Channel Switching subfield is set to 0 to indicate that this capability is not
supported on this link.
31 Interworking When dot11InterworkingServiceActivated is true, the Interworking field is set to
1 to indicate the STA supports interworking service as described in 11.25. When
dot11InterworkingServiceActivated is false, the Interworking field is set to 0 to
indicate the STA does not support this capability.
32 QoS Map When dot11QosMapActivated is true, the QoS Map field is set to 1 to indicate the
STA supports QoS Map service as described in 11.25.9. When
dot11QosMapActivated is false, the QoS Map field is set to 0 to indicate the STA
does not support this capability.
33 EBR When dot11EBRActivated is true, the EBR field is set to 1 to indicate the STA
supports EBR operation as described in 11.4. When dot11EBRActivated is false,
the EBR field is set to 0 to indicate the STA does not support this capability.
34 SSPN Interface When dot11SSPNInterfaceActivated is true, the SSPN Interface field is set to 1 to
indicate the AP supports SSPN Interface service as described in 11.25.5. When
dot11SSPNInterfaceActivated is false, the SSPN Interface is set to 0 to indicate
the AP does not support this capability. Non-AP STAs set this field to 0.
35 Reserved
36 MSGCF When dot11MSGCFActivated is true, the MSGCF Capability field is set to 1 to
Capability indicate the non-AP STA supports the MSGCF in 6.4. When
dot11MSGCFActivated is false, the MSGCF Capability is set to 0 to indicate the
non-AP STA does not support this capability. APs set this field to 0.
37 TDLS Support The TDLS Support subfield indicates support for TDLS, as defined in 11.23.
When dot11TunneledDirectLinkSetupImplemented is true, this field is set to 1 to
indicate support for TDLS. The field is set to 0 otherwise, to indicate that TDLS
is not supported.
38 TDLS Prohibited The TDLS Prohibited subfield indicates whether the use of TDLS is prohibited.
The field is set to 1 to indicate that TDLS is prohibited and to 0 to indicate that
TDLS is allowed.
39 TDLS Channel The TDLS Channel Switching Prohibited subfield indicates whether the use of
Switching TDLS Channel Switching is prohibited. The field is set to 1 to indicate that TDLS
Prohibited Channel Switching is prohibited and to 0 to indicate that TDLS Channel
Switching is allowed.
893
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-135—Extended Capabilities field (continued)
Bit Information Notes
40 Reject Unadmitted When dot11RejectUnadmittedTraffic is true, the Reject Unadmitted Frame bit is
Frame set to 1 to indicate that the STA rejects MA-UNITDATA.request primitives for
frames belonging to an unadmitted TS.
When dot11RejectUnadmittedTraffic is false, the Reject Unadmitted Frame bit is
set to 0 to indicate that the STA is not required to reject MA-UNITDATA.request
primitives for frames belonging to an unadmitted TS.
When dot11RejectUnadmittedTraffic is not present, the Reject Unadmitted frame
bit is set to 0.
41-43 Service Interval Duration of the shortest service interval (SI).
Granularity Used for scheduled PSMP only.
This field is defined when the S-PSMP Support field is set to 1;
otherwise, it is reserved.
See 11.4.6.
Set to 0 for 5 ms
Set to 1 for 10 ms
Set to 2 for 15 ms
Set to 3 for 20 ms
Set to 4 for 25 ms
Set to 5 for 30 ms
Set to 6 for 35 ms
Set to 7 for 40 ms
44 Identifier Location The STA sets the Identifier Location field to 1 when
dot11RMIdentifierMeasurementActivated is true, and sets it to 0 otherwise. See
11.11.9.10.
45 U-APSD The STA sets the U-APSD Coexistence field to 1 when
Coexistence dot11UAPSDCoexistenceActivated is true and sets it to 0 otherwise. See
11.2.3.5.2.
46 WNM The STA sets the WNM Notification field to 1 when
Notification dot11WNMNotificationActivated is true and sets it to 0
otherwise. See 11.24.17.
47 QAB Capability Set to 1 if AP supports QAB
Set to 0 otherwise
48 UTF-8 SSID The SSID in this BSS is interpreted using UTF-8 encoding
49 QMFActivated The STA sets the QMFActivated field to 1 when dot11QMFActivated is true and
sets it to 0 otherwise. See 11.26.
50 QMFReconfigurat The STA sets the QMFReconfigurationActivated field to 1 when
ionActivated dot11QMFActivated is true and sets it to 0 otherwise. See 11.26.
51 Robust AV The STA sets the Robust AV Streaming field to 1 when
Streaming dot11RobustAVStreamingImplemented is true and sets it to 0 otherwise. See
11.27.
52 Advanced GCR The STA sets the Advanced GCR field to 1 when dot11AdvancedGCRActivated
is true and sets it to 0 otherwise. See 11.24.16.3.
53 Mesh GCR The STA sets the mesh GCR field to 1 when dot11MeshGCRActivated is true and
sets it to 0 otherwise. See 11.24.16.3.
54 SCS The STA sets the SCS field to 1 when dot11SCSActivated is true and sets it to 0
otherwise. See 11.27.2.
894
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-135—Extended Capabilities field (continued)
Bit Information Notes
55 QLoad Report The STA sets the QLoad Report field to 1 when dot11QLoadReportActivated is
true and sets it to 0 otherwise. See 11.28.2.
56 Alternate EDCA The STA sets the Alternate EDCA field to 1 when dot11AlternateEDCAActivated
is true and sets it to 0 otherwise. See 10.2.4.2.
57 Unprotected The STA sets the Unprotected TXOP Negotiation field to 1 when
TXOP dot11PublicTXOPNegotiationActivated is true and sets it to 0 otherwise. See
Negotiation 11.28.3.
58 Protected TXOP The STA sets the Protected TXOP Negotiation field to 1 when
Negotiation dot11ProtectedTXOPNegotiationActivated is true and sets it to 0 otherwise. See
11.28.3.
59 Reserved
60 Protected QLoad The STA sets the Protected QLoad Report field to 1 when
Report dot11ProtectedQLoadReportActivated is true and sets it to 0 otherwise. See
11.28.2.
61 TDLS Wider The TDLS Wider Bandwidth subfield indicates whether the STA supports a wider
Bandwidth bandwidth than the BSS bandwidth for a TDLS direct link with a primary channel
equal to the primary or only channel of the base channel. The field is set to 1 to
indicate that the STA supports a wider bandwidth and to 0 to indicate that the STA
does not support a wider bandwidth. A 160 MHz bandwidth is defined to be
identical to an 80+80 MHz bandwidth (i.e., one is not wider than the other).
62 Operating Mode If dot11OperatingModeNotificationImplemented is true, the Operating Mode
Notification Notification field is set to 1 to indicate support for reception of the Operating
Mode Notification element and the Operating Mode Notification frame.
If dot11OperatingModeNotificationImplemented is false or not present, the
Operating Mode Notification field is set to 0 to indicate lack of support for
reception of the Operating Mode Notification element and the Operating Mode
Notification frame.
63–64 Max Number Of Indicates the maximum number of MSDUs in an A-MSDU that the STA is able to
MSDUs In receive from a VHT STA:
A-MSDU Set to 0 to indicate that no limit applies.
Set to 1 for 32.
Set to 2 for 16.
Set to 3 for 8
Reserved if A-MSDU is not supported or if the STA is not an HT STA.
65 Channel Schedule The STA sets the Channel Schedule Management field to 1 when
Management dot11ChannelScheduleManagementActivated is true and sets it to 0 otherwise.
See 11.44.5.
66 Geodatabase The STA sets the Geodatabase Inband Enabling Signal field to 1 when
Inband Enabling dot11GDDActivated is true and the STA permits GDD dependent STAs to
Signal operate. See 11.44.2.
67 Network Channel The STA sets the Network Channel Control field to 1 when
Control dot11NetworkChannelControlActivated is true and sets it to 0 otherwise. See
11.44.7.
68 White Space Map The STA sets the White Space Map field to 1 when
dot11WhiteSpaceMapActivated is true and sets it to 0 otherwise. See 11.44.9.
69 Channel The STA sets the Channel Availability Query field to 1 when
Availability Query dot11GDDActivated is true and sets it to 0 otherwise. See 11.44.4.
895
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-135—Extended Capabilities field (continued)
Bit Information Notes
70 Fine Timing The STA sets the Fine Timing Measurement Responder field to 1 when
Measurement dot11FineTimingMsmtRespActivated is true and sets it to 0 otherwise. See
Responder 11.24.6.
71 Fine Timing The STA sets the Fine Timing Measurement Initiator field to 1 when
Measurement dot11FineTimingMsmtInitActivated is true and sets it to 0 otherwise. See 11.24.6.
Initiator
73 Extended The STA sets the Extended Spectrum Management Capable field to 1 when
Spectrum dot11ExtendedSpectrumManagementImplemented is true and
Management dot11VHTOptionImplemented is false, and sets it to 0 otherwise.
Capable
74 Future Channel The STA sets the Future Channel Guidance field to 1 when
Guidance dot11FutureChannelGuidanceActivated is true and sets it to 0 otherwise. See
11.9.10.
72, 75–n Reserved
If a STA does not support any of capabilities defined in the Extended Capabilities element, then the STA is
not required to transmit the Extended Capabilities element.
NOTE—The fields of the Extended Capabilities element are not dynamic. They are determined by the parameters of the
MLME-START.request or MLME-JOIN.request primitive that caused the STA to start or join its current BSS, and they
remain unchanged until the next MLME-START.request or MLME-JOIN.request primitive.
9.4.2.28 BSS Load element
The BSS Load element contains information on the current STA population and traffic levels in the BSS.
The element information format is defined in Figure 9-260. This element might be used by the STA for
vendor-specific AP selection algorithm when roaming.
Length Available Admission
Element ID Station Count Channel Utilization
(5) Capacity
Octets: 1 1 2 1 2
Figure 9-260—BSS Load element format
The Element ID and Length fields are defined in 9.4.2.1.
The STA Count field is interpreted as an unsigned integer that indicates the total number of STAs currently
associated with this BSS.
The Channel Utilization field is defined as the percentage of time, linearly scaled with 255 representing
100%, that the AP sensed the medium was busy, as indicated by either the physical or virtual carrier sense
(CS) mechanism. When more than one channel is in use for the BSS, the Channel Utilization field value is
calculated only for the primary channel. This percentage is computed using the formula,
channel busy time
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
Channel Utilization = 255
dot11ChannelUtilizationBeaconIntervals dot11BeaconPeriod 1024
896
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
channel busy time is defined to be the number of microseconds during which the CS mechanism, as
defined in 10.3.2.1, has indicated a channel busy indication,
dot11ChannelUtilizationBeaconIntervals represents the number of consecutive beacon intervals during
which the channel busy time is measured. The default value of dot11ChannelUtilizationBea-
conIntervals is defined in Annex C.
The Available Admission Capacity field is 2 octets long and contains an unsigned integer that specifies the
remaining amount of medium time available via explicit admission control, in units of 32 s/s. The field is
helpful for roaming STAs to select an AP that is likely to accept future admission control requests, but it
does not represent an assurance that the HC admits these requests.
9.4.2.29 EDCA Parameter Set element
The EDCA Parameter Set element provides information needed by STAs for proper operation of the QoS
facility during the CP. The format of the EDCA Parameter Set element is defined in Figure 9-261.
Length QoS Reserve AC_BE AC_BK AC_VI AC_VO
Element ID Parameter Parameter Parameter Parameter
(18) Info d Record Record Record Record
Octets: 1 1 1 1 4 4 4 4
Figure 9-261—EDCA Parameter Set element
The Element ID and Length fields are defined in 9.4.2.1.
For an infrastructure BSS, the EDCA Parameter Set element is used by the AP to establish policy (by
changing default MIB attribute values), to change policies when accepting new STAs or new traffic, or to
adapt to changes in offered load. The most recent EDCA parameter set element received by a STA is used to
update the appropriate MIB values.
The format of the QoS Info field is defined in 9.4.1.17. The QoS Info field contains the EDCA Parameter Set
Update Count subfield, which is initially set to 0 and is incremented each time any of the AC parameters
changes. This subfield is used by non-AP STAs to determine whether the EDCA parameter set has changed
and requires updating the appropriate MIB attributes.
The formats of AC_BE, AC_BK, AC_VI, and AC_VO Parameter Record fields are identical and are
illustrated in Figure 9-262.
ACI / AIFSN ECWmin / TXOP Limit
ECWmax
Octets: 1 1 2
Figure 9-262—AC_BE, AC_BK, AC_VI, and AC_VO Parameter Record field format
The format of the ACI/AIFSN field is illustrated in Figure 9-263.
B0 B3 B4 B5 B6 B7
AIFSN ACM ACI Reserved
Bits: 4 1 2 1
Figure 9-263—ACI/AIFSN field
897
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The value of the AC index (ACI) references the AC to which all parameters in this record correspond. The
mapping between ACI and AC is defined in Table 9-136. The ACM (admission control mandatory) subfield
indicates that admission control is required for the AC. If the ACM subfield is equal to 0, then there is no
admission control for the corresponding AC. If the ACM subfield is set to 1, admission control has to be
used prior to transmission using the access parameters specified for this AC. The AIFSN subfield indicates
the number of slots after a SIFS a STA defers before either invoking a backoff or starting a transmission.
The minimum value of the AIFSN subfield is 2.
Table 9-136—ACI-to-AC coding
ACI AC Description
0 AC_BE Best effort
1 AC_BK Background
2 AC_VI Video
3 AC_VO Voice
The ECWmin and ECWmax fields are illustrated in Figure 9-264.
B0 B3 B4 B7
ECWmin ECWmax
Bits: 4 4
Figure 9-264—ECWmin and ECWmax fields
The ECWmin and ECWmax fields encode the values of CWmin and CWmax, respectively, in an exponent
form. The ECWmin and ECWmax values are defined so that
CWmin = 2ECWmin – 1
CWmax = 2ECWmax – 1
Hence the minimum encoded value of CWmin and CWmax is 0, and the maximum value is 32 767.
The value of the TXOP Limit field is specified as an unsigned integer, in units of 32 s. A TXOP Limit field
value of 0 has a special meaning (see 10.22.2.8).
Table 9-137 defines the default EDCA parameter values used by a non-AP STA if dot11OCBActivated is
false.24
24
The default values for TXOP limit are expressed in milliseconds and are multiples of 32 s.
898
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-137—Default EDCA Parameter Set element parameter values if dot11OCBActivated is false
TXOP limit
For PHYs defined
AC CWmin CWmax AIFSN For PHYs defined in Clause 17,
For PHY defined Other
in Clause 15 and Clause 18,
Clause 16 Clause 19, and in Clause 22 PHYs
Clause 21
AC_BK aCWmin aCWmax 7 3.264 ms 2.528 ms 0 0
AC_BE aCWmin aCWmax 3 3.264 ms 2.528 ms 0 0
AC_VI (aCWmin+1)/2 aCWmin 2 6.016 ms 4.096 ms 22.56 ms 0
–1 (BCU: 6 or 7
MHz),
16.92 ms
(BCU: 8 MHz)
AC_VO (aCWmin+1)/4 (aCWmin+1)/ 2 3.264 ms 2.080 ms 11.28 ms 0
–1 2–1 (BCU: 6 or 7
MHz),
8.46 ms (BCU:
8 MHz)
If dot11OCBActivated is true, the default EDCA parameter set for STAs transmitting QoS frames is given
in Table 9-138.
Table 9-138—Default EDCA parameter set for STA operation if dot11OCBActivated is true
AC CWmin CWmax AIFSN TXOP limit
AC_BK aCWmin aCWmax 9 0
AC_BE aCWmin aCWmax 6 0
AC_VI (aCWmin+1)/2–1 aCWmin 3 0
AC_VO (aCWmin+1)/4–1 (aCWmin+1)/2–1 2 0
9.4.2.30 TSPEC element
The TSPEC element contains the set of parameters that define the characteristics and QoS expectations of a
traffic flow, in the context of a particular STA, for use by the HC or PCP and STA(s) or a mesh STA and its
peer mesh STAs in support of QoS traffic transfer using the procedures defined in 11.4 and 11.24.16.3. The
element information format comprises the items as defined in this subclause, and the structure is defined in
Figure 9-265.
The TSPEC allows a set of parameters more extensive than might be needed, or might be available, for any
particular instance of parameterized QoS traffic. Unless indicated otherwise, fields that follow the TS Info
field are set to 0 for any unspecified parameter values. STAs set the value of any parameters to unspecified
if they have no information for setting that parameter.
899
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Element Length Nominal Maximum Minimum Maximum Inactivity Suspension
TS Info MSDU MSDU Service Service
ID (55) Size Size Interval Interval Interval Interval
Octets: 1 1 3 2 2 4 4 4 4
Surplus
Service Minimum Mean Peak Data Delay Minimum Medium DMG
Start Time Data Rate Data Rate Rate Burst Size Bound PHY Rate Bandwidth Time Attributes
Allowance
Octets: 4 4 4 4 4 4 4 2 2 0 or 2
Figure 9-265—TSPEC element format
The structure of the TS Info field is defined in Figure 9-266.
B0 B1 B4 B5 B6 B7 B8 B9 B10 B11 B13 B14 B15 B16 B17 B23
TSInfo
Traffic Access User
Type TSID Direction Policy Aggregation APSD Priority Ack Schedule Reserved
Policy
Bits: 1 4 2 2 1 1 3 2 1 7
Figure 9-266—TS Info field
The subfields of the TS Info field are defined as follows:
— The Traffic Type subfield is a single bit and is set to 1 for a periodic traffic pattern (e.g., isochronous
TS of MSDUs or A-MSDUs, with constant or variable sizes, that are originated at fixed rate) or set
to 0 for an aperiodic, or unspecified, traffic pattern (e.g., asynchronous TS of low-duty cycles).
— The TSID subfield is 4 bits in length and contains a value that is a TSID. Note that the MSB (bit 4 in
TS Info field) of the TSID subfield is always set to 1 when the TSPEC element is included within an
ADDTS Response frame.
— The Direction subfield specifies the direction of data carried by the TS as defined in Table 9-139.
Table 9-139—Direction subfield encoding
Bit 5 Bit 6 Usage
Uplink, defined as follows:
— Non-DMG BSS: MSDUs or A-MSDUs are sent from the non-AP STA to HC
0 0
— DMG BSS: MSDUs or A-MSDUs are sent by the non-AP originator of
the ADDTS Request frame
Downlink, defined as follows:
— Non-DMG BSS: MSDUs or A-MSDUs are sent from the HC to the non-AP
1 0 STA
— DMG BSS: MSDUs or A-MSDUs are sent by the non-AP recipient of the
ADDTS Request frame
Direct link (MSDUs or A-MSDUs are sent from the non-AP STA to another non-AP
0 1
STA)
1 1 Bidirectional link (equivalent to a downlink request plus an uplink request, each
direction having the same parameters).
The fields in the TSPEC element specify resources for a single direction. Double the
specified resources are required to support both streams.
900
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The Access Policy subfield is 2 bits in length, specifies the access method to be used for the TS, and
is defined in Table 9-140.
Table 9-140—Access Policy subfield
Bit 7 Bit 8 Usage
0 0 Reserved
1 0 Contention based channel access (EDCA)
0 1 Controlled channel access (HCCA for non-DMG STAs and SPCA for DMG STAs)
1 1 Controlled and contention based channel access (HCCA, EDCA mixed mode (HEMM)
for non-DMG STAs; SPCA, EDCA mixed mode (SEMM) for DMG STAs)
— The Aggregation subfield is 1 bit in length. The Aggregation subfield is valid only when the access
method is HCCA or SPCA or when the access method is EDCA and the Schedule subfield is equal
to 1. It is set to 1 by a non-AP STA to indicate that an aggregate schedule is required. It is set to 1 by
the AP if an aggregate schedule is being provided to the STA. It is set to 0 otherwise. In all other
cases, the Aggregation subfield is reserved.
— The APSD subfield is a single bit and is set to 1 to indicate that automatic PS delivery is to be used
for the traffic associated with the TSPEC and set to 0 otherwise.
— The UP subfield is 3 bits and indicates the actual value of the UP to be used for the transport of
MSDUs or A-MSDUs belonging to this TS when relative prioritization is required. When the
TCLAS element is present in the request, the UP subfield in TS Info field of the TSPEC element is
reserved.
— The TS Info Ack Policy subfield is 2 bits in length and indicates whether MAC acknowledgments
are required for MPDUs or A-MSDUs belonging to this TSID and the form of those
acknowledgments. The encoding of the TS Info Ack Policy subfield is shown in Table 9-141.
Table 9-141—TS Info Ack Policy subfield encoding
Bit 14 Bit 15 Usage
0 0 Normal Acknowledgment
The addressed recipient returns an Ack or QoS +CF-Ack frame after a SIFS, according
to the procedures defined in 10.3.2.9, 10.4.4, and 10.22.3.5.
1 0 No Ack: The recipient(s) do not acknowledge the transmission.
0 1 Reserved
1 1 Block Ack: A separate block ack mechanism described in 10.24 is used.
— The Schedule subfield is 1 bit in length and specifies the requested type of schedule. The setting of
the subfield when the access policy is EDCA is shown in Table 9-142. When the Access Policy
subfield is equal to any value other than EDCA, the Schedule subfield is reserved. When the
Schedule and APSD subfields are equal to 1, the AP sets the aggregation bit to 1, indicating that an
aggregate schedule is being provided to the STA.
901
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-142—Setting of Schedule subfield
APSD Schedule Usage
0 0 No Schedule
1 0 Unscheduled APSD
0 1 Scheduled PSMP or GCR-SP
1 1 Scheduled APSD
The Nominal MSDU Size field is 2 octets long and contains an unsigned integer that specifies the nominal
size, in octets, of MSDUs or (where A-MSDU aggregation is employed) A-MSDUs belonging to the TS
under this TSPEC and is defined in Figure 9-267. If the Fixed subfield is equal to 1, then the size of the
MSDU or A-MSDU is fixed and is indicated by the Size subfield. If the Fixed subfield is equal to 0, then the
size of the MSDU or A-MSDU might not be fixed and the Size subfield indicates the nominal MSDU size. If
both the Fixed and Size subfields are equal to 0, then the nominal MSDU or A-MSDU size is unspecified.
B0 B14 B15
Size Fixed
Bits: 15 1
Figure 9-267—Nominal MSDU Size field
The Maximum MSDU Size field is 2 octets long and contains an unsigned integer that specifies the
maximum size, in octets, of MSDUs or A-MSDUs belonging to the TS under this TSPEC.
The Minimum Service Interval field is 4 octets long and contains an unsigned integer that specifies the
minimum interval, in microseconds, between the start of two successive SPs. If the TSPEC element is
included within a GCR Request subelement that has the GCR delivery method equal to GCR-SP, a
Minimum Service Interval field value of 0 indicates that SPs up to the maximum service interval are
requested, including the continuous SP used by the GCR-A delivery method.
The Maximum Service Interval field is 4 octets long and contains an unsigned integer that, when the TSPEC
is for the admitting of HCCA streams, specifies the maximum interval, in microseconds, between the start of
two successive SPs. If the TSPEC element is intended for EDCA Admission Control, the Maximum Service
Interval field is used to indicate a latency limit, which limits the amount of aggregation (A-MSDU or A-
MPDU) used, so that excessive latency does not occur (see K.4.2.1). The Maximum Service Interval field is
greater than or equal to the Minimum Service Interval field. If the TSPEC element is included within a GCR
Request subelement that has the GCR delivery method equal to GCR-SP, a Maximum Service Interval field
value of 0 indicates that the continuous SP used by the GCR-A delivery method is requested.
K.4.2.2 provides guidance on the use of the Maximum Service Interval to determine the limit of aggregation
of nominal MSDUs.
The Inactivity Interval field is 4 octets long and contains an unsigned integer that specifies the minimum
amount of time, in microseconds, that can elapse without arrival or transfer of an MPDU belonging to the TS
before this TS is deleted by the MAC entity at the HC.
The Suspension Interval field is 4 octets long and contains an unsigned integer that specifies the minimum
amount of time, in microseconds, that can elapse without arrival or transfer of an MSDU belonging to the
TS before the generation of successive QoS(+)CF-Poll is stopped for this TS. A value of 4 294 967 295
(= 232 – 1) disables the suspension interval, indicating that polling for the TS is not to be interrupted based
on inactivity. The value of the suspension interval is always less than or equal to the inactivity interval.
902
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Service Start Time field is 4 octets and contains an unsigned integer that specifies the time, expressed in
microseconds, when the first scheduled SP starts. The service start time indicates to the AP the time when a
STA first expects to be ready to send frames and a power-saving STA needs to be awake to receive frames.
This might help the AP to schedule service so that the MSDUs encounter small delays in the MAC and help
the power-saving STAs to reduce power consumption. The field represents the four lower order octets of the
TSF timer at the start of the SP. If APSD and Schedule subfields are 0, this field is also set to 0
(unspecified).
The Minimum Data Rate field is 4 octets long and indicates the lowest data rate specified at the MAC SAP,
for transport of MSDUs or A-MSDUs belonging to this TS within the bounds of this TSPEC. The field is
encoded as a piecewise linear function described as follows:
31
F min F min 2
R min =
31 31 31
1024 F min – 2 +2 F min 2
where
Rmin is the minimum data rate (in units of bits per second)
Fmin is the value of the Minimum Data Rate field
The Mean Data Rate25 field is 4 octets long and indicates the average data rate specified at the MAC SAP,
for transport of MSDUs or A-MSDUs belonging to this TS within the bounds of this TSPEC. The field is
encoded as a piecewise linear function described as follows:
31
Fmean F mean 2
R mean =
31 31 31
1024 F mean – 2 +2 F mean 2
where
Rmean is the mean data rate (in units of bits per second)
Fmean is the value of the Mean Data Rate field
The Peak Data Rate field is 4 octets long and indicates the maximum allowable data rate specified at the
MAC SAP for transport of MSDUs or A-MSDUs belonging to this TS within the bounds of this TSPEC.
The field is encoded as a piecewise linear function described as follows:
31
Fpeak F peak 2
R peak =
31 31 31
1024 F peak – 2 +2 F peak 2
where
Rpeak is the peak data rate (in units of bits per second)
Fpeak is the value of the Peak Data Rate field
If p is the peak rate in bits per second, then the maximum amount of data, belonging to this TS, arriving in
any time interval [t1,t2], where t1 < t2 and t2 – t1 > 1 TU, does not exceed p × (t2 – t1) bits.
25
The mean data rate, the peak data rate, and the burst size are the parameters of the token bucket model, which provides standard
terminology for describing the behavior of a traffic source. The token bucket model is described in IETF RFC 2212 [B29], IETF RFC
2215 [B30], and IETF RFC 3290 [B37].
903
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Minimum, Mean and Peak Data Rates do not include the MAC and PHY overheads incurred in
transporting the MSDUs or A-MSDUs, with the exception of the MAC overheads specific to A-MSDUs
(A-MSDU subframe header and padding). K.4.3 provides guidance on how to determine the standard
deviation of the TS and how to calculate the total traffic when there are multiple TSs.
The Burst Size field is 4 octets long and contains an unsigned integer that specifies the maximum burst, in
octets, of the MSDUs or A-MSDUs belonging to this TS that arrive at the MAC SAP at the peak data rate. A
value of 0 indicates that there are no bursts.
The Delay Bound field is 4 octets long and contains an unsigned integer that specifies the maximum amount
of time, in microseconds, allowed to transport an MSDU or A-MSDU belonging to the TS in this TSPEC,
measured between the time marking the arrival of the MSDU, or the first MSDU of the MSDUs constituting
an A-MSDU, at the local MAC sublayer from the local MAC SAP and the time of completion of the
successful transmission or retransmission of the MSDU or A-MSDU to the destination. The completion of
the MSDU or A-MSDU transmission includes the relevant acknowledgment frame transmission time, if
present.
The Minimum PHY Rate field is 4 octets long and indicates the minimum PHY rate for transport of MSDUs
or A-MSDUs belonging to this TS within the bounds of this TSPEC.26 See 11.4.2 for constraints on the
selection of this field. The field is encoded as a piecewise linear function described as follows:
31
F minphy F minphy 2
R minphy =
31 31 31
1024 F minphy – 2 +2 F minphy 2
where
Rminphy is the minimum PHY rate (in units of bits per second)
Fminphy is the value of the Minimum PHY Rate field
The Surplus Bandwidth Allowance field is 2 octets long and specifies the excess allocation of time (and
bandwidth) over and above the stated application rates required to transport an MSDU or A-MSDU
belonging to the TS in this TSPEC. This field is represented as an unsigned binary number and, when
specified, is greater than 0. The 13 least significant bits (LSBs) indicate the decimal part while the three
MSBs indicate the integer part of the number. This field takes into account the retransmissions, as the rate
information does not include retransmissions. It represents the ratio of over-the-air bandwidth (i.e., time that
the scheduler allocates for the transmission of MSDUs or A-MSDUs at the required rates) to bandwidth of
the transported MSDUs or A-MSDUs required for successful transmission (i.e., time that would be
necessary at the minimum PHY rate if there were no errors on the channel) to meet throughput and delay
bounds under this TSPEC, when specified. As such, it should be greater than unity. A value of 1 indicates
that no additional allocation of time is requested. K.4.1 provides guidance on how to calculate the value for
Surplus Bandwidth Allowance.
The Medium Time field is a 16-bit unsigned integer and contains the amount of time admitted to access the
medium, in units of 32 s/s. This field is reserved in the ADDTS Request frame and is set by the HC in the
ADDTS Response frame. The derivation of this field is described in K.2.2. This field is not used for
controlled channel access.
26
This rate information is intended to confirm that the TSPEC parameter values resulting from an admission control negotiation are
sufficient to provide the required throughput for the TS. In a typical implementation, a TS is admitted only if the defined traffic volume
can be accommodated at the specified rate within an amount of WM occupancy time that the admissions control entity is willing to
allocate to this TS.
904
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The UP, Minimum Data Rate, Mean Data Rate, Peak Data Rate, Burst Size, Minimum PHY Rate, and Delay
Bound fields in a TSPEC element express the QoS expectations requested by a STA, if this TSPEC was
issued by that STA, or provided by the HC, if this TSPEC was issued by the HC, when these fields are
specified with nonzero values. Unspecified parameters in these fields as indicated by a value of 0 indicate
that the STA does not have specific requirements for these parameters if the TSPEC was issued by that STA
or that the HC does not provide any specific values for these parameters if the TSPEC was issued by the HC.
Annex K provides guidance on the use of the TSPEC and the settings of values of the various fields.
The DMG Attributes field is defined in Figure 9-268. The DMG Attributes field is present in a TSPEC when
the BSS to which the TSPEC applies is a DMG BSS; otherwise absent.
B0 B3 B4 B5 B6 B7 B8 B9 B10 B15
Allocation ID Reserved Allocation A-MSDU Reliability Reserved
Direction Subframe
Bits: 4 2 1 1 2 6
Figure 9-268—DMG Attributes field format
— The Allocation ID subfield is 4 bits in length. Traffic streams can share an allocation through
TSPEC aggregation (see Annex V). The Allocation ID subfield is used as follows:
— When setting up a TS, the DMG STA that transmits an ADDTS Request frame containing a
TSPEC or PTP TSPEC element sets the Allocation ID subfield to a nonzero value to identify
the allocation it requires to carry the TS. Alternatively, the same DMG STA sets the Allocation
ID subfield to 0 to indicate any CBAP allocation with the broadcast AID as Source AID.
— When setting up a TS, the DMG STA that transmits the ADDTS Response frame containing
the TSPEC or PTP TSPEC element sets the Allocation ID subfield to a nonzero value that
identifies the allocation carrying the TS. Alternatively, the same DMG STA sets the Allocation
ID subfield to 0 to indicate any CBAP allocation with the broadcast AID as Source AID and
Destination AID.
— When deleting a TS, the DMG STA that transmits the DELTS frame containing a TSPEC or
PTP TSPEC element sets the Allocation ID subfield to a nonzero value to identify the
allocation that is carrying the TS to be deleted. Alternatively, the same DMG STA sets the
Allocation ID subfield to 0 to indicate no allocation exists to carry the TS to be deleted.
— The Allocation Direction subfield is 1 bit in length. It is equal to 1 when the originator of the
ADDTS request is also the source of the allocation identified by the Allocation ID subfield and is
equal to 0 otherwise. The Allocation Direction subfield is equal to 0 when the Allocation ID subfield
is equal to 0.
— The A-MSDU Subframe subfield is 1 bit in length and contains a value that indicates the A-MSDU
subframe structure to be used for this TS. The A-MSDU Subframe subfield is set to 0 to indicate the
Basic A-MSDU subframe structure and set to 1 to indicate the Short A-MSDU subframe structure.
— The Reliability subfield is 2 bits in length and contains an expected reliability index. The reliability
index refers to the PHY PER (PSDU error rate as in 20.3.3.8). The relation between the reliability
index and the PER is shown in Table 9-143.
The Reliability subfield in an ADDTS Request frame that has the Direction subfield set to downlink
or in an ADDTS Response frame that has the Direction field set to uplink indicates the expectation
of the PER of the destination DMG STA for this TS. The Reliability subfield in an ADDTS Request
frame that has the Direction subfield set to uplink or in an ADDTS Response frame that has the
Direction field set to downlink is reserved. The reliability information is provided by the SME using
the MLME-ADDTS.request primitive and MLME-ADDTS.response primitives. Together with the
link margin (10.39) and other implementation-specific information, this value can be used by the
source DMG STA of this TS to estimate the MCS to be used for this particular TS.
905
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-143—Reliability subfield values
Reliability index PER
0 Not specified
1 10-2
2 10-3
3 10-4
9.4.2.31 TCLAS element
The TCLAS element contains a set of parameters necessary to identify various kinds of PDU or incoming
MSDU (from a higher layer in all STAs or from the DS in an AP) that belong to a particular TS. The TCLAS
element is also used when the traffic does not belong to a TS, for example, by the FMS, DMS, and TFS
services. If required, the TCLAS element is provided in ADDTS Request and ADDTS Response frames
only for the downlink or bidirectional links. The TCLAS element is always included when a PTP TSPEC is
transmitted to a peer STA via an AP or PCP. The structure of this element is shown in Figure 9-269.
Element ID Length User Priority Frame Classifier
Octets: 1 1 1 variable
Figure 9-269—TCLAS element format
The Element ID and Length fields are defined in 9.4.2.1.
When the UP field contains a value that is less than or equal to 7, the value specifies the UP of the associated
MSDUs. When the UP field contains a value that is greater than or equal to 8 and less than or equal to 11,
the value specifies the access category of the associated MPDUs. The UP field value 255 is reserved and
indicates that the UP of the MSDU and the access category of the MPDU are not compared as part of the
traffic filter. The encoding of the contents of the User Priority field of an TCLAS element is specified in
Table 9-144.
Table 9-144—User Priority field of TCLAS element
User Priority Meaning
0–7 The User Priority value of an MSDU
8 The AC value of an MPDU is AC-VO
9 The AC value of an MPDU is AC-VI
10 The AC value of an MPDU is AC-BE
11 The AC value of an MPDU is AC-BK
12–254 Reserved
255 The User Priority field is not used for comparison.
906
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Frame Classifier field is 3–255 octets in length and is defined in Figure 9-270.
Classifier Type Classifier Mask Classifier
Parameters
Octets: 1 1 or 3 variable
Figure 9-270—Frame Classifier field
The Frame Classifier field comprises the following subfields: Classifier Type, Classifier Mask, and
Classifier Parameters. The Classifier Type subfield is 1 octet in length and specifies the type of classifier
parameters in this TCLAS as defined in Table 9-145.
Table 9-145—Frame classifier type
Classifier type Classifier parameters
0 Ethernet parameters
1 TCP/UDP IP parameters
2 IEEE 802.1Q parameters
3 Filter Offset parameters
4 IP and higher layer parameters
5 IEEE 802.1D/Q parameters
6 IEEE 802.11 MAC header parameters
7–255 Reserved
When the Classifier type is a value less than or equal to 5, the Classifier Mask subfield specifies a bitmap in
which bits that have the value 1 identify a subset of the classifier parameters whose values need to match
those of the corresponding parameters in a given MSDU for that MSDU to be classified to the TS of the
affiliated TSPEC. The bitmap is ordered from the LSB to the MSB, with each bit pointing to one of the
classifier parameters of the same relative position as shown in this subclause based on classifier type. When
there are more bits in the bitmap than classifier parameters that follow, the MSBs that do not point to any
classifier parameters are reserved.
When the Classifier Type is equal to 6, the Classifier Mask subfield is three octets in length. It contains a
sequence of nine two-bit Classifier Mask Control subfields. Each Classifier Mask Control subfield applies to
a specific target field of the MAC header. It determines whether the target field is included in the
comparison and whether an additional bitmask (the target field filter mask) is present. When the target field
filter mask is present, it determines which bits of the target field are used in the comparison. Table 9-146
specifies the interpretation of the Classifier Mask Control subfield.
907
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-146—Interpretation of the Classifier Mask Control subfield values
Size of Match
Value of the Is the target Specification field
Classifier Mask Description subfield filter (as a multiplier to
Control subfield mask present? the size of the target
subfield)
0 Target field is not included in classification No 0
1 Target field is included in classification. No 1
Match based on target field bitwise = target
field filter specification
2 Reserved
3 Target subfield is included in classification. Yes 2
Match criteria: if the bit with the same bit
position in target filter mask subfield is set to
1, the bit value in the target field = target field
filter specification;
if the bit with the same bit position in target
filter mask subfield is set to 0, the bit in the
target field match specification need not be
compared.
The map from the location of the Classifier Mask subfield to the target subfield is defined in Table 9-147.
Table 9-147—Map from location of Classifier Mask subfield to target subfield
Bit number Target field
0–1 Frame Control
2–3 Duration/ID
4–5 Address 1
6–7 Address 2
8–9 Address 3
10–11 Sequence Control
12–13 Address 4
14–15 QoS Control
16–17 HT Control
18–23 Reserved
For Classifier Type 0, the classifier parameters are the following parameters contained in an Ethernet frame
header: Source Address, Destination Address, and Type (“Ethernet” [B12]). The endianness of the
Type field is as defined in Ethernet [B12]. The Frame Classifier field for Classifier Type 0 is defined in
Figure 9-271. It has a length of 16 octets.
908
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Classifier Type
(0) Classifier Mask Source Address Destination Address Type
Octets: 1 1 6 6 2
Figure 9-271—Frame Classifier field of Classifier Type 0
For Classifier Type 1, frame classifier is defined for both IPv4 and IPv6, shown in Figure 9-272 and
Figure 9-273, and distinguished by the Version field. Use of Classifier Type 1 for IPv6 is deprecated and
replaced by Classifier Type 4. The subfields in the classifier parameters are represented and transmitted in
the big-endian format. The classifier parameters are the following parameters:
— In a TCP or UDP header: Source Address, Destination Address, Source Port, Destination Port, and
Version, plus
— One of the following:
— In an IPv4 header: Differentiated Services Code Point (DSCP) (IETF RFC 2474 [B31]) and
Protocol, or
— In an IPv6 header: Flow Label.
Classifier
Type Classifier Version Source IP Destination Source Destination DSCP Protocol Reserved
Mask Address IP Address Port Port
(1)
Octets: 1 1 1 4 4 2 2 1 1 1
Figure 9-272—Frame Classifier field of Classifier Type 1 for traffic over IPv4
Classifier
Type Classifier Version Source IP Destination Source Destination Flow
Mask Address IP Address Port Port Label
(1)
Octet 1 1 1 16 16 2 2 3
s:
Figure 9-273—Frame Classifier field of Classifier Type 1 for traffic over IPv6
The DSCP field contains the value in the 6 LSBs, and the 2 MSBs are set to 0. The 2 MSBs of the DSCP
field are ignored for frame classification.
The value in the Version subfield is the value specified in IETF RFC 791 or IETF RFC 2460.
For Classifier Type 2, the Classifier Parameter is the IEEE 802.1Q-2003 VLAN Tag TCI. The endianness of
the IEEE 802.1Q VLAN TCI field is as defined in IEEE Std 802.1Q for the VLAN Tag TCI. The Frame
Classifier field for Classifier Type 2 is defined in Figure 9-274.
Classifier Type 802.1Q VLAN
(2) Classifier Mask TCI
Octets: 1 1 2
Figure 9-274—Frame Classifier field of Classifier Type 2
For Classifier Type 3, the classifier parameters are defined by a Filter Offset subfield, a Filter Value subfield
and a Filter Mask subfield. The Frame Classifier subfield of Classifier Type 3 is defined in Figure 9-275. It
has a variable length.
909
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Classifier Type
(3) Classifier Mask Filter Offset Filter Value Filter Mask
Octets: 1 1 2 variable variable
Figure 9-275—Frame Classifier field of Classifier Type 3
The Classifier Mask subfield is reserved.
The value of the Filter Offset subfield is the number of octets from the beginning of the MSDU or MMPDU
at which the Filter Value is compared.
The length of the Filter Value and Filter Mask subfields is (Length – 5)/2, where Length is the value in the
Length field of the TCLAS element.
The Filter Value subfield is an octet string that is compared to the MSDU or MMPDU content, beginning at
the octet indicated by the Filter Offset.
The Filter Mask subfield is an octet string that is used to indicate which bits in the Filter Value subfield are
compared. The length of the Filter Mask subfield is equal to the length of the Filter Value subfield. A bit in
the Filter Value subfield is compared only if the matching bit in the Filter Mask subfield is 1.
For Classifier Type 4, frame classifier is defined for both IPv4 and IPv6, shown in Figure 9-276 (with the
Classifier Type subfield set to 4) and Figure 9-277, and distinguished by the Version subfield. The classifier
parameters represent corresponding values in a received IPv4 or IPv6 frame and are defined in Table 9-148.
The subfields in the classifier parameters are represented and transmitted in big-endian format.
Table 9-148—Classifier parameters for Classifier Type 4
Included in IPv4 field length Included in IPv6 field length
Subfield
IPv4 (octets) IPv6 (octets)
Version Yes 1 Yes 1
Source IP Address Yes 4 Yes 16
Destination IP Address Yes 4 Yes 16
Source Port Yes 2 Yes 2
Destination Port Yes 2 Yes 2
DSCP Yes 1 Yes 1
Protocol Yes 1 No n/a
Next Header No n/a Yes 1
Flow Label No n/a Yes 3
910
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Frame Classifier subfield of Classifier Type 4 for traffic over IPv4 is shown in Figure 9-276.
Classifier Type Classifier Mask Version(4) Source IP Destination IP
(4) Address Address
Octets: 1 1 1 4 4
Source Port Destination Port DSCP Protocol Reserved
Octets: 2 2 1 1 1
Figure 9-276—Frame Classifier subfield of Classifier Type 4 for traffic over IPv4
The Frame Classifier subfield of Classifier Type 4 for traffic over IPv6 is shown in Figure 9-277.
Classifier Type Classifier Mask Version(6) Source IP Destination IP
(4) Address Address
Octets: 1 1 1 16 16
Source Port Destination Port DSCP Next Header Flow Label
Octets: 2 2 1 1 3
Figure 9-277—Frame Classifier subfield of Classifier Type 4 for traffic over IPv6
NOTE—Frame classification when extension headers are used is supported only if the TCLAS does not classify on ports
(Classifier Mask has the Source and Destination Port bits set to 0).
The value in the Version subfield is the value specified in IETF RFC 791 or IETF RFC 2460.
The DSCP subfield contains the value as described in IETF RFC 2474 in the 6 least significant bits. The 2
most significant bits are reserved.
The Next Header subfield contains the next encapsulated protocol and is compatible with the values
specified for the IPv4 Protocol subfield. In the presence of options in the IPv6 header, the Next Header
subfield specifies the presence of one or more out of six extension headers as defined in IETF RFC 2460.
The Flow Label subfield contains the value in the 20 least significant bits. The 4 most significant bits are
reserved.
NOTE—For example, the flow label 0x12345 is represented as the octet sequence 0x01, 0x23, 0x45.
A TCLAS element is valid when the Classifier Mask Version bit is 1.
For Classifier Type 5 when used to match an IEEE 802.1D-2004 frame [B23], the classifier parameter is
only the User Priority, and the DEI and VID parameters are ignored. For Classifier Type 5 when used to
match an IEEE 802.1Q frame, the classifier parameters are: Priority Code Point, Drop Eligibility Indicator
(DEI), and VLAN ID (VID).
911
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Frame Classifier field for Classifier Type 5 is defined in Figure 9-278.
Classifier Type 802.1D UP/
Classifier Mask 802.1Q Priority 802.1Q DEI 802.1Q VID
(5) Code Point
Octets: 1 1 1 1 2
Figure 9-278—Frame Classifier field of Classifier Type 5
The subfields in the classifier parameters are represented and transmitted in big-endian format.
The 802.1D UP/802.1Q Priority Code Point subfield contains the value to be matched to the appropriate
type frame header in the 4 LSBs; the 4 MSBs are reserved.
The 802.1Q DEI subfield contains the value to match against an IEEE 802.1Q frame header, in the LSB; the
7 MSBs are reserved. When matching an IEEE 802.1D-2004 frame header, this subfield is ignored.
The 802.1Q VID subfield contains the value to match against an IEEE 802.1Q frame header, in the 12 LSBs;
the 4 MSBs are reserved. When matching an IEEE 802.1D-2004 frame header, this subfield is ignored.
For Classifier Type 6, the format of the Frame Classifier field of an TCLAS element is illustrated in
Figure 9-279.
Classifier Classifier Frame Control Duration Match Address 1 Match Address 2 Match
Match
Type (6) Mask Specification Specification Specification Specification
Octets: 1 3 0 or 2 or 4 0 or 2 or 4 0 or 6 or 12 0 or 6 or 12
Address 3 Match Sequence Control Address 4 QoS Control HT Control
Specification Specification Specification Specification Specification
0 or 6 or 12 0 or 2 or 4 0 or 6 or 12 0 or 2 or 4 0 or 4 or 8
Figure 9-279—Frame Classifier field of Classifier Type 6
For Classifier Type 6, the formats of the Frame Control Match Specification subfield, Duration/ID Match
Specification subfield, Address 1 Match Specification subfield, Address 2 Match Specification subfield,
Address 3 Match Specification subfield, Sequence Control Match Specification subfield, Address 4 Match
Specification subfield, QoS Control Match Specification subfield and HT Control Match Specification
subfield of the Frame Classifier field of a TCLAS element are shown in Figure 9-280, Figure 9-281,
Figure 9-282, Figure 9-283, Figure 9-284, Figure 9-285, Figure 9-286, Figure 9-287, and Figure 9-288,
respectively. The Match Specification subfield contains the match specification (i.e., the parameters) of the
corresponding MAC header field with which an MPDU is compared. When the corresponding Filter Mask is
not present, every bit in a Match Specification is compared; otherwise, only the bits with the same bit
positions as the bits that are equal to 1 in the corresponding Filter Mask subfield are compared.
Frame Control Match
Frame Control Filter Mask
Specification
Octets: 2 0 or 2
Figure 9-280—Frame Control Match Specification subfield of Classifier Type 6
912
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Duration/ID Match
Specification Duration/ID Filter Mask
Octets: 2 0 or 2
Figure 9-281—Duration/ID Match Specification subfield of Classifier Type 6
Address 1 Match Specification Address 1 Filter Mask
Octets: 6 0 or 6
Figure 9-282—Address 1 Match Specification subfield of Classifier Type 6
Address 2 Match Specification Address 2 Filter Mask
Octets: 6 0 or 6
Figure 9-283—Address 2 Match Specification subfield of Classifier Type 6
Address 3 Match Specification Address 3 Filter Mask
Octets: 6 0 or 6
Figure 9-284—Address 3 Match Specification subfield of Classifier Type 6
Sequence Control Match
Sequence Control Filter Mask
Specification
Octets: 2 0 or 2
Figure 9-285—Sequence Control Match Specification subfield of Classifier Type 6
Address 4 Match Specification Address 4 Filter Mask
Octets: 6 0 or 6
Figure 9-286—Address 4 Match Specification subfield of Classifier Type 6
QoS Control Match QoS Control Filter Mask
Specification
Octets: 2 0 or 2
Figure 9-287—QoS Control Match Specification subfield of Classifier Type 6
913
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
HT Control Match
Specification HT Control Filter Mask
Octets: 4 0 or 4
Figure 9-288—HT Control Match Specification subfield of Classifier Type 6
9.4.2.32 TS Delay element
The TS Delay element is used in an ADDTS Response frame transmitted by an HC and indicates the time
after which the ADDTS can be retried; see 11.4.7. The TS Delay element is defined in Figure 9-289.
Element ID Length Delay
(4)
Octets: 1 1 4
Figure 9-289—TS Delay element
The Element ID and Length fields are defined in 9.4.2.1.
The Delay field is 4 octets long and specifies the amount of time, in TUs, a STA should wait before it
reinitiates setup of a TS.
The Delay field is set to 0 when an AP does not expect to serve any TSPECs for an indeterminate time and
does not know this time a priori.
9.4.2.33 TCLAS Processing element
The TCLAS Processing element is present in ADDTS Request, ADDTS Response, FMS Request, FMS
Response, DMS Request, DMS Response, TFS Request and SCS Descriptor frames if there are multiple
TCLAS elements associated with the request, response or descriptor. It is optionally present in the ADDTS
Request and ADDTS Response frames if there are no TCLAS elements. Together with the TCLAS
element(s), if present, it indicates how a PDU or MSDU should be processed by the classifier. The TCLAS
Processing element is defined in Figure 9-290.
Length
Element ID Processing
(1)
Octets: 1 1 1
Figure 9-290—TCLAS Processing element
The Element ID and Length fields are defined in 9.4.2.1.
The Processing subfield is 1 octet long. The encoding of the Processing subfield is shown in Table 9-149.
914
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-149—Encoding of Processing subfield
Processing
Meaning
subfield value
0 PDU contents or MSDU parameters have to match to the parameters in all of the associated
TCLAS elements.
1 PDU contents or MSDU parameters have to match to at least one of the associated TCLAS
elements.
2 PDUs or MSDUs that do not belong to any other TS are classified to the TS for which this TCLAS
Processing element is used. In this case, there are no associated TCLAS elements.
3–255 Reserved
9.4.2.34 Schedule element
The Schedule element is transmitted by the HC to a STA to announce the schedule that the HC/AP follows
for admitted streams originating from or destined to that STA, or GCR-SP streams destined to that STA, in
the future. The information in this element might be used by the STA for power management, internal
scheduling, or any other purpose. The element information format is shown in Figure 9-291.
Length Service Start Service Specification
Element ID (12) Schedule Info Time Interval Interval
Octets: 1 1 2 4 4 2
Figure 9-291—Schedule element
The Element ID and Length fields are defined in 9.4.2.1.
The Schedule Info field is shown in Figure 9-292.
B0 B1 B4 B5 B6 B7 B15
Aggregation TSID Direction Reserved
Bits: 1 4 2 9
Figure 9-292—Schedule Info field
The Aggregation subfield is set to 1 if the schedule is an aggregate schedule for all TSIDs associated with
the STA to which the frame is directed. It is set to 0 otherwise. The TSID subfield contains a value allowed
for a TSID, as defined in 9.2.4.5.2, and indicates the TSID for which this schedule applies. The TSID
subfield is reserved when the Schedule element is included within a GCR Response subelement. The
Direction subfield is as defined in 9.4.2.30 and defines the direction of the TSPEC associated with the
schedule. In a Schedule element sent within a GCR Response subelement, the Direction subfield is set to
“Downlink.” The TSID and Direction subfields are valid only when the Aggregation subfield is 0. If the
Aggregation subfield is 1, the TSID and Direction subfields are reserved.
The Service Start Time field is 4 octets and indicates the anticipated time, expressed in microseconds, when
service starts and represents the lower order 4 octets of the TSF timer value at the start of the first SP. The
AP uses this field to confirm or modify the service start time indicated in the TSPEC request.
The Service Interval field is 4 octets and indicates the time, expressed in microseconds, between two
successive SPs and represents the measured time from the start of one SP to the start of the next SP. If the
915
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Schedule element is included within a GCR Response subelement that has the GCR delivery method equal
to GCR-SP, a value of 0 in the Service Interval field indicates the delivery method is GCR-A.
The Specification Interval field is 2 octets long and contains an unsigned integer that specifies the time
interval, in TUs, to verify schedule compliance.
The HC can set the Service Start Time field and the Service Interval field to 0 (unspecified) for
nonpowersaving STAs, except when the Schedule element is included within a GCR Response subelement
that has the GCR delivery method equal to GCR-SP (see 11.24.16.3.8). When the Schedule element is
included within a GCR Response subelement that has the GCR delivery method equal to GCR-SP, the
Service Start Time field is not set to 0 and the Service Interval field might be set to 0.
9.4.2.35 QoS Capability element
The QoS Capability element contains a number of subfields that are used to advertise optional QoS
capabilities at a QoS STA. The QoS Capability element is present in Beacon frames that do not contain the
EDCA Parameter Set element and in (Re)Association Request frames. The QoS Capability element is
defined in Figure 9-293.
Element ID Length QoS Info
(1)
Octets: 1 1 1
Figure 9-293—QoS Capability element format
The Element ID and Length fields are defined in 9.4.2.1.
The QoS Info field is 1 octet in length and is defined in 9.4.1.17.
9.4.2.36 AP Channel Report element
The AP Channel Report element contains a list of channels where a STA is likely to find an AP. The format
of the AP Channel Report element is shown in Figure 9-294. See 11.11.18 for details.
Operating
Element ID Length Channel List
Class
Octets: 1 1 1 variable
Figure 9-294—AP Channel Report element format
The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 1 (based
on a minimum length for the channel list field of 0 octets).
Operating Class contains an enumerated value from Annex E, specifying the operating class in which the
Channel List is valid. An AP Channel Report only reports channels for a single operating class. Multiple AP
Channel Report elements are present when reporting channels in more than one operating class.
The Channel List contains a variable number of octets, where each octet describes a single channel number.
Channel numbering is dependent on Operating Class according to Annex E.
9.4.2.37 Neighbor Report element
The format of the Neighbor Report element is shown in Figure 9-295.
916
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Element BSSID Operating Channel PHY Optional
ID Length BSSID Information Class Number Type Subelements
Octets: 1 1 6 4 1 1 1 variable
Figure 9-295—Neighbor Report element format
The Element ID and Length fields are defined in 9.4.2.1.
Each Report element describes an AP and consists of BSSID, BSSID Information, Channel Number,
Operating Class, PHY Type, and optionally includes optional subelements. The minimum value of the
Length field is 13 (i.e., with no optional subelements in the Neighbor Report element).
The BSSID is the BSSID of the BSS being reported. The subsequent fields in the Neighbor Report element
pertain to this BSS.
The BSSID Information field can be used to help determine neighbor service set transition candidates. It is
4 octets in length and contains the subfields as shown in Figure 9-296.
B0 B1 B2 B3 B4 B9 B10 B11 B12 B13 B14 B31
AP Mobility High Very High
Security Key Scope Capabilities FTM Reserved
Reachability Domain Throughput Throughput
Bits: 2 1 1 6 1 1 1 1 18
Figure 9-296—BSSID Information field
The AP Reachability field indicates whether the AP identified by this BSSID is reachable by the STA that
requested the neighbor report. For example, the AP identified by this BSSID is reachable for the exchange of
preauthentication frames as described in 12.6.10.2. The values are shown in Table 9-150.
Table 9-150—Reachability field
Value Reachability Usage
0 Reserved Not used.
1 Not Reachable A station sending a preauthentication frame to the BSSID will not receive
a response even if the AP indicated by the BSSID is capable of
preauthentication.
2 Unknown The AP is unable to determine if the value Reachable or Not Reachable is
to be returned.
3 Reachable The station sending a preauthentication frame to the BSSID can receive a
response from an AP that is capable of preauthentication.
The Security bit, if 1, indicates that the AP identified by this BSSID supports the same security provisioning
as used by the STA in its current association. If the bit is 0, it indicates either that the AP does not support
the same security provisioning or that the security information is not available at this time.
The Key Scope bit, when set, indicates the AP indicated by this BSSID has the same authenticator as the AP
sending the report. If this bit is 0, it indicates a distinct authenticator or the information is not available.
917
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Capabilities subfield contains selected capability information for the AP indicated by this BSSID. The
bit fields within this subfield have the same meaning and are set to the equivalent bits within the Capability
Information field (see 9.4.1.4) being sent in the beacons by the AP being reported. The format of the
Capabilities subfield is as in Figure 9-297.
B4 B5 B6 B7 B8 B9
Spectrum QoS APSD Radio Measurement Delayed Block Immediate Block
Management Ack Ack
Bits: 1 1 1 1 1 1
Figure 9-297—Capabilities subfield
The Mobility Domain bit is set to 1 to indicate that the AP represented by this BSSID is including an MDE
in its Beacon frames and that the contents of that MDE are identical to the MDE advertised by the AP send-
ing the report.
The High Throughput bit is set to 1 to indicate that the AP represented by this BSSID is an HT AP including
the HT Capabilities element in its Beacons, and that the contents of that HT Capabilities element are identi-
cal to the HT Capabilities element advertised by the AP sending the report.
The Very High Throughput bit is set to 1 to indicate that the AP represented by this BSSID is a VHT AP and
that the VHT Capabilities element, if included as a subelement in the report, is identical in content to the
VHT Capabilities element included in the AP’s Beacon.
The FTM field is set to 1 to indicate that the AP represented by this BSSID is an AP that has set the Fine
Timing Measurement Responder field of the Extended Capabilities element to 1. The FTM field is set to 0 to
indicate either that the reporting AP has dot11FineTimingMsmtRespActivated equal to false, or the reported
AP has not set the Fine Timing Measurement Responder field of the Extended Capabilities element to 1 or
that the Fine Timing Measurement Responder field of the reported AP is not available to the reporting AP at
this time.
Bits 14–31 are reserved.
The Operating Class field indicates the channel set of the AP indicated by this BSSID. The Country,
Operating Class, and Channel Number fields together specify the channel frequency and spacing for the
channel on which the Beacon frames are being transmitted for the BSS being reported. Valid operating
classes are listed in Annex E.
The Channel Number field indicates the last known primary channel of the AP indicated by this BSSID.
Channel number is defined within an operating class as shown in Annex E.
The PHY Type field indicates the PHY type of the AP indicated by this BSSID. It is an integer value coded
according to the value of the dot11PHYType.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-151.
918
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-151—Optional subelement IDs for Neighbor report
Subelement ID Name Extensible
0 Reserved
1 TSF Information Yes
2 Condensed Country String Yes
3 BSS Transition Candidate Preference
4 BSS Termination Duration
5 Bearing
6 Wide Bandwidth Channel Yes
7–38 Reserved
39 Measurement Report Subelements
40–44 Reserved
45 HT Capabilities subelement Yes
46–60 Reserved
61 HT Operation subelement Yes
62 Secondary Channel Offset subelement
63–65 Reserved
66 Measurement Pilot Transmission Subelements
67–69 Reserved
70 RM Enabled Capabilities Yes
71 Multiple BSSID Subelements
72–190 Reserved
191 VHT Capabilities Yes
192 VHT Operation Yes
193–220 Reserved
221 Vendor Specific
222–255 Reserved
The TSF subelement contains TSF Offset and Beacon Interval subfields as shown in Figure 9-298.
Subelement ID Length TSF Offset Beacon Interval
Octets: 1 1 2 2
Figure 9-298—TSF subelement format
The Length field is defined in 9.4.3.
The TSF Offset subfield is 2 octets long and contains the neighbor AP’s TSF timer offset. This is the time
difference, in TU units, between the serving AP and a neighbor AP. This offset is given modulo the neighbor
AP’s Beacon Interval and rounded to the nearest TU boundary.
919
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Beacon Interval field is the beacon interval of the Neighbor AP indicated by this BSSID. This field is
defined in 9.4.1.3 and illustrated in Figure 9-67.
The Condensed Country String subelement is set to the first two octets of the value contained in
dot11CountryString. This subelement is present only if the country of the neighbor AP indicated by the
BSSID differs from the country of the AP that sent this neighbor report.
The Measurement Pilot Transmission subelement has the same format as the Measurement Pilot
Transmission element (see 9.4.2.42). The Measurement Pilot Interval subelement is not included if the
reported AP is not transmitting Measurement Pilot frames or if the Measurement Pilot Interval of the
reported AP is unknown.
A Measurement Report subelement with the Measurement Type field equal to LCI (see Table 9-107) is
optionally present. If present, the subelement has the same format as the Measurement Report element with
Measurement Type field equal to LCI.The subelement indicates the LCI of the neighbor STA and further
includes the Z subelement, or the subelement indicates an unknown LCI (see 11.24.6.7). The Late, Incapable
and Refused bits in the Measurement Report Mode field are set to 0. The Co-Located BSSID List
subelement is present in the Measurement Report subelement of the Neighbor Report element, when there is
at least one other BSS which is co-located with the reporting BSS.
A Measurement Report subelement with the Measurement Type field equal to Location Civic (see Table 9-
107) is optionally present. If present, the subelement has the same format as the Measurement Report
element with Measurement Type field equal to Location Civic, and the subelement indicates the civic
address of the transmitting STA or an unknown civic address (see 11.24.6.7). The Late, Incapable and
Refused bits in the Measurement Report Mode field are set to 0. The Co-Located BSSID List subelement is
present in the Measurement Report subelement of the Neighbor Report element, when there is at least one
other BSS which is co-located with the reporting BSS. When a Measurement Report subelement with
Measurement Type field equal to LCI that includes a Co-Located BSSID List subelement is present, the Co-
Located BSSID List subelement is not present in the Measurement Report subelement with Measurement
Type field equal to Location Civic.
The HT Capabilities subelement is the same as the HT Capabilities element as defined in 9.4.2.56.
The HT Operation subelement is the same as the HT Operation element as defined in 9.4.2.57.
The Secondary Channel Offset subelement is the same as the Secondary Channel Offset element as defined
in 9.4.2.20.
The RM Enabled Capabilities subelement has the same format as the RM Enabled Capabilities element (see
9.4.2.45).
The Multiple BSSID subelement has the same format as the Multiple BSSID element (see 9.4.2.46). The
reference BSSID for the Multiple BSSID subelement is the BSSID field in the Neighbor Report element.
This subelement is not present if the neighbor AP is not a member of a multiple BSSID set with two or more
members or its membership is unknown. (see 11.11.14).
The format of the BSS Transition Candidate Preference subelement is shown in Figure 9-299.
Subelement ID Length Preference
Octets: 1 1 1
Figure 9-299— BSS Transition Candidate Preference subelement format
920
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Length field is defined in 9.4.3.
The Preference field indicates the network preference for BSS transition to the BSS listed in this BSS
Transition Candidate List Entries field in the BSS Transition Management Request frame, BSS Transition
Management Query frame, and BSS Transition Management Response frame. The Preference field value is
a number ranging from 0 to 255, as defined in Table 9-152, indicating an ordering of preferences for the
BSS transition candidates for this STA. Additional details describing use of the Preference field are
provided in 11.24.7.
Table 9-152—Preference field values
Preference field value Description
0 Excluded BSS; reserved when present in the BSS Transition Management
Query or BSS Transition Management Response frames.
1–255 Relative values used to indicate the preferred ordering of BSSs, with 255
indicating the most preferred candidate and 1 indicating the least preferred
candidate.
The BSS Termination TSF field contained in the BSS Termination Duration subelement is the TSF time of
the BSS transmitting the neighbor report that corresponds to the time when termination of the neighbor BSS
occurs. How the BSS determines the neighbor BSS termination time is out of scope of the standard. The
format of the BSS Termination Duration subelement is shown in Figure 9-300.
BSS
Subelement ID Length Duration
Termination TSF
Octets: 1 1 8 2
Figure 9-300—BSS Termination Duration subelement format
The Length field is defined in 9.4.3.
The BSS Termination TSF field indicates the value of the TSF timer when BSS termination will occur in the
future. A BSS Termination TSF field value of 0 indicates that termination of the BSS will occur imminently.
Prior to termination of the BSS, all associated STAs are disassociated by the AP.
The Duration field is an unsigned 2-octet integer that indicates the number of minutes for which the BSS is
not present. The Duration field value of 0 is reserved. The Duration field value is 65 535 when the BSS is
terminated for a period longer than or equal to 65 535 minutes.
The format of the Bearing subelement is shown in Figure 9-301.
Subelement ID Length Bearing Distance Relative Height
Octets: 1 1 2 4 2
Figure 9-301—Bearing subelement format
The Length field is defined in 9.4.3.
921
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Bearing field specifies the direction that the neighbor, specified by the BSSID field in the Neighbor
Report element, is positioned, relative to the reporting BSS and defined in relation to true north, increasing
clockwise, measured in degrees from 0° to 359°. If the Bearing value is unknown, the subelement is not
included.
The Distance field specifies the distance that the neighbor, specified by the BSSID field in the Neighbor
Report element, is positioned relative to the reporting BSS as a 4-octet single precision floating point value
represented by a binary32 floating point value as defined in IEEE Std 754-2008, with the least significant bit
of the fraction occurring in bit 0 of the field, in meters. If the Distance field value is unknown the field is set
to 0.
The Relative Height field, defined by a 2-octet signed integer, specifies the relative height in meters that the
neighbor is positioned, relative to the reporting BSS. If the Relative height is unknown or at the same height
as the reporting BSS, the field is 0.
The format of the Wide Bandwidth Channel subelement is shown in Figure 9-302.
Channel Center Channel Center
Subelement ID Length Channel Width Frequency Frequency
Segment 0 Segment 1
Octets: 1 1 1 1 1
Figure 9-302—Wide Bandwidth Channel subelement format
The Length field is defined in 9.4.3.
The Channel Width, Channel Center Frequency Segment 0, and Channel Center Frequency Segment 1
subfields are defined in Table 9-153.
Table 9-153—HT/VHT Operation Information subfields
Field Definition Encoding
Channel This field defines the BSS Set to 0 for 20 MHz BSS bandwidth.
Width bandwidth (see 11.40.1). Set to 1 for 40 MHz BSS bandwidth.
Set to 2 for 80 MHz BSS bandwidth.
Set to 3 for 160 MHz BSS bandwidth.
Set to 4 for 80+80 MHz operating channel width.
Values in the range 5 to 255 are reserved.
Channel Defines the channel center For 20, 40, 80, or 160 MHz BSS bandwidth,
Center frequency for an HT or VHT BSS indicates the channel center frequency index for the
Frequency or the frequency segment 0 channel channel on which the HT or VHT BSS operates.
Segment 0 center frequency for an 80+80 MHz
VHT BSS. See 21.3.14. For 80+80 MHz BSS bandwidth, indicates the
channel center frequency index for the 80 MHz
channel of frequency segment 0 on which the VHT
BSS operates.
Channel Defines the frequency segment 1 For an 80+80 MHz BSS bandwidth, indicates the
Center channel center frequency for an channel center frequency index of the 80 MHz
Frequency 80+80 MHz VHT BSS. See channel of frequency segment 1 on which the VHT
Segment 1 21.3.14. BSS operates. The channel center frequency index
of segment 1 differs by more than 16 from the
channel center frequency index of segment 0 (i.e.,
the channel center frequencies are more than 80
MHz apart). Reserved otherwise.
922
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The VHT Capabilities subelement is the same as the VHT Capabilities element as defined in 9.4.2.158.
The VHT Operation subelement is the same as the VHT Operation element as defined in 9.4.2.159.
The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.38 RCPI element
The RCPI element indicates the received frame power level at the receiving STA as shown in Figure 9-303.
Element ID Length RCPI
Octets: 1 1 1
Figure 9-303—RCPI element format
The Element ID and Length fields are defined in 9.4.2.1.
The RCPI field contains an RCPI value, which is an indication of the received RF power in the selected
channel for a received frame.
RCPI is a monotonically increasing, logarithmic function of the received power level. The allowed values
for the RCPI field are defined in Table 9-154, where P is the received power level in dBm.
Table 9-154—RCPI values
RCPI Value Description
0 Represents P < –109.5 dBm
1–219 Power levels in the range – 109.5 P 0 are represented by RCPI = 2 P + 110
220 Represents P 0 dBm
221–254 Reserved
255 Measurement not available
9.4.2.39 BSS Average Access Delay element
The BSS Average Access Delay element contains the AP Average Access Delay, which is a measure of load
in the BSS and is available in both QoS APs and non-QoS APs. The format of the BSS Average Access
Delay element is defined in Figure 9-304.
AP Average
Element ID Length
Access Delay
Octets: 1 1 1
Figure 9-304—BSS Average Access Delay element format
The Element ID and Length fields are defined in 9.4.2.1.
923
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The AP Average Access Delay is a scalar indication of the relative level of loading at an AP. A low value
indicates more available capacity than a higher value. If the AP is not currently transmitting any DCF or
EDCAF traffic, the AP Average Access Delay is set to 255. The values between 1 and 252 are a scaled
representation of the average medium access delay for all DCF and EDCAF transmitted frames measured
from the time the DCF or EDCAF MPDU is ready for transmission (i.e., begins CSMA/CA access) until the
actual frame transmission start time. Non-QoS APs average the access delays for all DCF transmitted
frames. QoS APs average the access delays for all EDCA transmitted frames of all ACs. The AP Average
Access Delay values are scaled as follows:
0: Access Delay < 8 µs
1: 8 µs Access Delay < 16 µs
2 n 14: n 8 µs Access Delay < (n + 1) 8 µs
15: 120 µs Access Delay < 128 µs
16: 128 µs Access Delay < 144 µs
17 n 106: (n 16) – 128 µs Access Delay < ((n + 1) 16) – 128 µs
107: 1 584 µs Access Delay < 1 600 µs
108: 1 600 µs Access Delay < 1 632 µs
109 n 246: (n 32) – 1 856 µs Access Delay < ((n + 1) 32) – 1 856 µs
247: 6 048 µs Access Delay < 6 080 µs
248: 6 080 µs Access Delay < 8 192 µs
249: 8 192 µs Access Delay < 12 288 µs
250: 12 288 µs Access Delay < 16 384 µs
251: 16 384 µs Access Delay < 20 480 µs
252: 20 480 µs Access Delay < 24 576 µs
253: 24 576 µs Access Delay
254: Service unable to access channel
255: Measurement not available
The values 0–253 indicate Average Access Delay when one or more frames were transmitted during the
measurement window. The value 254 indicates that the DCF is or the EDCAFs are currently unable to
access the channel due to continuous carrier sense mechanism deferral and that no frames were transmitted
during the measurement window. The AP measures and averages the medium access delay for all transmit
frames using the DCF or the EDCAFs over a continuous 30 s measurement window. See 11.11.16 for
accuracy requirements.
9.4.2.40 Antenna element
The Antenna element contains the Antenna ID field as shown in Figure 9-305.
924
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Element ID Length Antenna ID
Octets: 1 1 1
Figure 9-305—Antenna element format
The Element ID and Length fields are defined in 9.4.2.1.
The Antenna ID field contains the identifying number for the relevant antenna(s). The Antenna ID identifies
the antenna(s) used to transmit the frame the Antenna element is contained in. A specific antenna has an
Antenna ID between 1 and 254. The value 0 indicates that the antenna identifier is unknown. The value 255
indicates that this transmission was made with multiple antennas, i.e., antennas were switched during the
transmission. If during frame reception, different antennas are used to receive the preamble and body, the
antenna ID identifies the antenna that receives the frame body. In these cases, the value 255 is not used. The
value 1 is the only value used for a STA with only one antenna. STAs with more than one antenna assign
Antenna IDs to each antenna and each antenna configuration as consecutive, positive integers starting with
1. Each Antenna ID number represents a unique antenna or unique configuration of multiple antennas
characterized by a fixed relative position, a fixed relative direction, and a fixed peak gain for that position
and direction.
9.4.2.41 RSNI element
The RSNI element contains an RSNI value, as shown in Figure 9-306.
Element ID Length RSNI
Octets: 1 1 1
Figure 9-306—RSNI element format
The Element ID and Length fields are defined in 9.4.2.1.
RSNI is in steps of 0.5 dB. RSNI is calculated by the ratio of the received signal power (RCPI-ANPI) to the
noise plus interference power (ANPI) using the expression:
RSNI = (10 log10((RCPIpower – ANPIpower) / ANPIpower)+10) 2
where RCPIpower and ANPIpower indicate power domain values for RCPI and ANPI and not dB domain
values. RSNI in dB is scaled in steps of 0.5 dB to obtain 8-bit RSNI values, which cover the range from
–10 dB to +117 dB. The value 255 indicates that RSNI is not available. See 11.11.9.4 for details and
procedures for measuring ANPI.
9.4.2.42 Measurement Pilot Transmission element
The Measurement Pilot Transmission element contains a Measurement Pilot Transmission field as shown in
Figure 9-307.
Measurement Pilot Optional
Element ID Length
Transmission Subelements
Octets: 1 1 1 variable
Figure 9-307—Measurement Pilot Transmission element format
925
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID field is equal to the Measurement Pilot Transmission value in Table 9-77.
The Element ID and Length fields are defined in 9.4.2.1.
The Measurement Pilot Transmission field contains the Measurement Pilot Interval as specified in 9.4.1.18.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-155.
Table 9-155—Optional subelement IDs for Measurement Pilot Transmission
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
9.4.2.43 BSS Available Admission Capacity element
The BSS Available Admission Capacity element contains a list of Available Admission Capacity fields at
different User Priorities and Access Categories as shown in Figure 9-308.
NOTE—The BSS Available Admission Capacity element is helpful for roaming QoS STAs to select a QoS AP that is
likely to accept future admission control requests, but it does not provide an assurance that the HC will admit these
requests.
Element Available Admission Available Admission
ID Length Capacity Bitmask Capacity List
Octets: 1 1 2 2 × (total number of
nonzero bits in
Available Admission
Capacity Bitmask)
Figure 9-308—BSS Available Admission Capacity element format
The Element ID and Length fields are defined in 9.4.2.1. The Length field is set to 2 + 2Nnz, where Nnz
equals the total number of nonzero bits in Available Admission Capacity Bitmask.
The Available Admission Capacity Bitmask field indicates the UP values that have an Available Admission
Capacity specified in the Available Admission Capacity List field. The format of the Available Admission
Capacity Bitmask is defined in Table 9-156.
Each bit in the Available Admission Capacity Bitmask is set to 1 to indicate that the Available Admission
Capacity for the corresponding traffic type is present in the Available Admission Capacity List field. The bit
is set to 0 to indicate that the Available Admission Capacity for the corresponding traffic type is not present
in the Available Admission Capacity List field.
926
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-156—Available Admission Capacity Bitmask definition
Bit Available Admission Capacity Reported
0 UP 0
1 UP 1
2 UP 2
3 UP 3
4 UP 4
5 UP 5
6 UP 6
7 UP 7
8 AC 0
9 AC 1
10 AC 2
11 AC 3
12–15 Reserved
The Available Admission Capacity List comprises a sequence of Available Admission Capacity fields
corresponding respectively to the nonzero bits in the Available Admission Capacity Bitmask field.
The Available Admission Capacity field is 2 octets long and contains an unsigned integer that specifies the
amount of medium time available using explicit admission control for the corresponding UP or AC traffic,
in units of 32 µs per 1 s. See 11.11.17 for furthers details.
9.4.2.44 BSS AC Access Delay element
The BSS AC Access Delay element contains an Access Category Access Delay field, as shown in
Figure 9-309.
Element Access Category
Length
ID Access Delay
Octets: 1 1 4
Figure 9-309—BSS AC Access Delay element format
The Element ID and Length fields are defined in 9.4.2.1.
The AC Access Delay field is formatted as four subfields as shown in Figure 9-310. The AC Access Delay is
a scalar indication of the average access delay at a QoS AP for services for each of the indicated access
categories. If the QoS AP is not currently transmitting any traffic using the indicated AC, the Average
Access Delay for that AC is set to 255. The values between 1 and 252 are a scaled representation of the
average medium access delay for transmitted frames in the indicated AC measured from the time the EDCA
MPDU is ready for transmission (i.e., begins CSMA/CA access) until the actual frame transmission start
time. The AC Access Delay values are scaled as follows:
927
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
0: Access Delay < 8 µs
1: 8 µs Access Delay < 16 µs
2 n 14: n 8 µs Access Delay < (n + 1) 8 µs
15: 120 µs Access Delay < 128 µs
16: 128 µs Access Delay < 144 µs
17 n 106: (n 16) – 128 µs Access Delay < ((n + 1) 16) – 128 µs
107: 1584 µs Access Delay < 1600 µs
108: 1600 µs Access Delay < 1632 µs
109 n 246: (n 32) – 1856 µs Access Delay < ((n + 1) 32) – 1856 µs
247: 6048 µs Access Delay < 6080 µs
248: 6080 µs Access Delay < 8192 µs
249: 8192 µs Access Delay < 12 288 µs
250: 12 288 µs Access Delay < 16 384 µs
251: 16 384 µs Access Delay < 20 480 µs
252: 20 480 µs Access Delay < 24 576 µs
253: 24 576 µs Access Delay
254: Service unable to access channel
255: Measurement not available
The values 0–253 indicate Average Access Delay when one or more frames were transmitted during the
measurement window. The value 254 indicates that the EDCAF is currently unable to access the channel
due to continuous carrier sense mechanism deferral to higher priority AC transmissions and that no frames
were transmitted during the measurement window. The QoS AP measures and averages the medium access
delay for all transmit frames of the indicated AC using EDCA mechanism over a continuous 30 s
measurement window. See 11.11.16 for accuracy requirements.
Average Access
Delay for Average Access Average Access Average Access
Delay for Background Delay for Video Delay for Voice
Best Effort (AC_BK) (AC_VI) (AC_VO)
(AC_BE)
Octets: 1 1 1 1
Figure 9-310—Access Category Access Delay subfields
928
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.45 RM Enabled Capabilities element
The RM Enabled Capabilities element signals support for radio measurements in a STA. The element is
shown in Figure 9-311.
Element Length RM Enabled
ID Capabilities
Octets: 1 1 5
Figure 9-311—RM Enabled Capabilities element format
The Element ID and Length fields are defined in 9.4.2.1.
The RM Enabled Capabilities field is an octet string. Each subfield of this field indicates whether the
corresponding capability listed in Table 9-157 is enabled.
Table 9-157—RM Enabled Capabilities definition
Bit position in the
RM Enabled Field name Notes
Capabilities field
0 Link Measurement A STA sets the Link Measurement Capability Enabled field to 1
Capability Enabled when dot11RMLinkMeasurementActivated is true and sets it to 0
otherwise.
1 Neighbor Report A STA sets the Neighbor Report Capability Enabled field to 1
Capability Enabled when dot11RMNeighborReportActivated is true and sets it to 0
otherwise.
2 Parallel Measurements A STA sets the Parallel Measurements Capability Enabled field to
Capability Enabled 1 when dot11RMParallelMeasurementsActivated is true and sets it
to 0 otherwise.
3 Repeated A STA sets the Repeated Measurements Capability Enabled field
Measurements to 1 when dot11RMRepeatedMeasurementsActivated is true and
Capability Enabled sets it to 0 otherwise.
4 Beacon Passive A STA sets the Beacon Passive Measurement Capability Enabled
Measurement field to 1 when dot11RMBeaconPassiveMeasurementActivated is
Capability Enabled true and sets it to 0 otherwise.
5 Beacon Active A STA sets the Beacon Active Measurement Capability Enabled
Measurement field to 1 when dot11RMBeaconActiveMeasurementActivated is
Capability Enabled true and sets it to 0 otherwise.
6 Beacon Table A STA sets the Beacon Table Measurement Capability Enabled
Measurement field to 1 when dot11RMBeaconTableMeasurementActivated is
Capability Enabled true and sets it to 0 otherwise.
7 Beacon Measurement A STA sets the Beacon Measurement Reporting Conditions
Reporting Conditions Capability Enabled field to 1 when
Capability Enabled dot11RMBeaconMeasurementReportingConditionsActivated is
true and sets it to 0 otherwise.
8 Frame Measurement A STA sets the Frame Measurement Capability Enabled field to 1
Capability Enabled when dot11RMFrameMeasurementActivated is true and sets it to
0 otherwise.
929
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-157—RM Enabled Capabilities definition (continued)
Bit position in the
RM Enabled Field name Notes
Capabilities field
9 Channel Load A STA sets the Channel Load Measurement Capability Enabled
Measurement field to 1 when dot11RMChannelLoadMeasurementActivated is
Capability Enabled true and sets it to 0 otherwise.
10 Noise Histogram A STA sets the Noise Histogram Measurement Capability Enabled
Measurement field to 1 when dot11RMNoiseHistogramMeasurementActivated
Capability Enabled is true and sets it to 0 otherwise.
11 Statistics Measurement A STA sets the Statistics Measurement Capability Enabled field to
Capability Enabled 1 when dot11RMStatisticsMeasurementActivated is true and sets
it to 0 otherwise.
12 LCI Measurement A STA sets the LCI Measurement Capability Enabled field to 1
Capability Enabled when dot11RMLCIMeasurementActivated is true and sets it to 0
otherwise.
13 LCI Azimuth A STA sets the LCI Azimuth Capability Enabled field to 1 when
Capability Enabled dot11RMLCIAzimuthActivated is true and sets it to 0 otherwise.
14 Transmit Stream/ A STA sets the Transmit Stream/Category Measurement
Category Measurement Capability Enabled field to 1 when
Capability Enabled dot11RMTransmitStreamCategoryMeasurementActivated is true
and sets it to 0 otherwise.
15 Triggered Transmit A STA sets the Triggered Transmit Stream/Category Measurement
Stream/Category Capability Enabled field to 1 when
Measurement dot11RMTriggeredTransmitStreamCategoryMeasurementActivate
Capability Enabled d is true and sets it to 0 otherwise.
16 AP Channel Report A STA sets the AP Channel Report Capability Enabled field to 1
Capability Enabled when dot11RMAPChannelReportActivated is true and sets it to 0
otherwise.
17 RM MIB Capability A STA sets the RM MIB Capability Enabled field to 1 when
Enabled dot11RMMIBActivated is true and sets it to 0 otherwise.
18–20 Operating Channel A STA sets the Operating Channel Max Measurement Duration
Max Measurement field to equal dot11RMMaxMeasurementDuration. See 11.11.4.
Duration
21–23 Nonoperating Channel A STA sets the Nonoperating Channel Max Measurement
Max Measurement Duration field to equal
Duration dot11RMNonOperatingChannelMaxMeasurementDuration. See
11.11.4.
24–26 Measurement Pilot A STA sets the Measurement Pilot Capability field to equal
Capability dot11RMMeasurementPilotActivated. See Table 11-10 in
11.11.15.
27 Measurement Pilot A STA sets the Measurement Pilot Transmission Capability
Transmission Enabled field to 1 when
Information Capability dot11RMMeasurementPilotTransmissionInformationActivated is
Enabled true and sets it to 0 otherwise.
28 Neighbor Report TSF A STA sets the Neighbor Report TSF Offset Capability Enabled
Offset Capability field to 1 when dot11RMNeighborReportTSFOffsetActivated is
Enabled true and sets it to 0 otherwise.
930
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-157—RM Enabled Capabilities definition (continued)
Bit position in the
RM Enabled Field name Notes
Capabilities field
29 RCPI Measurement A STA sets the RCPI Measurement Capability Enabled field to 1
Capability Enabled when dot11RMRCPIMeasurementActivated is true and sets it to 0
otherwise.
30 RSNI Measurement A STA sets the RSNI Measurement Capability Enabled field to 1
Capability Enabled when dot11RMRSNIMeasurementActivated is true and sets it to 0
otherwise.
31 BSS Average Access A STA sets the BSS Average Access Delay Capability Enabled
Delay Capability field to 1 when dot11RMBSSAverageAccessDelayActivated is
Enabled true and sets it to 0 otherwise (see NOTE).
32 BSS Available A STA sets the BSS Available Admission Capacity Capability
Admission Capacity Enabled field to 1 when
Capability Enabled dot11RMBSSAvailableAdmissionCapacityActivated is true and
sets it to 0 otherwise.
33 Antenna Capability A STA sets the Antenna Capability Enabled field to 1 when
Enabled dot11RMAntennaInformationActivated is true and sets it to 0
otherwise.
34 FTM Range Report A STA sets the FTM Range Report Capability Enabled field to 1
Capability Enabled when dot11RMFineTimingMsmtRangeRepActivated is true and
sets it to 0 otherwise.
35 Civic Location A STA sets the Civic Location Measurement Capability Enabled
Measurement field to 1 when dot11RMCivicMeasurementActivated is true and
Capability Enabled sets it to 0 otherwise.
36–39 Reserved
NOTE—At a QoS AP dot11RMBSSAverageAccessDelayActivated is true indicates that the AP BSS AC Access
Delay capability is also enabled.
9.4.2.46 Multiple BSSID element
The format of the Multiple BSSID element is shown in Figure 9-312.
MaxBSSID Optional
Element ID Length
Indicator Subelements
Octets: 1 1 1 variable
Figure 9-312—Multiple BSSID element format
The Element ID and Length fields are defined in 9.4.2.1.
The Max BSSID Indicator field contains a value assigned to n, where 2n is the maximum number of BSSIDs
in the multiple BSSID set, including the reference BSSID (see 11.11.14). The actual number of BSSIDs in
the multiple BSSID set is not explicitly signaled. The BSSID(i) value corresponding to the ith BSSID in the
multiple BSSID set is derived from a reference BSSID (REF_BSSID) as follows:
BSSID(i) = BSSID_A | BSSID_B
where
931
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
BSSID_A is a BSSID with (48–n) MSBs equal to the (48–n) MSBs of the REF_BSSID and n LSBs equal
to 0
BSSID_B is a BSSID with (48–n) MSBs equal to 0 and n LSBs equal to [(n LSBs of REF_BSSID) +i]
mod 2n
When the Multiple BSSID element is transmitted in a Beacon, DMG Beacon, or Probe Response frame, the
reference BSSID is the BSSID of the frame. More than one Multiple BSSID element can be included in a
Beacon or DMG Beacon frame. The AP or DMG STA determines the number of Multiple BSSID elements.
The AP or DMG STA does not fragment a nontransmitted BSSID profile subelement for a single BSSID
across two Multiple BSSID elements unless the length of the nontransmitted BSSID profile subelement
exceeds 255 octets. When the Multiple BSSID element is transmitted as a subelement in a Neighbor Report
element, the reference BSSID is the BSSID field in the Neighbor Report element.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-158.
Table 9-158—Optional subelement IDs for Multiple BSSID
Subelement ID Name Extensible
0 Nontransmitted BSSID Profile
1–220 Reserved
221 Vendor Specific
222–255 Reserved
The Nontransmitted BSSID Profile subelement contains a list of elements for one or more APs or DMG
STAs that have nontransmitted BSSIDs and is defined as follows:
— For each nontransmitted BSSID, the Nontransmitted BSSID Capability element (see 9.4.2.72) is the
first element included, followed by a variable number of elements, in the order defined in 9-27.
— The SSID and multiple BSSID-index subelements are included in the Nontransmitted BSSID Profile
subelement.
— The FMS Descriptor element is included in the Nontransmitted BSSID Profile subelement if the
Multiple BSSID element is included in a Beacon frame and if the TIM field indicates there are
buffered group addressed frames for this nontransmitted BSSID.
— The Timestamp and Beacon Interval fields, DSSS Parameter Set, IBSS Parameter Set, Country,
Channel Switch Announcement, Extended Channel Switch Announcement, Wide Bandwidth
Channel Switch, Transmit Power Envelope, Supported Operating Classes, IBSS DFS, ERP
Information, HT Capabilities, HT Operation, VHT Capabilities, and VHT Operation elements are
not included in the Nontransmitted BSSID Profile subelement; the values of these elements for each
nontransmitted BSSID are always the same as the corresponding transmitted BSSID element values.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of optional subelements.
The Multiple BSSID element is included in Beacon frames (as described in 9.3.3.3), in DMG Beacon frames
(as described in 9.3.4.2), and Probe Response frames (as described in 9.3.3.11). The use of the Multiple
BSSID element is described in 11.11.14. Nontransmitted BSSID advertisement procedures are described in
11.1.3.8.
932
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.47 Mobility Domain element (MDE)
The MDE contains the MDID (Mobility Domain Identifier) field and the FT Capability and Policy field. The
AP uses the MDE to advertise that it is included in the group of APs that constitute a mobility domain, to
advertise its support for FT capability, and to advertise its FT policy information. The format for this
element is given in Figure 9-313.
Element ID Length MDID FT Capability and
Policy
Octets: 1 1 2 1
Figure 9-313—Mobility Domain element format
The Element ID and Length fields are defined in 9.4.2.1.
The MDID field is a 2-octet value that follows the ordering conventions defined in 9.2.2.
The FT Capability and Policy field is 1 octet. The FT Capability and Policy field is defined in Figure 9-314.
B0 B1 B2 B7
Fast BSS Resource Request
Transition Reserved
over DS Protocol Capability
Bits: 1 1 6
Figure 9-314—FT Capability and Policy field
Bits 0–1 of the FT Capability and Policy field control the behavior of STAs performing fast BSS transitions
(see 13.3). The STA might use information from the MDE to determine the transition methods
recommended by the AP and protocols supported by the AP. The choice of executing any specific transition
method is outside the scope of this standard.
If the Resource Request Protocol Capability subfield is 1, then the STA might perform the FT resource
request protocol as described in 13.6.
When sent by a STA to a target AP, the FT Capability and Policy field matches the value advertised by that
target AP. See 13.8.
9.4.2.48 Fast BSS Transition element (FTE)
The FTE includes information needed to perform the FT authentication sequence during a fast BSS
transition in an RSN. This element is shown in Figure 9-315.
Element MIC Optional
ID Length Control MIC ANonce SNonce Parameter(s)
Octets: 1 1 2 16 32 32 variable
Figure 9-315—FTE format
The Element ID and Length fields are defined in 9.4.2.1.
933
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The MIC Control field is two octets and is defined in Figure 9-316.
B0 B7 B8 B15
Reserved Element Count
Bits: 8 8
Figure 9-316—MIC Control field
The Element Count subfield of the MIC Control field contains the number of elements that are included in
the message integrity code (MIC) calculation. A value of 0 indicates no MIC is present.
The MIC field contains a MIC that is calculated using the algorithm specified in 13.8.4 and 13.8.5.
The ANonce field contains a value chosen by the R1KH. It is encoded following the conventions in 9.2.2.
The SNonce field contains a value chosen by the S1KH. It is encoded following the conventions in 9.2.2.
The format of the Optional Parameter(s) field is shown in Figure 9-317.
Subelement ID Length Data
Octets: 1 1 variable
Figure 9-317—Optional Parameter(s) field
The Subelement ID field is defined in Table 9-159:
Table 9-159—Subelement IDs
Value Contents of Data field
0 Reserved
1 PMK-R1 key holder identifier (R1KH-ID)
2 GTK subelement
3 PMK-R0 key holder identifier (R0KH-ID)
4 IGTK
5–255 Reserved
R1KH-ID indicates the identity of the R1KH, which is used by the S0KH and the R0KH for deriving the
PMK-R1s. It is encoded following the conventions in 9.2.2.
934
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The GTK subelement contains the group temporal key, which is encrypted (see procedures in 13.8.5) and is
defined in Figure 9-318.
Subelement ID Length Key Info Key Length RSC Wrapped Key
Octets: 1 1 2 1 8 24–40
Figure 9-318—GTK subelement format
The GTK subelement Key Info subfield is defined in Figure 9-319.
B0 B1 B2 B15
Key ID Reserved
Bits: 2 14
Figure 9-319—GTK subelement’s Key Info subfield
Key Length field is the length of the Key field in octets, not including any padding (see 13.8.5).
RSC field contains the receive sequence counter (RSC) for the GTK being installed. Delivery of the RSC
field value allows a STA to identify replayed MPDUs. If the RSC field value is less than 8 octets in length,
the remaining octets are set to 0. The least significant octet of the transmit sequence counter (TSC) or packet
number (PN) is in the first octet of the RSC field. See Table 12-5.
For WEP, the RSC value is reserved.
The Wrapped Key field contains the encrypted GTK as described in 13.8.5.
When sent by a non-AP STA, the R0KH-ID indicates the R0KH with which the S0KH negotiated the
PMK-R0 it is using for this transition. When sent by an AP, the R0KH-ID indicates the R0KH that the
S0KH will be using to generate a PMK-R0 security association. It is encoded following the conventions
from 9.2.2.
The IGTK field contains the Integrity GTK, used for protecting robust Management frames. The IGTK
subelement format is shown in Figure 9-320.
Subelement ID Length Key ID IPN Key Length Wrapped Key
Octets: 1 1 2 6 1 24
Figure 9-320—IGTK subelement format
The Key ID field indicates the value of the BIP key identifier.
The IPN field indicates the receive sequence counter for the IGTK being installed, to allow a STA to iden-
tify replayed protected group addressed robust Management frames.
The Key Length field is the length of IGTK in octets, not including any padding (see 13.8.5).
The Wrapped Key field contains the wrapped IGTK being distributed. The length of the resulting AES-Key-
wrapped IGTK in the Wrapped Key field is Key Length + 8 octets.
935
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.49 Timeout Interval element (TIE)
The TIE specifies time intervals and timeouts. Figure 9-321 shows this element.
Element ID Length Timeout Interval Type Timeout Interval Value
Octets: 1 1 1 4
Figure 9-321—TIE format
The Element ID and Length fields are defined in 9.4.2.1.
The Timeout Interval Type field is defined in Table 9-160.
Table 9-160—Timeout Interval Type field value
Timeout Interval Type Meaning Units
0 Reserved
1 Reassociation deadline interval Time units (TUs)
2 Key lifetime interval Seconds
3 Association Comeback time Time units (TUs)
4 Time-to-Start (see 11.33.2.1) Time units (TUs)
5–255 Reserved
The Timeout Interval Value field contains an unsigned 32-bit integer. It is encoded according to the
conventions in 9.2.2.
A reassociation deadline interval value of 0 indicates no deadline exists. A key lifetime interval value of 0 is
reserved.
9.4.2.50 RIC Data element (RDE)
The RIC refers to a collection of elements that are used to express a resource request and to convey
responses to the corresponding requests.
A RIC is a sequence of one or more Resource Requests, or a sequence of one or more Resource Responses.
Each Resource Request or Response consists of an RDE, followed by one or more elements that describe
that resource. See 13.11 for examples and procedures.
The RDE format is shown in Figure 9-322.
Resource Descriptor
Element ID Length RDE Identifier Count Status Code
Octets: 1 1 1 1 2
Figure 9-322—RDE format
The Element ID and Length fields are defined in 9.4.2.1.
936
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The RDE Identifier field has an arbitrary 8-bit value, chosen by the resource requester to uniquely identify
the RDE within the RIC.
The Resource Descriptor Count field indicates the number of alternative Resource Descriptors that follow
this RDE.
The Status Code field is used in Resource Responses to indicate the result of the request. Valid values for the
Status Code field are given in 9.4.1.9. When an RDE is included in a Resource Request, the Status Code
field is reserved.
9.4.2.51 RIC Descriptor element
The RIC Descriptor element is used with an RDE during a fast BSS transition to negotiate resources that are
not otherwise described by elements. See 13.11 for procedures for including this element in a RIC.
Figure 9-323 shows the format of this element.
Element ID Length Resource Type Variable parameters
Octets: 1 1 1 variable
Figure 9-323—RIC Descriptor element format
The Element ID and Length fields are defined in 9.4.2.1.
The Resource Type field is defined in Table 9-161.
Table 9-161—Resource type code in RIC Descriptor element
Resource type
Meaning Variable parameters
value
1 Block Ack Block Ack Parameter Set field value as defined in
9.4.1.14, Block Ack Timeout field value as defined
in 9.4.1.15, and Block Ack Starting Sequence
Control subfield value as defined in 9.3.1.8.
0, 2–255 Reserved
Variable parameters contain any additional data based on the resource type.
9.4.2.52 DSE Registered Location element
A DSE Registered Location element includes DSE location configuration information (LCI), which contains
latitude, longitude, and altitude information. The DSE Registered Location element format is shown in
Figure 9-324.
Element ID Length DSE Registered Location Information
Octets: 1 1 20
Figure 9-324—DSE Registered Location element format
937
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The structure and information fields are based on the LCI format described in IETF RFC 6225.
The DSE Registered Location Information field is shown in Figure 9-325.
B0 B5 B6 B39 B40 B45 B46 B79 B80 B83 B84 B89 B90 B119 B120 B122
Latitude Latitude Longitude Longitude Altitude Altitude Altitude Datum
Uncertainty Uncertainty Type Uncertainty
Bits: 6 34 6 34 4 6 30 3
B123 B124 B125 B126 B127 B128 B143 B144 B151 B152 B159
Dependent
RegLoc RegLoc DSE Dependent Version Enablement Operating Channel
Agreement STA Class Number
Identifier
Bits: 1 1 1 2 16 8 8
Figure 9-325—DSE Registered Location Information field format
The fields within the DSE Registered Location Information field are defined in Section 2.2 of IETF RFC
6225 (July 2011) except as defined in this standard.
With an Altitude Type field value of 3 (i.e., height above ground is in meters), the altitude is defined to be in
meters and is formatted in 2s complement, fixed-point, 22-bit integer part with 8-bit fraction.
The Datum field is a 3-bit field defined in IETF RFC 6225, and the codes used are as defined in IETF RFC
6225.
The RegLoc Agreement bit field is set to 1 to report that the STA is operating within a national policy area
or an international agreement area near a national border (see 11.12.3); otherwise, it is 0.
The RegLoc DSE bit field is set to 1 to report that the enabling STA is enabling the operation of STAs with
DSE; otherwise, it is 0.
The Dependent STA bit field is set to 1 to report that the STA is operating with the enablement of the
enabling STA whose LCI is being reported; otherwise, it is 0.
The Version field is a 2-bit field defined in IETF RFC 6225, and the use is described in IETF RFC 6225.
The Dependent Enablement Identifier field is a 16-bit field with a value set by the enabling STA via the DSE
Enablement frame; otherwise, it is set to 0.
The Operating Class field indicates the channel set for which the enablement request, report, or
announcement applies. The Operating Class and Channel Number fields together specify the channel
frequency and channel bandwidth for which the report applies. Valid values for the Operating Class field are
shown in Annex E.
The Channel Number field indicates the channel number for which the enablement request, report, or
announcement applies. The channel number is defined within an operating class as shown in Annex E.
938
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.53 Extended Channel Switch Announcement element
The Extended Channel Switch Announcement element is used by an AP, IBSS STA, or mesh STA to
advertise when the BSS is changing to a new channel or a new channel in a new operating class. The
announcement includes both the operating class and the channel number of the new channel. The element is
present only when an extended channel switch is pending. The format of the Extended Channel Switch
Announcement element is shown in Figure 9-326.
Element ID Length Channel New Operating New Channel Channel
Switch Mode Class Number Switch Count
Octets: 1 1 1 1 1 1
Figure 9-326—Extended Channel Switch Announcement element format
The Element ID and Length fields are defined in 9.4.2.1.
The Channel Switch Mode field indicates any restrictions on transmission until a channel switch. An AP or
an IBSS STA sets the Channel Switch Mode field to either 0 or 1 on transmission as specified in 11.9.8.2
and 11.9.8.3. The Channel Switch Mode field is reserved in an MBSS.
The New Operating Class field is set to the number of the operating class after the channel switch, as defined
in Annex E.
The New Channel Number field is set to the number of the channel after the channel switch. The channel
number is a channel from the STA’s new operating class as defined in Annex E.
For nonmesh STAs, the Channel Switch Count field indicates either the number of target beacon
transmission times (TBTTs) until the STA sending the Channel Switch Count field switches to the new
channel or a value of 0. A value of 1 indicates that the switch occurs immediately before the next TBTT. A
value of 0 indicates that the switch occurs any time after the frame containing the Channel Switch Count
field is transmitted.
For mesh STAs, the Channel Switch Count field is encoded as an octet with bits 6 to 0 set to the time, in
units of 2 TU when the MSB (bit 7) is 0, or in units of 100 TU when the MSB (bit 7) is 1, until the mesh
STA sending the Channel Switch Count field switches to the new channel. A value of 0 for bits 6 to 0
indicates that the switch occurs at any time after the frame containing the Channel Switch Count field is
transmitted. For example, a 200 TU channel switch time is encoded as X'82' and a 10 TU channel switch
time is encoded as X'05'.
9.4.2.54 Supported Operating Classes element
The Supported Operating Classes element is used by a STA to advertise the operating classes that it is
capable of operating with in this country. The format of the Supported Operating Classes element is shown
in Figure 9-327.
Current Operating
Operating Class
Element ID Length Current Operating Operating Class Extension Duple Sequence
Class Classes Sequence
(optional) (optional)
Octets: 1 1 1 variable variable variable
Figure 9-327—Supported Operating Classes element format
939
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The Current Operating Class field, concatenated with the Current Operating Class Extension field within the
Current Operating Class Extension Sequence field if present, indicates the operating class in use for
transmission and reception. If the operating class in use is a single octet, the Current Operating Class
Extension Sequence field is not present. If the operating class in use is more than a single octet, then the
Current Operating Class Extension Sequence field is present, and the concatenation of the Current Operating
Class field with the Current Operating Class Extension Sequence field comprises N (where N 0) Operating
Class octets with an 80+ behavior limit followed by one Operating Class octet without an 80+ behavior limit
(as defined in Annex E).
The Operating Classes field lists, in descending order or preference, all single-octet operating classes that
the STA is capable of operating with in this country. The Operating Classes field terminates immediately
before a OneHundredAndThirty Delimiter (see Figure 9-328), a Zero Delimiter (see Figure 9-329), or the
end of the element.
The format of the optional Current Operating Class Extension Sequence field is shown in Figure 9-328.
one or more entries
Current Operating
OneHundredAndThirty Delimiter Class Extension
Octets: 1 variable
Figure 9-328—Current Operating Class Extension Sequence field format
The OneHundredAndThirty Delimiter field is set to 130.
The Current Operating Class Extension field comprises N (where N 0) Operating Class octets with an 80+
behavior limit followed by one Operating Class octet without an 80+ behavior limit (as defined in Annex E).
The format of the Operating Class Duple Sequence field is shown in Figure 9-329.
one or more entries
Operating Class
Zero Delimiter Duple List
Octets: 1 2n
Figure 9-329—Operating Class Duple Sequence field format
The Zero Delimiter is set to 0.
The Operating Class Duple List subfield lists all two-octet operating classes that the STA is capable of
operating with in this country. Each operating class in the Operating Class Duple List subfield contains an
Operating Class octet with an 80+ behavior limit followed by one Operating Class octet without an 80+
behavior limit (as defined in Annex E). Operating classes are transmitted in ascending order using the first
octet in the operating class as the primary sort key and then the second octet in the operating class as the
secondary sort key. If there are no two-octet operating classes that the STA is capable of operating with in
this country, then the Operating Class Duple Sequence field is omitted from the Supported Operating
Classes element. The Operating Class Duple List subfield terminates immediately before another zero octet
or the end of the element.
940
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The use of this element is described in 11.10.2 and 11.11.9.1.
9.4.2.55 Management MIC element
The Management MIC element (MME) provides message integrity and protects group addressed robust
Management frames from forgery and replay. Figure 9-330 shows the MME format.
Element ID Length Key ID IPN MIC
Octets: 1 1 2 6 8 or 16
Figure 9-330—Management MIC element format
The Element ID and Length fields are defined in 9.4.2.1.
The Key ID field identifies the IGTK used to compute the MIC. Bits 0–11 define a value in the range 0–
4095. Bits 12–15 are reserved. The IGTK Key ID is either 4 or 5. The remaining Key IDs are reserved.
The IPN field contains a 6 octet value, interpreted as a 48-bit unsigned integer and used to detect replay of
protected group addressed robust Management frames.
The MIC field contains a message integrity code calculated over the robust Management frame as specified
in 12.5.4.5 and 12.5.4.6. The length of the MIC field depends on the specific cipher negotiated and is either
8 octets (for BIP-CMAC-128) or 16 octets (for BIP-CMAC-256, BIP-GMAC-128, and BIP-GMAC-256).
9.4.2.56 HT Capabilities element
9.4.2.56.1 HT Capabilities element structure
An HT STA declares that it is an HT STA by transmitting the HT Capabilities element.
The HT Capabilities element contains a number of fields that are used to advertise optional HT capabilities
of an HT STA. The HT Capabilities element is present in Beacon, Association Request, Association
Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Mesh Peering
Open, and Mesh Peering Close frames. The HT Capabilities element is defined in Figure 9-331.
Element HT A-MPDU Supported HT Extended Transmit ASEL
Length Capability Beamforming
ID Information Parameters MCS Set Capabilities Capabilities Capabilities
Octets: 1 1 2 1 16 2 4 1
Figure 9-331—HT Capabilities element format
The Element ID and Length fields are defined in 9.4.2.1.
9.4.2.56.2 HT Capability Information field
The HT Capability Information field of the HT Capabilities element is 2 octets in length, and contains
capability information bits. The structure of this field is defined in Figure 9-332.
941
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3 B4 B5 B6 B7 B8 B9
LDPC Supported SM
HT- Short GI for Short GI for Tx Rx
Coding Channel Power Greenfield 20 MHz 40 MHz STBC STBC
Capability Width Set Save
Bits: 1 1 2 1 1 1 1 2
B10 B11 B12 B13 B14 B15
L-SIG TXOP
HT-delayed Maximum DSSS/CCK Forty MHz
Block Ack A-MSDU Length Mode in 40 MHz Reserved Intolerant Protection
Support
1 1 1 1 1 1
Figure 9-332—HT Capability Information field
The subfields of the HT Capability Information field are defined in Table 9-162.
Table 9-162—Subfields of the HT Capability Information field
Subfield Definition Encoding
LDPC Indicates support for Set to 0 if not supported
Coding receiving LDPC coded Set to 1 if supported
Capability packets
Supported Indicates the channel Set to 0 if only 20 MHz operation is supported
Channel widths supported by the Set to 1 if both 20 MHz and 40 MHz operation is supported
Width Set STA.
See 11.16. This field is reserved when the transmitting or receiving STA is
operating in an operating class that includes 20 in the Channel
spacing (MHz) column of the appropriate table in Annex E.
SM Power Indicates the spatial Set to 0 for static SM power save mode
Save multiplexing power save Set to 1 for dynamic SM power save mode
mode that is in operation Set to 3 for SM power save disabled or not supported
immediately after
(re)association. The value 2 is reserved
See 11.2.6.
Only valid in a (Re)Association Request frame sent to an AP.
Otherwise this subfield is set to 0 or 3 upon transmission and is
ignored upon reception.
NOTE—This subfield indicates the operational state immediately
after (re)association as well as (if not set to 3) a capability.
HT- Indicates support for the Set to 0 if not supported
Greenfield reception of PPDUs with Set to 1 if supported
HT-greenfield format.
See 19.1.4.
Short GI for Indicates short GI support Set to 0 if not supported
20 MHz for the reception of packets Set to 1 if supported
transmitted with
TXVECTOR parameter
CH_BANDWIDTH equal
to HT_CBW20
942
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-162—Subfields of the HT Capability Information field (continued)
Subfield Definition Encoding
Short GI for Indicates short GI support Set to 0 if not supported
40 MHz for the reception of packets Set to 1 if supported
transmitted with
TXVECTOR parameter
CH_BANDWIDTH equal
to HT_CBW40
Tx STBC Indicates support for the Set to 0 if not supported
transmission of PPDUs Set to 1 if supported
using STBC
Rx STBC Indicates support for the Set to 0 for no support
reception of PPDUs using Set to 1 for support of one spatial stream
STBC Set to 2 for support of one and two spatial streams
Set to 3 for support of one, two and three spatial streams
HT-delayed Indicates support for HT- Set to 0 if not supported
Block Ack delayed block ack Set to 1 if supported
operation.
See 10.24.8. Support indicates that the STA is able to accept an ADDBA request
for HT-delayed Block Ack
Maximum Indicates maximum Set to 0 for 3839 octets
A-MSDU A-MSDU length. Set to 1 for 7935 octets
Length See 10.12.
DSSS/CCK Indicates use of DSSS/CCK In Beacon and Probe Response frames:
Mode in mode in a 20/40 MHz BSS. Set to 0 if the BSS does not allow use of DSSS/CCK in 40 MHz
40 MHz See 11.16. Set to 1 if the BSS does allow use of DSSS/CCK in 40 MHz
Otherwise:
Set to 0 if the STA does not use DSSS/CCK in 40 MHz
Set to 1 if the STA uses DSSS/CCK in 40 MHz
See 11.16.8 for operating rules
Forty MHz Indicates whether APs Set to 1 by an HT STA to prohibit a receiving AP from operating that
Intolerant receiving this information AP’s BSS as a 20/40 MHz BSS; otherwise, set to 0.
or reports of this
information are required to
prohibit 40 MHz
transmissions (see
11.16.12).
L-SIG Indicates support for the L- Set to 0 if not supported
TXOP SIG TXOP protection Set to 1 if supported
Protection mechanism (see 10.26.5)
Support
The following subfields are reserved for a mesh STA: Tx STBC, Rx STBC.
9.4.2.56.3 A-MPDU Parameters field
The structure of the A-MPDU Parameters field of the HT Capabilities element is shown in Figure 9-333.
943
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B4 B5 B7
Maximum A-MPDU Minimum MPDU
Length Exponent Start Spacing Reserved
Bits: 2 3 3
Figure 9-333—A-MPDU Parameters field
The subfields of the A-MPDU Parameters field are defined in Table 9-163.
Table 9-163—Subfields of the A-MPDU Parameters field
Subfield Definition Encoding
Maximum Indicates the maximum length of A-MPDU This field is an integer in the range 0 to 3.
A-MPDU that the STA can receive.
Length The length defined by this field is equal to
Exponent 13 + Maximum A-MPDU Length Exponent
2 – 1 octets.
Minimum Determines the minimum time between the Set to 0 for no restriction
MPDU Start start of adjacent MPDUs within an Set to 1 for 1/4 s
Spacing A-MPDU that the STA can receive, Set to 2 for 1/2 s
measured at the PHY SAP. Set to 3 for 1 s
See 10.13.3. Set to 4 for 2 s
Set to 5 for 4 s
Set to 6 for 8 s
Set to 7 for 16 s
9.4.2.56.4 Supported MCS Set field
The Supported MCS Set field of the HT Capabilities element indicates which HT MCSs a STA supports.
An MCS is identified by an MCS index, which is represented by an integer in the range 0 to 76. The
interpretation of the MCS index (i.e., the mapping from MCS to data rate) is PHY dependent. For the HT
PHY, see 19.5.
The structure of the MCS Set field is defined in Figure 9-334.
B0 B76 B77 B79 B80 B89 B90 B95
Rx MCS Bitmask Reserved Rx Highest Supported Data Rate Reserved
Bits: 77 3 10 6
B96 B97 B98 B99 B100 B101 B127
Tx MCS Set Tx Rx MCS Set Tx Maximum Number Tx Unequal
Spatial Streams Modulation Reserved
Defined Not Equal Supported Supported
Bits: 1 1 2 1 27
Figure 9-334—Supported MCS Set field
944
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Rx MCS Bitmask subfield of the Supported MCS Set field defines a set of MCS index values, where bit
B0 corresponds to MCS 0 and bit B76 corresponds to MCS 76.
NOTE—An HT STA includes the mandatory MCS values defined in 19.1 in the Rx MCS Bitmask subfield.
The Rx Highest Supported Data Rate subfield of the Supported MCS Set field defines the highest HT PPDU
data rate that the STA is able to receive, in units of 1 Mb/s in the range 1 to 1023. If the maximum data rate
expressed in Mb/s is not an integer, then the value is rounded down to the next integer. The value 0 indicates
that this subfield does not specify the HT PPDU highest data rate that the STA is able to receive; see
10.7.6.5.3.
The Tx MCS Set Defined, Tx Rx MCS Set Not Equal, Tx Maximum Number Spatial Streams Supported,
and Tx Unequal Modulation Supported subfields of the Supported MCS Set field indicate the transmit-
supported MCS set, as defined in Table 9-164.
Table 9-164—Transmit MCS Set
Tx MCS Tx Rx
Tx Maximum Number Tx Unequal Modulation
Condition Set MCS Set
Spatial Streams Supported Supported
Defined Not Equal
No Tx MCS set 0 0 0 0
is defined
The Tx MCS set 1 0 0 0
is defined and is
equal to the Rx
MCS set
The Tx MCS set 1 1 Indicates the maximum number Indicates whether transmit
is defined and is of spatial streams supported unequal modulation (UEQM)
not necessarily when transmitting: is supported:
equal to the Rx Set to 0 for 1 spatial stream Set to 0 for UEQM not
MCS set Set to 1 for 2 spatial streams supported
Set to 2 for 3 spatial streams Set to 1 for UEQM supported
Set to 3 for 4 spatial streams
9.4.2.56.5 HT Extended Capabilities field
The structure of the HT Extended Capabilities field of the HT Capabilities element is defined in
Figure 9-335.
B0 B1 B2 B3 B7 B8 B9 B10 B11 B12 B15
PCO MCS +HTC-HT RD
PCO Transition Time Reserved Feedback Support Responder Reserved
Bits: 1 2 5 2 1 1 4
Figure 9-335—HT Extended Capabilities field
945
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The subfields of the HT Extended Capabilities field are defined in Table 9-165.
Table 9-165—Subfields of the HT Extended Capabilities field
Subfield Definition Encoding
PCO Indicates support for PCO. Set to 0 if not supported
Set to 1 if supported
When transmitted by an AP: indicates
whether the AP can operate its BSS as a PCO
BSS.
When transmitted by a non-AP STA:
indicates whether the STA can operate as a
PCO active STA when the Transition Time
subfield in its HT Extended Capabilities field
meets the intended transition time of the PCO
capable AP.
The PCO mechanism is obsolete.
Consequently, this subfield might be
reserved in a later revision of this standard.
PCO When transmitted by a non-AP STA: If the PCO subfield is equal to 0, this field is
Transition indicates that the STA can switch between 20 reserved.
Time MHz channel width and 40 MHz channel
width within the specified time. Otherwise:
Set to 1 for 400 µs
When transmitted by an AP: indicates the Set to 2 for 1.5 ms
PCO Transition Time to be used during PCO Set to 3 for 5 ms
operation. The value contained in this field is
dynamic when transmitted by an AP, i.e., the Set to 0 for no transition. In this case, the PCO
value of this field might change at any time active STA does not change its operating
during the lifetime of the association of a channel width and is able to receive 40 MHz
STA with the AP. See 11.17.3. PPDUs during the 20 MHz phase (see 11.17).
MCS Indicates whether the STA can provide MFB Set to 0 (No Feedback) if the STA does not
Feedback provide MFB
Set to 2 (Unsolicited) if the STA provides only
unsolicited MFB
Set to 3 (Both) if the STA can provide MFB in
response to MRQ (either Delayed or Immediate,
see 10.31.1) as well as unsolicited MFB
The value 1 is reserved
+HTC-HT Indicates support of the HT variant HT Set to 0 if not supported
Support Control field. Set to 1 if supported
See 10.9
RD Indicates support for acting as a reverse Set to 0 if not supported
Responder direction responder, i.e., the STA might use Set to 1 if supported
an offered RDG to transmit data to an RD
initiator using the reverse direction protocol
described in 10.28.
The following subfield is reserved for a mesh STA: PCO.
946
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.56.6 Transmit Beamforming Capabilities
The structure of the Transmit Beamforming Capabilities field is defined in Figure 9-336.
B0 B1 B2 B3 B4 B5 B6 B7 B8
Implicit
Transmit Receive Transmit Receive Transmit Implicit Explicit CSI
Staggered Staggered Transmit Transmit
Beamforming Sounding Sounding NDP NDP Beamforming Calibration Beamforming
Receiving Capable Capable
Capable Capable Capable Capable Capable
Bits: 1 1 1 1 1 1 2 1
B9 B10 B11 B12 B13 B14 B15 B16 B17 B18 B19 B20
Explicit Explicit
Explicit CSI Number of
Explicit Explicit Transmit Noncompressed Compressed Minimal Beamformer
Noncompressed Compressed Beamforming Beamforming
Steering Capable Steering Capable Beamforming Feedback Feedback Grouping Antennas
CSI Feedback Supported
Capable Capable
1 1 2 2 2 2 2
B21 B22 B23 B24 B25 B26 B27 B28 B29 B31
Noncompressed Steering Compressed Steering CSI Max Number of Channel
Number of Beamformer Number of Beamformer Rows Beamformer Estimation Reserved
Antennas Supported Antennas Supported Supported Capability
2 2 2 2 3
Figure 9-336—Transmit Beamforming Capabilities field
The subfields of the Transmit Beamforming Capabilities field are defined in Table 9-166.
Table 9-166—Subfields of the Transmit Beamforming Capabilities field
Subfield Definition Encoding
Implicit Transmit Indicates whether this STA can receive Set to 0 if not supported
Beamforming Transmit Beamforming steered frames Set to 1 if supported
Receiving Capable using implicit feedback
Receive Staggered Indicates whether this STA can receive Set to 0 if not supported
Sounding Capable staggered sounding frames. Set to 1 if supported
Transmit Staggered Indicates whether this STA can transmit Set to 0 if not supported
Sounding Capable staggered sounding frames. Set to 1 if supported
Receive NDP Indicates whether this receiver can Set to 0 if not supported
Capable interpret null data packets as sounding Set to 1 if supported
frames.
Transmit NDP Indicates whether this STA can transmit Set to 0 if not supported
Capable null data packets as sounding frames. Set to 1 if supported
Implicit Transmit Indicates whether this STA can apply Set to 0 if not supported
Beamforming implicit transmit beamforming. Set to 1 if supported
Capable
947
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-166—Subfields of the Transmit Beamforming Capabilities field (continued)
Subfield Definition Encoding
Calibration Indicates whether the STA can participate Set to 0 if not supported
in a calibration procedure initiated by
another STA that is capable of generating Set to 1 if the STA can respond to a calibration
an immediate response sounding PPDU request using the CSI report, but cannot
and can provide a CSI report in response initiate calibration
to the receipt of a sounding PPDU.
The value 2 is reserved
Set to 3 if the STA can both initiate and
respond to a calibration request
Explicit CSI Indicates whether this STA can apply Set to 0 if not supported
Transmit transmit beamforming using CSI explicit Set to 1 if supported
Beamforming feedback in its transmission
Capable
Explicit Indicates whether this STA can apply Set to 0 if not supported
Noncompressed transmit beamforming using Set to 1 if supported
Steering Capable noncompressed beamforming feedback
matrix explicit feedback in its
transmission
Explicit Compressed Indicates whether this STA can apply Set to 0 if not supported
Steering Capable transmit beamforming using compressed Set to 1 if supported
beamforming feedback matrix explicit
feedback in its transmission
Explicit Transmit Indicates whether this receiver can return Set to 0 if not supported
Beamforming CSI CSI explicit feedback. Set to 1 for delayed feedback
Feedback Set to 2 for immediate feedback
Set to 3 for delayed and immediate feedback
Explicit Indicates whether this receiver can return Set to 0 if not supported
Noncompressed noncompressed beamforming feedback Set to 1 for delayed feedback
Beamforming matrix explicit feedback. Set to 2 for immediate feedback
Feedback Capable Set to 3 for delayed and immediate feedback
Explicit Compressed Indicates whether this receiver can return Set to 0 if not supported
Beamforming compressed beamforming feedback matrix Set to 1 for delayed feedback
Feedback Capable explicit feedback. Set to 2 for immediate feedback
Set to 3 for delayed and immediate feedback
Minimal Grouping Indicates the minimal grouping used for Set to 0 if the STA supports groups of 1
explicit feedback reports (no grouping)
Set to 1 indicates groups of 1, 2
Set to 2 indicates groups of 1, 4
Set to 3 indicates groups of 1, 2, 4
CSI Number of Indicates the maximum number of Set to 0 for single Tx antenna sounding
Beamformer beamformer antennas the HT beamformee Set to 1 for 2 Tx antenna sounding
Antennas Supported can support when CSI feedback is Set to 2 for 3 Tx antenna sounding
required Set to 3 for 4 Tx antenna sounding
Noncompressed Indicates the maximum number of Set to 0 for single Tx antenna sounding
Steering Number of beamformer antennas the HT beamformee Set to 1 for 2 Tx antenna sounding
Beamformer can support when noncompressed Set to 2 for 3 Tx antenna sounding
Antennas Supported beamforming feedback matrix is required Set to 3 for 4 Tx antenna sounding
948
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-166—Subfields of the Transmit Beamforming Capabilities field (continued)
Subfield Definition Encoding
Compressed Indicates the maximum number of Set to 0 for single Tx antenna sounding
Steering Number of beamformer antennas the HT beamformee Set to 1 for 2 Tx antenna sounding
Beamformer can support when compressed Set to 2 for 3 Tx antenna sounding
Antennas Supported beamforming feedback matrix is required Set to 3 for 4 Tx antenna sounding
CSI Max Number of Indicates the maximum number of rows of Set to 0 for a single row of CSI
Rows Beamformer CSI explicit feedback from the HT Set to 1 for 2 rows of CSI
Supported beamformee or calibration responder or Set to 2 for 3 rows of CSI
transmit ASEL responder that an HT Set to 3 for 4 rows of CSI
beamformer or calibration initiator or
transmit ASEL initiator can support when
CSI feedback is required.
Channel Estimation Indicates the maximum number of space- Set 0 for 1 space-time stream
Capability time streams (columns of the MIMO Set 1 for 2 space-time streams
channel matrix) for which channel Set 2 for 3 space-time streams
dimensions can be simultaneously Set 3 for 4 space-time streams
estimated when receiving an NDP
sounding PPDU or the extension portion
of the HT Long Training fields (HT-LTFs)
in a staggered sounding PPDU. See
NOTE.
NOTE—The maximum number of space-time streams for which channel coefficients can be simultaneously estimated using the
HT-LTFs corresponding to the data portion of the packet is limited by the Rx MCS Bitmask subfield of the Supported MCS Set field
and by the Rx STBC subfield of the HT Capability Information field. Both fields are part of the HT Capabilities element.
9.4.2.56.7 ASEL Capability field
The structure of the ASEL Capability field of the HT Capabilities element is defined in Figure 9-337.
B0 B1 B2 B3 B4 B5 B6 B7
Explicit CSI Antenna
Indices Explicit
Antenna Feedback Feedback CSI Antenna Receive Transmit
Based Indices Sounding
Selection Transmit Based Feed- Feedback ASEL PPDUs Reserved
Capable Transmit back Capable
ASEL ASEL Capable Capable Capable
Capable
Capable
Bits: 1 1 1 1 1 1 1 1
Figure 9-337—ASEL Capability field
949
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The subfields of the ASEL Capability field are defined in Table 9-167.
Table 9-167—ASEL Capability field subfields
Subfield Definition Encoding
Antenna Selection Indicates whether this STA supports ASEL Set to 0 if not supported
Capable Set to 1 if supported
Explicit CSI Feedback Indicates whether this STA supports transmit ASEL Set to 0 if not supported
Based Transmit ASEL based on explicit CSI feedback Set to 1 if supported
Capable
Antenna Indices Feedback Indicates whether this STA supports transmit ASEL Set to 0 if not supported
Based Transmit ASEL based on antenna indices feedback Set to 1 if supported
Capable
Explicit CSI Feedback Indicates whether this STA can compute CSI and Set to 0 if not supported
Capable provide CSI feedback in support of ASEL Set to 1 if supported
Antenna Indices Feedback Indicates whether this STA can compute an antenna Set to 0 if not supported
Capable indices selection and return an antenna indices Set to 1 if supported
selection in support of ASEL
Receive ASEL Capable Indicates whether this STA supports receive ASEL Set to 0 if not supported
Set to 1 if supported
Transmit Sounding Indicates whether this STA can transmit sounding Set to 0 if not supported
PPDUs Capable PPDUs for ASEL training on request Set to 1 if supported
9.4.2.57 HT Operation element
The operation of HT STAs in the BSS is controlled by the HT Operation element. The structure of this
element is defined in Figure 9-338.
HT
Element Length Primary Operation Basic HT-
ID Channel MCS Set
Information
Octets: 1 1 1 5 16
Figure 9-338—HT Operation element format
The Element ID and Length fields are defined in 9.4.2.1.
950
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The structure of the HT Operation Information field is shown in Figure 9-339.
B0 B1 B2 B3 B4 B7
Secondary Channel Offset STA Channel Width RIFS Mode Reserved
Bits: 2 1 1 4
B8 B9 B10 B11 B12 B13 B20 B21 B23
HT Protection Nongreenfield HT Reserved OBSS Non-HT Channel Center Reserved
STAs Present STAs Present Frequency Segment 2
2 1 1 1 11 2
B24 B29 B30 B31 B32 B33 B34 B35 B36 B39
Dual CTS STBC L-SIG TXOP Protection
Reserved Dual Beacon PCO Active PCO Phase Reserved
Protection Beacon Full Support
6 1 1 1 1 1 1 4
Figure 9-339—HT Operation Information field
The Primary Channel field, subfields of the HT Operation Information field, and the Basic HT-MCS Set
field are defined in Table 9-168. The “Reserved in IBSS?” column indicates whether each field is reserved
(Y) or not reserved (N) when this element is present in a frame transmitted within an IBSS. The “Reserved
in MBSS?” column indicates whether each field is reserved (Y) or not reserved (N) when this element is
present in a frame transmitted within an MBSS.
Table 9-168—HT Operation element fields and subfields
Reserved Reserved
Field Definition Encoding
in IBSS? in MBSS?
Primary Channel Indicates the channel number Channel number of the primary channel N N
of the primary channel.
See 11.16.2.
Secondary Indicates the offset of the Set to 1 (SCA) if the secondary channel is N N
Channel Offset secondary channel relative to above the primary channel
the primary channel. Set to 3 (SCB) if the secondary channel is
below the primary channel
Set to 0 (SCN) if no secondary channel is
present
The value 2 is reserved
STA Channel Defines the channel widths Set to 0 for a 20 MHz channel width N N
Width that can be used to transmit to Set to 1 allows use of any channel width in the
the STA. Supported channel width set
See 11.16.12
This field is reserved when the transmitting or
receiving STA is operating in an operating class
that does not include a value of
PrimaryChannelLowerBehavior or
PrimaryChannelUpperBehavior in the behavior
limits set as specified in Annex E.
See NOTE 1.
951
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-168—HT Operation element fields and subfields (continued)
Reserved Reserved
Field Definition Encoding
in IBSS? in MBSS?
RIFS Mode Indicates whether the use of Set to 0 if use of RIFS is prohibited Y Y
reduced interframe space is Set to 1 if use of RIFS is permitted
permitted within the BSS.
See 10.3.2.3.2 and 10.26.3.3
HT Protection Indicates protection Set to 0 for no protection mode Y N
requirements of HT Set to 1 for nonmember protection mode
transmissions. Set to 2 for 20 MHz protection mode
See 10.26.3. Set to 3 for non-HT mixed mode
Nongreenfield AP indicates if any HT STAs Set to 0 if all HT STAs that are associated are Y N
HT STAs that are not HT-greenfield HT-greenfield capable or all HT peer mesh
Present capable have associated. STAs are HT-greenfield capable
Mesh STA indicates if it Set to 1 if one or more HT STAs that are not
establishes a mesh peering HT-greenfield capable are associated or one or
with an HT STA that is not more HT peer mesh STAs are not HT-greenfield
HT-greenfield capable. capable
Determines when a non-AP
STA should use HT-
greenfield protection.
Present in Beacon and Probe
Response frames transmitted
by an AP or mesh STA.
Otherwise reserved.
See 10.26.3.1.
OBSS Non-HT Indicates if the use of If not operating in an operating class for which Y Y
STAs Present protection for non-HT STAs the behavior limits set listed in Annex E
by overlapping BSSs is includes the value DFS_50_100_Behavior:
determined to be desirable.
Set to 1 if the use of protection for non-HT
If the BSS is operating in an STAs by OBSSs is determined to be desirable.
operating class for which the See NOTE 2.
behavior limits set listed in
Annex E includes the Set to 0 otherwise.
DFS_50_100_Behavior, this
field indicates if there exist
any non-HT OBSSs and If operating in an operating class for which the
whether HT-greenfield behavior limits set listed in Annex E includes
transmissions are allowed. the value DFS_50_100_Behavior:
Present in Beacon and Probe Set to 1 if there exists one or more non-HT
Response frames transmitted OBSSs. Indicates that HT-greenfield
by an AP. Otherwise transmissions are disallowed in the BSS.
reserved.
See 10.26.3.4 and 11.9.8.5. Set to 0 otherwise.
Channel Center Defines the channel center For a STA with dot11VHTExtendedNSSBW- N N
Frequency frequency for a 160 or 80+80 Capable equal to true: See Table 9-250, other-
Segment 2 MHz BSS bandwidth with wise this field is set to 0.
NSS support less than Max
VHT NSS.
NOTE—This subfield is not used in a non-VHT
See 21.3.14 and 9.4.2.158.3. HT STA.
952
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-168—HT Operation element fields and subfields (continued)
Reserved Reserved
Field Definition Encoding
in IBSS? in MBSS?
Dual Beacon Indicates whether the AP Set to 0 if no STBC beacon is transmitted Y Y
transmits an STBC beacon. Set to 1 if an STBC beacon is transmitted by the
AP
The use of the dual beacon
mechanism is deprecated.
Dual CTS Dual CTS protection is used Set to 0 if dual CTS protection is not required Y Y
Protection by the AP to set a NAV at Set to 1 if dual CTS protection is required
STAs that do not support
STBC and at STAs that can
associate solely through the
STBC beacon.
See 10.3.2.8.
The use of the dual CTS
mechanism is deprecated.
STBC Beacon Indicates whether the beacon Set to 0 in a primary beacon Y Y
containing this element is a Set to 1 in an STBC beacon
primary or an STBC beacon.
The STBC beacon has half a
beacon period shift relative to
the primary beacon.
Defined only in a Beacon
frame transmitted by an AP.
Otherwise reserved.
See 11.1.3.2.
L-SIG TXOP Indicates whether all HT STA Set to 0 if one or more HT STA in the BSS do Y Y
Protection Full in the BSS support L-SIG not support L-SIG TXOP protection
Support TXOP protection. Set to 1 if all HT STA in the BSS support L-SIG
See 10.26.5. TXOP protection
PCO Active Indicates whether PCO is Set to 0 if PCO is not active in the BSS Y Y
active in the BSS Set to 1 if PCO is active in the BSS
Present in Beacon/Probe
Response frames transmitted
by an AP. Otherwise
reserved.
Non-PCO STAs regard the
BSS as a 20/40 MHz BSS and
might associate with the BSS
without regard to this field.
See 11.17.
PCO Phase Indicates the PCO phase of Set to 0 indicates switch to or continue 20 MHz Y Y
operation phase
Defined only in a Beacon and Set to 1 indicates switch to or continue 40 MHz
Probe Response frames when phase
PCO Active is 1. Otherwise
reserved.
See 11.17.
953
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-168—HT Operation element fields and subfields (continued)
Reserved Reserved
Field Definition Encoding
in IBSS? in MBSS?
Basic HT-MCS Indicates the HT MCS values A bitmap where a bit is set to 1 to indicate N N
Set that are supported by all HT support for that MCS and 0 otherwise, where
STAs in the BSS. bit 0 corresponds to MCS 0.
Present in Beacon, Probe
Response, Mesh Peering MCS values are defined in 9.4.2.56.4.
Open and Mesh Peering
Confirm frames. Otherwise
reserved.
NOTE 1—Any change of STA Channel Width field value does not impact the value of the HT Protection field.
NOTE 2—Examples of when this bit might be set to 1 include, but are not limited to, the following situations:
— One or more non-HT STAs are associated
— A non-HT BSS is overlapping (a non-HT BSS might be detected by the reception of a Beacon or Probe Response frame that
does not include an HT Capabilities element)
9.4.2.58 20/40 BSS Intolerant Channel Report element
The 20/40 BSS Intolerant Channel Report element contains a list of channels on which a STA has found
conditions that disallow the use of a 20/40 MHz BSS. The format of the 20/40 BSS Intolerant Channel
Report element is shown in Figure 9-340.
Element ID Length Operating Class Channel List
Octets: 1 1 1 variable
Figure 9-340—20/40 BSS Intolerant Channel Report element format
The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 1 (based
on a minimum length for the Channel List field of 0 octets).
Operating Class field of the 20/40 MHz BSS Intolerant Channel Report element contains an enumerated
value from Annex E, encoded as an unsigned integer, specifying the operating class in which the channel list
is valid. If the operating class is “unknown” as described in 11.16.12, the Operating Class field is set to 0. A
20/40 BSS Intolerant Channel Report only reports channels for a single operating class. Multiple 20/40 BSS
Intolerant Channel Report elements are used to report channels in more than one operating class.
The Channel List field of the 20/40 MHz BSS Intolerant Channel Report element contains a variable number
of octets, where each octet describes a single channel number. Channel numbering is dependent on operating
class according to Annex E.
A 20/40 BSS Intolerant Channel Report element includes only channels that are valid for the regulatory
domain in which the STA transmitting the element is operating and that are consistent with the Country
element transmitted by the AP of the BSS of which it is a member.
954
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.59 Overlapping BSS Scan Parameters element
The Overlapping BSS Scan Parameters element is used by an AP to indicate the values to be used by BSS
members when performing OBSS scan operations. The format of the Overlapping BSS Scan Parameters
element is shown in Figure 9-341.
BSS OBSS OBSS
OBSS OBSS Channel BSS Width
Element Scan Scan Width Scan Scan Channel OBSS Scan
Length Passive Active Activity
ID Passive Active Trigger Total Per Total Per Transition Threshold
Dwell Dwell Scan Delay Factor
Interval Channel Channel
Octets: 1 1 2 2 2 2 2 2 2
Figure 9-341—Overlapping BSS Scan Parameters element format
The Element ID and Length fields are defined in 9.4.2.1.
The OBSS Scan Passive Dwell field contains a value in TUs, encoded as an unsigned integer, that a
receiving STA uses to set dot11OBSSScanPassiveDwell as described in 11.16.5.
The OBSS Scan Active Dwell field contains a value in TUs, encoded as an unsigned integer, that a receiving
STA uses to set dot11OBSSScanActiveDwell as described in 11.16.5.
The BSS Channel Width Trigger Scan Interval field contains a value in seconds, encoded as an unsigned
integer, that a receiving STA uses to set dot11BSSWidthTriggerScanInterval as described in 11.16.5.
The OBSS Scan Passive Total Per Channel field contains a value in TUs, encoded as an unsigned integer,
that a receiving STA uses to set dot11OBSSScanPassiveTotalPerChannel as described in 11.16.5.
The OBSS Scan Active Total Per Channel field contains a value in TUs, encoded as an unsigned integer,
that a receiving STA uses to set dot11OBSSScanActiveTotalPerChannel as described in 11.16.5.
The BSS Width Channel Transition Delay Factor field contains an integer value that a receiving STA uses to
set dot11BSSWidthChannelTransitionDelayFactor as described in 11.16.5.
The OBSS Scan Activity Threshold field contains a value in hundredths of percent, encoded as an unsigned
integer, that a receiving STA uses to set dot11OBSSScanActivityThreshold as described in 11.16.5.
The use of each of these parameters is described in 11.16.5.
9.4.2.60 20/40 BSS Coexistence element
The 20/40 BSS Coexistence element is used by STAs to exchange information that affects 20/40 BSS
coexistence.
The 20/40 BSS Coexistence element is formatted as shown in Figure 9-342.
Element 20/40 BSS Coexistence
ID Length Information field
Octets: 1 1 1
Figure 9-342—20/40 BSS Coexistence element format
955
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The structure of the 20/40 BSS Coexistence Information field is shown in Figure 9-343.
B0 B1 B2 B3 B4 B5 B7
Forty 20 MHz OBSS OBSS
Informatio Scanning Scanning
n Request MHz BSS Width Exemption Exemption Reserved
Intolerant Request
Request Grant
Bits: 1 1 1 1 1 3
Figure 9-343—20/40 BSS Coexistence Information field
The Information Request field is used to indicate that a transmitting STA is requesting the recipient to
transmit a 20/40 BSS Coexistence Management frame with the transmitting STA as the recipient.
The Forty MHz Intolerant field is set to 1 to prohibit an AP that receives this information or reports of this
information from operating a 20/40 MHz BSS. When equal to 0, it does not prohibit a receiving AP from
operating a 20/40 MHz BSS. This field is used for inter-BSS communication. The definition of this field is
the same as the definition of the Forty MHz Intolerant field in the HT Capabilities element (see 9.4.2.56),
and its operation is described in 11.16.11.
The 20 MHz BSS Width Request field is set to 1 to prohibit a receiving AP from operating its BSS as a
20/40 MHz BSS. Otherwise, it is set to 0. This field is used for intra-BSS communication. The operation of
this field is described in 11.16.12.
The OBSS Scanning Exemption Request field is set to 1 to indicate that the transmitting non-AP STA is
requesting the BSS to allow the STA to be exempt from OBSS scanning. Otherwise, it is set to 0. The OBSS
Scanning Exemption Request field is reserved when transmitted by an AP. The OBSS Scanning Exemption
Request field is reserved when a 20/40 BSS Coexistence element is included in a group addressed frame.
The OBSS Scanning Exemption Grant field is set to 1 by an AP to indicate that the receiving STA is
exempted from performing OBSS Scanning. Otherwise, it is set to 0. The OBSS Scanning Exemption Grant
field is reserved when transmitted by a non-AP STA. The OBSS Scanning Exemption Grant field is reserved
when a 20/40 BSS Coexistence element is included in a group addressed frame.
9.4.2.61 Time Advertisement element
The Time Advertisement element, shown in Figure 9-344, specifies fields describing the source of time
corresponding to a time standard, an external clock (external time source), an estimate of the offset between
that time standard and the TSF timer, and an estimate of the standard deviation of the error in the offset
estimate. This information is used by a receiving STA to align its own estimate of the time standard based on
that of another STA.
Timing Time Value Time Error Time Update
Element ID Length Counter
Capabilities (optional) (optional) (optional)
Octets: 1 1 1 0 or 10 0 or 5 0 or 1
Figure 9-344—Time Advertisement element format
The Element ID and Length fields are defined in 9.4.2.1.
956
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Timing Capabilities field specifies the STA’s source and encoding of the Time Value field. The
encoding of the Timing Capabilities field is specified in Table 9-169.
Table 9-169—Encoding of the Timing Capabilities field
Value Usage
0 No standardized external time source
1 Timestamp offset based on UTC [see ITU-R Recommendation TF.460-4(2002)
[B51]]. The Timestamp offset value in nanoseconds is defined to be 0 at the
beginning of the first nanosecond of the first day of the year 1958.
2 UTC time at which the TSF timer is 0.
3–255 Reserved
When the value of the Timing Capabilities field is 0, only the Element ID, Length, and Timing Capabilities
fields are included in the Time Advertisement element.
When the value of the Timing Capabilities is 1, the following additional fields are included in the Time
Advertisement element:
— Time Value field, a 2s complement integer in nanoseconds that, when added to the Timestamp
present in the same transmitted frame, gives the receiving STA an estimate of the time standard at
the time the frame was transmitted. The Timestamp is derived from the TSF Timer as defined in
11.22.
— Time Error field, which is set to an unsigned integer in nanoseconds that defines the standard
deviation of the error in the Time Value estimate. The value of all 1s is used to indicate that the error
is unknown.
When the Timing Capabilities field is 2, the following fields are included in the Time Advertisement
element:
— The Time Value field is the UTC time at which the TSF Timer is 0, given that the TSF Timer units
are 1 microsecond units as defined in 11.1.3. The format, including all subfields is shown in Table 9-
170. For any subfield not known in the Time Value field, the subfield value is 0.
— The Time Error field is an unsigned integer in milliseconds that defines the standard deviation of the
error in the Time Value estimate.
— The Time Update Counter field is a modulo 256 counter that increments each time the AP updates
the Time Value UTC at which the TSF Timer is 0.
957
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-170—Time Value field format when Timing Capabilities is 2
Octet Description
0–1 Year (0–65 534)
2 Month (0–12)
3 Day of month (0–31)
4 Hours (0–23)
5 Minutes (0–59)
6 Seconds (0–59)
7–8 Milliseconds (0–999)
9 Reserved
9.4.2.62 Link Identifier element
The Link Identifier element contains information that identifies a TDLS direct link. The element
information format is defined in Figure 9-345.
Element TDLS initiator STA TDLS responder STA
Length BSSID
ID Address Address
Octets: 1 1 6 6 6
Figure 9-345—Link Identifier element format
The Element ID and Length fields are defined in 9.4.2.1.
The BSSID field is set to the BSSID of the BSS to which the TDLS initiator STA is associated.
The TDLS initiator STA Address field is set to the TDLS initiator STA’s MAC address.
The TDLS responder STA Address field is set to the TDLS responder STA’s MAC address.
9.4.2.63 Wakeup Schedule element
The Wakeup Schedule element contains information regarding the periodic wakeup schedule for TDLS peer
PSM. The element format is defined in Figure 9-346.
Maximum
Awake
Element Length Offset Interval Window Awake Idle
ID Window Count
Slots Duration
Octets: 1 1 4 4 4 4 2
Figure 9-346—Wakeup Schedule element format
The Element ID and Length fields are defined in 9.4.2.1.
958
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Offset field is the time in microseconds between TSF 0 and the start of a first Awake Window. See
11.2.3.14.
The Interval field is set to the time in microseconds between the start of two successive Awake Windows.
See 11.2.3.14.
The Awake Window Slots field is set to the duration of the Awake Window in units of backoff slots (see
10.22.2.4). See 11.2.3.14.
The Maximum Awake Window Duration field is set to the maximum duration of the Awake Window, in
units of microseconds. See 11.2.3.14.
The Idle Count field is set to the number of consecutive Awake Windows during which no individually
addressed frame is received from the TDLS peer STA before a TDLS peer STA deletes the wakeup
schedule. See 11.2.3.14.
9.4.2.64 Channel Switch Timing element
The Channel Switch Timing element contains information regarding the channel switch timing. The element
is defined in Figure 9-347.
Element Switch
Length SwitchTime
ID Timeout
Octets: 1 1 2 2
Figure 9-347—Channel Switch Timing element format
The Element ID and Length fields are defined in 9.4.2.1.
The Switch Time field is set to the time it takes for a STA sending the Channel Switch Timing element to
switch channels, in units of microseconds.
The Switch Timeout field is set to a time in units of microseconds. The STA sending the Channel Switch
Timing element waits for the first Data frame exchange on the off-channel for Switch Timeout
microseconds before switching back to base channel. The time is measured from the end of the last symbol
of the Ack frame that is transmitted in response to TDLS Channel Switch Response frame, as seen on the
WM.
9.4.2.65 PTI Control element
The PTI Control element contains information regarding the traffic buffered at the TPU buffer STA for the
TPU sleep STA at the time a TDLS Peer Traffic Indication frame is transmitted by the TPU buffer STA. The
element is optionally included in the TDLS Peer Traffic Indication frame. The element is defined in
Figure 9-348.
Sequence
Element ID Length TID
Control
Octets: 1 1 1 2
Figure 9-348—PTI Control element format
959
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The TID field contained in the PTI Control element is set to the TID of the latest MPDU that has been
transmitted over the TDLS direct link to the TPU sleep STA that is the destination of the TDLS Peer Traffic
Indication frame that contains the PTI Control element. See 11.2.3.15.
The Sequence Control field is defined in 9.2.4.4. The Sequence Control field contained in the PTI Control
element is set to the sequence number of the latest MPDU that has been transmitted over the TDLS direct
link to the TPU sleep STA that is the destination of the TDLS Peer Traffic Indication frame that contains the
PTI Control element. See 11.2.3.15.
9.4.2.66 TPU Buffer Status element
The TPU Buffer Status element contains information regarding the traffic buffered at the TPU buffer STA
for the TPU sleep STA at the time a TDLS Peer Traffic Indication frame is transmitted by the TPU buffer
STA. The element is included in the TDLS Peer Traffic Indication frame. The element is defined in
Figure 9-349.
Element ID Length TPU Buffer Status Information
Octets: 1 1 1
Figure 9-349—TPU Buffer Status element format
The Element ID and Length fields are defined in 9.4.2.1.
The TPU Buffer Status Information field is defined in Figure 9-350
B0 B1 B2 B3 B4 B7
AC_BK AC_BE AC_VI AC_VO
traffic traffic traffic traffic Reserved
available available available available
Bits: 1 1 1 1 4
Figure 9-350—TPU Buffer Status Information field
The AC_BK traffic available field is one bit in size and is set to 1 if AC_BK contains traffic buffered for the
TPU sleep STA to which the TPU Buffer Status element will be transmitted and is set to 0 otherwise.
The AC_BE traffic available field is one bit in size and is set to 1 if AC_BE contains traffic buffered for the
TPU sleep STA to which the TPU Buffer Status element will be transmitted and is set to 0 otherwise.
The AC_VI traffic available field is one bit in size and is set to 1 if AC_VI contains traffic buffered for the
TPU sleep STA to which the TPU Buffer Status element will be transmitted and is set to 0 otherwise.
The AC_VO traffic available field is one bit in size and is set to 1 if AC_VO contains traffic buffered for the
TPU sleep STA to which the TPU Buffer Status element will be transmitted and is set to 0 otherwise.
960
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.67 Event Request element
9.4.2.67.1 Event Request definition
The Event Request element contains a request to the receiving STA to perform the specified event action.
The format of the Event Request element is shown in Figure 9-351.
Element ID Length Event Token Event Type Event Response Event Request
Limit
Octets: 1 1 1 1 1 variable
Figure 9-351—Event Request element format
The Element ID and Length fields are defined in 9.4.2.1.
The Event Token field is a nonzero number that is unique among the Event Request elements sent to each
destination MAC address for which a corresponding Event Report element has not been received.
The Event Type field is a number that identifies the type of event request. The values of the Event Type field
are defined in Table 9-171.
Table 9-171—Event Type field definitions for event requests and reports
Name Event Type
Transition 0
RSNA 1
Peer-to-peer link 2
WNM log 3
Reserved 4–220
Vendor Specific 221
Reserved 222–255
The Event Response Limit field contains the maximum number of requested Event Reports to be included in
the Event Report element. A value of 0 indicates that no limit is set on the number of Event Reports to be
included in the Event Report element.
The Event Request field contains the event request corresponding to the Event Type, as described in
9.4.2.67.2 to 9.4.2.67.4. The Event Request field is not present when requesting a WNM log report.
The Event Request element is included in an Event Request frame, as described in 9.6.14.2. The use of the
Event Request element and Event Request frame is described in 11.24.2.
9.4.2.67.2 Transition event request
The Event Request field corresponding to the Transition event request contains zero or more Transition
Event Request subelements. A transition event is a STA movement or attempted movement from one BSS
(the source BSS) in one ESS to another BSS (the target BSS) within the same ESS.
961
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Transition Event subelements specify the conditions in which a Transition Event Report is sent by a
STA. The set of valid Transition Event Request subelements is defined in Table 9-172.
Table 9-172—Transition Event Request subelement
Transition Event Request subelement Subelement ID
Transition Target BSSID 0
Transition Source BSSID 1
Transition Time Threshold 2
Transition Result 3
Frequent Transition 4
Reserved 5–255
The Transition Target BSSID subelement is used to request that a Transition Event Report includes the
transition event entry when the target BSSID is equal to the specific BSSID in the Target BSSID field.
Excluding this subelement from the Event Request element indicates a request for transition events for all
target BSSIDs. The format of the Transition Target BSSID subelement is shown in Figure 9-352.
Subelement ID Length Target BSSID
Octets: 1 1 6
Figure 9-352—Transition Target BSSID subelement format
The Subelement ID field is equal to the Transition Target BSSID value in Table 9-172.
The Length field is defined in 9.4.3.
The Target BSSID field contains a 6-octet BSSID.
The Transition Source BSSID subelement is used to request that a Transition Event Report includes the
transition event entry when the source BSSID is equal to the BSSID specified in the Source BSSID field.
Excluding this subelement from the Event Request element indicates a request for transition events for all
source BSSIDs. The format of the Transition Source BSSID subelement is shown in Figure 9-353.
Subelement ID Length Source BSSID
Octets: 1 1 6
Figure 9-353—Transition Source BSSID subelement format
The Subelement ID field is equal to the Transition Source BSSID value in Table 9-172.
The Length field is defined in 9.4.3.
The Source BSSID field contains a 6-octet BSSID.
962
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Transition Time Threshold subelement is used to request that a Transition Event Report includes the
transition event entry when the transition time is greater than or equal to the Transition Time Threshold
value. The format of the Transition Time Threshold subelement is shown in Figure 9-354.
Subelement ID Length Transition Time
Threshold
Octets: 1 1 2
Figure 9-354—Transition Time Threshold subelement format
The Subelement ID field is equal to the Transition Time Threshold value in Table 9-172.
The Length field is defined in 9.4.3.
The Transition Time Threshold field contains a value representing the Transition Time to be used as the
threshold value for the Transition Time condition in TUs. The Transition Time is defined in 11.24.2.2.
The Transition Result subelement is used to request that a Transition Event Report includes the transition
event entry that matches the transition result defined by this subelement. The format of Transition Result
subelement is shown in Figure 9-355.
Subelement ID Length Match Value
Octets: 1 1 1
Figure 9-355—Transition Result subelement format
The Subelement ID field is equal to the Transition Result value in Table 9-172.
The Length field is defined in 9.4.3.
The Match Value field is set with each bit as defined in Figure 9-356 to request that the specified transition
results that match the bit descriptions are included in the Transition Event report.
B0 B1 B2-B7
Include
Successful Include Failed Reserved
Transitions
Transitions
Bits 1 1 6
Figure 9-356—Match Value field definitions
The Frequent Transition subelement is used to request that an alerting Transition Event report be generated
when the total transition count during the specified time period is greater than or equal to the value given in
Frequent Transition Count Threshold field. The format of the Frequent Transition subelement is shown in
Figure 9-357.
The Subelement ID field is equal to the Frequent Transition value in Table 9-172.
The Length field is defined in 9.4.3.
963
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Frequent Transition
Subelement ID Length Count Threshold Time Interval
Octets: 1 1 1 2
Figure 9-357—Frequent Transition subelement format
The Frequent Transition Count Threshold field is a 1-octet field containing the number of transitions in the
measurement duration after which a Transition Event Report is generated.
The Time Interval field is the time interval in TUs during which the STA determines if the Frequent
Transition Count Threshold is exceeded.
9.4.2.67.3 RSNA event request
The Event Request field corresponding to an RSNA event request contains zero or more RSNA Event
Request subelements.
The subelement format and ordering of subelements are defined in 9.4.3. The set of valid RSNA Event
Request subelements is defined in Table 9-173.
Table 9-173—RSNA Event Request subelement
RSNA Event Request subelement Subelement ID
RSNA Target BSSID 0
Authentication Type 1
EAP Method 2
RSNA Result 3
Reserved 4–255
The RSNA subelements specify reporting conditions for RSNA Event Reports.
The RSNA Target BSSID subelement identifies the BSS at which an RSNA Event establishment was
attempted. Excluding this subelement from the Event Request element indicates a request for transition
events for all source BSSIDs. The format of the RSNA Target BSSID subelement is shown in
Figure 9-358.
Subelement ID Length Target BSSID
Octets: 1 1 6
Figure 9-358—RSNA Target BSSID subelement format
The Subelement ID field is equal to the RSNA Target BSSID value in Table 9-173.
The Length field is defined in 9.4.3.
The Target BSSID field contains a 6-octet BSSID.
964
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Authentication Type subelement is used to request that an RSNA Event Report includes the RSNA
event entry when the Authentication Type is equal to the authentication type specified in the Authentication
Type field. The format of the Authentication Type subelement is shown in Figure 9-359.
Subelement ID Length Authentication
Type
Octets: 1 1 4
Figure 9-359—Authentication Type subelement format
The Subelement ID field is equal to the Authentication Type value in Table 9-173.
The Length field is defined in 9.4.3.
The Authentication Type field contains one of the AKM suite selectors defined in Table 9-133 in 9.4.2.25.3.
The EAP Method subelement is used to request that an RSNA Event Report includes the RSNA event entry
when the EAP Method is equal to the EAP method specified in the EAP Method field. The format of the
EAP Method subelement is shown in Figure 9-360.
Subelement ID Length EAP Type EAP Vendor ID EAP Vendor
(optional) Type (optional)
Octets: 1 1 1 0 or 3 0 or 4
Figure 9-360—EAP Method subelement format
The Subelement ID field is equal to the EAP Method value in Table 9-173.
The Length field is defined in 9.4.3.
The EAP Type field contains a value that identifies a single EAP method and is any valid IANA assigned
EAP type.
The EAP Vendor ID field contains a value that identifies the EAP Vendor. The EAP Vendor ID field is
included when EAP Type field is 254 and is excluded otherwise.
The EAP Vendor Type field contains a value that identifies the EAP Type as defined by the vendor. The
EAP Vendor Type field is included when EAP Type field is 254 and is excluded otherwise.
The RSNA Result subelement is used to request that an RSNA Event Report includes the RSNA event entry
that matches the transition result defined by this subelement. The format of RSNA Result subelement is
shown in Figure 9-361.
Subelement ID Length Match Value
Octets: 1 1 1
Figure 9-361—RSNA Result subelement format
The Subelement ID field is equal to the RSNA Result value in Table 9-173.
The Length field is defined in 9.4.3.
965
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Match Value field bits are set as defined in Figure 9-362 to request that the specified RSNA results that
match that bit descriptions are included in the RSNA Event report.
B0 B1 B2-B7
Include Successful Include Failed Reserved
RSNA RSNA
Bits 1 1 6
Figure 9-362—Match Value field definitions
9.4.2.67.4 Peer-to-peer link event request
The Event Request field corresponding to peer-to-peer link event request contains zero or more Peer-to-Peer
Link Event Request subelements.
The Peer-to-Peer Link Event Request subelements are defined to have a common format consisting of a
1 octet Subelement ID field, a 1 octet Length field, and a variable-length subelement specific information
field. The set of valid Peer-to-Peer Link Event Request subelements is defined in Table 9-174.
Table 9-174—Peer-to-Peer Link Event Request subelement
Peer-to-Peer Link Event Request
Subelement ID
subelement
Peer Address 0
Channel Number 1
Reserved 2–255
The Peer-to-Peer Link subelements specify reporting conditions for peer-to-peer link event reporting.
The Peer Address subelement identifies the peer STA, BSS, or IBSS of the peer-to-peer links to be reported.
Excluding this subelement from the Event Request element indicates a request for peer-to-peer link events
for any peer STA, any BSS, and any IBSS. The format of the Peer Address subelement is shown in
Figure 9-363.
Peer STA/
Subelement ID Length BSSID Address
Octets: 1 1 6
Figure 9-363—Peer Address subelement format
The Subelement ID field is equal to the Peer Address value in Table 9-174.
The Length field is defined in 9.4.3.
966
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Peer STA/BSSID Address field contains a 6-octet MAC address of a peer STA or a BSSID for peer-to-
peer links in an IBSS. If the indicated address matches the Address 1 field of the MAC header contents (see
Table 9-26), then the address is a peer STA address for a TDLS or IBSS. If the indicated address matches
the Address 3 field of the MAC header contents, then the address is a BSSID for the Direct Link in an
infrastructure BSS or for the IBSS.
The Channel Number subelement(s) identify the channel for the peer-to-peer links to be reported. Excluding
this subelement from the Event Request element indicates a request for peer-to-peer link events for any
channel. The format of the Channel Number subelement is shown in Figure 9-364. The identified channel is
indicated by N+1 Channel Number subelements where the first N subelements contain an Operating Class
octet with an 80+ behavior limit and the last subelement contains an Operating Class octet without an 80+
behavior limit (as defined in Annex E).
Subelement ID Length Operating Class Channel
Number
Octets: 1 1 1 1
Figure 9-364—Channel Number subelement format
The Subelement ID field is equal to the Channel Number value in Table 9-174.
The Length field is defined in 9.4.3.
The Operating Class field indicates the channel set of the peer-to-peer link to be used for the Peer-to-Peer
Link event report. Operating Classes are defined in Annex E.
The Channel Number field indicates the channel number or (if the corresponding operating class in Annex E
has “—” in the channel set column) the center frequency index of the frequency segment containing the
primary channel of the peer-to-peer link events requested and included in the peer-to-peer link event report.
A Channel Number of 0 in all N+1 Channel Number subelements indicates a request to report any peer-to-
peer link event for any supported channel in the specified filtering Operating Class.
9.4.2.67.5 Vendor Specific event request
The Event Request field corresponding to Vendor Specific event request contains zero or more Vendor
Specific subelements. The Vendor Specific subelement has the same format as the Vendor Specific element
(see 9.4.2.26).
9.4.2.68 Event Report element
9.4.2.68.1 Event Report Definition
The Event Report element is used by a STA to report an event. The format of the Event Report element is
shown in Figure 9-365.
967
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Event Report
Element ID Length Event Token Event Type Status
Octets: 1 1 1 1 1
Event TSF Event Time
UTC Offset Event Report
(optional) (optional) Error (optional)
(optional)
Octets: 0 or 8 0 or 10 0 or 5 variable
Figure 9-365—Event Report element format
The Element ID and Length fields are defined in 9.4.2.1.
The Event Token field is the Event Token in the corresponding Event Request element. If the Event Report
element is being sent autonomously then the Event Token is 0.
The Event Type field is a number that identifies the type of event report. The Event Types are shown in
Table 9-171.
The Event Report Status field is a value in Table 9-175, indicating the STA’s response to the Event Request.
Table 9-175—Event Report Status
Event Report
Description
Status
0 Successful
1 Request failed
2 Request refused
3 Request incapable
4 Detected frequent transition
5–255 Reserved
The Event TSF, UTC Offset, Event Time Error, and Event Report fields are present only when the Event
Report Status field is 0.
The Event TSF field is TSF value when the STA logged the event.
The UTC Offset field is the UTC value that corresponds to the UTC time when the TSF timer is equal to 0.
If the UTC Offset is unknown, the field is 0.
The Event Time Error field is the UTC standard deviation, as described in 9.4.2.61, that corresponds to the
TSF value logged for the event. If the Event Time Error is unknown, the field is 0.
The Event Report field contains the specification of a single event report, as described in 9.4.2.68.2 to
9.4.2.68.5.
968
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Event Report element is included in an Event Report frame, as described in 9.6.14.3. The use of the
Event Report element and frame is described in 11.24.2.
9.4.2.68.2 Transition event report
The format of the Event Report field corresponding to a Transition event report is shown in Figure 9-366.
Source BSSID Target BSSID Transition Time Transition Transition
Reason Result
Octets: 6 6 2 1 2
Source RCPI Source RSNI Target RCPI Target RSNI
Octets: 1 1 1 1
Figure 9-366—Event Report format for Transition event
The Source BSSID field contains the 6-octet BSSID address of the associated AP prior to the attempted
transition.
The Target BSSID field contains the 6-octet BSSID address of the AP that is the target of the attempted
Transition.
The Transition Time field contains the transition time in TUs. The transition time is defined in 11.24.2.2.
The Transition Reason field indicates the reason why a transition attempt occurred and contains one of the
values in Table 9-176.
Table 9-176—Transition and Transition Query reasons
Transition Reason value Description
0 Unspecified
1 Excessive frame loss rates and/or poor conditions
2 Excessive delay for current traffic streams
3 Insufficient QoS capacity for current traffic streams (TSPEC rejected)
4 First association to ESS (the association initiated by an Association
Request frame instead of a Reassociation Request frame)
5 Load balancing
6 Better AP found
7 Deauthenticated or Disassociated from the previous AP
8 AP failed IEEE 802.1X EAP Authentication
9 AP failed 4-way handshake
10 Received too many replay counter failures
11 Received too many data MIC failures
969
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-176—Transition and Transition Query reasons (continued)
Transition Reason value Description
12 Exceeded maximum number of retransmissions
13 Received too many broadcast disassociations
14 Received too many broadcast deauthentications
15 Previous transition failed
16 Low RSSI
17 Roam from a non-IEEE-802.11 system
18 Transition due to received BSS Transition Request frame
19 Preferred BSS transition candidate list included
20 Leaving ESS
21–255 Reserved
The Transition Result field contains the result of the attempted transition and is one of the status codes
specified in Table 9-46 in 9.4.1.9.
The Source RCPI field indicates the received channel power of the most recently measured frame from the
Source BSSID before the STA reassociates to the Target BSSID. The Source RCPI is a logarithmic function
of the received signal power, as defined in 9.4.2.38.
The Source RSNI field indicates the received signal-to-noise indication of the most recently measured frame
from the Source BSSID before the STA reassociates to the Target BSSID. The Source RSNI is a logarithmic
function of the signal-to-noise ratio, as defined in 9.4.2.41.
The Source BSSID, Source RCPI, and Source RSNI fields are set to 0 if the transition is initiated by an
Association Request frame.
The Target RCPI field indicates the received channel power of the first measured frame just after the STA
reassociates to the Target BSSID. If association with the Target BSSID failed, the Target RCPI field
indicates the received channel power of the most recently measured frame from the Target BSSID. The
Target RCPI is a logarithmic function of the received signal power, as defined in 9.4.2.38.
The Target RSNI field indicates the received signal-to-noise indication of the first measured frame just after
the STA reassociates to the Target BSSID. If association with the Target BSSID failed, the Target RCPI
field indicates the received signal-to-noise indication of the most recently measured frame from the Target
BSSID. The Target RSNI is a logarithmic function of the signal-to-noise ratio, as defined in 9.4.2.41.
970
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.68.3 RSNA event report
The format of the Event Report field corresponding to an RSNA event report is shown in Figure 9-367.
Target BSSID Authentication EAP Method RSNA Result RSNE
Type
Octets: 6 4 1 or 8 2 variable
Figure 9-367—Event Report format for RSNA event
The Target BSSID field contains the 6-octet BSSID address of the AP accepting the authentication attempt.
The Authentication Type field contains the Authentication type in use at the time of the authentication
attempt and is one of the AKM suite selectors defined in Table 9-133 in 9.4.2.25.3.
When the Authentication Type field is the value of either 00-0F-AC:1 (Authentication negotiated over IEEE
Std 802.1X or using PMKSA caching as defined in 12.6.10.3) or 00-0F-AC:3 (AKM suite selector for fast
BSS transition as defined in 12.6.3), the EAP Method field contains the IANA assigned EAP type. The EAP
type contains either the legacy type (1 octet) or the expanded type (1 octet type = 254, 3-octet Vendor ID, 4-
octet Vendor-Type). The EAP Method field is 0 otherwise. The EAP Method field is a single octet set to 0
otherwise.
The RSNA Result field contains the result of the RSNA establishment attempt and is one of the status codes
specified in Table 9-46 in 9.4.1.9.
The RSNE field contains the entire contents of the negotiated RSNE at the time of the authentication
attempt. The maximum length of the RSNE field is less than the maximum length of an RSNE, as defined in
9.4.2.25. If the length of the RSNE included here exceeds the maximum length of the RSNE field, the RSNE
is truncated to the maximum length allowed for the RSNE field.
9.4.2.68.4 Peer-to-peer link event report
The format of the Event Report field corresponding to a Peer-to-Peer Link event report is shown in
Figure 9-368.
Peer STA/ Operating Channel STA Tx Connection
BSSID Peer Status
Address Class Number Power Time
Octets: 6 1 1 1 3 1
Figure 9-368—Event Report format for peer-to-peer link event
A peer-to-peer link is defined to be either a Direct Link within a QoS BSS, a TDLS, or a STA-to-STA
communication in an IBSS.
The Peer STA/BSSID Address field contains a 6-octet MAC address. If this event is for a peer-to-peer link
in an infrastructure BSS, this field contains the MAC address of the peer STA. If this event is for a peer-to-
peer link in an IBSS, this field contains the BSSID of the IBSS.
The Operating Class field indicates the channel set of the Peer-to-Peer link. Valid values of the Operating
Class are shown in Annex E.
971
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Channel Number field indicates the peer-to-peer channel number of the peer-to-peer link. The Channel
Number is defined within an Operating Class as shown in Annex E.
The STA Tx Power field indicates the target transmit power at the antenna (i.e., EIRP) in dBm with a
tolerance of ± 5 dB of the lowest basic rate of the reporting STA.
The Connection Time field contains the connection time in seconds. If the Peer Status is 0, this field
indicates the duration of the Direct Link. If the Peer Status is 1, this field indicates the time difference from
the time the Direct Link was established to the time at which the reporting STA generated the event report. If
the Peer Status is 2, this field indicates the duration of the IBSS membership. If the Peer Status is 3, this field
indicates the time difference from the time the STA joined the IBSS to the time at which the reporting STA
generated the event report. See 11.24.2.4.
The Peer Status field indicates the Peer link connection status as indicated in Table 9-177.
Table 9-177—Peer Status definitions
Peer Status Description
0 Direct Link terminated
1 Direct Link active
2 IBSS membership terminated
3 IBSS membership active
4–255 Reserved
9.4.2.68.5 WNM log event report
The format of the Event Report field corresponding to a WNM log event report is shown in Figure 9-369.
WNM Log Msg
Octets: variable
Figure 9-369—Event Report format for WNM log event
The WNM Log Msg field contains the entire syslog message, consisting of the PRI, HEADER, and MSG
portion of a WNM log message as described in IETF RFC 5424. The TAG field of the MSG portion of the
message is a 17 octet string containing the ASCII representation of the STA MAC address using
hexadecimal notation with colons between octets. The octet containing the Individual/Group bit occurs last,
and that bit is in the least significant position within that octet. See 11.24.2.5.
NOTE—For example, the TAG field for a STA with MAC address AC-DE-48-12-7B-80 is "80:7B:12:48:DE:AC" or
"80:7b:12:48:de:ac".
9.4.2.68.6 Vendor Specific event report
The Event Report field corresponding to Vendor Specific event report contains zero or more Vendor
Specific subelements. The Vendor Specific subelement has the same format as the Vendor Specific element
(see 9.4.2.26).
972
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.69 Diagnostic Request element
9.4.2.69.1 Diagnostic Request definition
The Diagnostic Request element contains a request that the receiving STA undertake the specified diagnos-
tic action. The format of the Diagnostic Request element is shown in Figure 9-370.
Diagnostic Diagnostic Diagnostic Diagnostic
Element ID Length Subelements
Token Request Type Timeout (optional)
Octets: 1 1 1 1 2 variable
Figure 9-370—Diagnostic Request element format
The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 4 (based
on a minimum length for the Diagnostic Subelements field of 0 octets).
The Diagnostic Token field is a number that is unique among the Diagnostic Request elements sent to each
destination MAC address for which a corresponding Diagnostic Report element has not been received.
The Diagnostic Request Type field is a number that identifies a type of diagnostic request. The values of
Diagnostic Request Types are shown in Table 9-178.
Table 9-178—Diagnostic Request/Report Type definitions
Name Diagnostic Type values
Cancel Diagnostic Request 0
Manufacturer Information STA Report 1
Configuration Profile 2
Association Diagnostic 3
IEEE 802.1X Authentication Diagnostic 4
Reserved 5–220
Vendor Specific 221
Reserved 222–255
The Diagnostic Timeout field contains the time, in seconds, after which no response is returned.
The Diagnostic Subelements field contains zero or more diagnostic subelements depending on the specific
Diagnostic Request Type, as defined in 9.4.2.69.2 to 9.4.2.69.4.
The Cancel Diagnostic Request, Manufacturer Information STA Report, and Configuration Profile
Diagnostic Request elements carry no Diagnostic subelements.
The Diagnostic Request element is included in a Diagnostic Request frame, as described in 9.6.14.4. The use
of Diagnostic Request element and frames is described in 11.24.3.
973
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.69.2 Association Diagnostic request
The Diagnostic Subelements field corresponding to an Association Diagnostic request type is shown in
Table 9-179. The corresponding Diagnostic subelements are defined in 9.4.2.69.5.
Table 9-179—Association Diagnostic request contents
Order Subelement
1 AP Descriptor
2 Profile ID
9.4.2.69.3 IEEE 802.1X Authentication Diagnostic request
The Diagnostic Subelements field corresponding to an IEEE 802.1X Authentication Diagnostic request type
is shown in Table 9-180. The corresponding Diagnostic subelements are defined in 9.4.2.69.5.
Table 9-180—IEEE 802.1X Authentication Diagnostic request contents
Order Subelement
1 AP Descriptor
2 EAP Method
3 Credential Type
4 Profile ID
9.4.2.69.4 Vendor Specific diagnostic request
The Diagnostic Subelements field corresponding to a Diagnostic Request element of type Vendor Specific
diagnostic request contains zero or more Vendor Specific subelements. The Vendor Specific subelements
have the same format as their corresponding elements (see 9.4.2.26).
9.4.2.69.5 Diagnostic subelement descriptions
The following text describes the various subelements that are optionally included in Diagnostic Subelements
field of a Diagnostic Request element (9.4.2.69) or a Diagnostic Report element (9.4.2.70). The format of a
Diagnostic subelement is shown in Figure 9-371.
Diagnostic Subelement Length Diagnostic Subelement
ID Contents
Octets: 1 1 variable
Figure 9-371—Diagnostic subelement format
974
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Diagnostic Subelement ID field indicates the Diagnostic subelement ID and is any allocated value in
Figure 9-181.
Table 9-181—Diagnostic subelement ID values
Subelement ID Subelement name
0 Credential Type
1 AKM Suite
2 AP Descriptor
3 Antenna Type
4 Cipher Suite
5 Collocated Radio Type
6 Device Type
7 EAP Method
8 Firmware Version
9 MAC Address
10 Manufacturer ID String
11 Manufacturer Model String
12 Manufacturer OI
13 Manufacturer Serial Number String
14 Power Save Mode
15 Profile ID
16 Supported Operating Classes
17 Status Code
18 SSID
19 Tx Power Capability
20 Certificate ID
21–220 Reserved
221 Vendor Specific
221–255 Reserved
The Length field is the length in octets of the Diagnostic Subelement Contents field.
The values of the Diagnostic Subelement Contents field are described in the following paragraphs.
The format for the Credential Type subelement is shown in Figure 9-372.
975
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Credential
Subelement ID Length Values
Octets: 1 1 variable
Figure 9-372—Credential Type subelement format
The Credentials Values field indicates one or more types of credential. Each value is chosen from those
shown in Table 9-182.
Table 9-182—Credentials values
Value Description
0 None
1 Preshared key
2 Username and password
3 X.509 certificate
4 Other certificate
5 One time password
6 Token
7–255 Reserved
The format for the AKM Suite subelement is shown in Figure 9-373.
Subelement ID Length OUI AKM Suite
Octets: 1 1 3 1
Figure 9-373—AKM Suite subelement format
The OUI and AKM Suite fields identify the authentication method, and the AKM suite selector is one of the
values in Table 9-133 in 9.4.2.25.3.
The format of the AP descriptor subelement is described in Figure 9-374.
Subelement ID Length BSSID Operating Class Channel
Number
Octets: 1 1 6 1 1
Figure 9-374—AP Descriptor subelement format
The set of current operating classes and channel widths of the AP is indicated by N+1 AP descriptor
subelements where the first N subelements contain an Operating Class octet with an 80+ behavior limit and
the last subelement contains an Operating Class octet without an 80+ behavior limit (as defined in Annex E).
NOTE—An 80+80 MHz AP sends four AP descriptor subelements for 20/40 MHz, 80 MHz, 80+ MHz (for the
secondary 80 MHz frequency segment), and 80 MHz (for the primary 80 MHz frequency segment).
976
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The BSSID field is a 6-octet field, as described in 9.2.4.3.4, that identifies the BSS indicated in the AP
Descriptor subelement.
The Operating Class field contains an enumerated value from Annex E that identifies the mapping from
Channel Number to frequency.
The Channel Number field indicates a current operating channel or (if the corresponding operating class in
Annex E has “—” in the channel set column) the center frequency index of the frequency segment containing
the primary channel, of the AP identified by the BSSID in the AP Descriptor.
The format for the Antenna Type subelement is shown in Figure 9-375.
Subelement ID Length Antenna Count Antenna Gain Antenna Type
Octets: 1 1 1 1 variable
Figure 9-375—Antenna Type subelement format
The Antenna Count field contains a 1-octet field indicating the number of antennas of the indicated antenna
type and antenna gain pair. The Antenna Count field value 0 is reserved.
The Antenna Gain field contains the peak gain, in dBi, of the antenna.
The Antenna Type field contains an ASCII string (truncated to 251 octets if required) describing the
manufacturer’s type information (i.e., a series of letters/numbers) of the antenna(s) connected to the wireless
adapter.
NOTE—Beamforming antennas might have several Antenna IDs, depending on antenna bearing.
The format for the Cipher Suite subelement is shown in Figure 9-376.
Subelement ID Length OUI Suite Type
Octets: 1 1 3 1
Figure 9-376—Cipher Suite subelement format
The OUI and Suite Type fields identify the cipher suite, and the cipher suite selector is one of the values in
Table 9-131.
The format for the Collocated Radio Type subelement is shown in Figure 9-377.
Collocated
Subelement ID Length Radio Type
Octets: 1 1 1
Figure 9-377—Collocated Radio Type subelement format
The Collocated Radio Type subelement contains a 1-octet field indicating the type of collocated radio and is
one of the values in Table 9-183. The method that a STA uses to obtain the information on the Collocated
Radio is out of the scope of this standard.
977
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-183—Collocated Radio Type
Collocated Radio Type Value
Reserved 0
Cellular 1
Cordless 2
GPS 3
IEEE 802.11™ 4
IEEE 802.15™ 5
IEEE 802.16™ 6
IEEE 802.20™ 7
IEEE 802.22™ 8
Digital Audio Broadcasting 9
Digital Video Broadcasting 10
Reserved 11–255
The Device Type subelement reports the type of device in which the IEEE 802.11 STA resides. The format
of the Device Type subelement is shown in Figure 9-378.
Subelement ID Length Device Type
Octets: 1 1 1
Figure 9-378—Device Type subelement format
The Device Type field is a 1-octet field indicating the category of device.27 The numerical assignment to
each device type category is defined in Table 9-184.
Table 9-184—Device Type definitions
Device Type Value
Reserved 0
Reference Design 1
Access Point or Wireless Router for Home or Small Office 2
Enterprise Access Point 3
Cable, DSL or Other Broadband Gateway 4
Digital Still Camera 5
27
The category of device is based on the Wi-Fi Alliance category definitions found at http://www.wi-fi.org/knowledge_center/insist-
on-wifi-certified.
978
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-184—Device Type definitions (continued)
Device Type Value
Portable Video Camera 6
Networked Web Camera 7
Digital Audio—Stationary 8
Digital Audio—Portable 9
Set-Top Box, Media Extender, Media Server (includes players & recorders) 10
Display Device (television, monitor, picture frame) 11
Game Console or Game Console Adapter 12
Gaming Device —Portable 13
Media Server or Media Adapter 14
Network Storage Device 15
External Card 16
Internal Card 17
Ultra-Mobile PC 18
Notebook Computer 19
PDA (Personal Digital Assistant) 20
Printer or Print Server (includes scanner and/or fax capability) 21
Phone—Dual-Mode 22
Phone—Single-Mode 23
Smartphone—Dual-Mode 24
Smartphone—Single-Mode 25
Reserved 26-220
Other devices 221
Reserved 222–255
The format for the EAP Method subelement is shown in Figure 9-379.
EAP Vendor ID EAP Vendor
Subelement ID Length EAP Type (optional) Type (optional)
Octets: 1 1 1 0 or 3 0 or 4
Figure 9-379—EAP Method subelement format
The EAP Type field contains a value that identifies a single EAP method and is any valid IANA assigned
EAP type.
979
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The EAP Vendor ID field contains a value that identifies the EAP Vendor. The EAP Vendor ID field is
included when EAP Type field is 254 and is excluded otherwise.
The EAP Vendor Type field contains a value that identifies the EAP Type as defined by the vendor. The
EAP Vendor Type field is included when EAP Type field is 254 and is excluded otherwise.
The format for the Firmware Version subelement is shown in Figure 9-380.
Subelement ID Length Firmware
Version
Octets: 1 1 variable
Figure 9-380—Firmware Version subelement format
This Firmware Version field contains an ASCII string identifying the version of firmware currently installed
on the wireless network adaptor.
The format for the MAC Address subelement is shown in Figure 9-381.
Subelement ID Length MAC Address
Octets: 1 1 6
Figure 9-381—MAC Address subelement format
This MAC Address field contains the 6-octet IEEE 802 MAC address of the STA.
The format for the Manufacturer ID String subelement is shown in Figure 9-382.
Subelement ID Length ID
Octets: 1 1 variable
Figure 9-382—Manufacturer ID String subelement format
The ID field contains an ASCII string indicating the manufacturer identifier of the wireless network adaptor.
The format for the Manufacturer Model String subelement is shown in Figure 9-383.
Subelement ID Length Model
Octets: 1 1 variable
Figure 9-383—Manufacturer Model String subelement format
The Model field contains an ASCII string indicating the model of the wireless network adaptor.
The format for the Manufacturer OI subelement is shown in Figure 9-384.
980
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Subelement ID Length OI
Octets: 1 1 3 or 5
Figure 9-384—Manufacturer OI subelement format
The OI field contains an organization identifier, as defined in 9.4.1.32.
The format for the Manufacturer Serial Number String subelement is shown in Figure 9-385.
Subelement ID Length Serial Number
Octets: 1 1 variable
Figure 9-385—Manufacturer Serial Number String subelement format
The Serial Number field contains an ASCII string indicating the serial number of the wireless network
adaptor.
The format for the Power Save Mode subelement is shown in Figure 9-386.
Power Save
Subelement ID Length
Mode
Octets: 1 1 4
Figure 9-386—Power Save Mode subelement format
The Power Save Mode field is a bitmap field that indicates the power save mode(s) in use by the STA, as
defined in Table 9-185.
Table 9-185—Power Save Mode definition
Power Save Mode Bit
Unknown 0
None 1
PS mode (ReceiveDTIMs=1, see 11.2.3) 2
PS mode (ReceiveDTIMs=0, see 11.2.3) 3
U-APSD (see 11.2.3.5) 4
S-APSD (see 11.2.3.5) 5
U-PSMP (see 10.29 6
S-PSMP (see 10.29) 7
SM power save (see 11.2.6) 8
WNM sleep mode (see 11.2.3.18) 9
FMS (see 11.2.3.16) 10
TIM broadcast (see 11.2.3.17) 11
981
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-185—Power Save Mode definition (continued)
Power Save Mode Bit
TFS (see 11.24.12) 12
TPU (see 11.2.3.15) 13
TDLS peer PSM (see 11.2.3.14) 14
TXOP power save mode 15
Reserved 16–31
The format for the Profile ID subelement is shown in Figure 9-387.
Subelement ID Length Profile ID
Octets: 1 1 1
Figure 9-387— Profile ID subelement format
The Profile ID field contains a unique identifier for referencing a configuration profile available on a device.
The value of the identifier is uniquely associated to a single configuration profile on the device sending the
identifier.
The format for the Supported Operating Classes subelement is shown in Figure 9-388.
Subelement ID Length Supported Operating Classes Element
Octets: 1 1 variable
Figure 9-388—Supported Operating Classes subelement format
The Supported Operating Classes Element field contains the Supported Operating Classes element, as
defined in 9.4.2.54.
The format for the Status Code subelement is shown in Figure 9-389.
Subelement ID Length Status Code
Octets: 1 1 2
Figure 9-389—Status Code subelement format
The Status Code field contains the final IEEE 802.11 Status code, as defined in Table 9-46 in 9.4.1.9,
received at the end of the applicable operation.
982
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The format for the SSID subelement is shown in Figure 9-390.
Subelement ID Length SSID
Octets: 1 1 0 to 32
Figure 9-390—SSID subelement format
The SSID field contains a Service Set Identifier with a maximum length of 32 octets, as defined in 9.4.2.2.
The format for the Tx Power Capability subelement is shown in Figure 9-391.
Subelement ID Length Tx Power Mode Tx Power
Octets: 1 1 1 variable
Figure 9-391—Tx Power Capability subelement format
The Tx Power Mode field identifies the transmit power mode of the non-AP STA and is one of the values in
Table 9-186.
Table 9-186—Tx Power Modes
Tx Power Mode Value
Discrete 0
Range 1
Reserved 2–255
The Tx Power field indicates the target transmit power level(s) at the antenna(s) (i.e., EIRP), where the
actual power is within ±5 dB to the target. Each transmit power level is encoded in a single octet as a 2s
complement value in dBm, rounded to the nearest integer. If the Tx Power Mode field is 0 then the Tx Power
field contains one or more transmit power levels in increasing numerical order. If the Tx Power Mode field
is 1, the Tx Power field contains the STA’s minimum and nonzero maximum transmit power levels, in that
order.
The format for the Certificate ID subelement is shown in Figure 9-392.
Subelement ID Length Certificate ID
Octets: 1 1 variable
Figure 9-392—Certificate ID subelement format
The Certificate ID field contains an UTF-8 string indicating an identifier assigned to the STA in a manner
outside the scope of the standard. The Certificate ID typically takes the form of “WFA3991” and might be
used by a receiving STA to look up the certificate assigned to that ID.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
983
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.70 Diagnostic Report element
9.4.2.70.1 Diagnostic report definition
The Diagnostic Report element contains a Diagnostic report. The format of the Diagnostic Report element is
shown in Figure 9-393.
Element Length Diagnostic Diagnostic Diagnostic Diagnostic Subelements
ID Token Report Type Status
Octets: 1 1 1 1 1 variable
Figure 9-393—Diagnostic Report element format
The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 3.
The Diagnostic Token field is the Diagnostic Token in the corresponding Diagnostic Request element.
The Diagnostic Report Type field is a number that identifies the Diagnostic report. The Diagnostic Report
Types are defined in Table 9-178.
The Diagnostic Status field is a value in Table 9-175 (see 9.4.2.68), indicating the STA’s response to the
diagnostic request indicated by the diagnostic token.
The Diagnostic Subelements field contains the results of the diagnostic request.
The Diagnostic Subelements field contains the diagnostic subelement values, defined in 9.4.2.69.5
corresponding to the Diagnostic Report Type field value.
The Diagnostic Report element is included in a Diagnostic Report frame, as described in 9.6.14.5. The use
of Diagnostic Report element and frames is described in 11.24.3.
9.4.2.70.2 Manufacturer Information STA Report
The contents of the Diagnostic Subelements field of a Diagnostic Report element of type Manufacturer
Information STA Report is shown in Table 9-187. The corresponding Diagnostic subelements are defined in
9.4.2.69.5.
Table 9-187—Manufacturer Information STA report contents
Order Subelement
1 Manufacturer OI
2 Manufacturer ID string
3 Manufacturer model string
4 Manufacturer serial number string
6 Firmware Version
7 Antenna Type
984
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-187—Manufacturer Information STA report contents (continued)
Order Subelement
8 Collocated Radio Type
9 Device Type
10 Certificate ID
9.4.2.70.3 Configuration Profile report
The contents of the Diagnostic Subelements field of a Diagnostic Report element of type Configuration
Profile is shown in Table 9-188. The corresponding Diagnostic subelements are defined in 9.4.2.69.5.
Table 9-188—Configuration Profile report contents
Order Subelement
1 Profile ID
2 Supported Operating Classes
3 Tx Power
4 Cipher Suite
5 AKM Suite
6 EAP Method
7 Credential Type
8 SSID
9 Power Save Mode
9.4.2.70.4 Association Diagnostic report
The contents of the Diagnostic Subelements field of a Diagnostic Report element of type Association
Diagnostic is shown in Table 9-189. The corresponding Diagnostic subelements are defined in 9.4.2.69.5.
Table 9-189—Association Diagnostic report contents
Order Subelement
1 AP Descriptor
2 Status Code
985
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.70.5 IEEE 802.1X Authentication Diagnostic report
The contents of the Diagnostic Subelements field of a Diagnostic Report element of type IEEE 802.1X
Authentication Diagnostic is shown in Table 9-190. The corresponding Diagnostic subelements are defined
in 9.4.2.69.5.
Table 9-190—IEEE 802.1X Authentication Diagnostic report contents
Order Subelement
1 AP Descriptor
2 EAP Method
3 Credential Type
4 Status Code
9.4.2.70.6 Vendor Specific diagnostic report
The contents of the Diagnostic subelements field of a Diagnostic Report element of type Vendor Specific
contains zero or more Vendor Specific subelements that have the same formats as Vendor Specific elements
in 9.4.2.26.
9.4.2.71 Location Parameters element
9.4.2.71.1 Location Parameters definition
The Location Parameters element is used for location services. The format of this element is shown in
Figure 9-394.
Element ID Length Location Subelements
Octets: 1 1 variable
Figure 9-394—Location Parameters element format
The Element ID and Length fields are defined in 9.4.2.1.
The Location Subelements field contains one or more Location subelements described in Table 9-191.
Table 9-191—Optional subelement IDs for Location Parameters
Subelement
Subelement name
ID
1 Location Indication Parameters (see 9.4.2.71.2)
2 Location Indication Channels (see 9.4.2.71.3)
3 Location Status (see 9.4.2.71.4)
4 Radio (see 9.4.2.71.5)
986
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-191—Optional subelement IDs for Location Parameters (continued)
Subelement
Subelement name
ID
5 Motion (see 9.4.2.71.6)
6 Location Indication Broadcast Data Rate (see 9.4.2.71.7)
7 Time of Departure (see 9.4.2.71.8)
8 Location Indication Options (see 9.4.2.71.9)
9–220 Reserved
221 Vendor Specific (see 9.4.2.26)
222–255 Reserved
The Location Parameters element is included in Location Configuration Request frames, as described in
9.6.14.6; Location Configuration Response frames, as described in 9.6.14.7; and Location Track
Notification frames, as described in 9.6.8.17. The use of the Location Parameters element is described in
11.24.4.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
Multiple Vendor Specific subelements are optionally present in the list of Optional subelements.
9.4.2.71.2 Location Indication Parameters subelement
The Location Indication Parameters subelement contains STA location reporting characteristics. The format
of the Location Indication Parameters subelement is shown in Figure 9-395.
Normal
Indication Report Normal Number of
Subelement ID Length Multicast Report
Address Interval Units Interval Frames per
Channel
Octets: 1 1 6 1 2 1
In-Motion
In-Motion Number of Burst Tracking ESS
Inter-frame Detection
Report Interval Frames per Interval Duration Interval
Channel
Octets: 2 1 1 1 1
Figure 9-395—Location Indication Parameters subelement
The Subelement ID field is defined in Table 9-191.
The Length field is defined in 9.4.3.
Except in Location Track Notification frames sent in an IBSS, the Indication Multicast Address field
specifies the destination address to which the Location Track Notification frames are sent. The value of this
field is a locally administered group address formed according to the procedure defined in 11.24.4.1. The
field is reserved when Location Track Notification frames are transmitted in an IBSS.
987
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Report Interval Units field contains the units used for the Normal Report Interval field and In-Motion
Report Interval field, as indicated in Table 9-192.
Table 9-192—Report Interval Units field
Report Interval Units Description
0 Hours
1 Minutes
2 Seconds
3 Milliseconds
4–255 Reserved
The Normal Report Interval is the time interval, expressed in the units indicated in the Report Interval Units
field, at which the reporting STA is expected to transmit one or more Location Track Notification frames if
either dot11MotionDetectionActivated is false or the STA is stationary. The STA does not transmit Location
Track Notification frames when the Normal Report Interval is 0.
The Normal Number of Frames per Channel is the number of Location Track Notification frames per
channel sent or expected to be sent by the STA at each Normal Report Interval.
Motion is the act or process of moving, or a particular action or movement relative to the point at which the
STA is configured to send Location Track Notification frames. Motion might be detected using one of the
following criteria:
— Detection of speed that is greater or equal to 0.5 m/sec.
— Detection of movement or vibration, for example by a ball-in-tube sensor or accelerometer or other
means.
The exact criteria and mechanism to detect motion is out of scope for this standard.
The In-Motion Report Interval is the time interval, expressed in the units indicated in the Report Interval
Units field, at which the STA reports its location by sending a Location Track Notification frame when the
reporting STA is in motion. If dot11MotionDetectionActivated is false, this field is 0.
The In-Motion Number of Frames per Channel is the number of Location Track Notification frames per
channel sent or expected to be sent by the STA at each In-Motion Report Interval. If
dot11MotionDetectionActivated is false, this field is 0.
The Burst Inter-frame Interval is the target time interval, expressed in milliseconds, between the
transmissions of each of the Normal or In-Motion frames on the same channel. The Burst Inter-frame
interval value is 0 to indicate that frames are transmitted with no target inter-frame delay.
The Tracking Duration is the amount of time, in minutes, that a STA sends the Location Track Notification
frames. The duration starts as soon as the STA sends a Location Configuration Response frame with a
Location Status value of Success. If the Tracking Duration value is a nonzero value the STA sends Location
Track Notification frames, based on the Normal and In-Motion Report Interval field values, until the
duration ends. If the Tracking Duration is 0 the STA continuously sends Location Track Notification frames
as defined by Normal and In-Motion Report Interval field values until transmission is terminated based on
the procedures detailed in 11.24.4.2.
988
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The ESS Detection Interval is the periodicity, in minutes, that a STA checks for beacons transmitted by one
or more APs belonging to the same ESS that configured the STA. If no beacons from the ESS are received
for this period, the STA terminates transmission of Location Track Notification frames, as described in the
procedures detailed in 11.24.4.2. The ESS Detection Interval field is not used when the ESS Detection
Interval field value is 0.
9.4.2.71.3 Location Indication Channels subelement
The Location Indication Channels subelement contains location reporting channel information. The format
of the Location Indication Channels subelement format is shown in Figure 9-396.
one or more
entries
Subelement Channel
ID Length Entry
Octets: 1 1 2xn
Figure 9-396—Location Indication Channels subelement
The Subelement ID field is defined in Table 9-191.
The Length field is defined in 9.4.3.
The Channel Entry field includes one or more Operating Class and Channel fields (see Figure 9-88).
The Operating Class subfield of the Operating Class and Channel field indicates the frequency band on
which a STA transmits Location Track Notification frames.
The Channel subfield of the Operating Class and Channel field indicates a channel number on which a STA
sends or an ESS expects to receive Location Track Notification frames.
The Operating Class and Channel fields can be grouped together to identify a noncontiguous channel. A
noncontiguous channel is indicated by a group of N+1 Operating Class and Channel fields where the first N
Operating Class and Channel fields contain an Operating Class subfield with an 80+ behavior limit and the
last Operating Class and Channel field in the group contains an Operating Class subfield without an 80+
behavior limit (as defined in Annex E).
9.4.2.71.4 Location Status subelement
The Location Status subelement provides the result of a Location Request or Location Configuration
Request frame. The format of the Location Status subelement is shown in Figure 9-397.
Config
Subelement ID Length Status
Subelement ID
Octets: 1 1 1 1
Figure 9-397—Location Status subelement
989
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Subelement ID field is defined in Table 9-191.
The Length field is defined in 9.4.3.
The Config Subelement ID field is a specific Location Parameters subelement ID transmitted in a Location
Configuration Request frame as defined in Table 9-191.
A Location Status subelement is included for each configuration subelement in the Location Configuration
Request frame, except when all status values are the same. When all status values are the same, one Location
Status subelement is included with the Config subelement ID set to 0 in the Location Configuration
Response frame.
The Status field identifies the result of the Location Request frame and is one of the values in Table 9-175.
9.4.2.71.5 Radio subelement
The Radio subelement contains radio information. The format of the Radio subelement is shown in Figure 9-
398.
Subelement Length Transmit Antenna Antenna RSNI RCPI
ID Power ID Gain
Octets: 1 1 1 1 1 1 1
Figure 9-398—Radio subelement
The Subelement ID field is defined in Table 9-191.
The Length field is defined in 9.4.3.
The Transmit Power field is the transmit power used to transmit the current Location Track Notification
frame containing the Location Parameters element with the Radio subelement and is a signed integer, 1 octet
in length, reported as an EIRP in dBm. A value of –128 indicates that the transmit power is unknown. The
tolerance for the transmit power value reported in the Radio subelement is ± 5 dB. This tolerance is defined
as the maximum possible difference, in decibels, between the reported power value and the total transmitted
power across all antennas of the STA, which are measured when transmitting Location Request frames.
The Antenna ID field is the identifying number for the antenna used to transmit the Location Request frame.
The Antenna ID is defined in 9.4.2.40.
The Antenna Gain field is the antenna gain of the antenna (or group of antennas) over which the Location
Track Notification frame is transmitted and is a signed integer, 1 octet in length, reported in dB. A value of –
128 indicates that the antenna gain is unknown.
The RSNI field contains the RSNI value measured against the most recently received Location
Configuration Request frame requesting that a Radio subelement be included in the Location Track
Notification frame. The RSNI value is defined in 9.4.2.41. A value of 255 indicates that the RSNI value is
unknown or is not used.
The RCPI field contains the RCPI value measured against the most recently received Location
Configuration Request frame requesting that a Radio subelement be included in the Location Track
Notification frame. The RCPI value is defined in 9.4.2.38. A value of 255 indicates that the RCPI value is
unknown or is not used.
990
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.71.6 Motion subelement
The Motion subelement contains motion information. The format of the Motion subelement is shown in
Figure 9-399.
Subelement Length Motion Bearing Speed Horizontal Vertical
ID Indicator Units Speed Speed
Octets: 1 1 1 2 1 2 2
Figure 9-399—Motion subelement
The Subelement ID field is defined in Table 9-191.
The Length field is defined in 9.4.3.
The Motion Indicator field is defined in Table 9-193. The mechanism that a STA uses to determine the value
or transitions from one value to another of the Motion Indicator field is beyond the scope of the standard.
Table 9-193—Motion Indicator field
Motion Indicator value Description
0 Stationary: the device is stationary and not in motion.
1 Start of motion: the device was stationary and is now in motion.
2 In motion: the device is and has been in motion.
3 End of motion: the device was in motion and is now stationary.
4 Unknown: information related to motion is unknown.
5–255 Reserved
The Bearing field, defined by a 2-octet unsigned integer, specifies the direction that the STA is traveling
with relation to true north, increasing clockwise, measured in degrees from 0° to 359°. If the Bearing value
is unknown, the field is 65 535.
The Speed Units field contains the units for both Horizontal and Vertical Speed field, as defined in
Table 9-194.
Table 9-194—Speed Units
Speed Units Value Description
0 Centimeters per second
1 Meters per second
2–255 Reserved
991
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Horizontal Speed field contains the horizontal speed of the STA expressed in the units indicated in the
Speed Units field. If the Horizontal Speed value is unknown, the field is 65 535.
The Vertical Speed field is a 2s complement signed integer indicating the vertical speed of the STA
expressed in the units indicated in the Speed Units field. If the Vertical Speed value is unknown or greater
than 32 766, the field is 32 767. If the Vertical Speed value is less than –32 767, the field is –32 768.
The Motion subelement field values are valid at the time of transmission of the Location Track Notification
frame containing the subelement.
9.4.2.71.7 Location Indication Broadcast Data Rate subelement
The Location Indication Broadcast Data Rate subelement contains location reporting transmission rate
information. The format of the Location Indication Broadcast Data Rate subelement format is shown in
Figure 9-400.
Subelement ID Length Broadcast Target Data Rate
Octets: 1 1 4
Figure 9-400—Location Indication Broadcast Data Rate subelement
The Subelement ID field is defined in Table 9-191.
The Length field is defined in 9.4.3.
The Broadcast Target Data Rate field specifies the target data rate at which the STA transmits Location
Track Notification frames. The Broadcast Target Data Rate field format is specified by the Rate
Identification field defined in 9.4.1.33. A value of 0 indicates the STA transmits Location Track Notification
frames at a rate chosen by the STA transmitting the Location Track Notification frames.
9.4.2.71.8 Time of Departure subelement
The Time of Departure subelement contains time of departure information for the Location Track
Notification frame including the subelement. The format of the Time of Departure subelement is shown in
Figure 9-401.
Subelement Length TOD TOD RMS TOD Clock
ID Timestamp Rate
Octets: 1 1 4 2 2
Figure 9-401—Time of Departure subelement
The Subelement ID field is defined in Table 9-191.
The Length field is defined in 9.4.3.
The TOD Timestamp field specifies when the first frame energy is sent by the transmitting port in units
equal to 1/TOD Clock Rate, where the TOD Clock Rate is specified in the TOD Clock Rate field. The
reported TOD timestamp value is determined from the TIME_OF_DEPARTURE parameter within the
PHY-TXSTART.confirm primitive.
992
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The TOD RMS field specifies the RMS time of departure error in units equal to 1/TOD Clock Rate, where
the TOD Clock Rate is specified in the TOD Clock Rate field, where the time of departure error equals the
difference between the TOD Timestamp field and the time of departure measured by a reference entity using
a clock synchronized to the start time and mean frequency of the local PHY entity’s clock. The TOD RMS
field is determined from aTxPHYTxStartRMS in units equal to 1/TOD Clock Rate, where the TOD Clock
Rate is specified in the TOD Clock Rate field.
The TOD Clock Rate field contains the clock rate used to generate the TOD timestamp value reported in the
TOD Timestamp field, and it is specified in units of MHz.
9.4.2.71.9 Location Indication Options subelement
The Location Indication Options subelement contains the options for the STA when transmitting the Loca-
tion Track Notification frame. The format of the Location Indication Options subelement is shown in
Figure 9-402.
Subelement Length Options Indication
ID Used Parameters
Octets: 1 1 1 variable
Figure 9-402—Location Indication Options subelement
The Subelement ID field is defined in Table 9-191.
The Length field is defined in 9.4.3.
The Options Used field specifies which Indication Parameter fields in the Location Indication Options
subelement are used. The format of the Options Used field is shown in Figure 9-403.
B0 B1 B7
Beacon Measurement
Mode Used Reserved
Bits: 1 7
Figure 9-403—Options Used field format
The Indication Parameters field defines a sequence of optional fields that are included in the Location
Indication Options subelement based on the Options Used field value. The value of the Indication
Parameters field is defined in Table 9-195.
Table 9-195—Indication Parameter values
Order Field length Field Description
1 1 Beacon The Beacon Measurement Mode field is the mode of
Measurement beacon measurement, as defined in Table 9-87. The
Mode results of the beacon measurement are included in the
Location Track Notification frame, as described in
9.6.8.17 and 11.24.4.2.
2–8 Reserved
993
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.72 Nontransmitted BSSID Capability element
The format of the Nontransmitted BSSID Capability element is shown in Figure 9-404.
DMG Nontransmitted
Nontransmitted BSSID DMG
Element ID Length BSSID Capability BSS Capabilities
Control
Element
Octets: 1 1 2 1 19
Figure 9-404—Nontransmitted BSSID Capability element format
When transmitted by a DMG STA, the Nontransmitted BSSID Capability element includes the DMG BSS
Control and the Nontransmitted BSSID DMG Capabilities Element fields. These fields are not present if this
element is transmitted by non-DMG STAs.
The Element ID and Length fields are defined in 9.4.2.1.
The Nontransmitted BSSID Capability field contains the contents of the Capability Information field in
beacons for the BSS when transmitted by a non-DMG STA. When transmitted by a DMG STA, the
Nontransmitted BSSID Capability field is reserved.
The Nontransmitted BSSID Capability element is included in the Nontransmitted BSSID Profile subelement
of the Multiple BSSID element defined in 9.4.2.46. The use of the Multiple BSSID element is described in
11.11.14 and Nontransmitted BSSID advertisement procedures are described in 11.1.3.8.
The DMG BSS Control field is defined in Figure 9-405.
B0 B1 B2 B7
BSS Type Reserved
Bits: 2 6
Figure 9-405—DMG BSS Control field format
The BSS Type field is as defined in 9.4.1.47.
The Nontransmitted BSSID DMG Capabilities Element field contains the DMG Capabilities element of the
DMG STA.
9.4.2.73 SSID List element
The format of the SSID List element is shown in Figure 9-406.
Element ID Length SSID List
Octets: 1 1 variable
Figure 9-406—SSID List element format
The Element ID and Length fields are defined in 9.4.2.1.
994
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SSID List field is a list of SSID elements for which the STA is requesting information.
The SSID List element is included in Probe Request frames, as described in 9.3.3.10. The use of the SSID
List element and frames is described in 11.1.4.
9.4.2.74 Multiple BSSID-Index element
The format of the Multiple BSSID-Index element is shown in Figure 9-407.
Element ID Length BSSID Index DTIM Period DTIM Count
(optional) (optional)
Octets: 1 1 1 0 or 1 0 or 1
Figure 9-407—Multiple BSSID-Index element format
The Element ID and Length fields are defined in 9.4.2.1. The value of the Length field is 1 octet when the
Multiple BSSID-Index element is included in the Probe Response frame and otherwise is three octets.
The BSSID Index field is a value between 1 and 2n– 1 that identifies the nontransmitted BSSID, where n is a
nonzero, positive integer value.
The DTIM Period field indicates the DTIM period for the BSSID. This field is not present when the
Multiple BSSID-Index element is included in the Probe Response frame.
The DTIM Count field indicates the DTIM count for the BSSID. This field is not present when the Multiple
BSSID-Index element is included in the Probe Response frame.
The Multiple BSSID-index element is included in the nontransmitted BSSID profile element, as described in
11.1.3.8. The use of the Multiple BSSID element and frames is described in 11.11.14.
9.4.2.75 FMS Descriptor element
The FMS Descriptor element defines information about group addressed BUs buffered at the AP. It is
present in the Beacon frames when dot11FMSActivated is true. The format of the FMS Descriptor element
is shown in Figure 9-408.
zero or more zero or more
FMS Counters FMSIDs
Number of FMS
Element ID Length FMS Counters FMSIDs
Counters
Octets: 1 1 1 n m
Figure 9-408—FMS Descriptor element format
The Element ID and Length fields are defined in 9.4.2.1.
The Number of FMS Counters field defines the number of FMS Counters fields that are contained in the
FMS Descriptor element.
The FMS Counters field contains zero or more FMS Counters. The format of the FMS Counter is shown in
Figure 9-409. When one or more FMS streams are accepted at the AP, at least one FMS counter is present in
the FMS Descriptor element. A maximum of eight FMS counters are permitted. The FMS counters are used
995
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
by the non-AP STA to identify the DTIM beacon after which group addressed BUs assigned to a particular
delivery interval are transmitted. A single FMS Counter is shared by all FMS streams that use the same
delivery interval.
B0 B2 B3 B7
FMS Counter ID Current Count
Bits: 3 5
Figure 9-409—FMS Counter format
The FMS Counter ID field is a 3- bit value that represents the counter ID assigned by the AP for a particular
FMS stream.
The Current Count field indicates how many DTIM Beacon frames (including the current one) appear before
the next DTIM Beacon frame after which the group addressed BUs assigned to a particular delivery interval
are scheduled to be transmitted.
The FMSIDs field contains zero or more FMSIDs. Each FMSID is a 1-octet identifier assigned by the AP.
Inclusion of an FMSID indicates the AP has buffered BUs for the corresponding group addressed stream
that is scheduled for transmission immediately after the DTIM Beacon frame.
The FMS Descriptor element is included in Beacon frames, as described in 9.3.3.3. The use of the FMS
Descriptor element and frames is described in 11.2.3.16.
9.4.2.76 FMS Request element
The FMS Request element defines information about the group addressed frames being requested by the
non-AP STA. The format of FMS Request element is shown in Figure 9-410.
Element ID Length FMS Token FMS Request
Subelements
Octets: 1 1 1 variable
Figure 9-410—FMS Request element format
The Element ID and Length fields are defined in 9.4.2.1.
The FMS Token field contains a unique identifier for the FMS Stream Set that is the set of FMS subelements
specified in the request. If this is a new request, then the FMS Token field is set to 0. Otherwise, the FMS
Token field is set to the value assigned by the AP in the FMS Response element.
The FMS Request Subelements field contains one or more FMS Request subelements described in Table 9-
196.
The format of the FMS subelement is shown in Figure 9-411.
The Subelement ID field is 1 to uniquely identify this subelement as the FMS subelement.
The Length field is defined in 9.4.3.
996
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-196—Optional subelement IDs for FMS Request subelements
Subelement ID Subelement name
0 Reserved
1 FMS subelement
2–220 Reserved
221 Vendor Specific subelement
222–255 Reserved
one or
more
TCLAS
Elements
TCLAS
Max
Subelement Length Delivery Delivery Rate FMSID TCLAS Processing
ID Interval Identification Elements Element
Interval (optional)
Octets: 1 1 1 1 4 1 variable 0 or 3
Figure 9-411—FMS subelement format
The Delivery Interval field defines the periodicity of stream transmission in units of DTIMs. The default
value is 1. The value set to 0 indicates that requesting non-AP STA does not use the FMS stream identified
by the TCLAS elements anymore.
The Max Delivery Interval field defines the maximum delivery interval the non-AP STA supports for the
requested stream in units of DTIMs. The value set to 0 indicates that the non-AP STA is willing to accept
any maximum delivery interval supported by the AP.
The Rate Identification field specifies the data rate as described in 9.4.1.33, at which the STA requests to
receive group addressed frames. If the STA does not request a particular multicast rate, the Rate
Identification field is 0.
The FMSID field contains a unique identifier for this stream. If this is a new request, the FMSID field is
reserved. Otherwise, the FMSID is set to the value assigned by the AP in the FMS Response element.
The TCLAS Elements field contains one or more TCLAS elements to specify the traffic filter as defined in
9.4.2.31. The number of TCLAS elements is limited and the total size of the FMS Request element is less
than or equal to 255 octets.
The TCLAS Processing Element field is optionally present and defines how multiple TCLAS elements are
processed as defined in 9.4.2.33.
The FMS Request element is included in FMS Request frames, as described in 9.6.14.11. The use of the
FMS Request element and frames is described in 11.2.3.16.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
997
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.77 FMS Response element
The FMS Response element provides information about the delivery of group addressed frames. The format
of the FMS Response element is shown in Figure 9-412.
Element ID Length FMS Token FMS Response
Subelements
Octets: 1 1 1 variable
Figure 9-412—FMS Response element format
The Element ID and Length fields are defined in 9.4.2.1.
The FMS Token field is assigned by the AP for the set of FMS streams that share the counter identified by
the FMS Counter ID maintained in the AP.
The FMS Response Subelements field contains one or more FMS Response subelements described in
Table 9-197.
Table 9-197—Optional subelement IDs for FMS Response subelements
Subelement ID Subelement name
0 Reserved
1 FMS Status subelement
2 TCLAS Status subelement
3–220 Reserved
221 Vendor Specific subelement
222–255 Reserved
The format of the FMS Status subelement is shown in Figure 9-413.
Max Rate
Subelement Element Delivery FMS Multicast
ID Length Status Interval Delivery FMSID Counter Identifica Address
Interval tion
Octets: 1 1 1 1 1 1 1 4 6
Figure 9-413—FMS Status subelement format
The Subelement ID field is 1 to uniquely identify this subelement as the FMS Status subelement.
The Length field is defined in 9.4.3.
The Element Status field indicates the status of STA’s requested delivery interval, as indicated in
Table 9-198, provided by the AP.
998
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-198—FMS Element Status and TFS Response Status definition
Value Description
0 Accept
1 Deny, due to request format error or ambiguous classifier.
2 Deny, due to lack of resources on the AP.
3 Deny, due to requested classifier(s) matching 2 or more existing streams on different intervals.
4 Deny, by policy, requested stream or filter is not permitted to participate in the service.
5 Deny, reason unspecified.
6 Alternate proposed, due to existing stream with different delivery interval.
7 Alternate proposed, due to policy limits on the AP.
8 Alternate proposed, because the AP changed the delivery interval.
9 Multicast rate changes not allowed.
10 Terminate, due to an AP policy change.
11 Terminate, due to lack of resources of the AP.
12 Terminate, due to other FMS stream with higher priority.
13 Alternate proposed, because the AP changed the maximum delivery interval.
14 Alternate proposed, because the AP is unable to provide requested TCLAS-based classifiers.
15–255 Reserved
The Delivery Interval field defines the minimum integer of DTIM periods between successive transmissions
of frames for the stream corresponding to that FMSID.
The Max Delivery Interval field defines the maximum delivery interval the AP uses for the stream
corresponding to FMSID. The value set to 0 indicates that the AP has no maximum delivery interval for the
stream identified by FMSID.
The FMSID field is assigned by the AP and provides a unique identifier for this stream within the BSS.
The format of the FMS Counter field is shown in Figure 9-409. The FMS Counter ID field of the FMS
Counter field is defined in 9.4.2.75. The Current Count field of the FMS Counter field is reserved in the
FMS Status subelement.
The Rate Identification field specifies the data rate as described in 9.4.1.33 to be used for the multicast
service. If the value of the Rate Identification field is 0 then the data rate is undefined.
The Multicast MAC Address field contains the MAC address of the multicast traffic to which this FMS
response relates.
The format of the TCLAS Status subelement is shown in Figure 9-414.
999
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
one or more
TCLAS Elements
Subelement TCLAS Processing
Length FMSID TCLAS Elements
ID Element (optional)
Octets: 1 1 1 variable 0 or 3
Figure 9-414—TCLAS Status subelement format
The Subelement ID field is 2 to uniquely identify this subelement as the TCLAS Status subelement.
The Length field is defined in 9.4.3.
The FMSID field is assigned by the AP and provides a unique identifier for this stream within the BSS.
The TCLAS Elements field contains one or more TCLAS elements to specify the traffic filter as defined in
9.4.2.31. The number of TCLAS elements is limited and the total size of the FMS Response element is less
than or equal to 255 octets.
The TCLAS Processing Element field is optionally present and defines how multiple TCLAS elements are
processed as defined in 9.4.2.33.
The FMS Response element is included in FMS Response frames, as described in 9.6.14.12. The use of the
FMS Response element and frames is described in 11.2.3.16.
The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26).
9.4.2.78 QoS Traffic Capability element
The QoS Traffic Capability element provides information about types of traffic generated by a non-AP QoS
STA and is used by a QoS AP to indicate the access categories of associated non-AP QoS STAs. The format
of the QoS Traffic Capability element is shown in Figure 9-415.
QoS Traffic Capability AC STA Count List
Element ID Length
Bitmask/Flags (optional)
Total number of nonzero
bits in Bits 0–1 of QoS
Octets: 1 1 1 Traffic Capability
Bitmask/Flags field
Figure 9-415—QoS Traffic Capability element format
The Element ID and Length fields are defined in 9.4.2.1. The value of the Length field is 1 + n, where n
equals the total number of nonzero bits in Bits 0–1 of the QoS Traffic Capability Bitmask/Flags field.
The format of QoS Traffic Capability Bitmask/Flags field is defined in Table 9-199.
Bits 0–1 serve as QoS Traffic Capability Bitmask. The bitmask indicates the AC values that have the station
count specified in the following AC STA Count List. An AP sets the bit to 1 to indicate that the station count
for the corresponding AC is present in the AC STA Count List field. An AP sets the bit to 0 to indicate that
the station count for the corresponding AC is not present in the AC STA Count List field. Bits 0–1 are
reserved in a transmission to an AP.
1000
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-199—QoS Traffic Capability Bitmask/Flags definition
Bit Description
0 AC_VO
1 AC_VI
2 Reserved
3 Reserved
4 UP 4 Traffic
5 UP 5 Traffic
6 UP 6 Traffic
7 Reserved
Bits 4–6 serve as QoS Traffic Capability Flags. Each of Bits 4–6 serves as a flag for a non-AP STA to
indicate application requirements about the user priorities of the traffic it generates. A non-AP STA sets the
bit to 1 to indicate the existence of an application that requires generation of traffic belonging to the
corresponding user priority (UP). A non-AP STA sets the bit to 0 to indicate that such application does not
exist. Bits 4–6 are reserved in a transmission from an AP.
Bits 2–3 and Bit 7 are reserved.
The AC STA Count List comprises a sequence of STA Count fields corresponding to the nonzero bits in the
Bits 0–1 of the QoS Traffic Capability Bitmask/Flags field. The STA Count field is 1 octet long and contains
an unsigned integer, encoded according to 9.2.2. The STA Count field specifies the number of associated
QoS STAs that have indicated QoS traffic capability of the corresponding AC. If the number of STAs is
greater than 255, the STA Count field is 255. The AC STA Count List field is present only when the QoS AP
transmits the QoS Traffic Capability element.
The QoS Traffic Capability element is included in Beacon frames, as described in 9.3.3.3; Probe Response
frames, as described in 9.3.3.11; Association Request frames, as described in 9.3.3.6; and Reassociation
Request frames, as described in 9.3.3.8.
9.4.2.79 BSS Max Idle Period element
The BSS Max Idle Period element contains the time period a non-AP STA can refrain from transmitting
frames to the AP before the AP disassociates the STA due to inactivity. The format of the BSS Max Idle
Period element is shown in Figure 9-416.
Element ID Length Max Idle Period Idle Options
Octets: 1 1 2 1
Figure 9-416—BSS Max Idle Period element format
The Element ID and Length fields are defined in 9.4.2.1.
The Max Idle Period field indicates the idle timeout limit, as described in 11.24.13.
The Idle Options field indicates the options associated with the BSS Idle capability. The Idle Options field is
shown in Figure 9-417.
1001
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1-B7
Protected
Keep-Alive Reserved
Required
Bits: 1 7
Figure 9-417—Idle Options field
The Protected Keep-Alive Required subfield is set to 1 to indicate that only a protected frame indicates
activity. The Protected Keep-Alive Required subfield is set to 0 to indicate that either an unprotected or a
protected frame indicates activity.
The BSS Max Idle Period element is included in Association Response frames, as described in 9.3.3.7, and
Reassociation Response frames, as described in 9.3.3.9. The use of the BSS Max Idle Period element and
frames is described in 11.24.13.
9.4.2.80 TFS Request element
The TFS Request element defines information about the traffic filters that are enabled at the AP for the
requesting non-AP STA. The format of the TFS Request element is defined in Figure 9-418.
one or more
TFS Request
subelements
TFS Action TFS Request
Element ID Length TFS ID Code Subelements
Octets: 1 1 1 1 variable
Figure 9-418—TFS Request element format
The Element ID and Length fields are defined in 9.4.2.1.
The TFS ID field is assigned by the STA and provides a unique identifier for the traffic filter set specified by
the TFS Request Subelements field.
The TFS Action Code field defines the actions taken at the AP when a frame matches a traffic filter set. The
functions of the bits in this field are shown in Table 9-200.
Table 9-200—TFS Action Code field values
Bit(s) Name Notes
0 Delete After Setting this field to 1for any traffic filter set indicates all traffic filter sets established at
Match the AP for the non-AP STA are deleted when a frame matches any of the traffic filter
sets established for the non-AP STA. A value of 0 for this field indicates no deletion of
the traffic filter set upon a match.
1 Notify Setting this field to 1 indicates the STA is to be sent a TFS Notify frame upon the first
frame matching to the traffic filter set or the first frame match after the AP receives a
Notify Response frame containing the corresponding TFS ID. Setting this field to 0
indicates the AP does not send TFS Notify frame to the requesting STA.
2–7 Reserved All other bits are reserved.
1002
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The TFS Request Subelements field contains one or more TFS Request subelements described in
Table 9-201. The subelement format and ordering of subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-201. Each TFS Request
subelement specifies one traffic filter. Using multiple TFS Request subelements in a TFS Request element is
the equivalent to a logical AND operation on the match conditions of each TFS Request subelement.
Table 9-201—Optional subelement IDs for TFS Request parameters
Subelement ID Subelement name
1 TFS subelement
221 Vendor Specific subelement
0, 2 to 220, 222 to 255 Reserved
In a TFS Response element, the number of the response subelements is the same as the number of the TFS
Request subelements in the corresponding TFS Request element, where the TFS Response subelements
appear in the same order as the corresponding TFS Request subelements in the corresponding TFS Request
frame.
The format of the TFS subelement is shown in Figure 9-419.
one or more TCLAS
Elements
Subelement ID Length TCLAS Elements TCLAS Processing
Element (optional)
Octets: 1 1 variable 0 or 3
Figure 9-419—TFS subelement format
The Subelement ID field uniquely identifies this subelement to be the TFS subelement.
The Length field is defined in 9.4.3.
The TCLAS Elements field contains one or more TCLAS elements, each specifying a set of filtering
parameters as defined in 9.4.2.31. The number of TCLAS elements is limited and the total size of the TFS
Request element is less than 255 octets.
The TCLAS Processing Element field is optionally present and defines how multiple TCLAS elements are
processed as defined in 9.4.2.33.
The format of the Vendor Specific subelement for a TFS Request element is shown in Figure 9-420.
Subelement ID Length Vender Specific
Octets: 1 1 variable
Figure 9-420—TFS Request Vendor Specific subelement format
1003
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Subelement ID field uniquely identifies this subelement to be the TFS Request subelement.
The Length field is defined in 9.4.3.
The Vendor Specific field contains the vendor specific information.
The TFS Request element is included in TFS Request frames, as described in 9.6.14.15, and WNM Sleep
Mode Request frames, as described in 9.6.14.19. The use of the TFS Request element and frames is
described in 11.24.12.
9.4.2.81 TFS Response element
The TFS Response element defines information about the status of the requested filtering parameters. The
format of the TFS Response element is defined in Figure 9-421.
one or more
TFS Response
subelements
TFS Response
Element ID Length TFS ID
Subelements
Octets: 1 1 1 variable
Figure 9-421—TFS Response element format
The Element ID and Length fields are defined in 9.4.2.1.
The TFS ID field indicates the unique ID for the TFS traffic filter set.
The TFS Response Subelements field contains one or more TFS Response subelements. The subelement
format and ordering of subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-202.
In a TFS Response element, the number of the response subelements is the same as the number of the TFS
Request subelements in the corresponding TFS Request element, where the TFS Response subelements
appear in the same order as the corresponding TFS Request subelements in the corresponding TFS Request
frame.
Table 9-202—Optional subelement IDs for TFS Response parameters
Subelement ID Subelement name
1 TFS Status subelement
221 Vendor Specific subelement
0, 2–220, 222–255 Reserved
A TFS Status subelement contains the information as defined in Figure 9-422.
1004
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TFS
Subelement ID Length TFS Response Subelements
Status
(optional)
Octets: 1 1 1 variable
Figure 9-422—TFS Status subelement format
The Length field is defined in 9.4.3.
The TFS Response Status field indicates the status returned by the AP responding to the STA’s requested
traffic filter, as indicated in Table 9-198.
If present, the TFS Subelements field contains one or more TFS Request subelements containing the
alternative filtering parameters preferred by the AP.
The format of the Vendor Specific subelement for a TFS Response element is shown in Figure 9-423.
Subelement ID Length Vendor Specific
Octets: 1 1 variable
Figure 9-423—TFS Response Vendor Specific subelement format
The Subelement ID field uniquely identifies this subelement to be the TFS Response subelement.
The Length field is defined in 9.4.3.
The Vendor Specific field contains the vendor specific information.
The TFS Response element is included in TFS Response frames, as described in 9.6.14.16, and WNM Sleep
Mode Response frames, as described in 9.6.14.20. The use of the TFS Response element and frames is
described in 11.24.12.
9.4.2.82 WNM Sleep Mode element
The WNM Sleep Mode element is used to enter and exit the WNM sleep mode. The format of the WNM
Sleep Mode element is shown in Figure 9-424.
Element Length Action WNM Sleep Mode WNM Sleep
ID Type Response Status Interval
Octets: 1 1 1 1 2
Figure 9-424—WNM Sleep Mode element format
The Element ID and Length fields are defined in 9.4.2.1.
The Action Type field is a number that identifies the type of WNM sleep mode request and response. The
Action Types are shown in Table 9-203.
1005
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-203—Action Type definitions
Name Action Type value
Enter WNM sleep mode 0
Exit WNM sleep mode 1
Reserved 2–255
The WNM Sleep Mode Response Status field indicates the status returned by the AP responding to the non-
AP STA’s WNM sleep mode request as defined in Table 9-204. This field is valid only in the WNM Sleep
Mode element in a WNM Sleep Mode Response frame and is reserved otherwise.
Table 9-204—WNM Sleep Mode Response Status definition
Value Description
0 Enter/Exit WNM sleep mode Accept.
1 Exit WNM sleep mode Accept, GTK/IGTK update required.
2 Denied. The AP is unable to perform the requested action.
3 Denied temporarily. The AP is unable to perform the requested action at the
current time. The request can be submitted again at a later time.
4 Denied. Due to the pending key expiration.
5 Denied. The requested action was not granted due to other WNM services in use
by the requesting STA.
6–255 Reserved
The WNM Sleep Interval field is reserved if the Action Type field is 1.
The WNM Sleep Interval field indicates to the AP how often a STA in WNM sleep mode wakes to receive
Beacon frames, defined as the number of DTIM intervals. The value set to 0 indicates that the requesting
non-AP STA does not wake up at any specific interval.
The WNM Sleep Mode element is included in WNM Sleep Mode Request frames, as described in 9.6.14.19,
and WNM Sleep Mode Response frames, as described in 9.6.14.20. The use of the WNM Sleep Mode
element and frames is described in 11.2.3.18.
9.4.2.83 TIM Broadcast Request element
The TIM Broadcast Request element contains information about the periodic TIM broadcast being requested
by the non-AP STA. The format of the TIM Broadcast Request element is shown in Figure 9-425.
TIM Broadcast
Element ID Length Interval
Octets: 1 1 1
Figure 9-425—TIM Broadcast Request element format
1006
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The TIM Broadcast Interval field is the number of beacon periods between TIM frame transmissions. A
value of 0 terminates the use of TIM Broadcast for the requesting station.
The TIM Broadcast Request element is included in TIM Broadcast Request frames, as described in
9.6.14.21; Association Request frames, as described in 9.3.3.6; and Reassociation Request frames, as
described in 9.3.3.8. The use of the TIM Broadcast Request element and frames is described in 11.2.3.17.
9.4.2.84 TIM Broadcast Response element
The TIM Broadcast Response element contains information about the periodic TIM broadcast by the AP.
The format of the TIM Broadcast Response element is shown in Figure 9-426.
TIM TIM High Rate Low Rate
Element Broadcast Broadcast
ID Length Status Interval Offset TIM Rate TIM Rate
(optional) (optional)
(optional) (optional)
Octets: 1 1 1 0 or 1 0 or 4 0 or 2 0 or 2
Figure 9-426—TIM Broadcast Response element format
The Element ID and Length fields are defined in 9.4.2.1. The value of the Length field is 1 or 10, depending
on the presence of a TIM Broadcast schedule (TIM Broadcast Interval, TIM Broadcast Offset, High Rate
TIM Rate, and Low Rate TIM Rate fields).
The Status field indicates the status of the AP responding to the STA’s requested delivery interval, as
indicated in Table 9-205.
Table 9-205—Status field values
Field value Description
0 Accept
1 Accept, valid timestamp present in TIM frames
2 Denied
3 Overridden
4 Overridden, valid timestamp present in TIM frames
5–255 Reserved
When the Status field is 0, 1, 3 or 4, the TIM Broadcast Interval field, TIM Broadcast Offset field, High Rate
TIM Rate field, and Low Rate TIM Rate field are included in the TIM Broadcast Response element.
The TIM Broadcast Interval field contains the number of beacon periods between scheduled TIM frame
transmissions.
The TIM Broadcast Offset field contains the offset in microseconds with a tolerance of ± 4 µs relative to the
TBTT for which a TIM frame is scheduled for transmission. The field contains a signed integer.
1007
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The High Rate TIM Rate field provides an indication of the rate that is used to transmit the high data rate
TIM frame, in units of 0.5 Mb/s. A value of 0 indicates that the high rate TIM frame is not transmitted.
The Low Rate TIM Rate field provides an indication of the rate that is used to transmit the low data rate TIM
frame, in units of 0.5 Mb/s. A value of 0 indicates that the low rate TIM frame is not transmitted.
The TIM Broadcast Response element is included in TIM Broadcast Response frames, as described in
9.6.14.22; Association Response frames, as described in 9.3.3.7; and Reassociation Response frames, as
described in 9.3.3.9. The use of the TIM Broadcast Response element and frames is described in 11.2.3.17.
9.4.2.85 Collocated Interference Report element
The Collocated Interference Report element contains some characteristics of the reported collocated
interference. The Collocated Interference Report element is defined in Figure 9-427.
Interference
Interference Level Accuracy/
Element ID Length Report Period Level Interference
Index
Octets: 1 1 1 1 1
Interference Interference
Interference Interference Start Time/Duty Center Interference
Interval Burst Length Bandwidth
Cycle Frequency
Octets 4 4 4 4 2
Figure 9-427— Collocated Interference Report element format
The Element ID and Length fields are defined in 9.4.2.1.
The Report Period field contains an unsigned integer value in units of 200 TUs. If the Report Period field is
a value that is greater than 0, then the reporting is periodic, and the field contains the period of sending the
report. If the Report Period field is 0, then the reporting is not periodic, and a report is generated when the
STA knows of a change in the collocated interference. See 11.24.9 for further details.
The Interference Level field is a 2s complement signed integer indicating the maximum level of the
collocated interference power in units of dBm over all receive chains averaged over a 4 s period during an
interference period and across interference bandwidth. When the interference level is unknown, the field is
+127 dBm. When the interference level is equal or greater than 126 dBm, the field is +126 dBm. If no
collocated interference is present the field is –128 dBm. When the interference level is equal or lower than –
127 dBm, the field is –127 dBm. The interference level is referenced to the antenna connector (see “antenna
connector” in 3.1) used for reception, like RCPI.
The Interference Level Accuracy/Interference Index field is shown in Figure 9-428.
B0 B3 B4 B7
Expected Accuracy Interference Index
Bits 4 4
Figure 9-428—Interference Level Accuracy/Interference Index field format
1008
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Expected Accuracy field represents an unsigned integer indicating the expected accuracy of the estimate
of interference in dB with 95% confidence interval. If the Interference Level field is X (dBm) and the
expected accuracy field is Y (dB), the actual interference level is in the range X – Y to X +Y with the
probability of 95%. The range of expected accuracy is from 0 dB to 14 dB. If accuracy is unknown or
greater than 14 dB, then the Expected Accuracy field is 15.
The Interference Index field indicates the interference index that is unique for each type of interference
source. The field set to 0 indicates that no collocated interference is present. See 11.24.9 for further details.
The Interference Interval field indicates the interval between two successive periods of interference
in microseconds. When the interval between two successive periods of interference is variable the field is
232–1. When the interval between two successive periods of interference is equal or greater than 232– 2 the
field is 232– 2. If no collocated interference is present, the field is 0.
The Interference Burst Length field indicates the duration of each period of interference in microseconds.
When the duration of each period of interference is variable the field is 232– 1. When the duration of each
period of interference is equal or greater than 232– 2 the field is 232– 2. If no collocated interference is pres-
ent, the field is 0.
The Interference Start Time/Duty Cycle field contains the least significant 4 octets (i.e., B0–B31) of the TSF
timer at the start of the interference burst. When either the Interference Interval or the Interference Burst
Length fields are set to 232– 1, this field indicates the average duty cycle. The average duty cycle value is
defined as follows:
32 T
Average duty cycle = 2 –2 -----B- + 0.5
TI
where
TB is the average interference burst length
TI is the average interference interval
When the interference is nonperiodic or no collocated interference is present, the Interference Start Time
field is 0.
The Interference Center Frequency field indicates the center frequency of interference in units of 5 kHz.
When center frequency is unknown, the center frequency of the STA’s operating channel is reported. If no
collocated interference is present the field is 0.
The Interference Bandwidth field indicates the bandwidth in units of 5 kHz at the –3 dB roll-off point of the
interference signal. When bandwidth of the interference signal is unknown, the field is 65 535. When
bandwidth of the interference signal is equal or greater than 65 534 the field is 65 534. If no collocated
interference is present, the field is 0.
9.4.2.86 Channel Usage element
The Channel Usage element defines the channel usage information for BSSs that are not infrastructure BSSs
or an off channel TDLS direct link. The format of the Channel Usage element is shown in Figure 9-429.
1009
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
zero or
more
entries
Element Length Usage Channel
ID Mode Entry
Octets: 1 1 1 2n
Figure 9-429—Channel Usage element format
The Element ID and Length fields are defined in 9.4.2.1.
The Usage Mode field is a number that identifies the usage of the recommended channels listed in the
Operating Class/Channel Number pair fields. The Usage Mode definitions are shown in Table 9-206.
Table 9-206—Usage Mode definitions
Value Usage Mode
0 Noninfrastructure IEEE 802.11 network
1 Off-channel TDLS direct link
2–255 Reserved
The Channel Entry field includes zero or more Operating Class and Channel fields. The format of the
Operating Class and Channel fields is defined in 9.4.1.22. Operating Class and Channel fields can be
grouped together to identify a noncontiguous channel as described in 9.4.2.71.3.
The Channel Usage element can be included in Probe Request frames, as described in 9.3.3.10; Probe
Response frames, as described in 9.3.3.11; Channel Usage Request frames, as described in 9.6.14.24; and
Channel Usage Response frames, as described in 9.6.14.25. The use of the Channel Usage element and
frames is described in 11.24.15.
9.4.2.87 Time Zone element
The Time Zone element contains the local time zone of the AP. The format of the Time Zone element is
shown in Figure 9-430.
Element ID Length Time Zone
Octets: 1 1 variable
Figure 9-430—Time Zone element format
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Time Zone field is as specified in 8.3 of IEEE Std 1003.1-2004:
stdoffset[dst[offset][,start[/time],end[/time]]]
1010
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The length of the field is no less than 4 octets and no more than TZNAME_MAX, as defined in IEEE
Std 1003.1-2004. The Time Zone field represents the time zone at the AP’s location. The encoding of the
field is in ASCII characters as shown in the following Example-1.
Example-1: EST5
Example-2: EST5EDT4,M3.2.0/02:00,M11.1.0/02:00
In the Example-2, the string is interpreted as a time zone that is normally five hours behind UTC, and four
hours behind UTC during daylight saving time (DST), which runs from the second Sunday in March at
02:00 local time through the first Sunday in November at 02:00 local time. Normally, the time zone is
abbreviated “EST” but during DST it is abbreviated “EDT.”
9.4.2.88 DMS Request element
The DMS Request element defines information about the group addressed frames to be transmitted as
individual addressed frames. The format of the DMS Request element is shown in Figure 9-431.
Element ID Length DMS
Descriptor List
Octets: 1 1 variable
Figure 9-431—DMS Request element format
The Element ID and Length fields are defined in 9.4.2.1.
The DMS Descriptor List field contains one or more DMS Descriptors. The format of the DMS Descriptor is
defined in Figure 9-432.
zero or more
TCLAS
Elements
TCLAS TSPEC
DMS Request TCLAS Processing Optional
DMSID Length Type Elements Element Element Subelements
(optional)
(optional)
Octets: 1 1 1 variable 0 or 3 0 or 57 variable
Figure 9-432—DMS Descriptor
The DMSID field is set to 0 when the Request Type field is “Add” as defined in Table 9-207; otherwise, the
DMSID field is set to the nonzero value assigned by the AP STA to identify the DMS traffic flow.
The DMS Length field is set to 1 + n, where n indicates the total length in octets of all of the TCLAS
Elements, optional TCLAS Processing Element, optional TSPEC Element, and Optional Subelements fields
contained in the DMS Descriptor field. The maximum value of the DMS Length field is 253.
The Request Type field identifies the type of DMS request. The encoding of the Request Type field is shown
in Table 9-207.
1011
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-207—DMS Request Type field
Description Request Type field value
Add 0
Remove 1
Change 2
Reserved 3–255
When the Request Type field contains “Add,” the TCLAS Elements field contains one or more TCLAS
elements to specify group addressed frames as defined in 9.4.2.31. When a GCR Request subelement is
included in the DMS Descriptor and the Request Type field is equal to “Add,” the TCLAS Elements field
contains at least a TCLAS element with frame classifier type set to 0 (Ethernet parameters) to specify a
destination group address as defined in 9.4.2.31. When the Request Type field contains any value other than
“Add,” the TCLAS Elements field contains zero TCLAS elements.
When the Request Type field contains “Add” and when there are two or more TCLAS elements present, the
TCLAS Processing Element field contains one TCLAS Processing element to define how these TCLAS
elements are to be processed, as defined in 9.4.2.33. Otherwise, the TCLAS Processing Element field
contains zero TCLAS Processing elements.
When the Request Type field contains “Add” or “Change,” the TSPEC Element field optionally contains
one TSPEC element to specify the characteristics and QoS expectations of the corresponding traffic flow as
defined in 9.4.2.30. When a GCR Request subelement is included in the DMS Descriptor and the Request
Type field is equal to “Add” or “Change,” the TSPEC Element field contains one TSPEC element.
Otherwise, the TSPEC Element field contains zero TSPEC elements.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-208.
Table 9-208—Optional subelement IDs for DMS Descriptor
Subelement ID Name Extensible
0 Reserved
1 GCR Request Yes
2–220 Reserved
221 Vendor Specific
222–255 Reserved
Each DMS Descriptor contains zero or one GCR Request subelements. If present and the Request Type field
is equal to “Add” or “Change,” the GCR Request subelement indicates a request by a STA to respectively
add or change the GCR service for a group addressed stream identified by the TCLAS element or by the
DMSID in the DMS Descriptor. The format of the GCR Request subelement is shown in Figure 9-433.
1012
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B7 B8 B15 B16 B19 B20 B23
GATS Retransmission
Subelement ID Length Policy GCR Delivery Method
Bits: 8 8 4 4
Figure 9-433—GCR Request subelement format
The Length field is defined in 9.4.3.
The GATS Retransmission Policy field is set to indicate the STA’s preferred retransmission policy for the
group address for which the GCR service is requested. The values are shown in Table 9-209.
Table 9-209—GATS Retransmission Policy field values
Value GATS retransmission policy Notes
0 No preference
1 DMS See 11.24.16.2.
2 GCR unsolicited retry See 11.24.16.3.6.
3 GCR Block Ack See 11.24.16.3.7.
4–15 Reserved
The GCR Delivery Method field is set to indicate the STA’s preferred delivery method for the group address
for which the GCR service is requested. The values are shown in Table 9-210.
Table 9-210—GCR Delivery Method field values
Value GCR delivery method Notes
0 No preference
1 Non-GCR-SP See 11.24.16.3.1.
2 GCR-SP See 11.24.16.3.8.
3–15 Reserved
The DMS Request element is included in DMS Request frames, as described in 9.6.14.26, and Reassociation
Request frames, as described in 9.3.3.8. The use of the DMS Request element and frames is described in
11.24.16.
9.4.2.89 DMS Response element
The DMS Response element provides the status information about the requested group addressed frames.
The format of the DMS Response element is shown in Figure 9-434.
1013
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
one or more
DMS Status
field
Element ID Length DMS Status List
Octets: 1 1 variable
Figure 9-434—DMS Response element format
The Element ID and Length fields are defined in 9.4.2.1.
The DMS Status List field contains one or more DMS Status field. The format of the DMS Status field is
defined in Figure 9-435.
zero or more
TCLAS
Elements
Last TCLAS TSPEC
DMS Response TCLAS Processing Optional
DMSID Length Type Sequence Elements Element Element Subelements
Control (optional)
(optional)
Octets: 1 1 1 2 variable 0 or 3 0 or 57 variable
Figure 9-435—DMS Status field format
The DMSID field is assigned by the AP and provides a unique identifier within the BSS for the DMS traffic
flow identified by the TCLAS Elements, TCLAS Processing Element, and TSPEC Element fields. The
uniqueness of the identifier is independent of the ordering of the TCLAS elements. In a mesh BSS, the
DMSID field is assigned by a mesh STA that responds to a GCR request and is unique among all existing
DMSIDs used by the mesh STA for its current GCR agreements.
The value of the DMS Length field is set to 3 + n, where n indicates the total length in octets of all of the
TCLAS Elements, optional TCLAS Processing Element, optional TSPEC Element, and Optional
Subelements fields contained in the DMS Status field. When the Response Type field is set to “Terminate,”
the value of the DMS Length field is set to 3. The maximum value of the DMS Length field is 253.
The Response Type field indicates the response type returned by the AP responding to the non-AP STA’s
request or by a mesh STA responding to its peer mesh STA’s request or indicates the DMS Status is an
advertisement of an existing GCR service, as indicated in Table 9-211.
Table 9-211—Response Type field values
Field value Description Notes
0 Accept STA accepts the DMS or GCR request
1 Denied STA rejects the DMS or GCR request
2 Terminate STA terminates DMS previously accepted DMS or GCR
request
3 GCR Advertise STA advertises a group addressed stream subject to an
existing GCR agreement.
4–255 Reserved
1014
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the Last Sequence Control field is not supported the Last Sequence Control field is set to 65 535.
When the Last Sequence Control field is supported and the Response Type field does not contain
“Terminate” or “GCR Advertise,” the Last Sequence Control field is reserved.
When the Response Type field is “Terminate” and the Last Sequence Control field is supported, Bit 0 to Bit
3 of the Last Sequence Control field is 0, and Bit 4 to Bit 15 of the Last Sequence Control field contains the
sequence number of the last group addressed frame that the AP delivered to the non-AP STA that is the
recipient of the DMS Response frame. If the Response Type field is “Terminate” and the last frame received
by the non-AP STA prior to DMS termination has not also been sent using a group addressed frame, the Last
Sequence Control field is set to 65 534.
When the Response Type field contains “Accept” or “Denied” and a GCR Response subelement is not
included in the DMS Status field, the TCLAS Elements field contains one or more TCLAS elements to
specify group addressed frames as defined in 9.4.2.31. When the Response Type field is equal to “Accept,”
“Denied,” or “GCR Advertise” and a GCR Response subelement is included in the DMS Status field, the
TCLAS Elements field contains at least one TCLAS element with frame classifier type set to 0 (Ethernet
parameters) to specify a destination group address as defined in 9.4.2.31. Otherwise, the TCLAS Elements
field contains zero TCLAS elements.
When the Response Type field contains “Accept” or “Denied,” the TCLAS Processing Element field
optionally contains one TCLAS Processing element to define how these TCLAS elements are to be
processed, as defined in 9.4.2.33. When the Response Type field contains “Terminate” or when there is only
one TCLAS element, the TCLAS Processing Element field contains zero TCLAS Processing elements.
When the Response Type field contains “Accept” or “Denied,” the TSPEC Element field optionally contains
one TSPEC element to specify the characteristics and QoS expectations of the corresponding traffic flow as
defined in 9.4.2.30. When a GCR Response subelement is included in the DMS Status field and the
Response Type field is equal to “Accept,” “Denied,” or “GCR Advertise,” the TSPEC Element field
contains one TSPEC element. Otherwise, the TSPEC Element field contains zero TSPEC elements.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-212.
Table 9-212—Optional subelement IDs for DMS Status
Subelement ID Name Extensible
0 Reserved
1 GCR Response Subelements
2–220 Reserved
221 Vendor Specific
222–255 Reserved
The GCR Response subelement contains one of the following:
— A response by an AP to a GCR request by a non-AP STA for GCR service for a group address
— A response by a mesh STA to a GCR request by a peer mesh STA for GCR service for a group
address
— An unsolicited advertisement for the parameters of a group addressed stream subject to the GCR
service
1015
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The format of the GCR Response subelement is shown in Figure 9-432.
Subelement GATS GCR Delivery GCR Schedule
Length Retransmission Concealment
ID Policy Method Address Element
Octets: 1 1 0 or 1 0 or 1 0 or 6 0 or 14
Figure 9-436—GCR Response subelement format
The GATS Retransmission Policy, GCR Delivery Method, and GCR Concealment Address fields are
present when the Response Type field is not equal to “Denied”; otherwise, they are omitted. The Schedule
Element field is optionally present when the Response Type field is not equal to “Denied.”
The GATS Retransmission Policy field is set to indicate the current GCR retransmission policy for the group
address for which the GCR service is requested. The values are shown in Table 9-209.
The GCR Delivery method field is set to indicate the current GCR Delivery method for the group address for
which the GCR service is requested. The values are shown in Table 9-210.
The GCR Concealment Address field, when present, indicates the GCR concealment address, as described
in 11.24.16.3.5.
The Schedule Element field is present if the GCR delivery method is equal to GCR-SP. It indicates the
current SP schedule for the group addressed stream (see 9.4.2.34).
The DMS Response element is included in DMS Response frames, as described in 9.6.14.27, and
Reassociation Response frames, as described in 9.3.3.9. The use of the DMS Response element and frames
is described in 11.24.16.
9.4.2.90 Destination URI element
The Destination URI element contains URI and ESS Detection Interval values from the requesting STA that
the responding STA can be used to deliver Event or Diagnostic Report frames. The format of the Destination
URI element is given in Figure 9-437.
ESS Detection
Element ID Length URI
Interval
Octets: 1 1 1 1–253
Figure 9-437—Destination URI element format
The Element ID and Length fields are defined in 9.4.2.1.
The ESS Detection Interval field is defined in 9.4.2.71.2 and its use for Event and Diagnostic requests is
described in 11.24.2 and 11.24.3.
The URI field specifies the destination URI for Event and Diagnostic reports using the format defined in
IETF RFC 3986. The URI field value is limited to 253 octets.
The Destination URI element is included as the last element in an Event or Diagnostic Request frame.
The Destination URI element is included in Event Request frames, as described in 9.6.14.2, or Diagnostic
Request frames, as described in 9.6.14.4.
1016
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Use of the Destination URI element in an Event Request frame is described in 11.24.2.1. Use of the
Destination URI element in a Diagnostic Request frame is described in 11.24.3.1.
9.4.2.91 U-APSD Coexistence element
The U-APSD coexistence provides the duration of requested transmission during a U-APSD service period.
The format of the U-APSD Coexistence element is shown in Figure 9-438.
Element ID Length TSF 0 Offset Interval/ Optional
Duration Subelements
Octets: 1 1 8 4 variable
Figure 9-438—U-APSD Coexistence element format
The Element ID and Length fields are defined in 9.4.2.1.
A nonzero value of the TSF 0 Offset field is the number of microseconds since TSF time 0 when the non-AP
STA knew the start of interference. The AP uses the TSF 0 Offset field together with the Interval/Duration
field to enqueue frames for transmission to the non-AP STA using the procedures as described in 11.2.3.5.2.
A TSF 0 Offset field value of 0 indicates the non-AP STA requests the AP transmit frames to the non-AP
STA using the procedure described in 11.2.3.5.2 for the case where TSF 0 Offset is equal to 0.
The Interval/Duration field is defined as follows:
— When the TSF 0 Offset is 0, the Interval/Duration field is the number of microseconds during the U-
APSD service period when the AP transmits frames to the non-AP STA as described in 11.2.3.5.2.
— When the TSF 0 Offset is nonzero, the Interval/Duration field is the number of microseconds
between the start of consecutive interference bursts.
The Interval/Duration field value of 0 is reserved.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-213.
Table 9-213—Optional subelement IDs for U-APSD coexistence
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
9.4.2.92 Interworking element
The Interworking element contains information about the interworking service capabilities of a STA as
shown in Figure 9-439.
1017
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Access
Element ID Length Network Venue Info HESSID
(optional) (optional)
Options
Octet 1 1 1 0 or 2 0 or 6
s:
Figure 9-439—Interworking element format
The Element ID and Length fields are defined in 9.4.2.1.
The format of Access Network Options field is shown in Figure 9-440.
Bits: B0 B3 B4 B5 B6 B7
Access
Network Internet ASRA ESR UESA
Type
Figure 9-440—Access Network Options field format
A non-AP STA sets Internet, ASRA, ESR, and UESA fields to 0 when including the Interworking element
in the Probe Request frame. A non-AP STA sets the Internet, ASRA and ESR bits to 0 when including the
Interworking element in (Re)Association Request frames. A mesh STA sets the Internet bit to 0 when
including the Interworking element in Mesh Peering Open frames. In (Re)Association Request frames, a
non-AP STA sets the UESA bit according to the procedures in 11.3.5. The access network types are shown
in Table 9-214. The Access Network Type field is set by the AP or the mesh STA to advertise its access
network type to non-AP STAs. A non-AP STA uses this field to indicate the desired access network type in
an active scan. See R.2 for informative text on usage of fields contained within the Interworking element.
Table 9-214—Access network type
Access
Meaning Description
network type
0 Private network Nonauthorized users are not permitted on this network. Examples of this
access network type are home networks and enterprise networks, which
might employ user accounts. Private networks do not necessarily employ
encryption.
1 Private network Private network but guest accounts are available. Example of this access
with guest access network type is enterprise network offering access to guest users.
2 Chargeable The network is accessible to anyone, however, access to the network requires
public network payment. Further information on types of charges might be available through
other methods (e.g., IEEE Std 802.21, http/https redirect or DNS redirection).
Examples of this access network type is a hotspot in a coffee shop offering
internet access on a subscription basis or a hotel offering in-room internet
access service for a fee.
3 Free public The network is accessible to anyone and no charges apply for the network
network use. An example of this access network type is an airport hotspot or
municipal network providing free service.
4 Personal device A network of personal devices. An example of this type of network is a
network camera attaching to a printer, thereby forming a network for the purpose of
printing pictures.
5 Emergency A network dedicated and limited to accessing emergency services.
services only
network
1018
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-214—Access network type (continued)
Access
Meaning Description
network type
6 to 13 Reserved Reserved
14 Test or The network is used for test or experimental purposes only.
experimental
15 Wildcard Wildcard access network type
Bit 4 is the Internet field. The AP or mesh STA sets this field to 1 if the network provides connectivity to the
Internet; otherwise it is set to 0 indicating that it is unspecified whether the network provides connectivity to
the Internet.
Bit 5 is the Additional Step Required for Access (ASRA) field. It is set to 1 by the AP to indicate that the
network requires a further step for access. For more information, refer to Network Authentication Type
Information in 9.4.5.6. A mesh STA uses the ASRA field as an emergency indicator. If a mesh STA requires
emergency services, the ASRA field is set to 1; otherwise it is set to 0. See 11.25.6.
Bit 6 is the ESR (emergency services reachable) field. It is set to 1 by the AP or mesh STA to indicate that
emergency services are reachable through the AP or mesh STA; otherwise it is set to 0 indicating that it is
unable to reach the emergency services. See 11.25.6.
Bit 7 is the UESA (unauthenticated emergency service accessible) field. When set to 0, this field indicates
that no unauthenticated emergency services are reachable through this AP or mesh STA. When set to 1, this
field indicates that higher layer unauthenticated emergency services are reachable through this AP or mesh
STA. A STA uses the Interworking element with the UESA bit set to 1 to gain unauthenticated access to a
BSS to access emergency services. A mesh STA uses the Interworking element with the UESA bit set to 1 to
gain unauthenticated access to another mesh STA to access emergency services. See 11.3.5.
The Venue Info field is defined in 9.4.1.35.
The HESSID field, which is the identifier for a homogeneous ESS, specifies the value of HESSID; see
11.25.2. A STA uses this field to indicate the target HESSID in an active scan per 11.1.4. The HESSID field
for an AP is set to dot11HESSID. This optional field is not used by mesh STAs.
9.4.2.93 Advertisement Protocol element
The Advertisement Protocol element contains information that identifies a particular advertisement protocol
and its corresponding Advertisement Control. The Advertisement Protocol element format is shown in
Figure 9-441.
Advertisement Advertisement
Element Protocol Tuple
ID Length Protocol Tuple ... #n
#1
(optional)
Octets: 1 1 variable variable
Figure 9-441—Advertisement Protocol element format
1019
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The format of Advertisement Protocol Tuple field is shown in Figure 9-442.
Query Response Advertisement
Info Protocol ID
Octets: 1 variable
Figure 9-442—Advertisement Protocol Tuple field format
The format of Query Response Info field is shown in Figure 9-443.
Bits: B0 B6 B7
Query Response
Length Limit PAME-BI
Figure 9-443—Query Response Info field format
The Query Response Info field is defined as follows:
— The Query Response Length Limit field indicates the maximum number of octets a STA will
transmit in the Query Response field contained within one or more GAS Comeback Response
frames. If the value of the Query Response Length Limit field is larger than the maximum MMPDU
size, the Query Response will span multiple MMPDUs. The Query Response Length Limit field is
encoded as an integer number of 256 octet units. A value of 0 is not permitted. A value of 0x7F
means the maximum limit enforced is determined by the maximum allowable number of fragments
in the GAS Query Response Fragment ID (see 9.4.1.34). The Query Response Length Limit field is
reserved in a transmission from the requesting STA to the responding STA.
— Bit 7, the Preassociation Message Exchange BSSID Independent (PAME-BI) bit, is used by an AP
to indicate whether the Advertisement Server, which is the non-AP STA’s peer for this
Advertisement Protocol, returns a Query Response that is independent of the BSSID used for the
GAS frame exchange. This bit is set to 1 to indicate the Query Response is independent of the
BSSID; it is set to 0 to indicate that the Query Response may be dependent on the BSSID. See
11.25.3.2 for further information. Bit 7 is reserved for non-AP STAs.
The Advertisement Protocol ID is a variable-length field. When this field contains a vendor-specific
Advertisement Protocol ID, then this field will be structured per the Vendor Specific element defined in
9.4.2.26, where the Element ID of the Vendor Specific element of 9.4.2.26 is the first octet of the field and
contains the vendor-specific value for Advertisement Protocol ID defined in Table 9-215; otherwise its
length is 1 octet and its value is one of the values in Table 9-215. When one or more vendor-specific tuples
are included in the Advertisement Protocol element, their total length needs to be constrained such that the
total length of all of the Advertisement Protocol Tuple fields (both vendor specific and otherwise) is less
than or equal to 255 octets.
Table 9-215—Advertisement protocol ID definitions
Name Value
Access network query protocol (ANQP) 0
MIH Information Service 1
1020
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-215—Advertisement protocol ID definitions
Name Value
MIH Command and Event Services Capability Discovery 2
Emergency Alert System (EAS) 3
Registered location query protocol (RLQP) 4
Reserved 5–220
Vendor Specific 221
Reserved 222–255
— ANQP supports information retrieval from an Advertisement Server. ANQP is a protocol used by a
requesting STA to query another STA (i.e., the receiving STA might respond to queries with or
without proxying the query to a server in an external network). See 11.25.3.3 for information on
ANQP procedures.
— MIH Information Service is a service defined in IEEE Std 802.21-2008 to support information
retrieval from an information repository.
— MIH Command and Event Services capability discovery is a mechanism defined in IEEE Std 802.21
(see IEEE Std 802.21-2008) to support discovering capabilities of command service and event
service entities in a STA or an external network.
— The EAS allows a network to disseminate emergency alert notifications from an external network to
non-AP STAs. EAS uses the message format as defined in OASIS EDXL.
— The RLQP supports information retrieval from a RLSS. RLQP is a protocol used by a requesting
STA to query another STA (i.e., the receiving STA can respond to queries with and without proxying
the query to a server in an external network). 11.25 for information on RLQP procedures.
— Advertisement Protocol ID 221 is reserved for Vendor Specific Advertisement Protocols. When the
Advertisement Protocol ID is equal to 221, the format of the Advertisement Protocol ID subfield
follows the format of the Vendor Specific element in 9.4.2.26.
9.4.2.94 Expedited Bandwidth Request element
The Expedited Bandwidth Request element is transmitted from a non-AP STA to an AP in an ADDTS
Request frame containing a TSPEC element and provides usage information for the bandwidth request. The
Expedited Bandwidth Request element format is shown in Figure 9-444.
Element ID Length Precedence Level
Octets: 1 1 1
Figure 9-444—Expedited Bandwidth Request element format
The Element ID and Length fields are defined in 9.4.2.1.
The Precedence Level field is provided in Table 9-216.
The precedence levels are derived from the 3rd Generation Partnership Project (3GPP) document 3GPP TS
22.067 [B3].
1021
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-216—Precedence Level field description
Precedence level value Description
0–15 Reserved
16 Emergency call, defined in NENA 08-002 [B56]
17 First responder (public)
18 First responder (private)
19 MLPP Level A
20 MLPP Level B
21 MLPP Level 0
22 MLPP Level 1
23 MLPP Level 2
24 MLPP Level 3
25 MLPP Level 4
26–255 Reserved
The first responders (public) in Table 9-216 are government agencies or entities acting on behalf of the
government, and the first responders (private) are private entities, such as individuals or companies.
9.4.2.95 QoS Map element
The QoS Map element is transmitted from an AP to a non-AP STA in a (Re)Association Response frame or
a QoS Map Configure frame and provides the mapping of higher layer quality-of-service constructs to User
Priorities defined by transmission of Data frames in this standard. This element maps the higher layer
priority from the DSCP field used with the Internet Protocol to User Priority as defined by this standard. The
QoS Map element is shown in Figure 9-445.
DSCP DSCP
UP 0 UP 1 UP 2 UP 7
Element Length Exception ... Exception DSCP DSCP DSCP ... DSCP
ID #1 #n
(optional) (optional) Range Range Range Range
Octets: 1 1 0 or 2 0 or 2 2 2 2 2
Figure 9-445—QoS Map element format
The Element ID and Length fields are defined in 9.4.2.1. The Length field is set to 16+2×n, where n is the
number of DSCP Exception fields in the QoS Map element.
DSCP Exception fields are optionally included in the QoS Map element. If included, the QoS Map element
has a maximum of 21 DSCP Exception fields. The format of the exception field is shown in Figure 9-446.
DSCP Value User Priority
Octets: 1 1
Figure 9-446—DSCP Exception format
1022
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DSCP value in the DSCP Exception field is in the range 0 to 63, or 255; the User Priority value is in the
range 0 to 7.
— When a non-AP STA begins transmission of a Data frame containing the Internet Protocol, it
matches the DSCP field in the IP header to the corresponding DSCP value contained in this element.
The non-AP STA first attempts to match the DSCP value to a DSCP exception field and uses the UP
from the corresponding UP in the same DSCP exception field if successful; if no match is found then
the non-AP STA attempts to match the DSCP field to a UP n DSCP Range field, and uses the n as the
UP if successful; and otherwise uses a UP of 0.
— Each DSCP Exception field has a unique DSCP Value.
DSCP Low Value DSCP High Value
Octets: 1 1
Figure 9-447—DSCP Range description
The QoS Map element has a DSCP Range field corresponding to each of the 8 user priorities. The format of
the range field is shown in Figure 9-447. The DSCP Range value is between 0 and 63 inclusive, or 255.
— The DSCP range for each user priority is nonoverlapping.
— The DSCP High Value is greater than or equal to the DSCP Low Value.
— If the DSCP Range high value and low value are both equal to 255, then the corresponding UP is not
used.
9.4.2.96 Roaming Consortium element
The Roaming Consortium element contains information identifying the roaming consortium and/or SSP
whose security credentials can be used to authenticate with the AP transmitting this element; see 11.25.8.
The element’s format is shown in Figure 9-448.
Number of OI OI OI OI
Element ID Length ANQP #1 and #2 #2 #3
OIs Lengths #1 (optional) (optional)
Octets: 1 1 1 1 variable variable variable
Figure 9-448—Roaming Consortium element format
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Number of ANQP OIs field is a one-octet unsigned integer whose value is the number of
additional roaming consortium organization identifiers (OIs) obtainable via ANQP. A value of 0 means that
no additional OIs are returned in response to an ANQP request for the Roaming Consortium list. A value of
255 means that 255 or more additional OIs are obtainable via ANQP.
The OI #1 and #2 Lengths field format is shown in Figure 9-449.
— The value of the OI #1 Length subfield is the length in octets of the OI #1 field.
— The value of the OI #2 Length subfield is the length in octets of the OI #2 field. If the OI #2 field is
not present, the value of the OI #2 Length subfield is set to 0.
NOTE—When there are three OIs, the OI #3 Length is calculated by subtracting sum of 2 plus the value of the OI #1
Length subfield plus the value of the OI #2 Length subfield from the value of the Length field.
1023
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Bits: B0 B3 B4 B7
OI #1 Length OI #2 Length
Figure 9-449—OI #1 and #2 Lengths field format
The OI field is defined in 9.4.1.32. Each OI identifies a roaming consortium (group of SSPs with inter-SSP
roaming agreement) or a single SSP. The value of the OI(s) in this table are equal to the value of the first
3 OIs in the dot11RoamingConsortiumTable. If fewer than 3 values are defined in the
dot11RoamingConsortiumTable, then only as many OIs as defined in the table are populated in this element.
The values of the OIs in this element are equal to the values of the first OIs, up to 3, from the table.
9.4.2.97 Emergency Alert Identifier element
The Emergency Alert Identifier element provides a hash to identify instances of the active EAS messages
that are currently available from the network. The hash allows the non-AP STA to assess whether an EAS
message advertised by an AP has been previously received and therefore whether it is necessary
to download from the network. The format of the Emergency Alert Identifier element is provided in
Figure 9-450.
Element ID Length Alert Identifier Hash
Octets: 1 1 8
Figure 9-450—Emergency Alert Identifier element format
The Element ID and Length fields are defined in 9.4.2.1.
The Alert Identifier Hash (AIH) is an 8-octet field. It is a unique value used to indicate an instance of an
EAS message. The value of this field is the hash produced by the HMAC-SHA-1-64 hash algorithm
operating on the EAS message.
AIH =HMAC-SHA-1-64(“ES_ALERT”, Emergency_Alert_Message)
where
“ES_ALERT” is an ASCII string.
Emergency_Alert_Message is the EAS message itself.
9.4.2.98 Mesh Configuration element
9.4.2.98.1 General
The Mesh Configuration element shown in Figure 9-451 is used to advertise mesh services. It is contained in
Beacon frames and Probe Response frames transmitted by mesh STAs and is also contained in Mesh Peering
Open and Mesh Peering Confirm frames.
Active Path Active Path Congestion Synchroniz
Authenticati Mesh
Element Length Selection Selection Control ation on Protocol Formation Mesh
ID Protocol Metric Mode Method Capability
Identifier Identifier Identifier Identifier Identifier Info
Octets 1 1 1 1 1 1 1 1 1
Figure 9-451—Mesh Configuration element format
1024
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The remainder of the fields are described in the following subclauses.
9.4.2.98.2 Active Path Selection Protocol Identifier
The Active Path Selection Protocol Identifier field indicates the path selection protocol that is currently
activated in the MBSS. Table 9-217 provides path selection protocol identifier values defined by this
standard.
Table 9-217—Active Path Selection Protocol Identifier field values
Value Meaning
0 Reserved
1 Hybrid wireless mesh protocol (default path selection protocol) defined in 14.10
(default path selection protocol)
2–254 Reserved
255 Vendor specific
(The active path selection protocol is specified in a Vendor Specific element)
When the Active Path Selection Protocol Identifier field is 255, the active path selection protocol is
specified by a Vendor Specific element that is present in the frame. The content of the Vendor Specific
element is beyond the scope of this standard. (See 9.4.2.26.)
9.4.2.98.3 Active Path Selection Metric Identifier
The Active Path Selection Metric Identifier field indicates the path metric that is currently used by the active
path selection protocol in the MBSS. Table 9-218 provides the path selection metric identifier values
defined by this standard.
Table 9-218—Active Path Selection Metric Identifier field values
Value Meaning
0 Reserved
1 Airtime link metric defined in 14.9 (default path selection metric)
2–254 Reserved
255 Vendor specific
(The active metric is specified in a Vendor Specific element)
When the Active Path Selection Metric Identifier field is 255, the active path metric is specified by a Vendor
Specific element that is present in the frame. The content of the Vendor Specific element is beyond the
scope of this standard. (See 9.4.2.26.)
1025
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.98.4 Congestion Control Mode Identifier
The Congestion Control Mode Identifier field indicates the congestion control protocol that is currently
activated in the MBSS. Table 9-219 provides the congestion control mode identifier values defined by this
standard.
Table 9-219—Congestion Control Mode Identifier field values
Value Meaning
0 Congestion control is not activated (default congestion control mode)
1 Congestion control signaling protocol defined in 14.12.2
2–254 Reserved
255 Vendor specific
(The active congestion control protocol is specified in a Vendor Specific element)
The congestion mode identifier value of 0 indicates the mesh STA has no active congestion control protocol
and is set as the default value for the congestion control mode identifier in the MBSS.
When the Congestion Control Mode Identifier field is 255, the active congestion control protocol is
specified by a Vendor Specific element that is present in the frame. The content of the Vendor Specific
element is beyond the scope of this standard. (See 9.4.2.26.)
9.4.2.98.5 Synchronization Method Identifier
The Synchronization Method Identifier field indicates the synchronization method that is currently activated
in the MBSS. Table 9-220 provides the synchronization method identifier values defined by this standard.
Table 9-220—Synchronization Method Identifier field values
Value Meaning
0 Reserved
1 Neighbor offset synchronization method defined in 14.13.2.2 (default
synchronization method)
2–254 Reserved
255 Vendor specific
(The active synchronization method is specified in a Vendor Specific element)
The neighbor offset synchronization method is defined as the default synchronization method among mesh
STAs. The details of the neighbor offset synchronization method are described in 14.13.2.2.
When the Synchronization Method Identifier field is 255, the active synchronization method is specified by
a Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond
the scope of this standard. (See 9.4.2.26.)
1026
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.98.6 Authentication Protocol Identifier
The Authentication Protocol Identifier field indicates the type of authentication protocol that is currently
used to secure the MBSS. Table 9-221 provides the authentication protocol identifier values defined by this
standard.
Table 9-221—Authentication Protocol Identifier field values
Value Meaning
0 No authentication method is required to establish mesh peerings within the MBSS
1 SAE defined in 12.4
2 IEEE 802.1X authentication
3–254 Reserved
255 Vendor specific
(The active authentication protocol is specified in a Vendor Specific element)
When the Authentication Protocol Identifier field is 255, the active authentication protocol is specified by a
Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond
the scope of this standard. (See 9.4.2.26.)
9.4.2.98.7 Mesh Formation Info
The format of the Mesh Formation Info field is shown in Figure 9-452.
B0 B1 B6 B7
Connected to Number of
Mesh Gate Peerings Connected to AS
Bits: 1 6 1
Figure 9-452—Mesh Formation Info field
The Connected to Mesh Gate subfield is set to 1, if the mesh STA has a mesh path to a mesh gate that
announces its presence using GANN elements, RANN elements, or PREQ elements, and set to 0 otherwise.
The Number of Peerings subfield contains an unsigned integer that indicates the number of mesh peerings
currently maintained by the mesh STA or 63, whichever is smaller.
The Connected to AS subfield is set to 1 if the Authentication Protocol Identifier field in the Mesh
Configuration element is set to 2 (indicating IEEE 802.1X authentication) and the mesh STA has an active
connection to an AS.
NOTE—When an AS is collocated with an IEEE 802.1X Authenticator an active connection is implicitly true.
1027
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.98.8 Mesh Capability
The Mesh Capability field comprises a set of values indicating whether a mesh STA is a possible candidate
for mesh peering establishment. The details of the Mesh Capability field are shown in Figure 9-453.
B0 B1 B2 B3 B4 B5 B6 B7
Accepting Mesh
Additional MCCA MCCA MBCA TBTT
Mesh Supported Enabled Forwarding Enabled Adjusting Power Save Reserved
Level
Peerings
Bits: 1 1 1 1 1 1 1 1
Figure 9-453—Mesh Capability field
The Accepting Additional Mesh Peerings subfield is set to 1 if the mesh STA is willing to establish
additional mesh peerings with other mesh STAs and set to 0 otherwise (i.e., the Accepting Additional Mesh
Peerings subfield is set in accordance with dot11MeshAcceptingAdditionalPeerings). When the Mesh
Configuration element is included in the Mesh Peering Open frame and in the Mesh Peering Confirm frame,
the Accepting Additional Mesh Peerings subfield is set to 1.
The MCCA Supported subfield is set to 1 if the mesh STA implements MCCA and set to 0 otherwise (i.e.,
the MCCA Supported subfield is set in accordance with dot11MCCAImplemented).
The MCCA Enabled subfield is set to 1 if the mesh STA is using the MCCA and set to 0 otherwise (i.e., the
MCCA Enabled subfield is set in accordance with dot11MCCAActivated).
The Forwarding subfield is set to 1 if the mesh STA forwards MSDUs and set to 0 otherwise (i.e.,
the Forwarding subfield is set in accordance with dot11MeshForwarding).
The MBCA Enabled subfield is set to 1 if the mesh STA is using MBCA and is set to 0 otherwise (i.e., the
MBCA Enabled subfield is set in accordance with dot11MBCAActivated). (See 14.13.4.)
The TBTT Adjusting subfield is set to 1 while the TBTT adjustment procedure is ongoing and is set to 0
otherwise. (See 14.13.4.4.3.)
The Mesh Power Save Level subfield is set to 1 if at least one of the peer-specific mesh power management
modes is deep sleep mode and set to 0 otherwise. The Mesh Power Save Level subfield is reserved when the
Power Management subfield in the Frame Control field is set to 0. See 9.2.4.5.11.
9.4.2.99 Mesh ID element
The Mesh ID element is used to advertise the identification of an MBSS and is described in 14.2.2. The
format of the Mesh ID element is shown in Figure 9-454. The Mesh ID element is transmitted in Mesh
Peering Open frames, Mesh Peering Confirm frames, Mesh Peering Close frames, Beacon frames, and
Probe Request and Response frames.
Element ID Length Mesh ID
Octets: 1 1 0–32
Figure 9-454—Mesh ID element format
The Element ID and Length fields are defined in 9.4.2.1.
1028
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A Mesh ID field of length 0 indicates the wildcard Mesh ID, which is used within Probe Request frame.
Detailed usage of the Mesh ID element is described in 14.2.2.
9.4.2.100 Mesh Link Metric Report element
The Mesh Link Metric Report element is transmitted by a mesh STA to a neighbor peer mesh STA to
indicate the quality of the link between the transmitting mesh STA and the neighbor peer mesh STA. The
format of the Mesh Link Metric Report element is shown in Figure 9-455.
Element ID Length Flags Link Metric
Octets: 1 1 1 variable
Figure 9-455—Mesh Link Metric Report element format
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Flags field is shown in Figure 9-456.
B0 B1 B7
Request Reserved
Bits: 1 7
Figure 9-456—Flags field
The Flags field is set as follows:
— Bit 0: Request subfield (0 = not a request, 1 = link metric report request). A Request subfield equal to
1 indicates that the recipient of Mesh Link Metric Report element is requested to send a link metric
report to the transmitter of the Mesh Link Metric Report element.
— Bit 1–7: Reserved.
The Link Metric field indicates the value of the link metric associated with the mesh link between the peer
mesh STA transmitting the Mesh Link Metric Report and the neighbor mesh STA receiving the Mesh Link
Metric report. The length and the data type of the Link Metric field are determined by the active path
selection metric identifier (see 9.4.2.98.3). The length and the data type for the airtime link metric are given
in Table 14-5 in 14.9.
9.4.2.101 Congestion Notification element
The Congestion Notification element is used to indicate the congestion status of the mesh STA per mesh
destination and AC, and the duration for which the STA expects the congestion to last. The format of the
Congestion Notification element is shown in Figure 9-457. The Congestion Notification element is included
in Congestion Control Notification frames, as described in 9.6.17.5.
The Element ID and Length fields are defined in 9.4.2.1.
The Destination Mesh STA Address field is represented as a 48-bit MAC address and is set to the address of
the mesh destination for which the intra-mesh congestion control is applied. It is set to the broadcast address
if the intra-mesh congestion control is applied to all destinations.
1029
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Congestion Congestion Congestion Congestion
Destination Notification Notification Notification Notification
Element
ID Length Mesh STA Duration Duration Duration Duration
Address Timer Timer Timer Timer
(AC_BK) (AC_BE) (AC_VI) (AC_VO)
Octets: 1 1 6 2 2 2 2
Figure 9-457—Congestion Notification element format
The element contains four Congestion Notification Duration fields for the four EDCA access categories to
indicate the estimated congestion duration per AC at the mesh STA transmitting the congestion notification.
The congestion notification duration values are encoded as unsigned integers in units of 100 µs.
9.4.2.102 Mesh Peering Management element
The Mesh Peering Management element is used to manage a mesh peering with a neighbor mesh STA. The
format of the Mesh Peering Management element is shown in Figure 9-458.
Mesh Chosen
Peering Local Link Peer Link ID Reason Code
Element ID Length Protocol ID (optional) (optional) PMK
(optional)
Identifier
Octets: 1 1 2 2 0 or 2 0 or 2 0 or 16
Figure 9-458—Mesh Peering Management element format
The Element ID and Length fields are defined in 9.4.2.1.
The Mesh Peering Protocol Identifier field indicates the type of mesh peering protocol that is currently used
to establish mesh peerings. Table 9-222 provides the mesh peering protocol identifier values defined by this
standard.
Table 9-222—Mesh Peering Protocol Identifier field values
Value Meaning
0 Mesh peering management protocol
1 Authenticated mesh peering exchange protocol
2–254 Reserved
255 Vendor specific
(The active mesh peering protocol is specified in a Vendor Specific element)
256–65 535 Reserved
When the Mesh Peering Protocol Identifier field is 255, the active mesh peering protocol is specified by a
Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond
the scope of this standard. (See 9.4.2.26.)
The Local Link ID field is the unsigned integer value generated by the local mesh STA to identify the mesh
peering instance.
The conditional components of the Mesh Peering Management element are present depending on the Action
field value of the frame in which the Mesh Peering Management element is conveyed.
1030
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Peer Link ID field is the unsigned integer value generated by the peer mesh STA to identify the mesh
peering instance. This field is not present for the Mesh Peering Open frame, is present for the Mesh Peering
Confirm frame, and is optionally present for the Mesh Peering Close frame. The presence or absence of the
Peer Link ID in a Mesh Peering Close is inferred by the Length field.
The Reason Code field enumerates reasons for sending a Mesh Peering Close. It is present for the Mesh
Peering Close frame and is not present for Mesh Peering Open or Mesh Peering Confirm frames. The reason
code is defined in 9.4.1.7.
The Chosen PMK field is present when dot11MeshSecurityActivated is true and a PMK is shared between
the transmitter and receiver of the frame containing the element. It contains the PMKID that identifies the
PMK used to protect the mesh peering Management frame.
Detailed usage of the Mesh Peering Management element is described in 14.3.6, 14.3.7, 14.3.8, and 14.5.5.
9.4.2.103 Mesh Channel Switch Parameters element
The Mesh Channel Switch Parameters element is used together with Channel Switch Announcement
element and Extended Channel Switch Announcement element by a mesh STA to advertise to other mesh
STAs when it is changing to a new operating channel and/or operating class. The format of the Mesh
Channel Switch Parameters element is shown in Figure 9-459.
Reason Precedence
Element ID Length Time To Live Flags Code Value
Octets: 1 1 1 1 2 2
Figure 9-459—Mesh Channel Switch Parameters element format
The Element ID and Length fields are defined in 9.4.2.1.
The Time To Live field is coded as an unsigned integer and indicates the remaining number of hops allowed
for this element.
The Flags field indicates the attribute of this channel switch attempt. The format of the Flags field is shown
in Figure 9-460.
B0 B1 B2 B3 B7
Transmit Restrict Initiator Reason Reserved
Bits: 1 1 1 5
Figure 9-460—Flags field
The Transmit Restrict subfield is set to 1 when the mesh STA asks neighboring peer mesh STAs not to
transmit further frames except frames containing Mesh Channel Switch Parameters element on the current
channel until the scheduled channel switch. The Transmit Restrict subfield is set to 0 otherwise.
The Initiator subfield is set to 1 when the mesh STA initiates this channel switch attempt. The Initiator
subfield is set to 0 when this channel switch attempt is initiated by another mesh STA and propagated by the
current mesh STA.
1031
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Reason subfield indicates the validity of the Reason Code field. It is set to 1 if the Reason Code field is
valid and is set to 0 otherwise. When the Reason subfield is 0, the content of the Reason Code field is
reserved.
The Reason Code field specifies the reason for the mesh channel switch. The Reason Code is defined in
9.4.1.7. The content of the Reason Code field is valid only when Reason subfield of Flags field is set to 1
and is reserved otherwise.
The Precedence Value field is coded as unsigned integer and is set to a random value drawn from a uniform
distribution in the range 0 to 65 535 determined by the initiator of this channel switch attempt.
The Mesh Channel Switch Parameters element is included in Channel Switch Announcement frames, as
described in 9.6.2.6, and Extended Channel Switch Announcement frames, as described in 9.6.8.7. During
MBSS channel switching, the Mesh Channel Switch Parameters element is included in Beacon frames, as
described in 9.3.3.3, and Probe Response frames, as described in 9.3.3.11, until the scheduled channel
switch.
9.4.2.104 Mesh Awake Window element
The Mesh Awake Window element is present in DTIM Beacon frames and is optionally present in Beacon
and Probe Response frames. The format of the Mesh Awake Window element is shown in Figure 9-461.
Element ID Length Mesh Awake Window
Octets: 1 1 2
Figure 9-461—Mesh Awake Window element format
The Element ID and Length fields are defined in 9.4.2.1.
The Mesh Awake Window field is 2 octets long and contains an unsigned integer that indicates the duration
of the mesh awake window in TUs.
9.4.2.105 Beacon Timing element
The Beacon Timing element is used to advertise the beacon timing information of neighbor STAs (mesh
STAs, IBSS APs, or IBSS STAs). The format of the Beacon Timing element is shown in Figure 9-462.
Element ID Length Report Control Beacon Timing ... Beacon Timing
Information #1 Information #N
Octets: 1 1 1 6 ... 6
Figure 9-462—Beacon Timing element format
The Element ID and Length fields are defined in 9.4.2.1.
The Report Control field is used to signal information about the beacon timing information tuple contained
in the Beacon Timing element. The structure of the Report Control field is defined in Figure 9-463.
The Status Number subfield is set to the status number of the beacon timing information set. The status
number is managed as described in 14.13.4.2.4.
1032
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beacon Timing More Beacon
Status Number Element Number Timing Elements
Bits: 4 3 1
Figure 9-463—Report Control field
The Beacon Timing Element Number subfield is an unsigned integer that indicates the index of the beacon
timing information tuple contained in this Beacon Timing element. The Beacon Timing Element Number is
set to 0 in the Beacon Timing element for the first or only tuple of the beacon timing information and is
incremented by one for each successive tuple of the beacon timing information. The beacon timing
information tuples are managed as described in 14.13.4.2.5.
The More Beacon Timing Element subfield is set to 1 if a successive tuple of beacon timing information
exists, and set to 0 otherwise.
The Beacon Timing Information field contains the beacon timing information of a neighbor STA. When the
mesh STA reports multiple beacon timing information, multiple Beacon Timing Information fields are
included in the Beacon Timing element. The structure of the Beacon Timing Information field is defined in
Figure 9-464.
Neighbor Beacon
Neighbor STA ID Neighbor TBTT Interval
Octets: 1 3 2
Figure 9-464—Beacon Timing Information field
The Neighbor STA ID subfield is an unsigned integer that indicates the identification of the neighbor STA
corresponding to this beacon timing information. When a mesh peering is established with this neighbor
STA, the MSB of this field is set to 0, and the rest of this field is set to the last 7 digits (7 LSBs) of the AID
value assigned to this neighbor mesh STA. When a mesh peering is not established with this neighbor STA,
the MSB of this field is set to 1, and the rest of this field is set to the last 7 digits (7 LSBs, taking the I/G bit
as the MSB) of the 48-bit MAC address of this neighbor STA.
NOTE—Since the Neighbor STA ID subfield is provided in abbreviated form, it is possible that the same Neighbor STA
ID value appears in multiple Beacon Timing Information fields.
The Neighbor TBTT subfield is an unsigned integer that indicates a TBTT of the corresponding neighbor
STA, measured in the local TSF timer of the mesh STA. The value is indicated in multiples of 32 µs. When
the active synchronization method is the neighbor offset synchronization method, the TBTT is calculated as
described in 14.13.4.2.2. The B5 to the B28 (taking the B0 as the LSB) of the calculated TBTT are contained
in this subfield.
The Neighbor Beacon Interval subfield is an unsigned integer that indicates the beacon interval being used
by the corresponding neighbor STA. The unit of the Neighbor Beacon Interval subfield is TU.
Detailed usage of the Beacon Timing element is described in 14.13.4.2.
9.4.2.106 MCCAOP Setup Request element
9.4.2.106.1 General
The MCCAOP Setup Request element is used to make an MCCAOP reservation. This element is
transmitted in individually addressed MCCA Setup Request frames or in group addressed MCCA Setup
1033
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Request frames. The mesh STA transmitting the MCCA Setup Request element is the MCCAOP owner of
the MCCAOPs that will be scheduled with this reservation setup request. The receivers of the MCCAOP
Setup Request frame are the MCCAOP responders. The format of the element is shown in Figure 9-465.
Element ID Length MCCAOP MCCAOP
Reservation ID Reservation
Octets 1 1 1 5
Figure 9-465—MCCAOP Setup Request element format
The Element ID and Length fields are defined in 9.4.2.1.
The MCCAOP Reservation ID field is an eight bit unsigned integer that represents the ID for the MCCAOP
reservation. It is determined by the MCCAOP owner. When used in combination with the MAC address of
the MCCAOP owner, the MCCAOP Reservation ID uniquely identifies the MCCAOP reservation. If this
MCCAOP Setup Request element is for an individually addressed transmission, the MCCAOP Reservation
ID is between 0 and 127 and the MCCAOP Setup Request element is transmitted in an individually
addressed frame to the intended responder. If this MCCAOP Setup Request element is for a group addressed
transmission, the MCCAOP Reservation ID is between 128 and 254 and the MCCAOP Setup Request
element is transmitted in a group addressed frame. The value 255 is not used to identify a single MCCAOP
reservation.
The MCCAOP Reservation field is described in 9.4.2.106.2.
9.4.2.106.2 MCCAOP Reservation field
The MCCAOP Reservation field is a 5 octet field specifying a schedule for frame transmissions
called MCCAOPs. The MCCAOP Reservation field consists of three subfields and its format is shown in
Figure 9-466.
MCCAOP MCCAOP
Duration Periodicity MCCAOP Offset
Octets: 1 1 3
Figure 9-466—MCCAOP Reservation field
The MCCAOP Duration subfield is 1 octet in length and contains an unsigned integer. It specifies the
duration of the MCCAOPs in multiples of 32 µs.
The MCCAOP Periodicity subfield is 1 octet in length and contains a positive integer. It specifies the
number of MCCAOPs scheduled in each DTIM interval.
The MCCAOP Offset subfield is three octets in length and contains an unsigned integer. It specifies the
beginning of the first MCCAOP in each DTIM interval. The value is specified in multiples of 32 µs. The
sum of MCCAOP Offset plus MCCAOP Duration is constrained to be smaller than the duration of the
DTIM interval divided by MCCAOP Periodicity.
9.4.2.107 MCCAOP Setup Reply element
The MCCAOP Setup Reply element is used to reply to an MCCAOP Setup Request. This element is
transmitted in individually addressed MCCA Setup Reply frames. The mesh STA transmitting the MCCA
Setup Reply element is the MCCAOP responder of the MCCAOPs scheduled in this reservation setup. The
1034
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
receiver of the MCCAOP Setup Reply is the MCCAOP owner. The format of the element is shown in
Figure 9-467.
Element ID Length MCCAOP MCCA Reply MCCAOP
Reservation ID Code Reservation
Octets: 1 1 1 1 0 or 5
Figure 9-467—MCCAOP Setup Reply element format
The Element ID and Length fields are defined in 9.4.2.1.
The MCCAOP Reservation ID field is an eight bit unsigned integer that represents the ID for the requested
series of MCCAOPs. It is determined by the MCCAOP owner and copied from the MCCAOP Setup
Request element. When used in combination with the MAC address of the MCCAOP owner, the MCCAOP
Reservation ID uniquely identifies the MCCAOP reservation.
The MCCA Reply Code field is a 1 octet field that contains the reply code used in an MCCAOP Setup Reply
element. The reply codes are defined in Table 9-223.
Table 9-223—MCCA Reply Code field values
MCCA reply code Meaning
0 Accept
1 Reject: MCCAOP reservation conflict
2 Reject: MAF limit exceeded
3 Reject: MCCA track limit (dot11MCCAMaxTrackStates) exceeded
4–255 Reserved
The MCCAOP Reservation field includes an alternative to the MCCAOP reservation specified in the
MCCAOP Setup Request frame. Its format is described in 9.4.2.106.2. When the MCCA Reply Code is 1,
the MCCAOP Reservation field might be present. When the MCCA Reply Code is set to other values, the
MCCAOP Reservation field is not present.
9.4.2.108 MCCAOP Advertisement Overview element
The MCCAOP Advertisement Overview element is used by a mesh STA to advertise its MCCA Information
and information about its MCCAOP Advertisement elements, representing its MCCAOP advertisement set,
to its neighbors. This element is transmitted in MCCA Advertisement frames and optionally present in
Beacon frames. The format of the MCCAOP Advertisement Overview element is shown in Figure 9-468.
Element Advertisement Set MCCA Access MAF Advertisement
Length Flags
ID Sequence Number Fraction Limit Elements Bitmap
Octets 1 1 1 1 1 1 2
Figure 9-468—MCCAOP Advertisement Overview element format
1035
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The Advertisement Set Sequence Number field is 1 octet in length and is coded as an unsigned integer. It is
set to the advertisement set sequence number of the current MCCAOP advertisement set. The
Advertisement Set Sequence Number, together with the MAC address of the transmitter of the MCCAOP
Advertisement Overview element, identifies an MCCAOP advertisement set and provides an identifier and a
chronological order of different MCCAOP advertisement sets of the same mesh STA.
The format of the Flags field is shown in Figure 9-469.
B0 B1 B7
Accept Reserved
Reservations
Bits: 1 7
Figure 9-469—Flags field format
The Flags field is set as follows:
— Bit 0: Accept Reservations subfield. The Accept Reservations subfield is set to 1 if the mesh STA
accepts additional reservations. It is set to 0 otherwise.
— Bit 1–7: Reserved
The MCCA Access Fraction field is an eight bit unsigned integer. The MCCA Access Fraction field is set to
the current value of the MCCA access fraction at the mesh STA rounded down to the nearest multiple of (1/
255) of the DTIM interval length.
The MAF Limit field is an eight bit unsigned integer. The MAF Limit field is set to the maximum MCCA
access fraction allowed at the mesh STA rounded down to the nearest multiple of (1/255) of the DTIM
interval length.
The Advertisement Elements Bitmap field is 2 octets in length and indicates the MCCAOP Advertisement
elements that are part of this MCCAOP advertisement set. The Advertisement Elements Bitmap field is a
bitmap. Bit i in this bitmap equals 1 if the MCCAOP Advertisement element with MCCAOP Advertisement
Element Index equal to i is part of this MCCAOP advertisement set, and it equals 0 otherwise.
9.4.2.109 MCCAOP Advertisement element
9.4.2.109.1 General
The MCCAOP Advertisement element is used by a mesh STA to advertise MCCAOP reservations to its
neighbors. This element is transmitted in MCCA Advertisement frames and optionally present in Beacon
frames. The format of the element is shown in Figure 9-470.
MCCAOP TX-RX Broadcast Interference
Element Length Advertisement Set Advertisement Periods Periods Periods
ID Sequence Number
Element Information Report Report Report
Octets: 1 1 1 1 variable variable variable
Figure 9-470—MCCAOP Advertisement element format
1036
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The Advertisement Set Sequence Number field is 1 octet in length and is coded as an unsigned integer. It is
set to the advertisement set sequence number of the current MCCAOP advertisement set. The
Advertisement Set Sequence Number, together with the MAC address of the transmitter of the MCCAOP
Advertisement element, identifies an MCCAOP advertisement set and provides an identifier and a
chronological order of different MCCAOP advertisement sets of the same mesh STA.
The MCCAOP Advertisement Element Information field is 1 octet in length. It is described in 9.4.2.109.2.
The TX-RX Periods Report field is a variable-length field that contains an MCCAOP Reservation Report
field, as described in 9.4.2.109.3. This field is present when the TX-RX Report Present subfield of the
MCCAOP Advertisement Element Information field is equal to 1; it is not present otherwise. The TX-RX
Periods Report field is described in 10.23.3.7.2.
The Broadcast Periods Report field is a variable-length field that contains an MCCAOP Reservation Report
field, as described in 9.4.2.109.3. This field is present when the Broadcast Report Present subfield of the
MCCAOP Advertisement Element Information field is equal to 1; it is not present otherwise. The Broadcast
Periods Report field is described in 10.23.3.7.2.
The Interference Periods Report field is a variable-length field that contains an MCCAOP Reservation
Report field, as described in 9.4.2.109.3. This field is present when the Interference Report Present subfield
of the MCCAOP Advertisement Element Information field is equal to 1; it is not present otherwise. The
Interference Periods Report field is described in 10.23.3.7.2.
9.4.2.109.2 MCCAOP Advertisement Element Information field
The MCCA Information field is 1 octets in length and provides information on the MCCAOP reservations.
The field consists of four subfields and its format is shown in Figure 9-471.
B0 B3 B4 B5 B6 B7
MCCAOP TX-RX Broadcast Interference
Advertisement Report Report Report Reserved
Element Index Present Present Present
Bits: 4 1 1 1 1
Figure 9-471—MCCAOP Advertisement Element Information field
The MCCAOP Advertisement Element Index subfield is a 4-bit unsigned integer. It identifies the MCCAOP
Advertisement element.
The TX-RX Report Present subfield is 1 bit in length. It is set to 1 if the TX-RX Periods Report field is
present in the MCCAOP Advertisement element and set to 0 if no TX-RX Periods Report field is present.
The Broadcast Report Present subfield is 1 bit in length. It is set to 1 if the Broadcast Periods Report field is
present in the MCCAOP Advertisement element and set to 0 if no Broadcast Periods Report field is present.
The Interference Report Present subfield is 1 bit in length. It is set to 1 if the Interference Periods Report
field is present in the MCCAOP Advertisement element and set to 0 if no Interference Periods Report field is
present.
1037
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.109.3 MCCAOP Reservation Report field
The MCCAOP Reservation Report field is of variable length and is used to report a number of MCCAOP
reservations. The field consists of a variable number of subfields and its format is shown in Figure 9-472.
Number of Reported MCCAOP MCCAOP
MCCAOP
Reservations Reservation 1 ... Reservation n
Octets: 1 5 5
Figure 9-472—MCCAOP Reservation Report field
The Number of Reported MCCAOP reservations is a field of 1 octet with an unsigned integer that specifies
the number, n, of MCCAOP Reservations reported in this MCCAOP Reservation Report field.
The MCCAOP Reservation 1 through MCCAOP Reservation n fields specify the MCCAOP reservations
reported. Each MCCAOP Reservation field is 5 octets in length and its format is shown in Figure 9-466 in
9.4.2.106.2.
9.4.2.110 MCCAOP Teardown element
The MCCAOP Teardown element is used to announce the teardown of an MCCAOP reservation. The
MCCAOP Teardown element is transmitted in individually addressed MCCA Teardown frames or in group
addressed MCCA Teardown frames. Its format is shown in Figure 9-473.
MCCAOP
Element ID Length MCCAOP Owner
Reservation ID
Octets: 1 1 1 0 or 6
Figure 9-473—MCCAOP Teardown element format
The Element ID and Length fields are defined in 9.4.2.1.
An MCCAOP Teardown element is transmitted by either the MCCAOP owner or the MCCAOP responder
of a MCCAOP reservation to tear down the MCCAOP reservation.
The MCCAOP Reservation ID field is an eight bit unsigned integer that represents the ID for the MCCAOP
reservation.
The MCCAOP Owner field is an optional field. It is 6 octets long and indicates the 48-bit MAC address of
the MCCAOP owner. This field is included if the element is transmitted by the MCCAOP responder; it is
not included otherwise.
1038
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.111 GANN element
The GANN (gate announcement) element is used for announcing the presence of a mesh gate in the MBSS.
The GANN element is transmitted in a Gate Announcement frame (see 9.6.17.4). The format of the GANN
element is shown in Figure 9-474.
Element Element Mesh GANN
Length Flags Hop Count Gate Sequence Interval
ID TTL Address Number
Octets: 1 1 1 1 1 6 4 2
Figure 9-474—GANN element format
The Element ID and Length fields are defined in 9.4.2.1.
The Flags field is reserved.
The Hop Count field is coded as an unsigned integer and indicates the number of hops from the originating
mesh gate to the mesh STA transmitting this element.
The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed
for this element.
The Mesh Gate Address field is represented as a 48-bit MAC address and is set to the MAC address of the
mesh gate.
The GANN Sequence Number field is coded as an unsigned integer and is set to a GANN Sequence Number
specific for the originating mesh gate.
The Interval field is coded as an unsigned integer and is set to the number of seconds between the periodic
transmissions of Gate Announcements by the mesh gate.
Detailed usage of the GANN element is described in 14.11.2.
9.4.2.112 RANN element
The RANN (root announcement) element is used for announcing the presence of a mesh STA configured as
root mesh STA with dot11MeshHWMProotMode set to rann (4). RANN elements are sent out periodically
by such a root mesh STA. The RANN element is transmitted in an HWMP Mesh Path Selection frame (see
9.6.17.3). The format of the RANN element is shown in Figure 9-475.
Root Mesh HWMP
Element ID Length Flags Hop Element STA Sequence Interval Metric
Count TTL
Address Number
Octets: 1 1 1 1 1 6 4 4 4
Figure 9-475—RANN element format
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Flags field is shown in Figure 9-476.
1039
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B7
Gate Announcement Reserved
Bits: 1 7
Figure 9-476—Flags field format
The Flags field is set as follows:
— Bit 0: Gate Announcement subfield (0 = gate announcement protocol not activated, 1 = gate
announcement protocol activated). A Gate Announcement subfield equal to 1 indicates that the Root
Mesh STA Address is a mesh gate with dot11MeshGateAnnouncements equal to true.
— Bit 1–7: Reserved.
The Hop Count field is coded as an unsigned integer and indicates the number of hops from the originating
root mesh STA to the mesh STA transmitting this element.
The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed
for this element.
The Root Mesh STA Address field is represented as a 48-bit MAC address and is set to the MAC address of
the root mesh STA.
The HWMP Sequence Number field is coded as an unsigned integer and is set to the HWMP sequence
number (SN) specific to the root mesh STA.
The Interval field is coded as an unsigned integer and is set to the number of TUs between the periodic
transmissions of Root Announcements.
The Metric field is set to the cumulative metric from the originating root mesh STA to the mesh STA
transmitting the announcement.
Detailed usage of the RANN element is described in 14.10.12.
9.4.2.113 PREQ element
The PREQ (path request) element is used for discovering a path to one or more target mesh STAs,
maintaining a path (optional), building a proactive (reverse) path selection tree to the root mesh STA, and
confirming a path to a target mesh STA (optional). The PREQ element is transmitted in an HWMP Mesh
Path Selection frame (see 9.6.17.3). The format of the PREQ element is shown in Figure 9-477.
Path Originator Originator Originator
Element Hop Element HWMP
ID Length Flags Count TTL Discovery Mesh STA Sequence External Lifetime
ID Address Address
Number
Octets: 1 1 1 1 1 4 6 4 0 or 6 4
Target Target
Per Target HWMP Per Target HWMP
Metric Target Target Address Sequence ... Target Address Sequence
Count
Flags #1 #1 Number Flags #N #N Number
#1 #N
4 1 1 6 4 ... 1 6 4
Figure 9-477—PREQ element format
1040
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Flags field is shown in Figure 9-478.
B0 B1 B2 B3 B5 B6 B7
Gate Addressing Proactive Reserved AE Reserved
Announcement Mode PREP
Bits 1 1 1 3 1 1
Figure 9-478—Flags field format
The Flags field is set as follows:
— Bit 0: Gate Announcement subfield (0 = gate announcement protocol not activated, 1 = gate
announcement protocol activated). A Gate Announcement subfield equal to 1 indicates that the
Originator Mesh STA Address is a mesh gate with dot11MeshGateAnnouncements equal to true.
— Bit 1: Addressing Mode subfield (0 = group addressed, 1 = individually addressed). When the
Addressing Mode subfield is 0, the PREQ element is sent in an HWMP Mesh Path Selection frame
that is group addressed to all neighbor peer mesh STAs. When the Addressing Mode subfield is 1,
the PREQ element is sent in an HWMP Mesh Path Selection frame that is individually addressed to
a neighbor peer mesh STA. Detailed addressing information is provided in 14.10.7.
— Bit 2: Proactive PREP subfield (0 = off, 1 = on). The Proactive PREP subfield is of relevance only if
the Target Address is the broadcast address (all 1s). If equal to 1, every recipient of a PREQ element
with Target Address equal to the broadcast address replies with a PREP element. If equal to 0, a
recipient replies only under certain conditions (see 14.10.4.2) and does not reply otherwise.
— Bit 3–5: Reserved.
— Bit 6: AE (Address Extension) subfield (1= external address present, 0 = otherwise). An AE subfield
equal to 1 indicates that the field Originator External Address is present, and that the originator mesh
STA is a proxy for this external address.
— Bit 7: Reserved.
The Hop Count field is coded as an unsigned integer and is set to the number of hops from the originator to
the mesh STA transmitting this element.
The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed
for this element.
The Path Discovery ID field is coded as an unsigned integer and is set to some unique ID for this
PathDiscovery.
The Originator Mesh STA Address field is represented as a 48-bit MAC address and is set to the originator
MAC address.
The Originator HWMP Sequence Number field is coded as an unsigned integer and is set to the HWMP SN
specific to the originator.
The Originator External Address field is the MAC address of an external STA proxied by the Originator.
This field is present only if the AE subfield in the Flags field is set to 1 and is represented as a 48-bit MAC
address.
The Lifetime field is coded as an unsigned integer and is set to the time for which mesh STAs receiving the
PREQ element consider the forwarding information to be valid. The lifetime is measured in TUs.
1041
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Metric field is set to the cumulative metric from the originator to the mesh STA transmitting the PREQ
element.
The Target Count N field is coded as an unsigned integer and gives the number of targets (N) contained in
this PREQ element. The maximum value of N is 20. The Per Target Flags field, the Target Address field,
and the Target HWMP Sequence Number field are repeated N times in the element.
The format of the Per Target Flags field is shown in Figure 9-479.
B0 B1 B2 B3 B7
TO Reserved USN Reserved
Bits: 1 1 1 5
Figure 9-479—Per Target Flags field format
The Per Target Flags field is set as follows:
— Bit 0: TO (Target Only) subfield: The TO subfield defines which mesh STA responds with a PREP
element to the PREQ element containing an individual target address. If TO = 1, only the target mesh
STA responds. If TO = 0, intermediate mesh STAs with active forwarding information to the target
mesh STA also respond. See 14.10.10.3.
— Bit 1: Reserved.
— Bit 2: USN (Unknown Target HWMP Sequence Number) subfield: The USN subfield indicates
whether the Target HWMP Sequence Number field of the corresponding target is interpreted as
HWMP SN (USN = 0) or not (USN = 1), the latter meaning that a target HWMP SN is unknown at
the originator mesh STA.
— Bit 3–7: Reserved.
The Target Address field is represented as a 48-bit MAC address.
The Target HWMP Sequence Number field is coded as an unsigned integer and is the latest known HWMP
SN received in the past by the originator mesh STA for any path toward the target. If such a target
HWMP SN is not known, the USN subfield is set to 1 and Target HWMP Sequence Number field is
reserved.
Detailed usage of the PREQ element is described in 14.10.9.
9.4.2.114 PREP element
The PREP (path reply) element is used to establish a forward path to a target and to confirm that a target is
reachable. The PREP element is issued in response to a PREQ element. The PREP element is transmitted
in an HWMP Mesh Path Selection frame (see 9.6.17.3). The format of the PREP element is shown in
Figure 9-480.
1042
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Target
Element Element Target HWMP Target
Length Flags Hop Count Mesh STA External Lifetime
ID TTL Address Sequence Address
Number
Octets: 1 1 1 1 1 6 4 0 or 6 4
Originator
Originator HWMP
Metric Mesh STA
Address Sequence
Number
4 6 4
Figure 9-480—PREP element format
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Flags field is shown in Figure 9-481.
B0 B5 B6 B7
Reserved AE Reserved
Bits: 6 1 1
Figure 9-481—Flags field format
The Flags field is set as follows:
— Bit 0–5: Reserved.
— Bit 6: AE (Address Extension) subfield (1 = external address present, 0 = otherwise). An AE
subfield equal to 1 indicates that the field Target External Address is present, and that the target
mesh STA is a proxy for this external address.
— Bit 7: Reserved.
The Hop Count field is coded as an unsigned integer and is set to the number of hops from the path target to
the mesh STA transmitting this element.
The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed
for this element.
The Target Mesh STA Address is the MAC address of the target mesh STA or target proxy mesh gate and is
represented as a 48-bit MAC address.
The Target HWMP Sequence Number field is coded as an unsigned integer and is set to the HWMP SN of
the target mesh STA (if the AE subfield in the Flags field is set to 0) or target proxy mesh gate (if the AE
subfield in the Flags field is set to 1).
The Target External Address field is set to the external address on behalf of which the PREP element is sent.
This field is present only if Bit 6 (AE subfield) in Flags field equals 1 and is represented as a 48-bit MAC
address.
The Lifetime field is coded as an unsigned integer and is set to the time for which mesh STAs receiving the
PREP element consider the forwarding information to be valid. The lifetime is measured in TUs.
1043
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Metric field indicates the cumulative metric from the path target to the mesh STA transmitting this
element.
The Originator Mesh STA Address field is represented as a 48-bit MAC address and is set to the MAC
address of the originator, which is contained in the PREQ element.
The Originator HWMP Sequence Number field is coded as an unsigned integer and is set to the HWMP SN
of the originator mesh STA contained in the PREQ element.
The detailed usage of the PREP element is described in 14.10.10.
9.4.2.115 PERR element
The PERR (path error) element is used for announcing an unreachable destination. The PERR element is
transmitted in an HWMP Mesh Path Selection frame (see 9.6.17.3). The format of the PERR element
is shown in Figure 9-482.
Number of Destination HWMP Destination Reason
Element Length Element Flags Sequence External
ID TTL Destinations #1 Address #1 Number Address Code #1 ...
N
#1 #1
Octets: 1 1 1 1 1 6 4 0 or 6 2
Figure 9-482—PERR element format
The Element ID and Length fields are defined in 9.4.2.1.
The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed
for this element.
The Number of Destinations N field is coded as an unsigned integer and indicates the number of announced
destinations in PERR. The maximum value of N is 19. The Flags field, the Destination Address field, the
HWMP Sequence Number field, the Destination External Address field, and the Reason Code field are
repeated N times in the element.
The format of the Flags field is shown in Figure 9-483.
B0 B5 B6 B7
Reserved AE Reserved
Bits: 4 1 1
Figure 9-483—Flags field format
The Flags field is set as follows:
— Bit 0–5: Reserved.
— Bit 6: AE (Address Extension) subfield (1 = destination external address is present, 0 = otherwise).
— Bit 7: Reserved.
The Destination Address field is represented as a 48-bit MAC address and indicates the detected
unreachable destination MAC address.
1044
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The HWMP Sequence Number field is coded as an unsigned integer and indicates the HWMP SN for the
invalidated destination, if applicable. Otherwise, the HWMP Sequence Number field is reserved depending
on the reason code.
The Destination External Address field is set to the external address, on behalf of which the PERR is sent.
This field is present only if Bit 6 (AE subfield) in the Flags field equals 1 and is represented as a 48-bit MAC
address.
The Reason Code field specifies the reason for sending a PERR element. The Reason Code is defined in
9.4.1.7.
The detailed usage of the PERR element is described in 14.10.11.
9.4.2.116 PXU element
The PXU (proxy update) element is used to inform the destination mesh STA of the proxy information at the
originator mesh STA. The PXU element is transmitted in a Proxy Update frame (see 9.6.18.2). The format
of the PXU element is shown in Figure 9-484.
PXU Number of Proxy Proxy
Element Originator Proxy
Length PXU ID Information ... Information
ID MAC Information #1 #N
Address (N)
11, 15, 17, or 11, 15, 17, or
Octets: 1 1 1 6 1 21 21
Figure 9-484—PXU element format
The Element ID and Length fields are defined in 9.4.2.1.
The PXU ID field is coded as an unsigned integer and is set to the sequence number of the PXU. The source
mesh STA sets the PXU ID field in the PXU element to a value from a single modulo 256 counter that is
incremented by 1 for each new PXU element.
The PXU Originator MAC Address field is represented as a 48-bit MAC address and is the MAC address of
the mesh STA that originates this PXU element.
The Number of Proxy Information fields is coded as an unsigned integer and is set to the number N of Proxy
Information field that follow this field and that are reported to the destination mesh STA. The maximum
value of N is 22.
The Proxy Information field contains a single proxy information (see 14.11.4.2). The length of the Proxy
Information field depends on the settings of the subfields in the Flags subfield and is 11, 15, 17, or 21 octets.
The format of the Proxy Information field is defined in Figure 9-485.
Proxy
External MAC Information Proxy MAC Proxy
Flags Information
Address Sequence Address Lifetime
Number
Octets: 1 6 4 0 or 6 0 or 4
Figure 9-485—Proxy Information field
1045
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The format of the Flags subfield is shown in Figure 9-486.
B0 B1 B2 B3 B7
Delete Originator Is Lifetime Reserved
Proxy
Bits: 1 1 1 5
Figure 9-486—Flags subfield
The Flags subfield is set as follows:
— Bit 0: The Delete subfield indicates whether this proxy information is to be deleted. It is set to 1 if the
proxy information is to be deleted, and set to 0 otherwise.
— Bit 1: The Originator Is Proxy subfield indicates that the originator mesh STA of the PXU element is
the proxy mesh gate of this proxy information when set to 1. In this case, there is no Proxy MAC
Address subfield present in this Proxy Information field. When the Originator Is Proxy subfield is 0,
the Proxy MAC Address subfield is present in this Proxy Information field.
— Bit 2: The Lifetime subfield indicates that the Proxy Information Lifetime subfield is present in this
Proxy Information field when set to 1.
— Bit 3–7: Reserved.
The External MAC Address subfield is represented as a 48-bit MAC address and is the MAC address of the
external STA proxied by the proxy mesh gate.
The Proxy Information Sequence Number field is coded as an unsigned integer and is set to the sequence
number of the proxy information. The sequence number of the proxy information defines a chronological
order of the proxy information for the external STA at this proxy mesh gate.
The Proxy MAC Address subfield is represented as a 48-bit MAC address and is set to the MAC address of
proxy mesh gate. It is present if the Originator Is Proxy subfield of the Flags subfield is 0; it is not present
otherwise.
The Proxy Information Lifetime subfield is coded as an unsigned integer and is set to the time for which the
mesh STA receiving this PXU considers this proxy information to be valid. The proxy information lifetime
is measured in TUs. It is present if the Lifetime subfield of the Flags subfield is 1; it is not present otherwise.
9.4.2.117 PXUC element
The PXUC (proxy update confirmation) element is used to confirm the previously received PXU. The
PXUC element is transmitted in a Proxy Update Confirmation frame (see 9.6.18.3). The format of PXUC
element is shown in Figure 9-487.
PXU Recipient
Element ID Length PXU ID MAC Address
Octets 1 1 1 6
Figure 9-487—PXUC element format
The Element ID and Length fields are defined in 9.4.2.1.
1046
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PXU ID field is coded as an unsigned integer and is the PXU ID of the received PXU that is being
confirmed.
The PXU Recipient MAC Address is represented as a 48-bit MAC address and is set to the MAC address of
the recipient of the PXU, i.e., the originator of the PXUC element.
9.4.2.118 Authenticated Mesh Peering Exchange element
The Authenticated Mesh Peering Exchange element includes information needed to perform
the authentication sequence during an authenticated mesh peering exchange. This element is shown in
Figure 9-488.
Element Selected Local Peer Key Replay GTKdata IGTKdata
Length Pairwise Counter
ID Cipher Suite Nonce Nonce (optional) (optional) (optional)
Octets 1 1 4 32 32 8 variable variable
Figure 9-488—Authenticated Mesh Peering Exchange element format
The Element ID and Length fields are defined in 9.4.2.1.
The Selected Pairwise Cipher Suite field contains a pairwise cipher suite selector, as defined in 9.4.2.25.2,
indicating a cipher suite to be used to secure the link.
The Local Nonce field contains a nonce value chosen by the mesh STA that is sending the element. It is
encoded following the conventions from 9.2.2.
The Peer Nonce field contains a nonce value that was chosen by the peer mesh STA or candidate peer mesh
STA to which the element is being sent. It is encoded following the conventions from 9.2.2.
The Key Replay Counter field is optional. It is used only for the Mesh Group Key Inform frame (see 14.6.3)
and the Mesh Group Key Acknowledge frame (see 14.6.4). It is represented as an unsigned integer.
The GTKdata field is optional. When present, it contains the bit string of {GTK || Key RSC ||
GTKExpirationTime} as the GTK data material. When present, the GTKdata field is protected by the
exchange in which it is contained (see 14.5). The Key RSC denotes the last TSC or PN sent using the GTK
and is specified in Table 12-5 of 12.7.2. GTKExpirationTime denotes the key lifetime of the GTK in
seconds and the format is specified in Figure 12-40 of 12.7.2.
The IGTKdata field is present when dot11RSNAProtectedManagementFramesActivated equals true. When
present, it contains the Key ID, IPN and IGTK used with BIP for management frame protection. The format
of the IGTKdata field is specified in Figure 12-42 of 12.7.2.
Detailed usage of the Authenticated Mesh Peering Exchange element is described in 14.5.5 and in 14.6.
9.4.2.119 MIC element
The MIC element provides message integrity to mesh peering Management frames. The format of the MIC
element is shown in Figure 9-489.
1047
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Element ID Length MIC
Octets: 1 1 16
Figure 9-489—MIC element format
The Element ID and Length fields are defined in 9.4.2.1.
The MIC field contains a message integrity code calculated over the mesh peering Management frame (as
specified in 14.5) and the mesh group key handshake frame (as specified in 14.6).
9.4.2.120 Quality-of-Service Management Frame Policy element
The Quality-of-Service Management Frame (QMF) Policy element defines a QMF access category mapping
(QACM) of Management frames and is used to advertise and exchange QMF policy between STAs. The use
of the QMF Policy element is given in 11.26. See Figure 9-490.
Element ID Length QACM #1 ... QACM #N
Octets: 1 1 variable variable
Figure 9-490—QMF Policy element format
The Element ID and Length fields are defined in 9.4.2.1.
The QACM field specifies a group of Management frames and their associated access categories. See
Figure 9-491 and see 11.26.3.
QACM Header Action Frame Category Action Value Bitmap
(optional) (optional)
Octets: 2 0 or 1 variable
Figure 9-491—QACM field format
The format of the QACM Header subfield of the QACM field is defined in Figure 9-492.
B0 B1 B2 B7 B8 B9 B10 B11 B12 B15
QACM Field Type QACM Field Length I G ACI Management Frame Subtype
Bits: 2 6 1 1 2 4
Figure 9-492—QACM Header subfield
The QACM Field Type subfield is 2 bits in length and defines the structure of the QACM field. Its value is
0. Values 1, 2, and 3 are reserved.
The QACM Field Length subfield is 6 bits in length and defines the length in octets of the QACM field
excluding the QACM Header subfield.
The Individually Addressed subfield (I) is 1 bit in length. When the QACM applies to individually
addressed Management frames, the value of the Individually Addressed subfield is 1. Otherwise, it is 0.
The Group Addressed subfield (G) is 1 bit in length. When the QACM applies to group addressed
Management frames, the value of the Group Addressed subfield is 1. Otherwise, it is 0.
1048
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The combination of I = 0 and G = 0 is not allowed.
The ACI subfield is 2 bits in length. Each Management frame that is listed in the QACM Header subfield is
transmitted using the access category identified by the accompanying ACI subfield.
The Management Frame Subtype subfield is 4 bits in length. It indicates the subtype of Management frames
that are sent using the access category indicated in the ACI subfield. The valid values for this subfield are
the subtypes in Table 9-1 that correspond to Management frames.
The Action Frame Category subfield is 1 octet in length and indicates the category of the Action frame, as
defined in 9.4.1.1, of Action frames that are sent using the access category indicated in the ACI subfield.
The Action Frame Category subfield is included only when the Management Frame Subtype subfield
indicates Action or Action No Ack subtype as specified in 11.26.3.
The Action Value Bitmap subfield is included when the QACM Policy is specified for a subset of Action
frame types in a Action Frame Category. The Action Value Bitmap subfield is of variable length and
indicates the action values, as defined in 9.6, for the corresponding Action frame category that are sent using
the access category indicated in the ACI subfield. The Action Value Bitmap subfield is included only when
the Management Frame Subtype subfield indicates Action or Action No Ack subtype and the QACM Field
Length subfield is greater than or equal to 2. Each bit in the Action Value Bitmap subfield is mapped to the
corresponding action value. The Action Value Bitmap subfield is zero padded to complete any incomplete
octet. When included, the size in octets of the Action Value Bitmap field is found by subtracting 1 from the
value of the QACM Field Length subfield.
9.4.2.121 Intra-Access Category Priority element
The Intra-Access Category Priority element provides information from a non-AP STA to an AP on the
relative priorities of streams within an AC, as described in 10.2.4.2 and 11.27.2. This element is optionally
present in ADDTS Request, QoS Map Configure, or SCS Request frames. The Intra-Access Category
Priority element is defined in Figure 9-493.
Element ID Length Intra-Access Priority
Octets: 1 1 1
Figure 9-493—Intra-Access Category Priority element format
The Element ID and Length fields are defined in 9.4.2.1.
The Intra-Access Priority field is defined in Figure 9-494.
B0 B2 B3 B4 B5 B7
User Priority Alternate Queue Drop Eligibility Reserved
Bits: 3 1 1 3
Figure 9-494—Intra-Access Priority field format
The User Priority subfield indicates the UP of MSDUs or A-MSDUs of the stream to which this Intra-
Access Category Priority element relates.
The Alternate Queue subfield indicates the intended primary or alternate EDCA queue that is used for this
stream. When dot11AlternateEDCAActivated is false, this subfield is reserved. When the Alternate Queue
1049
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
subfield is set to 0, the primary EDCA queue for this AC is used. When the Alternate Queue subfield is
equal to 1, the Alternate EDCA queue for this AC (see 10.2.4.2) is used.
The Drop Eligibility subfield is 1 bit in length and is used to indicate the suitability of this TS to be
discarded if there are insufficient resources. If there are insufficient resources, a STA should discard the
MSDUs or A-MSDUs of a TS with a Drop Eligibility subfield equal to 1, in preference to MSDUs or
A-MSDUs of a TS whose Drop Eligibility subfield is equal to 0. See 11.26.2. The mechanisms for
determining whether the resources are insufficient or when to discard MSDUs or A-MSDUs are beyond the
scope of this standard.
9.4.2.122 SCS Descriptor element
The SCS Descriptor element defines information about the stream that is being classified using the
procedures defined in 11.27.2. The format of the SCS Descriptor element is shown in Figure 9-495.
zero or
more
TCLAS
Elements
Intra-
Access TCLAS
TCLAS
Element Length SCSID Request Category Elements Processing Optional
ID Type Priority Element Subelements
Element (optional) (optional)
(optional)
Octets: 1 1 1 1 0 or 3 variable 0 or 3 variable
Figure 9-495—SCS Descriptor element format
The Element ID and Length fields are defined in 9.4.2.1.
The SCSID field is set to a nonzero value chosen by the non-AP STA identifying the SCS stream specified
in this SCS Descriptor element.
The Request Type field is set to a number to identify the type of SCS request. The Request Types are shown
in Table 9-224.
Table 9-224—SCS Request Type definitions
Name Value
Add 0
Remove 1
Change 2
Reserved 3–255
The Intra-Access Category Priority Element field is present when Request Type field is equal to “Add” or
“Change” and is defined in 9.4.2.121.
The TCLAS Elements field contains zero or more TCLAS elements to specify how incoming MSDUs are
classified as part of this SCS stream, as defined in 9.4.2.31. One or more TCLAS elements are present when
Request Type field is equal to “Add” or “Change,” and no TCLAS elements are present when Request Type
field is equal to “Remove.”
1050
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The TCLAS Processing Element field is present when more than one TCLAS element is present in the
TCLAS Elements field and contains a TCLAS Processing element that defines how the multiple TCLAS
elements are to be processed, as defined in 9.4.2.33.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Optional Subelement ID field values for the defined subelements are shown in Table 9-225.
Table 9-225—Optional subelement IDs for SCS Descriptor element
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
The SCS Descriptor element is included in SCS Request frames, as described in 9.6.19.2. The use of the
SCS Descriptor element and SCS Request frames is described in 11.27.2.
9.4.2.123 QLoad Report element
9.4.2.123.1 QLoad Report element format
The QLoad Report element contains the set of parameters necessary to support OBSS management. The
format of the QLoad Report element is provided in Figure 9-496.
Potential Allocated EDCA HCCA
Element Allocated HCCA Sharing Optional
ID Length Traffic Traffic Self Traffic Access Peak Access Overlap Policy Subelements
Self Shared Factor Factor
Octets: 1 1 5 5 5 1 2 1 1 1 variable
Figure 9-496—QLoad Report element format
The Element ID and Length fields are defined in 9.4.2.1.
Potential Traffic Self, Allocated Traffic Self, and Allocated Traffic Shared fields use the QLoad field format
as described in 9.4.2.123.2.
The Potential Traffic Self field represents the peak composite QoS traffic for this BSS if all of the potential
admission control and HCCA TSPECs from the non-AP STAs are active. The methods for gathering the
total potential TSPEC information are described in 11.28.2.
The Allocated Traffic Self field represents the composite QoS traffic for this BSS based upon all of the
admission control and HCCA TSPECs admitted within the same BSS, as described in 11.28.2.
The Allocated Traffic Shared field represents the sum of the Allocated Traffic Self field values that have
been received or obtained from other APs whose beacons have been detected or obtained within the last 100
beacon periods, plus the Allocated Traffic Self field value of the AP itself. Computation of the values
represented in the Allocated Traffic Shared field is described in 11.28.2.
1051
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
As described in 11.28.2, the EDCA Access Factor field value is the sum of the Potential Traffic Self field
values that have been received or obtained from other APs, plus the Potential Traffic Self field value of the
AP itself, minus the sum of the HCCA Peak field values that have been received or obtained from
overlapping APs, minus the HCCA Peak field value of the AP itself. The EDCA Access Factor is expressed
as a fraction rounded down to a multiple of 1/64. When the EDCA Access Factor is greater than 254/64, the
EDCA Access Factor field is set to 255.
The HCCA Peak field is the total peak HCCA TXOP requirement, over a period of 1 s, for the AP and BSS,
for all of the HCCA TSPECs that are included in the QLoad. HCCA Peak is expressed in multiples of 32 µs
over a period of 1 s. The HCCA Peak field is reserved if HCCA is not supported.
NOTE Because the HCCA peak is calculated over 1 s periods, its value might be an underestimate of the instantaneous
peak of interactive variable bit rate (VBR) flows.
The HCCA Access Factor field value is the sum of the HCCA Peak field values in the QLoad Report
elements that have been received from the APs of OBSSs, plus the HCCA Peak field value of the AP itself,
as described in 11.28.2. It is expressed as a fraction rounded down to a multiple of 1/64. When the HCCA
Access Factor is greater than 254/64, the HCCA Access Factor field is set to 255.
The Overlap field indicates the number of other APs that are sharing the same channel and whose beacons
have been detected or obtained within the last 100 beacon periods by the AP issuing this beacon.
The Sharing Policy field contains the currently active sharing policy. The values for the Sharing Policy field
are described in Table 9-226.
Table 9-226—Sharing Policy definitions
Sharing Policy field value Current sharing policy
0 Not specified
1 Static
2 Dynamic
3–220 Reserved
221 Vendor Specific
222–255 Reserved
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-227.
Table 9-227—Optional subelement IDs for QLoad Report element
Subelement ID Name Extensible
0–220 Reserved
221 Vendor Specific
222–255 Reserved
1052
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.123.2 QLoad field format
The QLoad field format is described in Figure 9-497.
B0 B15 B16 B29 B30 B31 B32 B35 B36 B39
Mean Standard Reserved AC_VO AC_VI Streams
Deviation Streams
Bits: 16 14 2 4 4
Figure 9-497—QLoad field format
The Mean subfield represents the amount of time admitted, or the amount of time scheduled traffic requires
to access the medium, in units of 32 µs per second. In the case of EDCA admission control, this value is the
sum of the admitted medium times, and for HCCA it is the total TXOP time required per second (see T.2.2).
If the mean medium time is larger than 2 097 088 µs (65 534 × 32), the Mean subfield is set to 0xFFFE. The
Mean subfield is set to 0xFFFF to indicate that the mean medium time is unknown.
The Standard Deviation subfield indicates the standard deviation from the mean medium time, in units of
32 µs per second. If the standard deviation is larger than 8128 µs (254 × 32), the Standard Deviation subfield
is set to 0x3FFE. The Standard Deviation subfield is set to 0x3FFF to indicate that the standard deviation
from the mean is unknown.
The AC_VO Streams subfield indicates the number of TSs using explicit admission control for AC_VO in
the QoS traffic load report. Bidirectional streams are counted as two streams. If the number of admitted
AC_VO streams is larger than 14, the AC_VO Streams subfield is set to 0xE. The AC_VO Streams subfield
is set to 0xF to indicate that the number of TSs using explicit admission control for AC_VO is unknown.
The AC_VI Streams subfield indicates the number of TSs using explicit admission control for AC_VI in the
QoS traffic load report. Bidirectional streams are counted as two streams. If the number of TSs using explicit
admission control for AC_VO is larger than 14, the AC_VI Streams subfield is set to 0xE. The AC_VI
Streams subfield is set to 0xF to indicate that the number of TSs using explicit admission control for
AC_VI is unknown.
See 11.28.2 and Annex T.
9.4.2.124 HCCA TXOP Update Count element
The HCCA TXOP Update Count element is used by an AP to advertise its change in TXOP schedule. The
format is provided in Figure 9-498.
Element ID Length Update Count
Octets: 1 1 1
Figure 9-498—HCCA TXOP Update Count element format
The Element ID and Length fields are defined in 9.4.2.1.
The Update Count field is described in 11.28.3 and is used to indicate that a change has occurred in the
number of active HCCA or HEMM TSs.
1053
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.125 Higher Layer Stream ID element
The Higher Layer Stream ID element identifies a stream from a higher layer protocol. This element is used
to bind messages that are exchanged in order to complete a procedure, e.g., messages exchanged in an AP-
initiated TS setup procedure. See 11.4.4.3. The format is provided in Figure 9-499.
Element ID Length Protocol ID Organization Higher Layer
Identifier Stream ID
Octets: 1 1 1 0, 3, or 5 variable
Figure 9-499—Higher Layer Stream ID element format
The Element ID and Length fields are defined in 9.4.2.1.
The Protocol ID field identifies the higher layer protocol to which the stream belongs. The values defined
for the Protocol ID field are described in Table 9-228.
Table 9-228—Protocol ID definitions
Protocol ID Protocol Description
0 Reserved
1 IEEE 802.1Q SRP Protocol is IEEE 802.1Q SRP, and the corresponding
Stream ID is 8 octets long.
2–220 Reserved
221 Vendor Specific Corresponding Organization Identifier field is included in
the element.
222–255 Reserved
The Organization Identifier field is present when the Protocol ID field is equal to 221 and contains a
organization identifier assigned by IEEE. The identifier is specified in 9.4.1.32. The order of the
Organization Identifier field is described in 9.2.2.
The Higher Layer Stream ID field is an octet string and is defined by the higher layer protocol specified in
the Protocol ID field.
9.4.2.126 GCR Group Address element
The GCR Group Address element defines information about group addressed frames to be transmitted using
the GCR service. The format of the GCR Group Address element is shown in Figure 9-500.
Element ID Length GCR Group Address
Octets: 1 1 6
Figure 9-500—GCR Group Address element format
The Element ID and Length fields are defined in 9.4.2.1.
GCR Group Address field is the MAC address of the GCR group.
1054
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.127 DMG BSS Parameter Change element
The DMG BSS Parameter Change element is defined in Figure 9-501.
Element ID Length Change Type Bitmap TBTT Offset BI Duration
Octets: 1 1 1 4 2
Figure 9-501—DMG BSS Parameter Change element format
The Element ID and Length fields are defined in 9.4.2.1.
The Change Type Bitmap field indicates the type of the parameter change to the BSS. This field is defined in
Figure 9-502.
B0 B1 B2 B7
Move Size Reserved
Bits: 1 1 6
Figure 9-502—Change Type Bitmap field format
If the Move subfield is set to 1, it indicates a change in the TBTT of the BSS. The TBTT is not changed if
the Move field is set to 0. If the Size subfield is set to 1, it indicates a change in the beacon interval duration.
The beacon interval duration is not changed if the Size subfield is set to 0.
The TBTT Offset field contains a value expressed in microseconds. In any DMG BSS Parameter Change
element included in the DMG Beacon and/or Announce frame, the value of the TBTT Offset field represents
the lower order 4 octets of the AP or PCP TSF timer of the first changed TBTT.
The BI Duration field value indicates the beacon interval, expressed in TUs, following the indicated DMG
BSS parameter change. The BI Duration field is reserved if the Size bit of the Change Type Bitmap field is
set to 0.
9.4.2.128 DMG Capabilities element
9.4.2.128.1 General
The DMG Capabilities element contains a STA identifier and several fields that are used to advertise the
support of optional DMG capabilities of a DMG STA. The element is present in Association Request,
Association Response, Reassociation Request, Reassociation Response, Probe Request and Probe Response
frames and can be present in DMG Beacon, Information Request, and Information Response frames. The
DMG Capabilities element is formatted as defined in Figure 9-503.
Maximum Maximum
DMG STA DMG AP Or
Element STA PCP DMG STA Extended Number Of Number Of
Length AID Capability
ID Address Capability BeamTracking SC MCS Basic A-MSDU Short A-MSDU
Information TimeLimit Capabilities Subframes In Subframes In
Information
A-MSDU A-MSDU
Octets: 1 1 6 1 8 2 2 1 1 1
Figure 9-503—DMG Capabilities element format
The Element ID and Length fields are defined in 9.4.2.1.
1055
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The STA Address field contains the MAC address of the STA.
The AID field contains the AID assigned to the STA by the AP or PCP. The AID field is reserved in
Association Request, Reassociation Request and Probe Request frames and when used in an IBSS.
9.4.2.128.2 DMG STA Capability Information field
The DMG STA Capability Information field, shown in Figure 9-504, represents the transmitting STA
capabilities irrespective of the role of the STA.
B0 B1 B2 B3 B4 B5 B6 B7 B13
Higher Layer SPSH and Number of Total
Reverse Timer TPC Interference RX DMG Fast Link Number of
Direction Adaptation
Synchronization Mitigation Antennas Sectors
Bit: 1 1 1 1 2 1 7
B14 B19 B20 B21 B26 B27 B28 B51 B52
RXSS DMG A-MPDU BA with Supported DTP
Antenna Flow
Length Reciprocity Parameters Control MCS Set Supported
Bit: 6 1 6 1 24 1
B53 B54 B55 B56 B57 B59 B60 B61 B62 B63
Antenna Heartbeat RXSSTxR
A-PPDU Supports Grant Ack
Supported Heartbeat Other_AID Pattern Elapsed Supported ate Reserved
Reciprocity Indication Supported
Bit: 1 1 1 1 3 1 1 2
Figure 9-504—DMG STA Capability Information field format
The Reverse Direction subfield is set to 1 if the STA supports RD as defined in 10.28 and is set to 0
otherwise.
The Higher Layer Timer Synchronization subfield is set to 1 if the STA supports Higher Layer Timer
Synchronization as defined in 11.6 and is set to 0 otherwise.
The TPC subfield is set to 1 if the STA supports the TPC as defined in 11.8 and is set to 0 otherwise.
The SPSH (spatial sharing) and Interference Mitigation subfield is set to 1 if the STA is capable of
performing the function of SPSH and Interference Mitigation and if dot11RadioMeasurementActivated is
true and is set to 0 otherwise (see 11.32).
The Number of RX DMG Antennas subfield indicates the total number of receive DMG antennas of the
STA. The value of this subfield is in the range 1 to 4, with the value being equal to the bit representation plus
1.
The Fast Link Adaptation subfield is set to 1 to indicate that the STA supports the fast link adaptation
procedure described in 10.39.3. Otherwise, it is set to 0.
1056
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Total Number of Sectors subfield indicates the total number of transmit sectors the STA uses in a
transmit sector sweep combined over all DMG antennas, including any LBIFS required for DMG antenna
switching (see 10.38). The value of this subfield is in the range 1 to 128, with the value being equal to the bit
representation plus 1.
The value represented by the RXSS Length subfield specifies the total number of receive sectors combined
over all receive DMG antennas of the STA, including any LBIFS required for DMG antenna switching (see
10.38). The value represented by this subfield is in the range 2 to 128 and is given by (RXSS Length+1)×2.
The DMG Antenna Reciprocity subfield is set to 1 to indicate that the best transmit DMG antenna of the
STA is the same as the best receive DMG antenna of the STA and vice versa. Otherwise, this subfield is set
to 0.
The A-MPDU Parameters subfield is shown in Figure 9-505.
B0 B2 B3 B5
Maximum A-MPDU Minimum MPDU
Length Exponent Start Spacing
Bits: 3 3
Figure 9-505—A-MPDU parameters subfield format
The subfields of the A-MPDU Parameters subfield are defined in Table 9-229.
Table 9-229—Subfields of the A-MPDU Parameters subfield
Subfield Definition Encoding
Maximum A-MPDU Indicates the maximum length of This subfield is an integer in the range 0 to 5.
Length Exponent A-MPDU that the STA can The length defined by this subfield is equal to
receive. 2(13 + Maximum A-MPDU Length Exponent) – 1 octets.
Minimum MPDU Start Determines the minimum time Set to 0 for no restriction
Spacing between the start of adjacent Set to 1 for 16 ns
MPDUs within an A-MPDU that Set to 2 for 32 ns
the STA can receive, measured at Set to 3 for 64 ns
the PHY SAP. Set to 4 for 128 ns
Set to 5 for 256 ns
Set to 6 for 512 ns
Set to 7 for 1024 ns
The BA with Flow Control subfield is set to 1 if the STA supports BA with flow control as defined in 10.39
and is set to 0 otherwise.
The Supported MCS Set subfield indicates which MCSs a STA supports. An MCS is identified by an MCS
index, which is represented by an integer in the range 0 to 31 or by one of the values 9.1, 12.1, 12.2, 12.3,
12.4, 12.5 and 12.6. The interpretation of the MCS index (i.e., the mapping from MCS to data rate) is PHY
dependent. For the DMG PHY, see Clause 20. The structure of the Supported MCS Set subfield is defined in
Figure 9-506.
1057
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B4 B5 B9 B10 B14 B15 B19 B20 B21 B22 B23
Maximum Maximum Low-Power
Maximum SC OFDM Rx Maximum OFDM Tx SC Mode Code Rate Reserved
Rx MCS SC Tx MCS 13/16
MCS MCS Supported
Bits: 5 5 5 5 1 1 2
Figure 9-506—Supported MCS Set subfield format
The Maximum SC Rx MCS subfield contains the value of the maximum MCS index the STA supports for
reception of single-carrier frames. Values 0-3 of this subfield are reserved. Possible values for this subfield
are shown in Table 20-19. This subfield does not indicate support for MCSs 9.1, 12.1, 12.2, 12.3, 12.4, 12.5
and 12.6. Support for these MCSs is indicated using the Extended SC MCS Capabilities field; see
9.4.2.128.5.
The Maximum OFDM Rx MCS subfield contains the value of the maximum MCS index the STA supports
for reception of OFDM frames. If this subfield is set to 0, it indicates that the STA does not support
reception of OFDM frames. Values 1–17 of this subfield are reserved. Possible values for this subfield are
described in 20.5.3.1.2.
The Maximum SC Tx MCS subfield contains the value of the maximum MCS index the STA supports for
transmission of single-carrier frames. Values 0-3 of this subfield are reserved. Possible values for this
subfield are shown in Table 20-19. This subfield does not indicate support for MCSs 9.1, 12.1, 12.2, 12.3,
12.4, 12.5 and 12.6. Support for these MCSs is indicated using the Extended SC MCS Capabilities field; see
9.4.2.128.5.
The Maximum OFDM Tx MCS subfield contains the value of the maximum MCS index the STA supports
for transmission of OFDM frames. If this subfield is set to 0, it indicates that the STA does not support
transmission of OFDM frames. Values 1–17 of this subfield are reserved. Possible values for this subfield
are described 20.5.3.1.2.
The Low-Power SC Mode Supported subfield is set to 1 to indicate that the STA supports the DMG low-
power SC mode (20.7). Otherwise, it is set to 0. If the STA supports the low-power SC mode, it supports all
low-power SC mode MCSs indicated in Table 20-23.
The Code Rate 13/16 subfield specifies whether the STA supports rate 13/16. It is set to 1 to indicate that the
STA supports rate 13/16 and is set to 0 otherwise. If this subfield is 0, MCSs with 13/16 code rate specified
in Table 20-14 and Table 20-19 are not supported regardless of the value in Maximum SC/OFDM Tx/Rx
MCS subfields.
The DTP Supported subfield is set to 1 to indicate that the STA supports DTP as described in 10.40 and
20.5.3.2.4.6.3. Otherwise, it is set to 0.
The A-PPDU Supported subfield is set to 1 to indicate that the STA supports A-PPDU aggregation as
described in 10.15. Otherwise, it is set to 0.
The Supports Other_AID subfield is set to 1 to indicate that the STA sets its AWV configuration according
to the Other_AID subfield in the BRP Request field during the BRP procedure as described in 10.38.6.4.4
and 20.10.2.2.6, if the value of the Other_AID subfield is different from zero. Otherwise, this subfield is set
to 0.
The Heartbeat subfield is set to 1 to indicate that the STA expects to receive a frame from the AP or PCP
during the ATI (10.36.3) and expects to receive a frame with the DMG Control modulation from a source
DMG STA at the beginning of an SP (10.36.6.2) or TXOP (10.22.2). Otherwise, it is set to 0.
1058
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Antenna Pattern Reciprocity subfield is set to 1 to indicate that the transmit antenna pattern associated
with an AWV is the same as the receive antenna pattern for the same AWV. Otherwise, this subfield is set to
0.
The Heartbeat Elapsed Indication subfield is used to calculate the value of the Heartbeat Elapsed Time. The
Heartbeat Elapsed Time is computed according to the following equation:
0 F HE = 0
T HE = F HE
2 -
--------- F HE 0
4
where
THE is the Heartbeat Elapsed Time (in milliseconds)
FHE is the value of the Heartbeat Elapsed Indication subfield
The Grant Ack Supported subfield is set to 1 to indicate that the STA is capable of responding to a Grant
frame with a Grant Ack frame. Otherwise, this subfield is set to 0.
The RXSSTxRate Supported subfield is set to 1 to indicate that the STA can perform an RXSS with SSW
frames transmitted at MCS 1 of the DMG SC modulation class. Otherwise, it is set to 0.
9.4.2.128.3 DMG AP Or PCP Capability Information field
The DMG AP Or PCP Capability Information field, illustrated in Figure 9-507, represents the capabilities
when the transmitting STA performs in the role of AP or PCP and that are in addition to the capabilities in
the DMG STA Capability Information field.
B0 B1 B2 B3 B10 B11
TDDTI Pseudo-static PCP Handover MAX Associated STA Power Source
Allocations Number
Bit: 1 1 1 8 1
B12 B13 B14 B15
Decentralized AP or PCP Centralized AP or PCP
Clustering PCP Forwarding Clustering Reserved
Bit: 1 1 1 1
Figure 9-507—DMG AP Or PCP Capability Information field format
The TDDTI (time division data transfer interval) subfield is set to 1 if the STA, while operating as an AP or
PCP, is capable of providing channel access as defined in 10.36.6 and 11.4 and is set to 0 otherwise.
The Pseudo-static Allocations subfield is set to 1 if the STA, while operating as an AP or PCP, is capable of
providing pseudo-static allocations as defined in 10.36.6.4 and is set to 0 otherwise. The Pseudo-static
Allocations subfield is set to 1 only if the TDDTI subfield in the DMG AP Or PCP Capability Information
field is set to 1. The Pseudo-static Allocations subfield is reserved if the TDDTI subfield in the DMG AP Or
PCP Capability Information field is set to 0.
1059
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PCP Handover subfield is set to 1 if the STA, while operating as a PCP, is capable of performing a PCP
Handover as defined in 11.29.2 and is set to 0 if the STA does not support PCP Handover.
The MAX Associated STA Number subfield indicates the maximum number of STAs that the STA can
perform association with if operating as an AP or PCP. The value of this subfield includes the STAs, if any,
that are co-located with the AP or PCP.
The Power Source subfield is set to 0 if the STA is battery powered and is set to 1 otherwise.
The Decentralized AP or PCP Clustering subfield is set to 1 if the STA, when operating as an AP or PCP, is
capable of performing decentralized AP or PCP clustering and is set to 0 otherwise.
The PCP Forwarding subfield is set to 1 if the STA, while operating as a PCP, is capable of forwarding
frames it receives from a non-PCP STA and destined to another non-PCP STA in the PBSS. This subfield is
set to 0 otherwise.
The Centralized AP or PCP Clustering subfield is set to 1 if the STA, when operating as an AP or PCP, is
capable of performing centralized AP or PCP clustering and is set to 0 otherwise. An AP or PCP that is
incapable of performing centralized AP or PCP clustering is subject to requirements as described in
10.37.2.2.
9.4.2.128.4 DMG STA Beam Tracking Time Limit field
The BeamTrackingTimeLimit subfield contains the value of dot11BeamTrackingTimeLimit. The resulting
value of dot11BeamTrackingTimeLimit of beam link established between peer STA’s is negotiated
following rules presented in Table 9-230.
Table 9-230—Beam Tracking Time Limit negotiation
dot11BeamTracking
TimeLimit
DMG STA DMG STA
(STA-A) vs.
BeamTrackingTimeLimit BeamTrackingTimeLimit Result
dot11BeamTracking
(STA-A) (STA-B)
TimeLimit
(STA-B)
0 0 NA Beam tracking is not supported
>0 0 NA
0 >0 NA
>0 and < 65 535 >0 and < 65 535 >, = dot11BeamTrackingTimeLimit
(STA-A)
>0 and < 65 535 >0 and < 65 535 < dot11BeamTrackingTimeLimit
(STA-B)
65 535 >0 and < 65 535 NA dot11BeamTrackingTimeLimit
(STA-B)
>0 and < 65 535 65 535 NA dot11BeamTrackingTimeLimit
(STA-A)
65 535 65 535 NA Default
dot11BeamTrackingTimeLimit
value
1060
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—In Table 9-230 STA-A and STA-B refer to any of the STAs performing the Beam Tracking Time Limit
negotiation procedure in no particular order.
9.4.2.128.5 Extended SC MCS Capabilities field
The Extended SC MCS Capabilities field (see Figure 9-508) advertises the support of the STA for MCSs
9.1, 12.1, 12.2, 12.3, 12.4, 12.5 and 12.6.
B0 B2 B3 B4 B6 B7
Maximum Code Rate 7/8 Maximum Code Rate 7/8
Extended SC Tx Tx Extended SC Rx Rx
MCS MCS
Bits: 3 1 3 1
Figure 9-508—Extended SC MCS Capabilities field
The Maximum Extended SC Tx MCS subfield indicates the maximum transmit extended SC MCS
supported by the STA. The values in the subfield are ordered as shown in Table 9-231.
Table 9-231—Mapping of Extended SC MCS to Maximum Supported Rx/Tx MCS
subfield values
Value in Maximum
Extended MCS name Extended SC Rx/Tx
MCS field
None 0
MCS 9.1 1
MCS 12.1 2
MCS 12.2 3
MCS 12.3 4
MCS 12.4 5
MCS 12.5 6
MCS 12.6 7
A STA that indicates support for transmission of an extended SC MCS by setting the value in the Maximum
Extended SC Tx MCS subfield to k supports the subset of MCSs {9.1, 12.1, 12.2, 12.3, 12.4, 12.5 12.6} that
have a data rate lower than or equal to the data rate of the MCS indicated by k. A STA that indicates support
for MCSs with a data rate higher than the data rate of MCS 9.1 in the Maximum Extended SC Tx MCS
subfield shall set the value of the Maximum SC Tx MCS subfield of the Supported MCS Set subfield to 12.
A STA that indicates support for transmission of an extended SC MCS by setting the value in the Maximum
Extended SC Tx MCS subfield to k supports all extended SC MCSs with values lower than or equal to k.
The Maximum Extended SC Rx MCS subfield indicates the maximum receive extended SC MCS supported
by the STA. The values in the subfield are ordered as shown in Table 9-231.
A STA indicates support for transmission of code rate 7/8 by setting the Code Rate 7/8 Tx subfield to 1. If a
STA indicates that it does not support code rate 7/8, then the STA does not support MCS 9.1 or 12.2 even if
the value in the Maximum Extended SC Tx MCS subfield is greater than 1 or 3 respectively. A STA that
1061
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
indicates support for MCSs with a data rate higher than the data rate of MCS 9.1 in the Maximum Extended
SC Rx MCS subfield shall set the value of the Maximum SC Rx MCS subfield of the Supported MCS Set
subfield to 12.
A STA that indicates support for reception of an extended SC MCS by setting the value in the Maximum
Extended SC Rx MCS subfield to k supports the subset of MCSs {9.1, 12.1, 12.2, 12.3, 12.4, 12.5 12.6} that
have a data rate lower than or equal to the data rate of the MCS indicated by k.
A STA indicates support for reception of code rate 7/8 by setting the Code Rate 7/8 Rx subfield to 1. If a
STA indicates that it does not support code rate 7/8, the STA does not support MCS 9.1 or 12.2 even if the
value in the Maximum Extended SC Rx MCS field is greater than 1 or 3 respectively.
9.4.2.128.6 Maximum number of A-MSDU subframes in an A-MSDU
The Maximum Number Of Basic A-MSDU Subframes In A-MSDU subfield is defined in Table 9-232 and
indicates the maximum number of Basic A-MSDU subframes in an A-MSDU that the DMG STA is able to
receive from another DMG STA.
Table 9-232—Maximum Number Of Basic A-MSDU Subframes In A-MSDU subfield
Value Meaning
0 No limit on the maximum number of Basic A-MSDU subframes supported
1 A maximum of 4 Basic A-MSDU subframes are supported
2 A maximum of 8 Basic A-MSDU subframes are supported
3 A maximum of 16 Basic A-MSDU subframes are supported
4 A maximum of 32 Basic A-MSDU subframes are supported
5 A maximum of 64 Basic A-MSDU subframes are supported
6 A maximum of 128 Basic A-MSDU subframes are supported
7 A maximum of 256 Basic A-MSDU subframes are supported
8–255 Reserved
The Maximum Number Of Short A-MSDU Subframes In A-MSDU subfield is defined in Table 9-233 and
indicates the maximum number of Short A-MSDU subfields in an A-MSDU that the DMG STA is able to
receive from another DMG STA.
Table 9-233—Maximum Number Of Short A-MSDU Subframes
In A-MSDU subfield
Value Meaning
0 No limit on the maximum number of Short A-MSDU subframes supported
1 A maximum of 32 Short A-MSDU subframes are supported
2 A maximum of 64 Short A-MSDU subframes are supported
3 A maximum of 128 Short A-MSDU subframes are supported
1062
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-233—Maximum Number Of Short A-MSDU Subframes
In A-MSDU subfield (continued)
Value Meaning
4 A maximum of 256 Short A-MSDU subframes are supported
5 A maximum of 512 Short A-MSDU subframes are supported
6 A maximum of 1024 Short A-MSDU subframes are supported
7–255 Reserved
9.4.2.129 DMG Operation element
The operational parameters of a BSS provided by the AP or PCP are determined by the DMG Operation
element defined in Figure 9-509.
Element ID Length DMG Operation Information DMG BSS Parameter Configuration
Octets: 1 1 2 8
Figure 9-509—DMG Operation element format
The Element ID and Length fields are defined in 9.4.2.1.
The DMG Operation Information field is shown in Figure 9-510.
B0 B1 B2 B3 B15
TDDTI Pseudo-static allocations PCP Handover Reserved
Bits: 1 1 1 13
Figure 9-510—DMG Operation Information field format
The TDDTI subfield is set to 1 if the AP or PCP provides time division channel access as defined in 10.36.6
and is set to 0 otherwise.
The Pseudo-static allocations subfield is set to 1 if the AP or PCP provides pseudo-static allocations as
defined in 10.36.6.4 and is set to 0 otherwise. The Pseudo-static allocations subfield is set to 1 only if the
TDDTI subfield in the DMG Operation Information field is 1. The Pseudo-static allocations subfield is
reserved if the TDDTI subfield in the DMG Operation Information field is 0.
The PCP Handover subfield is set to 1 if the PCP provides PCP Handover as defined in 11.29.2 and is set to
0 if the PCP does not provide PCP Handover.
1063
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DMG BSS Parameter Configuration field is defined in Figure 9-511.
PSRequestSuspensionInterval MinBHIDuration BroadcastSTAInfoDuration AssocRespConfirmTime
Octets: 1 2 1 1
MinPPDuration SPIdleTimeout MaxLostBeacons
Octets: 1 1 1
Figure 9-511—DMG BSS Parameter Configuration field format
The PSRequestSuspensionInterval subfield indicates the power save suspension interval and is specified in
number of beacon intervals.
The MinBHIDuration subfield indicates the minimum duration of the BHI, which can include the BTI, A-
BFT, and ATI and is specified in microseconds.
The BroadcastSTAInfoDuration subfield indicates the amount of time that the AP or PCP expects to take to
transmit information about associated STAs and is specified in number of beacon intervals.
The AssocRespConfirmTime subfield indicates the amount of time that the AP or PCP expects to take to
respond to association requests and is specified in units of 50 milliseconds. A non-PCP and non-AP STA
that receives a DMG Operation element can use the value of this field to set
dot11AssociationResponseTimeOut.
The MinPPDuration subfield indicates the minimum duration of the PP and GP as part of the dynamic
allocation of service period mechanism and is specified in microseconds.
The SPIdleTimeout subfield indicates time during which a STA expects to receive a frame from its peer
STA and is specified in microseconds.
The MaxLostBeacons subfield contains the value of dot11MaxLostBeacons.
9.4.2.130 DMG Beam Refinement element
The DMG Beam Refinement element is defined as shown in Figure 9-512.
B0 B7 B8 B15 B16 B17 B18 B19 B20
Element ID Length Initiator TX-train- RX-train- TX-TRN-OK TXSS-FBCK-REQ
response response
Bits: 8 8 1 1 1 1 1
B21 B26 B27 B28 B29 B33 B34 B51 B52 B53 B54 B55
BS-FBCK
BS-FBCK Antenna FBCK-REQ FBCK-TYPE MID Capability Reserved
Extension Request
ID
Bits: 6 2 5 18 1 1 2
Figure 9-512—DMG Beam Refinement element format
1064
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
A value of 1 in the Initiator field indicates that the sender is the beam refinement initiator. Otherwise, this
field is set to 0.
A value of 1 in the TX-train-response field indicates that this packet is the response to a TX training request.
Otherwise, this field is set to 0.
A value of 1 in the RX-train-response field indicates that the packet serves as an acknowledgment for a RX
training request. Otherwise, this field is set to 0.
A value of 1 in the TX-TRN-OK field confirms a previous training request received by a STA. Otherwise,
this field is set to 0.
A value of 1 in the TXSS-FBCK-REQ field indicates a request for transmit sector sweep feedback.
The BS-FBCK field indicates the index of the TRN-T field that was received with the best quality in the last
received BRP-TX PPDU, where the first TRN-T field in the PPDU is defined as having an index equal to 1.
If the last received PPDU was not a BRP-TX PPDU, this field is set to 0. The determination of best quality
is implementation dependent.
The BS-FBCK Antenna ID field specifies the antenna ID corresponding to the sector indicated by the BF-
FBCK field.
The FBCK-REQ field is defined in Figure 9-513 and is described in Table 9-234.
B29 B30 B31 B32 B33
Channel Measurement Sector ID Order
SNR Requested Requested Number of Taps Requested Requested
Bits: 1 1 2 1
Figure 9-513—FBCK-REQ field format
Table 9-234—FBCK-REQ field description
Subfield Meaning
SNR Requested If set to 1, the SNR subfield is requested as part of the channel measurement
feedback. Otherwise, set to 0.
Channel Measurement If set to 1, the Channel Measurement subfield is requested as part of the channel
Requested measurement feedback. Otherwise, set to 0.
Number of Taps Requested Number of taps in each channel measurement:
0x0 – 1 tap
0x1 – 5 taps
0x2 – 15 taps
0x3 – 63 taps
Sector ID Order Requested If set to 1, the Sector ID Order subfield is requested as part of the channel
measurement feedback. Otherwise, set to 0.
1065
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The FBCK-TYPE field is defined in Figure 9-514 and is described in Table 9-235. When both Nmeas and
Nbeam in this field are equal to 0, the Channel Measurement Feedback element is not present.
B34 B35 B36 B37 B38 B39 B45 B46 B47 B48 B49 B51
SNR Channel Tap Delay Number of Number of Sector ID Link Antenna Number
Measurement Taps Order
Present Present Present Present Measurements Present Type Type of Beams
Bits: 1 1 1 2 7 1 1 1 3
Figure 9-514—FBCK-TYPE field format
Table 9-235—FBCK-TYPE field description
Subfield Meaning
SNR Present Set to 1 to indicate that the SNR subfield is present as part of the channel measurement
feedback. Set to 0 otherwise.
Channel Measurement Set to 1 to indicate that the Channel Measurement subfield is present as part of the
Present channel measurement feedback. Set to 0 otherwise.
Tap Delay Present Set to 1 to indicate that the Tap Delay subfield is present as part of the channel
measurement feedback. Set to 0 otherwise.
Number of Taps Number of taps in each channel measurement:
Present 0x0 – 1 tap
0x1 – 5 taps
0x2 – 15 taps
0x3 – 63 taps
Number of Number of measurements in the SNR subfield and the Channel Measurement subfield.
Measurements It is equal to the number of TRN-T subfields in the BRP-TX packet on which the
measurement is based, or the number of received sectors if TXSS result is reported by
setting the TXSS-FBCK-REQ subfield to 1.
Sector ID Order Set to 1 to indicate that the Sector ID Order subfield is present as part of the channel
Present measurement feedback. Set to 0 otherwise.
Link Type Set to 0 for the initiator link and to 1 for the responder link
Antenna Type Set to 0 for the transmitter antenna and to 1 for the receiver antenna
Number of Beams Indicates the number of beams in the Sector ID Order subfield for the MIDC subphase
A value of 1 in the MID Extension field indicates the intention to continue transmitting BRP-RX packets
during the MID subphases. Otherwise, this field is set to 0.
A value of 1 in the Capability Request field indicates that the transmitter of the frame requests the intended
receiver to respond with a BRP frame that includes the BRP Request field. Otherwise, this field is set to 0.
9.4.2.131 DMG Wakeup Schedule element
The DMG Wakeup Schedule element is defined in Figure 9-515.
1066
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Element ID Length BI Start Time Sleep Cycle Number of Awake BIs
Octets: 1 1 4 2 2
Figure 9-515—DMG Wakeup Schedule element format
The Element ID and Length fields are defined in 9.4.2.1.
The DMG Wakeup Schedule element is used to communicate the wakeup schedule (WS) of DMG STAs.
The BI Start Time field indicates the lower order 4 octets of the TSF timer at the start of the first awake BI in
the WS defined by the DMG Wakeup Schedule element. A transmitted BI Start Time field points to a TBTT
not more than 231 µs minus aDMGDWSValidPeriod before, and not more than (231 – 1) µs after the TBTT
of the beacon interval during which the BI Start Time field is transmitted.
NOTE—The delay between the moment a STA receives a DMG Wakeup Schedule element over the air and the moment
the STA interprets the value of the BI Start Time field in the element can be large, to the extent that the beacon interval
during which the BI Start Time filed is interpreted is different from the beacon interval during which the DMG Wakeup
Schedule element is received. Excluding an interval from the range of BI Start Time values at transmission enables the
receiving STA to be able to correctly interpret any received value for the BI Start Time field of the DMG Wakeup
Schedule element belonging to a STA in PS mode without having to remember the beacon interval during which the
DMG Wakeup Schedule element was received, as long as the beginning of the beacon interval at the time of
interpretation has not advanced more than aDMGDWSValidPeriod relative to the beginning of the beacon interval at the
time of reception.
The Sleep Cycle field indicates the sleep cycle duration in beacon intervals, i.e., the sum of awake BIs and
doze BIs that make up the sleep cycle.
The Number of Awake BIs field indicates the number of awake BIs at the beginning of each sleep cycle. A
value of 0 for this field indicates that all BIs in the WS are doze BIs.
9.4.2.132 Extended Schedule element
The Extended Schedule element is defined in Figure 9-516. Because the length parameter supports only 255
octets of information in an element, the AP or PCP can split the Allocation fields into more than one
Extended Schedule element entry in the same DMG Beacon or Announce frame. Despite this splitting, the
set of Extended Schedule element entries conveyed within a DMG Beacon and Announce frame is
considered to be a single schedule for the beacon interval, and in this standard referred to simply as
Extended Schedule element unless otherwise noted. The Allocation fields are ordered by increasing
allocation start time with allocations beginning at the same time arbitrarily ordered.
Element ID Length Allocation 1 Allocation 2 … Allocation n
Octets: 1 1 15 15 … 15
Figure 9-516—Extended Schedule element format
The Element ID and Length fields are defined in 9.4.2.1.
The Allocation field is formatted as illustrated in Figure 9-517.
1067
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Allocation Allocation
Allocation BF Source Destination Allocation Block Number Block
Control Control AID AID Start of Blocks
Duration Period
Octets: 2 2 1 1 4 2 1 2
Figure 9-517—Allocation field format
The Allocation Control subfield is defined in Figure 9-518.
B0 B3 B4 B6 B7 B8 B9 B10 B11 B12 B15
Allocation Allocation Pseudo- PCP LP SC
ID Type static Truncatable Extendable Active Used Reserved
Bits: 4 3 1 1 1 1 1 4
Figure 9-518—Allocation Control subfield format
The Allocation ID subfield, when set to a nonzero value, identifies an airtime allocation from Source AID to
Destination AID. Except for CBAP allocations with broadcast Source AID and broadcast Destination AID,
the tuple (Source AID, Destination AID, Allocation ID) uniquely identifies the allocation. For CBAP
allocations with broadcast Source AID and broadcast Destination AID, the Allocation ID subfield is set to
zero.
The AllocationType subfield defines the channel access mechanism during the allocation, with possible
values listed in Table 9-236.
Table 9-236—AllocationType subfield values
Bit 4 Bit 5 Bit 6 Meaning
0 0 0 SP allocation
1 0 0 CBAP allocation
All other combinations Reserved
The Pseudo-static subfield is set to 1 to indicate that this allocation is pseudo-static (10.36.6.4) and set to 0
otherwise.
For an SP allocation, the Truncatable subfield is set to 1 to indicate that the source DMG STA and
destination DMG STA can request SP truncation and set to 0 otherwise. For a CBAP allocation, the
Truncatable subfield is reserved.
For an SP allocation, the Extendable subfield is set to 1 to indicate that the source DMG STA and
destination DMG STA can request SP extension and set to 0 otherwise. For a CBAP allocation, the
Extendable subfield is reserved.
For a PCP in active mode (see 11.2.7), or when applied to a CBAP or SP in a PCP awake BI, a value of 1 for
the PCP Active subfield indicates that the PCP is available to transmit or receive during the CBAP or SP,
and a value of 0 indicates the PCP unavailability to transmit or receive. The PCP Active subfield is set to 1
at least in the following cases:
1068
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The PCP transmitting the subfield is the source or destination of the CBAP or SP
— At least one of the Truncatable or Extendable subfields is set to 1
— The subfield is transmitted by an AP
The value of the PCP Active subfield is ignored when it applies to a CBAP or SP that resides in a PCP doze
BI.
The BF Control subfield is defined in 9.5.5.
The Source AID subfield is set to the AID of the STA that initiates channel access during the SP or CBAP
allocation or, in the case of a CBAP allocation, can also be set to the broadcast AID if all STAs are allowed
to transmit during the CBAP allocation.
The Destination AID subfield is set to the AID of the STA that the source STA targets during the allocation,
or to the broadcast AID if the source STA targets more than one STA during the allocation. If both Source
AID and Destination AID subfields for an SP allocation are set to the broadcast AID, then during the SP a
non-AP and non-PCP STA does not transmit unless it receives a Poll or Grant frame from the AP or PCP.
The Allocation Start subfield contains the lower 4 octets of the TSF at the time the SP or CBAP starts. The
Allocation Start subfield can be specified at a future beacon interval when the pseudo-static subfield is set
to 1.
The Allocation Block Duration subfield indicates the duration, in microseconds, of a time block for which
the SP or CBAP allocation is made and cannot cross beacon interval boundaries. Possible values range from
1 to 32 767 for an SP allocation and 1 to 65 535 for a CBAP allocation.
The Number of Blocks subfield contains the number of time blocks making up the allocation.
The Allocation Block Period subfield contains the time, in microseconds, between the start of two
consecutive time blocks belonging to the same allocation. The Allocation Block Period subfield is reserved
when the Number of Blocks subfield is set to 1.
The LP SC Used subfield is set to 1 to indicate that the low-power SC mode described in 20.7 is used in this
SP. Otherwise, it is set to 0.
9.4.2.133 STA Availability element
The STA Availability element is used by a non-AP and non-PCP STA to inform an AP or PCP about the
STA availability during the subsequent CBAPs (10.36.5) and to indicate participation in the dynamic
allocation of service periods (10.36.7). The AP or PCP uses the STA Availability element to inform the non-
AP and non-PCP STAs of other STAs availability during subsequent CBAPs and participation of other
STAs in the Dynamic allocation of service periods.
The format of the STA Availability element is defined in Figure 9-519.
Element ID Length STA Info 1 … STA Info n
Octets: 1 1 2 … 2
Figure 9-519—STA availability element format
The Element ID and Length fields are defined in 9.4.2.1.
1069
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The format of the STA Info field is shown in Figure 9-520.
B0 B7 B8 B9 B10 B15
AID CBAP PP Available Reserved
Bits: 8 1 1 6
Figure 9-520—STA Info field format
The AID subfield contains the AID of the STA for which availability is indicated.
The CBAP subfield is set to 1 to indicate that the STA is available to receive transmissions during CBAPs
and set to 0 otherwise.
The PP Available subfield is set to 1 to indicate that the STA is available during PPs (10.36.7) and is set to 0
otherwise.
9.4.2.134 DMG TSPEC element
The DMG TSPEC element is present in the ADDTS Request frame sent by a non-AP and non-PCP DMG
STA and contains the set of parameters needed to create or modify an airtime allocation. The DMG TSPEC
element is also present in the ADDTS Response frame sent by a DMG AP or PCP and reflects the
parameters, possibly modified, by which the allocation was created. The format of the DMG TSPEC
element is shown in Figure 9-521.
Element ID Length DMG Allocation Info BF Control Allocation Period
Octets: 1 1 4 2 2
Minimum Maximum Minimum Number of Traffic
Scheduling
Allocation Allocation Duration Constraints Constraint Set
Octets: 2 2 2 1 Variable
Figure 9-521—DMG TSPEC element format
The Element ID and Length fields are defined in 9.4.2.1.
The DMG Allocation Info field is formatted as shown in Figure 9-522.
The Allocation ID subfield identifies an allocation if set to a nonzero value and is used as follows:
— The STA that transmits an ADDTS Request frame containing the DMG TSPEC element sets the
Allocation ID subfield to a nonzero value to create a new allocation or modify an existing allocation.
— The STA that transmits an ADDTS Response frame containing the DMG TSPEC element sets the
Allocation ID subfield to a nonzero value to identify a created or modified allocation or sets it to 0 if
creating or modifying the allocation failed.
1070
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B3 B4 B6 B7 B8 B9
Allocation Pseudo-
Allocation ID AllocationType Truncatable
Format static
Bits: 4 3 1 1 1
B10 B11 B12 B14 B15 B22 B23 B30 B31
Extendable LP SC UP Destination AID Source AID Reserved
Used
Bits: 1 1 3 8 8 1
Figure 9-522—DMG Allocation Info field format
The AllocationType subfield defines the channel access mechanism used during the allocation, with values
listed in Table 9-236.
The Allocation Format field values are listed in Table 9-237.
Table 9-237—Allocation Format subfield values
Allocation Format subfield
Description
value
1 Isochronous allocation format
0 Asynchronous allocation format
The Pseudo-static subfield is set to 1 for a pseudo-static allocation and set to 0 otherwise.
For an SP allocation, the Truncatable subfield is set to 1 if the STA expects to truncate the SP, as described
in 10.36.8. If the STA does not expect to truncate the SP, the Truncatable subfield is set to 0. The subfield is
reserved for CBAP allocations.
For an SP allocation, the Extendable subfield is set to 1 if the STA expects to extend the SP, as described in
10.36.9. If the STA does not expect to extend the SP, the Extendable subfield is set to 0. The subfield is
reserved for CBAP allocations.
The LP SC Used subfield is defined in 9.4.2.132.
The UP subfield indicates the lowest priority UP to be used for possible transport of MSDUs belonging to
TCs with the same source and destination of the allocation.
The Destination AID subfield contains the AID of a STA that the requesting STA targets during the
allocation.
The Source AID subfield contains the AID of the STA that initiates channel access during the allocation.
The BF Control subfield is defined in 9.5.5.
1071
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Allocation Period is specified as a fraction or multiple of the beacon interval (BI) as defined in
Table 9-238.
Table 9-238—Allocation Period field values
B0–B14 B15 Meaning
0 0 Reserved
0 1 Not periodic or periodicity unknown
1–32 767 0 The allocation period is a multiple of the BI, i.e., allocation period = n x BI
where n is the value represented by B0–B14
1–32 767 1 The allocation period is a fraction of the BI, i.e., allocation period = BI/n where
n is the value represented by B0–B14.
For isochronous allocation format requests the Allocation Period, Minimum Allocation and Maximum
Allocation fields are set as follows:
— The Allocation Period field indicates the period over which the allocation repeats.
— The Minimum Allocation field is set to the minimum acceptable allocation in microseconds in each
allocation period.
— The Maximum Allocation field is set to the requested allocation in microseconds in each allocation
period.
For asynchronous allocation format requests the Maximum Allocation field is reserved, and the Allocation
Period and Minimum Allocation fields are set as follows:
— The Allocation Period field indicates the period over which the minimum allocation applies. The
Allocation Period is an integer multiple of the beacon interval.
— The Minimum Allocation field specifies the minimum allocation in microseconds that the STA
expects within the allocation period.
The Minimum Duration field specifies the minimum acceptable duration in microseconds. Possible values
range from 1 to 32 767 for an SP allocation and 1 to 65 535 for a CBAP allocation. A value of 0 indicates no
minimum specified.
The Number of Constraints field indicates the number of Constraint subfields contained in the element. The
value of this field ranges from 0 to 15. Other values are reserved.
The Traffic Scheduling Constraint Set field contains one or more Constraint subfields (see Figure 9-523).
One or more Constraint subfields
Octets: Variable
Figure 9-523—Traffic Scheduling Constraint Set field format
The Constraint subfield is defined as illustrated in Figure 9-524.
1072
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TSCONST Start Time TSCONST Duration TSCONST Period Interferer MAC address
Octets: 4 2 2 6
Figure 9-524—Constraint subfield format
The TSCONST Start Time subfield contains the lower 4 octets of the TSF at the time the scheduling
constraint starts.
The TSCONST Duration subfield indicates the time, in microseconds, for which the scheduling constraint is
specified.
The TSCONST Period subfield is specified as a fraction or multiple of the beacon interval (BI) as defined in
Table 9-239. This subfield is used to indicate a periodic scheduling constraint by specifying the temporal
gap between two consecutive scheduling constraints.
Table 9-239—TSCONST Period values
B0–B14 B15 Meaning
0 0 Reserved
0 1 Not periodic or periodicity unknown
1–32 767 0 The TSCONST period is a multiple of the BI, i.e., TSCONST period = n x BI
where n is the value represented by B0–B14.
1–32 767 1 The TSCONST period is a fraction of the BI, i.e., TSCONST period = BI/n
where n is the value represented by B0–B14.
The Interferer MAC Address subfield is set to the value of the TA field within a frame received during the
interval of time indicated by this Constraint subfield. If the value is unknown, the Interferer MAC Address
subfield is set to the broadcast MAC address.
9.4.2.135 Next DMG ATI element
The Next DMG ATI element indicates the earliest start time for the next ATI in a subsequent beacon
interval. See Figure 9-525.
Element ID Length Start Time ATI Duration
Octets: 1 1 4 2
Figure 9-525—Next DMG ATI element format
The Element ID and Length fields are defined in 9.4.2.1.
The Start Time field contains the low-order 4 octets of the TSF for the earliest time at which the next ATI in
a subsequent beacon interval starts.
The ATI Duration field contains the duration, in microseconds, of the next ATI in a subsequent beacon
interval.
1073
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.136 Channel Measurement Feedback element
The Channel Measurement Feedback element is used to carry the channel measurement feedback data that
the STA has measured on the TRN-T fields of the BRP packet that contained the Channel Measurement
request, to provide a list of sectors identified during a sector sweep, or during beam combination (10.38.6.3).
The format and size of the Channel Measurement Feedback element are defined by the parameter values
specified in the accompanying DMG Beam Refinement element.
The Channel Measurement Feedback element, as shown in Table 9-240, is composed of 4 subfields: the
SNR subfield, the Channel Measurement subfield, the Tap Delay subfield, and the Sector ID Order subfield.
Table 9-240—Channel Measurement Feedback element format
Field Size Meaning
Element ID 8 bits
Length 8 bits
SNR SNR 1 8 bits SNR as measured in the first TRN-T field or at
the first sector from which SSW frame is
received.
SNR 2 8 bits SNR as measured in the second TRN-T field or at
the second sector from which SSW frame is
received.
SNR N meas 8 bits SNR as measured in the Nmeas TRN-T field or at
sector Nmeas from which SSW frame is received.
Channel Channel Measurement 1 Ntaps×16 bits Channel measurement for the first TRN-T field
Measurement
Channel Measurement 2 Ntaps×16 bits Channel measurement for the second TRN-T
field
Channel Measurement Ntaps×16 bits Channel measurement for the Nmeas TRN-T field
Nmeas
Tap Delay Relative Delay Tap #1 8 bits The delay of Tap #1 in units of Tc relative to the
path with the shortest delay detected.
Relative Delay Tap #2 8 bits The delay of Tap #2 in units of Tc relative to the
path with the shortest delay detected.
Relative Delay Tap 8 bits The delay of Tap #Ntaps in units of Tc relative to
#Ntaps the path with the shortest delay detected.
1074
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-240—Channel Measurement Feedback element format (continued)
Field Size Meaning
Sector ID Order Sector ID1 6 bits Sector ID for SNR1 being obtained, or sector ID
of the first detected beam.
Antenna ID1 2 bits Antenna ID corresponding to sector ID1.
Sector ID2 6 bits Sector ID for SNR2 being obtained, or sector ID
of the second detected beam.
Antenna ID2 2 bits Antenna ID corresponding to sector ID2.
Sector IDNmeas 6 bits Sector ID for SNRNmeas being obtained, or sector
or sector IDNbeam ID of the detected beam Nbeam.
Antenna IDNmeas 2 bits Antenna ID corresponding to sector IDNmeas or
or Antenna IDNbeam sector IDNbeam
The Element ID and Length fields are defined in 9.4.2.1.
The number of channel/SNR measurements reported, Nmeas, is equal to the number of TRN-T subfields that
were appended to the packet on which the measurements were performed. If the measurement reports the
result of an SLS or of an MID, it is equal to the number of frames received during the sector sweep, or the
number of packets used during the MID subphase.
The SNR subfield levels are unsigned integers referenced to a level of –8 dB. Each step is 0.25 dB. SNR
values less than or equal to –8 dB are represented as 0. SNR values greater than or equal to 55.75 dB are
represented as 0xFF.
The format of each channel measurement is specified in Table 9-241.
Table 9-241—Channel measurement
Field Size Meaning
Relative I Component Tap #1 8 bits The in-phase component of impulse response for Tap #1,
relative to the amplitude of the strongest tap measured.
Relative Q Component Tap #1 8 bits The quadrature component of impulse response for Tap #1,
relative to the amplitude of the strongest tap measured.
Relative I Component Tap #2 8 bits The in-phase component of impulse response for Tap #2,
relative to the amplitude of the strongest tap measured.
Relative Q Component Tap #2 8 bits The quadrature component of impulse response for Tap #2,
relative to the amplitude of the strongest tap measured.
Relative I Component Tap #Ntaps 8 bits The in-phase component of impulse response for Tap #Ntaps,
relative to the amplitude of the strongest tap measured.
Relative Q Component Tap #Ntaps 8 bits The quadrature component of impulse response for Tap
#Ntaps, relative to the amplitude of the strongest tap measured.
1075
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Each channel measurement contains Ntaps channel impulse taps. The channel impulse response reported for
all Nmeas measurements correspond to a common set of relative tap delays. If the Tap Delay subfield is not
present, then the Ntaps channel taps is interpreted as consecutive time samples, separated by Tc. The delay
values in the Tap Delay subfield, when present, correspond to the strongest taps and are unsigned integers,
in increments of Tc, starting from 0. Each channel tap is reported as an in-phase and quadrature component
pair, with each component value represented as a 2s complement number between –128 and 127. Unless all
in-phase and quadrature component values are reported as zero, they are scaled such that the two most
significant bits for at least one of the component values equal 01 or 10 (binary).
The Sector ID Order subfield indicates the TX sector IDs corresponding to the SNRs in the SNR subfield
when the SNR Present subfield is set to 1 and Sector ID Order Present subfield is set to 1, in response to a
BRP packet with the SNR Requested subfield set to 1. The Sector ID Order subfield indicates the TX sector
IDs ranked in the decreasing order of link quality, determined in an implementation dependent manner,
when the SNR Present subfield is set to 0 and the Sector ID Order Present subfield is set to 1 in response to
setting the SNR Requested subfield to 0 and the Sector ID Order Requested subfield to 1. The FBCK-REQ
field and the FBCK TYPE field in the DMG Beam Refinement element are used by the transmitter and
receiver to, respectively, request for and indicate the sector IDs and their order.
9.4.2.137 Awake Window element
The Awake Window element is defined as shown in Figure 9-526.
Awake Window
Element ID Length Duration
Octets: 1 1 2
Figure 9-526—Awake Window element format
The Element ID and Length fields are defined in 9.4.2.1.
The Awake Window Duration field is 2 octets in length and contains the duration of the Awake Window in
microseconds.
9.4.2.138 Multi-band element
The Multi-band element indicates that the STA transmitting this element (the transmitting STA) is within a
multi-band device capable of operating in a frequency band or operating class or channel other than the one
in which this element is transmitted and that the transmitting STA is able to accomplish a session transfer
from the current channel to a channel using another STA in the same device, in the other or same band. The
format of the Multi-band element is shown in Figure 9-527.
Element Multi-band Operating Channel Beacon
ID Length Control Band ID Class Number BSSID Interval
Octets: 1 1 1 1 1 1 6 2
Multi-band STA MAC Pairwise Cipher Pairwise Cipher
TSF
Offset Connection FSTSessionTimeout Address Suite Count Suite List
Capability (optional) (optional) (optional)
Octets: 8 1 1 0 or 6 0 or 2 4×m
Figure 9-527—Multi-band element format
1076
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Multi-band Control field is shown in Figure 9-528.
B0 B2 B3 B4 B5 B7
STA Role STA MAC Address Pairwise Cipher Suite Present Reserved
Present
Bits: 3 1 1 3
Figure 9-528—Multi-band Control field format
The STA Role subfield specifies the role the transmitting STA plays on the channel of the operating class
indicated in this element. The possible values of the STA Role subfield are indicated in Table 9-242. If the
STA Role subfield is set to IBSS STA, the BSSID subfield contains the BSSID of the IBSS.
Table 9-242—STA Role subfield values
STA role Value
AP 0
TDLS STA 1
IBSS STA 2
PCP 3
Non-PCP and Non-AP STA 4
Reserved 5–7
NOTE—A STA can perform in more than one role in a channel, and the STA Role subfield identifies the role that is
most relevant for the STA for that channel.
The STA MAC Address Present subfield indicates whether the STA MAC Address subfield is present in the
Multi-band element. If the present subfield is set to 1, the STA MAC Address subfield is present. If the STA
MAC Address Present subfield is set to 0, the STA MAC Address subfield is not present.
The Pairwise Cipher Suite Present subfield indicates whether the Pairwise Cipher Suite Count field and the
Pairwise Cipher Suite List field are present in the Multi-band element. If the Pairwise Cipher Suite Present
subfield is set to 1, the Pairwise Cipher Suite Count field and the Pairwise Cipher Suite List field are present.
If the Pairwise Cipher Suite Present subfield is set to 0, the Pairwise Cipher Suite Count field and the
Pairwise Cipher Suite List field are not present.
The Band ID field provides the identification of the frequency band related to the Operating Class and
Channel Number fields. The Band ID field is defined in 9.4.1.46.
Operating Class indicates the channel set for which the Multi-band element applies. Operating Class and
Channel Number together specify the channel frequency and spacing for which the Multi-band element
applies. Valid values of Operating Class are shown in Annex E. This field is set to 0 to indicate all operating
classes within the frequency band specified by the value of the Band ID field.
1077
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Channel Number field is set to the number of the channel the transmitting STA is operating on or
intends to operate on. This field is set to 0 to indicate all channels within the frequency band specified by the
value of the Band ID field.
The BSSID field specifies the BSSID of the BSS operating on the channel and frequency band indicated by
the Channel Number and Band ID fields.
The Beacon Interval field specifies the size of the beacon interval for the BSS operating on the channel and
frequency band indicated by the Channel Number and Band ID fields. This field is set to 0 if no BSS is in
operation in the indicated channel and frequency band.
If the transmitting STA is a member of a PBSS or infrastructure BSS on both the channel indicated in this
element and the channel on which the element is transmitted, then the TSF Offset field contains the time
offset of the TSF of the PBSS or infrastructure BSS of which the transmitting STA is member on the channel
indicated in this element relative to the TSF of the PBSS or infrastructure BSS corresponding to the BSSID
indicated in the Address 3 field of the MPDU in which this element is transmitted. The value of the TSF
Offset field is specified as a 2s complement integer in microsecond units. If the transmitting STA is not a
member of an infrastructure BSS or PBSS on both the channel indicated in this element and the channel on
which the element is transmitted, then the TSF Offset field contains the value 0.
The Multi-band Connection Capability field is defined in Figure 9-529. The Multi-band Connection
Capability field indicates the connection capabilities supported by the STA on the channel and band
indicated in this element.
B0 B1 B2 B3 B4 B5 B7
AP PCP DLS TDLS IBSS Reserved
Bits: 1 1 1 1 1 3
Figure 9-529—Multi-band Connection Capability field format
The AP subfield specifies whether the STA can function as an AP on the channel and band indicated in the
element. It is set to 1 when the STA is capable to function as an AP, and it is set to 0 otherwise.
The PCP subfield specifies whether the STA can function as a PCP on the channel and band indicated in the
element. It is set to 1 when the STA is capable to function as a PCP, and it is set to 0 otherwise.
The DLS subfield is set to 1 to indicate that the STA can perform a DLS on the channel and band indicated
in the element. Otherwise, it is set to 0.
The TDLS subfield is set to 1 to indicate that the STA can perform a TDLS on the channel and band
indicated in the element. Otherwise, it is set to 0.
The IBSS subfield is set to 1 to indicate that the STA is able to support IBSS on the channel and band
indicated in the element. Otherwise, it is set to 0.
The FSTSessionTimeout field is used in the FST Setup Request frame to indicate the timeout value for FST
session setup protocol as defined in 11.33.1. The FSTSessionTimeout field contains the duration, in TUs,
after which the FST setup is terminated.
The STA MAC Address field contains the MAC address that the transmitting STA uses while operating on
the channel indicated in this element. The STA MAC Address field is not present in this element if the STA
MAC Address Present field is set to 0.
1078
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Pairwise Cipher Suite Count field and the Pairwise Cipher Suite List field are defined in 9.4.2.25. These
fields are not present in this element if the Pairwise Cipher Suite Present subfield is set to 0.
9.4.2.139 ADDBA Extension element
The ADDBA Extension element is shown in Figure 9-530.
Element ID Length ADDBA Capabilities
Octets: 1 1 1
Figure 9-530—ADDBA Extension element format
The Element ID and Length fields are defined in 9.4.2.1.
The ADDBA Capabilities field is shown in Figure 9-531.
B0 B1 B7
No-Fragmentation Reserved
Bits: 1 7
Figure 9-531—ADDBA Capabilities field format
The ADDBA Extension element can be included in the ADDBA Request and Response frames.
The No-Fragmentation subfield determines whether a fragmented MSDU can be carried in the MPDU sent
under the block ack agreement. When this subfield set to 1 in the ADDBA Request frame, it indicates that
the originator is not fragmenting sent MSDUs. When this subfield set to 1 in the ADDBA Response frame, it
indicates that the recipient is not capable of receiving fragmented MSDUs.
9.4.2.140 Next PCP List element
The Next PCP List element contains one or more AID of NextPCP i fields as shown in Figure 9-532.
Element AID of AID of
Length Token …
ID NextPCP 1 NextPCP n
Octets: 1 1 1 1 … 1
Figure 9-532—Next PCP List element format
The Element ID and Length fields are defined in 9.4.2.1.
The Token field is set to 0 when the PBSS is initialized and incremented each time the sequence of AID of
NextPCP i fields is updated.
Each AID of NextPCP i field contains the AID value of a STA. The AID values are listed in the order
described in 11.29.2.
1079
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.141 PCP Handover element
The PCP Handover element is used to indicate which STA becomes the new PCP following an explicit or
implicit handover procedure. The PCP Handover element is defined in Figure 9-533.
Element ID Length Old BSSID New PCP Address Remaining BIs
Octets: 1 1 6 6 1
Figure 9-533—PCP Handover element format
The Element ID and Length fields are defined in 9.4.2.1.
The Old BSSID field contains the BSSID of the PBSS from which control is being handed over.
The New PCP Address field indicates the MAC address of the new PCP following a handover.
The Remaining BIs field indicates the number of beacon intervals, from the beacon interval in which this
element is transmitted, remaining until the handover takes effect.
9.4.2.142 DMG Link Margin element
9.4.2.142.1 General
The format of the DMG Link Margin element is shown in Figure 9-534. The DMG Link Margin element is
included in a Link Measurement Report frame.
Element ID Length Activity MCS Link Margin SNR Reference Timestamp
Octets: 1 1 1 1 1 1 4
Figure 9-534—DMG Link Margin element format
The Element ID and Length fields are defined in 9.4.2.1.
The Activity field is set to a preferred action that the STA sending this element recommends that the peer
STA indicated in the RA field of the Link Measurement Report frame execute. The method by which the
sending STA determines a suitable action for the peer STA is implementation specific. The Activity field is
defined in 9.4.2.142.2.
The MCS field is set to an integer representation of the MCS that the STA sending this element recommends
that the peer STA indicated in the RA field of the Link Measurement Report frame use to transmit frames to
this STA. The reference PER for selection of the MCS is 10-2 for an MPDU length of 4096 octets. The
method by which the sending STA determines a suitable MCS for the peer STA is implementation specific.
Values 0–31 indicate MCS 0 to MCS 31. Values 133, 134, 135, 136, 137, 138, 140 indicate MCSs 12.1, 9.1,
12.3, 12.4, 12.5, 12.2 and 12.6, respectively.
The Link Margin field contains the measured link margin of Data frames received from the peer STA
indicated in the RA field of the Link Measurement Report frame and is coded as a 2s complement signed
integer in units of decibels. A value of –128 indicates that no link margin is provided. The method used to
measure the link margin is beyond the scope of this standard.
The SNR field indicates the SNR measured during the reception of a PHY packet. Values are from –13 dB
to 50.75 dB in 0.25 dB steps.
1080
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Reference Timestamp field contains the lower 4 octets of the TSF timer value sampled at the instant that
the MAC received the PHY-CCA.indication(IDLE) primitive that corresponds to the end of the reception of
the PPDU that was used to generate the feedback information contained in the Link Measurement Report
frame.
9.4.2.142.2 Activity field
The Activity field values are defined in Table 9-243.
Table 9-243—Activity field values
Preferred Action value Meaning
0 No change preferred
1 Change(d) MCS
2 Decrease(d) transmit power
3 Increase(d) transmit power
4 Fast session transfer (FST)
5 Power conserve mode
6 Perform SLS
7–255 Reserved
9.4.2.143 DMG Link Adaptation Acknowledgment element
The format of the DMG Link Adaptation Acknowledgment element is shown in Figure 9-535. The DMG
Link Adaptation Acknowledgment element is carried in the Optional Subelements field of the Link
Measurement Report frame.
Element ID Length Activity Reference Timestamp
Octets: 1 1 1 4
Figure 9-535—DMG Link Adaptation Acknowledgment element format
The Element ID and Length fields are defined in 9.4.2.1.
The Activity field is set to the action that the STA sending this element has executed following the reception
of the recommended activity in a Link Measurement Report frame. The method by which the sending STA
determines the action is described in 10.39 and the Activity field is defined in 9.4.2.142.2.
The Reference Timestamp field contains the lower 4 octets of the TSF timer value sampled at the instant that
the MAC received the PHY-CCA.indication(IDLE) primitive that corresponds to the end of the reception of
the PPDU that was used to generate the feedback information contained in the Link Measurement Report
frame.
1081
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.144 Switching Stream element
The Switching Stream element indicates the streams that the transmitting STA requests to be switched to a
new frequency band or operating class or channel. The format of the Stream Switching element is shown in
Figure 9-536.
Element Length Old New Non-QoS Number of Streams Switching
ID Band ID Band ID Data Frames Switching Parameters
2 × Number of
Octets: 1 1 1 1 1 1 Streams Switching
Figure 9-536—Switching Stream element format
The Element ID and Length fields are defined in 9.4.2.1.
The Old Band ID field specifies the frequency band to which the information carried in this element is
related. This field is defined in 9.4.1.46.
The New Band ID field specifies the frequency band to which the information contained in the Stream ID In
New Band subfield of this element is related. This field is defined in 9.4.1.46.
The Non-QoS Data Frames field specifies whether non-QoS Data frames can be transmitted in the frequency
band indicated in the New Band ID field. If the Non-QoS Data Frames field is set to 0, non-QoS Data frames
cannot be transmitted in the frequency band indicated in the New Band ID field. If the Non-QoS Data
Frames field is set to 1, non-QoS Data frames can be transmitted in the frequency band indicated in the New
Band ID field.
The Number of Streams Switching field specifies the number of streams to be switched.
The format of Switching Parameters field is shown in Figure 9-537.
B0 B3 B4 B5 B8 B9 B10 B11 B12 B15
Stream ID In Old Band Stream ID In New Band Stream ID In
New Band LLT Type Reserved
TID Direction TID Direction Valid
Bits: 4 1 4 1 1 1 4
Figure 9-537—Switching parameters field format
The Stream ID In Old Band and Stream ID In New Band subfields are comprised of the TID and Direction
subfields. The subfields within the Stream ID In New Band subfield are reserved if the Stream ID In New
Band Valid subfield is set to 0.
The TID subfield specifies the stream in the corresponding band.
The Direction subfield specifies whether the STA transmitting this element is the source or destination of the
corresponding TID. It is set to 0 to indicate that the STA transmitting this element is the source of the TID,
and it is set to 1 otherwise.
The Stream ID In New Band Valid subfield is set to 1 if the information contained in the Stream ID In New
Band subfield is valid, that is, the TID specified within the Stream ID In New Band subfield has been
established in the band identified in the New Band ID field. The Stream ID In New Band Valid subfield is
set to 0 otherwise.
1082
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The LLT Type subfield is set to 1 to indicate that the streambased Link Loss Countdown is used for the
stream identified by the Stream ID In Old Band subfield. The LLT Type subfield is set to 0 to indicate that
the STA-based Link Loss Countdown is used for the stream identified by the Stream ID In Old Band
subfield. This subfield is reserved when the LLT field within the FST Setup Request or FST Setup Response
frame containing this element is set to 0.
9.4.2.145 Session Transition element
The Session Transition element is defined in Figure 9-538.
New Band Old Band
Element Length FSTS Session
ID ID Control Band Band
Setup Operation Setup Operation
ID ID
Octets: 1 1 4 1 1 1 1 1 1 1
Figure 9-538—Session Transition element format
The Element ID and Length fields are defined in 9.4.2.1.
The FSTS ID (fast session transfer session identifier) field contains the identification of the FST session
established between a pair of STAs as allocated by the initiator (10.32).
The Session Control field is defined in Figure 9-539.
B0 B3 B4 B5 B7
Session Type Switch Intent Reserved
Bit: 4 1 3
Figure 9-539—Session Control field format
The Session Type subfield is defined as shown in Table 9-244 and indicates the type of connection/session
that is intended to be set up in the new band for this FST session.
Table 9-244—Session Type subfield values
Value Session type
0 Infrastructure BSS
1 IBSS
2 DLS
3 TDLS
4 PBSS
5–255 Reserved
When the Session Type subfield is set to IBSS and the STA Role subfield within the Multi-band element is
set to IBSS STA, the BSSID field within the Multi-band element contains the MAC address of the BSSID of
1083
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the IBSS. This indicates that the transmitting STA is not associated with an AP on the band and channel
indicated in the Multi-band element.
The Switch Intent subfield is set to 1 to indicate that the FST Initiator that transmitted the FST Setup
Request frame intends to switch to the band/channel indicated within the Band ID subfield of the FST Setup
Request frame and in the Multi-band element, even if the FST transition does not succeed. Otherwise, this
subfield is set to 0. This subfield is reserved when transmitted within an FST Setup Response frame.
The New Band and Old Band subfields are used for the signaling described in 11.33.1. Both the New Band
and Old Band subfields contain a Band ID subfield, a Setup subfield, and an Operation subfield.
The Band ID subfield is defined in 9.4.1.46. If a Multi-band element is present in the frame containing this
Session Transition element, the Band ID subfield refers to the Operating Class and Channel Number fields
within the Multi-band element provided the value of both of these fields are nonzero.
The Setup subfield is set to 1 to indicate that the STA transmitting this element has an FST session
established with the STA that the frame containing this element is addressed and in the band indicated
within the Band ID subfield. Otherwise, it is set to 0. Other values are reserved.
The Operation subfield is set to 1 to indicate that the STA is operating in the band indicated within the Band
ID subfield. Otherwise, it is set to 0. Other values are reserved.
9.4.2.146 Dynamic Tone Pairing (DTP) Report element
The DTP Report element is included in the DTP Response frame. The format of the DTP Report element is
shown in Table 9-245.
Table 9-245—DTP Report element format
Field Length Meaning
Element ID 8 bits
Length 8 bits
GroupPairIndex(0) 6 bits Index of DTP group pair n in the range 0 to
NG–1, for n = 0,1,2,…,NG–1 where NG=42
GroupPairIndex(1) 6 bits
… …
GroupPairIndex(NG-1) 6 bits
Zero pad 4 bits Zero padding to make the DTP Feedback
element length a multiple of 8 bits
The Element ID and Length fields are defined in 9.4.2.1.
GroupPairIndex(n) subfields for n=0,1,..,NG–1(where NG=42) indicate DTP groups, which in turn
determines how pairs of SQPSK symbols are mapped to OFDM tones when DTP is enabled, as described in
20.5.3.2.4.6.3. Valid values of GroupPairIndex(n) are in the range 0 to NG–1. Furthermore valid values of
GroupPairIndex(0), GroupPairIndex(1),…, GroupPairIndex(NG–1) are distinct and therefore represent a
permutation of integers 0 to NG–1.
All numeric fields are encoded as unsigned integers.
1084
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.147 Cluster Report element
The format of the Cluster Report element is shown in Figure 9-540. The Cluster Report element is included
Action frames, such as Announce and Information Response frames, transmitted to the AP or PCP of the
BSS. Because the Length field supports only 255 octets of information in an element, the STA can split the
content of the Extended Schedule Element field, as described in 9.4.2.132, in different Cluster Report
elements. The value of n in Figure 9-540 is given by the following equation:
n = 255 – 2 + S RB + S RT + S CC + S EPE + S TSCONST
where
SRB is the size of the Reported BSSID field in octets
SRT is the size of the Reference Timestamp field in octets
SCC is the size of the Clustering Control field in octets
SEPE is the size of the ECAPC Policy Element field in octets
STSCONST is the size of the Traffic Scheduling Constraint Set field in octets
Cluster Report Reported Reference Clustering
Element ID Length Control BSSID Timestamp Control
Octets: 1 1 1 0 or 6 0 or 4 0 or 8
ECAPC Policy Extended Schedule Number of
Element Element Constraints Traffic Scheduling Constraint Set
Octets: 0, 13 or 17 0 or 17 – n 1 Variable
Figure 9-540—Cluster Report element format
The Element ID and Length fields are defined in 9.4.2.1.
The Cluster Report Control field is defined in Figure 9-541.
B0 B1 B2 B3 B4 B5 B6 B7
ECAPC ECAPC
Cluster Cluster Schedule TSCONST
Request Report Present Present Policy Policy Reserved
Enforced Present
Bits: 1 1 1 1 1 1 2
Figure 9-541—Cluster Report Control field format
The Cluster Request subfield is set to 1 to indicate that the STA is requesting the AP or PCP to start AP or
PCP clustering (10.37). Otherwise, it is set to 0.
The Cluster Report subfield is set to 1 to indicate that this element contains a cluster report. If this subfield is
set to 1, the Reported BSSID, Reference Timestamp and Clustering Control fields are present in this
element. Otherwise, if the Cluster Report subfield is set to 0, none of the Reported BSSID, Reference
Timestamp, Clustering Control, Extended Schedule Element, and Traffic Scheduling Constraint Set fields is
present in this element.
1085
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Schedule Present subfield is valid only if the Cluster Report subfield is set to 1; otherwise, it is reserved.
The Schedule present subfield is set to 1 to indicate that the Extended Schedule Element field is present in
this element. Otherwise, the Extended Schedule Element field is not present in this element.
The TSCONST Present subfield is valid only if the Cluster Report subfield is set to 1; otherwise, it is
reserved. The TSCONST Present subfield is set to 1 to indicate that the Number of Constraints field and the
Traffic Scheduling Constraint Set field are present in this element. Otherwise, these fields are not present in
this element.
The ECAPC Policy Enforced subfield is valid only if the Cluster Report subfield is set to 1; otherwise, it is
reserved. The ECAPC Policy Enforced subfield is defined in 9.3.4.2 and contains the ECAPC Policy
Enforced subfield received in the DMG Beacon frame that generated this report.
The ECAPC Policy Present subfield is valid only if the Cluster Report subfield is set to 1; otherwise, it is
reserved. The ECAPC Policy Present subfield is set to 1 to indicate that the ECAPC Policy Present Element
field is present in this element. Otherwise, the ECAPC Policy Present Element field is not present in this
element.
The Reported BSSID field contains the BSSID of the DMG Beacon frame that triggered this report.
The Reference Timestamp field contains the lower 4 octets of the TSF timer value sampled at the instant that
the STA’s MAC received a DMG Beacon frame that triggered this report.
The Clustering Control field is defined in 9.3.4.2 and contains the Clustering Control received in the DMG
Beacon frame that triggered this report.
The ECAPC Policy Element field is defined in 9.4.2.151 and contains the ECAPC Policy element obtained
from the AP or PCP that sent the DMG Beacon frame that generated this report (see 10.37.4).
The Extended Schedule Element field is defined in 9.4.2.132 and contains a single Extended Schedule
element received in the DMG Beacon frame that generated this report. If an Extended Schedule element is
not present in the received DMG Beacon, this field is set to all 0s.
The Number of Constraints field indicates the number of Constraint subfields contained in the Traffic
Scheduling Constraint Set field. The value of this field ranges from 0 to 15. Other values are reserved.
The Traffic Scheduling Constraint Set field contains one or more Constraint subfields as defined in
9.4.2.134 and specifies periods of time with respect to the TBTT of the beacon interval of the BSS the STA
participates where the STA experiences poor channel conditions, such as due to interference.
9.4.2.148 Relay Capabilities element
A STA that intends to participate in relay operation (11.36) advertises its capabilities through the Relay
Capabilities element. The Relay Capabilities element is defined in Figure 9-542.
Element ID Length Relay Capabilities Information
Octets: 1 1 2
Figure 9-542—Relay Capabilities element format
The Element ID and Length fields are defined in 9.4.2.1.
The Relay Capability Information field is defined in Figure 9-543.
1086
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3 B4 B5 B6 B7 B8 B15
Relay Relay Relay A/C Relay
Supporter Client Permission Power Preference Duplex Cooperation Reserved
Bits: 1 1 1 1 1 2 1 8
Figure 9-543—Relay Capability Information field format
The Relay Supporter subfield indicates whether the STA is capable of relaying by transmitting and receiving
frames between a pair of other STAs. A STA capable of relaying is called a relay STA. This subfield is set to
1 if the STA supports relaying; otherwise, it is set to 0.
The Relay Client subfield indicates whether the STA is capable of using frame-relaying through a relay
STA. It is set to 1 if the STA supports transmission and reception of frames through a relay STA; otherwise,
it set to 0.
The Relay Permission subfield indicates whether the AP or PCP allows relay operation (11.36) to be used
within the AP’s or PCP’s BSS. It is set to 0 if relay operation is not allowed in the BSS; otherwise, it is set to
1. This subfield is reserved when transmitted by a non-AP and non-PCP STA.
The A/C Power subfield indicates whether the STA is capable of obtaining A/C power. It is set to 1 if the
STA is capable of being supplied by A/C power; otherwise, it is set to 0.
The Relay Preference subfield indicates whether the STA prefers to become RDS rather than REDS. It is set
to 1 if a STA prefers to be RDS; otherwise, it is set to 0.
The Duplex subfield indicates whether the STA is capable of full-duplex/amplify-and-forward (FD-AF) or
half-duplex/decode-and-forward (HD-DF). It is set to 1 if the STA is not capable of HD-DF but is capable of
only FD-AF. It is set to 2 if the STA is capable of HD-DF but is not capable of FD-AF. It is set to 3 if the
STA is capable of both HD-DF and FD-AF. The value 0 is reserved.
The Cooperation subfield indicates whether a STA is capable of supporting link cooperation. It is set to 1 if
the STA supports both link cooperation and link switching. It is set to 0 otherwise.
9.4.2.149 Relay Transfer Parameter Set element
A source REDS that intends to transfer frames via an RDS advertises the parameters for the relay operation
with the transmission of a Relay Transfer Parameter Set element (11.36). The Relay Transfer Parameter Set
element is defined in Figure 9-544.
Element ID Length Relay Transfer Parameter
Octets: 1 1 8
Figure 9-544—Relay Transfer Parameter Set element format
The Element ID and Length fields are defined in 9.4.2.1.
The Relay Transfer Parameter field is defined in Figure 9-545.
1087
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3 B7 B8 B15 B16 B23 B24 B39 B40 B55 B56 B63
Link Data
Duplex- Cooperation- Tx-Mode Reserved Change Sensing First Second Reserved
Mode Mode Period Period
Interval Time
Bits: 1 1 1 5 8 8 16 16 8
Figure 9-545—Relay Transfer Parameter field format
The Duplex-Mode subfield indicates that the source REDS set the duplex mode of the RDS involved in
RLS. The Duplex-Mode subfield value is set to 0 if the RDS operates in HD-DF mode. It is set to 1 if the
RDS operates in FD-AF mode.
The Cooperation-Mode subfield indicates whether the source REDS sets the link cooperation of the RDS
involved in RLS. This subfield is valid only when the RDS is capable of link cooperation and Duplex-Mode
subfield is set to 0. Otherwise, this subfield is reserved. The Cooperation-Mode subfield value is set to 0 if
the RDS operates in link switching. It is set to 1 if the RDS operates in link cooperation.
The Tx-Mode subfield indicates that the source REDS sets the transmission mode of the RDS involved in
RLS. This subfield is valid only when the RDS is capable of link switching and the Duplex-Mode subfield is
set to 1. Otherwise, this subfield is reserved. The Tx-Mode subfield value is set to 0 if a group of three STAs
involved in the RLS operates in Normal mode and is set to 1 if the group operates in Alternation mode.
The Link Change Interval subfield indicates when the link of frame transmission between source REDS and
destination REDS is changed. From the start position of one reserved continuous SP, every time instant of
link change interval can have an opportunity to change the link. Within one link change interval, only one
link is used for frame transfer. The unit of this subfield is microseconds. This subfield is used only when the
group involved in the RLS operates in link switching.
The Data Sensing Time subfield indicates the defer time offset from the time instant of the next link change
interval when the link switching occurs. By default, it is set to SIFS plus SBIFS. This subfield is used only
when the STAs involved in the RLS operate in link switching with Tx-Mode that is 0.
The First Period subfield indicates the period of the source REDS-RDS link in which the source REDS and
RDS exchange frames. This subfield is used only when HD-DF RDS operates in link switching.
The Second Period subfield indicates the period of the RDS-destination REDS link in which the RDS and
destination REDS exchange frames and the following period of the RDS-source REDS link in which the
RDS informs the source REDS of finishing one frame transfer. This subfield is used only when HD-DF RDS
operates in link switching.
9.4.2.150 Quiet Period Request element
The Quiet Period Request element defines a periodic sequence of quiet intervals that the requester AP
requests the responder AP to schedule. The format of the Quiet Period Request element is shown in
Figure 9-546.
Quiet
Element Request Quiet Quiet Repetition Target
ID Length Token Period Period Duration Count BSSID
Offset
Octets: 1 1 2 2 4 2 1 6
Figure 9-546—Quiet Period Request element format
1088
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The Request Token field is set to a nonzero value chosen by the requester AP.
The Quiet Period Offset field is set to the offset of the start of the first quiet interval from the QAB Request
frame that contains this element, expressed in TUs. The reference time is the start of the preamble of the
PPDU that contains this element.
The Quiet Period field is set to the spacing between the start of two consecutive quiet intervals, expressed in
TUs.
The Quiet Duration field is set to duration of the quiet time, expressed in TUs.
The Repetition Count field is set to the number of requested quiet intervals.
NOTE—The periodic sequence of quiet intervals ends after the start of preamble of the PPDU containing the QAB IE +
Quiet Period Offset + (Repetition Count-1)×Quiet Period + Quiet Duration (in TUs).
The Target BSSID field is set to the responder AP’s MAC address.
9.4.2.151 Quiet Period Response element
The Quiet Period Response element defines the feedback information from the AP that received the Quiet
Period Request element. The format of the Quiet Period Response element is shown in Figure 9-547.
Element ID Length Request Token BSSID Status Code
Octets: 1 1 2 6 2
Figure 9-547—Quiet Period Response element format
The Element ID and Length fields are defined in 9.4.2.1.
The Request Token field is set to the value of the Request Token field of the corresponding received Quiet
Period Request element.
The BSSID field is set to the value of the Target BSSID field of the corresponding received Quiet Period
Request element.
The Status Code field is defined in 9.4.1.9.
9.4.2.152 BeamLink Maintenance element
The format of the BeamLink Maintenance element is shown in Figure 9-548. The BeamLink Maintenance
element is included in Action frames, such as Probe, Announce and the Information Request and Response
frames, transmitted between a non-AP and non-PCP DMG STA and a DMG AP or PCP. The element is
included in the Probe and Information Request and Response frames transmitted between non-AP and non-
PCP DMG STAs.
Element ID Length Beamformed Link Maintenance
Octets: 1 1 1
Figure 9-548—BeamLink Maintenance element format
1089
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID and Length fields are defined in 9.4.2.1.
The Beamformed Link Maintenance field is defined in 9.5.6.
9.4.2.153 Multiple MAC Sublayers (MMS) element
The format of Multiple MAC Sublayers (MMS) element is shown in Figure 9-549. The MMS element is
included in Action frames, such as Probe Request, Association Request, Information Request, Announce,
and Information Response frames, transmitted to the peer STA and the AP or PCP of the BSS.
Element ID Length MMS Control STA MAC Address Interface Address(es)
Octets: 1 1 1 6 6 × n (variable)
Figure 9-549—MMS element format
The Element ID and Length fields are defined in 9.4.2.1.
The MMS Control field is defined in Figure 9-550.
B0 B1 B2 B3 B4 B5 B7
MMS Element Single MM-SME BeamLink Reserved
Owner AID Power Mode Cluster
Bit: 2 1 1 1 3
Figure 9-550—MMS Control field format
The MMS Element Owner subfield is encoded as shown in Table 9-246. If the MMS Element Owner field is
set to No Owner, then the Interface address(es) field in the MMS element is reserved.
Table 9-246—MMS Element Owner subfield definition
MMS Element Owner subfield
value
Meaning
B0 B1
0 0 No Owner
1 0 Non-AP and Non-PCP MMS element
0 1 PCP MMS element
1 1 AP MMS element
The Single AID subfield is one bit in length and is encoded as defined in Table 9-247.
1090
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-247—Single AID subfield definition
MMS Element Single
MMS MMS Owner AID
element sent element sent Meaning
from to
B0 B1 B3
Non-AP and AP or PCP 1 0 1 Request to allocate single AID for MAC addresses
non-PCP included in the MMS element
STA
Non-AP and AP or PCP 1 0 0 Do not allocate single AID for MAC addresses
non-PCP included in the MMS element
STA
AP or PCP Non-PCP, 1 0 1 Single AID is allocated for all MAC addresses in the
non-AP STA MMS element
AP or PCP Non-PCP, 1 0 0 Single AID is not allocated for all MAC addresses
non-AP STA in the MMS element
Non-AP and Non-PCP, 1 0 1 Single AID is allocated for all MAC addresses in the
non-PCP non-AP STA MMS element
STA
Non-AP and Non-PCP, 1 0 0 Single AID is not allocated for all MAC addresses
non-PCP non-AP STA in the MMS element
STA
AP or PCP Non-PCP, 0 1 1 Single AID is allocated for all MAC addresses in the
non-AP STA non-AP and non-PCP STA MMS element
AP or PCP Non-PCP, 0 1 0 Single AID is not allocated for all MAC addresses
non-AP STA in the non-AP and non-PCP STA MMS element
The MM-SME Power Mode subfield is one bit in length and is set to 1 to indicate that when a STA
advertised in the MMS element sent by the STA coordinated by an MM-SME moves from the awake to the
doze state, then all other STAs advertised in the MMS element sent by the STA move to the doze state. The
STA coordinated by the MM-SME moves to the awake state only when all STAs advertised in the MMS
element move to the awake state. The MM-SME Power Mode subfield is set to 0 to indicate that when a
STA advertised in the MMS element sent by the STA moves from the doze to the awake state, then all other
STAs advertised in the MMS element sent by the STA coordinated by the MM-SME move to the awake
state. The STA coordinated by the MM-SME moves to the doze state only when all STAs advertised in the
MMS element move to the doze state.
The BeamLink Cluster subfield is one bit in length and is set to 1 if the DMG STA intends to maintain the
same beamformed link for all of the links within the MMSL cluster. Otherwise, this subfield is set to 0.
The STA MAC Address field contains the MAC address of the STA.
When present in the element, the Interface Address(es) field contains one or more MAC addresses that can
be used to identify the STAs in addition to the STA MAC address, coordinated by the same MM-SME (see
11.34).
9.4.2.154 U-PID element
The format of the Upper Layer Protocol Identification (U-PID) element is described in Figure 9-551.
1091
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
LLC
Element ID Length Header LLC Header Copy
Removed
Octets: 1 1 1 Variable
Figure 9-551—U-PID element format
The Element ID and Length fields are defined in 9.4.2.1.
The LLC Header Removed field is set to 1 to indicate that MSDUs do not contain the LLC (Logical Link
Control) header over the WM. It is set to 0 otherwise.
The content and corresponding size of the LLC Header Copy field are specified in Table 9-248.
Table 9-248—LLC Header Copy field size
LLC Header Copy field contents LLC Header Copy field size (octets)
LLC header with 8-bit control field without SNAP 3
LLC header with 8-bit control field with SNAP 8
LLC header with 16-bit control field without SNAP 4
LLC header with 16-bit content field with SNAP 9
NOTE—The structure of the LLC header is defined in IEEE Std 802.2-1998. The structure of the LLC with SNAP
extension is defined in IEEE Std 802.2-1998.
9.4.2.155 ECAPC Policy element
The format of the ECAPC Policy element is shown in Figure 9-552.
Available TXSS TXSS TXSS
Element ECAPC CCSR Cluster CBAP CBAP CBAP
Length Policy
ID Detail ID Time Offset Offset Duration MaxMem
Bitmap (optional) (optional) (optional)
Octets: 1 1 1 6 4 0 or 2 0 or 1 0 or 1
Figure 9-552—ECAPC Policy element format
The Element ID and Length fields are defined in 9.4.2.1.
The ECAPC Policy Detail field is defined in Figure 9-553.
B0 B1 B2 B3 B7
BHI Enforced TXSS CBAP Enforced Protected Period Enforced Reserved
Bits: 1 1 1 5
Figure 9-553—ECAPC Policy Detail field format
1092
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The BHI Enforced subfield set to 1 indicates that an AP or PCP in a centralized AP or PCP cluster completes
the BHI for the current beacon interval before TBTT + (8×Beacon SP duration), as described in 10.37.3.4.
The BHI Enforced subfield set to 0 indicates that an AP or PCP within a cluster does not have to complete
the BHI for the current beacon interval before TBTT + (8×Beacon SP duration).
The TXSS CBAP Enforced subfield set to 1 indicates that a STA in a centralized AP or PCP cluster
performs each of its TXSSs in the DTI within one or more TXSS CBAPs, as described in 10.37.3.4. The
TXSS CBAP Enforced subfield set to 0 indicates that a STA within a centralized AP or PCP cluster does not
have to perform each of its TXSSs in the DTI within one or more TXSS CBAPs.
The Protected Period Enforced subfield indicates that every scheduled SP in the BSS is a DMG protected
period as specified in 10.36.6.6. The Protected Period Enforced subfield set to 0 indicates that a scheduled
SP in the BSS does not have to be a DMG protected period.
The CCSR ID field is set to the MAC address of the CCSR within the ECAPC that the AP or PCP belongs
to. The AP or PCP is the transmitter of the frame containing the ECAPC Policy element except when the
ECAPC Policy element is transmitted in a Cluster Report element, where the AP or PCP is the transmitter
that triggered the Cluster report.
The Available Time Cluster Offset Bitmap field is a bitmap where the bit n–1, n = 1 to 32, indicates the
availability of the nth Beacon SP. Values of n = 1 and greater than ClusterMaxMem are reserved (i.e., bit 0
and bits ClusterMaxMem+1 to 31 inclusive). Bit n–1 set to 0 indicates that ClusterTimeOffsetn-1 is
determined to be already in use by a neighboring AP or PCP, excluding the recipient if sent within an
individually addressed frame, in the ECAPC. Bit n–1 set to 1 indicates that ClusterTimeOffsetn-1 is not
determined to be already in use by a neighboring AP or PCP, excluding the recipient if sent within an
individually addressed frame, in the ECAPC.
If TXSS CBAP Enforced field is set to 0, then the TXSS CBAP Offset field, the TXSS CBAP Duration
field, and the TXSS CBAP MaxMem field are not present in the element; otherwise, they are present in the
element.
The TXSS CBAP Offset field is the delay of the first TXSS CBAP in a beacon interval from the TBTT, in
units of 8 µs.
The TXSS CBAP Duration field indicates the duration of each TXSS CBAP, in units of 8 µs.
The TXSS CBAP MaxMem field is the number of TXSS CBAPs per beacon interval.
9.4.2.156 Cluster Time Offset element
The format of the Cluster Time Offset element is shown in Figure 9-554.
Element ID Length Cluster Time Offset Index
Octets: 1 1 1
Figure 9-554—Cluster Time Offset element format
The Element ID and Length fields are defined in 9.4.2.1.
The Cluster Time Offset Index field is set to n–1 for a member AP or member PCP of a centralized AP or
PCP cluster that adopted the nth Beacon SP (see 10.37). Values equal to 0 and greater than ClusterMaxMem
are reserved.
1093
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.157 Antenna Sector ID Pattern element
The format of the Antenna Sector ID Pattern element is shown in Figure 9-555.
B0 B7 B8 B15 B16 B19 B20 B25 B26 B31 B32 B39 B40 B47
Element ID Length Type Tap 1 State 1 Tap 2 State 2
Bits: 8 8 4 6 6 8 8
Figure 9-555—Antenna Sector ID Pattern element format
The Element ID and Length fields are defined in 9.4.2.1.
The Type field is set to 0 for Random Sequence Generator. Values 1 to 3 are reserved.
The Tap 1 field indicates the taps for Sequence Generator 1.
The State 1 field indicates the state for Sequence Generator 1.
The Tap 2 field indicates the taps for Sequence Generator 2.
The State 2 field indicates the state for Sequence Generator 2.
Sequence Generator 1 is shown in Figure 9-556 and is defined as follows:
— Generate the sector IDs for subsequent DMG Beacons by advancing the Sequence Generator 1,
which is initialized using the values of the Tap 1 and State 1 fields contained in the Antenna Sector
ID Pattern element received from the AP or PCP.
— Advance the Sequence Generator 1 by one shift for each anticipated DMG Beacon frame
transmission thereafter.
— After advancing the Sequence Generator 1, if the next state equals the initial state for the second
time, overwrite the state with an all-zero state. The next state following the state following all zero-
state uses the first 6 bits of the state of Sequence Generator 2 as the initial state.
— If the STA’s total number of transmit sectors is not equal to the period of the Sequence Generator 1,
ignore state(s) greater than or equal total number of transmit sectors and continue advancing
Sequence Generator 1 until the state is less than the total number of transmit sectors.
NOTE—The taps are selected from the set of sequences with maximal length property.
Tap 1
0 1 2 3 4 5
0 1 2 3 4 5
State 1 (= Sector ID)
Figure 9-556—Sequence Generator 1
1094
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Sequence Generator 2 is shown in Figure 9-557 and is defined as follows:
— Sequence Generator 2 is initiated with the value of the Tap 2 and State 2 fields contained in the
Antenna Sector ID Pattern element received from the AP or PCP.
— Sequence Generator 2 is advanced by one shift when a new initial state is needed from Sequence
Generator 1.
NOTE—The taps are selected from the set of the sequences with maximal length property.
Tap 2
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7
State 2
Figure 9-557—Sequence Generator 2
9.4.2.158 VHT Capabilities element
9.4.2.158.1 VHT Capabilities element structure
A VHT STA declares that it is a VHT STA by transmitting the VHT Capabilities element.
The VHT Capabilities element contains a number of fields that are used to advertise the VHT capabilities of
a VHT STA. The VHT Capabilities element is defined in Figure 9-558.
Element VHT Capabilities Supported VHT-MCS
ID Length Info and NSS Set
Octets: 1 1 4 8
Figure 9-558—VHT Capabilities element format
The Element ID and Length fields are defined in 9.4.2.1.
9.4.2.158.2 VHT Capabilities Information field
The structure of the VHT Capabilities Information field is defined in Figure 9-559.
1095
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3 B4 B5 B6 B7 B8 B10 B11 B12 B13 B15
Short GI
for 80 Short GI
Maximum Supported for 160 SU SU Beamformee
MPDU Channel Rx MHz/ and Tx Rx Beamformer Beamformee STS
LDPC TVHT_ STBC STBC
Length Width Set MODE_ 80+80 Capable Capable Capability
MHz
4C
Bits: 2 2 1 1 1 1 3 1 1 3
B16 B18 B19 B20 B21 B22 B23 B25 B26 B27 B28 B29 B30 B31
Number Of MU MU +HTC- Maximum VHT Link Rx Antenna Tx Antenna Extended
TXOP A-MPDU Pattern
Sounding Beamformer Beamformee PS VHT Length Adaptation Pattern Consistency NSS BW
Dimensions Capable Capable Capable Capable Consistency Support
Exponent
3 1 1 1 1 3 2 1 1 2
Figure 9-559—VHT Capabilities Information field
The subfields of the VHT Capabilities Information field are defined in Table 9-249.
Table 9-249—Subfields of the VHT Capabilities Information field
Subfield Definition Encoding
Maximum MPDU Indicates the maximum MPDU Set to 0 for 3895 octets.
Length length that the STA is capable Set to 1 for 7991 octets.
of receiving (see 10.12). Set to 2 for 11 454 octets.
The value 3 is reserved.
Supported Channel Together with the Extended In a non-TVHT STA, see Table 9-250.
Width Set NSS BW Support subfield and
Supported VHT-MCS and NSS In a TVHT STA, the field is structured into subfields as
Set field, indicates the channel defined in Figure 9-560.
widths and maximum NSS In a TVHT STA, set the TVHT_MODE_2C Support
values per width supported by subfield to 1 if it supports TVHT_MODE_2C; otherwise
the STA. See 11.40. set the subfield to 0.
In a TVHT STA, set the TVHT_MODE_2N Support
subfield to 1 if it supports TVHT_MODE_2N; otherwise
set the subfield to 0.
Rx LDPC Indicates support for receiving Set to 0 if not supported.
LDPC encoded packets. Set to 1 if supported.
Short GI for 80 In a non-TVHT STA, indicates In a non-TVHT STA, set to 1 if Short GI for 80 MHz is
MHz/ short GI support for the supported.
TVHT_MODE_4C reception of packets transmitted
with TXVECTOR parameters In a TVHT STA, set to 1 if TVHT_MODE_4C is
FORMAT equal to VHT and supported.
CH_BANDWIDTH equal to
CBW80. Otherwise set to 0.
In a TVHT STA, indicates
support for TVHT_MODE_4C.
1096
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-249—Subfields of the VHT Capabilities Information field (continued)
Subfield Definition Encoding
Short GI for 160 Indicates short GI support for Set to 0 if not supported.
and 80+80 MHz the reception of packets Set to 1 if supported.
transmitted with TXVECTOR
parameters FORMAT equal to In a TVHT STA, set to 1 if it supports
VHT and CH_BANDWIDTH TVHT_MODE_4N.
equal to CBW160 or
CBW80+80.
Tx STBC Indicates support for the Set to 0 if not supported.
transmission of at least 2x1 Set to 1 if supported.
STBC.
Rx STBC Indicates support for the Set to 0 for no support.
reception of PPDUs using Set to 1 for support of one spatial stream.
STBC. Set to 2 for support of one and two spatial streams.
Set to 3 for support of one, two, and three spatial streams.
Set to 4 for support of one, two, three, and four spatial
streams.
The values 5, 6, 7 are reserved.
See NOTE 3.
SU Beamformer Indicates support for operation Set to 0 if not supported.
Capable as an SU beamformer (see Set to 1 if supported.
10.34.5).
SU Beamformee Indicates support for operation Set to 0 if not supported.
Capable as an SU beamformee (see Set to 1 if supported.
10.34.5).
Beamformee STS Indicates the maximum number If the SU Beamformee Capable field is set to 1, set to
Capability of space-time streams that the maximum number of space-time streams that the STA can
STA can receive in a VHT NDP receive in a VHT NDP minus 1.
and the maximum value of Nr Otherwise, reserved.
that the STA transmits in a VHT
Compressed Beamforming
frame.
Number of Beamformer’s capability If the SU Beamformer Capable field is set to 1, set to the
Sounding indicating the maximum value maximum supported value of the TXVECTOR parameter
Dimensions of the TXVECTOR parameter NUM_STS minus 1.
NUM_STS for a VHT NDP. Otherwise, reserved.
MU Beamformer Indicates support for operation Set to 0 if not supported or if SU Beamformer Capable is
Capable as an MU beamformer (see set to 0 or if sent by a non-AP STA.
10.34.5). Set to 1 if supported and SU Beamformer Capable is set
to 1.
MU Beamformee Indicates support for operation Set to 0 if not supported or if SU Beamformee Capable is
Capable as an MU beamformee (see set to 0 or if sent by an AP.
10.34.5). Set to 1 if supported, SU Beamformee Capable is set to 1
and not sent by an AP.
TXOP PS Indicates whether the AP Set to 0 if the AP does not support TXOP power save
supports TXOP power save mode.
mode or whether the non-AP Set to 1 if the AP supports TXOP power save mode.
STA has enabled TXOP power Set to 0 if the non-AP STA does not enable TXOP power
save mode. save mode.
Set to 1 if the non-AP STA enables TXOP power save
mode.
1097
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-249—Subfields of the VHT Capabilities Information field (continued)
Subfield Definition Encoding
+HTC-VHT Indicates whether the STA Set to 0 if not supported.
Capable supports receiving a VHT Set to 1 if supported.
variant HT Control field.
Maximum A- Indicates the maximum length This field is an integer in the range 0 to 7.
MPDU Length of an A-MPDU pre-EOF The length defined by this field is equal to
Exponent padding that the STA can 2
13 + Maximum A-MPDU Length Exponent
– 1 octets.
receive.
VHT Link Indicates whether the STA If +HTC-VHT Capable is 1:
Adaptation supports link adaptation using Set to 0 (No Feedback) if the STA does not provide
Capable VHT variant HT Control field. VHT MFB.
Set to 2 (Unsolicited) if the STA provides only
unsolicited VHT MFB.
Set to 3 (Both) if the STA can provide VHT MFB in
response to VHT MRQ and if the STA provides
unsolicited VHT MFB.
The value 1 is reserved.
Reserved if +HTC-VHT Capable is 0.
Rx Antenna Indicates the possibility of a Set to 0 if the receive antenna pattern might change
Pattern receive antenna pattern change. during the lifetime of the current association.
Consistency Set to 1 if the receive antenna pattern does not change
during the lifetime of the current association.
See 11.40.6.
Tx Antenna Indicates the possibility of a Set to 0 if the transmit antenna pattern might change
Pattern transmit antenna pattern during the lifetime of the current association.
Consistency change. Set to 1 if the transmit antenna pattern does not change
during the lifetime of the current association.
See 11.40.6.
Extended NSS BW Together with the Supported In a non-TVHT STA, see Table 9-250.
Support Channel Width Set subfield and
Supported VHT-MCS and NSS In a TVHT STA, the field is reserved.
Set field, indicates the channel
widths and maximum NSS In a STA with dot11VHTExtendedNSSBWCapable equal
values per width supported by to false or not present, this field is set to 0.
the STA (for non-TVHT VHT
STAs). See 11.40.
NOTE 1—An AP that sets MU Beamformer Capable to 1 can transmit a VHT MU PPDU with only one nonzero
TXVECTOR parameter NUM_STS[p], for 0 p 3. However, a STA that sets MU Beamformee Capable to 0 is not
required to be able to demodulate a VHT MU PPDU with only one nonzero RXVECTOR parameter NUM_STS[p],
for 0 p 3.
NOTE 2—The value of the Maximum MPDU Length subfield of the VHT Capabilities Information field imposes a
constraint on the allowed value in the Maximum MPDU Length subfield of the HT Capabilities element carried in
the same frame (see 10.12).
NOTE 3—Subject to any extended NSS BW support constraint.
1098
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-250—Setting of the Supported Channel Width Set subfield and Extended NSS BW
Support subfield at a STA transmitting the VHT Capabilities Information field
NSS Support of STA transmitting the VHT Location of Location of
Transmitted VHT
Capabilities Information field as a function of the 160 MHz 80+80 MHz
Capabilities
PPDU bandwidth (×Max VHT NSS) (see channel center center
Information field
requirements R1 and R2) frequency if frequency if
BSS BSS
Supported Extended 20 MHz 40 MHz 80 MHz 160 80+80
bandwidth is bandwidth is
Channel NSS BW MHz MHz
160 MHz 80+80 MHz
Width Set Support
0 0 1 1 1
0 1 1 1 1 1/2 CCFS2
0 2 1 1 1 1/2 1/2 CCFS2 CCFS2
0 3 1 1 1 3/4 3/4 CCFS2 CCFS2
1 0 1 1 1 1 CCFS1
1 1 1 1 1 1 1/2 CCFS1 CCFS2
1 2 1 1 1 1 3/4 CCFS1 CCFS2
1 3 2 2 2 2 1 CCFS1 CCFS1
2 0 1 1 1 1 1 CCFS1 CCFS1
2 3 2 2 2 1 1 CCFS1 CCFS1
R1: NSS support shall be rounded down to the nearest integer.
R2: The maximum NSS support shall be 8.
NOTE 1—Max VHT NSS is defined per MCS in 9.4.2.158.3.
NOTE 2—1/2× or 3/4× Max VHT NSS support might end up being 0, indicating no support.
NOTE 3—Any other combination than the ones listed in this table is reserved.
NOTE 4—CCFS1 refers to the value of the Channel Center Frequency Segment 1 field of the most recently
transmitted VHT Operation element.
NOTE 5—CCFS2 refers to the value of the Channel Center Frequency Segment 2 field of the most recently
transmitted HT Operation element.
NOTE 6—CCFS1 is nonzero when the current BSS bandwidth is 160 MHz or 80+80 MHz and the NSS support is at
least Max VHT NSS. CCFS2 is zero in this case.
NOTE 7—CCFS2 is nonzero when the current BSS bandwidth is 160 MHz or 80+80 MHz and the NSS support is
less than Max VHT NSS. CCFS1 is zero in this case.
NOTE 8—At most one of CCFS1 and CCFS2 is nonzero.
NOTE 9—A supported multiple of Max VHT NSS applies to both transmit and receive.
NOTE 10—2× Max VHT NSS support might be used for HT PPDUs (at 20 or 40 MHz PPDU bandwidth).
NOTE 11—A receiving STA in which dot11VHTExtendedNSSCapable is false will ignore the Extended NSS BW
Support subfield and effectively evaluate this table only at the entries where Extended NSS BW Support is 0.
1099
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1
TVHT_MODE_2C Support TVHT_MODE_2N Support
Bits: 1 1
Figure 9-560—Supported Channel Width Set field (TVHT)
Support for short GI for the reception of packets with TXVECTOR parameter CH_BANDWIDTH equal to
CBW20 or CBW40 is indicated in the HT Capabilities Info field of the HT Capabilities element.
9.4.2.158.3 Supported VHT-MCS and NSS Set field
The Supported VHT-MCS and NSS Set field is used to convey the combinations of VHT-MCSs and spatial
streams that a STA supports for reception and the combinations that it supports for transmission. The
structure of the field is shown in Figure 9-561.
B0 B15 B16 B28 B29 B31 B32 B47 B48 B60 B61 B62 B63
Rx Highest Tx Highest VHT
Rx VHT-MCS Supported Maximum Tx VHT-MCS Supported Extended
Map Long GI NSTS,total Map Long GI NSS BW Reserved
Data Rate Data Rate Capable
Bits: 16 13 3 16 13 1 2
Figure 9-561—Supported VHT-MCS and NSS Set field
The Supported VHT-MCS and NSS Set field’s subfields are defined in Table 9-251.
Table 9-251—Supported VHT-MCS and NSS Set subfields
Subfield Definition Encoding
Rx VHT-MCS If transmitted by a STA in which The format and encoding of this subfield are
Map dot11VHTEtxtendedNSSBWCapable is defined in Figure 9-562 and the associated
not true, it indicates the maximum value description.
of the RXVECTOR parameter MCS of a
PPDU that can be received at all channel
widths supported by this STA for each
number of spatial streams.
If transmitted by a STA in which
dot11VHTExtendedNSSBWCapable is
true, this field combined with the
Extended NSS BW Support subfield and
the 160/80+80 BW subfield of the
Operating Mode field determines the
maximum value of the RXVECTOR
parameter MCS of a PPDU as described in
9.4.2.158.2 and 9.4.1.53.
1100
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-251—Supported VHT-MCS and NSS Set subfields (continued)
Subfield Definition Encoding
Rx Highest Indicates the highest long GI VHT PPDU The largest integer value less than or equal to
Supported Long GI data rate that the STA is able to receive. the highest long GI VHT PPDU data rate in
Data Rate Mb/s the STA is able to receive (see 10.7.12.1).
The value 0 indicates that this subfield does not
specify the highest long GI VHT PPDU data
rate that the STA is able to receive.
Maximum Indicates the maximum value for NSTS,total If MU beamformee capable and different from
NSTS,total that can be sent to the STA in a VHT MU 0, indicates the maximum value for NSTS,total
PPDU. minus 1 that can be sent to the STA in a VHT
MU PPDU.
NOTE—This value is greater than or equal to
the value in the Beamformee STS Capability
subfield of the VHT Capabilities Information
field.
If MU Beamformee capable and equal to 0,
indicates that the maximum value for NSTS,total
is equal to the value in the Beamformee STS
Capability subfield of the VHT Capabilities
Information field.
Otherwise reserved.
Tx VHT-MCS If transmitted by a STA in which The format and encoding of this subfield are
Map dot11VHTExtendedNSSBWCapable is defined in Figure 9-562 and the associated
not true, indicates the maximum value of description.
the TXVECTOR parameter MCS of a
PPDU that can be transmitted at all
channel widths supported by this STA for
each number of spatial streams.
If transmitted by a STA in which
dot11VHTExtendedNSSBWCapable is
true, this field combined with the
Extended NSS BW Support subfield and
the 160/80+80 BW subfield of an
Operating Mode field determines the
maximum value of the TXVECTOR
parameter MCS of a PPDU as described in
9.4.2.158.2 and 9.4.1.53.
Tx Highest Indicates the highest long GI VHT PPDU The largest integer value less than or equal to
Supported Long GI data rate that the STA is able to transmit the highest long GI VHT PPDU data rate in
Data Rate at. Mb/s that the STA is able to transmit (see
10.7.12.2).
The value 0 indicates that this subfield does not
specify the highest long GI VHT PPDU data
rate that the STA is able to transmit.
VHT Extended Indicates whether the STA is capable of If dot11VHTExtendedNSSBWCapable is true,
NSS BW Capable interpreting the Extended NSS BW then this field is set to 1 to indicate that the
Support subfield of the VHT Capabilities STA is capable of interpreting the Extended
Information field. NSS BW Support subfield of the VHT
Capabilities Information field.
Set to 0 otherwise.
1101
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Rx VHT-MCS Map subfield and the Tx VHT-MCS Map subfield have the structure shown in
Figure 9-562.
B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15
Max VHT- Max VHT- Max VHT- Max VHT- Max VHT- Max VHT- Max VHT- Max VHT-
MCS For 1 MCS For 2 MCS For 3 MCS For 4 MCS For 5 MCS For 6 MCS For 7 MCS For 8
SS SS SS SS SS SS SS SS
Bits: 2 2 2 2 2 2 2 2
Figure 9-562—Rx VHT-MCS Map and Tx VHT-MCS Map subfields
and Basic VHT-MCS And NSS Set field
The Max VHT-MCS For n SS subfield (where n = 1, ..., 8) is encoded as follows:
— 0 indicates support for VHT-MCS 0-7 for n spatial streams
— 1 indicates support for VHT-MCS 0-8 for n spatial streams
— 2 indicates support for VHT-MCS 0-9 for n spatial streams
— 3 indicates that n spatial streams is not supported
The value of Max VHT NSS for a given MCS is equal to the smaller of:
— the maximum value of n for which the Max VHT-MCS for n SS has a value that indicates support
for that MAC (0, 1 or 2 for MCS 0-7, 1 or 2 for MCS 8, 2 for MCS 9)
— the maximum supported NSS as indicated by the value of the Rx NSS field of the Operating Mode
Notification frame if the value of RX NSS Type is 0
NOTE—A VHT-MCS indicated as supported in the VHT-MCS Map fields for a particular number of spatial streams
might not be valid at all bandwidths (see 21.5), might be limited by the declaration of Tx Highest Supported Long GI
Data Rates and Rx Highest Supported Long GI Data Rates, and might be affected by 10.7.12.3 and the value of the
Extended NSS BW Support field of the VHT Capabilities Information field in 9.4.2.158.2 and the 160/80+80 BW
subfield of the Operating Mode field in 9.4.1.53.
9.4.2.159 VHT Operation element
The operation of VHT STAs in the BSS is controlled by the HT Operation element and the VHT Operation
element. The format of the VHT Operation element is defined in Figure 9-563.
VHT Operation Basic VHT-MCS
Element ID Length
Information And NSS Set
Octets: 1 1 3 2
Figure 9-563—VHT Operation element format
The Element ID and Length fields are defined in 9.4.2.1.
The structure of the VHT Operation Information field is defined in Figure 9-564.
Channel Center Frequency Channel Center Frequency
Channel Width
Segment 0 Segment 1
Octets: 1 1 1
Figure 9-564—VHT Operation Information field
1102
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The VHT STA gets the primary channel information from the HT Operation element. The subfields of the
VHT Operation Information field are defined in Table 9-252.
Table 9-252—VHT Operation Information subfields
Subfield Definition Encoding
Channel Width This field, together with the HT Set to 0 for 20 MHz or 40 MHz BSS bandwidth.
Operation element STA Channel
Width field, defines the BSS Set to 1 for 80 MHz, 160 MHz or 80+80 MHz BSS
bandwidth (see 11.40.1). bandwidth.
Set to 2 for 160 MHz BSS bandwidth (deprecated).
Set to 3 for non-contiguous 80+80 MHz BSS
bandwidth (deprecated).
Values in the range 4 to 255 are reserved.
Channel Center Defines a channel center frequency For 80 MHz BSS bandwidth, indicates the channel
Frequency Segment for an 80, 160, or 80+80 MHz VHT center frequency index for the 80 MHz channel on
0 BSS. See 21.3.14. which the VHT BSS operates.
For 160 MHz BSS bandwidth and the Channel
Width subfield equal to 1, indicates the channel
center frequency index of the 80 MHz channel
segment that contains the primary channel.
For 160 MHz BSS bandwidth and the Channel
Width subfield equal to 2, indicates the channel
center frequency index of the 160 MHz channel on
which the VHT BSS operates.
For 80+80 MHz BSS bandwidth and the Channel
Width subfield equal to 1 or 3, indicates the
channel center frequency index for the primary 80
MHz channel of the VHT BSS.
Reserved otherwise.
Channel Center Defines a channel center frequency For a 20, 40, or 80 MHz BSS bandwidth, this
Frequency Segment for a 160 or 80+80 MHz VHT BSS. subfield is set to 0.
1 See 21.3.14.
For a 160 MHz BSS bandwidth and the Channel
Width subfield equal to 1, indicates the channel
center frequency index of the 160 MHz channel on
which the VHT BSS operates.
For a 160 MHz BSS bandwidth and the Channel
Width subfield equal to 2, this field is set to 0.
For an 80+80 MHz BSS bandwidth and the
Channel Width subfield equal to 1 or 3, indicates
the channel center frequency index of the
secondary 80 MHz channel of the VHT BSS.
See Table 9-253.
Reserved otherwise.
The Basic VHT-MCS And NSS Set field indicates the VHT-MCSs for each number of spatial streams in
VHT PPDUs that are supported by all VHT STAs in the BSS (including IBSS and MBSS). The Basic VHT-
MCS And NSS Set field is a bitmap of size 16 bits; each 2 bits indicates the supported VHT-MCS set for
NSS from 1 to 8. The Basic VHT-MCS And NSS Set field is defined in Figure 9-562.
1103
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-253—BSS bandwidth when the VHT Operation Information field Channel Width
subfield is 1
Channel Center Frequency
BSS bandwidth
Segment 1 subfield value
CCFS1 = 0 80 MHz or less
CCFS1 > 0 and 160 MHz
| CCFS1 – CCFS0 | = 8 (CCFS0: center frequency of the 80 MHz channel segment
(40 MHz apart) that contains the primary channel)
(CCFS1: center frequency of the 160 MHz channel)
CCFS1 > 0 and 80+80 MHz
| CCFS1 – CCFS0 | > 16 (CCFS0: center frequency of the primary 80 MHz channel)
(> 80 MHz apart) (CCFS1: center frequency of the secondary 80 MHz
channel)
CCFS1 > 0 and Reserved
| CCFS1 – CCFS0 | < 8
(< 40 MHz apart)
CCFS1 > 0 and Reserved
8 < | CCFS1 – CCFS0 | ≤ 16
(> 40 MHz and ≤ 80 MHz apart)
NOTE 1—CCFS0 represents the value of the Channel Center Frequency Segment 0 subfield.
NOTE 2—CCFS1 represents the value of the Channel Center Frequency Segment 1 subfield.
9.4.2.160 Extended BSS Load element
The Extended BSS Load element reported by the AP contains information on MIMO spatial stream
underutilization and bandwidth utilization. The element format is defined in Figure 9-565. A STA receiving
the element might use the information it conveys in an implementation-specific AP selection algorithm.
Observable Observable Observable
MU-MIMO
Element Length Capable STA Spatial Stream Secondary Secondary Secondary
ID Underutilization 20 MHz 40 MHz 80 MHz
Count Utilization Utilization Utilization
Octets: 1 1 2 1 1 1 1
Figure 9-565—Extended BSS Load element format
The Element ID and Length fields are defined in 9.4.2.1.
The MU-MIMO Capable STA Count field indicates the total number of STAs currently associated with this
BSS that have a 1 in the MU Beamformee Capable field of their VHT Capabilities element.
The Spatial Stream Underutilization field is defined as the percentage of time, linearly scaled with 255
representing 100%, that the AP has underutilized spatial domain resources for given busy time of the
medium. The spatial stream underutilization is calculated only for the primary channel. This percentage is
computed using the formula,
N max_SS T busy – T utilized
Spatial Stream Underutilization = ---------------------------------------------------------- 255
N max_SS T busy
1104
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
N max_SS is the maximum number of spatial streams supported by the AP.
T busy is the number of microseconds during which CCA indicated the channel was busy during the
measurement duration. The resolution of the CCA busy measurement is in microseconds.
N
T utilized is N SS i T i , where T i is the time interval, in units of microseconds, during which the pri-
i=1
mary 20 MHz channel is busy due to the transmission of one or more spatial streams by the AP
to MU beamformee capable STAs; NSS,i is the number of spatial streams transmitted during the
time interval T i ; and N is the number of busy events that occurred during the total measure-
ment time which is less than or equal to dot11ChannelUtilizationBeaconIntervals consecutive
beacon intervals.
If T busy is 0, the Spatial Stream Underutilization field is reserved.
The measurement of the observable loading on each of the secondary 20 MHz channel, secondary 40 MHz
channel, and secondary 80 MHz channel in conjunction with the measurement on the primary 20 MHz
channel provides a STA with the loading on the 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz channels.
The Observable Secondary 20 MHz Utilization, Observable Secondary 40 MHz Utilization, and Observable
Secondary 80 MHz Utilization fields are defined using Equation (9-3).
Observable Secondary W1 Utilization = (9-3)
T busy W1
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- 255
dot11ChannelUtilizationBeaconIntervals dot11BeaconPeriod 1024
where
dot11ChannelUtilizationBeaconIntervals represents the number of consecutive beacon intervals during
which the secondary channel busy time is measured.
Tbusy,W1 is computed as the sum of the times from PHY-CCA.indication(BUSY,{W2}) to the next issue
of a PHY-CCA.indication primitive and that overlap the measurement interval, for W1 = 20,
40, or 80, and where W2 equals secondary, secondary40, or secondary80 for W1 = 20, 40, or
80, respectively.
If the AP indicates a channel width of 20 MHz, 40 MHz, or 80 MHz in the STA Channel Width field in the
HT Operation element and in the Channel Width field in the VHT Operation element, then the Observable
Secondary 80 MHz Utilization field is reserved. If the AP indicates a channel width of 20 MHz or 40 MHz
in the STA Channel Width field in the HT Operation element, then the Observable Secondary 40 MHz
Utilization field is reserved. If the AP indicates a channel width of 20 MHz in the STA Channel Width field
in the HT Operation element, then the Observable Secondary 20 MHz Utilization field is reserved.
9.4.2.161 Wide Bandwidth Channel Switch element
The Wide Bandwidth Channel Switch element is included in Channel Switch Announcement frames, as
described in 9.6.2.6, Extended Channel Switch Announcement frames, as described in 9.6.8.7, and TDLS
Channel Switch Request frames, as described in 9.6.13.7. The format of the Wide Bandwidth Channel
Switch element is shown in Figure 9-566.
1105
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
New New
Element New Channel Center Channel Center
Length
ID Channel Width Frequency Frequency
Segment 0 Segment 1
Octets: 1 1 1 1 1
Figure 9-566—Wide Bandwidth Channel Switch element format
The Element ID and Length fields are defined in 9.4.2.1.
The subfields New Channel Width, New Channel Center Frequency Segment 0, and New Channel Center
Frequency Segment 1 have the same definition, respectively, as Channel Width, Channel Center Frequency
Segment 0, and Channel Center Frequency Segment 1 in the VHT Operation Information field, described in
Table 9-252.
9.4.2.162 Transmit Power Envelope element
The Transmit Power Envelope element conveys the local maximum transmit power for various transmission
bandwidths. The format of the Transmit Power Envelope element is shown in Figure 9-567.
Element Transmit Local Maximum Local Maximum Local Maximum Local Maximum
Length Power Transmit Power Transmit Power Transmit Power Transmit Power For
ID Information For 20 MHz For 40 MHz For 80 MHz 160/80+80 MHz
Octets: 1 1 1 1 0 or 1 0 or 1 0 or 1
Figure 9-567—Transmit Power Envelope element format
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Transmit Power Information field is defined in Figure 9-568.
B0 B2 B3 B5 B6 B7
Local Maximum Local Maximum
Transmit Power Transmit Power Reserved
Count Unit Interpretation
Bits: 3 3 2
Figure 9-568—Transmit Power Information field
The Local Maximum Transmit Power Count subfield indicates the number of Local Maximum Transmit
Power For X MHz fields (where X = 20, 40, 80, or 160/80+80) minus 1 in the Transmit Power Envelope
element, as shown in Table 9-254.
1106
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-254—Meaning of Local Maximum Transmit Power Count subfield
Value Field(s) present
0 Local Maximum Transmit Power For 20 MHz.
1 Local Maximum Transmit Power For 20 MHz and
Local Maximum Transmit Power For 40 MHz.
2 Local Maximum Transmit Power For 20 MHz,
Local Maximum Transmit Power For 40 MHz, and
Local Maximum Transmit Power For 80 MHz.
3 Local Maximum Transmit Power For 20 MHz,
Local Maximum Transmit Power For 40 MHz,
Local Maximum Transmit Power For 80 MHz, and
Local Maximum Transmit Power For 160/80+80 MHz.
For TVHT STAs, reserved.
4–7 Reserved
The Local Maximum Transmit Power Unit Interpretation subfield provides additional interpretation for the
units of the Local Maximum Transmit Power For X MHz fields (where X = 20, 40, 80, or 160/80+80) and is
defined in Table 9-255. Allowed values are further constrained as defined in Annex E.
Table 9-255—Definition of Local Maximum Transmit Power Unit Interpretation subfield
Unit interpretation of the
Value
Local Maximum Transmit Power For X MHz fields
0 EIRP
1–7 Reserved
NOTE—This table is expected to be updated only if regulatory domains mandate
the use of transmit power control with limits that cannot be converted into an
EIRP value per transmission bandwidth.
Local Maximum Transmit Power For X MHz fields (where X = 20, 40, 80, or 160/80+80) define the local
maximum transmit power limit of X MHz PPDUs. Each Local Maximum Transmit Power For X MHz field
is encoded as an 8-bit 2s complement signed integer in the range –64 dBm to 63 dBm with a 0.5 dB step.
The value of 63.5 dBm indicates 63.5 dBm or higher (i.e., no local maximum transmit power constraint).
In frames transmitted by a TVHT STA the Local Maximum Transmit Power for 20 MHz field indicates the
Local Maximum Transmit Power for TVHT_W bandwidth; the Local Maximum Transmit Power for 40
MHz field indicates the Local Maximum Transmit Power for TVHT_2W or TVHT_W+W bandwidth; the
Local Maximum Transmit Power for 80 MHz field indicates the Local Maximum Transmit Power for
TVHT_4W or TVHT_2W+2W bandwidth; the Local Maximum Transmit Power for 160/80+80 MHz field
is not included in the Transmit Power Envelope element.
1107
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.163 Channel Switch Wrapper element
The Channel Switch Wrapper element contains subelements that indicate characteristics of the BSS after a
channel switch. The format of the Channel Switch Wrapper element is defined in Figure 9-569. Procedures
related to the inclusion of subelements in the Channel Switch Wrapper element are defined in 11.40.4.
New Country Wide Bandwidth New Transmit
Element Channel Switch Power Envelope
ID Length subelement subelement subelement
(optional)
(optional) (optional)
Octets: 1 1 variable variable variable
Figure 9-569—Channel Switch Wrapper element format
The Element ID and Length fields are defined in 9.4.2.1.
The New Country subelement is present when an AP or mesh STA performs extended channel switching to
a new Country, new Operating Class Table, or a changed set of operating classes relative to the contents of
the Country element sent in the Beacon; otherwise, this subelement is not present. The format of the New
Country subelement is defined to be the same as the format of the Country element (see 9.4.2.9), except that
no Subband Triplet fields are present in the New Country subelement. The Country String field in the New
Country subelement indicates the Country and Operating Class Table of the BSS after extended channel
switching, and Operating Triplet fields within the New Country subelement indicate the operating classes of
the BSS after extended channel switching (see 11.40.1).
The Wide Bandwidth Channel Switch subelement is present under the following conditions:
— Channel switching to a BSS bandwidth of 40 MHz or wider
— Extended channel switching to a BSS bandwidth of 80 MHz or wider
The Wide Bandwidth Channel Switch subelement is optionally present if extended channel switching to a
BSS bandwidth of 40 MHz. The Wide Bandwidth Channel Switch subelement is not present if channel
switching to a 20 MHz BSS bandwidth.
The format of the Wide Bandwidth Channel Switch subelement is the same as the Wide Bandwidth Channel
Switch element (see 9.4.2.161) except for the following:
— A value 0 in the New Channel Width field signifies only a 40 MHz BSS bandwidth.
— When switching to a 40 MHz BSS bandwidth, the New Channel Center Frequency Segment 0 field
indicates the channel center frequency index for the 40 MHz channel after the channel switch.
If present, the Wide Bandwidth Channel Switch subelement indicates the BSS bandwidth after channel
switching (see 11.40.1). For example, when switching to a 40 MHz BSS bandwidth on channel indices 36
and 40, the New Channel Width field is set to 0, and the New Channel Center Frequency Segment 0 field is
set to 38.
Each New Transmit Power Envelope subelement that is present is defined to have the same format as the
Transmit Power Envelope element (see 9.4.2.162) and includes a distinct value of the Local Maximum
Transmit Power Unit Interpretation subfield. Each New Transmit Power Envelope subelement indicates the
local maximum transmit powers for the BSS for the indicated bandwidths with an indicated unit
interpretation after channel switching (see 11.40.1).
1108
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If transmitted by a TVHT STA, the Wide Bandwidth Channel Switch subelement is present when the STA is
switching channels to a BSS bandwidth of TVHT_2W or TVHT_W+W bandwidth or wider; if switching to
a TVHT_W bandwidth BSS bandwidth then this subelement is not present.
9.4.2.164 AID element
The AID element includes the AID assigned by an AP during association that represents the 16-bit ID of a
STA. The format of the AID element is shown in Figure 9-570.
Element Length AID
ID
Octets: 1 1 2
Figure 9-570—AID element format
The Element ID and Length fields are defined in 9.4.2.1.
The AID field is defined in 9.4.1.8.
9.4.2.165 Quiet Channel element
The Quiet Channel element is used to indicate that the secondary 80 MHz channel of a VHT BSS is to be
quieted during a quiet interval, and, in an infrastructure BSS, to indicate if the primary 80 MHz channel of a
VHT BSS can be used during the quiet interval. A quiet interval is established using either a Quiet element
(see 9.4.2.23) or, in an infrastructure BSS, the Quiet Channel element if its AP Quiet Mode field is equal
to 1.
The Quiet Channel element is optionally present in Beacon frames, as described in 9.3.3.3, and Probe
Response frames, as described in 9.3.3.11. The use of Quiet Channel elements is described in 11.9.3.
The format of the Quiet Channel element is shown in Figure 9-571.
Quiet
Element Length AP Quiet Quiet Count Quiet Period Duration Quiet Offset
ID Mode (optional) (optional) (optional)
(optional)
Octets: 1 1 1 0 or 1 0 or 1 0 or 2 0 or 2
Figure 9-571—Quiet Channel element format
The Element ID and Length fields are defined in 9.4.2.1.
The AP Quiet Mode field specifies STA behavior in an infrastructure BSS during the quiet intervals. When
communications to the AP are allowed within the primary 80 MHz channel, then the AP Quiet Mode field is
set to 1. Otherwise, the AP Quiet Mode field is set to 0.
If the AP Quiet Mode field is 1, then the Quiet Count field, Quiet Period field, Quiet Duration field, and
Quiet Offset field are present in the Quiet Channel element; otherwise, these fields are not present in the
Quiet Channel element.
The Quiet Count field, Quiet Period field, Quiet Duration field, and Quiet Offset field have the same
definition as described in 9.4.2.23.
1109
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.166 Operating Mode Notification element
The Operating Mode Notification element is used to notify STAs that the transmitting STA is changing one
or more of its operating channel width, the maximum number of spatial streams it can receive, and its LDPC
receive preference. The format of the Operating Mode Notification element is defined in Figure 9-572.
Element Length Operating
ID Mode
Octets: 1 1 1
Figure 9-572—Operating Mode Notification element
The Element ID and Length fields are defined in 9.4.2.1.
The Operating Mode field is defined in 9.4.1.53.
9.4.2.167 UPSIM element
The UPSIM element is defined as shown in Figure 9-573.
Element ID Length UPSIM Flags Partial Unsched-
uled Power
Save Bitmap
Octets: 1 1 1 0-32
Figure 9-573—UPSIM element format
The Element ID and Length fields are defined in 9.4.2.1.
The Length field for this element is constrained as described below.
The UPSIM Flags field is defined in Figure 9-574.
B0 B1 B2 B3 B7
PS PCP PS Non-PCP Reserved Bitmap Offset
Bits: 1 1 1 5
Figure 9-574—UPSIM Flags field format
The PS PCP field is set to 1 if the PCP is in unscheduled PS mode at the time of UPSIM element
transmission and is set to 0 otherwise. The PS PCP field is set to 0 in infrastructure BSS. The PS Non-PCP
field is set to 1 if all non-AP and non-PCP STAs are in unscheduled PS mode at the time of UPSIM element
transmission and is set to 0 otherwise. The Bitmap Offset field defines the octet offset into a virtual bitmap
maintained by the AP or PCP, as described below.
The AP or PCP maintains an unscheduled power save indication virtual bitmap that is 256 bits in length and
is organized into 32 octets such that bit number N ( 0 N 255 ) in the bitmap corresponds to bit number (N
mod 8) in octet number N / 8 , where the low order bit of each octet is bit number 0, and the high order bit
is bit number 7. Bit N in the bitmap is set to 1 if there is an associated DMG STA with AID equal to N and
the STA is in unscheduled PS mode and is set to 0 if there is no associated DMG STA with AID equal to N
or the STA is not in unscheduled PS mode. Bit 0 is set to 0 in the infrastructure BSS. Bit 255 is set to 0.
1110
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Partial Unscheduled Power Save Bitmap field is not present when bits numbered 1 to 254 of the
unscheduled power save indication virtual bitmap all have the same value at the time of UPSIM element
transmission. In this case, the Length field is set to 1 and the Bitmap Offset field is set to 0.
When there are two bits in the unscheduled power save indication virtual bitmap with numbers between 1
and 254 and different values, the Partial Unscheduled Power Save Bitmap field consists of octets numbered
N1 to N2 of the unscheduled power save indication virtual bitmap, where N1 is the largest integer such that
bits numbered 1 to (N1× 8) - 1 in the unscheduled power save indication virtual bitmap are all 0, and N2 is
the smallest number such that bits numbered (N2 + 1) × 8 to 255 in the unscheduled power save indication
virtual bitmap are all 0. In this case, the Length field is set to (N2 - N1) + 2 and the Bitmap Offset subfield is
set to N1.
NOTE—The Partial Unscheduled Power Save Bitmap field does not need to include bit 0 of the unscheduled power save
indication virtual bitmap even if that bit is set.
9.4.2.168 Fine Timing Measurement Parameters element
The Fine Timing Measurement Parameters element contains a number of fields that are used to advertise the
requested or allocated FTM configuration from one STA to another. The Fine Timing Measurement
Parameters element is included in the initial Fine Timing Measurement Request frame, as described in
9.6.8.32, and the initial Fine Timing Measurement frame, as described in 9.6.8.33. The use of the Fine
Timing Measurement Parameters element is described in 11.24.6.
The format of the Fine Timing Measurement Parameters element is shown in 9-575.
Element ID Length Fine Timing Measurement
Parameters
Octets: 1 1 9
Figure 9-575—Fine Timing Measurement Parameters element format
The format of the Fine Timing Measurement Parameters field is shown in 9-576.
B0 B1 B2 B6 B7 B8 B11 B12 B15 B16 B23 B24 B39
Status Value Reserved Number of Burst Min Delta Partial
Indication Bursts Duration FTM TSF Timer
Exponent
Bits: 2 5 1 4 4 8 16
B40 B41 B42 B43 B47 B48 B49 B50 B55 B56 B71
Partial TSF ASAP Capable ASAP FTMs per Reserved Format And Burst
Timer No Burst Bandwidth Period
Preference
Bits: 1 1 1 5 2 6 16
Figure 9-576—Fine Timing Measurement Parameters field format
The Element ID and Length fields are defined in 9.4.2.1.
The Status Indication field indicates the responding STA’s response to the Fine Timing Request. The
encoding of the Status Indication field is shown in Table 9-256.
1111
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-256—Status Indication field values
Value Description
0 Reserved
1 Successful (some requested parameters might have been overridden).
Measurement exchanges are about to begin.
2 Request incapable. Do not send same request again. FTM session ends.
3 Request failed. Do not send new request for Value seconds. FTM session ends.
The Status Indication field and Value field are reserved in the initial Fine Timing Measurement Request
frame. When the Status Indication field is set to 3 by the responding STA, the Value field contains a duration
in units of seconds; otherwise the Value field is reserved.
The Number of Bursts Exponent field indicates how many burst instances, defined in 11.24.6.4, are
requested for the FTM session if included in an initial Fine Timing Measurement Request frame, or
allocated for the FTM session if included in an initial Fine Timing Measurement frame respectively, where
the number of burst instances is 2Number of Bursts Exponent. The value 15 in an initial Fine Timing
Measurement Request frame indicates no preference by the initiating STA and is valid (indicating 215 burst
instances) when set by the responding STA.
The Burst Duration field indicates the duration of a burst instance. The value 15 in the initial Fine Timing
Measurement Request indicates no preference by the initiating STA and is not used by the responding STA.
Table 9-257 shows the encoding of this field.
Table 9-257—Burst Duration field encoding
Value Represents
0-1 Reserved
2 250 µs
3 500 µs
4 1 ms
5 2 ms
6 4 ms
7 8 ms
8 16 ms
9 32 ms
10 64 ms
11 128 ms
12–14 Reserved
15 No preference
The Min Delta FTM field indicates the minimum time between consecutive Fine Timing Measurement
frames. It is measured from the start of a Fine Timing Measurement frame to the start of following Fine
1112
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Timing Measurement frame, in units of 100 µs. The value 0 indicates no preference by the initiating STA
and is not used by the responding STA.
The Partial TSF Timer field in an initial Fine Timing Measurement frame indicates the partial value of the
responding STA’s TSF timer at the start of the first burst instance of an FTM session. The responding STA’s
TSF timer at the start of the first burst instance of an FTM session is limited to less than 62/64 of 65 536 TUs
(<63 488 TUs) ahead of the TSF time at which the STA transmits the Fine Timing Measurement frame and
1/64 of 65 536 TUs earlier (inclusive) (≥1024 TUs) than the TSF time at which the STA transmits the Fine
Timing Measurement frame, as shown in Figure 9-577. The Partial TSF Timer value is derived as follows,
so as to have units of TUs: from the 64 TSF timer bits at the start of the first burst instance of an FTM
session, where the 10 least significant bits equal 0, remove the most significant 38 bits and the least
significant 10 bits.
NOTE—1024 TUs out of the full range of the Partial TSF Timer field are not used in order to allow the recipient to
resolve ambiguity arising from 1) imperfect synchronization between the initiating and responding STAs, and 2) retries
of the initial Fine Timing Measurement Request frame or retransmissions of the initial Fine Timing Measurement frame.
The initiating STA indicates a preferred time for the start of the first burst instance by setting the Partial TSF
Timer No Preference field to 0 and by setting the Partial TSF Timer field to indicate the preferred start of the
first burst instance. Otherwise the Partial TSF Timer No Preference field is set to 1 and the Partial TSF
Timer field is reserved. The Partial TSF Timer No Preference field is reserved when the FTM Parameters
element is included in an initial Fine Timing Measurement frame.
Unused Earlier Ahead
(Indicated TSF[10:25] -
TSF[10:25]) mod 65536
63488 64511 64512 65535 0 63487
Partial TSF indicated in
a) Initial FTM Request frame with ASAP=0 or 1, or
b) Initial FTM frame with ASAP=0
Partial TSF indicated in initial FTM frame with
ASAP=1
Figure 9-577—Calculation of Partial TSF Timer field
The ASAP Capable field indicates that the responding STA is capable of sending a Fine Timing
Measurement frame as soon as possible; that is, the STA is capable of capturing timestamps associated with
an initial Fine Timing Measurement frame and sending them in the following Fine Timing Measurement
frame. This field is reserved in the initial Fine Timing Measurement Request frame.
The ASAP field indicates the initiating STA’s request to start the first burst instance of the FTM session as
soon as possible. When the ASAP field is set to 0 and the Partial TSF Timer No Preference field is set to 0
by an initiating STA, the initiating STA requests the start of the first burst instance specified by the Partial
TSF Timer field in the initial Fine Timing Measurement Request frame. When the ASAP field is set to 1 and
the Partial TSF Timer No Preference field is set to 0 by an initiating STA, the Partial TSF Timer field in the
Fine Timing Measurement Request frame indicates the requested start of the first burst instance if the ASAP
field is set to 0 in the initial Fine Timing Measurement frame. The ASAP field is also used by the responding
STA to signal whether that request has been honored or not. When the ASAP field is set to 0 by the
responding STA, the Partial TSF Timer field in the initial Fine Timing Measurement frame indicates the
start time of the first burst instance and the earliest time the Fine Timing Measurement Request frame (see
11.24.6.4) should be sent by the initiating STA. When the ASAP field is set to 1 by the responding STA, the
Partial TSF Timer field in the initial Fine Timing Measurement frame indicates the start time of the first
burst instance and the earliest time the initial Fine Timing Measurement frame will be sent. The responding
1113
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA sets the ASAP field to 1 to indicate the STA’s intent to send a Fine Timing Measurement frame as soon
as possible.
The FTMs per Burst field indicates how many successfully transmitted Fine Timing Measurement frames
are requested per burst instance by the initial Fine Timing Measurement Request frame, or allocated by the
initial Fine Timing Measurement frame, respectively. The value 0 indicates no preference by the initiating
STA and is not used by the responding STA.
The Format And Bandwidth field indicates the requested or allocated PPDU format and bandwidth that can
be used by Fine Timing Measurement frames in an FTM session and is shown in Table 9-258. The value 0
indicates no preference by the initiating STA in the associated state and is not used by the responding
STA.The value 0 is not used by the initiating STA in the unassociated state.
Table 9-258— Format And Bandwidth field
Field value Format Bandwidth (MHz)
0 No preference No preference
1-3 Reserved Reserved
4 Non-HT 5
5 Reserved Reserved
6 Non-HT 10
7 Reserved Reserved
8 Non-HT, 20
excluding
Clause 15 and
Clause 16
9 HT mixed 20
10 VHT 20
11 HT mixed 40
12 VHT 40
13 VHT 80
14 VHT 80+80
15 VHT (two 160
separate RF LOs)
16 VHT (single RF 160
LO)
17-30 Reserved Reserved
31 DMG 2160
32–63 Reserved Reserved
NOTE—See 21.3.17.3 regarding the usage of two separate RF LOs.
1114
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Burst Period field indicates the interval between two consecutive burst instances, in units of 100 ms.
The value 0 indicates no preference by the initiating STA. This field is reserved when the Number of Bursts
Exponent field is set to 0.
9.4.2.169 Device Location element
A Device Location element includes the location configuration information (LCI), which contains latitude,
longitude, and altitude information. The Device Location element format is shown in Figure 9-578.
Element ID Length Device Location Information
Body
Octets 1 1 16
Figure 9-578—Device Location element format
The Element ID and Length fields are defined in 9.4.2.1.
The format of the Device Location Information Body is defined in 9.4.1.56.
9.4.2.170 White Space Map element
The White Space Map element includes available radio frequency information obtained from a GDB. The
format of the WSM Information field is determined by the value of the WSM Type field. The format of the
White Space Map Announcement element is shown in Figure 9-579.
Element ID Length WSM Type WSM Information
Octets: 1 1 1 variable
Figure 9-579—WSM element format
The Element ID and Length fields are defined in 9.4.2.1.
The format and values of WSM Type and WSM Information fields are defined in 9.4.1.57.
9.4.2.171 Reduced Neighbor Report element
The Reduced Neighbor Report element contains channel and other information related to neighbor APs. The
format of the Reduced Neighbor Report element is shown in Figure 9-580.
Element ID Length Neighbor AP
Information
Fields
Octets: 1 1 variable
Figure 9-580—Reduced Neighbor Report element format
The Element ID and Length fields are defined in 9.4.2.1.
The Neighbor AP Information Fields field contains one or more of the Neighbor AP Information field
described in 9.4.2.171.1.
1115
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.2.171.1 Neighbor AP Information field
The Neighbor AP Information field specifies TBTT and other information related to a group of neighbor
APs on one channel. See Figure 9-581.
TBTT Infor- Operating Channel TBTT Infor-
mation Class Number mation Set
Header
Octets: 2 1 1 variable
Figure 9-581—Neighbor AP Information field format
The format of TBTT Information Header subfield is defined in Figure 9-582.
B0 B1 B2 B3 B4 B7 B8 B15
TBTT Filtered Reserved TBTT TBTT
Information Neighbor AP Information Information
Field Type Count Length
Bits: 2 1 1 4 8
Figure 9-582—TBTT Information Header subfield
The TBTT Information Field Type subfield is 2 bits in length and defines the structure of the TBTT
Information field. Its value is 0. Values 1, 2, and 3 are reserved.
The Filtered Neighbor AP subfield is 1 bit in length. It is set to 1 if the SSID of APs in this Neighbor AP
Information field matches the specific SSID in the Probe Request frame. It is set to 0 otherwise. This field is
valid only in the Reduced Neighbor Report element in a Probe Response frame and is reserved otherwise.
The TBTT Information Count subfield is 4 bits in length and contains the number of TBTT Information
fields that are included in the Neighbor AP Information field, minus one. A value of 0 indicates one TBTT
Information field is present.
The TBTT Information Length subfield is 1 octet in length and contains the length in octets of each TBTT
Information field that is included in the Neighbor AP Information field.
The Operating Class field is 1 octet in length and indicates a channel starting frequency that, together with
the Channel Number field, indicates the primary channel of the BSSs of the APs in this Neighbor AP
Information field. Values of Operating Class are shown in Table E-4, of which operating classes that,
together with the channel number, indicate the primary channel is valid (see 11.44.8).
NOTE—The Operating Class field and Channel Number tuple indicate the primary channel in order to assist with
passive scanning.
The Channel Number field is 1 octet in length and indicates the last known primary channel of the APs in
this Neighbor AP Information field. Channel Number is defined within an Operating Class as shown in
Table E-4.
The TBTT Information Set field contains one or more TBTT Information fields. The TBTT Information
field is defined in Figure 9-583.
1116
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Neighbor AP
TBTT Offset
Octets: 1
Figure 9-583—TBTT Information field
The Neighbor AP TBTT Offset subfield is 1 octet in length and indicates the offset in TUs, rounded down to
nearest TU, to the next TBTT of an AP from the immediately prior TBTT of the AP that transmits this
element. The value 254 indicates an offset of 254 TUs or higher. The value 255 indicates an unknown offset
value.
9.4.2.172 TVHT Operation element
The operation of TVHT STAs in the BSS is controlled by the TVHT Operation element. The format of the
TVHT Operation element is defined in Figure 9-584.
Element ID Length TVHT Operation Basic VHT-MCS
Information And NSS Set
Octets: 1 1 4 2
Figure 9-584—TVHT Operation element format
The Element ID and Length fields are defined in 9.4.2.1.
The structure of the TVHT Operation Information field is defined in Figure 9-585.
Primary Channel Width Channel Center Channel Center
Channel Frequency Seg- Frequency Seg-
Number ment0 ment1
Octets: 1 1 1 1
Figure 9-585—TVHT Operation Information field
The subfields of the TVHT Operation Information field are defined in Table 9-259.
Table 9-259—TVHT Operation Information subfields
Field Definition Encoding
Primary Indicates the channel number Channel number of the primary channel.
Channel of the primary channel (see
Number 11.43).
Channel This field defines the BSS Set to 0 for TVHT_W BSS bandwidth.
Width bandwidth (see 11.43). Set to 1 for TVHT_2W BSS bandwidth.
Set to 2 for TVHT_W+W BSS bandwidth.
Set to 3 for TVHT_4W BSS bandwidth.
Set to 4 for non-contiguous TVHT_2W+2W BSS bandwidth.
Values in the range 5 to 255 are reserved.
1117
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-259—TVHT Operation Information subfields (continued)
Field Definition Encoding
Channel Defines the channel center For TVHT_W or TVHT_2W or TVHT_4W BSS bandwidth,
Center frequency for a TVHT_W, indicates the center frequency of the lowest TV channel index
Frequency TVHT_2W, and TVHT_4W for the TVHT_W or TVHT_2W or TVHT_4W channel on
Segment0 TVHT BSS and the segment which the TVHT BSS operates.
0 channel center frequency For TVHT_W+W or TVHT_2W+2W BSS bandwidth, indicates
for a TVHT_W+W and the lowest TV channel index for the TVHT_W or TVHT_2W
TVHT_2W+2W TVHT BSS. channel of frequency segment 0 on which the TVHT BSS
See 22.3.14. operates.
Reserved otherwise.
Channel Defines the segment 1 For TVHT_W+W or TVHT_2W+2W BSS bandwidth, indicates
Center channel center frequency for the lowest TV channel index in the segment for the TVHT_W or
Frequency a TVHT_W+W and TVHT_2W channel of frequency segment 1 on which the TVHT
Segment1 TVHT_2W+2W TVHT BSS. BSS operates.
See 22.3.14. Reserved otherwise.
The Basic VHT-MCS And NSS Set field indicates the MCSs for each spatial stream in VHT PPDU in
TVWS bands that are supported by all TVHT STAs in the BSS (including IBSS). The Basic VHT-MCS And
NSS Set field is a bitmap of size 16 bits; B8-B9, B10-B11, B12-B13, and B14-B15 are set to 3. For B0-B7,
each 2 bits indicates the supported MCS set for N SS from 1 to 4. The Basic VHT-MCS And NSS Set field is
defined as B0-B7 of Rx VHT-MCS Map subfield in 9.4.2.158.3.
9.4.2.173 FTM Synchronization Information element
The format of the FTM Synchronization Information element is defined in Figure 9-586.
Element ID Length Element ID TSF Sync Info
Extension
Octets: 1 1 1 4
Figure 9-586—FTM Synchronization Information element format
The Element ID, Length and Element ID Extension fields are defined in 9.4.2.1.
The TSF Sync Info field is set to the 4 least significant octets of the value of TSF.
9.4.2.174 Estimated service parameters element
The Estimated Service Parameters element is used by a STA to provide information to another STA which
can then use the information as input to an algorithm to generate an estimate of throughput between the two
STAs.
The format of the Estimated Service Parameters element is shown in Figure 9-587.
Element ID ESP Information
Element ID Length Extension List
Octets: 1 1 1 variable
Figure 9-587—Estimated Service Parameters element format
1118
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1.
The ESP Information List field contains from 1 to 4 ESP Information fields, each corresponding to an access
category for which estimated service parameters information is provided.
The format of the ESP Information field is shown in Figure 9-588.
B0 B1 B2 B3 B4 B5 B7 B8 B15 B16 B23
Access Estimated Air Data PPDU
Category Reserved Data Format BA Window Size Time Fraction Duration Target
Bits: 2 1 2 3 8 8
Figure 9-588—ESP Information field format
The Access Category subfield is two bits in length and indicates the access category to which the remaining
parameters of the ESP Information field apply. The encoding of the Access Category subfield is given in
Table 9-260. When parameters for more than one access category are present in an Estimated Service
Parameters element the ESP Information fields for the access categories appear in order of Access Category
subfield value, with the ESP Information field with the lowest Access Category subfield value appearing
first.
Table 9-260—Access Category subfield encoding
Access
Value
Category
0 AC_BK
1 AC_BE
2 AC_VI
3 AC_VO
The Data format subfield is two bits in length and has the meaning indicated in Table 9-261.
Table 9-261—Data Format subfield encoding
Value Description
0 No aggregation is expected to be performed for MSDUs or MPDUs with the
Type subfield equal to Data for the corresponding AC
1 A-MSDU aggregation is expected to be performed for MSDUs for the
corresponding AC, but A-MPDU aggregation is not expected to be performed
for MPDUs with the Type subfield equal to Data for the corresponding AC
2 A-MPDU aggregation is expected to be performed for MPDUs with the Type
subfield equal to Data for the corresponding AC, but A-MSDU aggregation is
not expected to be performed for MSDUs for the corresponding AC
3 A-MSDU aggregation is expected to be performed for MSDUs for the
corresponding AC and A-MPDU aggregation is expected to be performed for
MPDUs with the Type subfield equal to Data for the corresponding AC
1119
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The BA Window Size subfield is three bits in length and indicates the size of the Block Ack window that is
expected for the corresponding access category as defined in Table 9-262. When the Block Ack window size
expected to be used by the transmitter of the element does not match any of the values shown in the table,
the transmitter uses the next lower value in the table.
Table 9-262—BA Window Size subfield encoding
Value Expected block ack window size
0 Block Ack not expected to be used
1 2
2 4
3 6
4 8
5 16
6 32
7 64
The Estimated Air Time Fraction subfield is 8 bits in length and contains an unsigned integer that represents
the predicted percentage of time, linearly scaled with 255 representing 100%, that a new STA joining the
BSS will be allocated for PPDUs that contain only MPDUs with the Type subfield equal to Data of the
corresponding access category for that STA.
The Data PPDU Duration Target field is 8 bits in length and is an unsigned integer that indicates the
expected target duration of PPDUs that contain only MPDUs with the Type subfield equal to Data for the
corresponding access category in units of 50 µs.
9.4.2.175 Future Channel Guidance element
Future Channel Guidance element is used by an AP, IBSS STA, mesh STA, or PCP to guide STAs about the
likely future channel if the sending STA changes channels of operation. The format of the Future Channel
Guidance element is shown in Figure 9-589.
Element Length Element New Second- Mesh Wide New
ID ID Exten- Channel ary Chan- Channel Band- Transmit
sion Number nel Offset Switch width Power
element Parame- Channel Envelope
ters ele- Switch element
ment element
Octets: 1 1 1 4 0 or 3 0 or 6 0 or 5 variable
Figure 9-589—Future Channel Guidance element format
The Element ID, Length and Element ID Extension fields are defined in 9.4.2.1.
The New Channel Number field is set to the number of the channel to which the STA will be moving in the
event of a channel switch (as defined in 17.3.8.4.3).
1120
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Secondary Channel Offset element is defined in 9.4.2.20. This element is present when switching to a
40 MHz or wider channel. It is optionally present when switching to a 20 MHz channel (in which case the
Secondary Channel Offset field is set to SCN). See 11.40.4.
The Mesh Channel Switch Parameters element is defined in 9.4.2.103. This element is present when a mesh
STA performs MBSS channel switch. Otherwise, the Mesh Channel Switch Parameters element is not
present.
The Wide Bandwidth Channel Switch element is defined in 9.4.2.161. This element is present when
switching to a channel width wider than 40 MHz.
Each New Transmit Power Envelope element that is present is defined to have the same format as the
Transmit Power Envelope element (see 9.4.2.162 and includes a distinct value of the Local Maximum
Transmit Power Unit Interpretation subfield. If present, the New Transmit Power Envelope element
indicates the local maximum transmit powers for the BSS for the BSS for the indicated bandwidths with an
indicated unit interpretation after channel switching (see 11.40.1).
The Future Channel Guidance procedure is defined in 11.9.10.
9.4.3 Subelements
Subelements are defined to have a common general format consisting of a 1-octet element-specific
Subelement ID field, a 1-octet Length field, and a variable-length subelement-specific Data field. Each
subelement is assigned a subelement ID that is unique within the containing element or subelement. The
Length field specifies the number of octets in the Data field. See Figure 9-590.
Subelement ID Length Data
Octets: 1 1 variable
Figure 9-590—Subelement format
At the location in this standard that a subelement is defined, the definition might indicate if the subelement is
extensible, typically using a table column called “Extensible” in the table in which subelement IDs are
defined. A subelement that is indicated as extensible (typically with “Yes” in the “Extensible” column)
might be extended in future revisions or amendments of this standard. A subelement that is indicated as
extensible through subelements (typically with “Subelements” in the “Extensible” column) might be
extended in future revisions or amendments of this standard by defining (additional) subelements within the
subelement.
If the definition of a subelement does not indicate whether it is extensible (e.g., there is no “Extensible”
column in a table defining it) that subelement is not extensible.
A subelement that is not defined as extensible will not be extended in future revisions or amendments of this
standard.
Subelements within an element are ordered by nondecreasing Subelement ID. See 10.27.9.
1121
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.4 TLV encodings
9.4.4.1 General
The following TLV encodings are used to convey parameters within MAC Management frames (9.3.3, 9.4,
and 9.6). TLV tuples with type values that are unknown, not specified in this subclause, or specified as
“reserved” are discarded upon receipt. The form of TLVs is shown in Table 9-263.
Table 9-263—General TLV format
Length Scope/
Name Type Value
(octets) Country code
The name of the 1 variable Single Octet, Single Value, or Compound TLV
TLV tuples.
NOTE—This standard is complete regarding the endianness of multi-octet fields as they are covered by 9.2.2. Be aware
that most protocols above the MAC operate in the opposite endianness.
Name is the name of the TLV tuple.
The ‘m.n’ syntax in the Type field means that the TLV has type n, an unsigned 1-octet integer, and is
embedded in the Value field of a TLV of type m. The length of the Type field is 1 octet.
The format of the Length field is an unsigned number of size 1 octet, and the value in the Length field
specifies the number of octets in the Value field.
A single octet TLV has a Value field that is a single octet, a single value TLV has a Value field larger than 1-
octet, and a compound TLV has a Value field that represents more than 1-octet fields.
When a Scope field entry contains two characters, it identifies the country or other entity to which the STA’s
operation is bound. If the two-character value stands for a country or other entity, then the value matches a
code defined in ISO 3166-1. When a Scope field entry contains more than two characters, it identifies a
scope for the TLV tuple.
9.4.4.2 Common TLVs
The general form of common TLVs is shown in Table 9-263 and is used in 9.4.4.2.1 to 9.4.4.2.5.
9.4.4.2.1 Device Class
This parameter contains the intended class of device for operation in TVWS band after it receives the
available channel list at its location. The Device Class field format is shown in Table 9-264.
1122
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-264—Device Class field definition
Length Scope/
Name Type Value
(octets) Country code
Device Class 2 1 The Device Class field contains an integer that CAQ,
indicates the device’s TVWS band mode of GDDENABLE
operation as follows: MENT, WSM
0: GDD non-AP STA
1: GDD geolocated non-AP STA
2: GDD AP
3: GDD fixed STA
4–255: Reserved
9.4.4.2.2 Device Identification Information
This parameter contains the identification information of the device initiating the channel availability query.
The Device Identification Information field format is shown in Table 9-265 and related Device Identification
Information Value fields tables in E.2 for specific regulatory domains.
Table 9-265—Device Identification Information field definition
Length Scope/
Name Type Value
(octets) Country code
Device 3 variable One or more TLV fields as defined in Table E-8 for a CAQ,
Identification specific regulatory domain. GDDENABLE
Information MENT, CSM
9.4.4.2.3 Device Location Information
This parameter contains the location information of the device initiating the channel availability query. The
Device Location Information field format is shown in Table 9-266.
Table 9-266—Device Location Information field definition
Length Scope/
Name Type Value
(octets) Country code
Device Location 10 16 The Device Location Information field contains the CAQ
Information latitude, longitude, and altitude information of the
device in the format specified by the Device
Location Information Body fields in Figure 9-121.
When the Device Type subfield (see Table 9-264) is
not GDD fixed STA, the altitude information
(Altitude Type, Altitude Uncertainty, and Altitude
subfields) of the Device Location Information field
remain unused.
1123
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.4.2.4 Channel Schedule Descriptor
This parameter contains the channel number associated with channel schedule information used for channel
schedule management. The Channel Schedule Descriptor Tuple attribute format is shown in Table 9-267 and
Table 9-268. Channel Schedule Descriptor field is constructed with either Channel Availability Starting
Time field or Channel Availability Starting Timestamp field present or neither of these two fields present.
Table 9-267—Channel Schedule Descriptor Tuple attribute definition
Length Scope/
Name Type Value
(octets) Country code
Channel 11 variable Compound TLVs in Table 9-268. CSM
Schedule
Descriptor
Table 9-268—Channel Schedule Descriptor Value fields
Length Scope/
Name Subtype Value
(octets) Country code
Operating Class 1 1 The Operating Class field is the number of the CSM
operating class of the channel, which is defined in
E.1.
Channel Number 2 1 The Channel Number field is the number of the CSM
channel, which is the subject of the value of Channel
Schedule Management Mode field. If the Channel
Schedule Management Mode field indicates the
schedule information is based on WLAN channels,
the Channel Number is a channel from the STA’s
operating class as defined in E.1; otherwise, the
Operating Class compound TLV is not present, and
the Channel Number is a positive integer value as
defined in D.1 to indicate the available TV channel
for WLAN operation.
Channel 3 8 The Channel Availability Starting Time field CSM
Availability indicates the starting time in Coordinated Universal
Starting Time Time (UTC) from when the channel indicated in the
Channel Number field is available for operation.
When neither this field nor a Channel Availability
Starting Timestamp is present, the STA takes the
time that the response element is received as the
starting time of the channel availability.
NOTE—The Channel Availability Starting Time
field follows the UTC time definition of the Time
Value field of the Time Advertisement element in
9.4.2.61, and the first 6 octets are used to indicate the
UTC time until minutes. The left 2 octets are
reserved.
1124
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-268—Channel Schedule Descriptor Value fields (continued)
Length Scope/
Name Subtype Value
(octets) Country code
Channel 4 8 The Channel Availability Starting Timestamp field CSM
Availability indicates the starting timestamp from when the
Starting channel indicated in the Channel Number field is
Timestamp available for operation. When neither this field nor a
Channel Availability Starting Time field is present,
the STA takes the time that the response element is
received as the starting time of the channel
availability.
Channel 5 2 The Channel Availability Offset Time field indicates CSM
Availability the offset of channel availability time with respect to
Offset Time the time that the Channel Schedule Descriptor is
received. This field is present when the Channel
Availability Starting Time field is not present in the
response TLV and the channel is not available at the
moment the TLV is received.
Channel 6 2 The Channel Availability Duration field indicates the CSM
Availability duration in minutes of the availability of the channel
Duration that indicated in the Channel Number field.
9.4.4.2.5 WSM information values
The format of the WSM information values is shown in Table 9-269. If the value of WSM Type field of the
White Space Map element (9.4.1.57) is 1, the WSM Information field specifies available channel
information for TVWS, which is country-specific.
Table 9-269—WSM information values
Length Scope/
Name Type Value
(octets) Country code
WSM 12 variable Single value TLV comprising fields in related table WSM
Information in E.2 for a specific regulatory domain.
1125
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The format of the WSM Information Value fields is shown in Table 9-270.
Table 9-270—WSM Information Value fields
Length Scope/
Name Value
(octets) Country code
Device Class 1 Single octet TLV comprising fields in Table 9-264. WSM
Map ID 1 Bit 0: Type bit indicates whether the following channel list is a WSM
full channel list or a partial channel list. If the Type bit is 1, the
following channel list is a full channel list; and if the Type bit is
0, the following channel list is a partial channel list.
Bits 1–7: Map version identifies the version of the WSM.
Channel Number 1 Channel Number field in related WSM Information Value fields WSM
table in E.2.
Maximum Power 1 Maximum Power Level field in related WSM Information Value WSM
Level fields table in E.2.
Validity 1 The Validity field indicates the time duration in minutes for WSM, UK
which the Channel Number is available with the allowed
maximum power level, where the Validity field is provided for
each available Channel Number.
Maximum 2 Limits on the maximum contiguous and maximum WSM, UK
Channel noncontiguous instantaneous bandwidths of STA specified as
Bandwidth n × 0.1 MHz, where n > 0.
The Device Class field is defined in 9.4.4.2.1 and identifies the device class used by the WSM. It determines
the length of the channel availability tuple consisting of the Channel Number, Maximum Power Level, and
Validity fields, which is repeated as indicated by the Length field of the WSM element. If the Device Class
field is 0, the Validity field in WSM Information Value field is not present. Otherwise, the Validity field
exists in the WSM Information Value field.
1126
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.5 Access network query protocol (ANQP) elements
9.4.5.1 General
ANQP-elements are defined to have a common format consisting of a 2-octet Info ID field (information
identifier), a 2-octet Length field, and a variable-length ANQP-element-specific Information field. Each
element is assigned a unique Info ID as defined in this standard. The ANQP-element format is shown in
Figure 9-591. See R.2 for informative text on ANQP usage.
Info ID Length Information
Octets: 2 2 variable
Figure 9-591—ANQP-element format
Each ANQP-element in 9.4.5 is assigned a unique 2-octet Info ID. The set of valid Info IDs are defined in
Table 9-271. The 2-octet Info ID field is encoded following the conventions given in 9.2.2.
Table 9-271—ANQP-element definitions
ANQP-element
ANQP-element name InfoID
(subclause)
Reserved 0–255 n/a
Query List 256 9.4.5.2
Capability List 257 9.4.5.3
Venue Name 258 9.4.5.4
Emergency Call Number 259 9.4.5.5
Network Authentication Type 260 9.4.5.6
Roaming Consortium 261 9.4.5.7
IP Address Type Availability 262 9.4.5.9
NAI Realm 263 9.4.5.10
3GPP Cellular Network 264 9.4.5.11
AP Geospatial Location 265 9.4.5.12
AP Civic Location 266 9.4.5.13
AP Location Public Identifier URI/FQDN 267 9.4.5.14
Domain Name 268 9.4.5.15
Emergency Alert Identifier URI 269 9.4.5.16
TDLS Capability 270 9.4.5.18
Emergency NAI 271 9.4.5.17
Neighbor Report 272 9.4.5.19
Venue URL 277 9.4.5.20
Advice of Charge 278 9.4.5.21
Local Content 279 9.4.5.22
Network Authentication Type with Timestamp 280 9.4.5.23
1127
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-271—ANQP-element definitions (continued)
ANQP-element
ANQP-element name InfoID
(subclause)
Reserved 273–276, n/a
281– 56 796
Vendor Specific 56 797 9.4.5.8
Reserved 56798–65 535 n/a
The Length field specifies the number of octets in the Information field and is encoded following the
conventions given in 9.2.2.
The ANQP-elements that can be configured are shown in Table 9-271. If information is not configured for a
particular ANQP-element, then a query for that element will return that element with all optional fields not
present.
9.4.5.2 Query List ANQP-element
The Query List ANQP-element provides a list of identifiers of ANQP-elements for which the requesting
STA is querying; see 11.25.3.3.2.
The format of the Query List ANQP-element is provided in Figure 9-592.
Info ID Length ANQP
Query IDs
Octets: 2 2 2
Figure 9-592—Query List ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The ANQP Query IDs field contains one or more 2-octet ANQP Query ID subfields.
Each ANQP Query ID subfield value is an Info ID drawn from Table 9-271. Including an Info ID in the
Query List ANQP-element declares that the STA performing the ANQP request is requesting the ANQP-
element corresponding to that Info ID be returned in the ANQP response. The Info IDs included in the
Query List ANQP-element are ordered by monotonically increasing Info ID value. The ANQP response is
defined in 11.25.3.3.1.
9.4.5.3 Capability List ANQP-element
The Capability List ANQP-element provides a list of information/capabilities that has been configured on a
STA. The Capability List ANQP-element is returned in response to a Query List ANQP-element containing
the Info ID of the Capability List ANQP-element.
The format of the Capability List ANQP-element is provided in Figure 9-593.
1128
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ANQP Vendor Specific
Info ID Length Capabilities ANQP-elements
Octets: 2 2 variable variable
Figure 9-593—Capability List ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The ANQP Capabilities field contains one or more 2-octet ANQP Capability subfields.
Each ANQP Capability subfield value is an Info ID drawn from Table 9-271. If included in the Capability
List ANQP-element, it declares that a Query List ANQP-element including that Info ID will return the
requested ANQP-element. The Info ID for Capability List ANQP-element is always included in the
Capability List ANQP-element returned in a GAS Query Response. The list does not include any duplicate
Info IDs, except possibly the Info ID for each Vendor Specific ANQP-element. The Info IDs returned in the
Capability List ANQP-element are ordered by nondecreasing Info ID value.
The Vendor Specific ANQP-elements field contains one or more variable length Vendor Specific ANQP-
elements.
The Vendor Specific ANQP-element is defined in 9.4.5.8. The Vendor Specific ANQP-element is structured
such that the first 2 octets of the Vendor Specific ANQP-element is the Info ID whose value corresponds to
the Vendor Specific ANQP-element (see Table 9-271). When a Vendor Specific ANQP-element is present
in the Capability List ANQP-element, the Vendor Specific ANQP-element contains the capabilities of that
vendor-specific query protocol.
9.4.5.4 Venue Name ANQP-element
The Venue Name ANQP-element provides zero or more venue names associated with the BSS. The format
of the Venue Name ANQP-element is shown in Figure 9-594. The Venue Name ANQP-element might be
used to provide additional metadata on the BSS. For example, the information might be used to assist a user
in selecting the appropriate BSS with which to associate. Zero or more Venue Name fields can be included
in the same or different languages.
Venue Name
Info ID Length Venue Info Tuples
Octets: 2 2 2 variable
Figure 9-594—Venue Name ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Venue Info field is a 2-octet field and is defined in 9.4.1.35.
The Venue Name Tuples field contains zero or more variable length Venue Name Tuple subfields.
The format of the Venue Name Tuple subfield is shown in Figure 9-595.
— The Length field is a 1-octet field whose value is equal to 3 plus the number of octets in the Venue
Name field.
— The Language Code field is a 3-octet ISO 14962:1997 encoded string field that defines the language
used in the Venue Name field. The Language Code field is a two or three character language code
1129
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
selected from ISO 639. A two character language code has 0 (“null” in ISO 14962:1997) appended
to make it 3 octets in length.
— The Venue Name field is a variable-length UTF-8 encoded field containing the venue’s name. The
maximum length of this field is 252 octets.
Length Language Code Venue Name
Octets: 1 3 variable
Figure 9-595—Venue Name Tuple subfield
A URL associated with the Venue Name field can be specified by the Venue URL ANQP-element defined
in 9.4.5.20.
9.4.5.5 Emergency Call Number ANQP-element
The Emergency Call Number ANQP-element provides a list of emergency phone numbers to an emergency
responder, such as directed by a public safety answering point (PSAP), that is used in the
geographic location of the STA. The format of the Emergency Call Number ANQP-element is provided in
Figure 9-596.
Info ID Length Emergency Call
Number Duples
Octets: 2 2 variable
Figure 9-596—Emergency Call Number ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Emergency Call Number Duples field contains zero or more variable length Emergency Call Number
Duple subfields.
Each Emergency Call Number Duple subfield has the structure shown in Figure 9-597.
Length of Emergency Emergency Call
Call Number Number
Octets: 1 variable
Figure 9-597—Emergency Call Number Duple subfield format
The Length of Emergency Call Number field is a 1-octet field whose value is set to the length of the
Emergency Call Number field.
The Emergency Call Number field is a variable-length UTF-8 encoded field containing information, used to
reach emergency services, from the network (e.g., dialed digits, emergency service URN label [B46]).
9.4.5.6 Network Authentication Type ANQP-element
The Network Authentication Type ANQP-element provides a list of authentication types when ASRA is set
to 1. The format of the Network Authentication Type ANQP-element is shown in Figure 9-598.
1130
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Network
Info ID Length Authentication
Type Tuples
Octets: 2 2 variable
Figure 9-598—Network Authentication Type ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Network Authentication Type Tuples field contains zero or more variable length Network
Authentication Type Tuple subfields.
Each Network Authentication Type Tuple subfield has the structure shown in Figure 9-599.
Network Authentication Redirect URL Redirect URL
Type Indicator Length (optional)
Octets: 1 2 variable
Figure 9-599—Network Authentication Type Tuple subfield format
The Network Authentication Type Indicator field is a 1-octet field and has one of the values shown in
Table 9-272.
Table 9-272—Network Authentication Type Indicator definitions
Value Meaning
0 Acceptance of terms and conditions
1 On-line enrollment supported
2 http/https redirection
3 DNS redirection
4–255 Reserved
Each Network Authentication Type Indicator defines additional information that can be communicated.
If the Network Authentication Type Indicator is 0, the network requires the user to accept terms and
conditions. The Redirect URL can be used by the non-AP STA to obtain the terms and conditions. If the
Redirect URL is not present, then, the Redirect URL Length is set to 0.
If the Network Authentication Type Indicator is 1, the network supports on-line enrollment. Higher layer
protocols on the non-AP STA might indicate to the user that accounts might be created. When the Network
Authentication Type Indicator is 1, the Redirect URL Length is set to 0 and the Redirect URL is not present.
If the Network Authentication Type Indicator is 2, the network infrastructure performs http/https redirect.
The ReDirect URL is used by the non-AP STA to perform additional steps required for network access.
1131
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the Network Authentication Type Indicator is 3, the network supports DNS redirection. Higher layer
software on the non-AP STA exchanges credentials with the network, the Redirect URL Length is set to 0
and the Redirect URL is not present.
The Redirect URL Length field is a 2-octet field whose value is the length of the Redirect URL. The value of
the Redirect URL Length field is set to 0 whenever the Redirect URL is not present.
The Redirect URL field is a variable-length field that is optionally included if the Network Authentication
Type Indicator is either 0 or 2. If the Network Authentication Type Indicator is other than 0 or 2, a Redirect
URL is not included. The URL is formatted in accordance with IETF RFC 3986.
9.4.5.7 Roaming Consortium ANQP-element
The Roaming Consortium ANQP-element provides a list of information about the Roaming Consortium and/
or SSPs whose networks are accessible via this AP. This list can be returned in response to a GAS Query
using procedures in 11.25.3.3.3. The format of the Roaming Consortium ANQP-element is provided in
Figure 9-600.
Info ID Length OI Duples
Octets: 2 2 variable
Figure 9-600—Roaming Consortium ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
OIs contained within the Roaming Consortium element (see 9.4.2.96) are also included in this ANQP-
element. The value of the OI subfield(s) in this ANQP-element are equal to the values of the OI(s) in the
dot11RoamingConsortiumTable.
The OI Duples field contains zero or more variable length OI Duple subfields.
The format of the OI Duple subfield is provided in Figure 9-601.
— The value of the OI Length field is equal to the number of octets in the OI field.
— The OI field is defined in 9.4.1.32. Each OI identifies a roaming consortium (group of SSPs with
inter-SSP roaming agreement) or a single SSP.
OI Length OI
Octets: 1 variable
Figure 9-601—OI Duple subfield format
9.4.5.8 Vendor Specific ANQP-element
The Vendor Specific ANQP-element is used to query for information not defined in this standard within a
single defined format, so that reserved Info IDs are not usurped for nonstandard purposes and
interoperability is more easily achieved in the presence of nonstandard information. The ANQP-element is
in the format shown in Figure 9-602.
1132
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Info ID Length OI Vendor Specific Content
Octets: 2 2 variable variable
Figure 9-602—Vendor Specific ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The OI field is defined in 9.4.1.32.
The Vendor Specific Content field is a variable-length field whose content is defined by the entity identified
in the OI field.
9.4.5.9 IP Address Type Availability ANQP-element
The IP Address Type Availability ANQP-element provides STA with the information about the availability
of IP address version and type that could be allocated to the STA after successful association. The format of
the IP Address Type Availability ANQP-element is shown in Figure 9-603.
Info ID Length IP Address
Octets: 2 2 1
Figure 9-603—IP Address Type Availability ANQP-element
The Info ID and Length fields are defined in 9.4.5.1.
The format of the IP Address field shown in Figure 9-604.
Bits: B0 B1 B2 B7
IPv6 Address IPv4 Address
Figure 9-604—IP Address field format
The IPv6 Address field values are shown in Table 9-273.
Table 9-273—IPv6 Address field values
Address value Meaning
0 Address type not available
1 Address type available
2 Availability of the address type not known
3 Reserved
1133
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The IPv4 Address field values are shown in Table 9-274.
Table 9-274—IPv4 Address field values
Address value Meaning
0 Address type not available
1 Public IPv4 address available
2 Port-restricted IPv4 address available
3 Single NATed private IPv4 address available
4 Double NATed private IPv4 address available
5 Port-restricted IPv4 address and single NATed IPv4 address available
6 Port-restricted IPv4 address and double NATed IPv4 address available
7 Availability of the address type is not known
8–63 Reserved
9.4.5.10 NAI Realm ANQP-element
The NAI Realm ANQP-element provides a list of network access identifier (NAI) realms corresponding to
SSPs or other entities whose networks or services are accessible via this AP; optionally included for each
NAI realm is a list of one or more EAP Method subfields, which that NAI realm uses for authentication. The
format of the NAI Realm ANQP-element is provided in Figure 9-605.
NAI NAI
Info ID Length Realm Realm
Count Tuples
Octets: 2 2 2 variable
Figure 9-605—NAI Realm ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The NAI Realm Count field is a 2-octet field that specifies the number of NAI realms included in the NAI
Realm ANQP-element.
The NAI Realm Tuples field contains zero or more variable length NAI Realm Tuple subfields.
The format of the NAI Realm Tuple subfield is shown in Figure 9-606.
NAI NAI NAI EAP EAP
Realm NAI
Data Field Realm Realm Realm Method Method
Encoding Length Count Tuples
Length
Octets: 2 1 1 variable 1 variable
Figure 9-606—NAI Realm Tuple subfield format
1134
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The NAI Realm Data Field Length is a 2-octet subfield whose value is equal to 3 plus the length of the NAI
Realm subfield plus the sum of the lengths of the EAP Method subfields.
The NAI Realm Encoding is a 1-octet subfield whose format is shown in Figure 9-607.
Bits: B0 B1 B7
NAI Reserved
Realm Encoding Type
Figure 9-607—NAI Realm Encoding subfield format
The NAI Realm Encoding Type is a 1-bit subfield. It is set to 0 to indicate that the NAI Realm in the NAI
Realm subfield is formatted in accordance with IETF RFC 4282. It is set to 1 to indicate it is a UTF-8
encoded character string that is not formatted in accordance with IETF RFC 4282.
NOTE—This encoding is to facilitate roaming consortium or other entities that use nonstandard NAI Realm formats.
NAI Realm Length subfield is a 1-octet subfield whose value is the length in octets of the NAI Realm
subfield.
The NAI Realm subfield is one or more NAI Realms formatted as defined in the NAI Realm Encoding Type
bit of the NAI Realm Encoding subfield. If there is more than one NAI Realm in this subfield, the NAI
Realms are delimited by a semicolon character (i.e., “;”, which is encoded in UTF-8 format as 0x3B). All of
the realms included in the NAI Realm subfield support all of the EAP methods identified by the EAP
Method subfields, if present. The maximum length of this subfield is 255 octets.
The EAP Method Count specifies the number of EAP methods subfields for the NAI realm. If the count is 0,
there is no EAP method information provided for the NAI realm.
The EAP Method Tuples field contains zero or more variable length EAP Method Tuple subfields.
The format of the optional EAP Method Tuple subfield is shown in Figure 9-608. Each EAP Method
subfield contains a set of Authentication Parameters associated with the EAP-Method.
EAP Authentication Authentication
Length Parameter
Method Count Parameters
Octets: 1 1 1 variable
Figure 9-608—EAP Method Tuple subfield format
The Length subfield is a 1-octet subfield whose value is equal to 2 plus the length of the Authentication
Parameter subfields.
The EAP method subfield is a 1-octet subfield that is set to the EAP Type value as given in IANA EAP
Method Type Numbers.
The Authentication Parameter Count indicates how many additional Authentication Parameter subfields are
specified for the supported EAP Method. If the Authentication Parameters Count subfield is 0, there are no
Authentication Parameters subfields present, meaning no additional Authentication Parameters are specified
for the EAP Method.
1135
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Authentication Parameters field contains zero or more variable length Authentication Parameter
subfields.
The format of the Authentication Parameter subfield is shown in Figure 9-609.
ID Length Authentication Parameter Value
Octets: 1 1 variable
Figure 9-609—Authentication Parameter subfield format
The ID subfield is a 1-octet subfield that indicates the type of authentication information provided.
The Length subfield is a 1-octet subfield whose value is set to the length of the Authentication Parameter
Value subfield.
The Authentication Parameter Value subfield is a variable-length subfield containing the value of the
parameter indicated by the ID.
The ID and its associated formats are specified in Table 9-275. Each ID indicates a different type of
information. Use of multiple Authentication Parameter subfields allows all of the required authentication
parameter requirements to be provided.
Table 9-275—Authentication Parameter types
Length
Authentication information ID Description
(octets)
Reserved 0
Expanded EAP Method 1 Expanded EAP Method Subfield 7
Non-EAP Inner 2 Enum (0 - Reserved, 1 - PAP, 2 - CHAP, 1
Authentication Type 3 - MSCHAP, 4 - MSCHAPV2)
Inner Authentication EAP 3 Value drawn from IANA EAP Method Type Numbers 1
Method Type
Expanded Inner EAP Method 4 Expanded EAP Method Subfield 7
Credential Type 5 Enum (1 - SIM, 2 - USIM, 3 - NFC Secure Element, 4 - 1
Hardware Token, 5 - Softoken, 6 - Certificate,
7 - username/password, 8 - none (See NOTE), 9 -
Reserved,
10 - Vendor Specific)
Tunneled EAP Method 6 Enum (1 - SIM, 2 - USIM, 3 - NFC Secure Element, 4 - 1
Credential Type Hardware Token, 5 - Softoken, 6 - Certificate,
7 - username/password, 8 - Reserved,
9 - Anonymous, 10 - Vendor Specific)
Reserved 7–220
Vendor Specific 221 Variable variable
Reserved 222–255
NOTE—None means server-side authentication only.
If the EAP Method type is an Expanded EAP type (the EAP Method value is 254), the Authentication
Parameter is used to specify additional information on the EAP method. Table 9-276 describes the
1136
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Authentication Parameter format for the Expanded EAP method; values for the Vendor ID and Vendor Type
are specified in IETF RFC 3748. The Vendor ID and Vendor Type fields are expressed in big endian octet
order.
Table 9-276—Authentication Parameter format for the Expanded EAP method
Length
Parameters
(octets)
ID 1
Length 1
Vendor ID 3
Vendor Type 4
The Non-EAP Inner Authentication Type is specified as single enumerated value given in Table 9-275. This
Authentication Information type is used for non-EAP Inner Authentication methods. The possible values are
PAP (as specified in IETF RFC 1334), CHAP (as specified in IETF RFC 1994), MSCHAP (as specified in
IETF RFC 2433), and MSCHAPv2 (as specified in IETF RFC 2759).
The Inner Authentication EAP Method Type is specified as the EAP number as defined in IANA EAP
Method Type Numbers. This Authentication Information type is used when the Inner Authentication method
is an EAP method. If the Inner Authentication EAP Method Type is equal to 254 indicating an Expanded
EAP Type, then the Expanded EAP Method Authentication Parameter is included.
A Credential Type is specified as a single enumerated value as shown in Table 9-275. If the value is equal to
the “Vendor Specific” value, then a Vendor-Specific Authentication Parameter is included.
Vendor-Specific Authentication Parameters are specified as shown in Table 9-277.
Table 9-277—Vendor Specific Authentication Parameters
Length
Parameters
(octets)
ID 1
Length 1
OI variable
Authentication Parameter Value Vendor-specific content
9.4.5.11 3GPP Cellular Network ANQP-element
The 3GPP Cellular Network ANQP-element contains cellular information such as network advertisement
information e.g., network codes and country codes to assist a 3GPP non-AP STA in selecting an
AP to access 3GPP networks. The format of the 3GPP Cellular Network ANQP-element is shown in
Figure 9-610.
1137
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Payload
Info ID Length (optional)
Octets: 2 2 variable
Figure 9-610—3GPP Cellular Network ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Payload field is a variable-length field and is a generic container. An example of the format and content
is defined in Annex H of 3GPP TS 24.302.
9.4.5.12 AP Geospatial Location ANQP-element
The AP Geospatial Location ANQP-element provides the AP’s location in LCI format; see 9.4.2.22.10. This
information is taken from dot11APLCITable. The Z and Usage Rules/Policy subelements are optionally
presented in the Location Configuration Report field, when it is used in the AP Geospatial Location ANQP
element. The Co-Located BSSID List subelement is present when there is at least one other BSS which is
co-located with the reporting BSS.
The format of the AP Geospatial Location ANQP-element is provided in Figure 9-611.
Location Configuration
Info ID Length Report
Octets: 2 2 variable
Figure 9-611—AP Geospatial Location ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Location Configuration Report field is of variable length and defined in 9.4.2.22.10. The Z and Usage
Rules/Policy subelements are optionally present in the Location Configuration Report field, when it is used
in the AP Geospatial Location ANQP element. The Co-Located BSSID List subelement is present when
there is at least one other BSS which is co-located with the reporting BSS.
9.4.5.13 AP Civic Location ANQP-element
The AP Civic Location ANQP-element provides the AP’s location in civic format. The format of the AP
Civic Location ANQP-element is provided in Figure 9-612.
Info ID Length Location Civic Report
Octets: 2 2 variable
Figure 9-612—AP Civic Location ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Location Civic Report is a variable-length field and the format is provided in 9.4.2.22.13. This
information is taken from dot11APCivicLocationTable. The Co-Located BSSID List subelement is present
when there is at least one other BSS which is co-located with the reporting BSS and the Co-Located BSSID
List subelement is not present in the Geospatial Location ANQP-element; this subelement is not present
otherwise.
1138
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.5.14 AP Location Public Identifier URI/FQDN ANQP-element
The AP Location Public Identifier URI/FQDN ANQP-element provides an indirect reference to the location
information for the AP. This list element can be returned in response to a GAS Query using the
procedures in 11.25.3.3. The format of the AP Location Public Identifier URI/FQDN ANQP-element is
provided in Figure 9-613.
Zero or more
Info ID Length Public Identifier URI/
FQDN
Octets: 2 2 variable
Figure 9-613—AP Location Public Identifier URI/FQDN ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Public Identifier URI/FQDN field is a variable-length field containing zero or more Public Identifier
URI/FQDN subelements, as defined in 9.4.2.22.14.
9.4.5.15 Domain Name ANQP-element
The Domain Name ANQP-element provides a list of one or more domain names of the entity operating the
IEEE 802.11 access network. Domain Names in this ANQP-element are taken from
dot11DomainNameTable. The format of the Domain Name ANQP-element is provided in Figure 9-614.
Domain Name
Info ID Length
Duples
Octets: 2 2 variable
Figure 9-614—Domain Name ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Domain Name Duples field contains zero or more variable length Domain Name Duple subfields.
The format of the Domain Name Duple subfield is shown in Figure 9-615.
Length Domain Name
Octets: 1 variable
Figure 9-615—Domain Name Duple subfield format
The Length subfield is a 1-octet subfield whose value is set to the length in octets of the Domain Name
subfield.
The Domain Name subfield is of variable length and contains a domain name compliant with the “Preferred
Name Syntax” as defined in IETF RFC 1035. The maximum length of this field is 255 octets.
1139
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.5.16 Emergency Alert URI ANQP-element
The Emergency Alert URI ANQP-element provides a URI for EAS message retrieval.
The format of the Emergency Alert URI ANQP-element is provided in Figure 9-616.
Info ID Length Emergency Alert URI
Octets: 2 2 variable
Figure 9-616—Emergency Alert URI ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Emergency Alert URI field is a variable-length field used to indicate the URI at which an EAS message
can be retrieved as described in 11.25.7. The Emergency Alert URI field is formatted in accordance with
IETF RFC 3986.
9.4.5.17 Emergency NAI ANQP-element
The Emergency NAI ANQP-element contains an emergency string, which is available for use by a STA as
its identity to indicate emergency access request. The format of the Emergency NAI ANQP-element is
provided in Figure 9-617.
Info ID Length Emergency NAI
Information
Octets: 2 2 variable
Figure 9-617—Emergency NAI ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Emergency NAI Information field is a variable-length field encoded using UTF-8 and formatted in
accordance with IETF RFC 4282.
9.4.5.18 TDLS Capability ANQP-element
The TDLS Capability ANQP-element is used by a STA to discover the TDLS capabilities of a peer STA.
The format of the TDLS Capability is provided in Figure 9-618.
Info ID Length Peer Information
Octets: 2 2 variable
Figure 9-618—TDLS Capability ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Peer Information field is a variable-length field containing information that a STA can use to establish a
TDLS link and is defined as an XML schema (see R.6). An example of the peer information is described in
11.25.3.3.10.
1140
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.5.19 Neighbor Report ANQP-element
The Neighbor Report ANQP-element provides zero or more neighbor reports about neighboring APs. This
is of benefit to a STA in a preassociated state. The format of the Neighbor Report ANQP-element is defined
in Figure 9-619.
Info ID Length Neighbor Report
element (optional)
Octets: 2 2 variable
Figure 9-619—Neighbor Report ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The format of the Neighbor Report element is shown in Figure 9-295 defined in 9.4.2.37. The Element ID
and the Length fields of the Neighbor Report element, as shown in Figure 9-295, are not included. The Co-
Located BSSID List subelement is present when there is at least one other BSS which is co-located with the
reporting BSS.
9.4.5.20 Venue URL ANQP-element
The Venue URL ANQP-element provides a list of one or more URLs which can be used for web page
advertising services or providing information, particular to a venue’s BSS, to a STA. The format of the
Venue URL ANQP-element is defined in Figure 9-620.
Info ID Length Venue URL Duples
Octets: 2 2 variable
Figure 9-620—Venue URL ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Venue URL Duples field contains one or more Venue URL Duple fields as shown in Figure 9-621.
Venue
Length Number Venue URL
Octets: 1 1 variable
Figure 9-621—Venue URL Duple field
The Length field is a 1-octet field whose value is set to 1 plus the number of octets in the Venue URL field.
The Venue Number field is a 1-octet field whose value corresponds to the implicit returned order value of
the corresponding Venue Name Duple returned in a Venue Name ANQP-element, as defined in 9.4.5.4. If
no Venue Name Tuple subfield was returned in the Venue Name ANQP-element then this value is 0.
The Venue URL field is a variable-length field that indicates the URL at which information relevant to the
corresponding Venue Name Tuple subfield, indicated by the Venue Number, might be retrieved. This is
further described in 11.25.3.3.11. If no Venue URL is provided this field is left empty. The Venue URL field
is formatted in accordance with IETF RFC 3986.
1141
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.4.5.21 Advice of Charge ANQP-element
The Advice of Charge ANQP-element provides a list of one or more financial advice of charges related to
access to a BSS. The format of the Advice of Charge ANQP-element is defined in Figure 9-622.
Info ID Length Advice of Charge
Duples
Octets: 2 2 variable
Figure 9-622—Advice of Charge ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Advice of Charge Duples field contains one or more Advice of Charge Duple fields as shown in
Figure 9-623.
NAI NAI NAI Plan
Advice of
Length Charge Type Realm Realm Realm Information
Encoding Length Tuples
Octets: 2 1 1 1 variable variable
Figure 9-623—Advice of Charge Duple field
The Length field is a 2-octet field whose value is set to 3 plus the number of octets in the NAI Realm and
Plan Information Tuples fields.
The Advice of Charge Type field is a 1-octet field with the values defined in Table 9-278.
Table 9-278—Advice of Charge Type field values
Advice of Charge Type
Description
Value
0 Time-based
1 Data-volume-based
2 Time-and-data-volume-based
3 Unlimited
4–255 Reserved
The NAI Realm Encoding, NAI Realm Length and NAI Realm fields are defined in 9.4.5.10.
The format of the Plan Information Tuples field is defined in Figure 9-624.
Length Language Currency Code Plan Information
Octets: 2 3 3 variable
Figure 9-624—Plan Information Tuple field
1142
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Length field is a 2-octet field whose value is set to the number of octets in the Language, Currency
Code, and Plan Information fields.
The Language Code field is a 3-octet ISO 14962:1997 encoded string field that defines the language used in
the Cost Information field. The Language Code field is a two or three character language code selected from
ISO 639. A two character language code has 0 (“null” in ISO 14962:1997) appended to make it 3 octets in
length.
The Currency Code field is a 3-octet string (e.g., “USD”) representing an ISO 4217 currency numeric code.
The Plan Information field is a variable length UTF-8 formatted field that carries an XML description of an
Advice of Charge plan. The schema and semantics of this description are outside the scope of this standard.
9.4.5.22 Local Content ANQP-element
The Local Content ANQP-element provides a list of one or more URLs which can be used to display local
content related to the BSS. The format of the Local Content ANQP-element is defined in Figure 9-625.
Info ID Length Local Content
Duples
Octets: 2 2 variable
Figure 9-625—Local Content ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Local Content Duples field contains one or more Local Content Duple fields as shown in Figure 9-626.
Length State Local Content URL Label Length Label
(optional) (optional)
Octets: 1 1 variable 0 or 1 variable
Figure 9-626—Local Content Duple field
The Length field is a 1-octet field whose value is set to 1 plus the number of octets in the Local Content
URL, Label Length and Label fields.
The State field is a 1-octet field whose value is defined in Table 9-279.
Table 9-279—Local Content State values
State Name
0 Not authenticated
1 Authenticated
2 Failure during authentication
3 Incorrect credentials
4 Credentials expired
5–255 Reserved
1143
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Local Content URL field is a variable-length field containing a URL that is used for directing the device
to local content. The Local Content URL field is formatted in accordance with IETF RFC 3986.
The Label Length field is a 1 octet field that contains the value of the length of the Label field in octets. If
the Label is not used, this field is also not used.
The Label field is a variable-length field containing a description of the URL. It provides the type and
potential usage of the URL. This is a UTF-8 formatted string.
9.4.5.23 Network Authentication Type with Timestamp ANQP-element
The Network Authentication Type with Timestamp ANQP-element provides similar information to that of
the Network Authentication Type as defined in 9.4.5.6. In addition, a timestamp field is optionally provided
to indicate to the requesting STA a timestamp corresponding to the time at which the received terms and
conditions were most recently modified. With this timestamp, the requesting STA can determine if
previously received information is stale.
The format of the Network Authentication Type with Time ANQP-element is shown in Figure 9-627.
Info ID Length Network Authentication
Timestamp Tuples
Octets: 2 2 variable
Figure 9-627—Network Authentication Type with Timestamp ANQP-element format
The Info ID and Length fields are defined in 9.4.5.1.
The Network Authentication Timestamp Tuples field contains zero or more variable length Network
Authentication Timestamp Tuple subfields.
Each Network Authentication Timestamp Tuple subfield has the structure shown in Figure 9-628.
Network Authentication Redirect URL Redirect URL Time Value
Type Indicator Length (optional) (optional)
Octets: 1 1 variable 0 or 10
Figure 9-628—Network Authentication Timestamp Tuple subfield format
The Network Authentication Type Indicator field is defined in 9.4.5.6
The Redirect URL Length field and the Redirect URL field are defined in 9.4.5.6.
The Time Value field is defined in Table 9-170 using the Timing Capability equal to 2 encoding. This field
is used by the responding STA to set a time of the ANQP response.
9.4.6 Registered location query protocol (RLQP) elements
9.4.6.1 General
RLQP-elements are defined to have a common format consisting of a 2-octet Info ID field, a 2-octet Length
field, and a variable-length RLQP-element-specific Information field. Each element is assigned a unique
Info ID as defined in this standard. The RLQP-element format is shown in Figure 9-629.
1144
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Info ID Length Information
Octets: 2 2 variable
Figure 9-629—RLQP-element format
Each RLQP-element in 9.4.6 is assigned a unique 2-octet Info ID. The set of valid Info IDs is defined in
Table 9-629. The 2-octet Info ID field is encoded following the conventions given in 9.2.2.
The Length field is a 2-octet field that indicates the number of octets in the Information field and is encoded
following the conventions given in 9.2.2.
The RLQP-elements are shown in Table 9-280. Info ID 56 797 stands for Vendor Specific information.
Table 9-280—RLQP-element definitions
RLQP-element name Info ID RLQP-element (subclause)
Reserved 0–272 N/A
Channel Availability Query 273 9.4.6.2
Channel Schedule Management 274 9.4.6.3
Network Channel Control 275 9.4.6.4
Reserved 276–56 796 N/A
Vendor Specific 56 797 9.4.6.5
Reserved 56 798–65 535 N/A
9.4.6.2 Channel Availability Query RLQP-element
The Channel Availability Query element is used to exchange the requests and responses for the channel
availability query process using the GAS protocol. The Channel Availability Query RLQP-element is
included in a GAS Query Request or returned in a response to a GAS Query Request.
The element is in the format shown in Figure 9-630.
Info Length Requester Responder Reason Channel Device Device Device WSM
ID STA STA Result Query Class Identification Location Information
Address Address Code Info Information Information
Octets: 2 2 6 6 1 1 variable variable variable variable
Figure 9-630—Channel Availability Query RLQP-element format
The Info ID and Length fields are defined in 9.4.6.1.
The RequesterSTAAddress field is the MAC address of the requesting STA that initiates the channel query
process. The length of the RequesterSTAAddress field is 6 octets.
The ResponderSTAAddress field is the MAC address of the responding STA that responds to the channel
query requesting STA. The length of the ResponderSTAAddress field is 6 octets.
1145
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Reason Result Code field is used to indicate the reason that a channel availability query was generated.
It also indicates the result of the query as successful or not and the reason when the query is not successful.
The length of the Reason Result Code field is 1 octet. The Reason Result Code field values that have been
allocated are shown in Table 9-281.
Table 9-281—Reason Result Code field values
Reason Result
Name Description
Code field value
0 Reserved.
1 Channel availability list requested.
2 SUCCESS Success with the available channel list result for a
Device Location Information field.
3 SUCCESS_MULTIPLE Success with an available channel list result for a
bounded geographic area defined by multiple Device
Location Information fields.
4 REFUSED Request declined.
5 DEVICE_VERIFICATION_ Request not successful because of device identification
FAILURE verification failure.
NOTE—Failure of providing an authorized
identification of the corresponding regulatory
organization can cause the responding STA to reject the
query and return such a Reason Result Code.
6 Continuation frame This frame continues the fields from the previous CAQ
frame.
7–255 Reserved.
The Channel Query Info field is used to indicate the type of Channel Query request and associated
parameters. The format of the Channel Query Info field is shown in Figure 9-631.
B0 B1 B3 B4 B7
Device Number of Reserved
Identification Device Location
Information Information
Present Subfields
Bits: 1 3 4
Figure 9-631—Channel Query Info field format
The Device Identification Information Present subfield value is set to 1 to indicate that the Device
Identification Information field is present in the Channel Availability Query element; otherwise it is set to 0
to indicate that the Device Identification Information field is not provided.
The Number of Device Location Information Subfields subfield indicates the number of device location
information subfields presented in the Channel Availability Query element. When no device location is
present, the Number of Device Location Information Subfields subfield is set to 0.
1146
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Device Class field is used to indicate the characteristics of STA requesting the channel availability
query. The format of the Device Class field is specified in 9.4.4.2.1. The Device Class field is present only
when the Reason Result Code field value is 1.
The Device Identification Information field is used to indicate the identification of the STA requesting the
channel availability query. The format of the Device Identification Information field is specified in 9.4.4.2.2.
The Device Location Information field is used to provide the location of the STA requesting the channel
availability query, which is provided in the format specified in 9.4.4.2.3.
The WSM Information field is defined in the White Space Map element (see 9.4.2.170). The WSM
Information field is present only when the Reason Result Code field value is 2 or 3, as the successful result
of the query.
9.4.6.3 Channel Schedule Management RLQP-element
The Channel Schedule Management element is used by an GDD enabling STA to query the RLSS or
another GDD enabling STA for channel schedule information. The element is in the format shown in
Figure 9-632.
Info ID Length Requester Responder Reason Channel Device Channel
STA Address STA Address Result Code Schedule Identification Schedule
Management Information Descriptor
Mode
Octets: 2 2 6 6 1 1 variable variable
Figure 9-632—Channel Schedule Management RLQP-element format
The Info ID and Length fields are defined in 9.4.6.1.
The Requester STA Address field is the MAC address of the requesting STA that initiates the channel
schedule management process.
The Responder STA Address field is the MAC address of the STA that responds to the STA that requested
channel schedule management.
The remaining fields are as defined in the Channel Schedule Management element (see 9.6.8.26).
9.4.6.4 Network Channel Control RLQP-element
The Network Channel Control element is used to request network channel control and respond to network
channel requests using the GAS protocol. The element is in the format shown in Figure 9-633.
a Network Channel Control triplet
Info Length Requester Responder Reason Number of Operating Channel Maximum
ID STA STA Result Network Class Number Transmit
Address Address Code Channel Power
Control
Triplets
Octets: 2 2 6 6 1 1 1 1 1
Figure 9-633—Network Channel Control RLQP-element format
The Info ID and Length fields are defined in 9.4.6.1.
1147
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The RequesterSTAAddress field is the MAC address of the requesting STA that initiates the network
channel control process.
The ResponderSTAAddress field is the MAC address of the STA that responds to the STA that requested
network channel control.
The Reason Result Code field is used to indicate the reason that a Network Channel Control frame was
generated. The length of the Reason Result Code field is 1 octet. The encoding of the Reason Result Code
field is shown in Table 9-282.
Table 9-282—Reason Result Code field values
Reason Result
Name Description
Code field value
0 REQUEST Network channel request.
1 SUCCESS Success.
2 REFUSED Request declined.
3 TOO_MANY_SIMULTA Network channel request denied because the GDD enabling
NEOUS_REQUESTS STA is unable to handle additional GDD dependent STAs.
4 Continuation frame This frame continues the fields from the previous NCC
frame.
5–255 Reserved.
The Number of Network Channel Control Triplets field indicates the number of triplets of Operating Class,
Channel Number, and Transmit Power Constraint fields.
The Operating Class field indicates the channel set for which the network channel control request applies.
The Operating Class field and Channel Number field are used together to specify the channel frequency and
channel bandwidth for which the network channel control applies. Values for the Operating Class field are
shown in E.1.
In a request, the Channel Number field of a Network Channel Control frame indicates the channel that the
requesting STA intends to operate on. In a response, the Channel Number field in the Network Channel
Control frame indicates the channels that the responding STA permits the requesting STA to operate on. The
Channel Number is defined within an Operating Class as shown in E.1.
The Maximum Transmit Power field gives the intended maximum transmit power in dBm for operation in
the request frame and indicates the maximum allowable transmit power in dBm for operation in the response
frame. The field is coded as a signed integer in units of 0.5 dBm. The field is set to –128 when a requesting
STA requests a responding STA to provide a network channel control response without specifying in the
request the intended maximum transmit power.
9.4.6.5 Vendor Specific RLQP-element
The Vendor Specific RLQP-element is used to carry information not defined in this standard within a single
defined format, so that reserved Info IDs are not usurped for nonstandard purposes and so that
interoperability is more easily achieved in the presence of nonstandard information. The RLQP-element is in
the format shown in Figure 9-634.
1148
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Info ID Length Organization Iden- Vendor-specific
tifier content
Octets: 2 2 j variable
Figure 9-634—Vendor Specific RLQP-element format
The Info ID and Length fields are defined in 9.4.6.1.
The Organization Identifier field identifies (see 9.4.1.32) the entity that has defined the content of the
particular Vendor Specific RLQP-element. See 9.4.1.32 for the definition of j.
9.5 Fields used in Management and Extension frame bodies and Control frames
9.5.1 Sector Sweep field
The format of the sector sweep (SSW) field is shown in Figure 9-635.
B0 B1 B9 B10 B15 B16 B17 B18 B23
Direction CDOWN Sector ID DMG Antenna ID RXSS Length
Bits: 1 9 6 2 6
Figure 9-635—SSW field format
The Direction subfield is set to 0 to indicate that the frame is transmitted by the beamforming initiator and
set to 1 to indicate that the frame is transmitted by the beamforming responder.
The CDOWN subfield is a down-counter indicating the number of remaining DMG Beacon frame
transmissions to the end of the TXSS, or the number of remaining SSW frame transmissions to the end of
the TXSS/RXSS. This subfield is set to 0 in the last frame DMG Beacon and SSW frame transmission.
Possible values range from 0 to 511.
The Sector ID subfield is set to indicate the sector number through which the frame containing this SSW
field is transmitted.
The DMG Antenna ID subfield indicates the DMG antenna the transmitter is currently using for this
transmission.
The RXSS Length subfield is valid only when transmitted in a CBAP and is reserved otherwise. The RXSS
Length subfield specifies the length of a receive sector sweep as required by the transmitting STA and is
defined in units of an SSW frame. The length of the sector sweep is given by RXSS Length + 1 2 .
9.5.2 Dynamic Allocation Info field
The format of the Dynamic Allocation Info field is shown in Figure 9-636.
The TID subfield identifies the TC or TS for the allocation request or grant.
NOTE—Unlike pseudo-static allocations, nonpseudo-static allocations are not labeled with an allocation ID, and are
associated to a TID.
1149
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B3 B4 B6 B7 B14 B15 B22 B23 B38 B39
Allocation
TID AllocationType Source AID Destination AID Duration Reserved
Bits: 4 3 8 8 16 1
Figure 9-636—Dynamic Allocation Info field format
The AllocationType subfield is defined in 9.4.2.132.
The Source AID subfield identifies the STA that is the source of the allocation.
The Destination AID subfield identifies the STA that is the destination of the allocation.
When the Dynamic Allocation Info field is transmitted within an SPR frame, the Allocation Duration
subfield contains the requested duration in microseconds. When the Dynamic Allocation Info subfield is
transmitted within a Grant frame by an AP or PCP in an ATI or GP, the Allocation Duration subfield
contains the granted duration of the SP or CBAP allocation in microseconds (see 10.36.3, 10.36.7, 10.36.8,
and 10.36.9). Possible values range from 0 to 32 767 for an SP allocation and a CBAP allocation. A value of
0 in the Allocation Duration subfield transmitted within a Grant frame means that the STA can transmit one
PPDU followed by any relevant acknowledgment plus one RTS/DMG CTS handshake.
When the Dynamic Allocation Info subfield is transmitted within a Grant frame in a CBAP, the value of the
Allocation Duration field indicates the purpose of the Grant frame transmission. Two purposes are possible:
a) Beyond current TXOP: in this case, the Allocation Duration subfield values range from 0 to 32 767.
The value of the Allocation Duration field plus the Duration field of the Grant frame indicates the
time offset from the PHY-TXEND.indication primitive of the Grant frame when the STA
transmitting the Grant frame will attempt to initiate access for communication with the STA
indicated by the RA field of the Grant frame.
b) Within current TXOP: in this case, the Allocation Duration subfield is set to 32 768.
When the Dynamic Allocation Info subfield is transmitted within a Grant frame with RA set to broadcast
address by a source or destination STA of an SP, the Allocation Duration subfield values range from 0 to 32
767.
When the Dynamic Allocation Info subfield is transmitted within a Grant frame with RA set to unicast
address by a source STA of an SP, the Allocation Duration subfield is set to 32 768.
9.5.3 Sector Sweep Feedback field
When the SSW Feedback field is transmitted as part of an ISS, the format of the field is as shown in
Figure 9-637. Otherwise, the format of the SSW Feedback field is as shown in Figure 9-638.
B0 B8 B9 B10 B11 B15 B16 B17 B23
Total Sectors in Number of RX Poll
ISS DMG Antennas Reserved Required Reserved
Bits: 9 2 5 1 7
Figure 9-637—SSW Feedback field format when transmitted as part of an ISS
1150
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B5 B6 B7 B8 B15 B16 B17 B23
DMG Antenna
Sector Select Select SNR Report Poll Required Reserved
Bits: 6 2 8 1 7
Figure 9-638—SSW Feedback field format when not transmitted as part of an ISS
The Total Sectors in ISS subfield indicates the total number of sectors that the initiator uses in the ISS,
including any repetition performed as part of multi-antenna beamforming. Possible values range from 0 to
511, representing 1 to 512 sectors.
The Number of RX DMG Antennas subfield indicates the number of receive DMG antennas the initiator
uses during the following RSS. The number of receive DMG antennas used is equal to the value of this
subfield plus 1.
The Sector Select subfield contains the value of the Sector ID subfield of the SSW field within the frame that
was received with best quality in the immediately preceding sector sweep. The determination of which
packet was received with best quality is implementation dependent. Possible values of this subfield range
from 0 to 63.
The DMG Antenna Select subfield indicates the value of the DMG Antenna ID subfield of the SSW field
within the frame that was received with best quality in the immediately preceding sector sweep. The
determination of which frame was received with best quality is implementation dependent.
The SNR Report subfield is set to the value of the SNR from the frame that was received with best
quality during the immediately preceding sector sweep, and which is indicated in the Sector Select field.
This subfield is encoded as 8-bit 2s complement value of 4×(SNR-19), where SNR is measured in dB. This
covers from –13 dB to 50.75 dB in 0.25 dB steps.
The Poll Required subfield is set to 1 by a non-AP and non-PCP STA to indicate that it requires the AP or
PCP to initiate communication with the non-AP and non-PCP. This subfield is set to 0 to indicate that the
non-AP and non-PCP has no preference about whether the AP or PCP initiates the communication. This
subfield is reserved when transmitted by an AP or PCP.
9.5.4 BRP Request field
The BRP Request field is defined in Figure 9-639.
B0 B4 B5 B6 B7 B8 B9 B10 B11 B16 B17 B24 B25 B26 B27 B31
TX- Chan- TX
L-RX TRN- MID- BC- MID- BC- FBCK- TX Other_AID Antenna Reserved
REQ REQ Grant Grant Sector ID
REQ CAP ID
Bits: 5 1 1 1 1 1 1 6 8 2 5
Figure 9-639—BRP Request field format
If the MID-REQ subfield is set to 0, the L-RX subfield indicates the compressed number of TRN-R
subfields requested by the transmitting STA as part of beam refinement. To obtain the number of TRN-R
subfields, the value of the L-RX subfield is multiplied by 4. Possible values range from 0 to 16,
corresponding to 0 to 64 TRN-R fields. Other values are reserved. If the subfield is set to 0, the transmitting
STA does not need receive training as part of beam refinement. If the MID-REQ subfield is set to 1, the
1151
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
L-RX subfield indicates the compressed number of AWV settings that the STA uses during the MID phase.
To obtain the number of AWVs that is used, the value of the L-RX subfield is multiplied by 4.
The TX-TRN-REQ subfield is set to 1 to indicate that the STA needs transmit training as part of beam
refinement. Otherwise, it is set to 0.
A STA sets the MID-REQ subfield to 1 in SSW-Feedback or BRP frames to indicate a request for an I-MID
subphase or R-MID subphase; otherwise, the STA sets the subfield to 0 to indicate it is not requesting an I-
MID subphase or R-MID subphase. In case an R-MID subphase is requested, the STA can include
information on the TX sector IDs to be used by the STA receiving this request. The STA receiving this
request sets the MID-grant subfield in SSW-Ack or BRP frames to 1 to grant this request or otherwise sets it
to 0.
A STA sets the BC-REQ subfield to 1 in SSW-Feedback or BRP frames to indicate a request for an I/R-BC
subphase; otherwise, the STA sets the subfield to 0 to indicate it is not requesting an I/R-BC subphase. In
case an R-BC subphase is requested, the STA can include information on the TX sector IDs to be used by
the STA receiving this request. The STA receiving this request sets the BC-grant subfield in SSW-Ack or
BRP frames to 1 to grant this request; otherwise, the STA sets it to 0 to reject the request.
The Chan-FBCK-CAP subfield is set to 1 to indicate the STA is capable to return channel measurement
during beam refinement. The Chan-FBCK-CAP subfield is set to 0 to indicate the STA is able to return only
BS-FBCK during beam refinement.
NOTE—Regardless of the value of the Chan-FBCK-CAP subfield, 10.38.6.4 requires a DMG STA to return the SNR
values from the last TXSS if it receives a BRP frame with the TXSS-FBCK-REQ field and the SNR Requested subfield
within the FBCK-REQ field both set to 1.
The TX sector ID subfield indicates the sector ID that is used when transmitting the packet. If the packet is
transmitted using a pattern that is not a sector that has been used in the sector sweep, the value of this
subfield is set to 0x63.
The Other_AID subfield is set to the AID of an additional STA referenced in the BRP procedure as
described in 10.38.6.4.4 and 20.10.2.2.6. Otherwise, if the additional STA is not used, this subfield is set to
0.
The TX Antenna ID subfield indicates the DMG antenna ID that is used when transmitting the packet.
9.5.5 Beamforming Control field
The Beamforming Control field is formatted as shown in Figure 9-640 when both the IsInitiatorTXSS and
IsResponderTXSS subfields are equal to 1, and the Beamforming Control field is transmitted in either a
Grant or Grant Ack frames. In all other cases, the Beamforming Control field is formatted as shown in
Figure 9-641.
B0 B1 B2 B3 B9 B10 B11 B12 B15
Number of
Beamforming IsInitiatorTXSS IsResponderTXSS Total Number RX DMG Reserved
Training of Sectors
Antennas
Bit: 1 1 1 7 2 4
Figure 9-640—BF Control field format when
both IsInitiatorTXSS and IsResponderTXSS subfields are equal to 1 and
the BF Control field is transmitted in Grant or Grant Ack frames
1152
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B3 B8 B9 B10 B15
Beamforming RXSS
Training IsInitiatorTXSS IsResponderTXSS Length RXSSTxRate Reserved
Bit: 1 1 1 6 1 6
Figure 9-641—BF Control field format in all other cases
The Beamforming Training subfield is set to 1 to indicate that the source DMG STA intends to initiate
beamforming training with the destination DMG STA at the start of the allocation and is set to 0 otherwise.
If the Beamforming Training subfield is set to 0, all other subfields of the Beamforming Control field are
reserved.
The IsInitiatorTXSS subfield is set to 1 to indicate that the source DMG STA starts the beamforming
training with an initiator TXSS. This subfield is set to 0 to indicate that the source DMG STA starts the BF
training with an initiator RXSS.
The IsResponderTXSS subfield is set to 1 to indicate that the destination DMG STA starts the RSS with a
responder TXSS. This subfield is set to 0 to indicate that the destination DMG STA is to initiate the RSS
with a responder RXSS.
When the Beamforming Control field is transmitted within an Extended Schedule element, either the
IsInitiatorTXSS subfield or the IsResponderTXSS subfield is set to 0, but not both.
The RXSS Length subfield is valid only if at least one of IsInitiatorTXSS subfield or IsResponderTXSS
subfield is equal to 0 and is reserved otherwise. The value represented by the RXSS Length subfield
specifies the total number of receive sectors combined over all receive DMG antennas of the STA, including
any LBIFS as necessary for DMG antenna switching. The value represented by this subfield is in the range 2
to 128 and is given by (RXSS Length+1)×2.
The RXSSTxRate subfield is valid only if the RXSS Length subfield is valid and the value of the RXSS
Length subfield is greater than 0. Otherwise, the RXSSTxRate subfield is reserved. The RXSSTxRate
subfield is set to 0 to indicate that all frames transmitted as part of the RXSS use the DMG Control
modulation class (10.7.7.1). The RXSSTxRate subfield is set to 1 to indicate that only the first frame
transmitted as part of the RXSS use the DMG Control modulation class and the remaining frames use MCS
1 of the DMG SC modulation class. If both the IsInitiatorTXSS and IsResponderTXSS subfields are set to 0
and the BF Control field is sent within a Grant frame, the RXSSTxRate subfield refers to the RSS only. If
both the IsInitiatorTXSS and IsResponderTXSS subfields are set to 0 and the BF Control field is sent within
a Grant Ack frame, the RXSSTxRate subfield refers to the ISS only.
When the BF Control field is transmitted in a Grant frame, the Total Number of Sectors subfield indicates
the total number of sectors the initiator uses during the ISS, including any LBIFS required for DMG antenna
switching (see 10.38). When the BF Control field is transmitted in a Grant Ack frame, the Total Number of
Sectors subfield indicates the total number of sectors the responder uses during the RSS. In both cases, the
total number of sectors used is equal to the value of this field plus 1.
When the BF Control field is transmitted in a Grant frame, the Number of RX DMG Antennas subfield
indicates the number of receive DMG antennas the initiator uses during the RSS. When the BF Control field
is transmitted in a Grant Ack frame, the Number of RX DMG Antennas subfield indicates the number of
receive DMG antennas the responder uses during the ISS. In both cases, the number of receive DMG
antennas used is equal to the value of this subfield plus 1.
1153
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the BF Control field is transmitted in a Grant Ack frame in response to a Grant frame with the
Beamforming Training field equal to 0, the following fields are reserved: IsInitiatorTXSS,
IsResponderTXSS, Total Number of Sectors, and Number of RX DMG Antennas.
9.5.6 Beamformed Link Maintenance field
The Beamformed Link Maintenance field is shown in Figure 9-642 and provides a DMG STA with the
value of dot11BeamLinkMaintenanceTime.
B0 B1 B6 B7
BeamLink Maintenance Unit Index BeamLink Maintenance Value BeamLink isMaster
Bits: 1 6 1
Figure 9-642—Beamformed Link Maintenance field format
The encoding of the BeamLink Maintenance Unit Index subfield is specified in Table 9-283.
Table 9-283—Encoding of BeamLink Maintenance Unit Index
BeamLink Maintenance Unit Index BeamLink Maintenance Unit (µs)
0 32
1 2000
If the content of the BeamLink Maintenance Value subfield is greater than 0, it is used to calculate
dot11BeamLinkMaintenanceTime as follows:
dot11BeamLinkMaintenanceTime = BLMU × BLMV
where
BLMU is the value of the BeamLink Maintenance Unit corresponding to the value of the BeamLink
Maintenance Unit Index subfield (see Table 9-283)
BLMV is the value of the BeamLink Maintenance Value subfield
Otherwise, if the value of the BeamLink Maintenance Value subfield is 0, the
dot11BeamLinkMaintenanceTime is left undefined. An undefined value of the
dot11BeamLinkMaintenanceTime indicates that the STA does not participate in beamformed link
maintenance.
The BeamLink isMaster subfield is set to 1 to indicate that the STA is the master of the data transfer and set
to 0 if the STA is a slave of the data transfer. The STAs use the BeamLink isMaster subfield to negotiate the
dot11BeamLinkMaintenanceTime as specified in Table 9-284.
NOTE—In Table 9-284, STA-A and STA-B refer to any of the STAs performing the Beamformed Link Maintenance
negotiation procedure in no particular order.
1154
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-284—The Beamformed Link Maintenance negotiation
BeamLink BeamLink dot11BeamLinkMaintenanceTime
isMaster isMaster (STA-A) vs.
Result
subfield subfield dot11BeamLinkMaintenanceTime
(STA-A) (STA-B) (STA-B)
0 0 ≥ dot11BeamLinkMaintenanceTime
(STA-A)
1 0 >, <, = dot11BeamLinkMaintenanceTime
(STA-A)
1 1 = dot11BeamLinkMaintenanceTime
(STA-A)
0 or 1 0 or 1 If either Undefined
dot11BeamLinkMaintenanceTime
(STA-A) or
dot11BeamLinkMaintenanceTime
(STA-B) is undefined
9.6 Action frame format details
9.6.1 Introduction
Subclause 9.6 describes the Action field formats allowed in each of the action categories defined in Table 9-
47 in 9.4.1.11.
9.6.2 Spectrum management Action frames
9.6.2.1 General
Five Action frame formats are defined for spectrum management. A Spectrum Management Action field, in
the octet field immediately after the Category field, differentiates the five formats. The Spectrum
Management Action field values associated with each frame format are defined in Table 9-285.
Table 9-285—Spectrum Management Action field values
Spectrum
Management Description
Action field value
0 Measurement Request
1 Measurement Report
2 TPC Request
3 TPC Report
4 Channel Switch Announcement
5–255 Reserved
1155
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.2.2 Measurement Request frame format
The Measurement Request frame uses the Action frame body format and is transmitted to request another
STA to measure one or more channels. The format of the Measurement Request Action field is shown in
Figure 9-643.
Spectrum Measurement
Category Management Dialog Token
Action Request Elements
Octets: 1 1 1 variable
Figure 9-643—Measurement Request frame Action field format
The Category field is defined in 9.4.1.11.
The Spectrum Management Action field is defined in 9.6.2.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the measurement request to
identify the request/report transaction.
The Measurement Request Elements field contains one or more of the Measurement Request elements
described in 9.4.2.21. The number and length of the Measurement Request elements in a Measurement
Request frame are limited by the maximum allowed MMPDU size.
9.6.2.3 Measurement Report frame format
The Measurement Report frame uses the Action frame body format and is transmitted in response to a
Measurement Request frame or transmitted autonomously providing measurement information. The format
of the Measurement Report Action field is shown in Figure 9-644.
Spectrum Measurement
Category Management Dialog Token
Action Report Elements
Octets: 1 1 1 variable
Figure 9-644—Measurement Report frame Action field format
The Category field is defined in 9.4.1.11.
The Spectrum Management Action field is defined in 9.6.2.1.
The Dialog Token field is set to the same value as the Dialog Token field of the corresponding Measurement
Request frame. If the Measurement Report frame is not being transmitted in response to a Measurement
Request frame, then the dialog token is set to 0.
The Measurement Report Elements field contains one or more of the Measurement Report elements
described in 9.4.2.22. The number and length of the Measurement Report elements in a Measurement Report
frame are limited by the maximum allowed MMPDU size.
9.6.2.4 TPC Request frame format
The TPC Request frame uses the Action frame body format and is transmitted requesting another STA for
transmit power and link margin information. The format of the TPC Request Action field is shown in
Figure 9-645.
1156
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Spectrum
Category Management Dialog Token TPC Request
element
Action
Octets: 1 1 1 2
Figure 9-645—TPC Request frame Action field format
The Category field is defined in 9.4.1.11.
The Spectrum Management Action field is defined in 9.6.2.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the request to identify the
transaction.
The TPC Request element is set as described in 9.4.2.16.
9.6.2.5 TPC Report frame format
The TPC Report frame uses the Action frame body format and is transmitted in response to a TPC Request
frame. The format of the TPC Report Action field is shown in Figure 9-646.
Spectrum TPC Report
Category Management Dialog Token
Action element
Octets: 1 1 1 4
Figure 9-646—TPC Report frame Action field format
The Category field is defined in 9.4.1.11.
The Spectrum Management Action field is defined in 9.6.2.1.
The Dialog Token field is set to the value of the Dialog Token field in the corresponding TPC Request
frame.
The TPC Report element is set as described 9.4.2.17.
9.6.2.6 Channel Switch Announcement frame format
The Channel Switch Announcement frame uses the Action frame body format and is transmitted by an AP,
IBSS STA, or mesh STA to advertise a channel switch. The format of the Channel Switch Announcement
Action field is shown in Figure 9-647.
Optional Zero or more
Mesh Channel Wide New Transmit
Spectrum Channel Switch Secondary
Category Management Announcement Channel Switch Bandwidth Power
Parameters Channel Switch Envelope
Action element Offset element element element element
Octets: 1 1 5 0 or 3 0 or 8 0 or 5 variable
Figure 9-647—Channel Switch Announcement frame Action field format
1157
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The Spectrum Management Action field is defined in 9.6.2.1.
The Channel Switch Announcement element is set as described 9.4.2.19.
The Secondary Channel Offset element is defined in 9.4.2.20. This element is present when switching to a
40 MHz or wider channel. It can be present when switching to a 20 MHz channel (in which case the
Secondary Channel Offset field is set to SCN); see 11.40.4.
The Mesh Channel Switch Parameters element is defined in 9.4.2.103. This element is present when a mesh
STA performs MBSS channel switching. Otherwise, the Mesh Channel Switch Parameters element is not
present.
The Wide Bandwidth Channel Switch element is defined in 9.4.2.161. This element is present when
switching to a channel width wider than 40 MHz.
Each New Transmit Power Envelope element that is present is defined to have the same format as the
Transmit Power Envelope element (see 9.4.2.162) and includes a distinct value of the Local Maximum
Transmit Power Unit Interpretation subfield. If present, the New Transmit Power Envelope element
indicates the local maximum transmit powers for the BSS for the indicated bandwidths with an indicated
unit interpretation after channel switching (see 11.40.1).
9.6.3 QoS Action frame details
9.6.3.1 General
Several Action frame formats are defined for QoS purposes. These frames are identified by the single octet
QoS Action field, which follows immediately after the Category field. The values of the QoS Action field
are defined in Table 9-286.
Table 9-286—QoS Action field values
QoS Action field
Meaning
value
0 ADDTS Request
1 ADDTS Response
2 DELTS
3 Schedule
4 QoS Map Configure
5 ADDTS Reserve Request
6 ADDTS Reserve Response
7–255 Reserved
Two variants are defined for the ADDTS frames: a Basic ADDTS frame variant and a DMG ADDTS frame
variant. These variants use different TSPEC formats. The variant of the frame is indicated by the Element ID
in the fourth field of the ADDTS Request frame Action field format (Table 9-303) and sixth field of the
1158
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ADDTS Response frame Action field format (Table 9-304). The Element ID is the first octet of each of
these fields. The encoding of the ADDTS frame variants is shown in Table 9-287 and Table 9-288.
Table 9-287—Encoding of the ADDTS Request frame variant
Element ID of fourth field of ADDTS Request frame ADDTS Request frame variant
13 (TSPEC) Basic ADDTS Request frame
146 (DMG TSPEC) DMG ADDTS Request frame
Table 9-288—Encoding of the ADDTS Response frame variant
Element ID of sixth field of ADDTS Response frame ADDTS Response frame variant
13 (TSPEC) Basic ADDTS Response frame
146 (DMG TSPEC) DMG ADDTS Response frame
9.6.3.2 Basic and DMG ADDTS Request frame format
9.6.3.2.1 Basic ADDTS Request frame variant
The ADDTS frames are used to carry TSPEC and optionally TCLAS elements to set up and maintain TSs
using the procedures defined in 11.4.
The Action field of the ADDTS Request frame contains the information shown in Table 9-289.
Table 9-289—Basic ADDTS Request frame variant Action field format
Order Information Notes
1 Category
2 QoS Action
3 Dialog token
4 TSPEC
5 TCLAS Optional
6 TCLAS Processing Optional
7 U-APSD Coexistence Optional
8 Expedited Bandwidth Request element Optional
9 Intra-Access Category Priority element Optional
10 Higher Layer Stream ID element Only in AP-initiated TS setup
11 Multi-band Optional
12 U-PID Optional
13 Multiple MAC Sublayers Optional
1159
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The QoS Action field is defined in 9.6.3.1.
The values of the Dialog Token, TCLAS, and subsequent fields of this frame are the same as the values of
the corresponding parameters in the invocation of the MLME-ADDTS.request primitive that causes the
frame to be sent. Some of the TSPEC parameters have the same values as the corresponding parameters in
the invocation of the MLME-ADDTS.request primitive, while the values of the other fields (i.e., Surplus
Bandwidth Allowance, Minimum Service Interval, Maximum Service Interval, and Minimum PHY Rate)
are generated within the MAC.
The TSPEC element, defined in 9.4.2.30, and the optional TCLAS element, defined in 9.4.2.31, contain the
QoS parameters that define the TS. The TS is identified by the TSID and Direction fields within the TSPEC
element. The TCLAS element is optional at the discretion of the STA that sends the ADDTS Request frame,
regardless of the setting of the access policy (EDCA, SPCA, or HCCA). There are zero or more TCLAS
elements in the ADDTS frame. The TCLAS Processing element is present when there is more than one
TCLAS element and is defined in 9.4.2.33. An Expedited Bandwidth Request element is optionally present,
which is defined in 9.4.2.94.
The U-APSD Coexistence element, defined in 9.4.2.91, contains the coexistence parameters requested by
the non-AP STA when using the U-APSD coexistence capability as described in 11.2.3.5.2. The U-APSD
Coexistence element is optionally present.
An Intra-Access Category Priority element is optionally present, which is defined in 9.4.2.121 and described
in 11.4.1.
The Higher Layer Stream ID element (9.4.2.125) provides the stream identifier from a higher layer protocol.
The Higher Layer Stream ID element is present only in the AP-initiated TS setup (11.4.4.3).
When present in an ADDTS Request frame, the Multi-band element indicates the frequency band, operating
class, and channel number to which the ADDTS Request frame applies and contains band-specific
information.
When present in the ADDTS Request frame, the U-PID element indicates the upper layer protocol
associated with the TID/TSID specified within the TSPEC element contained in this frame.
When present in the ADDTS Request frame, the Multiple MAC Sublayers element is used to establish an
MMSL cluster.
9.6.3.2.2 DMG ADDTS Request frame variant
The DMG ADDTS Request frame is used by DMG STAs in a PBSS and in an infrastructure BSS. The
Action field of the DMG ADDTS Request frame contains the information shown in Table 9-290.
Table 9-290—DMG ADDTS Request frame variant Action field format
Order Information Notes
1 Category
2 Action
3 Dialog Token
1160
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-290—DMG ADDTS Request frame variant Action field format (continued)
Order Information Notes
4 DMG TSPEC
5 TSPEC Optional
6 TCLAS Optional
7 TCLAS Processing Optional
8 Multi-band Optional
9 U-PID Optional
10 Multiple MAC Sublayers Optional
11 Higher Layer Stream ID Optional
The values of the Dialog Token, DMG TSPEC, TSPEC, TCLAS, and subsequent fields of this frame are the
same as the values of the corresponding parameters in the invocation of the MLME-ADDTS.request
primitive that causes the frame to be sent.
The DMG TSPEC element contains the parameters that define an allocation. The allocation uniquely
identified by the Source AID, Allocation ID, and Destination AID subfields within the DMG TSPEC
element.
The optional TSPEC element defines a TS that can use the allocation if the allocation is created successfully.
The TCLAS element is optional and can be present only when a TSPEC element is present; it is used to
identify the destination non-AP and non-PCP DMG STA of the ADDTS Request frame. There can be one or
more TCLAS elements in the DMG ADDTS Request frame. The TCLAS Processing element is present if
there is more than one TCLAS element.
When present in a DMG ADDTS Request frame, the Multi-band element indicates the frequency band,
operating class, and channel number to which the TS identified by the optional TSPEC element applies.
When present in the DMG ADDTS Request frame, the U-PID element indicates the upper layer protocol
associated with the TS identified by the optional TSPEC element contained in this frame. If a TSPEC
element is not present in the frame, the U-PID element is not present in the frame.
When present in the DMG ADDTS Request frame, the Multiple MAC Sublayers element is used to establish
an MMSL cluster.
9.6.3.3 Basic and DMG ADDTS Response frame format
9.6.3.3.1 Basic ADDTS Response frame variant
The ADDTS Response frame is transmitted in response to an ADDTS Request frame. The Action field of
the ADDTS Response frame contains the information shown in Table 9-291.
1161
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-291—Basic ADDTS Response frame variant Action field format
Order Information Notes
1 Category
2 QoS Action
3 Dialog Token
4 Status Code
5 TS Delay
6 TSPEC
7 TCLAS Optional
8 TCLAS Processing Optional
9 Schedule Optionally present if the status code is equal to
SUCCESS; otherwise not present
10 Expedited Bandwidth Request Optional
11 Higher Layer Stream ID Only in AP-initiated TS setup
12 Multi-band Optional
13 U-PID Optional
14 Multiple MAC Sublayers Optional
The Category field is defined in 9.4.1.11.
The QoS Action field is defined in 9.6.3.1.
The Status Code field is defined in 9.4.1.9.
The values the Dialog Token, TS Delay, TSPEC, TCLAS, and subsequent fields in this frame are the same
as the values of the corresponding parameters in the invocation of the MLME-ADDTS.response primitive
that causes the frame to be sent. The TS Delay element is present in an ADDTS Response frame only if the
status code is equal to REJECTED_FOR_DELAY_PERIOD.
The Schedule element, defined in 9.4.2.34, is present in an ADDTS Response frame only if the status code is
equal to SUCCESS(i.e., when the TS is admitted).
The Higher Layer Stream ID element is present only in AP-initiated TS setup. The Higher Layer Stream ID
element (9.4.2.125) contains the stream identifier provided by a higher layer protocol.
When present in an ADDTS Response frame, the Multi-band element indicates the frequency band,
operating class, and channel number to which the ADDTS Response frame applies and contains band-
specific information.
When present in the ADDTS Response frame, the U-PID element indicates the upper layer protocol
associated with the TID/TSID specified within the TSPEC contained in this frame.
When present in the ADDTS Response frame, the Multiple MAC Sublayers element is used to establish an
MMSL cluster (see 11.34).
1162
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.3.3.2 DMG ADDTS Response frame variant
The DMG ADDTS Response frame is used by DMG STAs in a PBSS and in an infrastructure BSS. The
Action field of the DMG ADDTS Response frame contains the information shown in Table 9-292.
Table 9-292—DMG ADDTS Response frame variant Action field format
Order Information Notes
1 Category
2 Action
3 Dialog Token
4 Status code
5 TS Delay
6 DMG TSPEC
7 TSPEC Optional
8 TCLAS Optional
9 TCLAS Processing Optional
10 Multi-band Optional
11 U-PID Optional
12 Multiple MAC Sublayers Optional
13 Higher Layer Stream ID Optional
The values of the Dialog Token, TS Delay, DMG TSPEC, TSPEC, TCLAS, and subsequent fields in this
frame are the same as the values of the corresponding parameters in the invocation of the MLME-
ADDTS.response primitive that causes the frame to be sent. The TS Delay element is present in a DMG
ADDTS Response frame only if the status code is set to REJECTED_FOR_DELAY_PERIOD (9.4.1.9).
When present in a DMG ADDTS Response frame, the Multi-band element indicates the frequency band,
operating class, and channel number to which the TS identified by the optional TSPEC element applies.
When present in the DMG ADDTS Response frame, the U-PID element indicates the upper layer protocol
associated with the TS identified by the optional TSPEC contained in this frame. If a TSPEC element is not
present in the frame, the U-PID element is not present in the frame.
When present in the DMG ADDTS Response frame, the Multiple MAC Sublayers element is used to
establish an MMSL cluster (see 11.34).
9.6.3.4 DELTS frame format
The DELTS frame is used to delete a TS or an allocation using the procedures defined in 11.4.9.
The Action field of a DELTS frame contains the information shown in Table 9-293.
1163
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-293—DELTS frame Action field format
Order Information
1 Category
2 QoS Action
3 TS Info
4 Reason Code
5 DMG Allocation Info (optional)
6 Multi-band (optional)
The Category field is defined in 9.4.1.11.
The QoS Action field is defined in 9.6.3.1.
The TS Info field is defined in 9.4.2.30. Either the field identifies an existing TS created using the TSPEC
element, or all its subfields are set to 0. The DMG Allocation Info field, defined in 9.4.2.134, is present
when an existing DMG allocation is being deleted. When a DMG allocation is being deleted, the DMG
Allocation Info field identifies an existing allocation created using the DMG TSPEC element. When a DMG
allocation is not being deleted, all subfields in the DMG Allocation Info field are set to 0.
The Reason Code field is defined in 9.4.1.7.
A DELTS frame is used to delete a TS characterized by the TS Info field or to delete a DMG allocation
identified by the DMG Allocation Info field in the frame. A DELTS frame can be sent from the HC or PCP
to the source STA of that TS, or vice versa, to indicate an imperative request, to which no response is
required from the recipient STA.
When present in an DELTS frame, the Multi-band element indicates the frequency band, operating class,
and channel number to which the DELTS frame applies.
9.6.3.5 Schedule frame format
The Schedule frame is transmitted by the HC to announce the schedule of delivery of data and polls. The
Action field of the Schedule frame contains the information shown in Table 9-294.
Table 9-294—Schedule frame Action field format
Order Information
1 Category
2 QoS Action
3 Schedule
The Category field is defined in 9.4.1.11.
The QoS Action field is defined in 9.6.3.1.
The Schedule element is defined in 9.4.2.34.
1164
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.3.6 QoS Map Configure frame format
The QoS Map Configure frame is used by an AP to provide the QoS Map information to a non-AP STA
using the procedures defined in 11.25.9.
The Action field of the QoS Map Configure frame contains the information shown in Table 9-295.
Table 9-295—QoS Map Configure frame Action field format
Order Information
0 Category
1 Action
2 QoS Map
3 Intra-Access Category Priority elements (optional)
The Category field is defined in 9.4.1.11.
The Action field is defined in 9.6.3.1.
The QoS Map element is defined in 9.4.2.95.
Zero or more Intra-Access Category Priority elements are present, which are defined in 9.4.2.121.
9.6.3.7 ADDTS Reserve Request frame format
The ADDTS Reserve Request frame is transmitted by an AP to a non-AP STA in response to a higher layer
protocol. See 11.4.4.3.
The Action field of the ADDTS Reserve Request frame contains the information shown in Table 9-296.
Table 9-296—ADDTS Reserve Request frame Action field format
Order Information
1 Category
2 QoS Action
3 TSPEC
4 Schedule
5 Higher Layer Stream ID
The Category field is defined in 9.4.1.11.
The QoS Action field is defined in 9.6.3.1. ADDTS Reserve Request.
The TSPEC element contains the QoS parameters that define the TS. The QoS parameters in the TSPEC are
equivalent to the QoS parameters of the higher level stream identified by the Higher Level Stream ID. The
TS is identified by the TSID and Direction fields within the TSPEC element.
1165
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Schedule element is defined in 9.4.2.34 and set to reflect schedule information corresponding to the
TSPEC specification.
The Higher Layer Stream ID element (defined in 9.4.2.125) provides the stream identifier from a higher
layer protocol.
9.6.3.8 ADDTS Reserve Response frame format
An ADDTS Reserve Response frame is used by a non-AP STA to indicate the completion of an AP-initiated
TS setup procedure (11.4.4.3). The Action field of the ADDTS Reserve Response frame contains the
information shown in Table 9-297.
Table 9-297—ADDTS Reserve Response frame Action field format
Order Information
1 Category
2 QoS Action
3 Higher Layer Stream ID
4 Status Code
The Category field is defined in 9.4.1.11.
The QoS Action field is defined in 9.6.3.1. representing ADDTS Reserve Response.
The Higher Layer Stream ID is defined in 9.4.2.125.
The Status Code field is defined in 9.4.1.9.
9.6.4 DLS Action frame details
9.6.4.1 General
Several Action frame formats are defined for DLS management purposes. A DLS Action field, in the octet
field immediately after the Category field, differentiates the formats. The DLS Action field values
associated with each frame format are defined in Table 9-298.
Table 9-298—DLS Action field values
DLS Action field
Meaning
value
0 DLS Request
1 DLS Response
2 DLS Teardown
3–255 Reserved
1166
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.4.2 DLS Request frame format
The DLS Request frame is used to set up a direct link with a peer MAC. The Action field of the DLS
Request frame contains the information shown in Table 9-299, with some fields being optionally present as
indicated in the “Notes” column of the table.
Table 9-299—DLS Request frame Action field format
Order Information Notes
1 Category
2 DLS Action
3 Destination MACAddress
4 Source MACAddress
5 Capability Information
6 DLS Timeout Value
7 Supported Rates and BSS
Membership Selectors
8 Extended Supported Rates
and BSS Membership
Selectors
9 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
10 AID The AID element containing the AID of the STA sending the
frame is present if dot11VHTOptionImplemented is true.
11 VHT Capabilities The VHT Capabilities element is present if the
dot11VHTOptionImplemented is true.
The Category field is defined in 9.4.1.11.
The DLS Action field is defined in 9.6.4.1.
The Destination MAC Address field value is the MAC address of the target destination.
The Source MAC Address field value is the MAC address of the initiating STA.
The Capability Information field value is the capability information of the originator of the request.
The DLS Timeout Value field is defined in 9.4.1.13.
The Supported Rates and BSS Membership Selectors and Extended Supported Rates and BSS Membership
Selectors fields contain the supported rates information of the originator.
9.6.4.3 DLS Response frame format
The DLS Response frame is sent in response to a DLS Request frame. The Action field of a DLS Response
frame contains the information shown in Table 9-300, with some fields being optionally present as indicated
in the “Notes” column of the table.
1167
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-300—DLS Response frame Action field format
Order Information Notes
1 Category
2 DLS Action
3 Status Code
4 Destination MACAddress
5 Source MACAddress
6 Capability Information
7 Supported Rates and BSS
Membership Selectors
8 Extended Supported Rates
and BSS Membership
Selectors
9 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
10 AID The AID element containing the AID of the STA sending the
frame is present if dot11VHTOptionImplemented is true.
11 VHT Capabilities The VHT Capabilities element is present if the
dot11VHTOptionImplemented is true.
The Category field is defined in 9.4.1.11.
The DLS Action field is defined in 9.6.4.1.
The Status Code field is defined in 9.4.1.9.
The Destination MAC Address field value and the Source MAC Address field value are copied from the
corresponding fields in the DLS Request frame.
The Capability Information field is the capability information of the target destination. This information is
included only if the DLS result code corresponds to SUCCESS (DLS status code 0).
The Supported Rates and BSS Membership Selectors and Extended Supported Rates and BSS Membership
Selectors fields contain the supported rates information of the target destination. This information is
included only if the DLS result code corresponds to SUCCESS (DLS status code 0).
9.6.4.4 DLS Teardown frame format
The DLS Teardown frame is sent to terminate a direct link with a peer MAC. The Action field of the DLS
Teardown frame contains the information shown in Table 9-301.
1168
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-301—DLS Teardown frame Action field format
Order Information
1 Category
2 DLS Action
3 Destination MAC Address
4 Source MAC Address
5 Reason Code
The Category field is defined in 9.4.1.11.
The DLS Action field is defined in 9.6.4.1.
The Destination MAC Address field value is the MAC address of the target destination.
The Source MAC Address field value is the MAC address of the initiating STA.
The Reason Code field is defined in 9.4.1.7.
9.6.5 Block Ack Action frame details
9.6.5.1 General
ADDBA Request and ADDBA Response frames are used to set up or, if a STA is PBAC, to modify Block
Ack operation for a specific TC, TS, or GCR group address. A Block Ack Action field, in the octet
immediately after the Category field, differentiates the Block Ack Action frame formats. The Block
Ack Action field values associated with each frame format within the Block Ack category are defined in
Table 9-302.
Table 9-302—Block Ack Action field values
Block Ack Action
Meaning
field values
0 ADDBA Request
1 ADDBA Response
2 DELBA
3–255 Reserved
9.6.5.2 ADDBA Request frame format
An ADDBA Request frame is sent by an originator of block ack to another STA. The Action field of an
ADDBA Request frame contains the information shown in Table 9-303.
1169
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-303—ADDBA Request frame Action field format
Order Information
1 Category
2 Block Ack Action
3 Dialog Token
4 Block Ack Parameter Set
5 Block Ack Timeout Value
6 Block Ack Starting Sequence Control
7 GCR Group Address element (optional)
8 Multi-band (optional)
9 TCLAS (optional)
10 ADDBA Extension (optional)
The Category field is defined in 9.4.1.11.
The Block Ack Action field is defined in 9.6.5.1.
The Dialog Token field is set to a nonzero value chosen by the STA.
The Block Ack Parameter Set field is defined in 9.4.1.14.
The Block Ack Timeout Value field is defined in 9.4.1.15.
The Starting Sequence Number subfield of the Block Ack Starting Sequence Control field (see Figure 9-27)
contains the sequence number of the first or next (in the case of a renegotiation of a block ack agreement)
MSDU to be sent under this block ack agreement. The Fragment Number subfield is set to 0.
If the GCR Group Address element is present, the TID field within the Block Ack Parameter Set field is
reserved.
The GCR Group Address element contains the group address for which a block ack agreement is requested.
When present in an ADDBA Request frame, the Multi-band element indicates the frequency band, operating
class, and channel number to which the ADDBA Request frame applies and contains band-specific
information.
The ADDBA Extension element is defined in 9.4.2.139.
9.6.5.3 ADDBA Response frame format
The ADDBA Response frame is sent in response to an ADDBA Request frame. The Action field of an
ADDBA Response frame contains the information shown in Table 9-304.
1170
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-304—ADDBA Response frame Action field format
Order Information
1 Category
2 Block Ack Action
3 Dialog Token
4 Status Code
5 Block Ack Parameter Set
6 Block Ack Timeout Value
7 GCR Group Address element (optional)
8 Multi-band (optional)
9 TCLAS (optional)
10 ADDBA Extension (optional)
The Category field is defined in 9.4.1.11.
The Block Ack Action field is defined in 9.6.5.1.
The Dialog Token field value is copied from the corresponding received ADDBA Request frame.
The Status Code field is defined in 9.4.1.9.
The Block Ack Parameter Set field is defined in 9.4.1.14.
The Block Ack Timeout Value field is defined in 9.4.1.15.
If the GCR Group Address element is present, the TID field within the Block Ack Parameter Set field is
reserved.
The GCR Group Address element contains the group address for which a block ack agreement is requested.
When present in an ADDBA Response frame, the Multi-band element indicates the frequency band ID,
operating class, and channel number to which the ADDBA Response frame applies and contains band-
specific information.
The ADDBA Extension element is defined in 9.4.2.139.
9.6.5.4 DELBA frame format
The DELBA frame is sent by either the originator of the traffic or the recipient to terminate the block ack
participation. The Action field of a DELBA frame format contains the information shown in Table 9-305.
1171
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-305—DELBA frame Action field format
Order Information
1 Category
2 Block Ack Action
3 DELBA Parameter Set
4 Reason Code
5 DELBA GCR Group Address
6 Multi-band (optional)
7 TCLAS (optional)
The Category field is defined in 9.4.1.11.
The Block Ack Action field is defined in 9.6.5.1.
The DELBA Parameter Set field is defined in 9.4.1.16.
The Reason Code field is defined in 9.4.1.7.
The DELBA GCR Group Address field is defined in 9.4.2.126 and contains the GCR group address whose
block ack agreement is being terminated.
When present in an DELBA frame, the Multi-band element indicates the frequency band, operating class,
and channel number to which the DELBA frame applies.
9.6.6 Vendor-specific action details
The Vendor Specific frame is defined for vendor-specific signaling. The format of the Action field of the
Vendor Specific frame is shown in Figure 9-648. An Organization Identifier, in the octet field immediately
after the Category field, differentiates the vendors (see 9.4.1.32).
NOTE—If management frame protection is negotiated, then Vendor Specific Protected Action frames (see Table 9-47)
are protected; otherwise they are unprotected.
Organization
Category Vendor Specific Content
Identifier
Octets: 1 j variable
Figure 9-648—Vendor Specific frame Action field format
The Category field is defined in 9.4.1.11.
The Organization Identifier field contains a organization identifier assigned by the IEEE and is specified in
9.4.1.32. The order of the Organization Identifier field is described in 9.2.2.
The Vendor Specific Content field contains vendor-specific field(s). The length of the vendor specific
content in a Vendor Specific frame is limited by the maximum allowed MMPDU size.
1172
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.7 Radio Measurement action details
9.6.7.1 General
Several Action frame formats are defined for radio measurement purposes. A Radio Measurement Action
field, in the octet field immediately after the Category field, differentiates the formats. The Radio
Measurement Action field values associated with each frame format are defined in Table 9-306.
Table 9-306—Radio Measurement Action field values
Radio Measurement
Description
Action field value
0 Radio Measurement Request
1 Radio Measurement Report
2 Link Measurement Request
3 Link Measurement Report
4 Neighbor Report Request
5 Neighbor Report Response
6–255 Reserved
9.6.7.2 Radio Measurement Request frame format
The Radio Measurement Request frame uses the Action frame body format. It is transmitted to another STA
to request that it makes one or more measurements on one or more channels. The format of the Action field
in the Radio Measurement Request frame is shown in Figure 9-649.
Radio Measurement Number of Measurement Request
Category Dialog Token
Action Repetitions Elements
Octets: 1 1 1 2 variable
Figure 9-649—Radio Measurement Request frame Action field format
The Category field is defined in 9.4.1.11.
The Radio Measurement Action field is defined in 9.6.7.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the radio measurement request
to identify the request/report transaction.
The Number of Repetitions field contains the requested number of repetitions for all of the Measurement
Request elements in this frame. A value of 0 in the Number of Repetitions field indicates Measurement
Request elements are executed once without repetition. A value of 65 535 in the Number of Repetitions field
indicates Measurement Request elements are repeated until the measurement is canceled or superseded.
The Measurement Request Elements field contains zero or more of the Measurement Request elements
described in 9.4.2.21. The number and length of the Measurement Request elements in a Measurement
Request frame are limited by the maximum allowed MMPDU size.
1173
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.7.3 Radio Measurement Report frame format
The Radio Measurement Report frame uses the Action frame body format. It is transmitted in response to a
Radio Measurement Request frame or by a STA providing a triggered autonomous measurement report. The
format of the Action field in the Radio Measurement Report frame is shown in Figure 9-650.
Category Radio Measurement Dialog Token Measurement
Action Report Elements
Octets: 1 1 1 variable
Figure 9-650—Radio Measurement Report frame Action field format
The Category field is defined in 9.4.1.11.
The Radio Measurement Action field is defined in 9.6.7.1.
The Dialog Token field is set to the value in the corresponding Radio Measurement Request frame. If the
Radio Measurement Report frame is not being transmitted in response to a Radio Measurement Request
frame then the dialog token is set to 0.
The Measurement Report Elements field contains one or more Measurement Report elements described in
9.4.2.22. The number and length of the Measurement Report elements in a single Radio Measurement
Report frame are limited by the maximum allowed MMPDU size. Subclause 11.11.6 describes the required
behavior for multiframe Radio Measurement Report frame responses.
9.6.7.4 Link Measurement Request frame format
The Link Measurement Request frame is transmitted by a STA to request another STA to respond with a
Link Measurement Report frame to enable measurement of link path loss and estimation of link margin. In a
non-DMG BSS, a Link Measurement Request frame is an Action frame and in a DMG BSS, a Link
Measurement Request frame is an Action or an Action No Ack frame. The format of the Action field in the
Link Measurement Request frame is shown in Figure 9-651.
Radio Measurement Dialog Transmit Max Transmit
Category Action Token Power Used Power
Octets: 1 1 1 1 1
Figure 9-651—Link Measurement Request frame Action field format
The Category field is defined in 9.4.1.11.
The Radio Measurement Action field is defined in 9.6.7.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the request to identify the
transaction.
The Transmit Power Used field is set to the transmit power used to transmit the frame containing the Link
Measurement Request, as described in 9.4.1.20.
The Max Transmit Power field provides the upper limit on the transmit power as measured at the output of
the antenna connector to be used by the transmitting STA on its operating channel. This field is described in
9.4.1.19. The Max Transmit Power field is a 2s complement signed integer and is 1 octet in length,
1174
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
providing an upper limit, in a dBm scale, on the transmit power as measured at the output of the antenna
connector to be used by the transmitting STA on its operating channel. The maximum tolerance for the value
reported in Max Transmit Power field is ±5 dB. The value of the Max Transmit Power field is equal to the
minimum of the maximum powers at which the STA is permitted to transmit in the operating channel by
device capability, policy, and regulatory authority.
9.6.7.5 Link Measurement Report frame format
The Link Measurement Report frame is transmitted in response to a Link Measurement Request frame. In a
non-DMG BSS, a Link Measurement Report frame is an Action frame and in a DMG BSS, a Link
Measurement Report frame is an Action or an Action No Ack frame. The format of the Action field in the
Link Measurement Report frame is shown in Figure 9-652.
Radio Dialog TPC Receive Transmit DMG DMG Link
Category Measurement Report Antenna RCPI RSNI Link Adaptation
Action Token element ID Antenna ID Margin Acknowledgment
Octets: 1 1 1 4 1 1 1 1 variable variable
Figure 9-652—Link Measurement Report frame Action field format
The Category field is defined in 9.4.1.11.
The Radio Measurement Action field is defined in 9.6.7.1.
The Dialog Token field is set to the value of the Dialog Token field in the corresponding Link Measurement
Request frame.
The TPC Report element is set as described in 9.4.2.17.
The Receive Antenna ID field contains the identifying number for the antenna(s) used to receive the
corresponding Link Measurement Request frame. Antenna ID is defined in 9.4.2.40.
The Transmit Antenna ID field contains the identifying number for the antenna(s) used to transmit this Link
Measurement Report frame. Antenna ID is defined in 9.4.2.40.
RCPI indicates the received channel power of the corresponding Link Measurement Request frame, which is
a logarithmic function of the received signal power, as defined in 9.4.2.38.
RSNI indicates the received signal-to-noise indication for the corresponding Link Measurement Request
frame, as described in 9.4.2.41.
The DMG Link Margin field is optionally present. When present, it contains a DMG Link Margin element
(see 9.4.2.142).
The DMG Link Margin Adaptation Acknowledgment field is optionally present. When present, it contains a
DMG Link Margin Adaptation Acknowledgment element (see 9.4.2.143).
9.6.7.6 Neighbor Report Request frame format
The Neighbor Report Request frame uses the Action frame body format and is transmitted requesting
information in the neighbor report about neighboring APs. The format of the Action field in the Neighbor
Report Request frame is shown in Figure 9-653.
1175
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Location Civic
Radio Measurement SSID LCI Measurement Measurement
Category Dialog Token Request
Action (optional) (optional) Request
(optional)
Octets: 1 1 1 variable variable variable
Figure 9-653—Neighbor Report Request frame Action field format
The Category field is defined in 9.4.1.11.
The Radio Measurement Action field is defined in 9.6.7.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the measurement request to
identify the request/report transaction.
The SSID field is optionally present. If present, it contains an SSID element. The presence of an SSID
element in a Neighbor Report Request frame indicates a request for a neighbor list for the specified SSID in
the SSID Element. The absence of an SSID element indicates neighbor report for the current ESS.
The LCI Measurement Request field is optionally present. If present, it contains a Measurement Request
element with Measurement Type field equal to LCI (see Table 9-82), which indicates a request for a
Measurement Report subelement with Measurement Type field equal to LCI for each Neighbor Report
element (see 11.11.10.2). The Enable bit in the Measurement Request Mode field in the Measurement
Request element is set to 0. The Location Subject field in the Measurement Request field of the
Measurement Request element is set to Location Subject Remote (see Table 9-94). The Request, Report and
Duration Mandatory bits within the Measurement Request Mode field in the Measurement Request element
are reserved (see 9.4.2.21.1).
The Location Civic Measurement Request field is optionally present. If present, it contains a Measurement
Request element with Measurement Type field equal to Location Civic (see Table 9-82). The element
indicates a request for a Measurement Report subelement with Measurement Type field equal to Location
Civic for each Neighbor Report element (see 11.11.10.2). The Enable bit in the Measurement Request Mode
field within the Measurement Request element is set to 0. The Location Subject field in the Measurement
Request field of the Measurement Request element is equal to Location Subject Remote (see Table 9-94).
The Location Service Interval Units field in the Measurement Request field of the Measurement Request
element is set to 0. The Request, Report and Duration Mandatory bits in the Measurement Request Mode
field in the Measurement Request element are reserved (see 9.4.2.21.1).
9.6.7.7 Neighbor Report Response frame format
The Neighbor Report Response frame uses the Action frame body format and is transmitted in response to a
Neighbor Report Request frame. The format of the Action field in the Neighbor Report Response frame is
shown in Figure 9-654.
Category Radio Measurement Dialog Token Neighbor Report
Action Elements
Octets: 1 1 1 variable
Figure 9-654—Neighbor Report Response frame Action field format
The Category field is defined in 9.4.1.11.
The Radio Measurement Action field is defined in 9.6.7.1.
1176
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Dialog Token field set to the value in the corresponding Neighbor Report Request frame. If the
Neighbor Report Response frame is not being transmitted in response to a Neighbor Report Request frame,
then the dialog token is set to 0.
The Neighbor Report Elements field contains the Neighbor Report elements for validated APs described in
9.4.2.37. If the STA has no information in response to the Neighbor Report Request, the Neighbor Report
elements are omitted. The number and length of the Neighbor Report Elements in a Neighbor Report frame
is limited by the maximum allowed MMPDU size.
NOTE—Under some circumstances, a Neighbor Report element is included for the STA transmitting the frame. See
11.11.10.3.
9.6.8 Public Action details
9.6.8.1 Public Action frames
The Public Action frame is defined to allow the following:
— Inter-BSS and AP to unassociated-STA communications
— Intra-BSS communication
— GAS
A Public Action field, in the octet immediately after the Category field, differentiates the Public Action
frame formats. The defined Public Action frames are listed in Table 9-307.
Table 9-307—Public Action field values
Public Action field value Description
0 20/40 BSS Coexistence Management (see 9.6.8.2)
1 DSE enablement
2 DSE deenablement
3 DSE Registered Location Announcement
4 Extended Channel Switch Announcement
5 DSE measurement request
6 DSE measurement report
7 Measurement Pilot
8 DSE power constraint
9 Vendor Specific
10 GAS Initial Request (see 9.6.8.12)
11 GAS Initial Response (see 9.6.8.13)
12 GAS Comeback Request (see 9.6.8.14)
13 GAS Comeback Response (see 9.6.8.15)
14 TDLS Discovery Response
15 Location Track Notification
1177
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-307—Public Action field values (continued)
Public Action field value Description
16 QAB Request frame
17 QAB Response frame
18 QMF Policy
19 QMF Policy Change
20 QLoad Request
21 QLoad Report
22 HCCA TXOP Advertisement
23 HCCA TXOP Response
24 Public Key
25 Channel Availability Query
26 Channel Schedule Management
27 Contact Verification Signal
28 GDD Enablement Request
29 GDD Enablement Response
30 Network Channel Control
31 White Space Map Announcement
32 Fine Timing Measurement Request
33 Fine Timing Measurement
25–255 Reserved
9.6.8.2 20/40 BSS Coexistence Management frame format
The 20/40 BSS Coexistence Management frame is a Public Action frame. The format of its Action field is
defined in Table 9-308.
Table 9-308—20/40 BSS Coexistence Management frame Action field format
Order Information Notes
1 Category
2 Public Action
3 20/40 BSS Coexistence (see 9.4.2.60)
4 20/40 BSS Intolerant Channel Report (see 9.4.2.58) Appears zero or more times
The Category field is defined in 9.4.1.11.
1178
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Public Action field is defined in 9.6.8.1.
9.6.8.3 Measurement Pilot frame format
The Measurement Pilot frame uses the Action frame format. The format of the Action field is shown in
Figure 9-655.
Public Condensed Condensed Operating Measurement Optional
Category Capability Country Channel
Action Information String Class Pilot Interval Subelements
Octets: 1 1 1 2 1 1 1 variable
Figure 9-655—Measurement Pilot frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Condensed Capability Information field contains two subfields as shown in Figure 9-656.
B0 B1 B2 B7
Spectrum
Short Slot Time Reserved
Management
Bits: 1 1 6
Figure 9-656—Condensed Capability Information field
The Spectrum Management subfield is set to 1 if dot11SpectrumManagementRequired is true; otherwise, it
is set to 0.
The Short Slot Time subfield is set to 1 if dot11ShortSlotTimeOptionImplemented and
dot11ShortSlotTimeOptionActivated are true. Otherwise, the Short Slot Time subfield is set to 0.
The Condensed Country String field is set to the first two octets of the value contained in
dot11CountryString.
If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the
operating class value for the operating channel. The Country, Operating Class, and Channel Number fields
together specify the channel frequency and spacing for the operating channel. Valid operating classes are
listed in Annex E, excluding Operating Classes that encompass a primary channel but do not identify the
location of the primary channel. The Channel Number field indicates the operating channel. Channel
number is defined within an operating class as shown in Annex E.
If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel
Switch subelement indicate the operating channel, and the Operating Class and Channel Number together
specify the primary channel and primary 40 MHz channel within the channel identified by the Wide
Bandwidth Channel Switch subelement.
The Measurement Pilot Interval field is set to the value contained in dot11RMMeasurementPilotPeriod.
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
1179
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Subelement ID field values for the defined subelements are shown in Table 9-309.
Table 9-309—Optional subelement IDs for Measurement Pilot frame
Subelement ID Name Extensible
0–70 Reserved
71 Multiple BSSID Subelements
72–162 Reserved
163 Wide Bandwidth Channel Switch Yes
164–255 Reserved
The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see
9.4.2.161) with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80
MHz BSS bandwidth.
The Multiple BSSID and Vendor Specific subelements have the same format as the Multiple BSSID and
Vendor Specific elements (see 9.4.2.46 and 9.4.2.36, respectively). Multiple Vendor Specific subelements
may be included in the list of optional subelements.
9.6.8.4 DSE Enablement frame format
The DSE Enablement frame is an Action frame. It is transmitted as part of enablement. The format of the
DSE Enablement frame Action field is shown in Figure 9-657.
Requester Responder Reason Enablement
Category Public Action
STA Address STA Address Result Code Identifier
Octets: 1 1 6 6 1 2
Figure 9-657—DSE Enablement frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The RequesterSTAAddress field is the MAC address of the requesting STA that initiates the enablement
process. The length of the RequesterSTAAddress field is 6 octets.
The ResponderSTAAddress field is the MAC address of the enablement responder. The length of the
ResponderSTAAddress field is 6 octets.
The Reason Result Code field is used to indicate the reason that a DSE Enablement frame was generated.
The length of the Reason Result Code field is 1 octet. The reason result codes that have been allocated are
shown in Table 9-310.
The Enablement Identifier field is a 16-bit number assigned by an enabling STA to a dependent STA;
otherwise, it is 0, set using the procedures defined in 11.12.
1180
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-310—Reason Result Code field values
Reason Result
Name Description
Code field value
0 Reserved
1 Reserved
2 Enablement requested
3 SUCCESS Success
4 REFUSED Request declined
5 INVALID_PARAMETERS Request not successful as one or more parameters
have invalid values
6 TOO_MANY_ Enablement denied because the enabling STA is
SIMULTANEOUS_REQUESTS unable to handle additional dependent STAs
7–255 Reserved
9.6.8.5 DSE Deenablement frame format
The DSE Deenablement frame is an Action frame. It is transmitted as part of deenablement. The format of
the DSE Deenablement frame Action field is shown in Figure 9-658.
Requester STA Responder STA Reason Result
Category Public Action
Address Address Code
Octets: 1 1 6 6 1
Figure 9-658—DSE Deenablement frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The RequesterSTAAddress field is the MAC address of the requesting STA that initiates the deenablement
process. The length of the RequesterSTAAddress field is 6 octets.
The ResponderSTAAddress field is the MAC address of the responding STA that becomes deenabled. The
length of the ResponderSTAAddress field is 6 octets.
The Reason Result Code field is used to indicate the reason that a DSE Deenablement frame was generated.
The length of the Reason Result Code field is 1 octet. The reason result codes that have been allocated are
shown in Table 9-311.
Table 9-311—Reason Result Code field values
Reason Result Code field value Description
0 Reserved
1 Reserved
2 Deenablement requested
3–255 Reserved
1181
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.8.6 DSE Registered Location Announcement frame format
The DSE Registered Location Announcement frame is transmitted by a dependent STA to advertise the
registered location of its enabling STA. The format of the DSE Registered Location Announcement frame
Action field is shown in Figure 9-659.
Category Public Action DSE Registered Location Information
Octets: 1 1 20
Figure 9-659—DSE Registered Location Announcement frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The DSE Registered Location Information field is defined in 9.4.2.52.
9.6.8.7 Extended Channel Switch Announcement frame format
The Extended Channel Switch Announcement frame is transmitted by an AP, IBSS STA, or mesh STA to
advertise a channel switch. The format of the Extended Channel Switch Announcement frame Action field
is shown in Figure 9-660.
Zero or Zero or Zero or
one one more
Mesh Wide New
Channel New New Channel Channel New Bandwidth Transmit
Public
Category Action Switch Operating Channel Switch Switch Country Channel Power
Mode Class Number Count Parameters element Switch Envelope
element element element
Octets: 1 1 1 1 1 1 0 or 8 variable variable variable
Figure 9-660—Extended Channel Switch Announcement frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Channel Switch Mode, New Operating Class, New Channel Number, and Channel Switch Count fields
are as described in the Extended Channel Switch Announcement element (see 9.4.2.53).
Mesh Channel Switch Parameters element is defined in 9.4.2.103. This element is present when a mesh STA
performs MBSS channel switching. The Mesh Channel Switch Parameters element is not included for
channel switching other than for a MBSS channel switch.
The New Country element is present when an AP or mesh STA performs extended channel switching to a
new Country, new Operating Class Table, or a changed set of operating classes relative to the contents of the
Country element sent in the Beacon; otherwise, this element is not present. The format of the New Country
element is defined to be the same as the format of the Country element (see 9.4.2.9), except that no Subband
Triplet fields are present in the New Country element. The Country String field in the New Country element
indicates the Country and Operating Class Table of the BSS after extended channel switching and Operating
Triplet fields within the New Country element indicate the operating classes of the BSS after extended
channel switching (see 11.40.1).
1182
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This Wide Bandwidth Channel Switch element is present when extended channel switching to a channel
width wider than 40 MHz; otherwise, this element is not present. The Wide Bandwidth Channel Switch
element is defined in 9.4.2.161. The Wide Bandwidth Channel Switch element indicates the BSS bandwidth
after extended channel switching (see 11.40.1).
Each New Transmit Power Envelope element that is present is defined to have the same format as the
Transmit Power Envelope element (see 9.4.2.162) and includes a distinct value of the Local Maximum
Transmit Power Unit Interpretation subfield. If present, the New Transmit Power Envelope element
indicates the maximum transmit powers for the BSS for the indicated bandwidths with an indicated unit
interpretation after extended channel switching (see 11.40.1).
9.6.8.8 DSE Measurement Request frame format
The DSE Measurement Request frame is a Public Action frame requesting a DSE measurement report. It is
transmitted using the procedures defined in 11.12. The format of the DSE Measurement Request frame
Action field is shown in Figure 9-661.
Public Requester Responder Operating Channel Measurement Measurement
Category STA STA
Action Address Address Class Number Start Time Duration
Octets: 1 1 6 6 1 1 8 2
Figure 9-661—DSE Measurement Request frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The RequesterSTAAddress field is the MAC address of the STA that requests the DSE measurement report.
The length of the RequesterSTAAddress field is 6 octets.
The ResponderSTAAddress field is the MAC address of the responding STA that operates based on the
enablement. The length of the ResponderSTAAddress field is 6 octets.
The Operating Class field indicates the channel set for which the measurement request applies. The
Operating Class and Channel Number fields together specify the channel frequency and channel bandwidth
for which the measurement request applies. Valid values for the Operating Class field are shown in
Annex E.
The Measurement Start Time field is set to the timing synchronization function (TSF) at the time (± 1 TU) at
which the requested DSE request measurement starts. A value of 0 indicates it starts immediately.
The Measurement Duration field is set to the duration of the requested measurement, expressed in number of
time units (TUs).
9.6.8.9 DSE Measurement Report frame format
The DSE Measurement Report frame is a Public Action frame. It is transmitted using the procedures defined
in 11.12. The format of the DSE Measurement Report frame Action field is shown in Figure 9-662.
1183
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Measure
Public Requester Responder Operating Channel ment Actual Measurem Reported
Category Action STA STA Length Class Number Report Measureme ent DSE LCI
Address Address Mode nt Start Time Duration fields
Octets: 1 1 6 6 2 1 1 1 8 2 n × 26
Figure 9-662—DSE Measurement Report frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The RequesterSTAAddress field is the MAC address of the STA that requested the DSE measurement
report. The length of the RequesterSTAAddress field is 6 octets.
The ResponderSTAAddress field is the MAC address of the responding STA that operates based on the
enablement. The length of the ResponderSTAAddress field is 6 octets.
The Length field indicates the length of the remaining frame fields in octets, and the value is variable. The
minimum value of the Length field is 13.
The Operating Class field indicates the channel set for which the measurement report applies. The Operating
Class and Channel Number fields together specify the channel frequency and spacing for which the
measurement request applies. Valid values for the Operating Class field are shown in Annex E.
The Measurement Report Mode field is as defined in 9.4.2.22 (see Figure 9-192).
The Actual Measurement Start Time field is set to the measuring STA’s TSF timer at the time (± 1 TU) at
which the DSE measurement started.
The Measurement Duration field is set to the duration over which the requested measurement was measured,
expressed in number of TUs.
The reported DSE LCI fields contain the DSE LCI received at the measuring STA. If the reported DSE LCI
fields would cause the frame to exceed the maximum MAC management protocol data unit (MMPDU) size,
then the reported DSE LCI fields are truncated so that the last reported DSE LCI field is complete. The DSE
LCI field format is shown in Figure 9-663.
B0 B47 B48 B53 B54 B87 B88 B93 B94 B127 B128 B131 B132 B137 B138 B167
SA MAC Latitude Longitude Altitude Altitude
Latitude Longitude Altitude
Address Uncertainty Uncertainty Type Uncertainty
Bits: 48 6 34 6 34 4 6 30
B168 B170 B171 B172 B173 B174 B175 B176 B191 B192 B199 B200 B207
RegLoc Dependent Dependent Operating Channel
Datum RegLoc DSE Version Enablement
Agreement STA Identifier Class Number
Bits: 3 1 1 1 2 16 8 8
Figure 9-663—DSE LCI field format
1184
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SA MAC Address field contains the SA MAC address from the Beacon or Public Action frame
containing a DSE Registered Location element being reported.
The remaining fields are as defined in the DSE Registered Location Information field (see 9.4.2.52).
9.6.8.10 DSE Power Constraint frame format
The DSE Power Constraint frame is a Public Action frame requesting that a dependent STA constrain
transmit power below the regulatory limit. It is transmitted by an enabling STA as part of enablement. The
format of the DSE Power Constraint frame Action field is shown in Figure 9-664.
Category Public Action Requester Responder Reason Local Power
STA Address STA Address Result Code Constraint
Octets: 1 1 6 6 1 1
Figure 9-664—DSE Power Constraint frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The RequesterSTAAddress field is the MAC address of the STA that requests the DSE power constraint.
The length of the RequesterSTAAddress field is 6 octets.
The ResponderSTAAddress field is the MAC address of the responding STA that initiates the enablement.
The length of the ResponderSTAAddress field is 6 octets.
The Reason Result Code field is used to indicate the reason that a DSE Power Constraint frame was
generated. The length of the Reason Result Code field is 1 octet. The reason result codes that have been
allocated are shown in Table 9-312.
Table 9-312—Reason Result Code field values
Reason Result Code
Name Description
field value
0 Reserved
1 Reserved
2 Power constraint requested
3 SUCCESS Success
4 REFUSED Refused — no reason specified
5 INVALID_PARAMETERS Request not successful as one or more
parameters have invalid values
6–255 Reserved
The Local Power Constraint field is coded as an unsigned integer in units of decibels relative to 1 mW. The
local maximum transmit power for a channel is thus defined as the maximum transmit power level specified
for the channel in the Country element minus the local power constraint specified for the channel in the DSE
Power Constraint frame.
1185
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.8.11 Vendor Specific Public Action frame format
The Vendor Specific Public Action frame is defined for vendor-specific signaling between unassociated
STAs. The format of the Action field of the Vendor Specific Public Action frame is shown in Figure 9-665.
Category Public Action Organization Vendor Specific
Identifier Content
Octets: 1 1 variable variable
Figure 9-665—Vendor Specific Public Action frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Organization Identifier field contains a organization identifier assigned by the IEEE and is specified in
9.4.1.32. The order of the Organization Identifier field is described in 9.2.2. The length of the Organization
Identifier field is variable, as specified in 9.4.1.32.
The Vendor Specific Content field contains vendor-specific field(s). The length of the vendor specific
content in a Vendor Specific frame is limited by the maximum allowed MMPDU size.
9.6.8.12 GAS Initial Request frame format
The GAS Initial Request frame is a Public Action frame. It is transmitted by a requesting STA to request
information from another STA. The format of the GAS Initial Request Action field is shown in Table 9-313.
Table 9-313—GAS Initial Request Action field format
Order Information
0 Category
1 Public Action
2 Dialog Token
3 Advertisement Protocol element
4 Query Request Length
5 Query Request
6 Multi-band (optional)
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA.
The Advertisement Protocol element is defined in 9.4.2.93. The Advertisement Protocol element includes
exactly one Advertisement Protocol ID.
1186
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Query Request Length field is defined in Figure 9-666. The value of the Query Request Length field is
set to the total number of octets in the Query Request field.
B0 B15
Query Request length
Octets: 2
Figure 9-666—Query Request Length field
The Query Request field is defined in Figure 9-667. The Query Request field is a generic container whose
value is a GAS Query that is formatted in accordance with the protocol identified in the Advertisement
Protocol element.
Query Request
Octets: variable
Figure 9-667—Query Request field
When present in a GAS Initial Request frame, the Multi-band element indicates the frequency band,
operating class, and channel number to which the GAS Initial Request frame applies.
9.6.8.13 GAS Initial Response frame format
The GAS Initial Response frame is a Public Action frame. It is transmitted responding to a GAS Initial
Request frame. The format of the GAS Initial Response Action field is shown in Table 9-314.
Table 9-314—GAS Initial Response Action field format
Order Information
0 Category
1 Public Action
2 Dialog Token
3 Status Code
4 GAS Comeback Delay
5 Advertisement Protocol element
6 Query Response Length
7 Query Response (optional)
8 Multi-band (optional)
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is copied from the corresponding GAS Initial Request frame.
1187
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Status Code values are defined in Table 9-46.
The GAS Comeback Delay field specifies the delay time value in TUs. The GAS Comeback Delay field
format is provided in Figure 9-668. The behavior is described in 11.25.3.2. The value 0 will be returned by
the STA when a Query Response is provided in this frame.
B0 B15
GAS Comeback Delay
Octets: 2
Figure 9-668—GAS Comeback Delay field
The Advertisement Protocol element is defined in 9.4.2.93. The Advertisement Protocol element includes
exactly one Advertisement Protocol ID.
The Query Response Length field is defined in Figure 9-669. The value of the Query Response Length field
is set to the total number of octets in the Query Response field. If the Query Response Length field is set to
0, then there is no Query Response included in this Action frame.
B0 B15
Query Response Length
Octets: 2
Figure 9-669—Query Response Length field
The Query Response field is defined in Figure 9-670. The Query Response field is a generic container
whose value is the response to a GAS Query and is formatted in accordance with the protocol specified in
the Advertisement Protocol element.
Query Response
Octets: variable
Figure 9-670—Query Response field
When present in a GAS Initial Response frame, the Multi-band element indicates the frequency band,
operating class, and channel number to which the GAS Initial Response frame applies.
9.6.8.14 GAS Comeback Request frame format
The GAS Comeback Request frame is a Public Action frame. It is transmitted by a requesting STA to a
responding STA. The format of the GAS Comeback Request Action field is shown in Table 9-315.
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is copied from the corresponding GAS Initial Request frame.
When present in a GAS Comeback Request frame, the Multi-band element indicates the frequency band,
operating class, and channel number to which the GAS Comeback Request frame applies.
1188
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-315—GAS Comeback Request Action field format
Order Information
0 Category
1 Public Action
2 Dialog Token
3 Multi-band (optional)
9.6.8.15 GAS Comeback Response frame format
The GAS Comeback Response frame is a Public Action frame. It is transmitted by a responding STA to a
requesting STA. The format of the GAS Comeback Response Action field is shown in Table 9-316.
Table 9-316—GAS Comeback Response Action field format
Order Information
0 Category
1 Public Action
2 Dialog Token
3 Status Code
4 GAS Query Response Fragment ID
5 GAS Comeback Delay
6 Advertisement Protocol element
7 Query Response Length
8 Query Response (optional)
9 Multi-band (optional)
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is copied from the Dialog Token field of the corresponding GAS Comeback Request
frame. The same value of the Dialog Token field is present in all fragments of a multi-fragment query
response.
The Status Code values are defined in Table 9-46. The same status code value will be present in all
fragments of a multi-fragment query response.
The GAS Query Response Fragment ID is defined in 9.4.1.34. If the responding STA has not received a
response to the query that it posted on behalf of a requesting STA, then the responding STA sets the GAS
Query Response Fragment ID to 0. When there is more than one query response fragment, the responding
STA sets the GAS Query Response Fragment ID to 0 for the initial fragment and increments it by 1 for each
1189
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
subsequent fragment in a multi-fragment Query Response. The More GAS Fragments field is set to 0
whenever the final fragment of a query response is being transmitted. A GAS Query Response Fragment ID
field having a nonzero Fragment ID and the More GAS Fragments field set to 1 indicates to the requesting
STA that another GAS Comeback frame exchange should be performed to continue the retrieval of the
query response.
The GAS Comeback Delay field format is provided in Figure 9-668. A nonzero GAS Comeback Delay
value is returned by the responding STA in this frame to indicate that the GAS Query being carried out on
behalf of the requesting STA is still in progress.
— A nonzero value indicates to the requesting STA that another GAS Comeback frame exchange
should be performed after the expiration of the GAS Comeback Delay timer in order to retrieve the
query response.
— This field is set to 0 for all GAS Comeback Response frames containing a query response or a
fragment of a multi-fragment query response.
The Advertisement Protocol element is defined in 9.4.2.93. The Advertisement Protocol element includes
exactly one Advertisement Protocol ID.
The Query Response Length field is defined in Figure 9-669. The value of the Query Response Length field
is the total number of octets in the Query Response field. If the Query Response Length field is set to 0, then
there is no Query Response included in this Action frame.
The Query Response field is defined in Figure 9-670. The value of the Query Response field is a generic
container dependent on the advertisement protocol specified in the Advertisement Protocol element and the
query itself. In a multi-fragment query response, the response to the query posted on behalf of a requesting
STA is fragmented such that each fragment to be transmitted fits within the MMPDU size limitation.
When present in a GAS Comeback Response frame, the Multi-band element indicates the frequency band,
operating class, and channel number to which the GAS Comeback Response frame applies.
9.6.8.16 TDLS Discovery Response frame format
The format of the TDLS Discovery Response Action field is shown in Table 9-317.
Table 9-317—TDLS Discovery Response Action field format
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 Public Action The Public Action field is defined in 9.6.8.1.
3 Dialog Token The dialog token is copied from the corresponding TDLS
Discovery Request frame. The dialog token is specified in 9.4.1.12.
4 Capability The Capability field indicates the capabilities of the STA. The
Capability field is defined in 9.4.1.4.
5 Supported Rates and BSS The Supported Rates and BSS Membership Selectors element
Membership Selectors indicates the rates which are supported by the STA. The Supported
Rates and BSS Membership Selectors element is defined in 9.4.2.3.
6 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors
and BSS Membership element is present whenever there are more than eight supported
Selectors rates, and it is optional otherwise. The Extended Supported Rates
and BSS Membership Selectors element is defined in 9.4.2.13.
1190
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-317—TDLS Discovery Response Action field format (continued)
Order Information Notes
7 Supported Channels The Supported Channels element is present if the TDLS channel
switching capability field is equal to 1.
The Supported Channels element is defined in 9.4.2.18.
8 RSNE The RSNE is optionally present if security is required on the direct
link.
The RSNE is defined in 9.4.2.25.
9 Extended Capabilities The Extended Capabilities element is optionally present if any of
the fields in this element are nonzero. The Extended Capabilities
element is defined in 9.4.2.27.
10 FTE The FTE is optionally present if security is required on the direct
link. The FTE is defined in 9.4.2.48.
11 Timeout Interval (TPK key The Timeout Interval element contains the TPK key lifetime.
lifetime) It is present if security is required on the direct link.
The Timeout Interval element is defined in 9.4.2.49.
12 Supported Operating The Supported Operating Classes element is present if the TDLS
Classes channel switching capability field is equal to 1.
The Supported Operating Classes element is defined in 9.4.2.54.
13 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
The HT Capabilities element is defined in 9.4.2.56.
14 20/40 BSS Coexistence The 20/40 BSS Coexistence element is present when
dot112040BSSCoexistenceManagementSupport is true. The 20/40
BSS Coexistence element is defined in 9.4.2.60.
15 Link Identifier The Link Identifier element is defined in 9.4.2.62.
16 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
17 VHT Capabilities VHT Capabilities element (optional). The VHT Capabilities
element is present if the dot11VHTOptionImplemented is true. The
VHT Capabilities element is defined in 9.4.2.158.
The TDLS Discovery Response frame is transmitted directly (i.e., not via the AP) to the TDLS peer STA
that sent the corresponding TDLS Discovery Request frame. See 11.23.
9.6.8.17 Location Track Notification frame format
The Location Track Notification frame uses the Action frame body format and is transmitted to allow
remote location determination to occur by another STA. The format of the Location Track Notification
Action field is shown in Figure 9-671.
Public Location Parameters Measurement Report
Category
Action Element Element (optional)
Octets: 1 1 variable variable
Figure 9-671—Location Track Notification Action field format
The Category field is defined in 9.4.1.11.
1191
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Public Action field is defined in 9.6.8.1.
The Location Parameters Element field contains the Location Parameters subelements, described in Table 9-
191. Table 9-318 defines the allowed Location Parameters subelements for a Location Parameters element
that is included in the frame.
Table 9-318—Location Parameters Element field for
Location Track Notification frame
Allowed Subelement
Notes
subelements ID
Location Indication 2 The Location Indication Channels subelement is included in the Location
Channels Track Notification frame.
Radio Information 4 The Radio subelement is included in the Location Track Notification
frame.
Motion 5 The Motion subelement is included in the Location Track Notification
frame if dot11MotionDetectionActivated is true.
Time of Departure 7 The Time of Departure subelement is included in the Location Track
Notification frame if dot11TODActivated is true.
Location Indication 8 The Location Indication Options subelement is included in the Location
Options Track Notification frame if the successful Location Configuration Request
frame that configured the STA included a Location Indication Options
subelement.
The Measurement Report Element field contains a Measurement Report element of type Beacon report as
defined in 9.4.2.22.7. The Measurement Report Element field is included in the Location Track Notification
frame if the Location Parameters Element field contains a Location Indication Options subelement. The
Measurement Report element Measurement Token field is set to the same value of the dialog token in the
Location Configuration Request frame that configured the STA.
9.6.8.18 QMF Policy frame format
The QMF Policy frame uses the Action frame format and is transmitted by a requesting STA to a receiving
STA with the included QMF policy. It is either sent unsolicited by the requesting STA or in response to a
QMF Policy Change frame from a receiving STA. The format of the Action field of the QMF Policy frame
is shown in Figure 9-672.
Category Public Action Dialog Token Status Code QMF Policy element
(optional)
Octets: 1 1 1 2 0 or 3-257
Figure 9-672—QMF Policy frame Action field contents
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is set to the value in the corresponding QMF Policy Change frame. If the QMF Pol-
icy frame is not being transmitted in response to a QMF Policy Change frame, then the Dialog Token field is
set to 0.
1192
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Status Code field is defined in Table 9.4.1.9.
The QMF Policy element is set as described in 9.4.2.120. It indicates the new access categories configured
for Management frame(s). This field is included if the Status Code is SUCCESS and this frame is not being
transmitted in response to a QMF Policy Change frame, and optionally included if the Status Code is
REQUEST_DECLINED.
9.6.8.19 QMF Policy Change frame format
The QMF Policy Change frame uses the Action frame format and is transmitted by a requesting STA to
request a change to the QMF policy it most recently received from the destination STA. The format of the
Action field of the QMF Policy Change frame is shown in Figure 9-673.
Category Public Action Dialog Token QMF Policy element
Octets: 1 1 1 3-257
Figure 9-673—QMF Policy Change Action field contents
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the QMF Policy Change frame
to identify the transaction.
The QMF Policy element is set as described in 9.4.2.120. It indicates the access categories requested for
Management frame(s), including any changes to the QMF policy it most recently received from the destina-
tion STA.
9.6.8.20 QLoad Request frame format
The QLoad Request frame is transmitted by an AP to request information from another AP. The Action field
format of the QLoad Request frame is shown in Table 9-319.
Table 9-319—QLoad Request frame Action field format
Order Information
1 Category
2 Public Action
3 Dialog Token
4 QLoad Report element
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA to a nonzero value that is used
for matching action responses with action requests. See 10.27.5.
1193
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The QLoad Report element is defined in 9.4.2.123 and contains the QLoad report corresponding to the AP
sending the request.
9.6.8.21 QLoad Report frame format
The QLoad Report frame is transmitted by an AP responding to a QLoad Request frame. The Action field
format of the QLoad Report frame is shown in Table 9-320.
Table 9-320—QLoad Report frame Action field format
Order Information
1 Category
2 Public Action
3 Dialog Token
4 QLoad Report element
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA to a nonzero value that is used
for matching action responses with action requests. See 10.27.5. The Dialog Token field is set to 0 when an
unsolicited QLoad Report frame is sent by the AP.
The QLoad Report element is defined in 9.4.2.123.
9.6.8.22 HCCA TXOP Advertisement frame
The HCCA TXOP Advertisement frame is transmitted by an AP to another AP to inform it of active and
pending TXOP reservations. The Action field format of the HCCA TXOP Advertisement frame is shown in
Figure 9-674.
Number of Number of Active Pending
Public Dialog Reported Pending
Category Action Token TXOP TXOP TXOP TXOP
Reservations Reservations
Reservations Reservations
Octets: 1 1 1 1 1 variable variable
Figure 9-674—HCCA TXOP Advertisement frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is defined in 9.4.1.12 and is set by the AP to a nonzero value that is used for
matching action responses with action requests. See 10.27.5.
1194
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Number of Reported TXOP Reservations field is 1 octet in length and contains a positive integer that
specifies the number of active TXOP reservations reported in this frame. A value of 0 indicates that no
TXOP reservations are active.
The Number of Pending Reported TXOP Reservations field is 1 octet in length and contains a positive
integer that specifies the number of pending TXOP reservations reported in this frame. A value of 0
indicates that no TXOP reservations are in the process of being activated.
The Active TXOP Reservation field contains zero or more TXOP Reservation fields as defined in 9.4.1.44.
This field indicates active HCCA TXOPs that the AP has scheduled. The Start Time subfield of the TXOP
Reservation field is relative to the TSF of the sending AP.
The Pending TXOP Reservation field contains zero or more TXOP Reservation fields as defined in 9.4.1.44.
This field indicates new HCCA TXOPs that the AP is scheduling. The Start Time subfield of the TXOP
Reservation field is relative to the TSF of the sending AP.
The use of the HCCA TXOP Advertisement frame is described in 11.28.3.
9.6.8.23 HCCA TXOP Response frame
The HCCA TXOP Response frame is transmitted by an AP to another AP to respond to an HCCA TXOP
Advertisement frame. The Action field format of the HCCA TXOP Response frame is shown in Figure 9-
675.
Public Dialog Schedule Alternate Avoidance
Category Action Token Status Code Conflict Schedule Request
Octets: 1 1 1 2 0 or 1 0 or 6 0 or 6
Figure 9-675—HCCA TXOP Response frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is set to the value of the Dialog Token field from the corresponding HCCA TXOP
Advertisement frame.
The Status Code field is defined in 9.4.1.9 and is set to either the value SUCCESS or
TS_SCHEDULE_CONFLICT.
The Schedule Conflict field is present only when the Status Code field is not SUCCESS. The Schedule
Conflict field indicates the TXOP reservation from the HCCA TXOP Advertisement frame that conflicts
with an existing or in-progress schedule. Its value is between 1 and the summation of the values from the
Number of Reported TXOP Reservations and Number of Pending TXOP Reservations fields of the HCCA
TXOP Advertisement frame. A value of 1 indicates the first TXOP reservation in the HCCA TXOP
Advertisement frame, a value of 2 indicates the second TXOP reservation in the HCCA TXOP
Advertisement frame, and so on. The value of zero is reserved.
The optional Alternate Schedule field contains a TXOP Reservation field, as defined in 9.4.1.44 and is
present only when the Status Code field is not SUCCESS. When the Alternate Schedule field is present, it
contains an alternate to the TXOP reservation given in the corresponding HCCA TXOP Advertisement
frame. The Start Time subfield of the Alternate Schedule field is relative to the TSF of the destination AP.
1195
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The optional Avoidance Request field contains a TXOP Reservation field, as defined in 9.4.1.44 and is
optionally present when the Status Code field is not SUCCESS. When the Avoidance Request field is
present, it indicates a TXOP schedule that the AP sending the TXOP Response frame is requesting to be
avoided by the AP that is the destination of the TXOP Response frame. The Start Time subfield of the
Avoidance Request field is relative to the TSF of the destination AP.
The use of the HCCA TXOP Response frame is described in 11.28.3.
9.6.8.24 Public Key frame
The Public Key frame is transmitted by an AP to provide its public key to peer APs and to request the peer’s
public key. The format of the Public Key Action field is defined in Figure 9-676.
Category Public Public Key Group Public Key
Action Frame Usage (optional)
Octets: 1 1 1 2 variable
Figure 9-676—Public Key Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Public Key Frame Usage field is set to a number to signify the usage mode of this frame. The Request
Types are shown in Table 9-321.
Table 9-321—Public Key Frame Usage field values
Public Key Frame Usage Value
Request 0
Response 1
NAK 2
Refused 3
Reserved 4–255
The Public Key Frame Usage field is set to “Request” to indicate that a public key is being requested from a
peer AP.
The Public Key Frame Usage field is set to “Response” to indicate that this frame is in response to a Public
Key frame.
The Public Key Frame Usage field is set to “NAK” to indicate rejection of a received Public Key frame.
The Group field is used to indicate which cryptographic group was used when generating the public key and
is defined in 9.4.1.43), or the preferred group when the Public Key Frame Usage field is set to “NAK”.
When the Public Key Frame Usage field is set to “NAK” or “Refused”, the Public Key field is not included.
In all other cases, the Public Key field contains the public key of the AP that is sending this Public Key
frame encoded as an octet string according to 12.4.7.2.5.
1196
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The use of the Public Key frame is described in 12.11.
9.6.8.25 Channel Availability Query frame format
The Channel Availability Query frame is an Action frame. It is transmitted as part of channel query. The
format of the Channel Availability Query frame Action field is shown in Figure 9-677.
Category Public Requester Responder Reason Length Channel Device Device Device WSM
Action STA STA Result Query Class Identifi- Location Informa-
Address Address Code Info cation Informa- tion
Informa- tion
tion
Octets: 1 1 6 6 1 1 1 variable variable variable variable
Figure 9-677—Channel Availability Query frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Length field indicates the length of the remaining frame fields in octets, and the value is variable.
The remaining fields are as defined in the Channel Availability Query element (see 9.4.6.2) and White Space
Map element (see 9.4.2.170).
9.6.8.26 Channel Schedule Management frame format
The Channel Schedule Management frame is a Public Action frame. It is transmitted to exchange the
channel schedule information as part of the channel schedule management procedure. The format of the
Channel Schedule Management frame Action field is shown in Figure 9-678.
Category Public Requester Responder Length Reason Channel Device Channel
Action STA STA Result Schedule Identifi- Schedule
Address Address Code Management cation Descriptor
Mode Informa-
tion
Octets: 1 1 6 6 1 1 1 variable variable
Figure 9-678—Channel Schedule Management frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Requester STA Address field is the MAC address of the requesting STA that initiates the Channel
Schedule Management process.
The Responder STA Address field is the MAC address of the STA that responds to the STA that requested
channel schedule management.
The Length field indicates the length of the remaining fields in octets, and the value is variable.
The Reason Result Code field indicates the reason for transmitting a query request for channel schedule
information. It also indicates the result of a query as successful or not and the reason when the query is not
successful. The value of this field is defined in Table 9-322.
1197
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-322—Reason Result Code field values
Reason Result
Description
Code field values
0 Request for channel schedule information from a RLSS.
1 Request for channel schedule information from a GDD enabling STA.
2 Success, returning full channel schedule information on the requested channels.
3 Success, returning additional timeslots from the list of the last query on the requested
channels.
4 Success, returning timeslots deleted from the list of last query on the requested
channels.
5 Success, returning deleted and added timeslots from the list of last query on the
requested channels.
6 Success, returning no channel schedule changes from last query.
7 Request declined by the GDD enabling STA for unspecified reason.
8 Request declined by the GDD enabling STA because of no capability for providing
schedule information on WLAN channels.
9 Request declined by RLSS for unspecified reason.
10 Request declined by RLSS because of no capability for providing schedule information
on WLAN channels.
11 Unknown reason.
12 Continuation frame. This frame continues the fields from the previous CSM frame.
13–63 Reserved.
The Channel Schedule Management Mode field indicates if the schedule information of the channel
availability is based on TV channels or WLAN channels. If the schedule information is based on WLAN
channels, the optional Operating Class field is present in the Channel Schedule Descriptor field as defined in
E.1. This field also indicates whether the optional Channel Availability Starting Time field is present in the
Channel Schedule Descriptor field. The value of this field is defined in Table 9-323.
Table 9-323—Channel Schedule Management Mode field values
Channel
Schedule
Description
Management
Mode value
0 The channel schedule information is based on TV channels. The Reason Result Code field is set
to either 0 or 1.
1 The channel schedule information is based on WLAN channels. The Reason Result Code field is
set to either 0 or 1.
2–3 Reserved.
1198
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Device Identification Information field indicates the regulatory identification of the STA that is
requesting the schedule information. The Device Identification Information field is present only when
Reason Result Code is either 0 or 1. The value of the field is defined in 9.4.4.2.2.
The Channel Schedule Descriptor field indicates the channels for which the schedule information is
requested, and the channel schedule information is provided in the response. The value of the field is defined
in 9.4.4.2.4. The Channel Schedule Descriptor field is repeated, as determined by the Length field.
9.6.8.27 Contact Verification Signal frame format
The Contact Verification Signal frame is a Public Action frame that is transmitted by a GDD enabling STA
to notify whether the available channel information from the GDB has been updated. The format of the
Contact Verification Signal frame Action field is shown in Figure 9-679.
Category Public Action Map ID
Octets: 1 1 1
Figure 9-679—Contact Verification Signal frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Map ID field is set to a number that is equal to the Map ID of the recently received WSM. The WSM is
defined in Table 9-269 in 9.4.4.2.5.
9.6.8.28 GDD Enablement Request frame format
The GDD Enablement Request frame is a Public Action frame. The format of the GDD Enablement Request
frame action field is shown in Figure 9-680.
Category Public Action Dialog Token Device Class Device
Identification
Information
Octets: 1 1 1 1 variable
Figure 9-680—GDD Enablement Request frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is a nonzero value chosen by the STA sending the GDD Enablement Request frame
to identify the request/response transaction.
The Device Class field is used to indicate the characteristic of the STA requesting the GDD Enablement
Request frame. The format of the Device Class field is specified in 9.4.4.2.1.
The Device Identification Information field is used to indicate the identification of the STA requesting the
GDD Enablement Request frame. The format of the Device Identification Information field is specified in
9.4.4.2.2.
1199
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.8.29 GDD Enablement Response frame format
The GDD Enablement Response frame is a Public Action frame. The format of the GDD Enablement
Response frame action field is shown in Figure 9-681.
Category Public Action Dialog Token Status Code WSM
Information
Octets: 1 1 1 2 variable
Figure 9-681—GDD Enablement Response frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is a nonzero value of the corresponding GDD Enablement Request frame. If a GDD
Enablement Response frame is being transmitted other than in response to an GDD Enablement Request
frame, then the Dialog Token field is 0.
The Status Code field contains the status code in response to a GDD Enablement Request frame as defined
in Table 9-46.
The remaining field is as defined in the WSM element (see 9.4.2.170).
9.6.8.30 Network Channel Control frame format
The Network Channel Control frame is a Public Action frame. It is transmitted by a GDD dependent STA
and a GDD enabling STA as part of the procedure that allows a GDD enabling STA to control the frequency
usage of a GDD dependent STA’s WLAN network channels. The format of the Network Channel Control
frame is shown in Figure 9-682.
a Network Channel Control triplet
Category Public Length Requester Responder Reason Number of Operating Channel Maximum
Action STA STA Result Network Class Number Transmit
Address Address Code Channel Power
Control
Triplets
Octets: 1 1 1 6 6 1 1 1 1 1
Figure 9-682—Network Channel Control frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Length field indicates the length of the remaining frame fields in octets, and the value is variable. The
minimum value of the Length field is 14.
The Requester STA Address field is the MAC address of the requesting STA that initiates the network
channel control process.
The Responder STA Address field is the MAC address of the STA that responds to the STA that requested
network channel control.
1200
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Reason Result Code field is used to indicate the reason that a Network Channel Control frame was
generated. The length of the Reason Result Code field is 1 octet. The encoding of the Reason Result Code
field is shown in Table 9-282.
The Number of Network Channel Control Triplets field indicates the number of triplets of Operating Class,
Channel Number, and Maximum Transmit Power fields.
The Operating Class field indicates the channel set for which the network channel control request applies.
The Operating Class and Channel Number fields together specify the channel frequency and channel
bandwidth for which the network channel control applies. Values for the Operating Class field are shown in
E.1.
In a request, the Channel Number field of the Network Channel Control frame indicates the channel that the
requesting STA intends to operate on. In the response, the Channel Number field in the Network Channel
Control frame indicates the channels that the responding STA permits the requesting STA to operate on. The
Channel Number is defined within an Operating Class as shown in E.1.
The Maximum Transmit Power field gives the intended maximum transmit power in dBm for operation in
the request frame and indicates the maximum allowable transmit power in dBm for operation in the response
frame. The field contains EIRP per channel bandwidth and is coded as a signed integer in units of 0.5 dBm.
The field is set to 0 when a requesting STA requests a responding STA to provide a network channel control
response without specifying in the request the intended maximum transmit power.
9.6.8.31 White Space Map Announcement frame format
The White Space Map Announcement frame is a Public Action frame. The format of the White Space Map
Announcement frame body is shown in Figure 9-683.
Category Public Action Reason Result White Space
Code Map
Octets: 1 1 1 variable
Figure 9-683—White Space Map Announcement frame Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
A Reason Result Code value of 1 indicates the Public Action frame is a continuation of the previous WSM
Public Action frame, and any other value indicates this is not a continuation of the previous WSM Public
Action frame.
The White Space Map field contains a White Space Map element (see 9.4.2.170).
9.6.8.32 Fine Timing Measurement Request frame format
The format of the Fine Timing Measurement Request Action field is shown in Figure 9-684.
1201
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
LCI Location Civic Fine Timing
Public Measurement Measurement Measurement
Category Trigger
Action Request Request Parameters
(optional) (optional) (optional)
Octets: 1 1 1 variable variable variable
Figure 9-684—Fine Timing Measurement Request Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Trigger field set to 1 indicates that the initiating STA requests that the responding STA start or continue
sending Fine Timing Measurement frames (see 11.24.6). The Trigger field set to 0 indicates that the
initiating STA requests that the responding STA stop sending Fine Timing Measurement frames. Trigger
field values 2–255 are reserved.
The LCI Measurement Request field is optionally present. If present, it contains a Measurement Request
element with Measurement Type field equal to LCI (see Table 9-82), which indicates a request for a
Measurement Report element with Measurement Type field equal to LCI (see 11.24.6.7). The Enable bit in
the Measurement Request Mode field in the Measurement Request element is set to 0. The Location Subject
field in the Measurement Request field of the Measurement Request element is set to Location Subject
Remote (see Table 9-94). The Request, Report and Duration Mandatory bits in the Measurement Request
Mode field in the Measurement Request element are reserved (see 9.4.2.21.1).
The Location Civic Measurement Request field is optionally present. If present, it contains a Measurement
Request element with Measurement Type field equal to Location Civic (see Table 9-82), which indicates a
request for a Measurement Report element with Measurement Type field equal to Location Civic (see
11.24.6.7). The Enable bit in the Measurement Request Mode field in the Measurement Request element is
set to 0. The Location Subject field in the Measurement Request field of the Measurement Request element
is set to Location Subject Remote (see Table 9-94). The Location Service Interval Units field in the
Measurement Request field of the Measurement Request element is set to 0. The Request, Report and
Duration Mandatory bits in the Measurement Request Mode field within the Measurement Request element
are reserved (see 9.4.2.21.1).
The Fine Timing Measurement Parameters field is present in the initial Fine Timing Measurement Request
frame (see 11.24.6.3) and its retransmissions and is not present in subsequent Fine Timing Measurement
Request frames. If present, it contains a Fine Timing Measurement Parameters element as defined in
9.4.2.168.
9.6.8.33 Fine Timing Measurement frame format
The Fine Timing Measurement frame is used to support the FTM procedure described in 11.24.6. The
format of the Fine Timing Measurement Action field is shown in Figure 9-685.
1202
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Follow Up
Category Public Action Dialog Token Dialog Token TOD TOA
Octets: 1 1 1 1 6 6
Fine Timing FTM
Location
TOD Error TOA Error LCI Report Civic Report Measurement Synchronizatio
(optional) Parameters n Information
(optional) (optional) (optional)
Octets: 2 2 variable variable variable variable
Figure 9-685—Fine Timing Measurement Action field format
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The TOD Error field is structured as shown in Figure 9-686.
B0 B4 B5 B14 B15
Max TOD Error Reserved TOD Not Continuous
Exponent
Bits: 5 10 1
Figure 9-686—Format of the TOD Error field
The TOA Error field is structured as shown in 9-687.
B0 B4 B5 B15
Max TOA Error Reserved
Exponent
Bits: 5 11
Figure 9-687—Format of the TOA Error field
The Dialog Token field is a nonzero value chosen by the responding STA to identify the Fine Timing
Measurement frame as the first of a pair, with the second or follow-up Fine Timing Measurement frame to
be sent later. The Dialog Token field is set to 0 to indicate the end of the FTM session (see 11.24.6.6 and
11.24.6.4).
The Follow Up Dialog Token field is the nonzero value of the Dialog Token field of the last transmitted Fine
Timing Measurement frame to indicate that it is the follow up Fine Timing Measurement frame and that the
TOD, TOA, Max TOD Error Exponent and Max TOA Error Exponent fields contain the values of the
timestamps captured with the first Fine Timing Measurement frame of the pair. The Follow Up Dialog
Token field is 0 to indicate that the Fine Timing Measurement frame is not a follow up to a last transmitted
Fine Timing Measurement frame. The value 0 in this field also indicates that TOD, TOA, TOD Error, and
TOA Error fields are reserved. See 11.24.6.
The TOD and TOA fields are expressed in units of picoseconds.
The maximum errors in the TOD and TOA values are represented using the function defined in
Equation (9-4).
1203
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
unknown F = 0
F–1
E max = 2 1 F 30 (9-4)
30
2 F = 31
where
F is the Max Error Exponent
Emax is the maximum TOD or TOA error, respectively, in units of picoseconds
The TOD field contains a timestamp that represents the time, with respect to a time base, at which the start
of the preamble of the last transmitted Fine Timing Measurement frame appeared at the transmit antenna
connector.
The TOA field contains a timestamp that represents the time, with respect to a time base, at which the start
of the preamble of the Ack frame to the last transmitted Fine Timing Measurement frame arrived at the
receive antenna connector.
NOTE—The values specified in the TOD and TOA fields are described in 6.3.70.
The Max TOD Error Exponent field contains an upper bound for the error exponent in the value specified in
the TOD field.
NOTE—For instance, a value of 2 in the Max TOD Error Exponent field indicates that the value in the TOD field has a
maximum error of ± 2 ps.
The TOD Not Continuous field indicates that the TOD value is with respect to a different underlying time
base than the last transmitted TOA value. It is set to 1 when a discontinuity is present. Otherwise, it is set
to 0.
The Max TOA Error Exponent field contains an upper bound for the error exponent in the value specified in
the TOA field.
A value of 0 for the Max TOD Error Exponent or the Max TOA Error Exponent field indicates that the upper
bound on the error in the corresponding TOD or TOA value is unknown. A value of 31 indicates that the
upper bound on the error is greater than or equal to 1.073 741 824 ms.
The LCI Report field is optionally present. If present, it contains a Measurement Report element with
Measurement Type field equal to LCI (see Table 9-107), which either indicates the LCI of the transmitting
STA and includes the Z and Usage Rules/Policy subelement or indicates an unknown LCI (see 11.24.6.7).
The Late, Incapable and Refused bits in the Measurement Report Mode field are set to 0.The Co-Located
BSSID List subelement is present in the Measurement Report element with Measurement Type field equal
to LCI, when there is at least one other BSS which is co-located withe the reporting BSS.
The Location Civic Report field is optionally present. If present, it contains a Measurement Report element
with Measurement Type field equal to Location Civic (see Table 9-107), which either indicates the Civic
address of the transmitting STA or an unknown Civic address (see 11.24.6.7). The Late, Incapable and
Refused bits in the Measurement Report Mode field are set to 0. The Co-Located BSSID List subelement is
present in the Measurement Report element with Measurement Type field equal to LCI, when there is at
least one other BSS which is co-located withe the reporting BSS. When the LCI Report field contains a Co-
Located BSSID List subelement, the Co-Located BSSID List subelement is not present in the Location
Civic Report field.
1204
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Fine Timing Measurement Parameters field is present in the initial Fine Timing Measurement Frame
and is not present in subsequent Fine Timing Measurement frames. If present, it contains a Fine Timing
Measurement Parameters element as defined in 9.4.2.168.
The FTM Synchronization Information field is present in the initial Fine Timing Measurement frame and its
retransmissions if any, and in the first Fine Timing Measurement frame within each burst and its
retransmissions if any; otherwise it is not present. If present, it contains an FTM Synchronization
Information element with a TSF Sync Info field containing the 4 least significant octets of the TSF at the
responding STA corresponding to the time the responding STA received the last Fine Timing Measurement
Request frame with the Trigger field equal to 1.
9.6.8.34 QAB Request frame format
The QAB Request frame is transmitted by an AP to another AP to schedule quiet periods that facilitate the
detection of other system operating in the same band. The format of the QAB Request frame Action field is
shown in Table 9-324.
Table 9-324—QAB Request frame Action field format
Order Information
1 Category
2 Public Action
3 Dialog Token
4 RequesterAP Address
5 ResponderAP Address
6 Quiet Period Request element
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field is set to a nonzero value chosen by the AP.
The RequesterAP Address field is the MAC address of the AP that initiates the process. The length of this
field is 6 octets.
The ResponderAP Address field is the MAC address of the responding AP. The length of this field is
6 octets. This field can be set to the broadcast address if the request is sent to multiple APs.
The Quiet Period Request element is defined in 9.4.2.150.
9.6.8.35 QAB Response frame format
A QAB Response frame is sent in response to a QAB Request frame. The format of a QAB Response frame
Action field contains the information shown in Table 9-325.
1205
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-325—QAB Response frame Action field format
Order Information
1 Category
2 Public Action
3 Dialog Token
4 RequesterAP Address
5 ResponderAP Address
6 Quiet Period Response element
The Category field is defined in 9.4.1.11.
The Public Action field is defined in 9.6.8.1.
The Dialog Token field value is copied from the corresponding received QAB Request frame.
The RequesterAP Address field is the MAC address of the AP that initiates the process. The length of this
field is 6 octets.
The ResponderAP Address field is the MAC address of the responding AP. The length of this field is
6 octets.
The Quiet Period Response element is defined in 9.4.2.151.
9.6.9 FT Action frame details
9.6.9.1 General
Four Action frame formats are defined to support fast BSS transitions over the DS, which are initiated
through the currently associated AP. The FT Action frames are sent over the air between the STA and the
current AP. The Action frame is used as a transport mechanism for data that are destined for the target AP.
An FT Action field, in the octet immediately after the Category field, differentiates the FT Action
frame formats. The FT Action field values associated with each FT Action frame format are defined in
Table 9-326.
Table 9-326—FT Action field values
FT Action field value Description
0 Reserved
1 FT Request frames
2 FT Response frames
3 FT Confirm frames
4 FT Ack frames
5–255 Reserved
1206
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.9.2 FT Request frame
The FT Request frame is sent by the STA to its associated AP to initiate an over-the-DS fast BSS transition.
Figure 9-688 shows the format of the FT Request frame Action field.
Category FT Action STA Target AP FT Request frame body
Address Address
Octets: 1 1 6 6 variable
Figure 9-688—FT Request frame Action field format
The Category field is defined in 9.4.1.11.
The FT Action field is defined in 9.6.9.1.
The STA Address field is set to the fast BSS transition originator’s (FTO’s) MAC address.
The Target AP Address field is set to the BSSID value of the target AP.
The FT Request frame body contains the information shown in Table 9-327.
Table 9-327—FT Request frame body
Order Information Notes
1 RSN A RSNE is present if dot11RSNAActivated is true.
2 Mobility Domain The MDE is present.
3 Fast BSS Transition An FTE is present if dot11RSNAActivated is true.
The usage of these elements is defined in 13.8.2.
9.6.9.3 FT Response frame
The FT Response frame is transmitted by the currently associated AP as a response to the STA’s FT Request
frame. Figure 9-689 shows the format of the FT Response frame Action field.
FT STA Target AP Status
Category FT Response frame body
Action Address Address Code
Octets: 1 1 6 6 2 variable
Figure 9-689—FT Response frame Action field format
The Category field is defined in 9.4.1.11.
The FT Action field is defined in 9.6.9.1.
The STA Address field is set to the FTO’s MAC address.
1207
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Target AP Address field is set to the BSSID value of the target AP.
The Status Code field is a value from the options listed in 9.4.1.9.
If the Status Code field is SUCCESS, then the FT Response frame body contains the information shown in
Table 9-328.
Table 9-328—FT Response frame body
Order Information Notes
1 RSN The RSNE is present if dot11RSNAActivated is true.
2 Mobility Domain The MDE is present.
3 Fast BSS Transition An FTE is present if dot11RSNAActivated is true.
The usage of these elements is defined in 13.8.3.
9.6.9.4 FT Confirm frame
The FT Confirm frame in an RSN is confirmation to the target AP of receipt of the ANonce and indicates the
liveness of the PTKSA. The FT Confirm frame is optionally used by the FTO to request resources. Figure 9-
690 shows the FT Confirm frame Action field format.
STA Target AP
Category FT Action FT Confirm frame body
Address Address
Octets: 1 1 6 6 variable
Figure 9-690—FT Confirm frame Action field format
The Category field is defined in 9.4.1.11.
The FT Action field is defined in 9.6.9.1.
The STA Address field is set to the FTO’s MAC address.
The Target AP Address field is set to the BSSID value of the target AP.
The FT Confirm frame body contains the information shown in Table 9-329.
Table 9-329—FT Confirm frame body
Order Information Notes
1 RSN The RSNE is present if dot11RSNAActivated is true.
2 Mobility Domain The MDE is present.
3 Fast BSS Transition An FTE is present if dot11RSNAActivated is true.
4 RIC The RIC Request field is present if resources are being requested.
1208
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The usage of these elements is defined in 13.8.4.
9.6.9.5 FT Ack frame
The FT Ack frame is transmitted by the currently associated AP as a response to the STA’s FT Confirm
frame. Figure 9-691 shows the FT Ack frame Action field format.
FT STA Target Status
Category AP FT Ack frame body
Action Address Address Code
Octets 1 1 6 6 2 variable
Figure 9-691—FT Ack frame Action field format
The Category field is defined in 9.4.1.11.
The FT Action field is defined in 9.6.9.1.
The STA Address field is set to the FTO’s MAC address.
The Target AP Address field is set to the BSSID value of the target AP.
The Status Code field is a value from the options listed in 9.4.1.9.
If the Status Code field is SUCCESS, then the FT Ack frame body contains the information shown in
Table 9-330.
Table 9-330—FT Ack frame body
Order Information Notes
1 RSN The RSNE is present if dot11RSNAActivated is true.
2 Mobility Domain The MDE is present.
3 Fast BSS Transition An FTE is present if dot11RSNAActivated is true.
4 Timeout Interval A TIE containing the reassociation deadline interval is present if
(reassociation deadline) resources were requested in the FT Confirm frame and
dot11RSNAActivated is false.
5 RIC The RIC Response field is present if resources were requested in the
FT Confirm frame.
The usage of these elements is defined in 13.8.5.
9.6.10 SA Query Action frame details
9.6.10.1 General
Two Action frame formats are defined for the SA Query procedure. A SA Query Action field, in the octet
field immediately after the Category field, differentiates the formats. The Action field values associated with
each frame format are defined in Table 9-331.
1209
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—The SA query functionality defined in this standard is used to prevent the Association Lockout problem
(defined in 11.3).
Table 9-331—SA Query Action field values
SA Query Action
Description
field value
0 SA Query Request
1 SA Query Response
9.6.10.2 SA Query Request frame
The SA Query Request frame is used to request a SA Query Response from the receiving STA. The format
of the Action field is shown in Figure 9-692.
Transaction
Category SA Query Action Identifier
Octets: 1 1 2
Figure 9-692—SA Query Request frame Action field format
The Category field is defined in 9.4.1.11.
The SA Query Action field is defined in 9.6.10.1.
The Transaction Identifier field is a 16-bit non-negative counter value set by the STA sending the SA Query
Request frame to identify any outstanding request/response transaction.
9.6.10.3 SA Query Response frame
The SA Query Response frame is used to respond to an SA Query Request frame from another STA. The
format of the Action field is shown in Figure 9-693.
Transaction
Category SA Query Action Identifier
Octets: 1 1 2
Figure 9-693—SA Query Response frame Action field format
The Category field is defined in 9.4.1.11.
The SA Query Action field is defined in 9.6.10.1.
The Transaction Identifier field is set to the same value as the Transaction Identifier field in the
corresponding SA Query Request frame.
1210
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.11 Protected Dual of Public Action frames
The Protected Dual of Public Action frame is defined to allow robust STA-STA communications of the
same information that is conveyed in Action frames that are not robust (see 9.4.1.11). A Public Action field,
in the octet immediately after the Category field, differentiates the Protected Dual of Public Action frame
formats. The defined Protected Dual of Public Action frames are listed in Table 9-332.
The Protected Dual of Public Action frames have the same format as the corresponding nonprotected Public
Action frame.
Table 9-332—Public Action field values defined for Protected Dual
of Public Action frames
Public Action field value Description Defined in
0 Reserved
1 Protected DSE Enablement 9.6.8.4
2 Protected DSE Deenablement 9.6.8.5
3 Reserved
4 Protected Extended Channel Switch Announcement 9.6.8.7
5 Protected Measurement Request 9.6.8.8
6 Protected Measurement Report 9.6.8.9
7 Reserved
8 Protected DSE Power Constraint 9.6.8.10
9 Protected Vendor Specific 9.6.8.11
10 Protected GAS Initial Request 9.6.8.12
11 Protected GAS Initial Response 9.6.8.13
12 Protected GAS Comeback Request 9.6.8.14
13 Protected GAS Comeback Response 9.6.8.15
14–17 Reserved
16 QAB Request 9.6.8.34
17 QAB Response 9.6.8.35
18 Protected QMF Policy 9.6.8.18
19 Protected QMF Policy Change 9.6.8.19
20 Protected QLoad Request 9.6.8.20
21 Protected QLoad Report 9.6.8.21
22 Protected HCCA TXOP Advertisement 9.6.8.22
23 Protected HCCA TXOP Response 9.6.8.23
24 Reserved
25 Protected Channel Availability Query 9.6.8.25
26 Protected Channel Schedule Management 9.6.8.26
27 Protected Contact Verification Signal 9.6.8.27
28 Protected GDD Enablement Request 9.6.8.28
1211
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-332—Public Action field values defined for Protected Dual
of Public Action frames (continued)
Public Action field value Description Defined in
29 Protected GDD Enablement Response 9.6.8.29
30 Protected Network Channel Control 9.6.8.30
31 Protected White Space Map Announcement 9.6.8.31
32–255 Reserved
9.6.12 HT Action frame details
9.6.12.1 HT Action field
Several Action frame formats are defined to support HT features. An HT Action field, in the octet
immediately after the Category field, differentiates the HT Action frame formats. The HT Action field
values associated with each frame format within the HT category are defined in Table 9-333. The frame
formats are defined in 9.6.12.2 to 9.6.12.9.
Table 9-333—HT Action field values
HT Action field value Meaning Time priority
0 Notify Channel Width No
1 SM Power Save No
2 PSMP Yes
3 Set PCO Phase Yes
4 CSI Yes
5 Noncompressed Beamforming Yes
6 Compressed Beamforming Yes
7 ASEL Indices Feedback Yes
8–255 Reserved —
9.6.12.2 Notify Channel Width frame format
A STA sends the Notify Channel Width frame to another STA if it wants to change the channel width of
frames that the other STA sends to it. See definition in 11.16.2.
The format of the Notify Channel Width frame Action field is defined in Table 9-334.
This frame can be sent by both non-AP STA and AP.
The Category field is defined in 9.4.1.11.
The HT Action field is defined in 9.6.12.1.
1212
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-334—Notify Channel Width frame Action field format
Order Information
1 Category
2 HT Action
3 Channel Width (see 9.4.1.21)
9.6.12.3 SM Power Save frame format
The SM Power Save frame is of category HT. The SM Power Save frame is used to manage SM power-
saving state transitions as defined in 11.2.6.
The Action field of the SM Power Save frame is defined in Table 9-335.
Table 9-335—SM Power Save frame Action field format
Order Information
1 Category
2 HT Action
3 SM Power Control (see 9.4.1.23)
The Category field is defined in 9.4.1.11.
The HT Action field is defined in 9.6.12.1.
9.6.12.4 PSMP frame format
PSMP is an Action frame of category HT.
The DA field of this frame is a group address. (See 10.29.2.8.)
The PSMP Parameter Set field and PSMP STA Info fields define zero or more PSMP-DTT and PSMP-UTT
time allocations that follow immediately after the PSMP frame.
The Action field of this frame is defined in Table 9-336. The PSMP Parameter Set field is followed by zero
or more PSMP STA Info fields.
The Category field is defined in 9.4.1.11.
The HT Action field is defined in 9.6.12.1.
The PSMP STA Info fields within a PSMP frame are ordered by STA_INFO Type as follows: group
addressed (STA_INFO Type=1) and then individually addressed (STA_INFO Type=2).
1213
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-336—PSMP frame Action field format
Order Information
1 Category
2 HT Action
3 PSMP Parameter Set (see 9.4.1.25)
4 PSMP STA Info (see 9.4.1.26)
Repeated N_STA times (N_STA is a subfield of the PSMP Parameter Set field)
9.6.12.5 Set PCO Phase frame format
The PCO mechanism is obsolete. Consequently, this subclause might be removed in a later revision of this
standard.
Set PCO Phase is an Action frame of category HT that announces the phase change between 20 MHz and
40 MHz. The format of its Action field is defined in Table 9-337. The operation of the PCO feature is
defined in 11.17.
Table 9-337—Set PCO Phase frame Action field format
Order Information
1 Category
2 HT Action
3 PCO Phase Control (see 9.4.1.24)
The Category field is defined in 9.4.1.11.
The HT Action field is defined in 9.6.12.1.
This frame is sent by a PCO active AP.
9.6.12.6 CSI frame format
The CSI frame is an Action or an Action No Ack frame of category HT. The format of its Action field is
defined in Table 9-338.
Table 9-338—CSI frame Action field format
Order Information
1 Category
2 HT Action
3 MIMO Control (see 9.4.1.27)
4 CSI Report (see 9.4.1.28)
1214
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The HT Action field is defined in 9.6.12.1.
In a CSI frame, the fields of the MIMO Control field (see 9.4.1.27) are used as described in Table 9-51. The
Codebook Information subfield is reserved in this frame.
9.6.12.7 Noncompressed Beamforming frame format
The Noncompressed Beamforming frame is an Action or an Action No Ack frame of category HT. The
format of its Action field is defined in Table 9-339.
Table 9-339—Noncompressed Beamforming frame Action field format
Order Information
1 Category
2 HT Action
3 MIMO Control (see 9.4.1.27)
4 Noncompressed Beamforming Report (see 9.4.1.29)
The Category field is defined in 9.4.1.11.
The HT Action field is defined in 9.6.12.1.
In a Noncompressed Beamforming frame, the fields of the MIMO Control field (see 9.4.1.27) are used as
described in Table 9-51. The Codebook Information subfield is reserved in this frame.
9.6.12.8 Compressed Beamforming frame format
The Compressed Beamforming frame is an Action or an Action No Ack frame of category HT. The format
of its Action field is defined in Table 9-340.
Table 9-340—Compressed Beamforming frame Action field format
Order Information
1 Category
2 HT Action
3 MIMO Control (see 9.4.1.27)
4 Compressed Beamforming Report (see 9.4.1.30)
The Category field is defined in 9.4.1.11.
The HT Action field is defined in 9.6.12.1.
In a Compressed Beamforming frame, the fields of the MIMO Control field (see 9.4.1.27) are used as
described in Table 9-51. The Coefficient Size subfield is reserved in this frame.
1215
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.12.9 Antenna Selection Indices Feedback frame format
The Antenna Selection Indices Feedback frame is an Action or Action No Ack frame of category HT. The
format of its Action field is defined in Table 9-341.
Table 9-341—Antenna Selection Indices Feedback frame Action field format
Order Information
1 Category
2 HT Action
3 Antenna Selection Indices (see 9.4.1.31)
The Category field is defined in 9.4.1.11.
The HT Action field is defined in 9.6.12.1.
9.6.13 TDLS Action field formats
9.6.13.1 General
Several Action field formats are defined to support TDLS. A TDLS Action field, in the octet immediately
after the Category field, differentiates the TDLS Action field formats. The TDLS Action field values
associated with each Action field format within the TDLS category are defined in Table 9-342.
Table 9-342—TDLS Action field values
Action field value Meaning
0 TDLS Setup Request
1 TDLS Setup Response
2 TDLS Setup Confirm
3 TDLS Teardown
4 TDLS Peer Traffic Indication
5 TDLS Channel Switch Request
6 TDLS Channel Switch Response
7 TDLS Peer PSM Request
8 TDLS Peer PSM Response
9 TDLS Peer Traffic Response
10 TDLS Discovery Request
11–255 Reserved
References to one of the TDLS Action field values as a frame, e.g., “TDLS Setup Request frame,” denote a
Data frame carrying a TDLS Action field and any vendor-specific elements tunneled as described in
11.23.1.
1216
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.13.2 TDLS Setup Request Action field format
The Action field of a TDLS Setup Request Action field contains the information shown in Table 9-343.
Table 9-343—Information for TDLS Setup Request Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Dialog Token The Dialog Token field contains a unique nonzero value for
the conversation between the STAs involved in this request.
The dialog token is specified in 9.4.1.12.
4 Capability The Capability field indicates the capabilities of the STA. The
Capability field is defined in 9.4.1.4.
5 Supported Rates and BSS The Supported Rates and BSS Membership Selectors element
Membership Selectors indicates the rates that are supported by the STA. The
Supported Rates and BSS Membership Selectors element is
defined in 9.4.2.3.
6 Country The Country element is present when
dot11MultiDomainCapabilityActivated is true or
dot11SpectrumManagementRequired is true. The Country
element is defined in 9.4.2.9.
7 Extended Supported Rates The Extended Supported Rates and BSS Membership
and BSS Membership Selectors element is present whenever there are more than
Selectors eight supported rates, and it is optionally present otherwise.
The Extended Supported Rates and BSS Membership
Selectors element is defined in 9.4.2.13.
8 Supported Channels The Supported Channels element is present if the TDLS
channel switching capability field is equal to 1.
The Supported Channels element is defined in 9.4.2.18.
9 RSNE The RSNE is present if security is required on the direct link.
The RSNE is defined in 9.4.2.25.
10 Extended Capabilities The Extended Capabilities element is optionally present if any
of the fields in this element are nonzero. The Extended
Capabilities element is defined in 9.4.2.27.
11 QoS Capability The QoS Capability element is present when
dot11QosOptionImplemented is true and not present
otherwise. The QoS Capability element is defined in 9.4.2.35.
12 FTE The FTE is present if security is required on the TDLS direct
link. The FTE is defined in 9.4.2.48.
13 Timeout Interval (TPK key The Timeout Interval element contains the TPK key lifetime
lifetime) and is present if security is required on the direct link.
The Timeout Interval element is defined in 9.4.2.49.
14 Supported Operating Classes The Supported Operating Classes element is present if the
TDLS channel switching capability field is equal to 1.
The Supported Operating Classes element is defined in
9.4.2.54 (optional).
15 HT Capabilities The HT Capabilities element is defined in 9.4.2.56.
The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
1217
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-343—Information for TDLS Setup Request Action field (continued)
Order Information Notes
16 20/40 BSS Coexistence The 20/40 BSS Coexistence element is defined in 9.4.2.60.
The 20/40 BSS Coexistence element is optionally present.
17 Link Identifier The Link Identifier element is specified in 9.4.2.62.
18 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
19 AID The AID element containing the AID of the STA sending the
frame is present if dot11VHTOptionImplemented is true.
20 VHT Capabilities The VHT Capabilities element is present if the
dot11VHTOptionImplemented is true.
The TDLS Setup Request Action field is encapsulated in a Data frame and transmitted to the recipient STA
through the AP to request the setup of a TDLS direct link. See 11.23.
9.6.13.3 TDLS Setup Response Action field format
The Action field of a TDLS Setup Response Action field contains the information shown in Table 9-344.
Table 9-344—Information for TDLS Setup Response Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Status Code The Status Code is defined in 9.4.1.9.
4 Dialog Token The dialog token is copied from the corresponding TDLS Setup
Request. The dialog token is specified in 9.4.1.12.
5 Capability The Capability field indicates the capabilities of the STA and is
present when the Status Code is SUCCESS and is not present
otherwise. The Capability field is defined in 9.4.1.4.
6 Supported Rates and BSS The Supported Rates and BSS Membership Selectors element
Membership Selectors indicates the rates that are supported by the STA and is present
when the Status Code is SUCCESS and is not present
otherwise.The Supported Rates and BSS Membership Selectors
element is defined in 9.4.2.3.
7 Country The Country element is present when Status Code is SUCCESS
and either dot11MultiDomainCapabilityActivated is true or
dot11SpectrumManagementRequired is true and is not present
otherwise.
The Country element is defined in 9.4.2.9
8 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors
and BSS Membership element is present when there are more than 8 supported rates and
Selectors Status Code is SUCCESS. It is optionally present when there are
less than 8 supported rates and Status Code is SUCCESS.
Otherwise it is not present. The Extended Supported Rates and
BSS Membership Selectors element is defined in 9.4.2.13.
1218
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-344—Information for TDLS Setup Response Action field (continued)
Order Information Notes
9 Supported Channels The Supported Channels element is defined in 9.4.2.18. It is
present if the TDLS channel switching capability bit is equal to 1
and the Status Code is SUCCESS, and not present otherwise.
10 RSNE The RSNE is present if security is required on the TDLS direct
link and the Status Code is SUCCESS, and not present otherwise.
The RSNE is defined in 9.4.2.25.
11 Extended Capabilities The Extended Capabilities element is present if any of the fields
in this element are nonzero and the Status Code is SUCCESS, and
not present otherwise. The Extended Capabilities element is
defined in 9.4.2.27.
12 QoS Capability The QoS Capability element is present when
dot11QosOptionImplemented is true and the Status Code is
SUCCESS and not present otherwise. The QoS Capability
element is defined in 9.4.2.35.
13 FTE The FTE is present if security is required on the TDLS direct link
and the Status Code is SUCCESS, and not present otherwise.
The FTE is defined in 9.4.2.48.
14 Timeout Interval (TPK key The Timeout Interval element, containing the TPK key lifetime,
lifetime) is present if security is required on the direct link and the Status
Code is SUCCESS, and not present otherwise.
The Timeout Interval element is defined in 9.4.2.49.
15 Supported Operating Classes The Supported Operating Classes element is present if the TDLS
channel switching capability bit is equal to 1 and the Status Code
is SUCCESS and not present otherwise.
The Supported Operating Classes element is defined in 9.4.2.54.
16 HT Capabilities The HT Capabilities element is present if
dot11HighThroughputOptionImplemented is true and the Status
Code is SUCCESS and is not present otherwise.
The HT Capabilities element is defined in 9.4.2.56.
17 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present if the
Status Code is SUCCESS and not present otherwise.
The 20/40 BSS Coexistence element is defined in 9.4.2.60.
18 Link Identifier The Link Identifier element is present if the Status Code is
SUCCESS and not present otherwise.
The Link Identifier is specified in 9.4.2.62.
19 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true and the Status Code is
SUCCESS and not present otherwise.
20 AID The AID element containing the AID of the STA sending the
frame is present if dot11VHTOptionImplemented is true and the
Status Code is SUCCESS and not present otherwise.
21 VHT Capabilities The VHT Capabilities element is present if the
dot11VHTOptionImplemented is true and the Status Code is
SUCCESS and not present otherwise.
22 Operating Mode Notification The Operating Mode Notification element is optionally present if
the TDLS Setup Request frame contained an Extended
Capabilities element with the Operating Mode Notification field
is equal to 1.
1219
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The TDLS Setup Response Action field is encapsulated in a Data frame and transmitted to the TDLS
initiator STA through the AP in response to a received TDLS Setup Request Action field. See 11.23.
9.6.13.4 TDLS Setup Confirm Action field format
The Action field of a TDLS Setup Confirm Action field contains the information shown in Table 9-345.
Table 9-345—Information for TDLS Setup Confirm Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Status Code The Status Code is defined in 9.4.1.9.
4 Dialog Token The dialog token is copied from the corresponding TDLS Setup
Response. The dialog token is specified in 9.4.1.12.
5 RSNE The RSNE is present if security is required on the TDLS direct
link and the Status Code is SUCCESS, and not present
otherwise. The RSNE is defined in 9.4.2.25.
6 EDCA Parameter Set The EDCA parameter set is present if QoS is supported on the
direct link. The EDCA Parameter Set element is specified in
9.4.2.29. It is present for Status Code SUCCESS.
7 FTE The FTE is defined in 9.4.2.48.
The FTE is present if security is required on the TDLS direct link
and the Status Code is SUCCESS, and not present otherwise.
8 Timeout Interval (TPK Key The Timeout Interval element is defined in 9.4.2.49.
Lifetime) The Timeout Interval, containing the TPK Key Lifetime, is
present if security is required on the direct link and the Status
Code is SUCCESS, and not present otherwise.
9 HT Operation The HT Operation element is present if
dot11HighThroughputOptionImplemented is true, the TDLS
Setup Response frame contained an HT Capabilities element, the
Status Code is SUCCESS.
The HT Operation element is defined in 9.4.2.57.
10 Link Identifier The Link Identifier is specified in 9.4.2.62. It is present if the
Status Code is SUCCESS.
11 VHT Operation VHT Operation element (optional). The VHT Operation element
is present if the dot11VHTOptionImplemented is true, the TDLS
Setup Response frame contained a VHT Capabilities element,
the status code is SUCCESS, and the TDLS direct link is not
established in the 2.4 GHz band. The VHT Operation element is
defined in 9.4.2.159.
12 Operating Mode Notification The Operating Mode Notification element is optionally present if
the TDLS Setup Request frame contained an Extended
Capabilities element with the Operating Mode Notification field
is equal to 1.
The TDLS Setup Confirm Action field is encapsulated in a Data frame and transmitted to the TDLS
responder STA through the AP in response to a received TDLS Setup Response Action field. See 11.23.
1220
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.13.5 TDLS Teardown Action field format
The Action field of a TDLS Teardown Action field contains the information shown in Table 9-346.
Table 9-346—Information for TDLS Teardown Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Reason Code The Reason Code is defined in 9.4.1.7.
4 FTE The FTE is present if a TPK handshake was successful for
this session (optional).
The FTE is defined in 9.4.2.48.
5 Link Identifier The Link Identifier is specified in 9.4.2.62.
The TDLS Teardown Action field is encapsulated in a Data frame and transmitted to the TDLS peer STA
directly or through the AP to tear down a TDLS direct link. See 11.23.
9.6.13.6 TDLS Peer Traffic Indication Action field format
The Action field of a TDLS Peer Traffic Indication Action field contains the information shown in
Table 9-347.
Table 9-347—Information for TDLS Peer Traffic Indication Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Dialog Token The dialog token is specified in 9.4.1.12.
4 Link Identifier The Link Identifier is specified in 9.4.2.62.
5 PTI Control The PTI Control element is optionally present. It is defined in
9.4.2.65.
6 TPU Buffer Status The TPU Buffer Status element is defined in 9.4.2.66.
The TDLS Peer Traffic Indication Action field indicates the state of the power save buffer at the STA
supporting TPU that is buffering data for a TDLS peer STA in power save mode.
The TPU Buffer Status element indicates the status of the AC buffers at the TPU buffer STA.
The PTI Control element is optionally included in the TDLS Peer Traffic Indication Action field (see
11.2.3.15) to identify the latest MPDU transmitted to the TPU sleep STA that is the destination of the TDLS
Peer Traffic Indication Action field.
The TDLS Peer Traffic Indication Action field is encapsulated in a Data frame and transmitted to the TDLS
peer STA through the AP. See 11.2.3.15.
1221
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.13.7 TDLS Channel Switch Request Action field format
The Action field of the TDLS Channel Switch Request Action field contains the information shown in
Table 9-348.
Table 9-348—Information for TDLS Channel Switch Request Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Target Channel 1 octet field that specifies the channel number of the target
channel. See 9.4.1.36.
4 Operating Class 1 octet field that specifies the operating class for the target
channel. The Operating Channel field is defined in 9.4.1.37.
5 Secondary Channel Offset The secondary channel offset is present if a switch to a 40
MHz direct link is indicated and is absent otherwise. See
9.4.2.20.
6 Link Identifier The Link Identifier element is specified in 9.4.2.62.
7 Channel Switch Timing The Channel Switch Timing element is specified in 9.4.2.64.
8 Wide Bandwidth Channel Wide Bandwidth Channel Switch element (optional). The
Switch Wide Bandwidth Channel Switch element is included when a
switch to an 80 MHz, 160 MHz, or 80+80 MHz direct link is
indicated. See 9.4.2.161.
9 Country Country element (optional). The Country element is included
to change operating classes when a switch to a direct link is
indicated. The Country element indicates the same country as
the BSS and includes zero Subband Triplet fields.
10 Transmit Power Envelope Transmit Power Envelope element (zero or more). Each
Transmit Power Envelope element that is present includes a
distinct value of the Local Maximum Transmit Power Unit
Interpretation subfield. If present, the New Transmit Power
Envelope element indicates the maximum transmit powers for
the direct link for the indicated bandwidths with an indicated
unit interpretation after a switch to a direct link (see
11.23.6.5.1).
The TDLS Channel Switch Request Action field is encapsulated in a Data frame and transmitted directly to
the TDLS peer STA to request for the TDLS direct link to be switched to another channel. See 11.23.
9.6.13.8 TDLS Channel Switch Response Action field format
The Action field of the TDLS Channel Switch Response Action field contains the information shown in
Table 9-349.
The TDLS Channel Switch Response Action field is encapsulated in a Data frame and transmitted directly to
the TDLS peer STA in response to a received TDLS Channel Switch Request Action field. See 11.23.
1222
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-349—Information for TDLS Channel Switch Response Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Status Code The Status Code is defined in 9.4.1.9.
5 Link Identifier The Link Identifier element is specified in 9.4.2.62. It is
present if the Status Code is SUCCESS.
6 Channel Switch Timing The Channel Switch Timing element is specified in 9.4.2.64.
9.6.13.9 TDLS Peer PSM Request Action field format
The TDLS Peer PSM Request Action field contains the information shown in Table 9-350.
Table 9-350—Information for TDLS Peer PSM Request Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Dialog Token The Dialog Token field contains a value that is unique among
TDLS Peer PSM Request Action fields for which a corresponding
TDLS Peer PSM Response Action field has not been received.
The dialog token is specified in 9.4.1.12.
4 Link Identifier The Link Identifier element is specified in 9.4.2.62.
5 Wakeup Schedule The Wakeup Schedule element is specified in 9.4.2.63.
The TDLS Peer PSM Request Action field is encapsulated in a Data frame and transmitted to the TDLS peer
STA, directly or through the AP, to set up or change a periodic wakeup schedule on the TDLS direct link.
See 11.2.3.14.
9.6.13.10 TDLS Peer PSM Response Action field format
The TDLS Peer PSM Response Action field contains the information shown in Table 9-351.
Table 9-351—Information for TDLS Peer PSM Response Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Dialog Token The dialog token is set to the value contained in the
corresponding TDLS Peer PSM Request Action field. The
dialog token is specified in 9.4.1.12.
4 Status Code The Status Code is specified in 9.4.1.9.
1223
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-351—Information for TDLS Peer PSM Response Action field (continued)
Order Information Notes
5 Link Identifier The Link Identifier element is specified in 9.4.2.62. It is
present if the Status Code is SUCCESS.
6 Wakeup Schedule The Wakeup Schedule element is present is present if the
status code is set to
TDLS_REJECTED_ALTERNATIVE_PROVIDED and is not
present otherwise. The Wakeup Schedule is specified in
9.4.2.63.
The TDLS Peer PSM Response Action field is encapsulated in a Data frame and transmitted to the TDLS
peer STA directly in response to a TDLS Peer PSM Request Action field. See 11.2.3.14.
9.6.13.11 TDLS Peer Traffic Response Action field format
The Action field of a TDLS Peer Traffic Response Action field contains the information shown in
Table 9-352.
Table 9-352—Information for TDLS Peer Traffic Response Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Dialog Token The dialog token is specified in 9.4.1.12.
4 Link Identifier The Link Identifier element is specified in 9.4.2.62.
The TDLS Peer Traffic Response Action field indicates the receipt of the corresponding TDLS Peer Traffic
Indication Action field.
The Dialog Token field is set to the nonzero value of the corresponding TDLS Peer Traffic Indication
Action field.
The Link Identifier field is set to identify the TDLS direct link in relation to which the TDLS Peer Traffic
Response Action field is transmitted.
The TDLS Peer Traffic Response Action field is encapsulated in a Data frame and transmitted to the TDLS
peer STA directly. See 11.2.3.15.
9.6.13.12 TDLS Discovery Request Action field format
The TDLS Discovery Request Action field contains the information shown in Table 9-353.
The TDLS Discovery Request Action field is encapsulated in a Data frame and transmitted to a TDLS peer
STA through the AP, to request TDLS capable STAs in the same BSS to respond with a TDLS Discovery
Response frame. See 11.23.
1224
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-353—Information for TDLS Discovery Request Action field
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 TDLS Action The TDLS Action field is defined in 9.6.13.1.
3 Dialog Token The Dialog Token field can be used to match TDLS Discovery
Response frames to the corresponding TDLS Discovery Request
frame. The dialog token is specified in 9.4.1.12.
4 Link Identifier The Link Identifier element is specified in 9.4.2.62.
5 Multi-band The Multi-band element is optionally present if
dot11MultibandImplemented is true.
9.6.14 WNM Action details
9.6.14.1 WNM Action fields
Several Action frame formats are defined for wireless network management (WNM) purposes. A WNM
Action field, in the octet field immediately after the Category field, differentiates the formats. The WNM
Action field values associated with each frame format are defined in Table 9-354.
Table 9-354—WNM Action field values
WNM Action field value Description
0 Event Request
1 Event Report
2 Diagnostic Request
3 Diagnostic Report
4 Location Configuration Request
5 Location Configuration Response
6 BSS Transition Management Query
7 BSS Transition Management Request
8 BSS Transition Management Response
9 FMS Request
10 FMS Response
11 Collocated Interference Request
12 Collocated Interference Report
13 TFS Request
14 TFS Response
15 TFS Notify
16 WNM Sleep Mode Request
17 WNM Sleep Mode Response
18 TIM Broadcast Request
1225
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-354—WNM Action field values (continued)
WNM Action field value Description
19 TIM Broadcast Response
20 QoS Traffic Capability Update
21 Channel Usage Request
22 Channel Usage Response
23 DMS Request
24 DMS Response
25 Timing Measurement Request
26 WNM Notification Request
27 WNM Notification Response
28 WNM-Notify Response
29–255 Reserved
9.6.14.2 Event Request frame format
The Event Request frame uses the Action frame body format and is transmitted to request another STA to
report one or more events. The format of the Event Request Action field is shown in Figure 9-694.
Destination URI
Event Request
Category WNM Action Dialog Token Elements Element
(optional)
Octets: 1 1 1 variable variable
Figure 9-694—Event Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value chosen by the STA sending the event request to identify the
request/report transaction.
The Event Request Elements field contains one or more of the Event Request elements described in 9.4.2.67.
The Destination URI element field contains zero or one Destination URI element described in 9.4.2.90.
9.6.14.3 Event Report frame format
The Event Report frame uses the Action frame body format and is transmitted in response to an Event
Request frame, or autonomously. The format of the Event Report Action field is shown in Figure 9-695.
1226
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Event Report
Category WNM Action Dialog Token Elements
Octets: 1 1 1 variable
Figure 9-695—Event Report Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value of the corresponding Event Request frame. If the Event Report
frame is being transmitted other than in response to an Event Request frame, then the dialog token is 0.
The Event Report Elements field contains one or more of the Event Report elements described in 9.4.2.68.
9.6.14.4 Diagnostic Request frame format
The Diagnostic Request frame uses the Action frame body format and is transmitted requesting the
receiving STA to execute a diagnostic test. The format of the Diagnostic Request Action field is shown in
Figure 9-696.
WNM Diagnostic Request Destination URI
Category Action Dialog Token Elements Element (optional)
Octets: 1 1 1 variable variable
Figure 9-696—Diagnostic Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value chosen by the STA sending the Diagnostic Request frame to
identify the request/report transaction.
The Diagnostic Request Elements field contains one or more of the Diagnostic Request elements described
in 9.4.2.69. The number and length of the Diagnostic Request elements in a Diagnostic Request frame is
limited by the maximum MMPDU size (see 9.3.3.2).
The Destination URI element field contains zero or one Destination URI element described in 9.4.2.90.
9.6.14.5 Diagnostic Report frame format
The Diagnostic Report frame uses the Action frame body format transmitted by a STA in response to a
Diagnostic Request frame. The format of the Diagnostic Report Action field is shown in Figure 9-697.
Diagnostic Report
Category WNM Action Dialog Token Elements
Octets: 1 1 1 variable
Figure 9-697—Diagnostic Report Action field format
1227
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value in any corresponding Diagnostic Request frame.
The Diagnostic Report Elements field contains one or more of the Diagnostic Report elements described in
9.4.2.70. The number and length of the Diagnostic Report elements in a Diagnostic Report frame is limited
by the maximum MMPDU size (see 9.3.3.2).
9.6.14.6 Location Configuration Request frame format
The Location Configuration Request frame uses the Action frame body format and is transmitted to
configure another STA to send a Location Track Notification frame on a set of channels periodically for the
purposes of determining location of the STA. The format of the Location Configuration Request Action
field is shown in Figure 9-698.
Category WNM Action Dialog Token Location Parameters
Element
Octets: 1 1 1 variable
Figure 9-698—Location Configuration Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value that is unique among the Location Configuration Request frames
sent to each destination MAC address for which a corresponding Location Configuration Response frame
has not been received.
The Location Parameters Element field contains the location parameters subelements, described in 9.4.2.71.
Table 9-355 defines the allowed Location Parameters subelements for a Location Parameters element that is
included in the Location Configuration Request frame.
Table 9-355—Location Parameters Element field for Location Configuration Request frame
Allowed subelements Subelement ID Notes
Location Indication Parameters 1 The Location Indication Parameters subelement is
included in the Location Configuration Request frame.
Location Indication Channels 2 The Location Indication Channels subelement is included
in the Location Configuration Request frame.
Location Indication Broadcast 6 The Location Indication Broadcast Data Rate subelement
Data Rate is included in the Location Configuration Request frame.
Location Indication Options 8 The Location Indication Options subelement is optionally
included in the Location Configuration Request frame.
Vendor Specific Information 221 Zero or more Vendor Specific subelements are included in
the Location Configuration Request frame.
1228
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.14.7 Location Configuration Response frame format
The Location Configuration Response frame uses the Action frame body format and is transmitted in
response to the receipt of a Location Configuration Request frame. The format of the Location
Configuration Response Action field is shown in Figure 9-699.
Location
Category WNM Action Dialog Token Parameters
Element
Octets: 1 1 1 variable
Figure 9-699—Location Configuration Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value received in the Location Configuration Request frame to
identify the request/response transaction.
The Location Parameters Element field contains the location parameters subelements, described in 9.4.2.71.
Table 9-356 defines the allowed Location Parameters subelements for a Location Parameters element that is
included in the Location Configuration Response frame.
Table 9-356—Location Parameters Element field for Location Configuration Response
frame
Allowed subelements Subelement ID Notes
Location Indication Parameters 1 The Location Indication Parameters subelement is
optionally included in the Location Configuration
Response frame.
Location Indication Channels 2 The Location Indication Channels subelement is
optionally included in the Location Configuration
Response frame.
Location Indication Broadcast 6 The Location Indication Broadcast Data Rate subelement
Data Rate is optionally included in the Location Configuration
Response frame.
Location Indication Options 8 The Location Indication Options subelement is optionally
included in the Location Configuration Response frame.
Location Status 3 The Location Status subelement is included in the
Location Configuration Response frame. If all
configuration of the subelements contained in a Location
Configuration Request frame was successful, then a
single Location Status subelement is included in the
Location Configuration Response frame. For each
subelement contained in the Location Configuration
Request frame that is not successful a Location Status
subelement is included in the Location Configuration
Response frame that indicates the subelement ID and the
unsuccessful status code for that subelement ID.
Vendor Specific Information 221 Zero or more Vendor Specific subelements are included in
the Location Configuration Response frame.
1229
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.14.8 BSS Transition Management Query frame format
The BSS Transition Management Query frame uses the Action frame body format and is transmitted to
request or provide information on BSS transition candidate APs. The format of the BSS Transition
Management Query Action field is shown in Figure 9-700.
BSS Transition
BSS Transition Candidate List
Category WNM Action Dialog Token Query Reason Entries
(Optional)
Octets: 1 1 1 1 variable
Figure 9-700—BSS Transition Management Query Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value chosen by the STA sending the BSS Transition Management
Query frame to identify the query/request/response transaction.
The BSS Transition Query Reason field contains the reason code for a BSS transition management query as
defined in Table 9-176.
The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements, as
described in 9.4.2.37. The Neighbor Report elements are collected by the STA as part of its scanning
procedures and provided to the AP as described in 11.24.7.2. The length of the BSS Transition Candidate
List Entries field in a BSS Transition Management Query frame is limited by the maximum MMPDU size
(see 9.3.3.2).
9.6.14.9 BSS Transition Management Request frame format
The BSS Transition Management Request frame uses the Action frame body format and is transmitted by an
AP STA in response to a BSS Transition Management Query frame, or autonomously. The format of the
BSS Transition Management Request Action field is shown in Figure 9-701.
Category WNM Action Dialog Token Request mode Disassociation
Timer
Octets: 1 1 1 1 2
BSS BSS Transition
Termination Session Candidate List
Validity Interval Information URL
Duration (optional) Entries
(optional) (optional)
Octets: 1 0 or 12 variable variable
Figure 9-701—BSS Transition Management Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value received in the BSS Transition Management Query frame if the
BSS Transition Management Request frame is being transmitted in response to a BSS Transition
1230
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Management Query frame. If the BSS Transition Management Request frame is being transmitted other than
in response to a BSS Transition Management Query frame, then the Dialog Token field is a nonzero value
chosen by the AP STA sending the BSS Transition Management Request frame to identify the request/
response transaction.
The Request mode field is defined in Figure 9-702.
Preferred Disassociation BSS ESS
Candidate List Abridged Termination Disassociation Reserved
Included Imminent Included Imminent
Bit: 0 1 2 3 4 5- 7
Figure 9-702—Request Mode field
— The Preferred Candidate List Included (bit 0) field indicates whether the BSS transition candidate
list included in this frame is a preferred candidate list or a list of known BSS transition candidates.
The Preferred Candidate List Included bit set to 0 indicates that the receiving STA can ignore the
BSS Transition Candidate List Entries field (see 11.24.7.3). The Preferred Candidate List Included
bit set to 1 indicates that the sender expects the receiving STA to process this frame.
— The Abridged (bit 1) field indicates to the recipient of the frame the intended treatment of all
BSSIDs not listed in the BSS Transition Candidate List Entries field. The AP sets the Abridged bit
in the Request Mode field to 1 when a preference value of 0 is assigned to all BSSIDs that do NOT
appear in the BSS Transition Candidate List. The AP sets the Abridged bit in the Request Mode field
to 0 when the AP has no recommendation for or against any BSSID not present in the BSS
Transition Candidate List Entries field.
— The Disassociation Imminent (bit 2) field indicates whether the STA will be disassociated from the
current AP. The value 1 in the Disassociation Imminent bit in the Request Mode field indicates that
the STA is to be disassociated from the current AP, while the value 0 indicates that disassociation
from the AP is not imminent.
— The BSS Termination Included (bit 3) field indicates that the BSS Termination Duration field is
included, the BSS is shutting down and the STA will be disassociated. The AP sets the BSS
Termination Included bit in the Request mode field to 1 to indicate that the BSS is shutting down.
The BSS Termination Included bit is 0 if no BSS Termination Duration information is included in
the BSS Transition Management Request frame.
— The ESS Disassociation Imminent (bit 4) field indicates that the Session Information URL field is
included, and that the STA will be disassociated from the ESS. The value 1 in the ESS
Disassociation Imminent bit in the Request Mode field indicates that the STA is to be disassociated
from the ESS, while the value 0 indicates that disassociation from the ESS is not imminent. When
the ESS Disassociation Imminent bit value is 1, a Session Information URL field is included in the
BSS Transition Management Request frame.
The Disassociation Timer indicates the time after which the AP issues a Disassociation frame to this STA.
The Disassociation Timer field contains the number of beacon transmission times (TBTTs) until the AP
sends a Disassociation frame to this STA. A value of 0 indicates that the AP has not determined when it will
send a Disassociation frame to this STA. If the Disassociation Imminent field is 0, the Disassociation Timer
field is reserved. The format of the Disassociation Timer field is shown in Figure 9-703.
1231
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B15
Disassociation
Timer
Bits 16
Figure 9-703—Disassociation Timer field format
The Validity Interval field is the number of beacon transmission times (TBTTs) until the BSS transition
candidate list is no longer valid. A value of 0 is reserved.
The BSS Termination Duration field contains the BSS Termination Duration subelement (see 9.4.2.37) for
the current BSS and is present only when the BSS Termination Included field is 1 in the Request mode field.
The format of the optional Session Information URL field is shown in Figure 9-704. This field is present
when the ESS Disassociation Imminent field is 1.
URL Length URL (optional)
Octets: 1 variable
Figure 9-704—Session Information URL field format
The URL Length field is the value of the length of the URL field. The URL Length field is 0 when the URL
field is not present.
The URL field is a variable-length field formatted in accordance with IETF RFC 3986.
The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements described
in 9.4.2.37. If the STA has no information in response to the BSS Transition Management Query frame or in
an unsolicited BSS Transition Management Request frame, the Neighbor Report elements are omitted and
the Preferred Candidate List Included bit is 0. The length of the BSS Transition Candidate List Entries in a
BSS Transition Management Request frame is limited by the maximum MMPDU size (see 9.3.3.2).
9.6.14.10 BSS Transition Management Response frame format
The BSS Transition Management Response frame uses the Action frame body format and is optionally
transmitted by a STA in response to a BSS Transition Management Request frame. The format of the BSS
Transition Management Response Action field is shown in Figure 9-705.
BSS
BSS Transition
Category WNM Dialog BTM Status Termination Target BSSID Candidate List
Action Token Code (Optional)
Delay Entries
(Optional)
Octets: 1 1 1 1 1 0 or 6 variable
Figure 9-705— BSS Transition Management Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
1232
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Dialog Token field is the value in the corresponding BSS Transition Management Request frame. The
BSS Transition Management Response frame is transmitted in response to a BSS Transition Management
Request frame.
The BTM Status Code field contains the status code in response to a BSS Transition Management Request
frame as defined in Table 9-357. If the STA will transition to another BSS, then the status code is 0 (i.e.,
Accept). If the STA intends to retain the association with the current BSS, the status code is one of the
“Reject” status codes.
Table 9-357—BTM status code definitions
Status code Status code description
0 Accept
1 Reject—Unspecified reject reason.
2 Reject—Insufficient Beacon or Probe Response frames received from all candidates.
3 Reject—Insufficient available capacity from all candidates.
4 Reject—BSS termination undesired.
5 Reject—BSS termination delay requested.
6 Reject—STA BSS Transition Candidate List provided.
7 Reject—No suitable BSS transition candidates.
8 Reject—Leaving ESS.
9–255 Reserved
The BSS Termination Delay field is the number of minutes that the responding STA requests the BSS to
delay termination. This field is reserved if the Status code field value is not set to 5.
The Target BSSID field is the BSSID of the BSS that the non-AP STA transitions to. This field is present if
the Status code subfield contains 0, and not present otherwise.
The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements described
in 9.4.2.37. The Neighbor Report elements are collected by the STA as part of its scanning procedures and
provided to the AP as described in 11.24.7.4. The length of the BSS Transition Candidate List Entries field
in a BSS Transition Management Response frame is limited by the maximum MMPDU size (see 9.3.3.2).
9.6.14.11 FMS Request frame format
The FMS Request frame is sent by a non-AP STA to the AP to request the specified FMS and to propose
delivery intervals for a set of group addressed streams. The FMS Request frame is also sent by a non-AP
STA to request a modification to a previous FMS Request. The format of the Action field is shown in
Figure 9-706.
FMS Request
Category WNM Action Dialog Token
Element
Octets: 1 1 1 variable
Figure 9-706—FMS Request Action field format
1233
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value that is unique among the FMS Request frame sent to each
destination MAC address for which a corresponding FMS Report frame has not been received.
The FMS Request Element field indicates the group addressed traffic streams that are requested by the non-
AP STA. The FMS Request Element field contains one FMS Request element described in 9.4.2.76.
9.6.14.12 FMS Response frame format
The FMS Response frame is sent by an AP in response to an FMS Request frame, or sent by the AP to the
STA to instruct the non-AP STA to change the delivery interval or data rate. The format of the Action field
is shown in Figure 9-707.
Category WNM Action Dialog Token FMS Response Element
Octets: 1 1 1 variable
Figure 9-707—FMS Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value received in the FMS Request frame to identify the request/
response transaction. If an FMS Response frame is being transmitted other than in response to an FMS
Request frame, then the Dialog Token field is 0.
The FMS Response Element indicates the group addressed traffic streams that the AP supports and the
corresponding delivery intervals. The FMS Response Element field contains one FMS Response elements,
described in 9.4.2.77.
9.6.14.13 Collocated Interference Request frame format
The Collocated Interference Request frame uses the Action frame body format and is transmitted to request
collocated interference reports, sent using Collocated Interference Report frames. The format of the
Collocated Interference Request Action field is shown in Figure 9-708.
Category WNM Action Dialog Token Request Info
Octets: 1 1 1 1
Figure 9-708—Collocated Interference Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is any nonzero value to identify the request/response transaction.
The Request Info field is shown in Figure 9-709.
1234
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B1 B2 B7
Automatic Report Enabled Report Timeout
Bits: 2 6
Figure 9-709—Request Info field format
The Automatic Report Enabled subfield contains an unsigned integer value.
The Automatic Report Enabled subfield set to 0 indicates that the requesting STA cancels the previous
requests so that the receiving STA stops sending collocated interference reports.
The Automatic Report Enabled subfield set to 1 indicates that the requesting STA requests the receiving
STA to send a collocated interference report when the STA knows of a change in the collocated interference,
subject to meeting the Report Timeout requirement.
The Automatic Report Enabled subfield set to 2 indicates that the requesting STA requests the receiving
STA to send a collocated interference report periodically using the period included in the Report Period field
in the Collocated Interference Report element; see 9.4.2.85.
The Automatic Report Enabled subfield set to 3 indicates that the requesting STA requests the receiving
STA to send collocated interference reports periodically using the period included in the Report Period field
in the Collocated Interference Report element; see 9.4.2.85, or send a collocated interference report when
the STA knows of a change in the collocated interference, subject to meeting the Report Timeout
requirement.
The Report Timeout field contains a value in units of 200 TUs and indicates the minimum duration between
two consecutive Collocated Interference Report frames from the reporting STA. When the Automatic
Report Enabled subfield is 0, the Report Timeout field is reserved.
9.6.14.14 Collocated Interference Report frame format
The Collocated Interference Report frame uses the Action frame body format and is transmitted in response
to Collocated Interference Request frame. The format of the Collocated Interference Report Action field is
shown in Figure 9-710.
Collocated
Interference
Category WNM Action Dialog Token Report
Elements
Octets: 1 1 1 variable
Figure 9-710—Collocated Interference Report Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value received in the corresponding Collocated Interference Request
frame to identify the request/response transaction.
The Collocated Interference Report Elements field contains one or more Collocated Interference Report
elements to indicate the characteristics of the reported collocated interferences, as defined in 9.4.2.85.
1235
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.14.15 TFS Request frame format
The TFS Request frame is sent by a non-AP STA to the AP to request the specified traffic filtering. The
format of TFS Request frame is defined in Figure 9-711.
zero or more
TFS Request
elements
TFS Request
Category WNM Action Dialog Token
Elements
Octets: 1 1 1 variable
Figure 9-711—TFS Request frame format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a value chosen by the STA sending the TFS Request frame to identify the request/
response transaction.
The TFS Request Elements field contains one or more TFS Request elements to specify one or more traffic
filter sets that are requested by the non-AP STA, as defined in 9.4.2.80, or zero TFS Request elements to
cancel all of the existing traffic filter sets (see 11.24.12.2).
9.6.14.16 TFS Response frame format
The TFS Response frame is sent by an AP in response to a TFS Request frame. The format of the TFS
Response Action field is defined in Figure 9-712.
one or more
TFS Response
elements
TFS Response
Category WNM Action Dialog Token
Elements
Octets: 1 1 1 variable
Figure 9-712—TFS Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the value in the corresponding TFS Request frame.
The TFS Response Elements field contains one or more TFS Response elements to indicate the status of the
filtering parameters that the AP is requested to support, as defined in 9.4.2.81. The number of TFS Response
elements in a TFS Response frame is the same as the number of the TFS Request elements in the TFS
Request frame with the same dialog token, where the TFS Response elements appear in the same order as
the corresponding TFS Request elements in the TFS Request frame with the same dialog token.
1236
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.14.17 TFS Notify frame format
The TFS Notify frame is sent by an AP to a STA when a frame matching a traffic filter is encountered. The
format of the TFS Notify Action field is defined in Figure 9-713.
one or more
TFS IDs
Number of TFS
Category WNM Action IDs TFS ID List
Octets: 1 1 1 variable
Figure 9-713—TFS Notify Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Number of TFS IDs field indicates the number of 1-octet TFS IDs present in the TFS ID List field.
The TFS ID field indicates the traffic filter set containing the matched TCLAS element.
9.6.14.18 TFS Notify Response frame format
A TFS Notify Response frame is transmitted by a non-AP STA to an AP to request the AP to resume
generation of the TFS Notify frame when a frame matches any traffic filter set identified by the TFS ID(s)
included in the TFS Notify Response frame. The format of the TFS Notify Response Action field is shown
in Figure 9-714.
Number of TFS
Category WNM Action TFS ID List
IDs
Octets: 1 1 1 variable
Figure 9-714—TFS Notify Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Number of TFS IDs field indicates the number of 1-octet TFS IDs present in the TFS ID List field.
The TFS ID List field indicates the identifiers of the traffic filter sets.
9.6.14.19 WNM Sleep Mode Request frame format
The WNM Sleep Mode Request frame is sent by a non-AP STA to the AP to enter the WNM sleep mode.
The format of the WNM Sleep Mode Request frame is defined in Figure 9-715.
1237
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
one or more
TFS Request
elements
Category WNM Dialog WNM Sleep TFS Request
Action Token Mode Element Elements
Octets: 1 1 1 6 variable
Figure 9-715—WNM Sleep Mode Request frame format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value chosen by the non-AP STA sending the WNM Sleep Mode
Request frame to identify the request/response transaction.
The WNM Sleep Mode Element field contains a WNM Sleep Mode element that is requested by a non-AP
STA, as described in 9.4.2.82.
The TFS Request Elements field contains one or more TFS Request elements to specify the traffic filters that
are requested by a non-AP STA, as defined in 9.4.2.80.
9.6.14.20 WNM Sleep Mode Response frame format
The WNM Sleep Mode Response frame is sent by an AP in response to a WNM Sleep Mode Request frame
or is sent without solicitation by an AP to a non-AP STA upon the AP’s deletion of all traffic filter sets
established according to the traffic filtering agreement between the AP and the non-AP STA. The format of
the WNM Sleep Mode Response Action field is defined in Figure 9-716.
Category WNM Action Dialog Token Key Data Key Data
Length
Octets: 1 1 1 2 variable
one or more
TFS Response
elements
WNM Sleep TFS Response
Mode Element Elements
Octets: variable variable
Figure 9-716—WNM Sleep Mode Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
When the WNM Sleep Mode Response frame is transmitted as a response to a WNM Sleep Mode Request
frame, the Dialog Token field is the value in the corresponding WNM Sleep Mode Request frame. When the
WNM Sleep Mode Response frame is transmitted as an unsolicited response, the Dialog Token field is set to
0.
1238
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Key Data Length field is the length of the Key Data field. If the management frame protection is not
used, this field is 0.
The Key Data field contains zero or more subelements that provide the current GTK and IGTK to the STA.
The format of these subelements is given in Figure 9-717 and Figure 9-718. The subelement IDs for these
subelements are defined in Table 9-358. Each subelement starts with the ID and Length fields. The Length
field in the subelement is the length of the contents of the subelement. When management frame protection
is not used, the Key Data field is not present.
Table 9-358—Optional subelement IDs for WNM Sleep Mode parameters
Value Contents of subelement
0 GTK
1 IGTK
2–255 Reserved
The GTK subelement contains the Group Key as shown in Figure 9-717.
Subelement
Length Key Info Key Length RSC Key
ID
Octets: 1 1 2 1 8 5 to 32
Figure 9-717—WNM Sleep Mode GTK subelement format
The Subelement ID field is set to 0.
The Length field is defined in 9.4.3.
The Key Info field is defined in Figure 9-319.
The Key Length field is the length of the Key field in octets.
The RSC field contains the receive sequence counter (RSC) for the GTK being installed. The RSC field
gives the current message number for the GTK to allow a STA to identify replayed MPDUs. If the RSC field
value is less than 8 octets in length, the remaining octets are set to 0. The least significant octet of the TSC or
PN is in the first octet of the RSC field.
NOTE—The RSC field value for TKIP is the Transmit Sequence Counter (TSC) and is stored in the first 6 octets; for
CCMP it is the Packet Number (PN) and is stored in the first 6 octets; see Table 12-5.
The Key field is the GTK being distributed.
The IGTK subelement contains the Integrity GTK as shown in Figure 9-718.
Subelement Length Key ID PN Key
ID
Octets: 1 1 2 6 16
Figure 9-718—WNM Sleep Mode IGTK subelement format
1239
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Subelement ID field is set to 1.
The Length field is defined in 9.4.3.
The Key ID field indicates the value of the BIP key identifier.
The PN field indicates the receive sequence counter for the IGTK being installed. The PN field gives the
current message number for the IGTK, to allow a STA to identify replayed MPDUs.
The Key field is the IGTK being distributed.
NOTE 1—There might be multiple GTK and multiple IGTK subelements if a group rekeying is in process when the
non-AP STA wakes up from WNM sleep mode.
NOTE 2—Management frame protection is used to provide confidentiality, replay, and integrity protection for GTK/
IGTK update in WNM Sleep Mode Response frames.
The WNM Sleep Mode Element field contains a WNM Sleep Mode element, as described in 9.4.2.82.
The TFS Response Elements field contains one or more TFS Response elements to specify the traffic filters,
as defined in 9.4.2.81.
9.6.14.21 TIM Broadcast Request frame format
The format of the TIM Broadcast Request Action field is shown in Figure 9-719.
Category WNM Action Dialog Token TIM Broadcast Request
Element
Octets: 1 1 1 3
Figure 9-719—TIM Broadcast Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value chosen by the STA sending the TIM Broadcast Request frame to
identify the request/response transaction.
The TIM Broadcast Request Element field contains a TIM Broadcast Request Element as specified in
9.4.2.83.
9.6.14.22 TIM Broadcast Response frame format
The format of the TIM Broadcast Response Action field is shown in Figure 9-720.
Category WNM Action Dialog Token TIM Broadcast
Response Element
Octets: 1 1 1 3 or 12
Figure 9-720—TIM Broadcast Response Action field format
The Category field is defined in 9.4.1.11.
1240
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value of the corresponding TIM Broadcast Request frame. If the TIM
Broadcast Response frame is being transmitted other than in response to a TIM Broadcast Request frame,
then the dialog token is 0.
The TIM Broadcast Response Element field contains a TIM Broadcast Response Element as specified in
9.4.2.84.
9.6.14.23 QoS Traffic Capability Update frame format
The QoS Traffic Capability Update frame is sent by a non-AP STA to the AP to update QoS Traffic
Capability information. The format of the Action field is shown in Figure 9-721.
Category WNM Action QoS Traffic
Capability Flags
Octets: 1 1 1
Figure 9-721—QoS Traffic Capability Update Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The QoS Traffic Capability Flags field is defined in Table 9-359. The QoS Traffic Capability Flags field
comprises 1 octet, with the bits 4–6 serving as QoS Traffic Capability Flags. Each of the bits 4–6 serves as a
flag for one of the three user priorities, UP 4–6. The field is 1 to indicate the expectation of generating traffic
belonging to the corresponding user priority (UP). The field is 0 to indicate that such expectation does not
exist. The use of the QoS Traffic Capability Update frame is described in 11.24.10.
Table 9-359—QoS Traffic Capability Flags definition
Bit Description
0–3 Reserved
4 UP 4 Traffic
5 UP 5 Traffic
6 UP 6 Traffic
7 Reserved
9.6.14.24 Channel Usage Request frame format
The Channel Usage Request frame is sent by a non-AP STA to the AP to request the specified Channel
Usage information. The format of the Channel Usage Request Action field is defined in Figure 9-722.
1241
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Supported
WNM Dialog Channel Operating
Category Usage
Action Token Elements Classes
Element
Octets: 1 1 1 variable variable
Figure 9-722—Channel Usage Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value chosen by the non-AP STA sending the Channel Usage Request
frame to identify the request/response transaction.
The Channel Usage Element field includes one or more Channel Usage elements described in 9.4.2.86 to
identify the request Usage Mode.
The Supported Operating Classes Element field includes a Supported Operating Classes element to indicate
the supported operating classes for the requested network type, consistent with the Country element
advertised by the AP. The Supported Operating Classes is described in 9.4.2.54.
9.6.14.25 Channel Usage Response frame format
The Channel Usage Response frame is sent by an AP STA in response to a Channel Usage Request frame, or
autonomously. The format of the Channel Usage Response Action field is shown in Figure 9-723.
Channel Power EDCA Transmit
Parameter Power
Category WNM Dialog Usage Country Constraint Set Envelope
Action Token Element String Element
s (optional) Element element
(optional) (optional)
Octets: 1 1 1 variable 3 0 or 3 0 or 20 variable
Figure 9-723—Channel Usage Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value received in the Channel Usage Request frame if the Channel
Usage Response frame is being transmitted in response to a Channel Usage Request frame. The Dialog
Token field is 0 if the Channel Usage Response frame is being transmitted other than in response to a
Channel Usage Request frame.
The Channel Usage Element field includes zero or more Channel Usage elements described in 9.4.2.86.
The Country String field is the value contained in the dot11CountryString attribute.
The Power Constraint Element field includes zero or one Power Constraint elements described in 9.4.2.14.
The use of the Power Constraint element included in the Power Constraint Element field is described in
11.24.15.
1242
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The EDCA Parameter Set Element field includes zero or one EDCA Parameter Set elements described in
9.4.2.29. The use of the EDCA Parameter Set element included in the EDCA Parameter Set Element field is
described in 11.24.15.
The Transmit Power Envelope element field is defined in 9.4.2.162.
9.6.14.26 DMS Request frame format
The DMS Request frame is sent by a non-AP STA to the AP to define information about a DMS request to
the AP. The format of the DMS Request Action field is defined in Figure 9-724.
DMS
Category WNM Action Dialog Token Request
Elements
Octets: 1 1 1 variable
Figure 9-724—DMS Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is a nonzero value chosen by the non-AP STA sending the DMS Request frame to
identify the request/response transaction.
The DMS Request Elements field contains one or more DMS Request elements as specified in 9.4.2.88.
9.6.14.27 DMS Response frame format
The DMS Response frame is sent by an AP or a mesh STA in response to a DMS Request frame, or
autonomously to terminate a requested DMS stream, or to advertise the current parameters for one or more
GCR streams. The format of the DMS Response Action field is shown in Figure 9-725.
DMS Response
Category WNM Action Dialog Token
Elements
Octets: 1 1 1 variable
Figure 9-725—DMS Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is the nonzero value received in the DMS Request frame if the DMS Response
frame is being transmitted in response to a DMS Request frame. The Dialog Token field is 0 if the DMS
Response frame is being transmitted autonomously, and not in response to a DMS Request frame.
The DMS Response Elements field contains one or more DMS Response elements as specified in 9.4.2.89.
9.6.14.28 Timing Measurement Request frame format
The format of the Timing Measurement Request Action field is shown in Figure 9-726.
1243
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Category WNM Action Trigger
Octets: 1 1 1
Figure 9-726—Timing Measurement Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Trigger field set to the value 1 indicates that the sending STA requests a timing measurement procedure
at the receiving STA as defined in 11.24.5. The Trigger field set to the value 0 indicates that the sending
STA requests that the receiving STA stop sending Timing Measurement frames. Trigger field values 2–255
are reserved.
9.6.14.29 WNM Notification Request frame format
The format of the WNM Notification Request Action field is shown in Figure 9-727.
Optional
Category WNM Action Dialog Token Type
Subelements
Octets: 1 1 1 1 variable
Figure 9-727—WNM Notification Request Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the WNM notification request
to identify the request/response transaction.
The Type field indicates the type of WNM notification, as defined in Table 9-360.
Table 9-360—WNM notification type
Value Description
0 Firmware Update Notification
1–220 Reserved
221 Vendor Specific
222–255 Reserved
The Optional Subelements field contains zero or more subelements. The subelement format and ordering of
subelements are defined in 9.4.3.
The Subelement ID field values for the defined subelements are shown in Table 9-361.
1244
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-361—Optional subelement IDs for WNM Notification Request
Subelement ID Name Extensible
0 AP Descriptor
1 Firmware Version—Current
2 Firmware Version—New
3–255 Reserved
When the Type field is 0, the AP Descriptor, Firmware Version—Current, and Firmware Version—New
optional subelements are included in the WNM Notification Request frame. The AP descriptor field format
is as defined in Figure 9-374. The Firmware Version—Current subelement contains the current firmware
version, in the Firmware Version subelement format defined in Figure 9-380. The Firmware Version—New
subelement contains the new firmware version, in the Firmware Version subelement format defined in
Figure 9-380.
9.6.14.30 WNM Notification Response frame format
The format of the WNM Notification Response Action field is shown in Figure 9-728.
Response
Category WNM Action Dialog Token
Status
Octets: 1 1 1 1
Figure 9-728—WNM Notification Response Action field format
The Category field is defined in 9.4.1.11.
The WNM Action field is defined in 9.6.14.1.
The Dialog Token field is set to the nonzero value of the corresponding WNM Notification Request frame.
The Response Status field indicates the Response Status value, as defined in Table 9-362.
Table 9-362—WNM Notification Response Status
Value Description
0 Notification Acknowledged
1–255 Reserved
9.6.15 Unprotected WNM Action details
9.6.15.1 Unprotected WNM Action fields
Unprotected WNM Action frames are not encapsulated using mechanisms defined for robust Management
frames. An Unprotected WNM Action field, in the octet field immediately after the Category field,
differentiates the formats. The Unprotected WNM Action field values associated with each frame format is
defined in Table 9-363.
1245
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-363—Unprotected WNM Action field values
Action field value Description
0 TIM
1 Timing Measurement
2–255 Reserved
9.6.15.2 TIM frame format
The format of the TIM Action field is shown in Figure 9-729.
Category Action Check Beacon Timestamp TIM Element
Octets: 1 1 1 8 6–256
Figure 9-729—TIM Action field format
The Category field is defined in 9.4.1.11.
The Unprotected WNM Action field is defined in 9.6.15.1.
The Check Beacon field is defined as an unsigned integer initialized to 0, that increments when a critical
update to the Beacon frame has occurred; see 11.2.3.17.
The Timestamp field is defined in 9.4.1.10. The field contains a valid TSF timestamp when the TIM
Broadcast Response frame contained a Status field set to “Accept, valid timestamp present in TIM frames”
or “Overridden, valid timestamp present in TIM frames.” The field is reserved otherwise.
The TIM Element field contains a TIM element as specified in 9.4.2.6. The bit corresponding to buffered
group addressed frames is reserved for all BSSIDs.
9.6.15.3 Timing Measurement frame format
The Timing Measurement frame is used to support the timing measurement procedure described in 11.24.5.
The format of the Timing Measurement Action field is shown in Figure 9-730.
Follow Up
Category Action Dialog Token Dialog Token TOD
Octets: 1 1 1 1 4
Max TOD Max TOA
TOA
Error Error
Octets: 4 1 1
Figure 9-730—Timing Measurement Action field format
The Category field is defined in 9.4.1.11.
The Unprotected WNM Action field is defined in 9.6.15.1.
1246
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Dialog Token field is a nonzero value chosen by the sending STA to identify the Timing Measurement
frame as the first of a pair, with the second or follow-up Timing Measurement frame to be sent later. The
Dialog Token field is set to 0 to indicate that the Timing Measurement frame will not be followed by a
subsequent follow-up Timing Measurement frame.
The Follow Up Dialog Token field is the nonzero value of the Dialog Token field of the previously
transmitted Timing Measurement frame to indicate that it is the follow up Timing Measurement frame and
that the TOD, TOA, Max TOD Error and Max TOA Error fields contain the values of the timestamps
captured with the first Timing Measurement frame of the pair. The Follow Up Dialog Token field is 0 to
indicate that the Timing Measurement frame is not a follow up to a previously transmitted Timing
Measurement frame. The value 0 in this field also indicates that the TOD, TOA, Max TOD Error, and Max
TOA Error fields are reserved. See 11.24.5.
The TOD, TOA, Max TOD Error, and Max TOA Error fields are expressed in units of 10 ns.
The TOD field contains a timestamp that represents the time at which the start of the preamble of the
previously transmitted Timing Measurement frame appeared at the transmit antenna connector.
The TOA field contains a timestamp that represents the time at which the start of the preamble of the Ack
frame to the previously transmitted Timing Measurement frame arrived at the receive antenna connector.
NOTE—The values specified in the TOD and TOA fields are described in 6.3.57.
The Max TOD Error field contains an upper bound for the error in the value specified in the TOD field. For
instance, a value of 2 in the Max TOD Error field indicates that the value in the TOD field has a maximum
error of ± 20 ns.
The Max TOA Error field contains an upper bound for the error in the value specified in the TOA field. For
instance, a value of 2 in the Max TOA Error field indicates that the value in the TOA field has a maximum
error of ± 20 ns.
A value of 0 for the Max TOD Error or the Max TOA Error field indicates that the upper bound on the error
in the corresponding TOD or TOA value is unknown. A value of 255 indicates that the upper bound on the
error is greater than or equal to 2.55 µs.
9.6.16 Self-protected Action frame details
9.6.16.1 Self-protected Action fields
The Self-protected Action frame is defined to allow robust STA-STA communications of the Action frames
that are not robust (see 9.4.1.11). The protocols that use these Action frames are responsible for deciding
whether to protect these frames and supporting protection mechanisms for these frames as needed.
Self-protected Action frames have a different nature than Public Action frames and robust Action frames.
Robust Action frames assume the existence of a completely established security association. Self-protected
Action frames typically exist to manage the creation and deletion of security associations, regardless of
whether they are completely established.
Public Action frames are defined as public for all STAs, including those that are not in the BSS and MBSS.
Self-protected Action frames, however, are used for relationship creation and maintenance between two
specific STAs. Their public nature is incidental.
A Self-protected Action field, in the octet field immediately after the Category field, differentiates the
formats. The defined Self-protected Action frames are listed in Table 9-364.
1247
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-364—Self-protected Action field values
Self-protected Action field value Description
0 Reserved
1 Mesh Peering Open
2 Mesh Peering Confirm
3 Mesh Peering Close
4 Mesh Group Key Inform
5 Mesh Group Key Acknowledge
6–255 Reserved
The Mesh Peering Open frame, the Mesh Peering Confirm frame, and the Mesh Peering Close frame are
referred to as mesh peering Management frames.
9.6.16.2 Mesh Peering Open frame format
9.6.16.2.1 Mesh Peering Open frame self protection
Protection of this frame is provided when authenticated mesh peering exchange (AMPE) is enabled. AMPE
provides integrity protection of Mesh Peering Open frames.
When the Mesh Peering Open frame is used by the mesh peering management (MPM) protocol, integrity
protection on the frame is not enabled.
9.6.16.2.2 Mesh Peering Open frame details
The Mesh Peering Open frame is used to open a mesh peering using the procedures defined in 14.3.6 and in
14.5.5. The format of the Mesh Peering Open frame Action field is shown in Table 9-365.
Table 9-365—Mesh Peering Open frame Action field format
Order Information Notes
1 Category
2 Self-protected Action
3 Capability
4 Supported Rates and BSS
Membership Selectors
5 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors element
and BSS Membership is present if there are more than eight supported rates and is optionally
Selectors present otherwise.
6 Power Capability The Power Capability element is present if
dot11SpectrumManagementRequired is true.
7 Supported Channels The Supported Channels element is present if
dot11SpectrumManagementRequired is true and
dot11ExtendedChannelSwitchActivated is false.
1248
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-365—Mesh Peering Open frame Action field format (continued)
Order Information Notes
8 RSN The RSNE is present if dot11MeshSecurityActivated,
dot11ProtectedQLoadReportActivated, or
dot11ProtectedTXOPNegotiationActivated is true; otherwise not
present.
9 Mesh ID
10 Mesh Configuration
11 Mesh Peering Management The Mesh Peering Management element is set as described in 9.4.2.98.
12 ERP Information The ERP element is present if ERP mesh STA detects NonERP STAs in
its vicinity and is optionally present otherwise.
13 Supported Operating The Supported Operating Classes element is present if
Classes dot11ExtendedChannelSwitchActivated is true.
14 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
15 HT Operation The HT Operation element is included when
dot11HighThroughputOptionImplemented is true.
16 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when the
element dot112040BSSCoexistenceManagementSupport is true.
17 Extended Capabilities The Extended Capabilities element is optionally present if any of the
element fields in this element are nonzero.
18 Interworking The Interworking element is present if
dot11InterworkingServiceActivated is true.
19 VHT Capabilities The VHT Capabilities element is present when
dot11VHTOptionImplemented is true.
20 VHT Operation The VHT Operation element is present when
dot11VHTOptionImplemented is true.
21 Operating Mode The Operating Mode Notification element is optionally present if
Notification dot11OperatingModeNotificationImplemented is true.
The Category field is defined in 9.4.1.11.
The Self-protected Action field is defined in 9.6.16.1.
The MIC element appears prior to the Authenticated Mesh Peering Exchange element in the Mesh Peering
Open frame. The information following the MIC element through to the end of the Mesh Peering Open
frame body is encrypted and authenticated (see 14.5).
9.6.16.3 Mesh Peering Confirm frame format
9.6.16.3.1 Mesh Peering Confirm frame self protection
Protection of this frame is provided when authenticated mesh peering exchange (AMPE) is enabled. AMPE
provides integrity protection of Mesh Peering Confirm frames.
When the Mesh Peering Confirm frame is used by the mesh peering management (MPM) protocol, integrity
protection on the frame is not enabled.
1249
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.16.3.2 Mesh Peering Confirm frame details
The Mesh Peering Confirm frame is used to confirm a mesh peering using the procedures defined in 14.3.7
and 14.5.5. The format of the Mesh Peering Confirm frame Action field is shown in Table 9-366.
Table 9-366—Mesh Peering Confirm frame Action field format
Order Information Notes
1 Category
2 Self-protected Action
3 Capability
4 AID
5 Supported Rates and BSS
Membership Selectors
6 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors element
and BSS Membership is present if there are more than eight supported rates and is optionally
Selectors present otherwise.
7 RSN The RSNE is present only when dot11MeshSecurityActivated,
dot11ProtectedQLoadReportActivated, or
dot11ProtectedTXOPNegotiationActivated is true.
8 Mesh ID
9 Mesh Configuration The Mesh Configuration element is present when dot11MeshActivated
is true.
10 Mesh Peering Management The Mesh Peering Management element is set as described in 9.4.2.102.
11 HT Capabilities The HT Capabilities element is present when
dot11HighThroughputOptionImplemented is true.
12 HT Operation The HT Operation element is included when
dot11HighThroughputOptionImplemented is true.
13 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when the
element dot112040BSSCoexistenceManagementSupport is true.
14 Extended Capabilities The Extended Capabilities element is optionally present if any of the
element fields in this element are nonzero.
15 VHT Capabilities The VHT Capabilities element is present when
dot11VHTOptionImplemented is true.
16 VHT Operation The VHT Operation element is present when
dot11VHTOptionImplemented is true.
17 Operating Mode The Operating Mode Notification element is optionally present if
Notification dot11OperatingModeNotificationImplemented is true.
The Category field is defined in 9.4.1.11.
The Self-protected Action field is defined in 9.6.16.1.
The MIC element appears prior to the Authenticated Mesh Peering Exchange element in the Mesh Peering
Open frame. The information following the MIC element through to the end of the Mesh Peering Confirm
frame body is encrypted and authenticated (see 14.5).
1250
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.16.4 Mesh Peering Close frame format
9.6.16.4.1 Mesh Peering Close frame self protection
Protection of this frame is provided when authenticated mesh peering exchange (AMPE) is enabled. AMPE
provides integrity protection of Mesh Peering Close frames.
When the Mesh Peering Close frame is used by the mesh peering management (MPM) protocol, integrity
protection on the frame is not enabled.
9.6.16.4.2 Mesh Peering Close frame details
The Mesh Peering Close frame is used to close a mesh peering using the procedures defined in 14.3.8 and in
14.5.5. The format of the Mesh Peering Close frame Action field is shown in Table 9-367.
Table 9-367—Mesh Peering Close frame Action field format
Order Information Notes
1 Category
2 Self-protected Action
3 Mesh ID
4 Mesh Peering Management
The Category field is defined in 9.4.1.11.
The Self-protected Action field is defined in 9.6.16.1.
The MIC element appears prior to the Authenticated Mesh Peering Exchange element in the Mesh Peering
Open frame. The information following the MIC element through to the end of the Mesh Peering Close
frame body is encrypted and authenticated (see 14.5).
9.6.16.5 Mesh Group Key Inform frame format
9.6.16.5.1 Mesh Group Key Inform frame self protection
The protection of the frames is provided by the mesh group key handshake protocol (see 14.6) that uses
Mesh Group Key Inform frames.
9.6.16.5.2 Mesh Group Key Inform frame details
The Mesh Group Key Inform frame is used to update a mesh GTK (MGTK) with a peer. The format of the
Mesh Group Key Inform frame Action field is shown in Table 9-368.
1251
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-368—Mesh Group Key Inform frame Action field format
Order Information Notes
1 Category
2 Self-protected Action
3 MIC element
4 Authenticated Mesh
Peering Exchange
The Category field is defined in 9.4.1.11.
The Self-protected Action field is defined in 9.6.16.1.
The MIC element is set as defined in 9.4.2.119.
The Authenticated Mesh Peering Exchange element is set according to 14.6. The information following the
MIC element through to the end of the Mesh Group Key Inform frame body is encrypted and authenticated
(see 14.6.2).
9.6.16.6 Mesh Group Key Acknowledge frame format
9.6.16.6.1 Mesh Group Key Acknowledge frame self protection
The protection of the frames is provided by the mesh group key handshake protocol (see 14.6) that uses
Mesh Group Key Acknowledge frames.
9.6.16.6.2 Mesh Group Key Acknowledge frame details
The Mesh Group Key Acknowledge frame is used to acknowledge receipt and processing of a Mesh Group
Key Inform frame. The format of the Mesh Group Key Acknowledge frame Action field is shown in
Table 9-369.
Table 9-369—Mesh Group Key Acknowledge frame Action field format
Order Information Notes
1 Category
2 Self-protected Action
3 MIC element
4 Authenticated Mesh
Peering Exchange
The Category field is defined in 9.4.1.11.
The Self-protected Action field is defined in 9.6.16.1.
The MIC element is set as defined in 9.4.2.119.
1252
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Authenticated Mesh Peering Exchange element is set according to 14.6. The information following the
MIC element through to the end of the Mesh Group Key Acknowledge frame body is encrypted and
authenticated (see 14.6.2).
9.6.17 Mesh Action frame details
9.6.17.1 Mesh Action fields
Several Mesh Action frame formats are defined for mesh BSS operation. A Mesh Action field, in the octet
field immediately after the Category field, differentiates the formats. The Mesh Action field values
associated with each frame format are defined in Table 9-370.
Table 9-370—Mesh Action field values
Mesh Action field value Description
0 Mesh Link Metric Report
1 HWMP Mesh Path Selection
2 Gate Announcement
3 Congestion Control Notification
4 MCCA Setup Request
5 MCCA Setup Reply
6 MCCA Advertisement Request
7 MCCA Advertisement
8 MCCA Teardown
9 TBTT Adjustment Request
10 TBTT Adjustment Response
11–255 Reserved
9.6.17.2 Mesh Link Metric Report frame format
The Mesh Link Metric Report frame is transmitted by a mesh STA to a neighbor peer mesh STA to report
metric information on the link between the two mesh STAs. It is also transmitted by a mesh STA to a
neighbor peer mesh STA to request metric information on the link between the two mesh STAs from the
recipient. This frame is transmitted using an individually addressed frame. The format of the Mesh Link
Metric Report frame Action field is shown in Table 9-371.
Table 9-371—Mesh Link Metric Report frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 Mesh Link Metric Report
element
1253
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
The Mesh Link Metric Report element is set as described in 9.4.2.100.
9.6.17.3 HWMP Mesh Path Selection frame format
The HWMP Mesh Path Selection frame is transmitted by a mesh STA to establish, update or delete paths to
other mesh STAs using the HWMP defined in 14.10. This frame is transmitted in an individually or group
addressed frame depending on the contained elements and as defined in 14.10.7. The format of the HWMP
Mesh Path Selection frame Action field is shown in Table 9-372.
The HWMP Mesh Path Selection frame contains one or more of the elements indicated in Table 9-372.
Table 9-372—HWMP Mesh Path Selection frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 PREQ element A PREQ element is optionally present
4 PREP element A PREP element is optionally present
5 PERR element A PERR element is optionally present
6 RANN element A RANN element is optionally present
Usage of the HWMP Mesh Path Selection frame is described in 14.10.7.
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
The PREQ element is set as described in 9.4.2.113. It is present in a HWMP Mesh Path Selection frame as
described in 14.10.9.
The PREP element is set as described in 9.4.2.114.
The PERR element is set as described in 9.4.2.115.
The RANN element is set as described in 9.4.2.112.
9.6.17.4 Gate Announcement frame format
The Gate Announcement frame is transmitted by a mesh gate to announce its presence in the MBSS. This
frame is transmitted using group addresses. The format of the Gate Announcement frame Action field is
shown in Table 9-373.
1254
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-373—Gate Announcement frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 GANN element
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
The GANN element is set as described in 9.4.2.111.
9.6.17.5 Congestion Control Notification frame format
A mesh STA uses the Congestion Control Notification frame to indicate its congestion status to its neighbor
peer mesh STA(s). This frame is transmitted using individual addresses or group addresses. The format of
the Congestion Control Notification frame Action field is shown in Table 9-374.
Table 9-374—Congestion Control Notification frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 Congestion Notification One or more Congestion Notification elements (9.4.2.101) are present.
element Repeated N times (N is the number of Congestion Notification
elements contained in the frame).
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
The Congestion Notification element is set as described in 9.4.2.101.
9.6.17.6 MCCA Setup Request frame format
The MCCA Setup Request frame is used to set up an MCCAOP reservation. A mesh STA (whose
dot11MCCAActivated is true) transmits the MCCA Setup Request frame to one or more neighbor mesh
STAs (whose dot11MCCAActivated values also are true). This frame is transmitted using individual
addresses or group addresses. The format of the MCCA Setup Request frame Action field is shown in
Table 9-375.
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
The MCCAOP Setup Request element is described in 9.4.2.106.
1255
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-375—MCCA Setup Request frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 MCCAOP Setup Request
element
9.6.17.7 MCCA Setup Reply frame format
The MCCA Setup Reply frame is used to reply to an MCCA Setup Request frame. It is transmitted by a
mesh STA with dot11MCCAActivated equal to true to a neighbor peer mesh STA with
dot11MCCAActivated equal to true. This frame is transmitted using individual addresses. The format of the
MCCA Setup Reply frame Action field is shown in Table 9-376.
Table 9-376—MCCA Setup Reply frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 MCCAOP Setup Reply
element
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
The MCCAOP Setup Reply element is described in 9.4.2.107.
9.6.17.8 MCCA Advertisement Request frame format
The MCCA Advertisement Request frame is transmitted by a mesh STA with dot11MCCAActivated equal
to true to a neighbor peer mesh STA with dot11MCCAActivated equal to true in order to request MCCAOP
advertisements from the neighbor peer mesh STA. This frame is transmitted using individual addresses. The
format of the MCCA Advertisement Request frame Action field is shown in Table 9-377.
Table 9-377—MCCA Advertisement Request frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 MCCAOP Advertisement An MCCAOP Advertisement Overview element is optionally present.
Overview element
The Category field is defined in 9.4.1.11.
1256
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Mesh Action field is defined in 9.6.17.1.
The MCCAOP Advertisement Overview element is described in 9.4.2.108.
9.6.17.9 MCCA Advertisement frame format
The MCCA Advertisement frame is transmitted by a mesh STA with dot11MCCAActivated equal to true to
one or more neighbor peer mesh STAs with dot11MCCAActivated equal to true. This frame is transmitted
using group addresses or individual addresses. The format of the MCCA Advertisement frame Action field
is shown in Table 9-378.
Table 9-378—MCCA Advertisement frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 MCCAOP Advertisement An MCCAOP Advertisement Overview element is optionally present.
Overview element
4 MCCAOP Advertisement If an MCCAOP Advertisement Overview element is present, zero or
elements more MCCAOP Advertisement elements are present. If an MCCAOP
Advertisement Overview element is not present, one or more
MCCAOP Advertisement elements are present.
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
The MCCAOP Advertisement Overview element is described in 9.4.2.108.
The MCCAOP Advertisement element is described in 9.4.2.109.
9.6.17.10 MCCA Teardown frame format
The MCCA Teardown frame is transmitted by a mesh STA with dot11MCCAActivated equal to true to one
or more neighbor peer mesh STAs with dot11MCCAActivated equal to true. This frame is transmitted using
group addresses or individual addresses. The format of the MCCA Teardown frame Action field is shown in
Table 9-379.
Table 9-379—MCCA Teardown frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 MCCAOP Teardown element
The Category field is defined in 9.4.1.11.
1257
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Mesh Action field is defined in 9.6.17.1.
The MCCAOP Teardown element is described in 9.4.2.110.
9.6.17.11 TBTT Adjustment Request frame format
The TBTT Adjustment Request frame is used to request a particular neighbor peer mesh STA to adjust its
TBTT. This frame is transmitted using individual addresses. The format of the TBTT Adjustment Request
frame Action field is shown in Table 9-380.
Table 9-380—TBTT Adjustment Request frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 Beacon Timing element Repeated N_Info times (N_Info is a number of beacon timing
information tuples as described in 14.13.4.2.5).
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
The Beacon Timing element is set as described in 9.4.2.105. When not all beacon timing information is
included in a Beacon Timing element due to the maximum element size limit, multiple Beacon Timing
elements are present. The elements are present in the order of Beacon Timing Element Number field value
in the Report Control field of the Beacon Timing element.
9.6.17.12 TBTT Adjustment Response frame format
The TBTT Adjustment Response frame is used to respond to a TBTT adjustment request. This frame is
transmitted using individual addresses. The format of the TBTT Adjustment Response frame Action field is
shown in Table 9-381.
Table 9-381—TBTT Adjustment Response frame Action field format
Order Information Notes
1 Category
2 Mesh Action
3 Status Code
4 Beacon Timing element Repeated N_Info times (N_Info is a number of beacon timing
(optional) information tuples as described in 14.13.4.2.5).
The Category field is defined in 9.4.1.11.
The Mesh Action field is defined in 9.6.17.1.
1258
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Status Code field is set as described in 14.13.4.4.2.
The Beacon Timing element is set as defined in 9.4.2.105. It is present only if the Status Code is set to
CANNOT_FIND_ALTERNATIVE_TBTT (i.e., when the request is not successful due to the neighbor
constraint). When not all beacon timing information is included in a Beacon Timing element due to the
maximum element size limit, multiple Beacon Timing elements are present. The elements are present in the
order of Beacon Timing Element Number field value in the Report Control field of the Beacon Timing
element.
9.6.18 Multihop Action frame details
9.6.18.1 Multihop Action fields
Several Multihop Action frame formats are defined for mesh BSS operation. A Multihop Action field, in the
octet field immediately after the Category field, differentiates the formats. The Multihop Action field values
associated with each frame format are defined in Table 9-382. The Mesh Control field is present
immediately after the Multihop Action field in all Multihop Action frames.
Table 9-382—Multihop Action field values
Multihop Action field value Description
0 Proxy Update
1 Proxy Update Confirmation
2–255 Reserved
9.6.18.2 Proxy Update frame format
The Proxy Update frame is used to inform the recipient about new, updated, or deleted proxy information.
This frame is transmitted using individual addresses. The format of the Proxy Update frame Action field is
shown in Table 9-383.
Table 9-383—Proxy Update frame Action field format
Order Information Notes
1 Category
2 Multihop Action
3 Mesh Control
4 PXU element Repeated N times (N is the number of PXU elements contained in the
frame).
The Category field is defined in 9.4.1.11.
The Multihop Action field is defined in 9.6.18.1.
The Mesh Control field is set as defined in 9.2.4.7.3.
1259
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PXU element is described in 9.4.2.116. The Proxy Update frame allows the inclusion of multiple PXU
elements.
9.6.18.3 Proxy Update Confirmation frame format
The Proxy Update Confirmation frame is transmitted by a mesh STA in response to a Proxy Update frame.
This frame is used to inform that the corresponding PXU element has been properly received and is
transmitted using individual addresses. The format of the Proxy Update Confirmation frame Action field is
shown in Table 9-384.
Table 9-384—Proxy Update Confirmation frame Action field format
Order Information Notes
1 Category
2 Multihop Action
3 Mesh Control
4 PXUC element Repeated N times (N is the number of PXUC elements contained in
the frame).
The Category field is defined in 9.4.1.11.
The Multihop Action field is defined in 9.6.18.1.
The Mesh Control field is set as defined in 9.2.4.7.3.
The PXUC element is described in 9.4.2.117. The Proxy Update Confirmation frame allows the inclusion of
one or more PXUC elements.
9.6.19 Robust AV Streaming Action frame details
9.6.19.1 General
Several Action frame formats are defined to support robust AV streaming. The Robust Action field values
associated with each frame format within the robust AV streaming category are defined in Table 9-385. The
frame formats are defined in 9.6.19.2 to 9.6.19.5.
Table 9-385—Robust AV streaming Robust Action field values
Robust Action field value Meaning
0 SCS Request
1 SCS Response
2 Group Membership Request
3 Group Membership Response
4–255 Reserved
1260
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.19.2 SCS Request frame format
SCS Request frames are used to request the creation, modification, or deletion of a stream classification
using the procedures defined in 11.27.2.
The Action field of the SCS Request frame contains the information shown in Figure 9-731.
Category Robust Action Dialog Token SCS Descriptor List
Octets: 1 1 1 variable
Figure 9-731—SCS Request frame Action field format
The Category field is defined in 9.4.1.11.
The Robust Action field is defined in 9.6.19.1.
The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA to a nonzero value that is used
for matching action responses with action requests. See 10.27.5.
The SCS Descriptor List field contains one or more SCS Descriptor elements, as defined in 9.4.2.122.
9.6.19.3 SCS Response frame format
The SCS Response frame is sent in response to an SCS Request frame using the procedures defined in
11.27.2. The Action field of an SCS Response frame contains the information shown in Figure 9-732.
Category Robust Action Dialog Token SCS Status List
Octets: 1 1 1 variable
Figure 9-732—SCS Response frame Action field format
The Category field is defined in 9.4.1.11.
The Robust Action field is defined in 9.6.19.1.
The Dialog Token field is set to the nonzero value of the corresponding SCS Request frame. If the SCS
Report frame is being transmitted for a reason other than in response to an SCS Request frame, then the
Dialog Token field is set to 0.
The SCS Status List field contains one or more SCS Status duples. The format of the SCS Status duple is
defined in Figure 9-733.
SCSID Status
Octets: 1 2
Figure 9-733—SCS Status duple format
The SCSID field is set to the value of the SCSID field in the SCS Descriptor element received in the SCS
Request frame.
1261
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Status field indicates the status of the requested SCSID, as indicated in Table 9-46.
9.6.19.4 Group Membership Request frame format
The Group Membership Request frame is sent to a STA to request the contents of its
dot11GroupAddressesTable. The Action field of a Group Membership Request frame contains the
information shown in Figure 9-734.
Category Robust Action Dialog Token
Octets: 1 1 1
Figure 9-734—Group Membership Request frame Action field format
The Category field is defined in 9.4.1.11.
The Robust Action field is defined in 9.6.19.1.
The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA to a nonzero value that is used
for matching action responses with action requests. See 10.27.5.
Usage of the Group Membership Request frame is described in 11.24.16.3.2.
9.6.19.5 Group Membership Response frame format
The Group Membership Response frame is sent in response to a Group Membership Request frame or upon
a change in the dot11GroupAddressesTable object, using the procedures defined in 11.24.16.3.2. The Action
field of a Group Membership Response frame contains the information shown in Figure 9-735.
Category Robust Action Dialog Token Address Count Group Address
List
Octets: 1 1 1 1 variable
Figure 9-735—Group Membership Response frame Action field format
The Category field is defined in 9.4.1.11.
The Robust Action field is defined in 9.6.19.1.
The Dialog Token field is set to the nonzero value of the corresponding Group Membership Request frame.
If the Group Membership Report frame is being transmitted for a reason other than in response to a Group
Membership Request frame, the Dialog Token field is set to 0.
The Address Count field specifies the number of MAC addresses that are in the Group Address List field.
The Group Address List field contains zero or more MAC addresses to indicate the set of group addressed
MAC addresses for which the STA receives frames. Each MAC address is 6 octets in length, as described in
9.2.4.3.2.
1262
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.20 DMG Action frame details
9.6.20.1 DMG Action field
Several Action frame formats are defined to support DMG features. A DMG Action field, in the octet
immediately after the Category field, differentiates the DMG Action frame formats. The DMG Action field
values associated with each frame format within the DMG category are defined in Table 9-386.
Table 9-386—DMG Action field values
DMG Action field value Meaning
0 Power Save Configuration Request
1 Power Save Configuration Response
2 Information Request
3 Information Response
4 Handover Request
5 Handover Response
6 DTP Request
7 DTP Response
8 Relay Search Request
9 Relay Search Response
10 Multi-Relay Channel Measurement Request
11 Multi-Relay Channel Measurement Report
12 RLS Request
13 RLS Response
14 RLS Announcement
15 RLS Teardown
16 Relay Ack Request
17 Relay Ack Response
18 TPA Request
19 TPA Response
20 TPA Report
21 ROC Request
22 ROC Response
9.6.20.2 Power Save Configuration Request frame format
The format of the Power Save Configuration Request (PSC-REQ) frame Action field is shown in
Table 9-387.
1263
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-387—Power Save Configuration Request frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 DMG Power Management
5 DMG Wakeup Schedule element (optional)
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to a value chosen by the STA sending the frame to uniquely identify the
transaction.
The length of the DMG Power Management (DPM) field is one octet. Setting the DPM field to 0 indicates a
transition from power save mode to active mode. Setting the DPM field to 1 indicates a transition from
active mode to power save mode. All other values are reserved.
The DMG Wakeup Schedule element is defined in 9.4.2.131 (11.2.7.2).
9.6.20.3 Power Save Configuration Response frame format
The format of the Power Save Configuration Response (PSC-RSP) frame Action field is shown in
Table 9-388.
Table 9-388—Power Save Configuration Response frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Status Code
5 DMG Wakeup Schedule element (optional)
6 Antenna Sector ID Pattern element (optional)
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to the value of the Dialog Token field in the corresponding PSC-REQ frame.
The Status Code field is defined in 9.4.1.9.
1264
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DMG Wakeup Schedule element is defined in 9.4.2.131.
The Antenna Sector ID Pattern element is defined in 9.4.2.157.
9.6.20.4 Information Request frame format
The Information Request frame is an Action frame of category DMG. The format of an Information Request
frame Action field is shown in Table 9-389.
Table 9-389—Information Request frame Action field format
Order Information
1 Category
2 DMG Action
3 Subject Address
4 Request element
5 Zero or more DMG Capabilities elements
6 Zero or more provided elements
7 Zero or more Extended Request elements
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Subject Address field contains the MAC address of the STA whose information is being requested. If
this frame is sent to the PCP and the value of the Subject Address field is the broadcast address, then the
STA is requesting information regarding all associated STAs.
The Request element field is described in 9.4.2.10.
The DMG Capabilities element carries information about the transmitter STA and other STAs known to the
transmitter STA. The format of this element is defined in 9.4.2.128.
Each provided element is an element as specified in 9.4.2, that the transmitter of this frame is providing to
the destination of the frame.
The Extended Request element is described in 9.4.2.11.
9.6.20.5 Information Response frame format
The Information Response frame is an Action frame of category DMG. The format of an Information
Response frame Action field is shown in Table 9-390.
This frame is individually addressed to a STA in response to an Information Request frame or it is sent
unsolicited and individually addressed to a STA or broadcast to all STAs in the PBSS/infrastructure BSS. If
this frame is sent as a broadcast, then this frame is an Action No Ack frame.
1265
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-390—Information Response frame Action field format
Order Information
1 Category
2 DMG Action
3 Subject Address
4 One or more DMG Capabilities elements
5 Zero or more requested elements
6 Zero or more provided elements
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Subject Address field contains the MAC address of the STA whose information is being provided. If
this field is set to the broadcast address, then the STA is providing information regarding all associated
STAs.
The DMG Capabilities element carries information about the transmitter STA and other STAs known to the
transmitter STA. The DMG Capabilities element is described in 9.4.2.128.
The requested elements are those returned in response to an Information Request frame, as described in
11.30.1.
The provided elements are elements, as described in 9.4.2, that the transmitter of this frame provides to the
destination of the frame, either in addition to the requested elements, or in an unsolicited Information
Response frame.
9.6.20.6 Handover Request frame format
The Handover Request frame is an Action frame of category DMG. The format of the Handover Request
frame Action field is shown in Table 9-391.
Table 9-391—Handover Request frame Action field format
Order Information
1 Category
2 DMG Action
3 Handover Reason
4 Handover Remaining BI
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
1266
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Handover Reason field is 1 octet in length and indicates the reason that the current PCP intends to do the
PCP handover. The Handover Reason field is set to 0 to indicate the PCP is leaving the PBSS, it is set to 1 to
indicate low power in the PCP, is set to 2 to indicate that a more qualified PCP handover capable STA is
available, and is set to 3 to indicate that the PCP handover capable STA wishes to become a PCP. The other
values are reserved.
The Handover Remaining BI field is 1 octet in length and indicates the number of beacon intervals,
excluding the beacon interval in which this frame is transmitted, remaining until the handover takes effect.
9.6.20.7 Handover Response frame format
The Handover Response frame is an Action frame of category DMG. The format of the Handover Response
frame Action field is shown in Table 9-392.
Table 9-392—Handover Response frame Action field format
Order Information
1 Category
2 DMG Action
3 Handover Result
4 Handover Reject Reason
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Handover Result field is 1 octet in length and indicates whether the STA accepted the handover request.
A value of 0 indicates that the STA accepts the handover request. A value of 1 indicates that the STA does
not accept the handover request.
If the Handover Result field is set to 0, the Handover Reject Reason field is reserved and set to 0. If the
Handover Result field is set to 1, the Handover Reject Reason field indicates the reason the STA rejected the
handover request and can be one of the following: 0 for low power, 1 for handover in progress with another
STA, 2 for invalid value for Handover Remaining BI field, and 3 for unspecified reason. The length of
Handover Reject Reason field is 1 octet.
9.6.20.8 DTP Request frame format
The DTP Request frame is transmitted to request DTP information. The format of the DTP Request frame
Action field is shown in Figure 9-736.
Category DMG Action Dialog Token
Octets: 1 1 1
Figure 9-736—DTP Request frame Action field format
The Category field is defined in 9.4.1.11.
1267
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the request to identify the
transaction.
9.6.20.9 DTP Report frame format
The DTP Report frame is transmitted in response to a DTP Request frame. A DTP Report frame can also be
sent unsolicited. The format of the DTP Report frame Action field is shown in Figure 9-737.
Category DMG Action Dialog Token DTP Report
Octets: 1 1 1 34
Figure 9-737—DTP Report frame Action field format
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to the value of the Dialog Token field in the corresponding DTP Request
frame. If the DTP Report frame is not being transmitted in response to a DTP Request frame, the Dialog
Token field is set to 0.
The DTP Report element is defined in 9.4.2.146.
9.6.20.10 Relay Search Request frame format
The Relay Search Request frame is transmitted by a non-AP and non-PCP STA to the AP or PCP to
request a list of RDSs in the BSS. The format of the Relay Search Request frame Action field is shown in
Table 9-393.
Table 9-393—Relay Search Request frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Destination REDS AID
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the Relay Search Request frame
to identify the request/response transaction.
The Destination REDS AID field is set to the AID of the target destination REDS. The structure of the field
is defined in 9.4.1.8.
1268
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.20.11 Relay Search Response frame format
The Relay Search Response frame is sent by an AP or PCP in response to a Relay Search Request frame.
The format of a Relay Search Response frame Action field is shown in Table 9-394.
Table 9-394—Relay Search Response frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Status Code
5 Number of Relay Capable STAs
6 Zero or more Relay Capable STA Info fields
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to the value in the corresponding Relay Search Request frame that generated
this response.
The Status Code field is defined in 9.4.1.9.
The Number of Relay Capable STAs field is one octet in length and indicates the number of STAs in the
BSS that are relay capable. The value of this field is zero if the Status Code does not indicate success.
The Relay Capable STA Info field is defined in 9.4.1.45. This information is included only if the status code
indicates successful. The number of Relay Capable STA Info fields that appear in the frame is indicated by
the value of the Number of Relay Capable STAs field.
9.6.20.12 Multi-relay Channel Measurement Request frame format
The Multi-Relay Channel Measurement Request frame is transmitted by a STA initiating relay operation to
the recipient STA in order to obtain Channel Measurements between the recipient STA and the other STA
participating in the relay operation. The format of the Multi-Relay Channel Measurement Request frame
Action field is shown in Table 9-395.
Table 9-395—Multi-relay Channel Measurement Request frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
1269
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the Multi-Relay Channel
Measurement Request frame to identify the request/report transaction.
9.6.20.13 Multi-relay Channel Measurement Report frame format
The Multi-Relay Channel Measurement Report frame is sent in response to a Multi-Relay Channel
Measurement Request. The format of the Multi-Relay Channel Measurement Report frame Action field is
shown in Table 9-396.
Table 9-396—Multi-relay Channel Measurement Report frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Number of Channel Measurement Info
5 One or more Channel Measurement Info fields
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to the value in any corresponding Multi-Relay Channel Measurement Request
frame. If the Multi-Relay Channel Measurement Report frame is not being transmitted in response to a
Multi-Relay Channel Measurement Request frame, then the dialog token is set to 0.
The Number of Channel Measurement Info field is one octet in length and indicates the number of Channel
Measurements Info fields included in the frame.
The format of the Channel Measurement Info field is defined in Figure 9-738. The number of Channel
Measurement Info fields included in the frame is indicated by the value of the Number of Channel
Measurement Info field. Multiple Channel Measurement Info fields can be included if the reporting STA
measures the channel for multiple RDSs.
B0 B7 B8 B15 B16 B22 B23 B24 B31
Peer STA AID SNR Internal Angle Recommend Reserved
Bits: 8 8 7 1 8
Figure 9-738—Channel Measurement Info field format
The Peer STA AID subfield contains the AID of the STA toward which the reporting STA measures link.
1270
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SNR subfield indicates the SNR measured in the link toward the STA corresponding to Peer STA AID.
This subfield is encoded as 8-bit 2s complement value of 4x(SNR-19), where SNR is measured in dB. This
covers from –13 dB to 50.75 dB in 0.25 dB steps.
The Internal Angle subfield indicates the angle between directions toward the other STAs involved in the
relay operation. This covers from 0° to 180° in 2° steps. This subfield uses the degree of the direction from
the sector that the feedbacks indicates has highest quality during TXSS if SLS phase of BF is performed and
RXSS is not included.
The Recommend subfield indicates whether the responding STA recommends relay operation based on the
channel measurement with the Peer STA. This subfield is set to 1 when the relay operation is recommended
and otherwise is set to 0.
9.6.20.14 RLS Request frame format
The RLS Request frame is used to set up a relay link. The format of the RLS Request frame Action field is
shown in Table 9-397.
Table 9-397—RLS Request frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Destination AID
5 Relay AID
6 Source AID
7 Destination Capability Information
8 Relay Capability Information
9 Source Capability Information
10 Relay Transfer Parameter Set
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the RLS Request frame to
identify the request/response transaction.
The Destination AID field value is the AID of the target destination.
The Relay AID field value is the AID of the selected RDS.
The Source AID field value is the AID of the initiating STA.
1271
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Destination Capability Information field indicates the Relay Capability Information field within the
Relay Capabilities element of the target destination REDS as defined in 9.4.2.148.
The Relay Capability Information field indicates the Relay Capability Information field within the Relay
Capabilities element of the selected RDS as defined in 9.4.2.148.
The Source Capability Information field indicates the Relay Capability Information field within the Relay
Capabilities element of the originator of the request as defined in 9.4.2.148.
The Relay Transfer Parameter Set element is defined in 9.4.2.149.
9.6.20.15 RLS Response frame format
The RLS Response frame is sent in response to an RLS Request frame. The format of an RLS Response
frame Action field is shown in Table 9-398.
Table 9-398—RLS Response frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Destination Status Code
5 Relay Status Code (optional)
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to the value in any corresponding RLS Request frame.
The Destination Status Code field is included when the destination REDS transmits an RLS Response frame
as a result of RLS Request. It is defined in 9.4.1.9.
The Relay Status Code field is included when the relay REDS transmits an RLS Response frame as a result
of RLS Request. It is defined in 9.4.1.9.
9.6.20.16 RLS Announcement frame format
The RLS Announcement frame is sent to announce the successful RLS. The format of an RLS
Announcement frame Action field is shown in Table 9-399.
1272
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-399—RLS Announcement frame Action field format
Order Information
1 Category
2 DMG Action
3 Status Code
4 Destination AID
5 Relay AID
6 Source AID
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Status Code field is defined in 9.4.1.9.
The Destination AID field value is the AID of the target destination.
The Relay AID field value is the AID of the RDS.
The Source AID field value is the AID of the initiating STA.
9.6.20.17 RLS Teardown frame format
The RLS Teardown frame is sent to terminate a relay operation. The format of the RLS Teardown frame
Action field is shown in Table 9-400.
Table 9-400—RLS Teardown frame Action field format
Order Information
1 Category
2 DMG Action
3 Destination AID
4 Relay AID
5 Source AID
6 Reason Code
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Destination AID field value is the AID of the destination REDS.
1273
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Relay AID field value is the AID of the RDS.
The Source AID field value is the AID of the source REDS.
The Reason Code field is defined in 9.4.1.7.
9.6.20.18 Relay Ack Request frame format
The Relay Ack Request frame is sent by a source REDS to an RDS participating in a relay operation in order
to determine whether all frames forwarded through the RDS were received by the destination REDS also
participating in the relay operation. This frame is used only when the RDS is operated in HD-DF mode and
relay operation is link switching. The format of the Relay Ack Request frame Action field is shown in
Table 9-401.
Table 9-401—Relay Ack Request frame Action field format
Order Information
1 Category
2 DMG Action
3 BAR Control
4 BlockAck Starting Sequence Control
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The BAR Control field and BlockAck Starting Sequence Control fields are defined in 9.3.1.8.
9.6.20.19 Relay Ack Response frame format
The Relay Ack Response frame is sent by an RDS to a source REDS participating in a relay operation in
order to report which frames have been received by the destination REDS also participating in the relay
operation. This frame is used only when the RDS is operated in HD-DF mode and relay operation is link
switching. The format of the Relay Ack Response frame Action field is shown in Table 9-402.
Table 9-402—Relay Ack Response frame Action field format
Order Information
1 Category
2 DMG Action
3 BA Control
4 BlockAck Starting Sequence Control
5 BlockAck Bitmap
1274
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The BA Control field is defined in 9.3.1.9.
The BlockAck Starting Sequence Control field is defined in 9.3.1.9 and is set to the corresponding value
within the immediately previously received Relay Ack Request frame.
The BlockAck Bitmap field is defined in 9.3.1.9.
9.6.20.20 TPA Request frame format
The TPA Request frame is sent by a destination REDS participating in operation based on link cooperation
to both the RDS and source REDS that belong to the same group as the destination REDS in order for them
to send back their own TPA Response frames at the separately predefined times. Also, a source REDS sends
a TPA Request frame to the RDS that is selected by the source REDS in order for the RDS to feedback its
own TPA Response frame at the pre-defined time.
The format of the TPA Request frame Action field is shown in Table 9-403.
Table 9-403—TPA Request frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Timing Offset
5 Sampling Frequency Offset
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the TPA Request frame to
identify the request/response transaction.
The Timing Offset field is 2 octets in length and indicates the amount of time, in nanoseconds, that the STA
identified in the RA of the frame is required to change the timing offset of its transmissions so that they
arrive at the expected time at the transmitting STA.
The Sampling Frequency Offset field is 2 octets in length and indicates the amount by which to change the
sampling frequency offset of the burst transmission so that bursts arrive at the destination DMG STA with
no sampling frequency offset. The unit is 0.01 ppm.
9.6.20.21 TPA Response frame format
The TPA Response frame is sent by an RDS or a source REDS participating in relay operation in response to
a TPA Request frame from a destination REDS or a source REDS. The RDS or the source REDS that
1275
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
receives a TPA Request frame responds to the destination REDS or the source REDS, as appropriate, with a
TPA Response frame at a predetermined time from the end of the TPA Request frame (see 11.36). The
format of the TPA Response frame Action field is shown in Table 9-404.
Table 9-404—TPA Response frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to the value of the Dialog Token field of the TPA Request frame that generated
this response.
9.6.20.22 TPA Report frame format
The TPA Report frame is sent to announce whether a TPA procedure is successful. The format of the TPA
Report frame Action field is shown in Table 9-405.
Table 9-405—TPA Report frame Action field format
Order Information
1 Category
2 DMG Action
3 Status code
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Status Code field indicates the result of the current TPA procedure and is defined in 9.4.1.9.
9.6.20.23 ROC Request frame format
The ROC Request frame is sent by the source REDS participating in a relay operation in order to request a
change in the current relay operation type. The format of the ROC Request frame Action field is shown in
Table 9-406.
1276
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-406—ROC Request frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Relay Operation Type
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the ROC Request frame to
identify the request/response transaction.
The format of the Relay Operation Type field is defined in Figure 9-739.
B0 B1 B2 B7
Link Cooperation Relay-link Reserved
Bits: 1 1 6
Figure 9-739—Relay Operation Type field format
The Link Cooperation subfield is set to 0 to request the operation to be changed to link switching and is set
to 1 to request the operation to be changed to link cooperation.
The Relay-link subfield is set to 0 to indicate that the link switching operation starts at the direct link
between the source REDS and destination REDS and set to 1 to indicate that the link switching operation
starts with the RDS. If the Link Cooperation subfield is set to 1, the Relay-link subfield is reserved.
9.6.20.24 ROC Response frame format
The ROC Response frame is sent by the RDS or the destination DMG STA participating in a relay operation
in response to a ROC Request frame from the source DMG STA. The format of the ROC Response frame
Action field is shown in Table 9-407.
Table 9-407—ROC Response frame Action field format
Order Information
1 Category
2 DMG Action
3 Dialog Token
4 Status Code
1277
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Category field is defined in 9.4.1.11.
The DMG Action field is defined in 9.6.20.1.
The Dialog Token field is set to the value received in the corresponding ROC Request frame that generated
this response.
The Status Code field is defined in 9.4.1.9.
9.6.21 FST Action frame details
9.6.21.1 FST Action field
The FST Action field values are defined in Table 9-408.
Table 9-408—FST Action field values
FST Action field value Meaning
0 FST Setup Request
1 FST Setup Response
2 FST Teardown
3 FST Ack Request
4 FST Ack Response
5 On-channel Tunnel Request
9.6.21.2 FST Setup Request frame format
The FST Setup Request frame is an Action frame of category FST. The FST Setup Request frame allows an
initiating STA to announce to a peer STA whether the initiating STA intends to enable FST for the session
between the initiating STA and the peer STA (11.33). The format of the FST Setup Request frame Action
field is shown in Table 9-409.
Table 9-409—FST Setup Request frame Action field format
Order Information
1 Category
2 FST Action
3 Dialog Token
4 LLT
5 Session Transition
6 Multi-band (optional)
7 DMG Wakeup Schedule (optional)
1278
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-409—FST Setup Request frame Action field format (continued)
Order Information
8 Awake Window (optional)
9 Switching Stream (optional)
10 Zero or more additional elements are present, as
defined in 11.33.1. Each of these elements is not
present more than once in the frame.
The Category field is defined in 9.4.1.11.
The FST Action field is defined in 9.6.21.1.
The Dialog Token field is set to a nonzero value chosen by the STA.
The Link loss timeout (LLT) field is 32 bits and indicates the compressed maximum duration counted from
the last time an MPDU was received by the initiating STA from the peer STA until the initiating STA
decides to initiate FST. The use of this field is described in 11.33.
The Session Transition field contains the Session Transition element as defined in 9.4.2.145.
The Multi-band field contains the Multi-Band element as defined in 9.4.2.138. The regulatory information
contained in the Multi-band element is applicable to all of the fields and elements contained in the frame.
The DMG Wakeup Schedule element is defined in 9.4.2.131.
The Awake Window element is defined in 9.4.2.137.
The Switching Stream element is defined in 9.4.2.144.
9.6.21.3 FST Setup Response frame format
The FST Setup Response frame is an Action frame of category FST. This frame is transmitted in response to
the reception of an FST Setup Request frame. The format of the frame Action field is shown in Table 9-410.
Table 9-410—FST Setup Response frame Action field format
Order Information
1 Category
2 FST Action
3 Dialog Token
4 Status Code
5 Session Transition
6 Multi-band (optional)
7 DMG Wakeup Schedule (optional)
1279
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-410—FST Setup Response frame Action field format (continued)
Order Information
8 Awake Window (optional)
9 Switching Stream (optional)
10 Timeout Interval (optional)
11 Zero or more additional elements are present, as
defined in 11.33.1. Each of these elements is not
present more than once in the frame.
The Category field is defined in 9.4.1.11.
The FST Action field is defined in 9.6.21.1.
The Dialog Token field value is copied from the corresponding received FST Setup Request frame.
The Status Code field is defined in 9.4.1.9.
The Session Transition field contains the Session Transition element as defined in 9.4.2.145.
The Multi-band element is defined in 9.4.2.138.
The DMG Wakeup Schedule element is defined in 9.4.2.131.
The Awake Window element is defined in 9.4.2.137
The Switching Stream element is defined in 9.4.2.144.
The Timeout Interval element is defined in 9.4.2.49.
9.6.21.4 FST Teardown frame format
The FST Teardown frame is an Action frame of category FST. This frame is transmitted to delete an
established FST session between STAs. The format of the frame Action field is shown in Table 9-411.
Table 9-411—FST Teardown frame Action field format
Order Information
1 Category
2 FST Action
3 FSTS ID
The Category field is defined in 9.4.1.11.
The FST Action field is defined in 9.6.21.1.
1280
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The FSTS ID field contains the identification of the FST session established between the STAs identified by
the TA and RA fields of this frame. The format of the FSTS ID field is as specified 9.4.2.145.
9.6.21.5 FST Ack Request frame format
The FST Ack Request frame is an Action frame of category FST. This frame is transmitted in the frequency
band an FST session is transferred to and confirms the FST. The format of the frame Action field is shown in
Table 9-412.
Table 9-412—FST Ack Request frame Action field format
Order Information
1 Category
2 FST Action
3 Dialog Token
4 FSTS ID
The Category field is defined in 9.4.1.11.
The FST Action field is defined in 9.6.21.1.
The Dialog Token field is set to a nonzero value chosen by the STA sending the FST Ack request to identify
the request/report transaction.
The FSTS ID field contains the identification of the FST session established between the STAs identified by
the TA and RA fields of this frame. The format of the FSTS ID field is as specified in 9.4.2.145.
9.6.21.6 FST Ack Response frame format
The FST Ack Response frame is an Action frame of category FST. This frame is transmitted in response to
the reception of an FST Ack Request frame. The format of the frame Action field is shown in Table 9-413.
Table 9-413—FST Ack Response frame Action field format
Order Information
1 Category
2 FST Action
3 Dialog Token
4 FSTS ID
The Category field is defined in 9.4.1.11.
The FST Action field is defined in 9.6.21.1.
1281
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Dialog Token field is set to the value in any corresponding FST Ack Request frame. If the FST Ack
Response frame is not being transmitted in response to an FST Ack Request frame, then the dialog token is
set to 0.
The FSTS ID field contains the identification of the FST session established between the STAs identified in
the TA and RA fields of this frame. The format of the FSTS ID field is as specified in 9.4.2.145.
9.6.21.7 On-channel Tunnel Request frame format
The On-channel Tunnel Request frame is an Action frame of category FST. The On-channel Tunnel Request
frame allows a STA of a multi-band device to encapsulate an MMPDU for transmission to an MLME of a
peer STA within the same multi-band device (11.33), which can be used to perform multi-band association
and multi-band authentication.
The format of the On-channel Tunnel Request frame Action field is shown in Table 9-414.
Table 9-414—On-channel Tunnel Request frame Action field format
Order Information
1 Category
2 FST Action
3 OCT MMPDU
4 Multi-band
The Category field is defined in 9.4.1.11.
The FST Action field is defined in 9.6.21.1.
The OCT MMPDU field is defined in Figure 9-740.
MMPDU Length MMPDU Frame Control MMPDU Frame Body
Octets: 2 2 Variable
Figure 9-740—Definition of the OCT MMPDU field
The MMPDU Length subfield contains the length in octets of the MMPDU Frame Body subfield.
The MMPDU Frame Control subfield carries the content of the Frame Control field of an MMPDU that
would be constructed if the MMPDU for the corresponding management frame type were transmitted over
the air.
The MMPDU Frame Body subfield carries the content of the Frame Body field of an MMPDU that would
be constructed if the MMPDU for the corresponding management frame type were transmitted over the air
(i.e., all of the octets after the MAC header and up to, but not including, the FCS).
The Multi-band field contains the Multi-band element (see 9.4.2.138) of the peer MLME to which the OCT
MMPDU is destined to. The channel, frequency band and MAC address contained in this element are used
to deliver the OCT MMPDU to the correct MLME within the peer STA.
1282
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.22 Unprotected DMG Action frame details
9.6.22.1 Unprotected DMG Action field
Unprotected DMG Action frames are not encapsulated using mechanisms defined for robust Management
frames. An Action field, in the octet field immediately after the Category field, differentiates the formats.
The Action field values associated with each frame format are defined in Table 9-415.
Table 9-415—Unprotected DMG Action field values
Unprotected DMG Action
Meaning
field value
0 Announce
1 BRP
9.6.22.2 Announce frame format
The Announce frame is an Action or an Action No Ack frame of category Unprotected DMG. The format of
an Announce frame Action field is shown in Table 9-416.
Announce frames can be transmitted during the ATI of a beacon interval and can perform functions
including of a DMG Beacon frame, but since this frame does not have to be transmitted as a sector sweep to
a STA, it can provide much more spectrally efficient access than using a DMG Beacon frame.
Table 9-416—Announce frame Action field format
Order Information Notes
1 Category The Category field is defined in 9.4.1.11.
2 Unprotected DMG Action The Unprotected DMG Action field is defined in 9.6.22.1.
3 Timestamp The Timestamp field is defined in 9.4.1.10.
4 Beacon Interval The Beacon Interval field is defined in 9.4.1.3 and specifies the
duration of the beacon interval of the BSS.
5 SSID The SSID element is defined in 8.4.2.2. The SSID element is
optionally present. If present, the SSID element specifies the
SSID of the BSS.
6 Extended Schedule The Extended Schedule element is defined in 9.4.2.132. The
Extended Schedule element is optionally present. If present, the
Extended Schedule element specifies the schedule of the BSS.
7 DMG Capabilities The DMG Capabilities element is defined in 9.4.2.128. The
DMG Capabilities element is optionally present. If present, the
DMG Capabilities element specifies capabilities of the
transmitting STA.
8 RSN The RSNE is defined in 9.4.2.25. The RSNE is optionally
present. If present, the RSNE indicates that security is required in
the BSS.
1283
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-416—Announce frame Action field format (continued)
Order Information Notes
9 Multiple BSSID The Multiple BSSID element is defined in 9.4.2.46. The Multiple
BSSID element is optionally present. If present, the Multiple
BSSID element signals all the BSSIDs in use by the BSS.
10 DMG Operation The DMG Operation element is defined in 9.4.2.129. The DMG
Operation element is optionally present. If present, the DMG
Operation element specifies the operational parameters of the
BSS.
11 Next DMG ATI The Next DMG ATI element is defined in 9.4.2.135. The Next
DMG ATI element is optionally present. If present, the Next
DMG ATI element specifies the start time of the next ATI at a
subsequent beacon interval.
12 Multi-band The Multi-band element is defined in 9.4.2.138. The Multi-band
element is optionally present.
13 Awake Window The Awake Window element is defined in 9.4.2.137. The Awake
Window element is optionally present.
14 DMG BSS Parameter Change The DMG BSS Parameter Change element is defined in
9.4.2.127. The DMG BSS Parameter Change element is
optionally present.
15 BeamLink Maintenance The BeamLink Maintenance element is defined in 9.4.2.152. The
BeamLink Maintenance element is optionally present.
16 Multiple MAC Sublayers The Multiple MAC Sublayers element is defined in 9.4.2.153.
The Multiple MAC Sublayers element is optionally present.
17 ECAPC Policy The ECAPC Policy element is defined in 9.4.2.155. The ECAPC
Policy element is optionally present.
18 Cluster Report The Cluster Report element is defined in 9.4.2.147. The Cluster
Report element is optionally present.
19 Next PCP List The Next PCP List element is defined in 9.4.2.140. The Next
PCP List element is optionally present.
20 PCP Handover The PCP Handover element is defined in 9.4.2.141. The PCP
Handover element is optionally present.
21 STA Availability The STA Availability element is defined in 9.4.2.133. The STA
Availability element is optionally present.
22 UPSIM The UPSIM element is defined in 9.4.2.167. The UPSIM element
is optionally present.
9.6.22.3 BRP frame format
The BRP frame is an Action No Ack frame. The format of a BRP frame Action field is shown in
Table 9-417.
Table 9-417—BRP frame Action field format
Order Information
1 Category
2 Unprotected DMG Action
1284
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-417—BRP frame Action field format (continued)
Order Information
3 Dialog Token
4 BRP Request field
5 DMG Beam Refinement element
6 Zero or more Channel Measurement Feedback elements
The Category field is defined in 9.4.1.11.
The Unprotected DMG Action field is defined in 9.6.22.1.
The Dialog Token field is set to a value chosen by the STA sending the frame to uniquely identify the
transaction.
The BRP Request field is defined in 9.5.4.
The DMG Beam Refinement element is defined in 9.4.2.130.
The Channel Measurement Feedback element is defined in 9.4.2.136.
The BRP frame contains more than one Channel Measurement Feedback element if the measurement
information exceeds 255 octets. The content of each Channel Measurement Feedback element that follows
the first one in a single BRP frame is a continuation of the content in the previous element. The Channel
Measurement, Tap Delay, and Sector ID Order subfields can be split between several elements. Each
Channel Measurement Feedback element that is not the last Channel Measurement Feedback element in the
frame is 257 octets long. Channel measurement information for a single channel measurement is always
contained within a single BRP frame.
NOTE—The length of a BRP frame can limit the choice of channel measurement parameters such as the number of
measurements and the number of taps.
9.6.23 VHT Action frame details
9.6.23.1 VHT Action field
Several Action frame formats are defined to support VHT functionality. A VHT Action field, in the octet
immediately after the Category field, differentiates the VHT Action frame formats. The VHT Action field
values associated with each frame format within the VHT category are defined in Table 9-418.
Table 9-418—VHT Action field values
Value Meaning Time priority
0 VHT Compressed Beamforming Yes
1 Group ID Management No
2 Operating Mode Notification No
3–255 Reserved
1285
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.23.2 VHT Compressed Beamforming frame format
The VHT Compressed Beamforming frame is an Action No Ack frame of category VHT. The Action field
of a VHT Compressed Beamforming frame contains the information shown in Table 9-419.
Table 9-419—VHT Compressed Beamforming frame Action field format
Order Information
1 Category
2 VHT Action
3 VHT MIMO Control (see 9.4.1.48)
4 VHT Compressed Beamforming Report (see 9.4.1.49)
5 MU Exclusive Beamforming Report (see 9.4.1.51)
The Category field is defined in 9.4.1.11.
The VHT Action field is defined in 9.6.23.1.
The VHT MIMO Control field is always present in the frame. The presence and contents of the VHT
Compressed Beamforming Report field and the MU Exclusive Beamforming Report field are dependent on
the values of the Feedback Type, Remaining Feedback Segments, and First Feedback Segment subfields of
the VHT MIMO Control field (see 9.4.1.48, 9.4.1.49, 9.4.1.51, and 10.34.5).
No vendor-specific elements are present in a VHT Compressed Beamforming frame.
9.6.23.3 Group ID Management frame format
The Group ID Management frame is an Action frame of category VHT. It is transmitted by the AP to assign
or change the user position of a STA for one or more group IDs. The Action field of a Group ID
Management frame contains the information shown in Table 9-420.
Table 9-420—Group ID Management frame Action field format
Order Information
1 Category
2 VHT Action
3 Membership Status Array (see 9.4.1.54)
4 User Position Array (see 9.4.1.55)
The Category field is defined in 9.4.1.11.
The VHT Action field is defined in 9.6.23.1.
1286
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
9.6.23.4 Operating Mode Notification frame format
The Operating Mode Notification frame is an Action frame of category VHT. It is used to notify STAs that
the transmitting STA is changing one or more of its operating channel width, the maximum number of
spatial streams it can receive, and its LDPC receive preference.
The Action field of the Operating Mode Notification frame contains the information shown in Table 9-421.
Table 9-421—Operating Mode Notification frame Action field format
Order Information
1 Category
2 VHT Action
3 Operating Mode (see 9.4.1.53)
The Category field is defined in 9.4.1.11.
The VHT Action field is defined in 9.6.23.1.
9.7 Aggregate MPDU (A-MPDU)
9.7.1 A-MPDU format
An A-MPDU consists of a sequence of one or more A-MPDU subframes and a variable amount of EOF
padding as shown in Figure 9-741.
A-MPDU pre-EOF padding
EOF
A-MPDU subframe 1 A-MPDU subframe 2 … A-MPDU subframe n Padding
Octets: variable variable variable variable
Figure 9-741—A-MPDU format
The structure of the A-MPDU subframe is shown in Figure 9-743. Each A-MPDU subframe consists of an
MPDU delimiter optionally followed by an MPDU. Each nonfinal A-MPDU subframe in an A-MPDU has
padding octets appended to make the subframe a multiple of 4 octets in length. The content of these octets is
unspecified.
In an HT PPDU, the final A-MPDU subframe is not padded.
The EOF Padding field is shown in Figure 9-742. This is present only in a VHT PPDU.
EOF Padding
EOF Padding Octets
Subframes
Octets: 4n 0–3
Figure 9-742—EOF Padding field format
1287
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The EOF Padding Subframes subfield contains zero or more EOF padding subframes. An EOF padding
subframe is an A-MPDU subframe with 0 in the MPDU Length field and 1 in the EOF field.
In a VHT PPDU, the following padding is present, as determined by the rules in 10.13.6:
— 0–3 octets in the Padding subfield of the final A-MPDU subframe (see Figure 9-743) before any
EOF padding subframes. The content of these octets is unspecified.
— Zero or more EOF padding subframes in the EOF Padding Subframes subfield.
— 0–3 octets in the EOF Padding Octets subfield. The content of these octets is unspecified.
An A-MPDU pre-EOF padding refers to the contents of the A-MPDU up to, but not including, the EOF
Padding field.
NOTE—A-MPDU pre-EOF padding includes any A-MPDU subframes with 0 in the MPDU Length field and 0 in the
EOF field inserted in order to meet the minimum MPDU start spacing requirement.
The maximum length of an A-MPDU in an HT PPDU is 65 535 octets. The maximum length of an A-
MPDU in a DMG PPDU is 262 143 octets. The maximum length of an A-MPDU pre-EOF padding in a
VHT PPDU is 1 048 575 octets. The length of an A-MPDU addressed to a particular STA can be further
constrained as described in 10.13.2.
MPDU delimiter MPDU Padding
Octets: 4 variable 0–3
Figure 9-743—A-MPDU subframe format
The MPDU delimiter is 4 octets in length. The structure of the MPDU delimiter when transmitted by a non-
DMG STA is defined in Figure 9-744. The structure of the MPDU Delimiter field when transmitted by a
DMG STA is shown in Figure 9-745.
B0 B1 B2 B15 B16 B23 B24 B31
EOF Reserved MPDU Length CRC Delimiter Signature
Bits: 1 1 14 8 8
Figure 9-744—MPDU delimiter (non-DMG)
B0 B2 B3 B15 B16 B23 B24 B31
Reserved MPDU Length CRC Delimiter Signature
Bits: 3 13 8 8
Figure 9-745—MPDU delimiter (DMG)
The fields of the MPDU delimiter when transmitted by a non-DMG STA are defined in Table 9-422. The
fields of the MPDU delimiter when transmitted by a DMG STA are defined in Table 9-423.
1288
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-422— MPDU delimiter fields (non-DMG)
Size
Field Description
(bits)
EOF 1 End of frame indication. Set to 1 in an A-MPDU subframe that has 0 in the
MPDU Length field and that is used to pad the A-MPDU in a VHT PPDU as
described in 10.13.6. Set to 1 in the MPDU delimiter of a VHT single MPDU as
described in 10.13.7. Set to 0 otherwise.
Reserved 1
MPDU Length 14 Length of the MPDU in octets. Set to 0 if no MPDU is present. An A-MPDU
subframe with 0 in the MPDU Length field is used as defined in 10.13.3 to meet
the minimum MPDU start spacing requirement and also to pad the A-MPDU to
fill the available octets in a VHT PPDU as defined in 10.13.6.
CRC 8 8-bit CRC of the preceding 16 bits.
Delimiter Signature 8 Pattern that can be used to detect an MPDU delimiter when scanning for an
MPDU delimiter.
The unique pattern is 0x4E (see NOTE below).
NOTE—The ASCII value of the character ‘N’ was chosen as the unique pattern for the value in the Delimiter
Signature field.
Table 9-423—MPDU delimiter fields (DMG)
MPDU Delimiter Size
Description
field (bits)
Reserved 3
MPDU Length 13 Length of MPDU in octets
CRC 8 8-bit CRC on preceding 16 bits
Delimiter Signature 8 Pattern that can be used to detect an MPDU delimiter when scanning for a
delimiter. The unique pattern is 0x4E.
The format of the MPDU Length field when transmitted by a non-DMG STA is shown in Figure 9-746. The
MPDU Length Low subfield contains the 12 low order bits of the MPDU length. In a VHT PPDU,
the MPDU Length High subfield contains the two high order bits of the MPDU length. In an HT PPDU, the
MPDU Length High subfield is reserved.
B0 B1 B2 B13
MPDU Length High MPDU Length Low
Bits: 2 12
Figure 9-746—MPDU Length field (non-DMG)
The MPDU length value is derived from the MPDU Length field subfields as follows:
1289
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
L low + L high 4096 VHT PPDU
L MPDU = L low HT PPDU (9-5)
L DMG PPDU
where
Llow is the value of the MPDU Length Low subfield
Lhigh is the value of the MPDU Length High subfield
L is the value of the MPDU Length field
NOTE—The format of the MPDU Length field maintains a common encoding structure for both VHT and HT PPDUs.
For HT PPDUs, only the MPDU Length Low subfield is used, while for VHT PPDUs, both subfields are used.
The purpose of the MPDU delimiter is to locate the MPDUs within the A-MPDU so that the structure of the
A-MPDU can usually be recovered when one or more MPDU delimiters are received with errors. See O.2
for a description of a deaggregation algorithm.
9.7.2 MPDU delimiter CRC field
The MPDU delimiter CRC field is an 8-bit CRC value. It is used as a frame check sequence (FCS) to protect
the Reserved and MPDU Length fields. The CRC field is the 1s complement of the remainder generated by
8 2 1
the modulo 2 division of the protected bits by the polynomial x x x 1 , where the shift-register state
is preset to all 1s.
NOTE—The order of transmission of bits within the CRC field is defined in 9.2.2.
Figure 9-747 illustrates the CRC calculation for the MPDU delimiter.
(MPDU delimiter)
B15…..B0
The feedback term is set to 0
during the shifting out of the result.
0
Serial c c c c c c c c
Input 7 6 5 4 3 2 1 0
C7=B16
Serial B16...B23
Output (MPDU delimiter)
Figure 9-747—MPDU delimiter CRC calculation
9.7.3 A-MPDU contents
In a non-DMG PPDU, an A-MPDU is a sequence of A-MPDU subframes carried in a single PPDU with one
of the following combinations of RXVECTOR or TXVECTOR parameter values:
— The FORMAT parameter set to VHT
— The FORMAT parameter set to HT_MF or HT_GF and the AGGREGATION parameter set to 1
In a DMG PPDU, an A-MPDU is a sequence of MPDUs carried in a single PPDU with the TXVECTOR/
RXVECTOR AGGREGATION parameter set to 1.
1290
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
All of the MPDUs within an A-MPDU are addressed to the same RA. All QoS Data frames within an
A-MPDU that have a TID for which an HT-immediate block ack agreement exists have the same value for
the Ack Policy subfield of the QoS Control field.
All protected MPDUs within an A-MPDU have the same Key ID.
The Duration/ID fields in the MAC headers of all MPDUs in an A-MPDU carry the same value. The
Duration/ID fields in the MAC headers of MPDUs in A-MPDUs carried in the same VHT MU PPDU all
carry the same value.
NOTE—The reference point for the Duration/ID field is the end of the PPDU carrying the MPDU. Setting the Duration/
ID field to the same value in the case of A-MPDU aggregation means that each MPDU consistently specifies the same
NAV setting.
An A-MPDU is transmitted in one of the contexts specified in Table 9-424 as defined by the description in
the “Definition of context” column, independently of whether the A-MPDU is contained in a VHT MU
PPDU or an SU PPDU. Ordering of MPDUs within an A-MPDU is not constrained, except where noted in
these tables. See 10.13.1.
Table 9-424—A-MPDU contexts
Table defining
Name of Context Definition of Context
permitted contents
Data Enabled The A-MPDU is transmitted outside a PSMP sequence by a Table 9-425
Immediate TXOP holder or an RD responder including potential
Response immediate responses.
Data Enabled No The A-MPDU is transmitted outside a PSMP sequence by a Table 9-426
Immediate TXOP holder that does not include or solicit an immediate
Response response.
See NOTE.
PSMP The A-MPDU is transmitted within a PSMP sequence. Table 9-427
Control Response The A-MPDU is transmitted by a STA that is neither a TXOP Table 9-428
holder nor an RD responder that also needs to transmit one of
the following immediate response frames:
Ack
BlockAck frame with a TID for which an HT-immediate block
ack agreement exists
VHT single MPDU The A-MPDU is transmitted within a VHT PPDU and Table 9-429
context contains a VHT single MPDU.
NOTE—This context includes cases when no response is generated or when a response is generated later by the
operation of the delayed block ack rules.
A VHT MU PPDU does not carry more than one A-MPDU that contains one or more MPDUs soliciting an
immediate response.
NOTE 1—The TIDs present in a data enabled A-MPDU context are also constrained by the channel access rules (for a
TXOP holder; see 10.22.2 and 10.22.3) and the RD response rules (for an RD responder, see 10.28.4). This is not shown
in these tables.
NOTE 2—If a STA supports A-MSDUs of 7935 octets (indicated by the Maximum A-MSDU Length field in the HT
Capabilities element), A-MSDUs transmitted by that TA within an A-MPDU carried in a PPDU with FORMAT HT_MF
or HT_GF or within an MPDU carried in a non-HT PPDU are constrained so that the length of the QoS Data frame
carrying the A-MSDU is no more than 4095 octets. The 4095-octet MPDU length limit does not apply to A-MPDUs
carried in VHT or DMG PPDUs. The use of A-MSDU within A-MPDU might be further constrained as described in
9.4.1.14 through the operation of the A-MSDU Supported field.
1291
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-425—A-MPDU contents in the data enabled
immediate response context
MPDU Description Conditions
Ack If the preceding PPDU contains an MPDU that requires
an Ack frame response, a single Ack frame at the start
of the A-MPDU. In a non-DMG STA: at
most one of these
HT-immediate BlockAck In a non-DMG STA: if the preceding PPDU contains an MPDUs is present.
implicit or explicit block ack request for a TID for
which an HT-immediate block ack agreement exists, at In a DMG STA: at most
most one BlockAck frame for this TID, in which case it one Ack frame is
occurs at the start of the A-MPDU. present, and zero or
more HT-immediate
In a DMG STA: if the preceding PPDU contains an BlockAck frames are
implicit or explicit block ack request for a TID for present.
which an HT-immediate block ack agreement exists,
one or more copies of the same BlockAck for this TID.
Delayed BlockAcks BlockAck frames with the BA Ack Policy subfield equal to No Acknowledgment
with a TID for which an HT-delayed block ack agreement exists.
Delayed block ack data QoS Data frames with a TID that corresponds to a Delayed or HT-delayed block
ack agreement.
These have the Ack Policy field equal to Block Ack.
Action No Ack Action No Ack frames.
Delayed BlockAckReqs BlockAckReq frames with a TID that corresponds to an HT-delayed block ack
agreement in which the BA Ack Policy subfield is equal to No Acknowledgment.
Data frames sent under an HT- QoS Data frames with the same TID, Of these, at most one of the following
immediate block ack which corresponds to an HT-immediate is present in a non-DMG BSS:
agreement block ack agreement. — One or more QoS Data frames
See NOTE. with the Ack Policy field equal to
QoS Null MPDUs with Ack In a DMG BSS, QoS Null MPDUs with Implicit Block Ack Request
Policy set to No Ack Ack Policy set to No Ack. — A BlockAckReq frame
Immediate BlockAckReq At most one BlockAckReq frame with a
Of these, at most one of the following
TID that corresponds to an HT-
is present in a DMG BSS:
immediate block ack agreement.
This is the last MPDU in the A-MPDU. — One or more QoS Data frames
with the Ack Policy field equal to
It is not present if any QoS Data frames Implicit Block Ack Request
for that TID are present. — QoS Null MPDU with Ack Policy
set to No Ack
— A BlockAckReq frame with an
optional QoS Null MPDU with
Ack Policy set to No Ack
NOTE—These MPDUs all have the Ack Policy field equal to the same value, which is either Implicit Block Ack
Request or Block Ack.
1292
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-426—A-MPDU contents in the data enabled no immediate response context
MPDU Description Conditions
Delayed BlockAcks BlockAck frames for a TID for which an HT-delayed block ack agreement exists
with the BA Ack Policy subfield equal to No Acknowledgment.
Delayed Block Ack data QoS Data frames with a TID that corresponds to a Delayed or HT-delayed block
ack agreement.
These have the Ack Policy field equal to Block Ack.
Data without a block ack QoS Data frames with a TID that does not correspond to a block ack agreement.
agreement These have the Ack Policy field equal to No Ack and the A-MSDU Present subfield
equal to 0.
Action No Ack Action No Ack frames.
Delayed BlockAckReqs BlockAckReq frames with the BA Ack Policy subfield equal to No
Acknowledgment and with a TID that corresponds to an HT-delayed block ack
agreement.
Table 9-427—A-MPDU contents in the PSMP context
MPDU Description Conditions
Acknowledgment for PSMP data At most one Multi-TID BlockAck frame.
Acknowledgment in response to data received with the Ack Policy field
equal to PSMP Ack and/or a Multi-TID BlockAckReq frame in the
previous PSMP-UTT or PSMP-DTT.
Delayed BlockAcks BlockAck frames with the BA Ack Policy subfield equal to No
Acknowledgment and with a TID for which an HT-delayed block ack
agreement exists.
HT-immediate Data QoS Data frames in which the Ack Policy
field is equal to PSMP Ack or Block Ack
and with a TID that corresponds to an
HT-immediate block ack agreement.
Delayed Block Ack data QoS Data frames with a TID that
An A-MPDU containing
corresponds to a Delayed or HT-delayed
MPDUs with a block ack
block ack agreement.
agreement does not also
These have the Ack Policy field equal to
contain MPDUs without a
Block Ack.
block ack agreement.
Data without a block ack agreement QoS Data frames with a TID that does
not correspond to a block ack agreement.
These have the Ack Policy field equal to
No Ack and the A-MSDU Present
subfield is equal to 0.
Action No Ack Action No Ack frames.
Delayed BlockAckReqs BlockAckReq frames with the BA Ack Policy subfield equal to No
Acknowledgment and with a TID that corresponds to an HT-delayed Block
Ack.
Multi-TID BlockAckReq At most one Multi-TID BlockAckReq frame with the BA Ack Policy
subfield equal to No Acknowledgment.
1293
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 9-428—A-MPDU contents MPDUs in the control response context
MPDU Conditions
Ack Ack frame transmitted in response to an
MPDU that requires an Ack frame. One of these is present at the start of
BlockAck BlockAck frame with a TID that corresponds the A-MPDU.
to an HT-immediate block ack agreement.
Action No +HTC Action No Ack frames carrying a Management Action Body containing an
Ack explicit feedback response or BRP frame.
Table 9-429—A-MPDU contents in the VHT single MPDU context
MPDU Conditions
Any MPDU A VHT single MPDU.
1294
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10. MAC sublayer functional description
10.1 Introduction
The MAC functional description is presented in this clause. The architecture of the MAC sublayer, including
the distributed coordination function (DCF), the point coordination function (PCF), the hybrid coordination
function (HCF), the mesh coordination function (MCF), and their coexistence in an IEEE 802.11 LAN are
introduced in 10.2. These functions are expanded on in 10.3, 10.4, 10.22, and 10.23. Fragmentation and
defragmentation are defined in 10.5 and 10.6. Multirate support is addressed in 10.7. A number of additional
restrictions to limit the cases in which MSDUs are reordered or discarded are described in 10.8. Operation
across regulatory domains is defined in 10.21. The block ack mechanism is described in 10.24. The No Ack
mechanism is described in 10.25. The protection mechanism is described in 10.26. Rules for processing
MAC frames are described in 10.27.
The PCF mechanism is obsolete. Consequently, the PCF mechanism might be removed in a later revision of
the standard.
10.2 MAC architecture
10.2.1 General
The MAC architecture is shown in Figure 10-1 and Figure 10-2.
Required for Required for Prioritized
Parameterized QoS Services
QoS Services
Required for Contention- Required for
Free Services for non-QoS Controlled Mesh
Mesh Coordination Function (MCF)
STA, optional otherwise Services
Hybrid Coordination Function (HCF)
Used for Contention
Services, basis for
PCF, HCF and MCF
Point HCF
HCF MCF
Coordina- Conten-
Controlled Controlled
tion tion
MAC Access Access
Function Access
extent (HCCA) (MCCA)
(PCF) (EDCA)
Distributed Coordination Function (DCF)
DSSS, OFDM, HR/DSSS, ERP, HT, VHT or TVHT
PHY
Figure 10-1—Non-DMG STA MAC architecture
1295
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Used for Used for Dynamic
Contention Allocation Services
Services
Used for non-
Used for
data services
Scheduled
Services
Used for beamforming
with an AP or PCP Dynamic Allocation
CBAP
Access
(HCF
A-BFT ATI SP
Contention
Access Access Access)
Access
DCF
DMG Channel Access
DMG PHY
Figure 10-2—DMG STA MAC architecture
In a non-DMG STA:
— The MAC provides the PCF, HCF and MCF service using the services of the DCF.
— The PCF is optionally present in nonmesh STAs and absent otherwise.
— The HCF is present in QoS STAs and absent otherwise.
— The MCF is present in mesh STAs and absent otherwise.
In a DMG STA:
— The MAC provides services using the DMG channel access mechanisms.
— Specific rules apply for access during scheduled periods, which include the association
beamforming training (A-BFT) period, announcement transmission interval (ATI), contention based
access period (CBAP), and service period (SP).
— The DCF is used during contention based access periods.
— Dynamic allocation (10.36.7) is built on service period and contention based access period.
10.2.2 DCF
The fundamental access method of the MAC used by non-DMG STAs is a DCF known as carrier sense
multiple access with collision avoidance (CSMA/CA). The DCF shall be implemented in all STAs.
For a STA to transmit, it shall sense the medium to determine if another STA is transmitting. If the medium is
not determined to be busy (see 10.3.2.1), the transmission may proceed. The CSMA/CA distributed algorithm
mandates that a gap of a minimum specified duration exists between frame exchange sequences. A transmitting
STA shall verify that the medium is idle for this required duration before attempting to transmit. If the medium
is determined to be busy, a non-DMG STA shall defer until the end of the current transmission, and a DMG
STA may defer until the end of the current transmission. After deferral, or prior to attempting to transmit again
immediately after a successful transmission, the STA shall select a random backoff interval and shall
decrement the backoff interval counter while the medium is idle. A refinement of the method may be used
under various circumstances to further minimize collisions—here the transmitting and receiving STA
exchange short Control frames (RTS and CTS frames for non-DMG STAs, and RTS and DMG CTS frames
for DMG STAs) after determining that the medium is idle and after any deferrals or backoffs, prior to data
transmission. The details of CSMA/CA, deferrals, and backoffs are described in 10.3. RTS/CTS and RTS/
DMG CTS exchanges are also presented in 10.3.
1296
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.2.3 PCF
The PCF mechanism is obsolete. Consequently, this subclause might be removed in a later revision of the
standard.
The IEEE 802.11 MAC may also incorporate an optional access method called a PCF, which is usable only in
infrastructure network configurations. This access method uses a PC, which shall operate at the AP of the BSS,
to determine which STA currently has the right to transmit. The operation is essentially that of polling, with the
PC performing the role of the polling master. The operation of the PCF might require additional coordination,
not specified in this standard, to permit efficient operation when multiple point-coordinated BSSs are operating
on the same channel, in overlapping physical space.
The PCF uses a virtual carrier sense (CS) mechanism aided by an access priority mechanism. The PCF shall
distribute information within Beacon frames to gain control of the medium by setting the NAV in STAs. In
addition, all frame transmissions under the PCF may use an interframe space (IFS) that is smaller than the IFS
for frames transmitted via the DCF. The use of a smaller IFS implies that point-coordinated traffic has priority
access to the medium over STAs in overlapping BSSs operating under the DCF access method.
The access priority provided by a PCF may be utilized to create a CF access method. The PC controls the frame
transmissions of the STAs so as to eliminate contention for a limited period of time.
10.2.4 Hybrid coordination function (HCF)
10.2.4.1 General
The QoS facility includes an additional coordination function called HCF that is usable only in QoS network
configurations. The HCF shall be implemented in all QoS STAs except mesh STAs. Instead, mesh STAs
implement the MCF. The HCF combines functions from the DCF and PCF with some enhanced, QoS-specific
mechanisms and frame subtypes to allow a uniform set of frame exchange sequences to be used for QoS data
transfers during both the CP and CFP. The HCF uses both a contention based channel access method, called
the enhanced distributed channel access (EDCA) mechanism for contention based transfer and a controlled
channel access, referred to as the HCF controlled channel access (HCCA) mechanism, for contention free
transfer.
A STA may obtain a TXOP using one or both of the channel access mechanisms specified in 10.22. If a TXOP
is obtained using the contention based channel access, it is defined as EDCA TXOP. If a TXOP is obtained
using the controlled channel access, it is defined as HCCA TXOP. If an HCCA TXOP is obtained due to a QoS
(+)CF-Poll frame from the HC, the TXOP is defined as a polled TXOP.
Time priority Management frames are transmitted outside of the normal MAC queuing process as per
individually described transmission rules. Frames listed in Table 9-333 and Table 9-418 with a value of “Yes”
in the “Time priority” column are time priority Management frames. No other frames are time priority
Management frames.
10.2.4.2 HCF contention based channel access (EDCA)
The EDCA mechanism provides differentiated, distributed access to the WM for STAs using eight different
UPs. The EDCA mechanism defines four access categories (ACs) that provide support for the delivery of
traffic with UPs at the STAs. Six transmit queues are defined when dot11AlternateEDCAActivated is true, and
four transmit queues otherwise. The transmit queue and AC are derived from the UPs as shown in Table 10-1.
NOTE—A DMG STA that implements a single AC (see 10.22.2.1) has all of its UP values in Table 10-1 mapped to
AC_BE.
1297
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-1—UP-to-AC mappings
UP Transmit queue
IEEE Transmit queue
(Same as IEEE (dot11Alternate- Designation
(dot11Alternate
Priority 802.1D AC EDCAActivated EDCAActivated
802.1D user false or (informative)
designation true)
priority) not present)
Lowest 1 BK AC_BK BK BK Background
2 — AC_BK BK BK Background
0 BE AC_BE BE BE Best Effort
3 EE AC_BE BE BE Best Effort
4 CL AC_VI VI A_VI Video (alternate)
5 VI AC_VI VI VI Video (primary)
6 VO AC_VO VO VO Voice (primary)
Highest 7 NC AC_VO VO A_VO Voice (alternate)
For each AC an enhanced variant of the DCF, called an enhanced distributed channel access function
(EDCAF), contends for TXOPs using a set of EDCA parameters. When communicating Data frames outside
the context of a BSS (dot11OCBActivated is true), the EDCA parameters are the corresponding default values
or are as set by the SME in dot11EDCATable (except for TXOP limits, which shall be set to 0 for each AC).
When communicating within a BSS, the EDCA parameters used are from the EDCA Parameter Set element or
from the default values for the parameters when no EDCA Parameter Set element is received from the AP of
the BSS with which the STA is associated or when the STA is a mesh STA. The parameters used by the
EDCAF to control its operation are defined by dot11QAPEDCATable at the AP and by dot11EDCATable at
the non-AP STA.
The following rules apply for HCF contention based channel access:
a) The minimum specified idle duration time is not the constant value (DIFS) defined for DCF, but is a
distinct value. This value is specified in table dot11QAPEDCATableAIFSN for an AP and in table
dot11EDCATableAIFSN for a non-AP STA; see 10.22.2. The minimum idle duration time is
assigned either by a management entity or by an AP.
b) The contention window limits aCWmin and aCWmax, from which the random backoff is computed,
are not fixed per PHY, as with DCF, but are variable (contained in tables
dot11QAPEDCATableCWmin and dot11QAPEDCATableCWmax for an AP and in tables
dot11EDCATableCWmin and dot11EDCATableCWmax for a non-AP STA) and assigned by a
management entity or by an AP.
c) Collisions between contending EDCAFs in a STA are resolved within the STA, so that the Data
frames from the higher priority AC receive the TXOP and the Data frames from the lower priority
colliding AC(s) behave as if there were an external collision on the WM except that the Retry
subfield in the MAC headers of MPDUs at the head of the lower priority ACs is not affected.
d) During an EDCA TXOP won by an EDCAF a STA may initiate multiple frame exchange sequences
to transmit MMPDUs and/or MSDUs within the same AC. The duration of this EDCA TXOP is
bounded, for an AC, by the value dot11QAPEDCATableTXOPLimit for an AP and by
dot11EDCATableTXOPLimit for a non-AP STA. A value of 0 for this duration means that the
EDCA TXOP is limited as defined by the rule for TXOP limit of 0 found in 10.22.2.8.
The QoS AP shall announce the EDCA parameters in selected Beacon frames and in all Probe Response and
(Re)Association Response frames by the inclusion of the EDCA Parameter Set element using the information
1298
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
from the MIB entries in dot11ECDATable. If no such element is received, a STA shall use the default values
for the parameters. The fields following the QoS Info field in the EDCA Parameter Set element shall be
included in all Beacon frames occurring within two (optionally more) delivery traffic indication map (DTIM)
periods following a change in AC parameters, which provides all STAs an opportunity to receive the updated
EDCA parameters. If any associated STAs are in WNM sleep mode or using FMS, these fields should be
included by the AP for as many DTIM periods as needed to exceed the longest interval any STA is expected to
not receive Beacon frames. A QoS STA shall update its MIB attributes that correspond to fields in an EDCA
Parameter Set element within an interval of time equal to one beacon interval after receiving an updated EDCA
parameter set. QoS STAs update the MIB attributes and store the EDCA Parameter Set update count value in
the QoS Info field. An AP may change the EDCA access parameters by changing the EDCA Parameter Set
element in the Beacon frame, Probe Response frame, and (Re)Association Response frame. However, the AP
should change them only rarely. A QoS STA shall use the EDCA Parameter Set Update Count Value subfield
in the QoS Capability element of all Beacon frames to determine whether the STA is using the current EDCA
Parameter Values. If the EDCA Parameter Set update count value in the QoS Capability element is different
from the value that has been stored, the QoS STA shall query the updated EDCA parameter values by sending
a Probe Request frame to the AP.
In the Beacon frame the EDCA Parameter Set Update Count subfield is initially set by the AP to 0 and is
incremented every time any of the AC parameters changes.
An AP or PCP may use a different set of EDCA parameter values than it advertises to the STAs in its BSS.
A QoS STA that transmits a Management frame determines access category used for medium access in
transmission of the Management frame as follows:
— If dot11QMFActivated is false or not present
— If the Management frame is individually addressed to a non-QoS STA, category AC_BE
should be selected
NOTE—Category AC_BE might not be selected when no prior Data frames have been transmitted to
the non-QoS STA
— If category AC_BE was not selected by the previous step, category AC_VO shall be selected
NOTE—Selection of AC_VO above is independent of whether the STA is associated with a BSS, or
whether there is a QoS facility in the BSS.
— If dot11QMFActivated is true the STA determines the access category as described in 11.26.
BlockAckReq and BlockAck frames shall be sent using the same access category for medium access as the
corresponding QoS Data frames.
PS-Poll frames shall be sent using the access category AC_BE for medium access (to reduce the likelihood of
collision following a Beacon frame).
When the first frame in a frame exchange sequence intended to carry a QoS Data, QoS Null or Management
frame is an RTS or CTS frame, the RTS or CTS frame shall be transmitted using the access category of the
corresponding QoS Data or QoS Null frame or the access category used for medium access of the Management
frame.
Control Wrapper frames shall be sent using the access category that would apply to the carried Control frame.
A beamformer may send a VHT NDP Announcement frame or Beamforming Report Poll frame using any
access category and without being restricted by admission control procedures.
PS-Poll frames and Management frames are exempted from any and all restrictions on transmissions arising
from admission control procedures.
1299
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The operation rules of HCF contention based channel access are defined in 10.22.2.
The alternate video (A_VI) and alternate voice (A_VO) transmit queues share the same EDCAF as VI and
VO transmit queues, respectively, as shown in Figure 10-25. When dot11AlternateEDCAActivated is true, a
scheduling function above the VO EDCAF selects from the primary or alternate transmit queue an MSDU,
an A-MSDU, an MMPDU, or set of MSDUs to be the next to be passed to the VO EDCAF (as shown in
Figure 10-25) so that the MSDU(s), A-MSDU(s), or MMPDU(s) from the queue with the higher UP are
selected with a higher probability than from the queue with the lower UP. When
dot11AlternateEDCAActivated is true, a scheduling function above the VI EDCAF selects from the primary
or alternate transmit queue an MSDU, an A-MSDU, an MMPDU, or set of MSDUs to be the next to be
passed to the VI EDCAF so that the MSDU(s), A-MSDU(s), or MMPDU(s) from the queue with the higher
UP are selected with a higher probability than from the queue with the lower UP. The default algorithm to
select an MSDU, A-MSDU, or MMPDU from either the A_VI or VI queue and to select an MSDU,
A-MSDU, or MMPDU from either the A_VO or VO queue is as follows:
a) For each EDCAF, an MSDU, A-MSDU, or MMPDU is selected for transmission using the
transmission selection procedures defined in 8.6.8 of IEEE Std 802.1Q-2011 using two queues, the
primary and alternate.
b) For a given AC, the order in which frames are selected for transmission shall maintain the
requirements specified in 10.8 of this standard.
Alternative prioritization algorithms that meet the requirements of 10.8 may be used.
All MSDUs, A-MSDUs, and MMPDUs passed to the VO EDCAF are transmitted according to AC_VO
EDCAF parameters and rules. All MSDUs, A-MSDUs, and MMPDUs passed to the VI EDCAF are
transmitted according to AC_VI EDCAF parameters and rules.
10.2.4.3 HCF controlled channel access (HCCA)
The HCCA mechanism uses a QoS-aware centralized coordinator, called a hybrid coordinator (HC), and
operates under rules that are different from the PC of the PCF. The HC is collocated with the AP of the BSS
and uses the HC’s higher priority of access to the WM to initiate frame exchange sequences and to allocate
TXOPs to itself and other STAs in order to provide limited-duration CAPs for contention free transfer of QoS
data.
The HC traffic delivery and TXOP allocation may be scheduled during the CP and any locally generated CFP
(generated optionally by the HC) to meet the QoS requirements of a particular TC or TS. TXOP allocations and
contention free transfers of QoS traffic might be based on the HC’s BSS-wide knowledge of the amounts of
pending traffic belonging to different TS and/or TCs and are subject to BSS-specific QoS policies.
An AP may transmit a CF-Poll to a non-QoS STA, thereby providing non-QoS contention free transfers during
the CFP. This provisioning of contention free transfers during the CFP to non-QoS STAs, however, is not
recommended. Implementers are cautioned that QoS STAs are not required to interpret data subtypes that
include QoS +CF-Ack in frames not addressed to themselves unless they set the Q-Ack subfield in the QoS
Capability element to 1. QoS STAs are also not required to interpret data subtypes that are non-QoS (+)CF-
Poll frames (i.e., Data frames with bits 7, 5, and 4 in the Frame Control field equal to 0, 1, and 0, respectively);
therefore, QoS STAs cannot be treated as CF-Pollable STAs. This requires an AP that provides non-QoS CF-
polling to adhere to frame exchange sequence restrictions considerably more complex than, and less efficient
than, those specified for either PCF or HCF. In addition, the achievable service quality is likely to be degraded
when non-QoS STAs are associated and being polled.
The HCF protects the transmissions during each CAP using the virtual CS mechanism.
1300
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA may initiate multiple frame exchange sequences during a polled TXOP of sufficient duration to
perform more than one such sequence. The use of virtual CS by the HC provides improved protection of the
CFP, in addition to the protection provided by having all STAs in the BSA setting their NAVs to
dot11CFPMaxDuration at the target beacon transmission time (TBTT) of DTIM Beacon frames.
The operation rules of the HCCA are defined in 10.22.3.
10.2.5 Mesh coordination function (MCF)
The mesh facility includes an additional coordination function called MCF that is usable only in an MBSS.
A mesh STA shall implement the MCF only. MCF has both a contention based channel access and
contention free channel access mechanism. The contention based mechanism is EDCA and the contention
free mechanism is called the MCF controlled channel access (MCCA). MCF uses the default values for the
PTKSA, GTKSA and STKSA Replay Counters. The operation rules of the EDCA are defined in 10.22.2.
The operation rules of the MCCA are defined in 10.23.3.
10.2.6 Combined use of DCF, PCF, and HCF
The DCF and a centralized coordination function (either PCF or HCF) are defined so they may operate within
the same BSS. When a PC is operating in a BSS, the PCF and DCF access methods alternate, with a CFP
followed by a CP. This is described in greater detail in 10.4. When an HC is operating in a BSS, it may
generate an alternation of CFP and CP in the same way as a PC, using the DCF access method only during the
CP. The HCF access methods (controlled and contention based) operate sequentially when the channel is in
CP. Sequential operation allows the polled and contention based access methods to alternate, within intervals
as short as the time to transmit a frame exchange sequence, under rules defined in 10.22.
10.2.7 Fragmentation/defragmentation overview
The process of partitioning an MSDU or an MMPDU into smaller MAC level frames, MPDUs, is called
fragmentation. Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length to increase
reliability, by increasing the probability of successful transmission (as defined in 10.2.2) of the MSDU or
MMPDU when channel characteristics limit reception reliability for longer frames. A STA may use
fragmentation to use the medium efficiently in consideration of the duration available in granted TXOPs, as
long as the rules in 10.5 are followed. Fragmentation is accomplished at each immediate transmitter. The
process of recombining MPDUs into a single MSDU or MMPDU is defined as defragmentation.
Defragmentation is accomplished at each immediate recipient.
An MSDU transmitted under HT-immediate or HT-delayed block ack agreement shall not be fragmented even
if its length exceeds dot11FragmentationThreshold. An MSDU or MMPDU transmitted within an A-MPDU
that does not contain a VHT single MPDU (see 10.13.8) shall not be fragmented even if its length exceeds
dot11FragmentationThreshold. MSDUs or MMPDUs carried in a group addressed MPDU shall not be
fragmented even if their length exceeds dot11FragmentationThreshold.
NOTE 1—A fragmented MSDU or MMPDU transmitted by an HT STA to another HT STA can be acknowledged only
using immediate acknowledgment (i.e., transmission of an Ack frame after a SIFS).
NOTE 2—As specified in 10.12, A-MSDUs are never fragmented.
Except as described below, when an individually addressed MSDU is received from the LLC or an individually
addressed MMPDU is received from the MLME that would result in an MPDU of length greater than
dot11FragmentationThreshold, the MSDU or MMPDU shall be fragmented. An exception applies when an
MSDU is transmitted using an HT-immediate or HT-delayed block ack agreement or when the MSDU or
MMPDU is carried in an A-MPDU that does not contain a VHT single MPDU, in which case the MSDU or
MMPDU is transmitted without fragmentation. Each fragment is a frame no longer than
dot11FragmentationThreshold, if security encapsulation is not invoked for the MPDU. If security
1301
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
encapsulation is active for the MPDU, then the fragments shall be expanded by the encapsulation overhead and
this may result in a fragment larger than dot11FragmentationThreshold. It is possible that any fragment may be
a frame smaller than dot11FragmentationThreshold. An illustration of fragmentation is shown in Figure 10-3.
Figure 10-3—Fragmentation
The MPDUs resulting from the fragmentation of an MSDU or MMPDU are sent as independent transmissions,
each of which is separately acknowledged. This permits transmission retries to occur per fragment, rather than
per MSDU or MMPDU. The fragments of a single MSDU or MMPDU are either
— Sent during a CP as individual frames using the DCF, or
— Sent during a CFP as individual frames obeying the rules of the PC medium access procedure, or
— Sent as a burst in an EDCA or HCCA TXOP, subject to TXOP limits and medium occupancy limits
for the attached PHY.
A QoS Data frame with a TID matching an existing block ack agreement may be transmitted outside an
A-MPDU with its Ack Policy subfield set to Normal Ack.
Transmission of fragmented MPDUs by a DMG STA outside of an A-MPDU depends on setting of the No-
Fragmentation field in the ADDBA Extension element within the ADDBA Response frame transmitted
during the block ack agreement handshake. The MSDU shall not be fragmented if the No-Fragmentation
field in the ADDBA Extension element within the ADDBA Response frame transmitted during the block
ack agreement handshake is 1. If the No-Fragmentation field in the ADDBA Extension element within the
ADDBA Response frame is 0, the originator may send fragmented nonaggregated MSDU with Normal Ack
policy under block ack agreement.
10.2.8 MAC data service
The MAC data service provides the transport of MSDUs between MAC peer entities as characterized in 5.1.1.
The transmission process is started by the MAC’s receipt of an MA-UNITDATA.request primitive containing
an MSDU and the associated parameters. This might cause one or more Data frames containing the MSDU to
be transmitted following A-MSDU aggregation, fragmentation, and security encapsulation, as appropriate.
The MAC generates the MA-UNITDATA.indication primitive in response to one or more received Data
frames containing an MSDU following validation, address filtering, decryption, decapsulation,
defragmentation, and A-MSDU deaggregation, as appropriate.
When dot11SSPNInterfaceActivated is true, an AP shall distribute the group addressed message into the BSS
only if dot11NonAPStationAuthSourceMulticast in the dot11InterworkingEntry identified by the source MAC
address in the received message is true. When dot11SSPNInterfaceActivated is false, the group addressed
message shall be distributed into the BSS. Unless the MPDU is delivered via DMS, the STA originating the
message receives the message as a group addressed message (prior to any filtering). Therefore, a STA shall
filter out group addressed messages that contain their address as the source address. When
dot11SSPNInterfaceActivated is false, group addressed MSDUs shall be propagated throughout the ESS.
1302
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When dot11SSPNInterfaceActivated is true, group addressed MSDUs shall be propagated throughout the ESS
only if dot11NonAPStationAuthSourceMulticast in the dot11InterworkingEntry identified by the source MAC
address in the received message is true.
The MAC performs address filtering on the Address 1 field of each MPDU contained in a PPDU and on the
DA of each MSDU within an A-MSDU. When the Address 1 field or DA field contains a group address,
address filtering is performed by comparing the value in the Address 1 field or DA field to all values in the
dot11GroupAddressesTable, and the STA also validates the BSSID to verify either that the group addressed
frame originated from a STA in the BSS of which the receiving STA is a member, or that it contains the
wildcard BSSID value, indicating a Data frame sent outside the context of a BSS (dot11OCBActivated is true
in the transmitting STA).
A mesh STA also uses the address matching rules described in 10.35.3, when it receives an individually
addressed frame. When a mesh STA receives a frame with the Address 1 field equal to a group address, the
mesh STA also checks the TA to determine whether the group addressed frame originated from one of its peer
mesh STAs; if there is no match, the STA shall discard the frame. A mesh STA also uses the address matching
rules described in 10.35.4.
If the Address 1 field of an MPDU carrying an A-MSDU does not match any address at a receiving STA, then
the entire A-MSDU is discarded.
In a QoS STA, the TID parameter of the MA-UNITDATA.request primitive results in a TID being specified
for the transmitted MSDU. This TID associates the MSDU with the AC or TS queue for the indicated traffic.
10.3 DCF
10.3.1 General
The basic medium access protocol is a DCF that allows for automatic medium sharing between compatible
PHYs through the use of CSMA/CA and a random backoff time following a busy medium condition. In
addition, all individually addressed traffic uses immediate positive acknowledgment (Ack frame), in which
retransmission is scheduled by the sender if no Ack frame is received.
The CSMA/CA protocol is designed to reduce the collision probability between multiple STAs accessing a
medium, at the point where collisions would most likely occur. Just after the medium becomes idle following a
busy medium (as indicated by the CS function) is when the highest probability of a collision exists. This is
because multiple STAs could have been waiting for the medium to become available again. This is the situation
that necessitates a random backoff procedure to resolve medium contention conflicts.
The DCF is modified for use by DMG STAs to allow sharing of the medium between compatible DMG
PHYs (see 10.3.4). A DMG STA has no direct knowledge of when it might interfere (collide with the
transmission of) another STA.
The CS function of a DMG STA might not indicate the medium busy condition due to the predominant
nature of directional transmissions and receptions. The transmission of a STA might interfere (collide) with
the transmission of another STA even though the CS function at the first STA does not indicate medium
busy. The interference (collision) is identified when the expected response frame is not received. SPSH is
achieved by the proper combination of the STA antenna configuration during the media access and data
transfer phases.
CS shall be performed both through physical and virtual mechanisms.
1303
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The virtual CS mechanism is achieved by distributing reservation information announcing the impending use
of the medium. The exchange of RTS and CTS frames prior to the actual Data frame is one means of
distribution of this medium reservation information. The RTS and CTS frames contain a Duration field that
defines the period of time that the medium is to be reserved to transmit the actual Data frame and the returning
Ack frame. A STA receiving either the RTS frame (sent by the originating STA) or the CTS frame (sent by the
destination STA) shall process the medium reservation. Thus, a STA might be unable to receive from the
originating STA and yet still know about the impending use of the medium to transmit a Data frame.
Another means of distributing the medium reservation information is the Duration/ID field in individually
addressed frames. This field gives the time that the medium is reserved, either to the end of the immediately
following Ack frame, or in the case of a fragment sequence, to the end of the Ack frame following the next
fragment.
The RTS/CTS exchange also performs both a type of fast collision inference and a transmission path check. If
the return CTS frame is not detected by the STA originating the RTS, the originating STA may repeat the
process (after observing the other medium-use rules) more quickly than if the long Data frame had been
transmitted and a return Ack frame had not been detected. An RTS/CTS exchange by VHT STAs also
performs fast collision inference on the secondary 20 MHz channel, secondary 40 MHz channel, and
secondary 80 MHz channel and helps the VHT STA transmitting the RTS to determine the available
bandwidth at the responder.
Another advantage of the RTS/CTS mechanism occurs where multiple BSSs utilizing the same channel
overlap. The medium reservation mechanism works across the BSS boundaries. The RTS/CTS mechanism
might also improve operation in a typical situation in which all STAs are able to receive from the AP, but
might not be able to receive from all other STAs in the BSA.
Except for MPDUs transmitted via the GCR service, the RTS/CTS mechanism cannot be used for MPDUs
with a group addressed immediate destination because there are multiple recipients for the RTS frame, and
thus potentially multiple concurrent senders of the CTS frame in response. For MPDUs transmitted via the
GCR service, an RTS frame may be used if it is directed to a STA within the GCR group (see 10.22.2.11.2 and
10.24.10). The RTS/CTS mechanism is not used for every Data frame transmission. Because the additional
RTS and CTS frames add overhead inefficiency, the mechanism is not always justified, especially for short
Data frames.
The use of the RTS/CTS mechanism is under control of dot11RTSThreshold. This attribute may be set on a
per-STA basis. This mechanism allows STAs to be configured to initiate RTS/CTS either always, never, or
only on frames longer than a specified length.
NOTE—A STA configured not to initiate the RTS/CTS mechanism updates its virtual CS mechanism with the duration
information contained in a received RTS or CTS frame, and responds to an RTS frame addressed to it with a CTS frame
if permitted by medium access rules.
All non-DMG STAs that are members of a BSS are able to receive and transmit at all of the data rates in the
BSSBasicRateSet parameter of the MLME-START.request primitive or BSSBasicRateSet parameter of the
SelectedBSS parameter of the MLME-JOIN.request primitive; see 6.3.4.2.4 and 6.3.11.2.4.
NOTE—A STA’s operational rate set does not necessarily contain all the mandatory rates. However a STA has to be
capable of receiving using a mandatory rate (as required by the rules in 10.7) even if it is not present in this set.
All HT STAs that are members of a BSS are able to receive and transmit using all of the MCSs in the Basic
HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS
Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive;
see 6.3.4.2.4 and 6.3.11.2.4.
All VHT STAs that are members of a BSS are able to receive and transmit using all of the
tuples in the basic VHT-MCS and NSS set (see 11.40.7) except as constrained by the rules of 10.7.12.
1304
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
All DMG STAs that are members of a BSS are able to receive and transmit using all of the MCSs in the
OperationalRateSet parameter of the MLME-START.request primitive or OperationalRateSet parameter of the
SelectedBSS parameter of the MLME-JOIN.request primitive; see 6.3.4.2.4 and 6.3.11.2.4.
To support the proper operation of the RTS/CTS by non-DMG STAs, RTS/DMG CTS by DMG STAs, and the
virtual CS mechanism, a non-DMG STA shall be able to interpret Control frames with the Subtype subfield
equal to RTS or CTS, and a DMG STA shall be able to interpret Control frames with the Subtype subfield
equal to RTS or DMG CTS.
A Data frame sent under the DCF shall have the Type subfield set to Data and the Subtype subfield set to Data
or Null. A STA receiving a frame with the Type subfield equal to Data shall not indicate the frame to the LLC
when the Subtype subfield is equal to Null, but shall indicate the frame to the LLC when the Subtype subfield
is equal to Data, even if the frame body contains zero octets.
While in the awake state and operating under DCF but not transmitting, a DMG STA can configure its receive
antenna to a quasi-omni pattern in order to receive frames transmitted by any STA that is covered by this
antenna pattern.
10.3.2 Procedures common to the DCF and EDCAF
10.3.2.1 CS mechanism
Physical and virtual CS functions are used to determine the state of the medium. When either function indicates
a busy medium, the medium shall be considered busy; otherwise, it shall be considered idle.
A physical CS mechanism shall be provided by the PHY. See Clause 8 for how this information is conveyed to
the MAC. The details of physical CS are provided in the individual PHY specifications.
A virtual CS mechanism shall be provided by the MAC. This mechanism is referred to as the NAV. The NAV
maintains a prediction of future traffic on the medium based on duration information that is announced in RTS/
CTS frames by non-DMG STAs and RTS/DMG CTS frames by DMG STAs prior to the actual exchange of
data. The duration information is also available in the MAC headers of all frames sent during the CP other than
PS-Poll frames, and during the BTI, the A-BFT, the ATI, the CBAP, and the SP. The mechanism for setting the
NAV using RTS/CTS or RTS/DMG CTS in the DCF is described in 10.3.2.4, use of the NAV in PCF is
described in 10.4.3.3, and use of the NAV in HCF is described in 10.22.2.2 and 10.22.3.4. Additional details
regarding NAV use appear in 10.3.2.5, 10.3.2.12, 10.36.10, and 10.26.
The CS mechanism combines the NAV state and the STA’s transmitter status with physical CS to determine
the busy/idle state of the medium. The NAV may be thought of as a counter, which counts down to 0 at a
uniform rate. When the counter is 0, the virtual CS indication is that the medium is idle; when the counter is
nonzero, the indication is busy. If a DMG STA supports multiple NAVs as defined in 10.36.10 and all counters
are 0, the virtual CS indication is that the medium is idle; when at least one of the counters is nonzero, the
indication is busy. The medium shall be determined to be busy when the STA is transmitting.
At aRxTxTurnaroundTime + aAirPropagationTime + aRxPHYDelay + 10% × (aSlotTime –
aAirPropagationTime) after each MAC slot boundary as defined in 10.3.7 and 10.22.2.4, the MAC shall issue a
PHY-CCARESET.request primitive to the PHY, where aAirPropagationTime determined as described in
10.21.5.
10.3.2.2 MAC-level acknowledgments
The reception of some frames, as described in 10.3.2.9 and 10.4.4.5, requires the receiving STA to respond
with an acknowledgment if the FCS of the received frame is correct. This technique is known as positive
acknowledgment.
1305
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Lack of reception of an expected frame containing an acknowledgment indicates to the STA initiating the
frame exchange that an error has occurred. Note, however, that the destination STA may have received the
frame correctly, and that the error may have occurred in the transfer or reception of the frame containing an
acknowledgment. When a frame containing an acknowledgment is lost, the MAC that initiated the frame
exchange does not receive a protocol indication of whether the initial frame was correctly received.
A correctly received frame is one for which the PHY-RXEND.indication primitive does not indicate an error
and the FCS indicates the frame is error free.
10.3.2.3 IFS
10.3.2.3.1 General
The time interval between frames is called the IFS. A STA shall determine that the medium is idle through the
use of the CS function for the interval specified. Ten different IFSs are defined to provide priority levels for
access to the wireless medium. Figure 10-4 shows some of these relationships. All timings are referenced from
occurrence of the PHY interface primitives PHY-TXEND.confirm, PHY-TXSTART.confirm, PHY-
RXSTART.indication, and PHY-RXEND.indication.
AIFS[i]
AIFS[i]
DIFS
PIFS Backoff Time
SIFS
Busy Medium Backoff Slots Next Frame
Slot Time
Select backoff time and decrement
Defer Access
as long as medium is idle
Figure 10-4—Some IFS relationships
The IFSs are as follows:
a) RIFS reduced interframe space
b) SIFS short interframe space
c) PIFS PCF interframe space
d) DIFS DCF interframe space
e) AIFS arbitration interframe space (used by the QoS facility)
f) EIFS extended interframe space
g) SBIFS short beamforming interframe space
h) BRPIFS beam refinement protocol interframe space
i) MBIFS medium beamforming interframe space
j) LBIFS long beamforming interframe space
The different IFSs shall be independent of the STA bit rate. The IFS timings are defined as time gaps on the
medium, and the IFS timings except AIFS are fixed for each PHY (even in multirate-capable PHYs). The IFSs
are determined from attributes specified by the PHY.
1306
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.3.2.3.2 RIFS
The use of RIFS for a non-DMG STA is obsolete, and support for such use might be subject to removal in a
future revision of the standard. A VHT STA shall not transmit frames separated by a RIFS.
RIFS is a means of reducing overhead and thereby increasing network efficiency.
RIFS may be used in place of SIFS to separate multiple transmissions from a single transmitter, when no SIFS-
separated response transmission is expected and either of the following is true:
— The transmitter is not a DMG STA.
— The transmitter is a DMG STA, and each transmission occurs with the same transmit antenna
configuration.
RIFS shall not be used between frames with different RA values. The duration of RIFS is defined by the aRIFS
PHY characteristic (see Table 19-25 and Table 20-32). The RIFS is the time from the end of the last symbol of
the previous frame to the beginning of the first symbol of the preamble of the subsequent frame as seen on the
WM. A STA shall not allow the space between frames that are defined to be separated by a RIFS, as measured
on the medium, to vary from the nominal RIFS (aRIFSTime) by more than ± 10% of aRIFSTime. Two frames
separated by a RIFS shall both be HT PPDUs or shall both be DMG PPDUs.
An HT STA shall not transmit PPDUs separated by a RIFS unless the beacon or probe response most recently
received from the BSS’s AP contains an HT Operation element with RIFS Mode field equal to 1.
There are additional restrictions regarding when RIFS may be employed as defined in 10.28 and 10.29. See
also 10.26.3.3.
10.3.2.3.3 SIFS
The SIFS is the time from the end of the last symbol, or signal extension if present, of the previous frame to the
beginning of the first symbol of the preamble of the subsequent frame as seen on the WM.
The SIFS shall be used prior to transmission of an Ack frame, a CTS frame, a PPDU containing a BlockAck
frame that is an immediate response to either a BlockAckReq frame or an A-MPDU, a DMG CTS frame, a
DMG DTS frame, a Grant Ack frame, a response frame transmitted in the ATI, the second or subsequent
MPDU of a fragment burst, and by a STA responding to any polling by the PCF. The SIFS may also be within
a TXOP or by a PC for any types of frames during the CFP (see 10.4).
An IEEE 802.11 implementation of a non-DMG STA shall not allow the space between frames that are
defined to be separated by a SIFS, as measured on the medium, to vary from the nominal SIFS by more than
±10% × (aSlotTime – aAirPropagationTime) for the PHY in use. An implementation of a DMG STA shall not
allow the space between frames that are defined to be separated by a SIFS, as measured on the medium, to vary
from the nominal SIFS by more than –0% or +10% × (aSlotTime – aAirPropagationTime).
SIFS is the shortest of the IFSs between transmissions from different STAs. SIFS shall be used when STAs
have seized the medium and need to keep it for the duration of the frame exchange sequence to be performed.
Using the smallest gap between transmissions within the frame exchange sequence prevents other STAs, which
are required to wait for the medium to be idle for a longer gap, from attempting to use the medium, thus giving
priority to completion of the frame exchange sequence in progress.
When transmitting a response frame immediately following a SIFS, a DMG STA shall set the TXVECTOR
parameter LAST_RSSI of the response frame to the power that was measured on the received packet, as
reported in the RCPI field of the frame that elicited the response frame. The encoding of the value is as follows:
— Power values less than or equal to –68 dBm are represented as the value of 1.
1307
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Power values between –68 dBm and –42 dBm are represented as p – – 71 + 0.5
------------------------------------ , where p is the
power in dBm. 2
— Power values greater than or equal to –42 dBm are represented as the value 15.
— For all other cases, the STA shall set the TXVECTOR parameter LAST_RSSI of the transmitted
frame to 0.
A DMG STA that transmits a PPDU containing at least one individually addressed MPDU shall set the
TXVECTOR parameter Turnaround to 1 if the STA is required to listen for an incoming PPDU immediately
following the transmission of the PPDU; otherwise, the STA shall set the TXVECTOR parameter Turnaround
to 0. The STA shall set the TXVECTOR parameter Turnaround to 0 when it transmits an RTS frame.
10.3.2.3.4 PIFS
The PIFS is used to gain priority access to the medium.
The PIFS may be used as described in the following list and shall not be used otherwise:
— A STA operating under the PCF, as described in 10.4
— A STA transmitting a Channel Switch Announcement frame, as described in 11.9 or transmitting an
Extended Channel Switch Announcement frame, as described in 11.10
— A STA transmitting a TIM frame, as described in 11.2.3.17
— An HC starting a CFP or a TXOP, as described in 10.22.3.2.3
— An HC or a non-AP QoS STA that is a polled TXOP holder recovering from the absence of an
expected reception in a CAP, as described in 10.22.3.2.4
— An HT STA using dual CTS protection before transmission of the CTS2, as described in 10.3.2.8
— A TXOP holder continuing to transmit after a transmission failure, as described in 10.22.2.7
— A TXOP holder transmitting an RTS with a bandwidth signaling TA within a multiple frame
transmission sequence, as specified in 10.22.2.7
— An RD initiator continuing to transmit using error recovery, as described in 10.28.3
— An HT AP during a PSMP sequence transmitting a PSMP recovery frame, as described in 10.29.2.3
— An HT STA performing clear channel assessment (CCA) in the secondary channel before
transmitting a 40 MHz mask PPDU using EDCA channel access, as described in 11.16.9
— An AP continuing to transmit in a GCR block ack TXOP after the failure to receive a BlockAck
frame, as described in 10.24.10
— A VHT STA performing CCA in the secondary 20 MHz, 40 MHz, and 80 MHz channels before
transmitting a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz mask PPDU using EDCA channel
access, as described in 10.22.3
— An AP or PCP continuing to transmit in the ATI after a transmission failure during the ATI
(10.36.3)
— A source DMG STA of an SP continuing to transmit after a transmission failure, as described in
10.36.6.2
— A DMG STA performing EDCA access during an allocated CBAP, as described in 10.36.5
— A TVHT STA performing CCA in the secondary TVHT_W and TVHT_2W channels before
transmitting a TVHT_2W or TVHT_W+W mask PPDU and TVHT_4W or TVHT_2W+2W mask
PPDU, respectively, using EDCA channel access, as defined in 10.22.3
With the exception of performing CCA in the secondary channel (where the timing is defined in 11.16.9), a
STA using PIFS starts its transmission after its CS mechanism (see 10.3.2.1) determines that the medium is idle
at the TxPIFS slot boundary, as defined in 10.3.7 and 10.22.2.4.
1308
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.3.2.3.5 DIFS
The DIFS shall be used by STAs operating under the DCF to transmit Data frames (MPDUs) and Management
frames (MMPDUs). A STA using the DCF may transmit if both:
— After it has correctly received a frame, its CS mechanism (see 10.3.2.1) determines that the medium
is idle at the TxDIFS slot boundary as defined in 10.3.7
— The STA’s backoff timer has expired.
10.3.2.3.6 AIFS
The AIFS shall be used by QoS STAs that access the medium using the EDCAF to transmit: all Data frames
(MPDUs) except during the ATI or an SP, all Management frames (MMPDUs) except during the ATI or an
SP, all Extension frames except for the DMG Beacon frame, and the following Control frames:
— PS-Poll
— SSW (if first transmission by an initiator in a CBAP)
— Poll (if first transmission and when in a CBAP)
— Grant (if first transmission and when in a CBAP and not transmitted in response to a SPR frame)
— SPR (when in a CBAP and not transmitted as a response to a Poll)
— RTS
— CTS (when not transmitted as a response to an RTS frame)
— DMG CTS (when not transmitted as a response to an RTS frame)
— BlockAckReq
— BlockAck (when not transmitted as a response to a BlockAckReq frame)
A STA using the EDCAF shall obtain a TXOP for an AC if the STA’s CS mechanism (see 10.3.2.1)
determines that the medium is idle at the AIFS[AC] slot boundary (see 10.22.2.4), after a correctly received
frame, and the backoff timer for that AC has expired.
A non-AP and non-PCP QoS STA computes the time periods for each AIFS[AC] from
dot11EDCATableAIFSN. In an infrastructure BSS, QoS STAs update their dot11EDCATableAIFSN values
using information in the most recent EDCA Parameter Set element of Beacon frames received from the AP of
the BSS (see 9.4.2.29) if the STA is a non-DMG STA or the most recent EDCA Parameter Set element of
DMG Beacon and Announce frames received from the AP or PCP of the BSS if the STA is a DMG STA. A
QoS AP or PCP computes the time periods for each AIFS[AC] from dot11QAPEDCATableAIFSN.
10.3.2.3.7 EIFS
A DCF shall use EIFS before transmission, when it determines that the medium is idle following reception of a
frame for which the PHY-RXEND.indication primitive contained an error or a frame for which the FCS value
was not correct. Similarly, a STA’s EDCA mechanism under HCF shall use the EIFS–DIFS+AIFS[AC]
interval. The duration of an EIFS is defined in 10.3.7. The EIFS or EIFS–DIFS+AIFS[AC] interval shall begin
following indication by the PHY that the medium is idle after detection of the erroneous frame, without regard
to the virtual CS mechanism. The STA shall not begin a transmission until the expiration of the later of the
NAV and EIFS or EIFS–DIFS+AIFS[AC]. The EIFS and EIFS–DIFS+AIFS[AC] are defined to provide
enough time for another STA to acknowledge what was, to this STA, an incorrectly received frame before this
STA commences transmission. Reception of an error-free frame during the EIFS or EIFS–DIFS+AIFS[AC]
resynchronizes the STA to the actual busy/idle state of the medium, so the EIFS or EIFS–DIFS+AIFS[AC] is
terminated and medium access (using DIFS or AIFS as appropriate and, if necessary, backoff) continues
following reception of that frame. At the expiration or termination of the EIFS or EIFS–DIFS+AIFS[AC], the
STA reverts to the NAV and physical CS to control access to the medium.
1309
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
EIFS shall not be invoked if the NAV is updated by the frame that would have caused an EIFS. EIFS shall not
be invoked for an A-MPDU if one or more of its frames are received correctly.
10.3.2.3.8 SBIFS
The SBIFS shall be used to separate multiple transmissions from a single transmitter during a receive sector
sweep or when each transmission occurs with a different transmit antenna configuration and no SIFS-
separated response transmission is expected. The duration of SBIFS is determined by the aSBIFSTime PHY
characteristic. The SBIFS is the time from the end of the last symbol of the previous frame to the beginning
of the first symbol of the preamble of the subsequent frame as seen on the WM. A STA shall not allow the
space between frames that are defined to be separated by a SBIFS, as measured on the medium, to be less
than aSBIFSTime or to be more than aSBIFSTime + aSBIFSAccuracy. Two frames separated by a SBIFS
shall both be DMG PPDUs.
10.3.2.3.9 BRPIFS
The BRPIFS shall be used by STAs between transmissions of BRP frames. The BRPIFS is the maximum
time from the end of the last symbol of the previous PPDU, or training field if present in the PPDU, to the
beginning of the first symbol of the preamble of the subsequent PPDU as seen on the WM. The
corresponding minimum time is SIFS. BRPIFS is defined to be equal to aBRPIFS+10%.
10.3.2.3.10 MBIFS
The MBIFS shall be used between the BTI and the A-BFT and between the ISS, RSS, SSW-Feedback, and
SSW-Ack. MBIFS is equal to 3×aSIFSTime. An implementation of a DMG STA shall not allow the space
between frames that are defined to be separated by an MBIFS, as measured on the medium, to vary from the
nominal MBIFS by more than –0% or +10% × (aSlotTime – aAirPropagationTime).
10.3.2.3.11 LBIFS
The LBIFS shall be used between transmissions employing different DMG antennas and when the recipient
STA is expected to switch DMG antennas. LBIFS is equal to TXTIME(SSW) + 2×SBIFS. An
implementation of a DMG STA shall not allow the space between frames that are defined to be separated by
an LBIFS, as measured on the medium, to vary from the nominal LBIFS by more than –0% or
+10% × (aSlotTime – aAirPropagationTime).
10.3.2.4 Setting and resetting the NAV
This subclause describes the setting and resetting of the NAV for non-DMG STAs and DMG STAs that
support a single NAV. DMG STAs that support multiple NAVs shall update their NAVs according to the
procedures described in 10.36.10.
A STA that receives at least one valid frame in a PSDU can update its NAV with the information from any
valid Duration field in the PSDU. When the received frame’s RA is equal to the STA’s own MAC address,
the STA shall not update its NAV. Further, when the received frame is a DMG CTS frame and its TA is
equal to the STA’s own MAC address, the STA shall not update its NAV. For all other received frames the
STA shall update its NAV when the received Duration is greater than the STA’s current NAV value. Upon
receipt of a PS-Poll frame, a STA shall update its NAV settings as appropriate under the data rate selection
rules using a duration value equal to the time, in microseconds, required to transmit one Ack frame plus one
SIFS, but only when the new NAV value is greater than the current NAV value. If the calculated duration
includes a fractional microsecond, that value is rounded up to the next higher integer. Various additional
conditions may set or reset the NAV, as described in 10.4.3.3. When the NAV is reset, a PHY-
CCARESET.request primitive shall be issued. This NAV update operation is performed when the PHY-
RXEND.indication primitive is received.
1310
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 10-5 indicates the NAV for STAs that might receive the RTS frame, while other STAs might receive
only the CTS frame, resulting in the lower NAV bar as shown (with the exception of the STA to which the RTS
frame was addressed).
Figure 10-5—RTS/CTS/data/Ack and NAV setting
A STA that used information from an RTS frame as the most recent basis to update its NAV setting is
permitted to reset its NAV if no PHY-RXSTART.indication primitive is received from the PHY during a
NAVTimeout period starting when the MAC receives a PHY-RXEND.indication primitive corresponding to
the detection of the RTS frame.
In non-DMG BSS, NAVTimeout period is equal to (2 x aSIFSTime) + (CTS_Time) + aRxPHYStartDelay + (2
x aSlotTime). The “CTS_Time” shall be calculated using the length of the CTS frame and the data rate at
which the RTS frame used for the most recent NAV update was received.
In DMG BSS, NAVTimeout period is equal to (2 x aSIFSTime) + TDMG-CTS + StartDelayCompensation + (2 x
aSlotTime), where TDMG-CTS is the duration of a DMG CTS frame calculated using the TXVECTOR TRN-
LEN parameter equal to the RXVECTOR TRN-LEN parameter of the received RTS frame and
StartDelayCompensation is equal to aSlotTime.
NOTE—This value of StartDelayCompensation is a compromise over the possible values of aRxPHYStartDelay, which
are dependent on both the implementation and the DMG PHY mode.
A STA supporting L-SIG TXOP that used the information from a frame with different L-SIG duration and
MAC duration endpoints (characteristics of an L-SIG TXOP initiating frame; see 10.26.5.4 for details) as the
most recent basis to update its NAV setting may reset its NAV if no PHY-RXSTART.indication primitive is
received from the PHY during a period with a duration of aSIFSTime + aRxPHYStartDelay + 2 aSlotTime
starting at the expiration of the L-SIG duration. For details of L-SIG duration, see 10.26.5.
10.3.2.5 RTS/CTS with fragmentation
The following is a description of using RTS/CTS for a fragmented MSDU or MMPDU. The RTS/CTS frames
define the duration of the following frame and acknowledgment. The Duration/ID field in the Data and Ack
frames specifies the total duration of the next fragment and acknowledgment. This is illustrated in Figure 10-6.
1311
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DIFS
PIFS
NAV (Fragment 0)
SIFS
NAV (RTS) NAV (Fragment 1) Backoff-Window
Other NAV (CTS) NAV (ACK 0) NAV (ACK 1)
RTS SIFS SIFS SIFS SIFS SIFS SIFS SIFS
Fragment 0 Fragment 1 Fragment 2
Source
CTS ACK 0 ACK 1 ACK 3
Destination
Figure 10-6—RTS/CTS with fragmented MSDU
Each frame contains information that defines the duration of the next transmission. The duration information
from RTS frames shall be used to update the NAV to indicate busy until the end of Ack frame 0. The duration
information from the CTS frame shall also be used to update the NAV to indicate busy until the end of Ack
frame 0. Both Fragment 0 and Ack frame 0 shall contain duration information to update the NAV to indicate
busy until the end of Ack frame 1. This shall be done by using the Duration/ID field in the Data and Ack
frames. This shall continue until the last fragment, which shall have a duration of one Ack time plus one SIFS,
and its Ack frame, which shall have its Duration/ID field set to 0. Each fragment and Ack frame acts as a
virtual RTS frame and CTS frame; therefore no further RTS/CTS frames need to be generated after the RTS/
CTS that began the frame exchange sequence even though the PSDUs carrying subsequent fragments may be
larger than dot11RTSThreshold.
In the case where an acknowledgment is sent but not received by the source STA, STAs that heard the
fragment, or Ack frame, mark the channel busy for the next frame exchange due to the NAV having been
updated from these frames. This is the worst-case situation, and it is shown in Figure 10-7. If an
acknowledgment is not sent by the destination STA, STAs that can only hear the destination STA do not
update their NAV and may attempt to access the channel when their NAV updated from the previously
received frame reaches 0. All STAs that hear the source are free to access the channel after their NAV updated
from the transmitted fragment has expired.
Figure 10-7—RTS/CTS with transmitter priority and missed acknowledgment
1312
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.3.2.6 VHT RTS procedure
A VHT STA transmitting an RTS frame carried in non-HT or non-HT duplicate format and addressed to a
VHT STA shall set the TA field to a bandwidth signaling TA and shall set the TXVECTOR parameters
CH_BANDWIDTH_IN_NON_HT and CH_BANDWIDTH to the same value. If the STA sending the RTS
frame is capable of dynamic bandwidth operation (see 10.3.2.7), the STA shall set the TXVECTOR
parameter DYN_BANDWIDTH_IN_NON_HT to Dynamic. Otherwise, the STA shall set the TXVECTOR
parameter DYN_BANDWIDTH_IN_NON_HT to Static.
A VHT STA that initiates a TXOP by transmitting an RTS frame with the TA field set to a bandwidth
signaling TA shall not send an RTS frame to a non-VHT STA for the duration of the TXOP.
NOTE—A non-VHT STA considers the bandwidth signaling TA as the address of the TXOP holder. If an RTS frame is
sent to a non-VHT STA during a TXOP that is initiated by an RTS frame with a bandwidth signaling TA, the non-VHT
STA does not recognize the RTS sender as the TXOP holder.
10.3.2.7 CTS and DMG CTS procedure
A STA that receives an RTS frame addressed to it considers the NAV in determining whether to respond
with CTS, unless the NAV was set by a frame originating from the STA sending the RTS frame (see
10.22.2.2). In this subclause, “NAV indicates idle” means that the NAV count is 0 or that the NAV count is
nonzero but the nonbandwidth signaling TA obtained from the TA field of the RTS frame matches the saved
TXOP holder address.
A VHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a
bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT
equal to Static behaves as follows:
— If the NAV indicates idle and CCA has been idle for all secondary channels (secondary 20 MHz
channel, secondary 40 MHz channel, and secondary 80 MHz channel) in the channel width
indicated by the RTS frame’s RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT for a
PIFS prior to the start of the RTS frame, then the STA shall respond with a CTS frame carried in a
non-HT or non-HT duplicate PPDU after a SIFS. The CTS frame’s TXVECTOR parameters
CH_BANDWIDTH and CH_BANDWIDTH_IN_NON_HT shall be set to the same value as the
RTS frame’s RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT.
— Otherwise, the STA shall not respond with a CTS frame.
A VHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a
bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT
equal to Dynamic behaves as follows:
— If the NAV indicates idle, then the STA shall respond with a CTS frame in a non-HT or non-HT
duplicate PPDU after a SIFS. The CTS frame’s TXVECTOR parameters CH_BANDWIDTH and
CH_BANDWIDTH_IN_NON_HT shall be set to any channel width for which CCA on all
secondary channels has been idle for a PIFS prior to the start of the RTS frame and that is less than
or equal to the channel width indicated in the RTS frame’s RXVECTOR parameter
CH_BANDWIDTH_IN_NON_HT.
— Otherwise, the STA shall not respond with a CTS frame.
A non-VHT STA that is addressed by an RTS frame or a VHT STA that is addressed by an RTS frame
carried in a non-HT or non-HT duplicate PPDU that has a nonbandwidth signaling TA or a VHT STA that is
addressed by an RTS frame in a format other than non-HT or non-HT duplicate behaves as follows:
— If the NAV indicates idle, the STA shall respond with a CTS frame after a SIFS.
— Otherwise, the STA shall not respond with a CTS frame.
1313
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The RA field of the CTS frame shall be set to the nonbandwidth signaling TA obtained from the TA field of
the RTS frame to which this CTS frame is a response. The Duration field in the CTS frame shall be the
duration field from the received RTS frame, adjusted by subtraction of aSIFSTime and the number of
microseconds required to transmit the CTS frame at a data rate determined by the rules in 10.7.
After transmitting an RTS frame, the STA shall wait for a CTSTimeout interval with a value of aSIFSTime +
aSlotTime + aRxPHYStartDelay. This interval begins when the MAC receives a PHY-TXEND.confirm
primitive. If a PHY-RXSTART.indication primitive does not occur during the CTSTimeout interval, the STA
shall conclude that the transmission of the RTS frame has failed, and this STA shall invoke its backoff
procedure upon expiration of the CTSTimeout interval. If a PHY-RXSTART.indication primitive does occur
during the CTSTimeout interval, the STA shall wait for the corresponding PHY-RXEND.indication primitive
to determine whether the RTS frame transmission was successful. The recognition of a valid CTS frame sent
by the recipient of the RTS frame, corresponding to this PHY-RXEND.indication primitive, shall be
interpreted as successful response, permitting the frame exchange sequence to continue (see Annex G). The
recognition of anything else, including any other valid frame, shall be interpreted as failure of the RTS frame
transmission. In this instance, the STA shall invoke its backoff procedure at the PHY-RXEND.indication
primitive and may process the received frame.
A DMG STA follows the procedure defined in this subclause, except that it uses a DMG CTS frame instead of
a CTS frame. A non-DMG STA does not transmit DMG CTS frames.
10.3.2.8 Dual CTS protection
10.3.2.8.1 Dual CTS protection procedure
The use of the dual CTS mechanism is deprecated.
A VHT STA shall not transmit VHT PPDUs in a TXOP protected by dual CTS protection.
A VHT AP shall not transmit an HT Operation element with the Dual CTS Protection field set to 1.
If the Dual CTS Protection field of the HT Operation element has value 1 in the Beacon frames transmitted by
its AP, a non-AP HT STA shall start every TXOP with an RTS frame addressed to the AP. The RTS frame
shall be an STBC frame if the STBC transmit and receive capabilities of the non-AP HT STA allow it to
receive and transmit STBC frames using a single spatial stream; otherwise, the RTS frame shall be a non-
STBC frame. The AP shall respond with a dual CTS (CTS1 followed by CTS2) separated by PIFS or SIFS.
Table 10-2 describes the sequence of CTS frame transmissions and the required timing.
Table 10-2—Dual CTS rules
Type of RTS CTS description Timing
RTS CTS1: Same rate or MCS as PIFS shall be used as the interval between CTS1 and CTS2.
(non-STBC the RTS frame (non-STBC
frame) frame) If the CS mechanism (see 10.3.2.1) indicates that the medium is
CTS2: Basic STBC MCS busy at the TxPIFS slot boundary (see Figure 10-26) following
(STBC frame) CTS1, CTS2 shall not be transmitted as part of this frame
exchange.
RTS CTS1: Basic STBC MCS SIFS shall be used as the interval between CTS1 and CTS2.
(STBC frame) (STBC frame) The STA resumes transmission a SIFS+CTS2+SIFS after
CTS2: Lowest basic rate receiving CTS1, instead of after SIFS.
(non-STBC frame)
1314
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The dual CTS response applies only to the AP; a non-AP STA shall respond to an RTS frame with a single
CTS frame.
If dual CTS Protection is enabled, the AP shall begin each EDCA TXOP with a CTS frame. This CTS frame
uses STBC when the immediately following frame uses non-STBC and vice versa. The RA of this CTS frame
shall be identical to the RA of the immediately following frame. The AP may continue a PIFS after the CTS
frame, only if the CS mechanism (see 10.3.2.1) indicates that the medium is IDLE at the TxPIFS slot boundary
(see Figure 10-26) following the transmission of the CTS frame.
To avoid the resetting of NAV by STAs that have set their NAV due to the reception of a non-STBC RTS
frame that is part of a dual CTS exchange, but then do not hear the CTS2, a non-AP HT STA may create a
NAV that is not resettable according to the RTS NAV reset rule defined in 10.3.2.4 at the receiving STAs by
initiating the TXOP with a non-STBC CTS addressed to the AP (known as CTS-to-AP).
NOTE—Sending a CTS-to-AP allows NAV protection to be established without causing the AP to update its NAV, as
opposed to, for example, the sending of a CTS-to-self frame, which would potentially have caused the AP NAV to
become set and then prevented it from responding to the subsequent RTS frame. The AP does not set a NAV in the CTS-
to-AP case and is able to respond to the following RTS frame. The NAV at receiving STAs is not updated by the RTS
frame because its duration does not exceed the duration of the preceding CTS frame, and subsequently, the NAV cannot
be reset during CTS2.
An STBC CTS addressed to the AP may be transmitted prior to an STBC RTS frame to set a NAV that is not
resettable according to the RTS NAV reset rule defined in 10.3.2.4 at receiving STAs.
NOTE—When an HT STA sends an RTS frame to the AP that is a non-STBC frame, the AP returns a CTS frame that is
a non-STBC frame to the STA and then immediately transmits a CTS frame that is an STBC frame. The original non-AP
STA is now free to transmit. But a non-HT STA that has set its NAV based on the original RTS frame might reset its
NAV and then decrement its backoff counter, given that a SIFS + the duration of CTS2 is longer than a DIFS (i.e., the
STA does not detect PHY-RXSTART.indication primitive within the period specified in 10.3.2.4). Thus, without
sending a CTS-to-AP, the NAV reservation might not always work.
If dual CTS protection is enabled and a STA obtains a TXOP and does not have any frames to transmit before
the expiration of the TXOP duration, the STA may indicate truncation of the TXOP provided that the
remaining duration of the TXOP after the transmission of the last frame can accommodate the CF-End frame, a
CF-End frame that is an STBC frame duration at the basic STBC MCS, a CF-End frame that is a non-STBC
frame at the lowest basic rate, and three SIFSs. The STA indicates truncation of the TXOP by transmitting a
CF-End frame with TXVECTOR parameter restrictions as specified in 10.7.6.3.
On receiving a CF-End frame from a STA with a matching BSSID, an AP whose last transmitted HT
Operation element contained the Dual CTS Protection field equal to 1 shall respond with dual CF-End frames,
one CF-End frame that is an STBC frame at the basic STBC MCS and one CF-End frame that is a non-STBC
frame at the lowest basic rate, after a SIFS. Dual CF-End frames eliminate unfairness toward STAs that are not
of the same mode as the one that owns the TXOP being truncated.
If the TXOP is owned by the AP and dual CTS protection is enabled in the system, the AP may send dual CF-
End frames if it runs out of frames to transmit, provided that the remaining TXOP duration after the
transmission of the last frame can accommodate a STBC CF-End frame duration at the lowest STBC basic rate,
a CF-End frame that is a non-STBC frame at the lowest basic rate, and two SIFSs.
The spacing between the dual CF-End frames sent by the AP shall be SIFS. The first CF-End frame shall use
the same encoding (STBC frame versus non-STBC frame) used for transmissions in the TXOP being
truncated, and the second CF-End frame shall use the other encoding.
An STBC-capable STA shall choose between control frame operation using either STBC frames or non-STBC
frames. In the non-STBC frame case, it discards Control frames that are STBC frames it receives. In the STBC
frame case, it discards Control frames that are non-STBC frames received from its own BSS. This choice is a
matter of policy local at the STA.
1315
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.3.2.8.2 Dual CTS protection examples
Figure 10-8 shows an example of the operation of the dual CTS protection mechanism. In this example, the
initiating STA is an STBC non-AP STA.
Key:
non-AP STA
CTS to AP
STBC frame
CF-End
STBC
Data
RTS
Non-STBC frame
SIFS SIFS SIFS SIFS ≥ SIFS SIFS SIFS
Optional
CF-End
CF-End
AP
CTS
CTS
Ack
NAV of 3rd-party STBC STA near non-AP STA
NAV of 3rd-party STBC STA near AP
NAV of 3rd-party non-STBC STA
Figure 10-8—Example of dual CTS mechanism (STBC initiator)
Figure 10-9 shows an example of the operation of the dual CTS protection mechanism. In this example, the
initiating STA is a non-STBC non-AP HT STA.
Key:
non-AP HT
Non-STBC
CTS to AP
STBC frame
CF-End
STA
Data
RTS
Non-STBC frame
SIFS SIFS PIFS SIFS ≥ SIFS SIFS SIFS
Optional
CF-End
CF-End
AP
CTS
CTS
Ack
NAV of 3rd-party STBC STA
rd
NAV of 3 -party non-STBC STA near non-AP STA
NAV of 3rd-party non-STBC not near non-AP STA
Figure 10-9—Example of dual CTS mechanism (non-STBC initiator)
10.3.2.9 Acknowledgment procedure
The cases when an Ack or BlockAck frame can be generated are shown in the frame exchange sequences listed
in Annex G.
A STA shall not transmit an Ack frame in response to a Management frame of subtype Action No Ack. A non-
AP STA shall not transmit an Ack or BlockAck frame in response to a group addressed frame.
NOTE—Group addressed MSDUs are sent to an AP in individually addressed frames.
1316
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Otherwise, upon reception of a frame that requires acknowledgment and, for an AP, with the To DS subfield
equal to 1, a STA shall transmit an Ack or BlockAck frame after a SIFS, without regard to the busy/idle state of
the medium. (See Figure 10-10.)
Source Data
SIFS Ack/
Destination BA
DIFS
Other Backoff Slots
Defer Access Backoff after Defer
Figure 10-10—Individually addressed data/Ack/BA frame
After transmitting an MPDU that requires an Ack or BlockAck frame as a response (see Annex G), the STA
shall wait for an AckTimeout interval, with a value of aSIFSTime + aSlotTime + aRxPHYStartDelay, starting at
the PHY-TXEND.confirm primitive. If a PHY-RXSTART.indication primitive does not occur during the
AckTimeout interval, the STA concludes that the transmission of the MPDU has failed, and this STA shall
invoke its backoff procedure upon expiration of the AckTimeout interval.
If a PHY-RXSTART.indication primitive does occur during the AckTimeout interval, the STA shall wait for the
corresponding PHY-RXEND.indication primitive to determine whether the MPDU transmission was successful.
If the STA recognizes a valid Ack frame addressed to the STA and corresponding to this PHY-
RXEND.indication primitive, this recognition shall be interpreted as successful acknowledgment.
If the STA does not recognize a valid Ack frame addressed to the STA, this condition shall be interpreted as
failure of its MPDU transmission. In this instance, the STA shall invoke its backoff procedure at the PHY-
RXEND.indication primitive and may process the received frame. If the STA has transmitted a PS-Poll frame,
then the STA’s receipt and recognition of a valid Data or Management frame transmitted by the recipient of the
PS-Poll frame shall also be accepted as successful acknowledgment of the PS-Poll frame.
NOTE 1—The backoff procedure in the specific case of reception of a corrupted Ack or BlockAck frame results in EIFS
rather than DIFS or AIFS being used after the AckTimeout interval and subsequent reception of the corrupted Ack or
BlockAck frame (see 10.3.4.3 and 10.22.2.4 respectively).
NOTE 2—The receiver STA performs the acknowledgment procedure on all received frames requiring
acknowledgment, even if an MSDU or A-MSDU is carried partly or wholly within the frame and is subsequently
discarded due to drop eligibility (see DEI subfield in 9.2.4.6.2).
NOTE 3—The rules that specify the contents of BlockAck frames are defined in 10.24.
10.3.2.10 MU acknowledgment procedure
The acknowledgment procedure performed by a STA that receives MPDUs that were transmitted within a
VHT MU PPDU is the same as the acknowledgment procedure for MPDUs that were not transmitted within
a VHT MU PPDU.
1317
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—All MPDUs transmitted within a VHT MU PPDU are contained within A-MPDUs, and the rules specified in
9.7.3 prevent an immediate response to more than one of the A-MPDUs.
Responses to A-MPDUs within a VHT MU PPDU that are not immediate responses to the VHT MU PPDU
are transmitted in response to explicit BlockAckReq frames by the AP. Examples of VHT MU PPDU frame
exchange sequences are shown in Figure 10-11 and Figure 10-12.
SIFS SIFS SIFS SIFS SIFS
AP VHT MU PPDU BAR BAR
STA 1 BA/Ack
STA 2 BA/Ack
STA 3 BA/Ack
Figure 10-11—Example of TXOP containing VHT MU PPDU transmission
with immediate acknowledgment to VHT MU PPDU
SIFS SIFS SIFS SIFS SIFS SIFS
AP VHT MU PPDU BAR BAR BAR
STA 1 BA/Ack
STA 2 BA/Ack
STA 3 BA/Ack
Figure 10-12—Example of TXOP containing VHT MU PPDU transmission
with no immediate acknowledgment to VHT MU PPDU
Recovery within the TXOP that contains a VHT MU PPDU can be performed according to the rules of
10.22.2.7. BlockAckRequest frames related to A-MPDUs within a VHT MU PPDU can be transmitted in a
TXOP separate from the one that contained the VHT MU PPDU.
NOTE 1—A BlockAck frame or an Ack frame is sent in immediate response to the BlockAckReq frame for HT-
immediate or HT-delayed Block Ack, respectively. An Ack frame might be sent in immediate response to a VHT single
MPDU in the VHT MU PPDU.
NOTE 2—A BlockAckRequest frame would typically not be sent to a STA in the case where the A-MPDU to the STA
contained no MPDUs requiring acknowledgment. It could be sent if MPDUs in a previous A-MPDU remain
unacknowledged.
1318
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.3.2.11 Duplicate detection and recovery
10.3.2.11.1 General
Because MAC-level acknowledgments and retransmissions are incorporated into the protocol, there is the
possibility that a frame may be received more than once. The procedures defined in this subclause attempt to
filter out these duplicates. Additional duplicate filtering is performed during Receive Buffer Operation for
frames that are part of a block ack agreement as described in 10.24.4 and 10.24.7.
Duplicate frame filtering is facilitated through the inclusion of a Sequence Control field (consisting of a
sequence number and fragment number) within Data, Management, and Extension frames, a TID subfield in
the QoS Control field within QoS Data frames, and an ACI subfield in the Sequence Number field within
QMFs.
NOTE—In 10.3.2.11, Data frames with a value of 1 in the QoS subfield of the Subtype subfield are collectively referred
to as QoS Data frames.
10.3.2.11.2 Transmitter requirements
A STA maintains one or more sequence number spaces that are used when transmitting a frame to determine
the sequence number for the frame. When multiple sequence number spaces are supported, the appropriate
sequence number space is determined by information from the MAC control fields of the frame to be
transmitted. Except as noted below, each sequence number space is represented by a modulo 4096 counter,
starting at 0 and incrementing by 1, for each MSDU or MMPDU transmitted using that sequence number
space.
NOTE—Group addressed retransmissions of BUs use the same sequence number as the initial group addressed
transmission of the BU. Unicast retransmissions of a group addressed BU delivered via DMS use the same sequence
number as the initial unicast transmission of the BU. When a BU is delivered both using group addressing and unicast
(e.g., when DMS is active but there are other associated STAs not using DMS), the sequence number might differ
between the group addressed and unicast transmissions of the same BU.
MPDUs that are part of the same MSDU or A-MSDU shall have the same sequence number. Different MSDUs
or A-MSDUs have (with a high probability) a different sequence number.
A transmitting STA shall support the applicable sequence number spaces defined in Table 10-3. Applicability
is defined by the “applies to” column. The “Status” column indicates the level of support that is required if
“Applies to” matches the transmission. The “Multiplicity” column indicates whether the sequence number
space contains a single counter, or multiple counters and in the latter case identifies any indexes. The
“Transmitter requirements” column identifies requirements for the operation of this sequence number space.
The referenced requirements are defined at the end of the table.
Table 10-3—Transmitter sequence number spaces
Sequence
Sequence
number Transmitter
number Applies to Status Multiplicity
space requirements
space
identifier
SNS1 Baseline A STA transmitting a frame Mandatory Single TR1
that is not covered by any of Instance
the other sequence number
spaces.
SNS2 Individually A STA transmitting an Mandatory Indexed by
addressed individually addressed QoS
1319
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-3—Transmitter sequence number spaces (continued)
Sequence
Sequence
number Transmitter
number Applies to Status Multiplicity
space requirements
space
identifier
SNS3 Time Priority A QoS STA transmitting a Optional Indexed by
Management Time Priority Management
SNS4 QMF A QMF STA transmitting a Mandatory Indexed by TR2
QMF
SNS5 QoS (+)Null A STA transmitting a QoS Mandatory None TR3
(+)Null frame
TR1: A transmitting STA should cache the last used sequence number per RA for frames that are assigned sequence
numbers from this sequence number space. The STA should check that the successively assigned sequence numbers
for frames transmitted to a single RA do not have the same value as is found in the cache for that RA. If the check
fails the STA should increment the counter by 2, rather than 1.
TR2: The STA shall assign the sequence number from one modulo 1024 counter per tuple starting
at 0 and incrementing by 1 for each MMPDU carried in one or more QMFs with Address 1 and ACI fields matching
the tuple values corresponding to that counter.
TR3: Sequence numbers for transmitted QoS (+)Null frames may be set to any value.
10.3.2.11.3 Receiver requirements
A STA maintains one or more duplicate detection caches. Table 10-4 defines the conditions under which a
duplication detection cache is supported and the rules followed by the receiver for the cache. When a Data,
Management or Extension frame is received, a record of that frame is inserted in an appropriate cache. That
record is identified by a sequence number and possibly other information from the MAC control fields of the
frame. When a Data, Management or Extension frame is received in which the Retry subfield of the Frame
Control field is equal to 1, the appropriate cache, if any, is searched for a matching frame. In DMG, when a
group addressed frame is received the appropriate cache is searched for a matching frame. If the search is
successful, the frame is considered to be a duplicate. Duplicate frames are discarded.
NOTE—The receiver STA performs the Ack and (for an AP) PS procedures on all received frames requiring
acknowledgment, even if the frame is discarded due to duplicate filtering.
There is a small possibility that a frame may be improperly rejected due to such a match; however, this
occurrence is rare and simply results in a lost frame (similar to an FCS error in other LAN protocols).
A receiving STA shall implement the applicable receiver requirements defined in Table 10-4 with “Status”
indicated as “Mandatory”. A receiving STA should implement the applicable receiver requirements defined in
Table 10-4 with “Status” indicated as “Recommended”. A receiving STA may implement the applicable
receiver requirements defined in Table 10-4 with “Status” indicated as “Optional”. Applicability is defined by
the “applies to” column. The “Status” column indicates the level of support that is required if “Applies to”
matches the received frame. The “Multiplicity / Cache size” column indicates the indexes that identify a cache
entry and the number of entries that shall be supported. The “Receiver requirements” column identifies
requirements for the operation of this cache. The referenced requirements are defined at the end of the table.
The requirements relate to caching information that identifies a cache entry and discarding duplicate MPDUs.
1320
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-4—Receiver caches
Receiver
Cache Multiplicity / Cache Receiver
cache Applies to Status
name size requirements
identifier
RC1 Not QoS A STA receiving frames Mandatory Indexed by: . RR5
QoS Data, excluding if
supported: At least the most recent
RC4 cache entry per
RC5 .
RC6
RC7
RC8
RC10
RC2 QoS A STA receiving an Mandatory Indexed by: .
frame, excluding RC3,
and if supported: At least the most recent
RC7, RC8, RC9, and cache entry per
RC10 pair
in this cache.
RC3 QoS A QoS STA receiving a Mandatory None RR4
(+)Null QoS (+)Null frame
RC4 Non- A STA receiving an Recommen Indexed by: RR5
Manage Management frame,
ment excluding RC6 if RC6 is At least the most recent
supported cache entry per
value.
RC5 Time A STA receiving an Supported if Indexed by: .
ment Management frame otherwise
not At least the most recent
supported cache entry per
value.
RC6 QMFs A STA receiving an Mandatory Indexed by: RR5
The most recent cache
entry per .
1321
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-4—Receiver caches (continued)
Receiver
Cache Multiplicity / Cache Receiver
cache Applies to Status
name size requirements
identifier
RC7 Nonmes A nonmesh STA Mandatory Indexed by:
addressed frame subject
to a GCR agreement. One cache entry per
tuple for each
group address subject to
a GCR agreement.
RC8 Mesh A mesh STA receiving a Mandatory Indexed by: .
agreement.
One cache entry per
tuple for each group
address subject to a
GCR agreement.
RC9 QoS A non-DMG QoS STA Recommen None RR4
Data receiving a QoS Data ded
under frame sent under a BA
BA agreement
RC10 DMG A DMG STA receiving a Mandatory Indexed by:
The most recent cache
entry per .
RR1: A receiving non-DMG STA with dot11QMFActivated false or not present and with
dot11RobustAVStreamingImplemented false or not present should omit tuples obtained from group addressed
frames from this cache.
RR2: A receiving STA should omit tuples obtained from ATIM frames from this cache.
RR3: A receiving QMF STA that is a non-DMG STA with dot11RobustAVStreamingImplemented false or not present
shall omit from the cache all tuples obtained from group addressed Data frames.
RR4: For the purposes of duplicate detection using receiver caches, QoS (+)Null frames and, in a non-DMG BSS,
QoS Data frames under a BA agreement, shall be ignored.
RR5: The STA shall discard the frame if the Retry subfield of the Frame Control field is 1 and it matches an entry in
the cache.
RR6: The STA shall discard the frame if it matches an entry in the cache.
10.3.2.12 NAV distribution
When a node needs to distribute NAV information, for instance, to reserve the medium for a transmission of a
nonbasic rate frame (that might not be heard by other nodes in the BSS), the node may first transmit a CTS
frame with the RA field equal to its own MAC address (CTS-to-self) if the node is a non-DMG STA, or it may
1322
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
transmit a DMG CTS frame with the RA field equal to its own MAC address and the TA field equal to the
MAC address of the peer STA for which the forthcoming transmission of the node is intended (DMG CTS-to-
self) if the node is a DMG STA. A duration value in the frame protects the pending transmission, plus possibly
an Ack frame.
The CTS-to-self and DMG CTS-to-self NAV distribution mechanisms are lower in network overhead cost than
are the RTS/CTS and RTS/DMG CTS NAV distribution mechanisms, respectively, but CTS-to-self and
DMG CTS-to-self are less robust against hidden nodes and collisions than RTS/CTS and RTS/DMG CTS-to-
self, respectively. STAs employing a NAV distribution mechanism should choose a mechanism that is
appropriate for the given network conditions. If errors occur when employing the CTS-to-self or DMG CTS-
to-self mechanism, STAs should switch to a more robust mechanism.
10.3.2.13 Operation of aSlotTime
A STA in which dot11ShortSlotTimeOptionImplemented is true shall set the MAC variable aSlotTime to
the short slot value upon transmission or reception of Beacon, Probe Response, Association Response, and
Reassociation Response frames from the BSS that the STA has joined or started and that have the short slot
subfield equal to 1. The STA shall set the MAC variable aSlotTime to the long slot value upon transmission
or reception of Beacon, Probe Response, Association Response, and Reassociation Response frames from
the BSS that the STA has joined or started and that have the short slot subfield equal to 0.
A STA in which dot11ShortSlotTimeOptionImplemented is false shall set the MAC variable aSlotTime to
the long slot value at all times. A STA in which dot11ShortSlotTimeOptionImplemented is not present, or
when the PHY supports only a single slot time value shall set the MAC variable aSlotTime to the slot value
appropriate for the attached PHY.
10.3.3 Random backoff time
A STA desiring to initiate transfer of Data frames and/or Management frames using the DCF shall invoke the
CS mechanism (see 10.3.2.1) to determine the busy/idle state of the medium. If the medium is busy, the STA
shall defer until the medium is determined to be idle without interruption for a period of time equal to DIFS
when the last frame detected on the medium was received correctly, or after the medium is determined to be
idle without interruption for a period of time equal to EIFS when the last frame detected on the medium was
not received correctly. After this DIFS or EIFS medium idle time, the STA shall then generate a random
backoff period (defined by Equation (10-1)) for an additional deferral time before transmitting, unless the
backoff timer already contains a nonzero value, in which case the selection of a random number is not needed
and not performed. This process minimizes collisions during contention between multiple STAs that have been
deferring to the same event.
Backoff Time = Random() aSlotTime (10-1)
where
Random() = Pseudorandom integer drawn from a uniform distribution over the interval [0,CW], where
CW is an integer within the range of values of the PHY characteristics aCWmin and aCW-
max, aCWmin CW aCWmax. It is important that designers recognize the need for
statistical independence among the random number streams among STAs.
The contention window (CW) parameter shall take an initial value of aCWmin. Every STA shall maintain a
STA short retry count (SSRC) as well as a STA long retry count (SLRC), both of which shall take an initial
value of 0. The SSRC shall be incremented when any short retry count (SRC) associated with any MPDU with
the Type subfield equal to Data is incremented. The SLRC shall be incremented when any long retry count
(LRC) associated with any MPDU with the Type subfield equal to Data is incremented. The CW shall take the
next value in the series every time an unsuccessful attempt to transmit an MPDU causes either STA retry
1323
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
counter to increment, until the CW reaches the value of aCWmax. A retry is defined as the entire sequence of
frames sent, separated by SIFSs, in an attempt to deliver an MPDU, as described in Annex G. Once it reaches
aCWmax, the CW shall remain at the value of aCWmax until the CW is reset. This improves the stability of the
access protocol under high-load conditions. See Figure 10-13.
Figure 10-13—Example of exponential increase of CW
The CW shall be reset to aCWmin after every successful attempt to transmit a frame containing all or part of an
MSDU or MMPDU, when SLRC reaches dot11LongRetryLimit, or when SSRC reaches
dot11ShortRetryLimit.
The SSRC shall be reset to 0 when a CTS frame is received in response to an RTS frame, when a BlockAck
frame is received in response to a BlockAckReq frame, when an Ack frame is received in response to the
transmission of a frame containing all or part of an MSDU or MMPDU that is contained in a PSDU of length
less than or equal to dot11RTSThreshold, or when a frame with a group address in the Address 1 field is
transmitted.
The SLRC shall be reset to 0 when an Ack frame is received in response to transmission of a frame containing
all or part of an MSDU or MMPDU that is contained in a PSDU of length greater than dot11RTSThreshold, or
when a frame with a group address in the Address 1 field is transmitted.
The set of CW values shall be sequentially ascending integer powers of 2, minus 1, beginning with a PHY-
specific aCWmin value, and continuing up to a PHY-specific aCWmax value.
10.3.4 DCF access procedure
10.3.4.1 Introduction
The CSMA/CA access method is the foundation of the DCF. The operational rules vary slightly between the
DCF and the PCF.
10.3.4.2 Basic access
Basic access refers to the core mechanism a STA uses to determine whether it may transmit using the DCF.
1324
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA may transmit an MPDU when it is operating under the DCF access method, either in the absence of
a PC, or in the CP of the PCF access method, when the STA determines that the medium is idle when a
frame is queued for transmission, and remains idle for a period of a DIFS, or an EIFS (10.3.2.3.7) from the
end of the immediately preceding medium-busy event, whichever is the greater, and the backoff timer is
zero. Otherwise the random backoff procedure described in 10.3.4.3 shall be followed.
A DMG STA operating under the DCF access method should transmit frames with its transmit antenna
pattern directed toward the intended receiver.
A DMG STA operating under the DCF access method that does not operate in a TXOP exchange may
configure its receiving antenna array to a quasi-omni antenna pattern to be ready to receive frames from any
DMG STA.
NOTE—The steady state of the antenna configuration might depend on the actual applications in which a DMG STA is
involved. For example, a DMG STA that expects transactions with several STAs during a CBAP configures the
receiving antenna to a quasi-omni pattern to be ready to receive transmission from any of the STAs. A DMG STA that
expects transactions with a single STA (e.g., AP or PCP) might keep its receiving antenna directed to the peer STA.
A DMG STA operating under the DCF access method that is participating in a TXOP exchange should
configure its receiving antenna array to be directed toward the other transmitter involved in the TXOP.
The basic access mechanism is illustrated in Figure 10-14.
Access after DIFS under
certain conditions
DIFS
PIFS Backoff Time
DIFS SIFS
Busy Medium Backoff Slots Next Frame
Slot Time
Select backoff time and decrement
Defer Access
as long as medium is idle
Figure 10-14—Basic access method
10.3.4.3 Backoff procedure for DCF
This subclause describes backoff procedure that is to be invoked when DCF is used. For the backoff procedure
when EDCA is used, see 10.22.2.2.
A STA shall invoke the backoff procedure to transfer a frame when finding the medium busy as indicated by
either the physical or virtual CS mechanism (see Figure 10-15). A transmitting STA shall invoke the backoff
procedure when the STA infers a failed transmission as defined in 10.3.2.7 or 10.3.2.9.
To begin the backoff procedure, the STA shall set its backoff timer to a random backoff time using the equation
in 10.3.3. All backoff slots occur following a DIFS during which the medium is determined to be idle for the
duration of the DIFS, or following an EIFS during which the medium is determined to be idle for the duration
of the EIFS, as appropriate (see 10.3.2.3) except that no backoff slots for DCF occur during the BTI, the A-
BFT, the ATI, and non-CBAP portions of the DTI.
A STA performing the backoff procedure shall use the CS mechanism (see 10.3.2.1) to determine whether
there is activity during each backoff slot. If no medium activity is indicated for the duration of a particular
backoff slot, then the backoff procedure shall decrement its backoff timer by aSlotTime.
1325
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 10-15—Backoff procedure
If the medium is determined to be busy at any time during a backoff slot, then the backoff procedure is
suspended; that is, the backoff timer shall not decrement for that slot. The medium shall be determined to be
idle for the duration of a DIFS or EIFS, as appropriate (see 10.3.2.3), before the backoff procedure is allowed
to resume. Transmission shall commence when the backoff timer reaches 0.
A backoff procedure shall be performed immediately after the end of every transmission with the More
Fragments bit equal to 0 of an MPDU with the Type subfield equal to Data, Management, or Control with
subtype PS-Poll, even if no additional transmissions are currently queued. In the case of successful
acknowledged transmissions, this backoff procedure shall begin at the end of the received Ack frame. In the
case of unsuccessful transmissions requiring acknowledgment, this backoff procedure shall begin at the end of
the AckTimeout interval (as defined in 10.3.2.9). An unsuccessful transmission is one where an Ack frame is
not received from the STA addressed by the RA field of the transmitted frame and the value of the RA field
is an individual address. If the transmission is successful, the CW value reverts to aCWmin before the random
backoff interval is chosen, and the SSRC and/or SLRC are updated as described in 10.3.3. The result of this
procedure is that transmitted frames from a STA are always separated by at least one backoff interval.
The effect of this procedure is that when multiple STAs are deferring and go into random backoff, then the
STA selecting the smallest backoff time using the random function wins the contention (assuming all of the
contending STAs detect the same instances of WM activity at their respective receivers, a situation that is not
always true, due to hidden node effects and interference events). The number of DMG STAs that are able to
detect each WM transmission is reduced even further due to SPSH.
In an IBSS the backoff timer for a pending non-Beacon or non-ATIM transmission shall not decrement in the
period from the TBTT until the expiration of the ATIM window, and the backoff timer for a pending ATIM
frame shall decrement only within the ATIM window. (See Clause 11.) Within an IBSS a separate backoff
interval shall be generated to precede the transmission of a Beacon frame, as described in 11.1.3.5.
At the start of an awake window, a DMG STA shall suspend decrementing its backoff timer(s) for any
transmission of non-ATIM frames for the duration of the awake window as indicated in the most recently
received Awake Window element. At the end of the awake window, the DMG STA shall resume the backoff
timer(s) for non-ATIM frames. A DMG STA shall not decrement the backoff timer for a pending ATIM
frame outside the awake window.
Figure 10-17 describes the backoff procedure for DMG STAs for the example topology shown in
Figure 10-16.
1326
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA C
STA A STA E
STA B
STA D
Figure 10-16—Example topology of NAV setting in DMG STAs
DIFS
A
Frame to STA E Backoff
STA A
Ack to STA D
Virtual
Backoff
CS=busy
STA B
RTS to STA B RTS to STA B
CS=
Backoff Backoff
busy
STA C
End of DMG CTS
DIFS
timeout DIFS
Data to STA B Backoff
STA D
Backoff
STA E
Response to STA A
Figure 10-17—Backoff procedure for DMG STAs
At the time that STA A starts transmitting a frame to STA E and STA E starts receiving the frame, the
antennas of both stations are directed to the peer, i.e., the transmitting antennas of STA A are directed to
STA E and the receiving antennas of STA E are directed to STA A. At this point, STA B, STA C, and STA
D are not involved in any frame exchange; therefore, they are in receiving state and happen to have the
configuration of their receiving antenna arrays set to a quasi-omni antenna pattern to be ready to receive
frames from any STA.
STA B receives the frame transmitted by STA A (to STA E), and CS (physical and virtual) in STA B
indicates a busy medium during the exchange between STA A and STA E.
STA D is not able to receive the frame transmitted by STA A or the response transmitted by STA E; hence
CS in STA D indicates IDLE for the duration of the exchange between STA A and STA E.
1327
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The physical CS function of STA C indicates a medium busy condition when it receives the response sent by
STA E, but indicates an idle medium condition during the transmission from STA A.
STA A and STA E (which are directly involved in the frame exchange), STA B (which received the frame
sent by STA A), and STA C (which received the response sent by STA E) are synchronized at point A,
where the transaction between STA A and STA E completes.
Since STA D cannot hear the directional transmissions from either STA A or STA C, its physical CS
indicates an idle medium condition for the duration of the frame exchange, enabling a frame exchange with
STA B at the same time as the frame exchange between STA A and STA E. This is an example of SPSH.
Because STA C is unaware of the transmission of the frame from STA A to STA E, STA C transmits an
RTS to STA B. But STA C does not receive a DMG CTS from STA B since the CS at STA B is busy when
STA B receives the RTS from the STA C. This causes STA C to retry the RTS transmission following the
expiration of a backoff count, which occurs after the completion of the exchange between STA A and
STA E.
10.3.4.4 Recovery procedures and retransmit limits
Under DCF, error recovery is always the responsibility of the STA that initiates a frame exchange sequence
(described in Annex G). Many circumstances may cause an error to occur that requires recovery. For example,
the CTS frame might not be returned after an RTS frame is transmitted. This may happen due to a collision
with another transmission, due to interference in the channel during the RTS or CTS frame, or because the STA
receiving the RTS frame has an active virtual CS condition (indicating a busy medium time period).
Error recovery shall be attempted by retrying transmissions for frame exchange sequences that the initiating
STA infers have failed. Retries shall continue, for each failing frame exchange sequence, until the transmission
is successful, or until the relevant retry limit is reached, whichever occurs first. A STA shall maintain a SRC
and an LRC for each MSDU or MMPDU awaiting transmission. These counts are incremented and reset
independently of each other.
After an RTS frame is transmitted, the STA shall perform the CTS procedure, as defined in 10.3.2.7. If the RTS
frame transmission fails, the SRC for the MSDU or MMPDU and the SSRC are incremented. This process
shall continue until the number of attempts to transmit that MSDU or MMPDU reaches dot11ShortRetryLimit.
After transmitting a frame that requires acknowledgment, the STA shall perform the acknowledgment
procedure, as defined in 10.3.2.9. The SRC for an MPDU with the Type subfield equal to Data or Management
and of length less than or equal to dot11RTSThreshold and the SSRC shall be incremented every time
transmission that MPDU fails. This SRC and the SSRC shall be reset when transmission of that MPDU
succeeds. The LRC for an MPDU with the Type subfield equal to Data or Management and of length greater
than dot11RTSThreshold and the SLRC shall be incremented every time transmission of that MPDU fails. This
LRC and the SLRC shall be reset when transmission of that MPDU succeeds. All retransmission attempts for
an MPDU with the Type subfield equal to Data or Management that has failed the acknowledgment procedure
one or more times shall be made with the Retry subfield set to 1.
Retries for failed transmission attempts shall continue until the SRC for the MPDU with the Type subfield
equal to Data or Management is equal to dot11ShortRetryLimit or until the LRC for the MPDU with the Type
subfield equal to Data or Management is equal to dot11LongRetryLimit. When either of these limits is
reached, retry attempts shall cease, and the MPDU with the Type subfield Data (and any MSDU of which it is
a part) or Management shall be discarded. A DMG STA, in addition to using random access within a CBAP,
may transmit retries in available scheduled SPs.
A STA in PS mode, in an infrastructure BSS, initiates a frame exchange sequence by transmitting a PS-Poll
frame to request data from an AP. If no Ack, Data, or Management frame is received from the AP in response
1328
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
to a PS-Poll frame, then the STA shall retry the sequence, by transmitting another PS-Poll frame. If the AP
sends a Data or Management frame in response to a PS-Poll frame, but fails to receive the Ack frame
acknowledging this Data or Management frame, the next PS-Poll frame from the same STA may cause a
retransmission of the last MSDU 28. If the AP responds to a PS-Poll frame by transmitting an Ack frame, then
responsibility for the Data or Management frame delivery error recovery shifts to the AP because the data are
transferred in a subsequent frame exchange sequence, which is initiated by the AP. The AP shall attempt to
deliver one buffered BU to the STA that transmitted the PS-Poll frame, using any frame exchange sequence
valid for an individually addressed BU. If the PS STA that transmitted the PS-Poll frame returns to doze state
after transmitting the Ack frame in response to successful receipt of this BU, but the AP fails to receive this
Ack frame, then the AP retries transmission of this BU until the relevant retry limit is reached. See 11.2.3.8 for
details on filtering of extra PS-Poll frames.
An AP that fails to receive an acknowledgment after the AP transmits a frame with the More Data subfield
set to 0 to a non-AP VHT STA that is in TXOP power save mode retransmits the frame within the current
TXOP under certain conditions as described in 11.2.3.19.
10.3.4.5 Control of the channel
The SIFS is used to provide an efficient MSDU delivery mechanism. Once the STA has contended for the
channel, that STA shall continue to send fragments until either all fragments of a single MSDU or MMPDU
have been sent or an acknowledgment is not received. Should the sending of the fragments be interrupted due
to one of these reasons, when the next opportunity for transmission occurs the STA shall resume transmission.
The algorithm by which the STA decides which of the outstanding MSDUs shall next be attempted after an
unsuccessful transmission (as defined in 10.3.4.3) attempt is beyond the scope of this standard, but any such
algorithm shall comply with the restrictions listed in 10.8.
Figure 10-18 illustrates the transmission of a multiple-fragment MSDU using the SIFS.
Figure 10-18—Transmission of a multiple-fragment MSDU using SIFS
When the source STA transmits a fragment, it shall release the channel, then immediately monitor the channel
for an acknowledgment as described in 10.3.2.9.
When the destination STA has finished sending the acknowledgment, the SIFS following the acknowledgment
shall be reserved for the source STA to continue (if necessary) with another fragment. The STA sending the
acknowledgment shall not transmit on the channel immediately following the acknowledgment.
The process of sending multiple fragments after contending for the channel is defined as a fragment burst.
If the source STA does not receive an acknowledgment frame, it shall attempt to retransmit the failed MPDU or
another eligible MPDU, as defined in 10.8, after performing the backoff procedure and the contention process.
28
This duplicate MSDU is filtered at the receiving STA using the duplicate frame filtering mechanism.
1329
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
After a STA contends for the channel to retransmit a fragment of an MSDU, it shall start with the last fragment
that was not acknowledged. The destination STA shall receive the fragments in order (because the source sends
them in order and they are individually acknowledged). It is possible, however, that the destination STA may
receive duplicate fragments. It shall be the responsibility of the receiving STA to detect and discard duplicate
fragments.
A STA shall transmit after the SIFS only under the following conditions during a fragment burst:
— The STA has just received a fragment that requires acknowledgment.
— The source STA has received an acknowledgment for a previous fragment and has more fragment(s)
for the same MSDU to transmit.
The following rules shall also apply:
— When a STA has transmitted a frame other than an initial or intermediate fragment, that STA shall
not transmit on the channel following the acknowledgment for that frame, without performing the
backoff procedure.
— When an MSDU has been successfully delivered or all retransmission attempts have been
exhausted, and the STA has a subsequent MSDU to transmit, then that STA shall perform a backoff
procedure.
10.3.5 Individually addressed MPDU transfer procedure
A STA using the DCF shall use an RTS/CTS exchange for individually addressed frames when the length of
the PSDU is greater than the length threshold indicated by dot11RTSThreshold. A STA may also use an RTS/
CTS exchange for individually addressed frames when it is necessary to distribute the NAV or when it is
necessary to establish protection (see 10.26). Otherwise a STA using the DCF shall not use the RTS/CTS
exchange.
If dot11RTSThreshold is 0, all MPDUs shall be delivered with the use of RTS/CTS. If dot11RTSThreshold is
larger than the maximum PSDU length, all PSDUs shall be delivered without RTS/CTS exchanges.
When an RTS/CTS exchange is used, the PPDU containing the PSDU shall be transmitted starting one SIFS
after the end of the CTS frame.
NOTE—No regard is given to the busy or idle status of the medium when transmitting this PSDU.
When an RTS/CTS exchange is not used, the PSDU shall be transmitted following the success of the basic
access procedure. With or without the use of the RTS/CTS exchange procedure, the STA that is the destination
of a Data frame shall follow the acknowledgment procedure.
10.3.6 Group addressed MPDU transfer procedure
When a STA transmits group addressed MPDUs in which the To DS subfield is 0, the STA shall use the basic
access procedure, unless these MPDUs are delivered using PCF or using the group addressed transmission
service (GATS). When GATS is not used to deliver group addressed MPDUs, the STA shall not use an RTS/
CTS or RTS/DMG CTS exchange, regardless of the length of the frame. In addition, no recipient of the frame
shall transmit an Ack frame. A STA that transmits a group addressed MPDU in which the To DS subfield is 1
shall, in addition to complying with the basic access procedure of CSMA/CA, obey the rules for RTS/CTS
exchange and the acknowledgment procedure because the MPDU is directed to the AP. For DMG STAs, the
MPDU transmission shall also comply with the access procedures defined in 10.36.
There is no MAC-level recovery on group addressed frames, except for the following:
— Frames in which the To DS subfield is 1
— Group addressed frames transmitted via the GATS
1330
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
As a result, the reliability of this traffic is reduced, relative to the reliability of individually addressed traffic,
due to the increased probability of lost frames from interference, collisions, or time-varying channel properties.
A DMG STA may transmit a copy of the same group addressed MPDU using different antenna configurations.
This might be needed to provide a quasi-omni coverage or to enable transmission by an MCS that is higher
than MCS 0. If multiple copies of a group addressed MPDU with a To DS subfield equal to 0 are transmitted,
the STA shall not transmit a different frame before the completion of the transmission of all copies of the group
addressed MPDU.
NOTE—The following paragraph addresses the Dual CTS protection mechanism. The use of the Dual CTS protection
mechanism is deprecated.
An STBC-capable STA shall discard either all received group addressed Data frames that are STBC frames or
all received group addressed Data frames that are non-STBC frames. How it makes this decision is outside the
scope of this standard.
A STA shall discard an MPDU with a group address in the Address 1 field if the value in the Address 1 field
does not match any value in the dot11GroupAddressesTable and does not match the Broadcast address value.
10.3.7 DCF timing relations
The IFSs are periods of time on the medium. The attributes of the IFSs are determined by the specific PHY (see
Figure 10-19). The IFSs apply to transmission under EDCA, too (see Figure 10-25).
DIFS
PIFS
aSIFSTime aSlotTime First backoff slot
Medium busy
D1 Rx/Tx
M1 D2 D2 D2
CCAdel CCAdel CCAdel
M2 M2 M2
PHY‐RXEND.indication
Rx/Tx Rx/Tx Rx/Tx
aSlotTime aSlotTime aSlotTime
MAC slot TxSIFS TxPIFS TxDIFS First backoff
boundaries slot boundary slot boundary slot boundary slot boundary
D1 = aRxPHYDelay (referenced from the end of the last symbol of a PPDU on the medium)
D2 = D1 + aAirPropagationTime
Rx/Tx = aRxTxTurnaroundTime (begins with a PHY‐TXSTART.request)
M1 = M2 = aMACProcessingDelay
CCAdel = aCCATime – D1
Figure 10-19—DCF timing relationships
All medium timings that are referenced from the end of the transmission are referenced from the end of the last
symbol, or signal extension if present, of the PPDU. The beginning of transmission refers to the first symbol of
the preamble of the next PPDU. All MAC timings are referenced from the PHY-TXEND.confirm, PHY-
TXSTART.confirm, PHY-RXSTART.indication, and PHY-RXEND.indication primitives.
aSIFSTime and aSlotTime are determined per PHY, aSIFSTime is fixed, and aSlotTime can change
dynamically as aAirPropagationTime changes (see 10.21.5).
1331
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The STA may employ any non-negative value for each of the parameters:
— aRxPHYDelay
— aMACProcessingDelay
— aTxPHYDelay
— aTxRampOnTime
— aCCATime
— aRxTxSwitchTime
provided that the constraints in Equation (10-2), Equation (10-3), and Equation (10-4) are met, and provided
that the CCA sensitivity specification for the attached PHY is met (see 15.4.6.5, 16.3.8.5, 17.3.10.6, 18.4.6 and
19.3.19.5, 20.4.4.2.2, 20.6.4.2.2, 21.3.18.5, and 22.3.18.6).
aSIFSTime = aRxPHYDelay + aMACProcessingDelay +
aRxTxTurnaroundTime (10-2)
aSlotTime = aCCATime + aMACProcessingDelay + aRxTxTurnaroundTime +
aAirPropagationTime (10-3)
aRxTxTurnaroundTime = aTxPHYDelay + aRxTxSwitchTime + aTxRampOnTime (10-4)
where
aAirPropagationTime is determined as described in 10.21.5
aSlotTime, aSIFSTime and aRxTxTurnaroundTime are the values indicated in the PLME-CHARACTER-
ISTICS.confirm primitive
the other attribute values are the values implemented
The PIFS and DIFS are derived by the Equation (10-5) and Equation (10-6), as illustrated in Figure 10-19.
PIFS = aSIFSTime + aSlotTime (10-5)
DIFS = aSIFSTime + 2 aSlotTime (10-6)
When dot11DynamicEIFSActivated is false or not defined, the EIFS is derived from the SIFS and the DIFS
and the length of time it takes to transmit an Ack frame at the lowest PHY mandatory rate by Equation (10-7).
EIFS = aSIFSTime + AckTxTime + DIFS (10-7)
where
AckTxTime is the time expressed in microseconds required to transmit an Ack frame, including
preamble, PHY header and any additional PHY dependent information, at the lowest PHY
mandatory rate.
When dot11DynamicEIFSActivated is true, EIFS is based on an estimated duration of the PPDU that is the
possible response to the PPDU that causes the EIFS.
When dot11DynamicEIFSActivated is true, if the PPDU that causes the EIFS does not contain a single MPDU
with a length equal to 14 or 32 octets, and the modulation of the PPDU that causes the EIFS is included in
Table 10-5, then EIFS is determined as shown in Equation (10-8).
1332
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
EIFS = aSIFSTime + EstimatedAckTxTime + DIFS (10-8)
where
EstimatedAckTxTime is based on an estimated duration of the PPDU that is the possible response to the
PPDU that causes the EIFS, as specified in Table 10-5.
Table 10-5—Determination of the EstimatedAckTxTime based on properties of the PPDU
causing the EIFS
Modulation of Other properties Presumed
Rate/MCS of PPDU Presumed EstimatedAck
PPDU causing of PPDU causing response
causing EIFS response TxTime (µs)
EIFS EIFS rate
(HR-)DSSS 1 Mb/s Ack 1 Mb/s 304
(HR-)DSSS ≥ 2 Mb/s (long Ack 2 Mb/s 248
preamble)
(HR-)DSSS ≥ 2 Mb/s (short Ack 2 Mb/s 152
preamble)
(ERP-)OFDM BPSK Ack 6 Mb/s 44
(ERP-)OFDM QPSK Ack 12 Mb/s 32
(ERP-)OFDM ≥16-QAM Ack 24 Mb/s 28
HT BPSK Aggregation = 0 Ack 6 Mb/s 44
HT QPSK Aggregation = 0 Ack 12 Mb/s 32
HT ≥16-QAM Aggregation = 0 Ack 24 Mb/s 28
HT BPSK Aggregation = 1 BlockAck 6 Mb/s 68
HT QPSK Aggregation = 1 BlockAck 12 Mb/s 44
HT ≥16-QAM Aggregation = 1 BlockAck 24 Mb/s 32
VHT BPSK BlockAck 68
VHT QPSK BlockAck 44
VHT ≥16-QAM BlockAck 32
When dot11DynamicEIFSActivated is true and the PPDU that causes the EIFS contains a single MPDU with a
length equal to 14 or 32 octets, EIFS is equal to DIFS. This reflects the fact that a 14 or 32 octet MPDU is very
likely an Ack or a BlockAck frame, which does not cause a response PPDU to be transmitted.
When dot11DynamicEIFSActivated is true and the modulation of the PPDU that causes the EIFS does not
occur in Table 10-5, then EIFS is determined as shown in Equation (10-7).
Figure 10-19 illustrates the relation between the SIFS, PIFS, and DIFS as they are measured on the medium
and the different MAC slot boundaries TxSIFS, TxPIFS, and TxDIFS. These slot boundaries define when the
transmitter shall be turned on by the MAC to meet the different IFS timings on the medium, after subsequent
detection of the CCA result of the previous slot time.
1333
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Equation (10-9), Equation (10-10) and Equation (10-11) define the MAC slot boundaries using attributes
provided by the PHY, which are such that they compensate for implementation timing variations. The starting
reference of these slot boundaries is again the end of the last symbol of the previous PPDU.
TxSIFS = SIFS – aRxTxTurnaroundTime (10-9)
TxPIFS = TxSIFS + aSlotTime (10-10)
TxDIFS = TxSIFS + 2 aSlotTime (10-11)
NOTE—The tolerance for SIFS is defined in 10.3.2.3.3.
10.3.8 Signal extension
Transmissions of frames with TXVECTOR parameter FORMAT of type NON_HT with
NON_HT_MODULATION values of ERP-OFDM and NON_HT_DUP_OFDM and transmissions of frames
with TXVECTOR parameter FORMAT with values of HT_MF and HT_GF include a period of no
transmission of duration aSignalExtension, except for RIFS transmissions. The purpose of this signal extension
is to enable the NAV value of Clause 16 STAs to be set correctly.
When an HT STA transmits a PPDU using a RIFS and with the TXVECTOR parameter FORMAT equal to
NON_HT with the NON_HT_MODULATION parameter equal to one of ERP-OFDM and
NON_HT_DUP_OFDM or a PPDU using a RIFS and with the TXVECTOR parameter FORMAT equal to
HT_MF or HT_GF, it shall set the TXVECTOR parameter NO_SIG_EXTN to true. Otherwise, it shall set the
TXVECTOR parameter NO_SIG_EXTN to false.
10.3.9 Determination of PLME aCWmin characteristics
In the case of the Clause 18 ERP, the aCWmin value is dependent on the requester’s characteristic rate set. The
characteristic rate set is equal to the IBSS’s basic rate set when the STA is operating as a member of an IBSS.
It is equal to the AP’s operational rate set when the STA is associated with an AP. At all other times, it is equal
to the STA’s mandatory rate set. The MAC variable aCWmin is set to aCWmin(0) if the characteristic rate set
includes only rates in the set 1, 2, 5.5, 11; otherwise, aCWmin is set to aCWmin(1). If the returned value for
aCWmin is a scalar, then the MAC always sets the variable aCWmin to the returned scalar value of aCWmin.
10.4 PCF
10.4.1 General
The PCF mechanism is obsolete. Consequently, this subclause might be removed in a later revision of the
standard.
The PCF provides CF frame transfer. It is an option for an AP to be able to become the PC. A non-AP STA
shall not become a PC. All STAs inherently obey the medium access rules of the PCF, because these rules are
based on the DCF, and all STAs set their NAV at the beginning of each CFP. The operating characteristics of
the PCF are such that all STAs are able to operate in the presence of a BSS in which a PC is operating, and, if
associated with a point-coordinated BSS, are able to receive frames sent under PCF control. It is also an option
for a STA to be able to respond to a CF-Poll received from a PC. A STA that is able to respond to CF-Polls is
referred to as being CF-Pollable and may request to be polled by an active PC. CF-Pollable STAs and the PC
do not use RTS/CTS in the CFP. When polled by the PC, a CF-Pollable STA may transmit only one MPDU,
which might be sent to the PC but may have any destination, and may “piggyback” the acknowledgment of a
frame received from the PC using particular data frame subtypes for this transmission. If the Data frame is not
in turn acknowledged, the CF-Pollable STA shall not retransmit the frame unless it is polled again by the PC,
or it decides to retransmit during the CP. If the addressed recipient of a CF transmission is not CF-Pollable, that
1334
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA acknowledges the transmission using the DCF acknowledgment rules, and the PC retains control of the
medium. A PC may use CF frame transfer solely for delivery of frames to STAs, and never to poll CF-Pollable
STAs.
A PC may perform a backoff on retransmission of an unacknowledged frame during the CFP. A PC that is
maintaining a polling list may retry the unacknowledged frame the next time the particular AID is at the top of
the polling list.
A PC may retransmit an unacknowledged frame during the CFP after a PIFS.
When more than one point-coordinated BSS is operating on the same PHY channel in overlapping space, the
potential exists for collisions between PCF transfer activities by the independent PCs. The rules under which
multiple, overlapping point-coordinated BSSs may coexist are presented in 10.4.4.3. As shown in Figure 10-1
(in 10.2), the PCF is built on top of the CSMA/CA-based DCF, by utilizing the access priority provisions
provided by this scheme. An active PC shall be located at an AP, which restricts PCF operation to
infrastructure networks. PCF is activated at a PC-capable AP by setting the CFPMaxDuration parameter in the
CF Parameter Set of the MLME-START.request primitive to a nonzero value.
Data frames sent by, or in response to polling by, the PC during the CFP shall use the appropriate data subtypes
based upon the following usage rules:
— Data +CF-Poll, Data +CF-Ack +CF-Poll, CF-Poll, and CF-Ack +CF-Poll shall be sent only by a PC.
— Data, Data +CF-Ack, Null Function, and CF-Ack may be sent by a PC or by any CF-Pollable STA.
A STA receiving Data frames shall consider the frame body as the basis of a possible indication to LLC only if
the frame is of subtype Data, Data +CF-Ack, Data +CF-Poll, or Data +CF-Ack +CF-Poll. A CF-Pollable STA
shall interpret all subtype bits of received Data type frames that contain the BSSID of the current BSS for CF
purposes, but shall not inspect the frame body unless the frame is of subtype Data, Data +CF-Ack, Data +CF-
Poll, or Data +CF-Ack +CF-Poll.
10.4.2 CFP structure and timing
The PCF controls frame transfers during a CFP. The CFP shall alternate with a CP, when the DCF controls
frame transfers, as shown in Figure 10-20. Each CFP shall begin with a Beacon frame that contains a DTIM
element (referred to as DTIM Beacon frame). The CFPs shall occur at a defined repetition rate, which shall be
synchronized with the beacon interval as specified in the following paragraphs.
Figure 10-20—CFP/CP alternation
The PC generates CFPs at the CFP repetition interval (CFPPeriod), which is defined as a number of DTIM
intervals. The PC shall determine the CFPPeriod (depicted as a repetition interval in the illustrations in
Figure 10-20 and Figure 10-21) to use from dot11CFPPeriod. This value, in units of DTIM intervals, shall be
communicated to other STAs in the BSS in the CFPPeriod field of the CF Parameter Set element of Beacon
1335
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
frames. The CF Parameter Set element shall be present only in Beacon and Probe Response frames transmitted
by STAs containing an active PC.
Figure 10-21—Beacon frames and CFPs
The length of the CFP is controlled by the PC, with maximum duration specified by dot11CFPMaxDuration.
Neither the maximum duration nor the actual duration (signaled by transmission of a Control frame of subtype
CF-End or CF-End +CF-Ack by the PC) is constrained to be a multiple of the beacon interval. If the CFP
duration is greater than the beacon interval, the PC shall transmit Beacon frames at the appropriate times
during the CFP (subject to delay due to traffic at the nominal times, as with all Beacon frames). The CF
Parameter Set element in all Beacon frames at the start of, or within, a CFP shall contain a nonzero value in the
CFPDurRemaining field. This value, in units of TU, shall specify the maximum time from the most recent
TBTT to the end of this CFP. The value of the CFPDurRemaining field shall be 0 in Beacon frames sent during
the CP. An example of these relationships is illustrated in Figure 10-21, which shows a case where the
CFPPeriod is two DTIM intervals, the DTIM interval is three beacon intervals, and the aCFPMaxDuration
value is approximately 2.5 beacon intervals.
The PC may terminate any CFP at or before the limit given by dot11CFPMaxDuration, based on available
traffic and size of the polling list. Because the transmission of any Beacon frame may be delayed due to a
medium busy condition at the TBTT, a CFP may be shortened by the amount of the delay. In the case of a busy
medium due to DCF traffic, the Beacon frame shall be delayed for the time required to complete the current
DCF frame exchange. When the Beacon frame transmission is delayed, the CFPDurRemaining value in the
Beacon frame at the beginning of the CFP shall specify a time that causes the CFP to end no later than TBTT
plus the value of aCFPMaxDuration. This is illustrated in Figure 10-22.
Target Beacon Transmission Time
dot11CFPMaxDuration
Beacon frame
DCF Traffic Contention Period
Nominal CF repetition interval
(shortened)
Contention-Free Period
Max RTS + CTS +
MPDU + Ack time
Figure 10-22—Example of delayed beacon and shortened CFP
1336
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.4.3 PCF access procedure
10.4.3.1 General
The CF transfer protocol is based on a polling scheme controlled by a PC operating at the AP of the BSS. The
PC gains control of the medium at the beginning of the CFP and attempts to maintain control for the entire CFP
by waiting a shorter time between transmissions than the STAs using the DCF access procedure. All STAs that
receive Beacon frames containing a CF Parameter Set element, including STAs not associated with the BSS,
set their NAVs to the CFPMaxDuration value at the nominal start time of each CFP. This prevents most
contention by preventing nonpolled transmissions by STAs regardless of whether they are CF-Pollable.
Acknowledgment of frames sent during the CFP may be accomplished using Data +CF-Ack, CF-Ack, Data
+CF-Ack +CF-Poll (only on frames transmitted by the PC), or CF-Ack +CF-Poll (only on frames transmitted
by the PC) frames when a Data (or Null) frame immediately follows the frame being acknowledged, thereby
avoiding the overhead of separate Ack frames. Non-CF-Pollable or unpolled CF-Pollable STAs acknowledge
frames during the CFP using the DCF acknowledgment procedure.
10.4.3.2 Fundamental access
At the nominal beginning of each CFP, the PC shall sense the medium. When the medium is determined to be
idle for one PIFS, the PC shall transmit a Beacon frame containing the CF Parameter Set element and a DTIM
element.
After the initial Beacon frame, the PC shall wait for one SIFS, and then transmit one of the following: a Data
frame, a CF-Poll frame, a Data +CF-Poll frame, a Management frame, or a CF-End frame. If the CFP is null,
i.e., no traffic is buffered and no polls exist to send at the PC, a CF-End frame shall be transmitted immediately
after the initial Beacon frame. If there are non-GCR-SP buffered group addressed MSDUs/MMPDUs, the PC
shall transmit these prior to any individually addressed MSDUs/MMPDUs.
STAs receiving individually addressed, error-free frames from the PC are expected to respond after a SIFS, in
accordance with the transfer procedures defined in 10.4.4. If the recipient STA is not CF-Pollable, the response
to receipt of an error-free Data frame shall be an Ack frame.
10.4.3.3 NAV operation during the CFP
The mechanism for handling the NAV during the CFP is designed to facilitate the operation of overlapping
CFP coordinated infrastructure BSSs. The mechanism by which infrastructure BSSs coordinate their CFPs is
beyond the scope of this standard.
Each STA, except the STA with the PC, shall preset its NAV to the CFPMaxDuration value (obtained from the
CF Parameter Set element in Beacon frames from this PC) at each TBTT (see Clause 11) at which a CFP is
scheduled to start (based on the CFPCount field in the CF Parameter Set element of the Beacon frames from
this PC). Each non-PC STA shall update its NAV using the CFPDurRemaining value in the CF Parameter Set
element of any error-free Beacon frame that the STA receives. This includes CFPDurRemaining values in CF
Parameter Set elements from Beacon frames received from other (overlapping) BSSs.
These actions prevent STAs from taking control of the medium during the CFP, which is especially important
when the CFP spans multiple medium-occupancy intervals. This setting of the NAV also reduces the risk of
hidden STAs determining the medium to be idle for a DIFS during the CFP and possibly corrupting a
transmission in progress.
A STA joining a BSS operating with a PC shall use the information in the CFPDurRemaining element of the
CF parameter set of any received Beacon or Probe Response frames to update its NAV prior to initiating any
transmissions.
1337
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PC shall transmit a CF-End or CF-End +CF-Ack frame at the end of each CFP. A STA that receives either
of these frames, from any BSS, shall reset its NAV.
10.4.4 PCF transfer procedure
10.4.4.1 General
Frame transfers under the PCF may consist of frames alternately sent from the AP/PC and sent to the AP/PC.
During the CFP, the ordering of these transmissions, and the STA allowed to transmit frames to the PC at any
given point in time, shall be controlled by the PC. Figure 10-23 depicts frame transfer during a typical CFP.
The rules under which this frame transfer takes place are detailed in 10.4.4.2 to 10.4.4.5.
Figure 10-23—Example of PCF frame transfer
MaxMPDUTime is the time to transmit the maximum-sized MAC frame, expanded by security mechanisms,
plus the time to transmit the PHY preamble, header, trailer, and expansion bits, if any.
10.4.4.2 PCF transfers when the PC STA is transmitter or recipient
The PC shall transmit frames between the Beacon frame that starts the CFP and the CF-End frame using the
SIFS except when a transmission by another STA is expected by the PC and a SIFS elapses without the receipt
of the expected transmission. In such cases the PC may send its next pending transmission as soon as one PIFS
after the end of its last transmission. This permits the PC to retain control of the medium in the presence of an
overlapping BSS. The PC may transmit any of the following frame types to CF-Pollable STAs:
— Data, used to send data from the PC when the addressed recipient is not being polled and there is no
previous frame to acknowledge;
— Data +CF-Ack, used to send data from the PC when the addressed recipient is not being polled or is
not CF-Pollable or the DA is a group address and the PC needs to acknowledge the receipt of a
frame received from a CF-Pollable STA a SIFS before starting this transmission;
— Data +CF-Poll, used to send data from the PC when the addressed recipient is the next STA to be
permitted to transmit during this CFP and there is no previous frame to acknowledge;
— Data +CF-Ack +CF-Poll, used to send data from the PC when the addressed recipient is the next
STA to be permitted to transmit during this CFP and the PC needs to acknowledge the receipt of a
frame received from a CF-Pollable STA a SIFS before starting this transmission;
— CF-Poll, used when the PC is not sending data to the addressed recipient but the addressed recipient
is the next STA to be permitted to transmit during this CFP and there is no previous frame to
acknowledge;
1338
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— CF-Ack +CF-Poll, used when the PC is not sending data to the addressed recipient but the addressed
recipient is the next STA to be permitted to transmit during this CFP and the PC needs to
acknowledge the receipt of a frame from a CF-Pollable STA a SIFS before starting this
transmission;
— CF-Ack, used when the PC is not sending data to, or polling, the addressed recipient, but the PC
needs to acknowledge receipt of a frame from a CF-Pollable STA a SIFS before starting this
transmission (useful when the next transmission by the PC is a Management frame, such as a Beacon
frame); or
— Any Management frame that is appropriate for the AP to send under the rules for that frame type.
The PC may transmit Data or Management frames to a non-CF-Pollable, non-PS STA during the CFP. This
STA shall acknowledge receipt with Ack frames after a SIFS, as with the DCF. The PC may also transmit
group addressed frames during the CFP. Because the Beacon frame that initiates the CFP contains a DTIM
element, if there are associated STAs using PS mode, the buffered group addressed frames that are not
delivered via the GCR-SP delivery method shall be sent immediately after any Beacon frame that contains a
TIM element whose DTIM Count field is 0.
A CF-Pollable STA that receives an individually addressed Data frame of any subtype that includes CF-Poll
may transmit one Data frame a SIFS after receiving the CF-Poll.
NOTE—A CF-Pollable STA ignores and does not reset its NAV when performing transmissions in response to a CF-
Poll.
Non-CF-Pollable STAs that receive an individually addressed frame during the CFP shall transmit an Ack
frame, but shall not reset their NAV.
For frames that require MAC-level acknowledgment, CF-Pollable STAs that received a CF-Poll (of any type)
may perform this acknowledgment using the Data +CF-Ack subtype in the response to the CF-Poll. For
example, the U1 frame in Figure 10-23 contains the acknowledgment to the preceding D1 frame. The D2 frame
contains the acknowledgment to the preceding U1 frame. The PC may use the CF-Ack subtypes to
acknowledge a received frame even if the Data frame sent with the CF-Ack subtype is addressed to a different
STA than the one being acknowledged. CF-Pollable STAs that are expecting an acknowledgment shall
interpret the subtype of the frame (if any) sent by the PC a SIFS after that STA’s transmission to the PC. If a
frame that requires MAC-level acknowledgment is received by a non-CF-Pollable STA, that STA shall not
interpret the CF-Poll indication (if any), and shall acknowledge the frame by sending an Ack frame after a
SIFS.
The lengths of the frames may be variable, only bounded by the frame and/or fragment length limitations that
apply for the BSS. If a CF-Pollable STA does not respond to a CF-Poll (of any type) within the SIFS following
a transmission from the PC, or a non-CF-Pollable STA does not return the Ack frame within a SIFS following
a transmission from the PC that requires acknowledgment, then the PC shall resume control and may transmit
its next frame after a PIFS from the end of the PC’s last transmission.
A CF-Pollable STA shall respond to a frame with any data subtype that includes CF-Poll directed to its MAC
address and received without error. If the STA has no frame to send when polled, the response shall be a Null
frame. If the STA has no frame to send when polled, but an acknowledgment is required for the frame that
conveyed the CF-Poll, the response shall be a CF-Ack (no data) frame. The null response is required to permit
a “no-traffic” situation to be distinguished from a collision between overlapping PCs.
The CFP shall end when the CFPDurRemaining time has elapsed since the Beacon frame originating the CFP
or when the PC has no further frames to transmit nor STAs to poll. In either case, the end of the CFP shall be
signaled by the transmission of a CF-End frame by the PC. If there is a received frame that requires
acknowledgment at the time the CF-End frame is to be transmitted, the PC shall transmit a CF-End +CF-Ack
frame instead. A STA receiving a CF-End frame or CF-End +CF-Ack frame shall reset its NAV.
1339
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.4.4.3 Operation with overlapping point-coordinated BSSs
Because the PCF operates without the CSMA/CA CW randomization and backoff of the DCF, there is a risk of
repeated collisions if multiple, overlapping, point-coordinated BSSs are operating on the same PHY channel,
and their CFP Rates and beacon intervals are approximately equal. To minimize the risk of significant frame
loss due to CF collisions, the PC shall use a DIFS plus a random backoff delay (with CW in the range 1 to
aCWmin) to start a CFP when the initial Beacon frame is delayed because of deferral due to a busy medium.
The PC may use this backoff during the CFP prior to retransmitting an unacknowledged, individually
addressed Data or Management frame.
To further reduce the susceptibility to inter-PC collisions, the PC shall require that the medium be determined
as being idle for a DIFS plus a random (over a range of 1 to aCWmin) number of slot times once every
dot11MediumOccupancyLimit TU during the CFP. This results in loss of control of the medium to overlapping
BSS or hidden STA traffic, because the STAs in this BSS are prevented from transmitting by their NAV setting
to CFPMaxDuration or CFPDurRemaining. dot11MediumOccupancyLimit may be set equal to
CFPMaxDuration, which provides no protection against PCF collisions. The dot11MediumOccupancyLimit is
also useful for compliance in regulatory domains that impose limits on continuous transmission time by a
single STA as part of a spectrum etiquette.
10.4.4.4 CFPMaxDuration limit
The value of CFPMaxDuration shall be limited to allow coexistence between contention and CF traffic.
The minimum value for CFPMaxDuration is two times MaxMPDUTime plus the time required to send the
initial Beacon frame and the CF-End frame of the CFP. This may allow sufficient time for the AP to send one
Data frame to a STA, while polling that STA, and for the polled STA to respond with one Data frame.
The maximum value for CFPMaxDuration is the duration of (BeaconPeriod DTIMPeriod CFPPeriod) minus
[MaxMPDUTime plus (2 aSIFSTime) plus (2 aSlotTime) plus (8 AckSize)], expressed in microseconds.
MaxMPDUTime is the time to transmit the maximum-sized MAC frame, expanded by security mechanisms,
plus the time to transmit the PHY preamble, header, trailer, and expansion bits, if any. This allows sufficient
time to send at least one Data frame during the CP.
10.4.4.5 CF usage rules
A PC may send group addressed frames, and individually addressed Data or Management frames to any active
STA, as well as to CF-Pollable PS STAs. During the CFP, a CF-Pollable STA shall acknowledge after a SIFS,
the receipt of each Data +CF-Poll frame or Data +CF-Ack +CF-Poll frame using Data +CF-Ack or CF-Ack
(no data) frames, the receipt of each CF-Poll (no data) using Data or Null (no data), and the receipt of all other
Data and Management frames using Ack frames. A non-CF-Pollable STA shall acknowledge receipt of Data
and Management frames using Ack frames sent after a SIFS. This non-CF-Pollable operation is the same as
that already employed by such STAs for DCF operation.
When polled by the PCF (Data +CF-Poll, Data +CF-Ack +CF-Poll, CF-Poll, or CF-Ack +CF-Poll) a
CF-Pollable STA may send one Data frame to any destination. Such a frame directed to or through the PC STA
shall be acknowledged by the PC, using the CF-Ack indication (Data +CF-Ack, Data +CF-Ack +CF-Poll, CF-
Ack, CF-Ack +CF-Poll, or CF-End +CF-Ack) sent after a SIFS. Such a frame directed to a non-CF-Pollable
STA shall be acknowledged using an Ack frame sent after a SIFS. A polled CF-Pollable STA with neither a
Data frame nor an acknowledgment to send shall respond by transmitting a Null frame after a SIFS. A polled
CF-Pollable STA with insufficient time before the end of the CFP or current medium occupancy limit to send
its queued MPDU and receive an acknowledgment shall respond by transmitting a Null frame, or a CF-Ack
frame if polled using Data +CF-Poll or Data +CF-Ack +CF-Poll, after a SIFS. The CF-Pollable STA may set
the More Data bit to 1 in its response to permit the PC to distinguish between an empty STA queue and a
response due to insufficient time to transfer an MPDU.
1340
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PC shall not issue frames with a subtype that includes CF-Polls if insufficient time remains in the current
CFP to permit the polled STA to transmit a Data frame containing a minimum length MPDU.
10.4.5 CF polling list
10.4.5.1 General
If the PC supports use of the CFP for inbound frame transfer as well as for frame delivery, the PC shall
maintain a “polling list” for use in selecting STAs that are eligible to receive CF-Polls during CFPs. The
polling list functional characteristics are defined below. If the PC supports the use of the CFP solely for frame
delivery, the PC does not require a polling list, and shall never generate Data frames with a subtype that
includes CF-Poll. The form of CF support provided by the PC is identified in the Capability Information field
of Beacon, Association Response, Reassociation Response, and Probe Response frames, which are sent from
APs. Any such frames sent by STAs, as in noninfrastructure networks, shall have these bits set to 0.
The polling list is used to force the polling of CF-Pollable STAs, regardless of whether the PC has pending
traffic to transmit to those STAs. The polling list may be used to control the use of Data +CF-Poll and Data
+CF-Ack +CF-Poll types for transmission of Data frames being sent to CF-Pollable STAs by the PC. The
polling list is a logical construct, which is not exposed outside of the PC. A minimum set of polling list
maintenance techniques are required to in order to provide interoperability of arbitrary CF-Pollable STAs in
BSSs controlled by arbitrary APs with active PCs. An AP may also implement additional polling list
maintenance techniques that are outside the scope of this standard.
10.4.5.2 Polling list processing
The PC shall send a CF-Poll to at least one STA during each CFP when there are entries in the polling list.
During each CFP, the PC shall issue polls to a subset of the STAs on the polling list in order by ascending AID
value.
While time remains in the CFP, all CF frames have been delivered, and all STAs on the polling list have been
polled, the PC may generate one or more CF-Polls to any STAs on the polling list. While time remains in the
CFP, all CF frames have been delivered, and all STAs on the polling list have been polled, the PC may send
Data or Management frames to any STAs.
In order to gain maximum efficiency from the CFP, and the ability to piggyback acknowledgments on
successor Data frames in the opposite direction, the PC should generally use Data +CF-Poll and Data +CF-
Ack +CF-Poll types for each Data frame transmitted while sufficient time for the potential response to the CF-
Poll remains in the CFP.
10.4.5.3 Polling list update procedure
A STA indicates its CF-Pollability using the CF-Pollable subfield of the Capability Information field of
Association Request and Reassociation Request frames.
NOTE—A STA might perform a reassociation in order to change the PC’s record of its CF-Pollability.
During association, a CF-Pollable STA may request to be placed on the polling list, or to never be polled, by
appropriate use of bits in the Capability Information field of the Associate Request or Reassociate Request
frame, as shown in Table 9-44 (see 9.4.1.4).
CF-Pollable STAs that are not on the polling list, but did not request never to be polled during their most recent
association, may be dynamically placed on the polling list by the PC to handle bursts of frame transfer activity
by that STA.
1341
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.5 Fragmentation
The MAC may fragment and reassemble MSDUs or MMPDUs that are carried in individually addressed
MPDUs. The fragmentation and defragmentation mechanisms allow for fragment retransmission.
The length of each fragment shall be an equal number of octets for all fragments except the last, which may be
smaller. The length of each fragment shall be an even number of octets, except for the last fragment of an
MSDU or MMPDU, which may be either an even or an odd number of octets. The length of a fragment shall
never be larger than dot11FragmentationThreshold unless security encapsulation is invoked for the MPDU. If
security encapsulation is active for the MPDU, then the MPDU shall be expanded by the encapsulation
overhead and this may result in a fragment larger than dot11FragmentationThreshold.
A fragment is an MPDU, the Frame Body field of which carries all or a portion of an MSDU or MMPDU.
When data are to be transmitted, the number of octets in the fragment (before processing by the security
mechanism) shall be limited by dot11FragmentationThreshold and the number of octets in the MPDU that
have yet to be assigned to a fragment at the instant the fragment is constructed for the first time. Once a
fragment is transmitted for the first time, its frame body content and length shall be fixed until it is successfully
delivered to the immediate receiving STA.
A STA shall be capable of receiving fragments, containing all or part of an MSDU, of arbitrary length that is
less than or equal to the maximum MSDU size as defined in 9.2.3, plus any security encapsulation overhead,
plus MAC header and FCS.
A STA shall be capable of receiving fragments, containing all or part of an MMPDU, of arbitrary length that
is less than or equal to the minimum of
— The maximum MMPDU size as defined in 9.3.3.2, plus any security encapsulation overhead, plus
MAC header and FCS
— Any maximum MPDU length advertised by the STA
If a fragment requires retransmission, its frame body content and length shall remain fixed for the lifetime of
the MSDU or MMPDU at that STA. Each fragment shall contain a Sequence Control field, which comprises a
sequence number and fragment number. When a STA is transmitting an MSDU or MMPDU, the sequence
number shall remain the same for all fragments of that MSDU or MMPDU. The fragments shall be sent in
order of lowest fragment number to highest fragment number, where the fragment number value starts at 0, and
increases by 1 for each successive fragment. The Frame Control field also contains a bit, the More Fragments
bit, that is equal to 0 to indicate the last (or only) fragment of the MSDU or MMPDU.
The source STA shall maintain a transmit MSDU timer for each MSDU being transmitted. The attribute
dot11MaxTransmitMSDULifetime specifies the maximum amount of time allowed to transmit an MSDU. The
timer starts on the initial attempt to transmit the first fragment of the MSDU. If the timer exceeds
dot11MaxTransmitMSDULifetime, then all remaining fragments are discarded by the source STA and no
attempt is made to complete transmission of the MSDU.
NOTE—A STA might interleave fragments of MSDUs with different TIDs sent to the same receiver, subject to any
constraint caused by the number of replay counters.
10.6 Defragmentation
Each fragment contains information to allow the complete MSDU or MMPDU to be reassembled from its
constituent fragments. The header of each fragment contains the following information that is used by the
destination STA to reassemble the MSDU or MMPDU:
— Frame type
— Address of the sender, obtained from the Address 2 field
1342
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Destination address
— Sequence Control field: This field allows the destination STA to check that all incoming fragments
belong to the same MSDU or MMPDU, and the sequence in which the fragments should be
reassembled. The sequence number within the Sequence Control field remains the same for all
fragments of an MSDU or MMPDU, while the fragment number within the Sequence Control field
increments for each fragment.
— Traffic identifier, for frames with a QoS Control field.
— More Fragments indicator: Indicates to the destination STA that this is not the last fragment of the
MSDU or MMPDU. Only the last or sole fragment of the MSDU or MMPDU shall have this bit set
to 0. All other fragments of the MSDU or MMPDU shall have this bit set to 1.
The destination STA shall reconstruct the MSDU or MMPDU by combining the fragments in order of
fragment number subfield of the Sequence Control field. If security encapsulation has been applied to the
fragment, it shall be deencapsulated and decrypted before the fragment is used for defragmentation of the
MSDU or MMPDU. If the fragment with the More Fragments bit equal to 0 has not yet been received, then the
destination STA knows that the MSDU or MMPDU is not yet complete. As soon as the STA receives the
fragment with the More Fragments bit equal to 0, the STA knows that no more fragments may be received for
the MSDU or MMPDU.
A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. A STA
should support the concurrent reception of fragments of at least one MSDU per access category. An AP should
support the concurrent reception of at least one MSDU per access category per associated STA. Note that a
STA receiving more than three fragmented MSDUs or MMPDUs concurrently might experience a significant
increase in the number of frames discarded.
NOTE—The three MSDUs or MMPDUs might be from different peers (e.g., in an IBSS or MBSS).
The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received, for a
minimum of three MSDUs or MMPDUs. The STA may implement additional timers to be able to receive
additional concurrent MSDUs or MMPDUs. The receiving STA shall discard all fragments that are part of an
MSDU or MMPDU for which a timer is not maintained. There is also dot11MaxReceiveLifetime, that
specifies the maximum amount of time allowed to receive an MSDU. The receive MSDU or MMPDU timer
starts on the reception of the first fragment of the MSDU or MMPDU. If the receive MSDU timer exceeds
dot11MaxReceiveLifetime, then all received fragments of this MSDU or MMPDU are discarded by the
destination STA. If additional fragments of an individually addressed MSDU or MMPDU are received after its
dot11MaxReceiveLifetime is exceeded, those fragments shall be acknowledged and discarded.
To properly reassemble MPDUs into an MSDU or MMPDU, a destination STA shall discard any duplicated
fragments received. A STA shall discard duplicate fragments as described in 10.3.2.11. However, an
acknowledgment shall be sent in response to a duplicate fragment of an individually addressed MSDU or
MMPDU.
10.7 Multirate support
10.7.1 Overview
Some PHYs have multiple data transfer rate capabilities that allow implementations to perform dynamic rate
switching with the objective of improving performance. The algorithm for performing rate switching is beyond
the scope of this standard, but in order to provide coexistence and interoperability on multirate-capable PHYs,
this standard defines a set of rules to be followed by all STAs.
1343
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Only the data transfer rates of the mandatory rate set of the attached PHY are guaranteed to be supported when
a STA for which dot11OCBActivated is true transmits a Management or Data frame. A higher layer protocol
entity within a STA in which dot11OCBActivated is true might negotiate a rate outside the mandatory rate set.
A STA that transmits a frame shall select a rate defined by the rules for determining the rates of transmission of
protection frames in 10.26 when the following conditions apply:
— The STA’s protection mechanism for non-ERP receivers is enabled.
— The frame is a protection mechanism frame.
— The frame initiates an exchange.
Otherwise, a non-DMG STA shall transmit the frame using a rate that is in accordance with rules defined in
10.7.5 and 10.7.6. A DMG STA shall transmit the frame using a rate that is in accordance with rules defined in
10.7.7.
For specific PHYs, the value of the Duration/ID field is determined using the PLME-TXTIME.request
primitive and the PLME-TXTIME.confirm primitive. These specific PHYs are defined in:
— Clause 16 for HR/DSSS
— Clause 17 for OFDM
— Clause 18 for ERP
— Clause 19 for HT
— Clause 20 for DMG
— Clause 21 for VHT
— Clause 22 for TVHT
The two PLME-TXTIME primitives are defined in the respective PHY specifications:
— 16.3.4 for HR TXTIME calculation
— 17.4.3 for OFDM TXTIME calculation
— 18.5.3.2 for ERP-OFDM TXTIME calculation
— 19.4.3 for HT TXTIME calculation
— 20.12.3 for DMG PLME TXTIME calculation
— 21.4.3 for VHT PLME TXTIME calculation
— 22.4.3 for TVHT PLME TXTIME calculation
The Duration/ID field in a frame transmitted by a QoS STA may cover multiple frames and might involve
using the PLME-TXTIME.request primitive several times.
10.7.2 Basic HT-MCS Set field
An AP that transmits a frame containing an HT Operation element with either the Dual Beacon field or the
Dual CTS Protection field equal to 1 shall include at least one MCS that has only one spatial stream in the
Basic HT-MCS Set field of the HT Operation element of that frame.
10.7.3 Basic STBC MCS
The basic STBC MCS has the value null when any of the following conditions is true:
— The Dual Beacon field in the HT Operation element is equal to 0, and the Dual CTS Protection field
in the HT Operation element is equal to 0.
— No HT Operation element is present in the Association Response frame received from the current
AP.
1344
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request
primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter
of the MLME-JOIN.request primitive is empty or does not exist.
— The lowest MCS of the Basic HT-MCS Set field of the HT Operation parameter of the MLME-
START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the
SelectedBSS parameter of the MLME-JOIN.request primitive has NSS value greater than 1 (the
mapping of MCS to NSS is PHY dependent, for the HT PHY see 19.5).
If none of the above conditions is true, then the basic STBC MCS is the lowest MCS index of the Basic HT-
MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS
Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request
primitive.
When an MCS from the basic STBC MCS is required in 10.7.5 and 10.7.6 but the basic STBC MCS has the
value null, the STA shall select a mandatory MCS of the attached PHY.
10.7.4 Basic rate set, basic HT-MCS set, and basic VHT-MCS and NSS set for mesh STA
A mesh STA shall not establish a mesh peering with a mesh STA using a different BSSBasicRateSet (see
14.2.7 and 14.2.8).
The SME of a Mesh STA should use the mandatory PHY rates as the default BSSBasicRateSet in the
MLME-START.request primitive to reduce the risk that a candidate peer mesh STA utilizes a different
BSSBasicRateSet. If the mesh STA is also an HT STA, it should adopt the mandatory HT MCSs as the
default basic HT-MCS set. If the mesh STA is also a VHT STA, it should adopt tuples
formed from the mandatory VHT-MCSs and NSS = 1 as the default basic VHT-MCS and NSS set (see
11.40.7).
10.7.5 Rate selection for Data and Management frames
10.7.5.1 Rate selection for non-STBC Beacon and non-STBC PSMP frames
If the BSSBasicRateSet parameter is not empty, a non-STBC PSMP frame or a non-STBC Beacon frame
shall be transmitted in a non-HT PPDU using one of the rates included in the BSSBasicRateSet parameter.
If the BSSBasicRateSet parameter is empty, the frame shall be transmitted in a non-HT PPDU using one of
the mandatory PHY rates.
10.7.5.2 Rate selection for STBC group addressed Data and Management frames
When a STA has dot11TxSTBCOptionActivated true, it shall use the basic STBC MCS when it transmits an
STBC Beacon frame or when it transmits a group addressed Data or Management frame that is an STBC
frame.
10.7.5.3 Rate selection for other group addressed Data and Management frames
This subclause describes the rate selection rules for group addressed Data and Management frames, excluding
the following:
— Non-STBC Beacon and non-STBC PSMP frames
— STBC group addressed Data and Management frames
— Data frames located in an FMS stream (see 11.24.8)
— Group addressed frames transmitted to the GCR concealment address (see 11.24.16.3.5)
1345
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the BSSBasicRateSet parameter is not empty, a Data or Management frame (excluding the frames listed
above) with a group address in the Address 1 field shall be transmitted in a non-HT PPDU using one of the
rates included in the BSSBasicRateSet parameter or the rate chosen by the AP, described in 11.24.8, if the Data
frames are part of an FMS stream.
If the BSSBasicRateSet parameter is empty and the Basic HT-MCS Set field of the HT Operation parameter
of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the
SelectedBSS parameter of the MLME-JOIN.request primitive is not empty, the frame shall be transmitted in
an HT PPDU using one of the MCSs included in the Basic HT-MCS Set field of the HT Operation parameter
of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the
SelectedBSS parameter of the MLME-JOIN.request primitive.
If the BSSBasicRateSet parameter is empty and the Basic HT-MCS Set field of the HT Operation parameter
of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the
SelectedBSS parameter of the MLME-JOIN.request primitive is empty and the basic VHT-MCS and NSS set
is not empty, the frame shall be transmitted in a VHT PPDU using one of the tuples
included in the basic VHT-MCS and NSS set.
If the BSSBasicRateSet parameter, the Basic HT-MCS Set field of the HT Operation parameter of the
MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the
SelectedBSS parameter of the MLME-JOIN.request primitive, and the basic VHT-MCS and NSS set are
empty (e.g., a scanning STA that is not yet associated with a BSS), the frame shall be transmitted in a non-HT
PPDU using one of the mandatory PHY rates.
10.7.5.4 Rate selection for polling frames
A Data frame of a subtype that includes CF-Poll that does not also include CF-Ack and that is sent in the CP
shall be transmitted at a rate selected as follows:
a) If an initial exchange has already established protection and the Duration/ID field in the frame
establishing protection covers the entire TXOP, the rate or MCS is selected according to the rules in
10.7.5.7.
b) Otherwise, the Data frame shall be transmitted at a rate or MCS as defined in 10.7.5.3, treating the
frame as though it has a group address in the Address 1 field, solely for the purpose of determining
the appropriate rate or MCS.
10.7.5.5 Rate selection for +CF-Ack frames
For a frame of type (QoS) Data +CF-Ack, (QoS) Data +CF-Poll+CFAck, or (QoS) CF-Poll +CF-Ack, the rate
or MCS and TXVECTOR parameter CH_BANDWIDTH used to transmit the frame shall be chosen from
among those supported by both the addressed recipient STA and the STA to which the Ack frame is intended.
10.7.5.6 Rate selection for Data frames sent within an FMS stream
Data frames sent within an FMS stream are sent at a rate negotiated during the establishment of the FMS
stream. See 11.24.8.
10.7.5.7 Rate selection for other individually addressed Data and Management frames
A Data or Management frame not identified in 10.7.5.1 through 10.7.5.6 shall be sent using any data rate,
MCS, or tuple subject to the following constraints:
— A STA shall not transmit a frame using a rate or MCS that is not supported by the receiver STA or
STAs, as reported in any Supported Rates and BSS Membership Selectors element, Extended
1346
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Supported Rates and BSS Membership Selectors element, or Supported MCS Set field in
Management frames transmitted by the receiver STA.
— A STA shall not transmit a frame using a tuple that is not supported by the
receiver STA, as reported in any Supported VHT-MCS and NSS Set field in Management frames
transmitted by the receiver STA.
— If at least one Operating Mode field with the Rx NSS Type subfield equal to 0 was received from the
receiver STA:
— A STA shall not transmit a frame with the number of spatial streams greater than that indicated in
the Rx NSS subfield in the most recently received Operating Mode field with the Rx NSS Type
subfield equal to 0 from the receiver STA.
— If at least one Operating Mode field with the Rx NSS Type subfield equal to 1 was received from the
receiver STA:
— A STA shall not transmit an SU PPDU frame using a beamforming steering matrix with the
number of spatial streams greater than that indicated in the Rx NSS subfield in the most recently
received Operating Mode field with the Rx NSS Type subfield equal to 1 from the receiver STA
if the beamforming steering matrix was derived from a VHT Compressed Beamforming report
with Feedback Type subfield indicating MU in the VHT Compressed Beamforming frame(s).
— A STA shall not transmit a frame using a value for the CH_BANDWIDTH parameter of the
TXVECTOR that is not supported by the receiver STA, as reported in any HT Capabilities element
or VHT Capabilities element received from the intended receiver.
— An HT STA that is a member of a BSS and that is not a VHT STA shall not transmit a frame using a
value for the CH_BANDWIDTH parameter of the TXVECTOR that is not permitted for use in the
BSS, as reported in the most recently received HT Operation element, with the exception
transmissions on an off-channel TDLS direct link, which follow the rules described in 11.23.6.2 and
11.23.6.3.
— A VHT STA that is a member of a BSS shall not transmit a frame using a value for the
CH_BANDWIDTH parameter of the TXVECTOR that is not permitted for use in the BSS, as
reported in the most recently received VHT Operation element with the following exceptions:
— Transmissions on an off-channel TDLS direct link follow the rules described in 11.23.6.2 and
11.23.6.3.
— Transmissions by a VHT STA on a TDLS link follow the rules described in 11.23.1 and
11.23.6.5.
— If at least one Operating Mode field with the Rx NSS Type subfield equal to 0 was received from the
receiver STA:
— A STA shall not transmit a frame using a value for the TXVECTOR parameter
CH_BANDWIDTH that is not supported by the receiver STA as reported in the most recently
received Operating Mode field with the Rx NSS Type subfield equal to 0 from the receiver STA.
When the operational rate set of the receiving STA or STAs is not known, the transmitting STA shall transmit
using a rate in the BSSBasicRateSet parameter, or an MCS in the Basic HT-MCS Set field of the
HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT
Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive, or a tuple in the basic VHT-MCS and NSS set, or a rate from the mandatory rate set of the attached PHY if
the BSSBasicRateSet, the Basic HT-MCS Set field of the HT Operation parameter of the MLME-
START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS
parameter of the MLME-JOIN.request primitive, and the basic VHT-MCS and NSS set are empty.
The rules in this subclause also apply to A-MPDUs that aggregate MPDUs with the Type subfield equal to
Data or Management with any other types of MPDU.
1347
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.7.6 Rate selection for Control frames
10.7.6.1 General rules for rate selection for Control frames
Control frames carried in an A-MPDU that does not contain a VHT single MPDU shall be sent at a rate
selected from the rules defined in 10.7.5.7.
NOTE—The rules defined in 10.7.6.2 through 10.7.6.5 apply only to Control frames not carried in an A-MPDU that
does not contain a VHT single MPDU.
The following rules determine whether a Control frame is carried in a non-HT, HT or VHT PPDU:
a) A Control frame shall be carried in an HT PPDU when the Control frame contains an L-SIG
duration value (see 10.26.5).
b) A control response frame shall be carried in an HT PPDU when the Control frame is a response to a
frame that meets any of the following conditions:
1) The frame eliciting the response included an HT variant HT Control field with the TRQ field
equal to 1 and the HT NDP Announcement subfield equal to 0, and this responder set the
Implicit Transmit Beamforming Receiving Capable field to 1 in its last transmitted HT
Capabilities element; or
2) The frame eliciting the response was an RTS frame carried in an HT PPDU; or
3) The frame eliciting the response was an STBC frame, and the Dual CTS Protection field was
equal to 1 in the last HT Operation element received from its AP or transmitted by the STA (see
10.3.2.8).
c) A Control frame may be carried in an HT PPDU when the Control frame meets any of the following
conditions:
1) The Control frame contains an HT variant HT Control field with the MRQ subfield equal to 1,
or
2) The Control frame contains an HT variant HT Control field with the TRQ field equal to 1.
d) A Control frame may be carried in a VHT PPDU when the Control frame contains an HT Control
field.
e) A Control frame shall be carried in an HT PPDU or a VHT PPDU when the Control frame is sent
using an STBC frame.
f) A control response frame shall be carried in a VHT PPDU if the eliciting frame was an RTS frame
carried in a VHT PPDU that contains an HT Control field with MRQ subfield equal to 1.
Otherwise, the Control frame shall be carried in a non-HT PPDU. The requirements specified in 10.30,
10.31.2, and 10.32 further constrain the choice of non-HT, HT, or VHT PPDU.
If an Operating Mode field has been received from the intended receiver STA, the following constraints also
apply:
— If at least one Operating Mode field with the Rx NSS Type subfield equal to 0 was received from the
receiver STA:
— A STA shall not transmit a frame with the number of spatial streams greater than that indicated in
the Rx NSS subfield in the most recently received Operating Mode field with the Rx NSS Type
subfield equal to 0 from the receiver STA.
— If at least one Operating Mode field with the Rx NSS Type subfield equal to 1 was received from the
receiver STA:
— A STA shall not transmit an SU PPDU frame using a beamforming steering matrix with the
number of spatial streams greater than that indicated in the Rx NSS subfield in the most recently
received Operating Mode field with the Rx NSS Type subfield equal to 1 from the receiver STA
if the beamforming steering matrix was derived from a VHT Compressed Beamforming report
with Feedback Type subfield indicating MU in the VHT Compressed Beamforming frame(s).
1348
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Selection of channel width is defined in 10.7.6.6.
A control response frame is a Control frame that is transmitted as a response to the reception of a frame a SIFS
after the PPDU containing the frame that elicited the response, e.g., a CTS frame in response to an RTS frame
reception, an Ack frame in response to a Data frame reception, a BlockAck frame in response to a
BlockAckReq frame reception. In some situations, the transmission of a Control frame is not a control
response transmission, such as when a CTS frame is used to initiate a TXOP.
10.7.6.2 Rate selection for Control frames that initiate a TXOP
This subclause describes the rate selection rules for Control frames that initiate a TXOP and that are either a
VHT single MPDU or not carried in an A-MPDU.
If a Control frame other than a Basic BlockAckReq or Basic BlockAck frame is carried in a non-HT PPDU,
the transmitting STA shall transmit the frame using one of the rates in the BSSBasicRateSet parameter or a rate
from the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty.
If a Basic BlockAckReq or Basic BlockAck frame is carried in a non-HT PPDU, the transmitting STA shall
transmit the frame using a rate supported by the receiver STA, if known (as reported in the Supported Rates
and BSS Membership Selectors element and/or Extended Supported Rates and BSS Membership Selectors
element in frames transmitted by that STA). If the operational rate set of the receiving STA or STAs is not
known, the transmitting STA shall transmit using a rate from the BSSBasicRateSet parameter or using a rate
from the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty.
NOTE—Because of their utility in resolving contention and in establishing a NAV, most control subtype frames that
initiate a frame exchange are subject to explicit limitations regarding the choice of transmission rate with the intent of
ensuring maximum possible coverage and receivability of the frame. But the Basic BlockAckReq and Basic BlockAck
frames are subject to fewer restrictions because their use at times mimics a typical data-Ack exchange, where no
BSSBasicRateSet rate restriction exists on the Data frame. In addition, the Basic BlockAck frame is significantly larger
than the other Control frames.
When L-SIG TXOP protection is not used for an HT PPDU, an HT STA shall select an MCS from the Basic
HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-
MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request
primitive when protection is required (as defined in 10.26) and shall select an MCS from the
SupportedMCSSet parameter of the intended receiver when protection is not required.
When L-SIG TXOP protection is used, an HT STA shall select an MCS from the SupportedMCSSet parameter
of the intended receiver.
When transmitting a VHT PPDU, a STA shall select a tuple from the basic VHT-MCS and
NSS set when protection is required (as defined in 10.26) and shall select a tuple from the
operational VHT-MCS and NSS set parameter of the intended receiver when protection is not required.
10.7.6.3 Rate selection for CF-End frames
If not operating during the 40 MHz phase of PCO, a STA that transmits a CF-End frame that is not at the end of
a TXOP that was obtained through the use of the dual CTS mechanism shall transmit the frame using a rate in
BSSBasicRateSet or from the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty.
If operating during the 40 MHz phase of PCO, a STA that transmits a CF-End frame that is not at the end of a
TXOP that was obtained through the use of the dual CTS mechanism shall transmit the frame using an MCS
from the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or
Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-
JOIN.request primitive.
1349
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA that transmits a CF-End frame at the end of a TXOP that was obtained by a non-AP STA through the
use of the dual CTS mechanism shall transmit the CF-End frame with the same value for the TXVECTOR
parameter STBC, TXVECTOR parameter MCS (if present), and TXVECTOR parameter RATE as was used
for the transmission of the matching Control frame at the beginning of the TXOP. The matching Control frame
is defined as follows:
— For the first CF-End frame transmitted in the TXOP, the matching Control frame is the first RTS
frame transmitted in the TXOP.
— For the second CF-End frame transmitted in the TXOP, the matching Control frame is the first CTS
frame that follows the first RTS frame transmitted in the TXOP.
— For the third CF-End frame transmitted in the TXOP, the matching Control frame is the second CTS
frame that follows the first RTS frame transmitted in the TXOP.
A STA that transmits a CF-End frame at the end of a TXOP that was obtained by an AP through the use of the
dual CTS mechanism shall transmit the CF-End frame with the same value for the TXVECTOR parameter
STBC, TXVECTOR parameter MCS (if present), and TXVECTOR parameter RATE as was used for the
transmission of the matching Control frame at the beginning of the TXOP. The matching Control frame is
defined as follows:
— For the first CF-End frame transmitted in the TXOP, the matching Control frame is the first CTS-to-
self frame transmitted in the TXOP.
— For the second CF-End frame transmitted in the TXOP, the matching Control frame is the first RTS
transmitted in the TXOP.
10.7.6.4 Rate selection for Control frames that are not control response frames
This subclause describes the rate selection rules for Control frames that are not control response frames, are not
the frame that initiates a TXOP, are not the frame that terminates a TXOP, and are either a VHT single MPDU
or not carried in an A-MPDU.
A frame other than a BlockAckReq or BlockAck that is carried in a non-HT PPDU shall be transmitted by the
STA using a rate no higher than the highest rate in the BSSBasicRateSet parameter that is less than or equal to
the rate or non-HT reference rate (see 10.7.10) of the previously transmitted frame that was directed to the
same receiving STA. If no rate in the BSSBasicRateSet parameter meets these conditions, the Control frame
shall be transmitted at a rate no higher than the highest mandatory rate of the attached PHY that is less than or
equal to the rate or non-HT reference rate (see 10.7.10) of the previously transmitted frame that was directed to
the same receiving STA.
A BlockAckReq or BlockAck frame that is carried in a non-HT PPDU shall be transmitted by the STA using a
rate supported by the receiver STA, as reported in the Supported Rates and BSS Membership Selectors element
and/or Extended Supported Rates and BSS Membership Selectors element in frames transmitted by that STA.
When the operational rate set of the receiving STA or STAs is not known, the transmitting STA shall transmit
using a rate from the BSSBasicRateSet parameter or from the mandatory rate set of the attached PHY if the
BSSBasicRateSet is empty.
A frame that is carried in an HT PPDU shall be transmitted by the STA using an MCS supported by the
receiver STA, as reported in the Supported MCS Set field in the HT Capabilities element received from that
STA. When the supported MCS set of the receiving STA or STAs is not known, the transmitting STA shall
transmit using an MCS in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-
START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS
parameter of the MLME-JOIN.request primitive.
A frame that is carried in a VHT PPDU shall be transmitted by the STA using a tuple
supported by the receiver STA. A tuple is supported if reported as such in the Supported
1350
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
VHT-MCS and NSS Set field in the VHT Capabilities element received from that STA. When the Supported
VHT-MCS and NSS set of the receiving STA or STAs is not known, the transmitting STA shall transmit using
a tuple in the basic VHT-MCS and NSS set.
10.7.6.5 Rate selection for control response frames
10.7.6.5.1 Introduction
Subclauses 10.7.6.5.2 through 10.7.6.5.5 describe the rate selection rules for control response frames that are
either a VHT single MPDU or not carried in an A-MPDU.
10.7.6.5.2 Selection of a rate or MCS
To allow the transmitting STA to calculate the contents of the Duration/ID field, a STA responding to a
received frame transmits its control response frame at a primary rate, or at an alternate rate, or at an MCS, as
specified by the following rules:
— If a CTS or Ack frame is carried in a non-HT PPDU, the primary rate is defined to be the highest rate
in the BSSBasicRateSet parameter that is less than or equal to the rate (or non-HT reference rate; see
10.7.10) of the previous frame. If no rate in the BSSBasicRateSet parameter meets these conditions,
the primary rate is defined to be the highest mandatory rate of the attached PHY that is less than or
equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. The STA may select
an alternate rate according to the rules in 10.7.6.5.4. The STA shall transmit the non-HT PPDU CTS
or Ack frame at either the primary rate or the alternate rate, if one exists.
— If a BlockAck frame is sent as an immediate response to either an implicit BlockAck request or to a
BlockAckReq frame that was carried in an HT or VHT PPDU and the BlockAck frame is carried in
a non-HT PPDU, the primary rate is defined to be the highest rate in the BSSBasicRateSet parameter
that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. If
no rate in the BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be
the highest mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT
reference rate; see 10.7.10) of the previous frame. The STA may select an alternate rate according to
the rules in 10.7.6.5.4. The STA shall transmit the non-HT PPDU BlockAck frame at either the
primary rate or the alternate rate, if one exists.
— If a Basic BlockAck frame is sent as an immediate response to a BlockAckReq frame that was
carried in a non-HT PPDU and the Basic BlockAck frame is carried in a non-HT PPDU, the primary
rate is defined to be the same rate and modulation class as the BlockAckReq frame, and the STA
shall transmit the Basic BlockAck frame at the primary rate.
— If a Compressed BlockAck frame is sent as an immediate response to a BlockAckReq frame that
was carried in a non-HT PPDU and the Compressed BlockAck frame is carried in a non-HT PPDU,
the primary rate is defined to be the highest rate in the BSSBasicRateSet parameter that is less than
or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. If no rate in the
BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest
mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate;
see 10.7.10) of the previous frame. The STA may select an alternate rate according to the rules in
10.7.6.5.4. The STA shall transmit the non-HT PPDU Compressed BlockAck frame at either the
primary rate or the alternate rate, if one exists.
— If the control response frame is carried in an HT or VHT PPDU, then it is transmitted using an MCS
or tuple as determined by the procedure defined in 10.7.6.5.3.
The modulation class of the control response frame shall be selected according to the following rules:
— If the received frame is of a modulation class other than HT or VHT and the control response frame
is carried in a non-HT PPDU, the control response frame shall be transmitted using the same
1351
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
modulation class as the received frame. In addition, the control response frame shall be sent using
the same value for the TXVECTOR parameter PREAMBLE_TYPE as the received frame.
— If the received frame is of the modulation class HT or VHT and the control response frame is carried
in a non-HT PPDU, the control response frame shall be transmitted using one of the ERP-OFDM or
OFDM modulation classes.
— If the control response frame is carried in an HT PPDU, the modulation class shall be HT.
— If the control response frame is carried in a VHT PPDU, the modulation class shall be VHT.
The selection of the value for the channel width (CH_BANDWIDTH parameter of the TXVECTOR) of the
response transmission is defined in 10.7.6.6.
10.7.6.5.3 Control response frame MCS computation
If a control response frame is to be transmitted within an HT or VHT PPDU, the channel width
(CH_BANDWIDTH parameter of the TXVECTOR) shall be selected first according to 10.7.6.6, and then the
MCS or tuple shall be selected from a set of MCSs and tuples called
the CandidateMCSSet as described in this subclause.
If the frame eliciting the response was transmitted by an HT STA that is not a VHT STA, the Rx Supported
MCS Set is determined from the Supported MCS Set field in the HT Capabilities element received from the
STA as follows:
— If a bit in the Rx MCS Bitmask subfield is equal to 0, the corresponding MCS is not supported.
— If a bit in the Rx MCS Bitmask subfield is equal to 1 and the integer part of the data rate (expressed
in megabits per second) of the corresponding MCS is less than or equal to the rate represented by the
Rx Highest Supported Data Rate subfield, then the MCS is supported by the STA on receive. If the
Rx Highest Supported Data Rate subfield is equal to 0 and a bit in the Rx MCS Bitmask is equal to
1, then the corresponding MCS is supported by the STA on receive.
If the frame eliciting the response was transmitted by a VHT STA, the Rx Supported MCS Set is determined
for VHT PPDUs as described in 10.7.12 and for HT PPDUs from the Supported MCS Set field in the HT
Capabilities element received from the STA as follows:
— If a bit in the Rx MCS Bitmask subfield is equal to 0, the corresponding MCS is not supported.
— If a bit in the Rx MCS Bitmask subfield is equal to 1 and the integer part of the data rate (expressed
in megabits per second) of the corresponding MCS is less than or equal to the rate represented by the
Rx Highest Supported Data Rate subfield, then the MCS is supported by the STA on receive. If the
Rx Highest Supported Data Rate subfield is equal to 0 and a bit in the Rx MCS Bitmask is equal to
1, then the corresponding MCS is supported by the STA on receive.
The CandidateMCSSet is determined using the following rules:
— If the frame eliciting the response was an STBC frame and the Dual CTS Protection bit is equal to 1,
the CandidateMCSSet shall contain only the basic STBC MCS.
— If the frame eliciting the response had an L-SIG duration value (see 10.26.5) and initiates a TXOP,
the CandidateMCSSet is the MCS Set consisting of the intersection of the Rx Supported MCS Set of
the STA that sent the frame that is eliciting the response and the set of MCSs that the responding
STA is capable of transmitting.
— If none of the above conditions is true, the CandidateMCSSet is the union of the Basic HT-MCS Set
field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set
field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request
primitive and the basic VHT-MCS and NSS set. If the frame eliciting the response was an RTS
frame carried in a VHT PPDU, then the CandidateMCSSet may additionally include the tuple with the same MCS and number of spatial streams as the VHT PPDU. If the
1352
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
combined Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request
primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter
of the MLME-JOIN.request primitive is empty, the CandidateMCSSet shall consist of
— The set of mandatory HT PHY MCSs if the STA eliciting the response is an HT STA that is not a
VHT STA
— The set of mandatory HT MCSs plus the set of tuples corresponding to the
mandatory VHT PHY MCSs with NSS = 1 if the STA eliciting the response is a VHT STA
MCS values from the CandidateMCSSet that cannot be transmitted with the selected CH_BANDWIDTH
parameter value shall be eliminated from the CandidateMCSSet.
The choice of a response MCS is made as follows:
a) If the frame eliciting the response is within a non-HT PPDU,
1) Eliminate from the CandidateMCSSet all tuples. Eliminate all MCSs that
have a data rate greater than the data rate of the received PPDU (the mapping of MCS to data
rate is defined in 19.5).
2) Find the highest indexed MCS from the CandidateMCSSet. The index of this MCS is the index
of the MCS that is the primary MCS for the response transmission.
3) If the CandidateMCSSet is empty, the primary MCS is the lowest indexed MCS of the
mandatory MCSs.
b) If the frame eliciting the response is within an HT PPDU,
1) Eliminate from the CandidateMCSSet all tuples. Eliminate all MCSs that
have an index that is higher than the index of the MCS of the received frame. Also eliminate all
MCSs that have a number of spatial streams greater than that indicated in the Rx NSS subfield
in the most recent Operating Mode field with the Rx NSS Type subfield equal to 0 from the
intended receiver STA, if at least one Operating Mode field with the Rx NSS Type subfield
equal to 0 was received from the intended receiver STA.
2) Determine the highest number of spatial streams (NSS) value of the MCSs in the
CandidateMCSSet that is less than or equal to the NSS value of the MCS of the received frame.
Eliminate all MCSs from the CandidateMCSSet that have an NSS value that is not equal to this
NSS value. The mapping from MCS to NSS is dependent on the attached PHY. For the HT PHY,
see 19.5.
3) Find the highest indexed MCS of the CandidateMCSSet for which the modulation value of
each stream is less than or equal to the modulation value of each stream of the MCS of the
received frame and for which the coding rate is less than or equal to the coding rate of the MCS
from the received frame. This MCS is the primary MCS for the response transmission. The
mapping from MCS to modulation and coding rate is dependent on the attached PHY. For the
HT PHY, see 19.5. For the purpose of comparing modulation values, the following sequence
shows increasing modulation values: BPSK, QPSK, 16-QAM, 64-QAM.
4) If no MCS meets the condition in step 3), remove each MCS from the CandidateMCSSet that
has the highest value of NSS in the CandidateMCSSet. If the resulting CandidateMCSSet is
empty, then set the CandidateMCSSet to the HT PHY mandatory MCSs. Repeat step 3) using
the modified CandidateMCSSet.
c) If the frame eliciting the response is within a VHT PPDU,
1) Eliminate from the CandidateMCSSet all MCSs and all tuples that meet
any of the following conditions:
i) Have a data rate that is higher than the data rate of the tuple of the
received frame using the largest possible value of CH_BANDWIDTH that is no larger
than the value of CH_BANDWIDTH of the received frame
1353
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ii) Have a number of spatial streams greater than that indicated in the Rx NSS subfield in the
most recent Operating Mode field with the Rx NSS Type subfield equal to 0 from the
intended receiver STA, if at least one Operating Mode field with the Rx NSS Type
subfield equal to 0 was received from the intended receiver STA
iii) Have a number of spatial streams greater than that indicated in the Rx NSS subfield in the
most recent Operating Mode field with the Rx NSS Type subfield equal to 1 from the
intended receiver STA if at least one Operating Mode field with the Rx NSS Type subfield
equal to 1 was received from the receiver STA and the control response frame is an SU
PPDU frame with a beamforming steering matrix and the beamforming steering matrix
was derived from a VHT Compressed Beamforming report with Feedback Type subfield
indicating MU in the VHT Compressed Beamforming frame(s)
2) Determine the highest number of spatial streams (NSS) value of the MCSs and tuples in the CandidateMCSSet that is less than or equal to the NSS value of the received
frame. Eliminate all MCSs from the CandidateMCSSet that have an NSS value that is not equal
to this NSS value. The mapping from MCS to NSS is dependent on the attached PHY. For the
HT PHY, see 19.5.
3) Find the highest rate MCS or tuple of the CandidateMCSSet for which the
modulation value of each stream is less than or equal to the modulation value of each stream of
the MCS of the received frame and for which the coding rate is less than or equal to the coding
rate of the MCS from the received frame. This MCS or tuple is the primary
MCS for the response transmission. The mapping from MCS or tuple to
modulation and coding rate is dependent on the attached PHY. For the HT PHY, see 19.5; for
the VHT PHY, see 21.5. For the purpose of comparing modulation values, the following
sequence shows increasing modulation values: BPSK, QPSK, 16-QAM, 64-QAM, 256-QAM.
4) If no MCS meets the condition in step 3), remove each MCS or tuple from
the CandidateMCSSet that has the highest value of NSS in the CandidateMCSSet. If the
resulting CandidateMCSSet is empty, then set the CandidateMCSSet to the VHT PHY
mandatory MCSs. Repeat step 3) using the modified CandidateMCSSet.
Once the primary MCS or tuple has been selected, the STA may select an alternate MCS
according to 10.7.6.5.4. The STA shall transmit the control response frame using either the primary MCS or the
alternate MCS, if one exists.
10.7.6.5.4 Selection of an alternate rate or MCS for a control response frame
An alternate rate may be selected provided that all of the following conditions are met:
— The duration of frame at the alternate rate is the same as the duration of the frame at the primary rate
determined by 10.7.6.5.2.
— The alternate rate is in either the BSSBasicRateSet parameter or is a mandatory rate of the attached
PHY.
— The modulation class of the frame at the alternate rate is the same class as that of the primary rate
selected by 10.7.6.5.2.
An alternate MCS may be selected provided that both of the following conditions are met:
— The duration of the frame at the alternate MCS is the same as the duration of the frame at the
primary MCS.
— The alternate MCS is in the CandidateMCSSet that was generated according to the procedure of
10.7.6.5.3.
1354
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.7.6.5.5 Control response frame TXVECTOR parameter restrictions
A STA shall not transmit a control response frame with TXVECTOR parameter GI_TYPE set to SHORT_GI
unless it is in response to a reception of a frame with the RXVECTOR parameter GI_TYPE equal to
SHORT_GI.
A STA shall not transmit a control response frame with TXVECTOR parameter FEC_CODING set to
LDPC_CODING unless it is in response to a reception of a frame with the RXVECTOR parameter
FEC_CODING equal to LDPC_CODING.
A STA shall not transmit a control response frame with the TXVECTOR parameter FORMAT set to HT_GF.
10.7.6.6 Channel Width selection for Control frames
The rules in this subclause, combined with the rules in 10.7.6.1, determine the format of control response
frames.
If a VHT STA transmits to another VHT STA a Control frame that is not an RTS frame or a CF-End frame,
if that Control frame elicits a control response frame or a VHT Compressed Beamforming frame, and
— If the Control frame is transmitted in a non-HT duplicate PPDU (channel width 40 MHz or wider),
the transmitting VHT STA shall set the TA field to a bandwidth signaling TA.
— If the Control frame is transmitted in a non-HT PPDU (channel width 20 MHz), the transmitting
VHT STA may set the TA field to a bandwidth signaling TA.
If the TA is a bandwidth signaling TA, the transmitting VHT STA shall set the TXVECTOR parameters
CH_BANDWIDTH_IN_NON_HT and CH_BANDWIDTH to the same value.
NOTE 1—Such Control frames are BlockAckReq frames, BlockAck frames in the context of HT-delayed Block Ack,
PS-Poll frames, VHT NDP Announcement frames, and Beamforming Report Poll frames.
NOTE 2—Control Wrapper frames follow the rules pertaining to the carried Control frame (see 10.10).
Channel width selection rules for RTS frames are described in 10.3.2.6.
A VHT STA that transmits a CF-End frame in a non-HT duplicate PPDU (channel width 40 MHz or wider)
addressed to a VHT AP shall set the Individual/Group bit in the BSSID(TA) field to 1.
A VHT STA that transmits a CF-End frame in a non-HT PPDU (channel width 20 MHz) addressed to a
VHT AP may set the Individual/Group bit in the BSSID(TA) field to 1.
If the Individual/Group bit in the BSSID(TA) field of the CF-End frame is set to 1, the transmitting VHT
STA shall set the TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and CH_BANDWIDTH to
the same value.
A STA that sends a Control frame in response to a frame carried in an HT PPDU or a VHT PPDU shall set
the TXVECTOR parameter CH_BANDWIDTH to indicate a channel width that is the same as the channel
width indicated by the RXVECTOR parameter CH_BANDWIDTH of the frame eliciting the response.
A STA that sends a Control frame in response to a frame carried in a non-HT or non-HT duplicate PPDU
with a nonbandwidth signaling TA
— Should set the TXVECTOR parameter CH_BANDWIDTH to the same value as the RXVECTOR
parameter CH_BANDWIDTH for the frame eliciting the response.
— Shall not set the TXVECTOR parameter CH_BANDWIDTH to a value greater than the
RXVECTOR parameter CH_BANDWIDTH for the frame eliciting the response.
1355
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—According to this rule, a STA can respond with a 20 MHz PPDU if it receives a non-HT duplicate frame but is
not able to detect the channel width occupied by the frame (whether by design or because the frame was received over a
channel that is narrower than the channel on which it was transmitted).
A VHT STA that sends a Control frame that is in response to a non-HT or non-HT duplicate format frame
with a bandwidth signaling TA and that is not a CTS shall set the channel width indicated by the
TXVECTOR parameter CH_BANDWIDTH to the same value as the channel width indicated by the
RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT for the frame eliciting the response. The RA
field of a Control frame that is not a CF-End frame and that is sent in response to a Control frame with a
bandwidth signaling TA shall be set to a nonbandwidth signaling TA obtained from the TA field of the
immediately previous Control frame. For the channel width selection rules for CTS sent in response to an
RTS with a bandwidth signaling TA, see 10.3.2.7.
A frame that is intended to provide protection is transmitted using a channel width selected by the rules defined
in 10.26.
An HT STA that uses a non-HT duplicate frame to establish protection of its TXOP shall send any CF-End
frame using a non-HT duplicate frame except during the 40 MHz phase of PCO operation. During the 40 MHz
phase of PCO operation, the rules in 11.17 apply.
The TXOP holder should set the TXVECTOR parameter CH_BANDWIDTH of a CF-End frame to the
maximum bandwidth allowed by the rules in 10.22.2.7.
NOTE—A CF-End frame transmitted by an AP a SIFS duration after receiving a CF-End frame is considered a control
response frame.
10.7.6.7 Control frame TXVECTOR parameter restrictions
A STA shall not transmit a Control frame that initiates a TXOP with the TXVECTOR parameter GI_TYPE set
to a value of SHORT_GI.
A STA shall not transmit a Control frame that initiates a TXOP with the TXVECTOR parameter
FEC_CODING set to a value of LDPC_CODING.
10.7.7 Multirate support for DMG STAs
10.7.7.1 Usage of DMG Control modulation class
The DMG Control modulation class has only one MCS, which is DMG MCS 0 defined in Clause 20. The
DMG Beacon, SSW-Feedback, SSW-Ack, RTS, DMG CTS, DMG CTS-to-self, DMG DTS, CF-End,
Grant, SPR, Poll and first BRP packet in beam refinement shall be transmitted using the DMG Control
modulation class. In the case of an RXSS that was specified through the Beamforming Control field with the
value of the RXSSTxRate subfield equal to 1 and the RXSSTxRate Supported field in the DMG Capabilities
element of the STA performing the RXSS is 1, the first SSW frame of the RXSS shall be transmitted using
the DMG Control modulation class, and the remaining frames of the RXSS shall be transmitted using MCS
1 of the DMG SC modulation class. In all other cases, the SSW frames shall be transmitted using the DMG
Control modulation class. Other DMG beamforming training frames may be transmitted using the DMG
Control modulation class or the DMG SC modulation class.
10.7.7.2 Rate selection rules for Control frames transmitted by DMG STAs
This subclause describes the rate selection rules for Control frames transmitted by DMG STAs. The rate
selection rules apply only for MCSs defined in Clause 20.
1356
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A Control frame that does not have an MCS defined in 10.7.7.1 and that is not a control response frame shall
be transmitted using an MCS from the mandatory MCS set of the DMG SC modulation class or DMG
Control modulation class.
A STA transmitting an Ack or a BlockAck frame that is a response to a frame sent using the DMG low-
power SC modulation class shall use an MCS from the DMG low-power SC Supported MCS set of the STA
that transmitted the frame that elicited the response as long as (a) the selected MCS has a Data Rate that does
not exceed the Data Rate of the frame that elicited the response, and (b) no other MCS satisfying condition
(a) results in a shorter frame transmission time.
A STA transmitting a Grant Ack frame shall use the DMG Control modulation class or any MCS from the
mandatory MCS set of the DMG SC modulation class.
A STA transmitting an Ack or a BlockAck frame that is a response to a frame sent using the DMG Control
modulation class shall use the DMG Control modulation class.
A STA transmitting an Ack frame or a BlockAck frame in response to a frame sent using the DMG SC
modulation class or DMG OFDM modulation class shall use an MCS from the mandatory MCS set of the
DMG SC modulation class as long as (a) the selected MCS has a Data Rate that does not exceed the Data
Rate of the frame that elicited the response, and (b) no other MCS satisfying condition (a) results in a shorter
frame transmission time.
NOTE—A control response frame is a Control frame that is transmitted within an MPDU as a response to a reception
SIFS after the PPDU containing the frame that elicits the response, e.g., a DMG CTS frame in response to an RTS frame
reception, an Ack frame in response to a Data frame reception, a BlockAck frame in response to a BlockAckReq frame
reception. In some situations, the transmission of some of these Control frames is not a control response transmission,
such as when a DMG CTS frame is used to initiate a TXOP.
Except in an A-MPDU consisting of one of the combinations listed below, the rules in this subclause do not
apply to Control frames that are contained in A-MPDUs that also include at least one MPDU with the Type
subfield equal to Data or Management. In the following cases, the rate selection rules are the same as those
for a standalone Ack or BlockAck frame:
— An Ack frame and a QoS Null frame
— A BlockAck frame and a QoS Null frame
— A BlockAckReq frame and a QoS Null frame
— A BlockAck frame, a BlockAckReq frame, and a QoS Null frame
10.7.7.3 Rate selection for group addressed Data and Management frames transmitted by
DMG STAs
This subclause describes the rate selection rules for group addressed Data and Management frames
transmitted by DMG STAs. The rate selection rules apply only for MCSs defined in Clause 20.
If the transmit antenna pattern of a single transmission of a group addressed frame covers more than one
receiver and the supported MCS set of each of the receivers is known to the sender, then the MCS used for
the transmission shall be an MCS common to the supported MCS sets of all of the receivers. If such an MCS
is not known, the frame shall be transmitted using an MCS from the mandatory MCS set of the DMG control
or SC mode.
If the transmit antenna pattern of a single transmission of a group addressed frame covers only one receiver,
the frame shall be transmitted following the rate selection rules of individually addressed frames as
described in 10.7.7.4.
1357
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.7.7.4 Rate selection for individually addressed Data and Management frames
transmitted by DMG STAs
This subclause describes the rate selection rules for individually addressed Data and Management frames as
transmitted by DMG STAs. The rate selection rules apply only for MCSs defined in Clause 20.
An individually addressed Data or Management frame shall be sent using an MCS supported by the receiver
STA, as reported in the maximum receive MCS subfields in the Supported MCS Set field in Management
frames transmitted by the receiver STA.
When the Supported MCS set of the receiving STA is not known, the transmitting STA shall transmit using
an MCS from the mandatory MCS set of the DMG control or SC mode.
A DMG STA shall transmit a TPA Request frame and a TPA Response frame using MCS 1.
The rules in this subclause also apply to A-MPDUs that contain at least one MPDU with Type subfield equal
to Control and at least one MPDU with Type subfield equal to Data or Management.
10.7.7.5 Rate selection for BRP packets
The first BRP packet transmitted from the initiator to the responder after the SLS phase shall use MCS 0.
The first BRP packet transmitted from the responder to the initiator after the SLS phase shall use MCS 0.
A BRP packet transmitted during beam refinement at the start of a SP (as defined in 10.36.6.2) should use
MCS 0, otherwise a BRP packet transmitted during beam refinement should use MCS 1. A BRP packet
transmitted during beam refinement shall not use any MCS greater than MCS 12.
BRP packets transmitted during the BRP setup subphase, the MID subphase, and the BC subphase shall use
MCS 0.
BRP packets transmitted during a BC subphase, as part of a BC subphase only training, may use MCS 0 to
MCS 12.
BRP packets transmitted during beam tracking may use any MCS.
10.7.8 Multiple BSSID Rate Selection
If the multiple BSSID capability is supported, Beacon frames shall be transmitted using any basic rate valid for
all of the BSSs supported. If no such rate exists, then Beacon frames shall be transmitted using any mandatory
PHY rate for any PHY type that all BSSs have in common.
10.7.9 Modulation classes
Table 10-6 defines modulation classes for the rules for response frames in 9.7.
1358
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-6—Modulation classes
Condition that selects this modulation class
Description of
modulation Clause 15 to Clause 18
Clause 19 PHY Clause 21 PHY
PHYs or Clause 20 PHY
DSSS and HR/ Clause 15 or Clause 16 FORMAT is NON_HT. N/A
DSSS transmission NON_HT_MODULATION is
ERP-DSSS or ERP-CCK.
ERP-OFDM 18.4 transmission FORMAT is NON_HT. N/A
NON_HT_MODULATION is
ERP-OFDM.
OFDM Clause 17 transmission FORMAT is NON_HT. FORMAT is NON_HT.
NON_HT_MODULATION is NON_HT_MODULATION
OFDM or is OFDM
NON_HT_DUP_OFDM. or
NON_HT_DUP_OFDM.
HT N/A FORMAT is HT_MF or FORMAT is HT_MF or
HT_GF. HT_GF.
DMG Control Clause 20 transmission N/A N/A
and MCS is 0
DMG SC Clause 20 transmission N/A N/A
and 1 MCS 12.6
DMG OFDM Clause 20 transmission N/A N/A
and 13 MCS 24
DMG Low-power Clause 20 transmission N/A N/A
SC and 25 MCS 31
VHT N/A N/A FORMAT is VHT.
10.7.10 Non-HT basic rate calculation
This subclause defines how to convert an HT MCS or a VHT-MCS to a non-HT basic rate for the purpose of
determining the rate of the response frame. It consists of two steps as follows:
a) Use the modulation and coding rate determined from the HT MCS (defined in 19.5) or VHT-MCS
(defined in 21.5) to locate a non-HT reference rate by lookup into Table 10-7.29 In the case of an
MCS with UEQM, the modulation of stream 1 is used.
b) The non-HT basic rate is the highest rate in the BSSBasicRateSet that is less than or equal to this
non-HT reference rate.
NOTE—In a TVWS band, the non-HT reference rate is scaled as described in 22.2.4.
29
For example, if an HT PPDU transmission uses 64-QAM and coding rate of 3/4, the related non-HT reference rate is 54 Mb/s.
1359
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-7—Non-HT reference rate
Coding rate Non-HT reference rate
Modulation
(R) (Mb/s)
BPSK 1/2 6
BPSK 3/4 9
QPSK 1/2 12
QPSK 3/4 18
16-QAM 1/2 24
16-QAM 3/4 36
64-QAM 1/2 48
64-QAM 2/3 48
64-QAM 3/4 54
64-QAM 5/6 54
256-QAM 3/4 54
256-QAM 5/6 54
10.7.11 Channel Width in non-HT and non-HT duplicate PPDUs
A non-VHT STA shall include neither the CH_BANDWIDTH_IN_NON_HT parameter nor the
DYN_BANDWIDTH_IN_NON_HT parameter in either of the TXVECTOR or RXVECTOR for NON_HT
PPDUs. A non-VHT STA shall not set the TA field to a bandwidth signaling TA. A VHT STA shall include
neither the CH_BANDWIDTH_IN_NON_HT parameter nor the DYN_BANDWIDTH_IN_NON_HT
parameter in the TXVECTOR of a non-HT PPDU addressed to a non-VHT STA. A VHT STA shall not set
the TA field to a bandwidth signaling TA in a frame addressed to a non-VHT STA. A VHT STA that
includes the DYN_BANDWIDTH_IN_NON_HT parameter in the TXVECTOR shall also include the
CH_BANDWIDTH_IN_NON_HT parameter in the TXVECTOR. A VHT STA shall not include the
DYN_BANDWIDTH_IN_NON_HT parameter in the TXVECTOR for transmitted frames other than RTS
frames with bandwidth signaling TA and that are sent in a non-HT PPDU. A STA that transmits an RTS
frame with a bandwidth signaling TA shall include the DYN_BANDWIDTH_IN_NON_HT parameter in
the TXVECTOR. A VHT STA shall include both the CH_BANDWIDTH_IN_NON_HT and
DYN_BANDWIDTH_IN_NON_HT parameters in the RXVECTOR if the detected PPDU format is
NON_HT.
A bandwidth signaling TA may be included in non-HT and non-HT duplicate PPDUs and shall not be
included in other PPDUs. If the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is present and a
control MPDU other than a CTS is being transmitted, then the TA field shall be set to a bandwidth signaling
TA; otherwise, the TA field shall be set to an individual address.
NOTE—A CTS frame, even though it does not have a TA field, can also be transmitted with the TXVECTOR parameter
CH_BANDWIDTH_IN_NON_HT present.
The TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT shall not be present in PPDUs carrying
Management or Data frames.
1360
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.7.12 Rate selection constraints for VHT STAs
10.7.12.1 Rx Supported VHT-MCS and NSS Set
The Rx Supported VHT-MCS and NSS Set of a first VHT STA is determined by a second VHT STA for
each tuple NSS = 1, …, 8 and bandwidth (20 MHz, 40 MHz, 80 MHz, and 160 MHz or
80+80 MHz) from the Supported VHT-MCS and NSS Set field received from the first STA as follows:
— If support for the VHT-MCS for NSS spatial streams at that bandwidth is mandatory (see 21.5), then
the tuple at that bandwidth is supported by the first STA on receive.
— Otherwise, if the Max VHT-MCS For n SS subfield (n = NSS) in the Rx VHT-MCS Map subfield
indicates support and the Rx Highest Supported Long GI Data Rate subfield is equal to 0, then
— the tuple at that bandwidth is supported by the first STA on receive, except
that if dot11VHTExtendedNSSBWCapable of the second STA is true, the supported
bandwidth values and NSS values of each tuple are updated according
to Table 9-250 if no OMN has been received from the first STA, otherwise, according to
Table 9-75, wherein the VHT Capabilities Information field and the Operating Mode field
have been transmitted by the first STA.
— Otherwise, if the Max VHT-MCS For n SS subfield (n = NSS) in the Rx VHT-MCS Map subfield
indicates support and the data rate for long GI of the MCS for NSS spatial streams at that bandwidth
(expressed as the largest integer in Mb/s that is less than or equal to the data rate) is less than or
equal to the rate represented by the Rx Highest Supported Long GI Data Rate subfield, then
— the tuple at that bandwidth is supported by the first STA on receive, except
that if dot11VHTExtendedNSSBWCapable of the second STA is true, the supported
bandwidth values and NSS values of each tuple are updated according
to Table 9-250 if no OMN has been received from the first STA, otherwise, according to
Table 9-75, wherein the VHT Capabilities Information field and the Operating Mode field
have been transmitted by the first STA.
— Otherwise, the tuple at that bandwidth is not supported by the first STA on
receive.
The tuples excluded by 10.7.12.3 are also eliminated from the Rx Supported VHT-MCS
and NSS Set.
A VHT STA shall not, unless explicitly stated otherwise, transmit a VHT PPDU unless the tuple and bandwidth used are in the Rx Supported VHT-MCS and NSS Set of the receiving STA(s).
NOTE 1—Support for a tuple at a given bandwidth implies support for both long GI and short GI on
receive, if short GI is supported at that bandwidth.
NOTE 2—A STA can determine the expected interpretation of its Supported Channel Width Set and Channel Width and
160/80+80 BW and Extended NSS BW Support fields at a recipient by examining the VHT Extended NSS BW Capable
field value in the Supported VHT-MCS and NSS Set field of the recipient.
10.7.12.2 Tx Supported VHT-MCS and NSS Set
The Tx Supported VHT-MCS and NSS Set of a first VHT STA is determined by a second STA for each
tuple NSS = 1, …, 8 and bandwidth (20 MHz, 40 MHz, 80 MHz, and 160 MHz or
80+80 MHz) from the Supported VHT-MCS and NSS Set field received from the first STA as follows:
— If support for the tuple at that bandwidth is mandatory (see 21.5), then the
tuple at that bandwidth is supported by the first STA on transmit.
— Otherwise, if the Max VHT-MCS for n SS subfield (n = NSS) in the Tx VHT-MCS Map subfield
indicates support and the Tx Highest Supported Long GI Data Rate subfield is equal to 0, then
1361
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— the tuple at that bandwidth is supported by the first STA on transmit,
except that if dot11VHTExtendedNSSBWCapable of the second STA is true, the supported
bandwidth values and NSS values of each tuple are updated according
to Table 9-250 if no OMN has been received from the first STA, otherwise, according to
Table 9-75, wherein the VHT Capabilities Information field and the Operating Mode field
have been transmitted by the first STA.
— Otherwise, if the Max VHT-MCS for n SS subfield (n = NSS) in the Tx VHT-MCS Map subfield
indicates support and the data rate for long GI of the tuple at that bandwidth
(expressed as the largest integer in Mb/s that is less than or equal to the data rate) is less than or
equal to the rate represented by the Tx Highest Supported Long GI Data Rate subfield, then
— the tuple at that bandwidth is supported by the first STA on transmit,
except that if dot11VHTExtendedNSSBWCapable of the second STA is true, the supported
bandwidth values and NSS values of each tuple are updated according
to Table 9-250 if no OMN has been received from the first STA, otherwise, according to
Table 9-75, wherein the VHT Capabilities Information field and the Operating Mode field
have been transmitted by the first STA.
— Otherwise, the tuple at that bandwidth is not supported by the first STA on
transmit.
NOTE 1—In contrast to reception, support for short GI transmissions by a STA cannot be determined by other STAs.
NOTE 2—A STA can determine the expected interpretation of its Supported Channel Width Set and Channel Width and
160/80+80 BW and Extended NSS BW Support fields at a recipient by examining the VHT Extended NSS BW Capable
field value in the Supported VHT-MCS and NSS Set field of the recipient.
10.7.12.3 Additional rate selection constraints for VHT PPDUs
The following apply for a STA that transmits a VHT PPDU with a number of spatial streams (NSS) less than
or equal to 4:
— If the channel width of the PPDU is equal to CBW20 or CBW40, then the STA should not use a
tuple if the VHT-MCS is equal to 0, 1, 2, or 3 and the HT MCS with value
VHT-MCS + 8 (NSS – 1) is marked as unsupported in the Rx MCS bitmask of the HT Capabilities
element of the receiver STA.
— If the channel width of the PPDU is equal to CBW80, CBW160, or CBW80+80, then the STA
should not use a tuple if the VHT-MCS is equal to 0 or 1 and both the HT MCS
values 2 VHT-MCS + 8 (NSS – 1) and 2 (VHT-MCS + 1) + 8 (NSS – 1) are marked as
unsupported in the Rx MCS bitmask of the HT Capabilities element of the receiver STA.
An example tabulation of this behavior is given in Table 10-8.
Table 10-8—Example of rate selection for VHT PPDUs
tuples that tuples that
HT MCSs that are
are not used for are not used for CBW80,
marked as unsupported
CBW20 and CBW40 CBW160, and CBW80+80
0, 8, 16 <0, 1>, <0, 2>, <0, 3> —
1, 9 <1, 1>, <1, 2> —
10 <2, 2> —
3 <3, 1> —
1362
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-8—Example of rate selection for VHT PPDUs (continued)
tuples that tuples that
HT MCSs that are
are not used for are not used for CBW80,
marked as unsupported
CBW20 and CBW40 CBW160, and CBW80+80
0, 1 <0, 1>, <1, 1> <0, 1>
2, 3 <2, 1>, <3, 1> <1, 1>
0, 1, 8, 9 <0, 1>, <1, 1>, <0, 2>, <1, 2> <0, 1>, <0, 2>
10.8 MSDU transmission restrictions
To avoid reordering MSDUs between pairs of LLC entities and/or unnecessarily discarding MSDUs, the
following restrictions shall be observed by any STA that is able to concurrently process multiple outstanding
MSDUs for transmission. The term outstanding refers to an MPDU containing all or part of an MSDU or
MMPDU for which transmission has been started, and for which delivery of the MSDU or MMPDU has not
yet been completed (i.e., an acknowledgment of the final fragment has not been received and the MSDU or
MMPDU has not been discarded due to retries, lifetime, or for some other reason). A STA may have any
number (greater than or equal to one) of eligible MSDUs outstanding concurrently, subject to the restrictions
below.
A non-QoS STA shall not have more than one MSDU or MMPDU from a particular SA to a particular
individual RA outstanding at a time.
NOTE—A simpler, more restrictive alternative to the rule in the above paragraph that might be used is that no more than
one MSDU with a particular individual RA be outstanding at a time.
For frames that are not sent within the context of a block ack agreement, a QoS STA shall not have more than
one MSDU or A-MSDU for each TID or MMPDU from a particular SA to a particular individual RA
outstanding at any time.
NOTE—A simpler, more restrictive alternative to the rule in the above paragraph that might be used is that no more than
one MSDU or A-MSDU with any particular TID with a particular individual RA be outstanding at any time.
In a STA where the optional StrictlyOrdered service class has been implemented, that STA shall not have any
group addressed (multidestination) MSDU of the StrictlyOrdered service class outstanding from the SA of any
other outstanding MSDU (either individual or group addressed). This is because a group addressed MSDU is
implicitly addressed to a collection of peer STAs that could include any individual RA.
A STA should select a value of dot11MaxTransmitMSDULifetime that is sufficiently large that the STA does
not discard MSDUs or A-MSDUs due to excessive Transmit MSDU timeouts under normal operating
conditions.
An A-MSDU shall contain only MSDUs of a single service class and inherits that service class for the purpose
of the following rules. For MSDUs or A-MSDUs belonging to the service class of QoSAck when the receiver
is a QoS STA, set to Normal Ack or Implicit Block Ack Request, PSMP Ack, or Block Ack. For MSDUs or
A-MSDUs belonging to the service class of QoSNoAck when the receiver is a QoS STA, the QoS Data frames
that are used to send these MSDUs or A-MSDUs shall have the Ack Policy subfield in the QoS Control field
set to No Ack.
1363
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.9 HT Control field operation
If dot11HTControlFieldSupported is true, a STA shall set the +HTC-HT Support subfield of the HT Extended
Capabilities field of the HT Capabilities element to 1 in HT Capabilities elements that it transmits. If
dot11VHTControlFieldOptionImplemented is true, a STA shall set the +HTC-VHT Support subfield of the
VHT Capabilities Information field of the VHT Capabilities element to 1 in VHT Capabilities elements that it
transmits.
A STA in which at least one of dot11RDResponderOptionImplemented,
dot11MCSFeedbackOptionImplemented, and dot11AlternateEDCAActivated is true shall set
dot11HTControlFieldSupported or dot11VHTControlFieldOptionImplemented or both to true.
An HT variant HT Control field shall not be present in a frame addressed to a STA unless that STA declares
support for +HTC-HT in the HT Extended Capabilities field of its HT Capabilities element (see 9.4.2.56).
A VHT variant HT Control field shall not be present in a frame addressed to a STA unless that STA declares
support for +HTC-VHT in the VHT Capabilities Information field of its VHT Capabilities element.
NOTE—An HT STA that does not support +HTC (HT or VHT variant) that receives a +HTC frame addressed to another
STA still performs the CRC on the actual length of the MPDU and uses the Duration/ID field to update the NAV, as
described in 10.3.2.4.
If the HT Control field is present in an MPDU aggregated in an A-MPDU, then all MPDUs of the same frame
type (i.e., having the same value of the Type subfield of the Frame Control field) aggregated in the same
A-MPDU shall contain an HT Control field. The HT Control field of all MPDUs containing the HT Control
field aggregated in the same A-MPDU shall be set to the same value.
If the HT variant HT Control field is present in an MPDU, the DEI subfield provides information on the drop
eligibility of the contents of the received MPDU. When there are insufficient resources in a STA, the STA
arbitrarily discards frames in order to recover from the lack of resources. With the information from the DEI
subfield, a STA may selectively drop frames with the DEI subfield set to 1 in preference to frames with the DEI
subfield set to 0, if resources are insufficient. Note that this might not help in the recovery in all conditions, and
the STA might still have to fall back to the arbitrary discard strategy. The mechanisms for determining whether
resources are insufficient or when to discard MSDUs or A-MSDUs are beyond the scope of this standard.
10.10 Control Wrapper operation
A STA supporting the HT Control field that receives a Control Wrapper frame shall process it as though it
received a frame of the subtype of the wrapped frame.
10.11 MSDU processing
A STA can use the U-PID element transmitted in ADDTS Request, DMG ADDTS Request, ADDTS Response
and DMG ADDTS Response frames to indicate the upper layer protocol responsible for handling MSDUs
corresponding to the TID indicated within the frame carrying the U-PID element (see 11.4.4.4).
A STA that participates in a successful ADDTS exchange that included a U-PID element in the ADDTS
Response or DMG ADDTS Response frame with the LLC Header Removed field equal to 1 shall strip the
number of octets in the LLC Header Copy field of the U-PID element from the start of an MSDU (received in
an MA-UNITDATA.request.primitive) corresponding to the TID indicated in the ADDTS exchange before
transmission of the MSDU to the peer STA. The MSDU in the MA-UNITDATA.request.primitive must start
with the octets specified in the LLC Header Copy field.
1364
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—The STA does not verify that the MSDU does indeed start with the octets specified in the LLC Header Copy
field.
A STA that participates in a successful ADDTS exchange that included a U-PID element in the ADDTS
Response or DMG ADDTS Response frame with the LLC Header Removed field equal to 1 and that receives
from the peer STA an MSDU corresponding to the TID indicated in the ADDTS exchange shall insert the
octets in the LLC Header Copy field of the U-PID element at the start of the MSDU before delivery of the
MSDU (in an MA-UNITDATA.indication.primitive).
NOTE—If the LLC Header Removed field is equal to 0, the LLC Header Copy field in the U-PID element is ignored,
except for possible implementation-dependent local optimizations.
10.12 A-MSDU operation
An A-MSDU contains only MSDUs whose DA parameter values map to a single RA value (see 9.3.2.2). An
A-MSDU contains only MSDUs whose SA parameter values map to a single TA value (see 9.3.2.2).
For the Short A-MSDU case, an A-MSDU contains only MSDUs whose SA and DA parameter values are the
same. The Short A-MSDU subframe structure is used only between a pair of STAs that communicate
directly (see 9.3.2.1). The Short A-MSDU subframe structure cannot be used for frame forwarding. The
constituent MSDUs of an A-MSDU shall all have the same priority parameter value from the corresponding
MA-UNITDATA.request primitive.
An A-MSDU shall be carried, without fragmentation, within a single QoS Data frame.
The Address 1 field of an MPDU carrying an A-MSDU shall be set to an individual address or to the GCR
concealment address.
The channel access rules for a QoS Data frame carrying an A-MSDU are the same as a Data frame carrying an
MSDU (or fragment thereof) of the same TID.
The expiration of the A-MSDU lifetime timer occurs only when the lifetime timer of all of the constituent
MSDUs of the A-MSDU have expired.
NOTE 1—This rule implicitly allows an MSDU that is a constituent of an A-MSDU to potentially be transmitted after
the expiration of its lifetime.
NOTE 2—Selecting any other value for the timeout would result in loss of MSDUs. Selecting the maximum value
avoids this loss of MSDUs at the cost of transmitting MSDUs that have exceeded their lifetime.
The following rules apply to the transmission of an A-MSDU:
— A non-DMG STA that has a value of false for dot11HighthroughputOptionImplemented shall not
transmit an A-MSDU.
— A non-DMG STA shall not transmit an A-MSDU to a STA from which it has not received a frame
containing an HT Capabilities element.
A STA shall support the reception of an A-MSDU, where the A-MSDU is carried in a QoS Data frame with
Ack Policy equal to Normal Ack in the following cases:
— By an HT STA when the A-MSDU is not aggregated within an A-MPDU
— By a VHT STA when the A-MSDU is sent as a VHT single MPDU
The use of an A-MSDU carried in a QoS Data frame under a block ack agreement is determined for each block
ack agreement. A STA shall not transmit an A-MSDU within a QoS Data frame under a block ack agreement
1365
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
unless the recipient indicates support for A-MSDU by setting the A-MSDU Supported field to 1 in its
BlockAck Parameter Set field of the ADDBA Response frame.
A STA shall not transmit an A-MSDU to a STA if the A-MSDU length exceeds the value indicated by the
Maximum A-MSDU Length field of the HT Capabilities element received from the recipient STA.
A VHT STA that sets the value of the Maximum MPDU Length subfield in the VHT Capabilities
Information field of the VHT Capabilities element to indicate 3895 octets shall set the Maximum A-MSDU
Length in the HT Capabilities element to indicate 3839 octets. A VHT STA that sets the Maximum MPDU
Length in the VHT Capabilities element to indicate 7991 octets or 11 454 octets shall set the Maximum
A-MSDU Length in the HT Capabilities element to indicate 7935 octets.
The length of an A-MSDU transmitted in a VHT PPDU is limited by the maximum MPDU size supported
by the recipient STA (see 10.13.5).
NOTE 1—An A-MSDU that meets the A-MSDU length limit for transmission in a VHT PPDU might exceed the
A-MSDU length limit for an HT PPDU, in which case it cannot be retransmitted in an HT PPDU.
NOTE 2—Support for A-MSDU aggregation does not affect the maximum size of MSDU transported by the
MA-UNITDATA primitives.
A VHT STA shall not transmit an A-MSDU that includes a number of MSDUs greater than the value indicated
by the Max Number Of MSDUs In A-MSDU field in any Extended Capabilities element sent by the recipient
STA. An HT STA should not transmit an A-MSDU that includes a number of MSDUs greater than the value
indicated by the Max Number Of MSDUs In A-MSDU field in any Extended Capabilities element sent by the
recipient STA.
A DMG STA shall not transmit an A-MSDU that includes a number of Basic A-MSDU subframes greater than
the value indicated by the Maximum Number Of Basic A-MSDU Subframes In A-MSDU subfield in any
DMG Capabilities element sent by the recipient STA. A DMG STA shall not transmit an A-MSDU that
includes a number of Short A-MSDU subframes greater than the value indicated by the Maximum Number Of
Short A-MSDU Subframes In A-MSDU subfield in any DMG Capabilities element sent by the recipient STA.
A DMG STA that sets the A-MSDU Subframe subfield to 1 in a DMG Attributes field of TSPEC element
(9.4.2.30), which indicates Short A-MSDU subframe support, shall be capable of receiving at least 32 Short
A-MSDU subframes in A-MSDU.
The transmitter of frames for a TID established using a PTP TSPEC shall use an A-MSDU subframe format
that is the result of the PTP TSPEC negotiation for that TID. The A-MSDU subframe format is negotiated
using the PTP TSPEC (9.4.2.30): the Short A-MSDU subframe format shall not be used for frames of the
corresponding TID if the A-MSDU subframe field of the PTP TSPEC element is 0 either in the ADDTS
Request frame or in the ADDTS Response frame used to set up the TID. Prior to PTP TSPEC negotiation, a
STA shall use the Basic A-MSDU subframe format if the STA employs MSDU aggregation.
A non-PCP DMG STA in a PBSS may use the PCP of the PBSS to forward MSDUs to another non-PCP
STA in the PBSS if the value of the PCP Forwarding field within the PCP’s DMG Capabilities element is 1.
A non-PCP DMG STA in a PBSS shall not use the PCP to forward MSDUs if the value of the PCP
Forwarding field within the PCP’s DMG Capabilities element is 0. To forward an MSDU via the PCP, a
non-PCP STA shall encapsulate the MSDU within an individually addressed A-MSDU sent to the PCP. The
DA field of the A-MSDU shall be set to the destination’s individual or group address.
1366
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.13 A-MPDU operation
10.13.1 A-MPDU contents
According to its context (defined in Table 9-424), an A-MPDU shall be constrained so that it contains only
MPDUs as specified in the relevant table referenced from Table 9-424.
When an A-MPDU contains multiple QoS Control fields, bits 4 and 8–15 of these QoS Control fields shall be
identical.
A DMG STA that transmits an A-MPDU shall do so only in the Data Enabled Immediate Response context or
the Control Response context, with contents as specified in Table 9-425 and Table 9-428, respectively.
10.13.2 A-MPDU length limit rules
A STA indicates in the Maximum A-MPDU Length Exponent field in its HT Capabilities element the
maximum A-MPDU length that it can receive in an HT PPDU. A STA indicates in the Maximum A-MPDU
Length Exponent field in its VHT Capabilities element the maximum length of the A-MPDU pre-EOF padding
that it can receive in a VHT PPDU. A DMG STA indicates in the Maximum A-MPDU Length Exponent field
in its DMG Capabilities element the maximum A-MPDU length that it can receive. The encoding of these
fields is defined in Table 9-163 for an HT PPDU, in Table 9-249 for a VHT PPDU, and in Table 9-229 for a
DMG STA.
A VHT STA that sets the Maximum A-MPDU Length Exponent field in its VHT Capabilities element to a
value in the range 0 to 3 shall set the Maximum A-MPDU Length Exponent in its HT Capabilities to the same
value. A VHT STA that sets the Maximum A-MPDU Length Exponent field in the VHT Capabilities element
to a value larger than 3 shall set the Maximum A-MPDU Length Exponent in its HT Capabilities element to 3.
Using the Maximum A-MPDU Length Exponent fields in the HT Capabilities and VHT Capabilities elements,
the STA establishes at association the maximum length of an A-MPDU pre-EOF padding that can be sent to it.
An HT STA shall be capable of receiving A-MPDUs of length up to the value indicated by the Maximum A-
MPDU Length Exponent field in its HT Capabilities element. A VHT STA shall be capable of receiving A-
MPDUs where the A-MPDU pre-EOF padding length is up to the value indicated by the Maximum A-MPDU
Length Exponent field in its VHT Capabilities element.
A STA shall not transmit an A-MPDU in an HT PPDU that is longer than the value indicated by the Maximum
A-MPDU Length Exponent field in the HT Capabilities element received from the intended receiver. MPDUs
in an A-MPDU carried in an HT PPDU shall be limited to a maximum length of 4095 octets. A STA shall not
transmit an A-MPDU in a VHT PPDU where the A-MPDU pre-EOF padding length is longer than the value
indicated by the Maximum A-MPDU Length Exponent field in the VHT Capabilities element received from
the intended receiver. A DMG STA shall not transmit an A-MPDU that is longer than the value indicated by
the Maximum A-MPDU Length Exponent field in the DMG Capabilities element received from the intended
receiver.
10.13.3 Minimum MPDU Start Spacing field
A STA shall not start the transmission of more than one MPDU within the time limit described in the
Minimum MPDU Start Spacing field declared by the intended receiver. To satisfy this requirement, the number
of octets between the start of two consecutive MPDUs in an A-MPDU, measured at the PHY SAP, shall be
equal to or greater than
t MMSS r 8
1367
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
t MMSS is the time (in microseconds) defined in the “Encoding” column of Table 9-163 for an HT STA
and of Table 9-229 for a DMG STA for the value of the Minimum MPDU Start Spacing field
r is the value of the PHY Data Rate (in megabits per second) defined in 19.5 for HT PPDUs, in
21.5 for VHT PPDUs, and in Clause 20 for a DMG STA
If necessary, in order to satisfy this requirement, a STA shall add padding between MPDUs in an A-MPDU.
Any such padding shall be in the form of one or more MPDU delimiters with the MPDU Length field set to 0.
QoS Null frames transmitted by DMG STAs are not subject to this spacing, i.e., no MPDU delimiters with zero
length need to be inserted after the MPDU immediately preceding the QoS Null frame in an A-MPDU.
10.13.4 A-MPDU aggregation of group addressed Data frames
A STA that is neither an AP nor a mesh STA shall not transmit an A-MPDU containing an MPDU with a
group addressed RA.
NOTE 1—An HT AP and an HT mesh STA can transmit an A-MPDU containing MPDUs with a group addressed RA.
NOTE 2—As a VHT STA is an HT STA, NOTE 1 also applies to VHT APs and VHT mesh STAs.
NOTE 3—An AP providing GCR service can transmit an A-MPDU containing MPDUs with a group addressed RA.
A STA that is an AP or a mesh STA shall not transmit an A-MPDU containing group addressed MPDUs if the
HT Protection field is equal to non-HT mixed mode.
A DMG STA may transmit an A-MPDU containing MPDUs with a group addressed RA.
When a STA transmits a PPDU containing at least one A-MPDU that contains MPDUs with a group addressed
RA, the following shall apply:
— If the PPDU is an HT PPDU transmitted by an AP, the maximum A-MPDU length exponent value is
the minimum value in the Maximum A-MPDU Length Exponent subfield of the A-MPDU
Parameters field of the HT Capabilities element of all HT STAs associated with the AP.
— If the PPDU is an HT PPDU transmitted by a mesh STA, the maximum A-MPDU length exponent
value is the minimum value in the Maximum A-MPDU Length Exponent subfield of the A-MPDU
Parameters field of the HT Capabilities element of all peer HT mesh STAs.
— If the PPDU is a VHT PPDU, the value of maximum A-MPDU length exponent that applies is the
minimum value in the Maximum A-MPDU Length Exponent subfields of the A-MPDU Parameters
fields of the VHT Capabilities elements across all VHT STAs associated with the transmitting AP or
across all peer VHT mesh STAs.
— If the PPDU is a VHT PPDU, the value of minimum MPDU start spacing that applies is the
maximum value in the Minimum MPDU Start Spacing subfields of the A-MPDU Parameters fields
of the HT Capabilities elements across all VHT STAs associated with the transmitting AP or across
all peer VHT mesh STAs of the transmitting mesh STA.
— If the PPDU is an HT PPDU transmitted by an AP, the minimum MPDU start spacing value that
applies is the maximum value in the Minimum MPDU Start Spacing subfield of the A-MPDU
Parameters field of the HT Capabilities element of all HT STAs associated with the AP.
— If the PPDU is an HT PPDU transmitted by a mesh STA, the minimum MPDU start spacing value
that applies is the maximum value in the Minimum MPDU Start Spacing subfield of the A-MPDU
Parameters field of the HT Capabilities element of all peer HT mesh STAs.
— If the PPDU is a DMG PPDU, the maximum A-MPDU length exponent value that applies is the
minimum value in the Maximum A-MPDU Length Exponent subfield of the A-MPDU Parameters
field of the DMG Capabilities element of all DMG STAs associated with the AP or PCP.
1368
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— If the PPDU is a DMG PPDU, the minimum MPDU start spacing value that applies is the maximum
value in the Minimum MPDU Start Spacing subfield of the A-MPDU Parameters field of the DMG
Capabilities element of all DMG STAs associated with the AP or PCP.
10.13.5 Transport of A-MPDU by the PHY data service
An A-MPDU shall be transmitted in a PSDU associated with a PHY-TXSTART.request primitive with the
TXVECTOR parameter AGGREGATION set to 1 or the TXVECTOR parameter FORMAT set to VHT. A
received PSDU is determined to be an A-MPDU when the associated PHY-RXSTART.indication primitive
RXVECTOR parameter AGGREGATION is equal to 1 or the RXVECTOR parameter FORMAT is equal to
VHT.
10.13.6 A-MPDU padding for VHT PPDU
A VHT STA that transmits a VHT PPDU that contains one or more PSDUs, each of which contains an
A-MPDU, shall construct the A-MPDU(s) as described in this subclause.
An A-MPDU pre-EOF padding (see 10.13.2) is constructed for each user from any of the following:
— A-MPDU subframes constructed from the MPDUs available for transmission that have a TID value
that maps to the primary AC
— A-MPDU subframes with 0 in the MPDU Length field and 0 in the EOF field
provided that each added subframe and the A-MPDU pre-EOF padding meet all of the following:
— A-MPDU content constraints (see 10.13.1) for the intended recipient
— Format and length limit constraints (see 9.7.1 and 10.13.2) for the intended recipient
— Minimum MPDU start spacing constraints (see 10.13.3) for the intended recipient
— TXOP duration limits (see 10.22.2.8) for the primary AC
The A-MPDU_Length[n] for user n is initialized as the length of the resulting A-MPDU pre-EOF padding.
This initial value of A-MPDU_Length[n] for user n is used as the APEP_LENGTH[n] parameter value for
the PLME-TXTIME.request primitive (see 6.5.5). The PLME-TXTIME.request primitive is then invoked
once for the VHT PPDU. The PLME-TXTIME.confirm primitive (see 6.5.6) provides the TXTIME
parameter and PSDU_LENGTH[] parameters for all of the users for the transmission.
Subsequently, for each user n, as permitted by the rules for EDCA TXOP Sharing (see 10.22.2.6), a VHT
STA may add A-MPDU subframes to the A-MPDU for that user that meets either of the following
conditions:
— Have a TID that maps to an AC that is not the primary AC
— Have 0 in the MPDU Length field and 0 in the EOF field
provided that each added subframe and the resulting A-MPDU meet all of the following:
— A-MPDU content constraints (see 10.13.1) for the intended recipient
— Length limit constraints (see 9.7.1 and 10.13.2) for the intended recipient
— MPDU start spacing constraints (see 10.13.3) for the intended recipient
and provided that, after incrementing the A-MPDU_Length[n] with the length of each such added A-MPDU
subframe, the relationship A-MPDU_Length[n] PSDU_LENGTH[n] is true.
1369
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Subsequently, for each user n, a VHT STA may add A-MPDU subframes to the A-MPDU for that user that
meet the following condition:
— Have 0 in the MPDU Length field
provided that each added subframe and the resulting A-MPDU meet the following condition:
— Length limit constraints (see 9.7.1 and 10.13.2) for the intended recipient
and provided that, after incrementing the A-MPDU_Length[n] with the length of each such added A-MPDU
subframe, the relationship A-MPDU_Length[n] PSDU_LENGTH[n] is true.
An implementation may reduce the A-MPDU_Length[n] by the amount of padding for user n that was added
subsequent to the addition of a subframe for user n that contains 1 in the EOF field.
The final value of A-MPDU_Length[] shall be used as APEP_LENGTH[] in the PHY-TXSTART.request
primitive for the VHT PPDU.
Padding is then added for each user such that the resulting A-MPDU contains exactly PSDU_LENGTH
octets for that user as follows:
— First, while A-MPDU_Length[n] < PSDU_LENGTH[n] and A-MPDU_Length[n] mod 4 0, add
an octet to the final A-MPDU subframe’s Padding subfield and increment A-MPDU_Length[n] by 1.
— Then, while A-MPDU_Length[n] + 4 PSDU_LENGTH[n], add an EOF padding subframe to the
EOF Padding Subframes field and increment A-MPDU_Length[n] by 4.
— Finally, while A-MPDU_Length[n] < PSDU_LENGTH[n], add an octet to the EOF Padding Octets
subfield and increment A-MPDU_Length[n] by 1.
An A-MPDU subframe with EOF set to 0 shall not be added after any A-MPDU subframe with EOF set to 1.
An A-MPDU subframe with EOF set to 1 and with MPDU Length field set to 0 shall not be added before an A-
MPDU subframe that contains a VHT single MPDU (see 10.13.7).
10.13.7 Setting the EOF field of the MPDU delimiter
The EOF field may be set to 1 in an A-MPDU subframe carried in a VHT PPDU if the subframe’s MPDU
Length field is nonzero and the subframe is the only subframe that has a nonzero MPDU Length field. The
EOF field of each A-MPDU subframe with an MPDU Length field with a nonzero value that is not the only A-
MPDU subframe with MPDU Length field with a nonzero value in the A-MPDU carried in a VHT PPDU shall
be set to 0. The EOF field shall be set to 0 in all A-MPDU subframes that are carried in an HT PPDU.
An MPDU that is the only MPDU in an A-MPDU and that is carried in an A-MPDU subframe with 1 in the
EOF field is called a VHT single MPDU.
10.13.8 Transport of VHT single MPDUs
The rules for VHT single MPDU operation are the same as the rules for non-A-MPDU frame operation with
other types of non-A-MPDU.
NOTE—This affects the following behavior:
— The frame could carry a fragment of an MSDU or MMPDU (see 10.2.7).
— Rate selection of control responses (see 10.7).
— A Data frame cannot indicate an Ack Policy of “Implicit Block Ack”, and does not generate a BlockAck frame
response (see 9.2.4.5.4).
— A Data frame could indicate an Ack Policy of “Normal Ack”, which solicits an Ack frame immediate response.
No block ack agreement is needed in this case (see 9.2.4.5.4).
— The frame could be a Management frame that solicits an Ack frame response (see 9.7.3).
1370
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.14 PPDU duration constraint
A STA shall not transmit an HT PPDU that has a duration (as determined by the PHY-TXTIME.confirm
primitive defined in 6.5.6 that is greater than aPPDUMaxTime defined in Table 19-25.
A STA shall not transmit a DMG PPDU that has a duration (as determined by the PHY-TXTIME.confirm
primitive defined in 6.5.6 that is greater than aPPDUMaxTime defined in Table 20-32.
A STA shall not transmit a VHT PPDU that has a duration (as determined by the PHY-TXTIME.confirm
primitive defined in 6.5.6 that is greater than aPPDUMaxTime defined in Table 21-29.
A STA shall not transmit a VHT PPDU in TVWS bands that has a duration (as determined by the PHY-
TXTIME.confirm primitive defined in 6.5.6 that is greater than aPPDUMaxTime defined in Table 22-25.
10.15 DMG A-PPDU operation
A DMG STA is aggregate PPDU (A-PPDU) capable if the A-PPDU supported field within the STA’s DMG
Capabilities element is 1. Otherwise, the STA is not A-PPDU capable.
A DMG STA shall not transmit an A-PPDU aggregate to a STA that is not A-PPDU capable.
An A-PPDU is a sequence of two or more PPDUs transmitted without IFS, preamble, and with a PHY-
dependent separation between PPDU transmissions. All PPDUs within an A-PPDU shall have the ADD-
PPDU parameter of the TXVECTOR set to ADD-PPDU, except for the last PPDU in the A-PPDU that shall
have this parameter set to NO-ADD-PPDU. The value of a TXVECTOR parameter of a PPDU belonging to
an A-PPDU might differ from the value of the same TXVECTOR parameter of another PPDU in the same
A-PPDU, including the MCS parameter.
A PPDU within an A-PPDU shall contain an A-MPDU. All MPDUs within A-MPDUs within an A-PPDU
shall have the same values for the TA and RA fields. All QoS Data frames within A-MPDUs within an A-
PPDU shall have the same value of the Ack Policy subfield of the QoS Control field. If a frame that requires
an immediate response is present within an A-PPDU, it shall be transmitted in the last A-MPDU of the A-
PPDU.
The transmission duration of an A-PPDU shall be no greater than aPPDUMaxTime (see Table 20-32).
10.16 LDPC operation
An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_MF or HT_GF
and the TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame
corresponds to an HT STA for which the LDPC Coding Capability subfield of the HT Capabilities element
received from that STA contained a value of 1 and dot11LDPCCodingOptionActivated is true.
A VHT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to VHT and the
TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame corresponds to a
VHT STA for which the Rx LDPC subfield of the VHT Capabilities element received from that STA contained
a value of 1 and dot11VHTLDPCCodingOptionActivated is true.
A VHT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to VHT and the
TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame corresponds to a
VHT STA for which the Rx LDPC subfield of the VHT Capabilities element received from that STA
contained a value of 1 and dot11VHTLDPCCodingOptionActivated is true.
1371
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA should not transmit a frame with the TXVECTOR parameter FORMAT set to HT_MF, HT_GF or
VHT and the TXVECTOR parameter FEC_CODING set to LDPC_CODING if the RA of the frame
corresponds to a STA from which it has received a frame containing an Operating Mode field and the most
recent Operating Mode field it has received from that STA had the No LDPC subfield equal to 1.
Further restrictions on TXVECTOR parameter values may apply due to rules found in 10.26 and 10.7.
10.17 STBC operation
A STA that has not set the Tx STBC subfield to 1 in the HT Capabilities element shall not transmit HT PPDUs
with a TXVECTOR parameter STBC set to a nonzero value. A STA that has not set the Tx STBC subfield to 1
in the VHT Capabilities element shall not transmit VHT SU PPDUs with a TXVECTOR parameter STBC set
to a nonzero value.
A STA shall not send an HT PPDU with the TXVECTOR parameter STBC set to a nonzero value to a recipient
STA unless the recipient STA has indicated in the Rx STBC field of its HT Capabilities element that it supports
the reception of PPDUs using STBC with a number of spatial streams greater than or equal to the number of
spatial streams in the HT PPDU. A STA shall not send a VHT PPDU with the TXVECTOR parameter STBC
set to a nonzero value to a recipient STA unless the recipient STA has indicated in the Rx STBC field of its
VHT Capabilities element that it supports the reception of PPDUs using STBC with a number of spatial
streams greater than or equal to the number of spatial streams in the VHT PPDU.
10.18 Short GI operation
A STA may transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to CBW20 and GI_TYPE
set to SHORT_GI only if all of the following conditions are met:
— The STA is an HT STA.
— The TXVECTOR parameter FORMAT is equal to HT_MF, HT_GF, or VHT.
— The RA of the frame corresponds to a STA for which the Short GI for 20 MHz subfield of the HT
Capabilities element contained a value of 1.
— dot11ShortGIOptionInTwentyActivated is present and is true.
A STA may transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to CBW40 and GI_TYPE
set to SHORT_GI only if all of the following conditions are met:
— The STA is an HT STA.
— The TXVECTOR parameter FORMAT is equal to HT_MF, HT_GF, or VHT.
— The RA of the frame corresponds to a STA for which the Short GI for 40 MHz subfield of the HT
Capabilities element contained a value of 1.
— dot11ShortGIOptionInFortyActivated is present and is true.
A STA shall not transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to CBW80 and
GI_TYPE set to SHORT_GI unless all of the following conditions are met:
— The STA is a VHT STA.
— The TXVECTOR parameter FORMAT is equal to VHT.
— The RA of the frame corresponds to a STA for which the Short GI for 80 MHz/TVHT_MODE_4C
subfield of the VHT Capabilities element contained a value of 1.
— dot11VHTShortGIOptionIn80Activated is present and is true.
1372
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA may transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to CBW160 or
CBW80+80 and GI_TYPE set to SHORT_GI only if all of the following conditions are met:
— The STA is a VHT STA.
— The TXVECTOR parameter FORMAT is equal to VHT.
— The RA of the frame corresponds to a STA for which the Short GI for 160 and 80+80 MHz subfield
of the VHT Capabilities element contained a value of 1.
— dot11VHTShortGIOptionIn160and80p80Activated is present and is true.
A STA may transmit a frame with TXVECTOR parameters FORMAT set to VHT, NUM_USERS set to
greater than 1, and GI_TYPE set to SHORT_GI only if all of the following conditions are met:
— The STA is a VHT STA.
— The TXVECTOR parameter FORMAT is equal to VHT.
— The RAs of all MPDUs in the VHT MU PPDU correspond to STAs for which the Short GI subfield
of the following conditions are satisfied:
— If the TXVECTOR parameter CH_BANDWIDTH is set to CBW20, the Short GI for 20 MHz
subfields of the HT Capabilities element contained a value of 1, and
dot11ShortGIOptionInTwentyActivated is present and is true.
— If the TXVECTOR parameter CH_BANDWIDTH is set to CBW40, the Short GI for 40 MHz
subfields of the HT Capabilities element contained a value of 1, and
dot11ShortGIOptionInFortyActivated is present and is true.
— If the TXVECTOR parameter CH_BANDWIDTH is set to CBW80, the Short GI for
80 MHz/TVHT_MODE_4C subfields of the VHT Capabilities element contained a value of 1,
and dot11VHTShortGIOptionIn80Activated is present and is true.
— If the TXVECTOR parameter CH_BANDWIDTH is set to CBW160 or CBW80+80, the Short
GI for 160 MHz and 80+80 MHz subfields of the VHT Capabilities element contained a value of
1, and dot11VHTShortGIOptionIn160and80p80Activated is present and is true.
An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_GF and the
GI_TYPE parameter set to SHORT_GI when the MCS parameter indicates a single spatial stream.
Further restrictions on TXVECTOR parameter values may apply due to rules found in 10.26 and 10.7.
10.19 Greenfield operation
An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_GF unless the
RA of the frame corresponds to a STA for which the HT-Greenfield subfield of the HT Capabilities element
contained a value of 1 and dot11HTGreenfieldOptionActivated is true. Further restrictions may apply due to
rules found in 10.26, 10.7, and 11.9.8.5.
10.20 Group ID and partial AID in VHT PPDUs
The partial AID is a nonunique STA identifier defined in Table 10-9. The partial AID is carried in the
TXVECTOR parameter PARTIAL_AID of a VHT SU PPDU and is limited to 9 bits.
A STA transmitting a VHT SU PPDU carrying one or more group addressed MPDUs or transmitting a VHT
NDP intended for multiple recipients shall set the TXVECTOR parameters GROUP_ID to 63 and
PARTIAL_AID to 0. The intended recipient of a VHT NDP is defined in 10.34.6.
1373
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA transmitting a VHT SU PPDU carrying one or more individually addressed MPDUs or a VHT NDP
intended for a single recipient shall set the TXVECTOR parameters GROUP_ID and PARTIAL_AID as
shown in Table 10-9.
Table 10-9—Settings for the TXVECTOR parameters GROUP_ID and PARTIAL_AID
Condition GROUP_ID PARTIAL_AID
Addressed to AP 0 BSSID[39:47]
Addressed to Mesh STA 0 RA[39:47]
Sent by an AP and 5 9
addressed to a STA AID + BSSID[44:47] BSSID[40:43] 2 mod 2 (10-12)
associated with that AP
or 63
sent by a DLS or TDLS
STA in a direct path to a
DLS or TDLS peer STA
Otherwise (see NOTE) 63 0
NOTE—The last row covers the following cases:
— A PPDU sent to an IBSS STA
— A PPDU sent by an AP to a non associated STA
— Any other condition not explicitly listed elsewhere in the table
In Table 10-9, BSSID[b:c] and RA[b:c] represent bits b to c inclusive of the BSSID and RA, respectively,
with bit 0 being the Individual/Group bit and bit 47 being the last transmitted bit, in which bit position b is
0 c–b
then scaled by 2 and c by 2 .
A STA shall include the values computed in Table 10-9 in the PHYCONFIG_VECTOR parameters
PARTIAL_AID_LIST_GID00 and PARTIAL_AID_LIST_GID63.
A STA that transmits a VHT PPDU to a DLS or TDLS peer STA obtains the AID for the peer STA from the
DLS Setup Request, DLS Setup Response, TDLS Setup Request or TDLS Setup Response frame.
An AP should not assign an AID to a STA that results in a 0 value PARTIAL_AID (as computed using
Equation (10-12)).
A STA transmitting a VHT MU PPDU sets the TXVECTOR parameter GROUP_ID as described in 21.3.11.4.
As an example of the GROUP_ID and PARTIAL_AID setting, consider the case of a BSS with BSSID 00-21-
6A-AC-53-5230 that has as a member a non-AP STA assigned AID 5. In VHT PPDUs sent to an AP, the
GROUP_ID is set to 0 and the PARTIAL_AID is set to 164. In VHT PPDUs sent by the AP to the non-AP
STA associated with that AP, the GROUP_ID is set to 63 and PARTIAL_AID is set to 229.
30As
described in IEEE Std 802-2014, the use of hyphens for the BSSID indicates hexadecimal representation rather
than bit-reversed representation.
1374
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.21 Operation across regulatory domains
10.21.1 General
The PHY of a WLAN is subject to regulations that might vary significantly from one regulatory domain to
another. This subclause provides the framework for operation across regulatory domains and describes the
mechanism that supports cross-domain mobility and operation in multiple regulatory domains. When this
mechanism is active, dot11MultiDomainCapabilityActivated attribute be true.
NOTE—This subclause does not eliminate the need to obtain type acceptance, regulatory approval, equipment
authorization, or equipment certification in each of the regulatory domains in which the equipment operates. The
mechanisms described in this subclause provide the information to the STA to identify the regulatory domain in which it
is located and to cease operation while in those domains for which it does not have type approval. It is incumbent upon
the implementer to provide proof of compliance to the requirements of individual regulatory agencies.
The method for configuring individual STAs is outside the scope of this standard. A STA needs to be properly
configured for operation in a particular regulatory domain prior to beginning normal operation. Particular care
needs to be taken when operating in an IBSS configuration.
10.21.2 Operation upon entering a regulatory domain
A STA that is enabled for operation across regulatory domains uses passive scanning when it has lost
connectivity with its ESS. Passive scanning is performed using only the receive capabilities of the STA and is,
thus, compatible with regulatory requirements. The timeout for determining the loss of connectivity is system
dependent and beyond the scope of this standard.
When a STA with dot11MultiDomainCapabilityActivated true enters a regulatory domain, before transmitting,
it shall passively scan to learn at least one valid channel, i.e., a channel upon which it detects IEEE 802.11
frames. The Beacon frame transmitted by non-DMG STAs and the DMG Beacon or Announce frame
transmitted by DMG STAs contains information on the country code, the maximum allowable transmit power,
and the channels that may be used for the regulatory domain. Optionally, these frames may also include in the
Country element, on a periodic basis, the regulatory information that would be returned in a Probe Response
frame. When DSE dependent STA operation is required in a regulatory domain, a dependent STA may be
required to receive a Beacon, DMG Beacon, or an Announce frame signaling dependent enablement (11.12.5),
and until one of these frames is received, the STA may continue passive scanning to receive one such frame
directly from an enabling STA. Once the STA has acquired the information so that it is able to meet the
transmit requirements of the regulatory domain, it shall transmit a Probe Request frame to an AP or PCP to
gain the additional necessary regulatory domain information contained in the Probe Response frame, unless the
information was previously received in a Beacon, DMG Beacon, or Announce frame. The STA then has
sufficient information available to configure its PHY for operation in the regulatory domain.
10.21.3 Operation with operating classes
The following, and only the following, are extended spectrum management capable: a VHT STA and a STA
that has dot11ExtendedSpectrumManagementImplemented true. A non-VHT STA that has
dot11ExtendedSpectrumManagementImplemented true shall indicate that it is extended spectrum management
capable using the Extended Spectrum Management Capable field of the Extended Capabilities element.
When communicating with a STA that supports global operating classes, all requests and Action frames that
convey elements containing operating classes shall use global operating class values.
When dot11OperatingClassesImplemented is true, the following statements apply:
— When dot11OperatingClassesRequired is false, or where operating classes domain information is
not present in a STA, that STA is not required to change its operation in response to an element that
contains an operating class.
1375
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— When dot11OperatingClassesRequired is true, or where operating classes domain information is
present in a STA, the STA shall indicate current operating class information in the Country element
and Supported Operating Classes element, except that a VHT STA may omit, from the Country
element, any Operating Triplet field for an Operating Class for which the Channel spacing (MHz)
column indicates 80 MHz or wider and for which the Behavior limits set column in the applicable
table in Annex E contains only a blank entry or either or both of “80+” and
“UseEirpForVHTTxPowEnv.”
— When dot11OperatingClassesRequired and dot11ExtendedChannelSwitchActivated are true and a
STA is capable of operating as specified in more than one operating class, the STA shall include the
Supported Operating Classes element in Association frames and Reassociation frames.
— When dot11OperatingClassesRequired is true, or where operating classes domain information is
present and the STA parsing a Country element finds an invalid First Channel Number field or
Operating Class field with a value that is reserved, the STA shall ignore the remainder of the
Country element and shall parse any remaining management frame body for additional elements.
— When dot11OperatingClassesRequired is true and the STA supports one or more global operating
classes, or where global operating classes domain information is present in a STA, the STA shall
indicate current operating class information in the Country element and Supported Operating
Classes element using the country string for the global operating classes, except that a VHT STA
may omit from the Country element any Operating Triplet field for an Operating Class for which the
Channel spacing (MHz) column indicates 80 MHz or wider and for which the Behavior limits set
column in the applicable table in Annex E contains only a blank entry or either or both of “80+” and
“UseEirpForVHTTxPowEnv.”
10.21.4 Operation with the Transmit Power Envelope element
A STA that is extended spectrum management capable and that has dot11SpectrumManagementRequired or
dot11RadioMeasurementActivated equal to true shall determine a local maximum transmit power from a
Transmit Power Envelope element for which the Local Maximum Transmit Power Unit Interpretation subfield
indicates EIRP.
A STA that sends two or more Transmit Power Envelope elements in a frame shall order the elements by
increasing values of their Local Maximum Transmit Power Unit Interpretation subfields.
If a STA that is extended spectrum management capable finds an unknown value in the Local Maximum
Transmit Power Unit Interpretation subfield in a Transmit Power Envelope element, then the STA shall ignore
that and subsequent Transmit Power Envelope elements.
A STA that receives two or more Transmit Power Envelope elements in the same frame with known values in
their Local Maximum Transmit Power Unit Interpretation subfields shall process all of the elements according
to the local regulations known at the STA.
NOTE—If a STA receives two Transmit Power Envelope elements, each with a known value in the Local Maximum
Transmit Power Unit Interpretation subfield, then the expected possibilities are as follows:
— The STA complies with either element (shared spectrum),
— The STA complies with both elements (tightened regulations), or
— The STA complies with the second element (changed regulations).
10.21.5 Operation with coverage classes
The attribute aSlotTime and other MAC timings are based on the PHY timing parameters, as specified in
10.3.2.3, 10.3.7 and 10.22.2.5, and in particular on aAirPropagationTime. If dot11OperatingClassesRequired
is true, it is possible to manage the MAC timings of STAs to increase fairness in contending for the medium.
Radio waves propagate at ~300 m/µs in free space, and, for example, 3 µs would be the ceiling for BSS
maximum one-way distance of ~450 m (~900 m round trip). The Coverage Class field of the Country element
1376
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
indicates a value of aAirPropagationTime (see Table 9-79), and the MAC can use the value to calculate
aSlotTime (as specified in the relevant PHY clause) and other timings.
If dot11OperatingClassesRequired is true and a Country element containing a Coverage Class field has been
received from the AP of the BSS with which a STA is associated, from the DO of the IBSS of which a STA is
a member, or from another mesh STA in the same MBSS, an associated STA, dependent STA, member of an
IBSS, or member of an MBSS shall, if the relevant PHY clause specifies that aAirPropagationTime is indicated
by the coverage class, use MAC timings that correspond to the value of aAirPropagationTime indicated (as
specified in the relevant PHY clause).
NOTE 1—Some PHYs do not specify a dependency of aSlotTime on aAirPropagationTime.
NOTE 2—Operation over larger BSS diameters is facilitated by relaxing some PHY timing parameters, while
maintaining compatibility with existing implementations in small BSS diameters.
aAirPropagationTime is 0 µs if:
— the relevant PHY clause specifies that aAirPropagationTime is indicated by the coverage class, and
— at least one of the following applies:
— dot11OperatingClassesRequired is false
— no Country element containing a Coverage Class field has been received from the AP of the
BSS with which a STA is associated, from the DO of the IBSS of which a STA is a member, or
from another mesh STA in the same MBSS
10.22 HCF
10.22.1 General
Under HCF, the basic unit of allocation of the right to transmit onto the WM is the TXOP. Each TXOP is
defined by a starting time and a defined maximum length. In a non-DMG BSS, the TXOP may be obtained by
a STA winning an instance of EDCA contention (see 10.22.2) during the CP or by a STA receiving a QoS
(+)CF-Poll frame (see 10.22.3) during the CP or CFP. The former is called EDCA TXOP, while the latter is
called HCCA TXOP or polled TXOP.
In a DMG BSS, the EDCAF operates only during CBAPs. Operation of the EDCAF is suspended at the end of
a CBAP and is resumed at the beginning of the following CBAP. See 10.36.5 and 10.36.5 for additional rules
regarding contention based access in DMG BSSs.
HCCA is not used by DMG STAs.
10.22.2 HCF contention based channel access (EDCA)
10.22.2.1 Reference model
The EDCA channel access protocol is derived from the DCF procedures described in 10.3 by adding four
independent enhanced distributed channel access functions (EDCAFs) to provide differentiated priorities to
transmitted traffic, through the use of four different access categories (ACs).
For the case in which dot11AlternateEDCAActivated is false or not present, a model of the reference
implementation is shown in Figure 10-24 and for the case in which dot11AlternateEDCAActivated is true, a
model is shown in Figure 10-25. These figures illustrate a mapping from frame type or UP to the transmit
queues and the four independent EDCAFs. The mapping of UP to the transmit queue and the mapping to AC
are described in 10.2.4.2 and Table 10-1. The mapping of frame types to ACs is also described in 10.2.4.2.
1377
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(MSDU, UP)
Mapping to
Access Category
VO VI BE BK
Transmit queues
for ACs
Per-queue EDCA
functions with
VO VI BE BK internal collision
resolution
Figure 10-24—Reference implementation model when dot11AlternateEDCAActivated is
false or not present
(MSDU, UP)
Mapping to transmit
queue and access
category
VO A_VO A_VI VI BE BK
Transmit
queues
VO VI BE BK EDCA functions
with internal
collision resolution
Figure 10-25—Reference implementation model when
dot11AlternateEDCAActivated is true
A DMG STA may implement a single AC. If the STA implements a single AC, all UP and frame types shall
be mapped to AC_BE.
NOTE—A DMG STA that implements a single AC has only one queue in Figure 10-24.
1378
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.22.2.2 EDCA backoff procedure
Each EDCAF shall maintain a state variable CW[AC], which shall be initialized to the value of the parameter
CWmin[AC], for that EDCAF’s AC.
For the purposes of this subclause, transmission failure of an MPDU is defined as follows:
— After transmitting an MPDU (even if it is carried in an A-MPDU or as part of a VHT MU PPDU that
is sent using TXVECTOR parameter NUM_USERS > 1) that requires an immediate response:
— The STA shall wait for a timeout interval of duration aSIFSTime + aSlotTime +
aRxPHYStartDelay, starting when the MAC receives a PHY-TXEND.confirm primitive. If a
PHY-RXSTART.indication primitive does not occur during the timeout interval, the
transmission of the MPDU has failed.
— If a PHY-RXSTART.indication primitive does occur during the timeout interval, the STA shall
wait for the corresponding PHY-RXEND.indication primitive to recognize a valid response
MPDU (see Annex G) that either does not have a TA field or is sent by the recipient of the
MPDU requiring a response. If anything else, including any other valid frame, is recognized,
the transmission of the MPDU has failed.
— The nonfinal (re)transmission of an MPDU that is delivered using the GCR unsolicited retry
retransmission policy (10.22.2.11.2)) is defined to be a failure.
— In all other cases, the transmission of the MPDU has not failed.
The TXNAV timer is a single timer, shared by the EDCAFs within a STA, that is initialized with the duration
from the Duration/ID field in the frame most recently successfully transmitted by the TXOP holder, except for
PS-Poll frames. The TXNAV timer begins counting down from the end of the transmission of the PPDU
containing that frame. An HT STA may retransmit unacknowledged MPDUs within the same TXOP or in a
subsequent TXOP. The Reservation Allocation Vector (RAV) timer for a mesh STA that has
dot11MCCAActivated true is initialized with the MCCAOP Duration in the MCCAOP Reservation field at the
start of an MCCAOP reservation. The RAV timer begins counting down from the start of an MCCAOP
reservation (see 10.23.3.9.2).
The backoff procedure shall be invoked by an EDCAF when any of the following events occurs:
a) An MA-UNITDATA.request primitive is received that causes a frame with that AC to be queued for
transmission such that one of the transmit queues associated with that AC has now become non-
empty and any other transmit queues associated with that AC are empty; the medium is busy on the
primary channel as indicated by any of the following:
— physical CS;
— virtual CS;
— a nonzero TXNAV timer value;
— a mesh STA that has dot11MCCAActivated true and a nonzero RAV timer value, and the
backoff timer has a value of 0 for that AC.
b) The transmission of the MPDU in the final PPDU transmitted by the TXOP holder during the TXOP
for that AC has completed and the TXNAV timer has expired, and the AC was a primary AC. (See
10.22.2.6).
c) The transmission of an MPDU in the initial PPDU of a TXOP fails, as defined in this subclause, and
the AC was a primary AC.
d) The transmission attempt collides internally with another EDCAF of an AC that has higher priority,
that is, two or more EDCAFs in the same STA are granted a TXOP at the same time.
1379
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
e) The transmission attempt of a STA coordinated by an MM-SME collides internally with another
STA coordinated by the same MM-SME (see 11.34), which is indicated to the first MAC entity with
a PHY-TXBUSY.indication(BUSY) primitive as response to the PHY-TXSTART.request
primitive.
In addition, the backoff procedure may be invoked by an EDCAF when:
f) The transmission by the TXOP holder of an MPDU in a non-initial PPDU of a TXOP fails, as
defined in this subclause.
NOTE—A STA can perform a PIFS recovery, as described in 10.22.2.7, or perform a backoff, as described in the
previous paragraph, as a response to transmission failure within a TXOP. How it chooses between these two is
implementation dependent.
A STA that performs a backoff within its existing TXOP shall not extend the TXNAV timer value (see
10.22.2.7).
NOTE—In other words, the backoff is a continuation of the TXOP, not the start of a new TXOP.
If the backoff procedure is invoked for reason a) above, the value of CW[AC] shall be left unchanged. If the
backoff procedure is invoked for reason b) above, the value of CW[AC] shall be reset to CWmin[AC].
If the backoff procedure is invoked for reason c), d), e), or f) above, or the transmission failure of a non-initial
frame by the TXOP holder, the value of CW[AC] shall be updated as follows before invoking the backoff
procedure:
— If the QSRC[AC] or the QLRC[AC] has reached dot11ShortRetryLimit or dot11LongRetryLimit
respectively, CW[AC] shall be reset to CWmin[AC].
— If dot11RobustAVStreamingImplemented is true and either the QSDRC[AC] or the QLDRC[AC]
has reached dot11ShortDEIRetryLimit or dot11LongDEIRetryLimit, respectively, CW[AC] shall be
reset to CWmin[AC].
— Otherwise,
— If CW[AC] is less than CWmax[AC], CW[AC] shall be set to the value (CW[AC] + 1) × 2 – 1.
— If CW[AC] is equal to CWmax[AC], CW[AC] shall be left unchanged.
10.22.2.3 EDCA TXOPs
There are three modes of EDCA TXOP defined: initiation of an EDCA TXOP, sharing an EDCA TXOP, and
multiple frame transmission within an EDCA TXOP. Initiation of the TXOP occurs when the EDCA rules
permit access to the medium. Sharing of the EDCA TXOP occurs when an EDCAF within an AP that supports
DL-MU-MIMO has obtained access to the medium, making the corresponding AC the primary AC, and
includes traffic from queues associated with other ACs in VHT MU PPDUs transmitted during the TXOP.
Multiple frame transmission within the TXOP occurs when an EDCAF retains the right to access the medium
following the completion of a frame exchange sequence, such as on receipt of an Ack frame.
10.22.2.4 Obtaining an EDCA TXOP
Each EDCAF shall maintain a backoff timer, which has a value measured in backoff slots as described below.
When the backoff procedure is invoked, the backoff timer is set to an integer value chosen randomly with a
uniform distribution taking values in the range 0 to CW[AC].
The duration AIFS[AC] is a duration derived from the value AIFSN[AC] by the relation
AIFS[AC] = AIFSN[AC] × aSlotTime + aSIFSTime.
1380
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In an infrastructure BSS, AIFSN[AC] is advertised by an EDCA AP in the EDCA Parameter Set element in
Beacon and Probe Response frames transmitted by the AP. The value of AIFSN[AC] shall be greater than or
equal to 2 for non-AP STAs. The value of AIFSN[AC] shall be greater than or equal to 1 for APs. An EDCA
TXOP is granted to an EDCAF when the EDCAF determines that it shall initiate the transmission of a frame
exchange sequence. Transmission initiation shall be determined according to the following rules:
EDCAF operations shall be performed at slot boundaries, defined as follows on the primary channel, for each
EDCAF:
a) Following AIFSN[AC] × aSlotTime – aRxTxTurnaroundTime of idle medium after SIFS (not
necessarily idle medium during the SIFS) after the last busy medium on the antenna that was the
result of a reception of a frame with a correct FCS.
b) Following EIFS – DIFS + AIFSN[AC] × aSlotTime + aSIFSTime – aRxTxTurnaroundTime of idle
medium after the last indicated busy medium as determined by the physical CS mechanism that was
the result of a frame reception that has resulted in FCS error, or PHY-RXEND.indication
(RXERROR) primitive where the value of RXERROR is not NoError.
c) When any other EDCAF at this STA transmitted a frame requiring acknowledgment, the earlier of
1) The end of the AckTimeout interval timed from the PHY-TXEND.confirm primitive, followed
by AIFSN[AC] × aSlotTime + aSIFSTime – aRxTxTurnaroundTime of idle medium, and
2) The end of the first AIFSN[AC] × aSlotTime – aRxTxTurnaroundTime of idle medium after
SIFS (not necessarily medium idle during the SIFS, the start of the SIFS implied by the length
in the PHY header of the previous frame) when a PHY-RXEND.indication primitive occurs as
specified in 10.3.2.9.
d) Following AIFSN[AC] × aSlotTime – aRxTxTurnaroundTime of idle medium after SIFS (not
necessarily medium idle during the SIFS) after the last busy medium on the antenna that was the
result of a transmission of a frame for any EDCAF and which did not require an acknowledgment
and after the expiration of the TXNAV timer if nonzero, and, if dot11MCCAActivated is true, the
expiration of the RAV timer if nonzero.
e) Following AIFSN[AC] × aSlotTime + aSIFSTime – aRxTxTurnaroundTime of idle medium after
the last indicated busy medium as indicated by the CS mechanism that is not covered by a) to d).
f) Following aSlotTime of idle medium, which occurs immediately after any of these conditions, a) to
f), is met for the EDCAF.
On these specific slot boundaries, each EDCAF shall make a determination to perform one and only one of the
following functions:
— Decrement the backoff timer.
— Initiate the transmission of a frame exchange sequence.
— Invoke the backoff procedure due to an internal collision.
— Do nothing.
NOTE—If an EDCAF gains access to the channel and transmits MSDUs, A-MSDUs, or MMPDUs from a secondary
AC, the EDCAF of the secondary AC is not affected by this operation. If the EDCAF of a secondary AC experiences an
internal collision with the EDCAF that gained access to the channel, it performs the backoff procedure regardless of the
transmission of any of its MSDUs, A-MSDUs, or MMPDUs (see 10.22.2.6).
At each of the above-described specific slot boundaries, each EDCAF shall decrement the backoff timer if the
backoff timer for that EDCAF has a nonzero value.
At each of the above-described specific slot boundaries, each EDCAF shall initiate a transmission sequence if
— There is a frame available for transmission at that EDCAF, and
— The backoff timer for that EDCAF has a value of 0, and
1381
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Initiation of a transmission sequence is not allowed to commence at this time for an EDCAF of
higher UP.
At each of the above-described specific slot boundaries, each EDCAF shall report an internal collision (which
is handled in 10.22.2.4) if
— There is a frame available for transmission at that EDCAF, and
— The backoff timer for that EDCAF has a value of 0, and
— Initiation of a transmission sequence is allowed to commence at this time for an EDCAF of higher
UP.
An example showing the relationship between AIFS, AIFSN, DIFS, and slot times immediately following a
medium busy condition (and assuming that medium busy condition was not caused by a frame in error) is
shown in Figure 10-26. In this case, with AIFSN = 2, the EDCAF may decrement the backoff counter for the
first time at 2 × aSlotTime following the TxSIFS (where TxSIFS is the time at which the MAC responds to the
end of the medium busy condition if it is going to respond “after SIFS”). If, in this example, the backoff
counter contained a value of 1 at the time the medium became idle, transmission would start as a result of an
EDCA TXOP on-air at a time
aSIFSTime + 3 × aSlotTime
following the end of the medium busy condition.
Earliest possible transmission on-air
when AIFSN = 2
Initial backoff Initial backoff
counter value of 0. counter value of 1.
DIFS
PIFS, or AIFS for AIFSN=1
aSlotTime aSlotTime aSlotTime
Medium busy
D1 Rx/Tx
M1 D2 D2 D2
CCADel CCADel CCADel
M2 M2 M2
PHY-RXEND.indication
Rx/Tx Rx/Tx Rx/Tx
aSlotTime aSlotTime aSlotTime
MAC slot TxSIFS TxPIFS and AIFSN = 1 AIFSN = 2 AIFSN = 3
boundaries slot boundary slot boundary slot boundary slot boundary
D1 = aRxPHYDelay (referenced from the end of the last symbol of a PPDU on the medium)
D2 = D1 + aAirPropagationTime
Rx/Tx = aRxTxTurnaroundTime (begins with a PHY-TXSTART.request) Decrement backoff or start rx
M1 = M2 = aMACProcessingDelay to tx turnaround if zero when
CCAdel = aCCATime – D1 AIF SN=2
Figure 10-26—EDCA mechanism timing relationships
A STA shall save the TXOP holder address for the BSS in which it is associated, which is the MAC address
from the Address 2 field of the frame that initiated a frame exchange sequence except when this is a CTS
frame, in which case the TXOP holder address is the Address 1 field. If the TXOP holder address is obtained
from a Control frame, a VHT STA shall save the nonbandwidth signaling TA value obtained from the
Address 2 field. If a non-VHT STA receives an RTS frame with the RA address matching the MAC address
of the STA and the MAC address in the TA field in the RTS frame matches the saved TXOP holder address,
then the STA shall send the CTS frame after SIFS, without regard for, and without resetting, its NAV. If a
VHT STA receives an RTS frame with the RA address matching the MAC address of the STA and the
nonbandwidth signaling TA value obtained from the Address 2 field in the RTS frame matches the saved
TXOP holder address, then the STA shall send the CTS frame after SIFS, without regard for, and without
1382
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
resetting, its NAV. When a STA receives a frame addressed to it that requires an immediate response, except
for RTS, it shall transmit the response independent of its NAV. The saved TXOP holder address shall be
cleared when the NAV is reset or when the NAV counts down to 0.
10.22.2.5 EDCA channel access in a VHT or TVHT BSS
If the MAC receives a PHY-CCA.indication primitive with the channel-list parameter present, the channels
considered idle are defined in Table 10-10.
Table 10-10—Channels indicated idle by the channel-list parameter
PHY-CCA.indication
primitive channel-list Idle channels
element
primary None
secondary Primary 20 MHz channel
secondary40 Primary 20 MHz channel and secondary 20 MHz channel
secondary80 Primary 20 MHz channel, secondary 20 MHz channel, and
secondary 40 MHz channel
When a STA and the BSS, of which the STA is a member, both support multiple channel widths, an EDCA
TXOP is obtained based solely on activity of the primary channel. “Idle medium” in this subclause means “idle
primary channel.” Likewise “busy medium” means “busy primary channel.” Once an EDCA TXOP has been
obtained according to this subclause, further constraints defined in 11.16.9 and 10.22.3 might limit the width of
transmission during the TXOP or deny the channel access, based on the state of CCA on secondary channel,
secondary 40 MHz channel, or secondary 80 MHz channel.
In the following description, the CCA is sampled according to the timing relationships defined in 10.3.7. Slot
boundaries are determined solely by activity on the primary channel. “Channel idle for an interval of PIFS”
means that the STATE parameter of the most recent PHY-CCA.indication primitive was IDLE, and no PHY-
CCA.indication(BUSY) occurred during the period of PIFS that ends at the start of transmission, the CCA for
that channel was determined to be idle.
If a STA is permitted to begin a TXOP (as defined in 10.22.2.4) and the STA has at least one MSDU pending
for transmission for the AC of the permitted TXOP, the STA shall perform exactly one of the following
actions:
a) Transmit a 160 MHz or 80+80 MHz mask PPDU if the secondary channel, the secondary 40 MHz
channel, and the secondary 80 MHz channel were idle during an interval of PIFS immediately
preceding the start of the TXOP.
b) Transmit an 80 MHz mask PPDU on the primary 80 MHz channel if both the secondary channel and
the secondary 40 MHz channel were idle during an interval of PIFS immediately preceding the start
of the TXOP.
c) Transmit a 40 MHz mask PPDU on the primary 40 MHz channel if the secondary channel was idle
during an interval of PIFS immediately preceding the start of the TXOP.
d) Transmit a 20 MHz mask PPDU on the primary 20 MHz channel.
e) Restart the channel access attempt by invoking the backoff procedure as specified in 10.22.2 as
though the medium is busy on the primary channel as indicated by either physical or virtual CS and
the backoff timer has a value of 0.
1383
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
f) Transmit a TVHT_4W or TVHT_2W+2W mask PPDU if the secondary TVHT_W channel and the
secondary TVHT_2W channel were idle during an interval of PIFS immediately preceding the start
of the TXOP.
g) Transmit a TVHT_2W or TVHT_W+W mask PPDU if the secondary TVHT_W channel was idle
during an interval of PIFS immediately preceding the start of the TXOP.
h) Transmit a TVHT_W mask PPDU on the primary TVHT_W channel.
NOTE 1—In the case of rule e), the STA selects a new random number using the current value of CW[AC], and the retry
counters are not updated (as described in 10.22.2.7; backoff procedure invoked for event a)).
NOTE 2—For both an HT and a VHT STA, an EDCA TXOP is obtained based on activity on the primary channel (see
10.22.2.4). The width of transmission is determined by the CCA status of the nonprimary channels during the PIFS
interval before transmission (see VHT description in 10.3.2).
10.22.2.6 Sharing an EDCA TXOP
This mode applies only to an AP that supports DL-MU-MIMO. The AC associated with the EDCAF that gains
an EDCA TXOP becomes the primary AC. TXOP sharing is allowed when primary AC traffic is transmitted in
a VHT MU PPDU and resources permit traffic from secondary ACs to be included, targeting up to four STAs.
The inclusion of secondary AC traffic in a VHT MU PPDU shall not increase the duration of the VHT MU
PPDU beyond that required to transport the primary AC traffic. If a destination is targeted by frames in the
queues of both the primary AC and at least one secondary AC, the frames in the primary AC queue shall be
transmitted to the destination first, among a series of downlink transmissions within a TXOP. The decision of
which secondary ACs and destinations are selected for TXOP sharing, as well as the order of transmissions, are
implementation specific and out of scope of this standard.
When sharing, the TXOP limit that applies is the TXOP limit of the primary AC.
NOTE—An AP can protect an immediate response by preceding the VHT MU PPDU (which might have TXVECTOR
parameter NUM_USERS > 1) with an RTS/CTS exchange or a CTS-to-self transmission.
An illustration of TXOP sharing is shown in Figure 10-27. In this figure, the AP has frames in queues of three
of its ACs. It is assumed that the TXOP was obtained by AC_VI and is shared by AC_VO and AC_BE. It is
also assumed that these frames are targeting three STAs, STA-1 to STA-3.
10.22.2.7 Multiple frame transmission in an EDCA TXOP
A frame exchange, in the context of multiple frame transmission in an EDCA TXOP, may be one of the
following:
— A frame not requiring immediate acknowledgment (such as a group addressed frame or a frame
transmitted with an acknowledgment policy that does not require immediate acknowledgment) or an
A-MPDU containing only such frames
— A frame requiring acknowledgment (such as an individually addressed frame transmitted with an
acknowledgment policy that requires immediate acknowledgment) or an A-MPDU containing at
least one such frame, followed after SIFS by a corresponding acknowledgment frame
— Either
— a VHT NDP Announcement frame followed after SIFS by a VHT NDP followed after SIFS by a
PPDU containing one or more VHT Compressed Beamforming frames, or
— a Beamforming Report Poll frame followed after SIFS by a PPDU containing one or more VHT
Compressed Beamforming frames
1384
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(MSDU, UP)
AC_VO AC_VI AC_BE AC_BK
(primary)
(4) (to S TA-3)
(3) (to S TA-2)
(3) (to S TA-1)
(2) (to S TA-3)
(2) (to S TA-1)
(1) (to S TA-2) (1) (to S TA-1) (1) (to S TA-2)
EDCAF EDCAF EDCAF EDCAF
TXOP
RA = STA-1, AC_VI (1) pad RA = STA-1, AC_VI (2) RA = STA-1, AC_VI (3)
Preamble
Preamble
Preamble
AP RA = STA-2, AC_BE (1) pad RA = STA-2, AC_VO (1) pad RA = STA-2, AC_BE (3)
BAR
BAR
BAR
BAR
BAR
RA = STA-3, AC_VI (4) RA = STA-3, AC_BE (2)
pad
STA-1 BA BA BA
STA-2 BA BA BA
STA-3 BA BA
Time
Figure 10-27—Illustration of TXOP sharing and PPDU construction
Multiple frames may be transmitted in an EDCA TXOP that was acquired following the rules in 10.22.2.4 if
there is more than one frame pending in the primary AC for which the channel has been acquired. However,
those frames that are pending in other ACs shall not be transmitted in this EDCA TXOP except when sent in a
VHT MU PPDU with TXVECTOR parameter NUM_USERS > 1 and if allowed by the rules in 10.22.2.6. If a
TXOP holder has in its transmit queue an additional frame of the primary AC and the duration of transmission
of that frame plus any expected acknowledgment for that frame is less than the remaining TXNAV timer value
and, if dot11MCCAActivated is true, the remaining RAV timer value, then the TXOP holder may commence
transmission of that frame a SIFS (or RIFS, if the conditions defined in 10.3.2.3.2 are met) after the
completion of the immediately preceding frame exchange sequence, subject to the TXOP limit restriction as
described in 10.22.2.8. A STA shall not commence the transmission of an RTS with a bandwidth signaling TA
until at least a PIFS after the immediately preceding frame exchange sequence. An HT STA that is a TXOP
holder may transmit multiple MPDUs of the same AC within an A-MPDU as long as the duration of
transmission of the A-MPDU plus any expected BlockAck frame response is less than the remaining TXNAV
timer value and, if dot11MCCAActivated is true, the remaining RAV timer value.
NOTE 1—PIFS is used by a VHT STA to perform CCA in the secondary 20 MHz, 40 MHz, and 80 MHz channels
before receiving RTS (see 10.3.2).
NOTE 2—An RD responder can transmit multiple MPDUs as described in 10.28.4.
1385
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
After a valid response (see Annex G) to the initial frame of a TXOP, if the Duration/ID field is set for multiple
frame transmission and there is a subsequent transmission failure, the corresponding channel access function
may transmit after the CS mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot
boundary (see Figure 10-26) provided that the duration of that transmission plus the duration of any expected
acknowledgment and applicable IFS is less than the remaining TXNAV timer value and, if
dot11MCCAActivated is true, the RAV timer. At the expiration of the TXNAV timer and if
dot11MCCAActivated is true, the RAV timer, if the channel access function has not regained access to the
medium, then the EDCAF shall invoke the backoff procedure that is described in 10.22.2.4. Transmission
failure is defined in 10.22.2.11.
All other channel access functions at the STA shall treat the medium as busy until the expiration of the
TXNAV timer.
Note that, as for an EDCA TXOP, a multiple frame transmission is granted to an EDCAF, not to a STA, so that
the multiple frame transmission is permitted only for the transmission of a frame of the same AC as the frame
that was granted the EDCA TXOP, unless the EDCA TXOP obtained is used by an AP for a PSMP sequence
or a VHT MU PPDU with TXVECTOR parameter NUM_USERS > 1.
In the case of PSMP, this AC transmission restriction does not apply to either the AP or the STAs participating
in the PSMP sequence, but the specific restrictions on transmission during a PSMP sequence described in
10.29 do apply.
If a TXOP is protected by an RTS or CTS frame carried in a non-HT or a non-HT duplicate PPDU, the TXOP
holder shall set the TXVECTOR parameter CH_BANDWIDTH of a PPDU as follows:
— To be the same or narrower than RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the
last received CTS frame in the same TXOP, if the RTS frame with a bandwidth signaling TA and
TXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT set to Dynamic has been sent by the
TXOP holder in the last RTS/CTS exchange.
— Otherwise, to be the same or narrower than the TXVECTOR parameter CH_BANDWIDTH of the
RTS frame that has been sent by the TXOP holder in the last RTS/CTS exchange in the same TXOP.
If there is no RTS/CTS exchange in non-HT duplicate format in a TXOP, and the TXOP includes at least one
non-HT duplicate frame exchange that does not include a PS-Poll, then the TXOP holder shall set the
CH_BANDWIDTH parameter in TXVECTOR of a PPDU sent after the first non-HT duplicate frame that is
not a PS-Poll to be the same or narrower than the CH_BANDWIDTH parameter in TXVECTOR of the initial
frame in the first non-HT duplicate frame exchange in the same TXOP.
If there is no non-HT duplicate frame exchange in a TXOP, the TXOP holder shall set the TXVECTOR
parameter CH_BANDWIDTH of a non-initial PPDU to be the same or narrower than the TXVECTOR
parameter CH_BANDWIDTH of the preceding PPDU that it has transmitted in the same TXOP.
If a TXOP is protected by a CTS-to-self frame carried in a non-HT or non-HT duplicate PPDU, the TXOP
holder shall set the TXVECTOR parameter CH_BANDWIDTH of a PPDU to be the same or narrower than
the TXVECTOR parameter CH_BANDWIDTH of the CTS-to-self frame in the same TXOP.
Note that when transmitting multiple frames in a TXOP using acknowledgment mechanisms other than
Normal Ack, a protective mechanism should be used (such as RTS/CTS or the protection mechanism described
in 10.26). A QoS AP or a mesh STA may send group addressed frames without using any protection
mechanism. In a QoS IBSS, group addressed frames shall be sent one at a time, and backoff shall be performed
after the transmission of each of the group addressed frames. In an MBSS, a mesh STA may send multiple
group addressed frames in a TXOP, bounded by the TXOP limit, without performing backoff after the TXOP
is obtained.
1386
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.22.2.8 TXOP limits
The duration of a TXOP is the time a STA obtaining a TXOP (the TXOP holder) maintains uninterrupted
control of the medium, and it includes the time required to transmit frames sent as an immediate response to
TXOP holder transmissions. The TXOP holder shall, subject to the exceptions below, ensure that the duration
of a TXOP does not exceed the TXOP limit, when nonzero.
The TXOP limits are advertised by the AP in the EDCA Parameter Set element in Beacon and Probe Response
frames transmitted by the AP.
A TXOP limit of 0 indicates that the TXOP holder may transmit or cause to be transmitted (as responses) the
following within the current TXOP:
a) One of the following at any rate, subject to the rules in 10.7
1) One or more SU PPDUs carrying fragments of a single MSDU or MMPDU
2) An SU PPDU or a VHT MU PPDU carrying a single MSDU, a single MMPDU, a single
A-MSDU, or a single A-MPDU
3) A VHT MU PPDU carrying A-MPDUs to different users (a single A-MPDU to each user)
4) A QoS Null frame or PS-Poll frame
b) Any required acknowledgments
c) Any frames required for protection, including one of the following:
1) An RTS/CTS exchange
2) CTS to itself
3) Dual CTS as specified in 10.3.2.8
d) Any frames required for beamforming as specified in 10.30, 10.34.5 and 10.38.
e) Any frames required for link adaptation as specified in 10.31
f) Any number of BlockAckReq frames
NOTE 1—This is a rule for the TXOP holder. A TXOP responder need not be aware of the TXOP limit nor of when the
TXOP was started.
NOTE 2—This rule prevents the use of RD when the TXOP limit is 0.
When dot11OCBActivated is true, TXOP limits shall be 0 for each AC.
The TXOP holder may exceed the TXOP limit only if it does not transmit more than one Data or Management
frame in the TXOP, and only for the following situations:
— Retransmission of an MPDU, not in an A-MPDU consisting of more than one MPDU
— Initial transmission of an MSDU under a block ack agreement, where the MSDU is not in an A-
MPDU consisting of more than one MPDU and the MSDU is not in an A-MSDU
— Transmission of a Control MPDU or a QoS Null MPDU, not in an A-MPDU consisting of more than
one MPDU
— Initial transmission of a fragment of an MSDU or MMPDU, if a previous fragment of that MSDU or
MMPDU was retransmitted
— Transmission of a fragment of an MSDU or MMPDU fragmented into 16 fragments
— Transmission of an A-MPDU consisting of the initial transmission of a single MPDU not containing
an MSDU and that is not an individually addressed Management frame
— Transmission of a group addressed MPDU, not in an A-MPDU consisting of more than one MPDU
— Transmission of a null data packet (NDP)
1387
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Transmission of a VHT NDP Announcement frame and NDP or transmission of a Beamforming
Report Poll frame, where these fit within the TXOP limit and it is only the response and the
immediately preceding SIFS that cause the TXOP limit to be exceeded.
Except as described above, a STA shall fragment an individually addressed MSDU or MMPDU so that the
initial transmission of the first fragment does not cause the TXOP limit to be exceeded.
NOTE—The TXOP limit is not exceeded for the following situations:
— Initial transmission of an MPDU containing an unfragmented though fragmentable (see 10.2.7) MSDU/
MMPDU
— Initial transmission of the first fragment of a fragmented MSDU/MMPDU, except for an MSDU/MMPDU
fragmented into 16 fragments
— Initial transmission of an A-MSDU
— Initial transmission of a fragment of a fragmented MSDU/MMPDU, if no previous fragment of that MSDU/
MMPDU was retransmitted, except for an MSDU/MMPDU fragmented into 16 fragments
— Transmission of an A-MPDU consisting of a single MPDU containing an A MSDU or individually addressed
Management frame, unless this is a retransmission of that MPDU
— Transmission of an A-MPDU consisting of more than one MPDU, even if some or all of the MPDUs are
retransmissions
If the TXOP holder exceeds the TXOP limit, it should use as high a PHY rate as possible to minimize the
duration of the TXOP.
The duration of a TXOP for a mesh STA that has dot11MCCAActivated true shall not exceed the time
between the start of the TXOP and the end of the current MCCAOP reservation.
NOTE—The rules in this subclause also apply to priority-downgraded MSDUs and A-MSDUs (see 10.22.4.2.
10.22.2.9 Truncation of TXOP
When a STA gains access to the channel using EDCA and empties its transmission queue, it may transmit a
CF-End frame provided that the remaining duration is long enough to transmit this frame. By transmitting the
CF-End frame, the STA is explicitly indicating the completion of its TXOP. In a DMG BSS, the STA shall not
send a CF-End frame with a nonzero value in the Duration/ID field if the remaining duration is shorter than
2×TCF-End + 2×SIFS, where TCF-End is the duration of a CF-End frame.
A TXOP holder that transmits a CF-End frame shall not initiate any further frame exchange sequences within
the current TXOP.
A non-AP STA that is not the TXOP holder shall not transmit a CF-End frame.
In a non-DMG BSS, a STA shall interpret the reception of a CF-End frame as a NAV reset, i.e., it resets its
NAV to 0 at the end of the PPDU containing this frame. After receiving a CF-End frame with a matching
BSSID(TA) without comparing Individual/Group bit, an AP may respond by transmitting a CF-End frame
after SIFS.
NOTE 1—The transmission of a single CF-End frame by the TXOP holder resets the NAV of STAs hearing the TXOP
holder. There may be STAs that could hear the TXOP responder that had set their NAV that do not hear this NAV reset.
Those STAs are prevented from contending for the medium until the original NAV reservation expires.
NOTE 2—A CF-End sent by a non-AP VHT STA that is a member of a VHT BSS can include the TXVECTOR
parameter CH_BANDWIDTH_IN_NON_HT as defined in 10.7.6.6 in case it elicits a CF-End response.
In a DMG BSS, a STA that is not in the listening mode (10.36.6.6) shall interpret the reception of a CF-End
frame as a NAV reset, i.e., it resets its NAV to 0 at the end of the time interval indicated in the value of the
Duration/ID field of the received frame. The interval starts at PHY-RXEND.indication primitive of the frame
reception. The STA shall not transmit during the interval if the RA field of the frame is not equal to the STA
1388
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAC address. The STA may transmit a CF-End frame if the RA field of the received frame is equal to the STA
MAC address and the value of the Duration/ID field in the received frame is not equal to 0.
Figure 10-28 shows an example of TXOP truncation. In this example, the STA accesses the medium using
EDCA channel access and then transmits a nav-set sequence (e.g., RTS/CTS for non-DMG STAs or RTS/
DMG CTS for DMG STAs) (using the terminology of Annex G). After a SIFS, it then transmits an initiator-
sequence, which may involve the exchange of multiple PPDUs between the TXOP holder and TXOP
responders. At the end of the second sequence, the TXOP holder has no more data that it can send that fits
within the TXOP limit; therefore, it truncates the TXOP by transmitting a CF-End frame.
TXOP Duration
f
o
d
d n P
n e
nav-set sequence initiator-sequence E
- l O
a X
F in T
C m
o
N
EDCA Channel
Access
SIFS SIFS
Figure 10-28—Example of TXOP truncation
Non-DMG STAs that receive a CF-End frame reset their NAV and can start contending for the medium
without further delay. A DMG STA that receives a CF-End frame can start contending for the medium at the
end of the time interval equal to the value in Duration/ID field of the frame if none of its NAVs has a nonzero
value (10.36.10).
TXOP truncation shall not be used in combination with L-SIG TXOP protection when the HT Protection field
of the HT Operation element is equal to nonmember protection mode or non-HT mixed mode.
10.22.2.10 Termination of TXOP
A TXOP holder that transmits a PPDU using one of the modulation classes in Table 10-11 should transmit a
short control frame as the final transmission in a TXOP, under the conditions specified in Table 10-12.
Table 10-11—Modulation classes eligible for TXOP termination
Modulation classes eligible for TXOP
termination
(see Table 10-6)
DSSS
HR/DSSS
ERP-OFDM
OFDM (20 MHz channel spacing)
HT
VHT
1389
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-12—Rate and modulation class of a final transmission in a TXOP
Modulation class and data rate of immediately preceding Rate and modulation class of final
frame in TXOP transmission
DSSS or HR/DSSS with long preamble, data rate > 1 Mb/s 1 Mb/s DSSS
HR/DSSS with short preamble, data rate > 2 Mb/s 2 Mb/s HR/DSSS short preamble
Other eligible modulation classes, data rate > 6 Mb/s 6 Mb/s OFDM
The final transmission can be a CF-End, or a CTS-to-self when no NAV needs to be truncated.
NOTE—The final transmission at the lowest data rate within the modulation class is needed because a final transmission
at a higher rate can cause spurious EIFSs to occur, because the PHY header of such frames travels farther than the
MPDU.
10.22.2.11 Retransmit procedures
10.22.2.11.1 General
A QoS STA shall maintain a short retry counter and a long retry counter for each MSDU, A-MSDU, or
MMPDU that belongs to a TC that requires acknowledgment. The initial value for the short and long retry
counters shall be 0. QoS STAs also maintain a short retry counter and a long retry counter for each AC. They
are defined as QSRC[AC] and QLRC[AC], respectively, and each is initialized to a value of 0. When
dot11RobustAVStreamingImplemented is true, a QoS STA shall maintain a short drop-eligible retry counter
and a long drop-eligible retry counter for each AC. They are defined as QSDRC[AC] and QLDRC[AC],
respectively, and each is initialized to a value of zero. APs with dot11RobustAVStreamingImplemented true
and mesh STAs with dot11MeshGCRImplemented true, shall maintain an unsolicited retry counter.
After an RTS frame is transmitted to protect an MSDU or MMPDU, a QoS STA performs the CTS procedure,
as defined in 10.3.2.7. If a valid CTS frame is not received, the short retry counter for the MSDU or MMPDU
and the QSRC[AC] for the corresponding AC shall be incremented. If a valid CTS frame is received, the
QSRC[AC] for the corresponding AC shall be reset to 0.
After transmitting a frame that requires an immediate acknowledgment, the STA shall perform either of the
acknowledgment procedures, as appropriate, that are defined in 10.3.2.9 and 10.24.3. The short retry count for
an MSDU or A-MSDU that is not part of a block ack agreement or for an MMPDU shall be incremented every
time transmission of a frame in a PSDU of length less than or equal to dot11RTSThreshold fails for that
MSDU, A-MSDU, or MMPDU. The unsolicited retry counter shall be incremented after the transmission of
every A-MSDU that is transmitted using the GCR unsolicited retry retransmission policy.
QSRC[AC] shall be incremented every time transmission of an A-MPDU or frame in a PSDU of length less
than or equal to dot11RTSThreshold fails, regardless of the presence or value of the DEI field. When
dot11RobustAVStreamingImplemented is true, QSDRC[AC] shall be incremented every time transmission of
an A-MPDU or frame in which the HT variant HT Control field is present, the DEI field is equal to 1 and the
length of the PSDU is less than or equal to dot11RTSThreshold fails. This short retry count and the QoS STA
QSRC[AC] shall be reset when an A-MPDU or frame of length in a PSDU less than or equal to
dot11RTSThreshold succeeds. When dot11RobustAVStreamingImplemented is true, the QSDRC[AC] shall
be reset when an A-MPDU or frame in a PSDU of length less than or equal to dot11RTSThreshold succeeds,
regardless of the presence or value of the DEI field.
The long retry count for an MSDU or A-MSDU that is not part of a block ack agreement or for an MMPDU
shall be incremented every time transmission of a MAC frame in a PSDU of length greater than
dot11RTSThreshold fails for that MSDU, A-MSDU, or MMPDU.
1390
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
QLRC[AC] shall be incremented every time transmission of an A-MPDU or frame in a PSDU of length greater
than dot11RTSThreshold fails, regardless of the presence or value of the DEI field. This long retry count and
the QLRC[AC] shall be reset when an A-MPDU or frame in a PSDU of length greater than
dot11RTSThreshold succeeds. When dot11RobustAVStreamingImplemented is true, QLDRC[AC] shall be
incremented every time transmission fails for an A-MPDU or frame in a PSDU of length greater than
dot11RTSThreshold in which the HT variant HT Control field is present and the DEI field is equal to 1. The
QLDRC[AC] shall be reset when an A-MPDU or frame in a PSDU of length greater than dot11RTSThreshold
succeeds, regardless of the presence or value of the DEI field.
All retransmission attempts by a non-DMG STA for an MPDU with the Type subfield equal to Data or
Management that is not sent under a block ack agreement and that has failed the acknowledgment procedure
one or more times shall be made with the Retry subfield set to 1. All retransmission attempts by a DMG STA
for an MPDU with the Type subfield equal to Data or Management that has failed the acknowledgment
procedure one or more times shall be made with the Retry subfield set to 1.
Retries for failed transmission attempts shall continue until one or more of the following conditions occurs:
— The short retry count for the MSDU, A-MSDU, or MMPDU is equal to dot11ShortRetryLimit.
— The long retry count for the MSDU, A-MSDU, or MMPDU is equal to dot11LongRetryLimit.
— The short drop-eligible retry count for the MSDU, A-MSDU, or MMPDU is equal to
dot11ShortDEIRetryLimit.
— The long drop-eligible retry count for the MSDU, A-MSDU, or MMPDU is equal to
dot11LongDEIRetryLimit.
— The unsolicited retry count for the A-MSDU is equal to dot11UnsolicitedRetryLimit.
When any of these limits is reached, retry attempts shall cease, and the MSDU, A-MSDU, or MMPDU shall be
discarded.
For internal collisions occurring with the EDCA access method, the appropriate retry counters (short retry
counter for MSDU, A-MSDU, or MMPDU and QSRC[AC] or long retry counter for MSDU, A-MSDU, or
MMPDU and QLRC[AC]) are incremented. For internal collisions occurring with the EDCA access method
where dot11RobustAVStreamingImplemented is true, the appropriate drop-eligible retry counters
(QSDRC[AC], and QLDRC[AC]) are incremented when the collision occurs for an MSDU, A-MSDU, or
MMPDU that has drop eligibility equal to 1. For transmissions that use block ack, the rules in 10.24.3 also
apply. A STA shall retry failed transmissions until the transmission is successful or until the relevant retry limit
is reached.
With the exception of a frame belonging to a TID for which block ack agreement is set up, a QoS STA shall
not initiate the transmission of any Management or Data frame to a specific RA while the transmission of
another Management or Data frame with the same RA and having been assigned its sequence number from the
same sequence counter has not yet completed to the point of success, retry fail, or other MAC discard (e.g.,
lifetime expiration).
A QoS STA shall maintain a transmit MSDU timer for each MSDU passed to the MAC.
dot11EDCATableMSDULifetime specifies the maximum amount of time allowed to transmit an MSDU for a
given AC. The transmit MSDU timer shall be started when the MSDU is passed to the MAC. If the value of
this timer exceeds the appropriate entry in dot11EDCATableMSDULifetime, then the MSDU, or any
remaining, undelivered fragments of that MSDU, shall be discarded by the source STA without any further
attempt to complete delivery of that MSDU.
When A-MSDU aggregation is used, the HT STA maintains a single timer for the whole A-MSDU. The timer
is restarted each time an MSDU is added to the A-MSDU. The result of this procedure is that no MSDU in the
A-MSDU is discarded before a period of dot11EDCATableMSDULifetime has elapsed.
1391
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.22.2.11.2 Unsolicited retry procedure
When using the GCR unsolicited retry retransmission policy for a group address, an AP or mesh STA may
retransmit an MPDU to increase the probability of correct reception at the STAs that are listening to this
group address (i.e., the group address is in their dot11GroupAddressesTable). The set of MPDUs that may
be retransmitted is dependent upon whether block ack agreements are active with the STAs that are listening
to this group address and is defined in 11.24.16.3.6. How an AP or a mesh STA chooses which MPDUs to
retransmit is an implementation decision and beyond the scope of this standard.
A protective mechanism (such as a mechanism described in 10.26) should be used to reduce the probability
of other STAs transmitting during the GCR TXOP. When using a protection mechanism that requires a
response from another STA, the AP should select a STA that is a member of the GCR group.
The TXOP initiation rules defined in 10.22.2.2 and 10.22.3.3 shall be used for initiating a GCR TXOP. The
duration of a GCR TXOP shall be subject to the TXOP limits defined in 10.22.2.8.
When transmitting MPDUs using the GCR service with retransmission policy equal to GCR unsolicited
retry, the following rules apply:
— Following a MAC protection exchange that includes a response frame, in all GCR unsolicited retry
retransmissions, the STA shall either transmit the frames within a GCR TXOP separated by SIFS or
invoke its backoff procedure as defined in 10.22.2.2. The STA shall not transmit an MPDU and a
retransmission of the same MPDU within the same GCR TXOP. The final frame transmitted within
a GCR TXOP shall follow the backoff procedure defined in 10.22.2.2
— Without MAC protection or with MAC protection that lacks a response frame, in all transmissions,
the STA shall invoke the backoff procedure defined in 10.22.2.2, using a value of CWmin[AC] for
CW, at the PHY-TXEND.confirm primitive that follows the transmission of each unsolicited retry
GCR MPDU.
— All retransmissions of an MPDU shall have the Retry subfield in their Frame Control fields set to 1.
— During a GCR TXOP, frames may be transmitted within the GCR TXOP that do not use the GCR
unsolicited retry retransmission policy.
10.22.3 HCF controlled channel access (HCCA)
10.22.3.1 General
The HCCA mechanism manages access to the WM using an HC that has higher medium access priority than
non-AP STAs. This allows it to transfer MSDUs to STAs and to allocate TXOPs to STAs.
The HC is a type of centralized coordinator, but differs from the PC used in PCF in several significant ways,
although it may implement the functionality of a PC. Most important is that HCF frame exchange sequences
may be used among STAs associated in an infrastructure BSS during both the CP and the CFP. Another
significant difference is that the HC grants a STA a polled TXOP with duration specified in a QoS (+)CF-Poll
frame. A STA may transmit multiple frame exchange sequences within given polled TXOPs, subject to the
limit on TXOP duration.
All STAs inherently obey the NAV rules of the HCF because each frame transmitted under HCF contains a
duration value chosen to cause STAs in the BSS to set their NAVs to protect the expected subsequent frames.
A non-AP QoS STA shall be able to respond to QoS (+)CF-Poll frames received from an HC with the Address
1 field matching their own addresses.
1392
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The HC shall perform delivery of buffered non-GCR-SP group addressed MSDUs/MMPDUs following DTIM
Beacon frames. The HC may also operate as a PC, providing (non-QoS) CF-Polls to associated CF-Pollable
STAs using the frame formats, frame exchange sequences, and other applicable rules for PCF specified in
10.4.31
An HC may perform a backoff following an interruption of a frame exchange sequence due to lack of an
expected response under the rules described in 10.22.3.2.4, using the parameters dot11HCCWmin,
dot11HCCWmax, and dot11HCCAIFSN and the backoff rules in 10.2 and 10.22.2.2. The decision to perform
a backoff by the HC is dependent on conditions such as interference from an overlapping BSS. The mechanism
to detect the interference from an overlapping BSS and the decision to perform a backoff, DFS (such as
in 11.6), or other techniques (such as inter-BSS scheduling) is beyond the scope of this standard.
10.22.3.2 HCCA procedure
10.22.3.2.1 General
The HC gains control of the WM as needed to send QoS traffic and to issue QoS (+)CF-Poll frames to STAs by
waiting a shorter time between transmissions than the STAs using the EDCA procedures. The duration values
used in QoS frame exchange sequences reserve the medium to permit completion of the current sequence.
The HC may include a CF Parameter Set element in the Beacon frames it generates. This causes the BSS to
appear to be a point-coordinated BSS to STAs. This causes STAs to set their NAVs to the CFPDurRemaining
value in the CF Parameter Set element value at TBTT, as specified in 10.4.4.3. This prevents most contention
in the CFP by preventing nonpolled transmissions by STAs regardless of whether they are CF-Pollable.
10.22.3.2.2 CFP generation
The HC may function as a PC that uses the CFP for delivery, generating a CFP as shown in Figure 10-20, with
the restriction that the CFP initiated by an HC shall end with a CF-End frame. The HC may also issue QoS
(+)CF-Poll frames to associated STAs during the CFP. However, because the HC can also grant polled TXOPs,
by sending QoS (+)CF-Poll frames, during the CP, the HC might not use the CFP for QoS data transfers.
Only an AP that also issues non-QoS CF-Poll frames to associated CF-Pollable A STA may end a CFP with a
CF-End +CF-Ack frame and only when the CF-End +CF-Ack is acknowledging a reception from a CF-
Pollable non-QoS STA. The use of a non-QoS CF-Poll frame by an AP to a QoS STA is deprecated (for further
discussion; see 9.4.1.4).
10.22.3.2.3 CAP generation
When the HC needs access to the WM to start a CFP or a TXOP in CP, the HC shall sense the WM. When the
WM is determined to be idle at the TxPIFS slot boundary as defined in 10.3.7, the HC shall transmit the first
frame of any permitted frame exchange sequence, with the duration value set to cover the CFP or the TXOP.
An HCCA TXOP shall not extend across a TBTT. The occurrence of a TBTT implies the end of the HCCA
TXOP, after which the regular channel access procedure (EDCA or HCCA) is resumed. It is possible that no
frame was transmitted during the TXOP. The shortened termination of the HCCA TXOP does not imply an
error condition. The first permitted frame in a CFP after a TBTT is the Beacon frame. CAPs along with the
CFPs and the CPs are illustrated in Figure 10-29.
31
Attempting to intersperse HCF frame exchange sequences and PCF frame exchange sequences in a single CFP might be extremely
complex.
1393
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B B B B
e e e e
a a a a
c c c c
o o o o
n n n n
DTIM DTIM DTIM DTIM
CFP CP CFP
CFP Repetition Interval
CAP
EDCA TXOPs and access by legacy STAs using DCF.
Figure 10-29—CAP/CFP/CP periods
After the last frame of all other nonfinal frame exchange sequences (e.g., sequences that convey individually
addressed QoS Data or Management frames) during a TXOP, the holder of the current TXOP shall wait for one
SIFS before transmitting the first frame of the next frame exchange sequence. The HC may sense the channel
and reclaim the channel if the WM is determined to be idle at the TxPIFS slot boundary after the TXOP (see
Figure 10-26). A CAP ends when the HC does not reclaim the channel at the TxPIFS slot boundary after the
end of a TXOP.
10.22.3.2.4 Recovery from the absence of an expected reception
This subclause describes recovery from the absence of an expected reception in a CAP. Note that the recovery
rules from the absence of an expected reception are different from EDCA because in this case the NAVs of all
of the STAs in the BSS have already been set up by the transmissions by the HC. The recovery rules for the
multiple frame transmission are different because a STA may always be hidden and may have not set its NAV
due to the transmission by another STA. Finally, since an HC is collocated with the AP, the AP may recover
using the rules described in this subclause even if the recovery is from the absence of an expected reception.
The beginning of reception of an expected response is detected by the occurrence of PHY-
CCA.indication(BUSY,channel-list) primitive at the STA that is expecting the response where the channel-list
parameter is absent or, if present, includes “primary.”
If the beginning of such reception does not occur during the first slot time following a SIFS, then:32
— If the transmitting STA is the HC, it may initiate recovery by transmitting at the TxPIFS slot
boundary after the end of the HC’s last transmission only if the PHY-CCA state indicates IDLE
during the CCAdel period preceding the TxPIFS slot boundary as shown in 10-19.
— If the transmitting STA is a non-AP QoS STA, and there is an MPDU for transmission, it shall
initiate recovery by transmitting at a PIFS after the end of the last transmission if the PHY-CCA
state indicates IDLE during the CCAdel period preceding the TxPIFS slot boundary, the polled
TXOP limit is nonzero and at least one frame (re)transmissions can be completed within the
remaining duration of a nonzero polled TXOP limit.
32
This restriction is intended to avoid collisions due to inconsistent CCA reports in different STAs, not to optimize the bandwidth
usage efficiency.
1394
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the transmitted frame is not of type QoS (+)CF-Poll and the expected response frame is not received
correctly, regardless of the occurrence of the PHY-RXSTART.indication primitive, the QoS STA may initiate
recovery following the occurrence of PHY-CCA.indication(IDLE) primitive so that a SIFS occurs between the
last energy on the WM and the transmission of the recovery frame.
When there is a transmission failure within a polled TXOP, the long or short retry counter (as described in
10.22.2.11) corresponding to the AC of the failed MSDU or MMPDU shall be incremented. An MPDU
belonging to a TC is subject to the respective retry limit as well as the dot11EDCATableMSDULifetime and is
discarded when either of them is exceeded. An MPDU belonging to a TS with a specified delay bound is
subject to delay bound and is discarded if the MPDU could not be transmitted successfully since it has been
delivered to the MAC. An MPDU belonging to a TS with an unspecified delay is subject to
dot11MaxTransmitMSDULifetime and is discarded when it is exceeded.
Non-AP STAs that receive a QoS (+)CF-Poll frame shall respond within a SIFS, regardless of the NAV
setting. If a response is not received but a PHY-CCA.indication(BUSY) primitive occurs during the slot
following a SIFS and is followed by a PHY-RXSTART.indication or PHY-RXEND.indication primitive prior
to a PHY-CCA.indication(IDLE) primitive, then the HC assumes that the transmitted QoS (+)CF-Poll frame
was received by the polled STA. In the cases of QoS Data +CF-Poll, QoS Data +CF-Ack +CF-Poll, or QoS
CF-Ack +CF-Poll, the PHY-CCA.indication(BUSY) primitive is used only to determine whether the transfer
of control of the channel has been successful. The PHY-CCA.indication(BUSY) primitive is not used for
determining the success or failure of the transmission. If the CF-Poll is piggybacked onto a QoS Data frame,
the HC may have to retransmit that QoS Data frame subsequently.
If an HC receives a frame from a STA with a duration/ID covering only the response frame, the HC shall
assume that the STA is terminating its TXOP, and the HC may initiate other transmissions, send a CF-End
frame (see 10.22.3.4), or allow the channel to go into the CP.
If a polled QoS STA has no queued traffic to send or if the MPDUs available to send are too long to be
transmitted within the specified TXOP limit, the QoS STA shall send a QoS (+)Null frame. In the case of no
queued traffic, this QoS (+)Null frame shall have a QoS Control field that reports a queue size of 0 for any TID
with the duration/ID set to the time required for the transmission of one Ack frame, plus one SIFS. In the case
of insufficient TXOP size, such as when the maximum MSDU size is not specified, this QoS (+)Null frame
shall have a QoS Control field that contains the TID and TXOP duration or a nonzero queue size needed to
send the MPDU that is ready for transmission. When a queue size is transmitted, the HC shall combine the
queue size information with the rate of the received QoS (+)Null frame to determine the required size of the
requested TXOP.
Within a polled TXOP, the unused portion of TXOPs shall not be used by the STA and may be reallocated by
the HC as follows:
a) The recipient of the final frame, with the Ack Policy subfield equal to Normal Ack, shall be the HC
if there will be time remaining in the TXOP after the transmission of the final frame and its expected
Ack frame. If there are no frames to be sent to the HC, then the QoS STA shall send to the HC a QoS
Null with the Queue Size subfield in the QoS Control field set to 0.
1) If a PHY-CCA.indication(BUSY) primitive occurs at the STA that is expecting the Ack frame
during the first slot following a SIFS after the end of the transmission of the final frame, it shall
be interpreted as indicating that the channel control has been successfully transferred and no
further frames shall be transmitted by the STA in the TXOP, even though the Ack frame from
HC may be incorrectly received.33
2) If the beginning of the reception of an expected Ack frame to the final frame does not occur,
detected as the nonoccurrence of the PHY-CCA.indication(BUSY) primitive at the QoS STA
33
Note that while the PHY-CCA.indication(BUSY) primitive is used in this instance to determine the control of the channel, it is not
used for determining the success or failure of the transmission.
1395
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
that is expecting the response during the first slot time following a SIFS, the QoS STA shall
retransmit the frame or transmit a QoS Null frame, with the Ack Policy subfield set to Normal
Ack and the Queue Size subfield set to 0, after PIFS from the end of last transmission, until
such time that it receives an acknowledgment or when there is not enough time remaining in
the TXOP for sending such a frame.34
b) If there is not enough time within the unused portion of the TXOP to transmit either the QoS Null
frame or the frame with the Duration/ID field covering only the response frame, then the STA shall
cease control of the channel.35
10.22.3.3 HCCA TXOP structure and timing
Any QoS Data frame of a subtype that includes CF-Poll contains a TXOP limit in its QoS Control field. The
ensuing polled TXOP is protected by the NAV set by the Duration field of the frame that contained the QoS
(+)CF-Poll function, as shown in Figure 10-30. Within a polled TXOP, a STA may initiate the transmission of
one or more frame exchange sequences, with all such sequences nominally separated by a SIFS. The STA shall
not initiate transmission of a frame unless the transmission and any acknowledgment or other immediate
response expected from the peer MAC entity are able to complete prior to the end of the remaining TXOP
duration. All transmissions, including response frames, within the polled TXOP are considered to be the part of
the TXOP, and the HC shall account for these when setting the TXOP limit. If the TXOP Limit subfield in the
QoS Control field of the QoS Data frame that includes CF-Poll is equal to 0, then the STA to which the frame
is directed to shall respond with either one MPDU or one QoS Null frame.
A TXOP or transmission within a TXOP shall not extend across TBTT, dot11CFPMaxDuration (if during
CFP), or dot11CAPLimit. The HC shall verify that the full duration of any granted TXOP meets these
requirements so that a STA may use the time prior to the TXOP limit of a polled TXOP without checking for
these constraints. Subject to these limitations, all decisions regarding what MSDUs, A-MSDUs, and/or
MMPDUs are transmitted during any given TXOP are made by the STA that holds the TXOP.36,37
TXOP limit from QoS CF-Poll
TXOP granted by QoS CF -Poll
QoS CF-Poll
NAV from QoS CF-Poll
Figure 10-30—Polled TXOP
34
This is to avoid the situation where the HC might not receive the frame and might result in an inefficient use of the channel.
35Inthis case the channel is not accessed until the NAVs expire at all of the STAs.
36In certain regulatory domains, channel sensing needs to be done at periodic intervals (for example, in Japan, this period is 4 ms). This
means that the duration of a TXOP in these regulatory domains might not be more than this periodic interval. In order to extend the
TXOP beyond the limit implied by this periodic interval, the TXOP holder needs to sense the channel at least once in the limit imposed
in the regulatory domain, by waiting for at least for the duration of one PIFS during which it senses the channel. If it does not detect any
energy, it may continue by sending the next frame. In other words, the total TXOP size assigned should include an extra time allocated
(i.e., n × aSlotTime, where n is the number of times the STA needs to sense the channel) and is given by
TXOP limit limit imposed in the regulatory domain .
37
The TID value in the QoS Control field of a QoS Data +CF-Poll frame pertains only to the MSDU or fragment thereof in the Frame
Body field of that frame. This TID value does not pertain to the TXOP limit value and does not place any constraints on what frame(s)
the addressed STA may send in the granted TXOP.
1396
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.22.3.4 NAV operation of a TXOP under HCCA
An HC shall set its own NAV to prevent it from transmitting during a TXOP that it has granted to a STA
through an HCCA poll. However, the HC may reclaim the TXOP if a STA is not using it or ends the TXOP
early (see 10.22.3.2.4).
In a CFP or CP, if the HC has no more STAs to poll and it has no more Data, Management, BlockAckReq, or
BlockAck frames to send, it may reset the NAVs of all QoS STAs in the BSS by sending a QoS CF-Poll frame
with the RA matching its own MAC address and with the Duration/ID field set to 0. When the AP contains a
PC, during the CFP, it may reset the NAVs of all receiving STAs by sending a CF-End frame, regardless of
how the NAVs have been originally set.
A STA that receives a QoS (+)CF-Poll frame with a MAC address in the Address 1 field that matches the HC’s
MAC address and the Duration/ID field value equal to 0 shall reset the NAV value to 0.
NOTE—A STA resets its NAV when it receives a CF-End or CF-End +CF-Ack frame according to the procedures
described in 10.4.3.3.
When a STA receives a QoS (+)CF-Poll frame containing the BSSID of the BSS in which the STA is
associated, that STA shall update the NAV if necessary and shall save the TXOP holder address for that BSS,
which is the MAC address from the Address 1 field of the frame containing the QoS (+)CF-Poll. If an RTS
frame is received with the RA address matching the MAC address of the STA and the MAC address in the TA
field in the RTS frame matches the saved TXOP holder address, then the STA shall send the CTS frame after
SIFS, without regard for, and without resetting, its NAV. The saved TXOP holder address shall be cleared
when the NAV is reset or when the NAV counts down to 0.
When a STA receives a frame addressed to it and requires an acknowledgment, it shall respond with an Ack or
QoS +CF-Ack frame independent of its NAV. A non-AP STA shall accept a polled TXOP by initiating a frame
exchange sequence independent of its NAV.
10.22.3.5 HCCA transfer rules
10.22.3.5.1 General
A TXOP obtained by receiving a QoS (+)CF-Poll frame uses the specified TXOP limit consisting of one or
more frame exchange sequences with the sole time-related restriction being that the final sequence shall end
not later than the TXOP limit. In QoS CF-Poll and QoS CF-Ack +CF-Poll frames, the TID subfield in the QoS
Control field indicates the TS for which the poll is intended. The requirement to respond to that TID is
nonbinding, and a STA may respond with any frame. Upon receiving a QoS (+)CF-Poll frame, a STA may
send any frames, i.e., QoS Data frames belonging to any TID as well as Management frames in the obtained
TXOP. MSDUs may be fragmented in order to fit within TXOPs.
The QoS CF-Poll frames shall be sent only by an HC. Non-AP STAs are not allowed to send QoS (+)CF-Poll
frames. A STA shall not send QoS (+)Data frames in response to any Data frame other than the QoS (+)CF-
Poll frames.
The TXOP limit is inclusive of the PHY and IFS overhead, and an AP should account for the overhead when
granting TXOPs.
If a STA has set up at least one TS for which the Aggregation subfield in the associated TSPEC is equal to 0,
the AP shall use only QoS CF-Poll or QoS CF-Ack +CF-Poll frames to poll the STA and shall never use QoS
(+)Data +CF-Poll to poll the STA. Note that although QoS (+)CF-Poll is a Data frame, but it should be
transmitted at one of the rates in the BSSBasicRateSet parameter in order to set the NAV of all STAs that are
not being polled (see 10.7). If a CF-Poll is piggybacked with a QoS Data frame, then the frame containing all
1397
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
or part of an MSDU or A-MSDU may be transmitted at a rate that is below the negotiated minimum PHY rate
in the TSPEC related to that data.
A QoS STA shall use QoS Data frames for all MSDU transfers to another QoS STA. The TID in the QoS
Control fields of these frames shall indicate the TC or TS to which the MPDU belongs. Furthermore, either the
Queue Size subfield shall indicate the amount of queued traffic present in the output queue that the STA uses
for traffic belonging to this TC or TS, or the TXOP Duration Requested subfield shall indicate the duration that
the STA requests for use in the next TXOP for traffic belonging to this TC or TS. The queue size value reflects
the amount on the appropriate queue not including the present MPDU. The queue size value may remain
constant in all QoS Data frames that carry fragments of the same MSDU even if the amount of queued traffic
changes as successive fragments are transmitted. In order to inform the HC of queue status, a STA may use the
QoS Null frame indicating the TID and the queue size or TXOP duration request (also see 10.22.3.5.2).
A QoS STA shall be able to receive QoS +CF-Ack frames. The HC may use QoS Data +CF-Ack frames to
send frames to the same STA a SIFS after receiving the final transmission of the previous TXOP. The HC may
also use QoS Data +CF-Ack frames to send frames to any other STA a SIFS after receiving the final
transmission of the previous TXOP, if the STA that sent the final transmission of the previous TXOP has set
the Q-Ack subfield in the QoS Capability element in the (Re)Association Request frame to 1. In both CFP and
CP, a STA shall respond to QoS Data frames having the Ack Policy subfield in the QoS Control field equal to
Normal Ack with an Ack frame, unless the acknowledgment is piggybacked in which case it shall use a QoS
+CF-Ack frame. Piggybacked frames are allowed only in CFP or within TXOPs initiated by the HC. The HC
shall not send a QoS Data frame containing a +CF-Ack with an Address 1 that does not correspond to the
address of the STA for which the +CF-Ack is intended, unless the STA to which the +CF-Ack is intended, sets
the Q-Ack subfield in the QoS Capability element in the (Re)Association Request frame. STAs are not
required to be able to transmit QoS Data frames with subtypes that include +CF-Ack.
An AP that has dot11QAckOptionImplemented true may allow associations with STAs advertising support for
the Q-Ack option. Such associations do not require the AP to employ piggyback acknowledgments directed
toward that associated STA in frames that are not directed to that associated STA. A QoS STA shall be able to
process received QoS Data frames with subtypes that include +CF-Ack when the STA to which the
acknowledgment is directed is the same as the STA addressed by the Address 1 field of that Data frame. A
STA that does not set the Q-Ack subfield to 1 in the QoS Capability element in the (Re)Association Request
frame is not required to handle the received QoS (+)Data +CF-Ack frames that are addressed to other STAs.
The net effect of these restrictions on the use of QoS +CF-Ack frames is that the principal QoS +CF-Ack
subtype that is useful is the QoS Data +CF-Ack frame, which can be sent by a STA as the first frame in a polled
TXOP when that TXOP was conveyed in a QoS Data +CF-Poll (+CF-Ack) frame and the outgoing frame is
directed to the HC’s STA address. QoS (Data +)CF-Poll +CF-Ack frames are useful to allow the HC to grant
another TXOP to the same STA a SIFS after receiving the final transmission of that STA’s previous TXOP.
QoS (Data+)CF-Poll +CF-Ack frames are also useful to allow the HC to grant another TXOP to a different
STA a SIFS after receiving the final transmission of a STA’s previous TXOP, if the STA that sent the final
transmission of the previous TXOP has set the Q-Ack subfield in the QoS Capability element in the
(Re)Association Request frame to 1.
HCF contention based channel access shall not be used to transmit MSDUs belonging to an established TS
(with the HC’s acceptance of the associated TSPEC), unless the granted TSPEC indicates it is permitted to do
so when the Access Policy subfield of the TS Info field is equal to “HCCA, EDCA mixed mode” (HEMM), the
polled STA utilized the full TXOP provided by the HC, and it has more MPDUs to send. When this STA sends
frames belonging to a TS using contention based channel access, it shall encode the TID subfield in the QoS
Data frame with the TID associated with the TS. When the AP grants a TSPEC with the Access Policy subfield
equal to HEMM and if the corresponding AC needs admission control, the AP shall include the medium time
that specifies the granted time for EDCA access in the ADDTS Response frame.
1398
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.22.3.5.2 TXOP requests
STAs may send TXOP requests during polled TXOPs or EDCA TXOPs using the QoS Control field in a QoS
Data frame or a QoS Null frame directed to the HC, with the TXOP Duration Requested or Queue Size
subfield value and TID subfield value indicated to the HC. APs indicate whether they process TXOP request or
queue size in the QoS Info field in the Beacon, Probe Response, and (Re)Association Response frames. An AP
shall process requests in at least one format. The AP may reallocate TXOPs if the request belongs to TS or
update the EDCA parameter set if the above request belongs to TC. A STA shall use only the request format
that the AP indicates it can process.
TXOP Duration Requested subfield values are not cumulative. A TXOP duration requested for a particular
TID supersedes any prior TXOP duration requested for that TID. A value of 0 in the TXOP Duration
Requested subfield may be used to cancel a pending unsatisfied TXOP request when its MSDU is no longer
queued for transmission. The TXOP duration requested is inclusive of the PHY and IFS overhead, and a
STA should account for this when attempting to determine whether a given transmission fits within a
specified TXOP duration.
The AP may choose to assign a TXOP duration shorter than that requested in the TXOP Duration Requested
subfield.
Even if the value of TXOP Duration Requested subfield or Queue Size subfield in a QoS Data frame is 0, the
HC shall continue to poll according to the negotiated schedule.
10.22.3.5.3 Use of RTS/CTS
In order to provide improved NAV protection, a STA may send an RTS frame as the first frame of any frame
exchange sequence, during either the CP or CFP, and without regard for dot11RTSThreshold.38
If a QoS STA sends an RTS frame and does not receive an expected CTS frame, then the recovery rules are as
specified in 10.22.3.2.4.
In order to provide NAV protection for a transmission to the AP in response to a QoS Data frame with a
subtype that includes CF-Poll, the polled STA may send a CTS frame with the RA containing its own MAC.
NOTE 1—The CTS frame is shorter than a QoS Data frame and has a higher probability that it will be received by other
STAs.
NOTE 2—The transmission of the CTS sets the NAV in its own vicinity without the extra time required to send an RTS
frame.39
10.22.3.5.4 HCCA transfer rules for a VHT STA
A VHT STA that is a member of a BSS that supports multiple channel widths is granted a TXOP for a
specified duration and for a channel width that is equal to the channel width of the frame containing the QoS
CF-Poll.
38The sending of an RTS frame during the CFP is usually unnecessary, but might be used to confirm that the addressed recipient QoS
STA is within range and awake and to elicit a CTS frame response that sets the NAV at STAs in the vicinity of the addressed recipient.
This is useful when there are nearby STAs that are members of other BSSs and are out of range to receive Beacon frames from this
BSS. Sending an RTS frame during the CFP is useful only when the recipient is a QoS STA, because a non-QoS STA in the same BSS
has its NAV set to protect the CFP, which renders those non-QoS STAs unable to respond. Using the same duration calculation during
the CFP as specified for the CP is directly applicable for all cases except when the RTS frame is sent by the HC and the following frame
includes a QoS (+)CF-Poll.
39
This is unnecessary because the NAVs in the vicinity of the QoS AP were set by the QoS (+)CF-Poll frame.
1399
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.22.4 Admission control at the HC
10.22.4.1 General
An IEEE 802.11 network may use admission control to administer policy or regulate the available bandwidth
resources. Admission control is used to attempt to provide a guarantee of the amount of time that a STA has
available to access the channel. The HC, which is in the AP, is used to administer admission control in the
network. As the QoS facility supports two access mechanisms, there are two distinct admission control
mechanisms: one for contention based access and another for controlled access.
Admission control, in general, depends on vendors’ implementation of the scheduler, available channel
capacity, link conditions, retransmission limits, and the scheduling requirements of a given stream. All of these
criteria affect the admissibility of a given stream. If the HC has admitted no streams that require polling, it
might not find it necessary to perform the scheduler or related HC functions.
10.22.4.2 Contention based admission control procedures
10.22.4.2.1 General
A non-AP STA may support admission control procedures in 10.22.4.2.3 to send frames in the AC where
admission control is mandated; but, if it does not support that procedure and dot11RejectUnadmittedTraffic is
false or not present, it shall use EDCA parameters of a lower priority AC, as indicated in Table 10-1, that does
not require admission control. When a STA uses the EDCA parameters of a lower AC for this purpose, it
affects only the EDCA parameters used for channel access, i.e., it has no effect on the contents of the
transmitted frame. An AP shall support admission control procedures, at least to the minimal extent of
advertising that admission is not mandatory on its ACs.
The AP uses the ACM (admission control mandatory) subfields advertised in the EDCA Parameter Set element
to indicate whether admission control is required for each of the ACs. While the CWmin, CWmax, AIFS, and
TXOP limit parameters may be adjusted over time by the AP, the ACM bit shall be static for the duration of the
lifetime of the BSS. A STA shall transmit an ADDTS Request frame to the HC in order to request admission of
traffic in any direction (i.e., uplink, downlink, direct, or bidirectional) employing an AC that requires
admission control. The ADDTS Request frame shall contain the UP associated with the traffic and shall
indicate EDCA as the access policy. The AP shall associate the received UP of the ADDTS Request frame with
the appropriate AC per the UP-to-AC mappings described in 10.2.4.2. The STA may transmit unadmitted
traffic for the ACs for which the AP does not require admission control. If dot11RejectUnadmittedTraffic is
false, a STA may send data without admission control for an AC that mandates admission control by using the
EDCA parameters that correspond to a lower priority AC that does not require admission control. When a STA
uses a lower priority AC for this purpose, the lower priority AC affects only the EDCA parameters used for
channel access, i.e., it has no effect on the contents of the transmitted frame. All ACs with priority higher than
that of an AC with an ACM flag equal to 1 should have the ACM flag set to 1. The HC contained within an AP
when dot11SSPNInterfaceActivated is true shall admit a non-AP STA’s request based on
dot11NonAPStationAuthAccessCategories stored in that non-AP STA’s dot11InterworkingEntry, which is
part of the dot11InterworkingTable. The dot11InterworkingEntry specifies the EDCA access classes and
throughput limitations on each access class for which a non-AP STA is permitted to transmit.
10.22.4.2.2 Procedures at the AP
Regardless of the AC’s ACM setting, the AP shall respond to an ADDTS Request frame with an ADDTS
Response frame that may be to accept or deny the request. On receipt of an ADDTS Request frame from a non-
AP STA, the AP shall make a determination about whether to:
a) Accept the request, or
b) Deny the request.
1400
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The algorithm used by the AP to make this determination is implementation dependent. An AP when
dot11SSPNInterfaceActivated is true shall use the policies delivered by the SSPN that are stored in the
dot11InterworkingEntry, which is part of the dot11InterworkingTable. If the AP decides to accept the request,
the AP shall also derive the medium time from the information conveyed in the TSPEC element in the ADDTS
Request frame. The AP may use any algorithm in deriving the medium time, but K.2.2 provides a procedure
that may be used. Having made such a determination, the AP shall transmit a TSPEC element to the requesting
non-AP STA contained in an ADDTS Response frame. If the AP is accepting the request, the Medium Time
field shall be specified. If the AP is accepting a request for a downlink TS, the Medium Time field shall be set
to 0. If the AP is accepting a request corresponding to an AC for which ACM is 0 (e.g., the TSPEC is to change
APSD behavior), the Medium Time field shall be set to 0.
10.22.4.2.3 Procedure at non-AP STAs
Each EDCAF shall maintain two variables: admitted_time and used_time.
The admitted_time and used_time shall be set to 0 at the time of (re)association. The STA may subsequently
decide to explicitly request medium time for the AC that is associated with the specified priority.
In order to make such a request, the STA shall transmit a TSPEC element contained in an ADDTS Request
frame with the following fields specified (i.e., nonzero): Nominal MSDU Size, Mean Data Rate, Minimum
PHY Rate, Inactivity Interval, and Surplus Bandwidth Allowance. The Medium Time field is not used in the
request frame and shall be set to 0.
On receipt of a TSPEC element contained in an ADDTS Response frame indicating that the request has been
accepted, the STA shall recompute the admitted_time for the specified EDCAF as follows:
admitted_time = admitted_time + dot11EDCAAveragingPeriod × medium time of TSPEC.
The STA may choose to tear down the explicit request at any time. For the teardown of an explicit admission,
the STA shall transmit a DELTS frame containing the TSID and direction that specify the TSPEC to the AP.
If the STA sends or receives a DELTS frame, it shall recompute the admitted_time for the specified EDCAF as
follows:
admitted_time = admitted_time – dot11EDCAAveragingPeriod × medium time of TSPEC.
To describe the behavior at the STA, two parameters are defined. The parameter used_time signifies the
amount of time used, in units of 32 s, by the STA in dot11EDCAAveragingPeriod. The parameter
admitted_time is the medium time allowed by the AP, in units of 32 s, in dot11EDCAAveragingPeriod. The
STA shall update the value of used_time:
a) At dot11EDCAAveragingPeriod second intervals
used_time = max((used_time – admitted_time), 0)
b) After each successful or unsuccessful MPDU (re)transmission attempt,
used_time = used_time + MPDUExchangeTime
The MPDUExchangeTime equals the time required to transmit the MPDU sequence. For the case of an MPDU
transmitted with Normal Ack policy and without RTS/CTS protection, this equals the time required to transmit
the MPDU plus the time required to transmit the expected response frame plus one SIFS. Frame exchange
sequences for Management frames are excluded from the used_time update. If the used_time value reaches or
exceeds the admitted_time value, the corresponding EDCAF shall no longer transmit QoS Data frames or QoS
Null MPDUs using the EDCA parameters for that AC as specified in the QoS Parameter Set element.
However, a STA may choose to temporarily replace the EDCA parameters for that EDCAF with those
specified for an AC of lower priority, if no admission control is required for those ACs.
1401
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—When a frame is transmitted using temporary EDCA parameters, the TID field of that frame is not modified.
If, for example, a STA has made and had accepted an explicit admission for a TS and the channel conditions
subsequently worsen, possibly including a change in PHY data rate so that it requires more time to send the
same data, the STA may make a request for more admitted_time to the AP and at the same time downgrade the
EDCA parameters for that AC for short intervals in order to send some of the traffic at the admitted priority and
some at the unadmitted priority, while waiting for a response to the admission request.
10.22.4.3 Controlled-access admission control
This subclause describes the schedule management of the admitted HCCA streams by the HC. When the HC
provides controlled channel access to STAs, it is responsible for granting or denying polling service to a TS
based on the parameters in the associated TSPEC. If the TS is admitted, the HC is responsible for scheduling
channel access to this TS based on the negotiated TSPEC fields. The HC should not initiate a modification of
TSPEC fields of an admitted TS unless requested by the STA. The HC should not tear down a TS unless
explicitly requested by the STA or at the expiration of the inactivity timer. The polling service based on
admitted TS provides a “guaranteed channel access” from the scheduler in order to have its QoS requirements
met. This is an achievable goal when the WM operates free of external interference (such as operation within
the channel by other technologies and co-channel overlapping BSS interference). The nature of wireless
communications may preclude absolute guarantees to satisfy QoS requirements.
The following are rules for the operation of the scheduler:
— The scheduler shall be implemented so that, under controlled operating conditions, all STAs with
admitted TS are offered TXOPs that satisfy the service schedule.
— Specifically, if a TS is admitted by the HC, then the scheduler shall service the STA during an SP.
An SP is a period of time during which a set of one or more downlink individually addressed frames
and/or one or more polled TXOPs are granted to the STA. An SP starts at fixed intervals of time
specified in Service Interval field. The first SP starts when the lower order 4 octets of the TSF timer
equals the value specified in Service Start Time field.40 Additionally, the minimum TXOP duration
shall be at least the time to transmit one maximum MSDU size successfully at the minimum PHY
rate specified in the TSPEC. If maximum MSDU size is not specified in the TSPEC, then the
minimum TXOP duration shall be at least the time to transmit one nominal MSDU size successfully
at the minimum PHY rate. The vendors are free to implement any optimized algorithms, such as
reducing the polling overheads, increasing the TXOP duration, etc., within the parameters of the
transmitted schedule.
— The HC shall admit its request based on Infrastructure Authorization Information in
dot11InterworkingEntry, which is part of the dot11InterworkingTable. The dot11InterworkingEntry
specifies whether a non-AP STA is permitted to use HCCA, its throughput limitation and its
minimum delay bound.
When the HC aggregates the admitted TS, it shall set the Aggregation field in the granted TSPEC to 1. An AP
shall schedule the transmissions in HCCA TXOPs and communicate the service schedule to the STA. The HC
shall provide an aggregate service schedule if the STA sets the Aggregation field in its TSPEC request. If the
AP establishes an aggregate service schedule for a STA, it shall aggregate all HCCA streams for the STA. The
service schedule is communicated to the STA in a Schedule element contained in an ADDTS Response frame.
In the ADDTS Response frame, the modified service start time shall not exceed the requested service start
time, if specified in ADDTS Request frame, by more than one maximum service interval (SI). The HC uses the
maximum SI for the initial scheduling only as there might be situations that HC is not be able to service the TS
at the scheduled timing, due to an EDCA or DCF transmission or other interferences interrupting the schedule.
40
The lower order 4 octets of the TSF timer cover a span of around 71 min. Due to TSF timer wrapover and due to the possibility of
receiving the schedule frame after the indicated start time timer, ambiguity may occur. This ambiguity is resolved by using the nearest
absolute TSF timer value in past or future when the lower order 4 octets match the Start Time field in the Schedule element.
1402
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Service Interval field value in the Schedule element shall be greater than the minimum SI. The service
schedule could be subsequently updated by an AP as long as it meets TSPEC requirements.
The HC may update the service schedule at any time by sending a Schedule element in a Schedule frame. The
updated schedule is in effect when the HC receives the Ack frame for the Schedule frame. The service start
time in the Schedule element in the Schedule frame shall not exceed the beginning of the immediately previous
SP by more than the maximum SI. The service start time shall not precede the beginning of the immediately
previous SP by more than the minimum SI.
A STA may affect the service schedule by modifying or deleting its existing TS as specified in 11.4.
K.3.1 provides guidelines for deriving an aggregate service schedule for a single STA from the STA’s admitted
TS. The schedule shall meet the QoS requirements specified in the TSPEC.
During any time interval [t1, t2] including the interval that is greater than the specification interval, the
cumulative TXOP duration shall be greater than the time required to transmit all MSDUs (of nominal MSDU
size) arriving at the mean data rate for the stream, over the period [t1, t2 – D]. The parameter D is set to the
specified maximum SI in the TSPEC. If maximum SI is not specified, then D is set to the delay bound in the
TSPEC.
The HC shall use the minimum PHY rate in calculating TXOPs if the minimum PHY rate is present in the
TSPEC field in the ADDTS response. Otherwise, the HC may use an observed PHY rate in calculating TXOPs.
A STA may have an operational rate lower than the minimum PHY rate due to varying conditions on the
channel for a short time and still may be able to sustain the TS without changing the minimum PHY rate in the
TSPEC.
A minimum set of TSPEC fields shall be specified during the TSPEC negotiation. The specification of a
minimum set of parameters is required so that the scheduler can determine a schedule for the stream that is to
be admitted. These parameters are Mean Data Rate, Nominal MSDU Size, Minimum PHY Rate, Surplus
Bandwidth Allowance, and at least one of Maximum Service Interval and Delay Bound in the ADDTS Request
frame. In the ADDTS Response frame, these parameters are Mean Data Rate, Nominal MSDU Size, Minimum
PHY Rate, Surplus Bandwidth Allowance, and Maximum Service Interval and shall be nonzero when a stream
is admitted.
If any of the elements in the minimum set of parameters does not have the required nonzero value, as specified
above in this subclause, in the ADDTS Request frame, the HC may replace the unspecified parameters with
nonzero values and admit the stream, or it may reject the stream. If the HC admits the stream with the
alternative set of TSPEC fields, these parameters are indicated to the STA through the ADDTS Response
frame. If both maximum SI and delay bound are specified, the HC may use only the maximum SI. If any other
parameter is specified in the TSPEC element, the scheduler may use it when calculating the schedule for the
stream. The HC may also use the UP value in the TS Info field for admission control or scheduling purposes;
however, this decision is outside the scope of this standard. The mandatory set of parameters might be set by
any higher layer entity or may be generated autonomously by the MAC.
If a STA specifies a nonzero minimum SI and if the TS is admitted, the HC shall generate a schedule that
conforms to the specified minimum SI.
A reference design for a sample scheduler and admission control unit is provided in Annex K. A sample use of
the TSPEC for admission control is also described in Annex K.
1403
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.23 Mesh coordination function (MCF)
10.23.1 General
Under MCF, the basic unit of allocation of the right to transmit onto the WM is the TXOP. Each TXOP is
defined by a starting time and a defined maximum length.
There are two types of TXOP in MCF: EDCA TXOPs and MCCA TXOPs. The EDCA TXOP is obtained by
a mesh STA winning an instance of EDCA contention (see 10.22.2). The MCCA TXOP is obtained by a
mesh STA gaining control of the WM during an MCCAOP. The MCCAOP is an interval of time for frame
transmissions that has been reserved by means of the exchange of MCCA frames (see 10.23.3).
EDCA TXOPs of a mesh STA that has dot11MCCAActivated true shall not overlap with the time periods of
any of its tracked MCCAOP reservations.
The process of tracking MCCAOP reservations involves the recording of the MCCAOP reservations and the
data that structure the MCCAOP advertisements of these reservations, namely the advertisement set
sequence number, advertisement elements bitmap, and the advertisement element indexes, in a local
database, and the updating of this database on the basis of received advertisements as described in
10.23.3.7.5.
10.23.2 MCF contention based channel access
MCF implements the same EDCA (see 10.22.2) as does HCF.
10.23.3 MCF controlled channel access (MCCA)
10.23.3.1 General
MCF controlled channel access (MCCA) is an optional access method that allows mesh STAs to access the
WM at selected times with lower contention than would otherwise be possible. This standard does not
require all mesh STAs to use MCCA. MCCA might be used by a subset of mesh STAs in an MBSS.
However, MCCAOP reservations may be set up among mesh STAs that have dot11MCCAActivated true
and that operate on the same channel; MCCAOP reservations shall not be set up otherwise. The performance
of MCCA might be impacted by STAs that do not respect MCCAOP reservations.
MCCA enabled mesh STAs use Management frames to make reservations for transmissions. The mesh STA
transmitting an MCCA Setup Request frame to initiate a reservation becomes the MCCAOP owner of the
MCCAOP reservation. The receivers of the MCCA Setup Request frame are the MCCAOP responders. The
MCCAOP owner and the MCCAOP responders advertise this MCCAOP reservation to their neighbors via
an MCCAOP advertisement. An MCCA enabled neighbor mesh STA shall not transmit during these
reserved MCCAOP time periods. During its MCCAOP, the MCCAOP owner obtains a TXOP by winning
an instance of EDCA contention. Because of its reservation, the MCCAOP owner experiences no
competition from other MCCA enabled neighbor mesh STAs. At the start of an MCCAOP, the EDCAF of
the MCCAOP owner replaces the AIFSN, CWmin, and CWmax value of its dot11EDCATable with MCCA
access parameters.
In order to use MCCA, a mesh STA maintains synchronization with its neighboring mesh STAs. Mesh
STAs that use MCCA shall use a DTIM interval with a duration of 2n 100 TU with n being a non-negative
integer less than or equal to 17. Additionally, a mesh STA shall track the reservations of its neighboring
mesh STAs.
1404
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 1—The DTIM interval of this form was chosen so that the starting times of the reservations do not change
relative to each other between consecutive DTIM intervals. The restriction that n be less than or equal to 17 was chosen
for compatibility with the maximum DTIM interval as well as the compatibility of the reservation’s MCCAOP offset
range (see 9.4.2.106.2) with the maximal DTIM interval length.
NOTE 2—It is allowed that a different value for the DTIM interval is used for mesh STAs that use MCCA in an MBSS
that is centrally controlled and the central authority provides a coordination of the DTIM interval of the mesh STAs that
use MCCA in the MBSS.
10.23.3.2 MCCA activation
When it receives an MLME-ACTIVATEMCCA.request primitive from its SME, a mesh STA shall set the
MCCA Enabled subfield of the Mesh Capability field in the Mesh Configuration element to 1 in Beacon and
Probe Response frames it transmits. It shall not initiate or accept MCCA Setup Request frames for
dot11MCCAScanDuration TUs after the receipt of the MLME-ACTIVATEMCCA.request primitive.
During the dot11MCCAScanDuration waiting period, the mesh STA learns its neighborhood MCCAOP
periods by receiving Beacon, Probe Response, or MCCA Advertisement frames from neighboring mesh
STAs.
After this period, the mesh STA may initiate and accept MCCA Setup Request frames as per 10.23.3.6.
10.23.3.3 MCCAOP reservations
An MCCAOP reservation specifies a schedule for frame transmissions. The time periods scheduled for
frame transmissions in the reservation are called MCCAOPs. The schedule is set up between an MCCAOP
owner and one (for individually addressed frames) or more (for group addressed frames) MCCAOP
responders. MCCAOPs are set up by means of the procedure defined in 10.23.3.6. Once an MCCAOP
reservation is set:
— Access to the channel by MCCA enabled mesh STAs is governed by the procedures in 10.23.3.9.
— The MCCAOP reservation is advertised according to the procedures in 10.23.3.7.
The schedule is defined by means of the MCCAOP Reservation field defined in 9.4.2.106.2. An MCCAOP
reservation schedules a series of MCCAOPs with a common duration given in the MCCAOP Duration
subfield of the MCCAOP Reservation field. This series is started after the first DTIM Beacon following the
successful completion of the MCCAOP setup procedure and terminated when the MCCAOP reservation is
torn down.
The reservation defines a regular schedule of MCCAOPs in the DTIM interval of the MCCAOP owner. The
number of MCCAOPs in the DTIM interval is given by the value of the MCCAOP Periodicity subfield of
the MCCAOP Reservation field. The MCCAOP Offset subfield specifies the offset of the first scheduled
MCCAOP of the transmission schedule relative to the beginning of the DTIM interval of the MCCAOP
owner. The following MCCAOPs are separated by a time interval with a duration equal to the length of the
DTIM period divided by the value in the MCCAOP Periodicity subfield.
An example of an MCCAOP reservation schedule is shown in Figure 10-31. In this example, the MCCAOP
Periodicity equals two, so that there are two MCCAOPs in each DTIM interval. As further illustrated in the
figure, the MCCAOP Offset value indicates the beginning of the first MCCAOP in each DTIM interval.
If a mesh STA adjusts its TBTT, e.g., in response to a TBTT adjustment request, it shall adjust the
MCCAOP reservations by modifying the MCCAOP Offset of each MCCAOP reservation.
1405
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DTIM Interval DTIM Interval
MCCAOP (DTIM Duration) /
Offset (MCCAOP Periodicity)
t
MCCAOP
Duration
MCCAOP
Figure 10-31—Example MCCAOP reservation with MCCAOP Periodicity equal to 2
An MCCAOP reservation is identified by an MCCAOP reservation ID. The MCCAOP owner shall select an
MCCAOP reservation ID that is unique among all of its MCCAOP reservations. The MCCAOP reservation
ID and MAC address of the MCCAOP owner uniquely identify the MCCAOP reservation in the mesh BSS.
The MCCAOP reservation ID is an 8-bit unsigned integer and included in the MCCAOP Reservation ID
field of an MCCAOP Setup Request element. If this MCCAOP setup request is for an individually
addressed transmission, the MCCAOP Reservation ID is between 0 and 127. If this MCCAOP setup request
is for a group addressed transmission, the MCCAOP Reservation ID is between 128 and 254. The value 255
is not used to identify a specific MCCAOP reservation but is reserved for usage in the MCCAOP teardown
procedure as described in 10.23.3.8.
A mesh STA with dot11MCCAActivated equal to true shall be able to track at least
dot11MCCAMinTrackStates MCCAOP reservations, including its own reservations. If the number of
tracked MCCAOP reservations is less than dot11MCCAMaxTrackStates, the mesh STA shall be able to
track, set up, and accept additional reservations. In this case, the mesh STA shall set the Accept Reservations
subfield in the Flags field to 1 in the MCCAOP Advertisement Overview elements it transmits.
If the number of tracked MCCAOP reservations is greater than or equal to dot11MCCAMaxTrackStates, the
mesh STA shall not track, set up, or accept additional reservations. In this case, the mesh STA shall set the
Accept Reservations subfield in the Flags field to 0 in the MCCAOP Advertisement Overview elements it
transmits. Moreover, it shall reply to MCCA Setup Request frames with an MCCA Setup Reply frame with
the MCCA Reply Code field in the MCCAOP Setup Reply element equal to 3: Reject: MCCAOP track limit
exceeded.
The tracked MCCAOP reservations are advertised as described in 10.23.3.7. How to access the medium
during the tracked MCCAOP reservations is specified in 10.23.3.9.
10.23.3.4 Neighborhood MCCAOP periods at a mesh STA
The set of MCCAOP reservations in which a mesh STA is involved as an MCCAOP owner or an MCCAOP
responder and that are used for individually addressed transmissions are referred to as the TX-RX periods of
this mesh STA.
The set of MCCAOP reservations in which a mesh STA is involved as an MCCAOP owner or an MCCAOP
responder and that are used for group addressed transmissions are referred to as the broadcast periods of this
mesh STA. Optionally, the broadcast periods of a mesh STA includes known Target Beacon Transmission
Time of Beacon frames for which this mesh STA is either the transmitter or the receiver, and transmission or
reception periods of a STA that is collocated with the reporting mesh STA, for example, beacon or HCCA
times of a collocated AP.
1406
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The interference periods of a mesh STA comprise the TX-RX periods and the broadcast periods of its
neighbor mesh STAs in which the mesh STA is not involved as the owner or as a responder. The TX-RX
periods, the broadcast periods, and the interference periods of a mesh STA shall not be used for a new
MCCAOP reservation with the mesh STA as transmissions in these periods might experience interference
from the transmissions in the new MCCAOPs or might cause interference to them.
The interference periods are directly derived from the TX-RX Periods Report field and Broadcast Periods
Report field of the MCCAOP Advertisement elements transmitted by the neighbor mesh STAs. The
Interference Periods Report field reflects the latest TX-RX Periods Report and Broadcast Periods Report
fields received from the neighbor mesh STAs.
The MCCAOP reservations of a mesh STA and its neighbors define a set of MCCAOPs that are already
reserved for frame transmissions in the mesh neighborhood of a mesh STA. This set of MCCAOPs is
referred to as the neighborhood MCCAOP periods for the mesh STA. Thus, neighborhood MCCAOP periods
at a mesh STA include all MCCAOPs for which the mesh STA or one of its neighbors, including neighbors
from other MBSSs, is either transmitter or receiver.
10.23.3.5 MCCA access fraction (MAF)
The MCCA access fraction at a mesh STA is the ratio of the time reserved for MCCAOPs in the DTIM
interval of this mesh STA to the duration of the DTIM interval. This parameter is reported in the MCCA
Access Fraction field of the MCCAOP Advertisement Overview elements. The maximum value for the
MAF that is allowed at a mesh STA is specified by dot11MAFlimit. The dot11MAFlimit is copied into the
MAF Limit field of the MCCAOP Advertisement Overview element as described in 9.4.2.108.
The MAF and the MAF Limit may be used to limit the use of MCCA in the mesh neighborhood of a mesh
STA, as specified in 10.23.3.6. Before attempting to set up an MCCAOP reservation with a neighbor peer
mesh STA, a mesh STA shall verify that the new MCCAOP reservation does not cause its MAF to exceed
its MAF Limit and that the new MCCAOP reservation does not cause the MAF of any of its neighbor peer
mesh STAs to exceed their MAF Limit. An MCCAOP setup request shall be refused by the intended
MCCAOP responder if the MAF limit of one of its neighbors is exceeded due to the new setup.
10.23.3.6 MCCAOP setup procedure
The setup of an MCCAOP reservation is initiated by the MCCAOP owner and is accepted or rejected by the
MCCAOP responder. The setup procedure for an MCCAOP reservation is as follows:
a) The MCCAOP owner shall build a map of the neighborhood MCCAOP periods in the DTIM
interval after hearing advertisements from all of its neighbor mesh STAs with the MCCA Enabled
subfield of the Mesh Capability field in the Mesh Configuration element equal to 1. It shall request
an MCCAOP advertisement, as described in 10.23.3.7.8, from each neighbor mesh STA from which
no advertisement was heard in the last dot11MCCAAdvertPeriodMax DTIM intervals.
b) The MCCAOP owner shall determine the MCCAOP reservation. The MCCAOP parameters shall be
chosen in such a way that they satisfy the following conditions:
1) The reservation shall not overlap with the neighborhood MCCAOP periods of the MCCAOP
owner.
2) The reservation shall not overlap with the interference periods of the intended MCCAOP
responder or responders.
3) The reservation shall not cause the MAF limit to be exceeded for either itself or its neighbor
mesh STAs.
4) The Accept Reservations subfield of the Flags field equals 1 in the most recent MCCAOP
Advertisement Overview element received from all intended MCCAOP responders.
1407
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) If the conditions in item b) are satisfied, the MCCAOP owner shall transmit an MCCAOP Setup
Request element to the intended MCCAOP responder with the chosen MCCAOP parameters.
d) The MCCAOP responder shall verify the following conditions:
1) The reservation does not overlap with its neighborhood MCCAOP periods.
2) The reservation does not cause the MAF limit to be exceeded for itself or its neighbor mesh
STAs.
3) The number of reservations in its neighborhood MCCAOP periods does not exceed
dot11MCCAMaxTrackStates.
e) If the conditions in item d) are satisfied, the responder shall send an MCCA Setup Reply frame to
the MCCAOP owner with the MCCA Reply Code field in the MCCAOP Setup Reply element equal
to 0: Accept, as defined in Table 9-223.
f) If the conditions in item d) are satisfied and the MCCAOP request has been intended for group
addressed transmissions, the responder shall include the reservation in its MCCAOP advertisement
only after the MCCAOP advertisement from the MCCAOP owner is received.
g) If not all of the conditions in item d) are satisfied and the MCCAOP request is intended for
individually addressed transmissions, the responder shall transmit to the MCCAOP owner an
MCCA Setup Reply frame that is constructed as follows:
1) If the condition in item d)1) is not satisfied and both conditions in item d)2) and item d)3) are
satisfied, the responder may calculate an alternative MCCAOP reservation and include it in the
MCCAOP Reservation field of the MCCAOP Setup Reply element. It shall set the MCCA
Reply Code field of the MCCAOP Setup Reply element to 1: Reject: MCCAOP reservation
conflict, as defined in Table 9-223.
2) If the condition in item d)2) is not satisfied, it shall set the MCCA Reply Code field of the
MCCAOP Setup Reply element to 2: Reject: MAF limit exceeded, as defined in Table 9-223.
3) If the condition in item d)2) is satisfied and the condition in item d)3) is not satisfied, it shall set
the MCCA Reply Code field of the MCCAOP Setup Reply element to 3: Reject: MCCAOP
track limit exceeded, as defined in Table 9-223.
h) If not all of the conditions in item d) are satisfied and the MCCAOP request is intended for group
addressed transmissions, the responder shall send an MCCA Setup Reply frame to the MCCAOP
owner with the MCCA Reply Code field in the MCCAOP Setup Reply element equal to 1: Reject:
MCCAOP reservation conflict.
i) If the MCCAOP owner receives an MCCA Setup Reply frame with MCCA Reply Code equal to
Accept, the MCCAOP reservation is established. Otherwise, the mesh STA may repeat the
MCCAOP setup procedure using a modified MCCAOP Setup Request. If an alternative MCCAOP
reservation is included in the MCCAOP Setup Reply element, the mesh STA may consider this
alternative in its modified MCCAOP Setup Request.
10.23.3.7 MCCAOP advertisement
10.23.3.7.1 General
A mesh STA with dot11MCCAActivated equal to true tracks MCCAOP reservations. The tracked
MCCAOP reservations contain the neighborhood MCCAOP periods and optionally other periodic
transmission of itself or of neighboring STAs.
The MCCAOP advertisement set contains all MCCAOP reservations tracked by the mesh STA. The
MCCAOP advertisement set is represented by an MCCAOP Advertisement Overview element and zero (if
the MCCAOP advertisement set is empty) or more (if the MCCAOP advertisement set is nonempty)
MCCAOP Advertisement elements. An MCCAOP Advertisement element contains one or more tracked
MCCAOP reservations.
1408
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The mesh STA advertises its MCCAOP advertisement set to its neighbor mesh STAs.
This subclause describes how the mesh STA constructs the MCCAOP Advertisement Overview element and
the MCCAOP Advertisement elements. Further, this subclause describes the procedure to advertise an
MCCAOP advertisement set, the procedure to request an MCCAOP advertisement from a neighboring mesh
STA, and the procedure to process a received MCCAOP advertisement.
10.23.3.7.2 Construction of an MCCAOP advertisement set
The following terminology is used in this subclause:
— TX-RX report: an MCCAOP Reservation field contained in the TX-RX Periods Report field of an
MCCAOP Advertisement element
— Broadcast report: an MCCAOP Reservation field contained in the Broadcast Periods Report field of
an MCCAOP Advertisement element
— Interference report: an MCCAOP Reservation field contained in the Interference Periods Report
field of an MCCAOP Advertisement element
Each MCCAOP reservation tracked by a mesh STA is one of the following types:
— TX-RX period:
— An MCCAOP reservation for individually addressed frames for which the mesh STA is the
MCCAOP owner or the MCCAOP responder.
— Broadcast period:
— An MCCAOP reservation for group addressed frames for which the mesh STA is the
MCCAOP owner or the MCCAOP responder.
— Optionally, a known Target Beacon Transmission Time of Beacon frames for which the mesh
STA is either the transmitter or the receiver.
— Optionally, a transmission or reception period of a STA that is collocated with the mesh STA,
for example, beacon or HCCA times of a collocated AP.
— Interference period:
— A TX-RX or a broadcast period reported by a neighbor peer mesh STAs of the mesh STA
excluding those periods for which this mesh STA is either the MCCAOP owner or the
MCCAOP responder.
— Optionally, a TX-RX or a broadcast period reported by neighbor nonpeer mesh STAs of the
mesh STA.
The MCCAOP reservations are grouped into the following sets:
— MCCAOP TX-RX advertisement set, which includes all TX-RX periods
— MCCAOP broadcast advertisement set, which includes all broadcast periods
— MCCAOP interference advertisement set, which includes all interference periods
These three sets constitute the MCCAOP advertisement set. The mesh STA uses the MCCAOP Overview
element and MCCAOP Advertisement elements to advertise its MCCAOP advertisement set to its neighbor
mesh STAs.
The mesh STA acts as follows to construct the MCCAOP Overview elements and the MCCAOP
Advertisement elements:
a) If the MCCAOP advertisement set is nonempty, the mesh STA constructs one or more MCCAOP
reports according to the format described in 9.4.2.109.3 as follows:
1409
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
1) If the MCCAOP TX-RX advertisement set is nonempty, the mesh STA constructs one or more
TX-RX reports according to the format described in 9.4.2.109.3 such that each reservation in
the MCCAOP TX-RX advertisement set occurs exactly in one TX-RX report.
2) If the MCCAOP broadcast advertisement set is nonempty, the mesh STA constructs one or
more broadcast reports according to the format described in 9.4.2.109.3 such that each
reservation in the MCCAOP broadcast advertisement set occurs exactly in one broadcast
report.
3) If the MCCAOP interference advertisement set is nonempty, the mesh STA constructs one or
more interference reports according to the format described in 9.4.2.109.3 such that each
reservation in the MCCAOP interference advertisement set occurs exactly in one interference
report.
b) If the MCCAOP advertisement set is nonempty, the mesh STA constructs one or more MCCAOP
Advertisement elements as follows:
1) The MCCAOP Advertisement Set Sequence Number field is set to the MCCAOP
advertisement set sequence number as explained in 10.23.3.7.3.
2) The MCCAOP Advertisement Element Index subfield is set to an identifier that uniquely
identifies the MCCAOP Advertisement element in the MCCAOP advertisement set.
3) Each MCCAOP Advertisement element includes at least one of the TX-RX reports, broadcast
reports, or interference reports. Moreover, it includes at most one of the TX-RX reports, at
most one of the broadcast reports, and at most one of the interference reports. In case the
MCCAOP Advertisement element contains a TX-RX report, the TX-RX Report Present
subfield of the MCCAOP Advertisement Element Information field is set to 1; otherwise this
subfield is set to 0. In case the MCCAOP Advertisement element contains a broadcast report,
the Broadcast Report Present subfield of the MCCAOP Advertisement Element Information
field is set to 1; otherwise this subfield is set to 0. In case the MCCAOP Advertisement element
contains an interference report, the Interference Report Present subfield of the MCCAOP
Advertisement Element Information field is set to 1; otherwise, this subfield is set to 0.
4) Each report as constructed in step a) is present in exactly one MCCAOP Advertisement
element.
c) The mesh STA constructs one MCCAOP Advertisement Overview element such that
1) The MCCAOP Advertisement Set Sequence Number field is set to the advertisement set
sequence number as explained in 10.23.3.7.3.
2) The Medium Access Fraction field is set to the medium access fraction.
3) The MAF limit field is set to dot11MAFlimit.
4) The Accept Reservations field is set to 1 if the number of tracked reservations of this mesh
STA is less than dot11MCCAMaxTrackStates, and set to 0 otherwise.
5) Bit i of the Advertisement Elements Bitmap field is set to 1 if an MCCAOP Advertisement
element with the MCCAOP Advertisement Element Index subfield equal to i is part of the
representation of this MCCAOP advertisement set, and set to 0 otherwise.
10.23.3.7.3 Setting the MCCAOP advertisement set sequence number
The MCCAOP advertisement set sequence number identifies an MCCAOP advertisement set. Mesh STAs
with dot11MCCAActivated equal to true assign MCCAOP advertisement set sequence numbers from a
single modulo 256 counter. The MCCAOP advertisement set sequence number is initialized to 0. The
MCCAOP advertisement set sequence number shall be incremented by 1 if one of the following conditions
holds:
a) The mesh STA sets the bit for an MCCAOP Advertisement element in the Advertisement Elements
Bitmap from 0 to 1 and this bit has been set to 1 under the same MCCAOP Advertisement Sequence
Number before.
1410
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) The bit of the Advertisement Elements Bitmap corresponding to an MCCAOP Advertisement
element is equal to 1 and the content of this MCCAOP Advertisement element changes.
However, the MCCAOP advertisement set sequence number may remain unchanged if
— The mesh STA changes a bit in the Advertisement Element Bitmap from 0 to 1 and this bit has not
been set to 1 under the same MCCAOP Advertisement Sequence Number before, or
— The mesh STA changes a bit in the Advertisement Elements Bitmap from 1 to 0.
NOTE—The Advertisement Set Sequence Number identifies the current distribution of the MCCAOP advertisement set
over the MCCAOP Advertisement elements. Using a new MCCAOP advertisement set sequence number signals a new,
(possibly) completely different distribution of the MCCAOP advertisement set over the MCCAOP Advertisement
elements, and requires an advertisement of all reservations of the MCCAOP advertisement set. Leaving the MCCAOP
advertisement set sequence number unchanged as in the previous MCCAOP Advertisement Overview element indicates
MCCAOP Advertisement elements that have previously been advertised are not changed and remain current. This
enables a limited advertisement procedure in which only new MCCAOP Advertisement elements are advertised.
Additionally, this enables mesh STAs that operate in light or deep sleep mode to request a limited update of the
MCCAOP advertisement set of a neighboring mesh STA in which only new MCCAOP Advertisement elements are
included.
10.23.3.7.4 Advertisement procedure
To advertise its MCCAOP advertisement set, the mesh STA constructs a representation of the MCCAOP
advertisement set as described in 10.23.3.7.2. The MCCAOP advertisement set is advertised by transmitting
an MCCAOP Advertisement Overview element and zero or more MCCAOP Advertisement elements (see
10.23.3.7.2) to neighbor peer mesh STAs. The MCCAOP Advertisement Overview element and the
MCCAOP Advertisement elements are transmitted in Beacon frames, Probe Response frames, or MCCA
Advertisement frames.
The mesh STA shall advertise its MCCAOP advertisement set according to the following rules:
a) The mesh STA shall advertise at least one MCCAOP Advertisement Overview element in every
dot11MCCAAdvertPeriodMax DTIM intervals.
b) The mesh STA shall advertise its MCCAOP Advertisement Overview element and any new
MCCAOP Advertisement elements at the latest with the transmission of its next Beacon frame after
its MCCAOP advertisement set has changed.
c) The mesh STA shall advertise the requested MCCAOP Advertisement elements as described in
10.23.3.7.8 if the mesh STA receives an MCCA Advertisement Request frame.
10.23.3.7.5 Receipt of an MCCAOP advertisement
Upon receipt of an MCCAOP advertisement a mesh STA with dot11MCCAActivated shall compare the
Advertisement Set Sequence Number contained in the MCCAOP Advertisement Overview element of the
received MCCAOP advertisement with the last advertisement set sequence number that this mesh STA
tracked for the sender of the received MCCAOP advertisement.
If the tracked advertisement set sequence number does not equal the Advertisement Set Sequence Number
of the received MCCAOP advertisement, the mesh STA shall perform the procedure described in
10.23.3.7.6.
If the tracked advertisement set sequence number equals the Advertisement Set Sequence Number of the
received MCCAOP advertisement, the mesh STA shall compare the Advertisement Elements Bitmap
contained in the received MCCAOP Advertisement Overview element with the last Advertisement Elements
Bitmap that this mesh STA tracked for the sender of the received MCCAOP advertisement. If the tracked
Advertisement Elements Bitmap does not equal the Advertisement Elements Bitmap of the received
MCCAOP advertisement, the mesh STA shall perform the procedure described in 10.23.3.7.7.
1411
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—If both the tracked advertisement set sequence number equals the Advertisement Set Sequence Number of the
received MCCAOP advertisement and the tracked Advertisement Elements Bitmap equals the Advertisement Elements
Bitmap of the received MCCAOP advertisement, the MCCAOP advertisement set of the sender of the MCCAOP
advertisement tracked by the mesh STA is current, and no update of the MCCAOP advertisement set is needed.
10.23.3.7.6 Complete update of the tracked MCCAOP reservations of a neighbor mesh STA
The mesh STA performed the steps in 10.23.3.7.5 and detected that the MCCAOP advertisement set
sequence number has been updated. Consequently, the mesh STA shall operate as follows.
The mesh STA shall discard all MCCAOP reservations that it tracked for the sender of the received
MCCAOP advertisement. The mesh STA shall record the Advertisement Set Sequence Number and the
source address (SA) of the received MCCAOP advertisement. The mesh STA shall record all reservations in
the MCCAOP Advertisement elements of the received MCCAOP advertisement.
If the mesh STA does not receive all MCCAOP Advertisement elements of the sender of the MCCAOP
advertisement before a frame exchange sequence on the wireless medium causes the mesh STA to set its
NAV, the mesh STA shall perform the MCCAOP advertisement request procedure as described in
10.23.3.7.8.
10.23.3.7.7 Partial update of the tracked MCCAOP reservations of a neighbor mesh STA
The mesh STA performed the steps in 10.23.3.7.5 and detected that part of the MCCAOP advertisement set
of the sender of the MCCAOP advertisement has been updated. Consequently, the mesh STA shall operate
as follows for each bit in the Advertisement Elements Bitmap contained in the MCCAOP Advertisement
Overview element of the received MCCAOP advertisement.
If the bit in position n of the Advertisement Elements Bitmap in the received MCCAOP Advertisement is
equal to 0 and if the bit in position n of the Advertisement Elements Bitmap tracked for the sender of the
received MCCAOP advertisement is equal to 1, the mesh STA shall delete the reservations with the same
Advertisement Sequence Number and the same MCCAOP Advertisement Element Index received from the
same sender from its tracked reservations.
If the bit in position n of the Advertisement Elements Bitmap in the received MCCAOP Advertisement is
equal to 1 and if the bit in position n of the Advertisement Elements Bitmap tracked for the sender of the
received MCCAOP advertisement is equal to 0, the mesh STA shall add the reservations of the received
MCCAOP Advertisement element with the MCCAOP Advertisement Element Index set to n to its tracked
reservations. If the mesh STA does not receive this MCCAOP Advertisement element of the sender of the
MCCAOP Advertisement before a frame exchange sequence on the wireless medium causes the mesh STA
to set its NAV, the mesh STA shall perform the MCCAOP Advertisement request procedure as described in
10.23.3.7.8.
NOTE—If the bit in position n of the received Advertisement Elements Bitmap contained in the received MCCAOP
Advertisement is equal to the bit in position n of the Advertisement Elements Bitmap tracked for the sender of the
received MCCAOP advertisement, then the Advertisement element with the MCCAOP Advertisement Element Index
equal to n is current, and no update of this Advertisement element is needed.
10.23.3.7.8 MCCAOP advertisement request procedure
To request all MCCAOP Advertisement elements from a neighbor peer mesh STA, the mesh STA transmits
an MCCA Advertisement Request frame without an MCCAOP Advertisement Overview element.
To request a subset of the MCCAOP Advertisement elements of a neighbor peer mesh STA, the mesh STA
transmits an MCCA Advertisement Request frame including an MCCAOP Advertisement Overview
element. The mesh STA shall set the contents of the MCCAOP Advertisement Overview element as
follows. The mesh STA sets
1412
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) The Advertisement Set Sequence Number field to the Advertisement Sequence Number that it
tracks for the recipient of this frame
b) In the Advertisement Element Bitmap, the bit to 1 for each MCCAOP Advertisement element that
the mesh STA requests from the recipient of this frame
c) The Flags field, the MCCA Access Fraction field, and the MAF Limit field to 0
The mesh STA shall discard the MCCA Advertisement Request frame from its frame queue if it receives all
of the MCCAOP Advertisement elements that it requests in the MCCAOP Advertisement Request.
10.23.3.8 MCCAOP teardown
10.23.3.8.1 Conditions that trigger an MCCAOP teardown
The MCCAOP owner and the MCCAOP responder may initiate a teardown of an MCCAOP reservation,
e.g., when the reservation is no longer needed. A mesh STA shall act as follows to resolve conflicts between
MCCAOP reservations in its neighborhood MCCAOP periods. If the conflict is caused by overlapping
reservations from its TX-RX periods and broadcast periods, it shall select one of these reservations and
initiate a teardown for it. If the conflict is caused by an overlap between a reservation from its TX-RX
periods or broadcast periods, and another reservation from its interference periods, it shall act as follows. It
creates a first unsigned integer by inverting the bit order of its MAC address and a second unsigned integer
by inverting the bit order of the lowest of the known MAC addresses of the owner and responder(s) of the
reservation in the interference periods. If the first unsigned integer is smaller than the second unsigned
integer, it shall initiate a teardown of the reservation in its TX-RX or broadcast periods. Otherwise, it may
initiate a teardown of the reservation in its TX-RX or broadcast periods.
There are also other conditions that trigger the MCCAOP owner and responder to delete a reservation,
without an explicit tear down. An MCCAOP owner shall delete a reservation for an individually addressed
transmission when it has not received an acknowledgment for any frame transmission in the MCCAOPs
corresponding to the reservation for greater than dot11MCCAOPtimeout time. An MCCAOP responder
shall delete a reservation for individually addressed transmission or group addressed transmissions when it
has not received a frame transmission in any of the MCCAOPs corresponding to the reservation for greater
than dot11MCCAOPtimeout time.
10.23.3.8.2 MCCAOP teardown procedure
The teardown is initiated by transmitting an MCCA Teardown frame. The MCCAOP Reservation ID field in
the MCCAOP Teardown element is set to the MCCAOP Reservation ID of the reservation that is to be torn
down. In case the tear down is initiated by an MCCAOP responder, the MCCAOP Owner field of the
MCCAOP Teardown element is set to the MAC address of the MCCAOP owner.
The transmitter of the MCCA Teardown frame deletes the reservation after the MCCA Teardown frame has
been successfully transmitted. The receiver of the MCCA Teardown frame acts as follows. In case the
MCCAOP Reservation ID field corresponds to a reservation for individually addressed transmissions, it
deletes the reservation. If the reservation is for group addressed transmissions for which it is the MCCAOP
owner, it deletes the reservation if there are no other MCCAOP responders for this reservation.
The MCCAOP owner acts as follows when deleting a reservation:
— It stops executing the access procedure described in 10.23.3.9.1 at the start of the MCCAOPs
corresponding to the reservation that was deleted.
— In case the reservation was for individually addressed frames, it stops advertising the MCCAOP
reservation in its TX-RX Periods Report field.
1413
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— In case the reservation was for group addressed frames, it stops advertising the MCCAOP
reservation in its Broadcast Periods Report field.
The MCCAOP responder acts as follows when deleting a reservation:
— It stops executing the procedure described in 10.23.3.9.2 during the MCCAOPs corresponding to the
reservation that was deleted.
— In case the reservation was for individually addressed frames, it stops advertising the MCCAOP
reservation in its TX-RX Periods Report field.
— In case the reservation was for group addressed frames, it stops advertising the MCCAOP
reservation in its Broadcast Periods Report field.
10.23.3.9 Access during MCCAOPs
10.23.3.9.1 Access by MCCAOP owners
At the start of the MCCAOP, the EDCAF of the MCCAOP owner shall set AIFSN[AC] equal to
dot11MCCAAIFSN, CWmax[AC] equal to dot11MCCACWmax, CW[AC] equal to dot11MCCACWmin,
QSRC[AC] to 0, and QLRC[AC] to 0 for all ACs. The TXOP limit shall specify a duration value no larger
than the MCCAOP Duration.
During the MCCAOP, the EDCAFs of the ACs operates as specified in 10.22.2, with the following
modifications.
— During the MCCAOP, the EDCAF of each AC shall consider only those frame whose RA matches
the MAC address of the MCCAOP responder.
— When the access to the medium is delayed, the TXOP limit shall specify a duration to end no later
than the MCCAOP start time plus the MCCAOP Duration.
— As specified in 10.23.3.9.2, a neighboring STA shall not access the WM during an MCCAOP, until
it receives a frame from either the MCCAOP owner or the MCCAOP responder. With the exception
of truncation of an MCCA TXOP by means of a CF-End, standard EDCA TXOP rules apply for the
remainder of the MCCAOP. For HT mesh STAs, these include the reverse direction protocol as
specified in 10.28.
— At the end of the MCCAOP, the parameters used by the EDCAF of the MCCAOP owner shall be set
to dot11EDCATable, and QSRC[AC] and QLRC[AC] shall be set to 0 for all ACs.
The MCCAOP owner may adjust the duration of an MCCAOP by setting the Duration/ID field in the frames
it transmits. In particular, if an MCCAOP owner has no data to transmit in an MCCAOP corresponding to an
MCCAOP reservation that is intended for individually addressed frames, it may transmit an individually
addressed QoS Null frame during the MCCAOP to end the MCCAOP.
NOTE—It is recommended to send a QoS Null frame to end the MCCAOP although there might be situations in which
the transmission of a QoS Null is not needed or undesirable.
If an MCCAOP owner has no data to transmit in an MCCAOP reservation that is intended for group ad-
dressed frames, it may transmit a group addressed QoS Null frame during the MCCAOP to end the
MCCAOP.
10.23.3.9.2 Access during an MCCAOP by mesh STAs that are not the MCCAOP owner
The MAC of a mesh STA with dot11MCCAActivated is true shall provide a Reservation Allocation Vector
(RAV) mechanism to indicate a busy medium from the start of an MCCAOP corresponding to a reservation
in its interference periods until the receipt of a frame transmitted by either the MCCAOP owner or the
MCCAOP responder. The RAV mechanism is provided in addition to the PHY and virtual CS mechanisms
described in 10.3.2.1. It is different from the virtual CS mechanism in two aspects. Firstly, a mesh STA
1414
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
might be neighbor to multiple ongoing MCCAOPs corresponding to different reservations and the regular
NAV setting and updating rules do not suffice to prevent interference during these reservations. Secondly,
the virtual CS mechanism is set immediately upon receipt of a frame, whereas the RAV mechanism is based
on reservation frames received at some earlier time instant. When either the CS function provided by the
PHY, the virtual CS function provided by the MAC via the NAV, or the RAV mechanism indicate a busy
medium during an MCCAOP for which the mesh STA is neither the MCCAOP owner nor the MCCAOP
responder, the medium shall be considered busy; otherwise, it shall be considered idle.
The RAV mechanism maintains an index of future MCCAOPs based on the reservation information that is
available in the interference periods of a mesh STA. At the start of each MCCAOP corresponding to a
reservation in the interference periods, a RAV is set to indicate a busy medium for the duration of the
MCCAOP given in the MCCAOP Duration subfield of the MCCAOP reservation. At the start of
each MCCAOP corresponding to a reservation in the TX-RX or broadcast periods for which the mesh STA
is an MCCAOP responder, a RAV is set to indicate a busy medium for the duration of the MCCAOP given
in the MCCAOP Duration subfield of the MCCAOP reservation. The RAV may be thought of as a counter,
corresponding to an MCCAOP corresponding to a reservation in the interference periods. The RAV counts
down to zero at a uniform rate. When the counter is zero, the RAV indication is that the medium is idle;
when nonzero, the indication is busy.
The mesh STA clears the RAV timer, i.e., sets it to 0, upon receipt of a frame from either the MCCAOP
owner or responder. If a mesh STA receives an RTS frame during an MCCAOP for which it is a MCCAOP
responder, with the RA address matching its MAC address and with the MAC address in the TA field in the
RTS frame matching the MAC address of the MCCAOP owner, then the STA shall send the CTS frame
after SIFS, without regard for the NAV and the RAV, and without resetting its NAV. The RAV for an
MCCAOP is not cleared upon receipt of a frame originating from stations that are not the MCCAOP owner
or responder. Since the NAV is set upon receipt of frames with a Duration/ID field, the MCCAOP owner
and responder adjust the reservation period of an MCCAOP to their actual traffic needs by the Duration/ID
field in the transmitted frame and obtain protection of the frame transmission via the NAV setting.
The RAV mechanism might be represented by a number of counters, where each counter corresponds to one
MCCAOP. The number of counters needed at any instant is equal to the number of MCCAOPs at this instant
corresponding to reservations in the interference periods of the mesh STA.
10.23.3.10 Interaction with time synchronization
If a mesh STA adjusts its TBTT, e.g., in response to a TBTT Adjustment Request, it shall adjust the
reservations by modifying the MCCAOP Offset of each of the tracked MCCAOP reservations. If a mesh
STA adjusts its timing offset value with respect to a neighbor mesh STA, as specified in 14.13.2.2, it shall
adjust the reservations by modifying the MCCAOP Offset of each of the tracked MCCAOP reservations for
which this neighbor mesh STA is the owner. In either case, an MCCAOP advertisement of a mesh STA shall
always contain the most recent MCCAOP Offsets.
10.24 Block acknowledgment (block ack)
10.24.1 Introduction
The block ack mechanism improves channel efficiency by aggregating several acknowledgments into one
frame. There are two types of block ack mechanisms: immediate and delayed. Immediate block ack is suitable
for high-bandwidth, low-latency traffic while the delayed block ack is suitable for applications that tolerate
moderate latency. In this subclause, the STA with data to send using the block ack mechanism is referred to as
the originator, and the receiver of that data as the recipient.
1415
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The block ack mechanism is initialized by an exchange of ADDBA Request/Response frames. After
initialization, blocks of QoS Data frames may be transmitted from the originator to the recipient. A block may
be started within a polled TXOP, within an SP, or by winning EDCA contention. The number of frames in the
block is limited, and the amount of state that is to be kept by the recipient is bounded. The MPDUs within the
block of frames are acknowledged by a BlockAck frame, which is requested by a BlockAckReq frame.
The block ack mechanism does not require the setting up of a TS; however, QoS STAs using the TS facility
may choose to signal their intention to use block ack mechanism for the scheduler’s consideration in assigning
TXOPs. The block ack mechanism is also used by the GCR service. Acknowledgments of frames belonging to
the same TID, but transmitted during multiple TXOPs/SPs, may also be combined into a single BlockAck
frame. This mechanism allows the originator to have flexibility regarding the transmission of Data frames. The
originator may split the block of frames across TXOPs/SPs, separate the data transfer and the block ack
exchange, and interleave blocks of MPDUs carrying all or part of MSDUs or A-MSDUs for different TIDs or
RAs.
Figure 10-32 illustrates the message sequence chart for the setup, data and block ack transfer, and the teardown
of the block ack mechanism, which are discussed in detail in 10.24.2 to 10.24.5.
ADDBA Request
Ack
(a) Setup
ADDBA Response
Ack
QoS Data frame
multiple
(b) Data & Block Ack
times Block A ckReq
Block A ck
DELB A Request
Ack
(c) Teardown
Originator Recipient
Figure 10-32—Message sequence chart for block ack mechanism:
(a) setup, (b) data and acknowledgment transfer, and (c) teardown
All operations on sequence numbers are performed modulo 212. Comparisons between sequence numbers are
circular modulo 212, i.e., the sequence number space is considered divided into two parts, one of which is “old”
and one of which is “new,” by means of a boundary created by adding half the sequence number range to the
current start of receive window (modulo 212).
10.24.2 Setup and modification of the block ack parameters
An originator that intends to use the block ack mechanism for the transmission of QoS Data frames to an
intended recipient should first check whether the intended recipient STA is capable of participating in block
ack mechanism by discovering and examining its Delayed Block Ack and Immediate Block Ack capability
bits. If the intended recipient STA is capable of participating, the originator sends an ADDBA Request frame
indicating the TID for which the block ack agreement is being set up. When a block ack agreement is set up
between HT STAs, the Buffer Size and Block Ack Timeout fields in the ADDBA Request frame are advisory.
When a block ack agreement is set up between HT or DMG STAs, the Buffer Size and Block Ack Timeout
1416
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
fields in the ADDBA Request frame are advisory. When a block ack agreement is set up between a non-HT
non-DMG STA and another STA, the Block Ack Policy and Buffer Size fields in the ADDBA Request frame
are advisory.
The recipient STA shall respond by an ADDBA Response frame. The recipient STA has the option of
accepting or rejecting the request. When the recipient STA accepts, then a block ack agreement exists between
the originator and recipient.
When the recipient STA accepts, it indicates the type of block ack and the number of buffers that it shall
allocate for the support of this block ack agreement within the ADDBA Response frame and the block ack
timeout that is used. Each block ack agreement that is established by a STA may have a different buffer
allocation. If the intended recipient STA rejects the request, then the originator shall not use the block ack
mechanism.
When the Block Ack Policy subfield value is set to 1 by the originator of an ADDBA Request frame between
HT STAs, then the ADDBA Response frame accepting the ADDBA Request frame shall contain 1 in the
Block Ack Policy subfield.
For each accepted block ack agreement, the originator shall set the sequence number of the first frame
transmitted under the agreement to the value of the Block Ack Starting Sequence Control field of the ADDBA
Request frame of the accepted block ack agreement.
When a block ack agreement is established between two HT STAs or two DMG STAs, the originator may
change the size of its transmission window if the value in the Buffer Size field of the ADDBA Response frame
is larger than the value in the ADDBA Request frame. If the value in the Buffer Size field of the ADDBA
Response frame is smaller than the value in the ADDBA Request frame, the originator shall change the size of
its transmission window (WinSizeO) so that it is not greater than the value in the Buffer Size field of the
ADDBA Response frame and is not greater than the value 64.
The originator STA may send an ADDBA Request frame in order to update block ack timeout value. If the
updated ADDBA Request frame is accepted, both STAs initialize the timer to detect block ack timeout. Even
if the updated ADDBA Request frame is not accepted, the original block ack setup remains active.
NOTE A block ack associated with a GCR group address does not use an inactivity timer because the GCR originator
might switch between the DMS delivery method, the GCR unsolicited retry retransmission policy, and the GCR block
ack retransmission policy during the lifetime of a GCR agreement.
The A-MSDU Supported field indicates whether an A-MSDU may be sent under the particular block ack
agreement. The originator sets this field to 1 to indicate that it might transmit A-MSDUs with this TID. The
recipient sets this field to 1 to indicate that it is capable of receiving an A-MSDU with this TID.
NOTE—The recipient is free to respond with any setting of the A-MSDU supported field. If the value in the ADDBA
Response frame is not acceptable to the originator, it can delete the block ack agreement and transmit data using normal
acknowledgment.
If the block ack mechanism is being set up for a TS, bandwidth negotiation (using ADDTS Request and
Response frames) should precede the setup of the block ack mechanism. If the block ack mechanism is being
set up for the GCR service, then the following steps apply:
— One or more GCR Request/Response exchanges precede the setup of the block ack mechanism.
— The ADDBA Request and Response frames exchanged to set up the block ack shall include the GCR
Group Address element indicating the group address of the GCR service.
Once the block ack exchange has been set up, Data and Ack frames are transferred using the procedure
described in 10.24.3.
1417
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.24.3 Data and acknowledgment transfer using immediate block ack policy and delayed
block ack policy
After setting up either an immediate block ack agreement or a delayed block ack agreement following the
procedure in 10.24.2, and having gained access to the medium and established protection, if necessary, the
originator may transmit a block of QoS Data frames separated by SIFS, with the total number of frames not
exceeding the Buffer Size subfield value in the associated ADDBA Response frame and subject to any
additional duration limitations based on the channel access mechanism. Each of the frames shall have the Ack
Policy subfield in the QoS Control field set to Block Ack. The RA field of the frames that are not delivered
using the GCR block ack retransmission policy shall be the recipient’s individual address. The RA field of
GCR frames delivered using the GCR block ack retransmission policy shall be set to the GCR concealment
address. The originator requests acknowledgment of outstanding QoS Data frames by sending a Basic
BlockAckReq frame. The recipient shall maintain a block ack record for the block.
Subject to any constraints in this subclause about permitted use of TXOP or SP according to the channel access
mechanism used, the originator may
— Separate the block of QoS data frames and the Basic BlockAckReq frames into separate TXOPs or
SPs
— Split transmission of Data frames sent under block ack policy across multiple TXOPs or SPs
— Interleave MPDUs with different TIDs within the same TXOP or SP
— Sequence or interleave MPDUs for different RAs within a TXOP or SP
A protective mechanism (such as transmitting using HCCA, RTS/CTS, RTS/DMG CTS, SP, protected period,
or the mechanism described in 10.26) should be used to reduce the probability of other STAs transmitting
during the TXOP or SP. If no protective mechanism is used, then the first frame that is sent as a block shall
have a response frame and shall have the Duration field set so that the NAVs are set to appropriate values at all
STAs in the BSS.
The originator shall use the block ack starting sequence control to signal the first MPDU in the block for which
an acknowledgment is expected. MPDUs in the recipient’s buffer with a sequence control value that precedes
the starting sequence control value are called preceding MPDUs. The recipient shall reassemble any complete
MSDUs from buffered preceding MPDUs and indicate these to its higher layer. The recipient shall then release
any buffers held by preceding MPDUs. The range of the outstanding MPDUs (i.e., the reorder buffer) shall
begin on an MSDU boundary. The total number of frames that can be sent depends on the total number of
MPDUs in all of the outstanding MSDUs. The total number of MPDUs in these MSDUs shall not exceed the
reorder buffer size in the receiver.
The recipient of an accepted block ack agreement that did not contain a GCR Group Address element in the
ADDBA Request frame shall maintain a block ack record consisting of originator address, TID, and a record of
reordering buffer size indexed by the received MPDU sequence control value. This record holds the
acknowledgment state of the Data frames received from the originator. The recipient of an accepted block ack
agreement that contained a GCR Group Address element in the ADDBA Request frame shall maintain a block
ack record consisting of the DA address from the A-MSDU subframe header, TID, and a record of reordering
buffer size indexed by the received MPDU sequence control value. This record holds the acknowledgment
state of the group addressed Data frames received from the originator.
If the immediate block ack policy is used, the recipient shall respond to a Basic BlockAckReq frame with a
Basic BlockAck frame. If the recipient sends the Basic BlockAck frame, the originator updates its own record
and retries any frames that are not acknowledged in the Basic BlockAck frame, either in another block or
individually.
If the delayed block ack policy is used, the recipient shall respond to a Basic BlockAckReq frame with an Ack
frame. The recipient shall then send its Basic BlockAck frame response in a subsequently obtained TXOP.
1418
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Once the contents of the Basic BlockAck frame have been prepared, the recipient shall send this frame in the
earliest possible TXOP using the highest priority AC. The originator shall respond with an Ack frame upon
receipt of the Basic BlockAck frame. If delayed block ack policy is used and if the HC is the recipient, then the
HC may respond with a +CF-Ack frame if the Basic BlockAckReq frame is the final frame of the polled
TXOP’s frame exchange. If delayed block ack policy is used and if the HC is the originator, then the HC may
respond with a +CF-Ack frame if the Basic BlockAck frame is the final frame of the TXOP’s frame exchange.
The Basic BlockAck frame contains acknowledgments for the MPDUs of up to 64 previous MSDUs. In the
Basic BlockAck frame, the STA acknowledges only the MPDUs starting from the starting sequence control
value until the MPDU with the highest sequence number that has been received, and the STA shall set bits in
the Block Ack Bitmap subfield corresponding to all other MPDUs to 0. The status of MPDUs that are
considered “old” and prior to the sequence number range for which the receiver maintains status shall be
reported as successfully received (i.e., the corresponding bit in the bitmap shall be set to 1). If the Basic
BlockAck frame indicates that an MPDU was not received correctly, the originator shall retry that MPDU
subject to that MPDU’s appropriate lifetime limit.
A typical block ack sequence using immediate block ack for a single TID is shown in Figure 10-33.
Originator Data Block Block Ack
Exchange
Frame-exchange q
a
t a
t a
t a
t e
a a a a c R
for NAV Protection is k
c
D D D D
S S S S a A
k
o o o o B c
Q Q Q Q lo
B
Recipient
k
c
A
k
c
o
l
B
Ack Policy = Block Ack ic
s
a
B
NAV at
other STAs
Figure 10-33—Typical block ack sequence when immediate policy is used
A typical block ack sequence using the delayed block ack is shown in Figure 10-34.
The subsequent Basic BlockAckReq frame’s starting sequence number shall be higher than or equal to the
starting sequence number of the immediately preceding Basic BlockAckReq frame for the same TID.
The originator may continue to transmit MPDUs (subject to the negotiated buffer size constraint) to the
recipient after transmitting the Basic BlockAckReq frame, but before receiving the Basic BlockAck frame
(applicable only to delayed block ack). The bitmap in the Basic BlockAck frame shall include the status of
frames received between the start sequence number and the transmission of the Basic BlockAckReq frame. A
recipient sending a delayed Basic BlockAck frame may update the bitmap with information on QoS Data
frames received between the receipt of the Basic BlockAckReq frame and the transmission of the Basic
BlockAck frame.
1419
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Originator Data Block Block Ack
Exchange
BlockAckReq
Frame -exchange
QoS Data
QoS Data
QoS Data
QoS Data
Basic
for NAV Protection
Ack
NAV due to
Recipient recipient
Basic BlockAck
Ack
Ack Policy = Block Ack
NAV at
other STAs
Figure 10-34—Typical block ack sequence when delayed policy is used
If there is no response (i.e., neither a Basic BlockAck frame nor an Ack frame) to the Basic BlockAckReq
frame, the originator may retransmit the Basic BlockAckReq frame within the current TXOP or SP (if time
permits) or within a subsequent TXOP or SP. MSDUs that are sent using the block ack mechanism are not
subject to retry limits but only to MSDU lifetime. A non-DMG originator does not need to set the Retry
subfield to 1 for any possible retransmissions of the MPDUs. A DMG originator shall set the Retry subfield to
1 for any possible retransmissions of the MPDUs.
The Basic BlockAckReq frame shall be discarded if all MSDUs referenced by this frame have been discarded
from the transmit buffer due to the expiration of their lifetime limit.
Under a block ack agreement, the Normal Ack policy may be used in order to improve efficiency. A STA
shall respond with an Ack frame to the reception of frames that are covered by a block ack agreement, but
that are not part of an A-MPDU and that are received with their Ack Policy subfield in the QoS Control field
equal to Normal Ack.
The block ack record shall be updated irrespective of the acknowledgment type (Normal or Block Ack) for
the TID/TSID with a block ack agreement.
The reception of QoS Data frames using Normal Ack policy shall not be used by the recipient as an
indication to reset the timer employed in detecting a block ack timeout (see 11.5). The block ack timeout
allows the recipient to delete the block ack if the originator does not switch back to using block ack.
The frame exchange sequences are provided in Annex G.
10.24.4 Receive buffer operation
For each block ack agreement, the recipient maintains a MAC variable NextExpectedSequenceNumber. The
NextExpectedSequenceNumber is initialized to the value of the Block Ack Starting Sequence Control field of
the ADDBA Request frame of the accepted block ack agreement.
Upon the receipt of a QoS Data frame from the originator for which a block ack agreement exists, the recipient
buffers the MSDU regardless of the value of the Ack Policy subfield within the QoS Control field of the QoS
1420
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Data frame, unless the sequence number of the frame is older than the NextExpectedSequenceNumber for that
block ack agreement, in which case the frame is discarded because it is either old or a duplicate.
The recipient flushes received MSDUs from its receive buffer as described in this subclause.
If a BlockAckReq frame is received, all complete MSDUs and A-MSDUs with lower sequence numbers than
the starting sequence number contained in the BlockAckReq frame shall be passed up to the next MAC process
as shown in Figure 5-1. Upon arrival of a BlockAckReq frame, the recipient shall pass up the MSDUs and
A-MSDUs starting with the starting sequence number sequentially until there is an incomplete or missing
MSDU or A-MSDU in the buffer. If no MSDUs or A-MSDUs are passed up to the next MAC process after the
receipt of the BlockAckReq frame and the starting sequence number of the BlockAckReq frame is newer than
the NextExpectedSequenceNumber for that block ack agreement, then the NextExpectedSequenceNumber for
that block ack agreement is set to the sequence number of the BlockAckReq frame.
If, after an MPDU is received, the receive buffer is full, the complete MSDU or A-MSDU with the earliest
sequence number shall be passed up to the next MAC process.
If, after an MPDU is received, the receive buffer is not full, but the sequence number of the complete MSDU or
A-MSDU in the buffer with the lowest sequence number is equal to the NextExpectedSequenceNumber for
that block ack agreement, then the MPDU shall be passed up to the next MAC process.
Each time that the recipient passes an MSDU or A-MSDU for a block ack agreement up to the next MAC
process, the NextExpectedSequenceNumber for that block ack agreement is set to the sequence number of the
MSDU or A-MSDU that was passed up to the next MAC process plus one.
The recipient shall pass MSDUs and A-MSDUs up to the next MAC process in order of increasing sequence
number.
10.24.5 Teardown of the block ack mechanism
When the originator has no data to send and the final block ack exchange has completed, it shall signal the end
of its use of the block ack mechanism by sending the DELBA frame to its recipient. The recipient does not
generate a Management frame in response to the DELBA frame.41 The recipient of the DELBA frame shall
release all resources allocated for the block ack transfer.
The block ack agreement may be torn down if there are no BlockAck, BlockAckReq, or QoS Data frames (sent
under block ack policy) for the block ack’s TID received from the peer within a duration of block ack timeout
value (see 11.5.4).
The DELBA frame transmitted to release the block ack setup of a GCR service shall include the GCR Group
Address element to indicate the group address of the GCR service.
10.24.6 Selection of BlockAck and BlockAckReq variants
The Compressed Bitmap subfield of the BA Control field or BAR Control field shall be set to 1 in all
BlockAck and BlockAckReq frames sent from one HT STA to another HT STA and shall be set to 0 otherwise.
The Multi-TID subfield of the BA Control field shall be set to 1 in all BlockAck frames related to an HT-
immediate agreement transmitted inside a PSMP sequence and shall be set to 0 otherwise. The Multi-TID
subfield of the BAR Control field shall be set to 1 in all BlockAckReq frames related to an HT-immediate
agreement transmitted inside a PSMP sequence and shall be set to 0 otherwise.
41
Normal Ack rules apply.
1421
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In a DMG BSS, if the Compressed Bitmap subfield of the BAR Control field within a BlockAckReq frame
related to an HT-immediate agreement is equal to 1, then all of the following BlockAck and BlockAckReq
frames transmitted as part of the HT-immediate agreement shall have the Compressed Bitmap subfield of
the BA Control and BAR Control fields set to 1. In this case, the Multi-TID subfield of the BA Control field
and BAR Control field shall be set to 0 in all BlockAck and BlockAckReq frames transmitted as part of the
HT-immediate agreement.
In a DMG BSS, if the Compressed Bitmap subfield of the BAR Control field within a BlockAckReq frame
related to an HT-immediate agreement is equal to 0, then all of the following BlockAck and BlockAckReq
frames transmitted as part of the HT-immediate agreement shall have the Compressed Bitmap subfield of
the BA Control and BAR Control fields set to 0. In this case, the Multi-TID subfield of the BA Control field
and BAR Control field shall be set to 1 in all BlockAck and BlockAckReq frames transmitted as part of the
HT-immediate agreement.
Where the terms BlockAck and BlockAckReq are used within 10.24.7 and 10.24.8, the appropriate variant
according to this subclause (e.g., Compressed, Multi-TID) is referenced by the generic term.
The GCR subfield of the BAR Control field shall be set to 1 in all BlockAckReq frames where the block ack
agreement is for a group address delivered using the GCR block ack retransmission policy and shall be set to 0
otherwise. The GCR subfield of the BA Control field shall be set to 1 in all BlockAck frames where the block
ack agreement is for a group address delivered using the GCR block ack retransmission policy and shall be set
to 0 otherwise.
10.24.7 HT-immediate block ack extensions
10.24.7.1 Introduction to HT-immediate block ack extensions
An HT extension to the block ack feature (defined in 10.24.1 through 10.24.5), called HT-immediate block ack,
is defined in 10.24.7.2 through 10.24.7.9.
The HT-immediate extensions simplify immediate block ack use with A-MPDUs and reduce recipient resource
requirements.
An HT STA shall support HT-immediate block ack in the role of recipient.
A DMG STA shall support HT-immediate block ack.
10.24.7.2 HT-immediate block ack architecture
The HT-immediate block ack rules are explained in terms of the architecture shown in Figure 10-35 and
explained in this subclause.
The originator contains a transmit buffer control that uses WinStartO and WinSizeO to submit MPDUs for
transmission and releases transmit buffers upon receiving BlockAck frames from the recipient.
WinStartO is the starting sequence number of the transmit window, and WinSizeO is the number of buffers
negotiated in the block ack agreement.
The Aggregation control creates A-MPDUs. It may adjust the Ack Policy field of transmitted QoS Data frames
according to the rules defined in 10.24.7.7 in order to solicit BlockAck frame responses.
1422
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Originator Recipient
Receive Reordering
Buffer Control per TA/TID
Transmit Buffer Control
(WinStartB, WinSizeB)
per RA/TID
(WinStartO, WinSizeO) Scoreboard Context
Control
(WinStartR, WinSizeR)
Aggregation control Deaggregation control
A-MPDU
BlockAck (BitMap, SSN)
Figure 10-35—HT-immediate block ack architecture
The recipient contains a receive reordering buffer control per TA/TID, which contains a related control state.
The receive reordering buffer is responsible for reordering MSDUs or A-MSDUs so that MSDUs or
A-MSDUs are eventually passed up to the next MAC process in order of received sequence number. It is also
responsible for identifying and discarding duplicate frames (i.e., frames that have the same sequence number as
a currently buffered frame) that are part of this block ack agreement. It maintains its own state independent of
the scoreboard context control to perform this reordering as specified in 10.24.7.6.
For each HT-immediate block ack agreement, the recipient chooses either full-state or partial-state operation
(this choice is known only to the recipient). A STA may simultaneously use full-state operation for some
agreements and partial-state operation for other agreements. The scoreboard context control stores an
acknowledgment bitmap containing the current reception status of MSDUs or A-MSDUs for HT-immediate
block ack agreements. Under full-state operation, status is maintained in statically assigned memory. Under
partial-state operation, status is maintained in a cache memory; therefore, the status information is subject to
cache replacement. This entity provides the bitmap and the value for the Starting Sequence Number subfield to
be sent in BlockAck frame responses to the originator.
The deaggregation control entity separates frames contained in an A-MPDU.
Each received MPDU is analyzed by the scoreboard context control as well as by the receive reordering buffer
control.
Each HT-immediate block ack agreement is uniquely identified by a tuple of Address 1, Address 2, and TID
from the ADDBA Response frame that successfully established the HT-immediate block ack agreement. The
STA that corresponds to Address 1 of the ADDBA Response frame is the originator. The STA that corresponds
to Address 2 of the ADDBA Response frame is the recipient. Data frames that contain the same values for
Address 1, Address 2, and TID as a successful ADDBA Response frame are related with the HT-immediate
block ack agreement that was established by the receipt of that ADDBA Response frame provided that the HT-
immediate block ack agreement is still active.
10.24.7.3 Scoreboard context control during full-state operation
For each HT-immediate block ack agreement that uses full-state operation, a recipient shall maintain a block
acknowledgment record as defined in 10.24.3. This record includes a bitmap, indexed by sequence number; a
12-bit unsigned integer starting sequence number, WinStartR, representing the lowest sequence number
position in the bitmap; a variable WinEndR; and the maximum transmission window size, WinSizeR, which is
set to the smaller of 64 and the value of the Buffer Size field of the associated ADDBA Response frame that
established the block ack agreement. WinEndR is defined as the highest sequence number in the current
transmission window. A STA implementing full-state operation for an HT-immediate block ack agreement
shall maintain the block acknowledgment record for that agreement according to the following rules:
1423
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) At HT-immediate block ack agreement establishment:
1) WinStartR = SSN from the ADDBA Request frame that elicited the ADDBA Response frame
that established the HT-immediate block ack agreement.
2) WinEndR = WinStartR + WinSizeR – 1.
b) For each received Data frame that is related with a specific full-state operation HT-immediate block
ack agreement, the block acknowledgment record for that agreement is modified as follows, where
SN is the value of the Sequence Number subfield of the received Data frame:
1) If WinStart R SN WinEnd R , set to 1 the bit in position SN within the bitmap.
11
2) If WinEnd R SN WinStart R +2 ,
i) Set to 0 the bits corresponding to MPDUs with Sequence Number subfield values from
WinEndR+1 to SN – 1.
ii) Set WinStartR = SN – WinSizeR + 1.
iii) Set WinEndR = SN.
iv) Set to 1 the bit at position SN in the bitmap.
11
3) If WinStart R +2 SN WinStart R , make no changes to the record.
NOTE—A later-arriving Data frame might validly contain a sequence number that is lower than an
earlier-arriving one. This might happen because the transmitter may choose to send Data frames in a
nonsequential sequence number order or because a previous Data frame transmission with lower sequence
number is not successful and is being retransmitted.
c) For each received BlockAckReq frame that is related with a specific full-state operation HT-
immediate block ack agreement that is not a protected block ack agreement, the block
acknowledgment record for that agreement is modified as follows, where SSN is the value from the
Starting Sequence Number subfield of the received BlockAckReq frame:
1) If WinStart R SSN WinEnd R ,
i) Set WinStartR = SSN.
ii) Set to 0 the bits corresponding to MPDUs with Sequence Number subfield values from
WinEndR + 1 through WinStartR + WinSizeR – 1.
iii) Set WinEndR = WinStartR + WinSizeR – 1.
11
2) If WinEnd R SSN WinStart R +2 ,
i) Set WinStartR = SSN.
ii) Set WinEndR = WinStartR + WinSizeR – 1.
iii) Set to 0 bits the corresponding to MPDU with Sequence Number subfield values from
WinStartR to WinEndR.
11
3) If WinStart R +2 SSN WinStart R , make no changes to the record.
10.24.7.4 Scoreboard context control during partial-state operation
In an HT-immediate block ack agreement that uses partial-state operation, a recipient shall maintain a
temporary block acknowledgment record, as defined in 10.24.3. This temporary record includes a bitmap,
indexed by sequence number; a 12-bit unsigned integer WinStartR (the lowest sequence number represented in
the bitmap); a 12-bit unsigned integer WinEndR (the highest sequence number in the bitmap); the originator
address; TID; and the maximum transmission window size, WinSizeR, which is set to the smaller of 64 and the
value of the Buffer Size field of the associated ADDBA Response frame that established the block ack
agreement.
1424
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
During partial-state operation of scoreboard context control, the recipient retains the current record for an HT-
immediate block ack agreement at least as long as it receives data from the same originator. If a frame for an
HT-immediate block ack agreement from a different originator is received, the temporary record may be
discarded if the resources it uses are needed to store the temporary record corresponding to the newly arriving
frame.
A STA implementing partial-state operation for an HT-immediate block ack agreement shall maintain the
temporary block acknowledgment record for that agreement according to the following rules:
a) During partial-state operation, WinStartR is determined by the Sequence Number subfield value of
received Data frames and by the Starting Sequence Number subfield value of received
BlockAckReq frames as described below.
b) For each received Data frame that is related with a specific partial-state operation HT-immediate
block ack agreement, when no temporary record for the agreement related with the received Data
frame exists at the time of receipt of the Data frame, a temporary block acknowledgment record is
created as follows, where SN is the value of the Sequence Number subfield of the received Data
frame:
1) WinEndR = SN.
2) WinStartR = WinEndR - WinSizeR + 1.
3) Create a bitmap of size WinSizeR, with the first bit corresponding to sequence number
WinStartR and the last bit corresponding to sequence number WinEndR, and set all bits in the
bitmap to 0.
4) Set to 1 the bit in the position in the bitmap that corresponds to SN.
c) For each received Data frame that is related with a specific partial-state operation HT-immediate
block ack agreement, when a temporary record for the agreement related with the received Data
frame exists at the time of receipt of the Data frame, the temporary block acknowledgment record
for that agreement is modified in the same manner as the acknowledgment record for a full-state
agreement described in 10.24.7.3.
d) For each received BlockAckReq frame that is related with a specific partial-state operation HT-
immediate block ack agreement that is not a protected block ack agreement, when no temporary
record for the agreement related with the received frame exists at the time of receipt of the frame, a
temporary block acknowledgment record is created as follows, where SSN is the starting value of the
Sequence Number subfield of the received BlockAckReq frame:
1) WinStartR = SSN.
2) WinEndR = WinStartR + WinSizeR – 1.
3) Create a bitmap of size WinSizeR, and set all bits in the bitmap to 0.
e) For each received BlockAckReq frame that is related with a specific partial-state operation HT-
immediate block ack agreement that is not a protected block ack agreement, when a temporary
record for the agreement related with the received frame exists at the time of receipt of the frame, the
temporary block acknowledgment record for that agreement is modified in the same manner as the
acknowledgment record for a full-state agreement described in 10.24.7.3.
10.24.7.5 Generation and transmission of BlockAck frames by an HT STA or DMG STA
Except when operating within a PSMP exchange, a STA that receives a PPDU that contains a BlockAckReq
frame in which the Address 1 field matches its MAC address during either full-state operation or partial-state
operation shall transmit a PPDU containing a BlockAck frame that is separated on the WM by a SIFS from the
PPDU that elicited the BlockAck frame as a response. A STA that receives an A-MPDU that contains one or
more MPDUs in which the Address 1 field matches its MAC address with the Ack Policy field equal to
Normal Ack (i.e., implicit block ack request) during either full-state operation or partial-state operation shall
transmit a PPDU containing a BlockAck frame that is separated on the WM by a SIFS from the PPDU that
elicited the BlockAck frame as a response.
1425
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU
with Ack Policy equal to Normal Ack (i.e., implicit block ack request) during either full-state operation or
partial-state operation, any adjustment to the value of WinStartR according to the procedures defined within
10.24.7.3 and 10.24.7.4 shall be performed before the generation and transmission of the response BlockAck
frame. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield of the
BlockAck frame shall be set to any value in the range (WinEndR – 63) to WinStartR. The values in the
recipient’s record of status of MPDUs beginning with the MPDU for which the Sequence Number subfield
value is equal to WinStartR and ending with the MPDU for which the Sequence Number subfield value is equal
to WinEndR shall be included in the bitmap of the BlockAck frame.
When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU
with Ack Policy equal to Normal Ack (i.e., implicit block ack request) during either full-state or partial-state
operation, if the adjusted value of WinStartR is greater than the value of the starting sequence number of the
BlockAck frame, within the bitmap of the BlockAck frame, the status of MPDUs with sequence numbers that
are less than the adjusted value of WinStartR may be set to any value.
When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU
with Ack Policy equal to Normal Ack (i.e., implicit block ack request) during either full-state or partial-state
operation, if the adjusted value of WinEndR is less than the value of the starting sequence number of the
BlockAck frame plus 63, within the bitmap of the BlockAck frame, the status of MPDUs with sequence
numbers that are greater than the adjusted value of WinEndR shall be reported as unsuccessfully received (i.e.,
the corresponding bit in the bitmap shall be set to 0).
If a BlockAckReq frame is received and no matching partial state is available, the recipient shall send a null
BlockAck frame in which the bitmap is set to all 0s.
10.24.7.6 Receive reordering buffer control operation
10.24.7.6.1 General
The behavior described in this subclause, 10.24.7.6.2, and 10.24.7.6.3 applies to a STA that uses either partial-
state operation or full-state operation for an HT-immediate block ack agreement.
A receive reordering buffer shall be maintained for each HT-immediate block ack agreement. Each receive
reordering buffer includes a record comprising the following:
— Buffered MSDUs or A-MSDUs that have been received, but not yet passed up to the next MAC
process
— A WinStartB parameter, indicating the value of the Sequence Number subfield of the first (in order
of ascending sequence number) MSDU or A-MSDU that has not yet been received
— A WinEndB parameter, indicating the highest sequence number expected to be received in the
current reception window
— A WinSizeB parameter, indicating the size of the reception window
WinStartB is initialized to the Starting Sequence Number subfield value of the ADDBA Request frame that
elicited the ADDBA Response frame that established the HT-immediate block ack agreement.
WinEndB is initialized to WinStartB + WinSizeB – 1, where WinSizeB is set to the smaller of 64 and the value of
the Buffer Size field of the ADDBA Response frame that established the block ack agreement.
Any MSDU or A-MSDU that has been passed up to the next MAC process shall be deleted from the receive
reordering buffer.
1426
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The recipient shall always pass MSDUs or A-MSDUs up to the next MAC process in order of increasing
Sequence Number subfield value.
10.24.7.6.2 Operation for each received Data frame
For each received Data frame that is related to a specific HT-immediate block ack agreement, the receive
reordering buffer record shall be modified as follows, where SN is the value of the Sequence Number subfield
of the received MPDU:
a) If WinStart B SN WinEnd B ,
1) Store the received MPDU in the buffer, if no MSDU with the same sequence number is already
present; otherwise discard the MPDU.
2) Pass MSDUs or A-MSDUs up to the next MAC process if they are stored in the buffer in order
of increasing value of the Sequence Number subfield starting with the MSDU or A-MSDU that
has SN=WinStartB or if SN>WinStartB, the STA is a DMG STA, and one of the following
conditions is met:
i) The MPDU is received as non-first frame in the A-MPDU; the bit at position SN=Win-
StartR – 1 is set to 1; and all delimiters between the received MPDU and the preceding
MPDU (SN=WinStartR – 1) are valid.
ii) The MPDU is received as first frame in the A-MPDU; the A-MPDU is received in SIFS or
RIFS after an A-MPDU or in SIFS after transmission of a BlockAck frame; the bit at posi-
tion SN=WinStartR – 1 is set to 1; and all delimiters after the MPDU(SN=WinStartR – 1)
in the preceding A-MPDU are valid.
iii) The MPDU is received in SIFS or RIFS after an A-MPDU or in SIFS after transmission of
a BlockAck frame; the bit at position SN=WinStartR – 1 is set to 1; and all delimiters after
the MPDU (SN=WinStartR – 1) in the preceding A-MPDU are valid.
iv) The MPDU is received as first frame in the A-MPDU; the A-MPDU is received in SIFS or
RIFS after an MPDU or in SIFS after transmission of an Ack frame; and the bit at position
SN=WinStartR – 1 is set to 1.
v) The MPDU is received in SIFS or RIFS after the preceding MPDU or in SIFS after trans-
mission of an Ack frame; and the bit at position SN=WinStartR – 1 is set to 1.
This process is continued sequentially until there is no buffered MSDU or A-MSDU for the
next sequential value of the Sequence Number subfield.
3) Set WinStartB to the value of the Sequence Number subfield of the last MSDU or A-MSDU
that was passed up to the next MAC process plus one.
4) Set WinEndB = WinStartB + WinSizeB – 1.
11
b) If WinEnd B SN WinStart B +2 ,
1) Store the received MPDU in the buffer, if no MSDU with the same sequence number is already
present; otherwise discard the MPDU.
2) Set WinEndB = SN.
3) Set WinStartB = WinEndB – WinSizeB + 1.
4) Pass any complete MSDUs or A-MSDUs stored in the buffer with Sequence Number subfield
values that are lower than the new value of WinStartB up to the next MAC process in order of
increasing Sequence Number subfield value. Gaps may exist in the Sequence Number subfield
values of the MSDUs or A-MSDUs that are passed up to the next MAC process.
5) In a non-DMG STA, pass MSDUs or A-MSDUs stored in the buffer up to the next MAC
process in order of increasing value of the Sequence Number subfield starting with WinStartB
and proceeding sequentially until there is no buffered MSDU or A-MSDU for the next
sequential Sequence Number subfield value. For a DMG STA, follow rules defined in item a)
2) above.
1427
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6) Set WinStartB to the Sequence Number subfield value of the last MSDU or A-MSDU that was
passed up to the next MAC process plus one.
7) Set WinEndB = WinStartB + WinSizeB – 1.
11
c) If WinStart B +2 SN WinStart B , discard the MPDU (do not store the MPDU in the buffer, and
do not pass the MSDU or A-MSDU up to the next MAC process).
10.24.7.6.3 Operation for each received BlockAckReq
For each received BlockAckReq frame that is related with a specific HT-immediate block ack agreement, the
receive reordering buffer record is modified as follows, where SSN is the Starting Sequence Number subfield
value of the received BlockAckReq frame:
11
a) If WinStart B SSN WinStart B +2 ,
1) In a block ack agreement that is not a protected block ack agreement, set WinStartB = SSN. See
10.24.9 for a protected block ack agreement.
2) Set WinEndB = WinStartB + WinSizeB – 1.
3) Pass any complete MSDUs or A-MSDUs stored in the buffer with Sequence Number subfield
values that are lower than the new value of WinStartB up to the next MAC process in order of
increasing Sequence Number subfield value. Gaps may exist in the Sequence Number subfield
values of the MSDUs or A-MSDUs that are passed up to the next MAC process.
4) Pass MSDUs or A-MSDUs stored in the buffer up to the next MAC process in order of
increasing Sequence Number subfield value starting with SN=WinStartB and proceeding
sequentially until there is no buffered MSDU or A-MSDU for the next sequential Sequence
Number subfield value.
5) Set WinStartB to the Sequence Number subfield value of the last MSDU or A-MSDU that was
passed up to the next MAC process plus one.
6) Set WinEndB = WinStartB + WinSizeB – 1.
11
b) If WinStart B +2 SSN WinStart B , do not make any changes to the receive reordering buffer
record.
10.24.7.7 Originator’s behavior
A STA may send a block of data in a single A-MPDU where each Data frame has its Ack Policy field set to
Normal Ack. The originator expects to receive a BlockAck frame response immediately following the
A-MPDU if at least one Data frame is received without error.
Alternatively, the originator may send an A-MPDU where each Data frame has its Ack Policy field set to
Block Ack under an HT-immediate block ack agreement if it does not require a BlockAck frame response
immediately following the A-MPDU.
If the BlockAck frame is lost, the originator may transmit a BlockAckReq frame to solicit an immediate
BlockAck frame or it may retransmit the Data frames.
A BlockAckReq frame sent using HT-delayed operation may be transmitted within an A-MPDU provided that
its BAR Ack Policy subfield is set to No Acknowledgment.
The originator may transmit QoS Data frames with a TID matching an established block ack agreement in any
order provided that their sequence numbers lie within the current transmission window. The originator may
transmit an MPDU with a sequence number that is beyond the current transmission window (SN > WinStartO +
WinSizeO – 1), in which case the originator’s transmission window (and the recipient’s window) is moved
forward. The originator should not transmit MPDUs that are lower than (i.e., SN < WinStartO) the current
transmission window.
1428
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The originator shall not retransmit an MPDU after that MPDU’s appropriate lifetime limit.
The originator may send a BlockAckReq frame for block ack agreement that is not a protected block ack
agreement or a robust ADDBA Request frame for protected block ack agreement when a Data frame that was
previously transmitted within an A-MPDU that had the Ack Policy field equal to Normal Ack is discarded due
to exhausted MSDU lifetime. The purpose of this BlockAckReq or robust ADDBA Request frame is to shift
the recipient’s WinStartB value past the hole in the sequence number space that is created by the discarded Data
frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process.
An originator that is a DMG STA shall transmit MPDUs sent under a BA agreement such that:
— MPDUs that need to be retransmitted are transmitted first, in sequential order of sequence number,
starting from the oldest MPDU that needs to be retransmitted
— MPDUs that are being transmitted for the first time are sent after any MPDUs that need to be
retransmitted, in sequential order of sequence number, starting from the oldest MPDU that has not
been transmitted
— MPDUs are transmitted with the Ack Policy subfield set to Block Ack if the A-MPDU that contains
them is followed after SIFS or RIFS by another A-MPDU
An originator that is a DMG STA shall not start a new TXOP or SP with an MPDU or A-MPDU that has an
Ack policy other than Normal Ack if at least one frame transmitted by the originator to the recipient in the
last PPDU did not require an immediate response.
10.24.7.8 Maintaining block ack state at the originator
If an originator successfully receives a BlockAck frame in response to a BlockAckReq frame, the originator
shall maintain block ack state as defined in 10.24.3.
If the originator receives a BlockAck frame in response to an HT-immediate BlockAckReq frame, it shall, in
addition,
— Not update the status of MPDUs with Sequence Number subfield values between WinStartO and
SSN of the received BlockAck frame, and
NOTE—It is possible for the Starting Sequence Number subfield value (SSN) of the received BlockAck frame
to be greater than WinStartO because of the failed reception of a nonzero number of MPDUs beginning with the
MPDU with Sequence Number subfield value equal to WinStartO at a recipient that is using partial-state
operation.
— Not update the status of MPDUs that have been already positively acknowledged.
NOTE—This second rule means that if an originator successfully delivered an MPDU and received the
BlockAck frame in one TXOP and then receives a BlockAck frame in a later TXOP in which the MPDU is not
indicated as successfully received (because the partial state has been reset), the originator knows not to retry the
MPDU.
10.24.7.9 Originator’s support of recipient’s partial state
A recipient may choose to employ either full-state operation or partial-state operation for each individual block
ack agreement. An originator is unaware of the recipient’s choice of full-state or partial-state operation.
NOTE—The originator might solicit a BlockAck frame as the last activity associated with that block ack agreement in
the current TXOP to reduce the probability that data are unnecessarily retransmitted due to loss of partial state.
1429
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.24.8 HT-delayed block ack extensions
10.24.8.1 Introduction
Subclauses 10.24.8.2 and 10.24.8.3 define an HT extension to the block ack feature to support operation on
delayed block ack agreements established between HT STAs. Other than the exceptions noted in 10.24.8.1
through 10.24.8.3, the operation of HT-delayed block ack is the same as is described in 10.24.7.
The HT-delayed extensions simplify the use of delayed block ack in an A-MPDU and reduce resource
requirements.
A DMG STA shall not use HT-delayed block ack.
10.24.8.2 HT-delayed block ack negotiation
HT-delayed block ack is an optional feature. An HT STA declares support for HT-delayed block ack in the HT
Capabilities element.
An HT STA shall not attempt to create a block ack agreement under HT-delayed block ack policy unless the
recipient HT STA declares support for this feature.
10.24.8.3 Operation of HT-delayed block ack
The BlockAck frame response to an HT-delayed BlockAckReq frame is transmitted after an unspecified delay
and when the recipient of the BlockAckReq frame next has the opportunity to transmit. This response may be
transmitted in a later TXOP owned by the recipient of the BlockAckReq frame or in the current or a later
TXOP owned by the sender of the BlockAckReq frame using the RD feature (see 10.28).
The BAR Ack Policy subfield of a BlockAckReq frame and the BA Ack Policy subfield of a BlockAck frame
may be set to No Acknowledgment under an HT-delayed block ack agreement.
A BlockAckReq or BlockAck frame containing a BAR Ack Policy or BA Ack Policy subfield equal to 1
indicates that no acknowledgment is expected to these Control frames. Otherwise, a response that is an Ack
frame is expected after a SIFS.
Setting of the BAR Ack Policy and BA Ack Policy subfields may be performed independently for
BlockAckReq and BlockAck frames associated with the same HT-delayed block ack agreement. All four
combinations of the values of these fields are valid.
Setting of the BAR Ack Policy and BA Ack Policy subfields is dynamic and may change from PPDU to
PPDU.
10.24.9 Protected block ack agreement
A STA indicates support for protected block ack by setting the RSN Capabilities field subfields Management
Frame Protection Capable (MFPC), Management Frame Protection Required (MFPR) and PBAC to 1. Such a
STA is a PBAC STA; otherwise, the STA is a non-PBAC STA. A block ack agreement that is successfully
negotiated between two PBAC STAs is a protected block ack agreement. A block ack agreement that is
successfully negotiated between two STAs when either or both of the STAs is not a PBAC STA is a block ack
agreement that is not a protected block ack agreement.
A PBAC STA may choose to negotiate a block ack agreement with a non-PBAC STA if
dot11RSNAPBACRequired is 0; otherwise, it shall negotiate a block ack agreement only with other PBAC
1430
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STAs. If a PBAC STA is communicating with a non-PBAC STA, it shall follow the rules for a nonprotected
block ack agreement.
A STA that has successfully negotiated a protected block ack agreement shall obey the following rule as a
block ack originator in addition to rules specified in 10.24.7.7 and 10.24.7.8:
— To change the value of WinStartB at the receiver, the STA shall use a robust ADDBA Request
frame.
A STA that has successfully negotiated a protected block ack agreement shall obey the following rules as a
block ack recipient in addition to rules specified in 10.24.7.3 to 10.24.7.6:
— The recipient STA shall respond to a BlockAckReq frame from a PBAC enabled originator with an
immediate BlockAck frame. The Block Ack Starting Sequence Control subfield value shall be
ignored for the purposes of updating the value of WinStartB. The Block Ack Starting Sequence
Control subfield value may be utilized for the purposes of updating the value of WinStartR. If the
Block Ack Starting Sequence Control subfield value is greater than WinEndB or less than WinStartB,
dot11PBACErrors shall be incremented by 1.
— Upon receipt of a valid robust ADDBA Request frame for an established protected block ack
agreement whose TID and transmitter address are the same as those of the block ack agreement, the
STA shall update its WinStartR and WinStartB values based on the starting sequence number in the
robust ADDBA Request frame according to the procedures outlined for reception of BlockAckReq
frames in 10.24.7.3, 10.24.7.4, 10.24.7.6.1, and 10.24.7.6.3, while treating the starting sequence
number as though it were the SSN of a received BlockAckReq frame. Values in other fields of the
ADDBA Request frame shall be ignored.
10.24.10 GCR block ack
10.24.10.1 Introduction
Subclause 10.24.10 extends the block ack mechanism to group addressed frames that are transmitted using
the GCR block ack retransmission policy. Other than the exceptions noted in 10.24.10.2 through 10.24.10.3,
the operation of GCR block ack is the same as is described in 10.24.7.
10.24.10.2 Scoreboard context control during GCR block ack
For each GCR block ack agreement, each recipient shall maintain a block acknowledgment record as
defined in 10.24.3. This record includes the following information:
— A bitmap, indexed by sequence number
— A 12-bit unsigned integer starting sequence number
— WinStartR, representing the lowest sequence number position in the bitmap
— A variable WinEndR
— The maximum transmission window size, WinSizeR
WinSizeR is set to the smaller of 64 and the value of the Buffer Size field of the associated ADDBA
Response frame that established the block ack agreement. WinEndR is defined as the highest sequence
number in the current transmission window. A STA implementing a GCR block ack agreement shall
maintain the block acknowledgment record for that agreement according to the following rules:
a) At GCR block ack agreement establishment:
1) WinStartR = the Starting Sequence Number subfield value (SSN) from the ADDBA Request
frame that elicited the ADDBA Response frame that established the GCR block ack agreement.
2) WinEndR = WinStartR + WinSizeR – 1.
1431
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) For each received Data frame that is related with a specific GCR block ack agreement, the block
acknowledgment record for that agreement is modified as follows, where SN is the value of the
Sequence Number subfield of the received Data frame:
1) If WinStartR ≤ SN ≤ WinEndR, set to 1 the bit in position SN within the bitmap.
2) If WinEndR < SN < WinStartR + 211,
i) Set to 0 the bits corresponding to MPDUs with Sequence Number subfield values from
WinEndR + 1 to SN – 1.
ii) Set WinStartR = SN – WinSizeR + 1.
iii) Set WinEndR = SN.
iv) Set to 1 the bit at position SN in the bitmap.
3) If WinStartR +211 ≤ SN ≤ WinStartR, make no changes to the record.
c) For each received BlockAckReq frame that is related with a specific GCR block ack agreement, the
block acknowledgment record for that agreement is modified as follows, where SSN is the value
from the Starting Sequence Number subfield of the received BlockAckReq frame:
1) If WinStartR < SSN ≤ WinEndR,
i) Set WinStartR = SSN.
ii) Set to 0 the bits corresponding to MPDUs with Sequence Number subfield values from
WinEndR + 1 through WinStartR + WinSizeR – 1.
iii) Set WinEndR = WinStartR + WinSizeR – 1.
2) If WinEndR < SSN < WinStartR + 211,
i) Set WinStartR = SSN.
ii) Set WinEndR = WinStartR + WinSizeR – 1.
iii) Set to 0 bits the corresponding to MPDU with Sequence Number subfield values from
WinStartR to WinEndR.
3) If WinStartR + 211 ≤ SSN ≤ WinStartR, make no changes to the record.
10.24.10.3 GCR block ack BlockAckReq and BlockAck frame exchanges
A protective mechanism (such as transmitting an HCCA CAP, MCCA, or RTS/CTS; setting the Duration
field in the first frame and response frames to update the NAVs of STAs in the BSS and OBSS(s); or using
another mechanism described in 10.26 and 10.3.2.8) should be used to reduce the probability of other STAs
transmitting during the GCR TXOP.
When the retransmission policy for a group address is GCR Block Ack, an originator shall not transmit more
than the GCR buffer size number of A-MSDUs with RA set to the GCR concealment address and the DA
field of the A-MSDU subframe set to the GCR group address before sending a BlockAckReq frame to one
of the STAs that has a GCR block ack agreement for this group address. The RA field of the BlockAckReq
frame shall be set to the MAC address of the destination STA. Upon reception of the BlockAck frame, an
originator may send a BlockAckReq frame to another STA that has a block ack agreement for this group
address, and this process may be repeated multiple times.
NOTE If the originator sends a BlockAckReq frame to a STA with a MAC address that matches the SA in any of the
A-MSDUs transmitted during the GCR TXOP, the Block Ack Bitmap subfield does not indicate the MSDUs sourced
from this STA. This is because the STA will have discarded all group addressed MPDUs transmitted by the AP that have
the source address equal to their MAC address (see 10.3.6).
When a recipient receives a BlockAckReq frame with the GCR Group Address subfield equal to a GCR
group address, the recipient shall transmit a BlockAck frame at a delay of SIFS after the BlockAckReq
frame. The BlockAck frame acknowledges the STA’s reception status of the block of group addressed
frames requested by the BlockAckReq frame.
1432
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 10-36 shows an example of a frame exchange when the GCR block ack retransmission policy is used.
The AP sends several A-MSDUs using the GCR block ack retransmission policy. The AP then sends a
BlockAckReq frame to group member 1 of the GCR group, waits for the BlockAck frame, and then sends a
BlockAckReq frame to group member 2. After receiving the BlockAck frame from GCR group member 2,
the AP determines whether any A-MSDUs need to be retransmitted and sends additional A-MSDUs (some
of which might be retransmissions of previous A-MSDUs) using the GCR block ack retransmission policy.
Block Block
Data Data Data
AckReq AckReq
AP
Block
Ack
GCR group member 1
Block
Ack
GCR group member 2
GCR group member 3
Figure 10-36—Example of frame exchange with GCR block ack retransmission policy
After completing the BlockAckReq and BlockAck frame exchanges, the originator determines from the
information provided in the BlockAck bitmap and from the missing BlockAck frames which, if any,
A-MSDUs need to be retransmitted.
An originator adopting the GCR block ack retransmission policy for a GCR group address chooses a lifetime
limit for the group address. The originator may vary the lifetime limit for the group address at any time and
may use different lifetime limits for different GCR group addresses. The originator transmits and retries
each A-MSDU until the appropriate lifetime limit is reached or until each one has been received by all group
members to which a BlockAckReq frame has been sent, whichever occurs first.
For GCR streams with retransmission policy equal to GCR Block Ack, an originator may regularly send a
BlockAckReq frame with the GCR Group Address subfield in the BAR Information field set to the GCR
group address and the Block Ack Starting Sequence Control subfield set to the Sequence Number field of
the earliest A-MSDU of the GCR stream that has not been acknowledged by all group members and has not
expired due to lifetime limits, in order to minimize buffering latency at receivers in the GCR group.
NOTE This is because an originator might transmit Management frames, QoS Data frames with a group address in the
Address 1 field (including different GCR streams), and non-QoS Data frames intermingled. Since these are transmitted
using a single sequence counter, missing frames or frames sent to group addresses absent from a receiving STA’s
dot11GroupAddresses table complicate receiver processing for GCR streams with a GCR block ack retransmission
policy since the cause of a hole in a receiver’s block ack bitmap is ambiguous: it is due either to an MPDU being lost
from the GCR stream or to transmissions of MPDUs not related to the GCR service using the same sequence number
counter.
If an originator accepts two or more GCR agreements with multiple STAs where the GCR agreements have the
same Ethernet classifiers, but different additional classifiers, then each STA receives multiple GCR flows from
the originator and sends them to upper layers where the MSDUs irrelevant to the STA are discarded, in the
same manner that non-GCR MSDUs irrelevant to the STA are discarded. In the Block Ack Bitmap field sent to
the originator, each STA sets bits corresponding to MPDUs received from any of the multiple GCR streams.
The originator should not retry MPDUs to the STA for the bit positions that are irrelevant to that STA.
1433
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The beginning of reception of an expected response to a BlockAckReq frame is detected by the occurrence
of a PHY-CCA.indication(BUSY, channel-list) primitive at the STA that is expecting the response where
the channel-list parameter is absent or, if present, includes “primary.”
If the beginning of such reception does not occur during the first slot time following a SIFS, then the
originator may perform error recovery by retransmitting a BlockAckReq frame PIFS after the previous
BlockAckReq frame when both of the following conditions are met:
— The carrier sense mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot
boundary (see Figure 10-26) after the expected start of a BlockAck frame, and
— The remaining duration of the GCR TXOP is longer than the total time required to retransmit the
GCR BlockAckReq frame plus one slot time.
NOTE If an originator fails to receive a BlockAck frame in response to a BlockAckReq frame and there is insufficient
time to transmit a recovery frame, the AP retransmits the BlockAckReq frame in a new TXOP.
10.24.11 DMG block ack with flow control
10.24.11.1 General
A DMG STA indicates that it is capable of supporting DMG block ack with flow control by setting the BA
with Flow Control field to 1 within the STA’s DMG Capabilities element. A DMG block ack agreement
with flow control can be established only when both originator and recipient support this capability.
10.24.11.2 DMG block ack architecture with flow control
The DMG block ack rules are explained in terms of the architecture shown in Figure 10-37 and explained in
this subclause.
Originator Recipient
Receive Reordering
Buffer Control per RA/TID
Transmit Buffer Control (WinTailB, WinHeadB, WinCapacityB,
per RA/TID WinStartB , WinEndB, BufSizeB)
(WinStartO , WinEndO, BufSizeO, Scoreboard Context
WinCapacityO, WinLimitO) Control
(WinStartR , WinSizeR)
Aggregation Control Deaggregation Control
A-MPDU
BlockAck {SSN, Bitmap, RBUFCAP}
Figure 10-37—DMG block ack architecture
The originator contains a transmit buffer control that uses WinStartO, BufSizeO, and WinLimitO to submit
MPDUs for transmission, and releases transmit buffers upon receiving BlockAck frames from the recipient
or when it advances the transmit control buffer window.
WinStartO is the starting sequence number of the transmit range, WinLimitO is the last sequence number
expected to exhaust the receiver buffer capacity, and BufSizeO is the number of buffers negotiated in the
block ack agreement.
Figure 10-38 shows the DMG block ack with flow control and its associated parameters from the originator
perspective.
1434
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Receiver Buffer seen by Originator
WinEndO WinHeadO WinTailO WinStartO
What the Transmitter maintains
WinStartO = Starting Seq . Number
BufSizeO = Receiver Buffer Size negotiated BufSizeO=WinCapacityO
WinLimitO = WinEndO
Figure 10-38—Flow control and its associated parameters as a function of
receiver buffer size
The Aggregation control creates A-MPDUs. It can adjust the Ack Policy field of transmitted Data frames
according to the rules defined in 10.24.7.7 in order to solicit block ack responses.
The recipient contains a Receive Reordering Buffer Control per TA/TID, which contains related control
state.
The receive reordering buffer is responsible for reordering MSDUs or A-MSDUs so that MSDUs or
A-MSDUs are eventually passed up to the next MAC process in order of received sequence number (SN). It
maintains its own state independent of the scoreboard context control to perform this reordering as specified
in 10.24.7.6. The delivery of in order MSDUs or A-MSDUs to the next MAC process is implementation
dependent. In some cases, the receiver reordering buffer might be forced to hold on to MSDUs ready for in
order delivery due to deferred reception at the next MAC process. This behavior can impose additional
buffering requirements on the receiver, causing the actual available buffer capacity to vary dynamically. The
reordering buffer is required to manage its lowest and highest (in order) SN, which are marked as WinTailB
and WinHeadB, respectively.
The scoreboard context control provides the WinCapacityB, actually controlled by the Reordering buffer in
addition to the bitmap field and the Starting Sequence Number (SSN) field to be sent in BlockAck frame
responses to the originator.
10.24.11.3 Scoreboard context control with flow control
The scoreboard context control with flow control is defined in 10.24.7.3 and 10.24.7.4.
10.24.11.4 Receive Reordering Buffer with flow control operation
10.24.11.4.1 General
A recipient shall maintain a receive reordering buffer for each DMG block ack agreement. Each receive
reordering buffer includes a record comprising the following:
— Buffered MSDUs or A-MSDUs that have been received, but not yet passed up to the next MAC
process
— A WinStartB parameter, indicating the value of the Sequence Number field (SN) of the first (in order
of ascending sequence number) MSDU or A-MSDU that has not yet been received
— A WinEndB parameter, indicating the highest SN expected to be received in the current reception
range
— A BufSizeB parameter, indicating the size of the reception window
1435
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— A WinTailB parameter, indicating the value of the Sequence Number field (SN) of the first (in order
of ascending sequence number) MSDU or A-MSDU that has not yet been delivered to the next
MAC process
— A WinHeadB parameter, indicating the highest SN received in the current reception range
WinStartB is initialized to the Starting Sequence Number field value (SSN) of the ADDBA Request frame
that elicited the ADDBA Response frame that established the DMG block ack agreement.
WinEndB is initialized to WinStartB + BufSizeB – 1, where BufSizeB is set to the value of the Buffer Size
field of the ADDBA Response frame that established the block ack agreement.
Both WinTailB and WinHeadB are initialized to the preceding Starting Sequence Number field value (SSN –
1), to indicate no MPDU was received, within the current reception window.
Any MSDU or A-MSDU that has been passed up to the next MAC process shall be deleted from the receive
reordering buffer, advancing the WinTailB.
The recipient shall pass MSDUs or A-MSDUs up to the next MAC process in order of increasing Sequence
Number field value.
10.24.11.4.2 Operation for DMG block ack agreement initialization
At DMG block ack agreement establishment:
a) WinStartB = SSN from the ADDBA Request frame that elicited the ADDBA Response frame that
established the DMG block ack agreement
b) WinEndB = WinStartB + BufSizeB – 1
c) WinCapacityB = BufSizeB
d) WinHeadB = SSN – 1, where SSN is taken from the ADDBA Request, similar to WinStartB
e) WinTailB = SSN – 1
10.24.11.4.3 Operation for each received Data frame
For each received Data frame that is related to a specific DMG block ack agreement, the receive reordering
buffer record is modified as follows, where SN is the value of the Sequence Number field of the received
MPDU:
a) If WinStart B SN WinEnd B
1) Store the received MPDU in the buffer.
i) If SN > WinHeadB, Set WinHeadB = SN.
ii) If SN > (WinTailB + BufSizeB),
1) All MSDU buffers with sequence numbers from WinTailB to SN – BufSizeB that
were received correctly are passed to the next MAC process.
2) Set WinTailB = SN – BufSizeB.
iii) Set WinCapacityB = WinTailB + BufSizeB – WinHeadB.
2) Set WinStartB to the value of the Sequence Number field of the first MSDU or A-MSDU that is
missing to allow in-order delivery to the next MAC process.
3) Set WinEndB = WinStartB + BufSizeB – 1.
b) If WinEndB < SN < WinStartB + 211
1) Store the received MPDU in the buffer.
2) Set WinEndB = SN.
1436
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
3) Set WinStartB = WinEndB – BufSizeB + 1.
4) All MSDU buffers with sequence numbers from WinTailB to SN – BufSizeB that were received
correctly are passed to the next MAC process.
5) Set WinTailB = SN – BufSizeB.
6) Set WinHeadB = SN.
7) Set WinCapacityB = WinTailB + BufSizeB – WinHeadB.
11
c) If WinStart B + 2 SN WinStart B , discard the MPDU (do not store the MPDU in the buffer, do
not pass the MSDU or A-MSDU up to the next MAC process).
d) For each received BlockAckReq frame the block acknowledgment record for that agreement is
modified as follows, where SSN is the value from the Starting Sequence Number field of the
received BlockAckReq frame:
1) If WinStart B SSN WinEnd B
i) Set WinStartB = SSN.
ii) Set WinEndB = WinStartB + BufSizeB – 1.
iii) If SSN > WinHeadB, set WinHeadB = SSN – 1.
iv) If SSN > (WinTailB + BufSizeB),
1) All MSDU buffers with sequence numbers from WinTailB to SSN – BufSizeB, are
discarded from the buffer.
2) Set WinTailB = SSN – BufSizeB.
v) Set WinCapacityB = WinTailB + BufSizeB – WinHeadB.
2) If WinEndB < SSN < WinStartB + 211
i) Set WinStartB = SSN.
ii) Set WinEndB = WinStartB + BufSizeB – 1.
iii) Set WinHeadB = SSN – 1.
iv) If SSN > (WinTailB + BufSizeB),
1) All MSDU buffers with sequence numbers from WinTailB to SSN – BufSizeB, are
discarded from the buffer.
2) Set WinTailB = SSN – BufSizeB.
v) Set WinCapacityB = WinTailB + BufSizeB – WinHeadB.
11
3) If WinStart B + 2 SSN WinStart B , make no changes to the record.
10.24.11.4.4 Operation for ongoing release of received MPDUs
The reordering buffer shall continue to pass MSDUs or A-MSDUs up to the next MAC process that are
stored in the buffer in order of increasing value of the Sequence Number field, starting with the MSDU or
A-MSDU that has SN = WinTailB and proceeding sequentially until there is no ready in-order MSDU or
A-MSDU buffered for the next sequential value of the Sequence Number field.
a) Set WinTailB to the value of the Sequence Number field of the last MSDU or A-MSDU that was
passed up to the next MAC process plus one.
10.24.11.5 Generation and transmission of BlockAck frame by a STA with flow control
In addition to the behavior specified in 10.24.7.5 when responding with a BlockAck frame, the RBUFCAP
field shall be updated with the value of WinCapacityB.
1437
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.24.11.6 Originator’s behavior with flow control support
If the BA with Flow Control field within a recipient’s DMG Capabilities element is equal to 1, the originator
shall not transmit an MPDU with a SN that is beyond the current recipient’s buffer capacity (WinLimitO).
The BlockAck frame indicates the number of free buffer slots available at the recipient for reception of
additional MPDUs.
The originator shall update the variable WinLimitO upon reception of a valid BlockAck:
— Set WinCapacityO to the received value of the RBUFCAP field in the BlockAck frame.
— Set MostSuccSN to the highest SN of positively acknowledged MPDUs
— Set WinLimitO = MostSuccSN + WinCapacityO
NOTE—Updating the variable WinLimitO limits the transmission of the following MPDUs.
Originator’s support of recipient’s partial state is defined in 10.24.7.9.
10.25 No Acknowledgment (No Ack)
When a QoS Data frame is transmitted with the Ack Policy subfield set to No Ack, there is no MAC-level
recovery, and the reliability of this traffic is reduced, relative to the reliability of traffic with other
acknowledgment policies, due to the increased probability of lost frames from interference, collisions, or time-
varying channel parameters. A protective mechanism (such as transmitting using HCCA, RTS/CTS, or the
mechanism described in 10.26) should be used to reduce the probability of other STAs transmitting during the
TXOP.
10.26 Protection mechanisms
10.26.1 Introduction
These protection mechanisms cause a STA that is a potential interferer to defer any transmission for a known
period of time. When these mechanisms are used, non-ERP STAs do not interfere with frame exchanges
using ERP PPDUs between ERP STAs and non-HT STAs do not interfere with frame exchanges using HT
PPDUs between HT STAs.
10.26.2 Protection mechanism for non-ERP receivers
The intent of a protection mechanism is to cause a STA not to transmit an MPDU with the Type subfield equal
to Data or an MMPDU with an ERP-OFDM preamble and header unless it has attempted to update the NAV of
receiving NonERP STAs. The updated NAV period shall be longer than or equal to the total time required to
send the Data and any required response frames. An ERP STA shall use protection mechanisms (such as RTS/
CTS or CTS-to-self) for ERP-OFDM MPDUs with the Type subfield equal to Data or an MMPDU when the
Use_Protection field of the ERP element is equal to 1 (see the requirements of 10.7). Protection mechanisms
frames shall be sent using one of the mandatory Clause 15 or Clause 16 rates and using one of the mandatory
Clause 15 or Clause 16 waveforms, so all STAs in the BSA are able to learn the duration of the exchange even
if they cannot detect the ERP-OFDM signals using their CCA function.
In the case of a BSS composed of only ERP STAs, but with knowledge of a neighboring co-channel BSS
having NonERP traffic, the AP might need protection mechanisms to protect the BSS’s traffic from
interference. This provides propagation of NAV to all attached STAs and all STAs in a neighboring co-channel
BSS within range by messages sent using rates contained in the BSSBasicRateSet parameter. The frames that
propagate the NAV throughout the BSS include RTS/CTS/Ack frames, all Data frames with the More
1438
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Fragments field equal to 1, all Data or Management frames sent in response to PS-Poll frame that are not
proceeded in the frame exchange sequence by a Data frame with the More Fragments field equal to 1, Beacon
frames with nonzero CFDurRemaining, CF-End frames, and CF-End +CF-Ack frames.
When RTS/CTS is used as the protection mechanism, cases exist such as NAV resetting (discretionary, as
indicated in 10.3.2.4), where a hidden STA may reset its NAV and this may cause a collision. The likelihood of
occurrence is low, and it is not considered to represent a significant impairment to overall system operation. A
mechanism to address this possible situation would be to use alternative protection mechanisms or to revert to
alternative modulation methods.
The rules for calculating RTS/CTS NAV fields are unchanged when using RTS/CTS as a protection
mechanism.
Additionally, if any of the rates in the BSSBasicRateSet parameter of the protection mechanism frame
transmitting STA’s BSS are Clause 15 or Clause 16 rates, then the protection mechanism frames shall be sent
at one of those Clause 15 or Clause 16 basic rates.
The NonERP_Present bit shall be set to 1 when a NonERP STA is associated with the BSS. In an IBSS if a
member of an IBSS detects one or more NonERP STAs that are members of the same IBSS the
NonERP_Present bit should be set to 1. Examples of when the NonERP present bit may additionally be set
to 1 include, but are not limited to, when:
a) A NonERP infrastructure BSS or NonERP IBSS is overlapping (a NonERP BSS may be detected by
the reception of a Beacon frame where the supported rates contain only Clause 15 or Clause 16
rates).
b) In an IBSS if a Beacon frame is received from one of the IBSS participants where the operational
rate set contains no Clause 18 rates and no BSS membership selectors.
c) A Management frame (excluding a Probe Request) is received where the operational rate set
contains no Clause 18 rates and no BSS membership selectors.
A NonERP mesh STA shall set the NonERP_Present and Use_Protection bits to 1, when establishing a mesh
peering with a mesh STA.
When a mesh STA establishes a mesh peering with a NonERP mesh STA, the mesh STA shall set the
NonERP_Present bit to 1 and the mesh STA should set the Use_Protection bit to 1. In addition, a mesh STA
should set the NonERP_Present bit and the Use_Protection bit to 1 when
— A mesh STA detects the overlapped presence of either a NonERP BSS, a NonERP IBSS, or a
NonERP MBSS, or
— A Beacon frame is received from a neighbor STA where the operational rate set contains no
Clause 18 rates and no BSS membership selectors, or
— A Management frame (excluding Probe Request) is received where the operational rate set contains
no Clause 18 rates and no BSS membership selectors.
A mesh STA may set the NonERP_Present and the Use_Protection bits to 1 based on its internal policies,
which is beyond the scope of the standard.
The Use_Protection bit may be set to 1 when the NonERP_Present bit is 1.
If one or more NonERP STAs are associated in the BSS, the Use_Protection bit shall be set to 1 in
transmitted ERP elements.
In an IBSS the setting of the Use_Protection bit is left to the STA. In an IBSS there is no uniform concept of
association; therefore, a typical algorithm for setting the Use_Protection bit takes into account the traffic
1439
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
pattern and history on the network. If a member of an IBSS detects one or more NonERP STAs that are
members of the same IBSS or receives a Beacon from a member of the same IBSS with the Use_Protection
bit equal to 1, then the Use_Protection bit should be set to 1 in the ERP element of transmitted Beacon and
Probe Response frames.
An ERP STA shall invoke the use of a protection mechanism after transmission or reception of the
Use_Protection bit with a value of 1 in an MMPDU to or from the BSS that the ERP STA has joined or
started. An ERP STA may additionally invoke protection mechanism use at other times. An ERP STA may
disable protection mechanism use after transmission or reception of the Use_Protection bit with a value of 0
in an MMPDU to or from the BSS that the ERP STA has joined or started.
An ERP mesh STA shall invoke the use of a protection mechanism after the transmission of the
Use_Protection bit with a value of 1 in an MMPDU. In addition, an ERP mesh STA may invoke protection
mechanism at other times. An ERP mesh STA may disable protection mechanism use after transmission of
the Use_Protection bit with a value of 0 in an MMPDU.
When there are no NonERP STAs associated with the BSS and the ERP element sender’s
dot11ShortPreambleOptionImplemented is true, then the Barker_Preamble_Mode bit may be set to 0. The
Barker_Preamble_Mode bit shall be set to 1 by the ERP element sender if one or more associated NonERP
STAs are not short preamble capable as indicated in their Capability Information field, or if the ERP element
senders dot11ShortPreambleOptionImplemented is false.
When dot11ShortPreambleOptionImplemented is true and all peer mesh STAs support the short preamble,
the mesh STA may set the Barker_Preamble_Mode bit to 0. When dot11ShortPreambleOptionImplemented
is false or any of its peer mesh STAs do not support the short preamble, the mesh STA shall set the
Barker_Preamble_Mode field to 1.
If a member of an IBSS detects one or more nonshort-preamble-capable STAs that are members of the same
IBSS, then the Barker_Preamble_Mode bit should be set to 1 in the transmitted ERP element.
An ERP STA shall use long preambles when transmitting Clause 15, Clause 16, and Clause 18 frames after
transmission or reception of an ERP element with a Barker_Preamble_Mode value of 1 in an MMPDU to or
from the BSS that the ERP STA has joined or started, regardless of the value of the short preamble
capability bit from the same received or transmitted MMPDU that contained the ERP element. An ERP STA
may additionally use long preambles when transmitting Clause 15, Clause 16, and Clause 18 frames at other
times. An ERP STA may use short preambles when transmitting Clause 15, Clause 16, and Clause 18
frames after transmission or reception of an ERP element with a Barker_Preamble_Mode value of 0 in an
MMPDU to or from the BSS that the ERP STA has joined or started, regardless of the value of the short
preamble capability bit from the same received or transmitted MMPDU. A NonERP STA may also follow
the rules given in this paragraph.
An ERP mesh STA shall use long preambles when transmitting Clause 15, Clause 16, and Clause 18 frames
after transmission or reception of an ERP element with a Barker_Preamble_Mode value of 1 in an MMPDU
to or from the MBSS to which the ERP mesh STA belongs. A Mesh STA may use long preambles when
transmitting Clause 15, Clause 16, and Clause 18 frames at other times.
10.26.3 Protection mechanisms for transmissions of HT PPDUs
10.26.3.1 General
Transmissions of HT PPDUs, referred to as HT transmissions, are protected if there are other STAs present that
cannot interpret HT transmissions correctly. The HT Protection and Nongreenfield HT STAs Present fields in
the HT Operation element within Beacon and Probe Response frames are used to indicate the protection
requirements for HT transmissions.
1440
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The HT Protection field may be set to no protection mode only if the following are true:
— All STAs detected (by any means) in the primary or the secondary channel are HT STAs, and
— All STAs that are known by the transmitting STA to be a member of this BSS are either
— 20/40 MHz HT STAs in a 20/40 MHz BSS, or
— 20 MHz HT STAs in a 20 MHz BSS.
The HT Protection field may be set to nonmember protection mode only if the following are true:
— A non-HT STA is detected (by any means) in either the primary or the secondary channel or in both
the primary and secondary channels, that is not known by the transmitting STA to be a member of
this BSS, and
— All STAs that are known by the transmitting STA to be a member of this BSS are HT STAs.
The HT Protection field may be set to 20 MHz protection mode only if the following are true:
— All STAs detected (by any means) in the primary channel and all STAs detected (by any means) in
the secondary channel are HT STAs and all STAs that are members of this BSS are HT STAs, and
— This BSS is a 20/40 MHz BSS, and
— There is at least one 20 MHz HT STA associated with this BSS.
The HT Protection field is set to non-HT mixed mode otherwise.
NOTE—The rules stated above allow an HT AP to select non-HT mixed mode at any time.
In an IBSS, the HT Protection field is reserved, but an HT STA shall protect HT transmissions as though the
HT Protection field were equal to non-HT mixed mode. A STA that is a member of an IBSS shall protect HT-
greenfield format PPDUs and RIFS sequences, adhering to the same requirements as described in the line of
Table 10-13 labeled “Use_Protection = 0 or ERP element is not present (HT Protection field equal to non-HT
mixed mode).”
Table 10-13—Protection requirements for HT Protection field values
nonmember protection mode and non-HT mixed mode
Condition Requirements
Use_Protection = 0 or ERP element is not The protection requirements for HT transmissions using HT-
present greenfield format are specified in 10.26.3.1.
(HT Protection field equal to non-HT mixed
mode) The protection requirements for HT transmissions using RIFS
within the HT transmission burst are specified in 10.26.3.3.
The protection mechanism for other transmissions not already
described above is based on one of the sequences defined in
Table 10-14.
Use_Protection = 1 All HT transmissions shall be protected using mechanisms as
(HT Protection field equal to nonmember described in 10.26.2.
protection mode or non-HT mixed mode)
In an MBSS, the HT Protection field and the Nongreenfield HT STAs Present field are determined as described
in 10.26.3.5.
In an IBSS and an MBSS, the RIFS Mode field of the HT Operation element is reserved, but an HT STA shall
operate as though this field were equal to 1.
1441
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
During the 40 MHz phase of PCO operation, a PCO active STA may act as though the HT Protection field
were equal to no protection mode, regardless of the actual value of the HT Protection field transmitted by the
AP.
When the HT Protection field is equal to no protection mode or 20 MHz protection mode and the
Nongreenfield HT STAs Present field is equal to 0, no protection is required since all HT STAs in the BSS are
capable of decoding HT-mixed format and HT-greenfield format transmissions.
When the HT Protection field is equal to no protection mode or 20 MHz protection mode and the
Nongreenfield HT STAs Present field is equal to 1, HT transmissions that use the HT-greenfield format shall
be protected. This protection may be established by transmitting a PPDU with the TXVECTOR FORMAT
parameter set to HT_MF or any of the methods described in Table 10-14.
Table 10-14—Applicable HT protection mechanisms
HT protection mechanism
Control frames such as RTS/CTS or CTS-to-self prior to the HT transmissions:
— 20 MHz transmissions use the rates defined in Clause 17 or Clause 18
— 40 MHz transmissions use non-HT duplicate frames defined in Clause 19
L-SIG TXOP protection
As the first PPDU in the TXOP, send one of:
— a non-HT PPDU containing a frame that requires an immediate response
— an HT-mixed format at PPDU containing a frame that requires an immediate response in a non-HT
PPDU
PPDUs after the first PPDU exchange may be HT-greenfield format PPDUs and/or be separated by RIFS.
When the HT Protection field is equal to nonmember protection mode and the Use_Protection field in the ERP
element is equal to 0, HT transmissions should be protected. When the HT Protection field is equal to
nonmember protection mode, the Use_Protection field in the ERP element is equal to 0, and the Nongreenfield
HT STAs Present field is equal to 1, HT transmissions using HT-greenfield format shall be protected. When
the HT Protection field is equal to nonmember protection mode and the Use_Protection field in the
ERP element is equal to 1, HT transmissions shall be protected according to the requirements described in
Table 10-13.
When the HT Protection field is equal to non-HT mixed mode, HT transmissions shall be protected. The type
of protection required depends on the type of transmission as well as the type of the non-HT STAs that are
present in the BSS. Protection requirements that apply when the HT Protection field is equal to non-HT mixed
mode are described in Table 10-13.
If the transmission requires protection and the Use_Protection field within the ERP element is equal to 0 or the
ERP element is not present in the Beacon, HT transmissions shall be protected using one of the mechanisms
identified in Table 10-14.
NOTE—Rules for rate selection for the HT protection mechanisms listed in Table 10-14 are described in 10.7.
If the HT Protection field is equal to no protection mode and the Secondary Channel Offset field is equal to
SCA or SCB, a STA may transmit a 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH set to
HT_CBW40) to initiate a TXOP provided that the restrictions specified in 10.7 are obeyed. When the HT
Protection field is not equal to no protection mode or the Secondary Channel Offset field is equal to SCN, a
1442
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA shall not transmit a 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH set to HT_CBW40)
to initiate a TXOP.
10.26.3.2 Protection rules for HT STA operating a direct link
An HT STA operating a direct link with another HT STA in a non-HT BSS shall operate according to the rules
found in 10.26 as though the following fields have the settings indicated:
a) The RIFS Mode field of the HT Operation element equal to 1
b) The HT Protection field equal to non-HT mixed mode
c) The Nongreenfield HT STAs Present field equal to 1
d) The OBSS Non-HT STAs Present field equal to 1
e) The L-SIG TXOP Full Support field equal to 0
f) The PCO Active field equal to 0
g) The Basic HT-MCS Set field equal to all 0s
10.26.3.3 RIFS protection
If the HT Protection field is equal to nonmember protection mode or non-HT mixed mode, the AP may set the
RIFS Mode field to 0 according to implementation-specific criteria (i.e., such as to protect overlapping non-HT
BSSs in the primary or secondary channels).
If the HT Protection field is not equal to nonmember protection mode and it is not equal to non-HT mixed
mode, the RIFS Mode field shall be set to 1.
If the RIFS Mode field of an AP’s HT Operation element is equal to 1:
a) A STA that is associated with the AP may protect RIFS sequences when the HT Protection field of
the HT Operation element transmitted by the AP is equal to nonmember protection mode.
b) A STA that is associated with the AP shall protect RIFS sequences when the HT Protection field of
the HT Operation element transmitted by the AP is equal to non-HT mixed mode.
10.26.3.4 Use of OBSS Non-HT STAs Present field
The OBSS Non-HT STAs Present field allows HT APs to report the presence of non-HT STAs that are not
members of its BSS in the primary channel, the secondary channel, or in both primary and secondary channels.
A second HT AP that detects a first HT AP’s Beacon frame with the OBSS Non-HT STAs Present field equal
to 1 may cause HT-greenfield format and RIFS sequence transmissions of the second AP’s BSS to be protected
by setting the HT Protection field of its HT Operation element to non-HT mixed mode. If the NonERP_Present
field is equal to 1 in the first AP’s Beacon frame, the Use_Protection field may also be set to 1 by the second
AP.
An HT STA may also scan for the presence of non-HT devices either autonomously or, for example, after the
STA’s AP transmits an HT Operation element with the HT Protection field equal to nonmember protection
mode. Non-HT devices can be detected as follows:
— Reception of a Management frame that does not carry an HT Capabilities element and the frame is
required to carry this element when transmitted by an HT STA, or
— Reception of a Beacon frame containing an HT Operation element with the OBSS Non-HT STAs
Present field equal to 1.
When non-HT devices are detected, the STA may enable protection of its HT-greenfield format and RIFS
sequence transmissions.
1443
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—If a non-HT device is detected and the STA determines that its HT-greenfield format or RIFS sequence
transmissions are affecting the operation of the non-HT device, then the STA might enable protection of its HT-
greenfield format and RIFS sequence transmissions.
See also 11.9.8.5, which defines rules for the OBSS Non-HT STAs Present field related to HT-greenfield
transmissions in certain operating classes.
10.26.3.5 Protection rules for an HT mesh STA
A mesh STA determines the HT Protection and Nongreenfield HT STAs Present fields in the HT Operation
element in the transmitting frame as follows:
The HT Protection field in a mesh STA may be set to no protection mode only if
— All STAs detected in the primary or the secondary channel are HT STAs, and
— All mesh STA members of this MBSS that are one-hop neighbors of the transmitting mesh STA are
either:
— 20/40 MHz HT mesh STAs in a 20/40 MHz MBSS, or
— 20 MHz HT mesh STAs in a 20 MHz MBSS.
The HT Protection field in a mesh STA may be set to nonmember protection mode only if
— A non-HT STA is detected in either the primary or the secondary channel or in both the primary and
secondary channels, that is not known by the transmitting mesh STA to be a member of this MBSS,
and
— All mesh STA members of this MBSS that are one-hop neighbors of the transmitting mesh STA are
HT mesh STAs.
The HT Protection field in a mesh STA may be set to 20 MHz protection mode only if
— All STAs detected in the primary and all STAs detected in the secondary channel are HT STAs, and
— All mesh STA members of this MBSS that are one-hop neighbors of the transmitting mesh STA are
HT mesh STAs, and
— The MBSS is a 20/40 MHz MBSS, and
— There is at least one 20 MHz HT mesh STA that is one-hop neighbor of the transmitting mesh STA.
The HT Protection field in a mesh STA is set to non-HT mixed mode otherwise.
If two peer HT mesh STAs report the same protection mode in HT Protection field, the protection
mechanisms of the related mode shall be used to protect the transmission between the peer HT mesh STAs.
If an HT mesh STA and its peer HT mesh STA report different protection modes in HT Protection field, the
following rules shall be used:
a) If an HT mesh STA or its peer HT mesh STA reports non-HT mixed mode, the protection
mechanisms of non-HT mixed mode shall be used to protect the transmission between the peer HT
mesh STAs.
b) If an HT mesh STA or its peer HT mesh STA reports nonmember protection mode and non-HT
mixed mode is not reported by any of these HT mesh STAs, the protection mechanisms of
nonmember protection mode shall be used to protect the transmission between the peer HT mesh
STAs.
c) If an HT mesh STA or its peer HT mesh STA reports 20 MHz protection mode and neither non-HT
mixed mode nor nonmember protection mode is reported by any of these HT mesh STAs, the
protection mechanisms of 20 MHz protection mode shall be used to protect the transmission
between the peer HT mesh STA.
1444
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If at least one HT peer mesh STA in its mesh neighborhood indicates the Nongreenfield HT STAs Present
equal to 1, the protection rules related to Nongreenfield HT STAs Present should also be applied to the
communication between HT peer mesh STAs.
10.26.4 L_LENGTH and L_DATARATE parameter values for HT-mixed format PPDUs
L_LENGTH and L_DATARATE determine the duration that non-HT STAs do not transmit, equal to the
remaining duration of the HT PPDU or the L-SIG duration when L-SIG TXOP protection is used as defined in
10.26.5, following the non-HT portion of the preamble of the HT-mixed format PPDU.
The L_DATARATE parameter of the TXVECTOR shall be set to the value 6 Mb/s.
A STA that is transmitting a PPDU with the FORMAT parameter of the TXVECTOR equal to HT_MF and
that is not operating by the L-SIG TXOP protection rules described in 10.26.5 shall set the value of the
L_LENGTH parameter to the value (in octets) given by Equation (10-13):
L_LENGTH = TXTIME – Signal Extension – aPreambleLength + aPHYHeaderLength
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
aSymbolLength
N OPS – aPHYServiceLength + aPHYConvolutionalTailLength
-----------------------------------------------------------------------------------------------------------------------------------
8
(10-13)
where
TXTIME is the duration (in microseconds) of the HT PPDU defined in 6.5.5
Signal Extension is 0 µs when TXVECTOR parameter NO_SIG_EXTN is true and is aSignalEx-
tension as defined in Table 19-25 of 19.4.4 when TXVECTOR parameter
NO_SIG_EXTN is false
aSymbolLength is the duration of a symbol (in microseconds), defined in 6.5.4
(aPreambleLength + aPHYHeaderLength) is the duration (in microseconds) of the non-HT PHY pream-
ble and L-SIG, defined in 6.5.4
N OPS is the number of octets transmitted during a period of aSymbolLength at the rate
specified by L_DATARATE
aPHYServiceLength is the number of bits in the PHY SERVICE field, defined in 6.5.4 (PLME-CHAR-
ACTERISTICS.confirm)
aPHYConvolutionalTailLength is the number of bits in the convolutional code tail bit sequence, defined
in 6.5.4
NOTE 1—The last term of the L_LENGTH definition corrects for the fact that non-HT STAs add the length of the
SERVICE field and tail bits (assuming a single convolutional encoder) to the value communicated by the L_LENGTH
field.
TXTIME – Signal Extension – 20
NOTE 2—For a Clause 19 PHY, this equation simplifies to L_LENGTH = ------------------------------------------------------------------------------------------ 3–3.
-
4
A STA that is operating under L-SIG TXOP protection shall set the L_LENGTH parameter according to rules
described in 10.26.5.
A STA shall not transmit a PPDU with the FORMAT parameter set to HT_MF in TXVECTOR if the
corresponding L_LENGTH value calculated with Equation (10-13) exceeds 4095 octets.
NOTE—The transmission of frames with L_LENGTH above 2332 octets (i.e., a Data frame containing an unencrypted
2304 octet MSDU) might be accompanied by a protection mechanism (e.g., RTS/CTS or CTS-to-self protection) if it is
determined that the use of L_LENGTH fails to effectively suppress non-HT transmissions. How this is determined is
outside the scope of this standard.
1445
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.26.5 L-SIG TXOP protection
10.26.5.1 General rules
The L-SIG TXOP protection mechanism is obsolete. Consequently, this subclause might be removed in a later
revision of this standard.
Figure 10-39 illustrates protection by the SIG Length and Rate fields. The terms used in this figure are defined
below and in 19.3.2.
aPreambleLength +
aPHYHeaderLength L-SIG Duration = (L_LENGTH / L_DATARATE) + Signal Extension
SIG
L-STF L-LTF L-SIG HT-SIG HT-STF HT-LTF(s) DATA
EXT
- L_DATARATE - MCS
- L_LENGTH - LENGTH SIG
Signal Extension Ack
EXT
Figure 10-39—Basic concept of L-SIG TXOP protection
The AP determines whether all HT STAs associated with its BSS support L-SIG TXOP protection and
indicates this determination in the L-SIG TXOP Protection Full Support field of its HT Operation element.
This field shall not be set to 1 unless the L-SIG TXOP Protection field is equal to 1 for all HT STAs in the
BSS.
Support for L-SIG TXOP protection at an intended recipient can be determined through examination of its HT
Capability element.
In an IBSS and an MBSS the L-SIG TXOP Protection Full Support field of the HT Operation element is
reserved, but an HT STA shall operate as though the field were equal to 0.
A VHT AP shall set the HT Operation element HT Operation Information field L-SIG TXOP Protection Full
Support subfield to 0.
A VHT STA shall set the HT Capabilities element HT Capability Information field L-SIG TXOP Protection
Support subfield to 0 during (re)association.
A STA shall not transmit a frame using L-SIG TXOP protection directed to a recipient that does not support L-
SIG TXOP protection.
A STA that transmits an L-SIG TXOP Protected frame should use an MCS from the Basic HT-MCS Set field
of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the
HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive for the
transmission of that frame if
— The frame initiates a TXOP in an IBSS or in an MBSS, or
— The L-SIG TXOP Protection Full Support field is equal to 0 by its AP.
Under L-SIG TXOP protection operation, the L-SIG field with an HT-mixed format PHY preamble represents
a duration value equivalent (except in the case of the initial frame that establishes the TXOP, as described
below) to the sum of:
a) The value of Duration/ID field contained in the MAC header and
b) The duration remaining in the current packet after the L-SIG, which is equal to the duration of the
current packet less (aPreambleLength + aPHYHeaderLength)
1446
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A duration value determined from the L_DATARATE and L_LENGTH parameters of the TXVECTOR or
RXVECTOR rounded up to a multiple of aSymbolLength that is not equal to the remaining duration of the
frame is called an L-SIG duration. The TXVECTOR L_LENGTH (defined in 19.2.2), when L-SIG TXOP
protection is used, shall contain the value (in octets) given by Equation (10-14).
L_LENGTH = L-SIG Duration – Signal Extension N OPS
-------------------------------------------------------------------------------------
aSymbolLength (10-14)
– aPHYServiceLength + aPHYConvolutionalTailLength
-----------------------------------------------------------------------------------------------------------------------------------
8
where
Signal Extension is defined in 10.26.4
aSymbolLength is the duration of symbol, defined in 6.5.4
N OPS is the number of octets transmitted during a period of aSymbolLength at
the rate specified by L_DATARATE
aPHYServiceLength is the number of bits in the PHY SERVICE field, defined in 6.5.4
aPHYConvolutionalTailLength is the number of bits in the convolutional code tail bit sequence, defined
in 6.5.4
durations are expressed in microseconds
L-SIG Duration – Signal Extension
NOTE—For a Clause 19 PHY, this equation simplifies to L_LENGTH = ----------------------------------------------------------------------------------------- 3–3.
4
Non-HT STAs are not able to receive any PPDUs that start during the L-SIG duration. Therefore, no frame
shall be transmitted to a non-HT STA during an L-SIG protected TXOP.
See also 10.3.2.4, which describes a rule for resetting a NAV value that was set by an L-SIG TXOP
protected frame.
10.26.5.2 L-SIG TXOP protection rules at the TXOP holder
Figure 10-40 illustrates an example of how L-SIG durations are set when using L-SIG TXOP protection.
MAC Duration
MAC Duration
F F IG F F IG
T T RTS T T
S
- -L -S S
- -L -S DATA CF-End
L L L L L L
L-SIG Duration L-SIG Duration
MAC Duration
F F G F F G
T T I T T I
S
- L
- -S CTS S
- L
- -S BA
L L L L L L
L-SIG Duration
Figure 10-40—Example of L-SIG duration setting
An L-SIG TXOP protected sequence shall start with one of the following:
— an initial handshake, which is the exchange of two frames (each inside an HT-mixed format PPDU)
that establish protection (e.g., RTS/CTS) or
— an initial frame that establishes protection but generates no response (e.g., a CTS to self)
1447
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
provided that this initial sequence is also valid for the start of a TXOP. The term L-SIG TXOP protected
sequence includes these initial frames and any subsequent frames transmitted within the protected duration.
Under L-SIG TXOP protection operation, when the initial PPDU that establishes protection requires a
response, the L-SIG duration of the initial PPDU shall be as follows:
L-SIG Duration = T Init_PPDU – aPreambleLength + aPHYHeaderLength + SIFS + T Res_PPDU
where
T Init_PPDU is the length in time (in microseconds) of the entire initial PPDU
T Res_PPDU is the length in time (in microseconds) of the expected response PPDU
aPreambleLength + aPHYHeaderLength is the length in time (in microseconds) of the non-HT PHY
header, defined in 6.5.4
When the initial PPDU that establishes protection requires no response, the L-SIG duration shall contain the
following value:
L-SIG Duration = T Init_MACDur + T Init_PPDU – aPreambleLength + aPHYHeaderLength
where
T Init_MACDur is the Duration/ID field value carried in the MAC header of the initial PPDU
An HT STA using L-SIG TXOP protection should use an accurate prediction of the TXOP duration inside the
Duration/ID field of the MAC header to avoid inefficient use of the channel capability.
The L-SIG duration of the initial frame shall allow for the longest possible duration of the response frame (i.e.,
taking into account wrapped +HTC in the case of control response frames). If the actual duration of the
response frame is less than this allowed duration, the TXOP holder shall delay transmission of the third PPDU
in the L-SIG TXOP protected sequence until a SIFS after this L-SIG duration expires.
NOTE—A result of this step is that a non-HT STA sees a SIFS between the end of the first PPDU and the start of the
third PPDU.
If the initial frame handshake succeeds (i.e., upon reception of a response frame with L-SIG TXOP protection
addressed to the TXOP holder), all HT-mixed format PPDUs transmitted inside an L-SIG TXOP protection
protected TXOP shall contain an L-SIG duration that extends to the endpoint indicated by the MAC Duration/
ID field. The first PPDU transmitted after a successful initial handshake (i.e., upon reception of a response
frame with L-SIG TXOP protection addressed to the TXOP holder) shall have the TXVECTOR FORMAT
parameter set to HT_MF.
NOTE—The requirement to use HT_MF for the third PPDU arises as follows. A third-party STA receives the first
PPDU, but does not receive any MPDU correctly from it. It sets its NAV based on the L-SIG duration. The STA does not
receive the second PPDU. It is necessary for the STA to be able to determine either an L-SIG duration or MAC duration
value from the third PPDU in order to protect the remaining time in the TXOP. The ability of the STA to make this
determination is enabled by sending the third PPDU using HT-mixed format, containing an L-SIG duration as shown in
Figure 10-40.
The TXOP holder should transmit a CF-End frame starting a SIFS after the L-SIG TXOP protected period.
This step enables STAs to terminate the EIFS procedure to avoid potential unfairness or a capture effect.
NOTE—This case is not an instance of TXOP truncation, because it is not transmitted to reset the NAV.
1448
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.26.5.3 L-SIG TXOP protection rules at the TXOP responder
On receiving a PPDU containing an L-SIG duration addressed to itself, a TXOP responder that set the L-SIG
TXOP Protection Support field to 1 on association shall generate an L-SIG TXOP protection response frame
with the L-SIG duration equivalent to the following:
L-SIG Duration = T MACDur – SIFS – aPreambleLength + aPHYHeaderLength
where
T MACDur is the Duration/ID field value carried in the MAC header of frame(s) received in the PPDU
that generated the response
A STA shall not transmit a response frame containing an L-SIG duration unless it is in response to a frame that
also contained an L-SIG duration.
10.26.5.4 L-SIG TXOP protection NAV update rule
An HT STA that set the L-SIG TXOP Protection Support field to 1 on association that receives a
PHY-RXSTART.indication primitive with RXVECTOR parameter FORMAT equal to HT_MF and
LSIGVALID equal to true and that receives no valid MPDU from which a Duration/ID field value can be
determined shall, when the PHY-RXEND.indication primitive is received, update its NAV to a value equal to
the following:
L-SIG duration – TXTIME – aPreambleLength + aPHYHeaderLength
where
TXTIME is the time required to send the entire PPDU
10.26.6 Protection rules for VHT STAs
A VHT STA is subject to all of the rules for HT STAs that apply to its operating band, except that a PPDU
with the TXECTOR FORMAT parameter set to VHT may be substituted for a PPDU with the TXVECTOR
FORMAT parameter set to HT_MF.
10.27 MAC frame processing
10.27.1 Introduction
Subclauses 10.27.2 to 10.27.9 describe MAC frame and element processing requirements to provide frame,
Action frame, element, and subelement extensibility.
10.27.2 Revision level field processing
A MAC entity that receives a frame with a higher revision level than it supports shall discard the frame
without indication to the sending STA or to LLC.
10.27.3 Duration/ID field processing
When the contents of a received Duration/ID field, treated as an unsigned integer and without regard for
address values, type, and subtype (even when type or subtype contain reserved values), are less than 32 768,
1449
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the duration value is used to update the network allocation vector (NAV) according to the procedures
defined in 10.3.2.4, 10.22.3.4, or 10.36.10, as appropriate.
When the contents of a received Duration/ID field, treated as an unsigned integer, are greater than 32 768,
the contents are interpreted as appropriate for the frame type and subtype or ignored if the receiving MAC
entity does not have a defined interpretation for that type and subtype.
10.27.4 Response to an invalid Action frame
If a STA receives an individually addressed Action frame with an unrecognized Category field or some other
syntactic error and the MSB of the Category field equal to 0, then the STA shall return the Action frame to
the source without change except that the MSB of the Category field is set to 1.
10.27.5 Operation of the Dialog Token field
A dialog token is an integer value that assists a STA in grouping Management frames sent or received at
different times as part of the same dialog. The algorithm by which the integer value for the dialog is selected
is implementation specific, but should be selected in a manner that minimizes the probability of a frame
associated with one dialog being incorrectly associated with another dialog.
10.27.6 Element parsing
A STA that encounters an element with an unknown or reserved element ID value, or an element with an
element ID extension whose element ID extension value is unknown or reserved, in a Management frame
received without error, shall ignore that element and shall parse any remaining management frame body for
additional elements with recognizable element ID (and, if present, element ID extension) values.
The MME of a Vendor-Specific Protected Action frame is located at the end of the frame body.
NOTE—It is not necessary to be able to parse the vendor-specific content to locate the MME.
10.27.7 Vendor specific element parsing
A STA receiving a vendor-specific element that it does not support shall ignore the vendor-specific element.
10.27.8 Extensible element parsing
Table 9-77 indicates which elements are considered extensible in future revisions of the standard, by placing a
Yes in the Extensible column. A STA that receives an extensible element in which the Length field plus two
exceeds the value indicated in Table 9-77 shall discard any part of the element beyond the maximum length
indicated in this table and shall otherwise process the element as though this truncated element had been
received.
10.27.9 Extensible subelement parsing
A subelement has the structure defined in 9.4.3 and is contained within an element or subelement.
A STA that encounters an unknown, unsupported, or reserved subelement ID value contained in an element or
subelement shall ignore the subelement with that subelement ID value and shall continue to parse any
remaining element or subelement body for additional subelements with recognizable subelement ID values.
A STA that receives an element or subelement for which a vendor-specific subelement is defined and that
contains a vendor-specific subelement that it does not support shall ignore this vendor-specific subelement and
1450
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
shall continue to parse any remaining element or subelement body for additional subelements with
recognizable subelement ID values.
Subelements are defined locally in each subclause that defines a structure containing subelements. Subelement
ID numbering is private to that structure. A STA that receives an extensible subelement that is not extensible
using subelements and in which the Length field exceeds the length of the structure of the subelement defined
in this standard shall discard any part of the subelement beyond that length and shall otherwise process the
subelement as though this truncated subelement had been received.
10.27.10 Extensible TLV parsing
A TVHT STA that receives a frame containing a TLV tuple with an unknown Type value shall discard the
tuple and continue processing the next tuple.
10.28 Reverse direction protocol
10.28.1 General
The RD protocol may be supported by an HT STA and by a DMG STA. A STA receiving an RDG is never
required to use the grant. The RD protocol defined in this subclause applies to both types of STAs.
An HT STA indicates support of the RD feature as an RD responder using the RD Responder subfield of the
HT Extended Capabilities field of the HT Capabilities element. A STA shall set the RD Responder subfield
to 1 in frames that it transmits containing the HT Capabilities element if
dot11RDResponderOptionImplemented is true. Otherwise, the STA shall set the RD Responder subfield to
0. In an HT STA, the RDG/More PPDU subfield and the AC Constraint subfield are present in the HTC
field.
A DMG STA indicates support of the RD feature using the Reverse Direction subfield of the DMG STA
Capability Information field of the DMG Capabilities element. A STA shall set the Reverse Direction
subfield to 1 in frames that it transmits containing the DMG Capabilities element if
dot11RDResponderOptionImplemented is true. Otherwise, the STA shall set the Reverse Direction subfield
to 0. In a DMG STA, the RDG/More PPDU subfield and the AC Constraint subfield are present in the QoS
Control field.
10.28.2 Reverse direction (RD) exchange sequence
An RD exchange sequence comprises the following:
a) The transmission of a PPDU by a TXOP holder or SP source containing an RD grant (the RDG
PPDU), which is indicated by the PPDU containing one or more +HTC or DMG MPDUs in which
the RDG/More PPDU subfield is equal to 1. The STA that transmits this PPDU is known as the RD
initiator. The rules for an RD initiator apply only during a single RD exchange sequence, i.e., after
the transmission of an RDG PPDU and up to the end of the last PPDU in the RD exchange sequence.
b) The transmission of one or more PPDUs (the RD response burst) by the STA addressed in the
MPDUs of the RDG PPDU. The first (or only) PPDU of the RD response burst contains at most one
immediate BlockAck or Ack frame. The last (or only) PPDU of the RD response burst contains any
MPDUs requiring a response that is an immediate BlockAck or Ack frame. The STA that transmits
the RD response burst is known as the RD responder. The rules for an RD responder apply only
during a single RD exchange sequence, i.e., following the reception of an RDG PPDU and up to the
transmission of a PPDU by the RD responder in which the RDG/More PPDU subfield is equal to 0.
c) The transmission of a PPDU by the RD initiator containing an immediate BlockAck frame or Ack
frame (the RD initiator final PPDU), if so required by the last PPDU of the RD response burst.
1451
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 1—An RD initiator might include multiple RD exchange sequences within a single TXOP or SP. Each RD
exchange sequence within a single TXOP or SP might be addressed to a different recipient, and any single recipient
might be given more than one RDG within a single TXOP or SP.
NOTE 2—If the RD responder is a VHT AP, the RD response burst can contain VHT MU PPDUs that might have
TXVECTOR parameter NUM_USERS > 1.
An example of an RD exchange sequence is given in O.3.
10.28.3 Rules for RD initiator
An RDG shall not be present unless the MPDU carrying the grant, or every MPDU carrying the grant in an
A-MPDU, matches one of the following conditions:
— A QoS Data frame with the Ack Policy field equal to any value except PSMP Ack (i.e., including
Implicit Block Ack Request), or
— A BlockAckReq frame related to an HT-immediate block ack agreement, or
— An MPDU not needing an immediate response (e.g., block ack under an HT-immediate block ack
agreement, or Action No Ack).
An RDG shall not be present within a PSMP sequence.
NOTE 1—These rules together with the rules in 9.7.3 cause an RDG to be delivered in a PPDU that either requires no
immediate response or requires an immediate response that is a BlockAck or Ack frame.
NOTE 2—An RD initiator is not required to examine the RD Responder field of a potential responder before deciding
whether to send a PPDU to that STA in which the RDG/More PPDU subfield is set to 1.
NOTE 3—An RD initiator is required according to 10.9 to examine the +HTC-HT Support field of a potential responder
before deciding whether to send a PPDU to that STA in which the RDG/More PPDU subfield is set to 1.
Transmission of a +HTC or DMG frame by an RD initiator with the RDG/More PPDU subfield equal to 1
(either transmitted as a non-A-MPDU frame, as a VHT single MPDU, or within an A-MPDU) indicates that
the duration indicated by the Duration/ID field is available for the RD response burst and RD initiator final
PPDU (if present).
An RD initiator that sets the RDG/More PPDU field to 1 in a +HTC or DMG frame transmitted during a TXOP
shall set the AC Constraint subfield to 1 in that frame if the TXOP was gained through the EDCA channel
access mechanism and shall otherwise set it to 0. An RD initiator that sets the RDG/More PPDU field to 1 in a
DMG frame transmitted during an SP can set the AC Constraint subfield to 1 to limit the Data frames
transmitted by the RD responder.
An RD initiator shall not transmit a +HTC or DMG frame with the RDG/More PPDU subfield set to 1 that
requires a response MPDU that is not one of the following frames:
— Ack
— Compressed BlockAck
Subject to TXOP or SP constraints, after transmitting an RDG PPDU, an RD initiator may transmit its next
PPDU as follows:
a) Normal continuation: The RD initiator may transmit its next PPDU a minimum of a SIFS after
receiving a response PPDU that meets one of the following conditions:
1) Contains one or more received +HTC or DMG frames with the RDG/More PPDU subfield
equal to 0
2) In an HT STA, contains one or more received frames that are capable of carrying the HT
Control field but did not contain an HT Control field
3) Contains a received frame that requires an immediate response
1452
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4) In a DMG STA, none of the correctly received frames in the PPDU carry the QoS Control field
b) Error recovery: The RD initiator may transmit its next PPDU when the CS mechanism (see
10.3.2.1) indicates that the medium is idle at the TxPIFS slot boundary (see Figure 10-26) (this
transmission is a continuation of the current TXOP or SP).
NOTE 1—Error recovery of the RDG mechanism is the responsibility of the RD initiator.
NOTE 2—After transmitting a PPDU containing an RDG, if the response is corrupted so that the state of the RDG/More
PPDU subfield is unknown, the RD initiator of the RD exchange is not allowed to transmit after a SIFS. Transmission
can occur a PIFS after deassertion of CS.
A STA that transmits a QoS +CF-Ack Data frame according to the rules in 10.22.3.5 may also include an RDG
in that frame provided that
— It is a non-A-MPDU frame or VHT single MPDU, and
— The target of the +CF-Ack is equal to the Address 1 field of the frame.
NOTE 1—In a non-DMG BSS, the RD initiator can transmit a CF-End frame according to the rules for TXOP truncation
in 10.22.2.9 following an RD transmit sequence. An RD responder never transmits a CF-End.
NOTE 2—In a DMG network, the RD initiator can transmit a CF-End frame according to the rules for TXOP truncation
in 10.22.2.9 or SP truncation in 10.36.8, as appropriate, following an RD transmit sequence. An RD responder never
transmits a CF-End.
10.28.4 Rules for RD responder
An RD responder shall transmit the initial PPDU of the RD response burst a SIFS after the reception of the
RDG PPDU. PPDUs in a response burst are separated by SIFS or RIFS. The RIFS rules in the RD are the same
as in the forward direction; the use of RIFS is constrained as defined in 10.3.2.3.2 and 10.26.3.3.
NOTE—The transmission of a response by the RD responder does not constitute a new channel access but a
continuation of the RD initiator’s TXOP or SP. An RD responder ignores the NAV when responding to an RDG.
The recipient of an RDG may decline the RDG by
— Not transmitting any frames following the RDG PPDU when no response is otherwise required, or
— Transmitting a control response frame with the RDG/More PPDU subfield set to 0, or
— Transmitting a control response frame that contains no HT Control field
An RD responder that is a non-DMG STA may transmit a +CF-Ack non-A-MPDU frame or +CF-Ack VHT
single MPDU in response to a QoS Data +HTC non-A-MPDU frame or VHT single MPDU that has the Ack
Policy field equal to Normal Ack and the RDG/More PPDU subfield equal to 1.
The RD responder shall ensure that its PPDU transmission(s) and any expected responses fit entirely within the
remaining TXOP or SP duration, as indicated in the Duration/ID field of MPDUs within the RDG PPDU.
An RD responder shall not transmit an MPDU (either individually or aggregated within an A-MPDU) that is
not one of the following frames:
— Ack
— Compressed BlockAck
— Compressed BlockAckReq
— Extended Compressed BlockAck
— Extended Compressed BlockAckReq
— QoS data
— Management
1453
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the AC Constraint subfield is equal to 1, the RD responder shall transmit Data frames of only the same AC as
the last frame received from the RD initiator. For a BlockAckReq or BlockAck frame, the AC is determined by
examining the TID field. For a Management frame, the AC is AC_VO. The RD initiator shall not transmit a
+HTC or DMG MPDU with the RDG/More PPDU subfield set to 1 from which the AC cannot be determined.
If the AC Constraint subfield is equal to 0, the RD responder may transmit Data frames of any TID.
During an RD response burst any PPDU transmitted by an RD responder shall contain at least one MPDU with
an Address 1 field that matches the MAC address of the RD initiator, and the inclusion of traffic to STAs other
than the RD initiator in a VHT MU PPDU shall not increase the duration of the VHT MU PPDU beyond that
required to transport the traffic to the RD initiator. The RD responder shall not transmit any frame causing a
response after SIFS with an Address 1 field that does not match the MAC address of the RD initiator. The RD
responder shall not transmit any PPDUs with a CH_BANDWIDTH that is wider than the CH_BANDWIDTH
of the PPDU containing the frame(s) that delivered the RD grant.
If an RDG PPDU also requires an immediate block ack response, the BlockAck frame shall be included in the
first PPDU of the response.
When a PPDU is not the final PPDU of a response burst, an HT Control field carrying the RDG/More PPDU
subfield set to 1 shall be present in every MPDU within the PPDU capable of carrying the HT Control field, or
if the PPDU is transmitted in a DMG BSS, the RDG/More PPDU subfield within the QoS Control field shall be
set to 1 in every MPDU within the PPDU. The last PPDU of a response burst shall have the RDG/More PPDU
subfield set to 0 in all +HTC or DMG MPDUs contained in that PPDU.
The RD responder shall not set the RDG/More PPDU subfield to 1 in any MPDU in a PPDU that contains an
MPDU that requires an immediate response.
NOTE—If the RD responder transmits a PPDU that expects a transmission by the RD initiator after SIFS and no such
transmission is detected, the RD responder has to wait for either another RDG or its own TXOP or SP before it can retry
the exchange.
After transmitting a PPDU containing one or more +HTC or DMG MPDUs in which the RDG/More PPDU
subfield is equal to 0, the RD responder shall not transmit any more PPDUs within the current response burst.
NOTE—If an RD-capable STA that is not the TXOP holder or SP source receives a PPDU that does not indicate an
RDG, there is no difference in its response compared to a STA that is not RD-capable.
10.29 PSMP operation
10.29.1 General
A DMG STA shall not use PSMP.
10.29.2 Frame transmission mechanism during PSMP
10.29.2.1 PSMP frame transmission (PSMP-DTT and PSMP-UTT)
The attribute aDTT2UTTTime is the minimum time between the end of the PSMP-DTT and the start of a
PSMP-UTT addressed to the same STA. This value represents the minimum time the STA is provided to react
to Multi-TID BlockAck, BlockAck, Multi-TID BlockAckReq, BlockAckReq, and Data frames received during
the PSMP-DTT with data, BlockAck, BlockAckReq, Multi-TID BlockAckReq, and Multi-TID BlockAck
frames transmitted in the PSMP-UTT. In a PSMP sequence, if the traffic conditions are such that the time
between the PSMP-DTT and PSMP-UTT of a STA would otherwise be less than the value of
aDTT2UTTTime, the AP shall delay the start of entire PSMP-UTT phase to meet this requirement.
1454
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A PSMP sequence may be used to transmit non-GCR-SP group addressed frames along with individually
addressed frames. Individually addressed frames shall be scheduled after group addressed frames.
In a PSMP frame the STA_ID subfields of all its STA Info fields with STA_INFO Type equal to 2
(individually addressed) shall be unique, i.e., each STA identified in the PSMP frame is identified exactly once.
Individually addressed entries in the PSMP frame should have their PSMP-DTT and PSMP-UTT start offsets
scheduled to minimize the number of on/off transitions or to maximize the delay between their PSMP-DTT and
PSMP-UTT periods. Entries that have only PSMP-DTT should be scheduled closer to the start of the PSMP-
DTTs. Entries that have only PSMP-UTT should be scheduled toward the end of PSMP-UTTs. Entries that
have both PSMP-DTT and PSMP-UTT should be scheduled closer to the transition point from downlink to
uplink transmissions.
NOTE—For effective resource allocation the AP needs to precisely estimate the PSMP-UTT duration for each STA
using the information indicated in a TSPEC, such as Minimum Data Rate, Mean Data Rate, Peak Data Rate, Burst Size,
and Delay Bound fields. However, when the traffic characteristic is quite bursty (e.g., a real-time video application),
precise estimation of PSMP-UTT duration is difficult without timely and frequent feedback of the current traffic
statistics. In order to avoid wasting the available bandwidth by overestimating the PSMP-UTT duration, the AP can
allocate the minimum amount of time to each STA using the PSMP-UTT Duration subfield in the PSMP frame, based on
the value of the Minimum Data Rate field specified in the TSPEC. When the STA receives the PSMP frame, it decides
whether the allocated resource indicated by the PSMP-UTT duration is sufficient for its queued data. If the allocated
resource is sufficient, the STA can transmit all of the queued data at the allocated time.
Frames of different TIDs may be transmitted within a PSMP-DTT or PSMP-UTT allocation of a PSMP
sequence without regard to user priority.
Within a PSMP-DTT or PSMP-UTT between HT STAs, BlockAckReq and BlockAck frames for which an
HT-immediate block ack agreement exists shall be the multi-TID variants, i.e., Multi-TID BlockAckReq and
Multi-TID BlockAck, respectively. Within a PSMP-DTT or PSMP-UTT between STAs where one is not an
HT STA, BlockAckReq and BlockAck frames shall be exchanged through the use of an immediate block ack
agreement and shall be the basic variants, i.e., Basic BlockAckReq and Basic BlockAck, respectively.
10.29.2.2 PSMP downlink transmission (PSMP-DTT)
During a PSMP sequence, a STA shall be able to receive frames during its scheduled PSMP-DTT and is not
required to be able to receive frames at other times.
The AP shall verify that any transmissions within a PSMP sequence to a STA participating in the PSMP
sequence occur wholly within the STA’s PSMP-DTT.
The PSMP-DTT may contain one or more PPDUs, each of which may contain either an A-MPDU or a single
MPDU. Data may be transmitted using either format, provided that the format is supported by both the
transmitter and the receiver.
PPDUs within a PSMP-DTT may be separated using RIFS or SIFS. The use of RIFS is limited as defined in
10.3.2.3.2 and 10.26.3.3.
Each PSMP-DTT shall contain only frames addressed to the RA signaled by the corresponding STA_INFO
field. PPDUs from adjacent PSMP-DTTs shall be separated by at least SIFS. In other words, PPDUs to a
different RA are separated by at least SIFS.
10.29.2.3 PSMP uplink transmission (PSMP-UTT)
A STA that has frames to send that are valid for transmission within the PSMP-UTT shall start transmission
without performing CCA and regardless of NAV at the start of its PSMP-UTT.
1455
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The STA shall complete its transmission within the allocated PSMP-UTT, even if it has more data queued than
can be transmitted during its allocated PSMP-UTT.
NOTE—PSMP-UTT is a scheduled transmission period for the STA, and transmission within a PSMP-UTT does not
imply that the STA is a TXOP holder. This lack of being a TXOP holder disallows a STA from using TXOP truncation
during PSMP-UTT.
The uplink schedule in a PSMP frame shall include an interval between the end of one PSMP-UTT and the
start of the following PSMP-UTT within the same PSMP sequence. This interval shall be either aIUStime or
SIFS. The aIUStime value shall not be used unless the use of RIFS is permitted, as defined in 10.26.3.3. The
PSMP-UTT Duration subfield in the PSMP frame does not include this interval.
PPDUs transmitted within a PSMP-UTT may be separated using RIFS or SIFS. The use of RIFS is limited as
defined in 10.3.2.3.2 and 10.26.3.3.
An AP may transmit a PSMP frame (called a PSMP recovery frame) during a PSMP-UTT when both of the
following conditions are met:
— The CS mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot boundary (see
Figure 10-26) after the start of the PSMP-UTT, and
— The PSMP-UTT duration is longer than the total time of the PSMP recovery frame plus PIFS.
The PSMP recovery frame shall not modify the schedule of a STA that is not scheduled to use this PSMP-UTT.
The schedules of other STAs shall remain unchanged. The PSMP recovery frame may include:
a) A modified PSMP-UTT (and/or PSMP-DTT) for the currently scheduled STA by adjusting the time
remaining by a PIFS plus the duration of the PSMP recovery frame, and
b) PSMP-UTTs for other STAs that were originally scheduled after this PSMP-UTT in the PSMP
sequence in which the PSMP-UTT start offset values are reduced by the time difference between the
end of the original PSMP frame and the end of the PSMP recovery frame.
If the currently scheduled PSMP-UTT duration is shorter than the total time of PSMP recovery frame plus
PIFS, no PSMP recovery frame is transmitted.
Figure 10-41 illustrates a PSMP sequence with and without PSMP recovery.
10.29.2.4 PSMP burst
After transmission of an initial PSMP sequence, additional PSMP sequences may be transmitted by the AP in
order to support resource allocation and error recovery. An initial PSMP sequence followed by one or more
PSMP sequences is termed a PSMP burst and is shown in Figure 10-42.
A STA shall not transmit a +HTC MPDU in which the RDG/More PPDU subfield is set to 1 during a PSMP
burst.
An AP may transmit a CF-End frame a SIFS after the end of a PSMP sequence to end the PSMP burst.
NOTE—A non-AP STA does not transmit a CF-End frame during the PSMP burst because it is not a TXOP holder
during its PSMP-UTT.
1456
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA 2 and STA3 do not
Downlink Phase receive the PSMP frame
P
P M PSMP- PSMP- PSMP- PSMP-
S
A P DTT1 DTT2 DTT3 DTT4
(STA1) (STA2) (STA3) (STA4)
A PSMP- PSMP-
T PSMP-UTT2 PSMP-UTT4
UTT1 UTT3
S (STA2) (STA4)
(STA1) (STA3)
Uplink Phase
(a): PSMP sequence without PSMP recovery
PSMP-recovery frame uses the
standard PSMP frame. PSMP-
recovery frame includes: modified
PSMP-UTT transmission schedule of STA2 and unmodified
from STA2 does not start schedules of STA3 and STA4.
New PSMP-UTT start offsets are
specified relative to the end of the
Downlink Phase y
PSMP-recovery frame (T').
- r
P P e
M PIFS M v
P S PSMP- PSMP- PSMP- PSMP- S o
P c
A DTT1 DTT2 DTT3 DTT4 P e
r
(STA1) (STA2) (STA3) (STA4)
A PSMP- PSMP- PSMP-
T PSMP-UTT4
UTT1 UTT2 UTT3
S (STA4)
(STA1) (STA2) (STA3)
T'
Uplink Phase
(b): PSMP sequence with PSMP recovery
Figure 10-41—Illustration of PSMP sequence with and without PSMP recovery
SIFS SIFS Last PSMP
sequence
Downlink Phase Uplink Phase
Block Ack
Multi-TID
MorePSMP=1
MorePSMP=1
MorePSMP=0
Multi-TID Block
(TID1)
(TID2)
(TID2)
Data
Data
Data
A-MPDU
Ack (RA2)
PSMP
PSMP
PSMP
(RA1)
etc...
A-MPDU A-MPDU
AP (RA2) (RA1)
aIUStime
or SIFS
RIFS or
SIFS SIFS
Data (TID1)
Data (TID2)
SIFS
Block Ack
Multi-TID
Multi-TID Block
(TA1)
Ack (TA1)
Multi-TID Block
A-MPDU
(TID1, TID2)
A-MPDU
Ack (TA2)
STA1
(TA2)
(TA1)
STA1
STA2 UTT
STA2
UTT
Figure 10-42—PSMP burst
1457
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
During the PSMP-DTT or PSMP-UTT, a STA shall not transmit a frame unless it is one of the following:
— Multi-TID BlockAck under HT-immediate policy
— Multi-TID BlockAckReq under HT-immediate policy
— BlockAck under an immediate policy with the BA Ack Policy subfield set to 1 (representing
No Acknowledgment)
— BlockAckReq under an immediate policy with the BAR Ack Policy subfield set to 1 (representing
No Acknowledgment)
— QoS data
— PSMP (a PSMP recovery frame as described in 10.29.2.3)
— BlockAckReq under HT-delayed policy with the BAR Ack Policy subfield set to 1 (representing
No Acknowledgment)
— BlockAck under HT-delayed policy with the BA Ack Policy subfield set to 1 (representing
No Acknowledgment)
— An MPDU that does not require an immediate response (e.g., Action No Ack)
NOTE—An AP can gain access to the channel after a PIFS in order to start transmission of a PSMP sequence.
10.29.2.5 Resource allocation within a PSMP burst
If the allocated PSMP-UTT duration is not long enough for its queued data, the STA transmits only the part of
the queued data that fits within the allocated PSMP-UTT duration and may transmit a resource request to the
AP within that PSMP-UTT. The resource request is communicated by setting either the Queue Size field or the
TXOP Duration Request field of the QoS Control field that is carried in a QoS Data frame (see Figure 10-43).
If a STA receives an PSMP-UTT that is not long enough to transmit data from its queues, it may transmit
within the PSMP-UTT a QoS Null frame containing information about the state of its transmit queues.
NOTE 1—An HT AP might use this information to schedule a PSMP-UTT either in the current PSMP burst or a later
PSMP burst.
NOTE 2—An HT AP might allocate a PSMP-UTT duration in the next PSMP sequence based on the resource request
from the STA sufficient to allow transmission of the remaining queued data.
NOTE 3—The PSMP burst supports retransmission as well as additional resource allocation (see Figure 10-44). Frames
transmitted under an HT-immediate block ack agreement during the PSMP-DTT are acknowledged by a Multi-TID
BlockAck frame during the PSMP-UTT period of the current PSMP sequence. Frames transmitted under an immediate
block ack agreement during the PSMP-DTT are acknowledged by a Basic BlockAck frame during the PSMP-UTT
period of the current PSMP sequence. Frames transmitted under an HT-immediate block ack agreement during the
PSMP UTT can be acknowledged using a Multi-TID BlockAck frame during the PSMP-DTT period of the next PSMP
sequence. Frames transmitted under an immediate block ack agreement during the PSMP-UTT can be acknowledged
using a Basic BlockAck frame during the PSMP-DTT period of the next PSMP sequence. Any failed transmissions
during the PSMP-DTT or PSMP-UTT periods can be respectively retransmitted during the PSMP-DTT or PSMP-UTT
period of the next PSMP sequence.
Figure 10-43 and Figure 10-44 illustrate the operation of resource allocation. STA1 requests the AP to provide
additional resources in its transmission to the AP. The box labeled “Queued data” represents the duration that
would be required to transmit data queued for transmission at the STA. In Figure 10-44, since the AP does not
receive an acknowledgment from STA2, the AP retransmits the data addressed to STA2 and also allocates
resources to STA2 so that STA2 can transmit in the next PSMP sequence.
1458
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
P U 1 U 2 P
D A D A
M P T P T M
S M S M S S
P - o - o P
AP A t A t
Allocated duration
is not enough
U U
D P Queued D P
P A P A
M
- o
t data M
- o
t
STA1 A A
Contains Allocated duration
a resource is enough
request U
D P
P A
M
- o
t
STA2 A
Figure 10-43—PSMP burst showing resource allocation
partially corrupted retransmission
1 2 k 2 k k
P U
D
U
D P ID c
A
U
D ID c
A P ID c
A P
M A A T A T T
S
P T
S
P T
S
M
S ti-l k
c
P T
S ti-l k
c
M
S ti-l k
c
M
S
M
- M
- u M u u
P A o
t A o
t P lo -
A o
t lo P lo P
AP M B M B M B
additional resource allocation
kc
U
D P ID A Queued
U
D P
T
P A ti-l kc
data
P A
M
- o
t u M o
t
A M lo -
A
STA1 B
Contains
a resource
U D ck U D ck
request
D P IT A D P IT A
P A -ti k P A -ti k
l c l c
-M to u o -M to u o
STA2 A M lB A M lB
partially corrupted retransmission
Figure 10-44—PSMP burst showing retransmission and resource allocation
10.29.2.6 PSMP-UTT retransmission
An AP transmits BlockAck frame or Multi-TID BlockAck frame responses, if any, to a STA’s PSMP-UTT
data transmissions under an immediate or HT-immediate block ack agreement, respectively, in the PSMP-
DTT of a subsequent PSMP sequence.
NOTE—An AP might reserve a PSMP-UTT in a subsequent PSMP sequence to allow a STA to retransmit failed frames.
The STA can retransmit failed frames in a PSMP sequence of the current PSMP burst if a PSMP-UTT reservation is
present or in a subsequent SP.
A STA that cannot complete its retransmissions in the last PSMP sequence of the PSMP burst because not
enough time is allocated in its PSMP-UTT may transmit the data outside any PSMP sequence.
NOTE 1—In the case of uplink frames transmitted outside the scheduled SP, the Multi-TID BlockAck frame that
acknowledges these frames is delivered in the PSMP-DTT within the next SP.
1459
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 2—A non-AP STA might transmit data outside the PSMP sequence. The acknowledgment of such frames is
based on their Ack Policy field value and whether a block ack agreement has been established, as follows:
— An Ack Policy of Block Ack, Normal Ack, or Implicit Block Ack Request results in the behavior defined in
9.2.4.5.4.
— An Ack Policy of PSMP Ack causes the AP to record the received Data frame and results in the transmission of
a Multi-TID BlockAck frame in the next PSMP-DTT allocated to the STA.
10.29.2.7 PSMP acknowledgment rules
A non-AP STA shall transmit a Multi-TID BlockAck frame during its PSMP-UTT for data received with the
Ack Policy field set to PSMP Ack or for TIDs in a received Multi-TID BlockAckReq frame for which a
BlockAck frame (Compressed BlockAck or Multi-TID BlockAck) has not yet been transmitted. An AP shall
transmit a Multi-TID BlockAck frame during a PSMP-DTT addressed to the STA for the data received from
that STA with the Ack Policy field set to PSMP Ack or for TIDs in a Multi-TID BlockAckReq frame received
from that STA for which a BlockAck frame (Compressed BlockAck or Multi-TID BlockAck) has not yet been
transmitted.
Data sent and received by a non-AP STA within a PSMP sequence may be contained in an A-MPDU that
contains MPDUs of multiple TIDs. Frames of differing TIDs may be transmitted in the same PSMP-DTT or
PSMP-UTT and are not subject to AC prioritization.
The subtype subfield of Data frames and the Ack Policy subfield of QoS Data frames transmitted during either
PSMP-DTT or PSMP-UTT periods are limited by the following rules:
— A QoS Data frame transmitted under an immediate or HT-immediate block ack agreement during
either a PSMP-DTT or a PSMP-UTT shall have one of the following Ack Policy values: PSMP Ack
or Block Ack.
— A QoS Data frame transmitted under an HT-delayed block ack agreement during either a PSMP-
DTT or a PSMP-UTT shall have the Ack Policy field set to Block Ack.
— A Data frame with the RA field containing an individual address transmitted during either a PSMP-
DTT or a PSMP-UTT and for which no block ack agreement exists shall be a QoS data subtype and
shall have the Ack Policy field set to No Ack.
— The Ack Policy field of a QoS Data frame transmitted during a PSMP sequence shall not be set to
either Normal Ack or Implicit Block Ack.
All TID values within a Multi-TID BlockAck frame or Multi-TID BlockAckReq frame shall identify a block
ack agreement that is HT-immediate. QoS Data frames transmitted with Ack Policy field equal to PSMP Ack
shall have a TID value that identifies a block ack agreement that is immediate or HT-immediate block ack.
NOTE—In this case, HT-immediate relates to the keeping of acknowledgment state for timely generation of a Multi-
TID BlockAck frame. It does not imply that there is any response mechanism for sending a Multi-TID BlockAck frame
after a SIFS. The timing of any response is determined by the PSMP schedule.
Acknowledgment for data transmitted under an immediate or HT-immediate block ack agreement may be
requested implicitly using PSMP Ack setting of the Ack Policy field in Data frames or explicitly with a Basic
BlockAckReq or Multi-TID BlockAckReq frame. An AP that transmits Data frames with the Ack Policy field
equal to PSMP Ack or that transmits a Basic BlockAckReq or Multi-TID BlockAckReq frame addressed to a
STA in a PSMP-DTT shall allocate sufficient time for the transmission of a Basic BlockAck frame or Multi-
TID BlockAck frame, respectively, in a PSMP-UTT allocated to that STA within the same PSMP sequence. A
STA that has received a PSMP frame and that receives a QoS Data frame with the Ack Policy field equal to
PSMP Ack or that receives a Basic BlockAckReq or Multi-TID BlockAckReq frame shall transmit a Basic
BlockAck frame or Multi-TID BlockAck frame, respectively, in the PSMP-UTT of the same PSMP sequence.
NOTE 1—If the STA does not receive the PSMP frame, it might still receive the downlink data, in which case it can
record the status of the data in its block ack buffer, but it cannot transmit a Multi-TID BlockAck frame.
1460
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 2—A Multi-TID BlockAck frame or Multi-TID BlockAckReq frame might contain any TID related to an HT-
immediate block ack agreement regardless of the contents of any prior transmission of Multi-TID BlockAck, Multi-TID
BlockAckReq, or QoS Data frames.
An AP that receives a QoS Data frame with the Ack Policy field equal to PSMP Ack during a PSMP-UTT
shall transmit a response that is a Basic BlockAck frame or Multi-TID BlockAck frame in the next PSMP-
DTT that it schedules for that STA, except if it has transmitted a BlockAck frame for such TIDs to the STA
outside the PSMP mechanism.
NOTE 1—The exception might occur if the non-AP STA transmits one or more BlockAckReq frames or QoS Data
frames with Ack Policy set to Implicit Block Ack outside the PSMP mechanism.
NOTE 2—An AP might receive a Multi-TID BlockAck frame in the PSMP-UTT of the current PSMP sequence. If the
Multi-TID BlockAck frame indicates lost frames or if the AP does not receive an expected Multi-TID BlockAck frame,
the AP might schedule and retransmit those frames in a PSMP sequence within the current PSMP burst or in the next SP.
A Multi-TID BlockAck frame shall include all of the TIDs for which data were received with Ack Policy field
equal to PSMP Ack and for the TIDs listed in any Multi-TID BlockAckReq frame received during the previous
PSMP-DTT (STA) or PSMP-UTT (AP). The originator may ignore the bitmap for TIDs in the Multi-TID
BlockAck frame for which the originator has not requested a Multi-TID BlockAck frame to be present either
implicitly (by the transmission of Data frames with the Ack Policy field set to PSMP Ack) or explicitly (by the
transmission of a Multi-TID BlockAckReq frame).
If a BlockAckReq frame for an HT-delayed block ack agreement is transmitted during a PSMP sequence, the
BAR Ack Policy subfield of the BlockAckReq frame shall be set to the value representing No
Acknowledgment.
10.29.2.8 PSMP group addressed transmission rules
10.29.2.8.1 Rules at the AP
This subclause defines rules that shall be followed by a PSMP-capable AP for the transmission of group
addressed Data and Management frames during a PSMP sequence.
Each separate group address for which frames are transmitted during a PSMP sequence shall have a single
STA_INFO record with STA_INFO Type set to 1 (group addressed) present in the PSMP frame and transmit
frames with the matching Address 1 field only during the PSMP-DTT indicated in this record.
The DA of the PSMP shall be set to the broadcast address, except if the PSMP contains only a single non-null
PSMP-DTT and this PSMP-DTT contains frames for a group address, in which case the DA of the PSMP
frame may be set to this group address.
NOTE—The transmission of a group addressed frame within a PSMP sequence does not change the rules regarding
when that frame can be transmitted. In other words, if there is a power-saving STA in the BSS, the group addressed
frame is transmitted following a DTIM beacon according to the rules in 11.2.3.
10.29.2.8.2 Rules at the STA
This subclause defines rules that shall be followed by a PSMP-capable STA for the reception of group
addressed frames during a PSMP sequence.
The STA shall be awake to receive during all PSMP-DTTs identified by a group addressed STA_INFO record
where the PSMP Group Address ID subfield matches the LSBs of any address within its
dot11GroupAddressesTable.
1461
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.29.3 Scheduled PSMP
A PSMP session exists while any periodic TS exists that was established by a TSPEC with the APSD field
equal to 0 and the Schedule field equal to 1 (representing Scheduled PSMP). The creation of a PSMP session is
described in 11.4.6.
While one or more PSMP sessions exist with the same SP, the AP shall periodically initiate a PSMP sequence
by transmitting a PSMP frame using the SP indicated to the STA in response to the received TSPEC. Under S-
PSMP rules, the AP shall not transmit a PSMP frame containing a STA_INFO record addressed to a STA
unless the transmission occurs within a SP of that STA. The PSMP-DTT and PSMP-UTT allocated to a STA
shall occur within a SP of that STA.
NOTE—An AP might simultaneously maintain multiple PSMP sessions with distinct SIs. The SIs of an AP’s PSMP
sessions are multiples of the SI granularity. An AP might combine the schedule of multiple PSMP sessions into a single
PSMP frame if the start times of the PSMP sessions coincide. For example, the schedule carried by a PSMP frame
related to a PSMP session at 20 ms and 30 ms SIs can be combined into a single PSMP frame once every 3 SIs of PSMP
session at 20 ms or once every 2 SIs of the PSMP session at 30 ms.
The start time of a PSMP sequence should be aligned with the start time of the SP.
10.29.4 Unscheduled PSMP
An HT AP may start an unscheduled PSMP sequence that includes STAs that are PSMP-capable at any time
that these STAs are awake.
NOTE—A STA in power save is awake as defined in 11.2.3.5 (U-APSD, S-APSD), as defined in 11.2.3.8 (PS-Poll
frame), or during a DTIM period.
U-APSD STAs can signal the queue size or TXOP duration required to transmit its queued data to the AP in the
QoS Control field of the trigger frame. This information might be used by the AP to estimate the duration of the
PSMP-UTT so that the STA can transmit the queued data.
All of the behavior defined in 11.2.3.5, 11.2.3.6, and 11.2.3.10 applies to unscheduled PSMP with the
following exceptions:
— PSMP allows the STA to sleep during PSMP-DTTs and PSMP-UTTs in which it has no interest.
— In addition to the EOSP mechanism, the AP may indicate the end of a SP through the transmission
of a PSMP frame with the More PSMP field set to 0 or by transmission of a CF-End frame when a
PSMP frame was expected.
10.30 Sounding PPDUs
The behavior described in this subclause is specific to the use of the HT variant HT Control field.
A sounding PPDU is a PPDU for which the SOUNDING parameter of the corresponding RXVECTOR or
TXVECTOR has the value SOUNDING. Sounding PPDUs are transmitted by STAs to enable the receiving
STAs to estimate the channel between the transmitting STA and the receiving STA.
A STA transmits sounding PPDUs when it operates in the following roles:
— MFB requester (see 10.31.2)
— HT beamformee responding to a training request, calibration initiator, or responder involved in
implicit transmit beamforming (see 10.32.2.2, 10.32.2.3, and 10.32.2.4)
— HT beamformer involved in explicit transmit beamforming (see 10.32.3)
— ASEL transmitter and ASEL sounding-capable transmitter involved in ASEL (see 10.33.2)
1462
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA receives sounding PPDUs when it operates in the following roles:
— MFB responder (see 10.31.2)
— HT beamformer sending a training request, calibration initiator, or responder involved in implicit
transmit beamforming (see 10.32.2.2, 10.32.2.3, and 10.32.2.4)
— HT beamformee involved in explicit transmit beamforming (see 10.32.3)
— Transmit ASEL responder and ASEL receiver involved in ASEL (see 10.33.2)
When transmitting a sounding PPDU, the transmitting STA follows the rules stated below to determine the
maximum number of space-time streams for which channel coefficients can be simultaneously estimated:
— When transmitting a sounding PPDU that
— Contains a +HTC frame with the MRQ subfield equal to 1, or
— Is sent as a response to a +HTC frame with the TRQ field equal to 1, or
— Is sent during a calibration sounding exchange, or
— Is sent by an HT beamformer involved in explicit transmit beamforming, or
— Is sent in transmit or receive ASEL exchanges,
— Then:
— If the sounding PPDU is not an NDP sounding PPDU, the NUM_EXTEN_SS parameter in the
TXVECTOR shall not be set to a value greater than the limit indicated by the Channel
Estimation Capability subfield in the Transmit Beamforming Capabilities field transmitted by
the STA that is the intended receiver of the sounding PPDU.
NOTE—The maximum number of space-time streams for which channel coefficients can be
simultaneously estimated using the HT-LTFs corresponding to the data portion of the packet is limited by
the Rx MCS Bitmask subfield of the Supported MCS Set field and by the Rx STBC subfield of the HT
Capability Information field. Both fields are part of the HT Capabilities element.
— If the sounding PPDU is an NDP, the number of spatial streams corresponding to the MCS
parameter of the TXVECTOR shall not exceed the limit indicated by the Channel Estimation
Capability subfield in the Transmit Beamforming Capabilities field transmitted from the STA
that is the intended receiver of the NDP (see 10.34.2 for details on setting the MCS parameter).
If a STA sets the Receive Staggered Sounding Capable bit in the Transmit Beamforming Capabilities field to 1,
the STA shall set the Channel Estimation Capability bit in the Transmit Beamforming Capabilities field to
indicate a dimension that is greater than or equal to the dimension indicated by the Supported MCS Set field of
the HT Capabilities element.
10.31 Link adaptation
10.31.1 Introduction
To fully exploit MIMO channel variations and transmit beamforming on a MIMO link, a STA can request that
another STA provide MIMO channel sounding and MFB.
Link adaptation may be supported by immediate response or delayed response as described below. Unsolicited
MFB is also possible.
— Immediate: An immediate response occurs when the MFB responder transmits the response in the
TXOP obtained by the TXOP holder. This approach allows the MFB requester to obtain the benefit
of link adaptation within the same TXOP.
— Delayed: A delayed response occurs when the MFB responder transmits the response in the role of a
TXOP holder in response to an MRQ in a previous TXOP obtained by the MFB requester.
1463
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Unsolicited: An unsolicited response occurs when a STA sends MFB independent of any preceding
MRQ.
10.31.2 Link adaptation using the HT variant HT Control field
The behavior described in this subclause is specific to the HT variant HT Control field.
A STA that supports link adaptation using the HT Control field shall set the MCS Feedback field of the
HT Extended Capabilities field to Unsolicited or Both, depending on its specific MFB capability, in HT
Capabilities elements that it transmits. A STA shall not send an MRQ to a STA that has not set the MCS
Feedback subfield to Both in the HT Extended Capabilities field of the HT Capabilities element. A STA whose
MCS Feedback field of the HT Extended capabilities field of the HT Capabilities element is equal to
Unsolicited or Both may transmit unsolicited MFB in any frame that contains a +HTC field.
The MFB requester may set the MRQ subfield to 1 in the MAI subfield of the HT Control field of a +HTC
frame to request a STA to provide MFB. In each MRQ, the MFB requester shall set the MSI subfield in the
MAI subfield to a value in the range 0 to 6. How the MFB requester chooses the MSI value is implementation
dependent.
The appearance of more than one instance of an HT Control field with the MRQ subfield equal to 1 within a
single PPDU shall be interpreted by the receiver as a single request for MFB.
An MFB requester shall transmit +HTC frames with the MRQ subfield equal to 1 in one of the following ways:
— Within a sounding PPDU, or
— With the HT NDP Announcement subfield in the +HTC frame set to 1 and following the +HTC
frame by an NDP transmission
The number of HT-LTFs sent in the sounding PPDU or in the NDP is determined by the total number of spatial
dimensions to be sounded, including any extra spatial dimensions beyond those used by the data portion of the
frame.
An MFB-capable STA (identified by the MCS Feedback field in the Extended HT Capability Information
field equal to 3) shall support the following:
— MFB estimate computation and feedback on the receipt of MRQ (MRQ=1 in +HTC) in a sounding
PPDU for which the RXVECTOR NUM_EXTEN_SS parameter contains 0 in the
PHY-RXSTART.indication primitive.
— MFB estimate computation and feedback on the receipt of MRQ (MRQ=1 in +HTC) in a staggered
sounding PPDU if this STA declares support for receive staggered sounding by setting the Receive
Staggered Sounding Capable subfield of the Transmit Beamforming Capabilities field to 1.
— MFB estimate computation and feedback on the receipt of NDP (see 10.34) if this STA declares
support for receiving NDP sounding by setting the Receive NDP Capable subfield of the Transmit
Beamforming Capabilities field to 1. The MFB requester shall set the MRQ subfield to 1 in the
frame where the HT NDP Announcement subfield is equal to 1.
On receipt of a +HTC frame with the MRQ subfield equal to 1, an MFB responder initiates computation of the
MCS estimate based on the associated sounding PPDU and labels the result of this computation with the MSI
value. The MFB responder includes the received MSI value in the MFSI field of the corresponding response
frame. In the case of a delayed response, this use of MSI and MFSI fields allows the MFB requester to correlate
the MFB with the related MRQ.
1464
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The responder may send a response frame with any of the following combinations of MFB and MFSI:
— MFB = 127, MFSI = 7: no information is provided for the immediately preceding request or for any
other pending request. This combination is used when the responder is required to include an HT
Control field due to other protocols that use this field (i.e., the reverse direction protocol) and when
no MFB is available. It has no effect on the status of any pending MRQ.
— MFB = 127, MFSI in the range 0 to 6: the responder is not now providing, and will never provide,
feedback for the request that had the MSI value that matches the MFSI value.
— MFB in the range 0 to 126, MFSI in the range 0 to 6: the responder is providing feedback for the
request that had the MSI value that matches the MFSI value.
— MFB in the range 0 to 126, MFSI = 7: the responder is providing unsolicited feedback.
Hardware and buffer capability may limit the number of MCS estimate computations that a MFB responder is
capable of computing simultaneously. When a new MRQ is received either from a different MFB requester or
from the same MFB requester with a different MSI value, and the MFB responder is not able to complete the
computation for MRQ, the MFB responder may either discard the new request or may abandon an existing
request and initiate an MCS estimate computation for the new MRQ.
An MFB responder that discards or abandons the computation for an MRQ should indicate this action to the
MFB requester by setting the MFB to the value 127 in the next transmission of a frame addressed to the MFB
requester that includes the HT Control field. The value of the MFSI is set to the MSI value of the sounding
frame for which the computation was abandoned.
When computing the MCS estimate for an MFB requester whose Tx MCS Set Defined field is equal to 1, the
number of spatial streams corresponding to the recommended MCS shall not exceed the limit indicated by the
Tx Maximum Number Spatial Streams Supported field. The MFB responder shall not recommend an MCS
corresponding to UEQM unless the MFB requester supports such modulation, as indicated by the Tx Unequal
Modulation Supported bit in the Supported MCS Set field.
If the MFB is in the same PPDU as a Noncompressed Beamforming frame or a Compressed Beamforming
frame, the MFB responder should estimate the recommended MCS under the assumption that the MFB
requester uses the steering matrices contained therein.
After the MCS estimate computation is completed, the MFB responder should include the MFB in the MFB
field in the next transmission of a frame addressed to the MFB requester that includes an HT Control field.
When the MFB requester sets the MRQ subfield to 1 and sets the MSI subfield to a value that matches the MSI
subfield value of a previous request for which the responder has not yet provided feedback, the responder shall
discard or abandon the computation for the MRQ that corresponds to the previous use of that MSI subfield
value.
A STA may respond immediately to a current request for MFB with a frame containing an MFSI field value
and MFB field value that correspond to a request that precedes the current request.
Bidirectional request/responses are supported. A STA may act as both the MFB requester for one direction of a
duplex link and the MFB responder for the other direction and include both MRQ and MFB in the same HT
Data frame.
If an HT beamformer transmits a PPDU with the TXVECTOR EXPANSION_MAT_TYPE set to either
COMPRESSED_SV or NON_COMPRESSED_SV, it should use the recommended MCS associated with
those matrices reported in a Noncompressed Beamforming frame or a Compressed Beamforming frame.
1465
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.31.3 Link adaptation using the VHT variant HT Control field
This subclause applies to frame exchange sequences that include PPDUs containing an HT variant HT Control
field.
A STA that supports VHT link adaptation using the VHT variant HT Control field shall set the VHT Link
Adaptation Capable subfield in the VHT Capabilities Information field in the VHT Capabilities element to
Unsolicited or Both, depending on its specific link adaptation feedback capability. A STA shall not send an
MRQ to a STA that has not set the VHT Link Adaptation Capable subfield to Both in the VHT Capabilities
Information field of the VHT Capabilities element. A STA whose VHT Link Adaptation Capable subfield of
the VHT Capabilities Information field of the VHT Capabilities element is either set to Unsolicited or Both
may transmit unsolicited MFB in any frame that contains a VHT variant HT Control field.
The MFB requester may set the MRQ field to 1 in the VHT variant HT Control field of a frame to request a
STA to provide link adaptation feedback. In each request the MFB requester shall set the MSI/STBC field to a
value in the ranges 0 to 6, 0 to 2, or 0 to 3, depending on the settings in the Unsolicited MFB and STBC fields
(see 9.2.4.6.3). The choice of MSI value is implementation dependent.
The appearance of more than one instance of a VHT variant HT Control field with the MRQ field equal to 1
within a single PPDU shall be interpreted by the receiver as a single request for link adaptation feedback.
An MFB responder that has set the VHT Link Adaptation Capable subfield to Both in the VHT Capabilities
Information field of the VHT Capabilities element shall support both of the following:
— Computation and feedback of the MFB estimate on the receipt of an MFB request (MRQ equal to 1
in the VHT variant HT Control field) in a PPDU that is not a VHT NDP Announcement frame
— Computation and feedback of the MFB estimate on the receipt of an MFB request (MRQ equal to 1
in VHT variant HT Control field) in a VHT NDP Announcement frame and the receipt of VHT
NDPs (see 10.34) if this STA set the SU Beamformee Capable subfield of the VHT Capabilities
Information field of the VHT Capabilities element to 1
On receipt of a VHT variant HT Control field with the MRQ field equal to 1, an MFB responder computes the
VHT-MCS, NUM_STS, and SNR estimates based on the PPDU carrying the MRQ or, in the case of a VHT
NDP Announcement frame carrying the MRQ, based on the subsequent VHT NDP. The MFB responder labels
the result of this computation with the MSI value from the VHT variant HT Control field in the received frame
carrying the MRQ. The MFB responder may include the received MSI value in the MFSI field of the
corresponding response frame. In the case of a delayed response, this allows the MFB requester to associate the
MFB with the soliciting MRQ.
An MFB responder that sends a solicited MFB shall set the Unsolicited MFB subfield in VHT variant HT
Control field to 0.
The MFB responder may send a solicited response frame with any of the following combinations of VHT-
MCS, NUM_STS, and MFSI:
— VHT-MCS = 15, NUM_STS = 7 in the MFB subfield, MFSI = 7: no information is provided for the
immediately preceding request or for any other pending request. This combination is used when the
responder is required to include a VHT variant HT Control field due to other protocols that use this
field (e.g., the Reverse Direction Protocol) and when no MFB is available. It has no effect on the
status of any pending MRQ.
— VHT-MCS = 15, NUM_STS = 7 in the MFB subfield, MFSI in the range 0 to 6: the responder is not
now providing, and will never provide, feedback for the request that had the MSI value that matches
the MFSI value.
— VHT-MCS = valid value, NUM_STS = valid value in the MFB subfield, MFSI in the range 0 to 6:
the responder is providing feedback for the request that had the MSI value that matches the MFSI
value.
1466
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An MFB responder that discards or abandons the MFB estimates computed in response to an MRQ may
indicate that it has done so by setting the VHT-MCS to 15 and NUM_STS to 7 in the MFB subfield in the next
frame addressed to the MFB requester that includes the VHT variant HT Control field. The value of the MFSI
is set to the value of the MSI/STBC subfield of the frame that contains an MRQ for which the computation was
abandoned, regardless of whether the MSI/STBC subfield contains an MSI or a Compressed MSI and STBC
Indication subfields.
The STA receiving MFB may use the received MFB to compute the appropriate VHT-MCS, SNR, and
NUM_STS.
A STA sending unsolicited MFB using the VHT variant HT Control field shall set the Unsolicited MFB
subfield to 1.
Unsolicited VHT-MCS, NUM_STS, BW, and SNR estimates reported in the MFB subfield of a VHT variant
HT Control field sent by a STA are computed based on the most recent PPDU received by the STA that
matches the description indicated by the GID-L, GID-H, Coding Type, STBC Indication, and FB Tx Type
fields in the same VHT variant HT Control field.
In an unsolicited MFB response the GID-L, GID-H, Coding Type, STBC Indication, FB Tx Type, and BW
fields are set according to the RXVECTOR parameters of the received PPDU from which the VHT-MCS,
SNR, BW, and NUM_STS are estimated, as follows:
— If the VHT-MCS, SNR, BW, and NUM_STS are estimated from a VHT MU PPDU, then the GID-L
field is set to the 3 least significant bits and the GID-H field to the 3 most significant bits of the
parameter GROUP_ID.
— If the VHT-MCS, SNR, BW, and NUM_STS are estimated from an SU PPDU, then the GID-L field
and GID-H field are set to all 1s.
— The Coding Type field is set to 0 if the parameter FEC_CODING is equal to BCC_CODING and set
to 1 if equal to LDPC_CODING.
— The STBC Indication field is set to 1 if the parameter STBC is equal to 1 and set to 0 if the STBC
parameter is equal to 0.
— The FB TX Type field is set to 1 if the parameter BEAMFORMED is equal to 1 and set to 0 if equal
to 0.
— The BW field shall indicate a bandwidth less than or equal to the bandwidth indicated by the
parameter CH_BANDWIDTH.
In an MFB response solicited by an MRQ that was not carried in a VHT NDP Announcement frame, the MFB
is computed based on RXVECTOR parameters CH_BANDWIDTH, GROUP_ID, NUM_STS,
FEC_CODING, BEAMFORMED, and STBC of the received PPDU that carried the MRQ and might
additionally be based on other factors that are not part of the RXVECTOR. The NUM_STS subfield of the
MFB subfield of VHT variant HT Control field shall be set to an equal or smaller value than the RXVECTOR
parameter NUM_STS of the received PPDU that triggered the MRQ.
If the MFB is in the same MPDU as a VHT Compressed Beamforming frame, the MFB responder shall
estimate the recommended MFB under the assumption that the beamformer will use the steering matrices
contained therein for performing an SU beamformed transmission. In this case the value of the NUM_STS
field in the MFB subfield of the VHT variant HT Control field shall be the same as the value of the Nc Index
field in the VHT MIMO Control field of the VHT Compressed Beamforming frame and, if the MFB is
unsolicited, the Coding Type shall be set to BCC and the FB Tx Type shall be set to 0. Additionally, MFB
estimate shall be based on the bandwidth indicated by the Channel Width subfield of the VHT MIMO Control
field of the VHT Compressed Beamforming frame. In this case the SNR and BW subfields are reserved and set
to 0.
1467
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If an unsolicited MFB is not in the same MPDU as a VHT Compressed Beamforming frame, the NUM_STS
subfield of the MFB subfield of the VHT variant HT Control field shall be set to an equal or smaller value than
the RXVECTOR parameter NUM_STS of the received PPDU from which the MFB parameters are estimated.
If the MFB requester sends the MRQ in a VHT NDP Announcement frame, then the MFB responder shall
include the corresponding MFB in (all of) the VHT Compressed Beamforming frame(s) sent in response to the
same VHT NDP Announcement frame and NDP sequence.
If the value of the NUM_STS subfield of the MFB field (solicited or unsolicited) is a smaller value than the
RXVECTOR parameter NUM_STS of the received PPDU on which the MFB is based, the MFB responder
shall estimate the recommended VHT-MCS under the assumption that the MFB requester will transmit the first
NSTS space-time streams in the corresponding PPDU carrying MRQ. If the MFB is based on an SU PPDU the
first NSTS space-time streams correspond to columns 1, ..., NSTS of the spatial mapping matrix Q. If the MFB is
based on a VHT MU PPDU, then for the user u the first NSTS space-time streams correspond to columns
Mu+1, ..., Mu+NSTS,u of the spatial mapping matrix Q (Mu is defined in 21.3.10.11.1). The VHT-MCS
recommendation shall be a value from the peer’s Tx Supported VHT-MCS and NSS Set (see 10.7.12.2).
A VHT NDP Announcement frame that contains multiple STA Info fields and that contains a VHT format of
HT Control field with the MRQ subfield equal to 1 solicits an MFB response from all of the STAs listed in the
STA Info fields.
When the MFB requester sets the MRQ subfield to 1 and sets the MSI/STBC subfield to a value that matches
the MSI/STBC subfield value of a previous request for which the responder has not yet provided feedback, the
responder shall discard or abandon the computation for the MRQ that corresponds to the previous use of that
MSI/STBC subfield value and start a new computation based on the new request.
A STA may respond immediately to a current request for MFB with a frame containing an MFSI field value
and an MFB field value that correspond to a request that precedes the current request.
Bidirectional request/responses are supported. A STA may act as both the MFB requester for one direction of a
duplex link and the MFB responder for the other direction and include both an MRQ and an MFB in the same
VHT variant HT Control field.
10.32 Transmit beamforming
10.32.1 HT steering matrix calculations
In order for an HT beamformer to calculate an appropriate steering matrix for transmit spatial processing when
transmitting to a specific HT beamformee, the HT beamformer needs to have an accurate estimate of the
channel over which it is transmitting. Two methods of calculation are defined as follows:
— Implicit feedback: When using implicit feedback, the beamformer receives long training symbols
transmitted by the HT beamformee, which allow the MIMO channel between the HT beamformee
and HT beamformer to be estimated. If the channel is reciprocal, the HT beamformer can use the
training symbols that it receives from the HT beamformee to make a channel estimate suitable for
computing the transmit steering matrix. Generally, calibrated radios in MIMO systems can improve
reciprocity. See 10.32.2.
— Explicit feedback: When using explicit feedback, the HT beamformee makes a direct estimate of the
channel from training symbols sent to the HT beamformee by the HT beamformer. The HT
beamformee may prepare CSI or steering feedback based on an observation of these training
symbols. The HT beamformee quantizes the feedback and sends it to the HT beamformer. The HT
beamformer can use the feedback as the basis for determining transmit steering vectors. See 10.32.3.
1468
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An HT STA shall not transmit a PPDU with the TXVECTOR EXPANSION_MAT parameter present if
dot11BeamFormingOptionActivated is false.
10.32.2 HT transmit beamforming with implicit feedback
10.32.2.1 General
The procedures for HT transmit beamforming with implicit feedback use only HT and non-HT PPDUs, and the
HT Control field, when present, is the HT variant HT Control field.
Transmit beamforming with implicit feedback can operate in a unidirectional or bidirectional manner. In
unidirectional implicit transmit beamforming, only the HT beamformer sends beamformed transmissions. In
bidirectional implicit transmit beamforming, both STAs send beamformed transmissions, i.e., a STA may act
as both HT beamformer and HT beamformee.
Calibration of receive/transmit chains should be done to improve performance of transmit beamforming using
implicit feedback. Over-the-air calibration is described in 10.32.2.4. For implicit transmit beamforming, only
the HT beamformer, which is sending the beamformed transmissions, needs to be calibrated.
A STA that advertises itself as being capable of being an HT beamformer and/or HT beamformee using
implicit feedback shall support the requirements in Table 10-15.
Table 10-15—STA type requirements for transmit beamforming with implicit feedback
STA capability Required support
Beamformer Shall set the Implicit Transmit Beamforming Capable subfield to 1 of the
Transmit Beamforming Capability field of the HT Capabilities element in HT
Capabilities elements that it transmits.
Shall set the Implicit Transmit Beamforming Receiving Capable subfield to 1
of the Transmit Beamforming Capability field of the HT Capabilities element.
Shall be capable of receiving a sounding PPDU for which the SOUNDING
parameter is SOUNDING and the NUM_EXTEN_SS is equal to 0 in the
RXVECTOR in the PHY-RXSTART.indication primitive, independently of
the values of the Receive Staggered Sounding Capable and Receive NDP
Capable subfields.
Shall set the Calibration subfield to 3 of the Transmit Beamforming Capability
field of the HT Capabilities element to advertise full calibration support.
Beamformee Shall set the Implicit Transmit Beamforming Receiving Capable subfield to 1
of the Transmit Beamforming Capability field of the HT Capabilities element
in HT Capabilities elements that it transmits.
Shall be capable of setting the SOUNDING parameter to SOUNDING and the
NUM_EXTEN_SS to 0 in the TXVECTOR in the PHY-TXSTART.request
primitive when transmitting a sounding PPDU, as a response to TRQ=1,
independently of the values of the Transmit Staggered Sounding Capable and
Transmit NDP Capable subfields.
A STA that performs one of the roles related to transmit beamforming with implicit feedback shall support the
associated capabilities shown in Table 10-16.
1469
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-16—Transmit beamforming support required with implicit feedback
Role Required support
HT beamformee: Shall transmit sounding PPDUs as a response to TRQ=1.
A receiver of transmit
beamformed PPDUs
Beamformer: Can receive sounding PPDUs.
A transmitter of Can compute steering matrices from MIMO channel estimates obtained from long
beamformed PPDUs training symbols in sounding PPDUs received from the HT beamformee.
A responder in a Can receive and transmit sounding PPDUs.
calibration exchange Can respond with a CSI frame that contains channel measurement information
obtained during reception of a sounding PPDU.
An initiator in a Can receive and transmit sounding PPDUs.
calibration exchange Can receive a CSI frame sent by a calibration responder.
When an HT beamformee transmits a sounding PPDU, the SOUNDING parameter in the TXVECTOR in the
PHY-TXSTART.request primitive shall be set to SOUNDING. If the HT beamformee is capable of implicit
transmit beamforming and the HT beamformer is capable of receiving implicit transmit beamforming, the
sounding PPDU from the HT beamformee may be steered.
A PPDU containing one or more +HTC MPDUs in which the TRQ field is equal to 1 shall not be sent to a STA
that sets the Implicit Transmit Beamforming Receiving Capable subfield of the Transmit Beamforming field of
the HT Capabilities element to 0.
If a PPDU containing one or more +HTC MPDUs in which the TRQ field is equal to 1 requires an immediate
response, either the response from the HT beamformee shall be included in a sounding PPDU, or the HT NDP
Announcement subfield of the HT Control field shall be set to 1 and the PPDU shall be followed by an NDP. If
the PPDU in which the TRQ field is equal to 1 does not require an immediate response, either the HT
beamformee shall transmit a sounding PPDU in the next TXOP obtained by the HT beamformee, or the HT
beamformee shall transmit a PPDU in the next TXOP obtained by the HT beamformee in which the HT NDP
Announcement subfield of the HT Control field is set to 1 and that PPDU shall be followed by an NDP. The
use of NDP as a sounding PPDU is described in 10.34.
NOTE—A STA that acts as an HT beamformer using implicit feedback expects to receive a sounding PPDU in response
to a training request. The STA can compute steering matrices from the channel estimates obtained from the received
sounding PPDU.
At the end of the TXOP the final PPDU from the HT beamformer shall not have the TRQ field set to 1 in a
frame that requests an immediate response if there is not enough time left in the TXOP for the HT beamformee
to transmit the longest valid sounding PPDU with its response.
10.32.2.2 Unidirectional implicit transmit beamforming
Figure 10-45 shows an example of a PPDU exchange used in unidirectional implicit transmit beamforming
using the Clause 19 PHY. In this example, sounding PPDUs are used that carry MPDUs (i.e., an example of
implicit beamforming using NDPs is not shown here.) STA A is the beamformer that initiates the PPDU
exchange, and STA B is the beamformee.
1470
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA A computes Tx
Unsteered steering Steered
HT-LTF HT-LTF
Unsteered Steered HT Data
STA A TRQ Data/TRQ ...
Unsteered Unsteered
HT-LTF Unsteered HT-LTF Unsteered
Sounding PPDU Sounding PPDU
STA B
Figure 10-45—Example PPDU exchange for unidirectional implicit transmit beamforming
The PPDU exchange can be summarized as follows:
a) STA A initiates the frame exchange sequence by sending an unsteered PPDU to STA B. The PPDU
includes a training request (TRQ= 1) in a +HTC MPDU.
b) STA B sends a sounding PPDU in response to the training request from STA A.
c) On receiving the sounding PPDU, STA A uses the resulting channel estimate to compute steering
matrices and uses these matrices to send a steered PPDU back to STA B.
d) The steered PPDU transmitted in step c) and subsequent steered PPDUs transmitted by STA A may
include training requests (TRQ=1) in a +HTC MPDU. In response to each training request, STA B
returns a sounding PPDU to STA A, which enables STA A to update its steering vectors. If the
steering vectors resulting from step c) or subsequent sounding PPDUs are deemed stale due to delay,
the sequence may be restarted by returning to step a).
Step d) in the above PPDU exchange represents steady-state unidirectional transmit beamforming operation.
During the PPDU exchange neither the receiving nor the transmitting STA should switch antennas.
10.32.2.3 Bidirectional implicit transmit beamforming
Figure 10-46 shows an example of a PPDU exchange used in bidirectional implicit transmit beamforming,
using the Clause 19 PHY. In this example, sounding PPDUs are used that carry MPDUs. STA A initiates the
frame exchange, and STA A and STA B alternate in the roles of HT beamformer and HT beamformee.
The PPDU exchange can be summarized as follows:
a) STA A initiates the frame exchange sequence by sending an unsteered PPDU to STA B. The PPDU
includes a training request (TRQ= 1) in a +HTC MPDU.
b) STA B sends a sounding PPDU in response to the training request. In addition, this PPDU includes a
training request in a +HTC MPDU to enable implicit transmit beamforming in the RD.
c) On receiving the sounding PPDU, STA A uses the resulting channel estimate to compute steering
matrices and uses these matrices to send a steered PPDU back to STA B. This steered PPDU is also
a sounding PPDU in response to the training request from STA B.
NOTE—Steering matrices with nonorthonormal columns should not be used in transmitting sounding PPDUs
for implicit feedback. In general, bidirectional implicit beamforming will not function as described here when
the steering matrices have nonorthonormal columns. See 19.3.12.2.
d) On receiving the sounding PPDU, STA B uses the resulting channel estimate to compute steering
matrices and uses these matrices to send a steered PPDU back to STA A. The steered PPDU
transmitted in step c) and subsequent steered PPDUs transmitted by STA A may include training
requests in HTC. In response to each training request, STA B returns a sounding PPDU to STA A,
1471
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
which enables STA A to update its steering vectors. If the steering vectors resulting from step c) or
subsequent sounding PPDUs are deemed stale due to delay, the sequence may be restarted by
returning to step a).
e) The steered PPDU transmitted in step d) and subsequent steered PPDUs transmitted by STA B may
include training requests in HTC. In response to each training request, STA A returns a sounding
PPDU to STA B, which enables STA B to update its steering vectors. If the steering vectors
resulting from step d) or subsequent sounding PPDUs are deemed stale due to delay, the sequence
may be restarted by returning to step a).
Steps d) and e) in the above PPDU exchange represent steady-state bidirectional transmit beamforming
operation.
During the PPDU exchange neither the receiving nor the transmitting STA should switch antennas.
NOTE—The TRQ protocol used with the beamforming training process is not sufficient to permit STA B to transmit
Data frames in the RD. In the example shown in Figure 10-46, STA A would additionally have to follow the rules of the
reverse direction protocol (see 10.28).
STA A computes Tx
steering
Steered
Unsteered HT-LTF
HT-LTF
Steered HT Data
Unsteered Sounding PPDU
[TRQ]/Data …………………...
STA A TRQ
Unsteered Steered
HT-LTF Unsteered HT Data HT-LTF Steered HT Data
Sounding PPDU Sounding PPDU
STA B TRQ/Data [TRQ]/Data
STA B computes
Tx steering
Figure 10-46—Example PPDU exchange for bidirectional implicit transmit beamforming
10.32.2.4 Calibration
10.32.2.4.1 Introduction
Differences between transmit and receive chains in a STA degrade the inherent reciprocity of the over-the-air
time division duplex channel and cause degradation of the performance of implicit beamforming. Calibration
acts to remove or reduce differences between transmit and receive chains and enforce reciprocity in the
observed baseband-to-baseband channels between two STAs.
A STA acting as an HT beamformer should be calibrated to maximize performance. A STA acting only as an
HT beamformee does not need to be calibrated. In order to perform calibration, the STA follows the procedure
described below.
1472
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The calibration procedure involves the computation of correction matrices that cause the observed channel
matrices in the two directions of the link to be transposes of each other and thus renders the resultant channel
reciprocal. See 19.3.12.2 for a more detailed description. If it is able to do so, a STA should calibrate upon
association.
NOTE—STAs with two or more transmit chains should be calibrated in order to engage in implicit transmit
beamforming. STAs with any number of RF chains, including those with a single RF chain, can participate in a
calibration exchange as a calibration responder.
10.32.2.4.2 Calibration capabilities
A STA that sets the Implicit Transmit Beamforming Capable subfield of the Transmit Beamforming
Capabilities field to 1 shall support calibration and shall set the Calibration subfield of the Transmit
Beamforming Capabilities field to 3 (indicating full support of calibration) in HT Capabilities elements that it
transmits. A STA that does not set the Implicit Transmit Beamforming Capable subfield of the Transmit
Beamforming Capabilities field to 1 may support calibration and shall set the Calibration subfield of the
Transmit Beamforming Capabilities field to the value that indicates its calibration capability in the Transmit
Beamforming Capabilities field in HT Capabilities elements that it transmits (see Table 9-166), when the
Transmit Beamforming Capabilities field exists.
A STA that is capable of initiating calibration (the Calibration subfield of the Transmit Beamforming
Capabilities field is equal to 3) shall set the CSI Max Number of Rows Beamformer Supported subfield to an
appropriate value, even if the STA sets the Explicit Transmit Beamforming CSI Feedback subfield to the
value 0.
In order to support calibration, a STA that advertises that it is capable of responding to a calibration request
shall be capable of transmitting a CSI frame in which the value of the Grouping subfield of the MIMO Control
field is 0 (no grouping) and the Coefficients Size subfield of the MIMO Control field is 3 (Nb = 8 bits) in
response to a CSI feedback request indicated by the CSI/Steering subfield of the HT Control field equal to 1
and the Calibration Position subfield of the HT Control field equal to 3, independently of the advertised values
of the Explicit Transmit Beamforming CSI Feedback subfield in the Transmit Beamforming Capabilities field
in the HT Capabilities element. A STA that advertises that it is capable of initiating a calibration request shall
be capable of receiving a CSI frame in which the value of the Grouping subfield of the MIMO Control field is
equal to 0 (no grouping) and the Coefficients Size subfield of the MIMO Control field is equal to 3
(Nb = 8 bits) as a response to CSI feedback request indicated by the CSI/Steering subfield of the HT Control
field equal to 1 with the Calibration Position subfield equal to 3, independently of the advertised values of the
Explicit CSI Transmit Beamforming Capable subfield in the Transmit Beamforming Capabilities field in the
HT Capabilities element.
A STA may initiate a calibration training frame exchange sequence with another STA if that STA supports
calibration. A STA shall not initiate a calibration training frame exchange with another STA if that STA does
not support calibration.
If the Receive NDP Capable field is equal to 1, the value of the Calibration field is equal to 1 or 3, and the
device supports transmitting sounding PPDUs for which two or more channel dimensions can be estimated
(two or more columns of the MIMO channel matrix), then transmission of NDPs shall be supported (and the
Transmit NDP Capable bit shall be set to 1).
10.32.2.4.3 Sounding exchange for calibration
Figure 10-47 illustrates the calibration PPDU exchange using sounding PPDUs that contain an MPDU.
1473
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PPDU Type: Sounding
Frame Type : QoS Null
Frame Type: QoS Null (Data)
Ack Policy : Normal
Ack Policy : Normal Ack
+ HTC : TRQ
+HTC CSI Feedback Request
Cal Position 1: Cal Position 3:
STA A Cal Start Sound Complete
Ack
PPDU Type: Sounding
Frame Type: Ack Frame Type: Management Action
+ HTC : TRQ +HTC
Cal Position 2:
STA B Cal Sound
Ack CSI
Step 1 Step 2
Figure 10-47—Calibration procedure with sounding PPDU containing an MPDU
The calibration procedure begins with a calibration sounding PPDU exchange sequence shown as Step 1 in
Figure 10-47. The Calibration Sequence subfield in the HT Control field shall be incremented each time a new
calibration procedure is started.
STA A (the calibration initiator) shall transmit a Calibration Start frame (Calibration Position subfield set to 1)
with the TRQ field in the HT Control field set to 1. This frame initiates a calibration procedure. It shall be a
QoS Null frame with the Ack Policy field set to Normal Ack.
In response, STA B (the calibration responder) shall transmit a Calibration Sounding Response frame
(Calibration Position subfield set to 2), a SIFS after the end of the Calibration Start frame, using a sounding
PPDU. This step allows STA A to estimate the MIMO channel from STA B to STA A. In the Calibration
Sounding Response frame, the Calibration Sequence subfield in HT Control field shall be set to the same value
that is indicated in the Calibration Start frame. The Calibration Sounding Response frame shall have a frame
type of Ack+HTC, and the TRQ field in the HT Control field in this frame shall be set to 1.
In response, STA A shall transmit a Calibration Sounding Complete frame (Calibration Position subfield set
to 3) that contains the CSI/Steering subfield of the HT Control field set to 1, a SIFS after the end of the
Calibration Sounding Response frame, using a sounding PPDU. This step allows STA B to estimate the MIMO
channel from STA A to STA B. In this Calibration Sounding Complete frame, the Calibration Sequence
subfield in the HT Control field shall be set to the same value that is indicated in the Calibration Sounding
Response frame. The Calibration Sounding Complete frame shall be a QoS Null+HTC with the Ack Policy
field set to Normal Ack.
A frame in which the Calibration Position subfield is equal to 2 or 3 shall be transmitted in a sounding PPDU (a
PPDU for which the SOUNDING parameter is set to SOUNDING). The number of Long Training fields
(LTFs) used to obtain MIMO channel estimation that are sent in the sounding PPDU shall be determined by the
number of transmit chains (NTX) used in sending these LTFs at the STA transmitting the sounding PPDU. The
transmit chains used at the calibration initiator are those for which calibration is required.
The calibration responder may train up to maximum available transmit chains to maximize the quality of the
resulting calibration, although the number of space-time streams for data symbols shall be determined by the
rule described in 10.7.
When transmitting a sounding PPDU during Step 1 of a calibration procedure, if the Receive Staggered
Capability subfield in the Transmit Beamforming Capability field of the HT Capabilities element transmitted
by the intended receiver is 0, then,
1474
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— If the sounding PPDU is not an NDP, the number of antennas used by the sender shall be less than or
equal to the maximum number of space-time streams indicated by the Rx MCS Bitmask subfield of
the Supported MCS Set field and the Rx STBC subfield of the HT Capabilities element transmitted
by the intended receiver.
— If the sounding PPDU is an NDP, the number of antennas used by the sender shall be less than or
equal to the number indicated by the Channel Estimation Capability subfield in the Transmit
Beamforming Capability field of the HT Capabilities element transmitted by the intended receiver.
Sounding packets in which the Calibration Position subfield is equal to 2 or 3 shall use the spatial mapping
matrices defined in 19.3.12.3. The calibration responder shall not remove the spatial mapping from the CSI to
be fed back to the initiator of the frame exchange.
NOTE—The calibration initiator of this frame exchange is responsible for accounting for the spatial mapping in both its
local channel estimate as well as in the quantized CSI fed back to it.
The row order in the CSI feedback matrix transmitted from STA B shall correspond to the association of the
rows of the spatial mapping matrix (see Equation (19-75)) to its transmit antennas. For example, the receive
antenna at STA B associated with row i in the CSI feedback matrix in each subcarrier is the same as its transmit
antenna associated with row i in the spatial mapping matrix used for transmitting the sounding response with
Calibration Position equal to 2.
Figure 10-48 and Figure 10-49 illustrate the calibration PPDU exchange using NDPs.
Frame Type : QoS Data (or RTS or Management)
Ack Policy : Normal Ack
+ HTC : HT NDP Announcement=1
Cal Position: 1 NDP
STA A Cal Start 1
Frame Type: Ack (or CTS)
Cal Position: 2 NDP
STA B Cal Sound 2
Step 1 Step 2 is not
shown here
Figure 10-48—Calibration procedure with NDP
The calibration procedure begins with a calibration sounding PPDU exchange sequence, shown as Step 1 in
Figure 10-48 and Figure 10-49, when STA B supports transmitting sounding PPDUs for which only one
channel dimension can be estimated (i.e., a single column of the MIMO channel matrix). The Calibration
Sequence subfield in the HT Control field shall be incremented each time a new calibration procedure is
started.
NDP transmission within a calibration procedure follows the rules defined in 10.34.1. STA A transmits a
Calibration Start frame (i.e., with the Calibration Position subfield set to 1) with the HT NDP Announcement
subfield set to 1 and CSI/Steering subfield of the HT Control field set to 1. Only the current TXOP holder may
set both the Calibration Position and HT NDP Announcement subfields to 1. This frame initiates a calibration
procedure.
1475
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Frame Type : QoS Data (or RTS or Management)
Ack Policy : Normal Ack
+ HTC : HT NDP Announcement=1
Cal Position: 1 NDP
STA A Cal Start 1
PPDU Type: Sounding
Frame Type: Ack (or CTS)
Cal Position: 2
STA B Cal Sound
Step 1 Step 2 is not
shown here
Figure 10-49—Calibration procedure with NDP when STA B supports
transmitting sounding PPDUs for which only one channel dimension can be estimated
(i.e., a single column of the MIMO channel matrix)
STA B shall transmit a Calibration Sounding Response frame (i.e., with the Calibration Position subfield set to
2) after a SIFS after the received Calibration Start frame. If STA B supports transmitting sounding PPDUs for
which only one channel dimension can be estimated (i.e., a single column of the MIMO channel matrix), this
Calibration Sounding Response frame is sent with the SOUNDING parameter of the TXVECTOR set to
SOUNDING (see Figure 10-49).
As determined by NDP rules a) or b) in 10.34.1, STA A sends the first NDP as a sounding PPDU a SIFS after
receiving the Calibration Sounding Response frame. This step allows STA B to estimate the MIMO channel
from STA A to STA B. In the Calibration Sounding Response frame, the Calibration Sequence subfield in HT
Control field shall be set to the same value that is contained in the Calibration Start frame. The Calibration
Sounding Response frame shall contain an HT Control field, and the type and subtype of the frame are
determined by the Calibration Start frame.
As determined by NDP rule d), STA B might transmit a second NDP as a sounding PPDU a SIFS after
receiving the first NDP. This second NDP allows STA A to estimate the channel from STA B to STA A.
NOTE—STA B does not transmit an NDP when it supports transmitting sounding PPDUs for which only one channel
dimension can be estimated (see Figure 10-49).
Otherwise (i.e., if STA B supports transmitting sounding PPDUs for which only one channel dimension can be
estimated (single column of the MIMO channel matrix)), the transmission of the sounding PPDU in
Calibration Position 2 allows STA A to estimate the channel from STA B to STA A.
NDP sounding PPDUs shall use the spatial mapping matrices defined in 19.3.13.3. The calibration responder
shall not remove the spatial mapping from the CSI to be fed back to the initiator of the frame exchange.
NOTE—The calibration initiator of this frame exchange is responsible for accounting for the spatial mapping in both its
local channel estimate as well as in the quantized CSI fed back to it.
10.32.2.4.4 CSI reporting for calibration
The remaining message exchange in the calibration procedure is not time critical.
The calibration initiator should not transmit any frames that are part of the calibration sequence shown in Step
1 in Figure 10-47 if either of the response frames from the calibration responder (the frames shown as
Calibration Position 2 and Ack in Step 1) is not received correctly within an AckTimeout interval (as defined in
10.3.2.9) after the PHY-TXEND.confirm primitive. If the calibration initiator aborts the calibration sequence,
1476
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
it may restart the calibration sequence with a value of the Calibration Sequence subfield in the Calibration
Control subfield of the HT Control field that is different (i.e., incremented) from the value used in the aborted
sequence. Within a non-NDP calibration sequence, the calibration responder should not transmit any further
frames that are part of the calibration sequence shown in Step 1 if the frame having Calibration Position 3 is not
received correctly within an AckTimeout interval (as defined in 10.3.2.9) after the PHY-TXEND.confirm
primitive.
When the MIMO channel measurements become available at STA B, STA B shall send one or more CSI
frames that contain the CSI report (Step 2 in Figure 10-47). This CSI report shall have full precision, i.e, Ng=1
(no grouping) and Nb=3 (8 bits). In these CSI frames, the Calibration Sequence subfields in HT Control fields
shall be set to the same value that is indicated in the Calibration Sounding Complete frame. These CSI frames
shall have a frame type of Management Action +HTC.
STA B should finish transmission of the first CSI frame within aMaxCSIMatricesReportDelay (in
milliseconds) after the reception of the frame containing the CSI feedback request or HT NDP announcement.
NOTE—If necessary, the CSI Report field can be split into up to 8 segments as specified in Table 9-51.
A STA that has started but not completed the calibration procedure and that receives some other request that
requires the buffering of CSI (such as another calibration initiation frame, MFB request, CSI feedback request
for link adaptation, or feedback request for explicit Transmit Beamforming) may ignore the other request.
From the beginning of Step 1 of the calibration procedure and continuing through the end of Step 2 of the
calibration procedure, neither the receiving nor the transmitting STA should switch antennas.
10.32.3 Explicit feedback beamforming
The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, if
present, is the HT variant HT Control field.
In this subclause, the terms HT beamformer and HT beamformee refer to STAs that are involved in explicit
feedback beamforming.
An HT beamformer uses the feedback response that it receives from the HT beamformee to calculate a
beamforming feedback matrix for transmit beamforming. This feedback response may have one of three
formats:
— CSI: The HT beamformee sends the MIMO channel coefficients to the HT beamformer.
— Noncompressed beamforming: The HT beamformee sends calculated beamforming feedback
matrices to the HT beamformer.
— Compressed beamforming: The HT beamformee sends compressed beamforming feedback matrices
to the HT beamformer.
The supported formats shall be advertised in the HT beamformee’s HT Capabilities element.
NOTE—An HT beamformer might discard the feedback response if the TSF time when the
PHY-CCA.indication(IDLE) primitive corresponding to the feedback response frame’s arrival minus the value from the
Sounding Timestamp field in the feedback response frame is greater than the coherence time interval of the propagation
channel.
An HT beamformee’s responding capabilities shall be advertised in HT Capabilities elements that are
transmitted by the HT beamformee. Devices that are capable of acting as an HT beamformee shall advertise
one of the following response capabilities in the Explicit Transmit Beamforming CSI Feedback subfield of the
Transmit Beamforming Capability field:
1477
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Immediate: The HT beamformee is capable of sending a feedback response a SIFS after receiving a
sounding PPDU and/or is capable of sending a feedback response aggregated in a PPDU that
contains a MAC response within the HT beamformer’s TXOP.
— Delayed: The HT beamformee is not capable of sending the feedback response within the HT
beamformer’s TXOP, but it is capable of sending the feedback response in a TXOP that it obtains.
— Immediate and Delayed: The HT beamformee is capable of sending a feedback response a SIFS
after receiving a sounding PPDU, sending a feedback response aggregated in a PPDU that contains a
MAC response within the HT beamformer’s TXOP, or sending the feedback response in a TXOP
that it obtains.
The sounding frame types supported by the HT beamformee, staggered and/or NDP, are advertised in the HT
Capabilities element in frames that are transmitted by the HT beamformee.
A STA that sets any of the Explicit Transmit Beamforming CSI Feedback Capable, Explicit Noncompressed
Beamforming Feedback Capable, or Explicit Compressed Beamforming Feedback Capable fields to 1 shall
transmit explicit feedback based on the receipt of a +HTC sounding PPDU in which the CSI/Steering subfield
has a nonzero value and that does not contain Extension HT-LTFs (HT-ELTFs). This requirement is
independent of the values of the Receive Staggered Sounding Capable and the Receive NDP Capable fields.
An HT beamformer shall set the SOUNDING parameter of the TXVECTOR to SOUNDING in the PHY-
TXSTART.request primitive corresponding to each packet that is used for sounding.
An HT beamformer shall set the response type format indicated in the CSI/Steering subfield of the HT Control
field of any sounding frame excluding the NDP and of any PPDU with the NDP Sounding Announcement field
equal to 1 to one of the nonzero values (CSI, Compressed Beamforming, or Noncompressed Beamforming)
that corresponds to a type that is supported by the HT beamformee.
The receipt of a PHY-RXSTART.indication primitive with the RXVECTOR SOUNDING parameter value
equal to SOUNDING indicates a sounding packet. A non-NDP request for feedback is a sounding PPDU with
a +HTC MPDU that contains a nonzero value of the CSI/Steering subfield and that has the HT NDP
Announcement subfield equal to 0.
An NDP request for feedback is the combination of a +HTC MPDU that contains a nonzero value of the CSI/
Steering subfield and that has the HT NDP Announcement subfield equal to 1 and the NDP that follows.
An HT beamformee that transmits a feedback frame in response to a sounding PPDU sent by an HT
beamformer shall transmit a frame of the type (CSI, Compressed Beamforming, or Noncompressed
Beamforming) indicated in the CSI/Steering subfield of the HT Control field transmitted by the HT
beamformer.
The HT beamformee decides on any tone grouping to be used in the explicit Beamforming feedback. The
value selected shall be a value supported by the HT beamformer as indicated in the Minimal Grouping subfield
of the HT beamformer’s HT Capabilities element.
An HT beamformee that sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities
element to either 2 or 3 shall transmit Explicit CSI feedback after SIFS or later in the HT beamformer’s TXOP
as a response to a non-NDP request for feedback in a frame that is appropriate for the current frame exchange
sequence following Table 10-17. An HT beamformee that sets the Explicit Noncompressed Beamforming
Feedback Capable field of its HT Capabilities element to either 2 or 3 shall transmit Explicit Noncompressed
Beamforming feedback after SIFS or later in the HT beamformer’s TXOP as a response to a non-NDP request
for feedback in a frame that is appropriate for the current frame exchange sequence following Table 10-17.
1478
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-17—Rules for HT beamformee immediate feedback transmission
responding to non-NDP sounding
Type of response Rule
CTS response If the transmission of a CTS is required in response to the non-NDP request for
feedback, the transmission of the feedback response frame shall be delayed until the
HT beamformee’s next transmission within the TXOP. This feedback response frame
may be aggregated in an A-MPDU with an Ack or BlockAck frame.
Acknowledgment If the transmission of an Ack or BlockAck frame is required in response to the non-
response NDP request for feedback, both the feedback response frame and the control response
frame may be aggregated in an A-MPDU.
No control response If the transmission of a control response frame is not required in response to the non-
NDP request for feedback, the feedback response frame shall be sent a SIFS after the
reception of the sounding PPDU containing the request for feedback.
Later aggregation of If the immediate-feedback-capable HT beamformee cannot transmit an aggregated or
feedback and immediate CSI/Steering response in a SIFS after the end of the received sounding
acknowledgment packet and the HT beamformee is subsequently required to transmit an Ack or
BlockAck frame in the same TXOP, it may transmit the feedback response in an
A-MPDU with the Ack or BlockAck frame.
An HT beamformee that sets the Explicit Compressed Beamforming Feedback Capable field of its HT
Capabilities element to either 2 or 3 shall transmit Explicit Compressed Beamforming feedback after SIFS or
later in the HT beamformer’s TXOP as a response to a non-NDP request for feedback in a frame that is
appropriate for the current frame exchange sequence following Table 10-17.
An HT beamformee that sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities
element to either 2 or 3 shall transmit the Explicit CSI feedback after SIFS or later in the HT beamformer’s
TXOP as a response to an NDP request for feedback in a frame that is appropriate for the current frame
exchange sequence following Table 10-18.
Table 10-18—Rules for HT beamformee immediate feedback transmission
responding to NDP sounding
Type of response Rule
Control response If the transmission of a control response frame is required in response to the NDP request for
feedback, the control response frame is transmitted a SIFS after reception of the PPDU that
elicited the control response, and the feedback response frame may be transmitted a SIFS
after the reception of the NDP.
— If the feedback response frame is not transmitted a SIFS after the reception of the
NDP and the HT beamformee is subsequently required to transmit an Ack or
BlockAck frame in the same TXOP, then the feedback response may be aggregated
with the Ack or BlockAck frame.
— If the feedback response frame is not transmitted a SIFS after the reception of the
NDP and is not transmitted with an aggregated Ack or BlockAck frame in the same
TXOP, then the feedback response frame is delayed until the HT beamformee’s
next transmission within the TXOP.
1479
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-18—Rules for HT beamformee immediate feedback transmission
responding to NDP sounding (continued)
Type of response Rule
No control If the transmission of a control response frame is not required in response to the NDP request
response for feedback, the feedback response frame may be sent a SIFS after the reception of the NDP.
— If the feedback response frame is not transmitted a SIFS after the reception of the
NDP and the HT beamformee is subsequently required to transmit an Ack or
BlockAck frame in the same TXOP, then the feedback response may be aggregated
with the Ack or BlockAck frame.
— If the feedback response frame is not transmitted a SIFS after the reception of the
NDP and is not transmitted with an aggregated Ack or BlockAck frame in the same
TXOP, then the feedback response frame is delayed until the HT beamformee’s
next transmission within the TXOP.
An HT beamformee that sets the Explicit Noncompressed Beamforming Feedback Capable field of its HT
Capabilities element to either 2 or 3 shall transmit the Explicit Noncompressed Beamforming feedback after
SIFS or later in the HT beamformer’s TXOP as a response to an NDP request for feedback in a frame that is
appropriate for the current frame exchange sequence following Table 10-18.
An HT beamformee that sets the Explicit Compressed Beamforming Feedback Capable field of its HT
Capabilities element to either 2 or 3 shall transmit the Explicit Compressed Beamforming feedback after SIFS
or later in the HT beamformer’s TXOP as a response to an NDP request for feedback in a frame that is
appropriate for the current frame exchange sequence following Table 10-18.
When the HT beamformee sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities
element to either 2 or 3 and the HT beamformer has transmitted an NDP or an non-NDP Explicit Beamforming
CSI feedback request in a frame that does not require immediate control response, the HT beamformer shall not
transmit the next packet to the HT beamformee until PIFS after transmitting the sounding request.
When the HT beamformee sets the Explicit Noncompressed Beamforming Feedback Capable field of its HT
Capabilities element to either 2 or 3 and the HT beamformer has transmitted an NDP or an non-NDP Explicit
Noncompressed Beamforming feedback request in a frame that does not require immediate control response,
the HT beamformer shall not transmit the next packet to the HT beamformee until PIFS after the sounding
request.
When the HT beamformee sets the Explicit Compressed Beamforming Feedback Capable field of its HT
Capabilities element to either 2 or 3 and the HT beamformer has transmitted an NDP or an non-NDP Explicit
Compressed Beamforming feedback request in a frame that does not require immediate control response, the
HT beamformer shall not transmit the next packet to the HT beamformee until PIFS after transmitting the
sounding request.
An HT beamformee shall not transmit a CSI, Compressed Beamforming, or Noncompressed Beamforming
frame except in response to a request for feedback.
NOTE—Error recovery in a TXOP is not affected by sounding. An HT beamformer that is a TXOP holder and that fails
to receive an expected response to a sounding PPDU can continue transmission as specified in 10.22.2.7.
An HT beamformee transmitting a feedback response after SIFS or later in the HT beamformer’s TXOP shall
use an Action No Ack frame or an Action No Ack +HTC frame (defined in 9.3.3.15).
An HT beamformee transmitting delayed feedback response shall use an Action frame or an Action +HTC
frame to send this information within a separate TXOP.
1480
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If necessary, the CSI Report field, Noncompressed Beamforming Report field, or Compressed Beamforming
Report field may be split into up to 8 frames. The length of each segment shall be equal number of octets for all
segments except the last, which may be smaller.
NOTE—A STA that has been granted an RDG can act as an HT beamformer during the RDG time period, provided that
the RD rules are obeyed.
An HT beamformee that advertises itself as delayed-feedback-capable shall not transmit an immediate
feedback response unless it also advertises itself as immediate-feedback-capable.
An HT beamformer may use the following worst-case parameters to estimate the duration of the expected
frame that contains the feedback response: lowest rate in basic HT-MCS set, HT-mixed format, no grouping.
An Explicit Feedback Request may be combined with an MRQ. If the response contains a beamforming
feedback matrix, the returned MCS shall be derived from the same information that was used to generate this
particular beamforming feedback matrix. If the response contains channel coefficients, the returned MCS shall
be derived from an analysis of the sounding frame that was used to generate the channel coefficients. The MFB
field set to 127 (meaning no feedback) may be used when the HT beamformee is unable to generate the MCS
in time for inclusion in the response transmission frame. A CSI-capable STA may be incapable of generating
MFB.
Explicit feedback shall be calculated only from a sounding PPDU.
An HT beamformee that transmits a feedback frame of type Compressed Beamforming in response to a
sounding PPDU sent by an HT beamformer shall set the value of Nr in the MIMO Control field of the feedback
frame to be the same value as the number of streams in the sounding PPDU.
10.32.4 VHT MU beamforming
An MU beamformer may transmit a VHT MU PPDU with a single nonzero TXVECTOR parameter
NUM_STS[p], where 0 p 3 .
An MU beamformer shall not transmit a VHT MU PPDU with a nonzero TXVECTOR parameter
NUM_STS[p], where 0 p 3 , to a STA whose MU Beamformee Capable field is equal to 0.
When transmitting a VHT MU PPDU, an MU beamformer shall order the per-user arrays of TXVECTOR
parameters so that the per-user USER_POSITION array is in ascending order.
10.33 Antenna selection (ASEL)
10.33.1 Introduction
The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, if
present, is the HT variant HT Control field.
ASEL is a time-variant mapping of the signals at the RF chains onto a set of antenna elements when the
number of RF chains is smaller than the number of antenna elements. The mapping might be chosen based on
instantaneous or averaged CSI. ASEL requires the training of the full size channel associated with all antenna
elements, which is obtained by transmitting or receiving sounding PPDUs over all antennas. These sounding
PPDUs should be sent within a single TXOP. To avoid channel distortions, these sounding PPDUs shall be
transmitted consecutively. The training information is exchanged using the HT Control field. When both
transmitter and receiver have ASEL capabilities, training of transmit and receive antennas might be done one
after another. ASEL supports up to eight antennas and up to four RF chains.
1481
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.33.2 Procedure
A STA shall not initiate an ASEL training frame exchange sequence with another STA unless that STA
supports ASEL, as determined by the ASEL Capability field (see 9.4.2.56.7).
A STA that is capable of supporting ASEL should set each subfield of the ASEL Capability field of the HT
Capabilities element to 1 depending on its capabilities in HT Capabilities elements that it transmits (see
9.4.2.56.7).
A STA that sets the Explicit CSI Feedback Based Tx ASEL Capable subfield of the ASEL Capability field (see
9.4.2.56.7) to 1 shall set the CSI Max Number of Rows Beamformer Supported subfield of the Transmit
Beamforming Capabilities field to an appropriate value, even if the STA sets the Explicit Transmit
Beamforming CSI Feedback subfield to the value 0.
The frame exchange sequence for transmit ASEL is shown in Figure 10-50, where the term ASEL transmitter
identifies the STA that is conducting transmit ASEL, and the term transmit ASEL responder identifies the STA
that provides ASEL feedback. The frame exchange comprises the following steps:
a) (Optional) A transmit ASEL responder may initiate the transmit ASEL training by sending a +HTC
frame with the ASEL Command subfield set to Transmit Antenna Selection Sounding Request
(TXASSR).
b) The ASEL transmitter sends out consecutive sounding PPDUs separated by SIFS in a TXOP of
which it is the TXOP holder with no acknowledgment over different antenna sets, each PPDU
containing a +HTC frame with the ASEL Command subfield set to Transmit Antenna Selection
Sounding Indication (TXASSI or TXASSI-CSI). Each sounding PPDU is transmitted over one
antenna set.
If the ASEL transmitter allows antenna indices feedback (by setting the ASEL Command subfield to
TXASSI), the antenna sets from which the sounding PPDUs are transmitted shall be disjoint. If the
ASEL transmitter uses NDP sounding PPDUs for the ASEL sounding, the spatial mapping matrix
Qk shall be set equal to the identity matrix starting with the first NDP. If the ASEL transmitter uses
non-NDP sounding PPDUs for the ASEL sounding, the spatial mapping matrix Qk shall be an FFT
matrix. An FFT matrix of size N is defined as a square matrix of dimension NxN with entries wim ,
1 im
i=0,..N–1, m=0,..N–1 where w im = -------- exp – j2 ------ .
N N
The ASEL transmitter shall not include TXASSI-CSI in the command field of the sounding frame if
the last received value of the Explicit CSI Feedback Capable subfield of the ASEL Capability field
(see 9.4.2.56.7) from the receiver was 0.
NOTE—For example, in the case of sounding over all disjointed antenna sets, the number of consecutive
sounding PPDUs equals the smallest integer that is greater than or equal to the number of antennas divided by
the number of RF chains. These sounding PPDUs need to be sent within a single TXOP in order to minimize
the change in the channel during this procedure.
c) The transmit ASEL responder estimates the subchannel corresponding to each sounding PPDU.
d) If the ASEL Command subfield in the sounding frames is equal to TXASSI-CSI, after receiving all
of the sounding PPDUs, the transmit ASEL responder shall respond with the full size CSI in a
subsequent TXOP. If the ASEL Command subfield in the sounding frames is equal to TXASSI, after
receiving all of the sounding PPDUs, the transmit ASEL responder may either respond with the full
size CSI in a subsequent TXOP, or conduct ASEL computation and provide the selected antenna
indices in a subsequent TXOP.
1) CSI is transported using the MIMO CSI Matrices frame defined in 9.6.12.6 contained within
either an Action No Ack or Action frame. Multiple CSI frames may be required to provide the
complete feedback, in which case the value of the Sounding Timestamp field within each of
1482
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
these CSI frames shall correspond to the arrival time of the sounding frame that was used to
generate the feedback information contained in the frame.
2) Antenna indices feedback is carried in the Antenna Selection Indices Feedback frame, defined
in 9.6.12.9. One octet of the Antenna Selection Indices field is used to carry the selected
antenna indices feedback.
+ HTC frame Consecutive Sounding PPDUs
Transmitter
ASEL with NDP
Announce = 1
TXASSI NDP NDP
or SIFS SIFS
…
TXASSI TXASSI
Responder
Transmit
SIFS
ASEL
Segmented Segmented
sounding PPDU sounding PPDU
TXASSR ASEL Feedback
(optional) Transmit Antenna
Selection sounding
request
Figure 10-50—Transmit ASEL
If the transmit ASEL responder does not correctly receive all of the sounding PPDUs but has correctly received
at least one of the preceding sounding PPDUs, it shall send a +HTC frame with the MAI subfield set to the
value ASELI (see Table 9-12), the ASEL Command subfield set to No Feedback Due to ASEL Training
Failure or Stale Feedback to indicate the failure of the ASEL training process, and the ASEL Data subfield set
to either of the following:
— The integer value corresponding to the number in sequence of the first sounding PPDU that was not
properly received, where 0 corresponds to the first sounding PPDU in the ASEL training sequence
or
— The value 0
A transmit ASEL responder that determines that the ASEL feedback is stale shall notify the ASEL transmitter
by transmitting a +HTC MPDU with the MAI subfield set to ASELI, the ASEL Command subfield set to No
Feedback Due to ASEL Training Failure or Stale Feedback, and the ASEL Data subfield set to 0.
If, in response to the transmission of a sequence of sounding PPDUs, the ASEL transmitter receives a +HTC
MPDU with the MAI subfield equal to ASELI, the ASEL Command subfield equal to No Feedback Due to
ASEL Training Failure or Stale Feedback, and the ASEL Data subfield equal to a nonzero value to indicate a
failed ASEL training frame sequence, the ASEL transmitter may perform any of the following actions:
— Do nothing.
— Restart the failed ASEL training frame sequence from the point of failure by transmitting a +HTC
MPDU with the MAI subfield set to ASELI, the ASEL Command subfield set to TXASSR, and the
ASEL Data subfield set to a nonzero value to correspond to the command Transmit Antenna
Selection Sounding Resumption (a Resumption MPDU), where the ASEL Data subfield value is the
order number (from the original training frame sequence) of the first sounding PPDU transmitted in
the restarted ASEL training frame sequence and where 0 corresponds to the first sounding PPDU in
the original ASEL training sequence.
— Execute a new ASEL training frame sequence by transmitting a +HTC MPDU with the MAI
subfield set to ASELI, the ASEL Command subfield set to TXASSI or TXASSI-CSI, and the ASEL
Data subfield set to a nonzero value.
1483
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If a transmit ASEL responder receives a +HTC MPDU with the MAI subfield equal to ASELI, the ASEL
Command subfield equal to TXASSR, and the ASEL Data subfield equal to a nonzero value to correspond to
the command Transmit Antenna Selection Sounding Resumption (a Resumption MPDU), the transmit ASEL
responder shall respond to the training sequence according to the original command value (i.e., TXASSI or
TXASSI-CSI) and shall assume a total number of sounding PPDUs that corresponds to the number of sounding
PPDUs from the original command frame. The number of sounding frames that follow the Resumption MPDU
is equal to the number of sounding PPDUs from the original command frame minus the order number
transmitted in the ASEL Data subfield of the Resumption MPDU.
The frame exchange sequence for receive ASEL is shown in Figure 10-51, where the term ASEL receiver
identifies the STA that is conducting receive ASEL, and the term ASEL sounding-capable transmitter
identifies the STA sending the consecutive sounding PPDUs used for receive ASEL calculations. The frame
exchange comprises the following steps:
— The ASEL receiver transmits a +HTC frame with the MAI subfield set to ASELI, the ASEL
Command subfield set to Receive Antenna Selection Sounding Request (RXASSR), and the ASEL
Data subfield set to the number of sounding PPDUs required.
NOTE— For example, in the case of sounding over all disjointed antenna sets, the number of total consecutive
sounding PPDUs or NDPs equals the smallest integer that is greater than or equal to the number of antennas
divided by the number of RF chains.
— The ASEL sounding-capable transmitter responds with the corresponding number of sounding
PPDUs in its subsequent TXOP. These PPDUs are separated by SIFS. When using non-NDP
sounding, each PPDU contains a +HTC frame in which the MAI subfield is set to ASELI, the ASEL
Command subfield is set to Receive Antenna Selection Sounding Indication (RXASSI), and the
ASEL Data subfield is set to the remaining number of sounding PPDUs to be transmitted. When
using NDP sounding, the PPDU that precedes the first NDP contains a +HTC frame in which the
NDP Announce field is set to 1, the MAI subfield is set to ASELI, the ASEL Command subfield is
set to RXASSI, and the ASEL Data subfield is set to the remaining number of sounding PPDUs to
be transmitted.
ASEL Sounding
Consecutive Sounding PPDUs
+ HTC frame
Transmitter
with NDP
Capable
announce = 1
RXASSI NDP NDP
…
or SIFS SIFS
RXASSI RXASSI
Receiver
SIFS Segmented
Segmented
ASEL
sounding PPDU sounding PPDU
RXASSR
ASEL Receiver transmits a Receive
Antenna Selection Sounding Request
Figure 10-51—Receive ASEL
The ASEL receiver uses different antenna sets to receive these sounding PPDUs, estimates CSI after receiving
all these sounding PPDUs, and conducts the ASEL.
When transmitting the consecutive sounding PPDUs in transmit and receive ASEL exchanges (illustrated in
Figure 10-50 and Figure 10-51), the transmitter shall not change the TXPWR_LEVEL_INDEX parameter of
the TXVECTOR.
1484
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When transmitting a sounding PPDU sent in transmit and receive ASEL exchanges (illustrated in Figure 10-50
and Figure 10-51), if the Receive Staggered Capability subfield of the Transmit Beamforming Capability field
of the HT Capabilities element transmitted by the intended receiver is 0, then,
— If the sounding PPDU is not an NDP, the number of antennas used by the sender, as indicated by the
ANTENNA_SET parameter in the TXVECTOR, shall be less than or equal to the maximum number
of space-time streams indicated by the Rx MCS Bitmask subfield of the Supported MCS Set field
and the Rx STBC subfield of the HT Capabilities element transmitted by the intended receiver.
— If the sounding PPDU is an NDP, the number of antennas used by the sender, as indicated by the
ANTENNA_SET parameter in the TXVECTOR, shall be less than or equal to the number indicated
by the Channel Estimation Capability subfield of the Transmit Beamforming Capability field of the
HT Capabilities element transmitted by the intended receiver.
When both transmitter and receiver have ASEL capabilities, the following constraints apply:
— During a transmit ASEL frame exchange, the transmit ASEL responder shall use a subset of
antennas that does not change during the reception of all of the sounding PPDUs of the ASEL
sounding sequence.
— During a receive ASEL frame exchange, the ASEL sounding-capable transmitter shall use a subset
of antennas that does not change during the transmission of all of the sounding PPDUs of the ASEL
sounding sequence.
NOTE—When a receiver (either a transmit ASEL responder or an ASEL receiver) conducts ASEL computations (for
either transmit or receive ASEL), if there is no transmit beamforming conducted at the same time, to achieve the best
performance of ASEL, the receiver assumes that the first N STS columns of the same spatial mapping matrix Q k used for
transmitting ASEL sounding PPDUs, where N STS is the number of space-time streams, are applied for the spatial
mapping at the ASEL transmitter after the ASEL exchange as in Figure 10-50 and Figure 10-51. To achieve the best
performance of ASEL, the ASEL transmitter applies the first N STS columns of the same Q k for spatial mapping after the
ASEL exchange as in Figure 10-50 and Figure 10-51.
10.34 Null data packet (NDP) sounding
10.34.1 HT NDP sounding protocol
Sounding may be accomplished using either staggered sounding PPDU or HT NDP, as described in 19.3.13.
The MAC rules associated with sounding using HT NDP are described in 10.34.1 to 10.34.4.
An HT STA that has set the Receive NDP Capable field of its HT Capabilities element to 1 during association
processes an HT NDP as a sounding packet if the destination of the sounding packet is determined to match
itself as described in 10.34.3 and if the source of the sounding packet can be ascertained as described in
10.34.4.
An RXVECTOR LENGTH parameter equal to 0 indicates that an HT PPDU is an HT NDP.
A STA that is a TXOP holder or an RD responder shall not set both the HT NDP Announcement and RDG/
More PPDU subfields to 1 simultaneously. The Calibration Position subfield shall not be set to any value
except 0 and 1 in any +HTC frame in a PPDU that is also an HT NDP announcement. The Calibration Position
subfield shall be set to 0 in any +HTC frame in a PPDU that is an HT NDP announcement that also contains
any +HTC frame with the MAI subfield equal to ASELI. The Calibration Position subfield shall be set to 0 in
all +HTC frames in a PPDU that is an HT NDP announcement and that contains any +HTC frame with the
MRQ subfield equal to 1. The TRQ field shall be set to 0 in all +HTC frames in a PPDU that is an HT NDP
announcement.
An NDP sequence contains at least one HT NDP and at least one PPDU that is not an NDP. Only one PPDU in
the NDP sequence may contain an HT NDP announcement. An NDP sequence begins with an HT NDP
1485
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
announcement. The NDP sequence ends at the end of the transmission of the last HT NDP that is announced by
the HT NDP announcement. A STA that transmits the first PPDU of an NDP sequence is the NDP sequence
owner. In the NDP sequence, only PPDUs carrying HT NDP and PPDUs carrying single MPDU Control
frames may follow the NDP sequence’s starting PPDU.
A STA shall transmit only one HT NDP per HT NDP announcement, unless the HT NDP announcement
includes a value in the ASEL Data subfield of the ASEL Command subfield of the HTC Control field that is
greater than one. Each PPDU in an NDP sequence shall start a SIFS after end of the previous PPDU.
A STA shall not transmit a VHT NDP in a NDP sequence that contains an HT NDP announcement.
A CTS frame that is a +HTC frame shall not contain the HT NDP Announcement subfield set to 1.
NOTE—A CTS frame cannot be used for HT NDP announcement: if the CTS frame is a response to an RTS frame, the
optional NAV reset timeout that starts at the end of the RTS frame does not include the additional HT NDP and SIFS
(see 10.3.2.4). Also, if the CTS were the first frame of an NDP sequence, it would not be possible to determine the
destination address of the HT NDP.
A STA shall transmit an HT NDP as follows:
a) A SIFS after sending a PPDU that is an HT NDP announcement and that does not contain an MPDU
that requires an immediate response.
b) A SIFS after successfully receiving a correctly formed and addressed immediate response to a
PPDU that is an HT NDP announcement and that contains an MPDU that requires an immediate
response.
c) A SIFS after transmitting an HT NDP if the HT NDP announcement contains an ASEL Command
subfield equal to TXASSI, TXASSI-CSI, or RXASSI and the ASEL Data subfield is equal to a value
greater than 0 and if the number of HT NDPs sent before this one is less than the value in the ASEL
Data subfield + 1.
NOTE—The total number of sent HT NDPs is equal to the value of in the ASEL Data subfield + 1.
d) A SIFS after receiving an HT NDP from a STA whose HT NDP announcement contained one or
more +HTC frames with the Calibration Position subfield equal to 1, when the receiving STA
supports transmitting sounding PPDUs for which more than one channel dimension can be
estimated (i.e., more than one column of the MIMO channel matrix).
This rule enables the NDP receiver to know that it will receive an HT NDP and can determine the source and
destination of the HT NDP. It enables the receiver and transmitter to know when the immediate response and
HT NDP will be transmitted relative to the frame containing the HT NDP announcement indication.
A STA that has transmitted an HT NDP announcement in a frame that requires an immediate response and that
does not receive the expected response shall terminate the NDP sequence at that point (i.e., the STA does not
transmit an HT NDP in the current NDP sequence).
A STA that has received an HT NDP announcement in a +HTC with the Calibration Position equal to 1 or 2,
and that does not receive the HT NDP. expected shall terminate the NDP sequence at that point (i.e., does not
transmit an HT NDP in the current NDP sequence) and not transmit any further frames that are a part of this
calibration sequence shown in Step 1 of Figure 10-48.
Feedback information generated from the reception of an HT NDP is transmitted using any of the feedback
rules and signaling as appropriate, e.g., immediate or delayed.
1486
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.34.2 Transmission of an HT NDP
A STA that transmits an HT NDP shall set the LENGTH, SOUNDING, STBC, MCS, and NUM_EXTEN_SS
parameters of the TXVECTOR as specified in this subclause.
— LENGTH shall be set to 0.
— SOUNDING shall be set to SOUNDING.
— STBC shall be set to 0.
— MCS shall indicate two or more spatial streams.
The number of spatial streams sounded is indicated by the MCS parameter of the TXVECTOR and shall not
exceed the limit indicated by the Channel Estimation Capability field in the Transmit Beamforming
Capabilities field transmitted by the STA that is the intended receiver of the HT NDP. The MCS parameter
may be set to any value, subject to the constraint of the previous sentence, regardless of the value of the
Supported MCS Set field of the HT Capabilities field at either the transmitter or recipient of the HT NDP. A
STA shall set the NUM_EXTEN_SS parameter of the TXVECTOR to 0 in the PHY-TXSTART.request
primitive corresponding to an HT NDP transmission.
A STA shall not transmit an HT NDP announcement with an RA corresponding to another STA unless it has
received an HT Capabilities element from the destination STA in which the Receive NDP Capable field is
equal to 1.
10.34.3 Determination of HT NDP destination
The destination of an HT NDP is determined at the NDP receiver by examining the HT NDP announcement as
follows:
— The destination of the first HT NDP in the NDP sequence is equal to the RA of any MPDU within
HT NDP announcement.
— If Calibration Position subfield is equal to 1 in the HT NDP announcement at the NDP receiver, the
destination of the second HT NDP is equal to the TA of that frame. Otherwise, the destination of the
second and any subsequent HT NDPs is equal to the destination of the previous HT NDP.
See O.4 for an illustration of these rules.
10.34.4 Determination of HT NDP source
The source of an HT NDP is determined at the NDP receiver by examining the NDP sequences’s starting
PPDU as follows:
— If any MPDU within the HT NDP announcement contains two or more addresses, the source of the
first HT NDP is equal to the TA of that frame.
— Otherwise (i.e., the HT NDP announcement contains one address), the source of the first HT NDP is
equal to the RA of the MPDU to which the HT NDP announcement is a response.
— If the Calibration Position subfield is equal to 1 in an MPDU in the HT NDP announcement, the
source of the second HT NDP is equal to the RA of that MPDU. Otherwise, the source of the second
and any subsequent HT NDPs is equal to the source of the previous NDP.
See O.4 for an illustration of these rules.
1487
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.34.5 VHT sounding protocol
10.34.5.1 General
Transmit beamforming and DL-MU-MIMO require knowledge of the channel state to compute a steering
matrix that is applied to the transmitted signal to optimize reception at one or more receivers. The STA
transmitting using the steering matrix is called the VHT beamformer, and a STA for which reception is
optimized is called a VHT beamformee. An explicit feedback mechanism is used where the VHT beamformee
directly measures the channel from the training symbols transmitted by the VHT beamformer and sends back a
transformed estimate of the channel state to the VHT beamformer. The VHT beamformer then uses this
estimate, perhaps combining estimates from multiple VHT beamformees, to derive the steering matrix.
If dot11VHTSUBeamformerOptionImplemented is true, a STA shall set the SU Beamformer Capable field in
the VHT Capabilities element to 1. If dot11VHTSUBeamformeeOptionImplemented is true, a STA shall set
the SU Beamformee Capable field in the VHT Capabilities element to 1.
If dot11VHTMUBeamformerOptionImplemented is true, a STA shall set the MU Beamformer Capable field
in the VHT Capabilities element to 1. If dot11VHTMUBeamformeeOptionImplemented is true, a STA shall
set the MU Beamformee Capable field in the VHT Capabilities element to 1.
If dot11VHTMUBeamformerOptionImplemented is true, a STA shall set
dot11VHTSUBeamformerOptionImplemented to true. If dot11VHTMUBeamformeeOptionImplemented is
true, a STA shall set dot11VHTSUBeamformeeOptionImplemented to true.
A STA is a VHT SU-only beamformer if it sets the SU Beamformer Capable field to 1 but sets the MU
Beamformer Capable field to 0 in transmitted VHT Capabilities elements. A STA is an SU-only beamformee if
it sets the SU Beamformee Capable field to 1 but sets the MU Beamformee Capable field to 0 in transmitted
VHT Capabilities elements.
If dot11VHTSUBeamformerOptionImplemented is false, a STA shall not act in the role of a VHT
beamformer. If dot11VHTSUBeamformeeOptionImplemented is false, a STA shall not act in the role of a
VHT beamformee.
10.34.5.2 Rules for VHT sounding protocol sequences
A VHT beamformer shall initiate a sounding feedback sequence by transmitting a VHT NDP Announcement
frame followed by a VHT NDP after a SIFS. The VHT beamformer shall include in the VHT NDP
Announcement frame one STA Info field for each VHT beamformee that is expected to prepare VHT
Compressed Beamforming feedback and shall identify the VHT beamformee by including the VHT
beamformee’s AID in the AID subfield of the STA Info field. The VHT NDP Announcement frame shall
include at least one STA Info field.
NOTE―A STA that transmits a VHT NDP Announcement frame to a DLS or TDLS peer STA obtains the AID for the
peer STA from the DLS Setup Request, DLS Setup Response, TDLS Setup Request, or TDLS Setup Response frame.
A VHT beamformer shall not transmit either a VHT NDP Announcement+HTC frame or a Beamforming
Report Poll+HTC frame that contains an HT variant HT Control field.
A VHT NDP shall be transmitted only following a SIFS after a VHT NDP Announcement frame. A VHT NDP
Announcement frame shall be followed by a VHT NDP after SIFS.
A VHT beamformer that has not received a VHT Capabilities element from a STA or where the last VHT
Capabilities element received from a STA has the SU Beamformee Capable field set to 0 shall not transmit
either of the following:
1488
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— A VHT NDP Announcement frame addressed to the STA or that includes the STA’s AID in one of
the STA Info fields
— A Beamforming Report Poll frame addressed to the STA
A VHT beamformer that transmits a VHT NDP Announcement frame to a VHT SU-only beamformee shall
include only one STA Info field in the VHT NDP Announcement frame and set the Feedback Type subfield of
the STA Info field to SU.
If the VHT NDP Announcement frame includes more than one STA Info field, the RA of the VHT NDP
Announcement frame shall be set to the broadcast address. If the VHT NDP Announcement frame includes a
single STA Info field, the RA of the VHT NDP Announcement frame shall be set to the MAC address of the
VHT beamformee.
A VHT NDP Announcement frame shall not include two or more STA Info fields with same value in the AID
subfield.
A VHT beamformer that transmits a VHT NDP Announcement frame to a VHT beamformee that is an AP,
mesh STA or STA that is a member of an IBSS, shall include a single STA Info field in the VHT NDP
Announcement frame and shall set the AID field in the STA Info field to 0.
A VHT NDP Announcement frame with more than one STA Info field shall not carry a VHT variant HT
Control field, unless all of the STAs listed in the AID field of the STA Info fields have set +HTC-VHT
Capable to 1 in the VHT Capabilities Information field.
A VHT beamformer that transmits a VHT NDP Announcement frame with more than one STA Info field
should transmit any Beamforming Report Poll frames used to retrieve VHT Compressed Beamforming
feedback from the intended VHT beamformees in the same TXOP. If the duration of the TXOP that contained
the VHT NDP Announcement frame has insufficient duration to accommodate the transmission of all of the
feedback reports, the VHT beamformer may poll for the remaining VHT Compressed Beamforming feedback
in subsequent TXOPs.
A VHT beamformer may use the following worst-case parameters to estimate the duration of the expected
frame(s) that contain(s) the feedback response(s): lowest rate in basic VHT-MCS set, no grouping.
NOTE—The transmission of the VHT NDP Announcement, VHT NDP, VHT Compressed Beamforming, and
Beamforming Report Poll frames is subject to the rules in 10.22.2.7.
A VHT beamformer that sets the Feedback Type subfield of a STA Info field to MU shall set the Nc Index
subfield of the same STA Info field to a value less than or equal to the minimum of both of the following:
— The maximum number of supported spatial streams for receive operation according to the
combination of the corresponding VHT beamformee’s Rx VHT-MCS Map subfield in the
Supported VHT-MCS and NSS Set field and VHT Capabilities Information field
— The maximum number of supported spatial streams according to the Rx NSS subfield value and,
when the value of the VHT Extended NSS BW Capable subfield received from the VHT
beamformee is 1 and dot11ExtendedNSSSupported is equal to true, the 160/80+80 BW subfield
value in the Operating Mode field of the most recently received Operating Mode Notification frame
or Operating Mode Notification element with the Rx NSS Type subfield equal to 0 from the
corresponding VHT beamformee, as computed according to 10.7.12.1
A non-AP VHT beamformee that receives a VHT NDP Announcement frame from a VHT beamformer with
which it is associated or has an established DLS or TDLS session and that contains the VHT beamformee’s
AID in the AID subfield of the first (or only) STA Info field and also receives a VHT NDP a SIFS after the
VHT NDP Announcement frame shall transmit the PPDU containing its VHT Compressed Beamforming
1489
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
feedback a SIFS after the VHT NDP. A VHT beamformee that is an AP, mesh STA, or STA that is a member
of an IBSS, that receives a VHT NDP Announcement frame with the RA matching its MAC address and the
AID subfield of the only STA Info field set to 0, and that also receives a VHT NDP a SIFS after the VHT NDP
Announcement frame shall transmit the PPDU containing its VHT Compressed Beamforming feedback a SIFS
after the VHT NDP. The TXVECTOR parameter CH_BANDWIDTH of the PPDU containing the VHT
Compressed Beamforming feedback shall be set to indicate a bandwidth not wider than that indicated in the
RXVECTOR parameter CH_BANDWIDTH of the received VHT NDP frame. A STA ignores received VHT
NDP Announcement, VHT NDP, and Beamforming Report Poll frames if
dot11VHTSUBeamformeeOptionImplemented is false.
A VHT beamformee shall indicate the maximum number of space-time streams it can receive in a VHT NDP
in the Beamformee STS Capability subfield of the VHT Capabilities Information field of the VHT
Capabilities element. If the beamformee is a non-AP STA, this shall be less than or equal to the maximum total
number of space-time streams that the STA can receive in a VHT MU PPDU.
An example of the VHT sounding protocol with a single VHT beamformee is shown in Figure 10-52.
VHT NDP
Beamformer Announce- NDP
ment VHT
Beamformee Compressed
SIFS SIFS
Beamforming
Figure 10-52—Example of the sounding protocol with a single VHT beamformee
A non-AP VHT beamformee that receives a VHT NDP Announcement frame from a VHT beamformer with
which it is associated or has an established DLS or TDLS session and that contains the VHT beamformee’s
AID in the AID subfield of a STA Info field that is not the first STA Info field shall transmit its VHT
Compressed Beamforming feedback a SIFS after receiving a Beamforming Report Poll with RA matching its
MAC address and a nonbandwidth signaling TA obtained from the TA field matching the MAC address of the
VHT beamformer. If the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the received
Beamforming Report Poll frame is valid, the TXVECTOR parameter CH_BANDWIDTH of the PPDU
containing the VHT Compressed Beamforming feedback shall be set to indicate a bandwidth not wider than
that indicated by the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the Beamforming Report
Poll frame; otherwise, the TXVECTOR parameter CH_BANDWIDTH of the PPDU containing VHT
Compressed Beamforming feedback shall be set to indicate a bandwidth not wider than that indicated by the
RXVECTOR parameter CH_BANDWIDTH of the Beamforming Report Poll frame.
An example of the VHT sounding protocol with more than one VHT beamformee is shown in Figure 10-8.
VHT NDP
Beamforming Beamforming
SIFS
SIFS
SIFS
SIFS
SIFS
SIFS
Beamformer Announce- NDP
Report Poll Report Poll
ment VHT
Compressed
Beamformee 1
Beamforming VHT
Compressed
Beamformee 2
Beamforming VHT
Compressed
Beamformee 3
Beamforming
Figure 10-53—Example of the sounding protocol with more than one VHT beamformee
The RA field of the VHT Compressed Beamforming frame(s) of the VHT Compressed Beamforming feedback
shall be set to a nonbandwidth signaling TA obtained from the TA field of the VHT NDP Announcement
1490
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
frame or the Beamforming Report Poll frame to which this VHT Compressed Beamforming feedback is a
response.
If the VHT Beamformee is transmitting VHT Compressed Beamforming frame(s) a SIFS after the VHT NDP,
then the VHT Compressed Beamforming frame(s) shall include the VHT Compressed Beamforming Report
information and, for the case of MU feedback, the MU Exclusive Beamforming Report information.
A VHT beamformee that transmits a VHT Compressed Beamforming frame shall set the Feedback Type field
in the VHT MIMO Control field to the same value as the Feedback Type field in the corresponding STA Info
field in the VHT NDP Announcement frame. If the Feedback Type field indicates MU, the STA shall send a
VHT Compressed Beamforming frame with the Nc Index field value in the VHT MIMO Control field equal to
the minimum of all of the following:
— The Nc Index field value in the corresponding STA Info field in the VHT NDP Announcement
Frame
— The maximum number of supported spatial streams for receive operation according to the
combination of its Rx VHT-MCS Map subfield in the Supported VHT-MCS and NSS Set field,
VHT Capabilities Information field and Operating Mode field (see 10.7.12.1)
— The maximum number of supported spatial streams according to the Rx NSS subfield value and,
when the value of the most recently transmitted VHT Extended NSS BW Capable subfield is 1, the
160/80+80 BW subfield value in the Operating Mode field of the most recently transmitted
Operating Mode Notification frame or Operating Mode Notification element, as computed
according to 10.7.12.1
If the Feedback Type indicates SU, the Nc Index field value in the VHT MIMO Control field is determined by
the VHT beamformee.
The Nr Index field in the VHT MIMO Control field shall be set to the same value as the RXVECTOR
parameter NUM_STS of the corresponding VHT NDP. The Nc Index field shall not be set to a value larger
than the Nr Index value in the VHT MIMO Control field. A VHT beamformee shall set the value of the
Channel Width subfield in the VHT MIMO Control field of a VHT Compressed Beamforming frame to the
same value as the RXVECTOR parameter CH_BANDWIDTH of the corresponding VHT NDP frame.
A VHT beamformee shall not include MU Exclusive Beamforming Report information in VHT Compressed
Beamforming feedback if the Feedback Type subfield in the MIMO Control field of the VHT Compressed
Beamforming frame(s) indicates SU. A VHT beamformee shall include both VHT Compressed Beamforming
Report information and MU Exclusive Beamforming Report information in VHT Compressed Beamforming
feedback if the Feedback Type subfield in the MIMO Control field of the VHT Compressed Beamforming
frame(s) indicates MU.
A VHT beamformee that transmits VHT Compressed Beamforming feedback shall include neither the VHT
Compressed Beamforming Report information and nor the MU Exclusive Beamforming Report information if
the transmission duration of the PPDU carrying the VHT Compressed Beamforming Report information and
any MU Exclusive Beamforming Report information would exceed the maximum PPDU duration.
The value of the Sounding Dialog Token Number subfield in the VHT MIMO Control field shall be set to the
same value as the Sounding Dialog Token Number subfield in the Sounding Dialog Token field in the
corresponding VHT NDP Announcement frame.
NOTE 1—The VHT beamformer can use the sounding dialog token in the VHT Compressed Beamforming frame(s) of
the VHT Compressed Beamforming feedback to associate the feedback with a prior VHT NDP Announcement frame
and thus compute the delay between sounding and receiving the feedback. The VHT beamformer can use this delay time
when making a decision regarding the applicability of the feedback for the link.
NOTE 2—Recovery in the case of a missing response to a VHT NDP Announcement or Beamforming Report Poll
frame follows the rules for multiple frame transmission in an EDCA TXOP (see 10.22.2.7).
1491
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
VHT Compressed Beamforming feedback comprises the VHT Compressed Beamforming Report information
(see Table 9-69) and the MU Exclusive Beamforming Report information (see Table 9-72). Subclause 9.6.23.2
specifies how VHT Compressed Beamforming feedback is converted into a VHT Compressed Beamforming
frame, and it also specifies the rules for the presence or absence of the two fields listed here.
In a frame transmitted by a TVHT STA, the TVHT Compressed Beamforming Report field replaces the VHT
Compressed Beamforming Report field.
In a frame transmitted by a TVHT STA, the TVHT MU Exclusive Beamforming Report field replaces the MU
Exclusive Beamforming Report field.
10.34.5.3 Rules for fragmented feedback in VHT sounding protocol sequences
VHT Compressed Beamforming feedback shall be transmitted in a single VHT Compressed Beamforming
frame unless the result would be a VHT Compressed Beamforming frame that exceeds the VHT beamformer’s
maximum MPDU length capability.
NOTE—The VHT beamformee might therefore have to transmit an MPDU that is bigger than the VHT beamformee is
capable of receiving.
If VHT Compressed Beamforming feedback would result in a VHT Compressed Beamforming frame that
exceeds the VHT beamformer’s maximum MPDU length capability, the VHT Compressed Beamforming
feedback shall be split into up to 8 feedback segments, with each feedback segment sent in a different VHT
Compressed Beamforming frame and containing successive portions of the VHT Compressed Beamforming
feedback consisting of the VHT Compressed Beamforming Report information followed by any MU Exclusive
Beamforming Report information. Each of the feedback segments except the last shall contain the maximum
number of octets allowed by the VHT beamformer’s maximum MPDU length capability. The last feedback
segment may be smaller. Each feedback segment is identified by the value of the Remaining Feedback
Segments subfield and the First Feedback Segment subfield in the VHT MIMO Control field as defined in
9.4.1.48; the other nonreserved subfields of the VHT MIMO Control field shall be the same for all feedback
segments. All feedback segments shall be sent in a single A-MPDU and shall be included in the A-MPDU in
the descending order of the Remaining Feedback Segments subfield values.
NOTE—The feedback segments of a VHT Compressed Beamforming report are not MSDU/MMPDU fragments and
can be included in an A-MPDU as described in this subclause.
A VHT beamformer, in its first attempt to retrieve VHT Compressed Beamforming feedback from a VHT
beamformee that is not the one indicated by the first STA Info field, shall transmit a Beamforming Report Poll
frame to poll all possible feedback segments of the VHT Compressed Beamforming feedback from the VHT
beamformee, by setting all of the bits in the Feedback Segment Retransmission Bitmap field of the
Beamforming Report Poll frame to 1.
If a VHT beamformer fails to receive some or all feedback segments of VHT Compressed Beamforming
feedback, the VHT beamformer may, subject to the condition on VHT SU-only beamformees described at the
end of this subclause, request a selective retransmission of missing feedback segments by transmitting a
Beamforming Report Poll frame with the Feedback Segment Retransmission Bitmap field set as described in
9.3.1.21 to indicate the feedback segments requested for retransmission. If the VHT beamformer fails to
receive the feedback segment with the First Feedback Segment field set to 1, the VHT beamformer may
request a selective retransmission of missing feedback segments assuming the VHT Compressed Beamforming
feedback is split into 8 feedback segments. The VHT beamformer may also request the retransmission of all
feedback segments by setting all of the bits in the Feedback Segment Retransmission Bitmap field of the
Beamforming Report Poll frame to 1.
A VHT beamformee that transmits VHT Compressed Beamforming feedback including the VHT Compressed
Beamforming Report information and any MU Exclusive Beamforming Report information in response to a
1492
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beamforming Report Poll frame shall either transmit only the feedback segments indicated in the Feedback
Segment Retransmission Bitmap field in the Beamforming Report Poll frame excluding the indicated feedback
segments that do not exist at the VHT beamformee or transmit all of the feedback segments that exist at the
VHT beamformee disregarding the Feedback Segment Retransmission Bitmap field in the Beamforming
Report Poll frame.
A VHT beamformer shall not transmit a Beamforming Report Poll frame to a VHT SU-only beamformee
unless the VHT beamformer has received at least one feedback segment of the VHT Compressed
Beamforming feedback from the VHT beamformee in the current frame exchange sequence.
In a frame transmitted by a TVHT STA, the TVHT Compressed Beamforming Report field replaces the VHT
Compressed Beamforming Report field.
In a frame transmitted by a TVHT STA, the TVHT MU Exclusive Beamforming Report field replaces the MU
Exclusive Beamforming Report field.
10.34.6 Transmission of a VHT NDP
A VHT NDP shall use the SU PPDU format as described in 21.1.4. A STA shall transmit a VHT NDP using
the following TXVECTOR parameters:
— APEP_LENGTH set to 0
— NUM_USERS set to 1
— NUM_STS indicates two or more space-time streams
— CH_BANDWIDTH set to the same value as the TXVECTOR parameter CH_BANDWIDTH in the
preceding VHT NDP Announcement frame
— GROUP_ID and PARTIAL_AID are set as described in 10.20
The number of space-time streams sounded and as indicated by the NUM_STS parameter shall not exceed the
value indicated in the Beamformee STS Capability field in the VHT Capabilities element of any intended
recipient of the VHT NDP. The NUM_STS parameter may be set to any value, subject to the constraint of the
previous sentence, regardless of the value of the Supported VHT-MCS and NSS Set field of the VHT
Capabilities element at either the transmitter or recipient of the NDP.
The destination of a VHT NDP is equal to the RA of the immediately preceding VHT NDP Announcement
frame.
The source of a VHT NDP is equal to the TA of the immediately preceding VHT NDP Announcement frame.
10.35 Mesh forwarding framework
10.35.1 General
The term mesh forwarding refers to forwarding of MSDUs and MMPDUs on paths determined by the mesh
path selection between mesh STAs at the link layer. The mesh paths are contained in the forwarding
information. The forwarding information, for instance, the lifetime of a mesh path, may be updated as a
consequence of mesh forwarding.
The forwarding of MSDUs and MMPDUs within an MBSS is described in 10.35.3, 10.35.4, 10.35.5, and
10.35.8. The forwarding of MSDUs and MMPDUs between the MBSS and the DS at proxy mesh gates is
described in 14.11.3.
1493
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.35.2 Forwarding information
Forwarding information is created by the active mesh path selection protocol and is utilized for MSDU/
MMPDU forwarding as described in 10.35.3 and 10.35.5.2.
The basic forwarding information to a destination mesh STA consists of the destination mesh STA address,
the next-hop address, the precursor list, and the lifetime of this forwarding information.
An entry in the precursor list contains the precursor mesh STA address and the lifetime of this entry. If an
existing entry in a precursor list is updated, the lifetime is the maximum of the current and the updated value.
If the lifetime of a precursor expires, it will be deleted from the precursor list. Precursors are used to identify
legitimate transmitters of individually addressed frames (see 10.35.3.2) and for the notification of link
failures (in case of HWMP, see 14.10.11).
The forwarding information shall be considered as invalid if its lifetime has expired. Also, forwarding
information is marked as invalid when certain conditions are met in the processing of mesh path selection
elements, e.g., path error processing in HWMP (14.10.11.4).
The active path selection protocol may define additional parameters in the forwarding information. Details
on the additional parameters of the forwarding information constructed by the hybrid wireless mesh protocol
(HWMP) are described in 14.10.8.4.
10.35.3 Addressing and forwarding of individually addressed mesh Data frames
10.35.3.1 At source mesh STAs (individually addressed)
MSDUs sent by a mesh STA (as a consequence of an MA-UNITDATA.request primitive with an individual
destination address) and destined to another mesh STA in the MBSS shall be transmitted using a frame with the
four-address MAC header format (with the Address Extension Mode subfield in the Mesh Control field set to
“None” (see Table 9-20)), where the four address fields are set as follows (see row “Mesh Data (individually
addressed)” in Table 9-42):
— Address 1: The address of the next-hop mesh STA (toward the destination mesh STA according to
the forwarding information—see 10.35.2)
— Address 2: The address of the transmitter mesh STA
— Address 3: The address of the destination mesh STA
— Address 4: The address of the source mesh STA
MSDUs that are sent by a mesh STA as a consequence of an MA-UNITDATA.request primitive with an
individual destination address and are destined to an address that is different from the mesh STA at the end
of a mesh path shall be transmitted using a frame with the four-address MAC header format [with the
Address Extension Mode subfield in the Mesh Control field set to “Address5&6” (see Table 9-20)], where
the Mesh Address Extension subfield in the Mesh Control field carries the addresses of the end stations, as
specified in row “Mesh Data (proxied, individually addressed)” of Table 9-42. The additional addresses 5
and 6 are defined as follows:
— Address 5: The address of the destination end mesh STA (may be the same as Address 3 if the
destination is the mesh STA at the end of the mesh path)
— Address 6: The address of the source end mesh STA (may be the same as Address 4 if the source is
the mesh STA at the beginning of the mesh path)
NOTE—The destination address is distinct from the mesh STA at the end of the mesh path in two cases: 1) when the
destination is an external address and 2) when the destination is a mesh STA distinct from the destination mesh STA at
the end of the mesh path. The former case is described in 14.11.3. The latter case might occur if a source mesh STA
1494
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
sends the MSDU to another intermediate mesh STA that sends the MSDU on a different mesh path to the destination
mesh STA in the MBSS.
The Mesh TTL subfield in the Mesh Control field shall be set to dot11MeshTTL.The MSDUs are forwarded
multiple hops, limited by the Mesh TTL value.
The source mesh STA shall set the Mesh Sequence Number subfield in the Mesh Control field to a value
from a modulo 232 counter that is incremented by 1 for each new MSDU transmitted with a Mesh Control
field and for each new MMPDU transmitted using a Multihop Action frame.
10.35.3.2 At intermediate and destination mesh STAs (individually addressed)
On receipt of an individually addressed mesh Data frame, a mesh STA shall perform the following:
a) The mesh STA shall decipher the frame and check it for authenticity. If it is not from a peer mesh
STA, the frame shall be silently discarded.
b) The mesh STA shall check to see whether the MAC address in the Address 3 field is a known
destination address; if it is an unknown destination address, the mesh STA may perform any of the
following three actions:
1) Silently discard the frame.
2) Trigger a path discovery procedure depending on the path selection protocol that is currently
active in the mesh BSS. For HWMP, see 14.10.9.3 Case A.
3) Inform the mesh STA in Address 2 that the destination is unreachable depending on the path
selection protocol that is currently active in the mesh BSS. For HWMP, see 14.10.11.3 Case B.
c) If Address 2 is not one of the precursors for this destination mesh STA (see 10.35.2), the frame shall
be discarded.
If the frame is not discarded and one or more MSDUs are collected from the frame, the mesh STA may
detect duplicate MSDUs according to 10.35.6 and discard them.
If Address 3 does not match the mesh STA’s own address, but is a known individual destination MAC
address in the forwarding information then the following actions are taken:
— The lifetime of the forwarding information to the destination (Address 3) is set to its initial value.
— The lifetime of the forwarding information to the source (Address 4) is set to its initial value.
— The lifetime of the precursor list entry for the precursor to the destination (Address 2) is set to the
maximum of the initial value and the current value.
— The lifetime of the precursor list entry for the precursor to the source (next hop to the destination) is
set to the maximum of the initial value and the current value.
— The Mesh TTL in the corresponding Mesh Control field of the collected MSDU is decremented by
1. If zero has been reached, the MSDU shall be discarded.
— If the MSDU has not been discarded, the mesh STA shall forward the MSDU via a frame with the
Address 1 field set to the MAC address of the next-hop mesh STA as determined from the
forwarding information (see 10.35.2) and the Address 2 field set to its own MAC address and queue
the frame for transmission.
If Address 3 matches the mesh STA’s own MAC address, the following actions are taken:
— The lifetime of the forwarding information to the source (Address 4) is set to its initial value.
— The lifetime of the precursor list entry for the precursor to the destination (Address 2) is set to the
maximum of the initial value and the current value.
1495
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— If the Address Extension Mode subfield in the Mesh Control field is “None” (see Table 9-20), the
MA-UNITDATA.indication primitive is passed from the MAC sublayer entity to the LLC sublayer
entity or entities.
— If the Address Extension Mode subfield in the Mesh Control field is “Address5&6” (see Table 9-20)
and Address 5 is equal to Address 3, the mesh STA is the final destination of the MSDU, and the
MA-UNITDATA.indication primitive is passed from the MAC sublayer entity to the LLC sublayer
entity or entities.
— If the Address Extension Mode subfield in the Mesh Control field is “Address5&6” (see Table 9-20)
and Address 5 is a known destination MAC address in the forwarding information (mesh STA), the
mesh STA shall forward the MSDU via a frame as described in 10.35.3.1 with the Address 3 field
set to the MAC Address of the Address 5 field.
— If the Address Extension Mode subfield in the Mesh Control field is “Address5&6” (see Table 9-
20), the MSDU is forwarded according to 14.11.3.2 in all other cases.
If Address 3 matches the group address, the mesh STA shall perform the procedures as given in 10.35.4.2.
Note that during the forwarding process at intermediate mesh STAs, the content of the MSDU is not
changed.
10.35.4 Addressing and forwarding of group addressed mesh Data frames
10.35.4.1 At source mesh STAs (group addressed)
MSDUs sent by a mesh STA (as a consequence of an MA-UNITDATA.request primitive with a group
destination address) shall be transmitted using a group addressed mesh Data frame (with the Address
Extension Mode subfield in the Mesh Control field set to “None” (see Table 9-20)) (see row “Mesh Data
(group addressed)” in Table 9-42). An implementation may circumvent the unreliability of group addressed
transmissions by using multiple individually addressed mesh Data frames, which are individually
acknowledged. In such case, the frame may be converted to individually addressed frames and transmitted
as individually addressed mesh Data frames to each peer mesh STA as described in 10.35.3.1 with the
Address 3 field set to the group address. The circumstances for choosing this method are outside the scope
of the standard.
In group addressed mesh Data frames, the address fields are set as follows:
— Address 1: The group address
— Address 2: The address of the transmitter mesh STA
— Address 3: The address of the source mesh STA
The source mesh STA shall set the Mesh TTL subfield in the Mesh Control field to dot11MeshTTL in order
to control the hop count. The MSDUs are forwarded multiple hops, limited by the Mesh TTL value. For
example, if the Mesh TTL subfield is 1, MSDUs are delivered only to immediate neighbors.
The source mesh STA shall set the Mesh Sequence Number subfield in the Mesh Control field to a value
from a modulo 232 counter that is incremented by 1 for each new MSDU transmitted with a Mesh Control
field and for each new MMPDU transmitted using a Multihop Action frame.
Procedures that enhance the reliability or efficiency of group addressed transmissions are outside the scope
of this standard.
1496
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.35.4.2 At recipient mesh STAs (group addressed)
On receipt of a group addressed mesh Data frame with Address 1 (DA) equal to the group address, or on
receipt of an individually addressed mesh Data frame with Address 3 (Mesh DA) equal to the group address,
a mesh STA shall perform the following:
a) The mesh STA shall decipher the frame and check it for authenticity. If it is not from a peer mesh
STA, the frame shall be silently discarded.
b) If the frame is not discarded and one or more MSDUs are collected from the frame, the mesh STA
may detect duplicate MSDUs according to 10.35.6 and discard them.
c) The mesh STA decrements the Mesh TTL in the Mesh Control field. If the Mesh TTL value has
reached zero, the corresponding MSDU shall not be forwarded to other mesh STAs.
d) If the Mesh TTL value has not reached zero and if dot11MeshForwarding is true, the mesh STA
shall forward the MSDU via a group address mesh Data frame with the Address 2 field set to its own
MAC address.
e) If the Address Extension Mode is “Address4” (see Table 9-20) and the recipient mesh STA is a
proxy mesh gate and if the Mesh TTL value has not reached zero and if dot11MeshForwarding is
true, the MSDU is forwarded according to 14.11.3.2.
When the SA and the Mesh SA are not identical (the source address is therefore an external address), the
MSDU shall be forwarded by using a frame with the three-address MAC header format [with the Address
Extension Mode subfield in the Mesh Control field set to “Address4” (see Table 9-20)] as specified in row
“Mesh Data (proxied, group addressed)” of Table 9-42. Otherwise, the MSDU shall be forwarded by using a
frame with the three-address MAC header format [with the Address Extension Mode subfield in the
Mesh Control field set to “None” (see Table 9-20)] as specified in row “Mesh Data (group addressed)” of
Table 9-42.
An implementation may circumvent the unreliability of group addressed transmissions by using multiple
individually addressed mesh Data frames, which are individually acknowledged. In such case, the frame
may be converted to individually addressed frames and transmitted as an individually addressed mesh Data
frame to each peer mesh STAs as described in 10.35.3.2 with the Address 3 field set to the group address. If
the Address Extension Mode subfield in the Mesh Control field in the group addressed mesh Data frame is
equal to “Address4” (see Table 9-20), the Address Extension Mode subfield in the Mesh Control field in the
individually addressed mesh Data frames is set to “Address5&6” (see Table 9-20), the Address 5 field is set
to the group address, and the Address 6 field set to the Source Address contained in the Address 4 field of
the group addressed mesh Data frame. The circumstances for choosing this method and the ability to
determine all of the addresses of the neighbor peer mesh STAs are beyond the scope of the standard.
If one or more MSDUs collected from the frame have not been discarded, the MA-UNITDATA.indication
primitive is passed from the MAC sublayer entity to the LLC sublayer entity or entities.
10.35.5 Addressing of Management frames and MMPDU forwarding
10.35.5.1 General
All MMPDUs except MMPDUs transmitted using Multihop Action frames are transmitted over only one
hop to peer mesh STAs.
NOTE—In several cases, the reception and processing of an Action frame leads to the transmission of a new Action
frame of the same type that might include an identical or a modified version of the contents from the elements of the
received Action frame. This is called propagation in contrast to forwarding.
A mesh STA may convert a group addressed Management frame to individually addressed Management
frames and transmit them as individually addressed frames to each peer mesh STA, if the frame is intended
1497
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
to be delivered only to its peer mesh STAs. The circumstances for choosing this method are outside the
scope of the standard.
10.35.5.2 MMPDU forwarding using individually addressed Multihop Action frames
MMPDUs sent by a mesh STA and destined to another mesh STA in the MBSS using individually addressed
Multihop Action frames (see 9.6.18) shall be transmitted using a Management frame with the three-address
MAC header format (with the Address Extension Mode subfield in the Mesh Control field set to “Address4”
(see Table 9-20)), where the four address fields are set as follows (see row “Multihop Action (individually
addressed)”) in Table 9-42:
— Address 1: The address of the next-hop mesh STA (toward the destination mesh STA according to
the forwarding information—see 10.35.2.
— Address 2: The address of the transmitter mesh STA.
— Address 3: The address of the destination mesh STA.
— Address 4: The address of the source mesh STA.
The source mesh STA shall set the Mesh TTL subfield in the Mesh Control field to dot11MeshTTL, and set
the Mesh Sequence Number subfield in the Mesh Control field to a value from a modulo 232 counter that is
incremented by 1 for each new MSDU transmitted with a Mesh Control field and for each new MMPDU
transmitted using a Multihop Action frame.
At intermediate and destination mesh STAs, on receipt of an individually addressed Multihop Action frame,
the address matching, the reception procedures, the forwarding information update, and the Mesh TTL
decrement are performed as described in 10.35.3.2, and the MMPDU is forwarded according to the
forwarding information and the procedures in 10.35.3.2.
At intermediate mesh STAs, frame fields following the Mesh Control field are not required to be examined.
If the Address 3 in the received Multihop Action frame matches the mesh STA’s own MAC address or the
group address, the mesh STA (destination mesh STA) shall process the content of the MMPDU.
10.35.5.3 MMPDU forwarding using group addressed Multihop Action frames
MMPDUs sent by a mesh STA and destined to all other mesh STAs in the MBSS using group addressed
Multihop Action frames (see 9.6.18) shall be transmitted using a Management frame with the three-address
MAC header format (with the Address Extension Mode subfield in the Mesh Control field set to “None”
(see Table 9-20)), where the three address fields are set as follows (see row “Multihop Action (group
addressed)” in Table 9-42):
— Address 1: The group address
— Address 2: The address of the transmitter mesh STA
— Address 3: The address of the source mesh STA
An implementation may circumvent the unreliability of group addressed transmissions by using multiple
individually addressed Multihop Action frames, which are individually acknowledged. In such case, the
frame may be converted to individually addressed frames and transmitted as individually addressed
Multihop Action frames to each peer mesh STA as described in 10.35.5.2 with the Address 3 field set to the
group address. The circumstances for choosing this method are outside the scope of the standard.
The source mesh STA shall set the Mesh TTL subfield in the Mesh Control field to dot11MeshTTL, and set
the Mesh Sequence Number subfield in the Mesh Control field to a value from a modulo 232 counter that is
incremented by 1 for each new MSDU transmitted with a Mesh Control field and for each new MMPDU
transmitted using a Multihop Action frame.
1498
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
At recipient mesh STAs, on receipt of Multihop Action frame, the address matching, the reception
procedures, the forwarding information update, and the Mesh TTL decrement are performed as described in
10.35.4.2, and the MMPDU is forwarded according to the forwarding information and the procedures in
10.35.4.2.
If the Address 1 in the received Multihop Action frame matches the group address, the mesh STA shall
process the content of the MMPDU.
Procedures that enhance the reliability or efficiency of group addressed transmissions are outside the scope
of this standard.
10.35.6 Detection of duplicate MSDUs/MMPDUs
A mesh STA may receive multiple copies of the same MSDU or MMPDU from different neighbor peer
mesh STAs.
The filtering of such duplicates is facilitated through the inclusion of a Mesh Sequence Number subfield in
the Mesh Control field in mesh Data frames and Multihop Action frames as specified in 9.2.4.7.3.
The receiving mesh STA shall keep a cache of recently received
tuples. The Mesh Source Address (Mesh SA) is contained in Address 4 for individually addressed mesh
Data frames and Multihop Action frames. The Mesh Source Address (Mesh SA) is contained in Address 3
for group addressed mesh Data frames.
A mesh STA shall reject an MSDU/MMPDU with a Mesh Control field as a duplicate if it matches a tuple of an entry in the cache.
The rules in 10.3.2.11 also apply to the filtering of duplicates sent by the same neighbor peer mesh STA.
10.35.7 Mesh STAs that do not forward
A mesh STA that has dot11MeshForwarding equal to false does not forward either MSDUs, or Multihop
Action frames. The circumstances in which a mesh STA may be allowed to become a non- forwarding entity
and the authority to set dot11MeshForwarding to false are beyond the scope of this standard.
A mesh STA that does not forward is a special case of a mesh STA. Such mechanism depends on whether
the path selection protocol provides a mechanism to allow mesh STAs not to participate in forwarding. The
HWMP path selection protocol provides such a mechanism; see 14.10.
10.35.8 MSDU forwarding and unknown destination
A source mesh STA in the MBSS might not able to forward an MSDU that it has received as a consequence
of an MA-UNITDATA.request primitive with an individual destination address. This is the case if the
destination of the MSDU is unknown to the mesh STA. The destination is unknown to a mesh STA if the
mesh STA has no forwarding information for this destination or if the destination is not in its proxy
information as an external STA (see 14.11.4.2). Note that the procedure to determine that an address is
unknown depends on the active path selection protocol. It might require an attempt to establish a path to the
destination (see 14.8).
If the source mesh STA is not able to forward the MSDU because its destination is unknown, the mesh STA
shall assume that the destination is outside the MBSS and shall forward the MSDU to known mesh gates in
the MBSS as one or more individually addressed frames according to the procedures for frame addressing
and data forwarding of individually addressed frames at source mesh STAs in an MBSS (10.35.3.1). These
frame(s) shall be transmitted using the four-address MAC header format (with the Address Extension Mode
1499
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
subfield in the Mesh Control field set to “Address5&6” (see Table 9-20)), where the Mesh Address
Extension subfield in the Mesh Control field carries the address of the destination end station, as specified in
row “Mesh Data (proxied, individually addressed)” of Table 9-42. The address fields are set as follows:
— Address 1: The address of the next-hop mesh STA (toward the known mesh gate in the MBSS
according to the forwarding information—see 10.35.2).
— Address 2: The address of the source mesh STA.
— Address 3: The address of the known mesh STA in the MBSS.
— Address 4: The address of the source mesh STA.
— Address 5: The address of the destination end mesh STA, which is the unknown destination address
of the MSDU
— Address 6: The address of the source mesh STA, which is the same as Address 4
If there is no mesh gate available, the mesh STA shall silently discard the MSDU.
Discovery of mesh gates by mesh STAs is performed using propagated elements, such as a GANN
(14.11.2). Other methods specific to the HWMP path selection protocol are also available, such as the
proactive PREQ mechanism (14.10.4.2) or the proactive RANN mechanism (14.10.4.3), when the Gate
Announcement subfield in the Flags field in these HWMP elements is set to 1.
10.36 DMG channel access
10.36.1 General
Channel access by a DMG STA is related to beacon interval timing and is coordinated using a schedule. A
DMG STA operating as an AP or PCP generates the schedule and communicates it to STAs using DMG
Beacon and Announce frames. A non-PCP STA that is a non-AP STA and that receives scheduling
information accesses the medium during the scheduled periods using the access rules specific to that period.
Medium access rules to establish a BSS are defined in 10.37 and 11.1.4.
10.36.2 Access periods within a beacon interval
Medium time within a DMG BSS is divided into beacon intervals. Subdivisions within the beacon interval
are called access periods. Different access periods within a beacon interval have different access rules. The
access periods are described in a schedule that is communicated by the AP or PCP to the non-PCP and non-
AP STAs within the BSS. The schedule communicated by the AP or PCP can include the following access
periods:
— BTI: An access period during which one or more DMG Beacon frames is transmitted. Not all DMG
Beacon frames are detectable by all non-PCP and non-AP STAs (see 10.38.4). Not all beacon
intervals contain a BTI. A non-PCP STA that is a non-AP STA shall not transmit during the BTI of
the BSS of which it is a member.
— A-BFT: An access period during which beamforming training is performed with the STA that
transmitted a DMG Beacon frame during the preceding BTI (see 10.38.5. The presence of the A-
BFT is optional and signaled in DMG Beacon frames.
— ATI: A request-response based management access period between the AP or PCP and non-AP and
non-PCP STAs (see 10.36.3). The presence of the ATI is optional and signaled in DMG Beacon
frames.
— CBAP: An access period during which frame exchanges between STAs that use the channel access
rules described in 10.36.5.
— SP: An access period during which frame exchanges between STAs use the channel access rules
described in 10.36.6.2.
1500
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The BHI comprises the BTI, A-BFT and ATI. The DTI, in turn, comprises contention based access periods
(CBAPs) and scheduled service periods (SPs). There is a single BHI and a single DTI per beacon interval.
Figure 10-54 illustrates an example of access periods within a beacon interval comprising a BTI, an A-BFT,
an ATI, and two CBAPs and SPs within the DTI. Any combination in the number and order of SPs and
CBAPs can be present in the DTI.
Beacon Interval
BHI DTI
BTI A-BFT ATI CBAP 1 SP 1 SP 2 CBAP 2
Time
Figure 10-54—Example of access periods within a beacon interval
The details of the access protocol within each of the access periods are described in the remaining
subclauses of 10.36 and within 10.38.
In the ATI, a non-AP and non-PCP STA shall be ready to receive a transmission from the AP or PCP at least
RxAdvanceTime before the expected transmission of a request frame. The destination STA of an SP shall be
ready to receive a transmission from the source STA of the SP at least RxAdvanceTime before the start of
the SP. A STA that participates in a CBAP shall be ready to receive a transmission within the CBAP at least
RxAdvanceTime before the start of the CBAP plus DIFS. In the A-BFT, the AP or PCP should be ready to
receive a transmission from a non-AP and non-PCP STA at least RxAdvanceTime before the start of an
SSW slot. In all of the preceding rules, RxAdvanceTime is defined as follows:
C T DI
RxAdvanceTime = Ceil -----------------
- + T P , T TR
6
10
where
C is aDMGTSFAccuracy, in ppm
TDI is the time elapsed since a synchronizing reference event, in µs. The synchronizing event is the
reception of the Timestamp field from the AP or PCP
TP is aAirPropagationTime, in µs
TTR is aTSFResolution, in µs
10.36.3 ATI transmission rules
The presence of an ATI in the current beacon interval is signaled by the ATI Present field set to 1 in the
current DMG Beacon frame(9.3.4.2). The Next DMG ATI element (9.4.2.135) transmitted in the Announce
frame or in the DMG Beacon frame indicates the earliest start time for the next ATI in a subsequent beacon
interval and ATI duration.
1501
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An example of an ATI is shown in Figure 10-55.
ATI
AP
Request Request Request
or Ack
1 2 N
PCP:
...
Response Response
STA: Ack
2 N
STA 1 STA 2 STA N
Figure 10-55—Example of frame exchanges during the ATI
During an ATI, request and response frames are exchanged between the AP or PCP and any subset of STAs.
The AP or PCP initiates all frame exchanges that occur during the ATI. The ATI shall not start sooner than
Max(guard time, MBIFS), where guard time is defined in 10.36.6.5, following the end of the previous A-
BFT when an A-BFT is present in the beacon interval or following the end of the previous BTI when an A-
BFT is not present but a BTI is present in the beacon interval. The ATI shall not start before TBTT if the
ATI is the first period in the beacon interval (the ATI is never the first period in the beacon interval in an
infrastructure BSS; see 11.1.2.1). Once the ATI starts, the AP or PCP may start transmission of a request
frame immediately or it may delay the transmission of the request frame if the medium is determined by the
CCA mechanism to be busy.
During each ATI the AP or PCP shall schedule transmissions to a non-AP and non-PCP STA if the non-AP
and non-PCP STA Heartbeat field in the STA’s DMG Capabilities element within the Association Request
frame of the last successful association attempt is 1. If the non-AP and non-PCP STA does not respond to
the frame transmitted by the AP or PCP, the AP or PCP shall use the DMG Control modulation class
(10.7.7.1) at its next transmission attempt to the non-AP and non-PCP STA. The AP or PCP shall use the
DMG Control modulation class for all subsequent transmissions to the non-AP and non-PCP STA until it
receives a valid frame from the non-AP and non-PCP STA.
A non-AP and non-PCP STA shall not transmit during the ATI except in response to a received individually
addressed frame whose TA field contains the AP’s or PCP’s MAC address and whose RA field contains the
STA’s MAC address.
During the ATI a STA shall not transmit frames that are not request or response frames. Request and
response frames transmitted during the ATI shall be one of the following:
— A Management frame
— An Ack frame
— A Grant, Poll, RTS or DMG CTS frame when transmitted as a request frame
— An SPR or DMG CTS frame when transmitted as a response frame
— A frame with the Type subfield equal to Data only as part of an authentication exchange to reach a
RSNA security association
1502
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—The Announce frame is designed to be used primarily during the ATI and can perform functions of a DMG
Beacon frame.
The transmission of Poll frames during the ATI follows the rules described in 10.36.7. The Response Offset
field within a Poll frame transmitted during the ATI shall be set to 0.
The transmission of Grant frame during the ATI follows the rules described in 10.36.7.3.
Individually addressed request frames transmitted during the ATI shall not be sent using Action No Ack
frames.
During the ATI, after an AP or PCP transmits an individually addressed request frame (such as an Announce
frame) to a non-AP and non-PCP STA, and the STA receives that frame, the STA shall transmit a response
frame addressed to the AP or PCP. The transmission of the response frame shall commence one SIFS after
the reception of the request frame. The AP or PCP shall interpret the receipt of the response frame as an
acknowledgment of the request frame. Response frames transmitted by non-AP and non-PCP STAs during
the ATI shall be individually addressed to the AP or PCP.
NOTE—STAs do not transmit a response frame to the AP or PCP when they receive a request frame from the AP or
PCP with the RA equal to a group address (see 10.3.6).
The Duration field of a request frame transmitted during the ATI shall be set to cover the remaining duration
of the ATI at the end of the request frame transmission. The Duration field of a response frame transmitted
during the ATI shall be set to the value of the Duration field within the previously received request frame
minus SIFS and minus the duration of the response frame transmission.
When a transmission by a STA is expected by an AP or PCP and a SIFS elapses without its receipt, the AP
or PCP may either repeat its individually addressed transmission to that STA or, as early as one PIFS after
the end of its previous transmission, transmit a frame to any other STA.
NOTE—If acknowledgment is required, the AP or PCP transmits an Ack frame to acknowledge the reception of a
response frame during the ATI (see Figure 10-55).
Multiple request and response frame exchanges between the AP or PCP and a STA might occur during a
single ATI.
10.36.4 DTI transmission rules
During the DTI, a STA may initiate a frame exchange (following the DMG channel access rules) if any of
the following conditions are met:
a) During a CBAP for which the STA is identified or included as source or destination
(10.36.6.3, 10.36.7, and 10.36.8)
b) During an SP for which the STA is identified as source or destination (10.36.6.2 and 10.36.7)
and shall not initiate a frame exchange if none of these conditions are met. A STA initiating data transfer
shall check that the transaction, including acknowledgments, completes before the end of the CBAP or SP in
which it was initiated.
When the entire DTI is allocated to CBAP (that is, the CBAP Only field is 1 in the DMG Parameters field),
the ATI Present field within the DMG Beacon frame containing the DMG Parameters field shall be set to 0.
A DMG STA shall be capable of processing Grant frames. A non-AP and non-PCP DMG STA shall be
capable of processing Poll frames and the Extended Schedule element. An AP or PCP shall be capable of
processing SPR frames transmitted by a non-AP and non-PCP STA and responding to an SPR frame with a
Grant frame.
1503
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DMG low-power SC mode (20.7) may be used only within SPs that have the LP SC Used subfield
within the Extended Schedule element equal to 1 and shall not be used otherwise. A STA supports the DMG
low-power SC mode if the Low-Power SC Mode Supported subfield within its DMG Capabilities element is
1. A STA that supports the DMG low-power SC mode shall not initiate a frame exchange using the DMG
low-power SC mode unless the STAs identified in the RA field of all MPDUs contained within the PPDU
support the DMG low-power SC mode. A STA can use the procedure described in 11.30.1 to discover the
capabilities of another STA.
A STA that receives a Grant frame and that has the Grant Ack Supported field equal to 1 in the STA’s DMG
Capabilities element shall respond with a Grant Ack frame SIFS interval after reception of the Grant frame.
In the transmitted Grant Ack frame, the STA shall copy the Source AID, Destination AID, and
Beamforming Training fields from the Grant frame that the Grant Ack frame is being sent in response to. A
STA that receives a group addressed Grant frame shall not respond with Grant Ack frame. A STA that
receives a Grant frame and that does not have the Grant Ack Supported field equal to 1 in the STA’s DMG
Capabilities element shall not respond with a Grant Ack frame.
10.36.5 Contention based access period (CBAP) transmission rules
The definition of contention based transmission rules used within a CBAP is provided in 10.3 and in 10.22.
This subclause specifies additional rules applicable to the CBAP.
A STA shall not initiate a frame exchange within a CBAP unless at least one of the following conditions is
met:
— The value of the CBAP Only field is equal to 1 and the value of the CBAP Source field is equal to 0
within the DMG Parameters field of the DMG Beacon frame that allocates the CBAP
— The STA is an AP or PCP and the value of the CBAP Only field is equal to 1 and the value of the
CBAP Source field is equal to 1 within the DMG Parameters field of the DMG Beacon frame that
allocates the CBAP
— The value of the Source AID field of the CBAP is equal to the broadcast AID
— The STA’s AID is equal to the value of the Source AID field of the CBAP
— The STA’s AID is equal to the value of the Destination AID field of the CBAP
If a STA’s AID is equal to the value of the Source AID field of a CBAP allocation or if a STA performs in
the role of AP or PCP and both the CBAP Only and CBAP Source fields are equal to 1 in the DMG Beacon
frame that allocates a CBAP, the STA may initiate a frame transmission within the CBAP immediately after
the medium is determined to be idle for one PIFS.
A BF initiator (10.38) should not initiate an SLS phase within a CBAP if there is not enough time within the
CBAP to complete the SLS phase.
A STA shall not extend a transmission frame exchange sequence that started during a CBAP beyond the end
of that CBAP. A STA that initiates a sequence shall check that the frame exchange sequence, including any
control frame responses, completes before the end of the CBAP.
Operation of the EDCAF is suspended at the end of a CBAP and is resumed at the beginning of the fol-
lowing CBAP. When the EDCAF is being suspended, the values of the backoff and NAVs shall remain
unchanged until the start of the following CBAP. A TXOP may be obtained by a DMG STA winning an
instance of EDCA contention (see 10.22.2)).
At the beginning of a TXOP with a TXOP responder that has the Heartbeat field in the TXOP responder’s
DMG Capabilities element equal to 1, the following rules apply:
1504
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The TXOP holder shall transmit a frame to the TXOP responder using the DMG Control modulation
class before it uses any other modulation class for transmission if the time elapsed since the last
frame received from the TXOP responder is larger than or equal to the Heartbeat Elapsed Time
value computed using the Heartbeat Elapsed Indication field within the TXOP responder’s DMG
Capabilities element.
— The TXOP holder may transmit a frame using a modulation class other than the DMG Control
modulation class at the start of the TXOP if the time elapsed since the last frame received from the
TXOP responder is shorter than the Heartbeat Elapsed Time value computed using the Heartbeat
Elapsed Indication field within the TXOP responder’s DMG Capabilities element.
The frame sent by the STA at the beginning of the TXOP may be an RTS frame or a DMG CTS-to-self
frame.
Within a CBAP a STA with multiple DMG antennas should use only one DMG antenna in its frame
transmission, CCA and frame reception, except if it is the initiator or responder in an SLS (10.38). The
algorithm to select a DMG antenna and switch the active DMG antenna is implementation dependent.
Within CBAPs a STA that changed to a different DMG antenna in order to transmit should perform CCA on
that DMG antenna until a frame is detected by which it can set its NAV, or until a period of time equal to the
dot11DMGNavSync has transpired, whichever is earlier.
10.36.6 Channel access in scheduled DTI
10.36.6.1 General
An AP or PCP schedules each allocation with a specified start time from the TSF and with a fixed duration.
An allocation can be an SP, where ownership of channel time is granted to a single STA, or a CBAP, where
STAs can compete for channel access. The start time of each allocation is based on the TSF of the AP or
PCP.
The AP or PCP may schedule SPs or CBAPs only during the DTI of a beacon interval, following the end of
an allocated BTI, A-BFT, and ATI when any of these periods are present in the beacon interval.
The schedule of the DTI of a beacon interval shall be communicated through the Extended Schedule
element. The AP or PCP transmits the Extended Schedule element in either or both an Announce frame or a
DMG Beacon frame. The Extended Schedule element shall contain the scheduling information of all
allocations in the DTI. The same Allocation field shall not appear more than once in the Extended Schedule
element transmitted in a beacon interval. The content of the Extended Schedule element communicated in a
beacon interval shall not change if transmitted more than once in the beacon interval, except that if the STA
transmitting the Extended Schedule element is a PCP with multiple DMG antennas then the value of the
PCP Active field of CBAP allocations within the Extended Schedule element might change when this
element is transmitted through different DMG antennas. The AP or PCP should schedule SPs for a STA
such that the scheduled SPs do not overlap in time with the traffic scheduling constraints indicated by this
STA in the Traffic Scheduling Constraint Set field of the associated DMG TSPEC element.
When scheduling a nonpseudo-static allocation or changing the start time of an existing pseudo-static
allocation that has a non-AP and non-PCP STA as a source DMG STA or as a destination DMG STA of the
allocation, an AP or PCP shall set the start time of the allocation to no less than
aMinAllocationDeliveryTime after the last Extended Schedule element containing this allocation is
transmitted by the AP or PCP.
NOTE—This rule does not apply to the case when an AP or PCP schedules a new pseudo-static allocation.
When receiving an Extended Schedule element containing a new pseudo-static allocation in which it is
expected to participate, a non-AP and non-PCP STA ignores the allocation if the value of the TSF at the time
1505
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the frame containing the Extended Schedule element is received is greater than the value of the TSF at the
start of the pseudo-static allocation; this allocation is called an obsolete allocation. The value of the TSF at
the start of the pseudo-static allocation is constructed using the value of the Allocation Start Time field
within the Allocation field for the pseudo-static allocation.
An SP or CBAP allocation within an Extended Schedule element may comprise one or more individual
allocations. The start time of each individual allocation of an SP or CBAP is given by
(Astart + (i – 1) × Aperiod)
where
Astart is the value of the Allocation Start field for the SP or CBAP
Aperiod is the value of the Allocation Block Period field for the SP or CBAP
i is an integer greater than 0 and less than or equal to the value of the Number of Blocks field for
the SP or CBAP
The end of the ith individual SP or CBAP allocation is computed by adding the start time of the ith individual
allocation to the value of the Allocation Block Duration field for the corresponding SP or CBAP allocation.
If the PCP Active subfield in the Allocation field for an allocation within an Extended Schedule element is
1, the PCP shall be in the receive state for the duration of that allocation, except when transmitting during
that allocation. The AP shall set the PCP Active field to 1 for every allocation within an Extended Schedule
element transmitted by the AP.
10.36.6.2 Service period (SP) allocation
The AP or PCP shall set the AllocationType subfield to 0 in an Allocation field within an Extended Schedule
element to indicate an SP allocation.
An SP is assigned to the source DMG STA identified in the Source AID subfield in an Allocation field that
is not an obsolete allocation within the Extended Schedule element. The source DMG STA shall initiate the
frame exchange sequence that takes place during the SP at the start of the SP, except when the source DMG
STA intends to establish a DMG protected period in which case the rules described in 10.36.6.6 shall be
followed before the source DMG STA initiates the frame exchange in the SP. The SP allocation identifies
the TC or TS for which the allocation is made; however, the type of traffic transmitted is not restricted to the
specified TC or TS (11.4.1).
Except when transmitting a frame as part of the SP recovery procedure (10.36.6.7) or transmitting a
response to the source DMG STA or transmitting a PPDU as part of an RD response burst (10.28), the STA
identified by the Destination AID field in the Extended Schedule element should be in the receive state for
the duration of the SP in order to receive transmissions from the source DMG STA. If the Destination AID
field of the scheduled SP is equal to the broadcast AID and if the Source AID field of the scheduled SP is not
equal to the broadcast AID, then all STAs on the PBSS/infrastructure BSS should be in the receive state in
order to receive transmissions from the source DMG STA for the duration of the SP. Subclause 10.36.7
describes the rules for when the scheduled SP has both the Source and Destination AID fields equal to the
broadcast AID.
Only a STA identified as the source DMG STA or destination DMG STA of an SP may transmit during the
SP, except when the rules in 10.36.7, 10.36.8, or 10.36.9 are used.
At the beginning of an SP (except when the source DMG STA intends to establish a DMG protected period,
see 10.36.6.6 before the source DMG STA initiates the frame exchange in the SP, a source DMG STA shall
1506
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
transmit a frame to the destination DMG STA using the DMG Control modulation class before it uses any
other modulation class for transmission if the Heartbeat field in the destination DMG STA’s DMG
Capabilities element is 1. The frame sent by the source STA may be an RTS frame or a DMG CTS-to-self
frame. The frame sent by the source STA may be an SSW frame or a BRP packet if the source STA is
performing beamforming (10.7.7.5).
At the beginning of an SP, a destination DMG STA shall transmit a frame to the source DMG STA using the
DMG Control modulation class before it uses any other modulation for transmission if the Heartbeat field in
the source DMG STA’s DMG Capabilities element is 1 and the frame sent by the destination DMG STA is
the unsolicited DMG DTS as first frame in the SP of the STA performing DMG protected period
(10.36.6.6).
Any MAC entity coordinated by an MM-SME that belongs to an MMSL cluster identified by the Source
AID and Destination AID that are equal to, respectively, the Source AID and Destination AID of the
Allocation field that is not an obsolete allocation in the Extended Schedule element that allocates the SP may
transmit during the SP, if the STA sent an MMS element to the peer STA and the BeamLink Cluster field
within the MMS element is 1.
The AP or PCP may create SPs in its beacon interval with the source and destination AID subfields within
an Allocation field set to 255 to prevent transmissions during specific periods in the beacon interval.
The AP or PCP shall set the Beamforming Training subfield to 1 in the Allocation field for an SP within an
Extended Schedule element to indicate that the source DMG STA of this SP initiates beamforming training
with the destination DMG STA at the start of that SP. The source DMG STA and destination DMG STA of
the SP shall perform beamforming training as described in 10.38.
If the PCP Active subfield is 0 in the Allocation field for an SP within an Extended Schedule element,
neither the destination DMG STA of the SP nor the source DMG STA of the SP shall transmit to the PCP
during the SP if none of the STAs are the PCP.
In no case shall the source or destination DMG STA extend a transmission frame exchange sequence that
started during an SP beyond the end of that SP. A STA that initiates a sequence shall check that the frame
exchange sequence, including any control frame responses, completes before the end of the SP.
When scheduling two adjacent SPs, the AP or PCP should allocate the SPs separated by at least
aDMGPPMinListeningTime if one or more of the source or destination DMG STAs participate in both SPs.
Except for frames used for beamforming as described in 10.38, the source of an SP may retransmit a frame
PIFS after the end of the frame transmission in case a response frame is expected from the destination DMG
STA and a SIFS elapses without receipt of the expected transmission.
The source DMG STA can relinquish the remainder of an SP to the destination DMG STA by sending a
Grant frame to the destination DMG STA (10.36.7.3).
10.36.6.3 Contention based access period (CBAP) allocation
The AP or PCP shall set the AllocationType subfield to 1, the Source AID subfield to the broadcast AID or
to the AID of the source of the CBAP, and the Destination AID subfield to the broadcast AID or to the AID
of the destination of the CBAP in an Allocation field within an Extended Schedule element to indicate a
CBAP allocation.
All CBAPs are allocated by the AP or PCP, except when allocated by a non-AP and non-PCP STA with the
transmission of a Grant frame following an SP truncation (10.36.8). Multiple CBAPs may be present in a
beacon interval, with the location and duration of each determined by the AP or PCP and announced in the
1507
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Extended Schedule element. When only one CBAP is present and no other allocations exist for the DTI, then
the AP or PCP shall announce the presence of the CBAP by setting the CBAP Only field to 1 in the DMG
Parameters field of the DMG Beacon. If at least one non-CBAP allocation is present, or more than one
CBAP is present, or no allocations are present within a DTI, then the AP or PCP shall set the CBAP Only
field to 0 in the DMG Parameters field in the DMG Beacon frame transmitted during the BTI. The AP or
PCP shall set the CBAP Only field to 0 in the DMG Parameters field within a transmitted DMG Beacon
frame if the DMG Beacon frame contains at least one Extended Schedule element.
When the entire DTI is allocated to CBAP through the CBAP Only field in the DMG Parameters field, then
that CBAP is pseudo-static and exists for dot11MaxLostBeacons beacon intervals following the most
recently transmitted DMG Beacon frame that contained the indication, except if the CBAP is canceled by
the transmission by the AP or PCP of a DMG Beacon frame with the CBAP Only field of the DMG
Parameters field equal to 0 or an Announce frame with an Extended Schedule element. A guard time
(10.36.6.5) precedes a CBAP that is allocated through the CBAP Only field equal to 1.
Channel access during a CBAP shall follow the rules described in 10.36.5.
10.36.6.4 Pseudo-static allocations
An SP or CBAP allocation is pseudo-static if the Pseudo-static field in the Allocation control field for the SP
or CBAP is 1, or when the Extended Schedule element is not used and the CBAP Only field within the DMG
Parameters field of the DMG Beacon frame is 1 (10.36.5). A pseudo-static SP or CBAP recurs at the same
relative offset to TBTT and with the same duration in up to dot11MaxLostBeacons beacon intervals
following the last received Extended Schedule element containing the pseudo-static allocation or DMG
Beacon frame with the CBAP Only field equal to 1.
A STA might fail to receive up to (dot11MaxLostBeacons–1) Extended Schedule elements or DMG Beacon
frame with the CBAP Only field equal to 1 in consecutive beacon intervals and still may access the channel
during the pseudo-static SP or CBAP. The STA shall cease transmission during a pseudo-static allocation if
it fails to receive an Extended Schedule element or DMG Beacon frame with the CBAP Only field equal to
1 for dot11MaxLostBeacons consecutive beacon intervals.
The AP or PCP may change the offset relative to TBTT or the duration of a pseudo-static allocation by
transmitting a modified Allocation field in an Extended Schedule element before dot11MaxLostBeacons
beacon intervals from the last transmitted Extended Schedule element. The AP or PCP may delete a pseudo-
static allocation by transmitting an Extended Schedule element that does not include an allocation field
containing that allocation’s TID, source AID, and destination AID before the completion of
dot11MaxLostBeacons beacon intervals from the last transmitted Extended Schedule element. In either
case, the AP or PCP should not schedule a new allocation that overlaps with the previous pseudo-static
allocation for a minimum of dot11MaxLostBeacons beacon intervals unless both the new and previous
allocation are for a CBAP or the new allocation identifies the same source DMG STA as the original
pseudo-static allocation.
If the destination DMG STA of a pseudo-static allocation receives an Extended Schedule element with an
Allocation field that indicates a change in the schedule of the pseudo-static allocation, the STA should enter
receive state during the new pseudo-static allocation and may enter receive state during the previous
allocation to account for the time it can take the source DMG STA of the allocation to receive the updated
schedule.
10.36.6.5 Guard time
Guard time is the time between the end of one allocation and the start of the following allocation, provided
these allocations are not under spatial sharing (11.32). For the purpose of guard time insertion, an allocation
is defined as an SP, a CBAP, and a BTI or A-BFT or ATI that is immediately followed by a CBAP allocated
1508
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
through the CBAP Only field (10.36.6.3). Guard times are used to keep transmissions in adjacent allocations
from colliding. Figure 10-56 shows an example of the insertion of the guard time such that the allocations
are separated by at least the guard time, in case the STAs participating in the adjacent allocations drift
toward each other’s allocation.
Desirable allocation N+1
Desirable allocation N position
position
Late estimate of allocation N Early estimate of allocation
position N+1 position
Guard time
Figure 10-56—The guard time
The AP or PCP shall insert a sufficient guard time between adjacent allocations so that transmissions in
adjacent allocations do not overlap in time. For each of the adjacent allocations, guard times are calculated
based on the worst case drift and the maximum allowed number of lost DMG Beacons. The AP or PCP shall
insert a guard time (Tguard) between adjacent allocations that is not shorter than
Ai + 1 C Di + Ai + 1 + 1 C Di + 1
T guard = Ceil ---------------------------------------------------------------------------------------------------------------
- + SIFS + T P T TR
6
10
where
Ai is the value of MLB allocation i, and the value of Ai for each allocation depends on
whether the allocation is pseudo-static. Ai is 0 for a nonpseudo-static allocation and is
equal to dot11MaxLostBeacons if the allocation is pseudo-static
C is aDMGTSFAccuracy, in ppm
Di is the time elapsed since a synchronizing reference event, in µs. The synchronizing event
is the reception of the Timestamp field from the AP or PCP. For a pseudo-static allocation,
Di is equal to the beacon interval
SIFS in aSIFSTime, in µs
TP is aAirPropagationTime, in µs, which accounts for the propagation delay between the
STAs participating in the adjacent allocations
TTR is aTSFResolution, in µs
10.36.6.6 DMG protected period
10.36.6.6.1 Introduction
Communicating STA pairs of neighboring PBSS/infrastructure BSS might be granted SPs that potentially
create interference for neighbor PBSS/infrastructure BSS STA pairs. SPs within a PBSS/infrastructure BSS
can also experience such interference when spatial diversity conditions change. The intent of DMG
protected period is to minimize such interference by allowing any pair of STAs to protect their SP and
thereby limit the transmission of frames during the DMG protected period to not more than one pair of
potentially interfering pairs of communicating stations.
1509
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A DMG protected period can be created by the source DMG STA during an SP, and shall be created by the
source DMG STA if at least one of the following conditions is met:
— The source DMG STA is the AP or PCP of the BSS, the ECAPC Policy Enforced subfield within the
DMG Parameters field of the last DMG Beacon frame transmitted by the source DMG STA is equal
to 1, and the Protected Period Enforced field within the ECAPC Policy Detail field of the last
ECAPC Policy element transmitted by the source DMG STA is equal to 1.
— The source DMG STA is not the AP or PCP of the BSS, the ECAPC Policy Enforced subfield within
the DMG Parameters field of the last DMG Beacon frame received by the source DMG STA from
the AP or PCP of the BSS is equal to 1, and the Protected Period Enforced field within the ECAPC
Policy Detail field of the last ECAPC Policy element received by the source DMG STA from the AP
or PCP of the BSS is equal to 1.
Both the source DMG STA and destination DMG STA of an SP are owners of the DMG protected period.
During any DMG protected period, both stations can receive frames from the other participant.
A DMG STA that creates a DMG protected period during an SP in which it is a source DMG STA or a
destination DMG STA moves to and stays in listening mode during time interval that starts before the start
of the SP and remains in the listening mode until it is allowed to use the SP. The actual duration of the time
the STA stays in the listening mode is limited by the aDMGPPMinListeningTime parameter. The intent of
the listening mode is that the STA listens to other STAs that may have an SP that overlaps with the SP where
the STA is a source DMG STA or a destination DMG STA. The NAV mechanism is used to indicate the
time occupancy and if the STA is in the listening mode, it updates its NAVs. If the NAVs are not equal to 0,
the STA does not use the time of the SP in which it is a source DMG STA or a destination DMG STA. If
none of the NAVs has a nonzero value at the start of the SP, the STA is allowed to leave the listening mode
and use the SP. If at least one of the NAVs has a nonzero value at the start of the SP, the STA is allowed to
leave the listening mode and to use the time remaining in the SP after all NAVs become or already have
value zero.
Listening mode is a mode of operation during which a DMG STA is in receiving state and meets at least one
of the following conditions:
a) Its receiving antenna are in the quasi-omni mode.
b) Its receiving antenna are directed to the peer STA for which this DMG STA is either the destination
or source DMG STA.
A DMG protected period is established through an RTS/DMG CTS handshake. To create a DMG protected
period, the source DMG STA of an SP sends an RTS, and the recipient STA responds with a DMG CTS. If
the recipient STA responds with a DMG CTS, then a DMG protected period is established; otherwise, no
DMG protected period has been established. In all cases of DMG protected period establishment, the same
antenna configurations that are used by the STAs that establish the DMG protected period are used for the
exchange of frames during the DMG protected period.
10.36.6.6.2 DMG protected period establishment and maintenance
A DMG STA that attempts to create a DMG protected period during an SP shall transition to listening mode
not less than aDMGPPMinListeningTime before the attempt and shall remain in listening mode for at least
aDMGPPMinListeningTime before making the attempt.
A STA shall not issue an RTS frame to establish a DMG protected period if any of its NAVs is not equal
to 0.
A DMG STA that transmits an RTS frame to establish a DMG protected period during an SP in which it is a
source DMG STA shall not transmit the RTS frame outside of the SP and the value of the Duration field of
1510
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the RTS frame shall not exceed the duration of the portion of the SP that remains following the RTS frame
transmission.
In order to maintain STAs that are not aware of the establishment of the DMG protected period because they
have begun listening to the medium after the establishment of a DMG protected period, a STA that
established a DMG protected period should transmit additional RTSs. An additional RTS frame should be
sent at the end of every (aDMGPPMinListeningTime – aRTSTimeoutTime) interval during the DMG
protected period if the duration of the RTS/DMG CTS exchange is less than the time remaining in the SP.
A DMG STA that transmitted an RTS frame that established a DMG protected period shall use the same
antenna configuration as was used for the transmission of the RTS frame during transmission of Data
frame(s) during the DMG protected period.
A DMG STA should transition to listening mode not less than aDMGPPMinListeningTime before the start
of an SP in which it is the destination DMG STA.
During an SP in which it is the destination DMG STA, a DMG STA that receives a valid RTS frame with the
RA equal to the recipient DMG STA MAC address and the TA corresponding to the source DMG STA of
the SP shall respond with a DMG CTS frame if the recipient DMG STA has been in listening mode for
aDMGPPMinListeningTime at the start of the reception of the RTS frame and none of its NAVs has a
nonzero value.
During an SP in which it is the destination DMG STA, a DMG STA that receives a valid RTS frame with the
RA equal to the recipient DMG STA MAC address and the TA corresponding to the source DMG STA of
the SP shall not respond with a DMG CTS frame if at the start of the reception of the RTS frame the
recipient DMG STA has a nonzero value in at least one of its NAVs or the recipient DMG STA has not been
in listening mode for at least aDMGPPMinListeningTime.
During an SP in which it is the destination DMG STA, a DMG STA that receives a valid RTS frame with the
RA equal to the recipient DMG STA MAC address and the TA corresponding to the source DMG STA of
the SP may respond with a DMG DTS frame if at the start of the reception of the RTS frame the recipient
DMG STA has a nonzero value in at least one of its NAVs.
A DMG STA may transmit a DMG DTS frame after the expiration of the aRTSTimeoutTime time following
the start of an SP in which it is the destination DMG STA, if any of its NAVs has a nonzero value at that
time and no RTS has been received from the source DMG STA of the SP and the STA has been in listening
mode for aDMGPPMinListeningTime immediately preceding the start of transmission of the DMG DTS
frame. The destination DMG STA shall not transmit a DMG DTS frame if any portion of the DMG DTS
frame would be transmitted outside of the SP.
The value in the Duration field of a DMG DTS frame shall be calculated by subtracting the DMG DTS
frame transmission time from the NAV in the destination DMG STA that has the largest value at the time of
the start of the transmission of the DMG DTS frame. The NAV-DA and NAV-SA fields shall be set to the
MAC addresses that identify the NAV in the destination DMG STA that was used to determine the Duration
field value of the DMG DTS frame.
During an SP in which it is the destination DMG STA, a DMG STA that receives a valid RTS frame with the
RA equal to the recipient DMG STA MAC address and the TA corresponding to the source DMG STA of
the SP may respond with a DMG DTS frame if at the start of the reception of the RTS frame the recipient
DMG STA has not been in listening mode for at least aDMGPPMinListeningTime. The value of the
Duration field of the DMG DTS frame sent by the recipient DMG STA shall include the difference of
aDMGPPMinListeningTime and the elapsed time since the recipient DMG STA has been in listening mode,
and the NAV-SA and the NAV-DA fields of the DMG DTS frame shall contain the recipient DMG STA
MAC address.
1511
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A destination DMG STA that responds to an RTS frame with a DMG CTS or DMG DTS frame shall
transmit the response frame a SIFS interval after the end of the received RTS frame. A destination DMG
STA that transmits either a DMG CTS or a DMG DTS frame shall use the same antenna configuration for
the subsequent transmission of Ack frames and Data frames within the SP as is used for the transmission of
the DMG CTS or DMG DTS frame.
The source DMG STA of an SP can send a CF-End frame to the destination DMG STA of the SP to truncate
a DMG protected period. Regardless of whether this CF-End frame is sent, a CF-End frame is also sent to
the AP or PCP (see 10.36.8).
10.36.6.6.3 NAV update in DMG protected period
STAs in the listening mode shall update their NAVs according to the procedures described in 10.36.10.
NOTE—Support of multiple NAVs as defined in 10.36.10 is not limited to be used in the listening mode only and is also
used in any case a NAV update is performed.
When an SP terminates, either through time allocation expiration or truncation, then the source DMG STA
of that SP may reset any NAV to 0 that has an associated variable NAV_DTSCANCELABLE with a value
of true.
10.36.6.6.4 Interference report
A STA that receives an RTS and/or DMG CTS frame that updates the NAV and that overlaps in time with
an SP where the STA is destination or source, may report the overlap to the AP or PCP by sending a DMG
ADDTS Request frame variant (9.6.3.3.2) and including in the DMG TSPEC element (9.4.2.134) the
indication of interference in the Traffic Scheduling Constraint Set field (Figure 9-523). Transmission of the
DMG ADDTS Request frame variant shall follow the rules defined in 11.4, with the following exceptions.
The Allocation ID subfield of the DMG TSPEC element shall identify the allocation during which the
interference was detected. One ADDTS Request frame is generated and transmitted for each allocation
during which interference is detected.
The Traffic Scheduling Constraint Set field of the DMG TSPEC element may contain one or more
Constraint subfields. Each Constraint subfield provides information separately for each overlapping NAV
event. The following NAV events should be reported:
a) Nonzero NAV at start of SP
b) Extension of NAV during the SP, including extension of an initial nonzero NAV and transitioning of
the NAV from zero to nonzero value during the SP
c) Truncation of the NAV during the SP
The TSCONST Start Time field is set to the TSF value at which the NAV event is detected. For event a)
above, the TSCONST Start Time field shall be set to the start of the SP. For event b) above, the TSCONST
Start Time field shall be set to the time the NAV was updated or initialized to the value reported in the
TSCONST Duration field. For event c) above, the TSCONST Start Time field shall be set to the time the
NAV was reset.
The TSCONST Duration field shall be set to the NAV value at the TSCONST Start Time, which is the value
zero for event c).
The TSCONST Period shall be set to 0 indicating that the field is not applicable.
The Interferer MAC Address shall be set to the NAVDST of the NAV from which the TSCONST Start Time
was derived (10.36.10).
1512
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
All values conveyed in the Traffic Scheduling Constraint Set field shall refer to the allocation identified by
the value of the Allocation ID subfield of the TSPEC.
The value of other fields within the DMG TSPEC element shall comply with the rules specified in 11.4.
Use of the information conveyed in the Traffic Scheduling Constraint Set field is outside the scope of this
standard.
10.36.6.7 Service period recovery
When a non-AP and non-PCP STA fails to receive the Extended Schedule element for a beacon interval, the
non-AP and non-PCP STA has no knowledge of the nonpseudo-static SPs allocated during the beacon
interval that indicate it is the source DMG STA; therefore, it fails to transmit during those SPs. If the
destination of the nonpseudo-static SP is an AP or PCP and it does not receive any frames from the source
non-AP and non-PCP STA for the dot11SPIdleTimeout interval from the start of the SP, the AP or PCP may
truncate the SP and use the mechanism described in 10.36.7 to reallocate the remaining duration of the SP to
the source DMG STA of the SP or other STAs provided that it was a truncatable SP. If the SP is not a
truncatable SP, the PCP may stay in awake state or may switch to doze state. If the non-AP and non-PCP
STA failed to receive the Extended Schedule element from the AP or PCP for that beacon interval, it may
switch to doze state or may direct its receive antenna toward the AP or PCP to receive a grant during
nonpseudo-static SPs or CBAPs in the current beacon interval.
An AP or PCP may reclaim the entire time allocated in an SP between two non-AP and non-PCP STAs if the
following two conditions are met:
— The SP is announced within an Extended Schedule element transmitted during the ATI.
— The AP or PCP does not receive a response frame from at least one of the source and destination
non-AP and non-PCP STAs of that SP as part of the ATI exchange (10.36.3).
In either case described in this subclause, the AP or PCP may reallocate the reclaimed SP time as a CBAP,
SP, or take no further action. Otherwise, if none of these conditions apply, no time may be reclaimed.
10.36.7 Dynamic allocation of service period
10.36.7.1 General
Dynamic allocation of service period is employed to allocate channel time during scheduled SPs and
CBAPs. The procedure includes an optional Polling Period (PP) phase and a Grant Period (GP) phase.
Service periods allocated using this mechanism do not persist beyond a beacon interval. Persistent
allocations are created using the allocation mechanisms described in 11.4.
The PP Available field in the STA Availability element (9.4.2.133) indicates whether a STA participates in
the PP phase of the dynamic allocation of service period mechanism. A STA that participates in PP phase of
the dynamic allocation of service periods responds to Poll frames during the PP. A STA that participates in
dynamic allocation of service periods uses the time allocated through Grant frames during the GP to transmit
frames. A STA may set the PP Available field in a transmitted STA Availability element to 0 to indicate that
the STA does not respond to Poll frames during the PP and the GP.
NOTE—A STA can receive a Grant frame in periods of the beacon interval other than the GP, in which case the STA
uses the time allocated through the Grant frame.
The AP or PCP shall not transmit Poll frames to a STA whose PP Available field in the STA Availability
element is 0. The AP or PCP shall not dynamically allocate a service period to a STA that is in a doze BI
(11.2.7). An AP or PCP may transmit Poll frames to a STA from which the AP or PCP has not received a
STA Availability element with the PP Available field from the STA equal to 0.
1513
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An AP or PCP may dynamically allocate Service Periods during a scheduled SP for which both the source
and destination AID fields are set to the broadcast AID by setting the Truncatable subfield to 1 within the
Allocation field corresponding to the scheduled SP.
If a non-AP and non-PCP STA is neither source nor an individually addressed destination during a
truncatable SP and the non-AP and non-PCP STA participates in dynamic allocation of service periods and
the non-AP and non-PCP STA is in an awake BI, then the non-AP and non-PCP STA should be in the awake
state for the duration of the truncatable SP.
A non-AP and non-PCP STA that participates in dynamic allocation of service periods shall be in the awake
state for dot11MinPPDuration from the start of each truncatable SP for which both the source and the
destination AID fields are set to the broadcast AID and that occurs within each awake BI of that STA.
Following the expiration of dot11MinPPDuration, the non-AP and non-PCP STA should remain in the
awake state until the end of the truncatable SP.
A STA shall be in the awake state for dot11MinPPDuration from the start of each scheduled CBAP that
occurs within each awake BI of that STA. A STA that enters the doze state at any time during a CBAP and
then returns to the awake state later during that same CBAP shall perform CCA until a frame is detected by
which it can set its NAV, or until a period of time equal to the ProbeDelay has expired before it initiates a
transmission.
As described in 10.36.8, a STA that participates in dynamic allocation of service periods and that is neither
source nor destination during a truncatable SP can be in the receive state with its receive antennas
configured in a quasi-omni antenna pattern for the duration of the truncatable SP.
A STA that receives a Grant frame with an SP allocation for which it is either source or destination shall not
transmit longer than the time granted to it.
Any STA coordinated by an MM-SME that belongs to an MMSL cluster identified by the Source AID and
Destination AID that are equal to, respectively, the Source AID and Destination AID of the Dynamic
Allocation Info field in the Grant frame may transmit during the allocation, if the STA sent an MMS element
to the peer STA and the BeamLink Cluster field within the MMS element is 1.
An example of dynamic allocation of service period is shown in Figure 10-57.
Polling Period Grant Period
Data Transfer in SP
(PP) (GP)
Time
SBIFS SBIFS SIFS SIFS SIFS
AP or ... ...
Poll1 PollN SPR1 SPRN Grant1 Grant2
PCP:
STA: Poll1 ... PollN SPR1 ... SPRN Grant1 Grant2
SBIFS
Figure 10-57—Example of dynamic allocation of service period mechanism
1514
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.36.7.2 Polling period (PP)
An AP or PCP that uses a PP to dynamically allocate an SP within the DTI shall commence the PP at a time
instant indicated by at least one of the following:
— Any time during a scheduled SP for which the source AID and destination AID are equal to the
broadcast AID, excluding any time that has been allocated dynamically
— Any time during a TXOP within a scheduled CBAP for which the destination AID is equal to the
broadcast AID, excluding any time that has been allocated dynamically
— Any time during the relinquished channel time following an SP truncation, excluding any time that
has been allocated dynamically
The AP or PCP shall not transmit a frame during a PP if any portion of that frame would extend beyond the
end of the originally scheduled SP or CBAP.
During the PP, the AP or PCP may transmit individually addressed Poll frames to STAs to solicit SPR
frames from those STAs. The Duration field within each Poll frame i out of a total of n ( 0 i n )
transmitted Poll frames in the PP shall be calculated as defined by Equation (10-15).
D i = D i n + O m + Ceil TXTIME(SPR m) T TR (10-15)
where
Di,n is the duration of the remaining poll transmissions, in µs, given by
n
Di n = Ceil( TXTIME(Poll k) + SBIFS + A k + S T TR)
k = i+1
Om is the offset of SPR transmission m, in µs
SPRm is SPR transmission m
TTR is aTSFResolution, in µs
The AP or PCP expects an SPR frame in response to each transmitted Poll frame (i.e., m=n). The position of
each SPR frame in the sequence of SPR frames is indicated as j. Thus, j=1 refers to the first SPR frame
transmission in the sequence of SPR frames, and j=m refers to the last SPR frame transmission in the
sequence of SPR frames. Based on this, the Response Offset field within each Poll frame i transmitted in the
PP shall be calculated as follows:
Response Offseti = Di,n + Oj
where
Di,n is the duration of the remaining poll transmissions, defined in Equation (10-15).
Pollk is Poll transmission k
SBIFS is aSBIFSTime, in µs
Ak is the antenna switching time, in µs, which is 0 if the AP or PCP uses the same antenna to
transmit frame k and frame k+1 and is equal to dot11AntennaSwitchingTime otherwise
S is aSBIFSAccuracy, in µs
TTR is aTSFResolution, in µs
1515
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Oj is the offset of SPR transmission j, given by
SIFS j = 1
Oj =
O j – 1 + Ceil(TXTIME(SPR j) + SIFS T TR) 2 j m
SIFS is aSIFSTime, in µs, the time interval between the end of the last Poll frame transmitted by
the AP or PCP and the expected start time of the first SPR frame by the non-AP and non-
PCP STA
SPRj is a SPR transmission j
NOTE—The calculation of Oj guarantees that no less than SIFS or SIFS+dot11AntennaSwitchingTime is provided for
the AP or PCP to switch antennas when receiving an SPR from different STAs.
A STA that receives an individually addressed Poll frame shall respond to the AP or PCP with a single
directional and individually addressed SPR frame at the time offset from the end of the Poll frame indicated
in the Response Offset field within the received Poll frame. The Duration field within the SPR frame shall
be set to the value of the Duration field contained in the received Poll frame, minus the value of the
Response Offset field contained in the received Poll frame, minus the time taken to transmit the SPR frame.
The PP ends at a time equal to the end of the last Poll frame transmission plus the value of the Response
Offset field in that Poll frame plus the expected duration of the SPR transmission that is expected in
response to that Poll frame plus SIFS.
10.36.7.3 Grant period (GP)
An AP or PCP that intends to dynamically allocate an SP within the DTI shall commence a GP at a time
instant indicated by at least one of the following:
— SIFS interval following the end of a PP if the PP is present
— Any time during a scheduled SP for which the source AID and destination AID are equal to the
broadcast AID if a PP does not precede the GP, excluding any time that has been allocated
dynamically
— Any time during a TXOP within a scheduled CBAP for which the destination AID is equal to the
broadcast AID, excluding any time that has been allocated dynamically
— Any time during the relinquished channel time following an SP truncation if a PP does not precede
the GP, excluding any time that has been allocated dynamically
The AP or PCP shall not transmit a frame during a GP if any portion of that frame would extend beyond the
end of the originally scheduled SP or CBAP, or beyond the end of an immediately following SP if that SP
has the broadcast AID as both source and destination AID, whichever is later.
A non-AP and non-PCP STA may switch to doze state if it does not receive a Grant frame from the AP or
PCP within dot11MinPPDuration from the start of the scheduled SP for which the source AID and
destination AID are set to the broadcast AID.
To commence the GP, the AP or PCP shall transmit Grant frames to notify the source DMG STA and
destination DMG STA about a dynamically allocated service period. The AP or PCP should transmit the last
Grant frame within a GP to the source of the dynamically allocated SP if the source of the dynamically
allocated SP is not the AP or PCP. In each transmitted Grant frame, the AP or PCP shall set the Duration
field within the Grant frame to a time that covers the duration of all remaining Grant frame and Grant Ack
frame transmissions, if any, plus all appropriate IFSs (10.3.2.3). In addition, the source AID and destination
AID fields shall be set to the source and destination, respectively, of the dynamically allocated SP, the
AllocationType field set to indicate the channel access mechanism during the allocation, and the Allocation
Duration field set to a value that if added to the value of the Duration field does not overlap in time with
another SP that has either the source AID or destination AID different from the broadcast AID. An
1516
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
allocation that is indicated in this manner begins at the time that is equal to the PHY-TXEND.indication
primitive of the Grant frame plus the value from the Duration field of the Grant frame.
The Dynamic Allocation Info field within Grant frames transmitted as part of the same GP shall be the same.
NOTE—This means the AP or PCP can create only one allocation per GP.
During an SP between a source DMG STA and a destination DMG STA, the source DMG STA may
transmit a Grant frame to the destination DMG STA to relinquish the remainder of the SP to the destination
DMG STA. In the Allocation Info field of the transmitted Grant frame, the source DMG STA shall set
source AID field to the AID of the destination DMG STA, the destination AID field to the AID of the source
DMG STA, the AllocationType field set to indicate SP, and the Allocation Duration field set to a value of
32 768 as defined in 9.5.2. The Duration field in the Grant frame shall be set to the time remaining in the SP
minus TXTIME (Grant frame) minus aSIFSTime. Upon transmission of the Grant frame with the
Beamforming Training field equal to 0, for the remainder of the SP the roles of source DMG STA and
destination DMG STA are swapped between the STAs.
During a TXOP between a TXOP holder and a TXOP responder, the TXOP holder may transmit a Grant
frame to the TXOP responder to relinquish the remainder of the TXOP to the TXOP responder. In the
transmitted Grant frame, the TXOP holder shall set source AID field to the AID of the TXOP responder, the
destination AID field to the AID of the TXOP holder, the AllocationType field set to indicate CBAP, and the
Allocation Duration field set to a value of 32 768 as defined in 9.5.2. The Duration field in the Grant frame
shall be set to the time remaining in the TXOP minus TXTIME (Grant frame) minus aSIFSTime. Upon
transmission of the Grant frame with the Beamforming Training field equal to 0, for the remainder the
TXOP the roles of TXOP holder and TXOP responder are swapped between the STAs.
A STA that receives a Grant frame shall not update its NAV if the value of either the source AID or
destination AID fields in the Grant frame are equal to the STA’s AID.
The AP or PCP may grant a dynamic allocation of service period to a STA that does not transmit a SPR
frame during the PP.
10.36.8 Dynamic truncation of service period
A STA truncates an SP to release the remaining time in the SP. The STA can use the CF-End frame to
truncate the SP at the peer STA, to reset NAV in third party STAs and to return to the AP or PCP the time
left in the SP, thus allowing the AP or PCP to grant any portion of the released time as part of an SP to any
other STA or to allocate any portion of it as a CBAP. The STA can use the Grant frame to release any part of
the time left in the SP as a CBAP.
A STA that is neither source nor destination during a truncatable SP may participate in dynamic allocation
of service period by being in the receive state with its receive antenna configured in a quasi-omni antenna
pattern for the duration of the truncatable SP. If both the source and destination AID fields of a truncatable
SP are set to the broadcast AID, a non-AP and non-PCP STA may direct its receive antenna to its AP or PCP
for the duration of the truncatable SP if the non-AP and non-PCP STA does not participate in a frame
exchange and the truncatable SP is not dynamically allocated to the non-AP and non-PCP STA.
Only the source DMG STA of an SP may truncate the SP, except that the destination DMG STA may
truncate the SP if it does not receive an expected transmission from the source DMG STA at the start of the
SP as defined in 10.36.6.7.
In order to advertise the availability of truncatable SP time for reuse through AP or PCP dynamic allocation,
a non-AP and non-PCP STA shall transmit an CF-End frame to the AP or PCP. A STA is not required to
truncate an SP if a portion of the SP is unused.
1517
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In order to enable CBAP access during the time released through SP truncation, the STA shall broadcast a
Grant frame with the Source AID and Destination AID set to broadcast AID, the AllocationType field set to
indicate CBAP and the Duration field set to the time needed to transmit the Grant frame(s) (the Duration
field in a Grant frame does not include duration of that frame) plus SIFS and plus the time needed to transmit
the following CF-End frame and the response CF-End frame, if required and appropriate IFS (10.3.2.3)
values. The Allocation Duration field shall be set to a value that is not greater than the result of the
subtraction of the value in the Duration field from the time remaining in the SP. The CBAP that is indicated
in this manner begins at the time that is equal to the PHY-TXEND.indication primitive of the Grant frame
plus the value from the Duration field of the Grant frame and continues for the time indicated in the
Allocation Duration field of the Grant frame.
The STA shall not transmit the Grant frame and shall not transmit the CF-End frame to the AP or PCP if the
SP is not indicated as truncatable.
After transmission of the CF-End frame to the AP or PCP or after broadcasting a Grant frame, the STA shall
transmit a CF-End frame to the peer STA of the SP. The CF-End frame releases any time remaining in the
SP at the recipient and resets the NAV in third party STAs. The NAV is reset only if the RA and TA of the
CF-End frame match the addresses of the frame that established the NAV (see 10.36.10). The recipient STA
may transmit a CF-End frame SIFS after the reception if the Duration field of the received frame is not equal
to 0 and the transmission does not extend beyond the end of the originally scheduled SP.
A STA shall not initiate SP truncation if there is not enough time left in the SP to complete the frame
exchange required for truncation of the SP.
After the truncation is completed, the AP or PCP may dynamically allocate any portion of the relinquished
channel time that has not been allocated to a CBAP through a transmitted Grant frame (10.36.7).
10.36.9 Dynamic extension of service period
A non-AP and non-PCP STA uses dynamic extension of SP to extend the allocated time in the current SP.
The additional time can be used to support variable bit rate traffic, for retransmissions or for other purposes.
The SPR frame is sent by a non-AP and non-PCP STA to the AP or PCP to request additional SP time in the
current beacon interval.
Except in response to a Poll frame from the AP or PCP, a non-AP and non-PCP STA shall not transmit an
SPR frame within an SP if the current SP is not extendable (see 9.4.2.132).
Only the source DMG STA and destination DMG STA of an SP can transmit an SPR frame during that SP.
If the AP or PCP is not the source of an extendable SP, it should be in the receive state and with its receive
antennas configured in a quasi-omni antenna pattern for the duration of the extendable SP.
To request an extension of the current SP, a non-AP and non-PCP STA shall transmit an SPR frame to the
AP or PCP. The non-AP and non-PCP STA shall not request extension of the current SP if there is not
enough time left in the SP to complete the frame exchange required for the SP extension. In the transmitted
SPR frame, the STA shall set the RA field to the address of the AP or PCP, the Duration field to the time left
in the SP (not including the SPR transmission time), and the Allocation Duration field to the additional
amount of time requested by the STA following the end of the current SP.
The AP or PCP may grant the request for an extension of an SP only if the following SP has the broadcast
AID as both source and destination AID, and the duration of the following SP is larger than the value of the
Allocation Duration field in the received SPR frame. To grant an extension request, the AP or PCP shall
transmit a Grant frame with the RA field set to the value of the TA in the received SPR frame, the Duration
field set to the value of the Duration field received in the SPR frame minus SIFS and minus the duration of
1518
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
this Grant frame transmission, and the Allocation Duration field set to the amount of additional time granted
by the AP or PCP. If a Grant Ack frame is transmitted following reception of the Grant frame, the frame
shall be configured as specified in 10.36.4.
To decline a request for an extension of an SP, the AP or PCP shall transmit a Grant frame with the RA field
set to the value of the TA in the received SPR frame, the Duration field set to the value of the Duration field
received in the SPR frame minus SIFS and minus the duration of this Grant frame transmission, and the
Allocation Duration field set to 0.
The extension request is successful if the non-AP and non-PCP STA receives from the AP or PCP a Grant
frame with a nonzero value of the Allocation Duration field SIFS after the SPR. SIFS after the reception of a
Grant frame from the AP or PCP with a nonzero value of the Allocation Duration field, the non-AP and non-
PCP STA shall transmit a Grant frame to the partner STA of the SP with the Duration field set to the value
of the Duration field of the Grant frame received from the AP or PCP minus the duration of this Grant frame
transmission minus SIFS, and the Allocation Duration field set to the value of the Allocation Duration field
of the Grant frame received from the AP or PCP.
An AP or PCP may extend an SP for which it is the source DMG STA by transmitting a Grant frame to the
destination DMG STA of the SP. The Grant frame indicates extension of the SP. The Duration field in the
transmitted Grant frame shall be set to the remaining time in the SP. The Allocation Duration field of the
Grant frame shall be set to the additional channel time allocated by the AP or PCP following the end of the
SP. If a Grant Ack frame is transmitted following reception of the Grant frame the frame shall be configured
as specified in 10.36.4.
10.36.10 Updating multiple NAVs
If a DMG STA supports multiple NAVs, the number of available NAVs within the STA shall be not less
than aMinNAVTimersNumber. Each NAV is identified by a pair of MAC addresses, NAVSRC and
NAVDST, and has associated variables NAV_RTSCANCELABLE and NAV_DTSCANCELABLE. Each
STA also maintains a variable UPDATE_OPTIONAL. When a STA is enabled for operation, all NAVs
shall have NULL values for their NAVSRC and NAVDST identifiers, the value of
NAV_RTSCANCELABLE shall be false, the value of NAV_DTSCANCELABLE shall be false, and each
NAV shall have the value 0. NAV address pairs correspond to the NAV-SA and NAV-DA fields in DMG
DTS frames and correspond to the RA and TA fields of all other received frames that are used to update the
NAV. Receipt of any frame can cause an update to the NAV whose identifying address pair corresponds to
the specified address fields of the received frame according to the rules in this subclause.
STAs receiving any valid frame shall perform the following NAV update operation expressed using the
following pseudocode:
NAV_TIMER_UPDATE(received_frame):
UPDATE_OPTIONAL false
If (received_frame = DMG DTS) {
UPDATE_OPTIONAL true
}
If (received_frame(RA) This STA MAC address || UPDATE_OPTIONAL = true) {
If (received_frame = DMG DTS) {
R_DST received_frame(NAV-DA)
R_SRC received_frame(NAV-SA)
} else if (received_frame = Ack) {
1519
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
R_DST received_frame(RA)
R_SRC 0
} else {
R_DST received_frame(RA)
R_SRC received_frame(TA)
}
R_DUR received_frame(DUR)
N_TIMER -1
// Searching for a matching NAV
For (x 0; x < aMinNAVTimersNumber; x++) {
If (received_frame = Ack || NAVSRC(x)=R_DST) {
If(NAVDST(x) = R_DST) {
N_TIMER x
Break
}
} else if (NAVSRC(x) = R_SRC && (NAVDST(x) = R_DST
|| NAVDST(x) = 0) ||
(NAVSRC(x)=0 && NAVDST(x) = R_DST) ||
(NAVDST(x)=R_SRC && NAVSRC(x)=R_DST)) {
N_TIMER x
Break
}
}
// No NAV has been found that matches the addresses
If (N_TIMER < 0) {
For (x 0; x < aMinNAVTimersNumber; x++) {
If (NAVSRC(x) = NULL && NAVDST(x) = NULL
|| NAV(x) = 0) {
NAVSRC(x) R_SRC
NAVDST(x) R_DST
N_TIMER x
Break
}
}
}
// Existing NAV found
If (N_TIMER 0) {
If (UPDATE_OPTIONAL = false
&& R_DUR > NAV(N_TIMER) ) {
NAV(N_TIMER) R_DUR
If (received_frame = RTS) {
NAV_RTSCANCELABLE(N_TIMER) true
} else {
NAV_RTSCANCELABLE(N_TIMER) false
}
1520
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
} else if (UPDATE_OPTIONAL = true && R_DUR > NAV(N_TIMER)) {
If ((implementation decision to update = true) ||
(received_frame(RA) = This STA MAC address &&
This STA MAC address = source DMG STA MAC address for current SP))
){
NAV_DTSCANCELABLE(N_TIMER) true
NAV(N_TIMER) R_DUR
}
}
}
} else {
No change to NAV
}
END OF NAV_TIMER_UPDATE
A STA that has updated a NAV as a result of the reception of an RTS may reset its NAV(s) as follows. After
the NAV update for a duration of NAVTimeout period (10.3.2.4), the STA shall monitor the channel to
determine if a PHY-RXSTART.indication primitive is received from the PHY. If such an event has not
occurred during this time period, then the STA may reset to 0 any NAV whose NAV_RTSCANCELABLE
value is true.
After each NAV is updated, it counts down until it reaches 0 or is reset to 0.
If a STA receives a valid CF-End frame response with RA and TA values that match the NAVSRC and
NAVDST values, in any order, for any NAV, then the STA shall set the associated NAV to the value of the
Duration field in the received CF-End frame. If one of NAVSRC or NAVDST of a NAV is 0 and the
corresponding NAVDST or NAVSRC, respectively, of the NAV match the RA or the TA value of the
received valid CF-End frame, then the STA shall set the associated NAV to the value of the Duration field in
the received CF-End frame.
If one of NAVSRC or NAVDST of a NAV is 0 and the nonzero NAVDST or NAVSRC of the NAV match
either the RA or the TA value of a received valid frame, the NAVSRC or NAVDST that is 0 shall be set to
the RA or TA that does not match the nonzero NAVSRC or NAVDST.
10.37 DMG AP or PCP clustering
10.37.1 General
An AP or PCP may use the AP or PCP clustering mechanism to improve spatial sharing and interference
mitigation with other co-channel DMG BSSs. There are two types of clustering:
— Decentralized AP or PCP clustering that involves a single S-AP or S-PCP in the BSA of the S-AP or
S-PCP
— Centralized AP or PCP clustering where there can be multiple S-APs in the BSA of any one S-AP,
and all S-APs are coordinated via a single centralized coordination service set
AP or PCP clustering allows an AP or PCP that is a member of a cluster to schedule transmissions in
nonoverlapping time periods with respect to other members of the same cluster since the AP or PCP can
receive DMG Beacon and Announce frames containing the Extended Schedule element of other APs and
1521
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PCPs that are members of the cluster and can also receive the Extended Schedule element from another BSS
through associated non-AP and non-PCP STAs (10.37.4).
A STA is decentralized AP or PCP clustering capable if it sets the Decentralized AP or PCP Clustering field
to 1 within the DMG AP Or PCP Capability Information field in the DMG Capabilities element. A STA is
centralized AP or PCP clustering capable if it sets the Centralized AP or PCP Clustering field to 1 within the
DMG AP Or PCP Capability Information field in the DMG Capabilities element. The AP or PCP employs
the Clustering Control field and ECAPC Policy Enforced field defined in 9.3.4.2 to configure the use of AP
or PCP Clustering. A decentralized AP or PCP clustering capable or centralized AP or PCP clustering
capable AP or PCP that transmits the Clustering Control field is decentralized clustering enabled or
centralized clustering enabled, respectively.
An AP or PCP cluster includes one S-AP or S-PCP and zero or more member APs and PCPs. Decentralized
clustering enabled APs and PCPs operating on the same channel may form a decentralized AP or PCP
cluster. The Cluster ID of the decentralized AP or PCP cluster shall be set to the MAC address of the S-AP
or S-PCP. Centralized clustering enabled APs and PCPs operating on the same channel as a S-AP form a
centralized AP or PCP cluster as described in 10.37.2.2. The Cluster ID of the centralized AP or PCP cluster
shall be set to the MAC address of the S-AP.
A clustering enabled AP or PCP that is not a member of any cluster shall set the Cluster Member Role
subfield to 0 in transmitted frames that contain the Clustering Control field.
Each AP or PCP that is a member of an AP or PCP cluster shall include the Clustering Control field in each
DMG Beacon frame it transmits.
For each cluster, there exists a set of ClusterMaxMem Beacon SPs. The nth Beacon SP, Beacon SPn, begins
at ClusterTimeOffsetn-1 µs following the TBTT of the S-AP or S-PCP, where
ClusterTimeOffsetn-1 = 1024 × (dot11BeaconPeriod/ClusterMaxMem) × (n–1)
and n=2, 3,…, ClusterMaxMem
The ClusterTimeOffsetn-1 and Beacon SPn where n equals one is reserved for the S-AP or S-PCP.
An AP or PCP that is a member of an AP or PCP cluster shall transmit its DMG Beacon frame during one of
the Beacon SPs as specified in 10.37.2.
The maximum size of the Beacon SP Duration field transmitted by a S-AP or S-PCP shall be the beacon
interval of the S-AP or S-PCP divided by ClusterMaxMem.
10.37.2 Cluster formation
10.37.2.1 Decentralized AP or PCP cluster formation
A clustering enabled AP or PCP starts a decentralized AP or PCP cluster by becoming an S-AP or S-PCP,
subject to the absence of existing clusters as described below and in 10.37.2.2. A decentralized clustering
enabled AP or PCP becomes an S-AP or S-PCP of a decentralized AP or PCP cluster by transmitting a DMG
Beacon frame at least once every aMinBTIPeriod beacon intervals that has the ECAPC Policy Enforced
subfield in the DMG Parameters field set to 0 and that includes a Clustering Control field with the Beacon
SP Duration subfield set to dot11BeaconSPDuration, the Cluster ID subfield set to the S-AP or S-PCP MAC
address, and the Cluster Member Role subfield set to the value for an S-AP or S-PCP. The value of
ClusterMaxMem subfield shall be chosen to keep the result of (beacon interval length/ClusterMaxMem) as
an integer number of microseconds.
1522
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A decentralized clustering enabled AP or PCP that receives a DMG Beacon frame with the ECAPC Policy
Enforced subfield in the DMG Parameters field set to 0 from an S-AP or S-PCP on the channel the AP or
PCP selects to establish a BSS shall monitor the channel for DMG Beacon frame transmissions during each
Beacon SP for an interval of length at least aMinChannelTime. A Beacon SP is empty if no DMG Beacon
frame is received during the Beacon SP over an interval of length aMinChannelTime. The AP or PCP shall
not become a member of the cluster if no Beacon SP is determined to be empty during aMinChannelTime, in
which case, subject to the requirements described in 10.37.2.2, then the AP or PCP may become the S-AP or
S-PCP of a new cluster, or may cease its activity on this channel and may attempt operation on a different
channel.
A decentralized clustering enabled AP or PCP that operates its BSS on a channel on which it discovered an
S-AP or S-PCP within a decentralized AP or PCP cluster and at least one empty Beacon SP shall transmit its
DMG Beacon frame during an empty Beacon SP. By transmitting its DMG Beacon frame during an empty
Beacon SP and by setting the clustering control field appropriately as described in 9.3.4.2, the AP or PCP
becomes a member AP or member PCP.
The member AP or member PCP shall select a beacon interval length that is equal to the beacon interval
length of its S-AP or S-PCP.
The member AP or member PCP shall transmit its DMG Beacon frame with the ECAPC Policy Enforced
field set to 0, the Beacon SP Duration subfield set to the value of the Beacon SP Duration subfield contained
in the S-AP or S-PCP DMG Beacon, the Cluster ID subfield set to the MAC address of the S-AP or S-PCP,
the Cluster Member Role subfield set to the member AP or member PCP value, and the ClusterMaxMem
subfield set to the value of the ClusterMaxMem field contained in the S-AP or S-PCP DMG Beacon.
An AP or PCP with a value of Cluster Member Role that is not zero shall schedule a Beacon SP that is
allocated for DMG Beacon frame transmission of other cluster member APs and PCPs within the
decentralized AP or PCP cluster at each of ClusterTimeOffsetn, at any time the AP or PCP transmits its own
DMG Beacon. The minimum size of the Beacon SP should be equal to the value of the Beacon SP Duration
subfield within the S-AP or S-PCP DMG Beacon.
An S-AP or S-PCP and a member AP or member PCP of a decentralized AP or PCP cluster should not
transmit or schedule transmissions during a Beacon SP that is not its own Beacon SP.
Figure 10-58 illustrates, for three APs and PCPs, the Beacon SPs of the S-AP or S-PCP and member APs
and PCPs of a decentralized AP or PCP cluster.
ClusterTime Beacon Interval
Offset (n=1)
AP or PCP 1 BTI Rx Rx BTI ...
(S-AP or S-PCP) ...
ClusterTimeOffset (n=2)
AP or PCP 2 Rx BTI Rx Rx ...
...
ClusterTimeOffset (n=3)
AP or PCP 3 Rx Rx BTI Rx ...
...
Figure 10-58—Decentralized AP or PCP clustering for 3 APs and PCPs
1523
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.37.2.2 Centralized AP or PCP cluster formation
In order to become an S-AP, a centralized clustering enabled STA that is stationary with respect to its local
environment shall successfully perform both the following steps in order:
— Configuration step
— Verification step
Once these steps have been performed successfully, the STA has become an S-AP.
— Configuration step: The configuration step is defined to be successful if the following occur:
— The STA obtains the MAC address of the CCSR; and
— The STA obtains an ECAPC Policy Detail field, beacon interval, ClusterMaxMem, Beacon SP
Duration, TXSS CBAP Offset, TXSS CBAP Duration, TXSS CBAP MaxMem, TSF
synchronization parameters, Cluster Time Offset availability information, and a nonempty list
of excluded channels for the intended operating class of the STA from the CCSR; and
— Either channel 2 is an allowed channel in the current regulatory domain and the list of excluded
channels includes channel 2, or channel 2 is not an allowed channel in the current regulatory
domain; and
— The beacon interval/ClusterMaxMem is an integer number of microseconds; and
— At least one of beacon interval/TXSS CBAP MaxMem or TXSS CBAP MaxMem/beacon
interval is an integer.
Otherwise, the configuration step is defined to be unsuccessful. If the configuration step is
unsuccessful, then the STA can attempt to resolve the problem or quit attempting to start a
centralized AP or PCP cluster. The method by which the STA obtains the configuration information
from the CCSR is not defined in this standard.
— Verification step: The verification step is defined to be the following procedure:
— The centralized clustering enabled STA monitors the channel for DMG Beacon frames over an
interval of at least aMinChannelTime.
— During this monitoring period, for each distinct Cluster ID received in a DMG Beacon frame
that has the ECAPC Policy Enforced field set to 1 in the DMG Parameters field and Cluster
Member Role set to 1 (S-AP or S-PCP of the cluster) or 2 (a member AP or member PCP of the
cluster), the centralized clustering enabled STA determines if an S-AP with a MAC address
equal to the Cluster ID belongs to the same CCSS as the centralized clustering enabled STA,
via i) attempting to receive an Announce frame from the S-AP that transmitted the DMG
Beacon frame according to the channel access rules described in 10.36 in order to solicit an
ECAPC Policy element or ii) any other means. Any such DMG Beacon frame whose
transmitter cannot be determined in this way to belong to the same CCSS as the centralized
clustering enabled STA is defined to be from another ECAPC.
The verification step is defined to be unsuccessful if, at the end of the monitoring period, there are
one or more received DMG Beacon frames that are from another ECAPC. Otherwise, the
verification step is defined to be successful.
If a centralized clustering enabled STA receives at least one DMG Beacon frame that has the ECAPC Policy
Enforced field set to 1 and from a member AP, S-AP, or member PCP of another ECAPC during the
monitoring period and the STA is not an ECAPC policy blind AP or PCP, the STA
— Shall cease its activity on this channel and may attempt operation on a different channel, or
— If one of the received DMG Beacon frames was sent by an S-AP, may elect to unenroll from its
current CCSS and join the cluster of the S-AP as a member AP or member PCP.
If a centralized clustering enabled STA receives at least one DMG Beacon frame that has the ECAPC Policy
Enforced field set to 1 from an S-AP from the same CCSS during the monitoring period and the STA is not
1524
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
an ECAPC policy blind AP or PCP, the STA may elect either to unenroll from its current CCSS and join the
cluster of the S-AP as a member AP or member PCP or to continue and become an S-AP in the CCSS.
In order to become an S-AP in a centralized AP or PCP cluster, a centralized clustering enabled STA shall
take the following actions:
— Set dot11ChannelUsageImplemented to true
— Start a BSS as an AP
— On a channel that is not listed as excluded by the CCSR, and
— At the start time and with the beacon interval configured by the CCSR
— Include in transmitted DMG Beacon frames
— The ECAPC Policy Enforced field set to 1 in the DMG Parameters field, and
— A Clustering Control field with the ClusterMaxMem subfield set to the values configured by
the CCSR, the Beacon SP Duration subfield set to the value most recently configured by the
CCSR, the Cluster ID subfield set to the S-AP MAC address, and the Cluster Member Role
subfield set to 1 (S-AP or S-PCP of the cluster).
An S-AP in a centralized AP or PCP cluster shall set the ECAPC Policy Enforced subfield in the DMG
Parameters field to 1 for the lifetime of the BSS.
An S-AP within a centralized AP or PCP cluster shall include the ECAPC Policy element in (Re)Association
Response, Announce, and Information Response frames with the ECAPC Policy Detail, TXSS CBAP
Offset, and TXSS CBAP Duration fields set to the respective values most recently configured by the CCSR
for the S-AP, the TXSS CBAP MaxMem subfield set to the policy configured by the CCSR, the CCSR ID
subfield set to the MAC address of the CCSR, and bits in the Available Cluster Time Offset Bitmap subfield
set to 0 to indicate the Cluster Time Offsets that are determined to be already in use, excluding the recipient
if sent within an individually addressed frame. The means by which a Cluster Time Offset is determined to
be in use are unspecified. Bits in the Available Cluster Time Offset Bitmap subfield for other Cluster Time
Offsets shall be set to 1.
An AP or PCP that
— receives a DMG Beacon frame that has the ECAPC Policy Enforced subfield in the DMG
Parameters field set to 1 from an S-AP on a channel and
— does not receive at least one DMG Beacon frame that has the ECAPC Policy Enforced subfield in
the DMG Parameters field set to 1 from S-AP on every channel supported by the AP or PCP in the
Operating Class within the next aMinChannelTime and
— is not an ECAPC policy blind AP or PCP
shall either join the cluster of the S-AP as a member AP or member PCP if centralized clustering enabled or
cease its activity on this channel and may attempt operation on a different channel. S-APs within a CCSS
report the channels unused by the ECAPC via the Channel Usage procedures (see 11.24.15).
An AP or PCP within a decentralized AP or PCP cluster that
— receives a DMG Beacon frame that has the ECAPC Policy Enforced subfield in the DMG
Parameters field set to 1 from an S-AP and
— does not receive at least one DMG Beacon frame that has the ECAPC Policy Enforced subfield in
the DMG Parameters field set to 1 from an S-AP on every channel supported by the AP or PCP in
the Operating Class within the next aMinChannelTime (i.e., does not become a ECAPC policy blind
AP or PCO) and
— is not already an ECAPC policy blind AP or PCP
1525
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
shall quit the decentralized AP or PCP cluster before the next TBTT + beacon interval length, then the AP or
PCP shall either join the cluster of the S-AP as a member AP or member PCP if centralized AP or PCP
clustering enabled or cease its activity on this channel and may attempt operation on a different channel.
An AP or PCP that receives at least one DMG Beacon frame that has the ECAPC Policy Enforced subfield
in the DMG Parameters field set to 1 sent by an S-AP on every channel supported by the AP or PCP in the
Operating Class within the most recent aMinChannelTime ignores the ECAPC Policy Enforced subfield
(i.e., treats this subfield as though equal to 0) in DMG Beacon frames received from S-APs for
300×aMinChannelTime. During this period, the AP or PCP is called an ECAPC policy blind AP or PCP.
NOTE—An AP or PCP within a decentralized AP or PCP cluster does not cease DMG Beacon frame transmission when
quitting a decentralized AP or PCP cluster. Hence, data communication is unaffected while performing these procedures.
A centralized clustering enabled AP or PCP that attempts to join the centralized AP or PCP cluster of an S-
AP as a member AP or member PCP shall be a STA coordinated by an MM-SME that also coordinates a
second non-AP and non-PCP STA, and shall successfully perform the following steps in order:
— The AP or PCP shall monitor the channel for DMG Beacon frames during each Beacon SP over an
interval of length at least aMinChannelTime. A Beacon SPn is empty if no DMG Beacon frame is
received during the Beacon SPn over an interval of length aMinChannelTime.
— The second non-AP and non-PCP STA shall attempt to associate with the S-AP and thereby receive
an Announce frame from the S-AP. The contents of the Announce frame are passed to the AP or
PCP.
— Upon receiving an Announce frame that includes the ECAPC Policy element, the AP or PCP shall
select a Cluster Time Offset index from the intersection of a) the Cluster Time Offset indices of the
empty Beacon SPs with b) the indices indicated by the Available Cluster Offset Bitmap field in the
ECAPC Policy element. If the intersection is empty, the AP or PCP shall select a Cluster Time
Offset index of an empty Beacon SP. The selected Cluster Time Offset index is passed to the second
non-AP and non-PCP STA.
— The second non-AP and non-PCP STA shall respond to the Announce frame with an Information
Response frame that includes the Cluster Time Offset element containing the Cluster Time Offset
Index set to the selected index.
— The AP or PCP shall operate its BSS at the selected Cluster Time Offset on the channel of the S-AP
and include the AP or PCP clustering control field in transmitted DMG Beacon frames.
The AP or PCP shall not become a member of the centralized AP or PCP cluster if no Beacon SP is
determined to be empty during aMinChannelTime or if the second non-AP and non-PCP STA did not
associate to the S-AP, in which case the AP or PCP may attempt to join the cluster of another S-AP or cease
its activity on this channel and may attempt operation on a different channel.
A member AP or member PCP within a centralized AP or PCP cluster shall select a beacon interval that is
equal to the beacon interval of the S-AP of the cluster.
The member AP or member PCP within a centralized AP or PCP cluster shall transmit its DMG Beacon
frames with the ECAPC Policy Enforced subfield in the DMG Parameters field set to 1, the Beacon SP
Duration subfield in the Clustering Control field set to the value of the Beacon SP Duration subfield
contained in the most recently received S-AP DMG Beacon, the Cluster ID subfield set to the MAC address
of the S-AP, the Cluster Member Role subfield set to 2 (a member AP or member PCP of the cluster), and
the ClusterMaxMem subfields set to the value of the ClusterMaxMem field contained in the S-AP DMG
Beacon.
A member AP or member PCP within a centralized AP or PCP cluster shall include the ECAPC Policy
element in (Re)Association Response, Announce, and Information Response frames with the ECAPC Policy
Detail, TXSS CBAP Offset, and TXSS CBAP Duration fields set to the most recently received respective
1526
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
field from the S-AP of the cluster, the TXSS CBAP MaxMem field set to the value of the TXSS CBAP
MaxMem field received from the S-AP of the cluster, with the CCSR ID set to the MAC address of the
CCSR field received from the S-AP of the cluster, and with the Available Cluster Time Offset Bitmap field
reserved.
At any time an AP or PCP within a centralized AP or PCP cluster transmits a DMG Beacon frame, the AP or
PCP shall schedule a Beacon SP that reserves time for BHI transmission by other APs and PCPs within the
centralized AP or PCP cluster at each in use ClusterTimeOffsetn-1 as indicated by the most recently
transmitted (if S-AP) or received (if member AP or member PCP) Available Cluster Time Offset Bitmap.
The minimum size of the Beacon SP shall be equal to the value of the Beacon SP Duration subfield within
the DMG Beacon frame of the S-AP of the centralized AP or PCP cluster. A member AP, S-AP, or member
PCP of a centralized AP or PCP cluster shall not transmit or schedule transmissions during a Beacon SP of
another member AP, S-AP, or member PCP.
10.37.3 Cluster maintenance
10.37.3.1 General cluster maintenance
The TBTT of the S-AP or S-PCP provides a timing reference for the Beacon SPs of the member APs and
PCPs. Timing synchronization among the member APs and PCPs facilitates equitable sharing of the
common medium among the member APs and PCPs. As long as a member AP or member PCP periodically
receives DMG Beacons from the S-AP or S-PCP, the member AP or member PCP is able to maintain
synchronization with the S-AP or S-PCP and hence the other member APs and PCPs.
10.37.3.2 Decentralized AP or PCP cluster maintenance
In the case when the S-AP or S-PCP of a decentralized AP or PCP cluster is lost, or appears to a member AP
or member PCP to have been lost, another AP or PCP needs to become the S-AP or S-PCP of the
decentralized AP or PCP cluster in order to allow the remaining member APs and PCPs to maintain
synchronization with the cluster. The creation of a new S-AP or S-PCP is called S-AP or S-PCP handover.
After an S-AP or S-PCP handover, the cluster might continue to function as before, except with altered
membership, or the cluster might no longer exist, or there might be one or more new clusters.
A member AP or member PCP of the decentralized AP or PCP cluster shall start an S-AP or S-PCP
handover if, within a time period of 4×aMinBTIPeriod beacon intervals, it does not receive a DMG Beacon
frame with the ECAPC Policy Enforced field set to 0, with the value of the Cluster ID field equal to the
Cluster ID of the cluster of which the AP or PCP is a member and with the Cluster Member Role field set to
the S-AP or S-PCP value. This is the first cluster monitoring period. During the next step in the S-AP or S-
PCP handover, the member AP or member PCP performs another cluster monitoring period. A cluster
monitoring period is a time period of 4×aMinBTIPeriod beacon intervals during which the AP or PCP
listens for DMG Beacons while continuing to transmit DMG Beacons using its current Beacon SPn.
NOTE—A decentralized clustering enabled AP or PCP does not cease DMG Beacon frame transmission during Cluster
Monitoring and S-AP or S-PCP handover. Hence, data communication is unaffected while performing these procedures.
If, during a cluster monitoring period, the member AP or member PCP receives a DMG Beacon frame with
the value of Cluster Member Role set to the S-AP or S-PCP value, the member AP or member PCP shall
follow the rules in 10.37.2 to become a member AP or member PCP of the cluster corresponding to the
detected S-AP or S-PCP or cease operation on the channel; in either case, the cluster monitoring period is
terminated.
If, during a cluster monitoring period, the AP or PCP receives no DMG Beacons with the value of Cluster
Member Role set to the S-AP or S-PCP value and one or more DMG Beacons with the ECAPC Policy
Enforced field set to 0 and with Cluster ID equal to the Cluster ID of its last S-AP or S-PCP, then at the end
of the cluster monitoring period the AP or PCP compares the MAC addresses of all such received DMG
1527
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beacons with its own MAC address. If its MAC address is the lowest, the AP or PCP shall become an S-AP
or S-PCP according to the rules in 10.37.2. If its MAC address is not the lowest, the AP or PCP shall
perform a new cluster monitoring period. If the number of cluster monitoring periods performed by the AP
or PCP exceeds dot11MaxNumberOfClusteringMonitoringPeriods, the AP or PCP may cease cluster
maintenance and initiate cluster formation as described in 10.37.2.
If, during a cluster monitoring period, the AP or PCP does not receive a DMG Beacon frame that contains
the value of S-AP or S-PCP in the Cluster Member Role field and does not receive a DMG Beacon frame
with the ECAPC Policy Enforced field set to 0 and with Cluster ID equal to the Cluster ID of the cluster of
which it is currently a member, then at the end of the cluster monitoring period the AP or PCP may become
an S-AP or S-PCP according to the rules of 10.37.2, or it may cease its activity on this channel and may
attempt operation on a different channel.
NOTE—An assumption to allow the establishment of an S-AP or S-PCP in this case is that the APs and PCPs cannot
hear each other’s DMG Beacons. How a STA decides to switch the channel or to establish an S-AP or S-PCP is
implementation dependent.
If, during a cluster monitoring period, the member AP or member PCP of a decentralized AP or PCP cluster
receives no DMG Beacons from clustering enabled STAs, then the AP or PCP shall establish itself as an S-
AP or S-PCP according to the rules in 10.37.2.
If an S-AP or S-PCP of a decentralized AP or PCP cluster detects the presence of a S-AP or S-PCP of
another decentralized AP or PCP cluster on the same channel, it should schedule a Beacon SP for the DMG
Beacon frame transmission of the other S-AP or S-PCP if the MAC address of the other S-AP or S-PCP is
lower than the MAC address of this S-AP or S-PCP. The S-AP or S-PCP with higher MAC address should
become a member AP or member PCP of the cluster corresponding to the S-AP or S-PCP with the lower
MAC address according to the rules in 10.37.2.
10.37.3.3 Centralized AP or PCP cluster maintenance
A STA, while operating as an S-AP, remains stationary with respect to its local environment.
An S-AP within a centralized AP or PCP cluster, upon a change of the Beacon SP Duration field or the
ECAPC Policy element configured by the CCSR, shall update the Clustering Control field sent in
subsequent frames and shall send individually addressed Announce or Information Response frames to other
STAs within the BSS in order notify them of the changes.
When a member AP or member PCP is coordinated by an MM-SME and the member AP or member PCP
elects to change its S-AP within a centralized AP or PCP cluster, then a second non-AP and non-PCP STA
coordinated by the MM-SME of the member AP or member PCP should disassociate from the previous S-
AP, and the member AP or member PCP shall perform the steps described in 10.37.2.2 that allow a
clustering enabled AP or PCP to join the centralized AP or PCP cluster of an S-AP as a member AP or
member PCP.
When a member AP or member PCP is coordinated by an MM-SME and the member AP or member PCP
elects to change its Cluster Time Offset within a centralized AP or PCP cluster, then the member AP or
member PCP shall pass the updated Cluster Time Offset to a second non-AP and non-PCP STA coordinated
by the MM-SME of the member AP or member PCP, and the second non-AP and non-PCP STA shall send
an Information Response frame that includes a Cluster Time Offset element containing the Cluster Time
Offset Index set to the updated index to the S-AP of the centralized AP or PCP cluster.
A member AP or member PCP within a centralized AP or PCP cluster, upon a change of the Clustering
Control field received from its S-AP, shall update the Clustering Control field sent in subsequent frames.
Upon a change of the ECAPC Policy Detail field received from its S-AP, a member AP or member PCP
within a centralized AP or PCP cluster shall update the ECAPC Policy element sent in subsequent frames
1528
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
and send individually addressed Announce or Information Response frames to other STAs within the BSS in
order notify them of the changes. The member AP or member PCP within the centralized AP or PCP cluster
shall attempt to receive a DMG Beacon frame from its S-AP at least once every
dot11DMGEcssPolicyDetailUpdateDurationMax TUs.
In the case when a member AP or member PCP of a cluster has not received DMG Beacon frames from its
S-AP for a duration exceeding 4×aMinBTIPeriod beacon intervals, and the member AP or member PCP
intends to continue to operate a BSS on the channel, the AP or PCP shall either
a) Stop the current BSS then become an S-AP within the CCSS as described in 10.37.2.2; or
b) Monitor the channel for DMG Beacon frames for an interval of length at least aMinChannelTime.
During this period
1) if one or more DMG Beacon frames are received with the ECAPC Policy Enforced field set to
1 in the DMG Parameters field and the Cluster Member Role set to 1 (S-AP or S-PCP of clus-
ter) from one or more S-APs and the AP or PCP is not an ECAPC policy blind AP or PCP, then
the AP or PCP shall join a selected S-AP as a cluster member as described in 10.37.2.2;
2) otherwise, if the AP or PCP is an ECAPC policy blind PCP or AP, then it may join a selected S-
AP as a cluster member;
3) otherwise, if, after the period elapses, no DMG Beacon frames are received with the ECAPC
Policy Enforced field in the DMG Parameters field set to 1 and the Cluster Member Role set to
1 (S-AP or S-PCP of cluster) and if the AP or PCP is decentralized AP or PCP clustering
capable, then the AP or PCP shall attempt to join a decentralized AP or PCP cluster if present
as described in 10.37.2.1. If the AP or PCP is not decentralized AP or PCP clustering capable
or a decentralized AP or PCP cluster is not present, then the AP or PCP shall set its Cluster
Member Role to 0 (not currently participating in a cluster).
c) In all three cases, the AP or PCP
1) Shall set the ECAPC Policy Enforced bit to 0 and shall not include the ECAPC Policy element
in (Re)Association Response, Announce, or Information Response frames and
2) Should send individually addressed Announce or Information Response frames to other STAs
within the BSS to notify them of the changes.
10.37.3.4 Centralized AP or PCP cluster MAC requirements
If the most recent ECAPC Policy element transmitted by a member AP, S-AP, or member PCP includes the
BHI Enforced field set to 1, the member AP, S-AP, or member PCP shall complete the BTI, A-BFT, and
ATI for each subsequent beacon interval before TBTT + (8×Beacon SP duration). The most recently
transmitted (if an S-AP) or received (if a member AP, member PCP, or non-AP and non-PCP STA) value of
Beacon SP Duration is used.
If the most recent ECAPC Policy element transmitted by a member AP, S-AP, or member PCP has the
TXSS CBAP Enforced field set to 1, the member AP, S-AP, or member PCP shall complete each of its
TXSSs in the DTI within one or more TXSS CBAPs.
If the most recent ECAPC Policy element, received by a non-AP and non-PCP STA in a BSS from the
member AP, S-AP, or member PCP of the BSS, has the TXSS CBAP Enforced field set to 1, then the non-
AP and non-PCP STA shall perform each of its TXSSs in the DTI within one or more TXSS CBAPs. If the
non-AP and non-PCP STA is the source DMG STA of an SP and if the non-AP and non-PCP determines
that it needs to perform a TXSS before continuing to transmit to the destination DMG STA of the SP, then
the non-AP and non-PCP STA should truncate the SP (see 10.36.8).
A TXSS CBAP shall last from TStart to TEnd, as defined below, excluding any time that overlaps a BHI or an
SP that has source and destination DMG AIDs set to 255 (such as for a Beacon SP).
1529
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
n – 1 1024 T BI
T Start = T TBTT + 8 T o + ------------------------------------------------
- 1 n N
N
n – 1 1024 T BI
T End = T TBTT + 8 T o + ------------------------------------------------
-+8 Td 1 n N
N
where
TTBTT is the TBTT
To is the TXSS CBAP Offset, in microseconds
Td is the TXSS CBAP Duration, in microseconds
TBI is the beacon interval, in TU
N is TXSS CBAP MaxMem
The most recently transmitted (if an S-AP) or received (if a member AP, member PCP, or non-AP and non-
PCP STA) value of TXSS CBAP Offset and TXSS CBAP Duration fields are used.
The TXSS CBAP is available to all STAs in an ECAPC. A STA may also use the TXSS CBAP for sending
frames not related to transmit sector sweeping. Transmission rules during a TXSS CBAP are defined in
10.36.5.
NOTE—Frames, such as Data frames, sent in a TXSS CBAP when the TXSS CBAP Enforced field is set to 1 might
experience erratically higher interference than frames sent at other times due to the TXSSs of other nearby STAs.
Additional centralized AP or PCP cluster requirements are defined in 10.36.6.6 and 11.1.3.3.
10.37.4 Cluster report and re-scheduling
A clustering enabled AP or PCP that receives an Extended Schedule element from another clustering
enabled AP or PCP may re-schedule SPs and CBAPs in its beacon interval, or move the BTI (11.1.3.3), in an
attempt to mitigate any interference with the transmissions indicated in the received Extended Schedule
element. The AP or PCP can create SPs in its beacon interval with the source and destination AID set to 255
to prevent transmissions during specific periods in the beacon interval (10.36.6.2).
A non-AP and non-PCP STA that is a member of a BSS and that receives a DMG Beacon frame should send
a Cluster Report element to its AP or PCP if the received DMG Beacon frame meets all of the following
conditions:
— The DMG Beacon frame is not from the STA’s AP or PCP.
— The DMG Beacon frame contains the Clustering Control field.
— Either
— The value of the Cluster ID field within the Clustering Control field is different from the MAC
address of the STA’s AP or PCP; or
— The value of the Cluster ID field within the Clustering Control field is the same as the MAC
address of the STA’s AP or PCP, the TBTTs of the two BSSs are less than dot11BeaconPeriod/
(2×ClusterMemMax) apart in time, and the ECAPC Policy Enforced field in the DMG Beacon
frame received most recently from the STA’s AP or PCP is equal to 1.
The non-AP and non-PCP STA shall not send a Cluster Report element to its AP or PCP if the received
DMG Beacon frame does not meet the preceding conditions.
A Cluster Report element meeting the conditions above shall be transmitted in an Announce or Information
Response frame sent to the STA’s AP or PCP. Within the transmitted Cluster Report element, the STA shall
1530
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
set the Cluster report subfield to 1. The STA shall set the Clustering Control field within a transmitted
Cluster Report element to the corresponding field values within the Clustering Control of the received DMG
Beacon, shall set the Reported BSSID field to the BSSID of the received DMG Beacon, and shall set the
Reference timestamp field to indicate the DMG Beacon frame reception time. The STA shall set the
Schedule present subfield to 1 if the Extended Schedule field is present in the transmitted Cluster Report
element; otherwise, it shall set Schedule present subfield to 0. The STA shall set the TSCONST present
subfield to 1 if the Traffic Scheduling Constraint Set field is present in the transmitted Cluster Report
element; otherwise, it shall set TSCONST present subfield to 0.
The STA shall set the ECAPC Policy Enforced field in the Cluster Report Control field to the value of the
ECAPC Policy Enforced field in the received DMG Beacon. The STA should attempt to receive an
Announce frame from the AP or PCP that transmitted the DMG Beacon frame according to the channel
access rules described in 10.36 in order to solicit an ECAPC Policy element. If the STA obtains an ECAPC
Policy element from the AP or PCP that transmitted the DMG Beacon, the STA shall set the ECAPC Policy
Present subfield to 1 and include the ECAPC Policy element in the transmitted Cluster Report element;
otherwise, the STA shall set ECAPC Policy Present subfield to 0 and not include the ECAPC Policy element
in the transmitted Cluster Report element. If present, the Extended Schedule Element field within the Cluster
Report element shall be set to the corresponding field values within the Extended Schedule element of the
received DMG Beacon. If present, the Traffic Scheduling Constraint Set field shall be set to indicate periods
of time with respect to the TBTT of the beacon interval of the BSS the STA participates where the
transmitting STA experiences poor channel conditions, such as due to interference.
If the received DMG Beacon frame contains more than one Extended Schedule element entry, the STA shall
repeat the aforementioned procedure and transmit a Cluster Report element corresponding to each Extended
Schedule element entry.
Upon receiving a Cluster Report element from a non-AP and non-PCP STA with the Cluster report field set
to 1, a clustering enabled AP or PCP may re-schedule SPs and CBAPs in its beacon interval, move the BTI
if the clustering enabled AP or PCP is an S-AP or S-PCP in a decentralized AP or PCP cluster, or change the
Cluster Time Offset if the clustering enabled AP or PCP is a member AP or member PCP, or perform other
actions, in an attempt to mitigate any interference with the transmissions indicated in the received Cluster
Report element. The clustering enabled AP or PCP may also create SPs in its beacon interval with the source
and destination AID set to 255 to prevent transmissions during specific periods in the beacon interval.
A member AP or member PCP within a centralized AP or PCP cluster should report new interference
information and may report all interference information to the S-AP of the cluster
— When the member AP or member PCP receives one or more of the following:
— A DMG Beacon frame from another AP or PCP in another centralized AP or PCP cluster
within the same CCSS or another CCSS
— A Cluster Report element with the Cluster Report field set to 1 from a non-AP and non-PCP
STA within the same BSS characterizing an AP or PCP in another centralized AP or PCP
cluster within the same CCSS or another CCSS; and
— If at least dot11DMGEcssClusterReportDurationMin TUs have elapsed since the last report.
The report should aggregate the information received from all sources and minimize duplication. The
member AP or member PCP passes the report to a second non-AP and non-PCP STA coordinated by the
MM-SME of the member AP or member PCP, and the second non-AP and non-PCP STA sends the report in
an Information Response frame that includes one or more Cluster Report elements to the S-AP of its
centralized AP or PCP cluster. If the member AP or member PCP does not elect to change its Cluster Time
Offset at this time, the second non-AP and non-PCP STA includes a Cluster Time Offset element with an
unchanged Cluster Time Offset Index field.
1531
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Via unspecified means, the S-AP might aggregate received DMG Beacon frames and Cluster Report
elements and send the aggregate to the CCSR. Upon receiving this information, the CCSR might reconfigure
the TSF offsets of an S-AP, reconfigure the ECAPC Policy Detail of an S-AP, update the Cluster Time
Offset availability information provided in an individually addressed frame by an S-AP to a member AP or
member PCP, or perform other actions.
10.37.5 Decentralized AP or PCP cluster request
A non-AP and non-PCP STA that is a member of a BSS may transmit a Cluster Report element to its AP or
PCP to request that decentralized AP or PCP clustering be enabled in the BSS. The non-AP and non-PCP
STA can make this request if, for example, the device containing the non-AP and non-PCP STA intends to
initialize another co-channel BSS (11.1) in which it performs the role of AP or PCP and, when performing
this role, it wishes to become a member AP or member PCP of the decentralized AP or PCP cluster formed
by its current AP or PCP.
To request AP or PCP clustering to be enabled in the BSS, the STA shall transmit a Cluster Report element
with the Cluster request subfield set to 1 to its AP or PCP. Upon receiving a Cluster Report element with the
Cluster request subfield set to 1, the AP or PCP should form and maintain decentralized AP or PCP
clustering in the BSS according to the procedures described in 10.37.2 and 10.37.3. In doing that, the AP or
PCP should set the minimum duration of the Beacon SP to be equal to the Beacon SP duration.
If the non-AP and non-PCP STA does not receive a DMG Beacon frame from its AP or PCP with
decentralized AP or PCP clustering enabled after dot11ClusterEnableTime following the transmission to its
AP or PCP of a Cluster Report element with the Cluster request subfield set to 1, the non-AP and non-PCP
STA may transmit an Announce frame including the last Extended Schedule element transmitted by the AP
or PCP. If the Announce frame is transmitted, it shall use MCS 0, and the TA field shall be set to the
broadcast address. If a DMG STA receives an Announce frame with the TA field set to the broadcast
address and with the BSSID field different from the BSSID of its BSS, the STA may send a Cluster Report
element containing the Extended Schedule element within the received Announce frame to its AP or PCP,
which might be used by the AP or PCP to reschedule SPs in portions of the beacon interval that are
nonoverlapping in time with the SPs contained in the Extended Schedule element reported by the STA.
If a non-AP and non-PCP STA becomes a member AP or member PCP of the clustering enabled by its
current AP or PCP, the non-AP and non-PCP STA can synchronize scheduled CBAP allocations, if any,
between the BSS in which it performs the role of AP or PCP and the BSS of its current AP or PCP. The non-
AP and non-PCP STA can disallow STAs in the BSS in which it plays the role of AP or PCP from
transmitting during the Beacon SPs of the cluster it is a part of, and this can be done by allocating an SP
time-overlapping with each Beacon SP such that each allocated SP has both the source AID and destination
AID fields within the Extended Schedule element set to the AID of the non-AP and non-PCP STA.
10.38 DMG beamforming
10.38.1 General
Beamforming (BF) is a mechanism that is used by a pair of STAs to achieve the necessary DMG link budget
for subsequent communication. BF training is a bidirectional sequence of BF frame transmissions that uses
sector sweep and provides the necessary signaling to allow each STA to determine appropriate antenna
system settings for both transmission and reception. After the successful completion of BF training, BF is
said to be established. A BF frame is an SSW frame, a DMG Beacon frame, an SSW-Feedback frame, an
SSW-Ack frame or a BRP frame. Figure 10-59 gives an example of the beamforming training procedure.
1532
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Sector Sweep BRP with final
Transmit Sector Sweep Feedback feedback
Initiator
SSW SSW SSW SSW BRP‐RX BRP‐TX
SSW SSW SSW SSW BRP‐RX BRP‐TX
Responder
Sector
BRP
Transmit Sector Sweep Sweep
Ack
Initiator Sector Sweep Responder Sector Sweep
Sector-Level Sweep Beam refinement
Figure 10-59—An example of beamforming training
In this subclause, the STA that initiates BF training through the transmission of a BF frame is referred to as
the initiator, and the recipient STA of the BF frame that participates in BF training with the initiator is
referred to as the responder. For BF training that occurs within the A-BFT allocation, the AP or PCP is the
initiator and a non-AP and non-PCP STA becomes the responder. For BF training that occurs during an SP
allocation, the source DMG STA of the SP is the initiator and the destination DMG STA of the SP becomes
the responder. For BF training during a CBAP allocation, the TXOP holder is the initiator and the TXOP
responder is the responder and the value of the Duration field in the transmitted BF frames does not limit the
duration of the BF training procedure. The duration of the BF training procedure is specified in 10.38.6.2
and 10.38.6.4.
The link from the initiator to the responder is referred to as the initiator link, and the link from the responder
to the initiator is referred to as the responder link.
BF training starts with a SLS from the initiator. A beam refinement protocol (BRP) may follow, if requested
by either the initiator or the responder. The purpose of the SLS phase is to enable communications between
the two participating STAs at the DMG control mode rate or higher MCS. Normally, the SLS phase provides
only transmit BF training. The purpose of the BRP phase is to enable receive training and enable iterative
refinement of the AWV of both transmitter and receiver at both participating STAs. If one of the
participating STAs chooses to use only one transmit antenna pattern, receive training may be performed as
part of the SLS.
Any BF information obtained by an initiator or a responder during a BF training attempt shall be considered
invalid if either or both of the following conditions are satisfied:
a) The SLS phase was not completed within dot11MaxBFTime beacon intervals from the start of the
SLS phase.
b) The BRP phase, if initiated, was not completed within dot11MaxBFTime beacon intervals from the
start of the BRP phase.
A STA shall abort an SLS if the SLS is not completed within dot11MaxBFTime beacon intervals from the
start of the SLS, and shall abort a BRP if the BRP is not completed within dot11MaxBFTime beacon
intervals from the start of the BRP.
A STA can have one or more DMG antennas. A DMG antenna can be used to create sectors through which
a STA can transmit or receive frames. The number of sectors per DMG antenna shall not be greater than 64.
The total number of sectors across all DMG antennas in a STA shall not be greater than 128.
1533
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 10-19 shows the mandatory and optional procedures in the beamforming mechanism described in this
subclause.
Table 10-19—Mandatory and optional procedures in the Beamforming mechanism
Support
Beamforming item Notes
mandatory
SLS phase (10.38.2, 10.38.6.2) Yes A DMG STA is capable to participate in an SLS
with any other STA as described in 10.38.2 and
10.38.6.2
Beamforming in BTI (10.38.4) Yes When operating as an AP or PCP, a DMG STA is
capable to perform beamforming in the BTI as
described in 10.38.4
Beamforming in A-BFT (10.38.5) Yes When operating as an AP or PCP, a DMG STA is
capable to perform beamforming in the A-BFT as
described in 10.38.5
BRP setup subphase (10.38.3.2) Yes A DMG STA is capable to negotiate BRP settings
with any other STA as described in 10.38.3.2
MIDC subphase MID subphase No A DMG STA does not have to be capable to perform
(10.38.6.3) MID as described in 10.38.6.3
BC subphase No A DMG STA does not have to be capable to perform
BC as described in 10.38.6.3
BRP phase Feedback = Yes A DMG STA is capable to perform the BRP with
(10.38.3, BS-FBCK any other STA as described in 10.38.3 and 10.38.6.4
10.38.6.4) and is capable to return the BS-FBCK
Feedback = No A DMG STA is capable to perform the BRP with
Channel any other STA as described in 10.38.3 and
measurement 10.38.6.4, but does not have to be capable to return
channel measurements
Beam tracking Feedback = Yes A DMG STA is capable of responding to a receive
(10.38.7) BS-FBCK beam tracking request. A DMG STA is capable of
responding to a transmit beam tracking request with
the BS-FBCK.
Feedback = No A DMG STA is capable of responding to a receive
Channel beam tracking request. A DMG STA does not have
measurement to be capable of responding to a transmit beam
tracking request with channel measurements.
An SLS between an initiator and a responder is successful for the initiator if, after the completion of the
SLS, the initiator receives a response to a frame transmitted to the responder using the sector and antenna
selected during the SLS. The SLS is successful for the responder if, after the completion of the SLS, the
responder receives a response to a frame transmitted to the initiator using the sector and antenna selected
during the SLS.
In this subclause, the last negotiated Total Number of Sectors field, Number of RX DMG Antennas field,
and RXSS Length field held by the initiator with respect to the responder refer to the last value of the
corresponding field received by the initiator from the responder and that the SLS between the initiator and
responder using this value was successful for the initiator. Similarly, the last negotiated Total Number of
Sectors field, Number of RX DMG Antennas field, and RXSS Length field held by the responder with
respect to the initiator refer to the last value of the corresponding field received by the responder from the
1534
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
initiator and that the SLS between the responder and initiator using this value was successful for the
responder.
Until an SLS is successful between an initiator and a responder, the last negotiated Total Number of Sectors
field, Number of RX DMG Antennas field, and RXSS Length field used by the initiator with respect to the
responder refer to the value of these fields in the responder’s DMG Capabilities element, and the last
negotiated Total Number of Sectors field, Number of RX DMG Antennas field, and RXSS Length field used
by the responder with respect to the initiator refer to the value of these fields in the initiator’s DMG
Capabilities element.
If an MMSL cluster capable STA has successfully transmitted to a peer STA an MMS element with the
BeamLink Cluster field set to 1, then all MAC entities coordinated by the same MM-SME as the MMSL
cluster capable STA shall use a single beamformed link for the MMSL cluster. Also, the MAC address used
by the MMSL cluster capable STA to initiate the beamforming procedure shall remain the same until the
completion of the beamforming procedure.
10.38.2 Sector-level sweep (SLS) phase
10.38.2.1 General
The SLS phase can include as many as four components: an initiator sector sweep (ISS) to train the initiator
link as described in 10.38.2.2, a responder sector sweep (RSS) to train the responder link as described in
10.38.2.3, an SSW feedback procedure as described in 10.38.2.4, and an SSW ack procedure as described in
10.38.2.5.
An initiator shall begin the SLS phase by transmitting the frames of the ISS.
A responder shall not begin transmitting the frames of an RSS before the ISS is successfully completed (as
defined in 10.38.1), except when the ISS occurs in the BTI (10.38.5).
An initiator shall not begin an SSW feedback procedure before the RSS phase is successfully completed (as
defined in 10.38.1), except when the RSS occurs in the A-BFT.
A responder shall not begin an SSW ack procedure with an initiator in the A-BFT. A responder shall begin
an SSW ack procedure with an initiator immediately following the successful completion (as defined in
10.38.1) of the SSW feedback procedure with the initiator.
During the SLS phase the only BF frames an initiator may transmit are the DMG Beacon frame, the SSW
frame, and the SSW-Feedback frame. During the SLS phase the only BF frames a responder may transmit
are the SSW frame and the SSW-Ack frame.
If during the SLS the initiator and responder each execute a TXSS, then at the end of the SLS phase both the
initiator and the responder possess their own transmit sector. If either the ISS or the RSS employs a receive
sector sweep, then the responder or the initiator, respectively, possesses its own receive sector.
The following rule applies to all channel access in DMG BSSs. A STA shall not transmit a frame as part of a
sector sweep comprising at least two sectors if a response is expected within SIFS interval from the STA
identified in the RA field of the transmitted frame.
A STA shall not change its transmit power during a sector sweep.
A frame transmitted as part of a sector sweep does not include training fields. A STA shall set the TRN-LEN
parameter of the TXVECTOR to 0 for a frame transmitted as part of a sector sweep.
1535
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Two examples of the SLS phases are shown in Figure 10-60 and Figure 10-61.
Transmit Sector Sweep Sector Sweep
Feedback
Initiator CDOWN=31 CDOWN=30 CDOWN=29 CDOWN=0
Sector Id=14 Sector Id=10 Sector Id=25 Sector Id=3
CDOWN=31 CDOWN=30 CDOWN=29 CDOWN=0
Sector Id=1 Sector Id=1 Sector Id=1 Sector Id=1
Best Sector=25 Best Sector=25 Best Sector=25 Best Sector=25
Responder
Receive Sector Sweep Sector
Sweep
Ack
Initiator Sector Sweep Responder Sector Sweep
Figure 10-60—An example of SLS
Sector Sweep
Transmit Sector Sweep Feedback
Initiator CDOWN=31 CDOWN=30 CDOWN=29 CDOWN=0
Best Sector=1
Sector Id=14 Sector Id=10 Sector Id=25 Sector Id=3
CDOWN=0
Sector Id=1
Best Sector=25
Responder
Transmit
Sector Sector
Sweep Sweep
Ack
Initiator Sector Responder Sector
Sweep Sweep
Figure 10-61—An example of SLS
In Figure 10-60 the initiator has many sectors, the responder has only one transmit sector and receive sector
sweep is used at the responder sector sweep (the responder is transmitting all responder SSW frames through
the same transmit sector, the initiator is switching receive antennas at the same time).
In Figure 10-61 the initiator has many transmit sectors, the responder has one transmit sector. In this case,
receive training for the initiator is performed in the BRP phase.
1536
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.38.2.2 Initiator sector sweep (ISS)
10.38.2.2.1 General
An ISS comprises either an initiator TXSS or an initiator RXSS.
An initiator RXSS may be performed in an ISS when the initiator chooses to use only one transmit antenna
pattern across each of its DMG antennas.
An initiator may employ either DMG Beacon frames or SSW frames in the ISS. If the initiator begins an ISS
with the transmission of a DMG Beacon frame, it shall use the DMG Beacon frame for all subsequent
transmissions during the ISS. Conversely, if the initiator begins an ISS with the transmission of an SSW
frame, it shall use the SSW frame for all subsequent transmissions during the ISS. A responder never begins
an ISS.
The initiator shall set the Direction subfield in the Sector Sweep field to 0 within each DMG Beacon and
SSW frame transmitted during an ISS.
The initiator shall set the Total Sectors in ISS subfield within the SSW Feedback field to the total number of
sectors that it is using in the ISS. The total is computed as the sum of all sectors employed on all antennas in
the ISS multiplied by the number of the responder’s receive DMG antennas. For example, if 4 sectors are
used on antenna 0, 3 sectors on antenna 1, 5 sectors on antenna 2, and the responder has two receive DMG
antennas, then the Total Sectors in ISS subfield is set to 24.
10.38.2.2.2 Initiator TXSS
When the IsInitiatorTXSS field for a specific SP is 1 in a received Extended Schedule element (see
9.4.2.132) or Grant frame (see 9.3.1.13) and the Beamforming Training field of the BF Control field for that
SP in the same Extended Schedule element or Grant frame is 1, then the SP contains an initiator TXSS, and
the initiator shall start an initiator TXSS at the start of the next SP as indicated by the received Extended
Schedule element or Grant frame.
During the BTI, the initiator shall start an initiator TXSS (see also 10.38.4).
During a CBAP, an initiator may obtain a TXOP with an initiator TXSS or use an existent TXOP for the
initiator TXSS. If transmission of a Grant frame to the responder is used to initiate the TXSS, the
Beamforming Training and IsInitiatorTXSS fields of the BF Control field is set to 1. If a Grant Ack frame is
transmitted by the responder, it shall comply with 10.36.4. In the Grant Ack frame, the responder shall set
the Beamforming Training field to 1. The initiator starts the initiator TXSS SIFS interval after transmission
of the Grant frame or after the reception of the Grant Ack frame if the Grant Ack Supported field in the
responder’s DMG Capabilities element is 1 or PIFS interval after the transmission the Grant frame
otherwise.
During an initiator TXSS, the Sector ID field in each BF frame shall be set to a value that uniquely identifies
the transmit antenna sector employed when the BF frame is transmitted. The CDOWN field in each
transmitted frame shall contain the total number of transmissions remaining until the end of the initiator
TXSS, including any LBIFS if required, such that the last BF frame transmission of the initiator TXSS has
the CDOWN field set to 0. Each transmitted BF frame shall be separated by a time interval equal to SBIFS,
unless the allocation ends as described in 10.38.6. This is indicated in Figure 10-62.
1537
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SBIFS (if same DMG antenna) or
LBIFS (if switching DMG antenna)
BF BF BF BF
...
frame frame frame frame
CDOWN=N-1 CDOWN=N-2 CDOWN=N-3 CDOWN=0
Figure 10-62—Initiator TXSS or initiator RXSS
If the initiator has more than one DMG antenna, the initiator transmits the BF frame through a number of
sectors equal to the value of the last negotiated Total Number of Sectors field that was transmitted by the
initiator to the responder. In each transmitted BF frame, the initiator shall set the Sector ID and DMG
Antenna ID fields to uniquely identify the sector and the DMG Antenna ID, respectively, the initiator is
using for the frame transmission and shall set the CDOWN field to the total number of transmissions
remaining from all of the initiator’s DMG antennas.
If an ISS is outside the BTI and if the responder has more than one DMG antenna, the initiator repeats its
initiator sector sweep for the number of DMG antennas indicated by the responder in the last negotiated
Number of RX DMG Antennas field that was transmitted by the responder. Repetitions of the initiator sector
sweep are separated by an interval equal to LBIFS. In this case CDOWN indicates the number of sectors
until the end of transmission from all initiator’s DMG antennas to all responder’s DMG antennas. At the
start of an initiator TXSS, the responder should have its first receive DMG antenna configured to a quasi-
omni pattern and should not change its receive antenna configuration for a time corresponding to the value
of the last negotiated Total Number of Sectors field transmitted by the initiator multiplied by the time to
transmit a single SSW frame, plus appropriate IFSs (10.3.2.3). After this time, the responder may switch to a
quasi-omni pattern in another DMG antenna.
The initiator TXSS ends at the end time of the BF frame from the initiator with the CDOWN field set to 0. If
the responder is unable to receive this frame, the responder shall assume that the initiator TXSS has
completed at the expected end time of this frame.
10.38.2.2.3 Initiator RXSS
An initiator RXSS may be requested only when an initiator is aware of the capabilities of a responder, which
includes the RXSS Length field. An initiator can obtain the capabilities of a responder using the Information
Request and Response procedure as described in 11.30.1.
When the IsInitiatorTXSS field for a specific SP in a received Extended Schedule element or Grant frame is
0 and the Beamforming Training field of the BF Control field for that SP in the same Extended Schedule
element or Grant frame is 1, then the SP shall contain an initiator RXSS, and the initiator shall start an
initiator RXSS at the start of the next SP described by the received Extended Schedule element or Grant
frame.
The initiator never performs an initiator RXSS during the BTI.
During a CBAP, an initiator shall not obtain a TXOP with an initiator RXSS. When transmission of a Grant
frame to the responder is used to initiate the RXSS the Beamforming Training field set to 1 and the
IsInitiatorTXSS field set to 0. If a Grant Ack frame is transmitted by the responder it shall comply with
10.36.4. In the Grant Ack frame, the responder shall set the Beamforming Training field to 1. The initiator
starts the initiator RXSS SIFS interval after transmission of the Grant frame or after the reception of the
1538
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Grant Ack frame if the Grant Ack Supported field in the responder’s DMG Capabilities element is 1 or PIFS
interval after the transmission the Grant frame otherwise.
If the initiator uses more than one transmit sector or more than one transmit DMG antenna to perform
beamforming with the responder, the initiator shall perform an initiator TXSS with the responder before
participating in an initiator RXSS with the responder.
During the initiator RXSS the initiator shall transmit from the DMG antenna and sector that were selected
during the preceding TXSS with the responder the number of BF frames indicated by the responder in the
last negotiated RXSS Length field transmitted by the responder. Each transmitted BF frame shall be
transmitted with the same fixed antenna sector or pattern. The initiator shall set the Sector ID and DMG
Antenna ID fields in each transmitted BF frame to a value that uniquely identifies the single sector through
which the BF frame is transmitted. The initiator shall set the CDOWN field in each transmitted BF frame to
contain the total number of transmissions remaining to the end of the initiator RXSS, such that the last BF
frame transmission of the initiator RXSS has the CDOWN field set to 0. Each transmitted BF frame shall be
separated by a time interval equal to SBIFS, except if the allocation ends as described in 10.38.6. This is
indicated in Figure 10-62.
During an initiator RXSS, the responder should have its receive antenna array configured to sweep RXSS
Length sectors, including any LBIFS if required, while attempting to receive SSW frames from the initiator.
The initiator RXSS ends at the end time of the SSW frame from the initiator with the CDOWN field set to 0.
If the responder is unable to receive this frame, the responder shall assume that the initiator RXSS has
completed at the expected end time of this frame.
10.38.2.3 Responder sector sweep (RSS)
10.38.2.3.1 General
An RSS comprises either a responder TXSS or a responder RXSS.
A responder RXSS may be performed in an RSS when the responder chooses to use only one transmit
antenna pattern across each of its DMG antennas.
The responder initiates an RSS with the transmission of an SSW frame, which is the only frame allowed
during an RSS.
The responder shall set the Direction subfield in the Sector Sweep field to 1 within each SSW frame
transmitted during an RSS.
10.38.2.3.2 Responder TXSS
If the DMG Beacon frame immediately preceding an A-BFT contained a value of one in the
IsResponderTXSS subfield of the Beacon Interval Control field, then the A-BFT is a responder TXSS A-
BFT.
When the IsResponderTXSS field for a specific SP in a received Extended Schedule element or Grant frame
is 1 and the Beamforming Training field of the BF Control field for that SP in the same Extended Schedule
element or Grant frame is 1, then the SP contains a responder TXSS, and the responder shall initiate a TXSS
following the completion of the ISS in the SP described by the received Extended Schedule element or Grant
frame.
1539
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the RXSS Length field within an SSW frame used to obtain a TXOP during a CBAP is 0, the
responder shall initiate a TXSS following the completion of the ISS in the TXOP described by the received
SSW frame.
During a responder TXSS, the responder shall set the Sector ID and the DMG Antenna ID fields in each
transmitted SSW frame to a value that uniquely identifies the sector through which the SSW frame is
transmitted. The initial value of CDOWN is set to the total number of sectors in the responder (covering all
DMG antennas) multiplied by the number of DMG antennas at the initiator minus one. The responder shall
set the CDOWN field in each transmitted SSW frame to contain the total number of transmissions remaining
to the end of the responder TXSS, including any LBIFS if required, such that the last SSW frame
transmission of the responder TXSS has the CDOWN field set to 0. The responder shall transmit from its
DMG antennas in increasing order of Antenna ID. Each transmitted SSW frame shall be separated by an
interval of time equal to SBIFS. Transmissions are not separated by SBIFS if the allocation ends as
described in 10.38.4 and 10.38.6 or if the end of an SSW slot is reached as described in 10.38.5 or when the
responder completed a full sweep of all its transmit sectors and is ready to transmit to another DMG antenna
of the initiator. In the latter case, the next transmission is separated from the previous transmission by LBIFS
interval. This is indicated in Figure 10-63.
SBIFS (if same DMG antenna) or
LBIFS (if switching DMG antenna)
SSW SSW SSW SSW
...
frame frame frame frame
CDOWN=N-1 CDOWN=N-2 CDOWN=N-3 CDOWN=0
Figure 10-63—Responder TXSS or responder RXSS
A responder that has more than one DMG antenna and has set the value of the DMG Antenna Reciprocity
field in its DMG Capabilities element to 0 transmits sequentially through all of the sectors of all of its DMG
antennas. A responder that has more than one DMG antenna and has set the value of the DMG Antenna
Reciprocity field in the responder’s DMG Capabilities element to 1 transmits through the DMG antenna
from which it had the best reception in the initiator sector sweep. The length of the sector sweep to each of
the initiator’s DMG antennas is not dependent on the value of the DMG Antenna Reciprocity field.
A responder that has only one DMG antenna should transmits through all its sectors, regardless of the setting
of the DMG Antenna Reciprocity field.
The responder shall set the Sector Select field and the DMG Antenna Select field in each transmitted SSW
frame to the value of the Sector ID field and DMG Antenna ID field, respectively, of the frame received with
the best quality during the ISS. The determination of which frame is received with best quality is
implementation dependent and beyond the scope of this standard. The responder shall set the SNR Report
field to the SNR measured for the frame indicated by the Sector Select field and DMG Antenna Select field.
If the initiator has more than one DMG antenna, the responder repeats its responder sector sweep for the
number of DMG antennas indicated by the initiator in the last negotiated Number of RX DMG Antennas
field transmitted by the initiator. At the start of a responder TXSS, the initiator should have its receive
antenna array configured to a quasi-omni antenna pattern in one of its DMG antennas for a time
corresponding to the value of the last negotiated Total Number of Sectors field transmitted by the responder
multiplied by the time to transmit a single SSW frame, plus any appropriate IFSs (10.3.2.3). After this time,
the initiator may switch to a quasi-omni pattern in another DMG antenna.
1540
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The responder TXSS ends at the end time of the SSW frame from the responder with the CDOWN field set
to 0. If the initiator is unable to receive this frame, the initiator shall assume that the responder TXSS has
completed at the expected end time of this frame.
10.38.2.3.3 Responder RXSS
If the DMG Beacon frame immediately preceding an A-BFT contained a value of zero in the
IsResponderTXSS subfield of the Beacon Interval Control field within the DMG Beacon, then the A-BFT is
a responder RXSS A-BFT.
When the IsResponderTXSS field for a specific SP in a received Extended Schedule element or Grant frame
is 0 and the Beamforming Training field of the BF Control field for that SP in the same Extended Schedule
element or Grant frame is 1, then the SP contains a responder RXSS, and the responder shall initiate an
RXSS following the completion of the ISS in the SP described by the received Extended Schedule element
or Grant frame.
When the RXSS Length field within an SSW frame used to obtain a TXOP during a CBAP is equal to a
nonzero value, the responder shall initiate an RXSS following the completion of the ISS in the TXOP
described by the received SSW frame.
If the responder chooses to use more than one transmit sector or more than one transmit DMG antenna to
perform beamforming with the initiator, the responder shall perform a responder TXSS with the initiator
before participating in a responder RXSS with the initiator.
During the responder RXSS, the responder shall transmit the number of SSW frames indicated by the
initiator in the initiator’s most recently transmitted RXSS Length field (non-A-BFT) or FSS field (A-BFT)
from the DMG antenna and sector that were selected during the preceding TXSS with the initiator. The
responder shall set the Sector ID and DMG Antenna ID fields in each transmitted frame to a value that
uniquely identifies the sector and DMG antenna, respectively, through which the BF frame is transmitted.
The responder shall set the CDOWN field in each transmitted SSW frame to contain the total number of
transmissions remaining until the end of the responder RXSS, such that the last SSW frame transmission of
the responder RXSS has the CDOWN field equal to 0. Each transmitted SSW frame shall be separated by an
interval of time equal to SBIFS, except if the allocation ends as described in 10.38.6 or if the end of an SSW
slot is reached as described in 10.38.5. This is indicated in Figure 10-63.
The responder shall set the Sector Select field and the DMG Antenna Select field in each transmitted SSW
frame to the value of the Sector ID field and the DMG Antenna ID field, respectively, of the frame received
with the best quality during the ISS. The determination of which frame is received with best quality is
implementation dependent and beyond the scope of this standard.
At the start of a responder RXSS, the initiator should have its receive antenna array configured to sweep
over RXSS Length sectors, including any LBIFS if required, when it attempts to receive frames from the
responder until the completion of the responder RXSS.
The responder RXSS ends at the end time of the SSW frame from the responder with the CDOWN field set
to 0. If the initiator is unable to receive this frame, the initiator shall assume that the responder RXSS has
completed at the expected end time of this frame.
10.38.2.4 Sector sweep (SSW) feedback
An SSW feedback procedure occurs following each RSS.
During an SSW feedback procedure, the initiator shall transmit an SSW-Feedback frame to the responder.
1541
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
During an SSW feedback procedure, the responder should have its receive antenna array configured to a
quasi-omni antenna pattern in the DMG antenna through which it received with the highest quality during
the ISS, or to the best antenna configuration it has found during RXSS if RXSS has been performed during
the ISS, and should not change its receive antenna configuration when it communicates with the initiator
until the expected end of the SSW feedback procedure.
When responder TXSS was performed during the preceding RSS, the initiator shall set the Sector Select
field and the DMG Antenna Select field in the SSW-Feedback frame it transmits to the value of the Sector
ID field and DMG Antenna ID field, respectively, of the frame received with the best quality during the
responder TXSS. The determination of which frame is received with the best quality is implementation
dependent and beyond the scope of this standard. In addition, the initiator shall set the SNR Report field to
the SNR measured for the frame received by the sector and DMG antenna indicated by the Sector Select
field and DMG Antenna Select field. The SSW-Feedback frame shall be transmitted through the sector
identified by the value of the Sector Select field and DMG Antenna Select field received from the responder
during the preceding responder TXSS.
When responder RXSS was performed during the preceding RSS, the Sector Select field and the DMG
Antenna select field in the transmitted SSW-Feedback frame are reserved. The initiator shall set the SNR
Report field to the SNR measured on the frame on the receive sector designated by the RSS. The SSW-
Feedback frame shall be transmitted through the sector identified by the value of the Sector Select field
received from the responder during its most recently completed RSS with the initiator.
The initiator may include transmit training as part of the beam refinement phase by setting the TX-TRN-
REQ field to 1 in the SSW Feedback frame and setting the L-RX field to indicate the length of the training
sequence it requests the responder to use in the beam refinement phase. The initiator may carry out the
MIDC subphase as part of the beam refinement by setting the BC-REQ field to 1 (to request a BC subphase)
and setting the MID-REQ field to 1 (to request an MID subphase); in this case, the L-RX field shall be set to
indicate the number of receive AWVs the initiator uses during the MID subphase.
If the responder receives an SSW-Feedback frame from the initiator before it completes the RSS with the
initiator such as described in 10.38.5, the responder may cease the RSS.
10.38.2.5 SSW ack
When present, the SSW ack procedure occurs following an SSW feedback procedure.
When a responder TXSS is performed during an RSS, the responder shall transmit an SSW-Ack frame to the
initiator to perform an SSW ack procedure. The SSW-Ack frame shall be transmitted through the sector
identified by the value of the Sector Select field and the DMG Antenna Select field received from the
initiator in the last SSW-Feedback frame.
When an RXSS was performed during an RSS, an SSW-Ack frame shall be sent by the responder to the
initiator. The SSW-Ack frame should be sent using the DMG antenna indicated in the DMG Antenna Select
field in the last SSW-Feedback frame.
The responder may include transmit training as part of the beam refinement phase by setting the TX-TRN-
REQ field to 1 in the SSW-Ack frame and setting the L-RX field to indicate the length of the training
sequence it requests the initiator to use in the beam refinement phase, as described in 9.5.4. The responder
may carry out a MID subphase by setting the MID-REQ bit to 1 in the BRP Request field of the SSW frame.
In this case, it shall also set the L-RX field to indicate the number of receive AWVs it uses during the MID
subphase. The responder may carry out a BC subphase by setting the BC-REQ bit to 1. If the initiator has set
either the MID-REQ or the BC-REQ fields to 1 in the SSW-Feedback frame, the responder may set the
MID-Grant or the BC-Grant fields to 1, or both, to grant the requests.
1542
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
At the start of an SSW ack procedure, the initiator should have its receive antenna array configured to a
quasi-omni antenna pattern using the DMG antenna through which it received with the highest quality
during the RSS, or the best receive sector if an RXSS has been performed during the RSS, and should not
change its receive antenna configuration while it attempts to receive from the responder until the expected
end of the SSW ack procedure.
10.38.3 Beam Refinement Protocol (BRP) phase
10.38.3.1 General
BRP is a process in which a STA trains its RX and TX antenna array(s) and improves its TX antenna
configuration and RX antenna configuration using an iterative procedure. BRP may be used regardless of
the antenna configuration a STA supports.
The BRP phase is composed of a BRP setup subphase, a Multiple sector ID Detection (MID) subphase, a
Beam Combining (BC) subphase, a subset of the previous subphases, and one or more beam refinement
transactions. BRP setup allows STAs to exchange beam refinement capability information and to request the
execution of the other BRP subphases. MID and BC (collectively, the MIDC subphase) are optionally used
to find better initial AWVs for iterative beam refinement than might have been found by SLS due to
imperfect quasi-omni receive antenna patterns. In MID, a quasi-omni transmit pattern is tested against a
number of receive AWVs; this reverses the scanning roles from the transmit sector sweep. In BC, a small set
of transmit and receive AWVs are tested in pairwise combinations, thus avoiding the use of quasi-omni
patterns. Finally, given the starting point from SLS or MIDC, STAs can explore a broader set of transmit
and receive AWVs using a request/response exchange referred to as a beam refinement transaction.
The BRP setup subphase may be skipped if the BRP follows an SSW-Ack frame and no MID or BC
subphases were requested during the SLS. MID and BC subphases can be skipped if either STA indicates
that the subphase is not needed by setting the MID-REQ and BC-REQ fields to 0 or by setting the MID-
Grant and BC-Grant fields to 0. The beam refinement transaction can be skipped if both sides indicate that
the transaction is not needed by setting the L-RX and TX-TRN-REQ fields to 0.
The BRP setup subphase is defined in 10.38.3.2.
The MID subphase is composed of either an R-MID subphase or an I-MID subphase or both, which are
composed of one or more transmissions of BRP-RX packets (20.10.2.2), followed by feedback contained in
the next BRP frames from the initiator and responder.
The BC subphase is composed of either an R-BC subphase or an I-BC subphase or both, which are
composed of transmission of BRP-RX packets to select a beam, followed by feedback.
A beam refinement transaction is a set of BRP frames consisting of beam refinement requests and responses.
A beam refinement request can be either a transmit beam refinement request or a receive beam refinement
request or both.
A transmit beam refinement request (TX-TRN-REQ field within the BRP Request field set to 1) indicates
the need for transmit antenna array training by the transmitting STA. The BRP packet that has the TX-TRN-
REQ set to 1 (or the next BRP packet from this STA) shall include transmit training (TRN-T) subfields
appended to it. The STA responding to the BRP packet shall include feedback based on measurements it
performed during the reception of the BRP packet. The feedback type is dictated by the FBCK-TYPE field
within the DMG Beam Refinement element contained in the BRP packet.
A receive beam refinement request (L-RX field within the BRP Request field greater than zero) indicates the
need of the receive antenna array training for the transmitting STA. The responding STA shall respond with
a BRP packet with receive training (TRN-R) subfields appended to it.
1543
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Requests and responses can be combined in the same frame. As an example, the same frame can be both a
transmit beam refinement request and a receive beam refinement request. The same frame can also be
used as receive beam refinement response and a receive beam refinement request. See the example in
Figure 10-64.
Transmit BRP
BRP train
request,
response,
TX-TRN-REQ=1,
RX-Train-
Receive BRP
response=1
request,
L-RX>0 TRN-T
TRN-R
subfields
subfields
≥SIFS ≥SIFS ≥SIFS
≤BRPIFS ≤BRPIFS ≤BRPIFS
Transmit BRP Feedback, TX- TRN-R BRP Frame,
train-response=1 subfields No requests
Receive BRP training, RX-train-
response=1
Receive BRP request, L-RX>0
TX-TRN-OK=1
Figure 10-64—Example of beam refinement transaction
A beam refinement response is separated from a preceding beam refinement request by at least a SIFS
interval and at most a BRPIFS interval provided sufficient time is available for the complete transmission of
those frames within the SP allocation or TXOP. Similarly, a beam refinement request, if any, is separated
from a preceding beam refinement response by at least a SIFS interval and at most a BRPIFS interval
provided sufficient time is available for the complete transmission of the beam refinement request within the
SP allocation or TXOP.
When performing BRP, if a responding STA requires longer than SIFS to transmit a BRP frame as a
response for beam refinement training request from a requesting STA, the responding STA should keep the
IFS not longer than SIFS by transmitting one or more PPDUs to the requesting STA.
When the beam refinement occurs within the same allocation as the SLS, the SLS initiator is the beam
refinement initiator. If the beam refinement occurs in a separate allocation, the STA that transmits the first
beam refinement request is the beam refinement initiator. The other STA is the beam refinement responder.
A beam refinement transaction is complete when one of the following conditions is met:
a) the initiator determines that it does not need further training and it has received a BRP frame with no
training requests from the beam refinement responder.
b) a duration equal to BRPIFS plus aSlotTime has elapsed since the last transmission from the beam
refinement initiator to the refinement responder without a response from the beam refinement
responder.
In Figure 10-64, the first packet (from the initiator) has TX-TRN-REQ=1, the L-RX field has a value greater
than zero and TRN-T subfields are appended to the packet. The second packet (from the responder) has a
1544
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
value greater than zero in the L-RX field, the TX-train-response field set to 1, the RX-train-response field set
to 1, and TRN-R subfields are appended to the packet. The last packet (from the initiator) has RX-train-
response set to 1 and TRN-R subfields are appended to the packet.
10.38.3.2 BRP setup subphase
The BRP setup subphase is used to exchange the intent and capabilities to conduct some or all of the
subphases and beam refinement transactions in a subsequent BRP phase. The BRP setup subphase is used to
set up the MIDC subphase, but can also be used to set up beam refinement transactions.
The BRP setup subphase shall be used in the following two cases:
— When the RSS part of the SLS phase occurred in an A-BFT, in which case the SSW-Ack frame was
not part of the SLS.
— When the initiator set the MID-REQ or BC-REQ fields in the SSW-Feedback frame to 1 or the
responder set the MID-REQ or BC-REQ fields in the SSW-Ack frame to 1.
The BRP setup subphase starts with the initiator sending a BRP packet with the Capability Request subfield
set to 1 and with the remaining subfields within the BRP Request field set according to the initiator’s need
for an MID subphase, a BC subphase, and a beam refinement subphase. The BRP setup subphase can also
start when the responder grants a MID-REQ or BC-REQ through the SSW-Ack frame or when the responder
requests MID or BC in the SSW-Ack frame. Upon receiving a BRP packet with the Capability Request
subfield set to 1, the responder shall respond with a BRP packet with the subfields within the BRP Request
field set to indicate the presence of an MID subphase, a BC subphase and a beam refinement subphase. This
process is repeated until the responder transmits to the initiator a BRP packet with the Capability Request
subfield set to 0 and the initiator sends as a response a BRP packet with the Capability Request subfield also
set to 0. The BRP packet from the initiator that initiates the termination of the BRP setup subphase can be
the first BRP packet of the BRP phase, either as part of beam refinement or as part of a MID or BC
subphase.
A DMG STA (either initiator or responder) requests MID and BC subphases (see 10.38.6.3.2) by setting
both the MID-REQ and BC-REQ subfields to 1 in the BRP Request field of an SSW-Feedback, SSW-Ack or
BRP frame. It shall also set the L-RX subfield in the BRP Request field to the number of RX AWV settings
it needs in each BRP-RX packet during the MID subphase. The peer STA grants the request by setting the
MID-Grant and BC-Grant subfields to 1 in the BRP Request field within the next SSW-Ack or BRP frame
transmitted to the requesting DMG STA. If either the MID or BC were not granted by the peer STA, the
MID and BC subphases shall not occur.
A DMG STA (either initiator or responder) requests an MID only subphase (see 10.38.6.3.3) by setting the
MID-REQ subfield to 1 in the BRP Request field of an SSW-Feedback, SSW-Ack or BRP frame. The STA
shall also set the L-RX subfield in the BRP Request field to the number of RX AWV settings it needs in each
BRP-RX packet during the MID-subphase. The peer STA grants the request by setting the MID-Grant
subfield to 1 in the BRP Request field within the next SSW-Ack or BRP frame transmitted to the requesting
DMG STA. The Capability Request subfield and request subfields (TX-TRN-REQ, L-RX, MID-REQ, BC-
REQ) within the granting frame shall be set to 0.
If the MID-REQ was granted, the requesting STA shall transmit a BRP frame with the SNR Present and
Sector ID Order Present subfields set to 1 and with the Number of Measurements field in the FBCK-TYPE
field indicating the number of SNR measurements from the last SLS phase. In the Channel Measurement
Feedback element, the requesting STA sets the SNR subfields to the SNRs corresponding to the TX sectors
received during the SLS phase. In the Sector ID Order subfield, the requesting STA lists the sector IDs of the
received sectors. The Capability Request field within the BRP frame shall be set to 0. The MID subphase
starts with the transmission of a BRP packet from the peer STA after the reception of the list of sectors. A
STA that has granted a MID only request shall not request MID or BC in the response packet. The STA may
1545
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
request MID or BC in the last packet it transmits to the requesting STA as part of the MID. The MID only
subphase shall not occur if it was not granted by the peer STA.
A DMG STA (either initiator or responder) requests a BC only subphase (see 10.38.6.3.4) by setting the BC-
REQ subfield to 1 in the BRP Request field of an SSW-Feedback, SSW-Ack, or BRP frame. The peer STA
(either a responder or initiator) grants the request by setting the BC-Grant subfield to 1 in the BRP Request
field within the next SSW-Ack or BRP frame transmitted to the requesting STA. The BC subphase shall not
occur if the peer STA does not grant the request.
A DMG STA indicates that beam refinement transactions (10.38.6.4.2) occur by setting the L-RX field to a
value greater than 0 to indicate the need for receive beam refinement or by setting the value of the TX-TRN-
REQ field to 1 to indicate the need for transmit beam refinement or by setting both. The beam refinement
transactions shall occur if at least one of these conditions is met.
If the initiator has requested an MID subphase by setting the MID-REQ subfield or the BC-REQ subfield to
1 and the responder rejected by setting in the response the MID-Grant subfield or the BC-Grant subfield to
0, respectively, the initiator should send a BRP frame with the MID-REQ field set to 0 and the L-RX field
set to indicate the number of TRN-R fields the initiator requests for use in the BRP transaction.
If the responder has requested an MID subphase by setting the MID-REQ subfield or the BC-REQ subfield
to 1 and the initiator rejected by setting in the response the MID-Grant or the BC-Grant subfields to 0, the
initiator should send a BRP frame with the Capability Request subfield set to 1. The responder shall respond
with a BRP frame with the MID-REQ field set to 0 and the L-RX field set to indicate the number of TRN-R
fields the responder requests for use in the BRP transaction.
Beam refinement transactions shall occur following a MIDC subphase when one or both of the following
conditions are met at the last BRP frame transmitted by either the initiator or responder as part of the MID or
BC subphases:
a) Either the initiator or the responder set the L-RX field to a value greater than 0.
b) Either the initiator or responder has set the value of the TX-TRN-REQ field to 1.
If within the appropriate IFS the initiator does not receive a response from the responder to a packet
transmitted to the responder, the initiator may retransmit the packet.
After the BRP setup subphase, beamforming training shall immediately continue to the next phase (i.e.,
either MIDC subphase or the beam refinement transactions). Examples of BRP setup subphase procedures
are illustrated in Figure 10-65, Figure 10-66, Figure 10-70, Figure 10-71, and Figure 10-77.
1546
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Initiator=1,
Capability Request=1
L‐RX>0, Initiator=1,
TX‐TRN‐REQ=1 Capability Request=0
Initiator TXSS
Initiator
SSW‐Feedback
DMG Beacon
DMG Beacon
BRP
BRP
BRP
...
SLS (BTI+A‐BFT) BRP setup (ATI+DTI) BRP transactions (DTI)
SSW
SSW
BRP
BRP
...
Responder
Responder TXSS
Time separation between BRP frame
Initiator=0,
Capability Request=0, exchanges: ≥ SIFS and ≤ BRPIFS
L‐RX>0, TX‐TRN‐REQ=1
Figure 10-65—Example of BRP setup subphase procedure (SLS in BTI and A-BFT)
L-RX>0, TX-TRN-
REQ=1
Initiator TXSS
Initiator
SSW-Feedback
BRP setup sub-phase
SSW
SSW
BRP
... is skipped in this case
SLS BRP transactions
SSW-Ack
SSW
SSW
BRP
...
Responder
Responder TXSS
Time separation between BRP frame
L-RX>0, TX-TRN- exchanges: ≥ SIFS and ≤ BRPIFS
REQ=1
Figure 10-66—Example of skipping the BRP setup subphase (SLS in DTI)
10.38.4 Beamforming in BTI
In the BTI, the AP or PCP performs an initiator TXSS as the first part of the SLS with the transmission of at
least one DMG Beacon frame. The AP or PCP does not transmit SSW frames in the BTI (10.38.2.2.1).
The AP or PCP may fragment the initiator TXSS over multiple consecutive BTIs by not transmitting a DMG
Beacon frame through all sectors available to the AP or PCP in a single BTI. In a BTI with a fragmented
initiator TXSS, the AP or PCP shall transmit DMG Beacon frames with the Fragmented TXSS field set to 1.
1547
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Otherwise, the AP or PCP shall set the Fragmented TXSS field to 0. The AP or PCP shall not change the
duration of the next BTI if at least one of the DMG Beacon frames transmitted in the current BTI have the
Fragmented TXSS field set to 1. The CDOWN field shall be set to the total number of transmissions
remaining to the end of the initiator TXSS, such that the last DMG Beacon frame transmission of the
initiator TXSS has the CDOWN field set to 0 (i.e., in a fragmented TXSS, the value of the CDOWN field
covers the total number of transmissions remaining in the fragmented TXSS). The TXSS Span field shall be
set to the total number of beacon intervals it takes the AP or PCP to complete the entire TXSS phase. The
Duration field within each transmitted DMG Beacon frame shall be set to the time remaining until the end of
the current BTI.
When an AP or PCP has more than one DMG antenna, the TXSS shall cover all of the sectors in all DMG
antennas. The TXSS Span field indicates the total number of beacon intervals it takes the AP or PCP to
cover all sectors in all DMG antennas. The value of the TXSS Span field shall be lower than
dot11MaximalSectorScan. The AP or PCP shall not change DMG antennas within a BTI. The AP or PCP
has a regular schedule of transmitting through each DMG antenna (see 10.38.5.4).
NOTE—If an unassociated responder receives a DMG Beacon frame in the BTI with a fragmented initiator TXSS, the
responder may start a responder TXSS in the following A-BFT, or it may scan for the number of beacon intervals
indicated in a received TXSS Span field in order to cover a complete initiator TXSS and find a suitable TX sector from
the AP or PCP.
Each subfield in the Beacon Interval Control field and DMG Parameters field of each DMG Beacon frame
transmitted by the AP or PCP shall retain the same value from start to completion of a TXSS phase.
10.38.5 Beamforming in A-BFT
10.38.5.1 Allocation of A-BFT
The AP or PCP shall allocate an A-BFT period MBIFS following the end of a BTI that included a DMG
Beacon frame transmission with Next A-BFT equal to 0.
Following the end of a BTI, the AP or PCP shall decrement the value of the Next A-BFT field by 1 provided
it is not equal to 0 and shall announce this value in the next BTI. The AP or PCP may increase the Next A-
BFT field value following a BTI in which the Next A-BFT field was equal to 0. A STA shall consider that a
BTI is completed at the expiration of the value within the Duration field of the last DMG Beacon frame
received in that BTI.
All DMG Beacon frames transmitted within the number of beacon intervals specified within the most
recently updated TXSS Span field have the same value for each subfield within the Beacon Interval Control
field (11.1.3.3).
10.38.5.2 Operation during the A-BFT
Beamforming training in the A-BFT consists of the RSS and SSW feedback procedures of the SLS between
the AP or PCP and a STA.
In the A-BFT, the AP or PCP is the initiator and the STA is the responder in the RSS part of the SLS
(10.38.2.3). The BRP phase shall not be performed within the A-BFT. A STA shall not transmit in the A-
BFT of a beacon interval if it does not receive at least one DMG Beacon frame during the BTI of that beacon
interval.
A DMG STA that receives a DMG Beacon frame with the Discovery Mode field equal to 1 may transmit in
the A-BFT following the BTI where the DMG Beacon frame is received if at least one of the following
conditions is met:
1548
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The CC Present field within the received DMG Beacon frame is equal to 1 and the STA’s MAC
address is equal to the value of the A-BFT Responder Address subfield within the received DMG
Beacon frame.
— The CC Present field within the received DMG Beacon frame is equal to 1, the value of the A-BFT
Responder Address subfield within the received DMG Beacon frame is a group address of a group
to which the STA belongs, and the responding STA’s role matches the role identified by the value of
the BSS Type subfield within the received DMG Beacon frame and the “Responding STA role”
column of Table 9-65.
— The CC Present field within the received DMG Beacon frame is equal to 0
If none of these conditions is met following the reception of a DMG Beacon frame with the Discovery Mode
field equal to 1, the STA shall not transmit in the A-BFT.
The A-BFT is slotted and the length of the A-BFT is an integer multiple of the sector sweep slot time. The
structure of the A-BFT is shown in Figure 10-67. The AP or PCP shall announce the size of the A-BFT in
the A-BFT Length subfield of the Beacon Interval Control field (9.3.4.2). The first SSW slot begins at
the start of the A-BFT, and the following SSW slots are adjacent and nonoverlapping. An SSW slot
(Figure 10-68) is a period of time within the A-BFT that can be used by a responder to transmit at least one
SSW frame. An SSW slot has a duration of aSSSlotTime. aSSSlotTime is defined to be
aSSSlotTime = aAirPropagationTime + aSSDuration + MBIFS + aSSFBDuration + MBIFS
where
aAirPropagationTime accounts for the propagation delay between the initiator and the responder
aSSDuration (11.39) provides time for a responder to transmit up to the number of SSW
frames announced in the FSS subfield of the Beacon Interval Control field in the
DMG Beacon
aSSFBDuration provides time for the initiator to perform an SSW feedback procedure (see 11.39)
The initiator shall set the FSS subfield of the Beacon Interval Control field in the DMG Beacon frame to a
value that is no less than aSSFramesPerSlot.
If the IsResponderTXSS subfield of the Beacon Interval Control field is equal to 1, the A-BFT shall be used
to perform a responder TXSS. Otherwise, the A-BFT shall be used to perform a responder RXSS. In the case
of a responder RXSS, the same slotted structure described above is used and the responder shall transmit the
number of SSW frames announced in the FSS field in the DMG Beacon. If the AP or PCP allocates the A-
BFT as a responder RXSS, it should set the value of the FSS field within the Beacon Interval Control to the
number of receive sectors supported by the AP or PCP. The AP or PCP shall allocate the A-BFT as a
responder TXSS at least once every dot11ABFTRTXSSSwitch beacon intervals in which an A-BFT is
present.
At the start of each A-BFT, the responder(s) shall invoke a random backoff procedure to initiate or resume
an RSS as follows. The random backoff procedure begins at the start of the A-BFT with the responder
selecting a backoff count as a random integer drawn from a uniform distribution [0, A-BFT Length), i.e., 0
to A-BFT Length – 1, where A-BFT Length is the value of the A-BFT Length field in the last received DMG
Beacon. The responder shall decrement the backoff count by one at the end of each SSW slot, even if the CS
function at the responder indicates the medium busy condition for that SSW slot. The responder may initiate
the RSS only at the start of the SSW slot for which the backoff count is 0 at the beginning of the SSW slot.
1549
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beacon Interval
BTI A-BFT ATI DTI BTI
aSSSlotTime
A-BFT LENGTH = 8
SSW-
Feedb ... SSW-
Feedb
ack ack
SBIFS
SSW
Number of SSW frames transmitted in aSSDuration = Value of the
FSS subfield of the Beacon Interval Control field within the DMG
Beacon. In the example shown above, the value of FSS is 8.
Example of A-BFT with length 8 and with each SSW slot accommodating 8 SSW frames. A
possible contention between 3 STAs is shown in the figure below: STAs A, B and C are
competing for access. All STAs choose a random value between [0,7]. STA A chooses value = 2,
while STAs B and C choose value = 5, which might result in a collision.
STA B
STA A
&C
Figure 10-67—A-BFT structure
e
im
T
n
io
t
a
g
Responder TXSS or SSW
a Responder RXSS Feedback
p
o
r S S
P F
I F
I
ir B B
A M M
a
aSSDuration aSSFBDuration
aSSSlotTime
Figure 10-68—SSW slot (aSSSlotTime) definition
The responder shall transmit no more SSW frames within an SSW slot than indicated in the value of the FSS
subfield in the DMG Beacon. If the responder has more SSW frames to transmit as part of the RSS, but is
not allowed to send any more SSW frames in the current SSW slot, then the responder may resume the RSS
at the start of the following SSW slot provided that the A-BFT has not ended. If the responder cannot
complete the RSS before the end of the A-BFT, it may use the same backoff procedure described above to
resume the RSS at the next A-BFT for which the value of the IsResponderTXSS field is the same as the
current A-BFT.
The initiator shall initiate an SSW feedback procedure to a responder (10.38.2.4) at a time such that the
beginning of the first symbol of the SSW-Feedback frame on the WM occurs at aSSFBDuration + MBIFS
before the end of the SSW slot. A responder that transmitted at least one SSW frame within an SSW slot
shall be in quasi-omni receive mode for a period of aSSFBDuration ending MBIFS before the end of the
1550
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SSW slot. The initiator may initiate an SSW feedback procedure to the responder at an SSW slot even if the
responder did not complete RSS within that SSW slot. If the initiator transmits an SSW-Feedback under this
circumstance, it can transmit an Announce frame to the responder in an ATI. Following the reception of the
Announce frame, the responder can respond with an SPR frame requesting time for the responder to
continue with the RSS. Alternatively, the responder can transmit an SPR frame to the AP or PCP in
accordance with the channel access rules.
The information contained in an SSW-Feedback frame is based on the SSW frames received during the
SSW slot in which the SSW-Feedback frame was transmitted. To communicate with each other following an
SLS, an initiator and responder should use the information contained within the SSW-Feedback frame that
had the highest value in its SNR Report field and was transmitted or received, respectively, as part of the
most recent SLS between the initiator and responder.
A responder that receives an SSW-Feedback frame from the initiator during an A-BFT that was allocated
with a DMG Beacon frame with Discovery Mode equal to 1 should not attempt to access the following
aMaxABFTAccessPeriod A-BFT allocations to redo beamforming with the initiator, unless in the BTI
preceding the A-BFT the responder receives a DMG Beacon frame that has the Discovery Mode field equal
to 1, the CC Present field equal to 1 and the value of the A-BFT Responder Address subfield equal to the
responder’s MAC address. This allows other STAs the opportunity to successfully contend for A-BFT
access and perform beamforming with the initiator.
The responder may attempt to restart the RSS within the same A-BFT if it does not receive an SSW-
Feedback frame from the initiator by the end of the SSW slot in which it completes the RSS. To do this, the
responder shall invoke the random backoff procedure beginning at the start of the SSW slot following the
completion of the RSS. The responder shall select a backoff count as a random integer drawn from a
uniform distribution [0, A-BFT Length), i.e., 0 to A-BFT Length – 1, where A-BFT Length is the value of
the A-BFT Length field in the last received DMG Beacon. The responder shall decrement the backoff count
by one at the end of each SSW slot, even if the CS function at the responder indicates the medium busy
condition for that SSW slot. The responder may restart the RSS at the start of the SSW slot for which the
backoff count is 0 at the beginning of the SSW slot provided the A-BFT still has SSW slots available.
At the end of an A-BFT the responder shall cancel a backoff procedure that was started during the A-BFT,
but has not been completed at the end of the A-BFT. As described above, the responder invokes a random
backoff procedure at the start of each A-BFT.
Each STA maintains a counter, FailedRSSAttempts, of the consecutive number of times the STA initiates
RSS during A-BFTs but does not successfully receive an SSW-Feedback frame as a response. If
FailedRSSAttempts exceeds dot11RSSRetryLimit, the STA shall select a backoff count as a random integer
drawn from a uniform distribution [0, dot11RSSBackoff), i.e., 0 to dot11RSSBackoff – 1. The responder
shall decrement the backoff count by one at the end of each A-BFT period in the following beacon intervals.
The responder may re-initiate RSS only during an A-BFT when the backoff count becomes zero. The STA
shall set FailedRSSAttempts to 0 upon successfully receiving an SSW-Feedback frame during the A-BFT.
In an A-BFT, the responder shall not initiate an SSW ack procedure (10.38.2.5) in response to the reception
of an SSW-Feedback frame from the initiator. The SSW ack procedure occurs within the DTI of a beacon
interval (10.38.6.2); it does not occur otherwise.
If the AP or PCP receives an SSW frame from the responder during the RSS with the Poll Required field
within the SSW frame equal to 1 and the TDDTI field within the AP’s or PCP’s DMG Capabilities element
is 1, the AP or PCP shall allocate time for the responder and the AP or PCP to communicate during the ATI
or within an SP of the DTI of at least one of the following aMinBTIPeriod beacon intervals beginning with
the beacon interval in which the SSW frame was received. This can be done through the Extended Schedule
element or the transmission of a Poll or Grant frame addressed to the responder, and the allocated time can
be used for at least one of association, authentication, and service period request.
1551
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
After transmitting an SSW-Feedback frame to the responder, the initiator shall send a BRP frame with the
Capability Request subfield within the BRP Request field set to 1 and addressed to the responder. The BRP
frame shall be sent in one of the following aMinBTIPeriod beacon intervals beginning with the beacon
interval in which the RSS phase with the responder was last completed. The BRP frame shall be transmitted
at MCS 0 using the sector identified by the Sector Select field received from the responder during the RSS.
In an ATI after the completion of the SSW feedback procedure, a responder should have its receive antenna
configured to a quasi-omni antenna pattern in the DMG antenna in which it received the best sector from the
initiator during the preceding ISS in order to receive an Announce, Grant, or BRP frame (with the Capability
Request subfield within the BRP Request field set to 1) from the initiator, while the initiator should
configure its transmit DMG antenna to the value of the Sector Select and the DMG Antenna Select fields
received from the responder during the preceding RSS. If the responder does not receive an Announce or
Grant frame from the initiator with the RA address equal to the responder’s MAC address until
aMinBTIPeriod beacon intervals after the beacon interval in which the SLS phase with the initiator was last
attempted, it may retry BF with the initiator in the A-BFT.
NOTE—Due to the multiple access nature of RSS in the A-BFT, the AP or PCP might not receive the best sector for
communication with the STA. The AP or PCP might schedule an SP to perform BF again with the STA to find the best
sector for communication with the STA.
10.38.5.3 STA Beamforming after A-BFT
The initiator shall either initiate BRP execution with the responder in the next CBAP or shall schedule time
in the DTI for BRP execution with the responder if the initiator needs BRP training or the responder
indicated a need for training (by setting any of the L-RX, TX-TRN-REQ, MID-REQ, or BC-REQ fields to a
nonzero value) as a response to an SSW-Feedback or BRP frame with Capability Request subfield within
the BRP Request field set to 1.
The responder may initiate BRP in a CBAP by sending a BRP frame with any of the training request fields
(i.e., L-RX, TX-TRN-REQ, MID-REQ, BC-REQ) set to 1.
To schedule time in the DTI for BRP execution with a responder, the initiator may use any of the following
methods:
1) Allocate an SP with the Beamforming Training subfield set to 1 in the Allocation field within
an Extended Schedule element. The source of the SP shall be the initiator and the destination of
the SP shall be the responder. The Extended Schedule element is carried in DMG Beacon or
Announce frames, as defined in 10.36.4. The source AID of the allocation shall be set to the
AID of the initiator. The destination AID of the allocation shall be set to the AID of the
responder or the broadcast AID.
2) Allocate a CBAP in which the initiator or responder may start beamforming training with each
other. The CBAP allocation is announced in an Extended Schedule element carried in a DMG
Beacon or an Announce frame, as defined in 10.36.4. The source AID of the CBAP shall be
set to the AID of the initiator or to the broadcast AID. The destination AID of the CBAP may
be set to the AID of the responder or to the broadcast AID.
3) Use a Grant frame to allocate either a CBAP or an SP in which the initiator or responder may
start beamforming with each other. In the Grant frame, the initiator shall set the RA field to the
MAC address of the responder and the TA field to the MAC address of the initiator. In the
Dynamic Allocation Info field of the Grant frame, the AllocationType field shall be set to
indicate CBAP or SP, the source AID field shall be set to the AID of the initiator, the
destination AID field shall be set to the AID of the responder or the broadcast AID, and the
Allocation Duration field shall be set to the expected duration of the BRP phase.
4) Allocate a DTI as CBAP only as defined in 10.36.4.
1552
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
At least one of the above allocations shall occur during one of the following aMinBTIPeriod beacon
intervals beginning with the beacon interval in which the SLS phase with the responder was last completed.
The duration of the allocation, as specified in the Allocation Block Duration (see 9.4.2.132), shall cover at
least the expected duration of the BRP phase.
If the initiator receives at least one SSW frame from a responder within an A-BFT but did not transmit an
SSW-Feedback frame to the responder within that A-BFT, the initiator may schedule time in the DTI to
perform the ISS and RSS. To do that, the initiator may use one of the methods above. The Allocation Block
Duration field shall be set to cover at least the ISS and RSS.
The initiator may transmit an Announce frame to the responder during the ATI to announce a CBAP
allocation in the beacon interval. If the responder receives the Announce frame with a CBAP allocation, the
responder may contend for a TXOP during a CBAP to perform the BRP execution with the initiator or
continue the RSS with the initiator.
Any Announce or Grant frame the initiator sends to a responder after initiating beamforming with the
responder in the A-BFT but before beamforming with the responder is completed shall be transmitted at
MCS 0 using the sector identified by the Sector Select field received from the responder in the RSS.
The execution of the beamforming procedure in an allocation in the DTI is described in 10.38.6.
10.38.5.4 Beamforming in A-BFT with multiple DMG antennas
An AP or PCP shall receive through a quasi-omni antenna pattern from a single DMG antenna throughout an
A-BFT unless RXSS is used in the A-BFT, in which case it switches through antenna patterns as described
in 10.38.5.2.
An AP or PCP shall have an A-BFT every k beacon intervals, where k is the value indicated by the N BIs A-
BFT subfield in the Beacon Interval Control field. In an A-BFT, the AP or PCP shall receive in a quasi-omni
antenna pattern using the DMG antenna indicated by the value of the DMG Antenna ID subfield within the
SSW field transmitted in the DMG Beacon. An AP or PCP with multiple DMG antennas has a regular
schedule of receiving through each DMG antenna corresponding to the DMG antenna in which a DMG
Beacon frame is transmitted through. The AP or PCP shall switch RX DMG antenna every l allocations,
where l is the value of the N A-BFT in Ant subfield within the Beacon Interval Control field.
In each DMG Beacon, the A-BFT Count subfield in the Beacon Interval Control field indicates the number
of A-BFTs that have passed since the AP or PCP last switched RX DMG antennas.
10.38.6 Beamforming in DTI
10.38.6.1 General
An initiator and responder may perform BF training within an SP or CBAP.
An initiator shall determine the capabilities of the responder prior to initiating BF training with the
responder if the responder is associated. A STA may obtain the capabilities of other STAs through the
Information Request and Information Response frames (11.30.1) or following a STA’s association with the
PBSS/infrastructure BSS. The initiator should use its own capabilities and the capabilities of the responder
to compute the required allocation size and TXOP duration to perform BF training and BF training related
timeouts.
An initiator may request the AP or PCP to schedule an SP to perform BF training with a responder by setting
the Beamforming Training subfield in the BF Control field of the DMG TSPEC element or SPR frame to 1.
1553
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The AP or PCP shall set the Beamforming Training subfield to 1 in the Allocation field of the Extended
Schedule element if the Beamforming Training subfield in the BF Control field of the DMG TSPEC element
or SPR frame that generated this Allocation field is equal to 1. The AP or PCP should set the Beamforming
Training subfield in an Allocation field of the Extended Schedule element to 0 if this subfield was equal to 1
when the allocation was last transmitted by the AP or PCP in an Extended Schedule element and if, since
that last transmission, the AP or PCP did not receive a DMG TSPEC element for this allocation with the
Beamforming Training subfield equal to 1.
10.38.6.2 SLS phase execution
For BF training in the DTI, both the initiator and responder shall use the SSW frame for the ISS and RSS.
The initiator shall begin an ISS (10.38.2.2) at the start of an SP allocation or TXOP with an initiator TXSS,
except in the case of an SP allocation that has the IsInitiatorTXSS field for this SP is equal to 0 in which case
the initiator shall begin an ISS with an initiator RXSS.
If the responder has more than one DMG antenna, the initiator shall repeat its ISS k+1 times, where k is the
value indicated by the responder in the last negotiated Number of RX DMG Antennas field transmitted by
the responder. Repetitions of the ISS are separated by an interval equal to LBIFS. The value of the CDOWN
field within SSW frames transmitted in the ISS indicates the number of sectors until the end of transmissions
from all of the initiator’s DMG antennas to all of the responder’s DMG antennas. The ISS phase shall not be
fragmented across multiple allocations.
The RSS comprises a responder TXSS unless the allocation is an SP and the IsResponderTXSS field for this
SP is equal to 0 or the allocation is a CBAP and the RXSS Length field within the SSW frame received by
the responder during the ISS is equal to a nonzero value. The responder shall begin an RSS (10.38.2.3)
MBIFS following the completion of an ISS, provided the responder received an SSW frame from the
initiator during the ISS and there is sufficient time in the allocation for the responder to transmit all SSW
frames necessary to complete the RSS phase. The responder shall not begin or continue the RSS phase in a
different allocation from the allocation that contained the ISS phase.
NOTE—The responder can begin an RSS if there is not sufficient time in the allocation to complete the RSS phase. The
RSS phase does not continue in a subsequent allocation in this case.
The initiator shall begin an SSW feedback procedure (10.38.2.4) MBIFS following the completion of an
RSS, provided the initiator received an SSW frame from the responder during the RSS and there is sufficient
time left in the allocation to complete the SSW feedback procedure followed by an SSW ack procedure
(10.38.2.5) from the responder in an MBIFS. If there is not sufficient time left in the allocation for the
completion of the SSW feedback and SSW ack procedures, the initiator may begin the SSW feedback
procedure in the following allocation between the initiator and the responder.
The responder shall begin an SSW ack procedure (10.38.2.5) to the initiator an MBIFS following the
reception of an SSW-Feedback frame from the initiator.
The initiator may restart the SSW feedback procedure up to dot11BFRetryLimit times if it does not receive
an SSW-Ack frame from the responder an MBIFS following the completion of the SSW feedback
procedure. The initiator shall restart the SSW feedback procedure PIFS following the expected end of the
SSW-Ack frame by the responder, provided there is sufficient time left in the allocation for the initiator to
begin the SSW feedback procedure followed by an SSW ack procedure from the responder in an MBIFS. If
there is not sufficient time left in the allocation for the completion of the SSW feedback and SSW ack
procedures, the initiator may restart the SSW feedback procedure in the following allocation between the
initiator and the responder.
Once started, the initiator and responder shall complete the SLS phase before any additional frame exchange
takes place between these STAs.
1554
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.38.6.3 Multiple sector ID capture (MIDC) subphase
10.38.6.3.1 General
In practice, the quasi-omni RX antenna patterns used in the SLS phase might exhibit imperfections that lead
to an incorrect choice of the best TX sector and consequently a sub-optimal starting point for beam
refinement in the BRP phase. To remedy this, a multiple sector ID capture (MIDC) subphase may be used.
Instead of selecting the starting point for the beam refinement transactions (i.e., the best TX sector) based on
information obtained with quasi-omni RX antenna patterns from the SLS phase, the MIDC subphase enables
the use of additional information based on the trial of multiple transmit and receive sectors.
The MIDC subphase can be implemented in two ways. The first option is to conduct a trial between a small
set of transmit and receive AWV settings with wide (e.g., quasi-omni) antenna patterns. The second option
is to carry out a trial between a small set of TX sectors and a set of RX AWV settings, chosen by the receiver
in an implementation dependent manner, that maximizes the probability of determining the RX AWVs that
best match the chosen set of TX sectors. Note that this may involve using a set of RX AWVs that correspond
to the “full set” of RX sectors (from the SLS phase). The set of TX sectors are chosen from a TX sector
sweep with a quasi-omni RX antenna pattern. With either option, the end result from the MIDC subphase
can be the better starting point transmit and receive sector pair for further beam refinement.
For the first option above, the MIDC subphase consists of a MID subphase and a BC subphase. This is
further elaborated upon in 10.38.6.3.2, and a sample time allocation is illustrated in Figure 10-69. For the
second option, the MIDC subphase consists only of a MID subphase. This is further elaborated upon in
10.38.6.3.3, and a sample time allocation is illustrated in Figure 10-70.
BTI A‐BFT ATI DTI
SLS BRP
SSW‐ 1st BRP iteration
BRP
FBCK 2nd BRP Nth BRP
I‐TXSS R‐TXSS Setup
subphase
R‐
MID
I‐MID
BRP‐ BRP‐
FBCK FBCK
R‐BC I‐BC
BRP‐ BRP‐
FBCK FBCK
iteration ... iteration
MIDC subphase
Figure 10-69—Example of time allocation for the MIDC subphase with MID and BC
subphases
BTI A‐BFT ATI DTI
SLS BRP
SSW‐ st
1 BRP iteration
BRP
FBCK 2nd BRP Nth BRP
I‐TXSS R‐TXSS Setup R‐ R‐ R‐ I‐ I‐ I‐ I‐ BRP‐ BRP‐
subphase MID MID MID MID MID MID MID FBCK FBCK
iteration ... iteration
MIDC subphase
Figure 10-70—Example of time allocation for the MIDC subphase with the MID subphase
only
Prior to the beginning of the MIDC subphase, a BRP setup subphase is carried out as specified in 10.38.3.2.
This subphase enables the two DMG STAs involved to negotiate whether and how the MIDC subphase is
carried out.
1555
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In 10.38.6.3 the following terminology is used:
— Nbeam: the value of the Number of Beams subfield of the FBCK-TYPE field
— Nbeam(Link Type,Antenna Type): represents a combination of Nbeam, Link Type (I for Initiator, R
for Responder), and Antenna Type (TX for Transmitter, RX for Receiver)
— Number of Measurements: the value of the Number of Measurements subfield of the FBCK-TYPE
field.
Examples of how the MIDC subphase is set up, depending on whether beamforming is initiated in the BTI
and A-BFT or in the DTI, are illustrated in Figure 10-71 and Figure 10-72, respectively. Note that the MIDC
subphase is applicable only when both the initiator and the responder have the ability to switch among their
sectors.
Capability Request=1,
Nmeas, SNR Present=1,
Capability Request=1, Sector ID Order Present=1,
MID/BC‐REQ=1, MID/BC‐Grant=1,
TXSS‐FBCK‐REQ=1, Nbeam(R,RX)
L‐RX>0
SNR Requested=1
Capability
Request=0 Nbeam(R,TX),
MID/BC‐REQ=1 Sector ID Order Present=1
Initiator TXSS I‐MID I‐BC
Initiator
DMG Beacon
DMG Beacon
BRP frame(s)
SSW‐Feedback
BRP
BRP
BRP
BRP
BRP
BRP
BRP
... ...
SLS (BTI+A‐BFT) BRP setup (ATI+DTI) MID (DTI) BC (DTI)
BRP frame(s)
SSW
SSW
BRP
BRP
BRP
BRP
BRP
BRP
... ...
Responder
Responder TXSS R‐MID R‐BC
Nbeam(I,RX)
Capability Request=1, MID/BC‐Grant=1, Capability Request=0,
TXSS‐FBCK‐REQ=1, SNR Requested=1, Nmeas, SNR Present=1,
Sector ID Order Present=1 Nbeam(I,TX),
MID/BC‐REQ=1, L‐RX>0
Sector ID Order Present=1
Time separation between BRP frame exchanges: ≥ SIFS and ≤ BRPIFS
Figure 10-71—Example of using BRP setup subphase to set up subsequent MIDC
subphase in A-BFT and DTI
1556
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Capability
Request=1,
MID/BC-Grant=1,
TX-FBCK-REQ=1, Capability Request=1, Nbeam(R,RX)
SNR Requested=1 Nmeas, SNR Present=1,
Sector ID Order Present=1, Nbeam(R,TX),
MID/BC- Capability
Request=0 Sector ID Order
REQ=1,
Present=1
L-RX>0
Initiator TXSS I-MID I-BC
Initiator
SW-Feedback
BRP frame(s)
.. ..
SSW
SSW
BRP
BRP
BRP
BRP
BRP
BRP
BRP
. .
SLS (DTI) BRP setup (DTI) MID (DTI) BC (DTI)
SSW-Ack
BRP frame(s)
SSW
SSW
.. ..
BRP
BRP
BRP
BRP
BRP
BRP
. .
Responder
Responder TXSS R-MID R-BC
Nbeam(I,RX)
MID/BC-Grant=1, Capability Request=0
MID/BC-REQ=1, L-RX>0 Nbeam(I,TX),
Sector ID Order
Capability Request=1,
Present=1
Nmeas, SNR Present=1,
Sector ID Order Present=1, Time separation between BRP frame exchanges:
TXSS-FBCK-REQ=1, SNR ≥ SIFS and ≤ BRPIFS
Requested=1
Figure 10-72—Example of using BRP setup subphase to set up subsequent MIDC
subphase in DTI
10.38.6.3.2 MIDC subphase with MID and BC subphases
The MIDC subphase can be implemented such that small subsets of TX sector IDs and RX AWVs are first
chosen, followed by trials between these subsets to determine the optimal starting TX sector ID and RX
AWV pair. The set of TX sectors is chosen from an a priori TX sector sweep with a quasi-omni RX antenna
pattern (in the SLS phase). To enable the selection of the RX sectors, and the subsequent trial between the
transmit and receive sectors, the MIDC subphase consists of an MID subphase and a BC (or beam
combining) subphase. In the MID subphase, a wide TX beam (e.g., quasi-omni) is used while the receiver
sweeps through its choice of AWV settings to determine the set of RX AWVs with the highest link quality.
This is followed by the BC subphase, which involves testing the multiple RX AWVs together with multiple
TX AWVs.
This is conceptually illustrated in Figure 10-73. Note that the consecutive numbering of TX sector IDs (e.g.,
TX sector ID1, TX sector ID2, …) or RX AWVs is just used for representation purposes. It is used to
indicate the subset of TX sector IDs without placing any restrictions on how these sector IDs are selected
(i.e., consecutive numbering of TX sector IDs does not mean that the selected TX sector IDs should be those
that are consecutively numbered).
1557
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Best TX Sector IDs up to Nbeam(I, TX)
STA2 TX Sector ID 1
TX Sector ID 2
STA1
TX Sector IDNbeam(I, TX)
(a) Initiator TXSS in SLS
Best RX Sector IDs up to Nbe am(I, RX)
RX Sector/AWV 1
STA1
RX Sector/AWV 2
STA2
RX Sector /AWV Nbeam(I, RX)
(b) I-MID
Verification by 49(max) beam formed trials
TX Sector ID1 RX Sector/AWV 1
TX Sector ID2 RX Sector/AWV 2
STA1 STA2
TX Sector IDNbeam(I, TX) RX Sector /AWV Nbeam(I, RX)
(c) I- BC (Beam Combining)
Figure 10-73—Conceptual flow of sample MIDC subphase execution with MID and BC
subphases for initiator link
a) Setting up the MID and BC subphases: To request a MIDC subphase with the MID and the BC
subphases, the initiator shall transmit an SSW-Feedback or BRP frame with the MID-REQ and the
BC-REQ fields set to 1 in the BRP Request field. The responder may grant this request by setting the
MID-Grant and the BC-Grant fields to 1 in the BRP Request field within the next SSW-Ack or BRP
frame transmitted to the initiator. The R-MID and R-BC subphases are performed if the request is
granted and are not performed otherwise.
The responder shall transmit an SSW-Ack or BRP frame to request a MIDC subphase, with the I-
MID and I-BC subphases. It shall do so by setting the MID-REQ and the BC-REQ fields to 1 in the
BRP Request field within the transmitted frame. The initiator may grant this request by setting the
MID-Grant and the BC-Grant fields to 1 in the BRP Request field within the next BRP frame
transmitted to the responder. The I-MID and I-BC subphases are performed if the request is granted
and are not performed otherwise.
If all of R-MID, R-BC, I-MID, and I-BC subphases are performed, the MID subphases are
performed before the BC subphases. Within the MID subphase, R-MID is performed before I-MID.
Within the BC subphase, R-BC is performed before I-BC (see Figure 10-69 and Figure 10-70).
In addition to the MID-REQ, BC-REQ, MID-Grant and BC-Grant fields, the responder (and/or
initiator) needs to obtain the number of RX AWV settings to be appended to BRP-RX packets in the
R/I-MID subphase. To do this, the initiator (and/or responder) should use the L-RX field in the BRP
Request field to convey this information. Similarly, the responder (and/or initiator) needs to obtain
the IDs and SNRs of the TX sectors received during the SLS phase for use in the R-BC and I-BC
subphases. To do this, the responder (and/or initiator) shall send a BRP packet with the TXSS-
FBCK-REQ subfield and SNR Requested subfield set to 1 in the FBCK-REQ field of the DMG
1558
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beam Refinement element. In response, the initiator (and/or responder) should send a BRP frame
with both the SNR Present subfield and the Sector ID Order Present subfield set to 1. The Number of
Measurements subfield in the FBCK-TYPE field is set to indicate the number of sectors received
during the last SLS for which an SNR measurement is included. In the Channel Measurement field,
the initiator (or responder) should set the SNR subfield to the SNRs corresponding to the TX sectors
trialled during the SLS phase. In the Sector ID subfield, it should list the sector IDs of the received
sectors. The responder (and/or initiator) should then use the SNR information, and any additional
information such as angular separation between sectors, to determine the TX sectors for use in the
BC subphase. The responder (or initiator) shall inform the initiator (or responder) of the number of
TX sectors using the Number of Beams subfield in the FBCK-TYPE field during the BRP setup
subphase. After the R/I-MID subphases, the same field is used to exchange information about the
number of RX AWVs to be trialled during the BC subphase.
b) Executing the MID subphase: If R-MID was requested and granted during the SLS and/or
subsequent BRP setup subphase, then after the BRP setup subphase, the R-MID shall be initiated by
the responder sending a BRP frame with TRN-R fields (as requested in the BRP setup subphase).
This packet may be transmitted using a wide pattern, approaching an omni transmit pattern, or using
a sector antenna pattern. The receiver may use the TRN-R fields for receive training.
If the MID Extension field in the packet is equal to 1, the responder shall transmit another BRP-RX
packet, which may be transmitted using another transmit pattern. It may continue transmitting BRP-
RX packets as long as the MID Extension field in all of them is equal to 1. The last BRP-RX packet
transmitted by the responder shall have the MID Extension field set to 0.
If the initiator does not receive a BRP-RX packet within BRPIFS after transmitting the last packet of
the BRP setup subphase, it may retransmit the last packet of the BRP setup subphase.
After the initiator receives a BRP-RX packet with the MID Extension field set to 0, it shall respond
with a BRP frame with the appropriate feedback. This BRP frame should be sent using the best TX
sector as determined in the SLS phase, while the responder should use a quasi-omni pattern to
receive this frame. The feedback included in this BRP frame is the number of RX AWVs to be tested
in the subsequent R-BC subphase using the Number of Beams subfield in the FBCK-TYPE field.
If I-MID was granted in addition to R-MID, the initiator shall send a BRP frame with TRN-R fields
(as requested in the BRP setup subphase). The initiator shall continue to send BRP packets if the
MID Extension was set to 1 as in the R-MID.
After the responder receives a BRP-RX packet with the MID Extension set to 0, it shall respond by
sending a BRP frame with feedback. This BRP frame should be sent using the best TX sector as
determined in the SLS phase, while the initiator should use a quasi-omni pattern to receive this
frame. The feedback included in this BRP frame is the number of RX AWVs to be tested in the
subsequent I-BC subphase using the Number of Beams subfield in the FBCK-TYPE field. The
initiator shall respond with a BRP frame with the TX-TRN-OK field set to 1 as an acknowledgment.
The R-BC subphase then follows.
If I-MID does not follow R-MID, the BC subphase follows immediately.
c) Executing the BC subphase: The execution of an I-BC subphase is used as an example. In an I-BC
subphase, the initiator shall transmit Nbeam(I,TX) BRP-RX frames using the number of TX sectors
specified during the BRP setup subphase. Each BRP-RX frame shall be appended with
Nbeam(I,RX) TRN-R subfields, and shall include the Sector ID subfield of the TX sector used.
While receiving these TRN-R subfields, the responder shall switch through the RX AWVs selected
during the prior I-MID subphase. To conclude the I-BC subphase, the responder shall feed back to
the initiator a BRP frame with (a) the BS-FBCK field set to the TX sector ID of the BRP-RX packet
received with the highest link quality, and (b) the ordered list of transmit sectors (based on received
link quality during the I-BC) using the Sector ID Order subfield in the Channel Measurement
Feedback element. This BRP frame should be sent using the best TX sector as determined in the
SLS phase, while the initiator should use a quasi-omni pattern to receive this frame. The complete
procedure is illustrated in Figure 10-74, while Figure 10-75 depicts the beam combining subphase.
1559
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
BRP- RX BRP frame BRP- RX BRP with
packet with feedback packets feedback
Responder
R- MID R-BC
MID Extension=0
MID Extension=0
I- MID I-BC
Initiator
BRP- RX BRP frame BRP-RX BRP with
packet with feedback packets feedback
(a) Normal process: one MID and BC for each initiator and responder link
(the initiator and responder use a quasi‐omni TX pattern)
BRP-RX BRP-RX BRP frame BRP- RX BRP frame
packet packet with feedback packets with feedback
Responder
R- MID R- MID R-BC
MID Extension=1 MID Extension=0
MID Extension=1 MID Extension= 0
I- MID I- MID I-BC
Initiator
BRP- RX BRP- RX BRP frame BRP- RX BRP frame
packet packet with feedback packets with feedback
(b) The MID for both the initiator and responder are repeated twice:
each TX beam is wider than a TX sector, but narrower than a quasi‐omni pattern and covers a different direction
BRP-RX BRP- RX BRP frame BRP- RX BRP frame
packet packet with feedback packets with feedback
Responder
R- MID R- MID R-BC
MID Extension =1 MID Extension=0
I- MID I-BC
Initiator
MID Extension=0 BRP frame BRP- RX BRP frame
with feedback packets with feedback
(c) The MID for the initiator is repeated twice:
each TX beam is wider than a TX sector, but narrower than a quasi‐omni pattern and covers a different direction
Figure 10-74—Examples of using MID Extension field during execution of MID subphase
1560
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
≥ SIFS ≥ SIFS
SBIFS ≤ BRPIFS SBIFS ≤ BRPIFS BRP with
feedback
Responder
BRP-RX BRP-RX BRP-RX
(R, Tx)
1 2 Nbeam
BRP-RX BRP-RX BRP-RX BRP
Initiator
(I , Tx)
1 2 Nbeam
(R,Rx)
N be am R x be ams are tested whi le
receiving each B RP -RX packe t. ≥ SIFS
≤ BRPIFS
(I,Rx)
N be am R x be ams are tested whi le
receiving each B RP- RX packe t.
Figure 10-75—Beam combining
10.38.6.3.3 MIDC subphase with MID subphase only
The MIDC subphase may also be implemented such that multiple TX sectors, obtained from the TXSS in
the SLS phase, are used instead of wide TX beams. Here, the receiver employs multiple RX AWVs for each
TX sector chosen by the transmitter. Based on this joint trial of transmit and receive AWVs, the optimal
starting transmit and receive AWV pair is chosen for further refinement in the BRP phase. In this case, the
MIDC subphase consists only of the MID subphase. This is conceptually illustrated in Figure 10-76.
Best TX Sector IDs up to N beam(I, TX)
STA2 TX Sector ID 1
TX Sector ID 2
STA1
(I, TX)
TX Sector ID Nbeam
(a) I - TXSS in SLS
Verification by Nbeam(I, TX) x N RX beamformed trials
st
TX Sector ID 1 1 RX sector/AWV
nd
STA1 STA2 TX Sector ID 2 2 RX sector/AWV
MID extension
Total number of
RX sectors/AVWs; N RX ( I, TX)
TX Sector ID Nbeam (NRX) -th RX sector/AWV
(b) I-MID
Figure 10-76—Conceptual flow of sample MIDC subphase execution with only MID
subphase for initiator link
1561
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) Setting up the MID subphase: The procedure of setting up the MID-subphase is described in
10.38.3.2.
In the example of Figure 10-77, the initiator transmits an SSW-Feedback frame with the MID-REQ
subfield set to 1 and the BC-REQ subfield set to 0 in the BRP Request field, thus requesting an
MIDC with only the R-MID subphase. The responder grants the MID-REQ by setting the MID-
Grant subfield to 1 in the SSW-Ack frame. The initiator then sends a frame with the SNR Present
and Sector ID Order Present subfields both set to 1, the Number of Measurement subfield in the
FBCK-TYPE field indicating the number of SNR measurements from the last SLS phase, and the
SNR and Sector ID subfields with the SNRs measured during the SLS phase and the list of received
sectors, respectively. The L-RX subfield is set according to the number of training fields the initiator
needs in each packet as part of the R-MID. The responder then starts the R-MID process by
transmitting BRP-RX packets.
SLS BRP setup BRP MID
SNR Present =1
Sector ID Order
Present = 1
Nmeas = 7 BS-FBCK = best from all
L-RX > 0 SNR Present =1(optional)
BC-REQ = 0 Sector ID Order Present = 1(optional)
Initiator =1 Nmeas = 3 (optional)
MID-REQ = 1
BRP BRP
Initiator SSW-
frame frame
Feedback (sector list) (FBCK)
≥ SIFS ≥ SIFS
MBIFS ≤ BRPIFS SIFS ≤ BRPIFS
MID BRP MID BRP MID BRP
Responder SSW-
Ack NTx (1) NTx (2) ... NTx (Nbeam)
MID-REQ = 0
MID-Grant=1 Tx Sector ID = NTx (1) Tx Sector ID = NTx (2) Tx Sector ID = NTx (Nbeam)
MID Extension = 1 MID Extension = 1 MID Extension = 0
Figure 10-77—Example of using BRP setup subphase to set up subsequent R-MID
subphase
b) Executing the MID subphase: The execution of the MID subphase for the responder link (i.e., R-
MID) is used as an example. Execution of the MID subphase for the initiator link (i.e., I-MID) is
similar, except for a change in the direction of the corresponding frames. In an R-MID subphase, the
responder shall transmit one BRP-RX packet each from one of the chosen TX sectors. In each
packet, it shall indicate the sector ID of the TX sector used using the Sector ID field in the BRP
Request field. Each transmitted BRP-RX packet should be appended with multiple TRN-R subfields
such that the initiator can train its receiver antenna during the R-MID subphase. The initiator shall
train its receiver antenna by cycling through its choice of RX AWVs while receiving the TRN-R
subfields. The initiator shall indicate to the responder the number of TRN-R subfields to be
appended using the L-RX field in the BRP Request field during the SLS phase or the BRP setup
subphase. For all BRP-RX packets except the last one, the responder shall also set the MID
Extension field to 1.
In the R-MID subphase, the initiator shall send a BRP frame with feedback. This BRP frame should
be sent using the best TX sector as determined in the SLS phase, while the responder should use a
quasi-omni pattern to receive this frame. The feedback included in this BRP frame should be (a) the
BS-FBCK field set to the TX sector ID of the BRP-RX packet received with the highest link quality,
and (b) the ordered list of transmit sectors (based on received link quality during the R-MID) using
the Sector ID Order subfield.
1562
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.38.6.3.4 MIDC subphase with BC subphase only
An MIDC subphase with only the BC subphase is carried out when the MID and BC subphases have been
carried out earlier. In this case, the initiator and responder keep track of the transmit and receive sectors, for
use in the BC subphase, from earlier iterations. Since the best transmit and receive sectors (in terms of link
quality) are kept track of, this information can be used to deal with link blockage events. STAs can utilize
only the chosen set of TX sectors in the SLS phase to reduce beamforming training time, and jump to the BC
subphase directly without executing the MID subphase. In this manner, fast recovery is possible when some
of the backup links are available after partial blockage around the STA.
To carry out the MIDC subphase with the BC subphase only, the MID-REQ field is set to 0 and the BC-REQ
field is set to 1 in SSW-Feedback or SSW-Ack or BRP frames, and the BC-Grant field is set to 1 in the
following SSW-Ack or BRP frame. The BC subphase can include an I-BC and/or an R-BC (10.38.6.3.2).
10.38.6.4 BRP phase execution
10.38.6.4.1 General
Beam refinement is a request/response based process. A STA requests receive beam refinement training by
sending a BRP frame with a nonzero value in the L-RX field. The STA that receives the BRP frame shall
respond with a BRP packet (20.10.2.2) including as many TRN-R fields as indicated in the value of the L-
RX field within the received BRP frame and with the RX-train-response field in the DMG Beam Refinement
element set to 1.
A STA requests transmit beam refinement training by sending a BRP frame as follows. In the BRP Request
field, the TX-TRN-REQ field is set to 1, and the FBCK-REQ field indicates the feedback type. In the PHY
header, the Packet Type and the Training Length fields are set to indicate the number of AGC and TRN-T
fields appended to the packet.
The responding STA shall reply to the transmit beam refinement training with a BRP frame containing a
DMG Beam Refinement element with the TX-TRN-OK field and TX-train-response field both set to 1 and
the BS-FBCK field set to indicate the TRN-T field on which the responding STA received the best signal
(the determination of best signal is implementation dependent). The FBCK-TYPE field shall be set to
according to the format of the Channel Measurement Feedback element, if one is included in the frame. If
the SNR Present and Channel Measurement Present subfields of this FBCK-TYPE field are set to 0, the
Channel Measurement Feedback element shall not be included. The number of taps indicated in the FBCK-
TYPE field shall be less than or equal to the number of taps indicated in the FBCK-REQ field of the request
frame.
If a STA requests transmit beam refinement training, but does not send TRN-T fields, the responding STA
shall reply with a BRP frame containing a DMG Beam Refinement element with the TX-TRN-OK field set
to 1. In this case (i.e., when the TX-train-response field is equal to 0), the responding STA shall set L-RX
field to 0. The requesting STA shall then transmit a BRP packet with TRN-T fields. The responding STA
shall then respond with a BRP frame with the TX-train-response field set to 1 and the BS-FBCK and
Channel Measurement Feedback element as above.
1563
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beam refinement can be performed following SLS (10.38.6.4.3). If the responder receives an SSW-
Feedback frame from the AP or PCP in an A-BFT, the AP or PCP allocates an SP for the beam refinement if
required (see 10.38.5.3). A STA may transmit a BRP packet to another STA whenever the STA transmits a
frame to that STA, provided that the transmitting STA knows that the recipient STA’s receive antennas are
directed to it or are in a quasi-omni antenna pattern.
A STA shall set the Initiator field to 1 within a DMG Beam Refinement element if the previous received
frame was not a BRP frame, or the last packet the STA transmitted was a BRP frame with the Initiator field
set to 1.
A STA that has transmitted a BRP frame with the Initiator field set to 1 and has not received a response
BRPIFS after the transmission may retransmit the frame.
A STA may request a TXSS sector list feedback by sending a BRP frame with the TXSS-FBCK-REQ field
set to 1, the SNR Requested subfield within the FBCK-REQ field set to 1 and the remaining subfields within
the FBCK-REQ field set to 0. The responding STA shall respond with a BRP frame with the SNR Present
subfield within the FBCK-TYPE field set to 1 and Sector ID Order Present subfield set to 1, with a list of
sector IDs indicating the sector IDs of the received SSW frames or DMG Beacon frames, and with the SNR
values with which those frames were received in the last TXSS. The Number of Measurements subfield in
the FBCK-TYPE field is set to indicate the number of sectors received during the last SLS for which an SNR
measurement is included.
A STA shall not set the TXSS-FBCK-REQ and the TX-TRN-REQ fields to 1 in the same BRP frame.
Two or more BRP frames shall not be aggregated in the same A-MPDU. A BRP frame may be aggregated
with another frame in the same A-MPDU only if the other frame is a single Ack, BA or QoS Null frame.
The Duration field within each BRP frame is set to the time remaining until the end of the current allocation,
when transmitted within an SP. Otherwise it is set to the time remaining until the end of the TXOP.
10.38.6.4.2 Beam refinement transaction
A beam refinement transaction is a set of BRP frames composed of request and responses.
A beam refinement transaction starts with the beamforming initiator STA sending a BRP frame with the
Initiator field set to 1.
A beam refinement responder is a STA that receives a BRP frame (which is directed to it) with the Initiator
field set to 1.
A beam refinement transaction participant shall respond to a BRP frame with a BRP frame.
If the beam refinement transaction initiator received a BRP frame from the responder with no training
requests, the initiator may terminate the transaction by not transmitting any further BRP packets.
1564
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 10-78, Figure 10-79, and Figure 10-80 show examples of beam refinement transactions.
Receive beam
refinement training Transmit Training Request –
request, L-RX 0 Transmit Training Request – TX-TRN-REQ=1,
TX-TRN-REQ=1 TRN-T field present
Initiator Initiator
Responder Responder
Receive beam refinement response,
RX-Train-response=1, TRN-R field Transmit Training response Transmit Training response
present TX-TRN-OK=1 TX-Train-response=1
Figure 10-78—Example beam Figure 10-79—Example beam
refinement transaction refinement transaction
(receive training) (transmit training)
Receive Response,
RX-Train-response=1,
Receive Beam TRN-R field present, TX training, TRN-T field present,
refinement training TX training response, TX-TRN-OK=1, Transmit training response+FBCK,
Req – L-RX 0 Transmit training request, TX-TRN-REQ=1 Receive training request
Initiator
Responder
RX training, RX-train-response=1,
Receive Response, RX-Train-response=1, TX training, TRN-T field present, TRN-R field present,
TRN-R field present, Transmit training request, TX-TRN-OK=1 Transmit training response+FBCK
Transmit training request, TX-TRN-REQ=1,
Receive request, L-RX>0
Figure 10-80—Example beam refinement transaction
(combination of receive and transmit training)
10.38.6.4.3 Beam refinement transaction after SLS
If either L-RX or TX-TRN-REQ is nonzero within the BRP Request field in the SSW-Ack frame of the most
recent SLS phase execution, no MID or BC was granted during the BRP setup subphase, and no beam
refinement transaction has been done since the most recent SLS phase execution, then the initiator shall
initiate the beam refinement transaction with the responder by sending a BRP frame to the responder. If the
value of the L-RX field is greater than 0 in the SSW-Ack frame, the first BRP frame the initiator transmits to
the responder is a BRP-RX frame. If the value of the L-RX field is 0 and the value of the TX-TRN-REQ
1565
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
field is 1, the first BRP frame the initiator transmits to the responder shall have either the TX-TRN-OK field
set to 1 or the L-RX field greater than 0.
10.38.6.4.4 Antenna configuration setting during a beam refinement transaction
A STA that has requested beam refinement receive training shall, except when receiving TRN-R fields, set
its receive antenna configuration to the best known receive antenna configuration based on previous beam
refinement receive training or RXSS. If the STA has not received a BRP frame since the last SLS and the
SLS did not include an RXSS, the STA should set its receive antenna configuration to a quasi-omni antenna
pattern in the DMG antenna through which the STA received the best sector during the SLS.
A STA that has received a beam refinement transmit training request shall send the response frame and then
set its antenna configuration to the best known receive antenna configuration based on previous beam
refinement receive training or RXSS, except if both the initiator STA and responder STA support the
Other_AID subfield as indicated through the Supports Other_AID field set to 1 within the STA’s DMG
Capabilities element and the value of the Other_AID subfield within the BRP Request field is different from
0, in which case the STA sets its antenna configuration to the best known receive antenna configuration for
receiving from the STA with AID equal to the value of the Other_AID subfield within the BRP Request
field. If the STA has not received a BRP frame since the last SLS and the SLS did not include an RXSS, the
STA should set its antennas to a quasi-omni antenna pattern.
In a BRP-RX packet, all TRN-R fields shall be transmitted using the same TX AWV configuration as the
preamble and data fields of the packet, except if both the transmitting and receiving STAs support the
Other_AID subfield as indicated through the Supports Other_AID field set to 1 within the STA’s DMG
Capabilities element and the value of the Other_AID subfield within the BRP Request field is different from
0, in which case the TRN-R fields shall be transmitted using the best known TX AWV configuration for
transmitting to the STA with AID equal to the value of the Other_AID subfield within the BRP Request
field.
A STA that has the DMG Antenna Pattern Reciprocity subfield within the DMG STA Capability
Information field of the DMG Capabilities element equal to 1 and that has received a BRP-RX packet from
a peer STA that also has the DMG Antenna Pattern Reciprocity subfield within the DMG STA Capability
Information field of the peer STA’s DMG Capabilities element equal to 1 shall use the same AWV that was
configured with the BRP-RX packet in subsequent transmissions and receptions with the peer STA during
the DTI. This allows STAs that use reciprocity to shorten the beamforming training time.
10.38.7 Beam tracking
A STA (beam tracking initiator) may request a peer STA (beam tracking responder) to perform receive
beam tracking by setting, in a transmitted packet, the TXVECTOR parameter
BEAM_TRACKING_REQUEST to Beam Tracking Requested, TRN-LEN to the number of requested TRN
fields as described in 20.10.2.2.3 and packet type to TRN-R-PACKET. Otherwise, the
BEAM_TRACKING_REQUEST parameter shall be set to Beam Tracking Not Requested.
A beam tracking responder that receives a packet with the Beam Tracking Request field in the PHY header
equal to 1 (corresponding to the BEAM_TRACKING_REQUEST parameter in the RXVECTOR set to
Beam Track Requested) and the Packet Type field in the PHY header equal to 0 (corresponding to
PACKET-TYPE field in the RXVECTOR set to TRN-R-PACKET) shall follow the rules described in
20.10.2.2 and shall include a beam refinement AGC field and TRN-R subfields appended to the following
packet transmitted to the initiator in the same allocation, with an MCS index greater than 0. The value of
TRN-LEN in the following packet from the responder to the initiator shall be equal to the value of the TRN-
LEN parameter in the RXVECTOR of the packet from the initiator. A responder may ignore a request for
beam tracking within an allocation if no packets with an MCS index greater than 0 are transmitted from the
responder to the initiator within the allocation.
1566
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A beam tracking initiator requesting transmit beam tracking shall set the BEAM_TRACKING_REQUEST
parameter in the TXVECTOR to Beam Tracking Requested, Packet Type to TRN-T-PACKET, TRN-LEN
to the number of TRN-Units as described in 20.10.2.2.3, and append an AGC field and TRN-T subfields to
the packet. The beam tracking responder may append the feedback to any packet from the responder to the
initiator. The initiator may allocate time for the feedback through a reverse direction grant, provided the
reverse direction protocol is supported by both the initiator and responder. The feedback type shall be the
same as the feedback type in the last BRP frame that was transmitted from the initiator to the responder with
TX-TRN-REQ equal to 1. If the responder has never received a BRP frame from the initiator with TX-TRN-
REQ equal to 1, the responder shall respond with all subfields of the FBCK-TYPE field equal to 0 and set
the BS-FBCK field to the index of the TRN-T subfield that was received with the best quality.
A beam tracking initiator may also request a beam tracking responder to perform receive beam tracking by
setting, in the PHY header of a transmitted packet, the Beam Tracking Request field to 0, the Training
Length field to a nonzero value, the Packet Type field to 0, and append an AGC field and TRN-R subfields
to the transmitted packet.
A beam tracking responder that receives a packet with the Beam Tracking Request field in the PHY header
equal to 0, the Training Length field in the PHY header equal to a nonzero value and the Packet Type field in
the PHY header equal to 0 shall follow the rules described in 20.10.2.2 and may use the beam refinement
AGC field and TRN-R subfields appended to the received packet to perform receive beam training.
BRP frames transmitted during beam tracking may be aggregated within A-MPDUs. Figure 10-81 illustrates
a beam tracking frame exchange sequence when the beam tracking initiator requests TRN-R fields, while
Figure 10-82 illustrates a beam tracking frame exchange sequence when the beam tracking initiator requests
TRN-T fields.
TRN-R fields
Beam appended
Tracking
Responder
Data Data Data
Ack Ack Ack
Beam
Tracking
Initiator
Beam Tracking Requested
Packet Type = TRN-R
TRN-LEN>0
Figure 10-81—Example of beam tracking procedure with initiator requesting TRN-R
A beam tracking initiator may transmit to the beam tracking responder a PPDU requesting transmit beam
tracking if at least one of the following conditions is met:
— The time duration since the last PPDU it transmitted to the beam tracking responder that requested
transmit beam tracking is greater than dot11BeamTrackingTimeLimit plus BRPIFS.
— A BRP frame with the channel measurement feedback from the beam tracking responder has been
received.
1567
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beam Tracking Requested
Packet Type = TRN-T TRN-T fields
Beam TRN-LEN>0 appended
Tracking
Initiator
Data Data Data
BRP
Ack Ack Ack
Beam frame
Tracking
Responder
BRP frame with
feedback
Figure 10-82—Example of beam tracking procedure with initiator requesting TRN-T
If the beam tracking initiator does not receive the expected feedback from the beam tracking responder
within a time period that is less than dot11BeamTrackingTimeLimit of the last request, the beam tracking
request has failed. If the initiator receives the expected feedback from the responder within time that is
greater than or equal to dot11BeamTrackingTimeLimit of the last request, the beam tracking initiator should
ignore it.
The time of arrival of the beam tracking responder’s feedback is indicated by the PHY-RXEND.indication
primitive of PPDU that contains the BRP MMPDU.
The time of transmit completion of the beam tracking initiator’s PPDU is indicated by the PHY-
TXEND.confirm primitive.
The beam tracking responder shall not transmit a BRP frame with feedback to the beam tracking initiator if
the time period between PHY-RXEND.indication primitive of the PPDU that contains the beam tracking
request and of PHY-TXEND.confirm primitive of the response BRP frame is longer than
dot11BeamTrackingTimeLimit.
10.38.8 State machines
Figure 10-83 depicts an example state machine of the SLS phase for the initiator, and Figure 10-84
illustrates an example state machine of the SLS phase for the responder. These state machines describe the
behavior of the initiator and responder during BF and are applicable for any period of the beacon interval
where BF is performed.
1568
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11BFRetryLimit not exceeded or
(start of BTI and STA is AP or PCP) ->
Perform Initiator TXSS
Sector SSW frame
Idle received
Selector
(Timeout (T1 or T2) and DTI) or
(end of A-BFT and STA is AP or PCP)
Sector selected and DTI ->
Perform SSW Feedback TXSS Phase
Complete
SSW
acknowledg-
ment
Timeout (MBIFS) and dot11BFRetryLimit not T1 = dot11BFTXSSTime
exceeded -> Perform SSW Feedback T2 = dot11MaxBFTime
Figure 10-83—SLS phase state machine (initiator)
BF frame
Idle Sector Selector
received
Timeout (T2)
SSW frame
received
SSW frame Sector selected ->
received Perform Responder TXSS
Timeout (T2) or
(end SSW slot (A-
BFT)
and no backoff)
SSW-Feedback frame SSW-Feedback frame
received -> End SSW slot (A-BFT) and
TXSS Phase received and DTI -> SSW
Perform SSW backoff within A-BFT ->
Pre-Complete Perform SSW Feedback
acknowledgment Perform Responder TXSS
acknowledgment
TXSS Phase
Complete
T2 = dot11MaxBFTime
Figure 10-84—SLS phase state machine (responder)
1569
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.39 DMG link adaptation
10.39.1 General
A STA may transmit a Link Measurement Request frame to request a STA indicated in the RA field of the
frame to respond with a Link Measurement Report frame (9.6.7.5). If the Link Measurement Request frame
is sent within a PPDU defined in Clause 20, the Link Measurement Report frame shall contain the DMG
Link Margin element. The requesting STA may use values of the MCS, of the SNR and of the Link Margin
to transmit frames to the STA indicated in the RA field of the Link Measurement Request frame.
The requesting STA may aggregate a Link Measurement Request frame in an A-MPDU as defined in
Table 9-425 and Table 9-428.
If the Dialog Token field in the Link Measurement Request frame is equal to a nonzero value, the
responding STA shall perform the measurement on the next frame received from the requesting STA and
shall send back a Link Measurement Report frame corresponding to the received frame.
The responding STA may aggregate a Link Measurement Report frame in a A-MPDU as defined in Table 9-
425 and Table 9-428.
The DMG STA whose MAC address equals the value of the Link Measurement Request frame RA field
shall transmit a Link Measurement Report frame addressed to the requesting STA. The RA field of the Link
Measurement Report frame shall be equal to the TA field of the Link Measurement Request frame.
If the Dialog Token field in the Link Measurement Report frame is equal to the nonzero Dialog Token field
of the Link Measurement Request frame, then the MCS, SNR, and Link Margin fields of the Link
Measurement Report frame shall be computed using the measurements of the PPDU that is the next frame
received from the requesting STA.
If the Dialog Token field in the Link Measurement Request frame is equal to 0, the responding STA may set
the MCS field in the Link Measurement Report frame to the MCS value computed based on any of the
received frames from the requesting STA.
The SNR field and Link Margin field in the Link Measurement Report frame shall indicate the
corresponding measurements based on the reception of the PPDU that was used to generate the MCS
feedback contained in the same Link Measurement Report frame.
The Link Measurement Request and Report frames can be used to obtain link margin information, which
can be used to determine appropriate action by the requesting STA (e.g., change MCS or control transmit
power or initiate FST).
A STA may send an unsolicited Link Measurement Report frame with the Dialog Token field set to 0.
10.39.2 DMG TPC
A DMG STA that receives a Link Measurement Report frame containing a DMG Link Margin element that
indicates increase or decrease transmit power behaves according to the following rules:
— If the STA implements the recommendation indicated in the Activity field of the Link Measurement
Report, it shall send a Link Measurement Report frame containing a DMG Link Adaptation
Acknowledgment element. The Activity field of the DMG Link Adaptation Acknowledgment
element shall be set to the value of the Activity field in the received DMG Link Margin Subelement.
— If the STA does not implement the recommendation indicated in the Activity field of the Link
Measurement Report, it may send a Link Measurement report containing a DMG Link Adaptation
1570
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Acknowledgment element. The Activity field of the DMG Link Adaptation Acknowledgment
element shall be set to 0, indicating that the STA did not change its transmit power.
— A STA shall not send a Link Measurement Report later than 2×aPPDUMaxTime after it
acknowledged the reception of the Link Measurement report.
A DMG STA shall not include the DMG Link Adaptation Acknowledgment element in a Link Measurement
Report frame, unless the frame is being transmitted in response to a received Link Measurement Report
frame whose Activity field is equal to increase or decrease transmit power.
10.39.3 Fast link adaptation
A STA indicates support for fast link adaptation by setting the Fast Link Adaptation field in the STA’s DMG
Capabilities element to 1. A STA that does not support fast link adaptation sets the Fast Link Adaptation
field in the STA’s DMG Capabilities element to 0. A STA that supports fast link adaptation shall not initiate
fast link adaptation with a peer STA that does not support fast link adaptation.
A STA that supports fast link adaptation shall support the reverse direction protocol (see 10.28). The STA
that transmits a Link Measurement Request frame as part of fast link adaptation shall be the RD initiator and
the STA that responds with a Link Measurement Report frame shall be the RD responder. Transmission of
Link Measurement Request, Link Measurement Report and the frames defined below shall follow the rules
of the reverse direction protocol.
A STA initiates fast link adaptation by transmitting a Link Measurement Request frame that is of subtype
Action No Ack and has its Dialog Token field set to 0. The PPDU containing the frame shall have the
AGGREGATION parameter in the TXVECTOR set to AGGREGATED, shall not contain any other frame
that requires immediate response, and shall have a duration (as determined by the PHY-TXTIME.confirm
primitive defined in 6.5.6) that is greater than aMinPPDUDurationForDMGMeasurement.
NOTE—The PPDUs have the AGGREGATION parameter in the TXVECTOR set to AGGREGATED to allow padding
of the PSDUs with MPDU delimiters of size 0, therefore meeting the transmission duration requirement.
A STA that supports fast link adaptation and receives a Link Measurement Request frame of subtype Action
No Ack, with the Dialog Token field equal to 0 and contained in a PPDU with the AGGREGATION
parameter in the RXVECTOR equal to AGGREGATED shall respond with a Link Measurement Report
frame in no longer than BRPIFS from the reception of the Link Measurement Request frame. The TPC
Report element, DMG Link Margin element and other fields transmitted in the Link Measurement Report
frame shall reflect measurements on the PPDU that contained the last received Link Measurement Request
frame from the initiating STA.
The STA responding with the Link Measurement Report frame shall keep the IFS not longer than SIFS by
transmitting PPDUs that do not contain frames requiring immediate response and that have a duration that is
greater than aMinPPDUDurationForDMGMeasurement. All transmitted PPDUs should use the same MCS
and the same transmit power.
The transmitted Link Measurement Report frame shall be of subtype Action No Ack, shall be sent using
MCS 1, and shall be sent within a PPDU with the AGGREGATION parameter in the TXVECTOR set to
AGGREGATED. In addition, the PPDU shall not contain any frame that requires immediate response and
shall have a duration that is greater than aMinPPDUDurationForDMGMeasurement.
If at least one of the conditions above for the transmission of the Link Measurement Report frame is not met,
the STA may follow the rules in 10.39.1 to respond to the received Link Measurement Request frame.
A STA that supports fast link adaptation and that receives a Link Measurement Report frame should respond
with an unsolicited Link Measurement Report frame in no longer than BRPIFS from the reception of the
1571
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Link Measurement Report frame. The TPC Report element, DMG Link Margin element and other fields
transmitted in the unsolicited Link Measurement Report frame shall reflect measurements taken on one or
more of the PPDUs received by the STA transmitting the unsolicited Link Measurement Report frame,
starting with the received Link Measurement Report frame itself. If the unsolicited Link Measurement
Report frame is transmitted longer than SIFS from the reception of the Link Measurement Report frame, the
STA transmitting the unsolicited Link Measurement Report frame shall keep the IFS not longer than SIFS
by transmitting one or more PPDUs before issuing the unsolicited Link Measurement Report frame.
An example of the fast link adaptation procedure is shown in Figure 10-85.
Initiating STA SIFS < Computation time < BRPIFS
Link unsolicited Link
Measurement PPDU Measurement
Request Report
Link
Responding STA PSDU PPDU ... PPDU Measurement
Report
BRPIFS
SIFS
5.27us
Figure 10-85—Example of fast link adaptation procedure
10.40 DMG dynamic tone pairing (DTP)
A pair of communicating STAs shall employ DTP modulation only if both STAs support DTP as indicated
through the DTP Supported field within the STA’s DMG Capabilities element.
A DTP capable STA may use DTP with another DTP capable STA by setting the DTP_TYPE in the
TXVECTOR to dynamic; otherwise, the DTP_TYPE is set to static. The transmitting STA may stop using
DTP by setting the DTP_TYPE in the TXVECTOR to static.
A transmitting STA requests a DTP report from a receiving STA by sending a DTP Request frame to that
STA. Upon receiving a DTP Request frame, the receiving STA shall respond with a DTP Report frame
carrying the DTP configuration. The DTP Report frame should be sent no later than dot11BeaconPeriod
TUs after the receiving STA transmits an Ack frame in response to the reception of the DTP Request frame.
If the transmitting STA does not receive a DTP Report frame from the receiving STA within
dot11BeaconPeriod TUs from the transmitting STA’s reception of the Ack frame corresponding to its most
recent DTP Request frame transmission to the receiving STA, the transmitting STA may retransmit the DTP
Request frame to the receiving STA. The Dialog Token field of the DTP Report frame is set to the value of
the Dialog Token field in the corresponding DTP Request frame.
The transmitting STA should switch to the updated DTP configuration after a DTP Report frame is received.
If a STA transmits a DTP Report frame in response to the reception of a DTP Request frame, the STA shall
not send an updated DTP Report frame unless it receives another DTP Request frame.
A STA that transmits an unsolicited DTP Report frame should not send a new unsolicited updated DTP
Report frame unless the STA has received a frame from the peer STA indicating that the peer STA has
switched to the DTP configuration last sent.
Both the transmitting and receiving STAs maintain two copies of DTP configurations: the current
configuration that is in use for transmission and an updated configuration, if any, received after the current
configuration. The transmitting STA determines when to switch from the current to the updated DTP
1572
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
configuration. The transmitting STA shall indicate the switch from the current configuration to the updated
configuration by toggling the DTP Indicator bit field in the PHY header. The value of the DTP Indicator
field shall be kept unchanged until the transmitting STA decides to switch to the new DTP configuration. By
receiving an Ack frame in response to a Data frame from the receiving STA, the switching operation is
completed.
The transmitting STA may send another DTP Request frame to a receiving STA even if it decided not to
switch to the DTP configuration indicated by the receiving STA’s last transmitted, if any, DTP Report
frame.
If the Beam link cluster field is 0, then the links within the MMSL cluster that use DTP may maintain
independent DTP configurations.
10.41 DMG relay operation
10.41.1 General
The DMG relay procedures are specified in 11.36. This subclause specifies the supported types of DMG
relay.
DMG relay operation is not supported by an IBSS STA. An IBSS STA shall set dot11RelayActivated to
false.
A source REDS, a destination REDS and an RDS can establish two types of relay operation:
— Link switching (10.41.2): If the direct link between the source REDS and destination REDS is
disrupted, the source REDS redirects the transmission of frames addressed to the destination REDS
via the RDS. The RDS forwards frames received from the source REDS to the destination REDS
and from the destination REDS to the source REDS. Direct communication between the source
REDS and destination REDS might resume after the direct link between them is recovered.
— Link cooperation (10.41.3): In this case, the RDS is actively involved in the direct communication
between the source REDS and the destination REDS. A frame transmission from the source REDS
to the destination REDS is simultaneously repeated by the RDS, which might possibly increase the
signal quality received at the destination REDS.
10.41.2 Link switching
10.41.2.1 General
A source REDS that has successfully completed an RLS procedure with a destination REDS for which the
value of the Cooperation-Mode subfield within the negotiated Relay Transfer Parameter Set element is 0
may use the selected RDS between the source REDS and destination REDS for the purpose of link
switching. This is described in this subclause.
10.41.2.2 SP request and allocation
The source REDS uses the procedures described in 11.4 to request an SP allocation between itself and the
destination REDS.
Upon receiving an ADDTS Request frame for which the source AID and the destination AID fields within
the DMG TSPEC element are equal to a pair of a source REDS and a destination REDS, respectively, that
have successfully completed the RLS procedure defined in 11.36.2.4, the AP or PCP schedules an SP with
the source DMG STA as the source REDS and the destination DMG STA as the destination REDS.
1573
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An RDS shall check the value of the source AID and the destination AID fields of each SP allocation within
an Extended Schedule element it receives in a DMG Beacon or Announce frame from the AP or PCP. If the
value of the source AID and the destination AID fields of an SP allocation correspond to a source REDS and
a destination REDS, respectively, that have successfully completed the RLS setup procedure (11.36.2), the
RDS shall operate as an RDS during that SP allocation.
10.41.2.3 Usage of RDS
In link switching, an RDS operates either in FD-AF mode or in HD-DF mode. An RDS capable of FD-AF
relaying shall be in one of two frame transmission modes:
— Normal mode: A pair of source REDS and destination REDS exchange frames via either the direct
link or the relay link until this link is determined to become unavailable due to, for example,
blockage or channel degradation.
— Alternation mode: A source REDS and a destination REDS exchange frames via two separate links,
where the use of each link alternates at each link change interval. The link change interval specifies
the time instants at which a source REDS is allowed to change the link used for a frame transmission
to the destination REDS as specified in 9.4.2.149.
An RDS that supports only HD-DF shall operate in the Normal mode.
The frame transmission mode is indicated in the Relay Transfer Parameter Set element exchanged by the
source REDS, destination REDS, and RDS during the RLS procedure. A source REDS or destination REDS
may change the transmission mode used in a relay link following a successful exchange of RLS Request and
RLS Response frames as described in 11.36.2.4.
An RDS shall start to operate as RDS at the start of an SP for which the value of the source AID and
destination AID fields for that SP are equal to the source REDS and destination REDS, respectively, for
which the RDS has successfully completed the RLS procedure. The RDS can determine the SPs for which it
operates as an RDS upon the reception of an Extended Schedule element.
10.41.2.4 Relay frame exchange rules
10.41.2.4.1 General
Following the completion of the RLS procedure and SP allocation, each of the source REDS, destination
REDS, and RDS have a direct link with one another.
The values of link change interval and data sensing time are indicated within the Relay Transfer Parameter
Set transmitted by the source REDS to the destination REDS during the RLS procedure. Either the link
change interval period or the first period begins at the start of an SP between the source REDS and the
destination REDS, and any transmission by the source REDS, destination REDS, and RDS within a link
change interval period shall use the same link that is used at the start of the link change interval period. A
new link change interval period starts immediately after another link change interval period, but shall not
exceed the end of the SP.
In the normal mode, a source REDS shall use the direct link to initiate frame transmission to the destination
REDS at the start of the first SP allocated between the source REDS and destination REDS for a particular
TID. At the start of the following SP allocations for that same TID, the source REDS uses the last link in
which a frame transmission to the destination REDS via this link was successful. In the alternation mode, the
source DMG STA shall alternate the frame transmission to the destination REDS between direct frame
transmission to the destination REDS and frame transmission through the RDS. The source REDS shall
alternate the link used for a frame transmission at the start of each link change interval.
1574
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If a source REDS transmits a frame to the destination REDS via the direct link but does not receive an
expected Ack frame or BlockAck frame from the destination REDS during a link change interval period, the
source REDS should change the link used for frame transmission at the start of the following link change
interval period and use the RDS to forward frames to the destination REDS.
If a source REDS transmits a frame to the destination REDS via the RDS but does not receive an expected
Ack frame or BlockAck frame from the RDS during a link change interval period or a first period, the source
REDS should change the link used for frame transmission at the start of the following link change interval
period or the following first period and transmit frames directly to the destination REDS.
10.41.2.4.2 Additional frame exchange rules for FD-AF RDS
If the source REDS decides to change the link at the start of the following link change interval period and the
Normal mode is used, the source REDS shall start its frame transmission after data sensing time from the
start of the following link change interval period. If the Alternation mode is used, the source REDS
alternates the link used for frame transmission at the start of each link change interval period, and the value
of data sensing time is ignored.
In the Normal mode, if the destination REDS does not receive a valid frame from the source REDS within
data sensing time after the start of a link change interval, the destination REDS shall immediately change the
link to attempt to receive frames from the source REDS through the RDS. If the More Data subfield in the
last frame received from the source REDS is equal to 0, then the destination REDS shall not switch to the
link in the next link change interval period even if it does not receive a frame during the data sensing time.
An example of frame transfer under Normal mode with FD-AF RDS is illustrated in Figure 10-86.
Data frame to Ack frame to Data frame to Ack frame to
direct link direct link relay link relay link
Link Change Interval
SP SP SP
S D S D S D S R D S R D S R D
Data Sensing
SIFS
Time
Figure 10-86—Example of Normal mode operation with FD-AF relay
In the Alternation mode, if the destination REDS receives an out of order frame, the destination REDS shall
remain at the current link. If the More Data subfield in the last frame received from the source REDS is
equal to 0, then the destination REDS shall not switch links in the next link change interval period. If the
source REDS uses either the direct or the relay link and decides to resume alternate frame transmission, the
source REDS should transmit a frame to the other link data sensing time after the next link change interval to
inform the destination REDS that operation on the other link has been resumed. Note that this is the only
situation when data sensing time is used in the Alternation mode.
1575
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.41.2.4.3 Additional frame exchange rules for HD-DF RDS
When the RDS is operating as a HD-DF RDS and the RDS is used in the frame exchange between the source
REDS and the destination REDS, the frame exchange is performed in two periods, which are repeated for as
long as the RDS is used. In the first period, the source REDS shall transmit a frame to the RDS and then the
RDS responds after SIFS if needed. In the second period, the RDS shall forward the frame received from the
source REDS to the destination REDS, and then the destination REDS responds after SIFS if needed. The
duration of the first period and the second period are specified in the last Relay Transfer Parameter Set
element transmitted from the source REDS.
The first period and second period are valid only when the source REDS and destination REDS exchange
frames via the RDS. The link change interval is valid only when the source REDS and destination REDS
exchange frames via the direct link. The first period begins at the end of the link change interval when a
change to the relay link occurs. The link change interval begins at the end of the second period when a
change to the direct link occurs.
The source REDS may transmit a Relay Ack Request frame to the RDS to determine whether all frames
forwarded through the RDS were received by the destination REDS. Upon reception of a Relay Ack Request
frame, the RDS shall respond with a Relay Ack Response frame and set the BlockAck Bitmap field to
indicate which frames have been received by the destination REDS.
If the source REDS decides to change to the relay link at the start of the following link change interval
period, the source REDS shall start its frame transmission at the start of the following link change interval
period. If the current link is the direct link and the destination REDS does not receive a valid frame from the
source REDS within data sensing time after the start of each link change interval, the destination REDS shall
change the link and consider the first period to begin at the start of the link change interval.
If a link change to the direct link occurs, the source REDS shall start to transmit a frame using the direct link
at the end of the second period when the link change interval begins. The destination REDS shall switch to
the direct link at each first period and listen to the medium toward the source REDS. If the destination REDS
receives a valid frame from the source REDS, the destination REDS shall remain on the direct link and
consider the link change interval to begin at the start of the first period. Otherwise, the destination REDS
shall change the link at the start of the next second period and attempt to receive frames from the source
REDS through the RDS. If the active link is the relay link and the More Data subfield in the last frame
received from the RDS is equal to 0, then the destination REDS shall not switch to the direct link even if it
does not receive any frame during the second period.
The source REDS that intends to use the block ack mechanism through the RDS shall perform the block ack
setup procedure with the RDS using the same TID as it is used for the direct communication between the
source REDS and the destination REDS. Similarly, the RDS shall perform the block ack setup procedure
with the destination REDS before transmitting data using the block ack mechanism. Upon reception of an
ADDBA Request frame from the source REDS, the RDS shall send an ADDBA Request frame to the
destination REDS with the same content for all corresponding fields as the ADDBA Request frame received
from the source REDS, except for Buffer Size field, which contains the buffer size of the RDS. Following
the reception of the ADDBA Response frame from the destination REDS, the RDS shall send an ADDBA
Response frame to the source REDS. The ADDBA Response frame shall have the same content for all
corresponding fields as the ADDBA Response frame received from the destination REDS, except for the
Buffer Size field, which shall be set to the minimum between the buffer size of the RDS and the destination
REDS.
1576
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An example of frame transfer with HD-DF RDS is illustrated in Figure 10-87.
Data frame to BAR frame to BA frame to Data frame to BAR frame to BA frame to Relay Ack Relay Ack
direct link direct link direct link relay link relay link relay link request response
Link change
interval 1st Period 2nd Period 1st Period
SP SP
S D S D S D S R S R S R R D R D R D S R
SIFS Data sensing time
Figure 10-87—Example of operation with HD-DF relay
10.41.2.4.4 Operation of FD-AF RDS
In an SP allocated for relay operation, a FD-AF RDS operates in an amplify-and-forward manner. This
means that for each frame detected at the RF in the receive state within an SP in which it operates as a FD-
AF RDS, the RDS amplifies the received signal and simultaneously retransmits it via the RF in transmit
state.
At the start of the SP where it operates as a FD-AF RDS, the RDS shall initiate an RF antenna module in the
receive state directed toward the source REDS and another RF antenna module in transmit state directed
toward the destination REDS.
For each frame received at the RDS during the SP, the RDS shall follow the same rules for frame exchange
sequences as described in Annex G and 10.36. This includes switching the state of each RF available to the
RDS from receive to transmit, and vice-versa, depending upon the frame type and its ack policy.
10.41.2.5 Link monitoring
After a link change, the source REDS might periodically monitor the quality of the previous link. To do that,
the source REDS can use the link change mechanism described in 10.41.2.4. If the previous link is the relay
link, the source REDS can acquire the channel status by using relay link measurement mechanism as
described in 10.41.4. If the previous link is the direct link, the source REDS can acquire the channel status
via the link adaptation mechanism defined in 10.39. If the channel quality of the previous link is better than
the one on the current link, which is an implementation dependent decision, the source REDS may switch to
the previous link.
10.41.3 Link cooperation
10.41.3.1 TPA procedure
A source REDS, a destination REDS, and an RDS use the common relay setup procedure defined in 11.36.2
to set up a link cooperation relay. In addition, to establish a link cooperation relay, the source REDS,
destination REDS, and RDS shall perform the TPA procedure described in this subclause and shown in
Figure 10-88.
1577
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SBIFS dTDR : Propagation delay from D to R
dTDS : Propagation delay from D to S
TPA TPA dTSR : Propagation delay from S to R TPA
Request Request Request
frame frame frame
Destination (D R) (D S) (D R) dTDS-dTDR
REDS (‘D’) dTDR dTSR dTDR
TPA TPA TPA
Response Response Response
aDtime
frame frame frame
(R D) (R S) (R D)
RDS (‘R’)
dTDS
TPA TPA
Response Request
frame frame
Source (S D) (S R)
REDS (‘S’)
SBIFS
Figure 10-88—TPA mechanism
The TPA procedure is triggered by the destination REDS following the common relay setup procedure with
the source REDS and RDS. First, the destination REDS uses the procedures described in 11.4 to request the
allocation of an SP to perform TPA, wherein the source of the SP is the destination REDS and the
destination of the SP is the source REDS. If the value of a source AID and the destination AID fields of an
SP allocation correspond to a destination REDS and a source REDS, respectively, that have successfully
completed the RLS setup procedure, a STA that performs as an RDS in that SP allocation shall operate
during the allocation as a non-RDS-capable DMG STA.
Within the allocated SP, the destination REDS sends a TPA Request frame to the RDS and sets the Timing
Offset field to 0 (see Figure 10-88). SBIFS interval following the end of the first TPA Request frame
transmission, the destination REDS shall send the second TPA Request frame to the source REDS and set
the Timing Offset field to 0. aDtime interval (11.39) following the reception of the first TPA Request frame,
the RDS shall transmit a TPA Response frame back to the destination REDS. Upon receiving the TPA
Response frame from the RDS, the destination REDS shall estimate the TPA value of the RDS and the time
deviation (i.e., 2×dTDR) between the expected Dtime and the actual arrival time of the TPA Response frame.
aDtime interval following the reception of the second TPA Request frame, the source REDS shall transmit a
TPA Response frame back to the destination REDS. The destination REDS shall repeat the same procedure
upon reception of the TPA Response frame received from the source REDS.
SBIFS interval following the end of the transmission of the TPA Response frame to the destination REDS,
the source REDS shall send a TPA Request frame to the RDS and set the Timing Offset field to 0. aDtime
interval following the reception of the TPA Request frame, the RDS shall transmit a TPA Response frame
back to the source REDS. Upon reception of the TPA Response frame from the RDS, the source REDS shall
estimate the TPA value of the RDS and the time deviation (i.e., 2×dTSR) between aDtime and the actual
arrival time of the TPA Response frame.
At aRelayTPATime (11.39) from the end of the last TPA Request frame transmitted by the destination
REDS to the source REDS, the destination REDS shall send a TPA Request frame to the RDS and set the
Timing Offset field to dTDS–dTDR. Upon reception of the TPA Request frame, the RDS shall transmit a TPA
Response frame to the destination REDS at aDtime+dTDR+(dTDS–dTDR) from the end of the TPA Request
frame. Upon reception of the TPA Response frame, the destination REDS shall estimate the time deviation
(i.e., 2×dTDR+(dTDS–dTDR)) between aDtime and the actual arrival time of the TPA Response frame. If the
destination REDS determines that the estimated deviation is equal to 2×dTDR+(dTDS–dTDR), then the
destination REDS considers that the TPA procedure was successful. As the last step of the TPA procedure,
the destination REDS shall send a TPA Report frame to the source REDS that includes the information
regardless of whether the last TPA procedure succeeded.
1578
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If it is not successful, the TPA procedure is repeated until it is successful or upon the decision of the
destination REDS to stop performing the TPA procedure. The TPA procedure includes the estimation of the
sampling frequency-offset (SFO), in order for the source REDS and RDS to adjust their SFOs.
10.41.3.2 Frame exchange operation
10.41.3.2.1 General
A source REDS that has successfully completed an RLS procedure with a destination REDS for which the
value of the Cooperation-Mode subfield within the negotiated Relay Transfer Parameter Set element is equal
to 1 and has successfully completed the TPA procedure shall use the selected RDS between the source
REDS and destination REDS for the purpose of link cooperation. This is described in this subclause.
10.41.3.2.2 Cooperative transmission SP request and allocation
If the source REDS receives a TPA Report frame that indicates the successful completion of the TPA
procedure with the RDS and the destination REDS, the source REDS uses the procedure in 11.4 to request
an SP allocation with the destination REDS. The source REDS might use the SP allocation for
communication with the destination REDS with the assistance of the RDS.
10.41.3.2.3 Data transmission rules
As shown in the example of Figure 10-89, in the allocated SP the first time interval (T1) and the second time
interval (T2) for a cooperative Data frame transfer are determined by the packet transmission time at each
transmission from the source REDS to the destination REDS within the SP.
Pre-determined time = Ptime The period for one cooperative data frame transfer
Data frame from S R
Normal Ack frame beamformed from D S
T1 T2 T1 T2 T1 T2
S R R D S R R D R D
S R
S D S D S D
Ptime SIFS Ptime SIFS Ptime SIFS
The SP period allocated
Figure 10-89—Example of data transmission in SP with link cooperation relay
The data transmission rules are as follows. At the start of each time T1, the source REDS transmits a frame
with its transmit antenna pattern directed toward the RDS and with the TA and the RA fields in the MAC
header set to the MAC address of the source REDS and destination REDS, respectively. After Ptime+dTSR
from the start of T2, the source REDS retransmits the same frame sent to the RDS during the previous time
T1 but now with its transmit antenna pattern directed toward the destination REDS. Similarly, after
Ptime+(dTDS–dTDR) from the start of T2, the RDS retransmits the same frame it received from the source
REDS during the previous time T1. So that the destination REDS might take advantage of the improved
received signal level from both of these transmissions, the destination REDS should set its receive antenna
pattern during T2 such that it simultaneously covers the links toward both the source REDS and the RDS.
1579
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
10.41.4 Relay link adaptation
When a relay link is used for communication between a source REDS and a destination REDS, the link
qualities of the S-R link, the R-D link, and the S-D link might be required.
The source REDS, destination REDS, and RDS use the procedure described in 10.39 to request and report
the link quality among themselves with the following exception. In the Link Measurement Report frame the
RDS transmits to the source REDS, the RDS shall include two Link Margin elements in this order:
— The first Link Margin element shall report the link quality between the source REDS and the RDS.
— The second Link Margin element shall report the link quality between the RDS and the destination
REDS.
Upon reception of a Link Measurement Report frame, the source REDS might take several actions including
changing the MCS it uses for frame transmission to the RDS and destination REDS.
1580
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11. MLME
11.1 Synchronization
11.1.1 General
STAs in a single infrastructure BSS, PBSS, or IBSS are synchronized to a common clock using the
mechanisms defined in 11.1.
STAs in mesh BSSs use a synchronization method that is part of the extensible synchronization framework.
The synchronization in an MBSS is described in 14.13.
A STA for which dot11OCBActivated is true is not a member of a BSS and, therefore, is not required to
synchronize to a common clock or to use these mechanisms.
A timing synchronization function (TSF) keeps the timers for all STAs in the same BSS synchronized. All
STAs in which dot11OCBActivated is false maintain a local TSF timer. STAs in which dot11OCBActivated
is true may maintain a TSF timer for purposes other than synchronization.
A multi-band capable device (11.33) shall maintain a local TSF timer for each channel in which the STA
operates.
11.1.2 Basic approach
11.1.2.1 TSF for an infrastructure BSS or a PBSS
In an infrastructure BSS or in a PBSS, the AP in the infrastructure BSS or the PCP in the PBSS shall be the
timing master for the TSF. In a non-DMG BSS, the AP shall periodically transmit frames called Beacon
frames. In a DMG BSS, the AP or PCP shall periodically transmit frames called DMG Beacon frames and
Announce frames, which provide a similar function to the Beacon frame in a non-DMG BSS. Beacon, DMG
Beacon, and Announce frames contain the value of the AP’s or PCP’s TSF timer in order to synchronize the
TSF timers of other STAs in a BSS. A receiving STA shall accept the timing information in Beacon, DMG
Beacon, and Announce frames sent from the AP or PCP servicing its BSS. If a STA’s TSF timer is different
from the timestamp in the received Beacon, DMG Beacon, or Announce frame, the receiving STA shall set
its local TSF timer to the received timestamp value.
In a non-DMG BSS, Beacon frames shall be generated for transmission by the AP once every
dot11BeaconPeriod TUs.
NOTE—The beacon interval, and hence the valid values of dot11BeaconPeriod, is constrained for APs in which
dot11PublicHCCATXOPNegotiationActivated is true or dot11ProtectedHCCATXOPNegotiationActivated is true as
specified in 11.28.4.1.
In a DMG infrastructure BSS, zero or more DMG Beacon frames shall be generated for transmission by the
AP every dot11BeaconPeriod TUs (see 11.1.3.3). The AP shall transmit at least one DMG Beacon frame
through each sector available to the AP within a time interval that is not longer than dot11BeaconPeriod ×
dot11MaxLostBeacons TUs. The TXSS Span field in the DMG Beacon frame shall be set to a value that is
less than or equal to dot11MaxLostBeacons.
In a PBSS, the value of the TSF timer is delivered to the STA by the DMG Beacon frames generated at each
BTI and by the Announce frames generated during the ATI. In a PBSS, at TBTTs that do not start with a
BTI, the PCP begins a beacon interval with an ATI sequence (see 11.1.3.3.2). The time interval in between
two consecutive BTIs shall be an integer multiple of dot11BeaconPeriod TUs. The PCP shall transmit at
least one DMG Beacon frame to each associated STA within a time interval that is not longer than
1581
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11BeaconPeriod × dot11MaxLostBeacons TUs. The PCP shall transmit at least one DMG Beacon frame
through each possible antenna configuration in a full-coverage set of antenna configurations within the
number of beacon intervals specified within the most recently updated TXSS Span field.
11.1.2.2 TSF for an IBSS
The TSF in an IBSS is implemented via a distributed algorithm that is performed by all of the members of
the BSS. Each STA in the IBSS shall transmit Beacon frames according to the algorithm described in this
clause. Each IBSS STA shall adopt the TSF value received from any Beacon frame or probe response from
the IBSS of which it is a member and which has a TSF value later than its own TSF timer.
11.1.2.3 TSF for an MBSS
The TSF in an MBSS is provided by the MBSS’s active synchronization method. A mesh STA shall
initialize its TSF timer according to the MBSS’s active synchronization method. The mesh STA shall
periodically transmit Beacon frames that contain the value of its TSF timer to announce its local time
reference. Mesh STAs receiving a Beacon frame use the timing information in the Beacon frame as
specified by the MBSS’s active synchronization method. See 14.13.2 for details.
11.1.3 Maintaining synchronization
11.1.3.1 General
Each STA shall maintain a TSF timer with modulus 264 counting in increments of microseconds. STAs
expect to receive Beacon frames at a nominal rate. In a non-DMG infrastructure BSS, the interval between
Beacon frames is defined by dot11BeaconPeriod. In a DMG infrastructure BSS, the STAs expect to receive
at least one DMG Beacon frame every dot11BeaconPeriod × dot11MaxLostBeacons TUs. In a PBSS, STAs
expect to receive at least one DMG Beacon frame or one Announce frame every dot11BeaconPeriod ×
dot11MaxLostBeacons TUs.
A STA sending a Beacon frame shall set the value of the Beacon frame’s timestamp so that it equals the
value of the STA’s TSF timer at the time that the data symbol containing the first bit of the timestamp is
transmitted to the PHY plus the transmitting STA’s delays through its local PHY from the MAC-PHY
interface to its interface with the WM [e.g., antenna]. A STA sending a DMG Beacon or an Announce frame
shall set the value of the frame’s timestamp field to equal the value of the STA’s TSF timer at the time that
the transmission of the data symbol containing the first bit of the MPDU is started on the WM (which can be
derived from the PHY-TXHEADEREND.indication primitive), including any transmitting STA’s delays
through its local PHY from the MAC-PHY interface to its interface with the WM.
11.1.3.2 Beacon generation in non-DMG infrastructure networks
The AP shall define the timing for the entire BSS by transmitting Beacon frames according to
dot11BeaconPeriod. This defines a series of TBTTs exactly dot11BeaconPeriod TUs apart. Time 0 is
defined to be a TBTT with the Beacon frame being a DTIM. At each TBTT, the AP shall schedule a Beacon
frame as the next frame for transmission according to the medium access rules specified in Clause 10.
NOTE—To achieve this requirement, the AP suspends any pending transmissions until the beacon has been transmitted.
In the case of a DTIM, the AP also suspends any pending individually addressed transmissions until any pending group
addressed transmissions have been performed (see 11.2.3.4).
The beacon period is included in Beacon and Probe Response frames, and a STA shall adopt that beacon
period when joining the BSS, i.e., the STA sets dot11BeaconPeriod to that beacon period.
NOTE—Though the transmission of a Beacon frame might be delayed because of CSMA deferrals, subsequent Beacon
frames are scheduled at the undelayed nominal beacon interval. This is shown in Figure 11-1.
1582
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 11-1—Beacon transmission on a busy network
If a STA that does not support short slot time associates with an AP that supports Clause 18 operation, and
the AP is using short slot time, the AP shall use long slot time beginning at the first Beacon frame
subsequent to the association of the long slot time STA.
An AP whose last transmitted values for the Tx STBC subfield and Rx STBC subfield of the HT Capability
Information field of the HT Capabilities element are both nonzero may transmit an STBC Beacon frame and
group addressed traffic using the basic STBC MCS, as defined in 10.7.3. An AP that transmits an STBC
Beacon frame shall set the Dual Beacon field to 1 in transmitted HT Operation elements. A VHT AP shall
set the Dual Beacon field to 0 in transmitted HT Operation elements. The STBC Beacon field shall be set to
1 to identify an STBC Beacon frame. The TBTT for the STBC Beacon frame shall be offset by half of a
beacon interval from the TBTT of the non-STBC Beacon frame. Except for the setting of the STBC Beacon
field, TIM field, and TSF field, all other fields inside the STBC Beacon frame shall be identical to the non-
STBC Beacon frame.
The use of the dual beacon mechanism is deprecated.
11.1.3.3 Beacon generation in a DMG infrastructure BSS and in a PBSS
11.1.3.3.1 General
A DMG STA acting as an AP or PCP follows the DMG channel access procedures (see 10.36) and the rules
described in this subclause to transmit DMG Beacon frames.
Each DMG Beacon frame transmitted by a PCP and by a DMG AP shall have the Discovery Mode field
within the DMG Beacon frame set to 0.
The Duration field of each transmitted DMG Beacon frame shall be set to the time remaining until the end of
the current BTI.
A PCP and a DMG AP establish a series of Target Beacon Transmission Times (TBTTs) spaced
dot11BeaconPeriod TUs apart. The period between two TBTTs is referred to as the beacon interval. The
beacon interval length shall be no more than aMaxBIDuration. Time value zero of the TSF is defined to be a
TBTT.
The length of the beacon interval is included in the DMG Beacon, Announce, and Probe Response frames,
and a DMG STA shall adopt that beacon interval when joining the BSS.
A PCP and a DMG AP that move the TBTT (11.31.2) or change the beacon interval duration (11.31.3) shall
reestablish the TBTT by resetting the TSF to 0 at the time the BSS parameter change takes effect in the BSS.
At each BTI, a PCP and a DMG AP schedule DMG Beacon frames for transmission according to the
procedure specified in 10.38.4. Subject to this constraint, the AP or PCP may delay the DMG Beacon frame
transmission if the medium is determined by the CCA mechanism to be busy. When delaying a DMG
1583
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beacon frame transmission, the AP or PCP shall check that the BTI, A-BFT, and ATI do not overlap in time
with pseudo-static SPs for which the AP or PCP is not the source DMG STA and, if AP or PCP clustering is
in use, that the DMG Beacon frame transmission follows the additional rules described in 10.37.
An AP or PCP may transmit DMG Beacon frames through different antenna configurations during the BTI,
but shall not transmit more than one DMG Beacon frame through the same antenna configuration during the
BTI of any beacon interval. For any beacon interval that does not include a DMG Beacon frame
transmission in the BTI, the AP shall begin the beacon interval with an ATI, and the PCP may begin the
beacon interval with an ATI (11.2.7.3).
When the DMG Beacon frame transmission is performed as multiple directional transmissions, an AP or
PCP should change the sequence of directions through which a DMG Beacon frame is transmitted after it
has transmitted a DMG Beacon frame through each direction in the current sequence of directions. When the
ECAPC Policy Enforced field is equal to 1 in the DMG Beacon frame most recently transmitted by an AP or
PCP, then
— When the AP or PCP transmits a DMG Beacon frame as multiple directional transmissions, the AP
or PCP shall change the sequence of directions through which a DMG Beacon frame is transmitted
after it has transmitted a DMG Beacon frame through each direction in the current sequence of
directions.
— When the AP or PCP transmits a DMG Beacon frame as a single transmission, the AP or PCP shall
randomly delay the transmission of the DMG Beacon frame by up to min(4×TXTIME(DMG
Beacon), 1024×dot11MinBHIDuration) µs after the TBTT.
This is done to randomize and potentially minimize interference to/from the DMG Beacon. One such
example is indicated in Figure 11-2. If the sequence of directions is changed, the sequence of directions shall
be pseudorandomly chosen from a sequence of directions covering the full set of directions available to an
AP or PCP.
Beacon Interval 0 Beacon Interval 1 Beacon Interval N-1 Beacon Interval N
BTI BTI ... BTI BTI ...
0 1 ... N-1 2 N-1 ... 1 N-2 0 ... 2 0 1 ... N-1
Figure 11-2—Example of DMG beacon transmission by an AP or PCP during the BTI
NOTE—An AP or PCP operating in a DMG BSS can transmit Announce frames during the ATI (10.36.3). An
Announce frame can perform the function of a DMG Beacon frame, can be transmitted as an individually addressed
frame directed to a STA, and can provide a much more spectrally efficient access than using a DMG Beacon frame.
A DMG STA that is an AP or a PCP shall include a DMG Operation element within a transmitted DMG
Beacon frame if the CBAP Only field within the DMG Beacon frame is equal to 1. A DMG STA that is an
AP or a PCP shall include a DMG Operation element within a transmitted DMG Beacon frame if the CBAP
Only field within the DMG Beacon frame is equal to 0 and the Extended Schedule element is included in the
DMG Beacon frame. A DMG STA that is an AP or a PCP shall include a DMG Operation element within a
transmitted Announce frame if the Extended Schedule element is included in the Announce frame.
11.1.3.3.2 Beacon generation in a PBSS
In a PBSS, every beacon interval shall start with a BTI or ATI, except in PCP power save (PPS) mode,
where a PCP doze BI may not start with a BTI or ATI.
1584
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A PCP that transmits a DMG Beacon frame with the CBAP Only field equal to 1 within a BTI shall include
a BTI in any following beacon intervals until the completion of the TXSS of which the DMG Beacon frame
is a part.
11.1.3.3.3 Beacon generation in a DMG infrastructure BSS
A DMG AP shall set dot11MaxLostBeacons to the value of the aMinBTIPeriod parameter.
11.1.3.4 DMG beacon generation before establishment of a BSS
A DMG STA can transmit DMG Beacon frames before establishment of a BSS to discover and perform
beamforming during the A-BFT with another DMG STA so that the following frame exchanges between
these STAs do not have to be done as a sector sweep (see 11.1.4.3.3).
A DMG STA that transmits DMG Beacon frames before establishment of a BSS shall set the Discovery
Mode field in each transmitted DMG Beacon frame to 1 to indicates that the establishment of a BSS
procedure defined in 11.1.4.4 has not been performed. In addition, the STA shall set the Next A-BFT field
to 0.
Before establishment of a BSS, the spacing between TBTTs can change, and the time to the next TBTT is
contained in each DMG Beacon frame transmitted at the last BTI. At each TBTT, the STA should generate a
random value for the Beacon Interval field within the DMG Beacon frame from a uniform distribution
between [10 TUs, 200 TUs), i.e., 10 TUs to 199 TUs. Every DMG Beacon frame transmission in the same
BTI shall have the same value in its Beacon Interval field.
The TSF shall be set to 0 at the first TBTT for which the Discovery Mode field within the DMG Beacon
frame is equal to 1. After that, the TSF shall be set to 0 at the TBTT of the beacon interval in which the STA
changes the value of the Beacon Interval field.
A STA shall transmit the first DMG Beacon frame of the next BTI at the time indicated by the start of the
transmission of the first DMG Beacon frame within the last BTI and the value of the Beacon Interval field
contained in the DMG Beacon frame transmitted within the last BTI, unless the medium is determined by
the CCA mechanism to be busy in which case the STA may delay the transmission of the first DMG Beacon
frame transmission.
A STA that transmits a DMG Beacon frame with the Discovery Mode field equal to 1 may indicate the
STA(s) that is allowed to respond in the A-BFT following the BTI where the DMG Beacon frame is
transmitted. To do that, in the DMG Beacon frame the STA shall set the CC Present field to 1 and shall set
the A-BFT Responder Address subfield to an individual address or to a group address of a group that
includes the STA(s) that is allowed to respond in the A-BFT.
A DMG STA that is transmitting DMG Beacon frames with the Discovery Mode field equal to 1 should
configure its receive antenna to a quasi-omni antenna pattern and stay in receiving state during portions of
the DTI defined by the DMG Beacon frame transmissions. This enables the STA to receive frames
transmitted by any STA that is covered by this antenna pattern.
A STA that is transmitting DMG Beacon frames with the Discovery Mode field equal to 1 should cease
transmitting these beacons when it has received a DMG Beacon frame from another STA, or when it has
received acknowledgment of a transmitted Probe Response frame. If a BSS is not initialized as a result of the
channel scanning, the STA can resume transmitting DMG Beacon frames with the Discovery Mode field
equal to 1.
1585
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The procedure of TBTT change described in the preceding paragraph is applicable for DMG Beacon frame
generation before establishment of a BSS, whereas the procedures defined in 11.31.2 and 11.31.3 are used to
change the DMG BSS parameters after an infrastructure BSS or PBSS has been established.
A STA shall set the Duration field of each transmitted DMG Beacon frame to the time remaining until the
end of the current BTI.
11.1.3.5 Beacon generation in an IBSS
Beacon generation in an IBSS is distributed. The beacon period is included in Beacon, Announce, and Probe
Response frames, and a STA shall adopt that beacon period when joining the IBSS. All members of the
IBSS participate in beacon generation. Each STA shall maintain its own TSF timer that is used for
dot11BeaconPeriod timing. The beacon interval within an IBSS is established by the STA at which the
MLME-START.request primitive is performed to create the IBSS. This defines a series of TBTTs exactly
dot11BeaconPeriod TUs apart. Time zero is defined to be a TBTT. At each TBTT the STA shall
a) Suspend the decrementing of the backoff timer for any pending transmission that is not a Beacon or
DMG Beacon frame,
b) Calculate a random delay uniformly distributed in the range between zero and twice aCWmin
aSlotTime when the STA is a non-DMG STA, and between zero and the result of two multiplied
by aCWminDMGIBSS multiplied by the duration of the STA’s following BTI when the STA is a
DMG STA,
c) Wait for the period of the random delay, decrementing the random delay timer using the same
algorithm as for backoff, except that SIFS + aSlotTime should be used as the initial medium idle
period within the backoff procedure. If the ATIM window in use within the IBSS is greater than 0
and the end of the ATIM window occurs before the random delay timer expires, cancel the
remaining random delay and pending Beacon frame transmission and proceed to step f),
d) Cancel the remaining random delay and the pending Beacon frame transmission or BTI (DMG
only), if a Beacon frame arrives from the IBSS of which the STA is a member before the random
delay timer has expired,
e) Send a Beacon frame in a non-DMG BSS or DMG Beacon frame(s) in a DMG BSS if the random
delay has expired and no Beacon frame in a non-DMG BSS or no DMG Beacon frame in a DMG
BSS has arrived from the IBSS of which the STA is a member during the delay period,
f) If the ATIM window in use within the IBSS is greater than 0, then
1) Resume decrementing the backoff timer for any pending transmission allowed inside the ATIM
window and
2) At the end of the ATIM window duration resume the backoff for any pending frames intended
for transmission outside the ATIM window,
g) If the ATIM window in use within the IBSS is 0, then resume decrementing the backoff timer for
any pending transmissions.
Figure 11-3 illustrates beacon transmission in an IBSS.
11.1.3.6 Beacon generation in an MBSS
Beacon generation in an MBSS is described in 14.13.3.1.
1586
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 11-3—Beacon transmission in an IBSS
11.1.3.7 Beacon reception
A STA shall use information from the CF Parameter Set element of all received Beacon frames, without
regard for the BSSID, to update their NAV as specified in 10.4.3.3.
STAs in an infrastructure network or PBSS shall use information that is not in the CF Parameter Set element
in received Beacon frames, DMG Beacon frames, or Announce frames only if the BSSID field is equal to
the MAC address currently in use by the STA contained in the AP of the BSS or to the MAC address
currently in use by the PCP of the PBSS. A non-AP STA in an infrastructure BSS and a non-PCP STA in a
PBSS that supports the Multiple BSSID capability shall use other information in received Beacon or DMG
Beacon frames only if the BSSID field of the non-AP or non-PCP STA is equal to the MAC address
currently in use by the STA contained in the AP or PCP, respectively, of the BSS corresponding to the
transmitted BSSID or if the BSSID field of the non-AP or non-PCP STA is equal to one of the
nontransmitted BSSIDs.
STAs in a non-DMG IBSS shall use information that is not in the CF Parameter Set element in any received
Beacon frame for which the IBSS subfield of the Capability field is 1, the content of the SSID element is
equal to the SSID of the IBSS, and the TSF value is later than the receiving STA’s TSF timer. Use of this
information is specified in 11.1.5.
STAs in an MBSS shall use information in received Beacon frames as described in 14.13.3.2.
A non-AP STA in which dot11MultiBSSIDActivated is true shall support frame filtering for up to two
BSSIDs; one for the transmitted BSSID and one for the nontransmitted BSSID. The STA, when associated
with a BSS corresponding to a nontransmitted BSSID, shall discard all Data and Management frames that
use the transmitted BSSID as the transmit address, except for Beacon, Probe Response, and TIM broadcast
frames.
DMG IBSS STAs shall use other information in any received DMG Beacon (excluding those with the
Discovery Mode field equal to 1) and Announce frames for which the BSS Type subfield is 1, the content of
1587
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the SSID element is equal to the SSID of the IBSS, and the TSF value is later than the receiving STA’s TSF
timer. Use of this information is specified in 11.1.5.
A STA shall ignore the BSS Type field contained in a received DMG Beacon frame if the Discovery Mode
field within the DMG Beacon frame is 1.
An active DMG STA operating in a BSS shall be ready to receive from its AP or PCP for a period of time of
at least dot11MinBHIDuration following the TBTT or expected ATI start time as specified in the last Next
DMG ATI element (9.4.2.135) transmitted by the AP or PCP.
An active DMG STA that is receive beamforming trained with the AP or PCP shall direct its receive antenna
pattern toward the AP or PCP or use a quasi-omni antenna pattern during this time.
A non-PCP STA that receives a DMG Beacon frame from a PCP in which the PCP Association Ready field
is 0 shall not transmit an Association Request frame addressed to the PCP that transmitted the received
DMG Beacon. A non-PCP STA that receives a DMG Beacon frame from a PCP with the PCP Association
Ready field set to 1 may transmit an Association Request frame addressed to the PCP that transmitted the
received DMG Beacon.
11.1.3.8 Multiple BSSID procedure
Implementation of the Multiple BSSID capability is optional for a WNM STA and for a DMG STA. A STA
that implements the Multiple BSSID capability has dot11MultiBSSIDImplemented equal to true. When
dot11MultiBSSIDImplemented is true, dot11WirelessManagementImplemented shall be equal to true
except for a DMG STA, in which case it may be equal to false. A STA in which dot11MultiBSSIDActivated
is true is defined as a STA that supports the Multiple BSSID capability. The STA shall set to 1 the Multiple
BSSID field of the Extended Capabilities elements that it transmits.
The nontransmitted BSSID profile shall include the SSID element (see 9.4.2.2) and Multiple BSSID-Index
element (see 9.4.2.74) for each of the supported BSSIDs. The AP or PCP may include all other elements in
the nontransmitted BSSID profile. The AP or PCP may include two or more Multiple BSSID elements
containing elements for a given BSSID index in one Beacon frame or DMG Beacon frame. If two or more
are given, the profile is considered to be the complete set of all elements given in all such Multiple BSSID
elements sharing the same BSSID index. Since the Multiple BSSID element is also present in Probe
Response frames, an AP or PCP may choose to advertise the complete or a partial profile of a BSS
corresponding to a nontransmitted BSSID only in the Probe Response frames. In addition, the AP or PCP
may choose to include only a partial list of nontransmitted BSSID profiles in the Beacon frame or DMG
Beacon frame or to include different sets of nontransmitted BSSID profiles in different Beacon frames or
DMG Beacon frames.
When a station receives a Beacon frame or DMG Beacon frame with a Multiple BSSID element that consists
of a nontransmitted BSSID profile with only the mandatory elements, it may inherit the complete profile
from a previously received Beacon frame, DMG Beacon frame, or Probe Response frame, or it may send a
Probe Request frame to obtain the complete BSSID profiles. Each Beacon element not transmitted in a
nontransmitted BSSID subelement is inherited from previous Beacon, DMG Beacon, or Probe Response
frame in which the element is present, except for the Quiet element, which shall take effect only in the
Beacon frame or DMG Beacon frame that contains it and not carry forward as a part of the inheritance. An
AP or PCP is not required to include all supported nontransmitted BSSID profiles in a Probe Response
frame, and may choose to only include a subset based on any criteria. When a nontransmitted BSSID profile
is present in the Multiple BSSID element of the Probe Response frame, the AP or PCP shall include all
elements that are specific to this BSS. If any of the optional elements are not present in a nontransmitted
BSSID profile, the corresponding values are the element values of the transmitted BSSID.
A non-AP and non-PCP STA derives its nontransmitted BSSID value according to 9.4.2.46 and 9.4.2.74.
1588
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Partial Virtual Bitmap field in the transmitted BSSID Beacon frame or DMG Beacon frame shall
indicate the presence or absence of traffic to be delivered to all stations associated to a transmitted or
nontransmitted BSSID. The first 2n bits of the bitmap are reserved for the indication of group addressed
frame for the transmitted and all nontransmitted BSSIDs. The AID space is shared by all BSSs and the
lowest AID value that shall be assigned to a station is 2n (see 9.4.2.6).
Operation in a non-DMG BSS is subject to the following additional rules. If the Contention Free Period is
supported and if more than one BSS’s CFPCount becomes 0 in the same Beacon frame, the AP shall
concatenate the Contention Free Periods of all CFPs that coincide and shall not transmit a CF-End or CF-
End+Ack frame until the end of the concatenated CFP, indicated with a single CF-End or CF-End+Ack
frame, if required. The CF Parameter Set in the transmitted BSSID contains times that are an aggregate of
CFP times of the nontransmitted BSSIDs.
Multiple BSSID rate selection is defined in 10.7.8.
11.1.3.9 TSF timer accuracy
A non-DMG STA’s TSF timer shall be accurate to within ±100 ppm. A DMG STA’s TSF timer shall be
accurate to within ±20 ppm.
NOTE—The worst-case drift between two non-DMG STAs is, therefore, ±200 ppm, and between two DMG STAs, ±40
ppm.
Upon receiving a Beacon, a DMG Beacon, or an Announce frame for the BSS, as described in 11.1.3.7, a
STA shall update its TSF timer according to the following algorithm
— Non-DMG STA: The received timestamp value shall be adjusted by adding an amount equal to the
receiving STA’s delay through its local PHY components plus the time since the first bit of the
timestamp was received at the MAC/PHY interface. In the case of an infrastructure BSS, the STA’s
TSF timer shall then be set to the adjusted value of the timestamp.
— DMG STA: The received timestamp value shall be adjusted by adding an amount equal to the
receiving STA’s delay through its local PHY components plus the time since the last data symbol of
the PHY header, excluding any guard interval, was received as indicated by the
PHY-RXSTART.indication primitive.
In the case of an infrastructure BSS or a PBSS, the STA’s TSF timer shall then be set to the adjusted value of
the timestamp. In the case of an IBSS, the STA’s TSF timer shall be set to the adjusted value of the received
timestamp, if the adjusted value of the timestamp is later than the value of the STA’s TSF timer.
When a STA is associated to a BSS with a nontransmitted BSSID, it shall use the TSF from the transmitted
BSSID Beacon frame.
11.1.4 Acquiring synchronization, scanning
11.1.4.1 General
A STA shall operate in either a Passive Scanning mode or an Active Scanning mode depending on the
current value of the ScanMode parameter of the MLME-SCAN.request primitive.
NOTE—Active scanning is restricted in some frequency bands and regulatory domains.
Upon receipt of the MLME-SCAN.request primitive, a STA shall perform scanning. The SSID parameter
indicates the SSID for which to scan. The SSID List parameter indicates one or more SSIDs for which to
scan.
1589
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
To become a member of a particular ESS using passive scanning, a STA shall scan for Beacon and DMG
Beacon frames containing that ESS’s SSID, returning all Beacon and DMG Beacon frames matching the
desired SSID in the BSSDescriptionSet parameter of the corresponding MLME-SCAN.confirm primitive
with the appropriate bits in the Capability Information field or DMG Capabilities field indicating whether
the Beacon frame or DMG Beacon frame came from an infrastructure BSS, PBSS, or IBSS. If dot11RM-
MeasurementPilotActivated is greater than 1, the STA shall additionally scan for Measurement Pilot frames,
returning in the BSSDescriptionFromMeasurementPilotSet parameter all Measurement Pilot frames that
equal the requested BSSID of the corresponding MLME-SCAN.request primitive and are not already mem-
bers of the BSSDescriptionSet.
To actively scan, the STA shall transmit Probe Request frames containing the desired SSID or one or more
SSID List elements, but a DMG STA might also have to transmit DMG Beacon frames or perform beam-
forming training prior to the transmission of Probe Request frames. When the SSID List element is present
in the Probe Request frame, one or more of the SSID elements may include a wildcard SSID (see 9.4.2.2).
The exact procedure for determining the SSID or SSID List values in the MLME-SCAN.request primitive is
not specified in this standard. When a STA scans for a BSS whose AP does not support the SSID List ele-
ment, or for a BSS for which AP support of the SSID List element is unknown, the SSID element with an
SSID or wildcard SSID shall be included in the MLME-SCAN.request primitive.
NOTE—MLME-SCAN.request primitives and resulting Probe Request frames might include a Request element or
Extended Request element(s) that can be used to request radio measurement information from the scanned BSSs.
Requested radio measurement information from the scanned BSSs is included in the Probe Response frames and in the
MLME-SCAN.confirm primitive.
Upon completion of scanning, an MLME-SCAN.confirm primitive is issued by the MLME indicating all of
the BSS information received.
In DMG BSSs, the Active Scan procedure (11.1.4.3) can be used for device discovery prior to initializing or
joining a BSS.
Upon receipt of an MLME-JOIN.request primitive, the nonmesh STA shall use the synchronization
procedure described in 11.1.4.5. The MLME-JOIN.request primitive is not used to start synchronization in
an MBSS. The synchronization in an MBSS is described in 14.13.
Upon receipt of an MLME-SCAN.request primitive with the SSID parameter equal to the wildcard SSID,
the STA shall passively scan for any Beacon, DMG Beacon, or Measurement Pilot frames, or actively
transmit Probe Request or DMG Beacon frames containing the wildcard SSID, as appropriate depending
upon the value of ScanMode.
If a STA’s scanning does not result in finding a BSS with the target SSID and of the target type, or does not
result in finding any BSS, the STA may start an IBSS upon receipt of the MLME-START.request primitive.
NOTE—Starting an IBSS is restricted in some frequency bands and regulatory domains.
When scanning MBSSs, the STA shall process the procedures described in 14.2.
When a STA starts a BSS, that STA shall determine the BSSID of the BSS. If the BSSType indicates an
infrastructure BSS, then the STA shall start an infrastructure BSS and the BSSID shall be equal to the STA’s
dot11StationID. If the BSSType indicates a PBSS, then the STA shall start a PBSS. For both the
infrastructure BSS and the PBSS, the value of the BSSID shall remain unchanged, even if dot11StationID is
changed after the completion of the MLME-START.request primitive. If the BSSType indicates an IBSS,
the STA shall start an IBSS, and the BSSID shall be an individual locally administered IEEE MAC address
as defined in Clause 8 of IEEE Std 802-2014. The remaining 46 bits of that MAC address shall be a number
selected in a manner that minimizes the probability of STAs generating the same number, even when those
STAs are subjected to the same initial conditions. The value SSID parameter shall be used as the SSID of the
1590
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
new BSS. It is important that designers recognize the need for statistical independence among the random
number streams among STAs.
11.1.4.2 Passive scanning
11.1.4.2.1 Passive scanning for non-DMG STAs
If the ScanType parameter indicates a passive scan, the STA shall listen to each channel scanned for no
longer than a maximum duration defined by the MaxChannelTime parameter.
11.1.4.2.2 Passive scanning for DMG STAs
Upon receipt of the MLME-SCAN.request primitive with the ScanType parameter set to Passive, a DMG
STA shall passively scan for transmissions on each channel specified within the ChannelList parameter of
the MLME-SCAN.request primitive. The channel traversal order during passive scanning is implementation
specific.
That is, the STA shall be in the receive state scanning for a period of time in a channel no less than
MinChannelTime and return information on all DMG Beacon frames received matching a particular BSSID
or SSID parameters specified in the MLME-SCAN.request primitive. If no DMG beacon scan parameters
are specified in the request, then the STA shall return information on all received DMG Beacon frames.
If at any time during the scan the STA detects a frame that is not a DMG Beacon frame, the STA shall
continue to scan the current channel until the scanning timer expires. After scanning one channel, the STA
shall initiate scanning in another channel if at least one channel within the ChannelList parameter has not yet
been scanned.
When the STA has completed scanning all indicated channels, it returns the scan results via the MLME-
SCAN.confirm primitive.
11.1.4.3 Active scanning
11.1.4.3.1 Introduction
Active scanning involves the generation of Probe Request frames and the subsequent processing of received
Probe Response frames. The details of the active scanning procedures are as specified in the following
subclauses.
11.1.4.3.2 Active scanning procedure for a non-DMG STA
Upon receipt of the MLME-SCAN.request primitive with ScanType indicating an active scan, a STA shall
use the following procedure.
For each channel to be scanned:
a) Wait until the ProbeDelay time has expired or a PHY-RXSTART.indication primitive has been
received.
b) Perform the basic access procedure as defined in 10.3.4.2.
c) Send a probe request to the broadcast destination address. The probe request is sent with the SSID
and BSSID from the received MLME-SCAN.request primitive.
d) When the SSID List is present in the invocation of the MLME-SCAN.request primitive, send zero or
more Probe Request frames, to the broadcast destination address. Each probe request is sent with an
SSID indicated in the SSID List and the BSSID from the MLME-SCAN.request primitive. The
basic access procedure (10.3.4.2) is performed prior to each probe request transmission.
1591
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
e) Initialize a timer to 0 and start it running.
f) If a PHY-CCA.indication (BUSY) primitive is not received before the timer reaches
MinChannelTime, proceed to step h).
g) Process all probe responses received until the timer reaches MaxChannelTime, constructing
BSSDescriptions corresponding to the probe responses that match the criteria specified in the
MLME-SCAN.request primitive.
h) Set the NAV to 0 and scan the next channel.
See Figure 11-4 for non-DMG STAs.
Figure 11-4—Probe response
When all channels in the ChannelList have been scanned, the MLME shall issue an MLME-SCAN.confirm
primitive with the BSSDescriptionSet containing all the BSSDescriptions constructed during the scan.
11.1.4.3.3 Active scanning procedure for a DMG STA
Upon receipt of the MLME-SCAN.request primitive with ScanType indicating an active scan, a DMG STA
shall use the following procedure.
For each channel to be scanned:
a) Wait until the ProbeDelay time has expired or a PHY-RXSTART.indication primitive has been
received.
b) Initialize a timer to 0 and start it running.
c) If the DiscoveryMode parameter of the MLME-SCAN.request primitive is equal to 1, generate
DMG Beacon frames as (described in 11.1.3.4) for a period no longer than MaxChannelTime.
d) If a DMG Beacon frame is received before the timer reaches MaxChannelTime and beamforming
training is required (see 10.38), perform beamforming training defined in 10.38.5.
e) Perform the basic access procedure defined in 10.3.4.2
f) If an SSW-Feedback frame is transmitted or received in step d), then:
1) Send a probe request to the broadcast destination address or
— Following the transmission of an SSW-Feedback frame, send a probe request to the MAC
address of the STA addressed by the SSW-Feedback frame.
— Optionally, following the reception of an SSW-Feedback frame, send a probe request to the
MAC address of the STA that transmitted the SSW-Feedback frame.
1592
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In all probe requests sent under step f) 1), the probe request is sent with the SSID and BSSID
from the received MLME-SCAN.request primitive and includes the DMG Capabilities
element. The basic access procedure (10.3.4.2) is performed prior to the probe request
transmission.
2) When the SSID List is present in the invocation of the MLME-SCAN.request primitive, send
zero or more probe requests to the broadcast destination address. Each probe request is sent
with an SSID indicated in the SSID List and the BSSID from the received MLME-
SCAN.request primitive and includes the DMG Capabilities element. The basic access
procedure (10.3.4.2) is performed prior to each probe request transmission.
g) If an SSW-Feedback frame is neither transmitted nor received in step d), then:
1) Optionally send a probe request to the broadcast destination address. The probe request is sent
with the SSID and BSSID from the received MLME-SCAN.request primitive and includes the
DMG Capabilities element. The basic access procedure (10.3.4.2) is performed prior to the
probe request transmission.
2) When the SSID List is present in the invocation of the MLME-SCAN.request primitive, send
zero or more probe requests to the broadcast destination address. Each probe request is sent
with an SSID indicated in the SSID List and the BSSID from the MLME-SCAN.request
primitive and includes the DMG Capabilities element. The basic access procedure (10.3.4.2) is
performed prior to each probe request transmission.
h) Process all probe responses received until the timer reaches MaxChannelTime, constructing
BSSDescriptions corresponding to the probe responses that match the criteria specified in the
MLME-SCAN.request primitive.
i) Set the NAV to 0 and scan the next channel.
When all channels in the ChannelList have been scanned, the MLME shall issue an MLME-SCAN.confirm
primitive with the BSSDescriptionSet containing all the BSSDescriptions constructed during the scan.
See Figure 11-5 for DMG STAs that generate DMG Beacon frames with the Discovery Mode field set to 1.
STA A STA B
DMG Beacon
(Discovery Mode = 1)
Beacon
DMG Beacon
interval length
DMG Beacon (Discovery Mode = 1)
is randomized
(Discovery Mode = 1)
SLS (and BRP (optional)) STA found
Probe Request
Ack
Single TX in Single TX in
STA B Probe Response STA A
direction Ack direction
Figure 11-5—Active scanning for DMG STAs
1593
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.1.4.3.4 Criteria for sending a probe response
A STA that receives a Probe Request frame shall not respond if any of the following apply:
a) The STA does not match any of the following criteria:
1) The STA is an AP.
2) The STA is an IBSS STA.
3) The STA is a mesh STA.
4) The STA is a DMG STA that is not a member of a PBSS and that is performing active scan as
defined in 11.1.4.3.3.
5) The STA is a PCP.
b) The Address 1 field of the Probe Request frame contains an individual address that is not the MAC
address of the STA.
c) The STA is a non-AP STA in an infrastructure BSS and the Address 1 field of the Probe Request
frame contains the broadcast address.
d) The STA is a non-PCP STA in a PBSS and the Address 1 field of the Probe Request frame contains
the broadcast address.
e) The STA is in an IBSS and did not transmit a Beacon or DMG Beacon frame since the last TBTT,
and the Address 1 field of the Probe Request frame contains the broadcast address.
f) The STA is a mesh STA and either of the following criteria are met:
1) The Probe Request frame does not contain a Mesh ID element.
2) The Mesh ID element in the Probe Request frame is present but does not contain the wildcard
Mesh ID and does not match the Mesh ID of the MBSS with which the STA is peered.
g) The STA is not a mesh STA and none of the following criteria are met:
1) The SSID in the Probe Request frame is the wildcard SSID.
2) The SSID in the Probe Request frame matches the SSID of the STA’s.
3) The SSID List element is present in the Probe Request frame and includes the SSID of the
STA’s BSS.
h) The STA is not a mesh STA and the Address 3 field of the Probe Request frame does not contain a
wildcard BSSID and does not match the BSSID of the STA’s BSS.
i) The STA has dot11InterworkingServiceActivated equal to true and the Probe Request frame con-
tains an Interworking element and an Extended Capabilities element whose Interworking field con-
tains the value 1, and at least one of the following criteria is not met:
1) The HESSID field of the Interworking element is absent, or is present and contains the
wildcard HESSID or matches the HESSID field of the InterworkingInfo parameter of the last
MLME-START.request or MLME-JOIN.request primitive.
2) The Access Network Type field of the Interworking element contains the wildcard access
network type or matches the access network type of the STA.
j) The STA has dot11RadioMeasurementActivated equal to true and the Probe Request frame contains
a DSSS Parameter Set element in which the Current Channel field contains a value that is not the
same as dot11CurrentChannel.
k) The STA is a DMG STA and the transmit antenna of the DMG STA is not trained to transmit to the
STA from which the Probe Request frame was received.
An AP shall remain in the awake state, and shall respond to probe requests, subject to the criteria above.
An IBSS STA that sent a Beacon or DMG Beacon frame shall remain in the awake state, and shall respond
to probe requests, subject to the criteria above, until a Beacon or DMG Beacon frame with the BSSID of the
STA’s IBSS is received.
1594
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A mesh STA or PCP that is awake shall respond to probe requests, subject to the criteria above.
NOTE—A result of the procedures defined in this subclause is that:
— Infrastructure BSS: the AP is always awake to respond to probe requests.
— IBSS: at least one STA will be awake to respond to probe requests. More than one STA might respond to any
given probe request, particularly when more than one STA transmitted a Beacon or DMG Beacon frame
following the most recent TBTT, either due to not receiving successfully a previous Beacon or DMG Beacon
frame or due to collisions between beacon transmissions.
— MBSS or PBSS: At any given time it might be the case that no STA is awake to respond to probe requests.
11.1.4.3.5 Contents of a probe response
A STA that responds to a Probe Request frame according to 11.1.4.3.4 shall transmit a Probe Response
frame individually addressed to the STA that transmitted the Probe Request frame.
If there was a Request element or Extended Request element in the Probe Request frame, then:
— Each element that is listed in the Request element or Extended Request element(s) and that is
supported by the STA shall be included in the Probe Response frame. An element that is listed in a
Request element or Extended Request element and that is not supported by the STA shall not be
included.
— Elements that would not have been included otherwise shall be included after all of the elements that
would have been included even in the absence of the Request element or Extended Request element.
— Elements that would have been included even in the absence of the Request element or Extended
Request element shall be included in their normal position (see Table 9-34), and may be included
again after all of the elements that would have been included even in the absence of the Request
element.
NOTE—An element that would necessarily be included anyway is not expected to be requested.
— Elements after all of the elements that would have been included even in the absence of the Request
element or Extended Request element shall be included in the order that they appear in the
(Extended) Request element(s) of the Probe Request frame.
— If dot11RadioMeasurementActivated is true and the RCPI element was requested, an RCPI element
containing the RCPI of the Probe Request frame shall be included. If no measurement result is
available, the RCPI value shall be set to indicate “Measurement not available” (see Table 9-154).
— If dot11RadioMeasurementActivated is true and the RSNI element was requested, an RSNI element
containing the RSNI of the Probe Request frame shall be included. If no measurement result is
available, the RSNI value shall be set to indicate that a measurement is not available. (see 9.4.2.41).
11.1.4.3.6 PCP selection in a PBSS
The PCP selection procedure is performed by the SME when:
— An MLME-SCAN.confirm primitive is received in response to an MLME-SCAN.request primitive
with the value of the ScanType parameter equal to ACTIVE and BSSType parameter equal to
PERSONAL
— There is a PCP handover (see 11.29.2)
The decision of whether a STA or its peer STA is the PCP depends on a comparison of their respective PCP
factors (self_PCP_factor and peer_PCP_factor).The PCP factor, defined in Figure 11-6, is the concatenation
of the value of some of the fields from the DMG Capabilities element transmitted by the STA (see
9.4.2.128).
NOTE—According to convention, the least significant bit is the leftmost bit (B0).
1595
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B0 B6 B7 B14 B15 B21 B22 B23 B24 B25 B26 B31
MAX Pseudo- Decentrali
Associate Total Static zed AP or Power
Reserved Number of TDDTI Reserved
d STA Sectors Allocation PCP Source
Number s clustering
Bits: 7 8 7 1 1 1 1 6
Figure 11-6—PCP factor for a DMG STA
For each peer STA reported as part of an MLME-SCAN.confirm primitive or considered as part of a PCP
handover, the STA proceeds as follows. If the STA’s value of self_PCP_factor is greater than the value of
peer_PCP_factor or if the values are equal and the MAC address of the STA is greater than (see 12.7.1 for
MAC address comparison) the MAC address of the peer STA contained in the peer STA’s DMG
Capabilities element, the STA becomes a candidate PCP. Otherwise, the STA does not become a candidate
PCP.
Subclause 11.1.4.4.2 specifies the rules followed by the SME of a candidate PCP to start a PBSS.
11.1.4.4 Initializing a BSS
11.1.4.4.1 General
Upon receipt of an MLME-START.request primitive, a STA shall determine the BSS’s BSSID (as described
in 11.1.4), select channel synchronization information, select a beacon period, initialize and start its TSF
timer, and begin transmitting Beacon frames if the STA is a non-DMG STA or DMG Beacon frames if the
STA is a DMG STA. See 9.3.3.3 for the description of a Beacon frame, and see 9.3.4.2 for the description of
a DMG Beacon frame.
11.1.4.4.2 Initializing a DMG BSS
Prior to choosing a suitable operating channel and starting a BSS, the SME of a DMG STA should perform
a channel scan to ascertain the quality of each channel that the STA supports. The rules for choosing a
suitable operating channel are implementation specific and might be subject to regulatory requirements.
When a STA’s MAC receives an MLME-START.request primitive, the MAC shall attempt to start a BSS.
The STA may listen for a duration of aMinChannelTime, the listening duration, in the channel specified by
the SME in the request. If the STA determines the channel is suitable for BSS operation at the end of this
listening duration, the STA initializes the BSS by commencing transmission of DMG Beacon frames
according to 11.1.3.3 in the case of a PBSS or an infrastructure BSS and according to 11.1.3.5 in the case of
an IBSS. If AP or PCP clustering is in use on the selected channel, the DMG Beacon frame transmission by
an AP or PCP commences following the additional rules described in 10.37.
If the STA determines that no channels are suitable or available, it responds with an MLME-
START.confirm primitive with a ResultCode of NOT_SUPPORTED. Otherwise, the MLME shall respond
with an MLME-START.confirm primitive with a ResultCode of SUCCESS.
The SME should issue an MLME-START.request primitive with BSSType parameter equal to PERSONAL
for at least one network in which the STA becomes a candidate PCP as defined in 11.1.4.3.6. If the STA
becomes a candidate PCP of more than one network, the SME may issue an MLME-START.request
primitive with BSSType parameter equal to PERSONAL for any of the remaining networks. In either case,
the MLME-START.request primitive should be issued no later than 4×aMaxBIDuration after the MAC
receives an MLME-SCAN.confirm primitive.
1596
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SME should not issue an MLME-START.request primitive with BSSType parameter equal to
PERSONAL for networks in which the STA does not become a candidate PCP as defined in 11.1.4.3.6. If
the SME issues the MLME-START.request primitive under this circumstance, it shall not be issued if less
than 4×aMaxBIDuration has elapsed since the MAC received the MLME-SCAN.confirm primitive.
11.1.4.5 Synchronizing with a BSS
Upon receipt of an MLME-JOIN.request primitive, a STA shall adopt the BSSID in the request. Upon
receipt of a Beacon frame from the BSS, a STA shall adopt the TSF timer value of the parameters in the
Beacon frame using the algorithm described in 11.1.3.9, and the MLME shall issue an MLME-
JOIN.confirm primitive indicating the operation was successful.
In addition to these synchronization parameters, a STA joining an infrastructure BSS adopts each of the
parameters found in the SelectedBSS parameter of the MLME-JOIN.request primitive except Local time,
Capability Information, BSSBasicRateSet parameters, and HT Capabilities element. Local time is not
adopted but is used as a local variable in adopting the TSF as described in 11.1.3.9. The Capability
Information reflects the capabilities of the sender and is not adopted but may be used to determine local
configuration or behavior. The BSSBasicRateSet parameter is not adopted but may determine if the STA
can join the BSS.
If the JoinFailureTimeout timer expires prior to the receipt of a Beacon frame from the BSS, the MLME
shall issue an MLME-JOIN.confirm primitive indicating the operation was unsuccessful.
If dot11MultiDomainCapabilityActivated is true, a STA that is joining an infrastructure BSS and receives a
Beacon or Probe Response frame containing a Country element shall adopt the applicable parameters
included in that Country element, and the dot11RegDomainsSupportedEntry shall be set to Other.
In addition to adopting the synchronization parameters as described in the first paragraph of this subclause, a
STA joining an IBSS shall adopt each of the parameters found in the SelectedBSS parameter of the MLME-
JOIN.request primitive according to the rule found for that parameter in the “IBSS adoption” column of the
matching row of the BSSDescription table found in 6.3.3.3.2 when those parameters exist at the STA.
Parameters adopted by a STA when joining an IBSS shall not be changed by the STA except when adopting
parameters following the reception of a Beacon frame with a later timestamp as described in 11.1.5. When
an IBSS contains STAs with a mix of STA capabilities, e.g., non-HT and HT, a STA in the IBSS adopts the
behavioral parameters of the last beacon with the highest TSF (e.g., a HT STA does not continue use of HT
and does not include an HT Operations element in its beacons).
In addition to the table entries in 6.3.3.3.2, if dot11MultiDomainCapabilityActivated is true, a STA that is
joining an IBSS and receives a Beacon or Probe Response frame containing a Country element shall adopt
the applicable parameters included in that Country element, and the dot11RegDomainsSupportedEntry shall
be set to Other.
A DMG STA shall be capable of transmitting DMG Beacon frames. A DMG STA obtains the operational
parameters in use by its AP or PCP through the DMG Operation Information field of the DMG Operation
element. A DMG STA shall update the value of its local MIB variables with the corresponding field value
transmitted by its AP or PCP within the DMG BSS Parameter Configuration field of the DMG Operation
element (9.4.2.129). Except for the prefix “dot11” used in the MIB variable naming convention, the name of
the field is the same as the name of the corresponding MIB variable.
11.1.4.6 Operation of Supported Rates and BSS Membership Selectors element and
Extended Supported Rates and BSS Membership Selectors element
The Supported Rates and BSS Membership Selectors element and Extended Supported Rates and BSS
Membership Selectors element in Beacon and Probe Response frames is used by STAs in order to avoid
1597
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
associating with a BSS if they do not support all of the data rates in the BSSBasicRateSet parameter or all of
the BSS membership requirements in the BSSMembershipSelectorSet parameter.
If the combined total of the number of rates in the OperationalRateSet parameter and the number of BSS
membership selectors does not exceed eight, the Extended Supported Rates and BSS Membership Selectors
element is optional for inclusion in all of the frame types that include the Supported Rates and BSS
Membership Selectors element. If the combined total of the number of rates in the OperationalRateSet
parameter and the number of BSS membership selectors exceeds eight, an Extended Supported Rates and
BSS Membership Selectors element shall be included to specify the remaining supported rates and BSS
membership selectors in all of the frame types that include the Supported Rates and BSS Membership
Selectors element.
The Supported Rates and BSS Membership Selectors element in Beacon and Probe Response frames is
delivered to the management entity in a STA via the BSSBasicRateSet parameter in the MLME-
SCAN.confirm primitive. The BSS membership selector information in Beacon and Probe Response frames
is delivered to the management entity in a STA via the BSSMembershipSelectorSet parameter in the
MLME-SCAN.confirm primitive. Together, these parameters are used by the management entity in a STA
to avoid associating with a BSS if the STA cannot receive and transmit all of the data rates in the
BSSBasicRateSet parameter or does not support all of the features represented in the
BSSMembershipSelectorSet parameter.
NOTE—A STA that was implemented before the existence of the BSSMembershipSelectorSet parameter interprets each
BSS membership selector in the Supported Rates and BSS Membership Selectors element that is contained in the
BSSMembershipSelectorSet parameter of the transmitting STA as though it were a rate from the BSSBasicRateSet
parameter. The value of each BSS membership selector does not match a rate that is known to the STA and, therefore,
the management entity in the STA avoids associating with the BSS because it determines that the STA cannot receive or
transmit at what appears to be a required rate.
A STA that is implemented after the existence of the BSSMembershipSelectorSet parameter includes each
octet of the Supported Rates and BSS Membership Selectors element that is encoded with the MSB (bit 7)
equal to 1 and that it does not recognize as a rate in its BSSMembershipSelectorSet parameter. The STA then
determines if it can support all of the features represented in its BSSMembershipSelectorSet parameter
before attempting to join the network. If some BSSMembershipSelectorSet parameter values are not
recognized by the STA, the STA does not attempt to join the network.
11.1.5 Adjusting STA timers
A STA in an infrastructure BSS or PBSS shall adopt the TSF timer value in a Beacon, Probe Response,
DMG Beacon, or Announce frame transmitted by the BSS’s AP or PCP. The STA shall use the algorithm
specified in 11.1.3.9.
To response to an MLME-JOIN.request primitive, a STA joining an IBSS shall initialize its TSF timer to 0
and shall not transmit a Beacon, Probe Response, or DMG Beacon frame until it receives from a member of
the IBSS a Beacon, Probe Response or DMG Beacon frame that has a matching SSID. Consequently, the
STA joining an IBSS adopts the timer from the next Beacon, Probe Response, or DMG Beacon frame from
its IBSS.
All Beacon, Probe Response, DMG Beacon, and Announce frames carry a Timestamp field. A STA
receiving such a frame from another IBSS STA with the same SSID shall compare the Timestamp field with
its own TSF time. If the Timestamp field of the received frame is later than its own TSF timer, a non-DMG
STA in the IBSS shall adopt all parameters contained in the Beacon frame according to the rule for that
parameter found in the “IBSS adoption” column of the matching row of the BSSDescription table found in
6.3.3.3.2. A DMG IBSS STA shall adopt each parameter contained in the DMG Beacon or Announce
frames. Parameters adopted by a STA due to the receipt of a later timestamp shall not be changed by the
1598
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA except when adopting parameters due to a subsequently received Beacon, DMG Beacon, or Announce
frame with a later timestamp.
11.1.6 Terminating a BSS
At any time an infrastructure BSS or PBSS may be terminated. At any time a STA may cease support for an
IBSS that it formed. Upon receipt of an MLME-STOP.request primitive, a STA shall stop transmitting
Beacon, Probe Response, DMG Beacon, and Announce frames and deauthenticate all associated STAs.
11.1.7 Supported rates and extended supported rates advertisement
A STA shall include the rates from its OperationalRateSet parameter and the rates from the
BSSBasicRateSet parameter and the BSS membership selectors from the BSSMembershipSelectorSet
parameter in frames it transmits containing Supported Rates and BSS Membership Selectors elements and
Extended Supported Rates and BSS Membership Selectors elements according to the rules described in this
subclause, except that a non-AP STA may omit the HT and VHT BSS membership selectors, as the (V)HT
capabilities are indicated through the presence of a (V)HT Capabilities element.
A STA that supports a combined total of eight or fewer data rates and BSS membership selectors may
include the Extended Supported Rates and BSS Membership Selectors element in all of the frame types that
include the Supported Rates and BSS Membership Selectors element.
A STA that supports a combined total of the number of rates in the OperationalRateSet parameter and the
number of BSS membership selectors that exceeds eight shall generate an Extended Supported Rates and
BSS Membership Selectors element to specify the supported rates and BSS membership selectors that are
not included in the Supported Rates and BSS Membership Selectors element. If the
BSSMembershipSelectorSet parameter contains at least one BSS membership selector, then the STA shall
include at least one BSS membership selector value from the BSSMembershipSelectorSet parameter in the
Supported Rates and BSS Membership Selectors element.
NOTE—Inclusion of at least one BSS membership selector in the Supported Rates and BSS Membership Selectors
element causes a receiving STA that does not process the Extended Supported Rates and BSS Membership Selectors
element to still receive a BSS membership selector (which it considers to be a basic rate) that it does not support. Any
values from the BSSMembershipSelectorSet parameter that are not transmitted in the Supported Rates and BSS
Membership Selectors element are transmitted in the Extended Supported Rates and BSS Membership Selectors
element.
11.2 Power management
11.2.1 General
A STA can be in one of two power states:
— Awake: STA is fully powered.
— Doze: STA is not able to transmit or receive and consumes very low power.
The manner in which a STA transitions between power states is determined by its power management mode
and reflected in dot11PowerManagementMode.
The power management mode of a STA is selected by the PowerManagementMode parameter of the
MLME-POWERMGT.request primitive or MLME-MESHPOWERMGT.request primitive. Once the STA
updates its power management mode, the MLME shall issue an MLME-POWERMGT.confirm primitive or
MLME-MESHPOWERMGT.confirm primitive respectively indicating the success of the operation.
1599
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When MSDUs or A-MSDUs are buffered for power management purposes, the information in the MAC
service tuple(s) for the MSDU(s) shall be maintained (and reordered) as a unit.
11.2.2 Bufferable MMPDUs
MMPDUs are categorized as bufferable or nonbufferable, as shown in Table 11-1. Bufferable MMPDUs are
eligible to be queued for delivery using a power-saving mechanism.
Nonbufferable MMPDUs are delivered without reference to a power-saving mechanism.
Table 11-1—Bufferable/nonbufferable classification of MMPDUs
Description Classification
An MMPDU that is carried in one or more Action (except for Fine Timing Bufferable
Measurement frame and Fine Timing Measurement Request frame),
Disassociation, or Deauthentication frame
An individually addressed MMPDU that is carried in one or more Probe Bufferable
Response frames and that is sent in an IBSS in response to an individually
addressed Probe Request frame.
All other MMPDUs. Nonbufferable
11.2.3 Power management in a non-DMG infrastructure network
11.2.3.1 General
A STA that is associated with an AP and that changes power management mode shall inform the AP of this
fact using the Power Management subfield within the Frame Control field of transmitted frames. The STA
shall remain in its current power management mode until it informs the AP of a power management mode
change via a frame exchange that includes an acknowledgment from the AP. Power management mode shall
not change during any single frame exchange sequence, as described in Annex G.
NOTE—This means the Power Management subfield is the same for all MPDUs in an A-MPDU.
The AP shall buffer individually addressed BUs addressed to STAs operating in a PS mode. These buffered
BUs shall be transmitted only at designated times.
If any STA in its BSS is in PS mode, the AP shall buffer all non-GCR-SP group addressed BUs and deliver
them to all STAs immediately following the next Beacon frame containing a DTIM transmission.
The STAs that currently have buffered BUs (excluding those BUs for a STA associated with ACs that are U-
APSD delivery-enabled when not all ACs are delivery-enabled by that STA) within the AP are identified in
a TIM, which shall be included as an element within all Beacon frames generated by the AP. A STA shall
determine that a BU is buffered for it by receiving and interpreting a TIM.
A STA operating in PS mode that is not in WNM sleep mode shall periodically listen for Beacon frames, as
determined by the ListenInterval parameter of the MLME-ASSOCIATE.request or MLME-
REASSOCIATE.request primitive and the ReceiveDTIMs parameter of the MLME-POWERMGT.request
primitive.
WNM sleep mode enables an extended power save mode for non-AP STAs in which a non-AP STA need
not listen for every DTIM Beacon frame, and need not perform GTK/IGTK updates. STAs in WNM sleep
1600
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
mode can wake up as infrequently as once every WNM sleep interval to check whether the corresponding
TIM bit is set or group addressed traffic is pending.
NOTE—A STA may use both WNM sleep mode and PS mode simultaneously.
The Power Management subfield of the Frame Control field may be set to 0 or 1 within a frame sent by a
STA in WNM sleep mode.
When a STA is in WNM sleep mode and in PS mode, the AP buffers unicast frames according to the traffic
filtering agreement established between the AP and STA, as specified in 11.24.12.2. When a STA is in
WNM sleep mode but not in PS mode, the traffic filtering agreement between the AP and STA and the timer
for the WNM sleep interval remain in place, and the AP queues for nonbuffered delivery all matched frames
(i.e., matched by the traffic filtering agreement) destined to the STA.
In a BSS operating under the DCF or EDCA, or during the CP of a BSS using the PCF, upon determining
that a BU is currently buffered in the AP, a STA operating in the normal (non-APSD) PS mode transmits a
PS-Poll frame to the AP, which responds with the corresponding buffered BU immediately, or
acknowledges the PS-Poll frame and responds with the corresponding BU at a later time. If the TIM
indicating the buffered BU is sent during a CFP, a CF-Pollable STA operating in the PS mode does not send
a PS-Poll frame, but remains active until the buffered BU is received (or the CFP ends).
A non-AP QoS STA may be in PS mode before the setup of DLS or block ack. Once DLS is set up, both of
the QoS STAs associated with a DLS link suspend the PS mode and shall be awake. BUs for a TID without
a schedule are sent using Normal Ack following a PS-Poll frame as described in rest of 11.2.3. Uplink block
ack agreements, block ack agreements for any TID with a schedule, and any block ack agreements to APSD
STAs continue to operate normally.
NOTE—When a STA is in normal (non-APSD) PS mode, the rules described in 11.2.3.6 for PS-Poll operation apply to
any downlink block ack agreement without an associated schedule. An (A-)MSDU delivered for this block ack
agreement in response to the PS-Poll frame might be delivered in an A-MPDU.
11.2.3.2 STA power management modes
A non-AP STA can be in one of two power management modes:
— Active mode: The STA receives and transmits frames at any time. The STA remains in the awake
state.
— Power save (PS) mode: The STA enters the awake state to receive or transmit frames. The STA
remains in the doze state otherwise.
A non-AP STA shall be in active mode upon (re)association.
A STA that has transmitted a frame to an AP with which it is not associated and from which it expects a
response shall remain in the awake state until such a response is received or until the procedure has timed
out.
To change power management modes a STA shall inform the AP by completing a successful frame
exchange (as described in Annex G) that is initiated by the STA. This frame exchange shall include a
Management frame, Extension frame or Data frame from the STA, and an Ack or a BlockAck frame from
the AP. The Power Management subfield(s) in the Frame Control field of the frame(s) sent by the STA in
this exchange indicates the power management mode that the STA shall adopt upon successful completion
of the entire frame exchange, except where the Power Management subfield is reserved (see 9.2.4.1.7). A
non-AP STA shall not change power management mode using a frame exchange that does not receive an
Ack or BlockAck frame from the AP, or using a BlockAckReq frame.
NOTE 1—A PS-Poll frame exchange does not necessarily result in an Ack frame from the AP, so a non-AP STA cannot
change power management mode using a PS-Poll frame.
1601
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 2—The Power Management subfield is ignored in frame exchanges initiated by the AP.
A STA that is changing from doze to awake state in order to transmit shall perform CCA until a frame is
detected by which it can set its NAV, or until a period of time indicated by the NAVSyncDelay from the
MLME-JOIN.request primitive has transpired.
To change power management mode, a STA that is coordinated by an MM-SME shall inform the AP
through a successful frame exchange initiated by the STA. The Power Management subfield in the Frame
Control field of the frame sent by the STA in this exchange indicates the power management mode that the
STAs coordinated by the MM-SME and advertised in the MMS element sent by the STA shall adopt upon
successful completion of the entire frame exchange. To change the power management mode of the
coordinated STA, the frame may be sent using any of the MMSLs within the MMSL cluster established with
the AP.
11.2.3.3 AP TIM transmissions
The TIM shall identify the STAs for which traffic is pending and buffered in the AP. This information is
coded in a partial virtual bitmap, as described in 9.4.2.6. In addition, the TIM contains an indication whether
group addressed traffic is pending. Every STA is assigned an AID by the AP as part of the association
process. AID 0 (zero) is reserved to indicate the presence of buffered non-GCR-SP group addressed BUs.
The AP shall identify those STAs for which it is prepared to deliver42 buffered BUs by setting bits in the
TIM’s partial virtual bitmap that correspond to the appropriate AIDs.
11.2.3.4 TIM types
Two different TIM types are distinguished: TIM and DTIM. After a DTIM, the AP shall transmit buffered
non-GCR-SP group addressed BUs, before transmitting any individually addressed frames.
The AP shall transmit a TIM with every Beacon frame. Every dot11DTIMPeriod, a TIM of type DTIM is
transmitted within a Beacon frame, rather than an ordinary TIM.
Figure 11-7 illustrates the AP and STA activity under the assumptions that no PCF is operating and that a
DTIM is transmitted once every three TIMs. The top line in Figure 11-7 represents the time axis, with the
beacon interval shown together with a DTIM Interval of three beacon intervals. The second line depicts AP
activity. The AP schedules Beacon frames for transmission every beacon interval, but the Beacon frames
may be delayed if there is traffic at the TBTT. This is indicated as “busy medium” on the second line. For
the purposes of this figure, the important fact about Beacon frames is that they contain TIMs, some of which
are DTIMs. Note that the second STA with ReceiveDTIMs equal to false does not power-on its receiver for
all DTIMs.
The third and fourth lines in Figure 11-7 depict the activity of two STAs operating with different power
management requirements. Both STAs power-on their receivers when they need to listen for a TIM. This is
indicated as a ramp-up of the receiver power prior to the TBTT. The first STA, for example, powers up its
receiver and receives a TIM in the first Beacon frame; that TIM indicates the presence of a buffered BU for
the receiving STA. The receiving STA then generates a PS-Poll frame, which elicits the transmission of the
buffered BU from the AP. Non-GCR-SP group addressed BUs are sent by the AP subsequent to the
transmission of a Beacon frame containing a DTIM. The DTIM is indicated by the DTIM count field of the
TIM element having a value of 0.
42
How the AP or mesh STA determines the traffic it is prepared to deliver is outside the scope of this standard.
1602
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 11-7—Infrastructure power management operation (no PCF operating)
11.2.3.5 Power management with APSD
11.2.3.5.1 Power management with APSD procedures
QoS APs capable of supporting automatic power save delivery (APSD) shall signal this capability through
the use of the APSD subfield in the Capability Information field in Beacon, Probe Response, and
(Re)Association Response frames.
QoS STAs use the Power Management subfield in the Frame Control field of a frame to indicate whether it
is in active or PS mode. As APSD is a mechanism for the delivery of downlink BUs to power-saving STAs,
the frames transmitted by a STA in PS mode that is using APSD have the Power Management subfield in the
Frame Control field set to 1, thereby causing buffering to take place at the AP.
APSD defines two delivery mechanisms, namely unscheduled APSD (U-APSD) and scheduled APSD
(S-APSD). STAs may use U-APSD to have some or all of their BUs delivered during unscheduled SPs.
STAs may use S-APSD to schedule delivery of some or all of their BUs during scheduled SPs.
If there is no unscheduled SP in progress, the unscheduled SP begins when the AP receives a trigger frame
from a STA, which is a QoS Data or QoS Null frame using an AC the STA has configured to be trigger-
enabled. An A-MPDU that contains one or more trigger frames acts as a trigger frame. An unscheduled SP
ends after the AP has attempted to transmit at least one BU using a delivery-enabled AC and destined for the
STA, but no more than the number indicated in the Max SP Length field of the QoS Capability element of
the STA’s (Re)Association Request frame if the field has a nonzero value.
NOTE—The transmission of one or more fragments of a BU counts as the transmission of one BU for the purposes of
the constraint indicated by the Max SP Length field.
By setting the EOSP subfield to 1 in the last frame sent during the SP, an unscheduled SP may be terminated
before the maximum number of BUs in the SP has been reached. The times at which an AP may transmit
during an unscheduled SP might be constrained by the U-APSD coexistence mechanism (see 11.2.3.5.2).
In order to configure an AP to deliver BUs during an unscheduled SP, a STA designates one or more of its
ACs to be delivery-enabled and one or more of its AC to be trigger-enabled. A STA may configure an AP to
use U-APSD using two methods. First, the STA may set individual U-APSD Flag bits in the QoS Info
subfield of the QoS Capability element carried in (Re)Association Request frames. When a U-APSD Flag
bit is 1, it indicates that the corresponding AC is both delivery- and trigger-enabled. When all four U-APSD
1603
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Flag subfields are equal to 1 in (Re)Association Request frames, all of the ACs associated with the STA are
trigger- and delivery-enabled during (re)association. When all four U-APSD Flag subfields are equal to 0 in
(Re)Association Request frames, none of the ACs associated with the STA is trigger- or delivery-enabled
during (re)association.
Alternatively, the STA may designate one or more AC as trigger-enabled and one or more AC as delivery-
enabled by sending an ADDTS Request frame per AC to the AP with the APSD subfield set to 1 and the
Schedule subfield set to 0 in the TS Info field in the TSPEC element. APSD settings in a TSPEC request
take precedence over the static U-APSD settings carried in the QoS Capability element. In other words, a
TSPEC request overwrites any previous U-APSD setting of an AC.
NOTE—Such an ADDTS Request frame can be sent regardless of the ACM setting of the AC.
A STA may set an AC to be trigger- or delivery-enabled for its own use by setting up TSPECs with the
APSD subfield set to 1 and the Schedule subfield set to 0 in the uplink or downlink direction, respectively.
An uplink TSPEC plus a downlink TSPEC, or a bidirectional TSPEC with the APSD subfield equal to 1 and
the Schedule subfield equal to 0, makes an AC both trigger- and delivery-enabled. An uplink TSPEC plus a
downlink TSPEC, or a bidirectional TSPEC with the APSD and the Schedule subfields both equal to 0,
makes an AC neither trigger- nor delivery-enabled.
A scheduled SP starts at fixed intervals of time specified in the Service Interval field.The following rules
describe scheduled SP operation:
a) If the scheduled Service Interval field equals 0 (for example, with the GCR-A delivery method), the
scheduled SP starts from the service start time without a fixed delivery interval.
b) To use a scheduled SP for a TS when the access policy is controlled channel access, a STA shall
send an ADDTS Request frame to the AP with the APSD subfield of the TS Info field in the TSPEC
element set to 1.
c) To use a scheduled SP for a TS for an AC when the access policy is contention based channel
access, a STA shall send an ADDTS Request frame to the AP with the APSD and Schedule
subfields of the TS Info field in the TSPEC element both set to 1. If the APSD mechanism is
supported by the AP and the AP accepts the corresponding ADDTS Request frame from the STA,
the AP shall respond to the ADDTS Request frame with a response containing the Schedule element
indicating that the requested service can be accommodated by the AP.
d) When the access policy is contention based channel access for a GCR group addressed stream, a
scheduled SP is set up according to 11.24.16.3.3. The first scheduled SP starts when the lower order
4 octets of the TSF timer equals the value specified in the Service Start Time field.
e) If the SI is nonzero, a STA using scheduled SP shall first wake up at the service start time to receive
downlink individually addressed and/or GCR-SP group addressed BUs buffered and/or to receive
polls from the AP/HC. The STA shall wake up subsequently at a fixed time interval equal to the SI.
f) The AP may modify the non-GCR service start time by indicating so in the Schedule element in a
successful ADDTS Response frame (which is sent in response to an ADDTS Request frame) and in
Schedule frames (which are sent at other times).
g) The AP may modify the GCR service start time by indicating so in the Schedule element in the GCR
Response subelements (see 9.4.2.89 and 11.24.16.3.4).
h) In both non-GCR and GCR cases, the service start time shall be updated (using the previously
described service start time modification procedures) whenever the upper 4 octets of the TSF timer
change.
A scheduled SP begins at the scheduled wakeup time that corresponds to the SI and the service start time
indicated in the Schedule element sent in response to a TSPEC or GCR Request. If the SI is nonzero, the
STA shall wake up at a subsequent time when
1604
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(TSF – Tservice-start) mod SImin = 0.
where
Tservice-start is the service start time
SImin is the minimum SI.
If the SI is nonzero, a scheduled SP for a GCR group ends after the AP has attempted to transmit at least one
BU associated with the GCR group but no more than the number indicated in the Max SP Length field of the
QoS Capability element of the STA’s (Re)Association Request frame. The last frame of the GCR SP shall
have the EOSP subfield set to 1.
NOTE—The transmission of one or more fragments of a BU counts as the transmission of one BU for the purposes of
the constraint indicated by the Max SP Length field.
If a scheduled SP overlaps the period during which the AP is required to transmit non-GCR-SP group
addressed frames and individually addressed frames to STAs in PS mode that follow a DTIM beacon that
has at least 1 bit set to 1 in the partial virtual bitmap of its TIM, the scheduled SP shall be deferred until the
AP has transmitted all such buffered frames.
When the GCR-A delivery method is used, the scheduled Service Interval field is 0. If a STA has a GCR
agreement with an AP for a group address using the GCR-A delivery method, there is no defined end of the
scheduled SP. The STA in PS mode shall enter the awake state and shall remain awake in order to receive
the buffered group addressed BUs until the AP changes the delivery method of the stream to a method other
than GCR-A or until the GCR agreement is canceled.
If scheduled SPs are supported in a BSS, a STA may use both unscheduled and scheduled APSD on
different ACs at the same time. The GCR-SP delivery method may be used on any AC, irrespective of any
non-GCR unscheduled or scheduled APSD flows. When a STA establishes scheduled delivery for an AC the
AP shall not transmit BUs using that AC during an SP that is initiated by a trigger frame, and it shall not
treat BUs using the AC that are received from the STA as trigger frames. The AP shall decline any ADDTS
Request frame that indicates the use of both scheduled and unscheduled APSD to be used on non-GCR-SP
frames of the same AC at the same time.
APSD shall be used only to deliver individually addressed BUs and GCR-SP BUs to a STA. Non-GCR and
non-GCR-SP group addressed BU delivery shall follow the frame delivery rules defined for group addressed
BUs as defined in 11.2.3.7.
11.2.3.5.2 U-APSD coexistence
A non-AP STA that uses U-APSD might not be able to receive all AP transmitted frames during the service
period due to interference observed at the non-AP STA. Although the AP might not observe the same
interference, it is able to determine that the frames were not received correctly by the non-AP STA. The U-
APSD coexistence capability enables the non-AP STA to indicate a requested transmission duration to the
AP for use during U-APSD service periods. Use of the transmission duration enables the AP to transmit
frames during the service period and improve the likelihood that the non-AP STA receives the frames when
the non-AP STA is experiencing interference. The U-APSD coexistence capability reduces the likelihood
that the AP transmits frames during the service period that are not received successfully.
A STA whose dot11UAPSDCoexistenceActivated is true shall support U-APSD coexistence and shall set to
1 the U-APSD Coexistence field of the Extended Capabilities elements that it transmits. Otherwise it shall
set this field to 0.
1605
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A non-AP STA that is associated to an AP where both have previously advertised support for the U-APSD
coexistence capability may transmit ADDTS Request frames including the U-APSD Coexistence element to
the AP.
The content of the ADDTS Request frame excluding the U-APSD Coexistence element is referred to in
subsequent text as the base ADDTS request. Upon reception of the ADDTS Request frame, the AP shall
process the content of the base ADDTS request as described in 11.2.3.5. If the AP determines that the base
ADDTS request cannot be granted it shall respond as described in 11.2.3.5, without processing the U-APSD
Coexistence element. If the AP determines the base ADDTS request can be granted, it shall process the U-
APSD Coexistence element. If the AP supports transmission of frames during the U-APSD service period
for the duration value specified in the U-APSD Coexistence element Interval/Duration field, it shall grant
the ADDTS request as described in 11.2.3.5. Otherwise, it shall deny the ADDTS Request.
If the AP has previously granted an ADDTS request with U-APSD coexistence, a non-AP STA that
continues using QoS services provided by an ADDTS Request frame without U-APSD coexistence may
terminate the use of U-APSD coexistence by transmitting an ADDTS Request frame without the U-APSD
Coexistence element. A non-AP STA may terminate use of all QoS services (including U-APSD
coexistence) resulting from an ADDTS Request frame by transmitting a DELTS Request frame to the AP.
The non-AP STA may transmit multiple ADDTS Request frames to the AP where the last received ADDTS
Request frame will override any previously received ADDTS Request frame.
An AP that supports U-APSD coexistence and accepts an ADDTS request limits the U-APSD coexistence
service period according to the parameters specified in the ADDTS frame U-APSD Coexistence element,
and shall transmit frames to the requesting non-AP STA according to the rules in 10.2.4.2 and the following
rules:
— If the non-AP STA specified a nonzero TSF 0 Offset value in the U-APSD Coexistence element, the
AP should not transmit frames to the non-AP STA outside of the U-APSD Coexistence Service
Period, which begins when the AP receives the U-APSD trigger frame and ends after the
transmission period specified by the result of the following calculation:
End of transmission period = T + (Interval – ((T – TSF 0 Offset) mod Interval))
where
T is the time the U-APSD trigger frame was received at the AP
Interval is the UAPSD Coexistence element Duration/Interval field value (see 9.4.2.91)
or upon the successful transmission of a frame with the EOSP subfield set to 1, whichever is earlier.
— If the non-AP STA specified a TSF 0 Offset value of 0 in the U-APSD Coexistence element, the AP
should not transmit frames to the non-AP STA outside of the U-APSD coexistence service period,
which begins when the AP receives a U-APSD trigger frame and ends after the transmission period
specified by the result of the following calculation:
End of transmission period = T + Duration
where
T is the time the U-APSD trigger frame was received at the AP
Duration is the UAPSD Coexistence element Duration/Interval field value (see 9.4.2.91)
or upon the successful transmission of a frame with the EOSP subfield set to 1, whichever is earlier.
Throughout the U-APSD coexistence service period, the AP shall set the More bit to 1 if it has more frames
to be transmitted and it can determine the frame might be received successfully before the service period
expires.
1606
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The AP should set the EOSP subfield to 1 in the frame that it expects to be the last frame transmitted to the
non-AP STA during the U-APSD coexistence duration. If the last frame expected to be transmitted cannot
be successfully transmitted to the non-AP STA before the termination of the U-APSD SP, or does not have
QoS Control field, the AP should transmit a QoS Null frame with the EOSP subfield set to 1.
The non-AP STA may enter doze state at the end of the U-APSD coexistence service period.
11.2.3.6 AP operation during the CP
An AP shall maintain for each currently associated STA a Power Management status that indicates in which
power management mode the STA is currently operating. APs that implement and signal their support of
APSD shall maintain for each currently associated STA an APSD and an access policy status that indicates
whether the STA is presently using APSD and shall maintain the schedule (if any) for the STA. An AP shall,
depending on the power management mode of the STA, temporarily buffer BUs destined to the STA. An AP
implementing APSD shall, if a STA is using APSD and is in PS mode, temporarily buffer BUs destined to
that STA. No BUs addressed directly to STAs operating in the active mode shall be buffered for power
management reasons.
The following rules describe operation during the CP:
a) BUs destined for PS STAs shall be temporarily buffered in the AP. The algorithm to manage this
buffering is beyond the scope of this standard, with the exception that if the AP is QoS-enabled, it
shall preserve the order of arrival of frames on a per-TID, per-STA basis.
b) Nonbufferable MMPDUs and BUs destined for STAs in the active mode shall be directly
transmitted to those STAs.
c) At every beacon interval, the AP shall assemble the partial virtual bitmap containing the buffer
status per destination for STAs in the PS mode and shall send this out in the TIM field of the Beacon
frame. At every beacon interval, the APSD-capable AP shall assemble the partial virtual bitmap
containing the buffer status of nondelivery-enabled ACs (if there exists at least one nondelivery-
enabled AC) per destination for STAs in PS mode and shall send this out in the TIM field of the
Beacon frame. When all ACs are delivery-enabled, the APSD-capable AP shall assemble the partial
virtual bitmap containing the buffer status for all ACs per destination. If FMS is enabled, the AP
shall include the FMS Descriptor element in every Beacon frame. The FMS Descriptor element shall
indicate all FMS group addressed frames that the AP buffers.
d) If a STA has set up a scheduled SP, it shall automatically wake up at each SP. Therefore, the APSD-
capable AP shall transmit frames associated with admitted traffic with the APSD subfield equal to 1
in the TSPECs buffered for the STA during a scheduled SP. If the STA has set up to use
unscheduled SPs, the AP shall buffer BUs using delivery-enabled ACs until it has received a trigger
frame using a trigger-enabled AC from the non-AP STA, which indicates the start of an unscheduled
SP. A trigger frame received by the AP from a STA that already has an unscheduled SP underway
shall not trigger the start of a new unscheduled SP. The AP transmits BUs destined for the STA and
using delivery-enabled ACs during an unscheduled SP. The bit for AID 0 (zero) in the Bitmap
Control field of the TIM element shall be set to 1 when non-GCR-SP group addressed traffic is
buffered, according to 9.4.2.6.
e) If any associated STAs are in PS mode, the AP shall buffer all non-GCR-SP group addressed BUs,
except those that have the StrictlyOrdered service class.
f) When dot11FMSActivated is false, the AP shall transmit all buffered non-GCR-SP group addressed
BUs immediately after every DTIM.
When dot11FMSActivated is true and the AP has established an FMS delivery interval for a
multicast stream, the AP shall transmit all non-GCR-SP group addressed BUs belonging to
particular FMS stream immediately after the DTIM that has the Current Count field value of the
FMS Counter field set to 0 for that particular FMS stream.
1607
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The More Data subfield of each group addressed frame shall be set to indicate the presence of
further buffered non-GCR-SP group addressed BUs. If the AP is unable to transmit all of the
buffered non-GCR-SP group addressed BUs before the primary or secondary TBTT following the
DTIM, the AP shall set the bit for AID 0 (zero) in the TIM element to 1 for a single BSSID or set the
corresponding group address bit to 1 for multiple BSSIDs, as defined in 9.4.2.6, and when
dot11FMSActivated is true, shall set the appropriate bits in the FMS Descriptor element as
described in 9.4.2.75 to indicate for which non-GCR-SP group addresses there are still buffered
BUs, until all buffered non-GCR-SP group addressed BUs have been transmitted.
When the AP transmits an STBC DTIM or TIM Beacon frame, the AP shall retransmit all non-
GCR-SP group addressed BUs that were transmitted following the non-STBC DTIM or TIM
Beacon frame except that they are transmitted using the basic STBC MCS. It may be the case that a
complete set of buffered non-GCR-SP group addressed BUs is sent over a period of time during
which non-STBC and STBC transmissions are interleaved, but the transition from non-STBC group
addressed transmissions to STBC group addressed transmissions shall be preceded by the
transmission of an STBC Beacon frame and the transition from STBC group addressed
transmissions to non-STBC group addressed transmissions shall be preceded by the transmission of
a non-STBC Beacon frame.
g) When the AP receives a PS-Poll frame from a STA that is in PS mode, it shall forward to the STA a
single buffered BU. The AP shall respond after a SIFS either with a Data or Management frame, or
with an Ack frame; in which case the corresponding Data or Management frame is delayed. Until
the transmission of this BU either has succeeded or is presumed failed (when maximum retries are
exceeded), the AP shall acknowledge but ignore all PS-Poll frames from the same STA. This
prevents a retried PS-Poll frame from being treated as a new request to deliver a buffered BU.
For a STA using U-APSD, the AP transmits one BU destined for the STA from any AC that is not
delivery-enabled in response to PS-Poll frame from the STA. The AP should transmit the BU from
the highest priority AC that is not delivery-enabled and that has a buffered BU. When all ACs
associated with the STA are delivery-enabled, the AP transmits one BU from the highest priority AC
that has a BU.
For a STA in PS mode and not using U-APSD, the AP shall set the More Data subfield of the
response Data or Management frame to 1 to indicate the presence of further buffered BUs (not
including the BU currently being transmitted) for the polling STA.
For a STA using U-APSD, the AP shall set the More Data subfield to 1 to indicate the presence of
further buffered BUs (not including the BU currently being transmitted) that do not use delivery-
enabled ACs. When all ACs associated with the STA are delivery-enabled, the AP shall set the More
Data subfield to 1 to indicate the presence of further buffered BUs (not including the BU currently
being transmitted) using delivery-enabled ACs.
If there are buffered BUs to transmit to the STA, the AP may set the More Data bit in a QoS +CF-
Ack frame to 1 in response to a QoS Data frame to indicate that it has one or more pending BUs
buffered for the PS STA identified by the RA in the QoS +CF-Ack frame. An AP may also set the
More Data bit in an Ack frame to 1 in response to a QoS Data frame to indicate that it has one or
more pending BUs buffered for the PS STA identified by the RA in the Ack frame, if that PS STA
has set the More Data Ack subfield in the QoS Capability element to 1.
Unless indicated above, the AP shall set the More Data bit to 0.
h) At each scheduled APSD SP for a STA, the APSD-capable AP (i.e., an AP for which
dot11APSDOptionImplemented is true) shall attempt to transmit at least one BU, using admitted
TSPECs with the APSD and Schedule subfields both set to 1, that are destined for the STA. At each
unscheduled SP for a STA, the AP shall attempt to transmit at least one BU, but no more than the
value specified in the Max SP Length field in the QoS Capability element from delivery-enabled
ACs, that are destined for the STA.
NOTE—The transmission of one or more fragments of a BU counts as the transmission of one BU for the
purposes of the constraint indicated by the Max SP Length field.
1608
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The AP shall set to 1 the More Data bit of an individually addressed MPDU containing all or part of
a BU, using a delivery-enabled AC and destined for that STA, to indicate that more BUs (not
including the BU currently being transmitted) are buffered for the delivery-enabled ACs. The AP
shall set to 1 the More Data bit of an individually addressed MPDU containing all or part of a BU,
using a nondelivery-enabled AC and destined for that STA, to indicate that more BUs (not including
the BU currently being transmitted) are buffered for the nondelivery-enabled ACs.
In all frames except for the final frame of the SP, the AP shall set the EOSP subfield, if present, to 0
to indicate the continuation of the SP. An AP may also set the More Data bit to 1 in a QoS +CF-Ack
frame in response to a QoS Data frame to indicate that it has one or more pending BUs buffered for
the target STA identified by the RA in the QoS +CF-Ack frame. If the QoS Data frame is using a
delivery-enabled AC, the AP shall set the More Data bit in the QoS +CF-Ack frame to 1 to indicate
more BUs (not including the BU currently being transmitted) are buffered for the delivery-enabled
ACs. If the QoS Data frame is not using a delivery-enabled AC, the AP shall set the More Data bit in
the QoS +CF-Ack frame to 1 to indicate more BUs (not including the BU currently being
transmitted) are buffered for the ACs that are not delivery-enabled.
Unless indicated above, the AP shall set the More Data bit to 0.
The AP considers an APSD STA to be in awake state after it has sent a QoS +CF-Ack frame, with
the EOSP subfield equal to 0, to the APSD STA. If necessary, the AP may generate an extra QoS
Null frame, with the EOSP subfield set to 1. When the AP has transmitted an individually addressed
frame to the STA with the EOSP subfield set to 1 during the SP except for retransmissions of that
frame, the AP shall not transmit any more frames to that STA using this mechanism until the next
SP.
The AP shall set the EOSP subfield to 1 to indicate the end of the SP in APSD.
NOTE—Management frames do not have an EOSP subfield and so the end of the SP cannot be indicated in a
Management frame. If the SP is to end after a Management, a QoS Null frame is used to indicate this.
The AP should not set the EOSP field to 1 in a frame that is not an individually addressed Data
frame that requires acknowledgment.
i) If the AP does not receive an acknowledgment to an individually addressed MPDU containing all or
part of a BU sent to a STA in PS mode following receipt of a PS-Poll frame from that STA, it may
retransmit the frame for at most the lesser of the maximum retry limit and
dot11QAPMissingAckRetryLimit times before the next Beacon frame, but it shall retransmit that
frame at least once before the next Beacon frame, time permitting and subject to its appropriate
lifetime limit. If an acknowledgment to the retransmission is not received, it may wait until after the
next Beacon frame to further retransmit that frame subject to its appropriate lifetime limit.
j) If the AP does not receive an acknowledgment in response to a non-A-MPDU frame that is an
individually addressed Data frame that is sent with the EOSP subfield equal to 1, and that requires
acknowledgment, it shall retransmit that frame at least once within the same SP, subject to
applicable retry or lifetime limits. If the AP does not receive a Block Ack frame in response to an A-
MPDU that contains one or more individually addressed Data frames that are sent with the EOSP
subfield equal to 1, and that require acknowledgment, it shall retransmit at least one of those frames
at least once within the same SP, subject to applicable retry or lifetime limits. The maximum number
of retransmissions within the same SP is the lesser of the maximum retry limit and
dot11QAPMissingAckRetryLimit.
If the AP does not receive an acknowledgment to an individually addressed Data or Management
frame that requires acknowledgment and that is not the initial attempt in this SP to send a frame with
the EOSP subfield equal to 1, it may retransmit that frame in the next SP, subject to applicable retry
or lifetime limits.
An AP that transmits an A-MPDU containing Data frames in which the EOSP subfield is equal to 1
and that receives a BlockAck frame that does not acknowledge all of those MPDUs should not
transmit any missed Data frames within the current service period because the destination STA
might now be asleep.
1609
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
k) An AP may delete buffered BUs for implementation dependent reasons (subject to 11.2.3.12),
including the use of an aging function and availability of buffers. The AP may base the aging
function on the listen interval indicated by the STA in its (Re)Association Request frame or the
WNM sleep interval specified by the non-AP STA in the WNM Sleep Mode Request frame.
l) When an AP is informed that a STA has changed to the active mode, then the AP shall send buffered
BUs (if any exist) to that STA without waiting for a PS-Poll frame. When an AP is informed that an
APSD-capable STA is not using APSD, then the AP shall send buffered BUs (if any exist) to that
STA according to the rules corresponding to the current PS mode of the STA.
11.2.3.7 AP operation during the CFP
An AP shall maintain for each currently associated CF-Pollable STA a Power Management status that
indicates the STA’s current power management mode. An AP shall, for STAs in PS mode, temporarily
buffer BUs addressed to the STA.
The following rules describe operation during the CFP:
a) BUs destined for PS STAs shall be temporarily buffered in the AP. The algorithm to manage this
buffering is beyond the scope of this standard.
b) Nonbufferable MMPDUs and all BUs destined to STAs in the active mode shall be transmitted as
defined in Clause 10.
c) Prior to every CFP, and at each beacon interval within the CFP, the AP shall assemble the partial
virtual bitmap containing the buffer status per destination for STAs in the PS mode, set to 1 the bits
in the partial virtual bitmap for STAs the PC is intending to poll during this CFP, and shall send this
out in the TIM field of the DTIM. The bit for AID 0 (zero) in the Bitmap Control field of the TIM
element shall be set to 1 when group addressed traffic is buffered, according to 9.4.2.6.
d) All non-GCR-SP group addressed MSDUs except those with a service class of StrictlyOrdered shall
be buffered if any associated STAs are in the PS mode, regardless of whether those STAs are CF-
Pollable.
e) When dot11FMSActivated is false, the AP shall transmit all buffered non-GCR-SP group addressed
BUs immediately after every DTIM (Beacon frame with DTIM Count field of the TIM element
equal to 0).
When dot11FMSActivated is true and the AP has set up an FMS delivery interval for a multicast
stream, the AP shall send all non-GCR-SP group addressed BUs belonging to a particular FMS
stream immediately after the DTIM with the Current Count field value of the FMS Counter field set
to 0 for that particular FMS stream.
The More Data subfield shall be set to 1 in the headers of all but the final frame containing one of
these buffered non-GCR-SP group addressed BUs to indicate the presence of further buffered group
addressed BUs. If the AP is unable to transmit all of the buffered non-GCR-SP group addressed BUs
before the non-STBC or STBC TBTT following the DTIM, the AP shall set the bit for AID 0 (zero)
in the TIM element to 1 for a single BSSID or set the corresponding group addressed bit to 1 for
multiple BSSIDs, as defined in 9.4.2.6, and when dot11FMSActivated is true, shall set the
appropriate bits in the FMS Descriptor element as described in 9.4.2.75 to indicate for which non-
GCR-SP group addresses there are still buffered BUs, until all buffered non-GCR-SP group
addressed BUs have been transmitted.
When the AP transmits an STBC DTIM or TIM Beacon frame, the AP shall retransmit all non-
GCR-SP group addressed BUs that were transmitted following the non-STBC DTIM or TIM
Beacon frame except that they are transmitted using the basic STBC MCS. It may be the case that a
complete set of buffered non-GCR-SP group addressed BUs is sent over a period of time during
which non-STBC and STBC transmissions are interleaved, but the transition from non-STBC group
addressed transmissions to STBC group addressed transmissions shall be preceded by the
transmission of a STBC Beacon frame and the transition from STBC group addressed transmissions
1610
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
to non-STBC group addressed transmissions shall be preceded by the transmission of a non-STBC
Beacon frame.
f) Buffered BUs for STAs in the PS mode shall be forwarded to the CF-Pollable STAs under control of
the PC. Transmission of these buffered BUs as well as CF-Polls to STAs in the PS mode that were
indicated in the DTIM in accordance with paragraph c) of this subclause shall begin immediately
after transmission of buffered non-GCR-SP group addressed frames (if any), and shall occur in order
by increasing AID of CF-Pollable STAs. A CF-Pollable STA for which the TIM element of the most
recent Beacon frame indicated buffered BUs shall be in the awake state at least until the receipt of an
individually addressed frame from the AP in which the Frame Control field does not indicate the
existence of more buffered BUs. After acknowledging the last of the buffered BUs, the CF-Pollable
STA operating in the PS mode may enter the doze state until the next DTIM is expected.
g) An AP shall have an aging function to delete pending traffic buffered for an excessive time period.
The exact specification of the aging function is beyond the scope of this standard.
h) When an AP detects that a CF-Pollable STA has changed from the PS mode to the active mode, then
the AP shall queue any buffered BUs addressed to that STA for transmission to that CF-Pollable
STA as directed by the AP’s PC.
11.2.3.8 Receive operation for STAs in PS mode during the CP
A STA in PS mode shall operate as follows to receive a BU from the AP when no PC is operating and during
the CP when a PC is operating.
The following rules describe operation of a STA in PS mode during the CP:
a) The STA shall wake up early enough to be able to receive the first Beacon frame scheduled for
transmission at the time corresponding to the last TBTT for which the STA was awake plus the time
interval indicated by the ListenInterval parameter of the MLME-ASSOCIATE.request or MLME
REASSOCIATE.request primitive.
NOTE—The STA might wake for a TBTT that is earlier than this deadline. In that case the previous
requirement is reset based on a new “last TBTT”.
b) When the STA detects that the bit corresponding to its AID is 1 in the TIM, the STA shall issue a
PS-Poll frame, or a trigger frame if the STA is using U-APSD and all ACs are delivery-enabled, to
retrieve the buffered BU. The PS-Poll or trigger frame shall be transmitted after a random delay
uniformly distributed between zero and aCWmin slots following a DIFS.
c) The STA shall remain in the awake state until it receives the BU in response to its poll or it receives
another Beacon frame whose TIM indicates that the AP does not have any BUs buffered for this
STA. If the bit corresponding to the STA’s AID is 1 in the subsequent TIM, the STA shall issue
another PS-Poll frame to retrieve the buffered BU. When a STA that is using U-APSD and has all
ACs delivery-enabled detects that the bit corresponding to its AID is 1 in the TIM, the STA shall
issue a trigger frame or a PS-Poll frame to retrieve the buffered BU.
d) If the More Data subfield in the MPDU(s) containing the BU indicates that more traffic for that STA
is buffered, the STA, at its convenience, shall poll until no more BUs are buffered for that STA.
e) When dot11FMSActivated is false and ReceiveDTIMs is true, the STA shall wake up early enough
to be able to receive either every non-STBC DTIM or every STBC DTIM sent by the AP of the BSS.
When dot11FMSActivated is true and ReceiveDTIMs is true and the STA has been granted by the
AP an alternate delivery interval for a multicast stream, the STA shall wake up before the non-STBC
DTIM or STBC DTIM having Current Count of FMS Counter field set to 0 for that particular FMS
stream.
A STA that stays awake to receive group addressed BUs shall elect to receive all group addressed
non-STBC transmissions or all group addressed STBC transmissions and remain awake until the
More Data subfield of the appropriate type (non-STBC or STBC) of group addressed BUs indicates
1611
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
there are no further buffered group addressed BUs of that type, or until a TIM is received indicating
there are no more buffered group addressed BUs of that type, or until an FMS Descriptor element is
received indicating that there are no further buffered group addressed BUs for which the STA has
previously received an FMS Response element in a frame that has a value in Address 1 that matches
its MAC address or that has an Address 1 value that is a group address corresponding to a group of
which it is a member and that was transmitted by the AP with which it is associated and which had
an Element Status value in the FMS Status subelement of “Accept”. If a STA receives a QoS +CF-
Ack frame from its AP with the More Data bit equal to 1, then the STA shall operate exactly as if it
received a TIM with its AID bit equal to 1. If a STA has set the More Data Ack subfield in QoS
Capability element to 1, then if it receives an Ack frame from its AP with the More Data bit equal to
1, the STA shall operate exactly as if it received a TIM with its AID bit equal to 1. For example, a
STA that is using the PS-Poll delivery method shall issue a PS-Poll frame to retrieve a buffered BU.
See also 10.3.6.
11.2.3.9 Receive operation for STAs in PS mode during the CFP
A STA in PS mode that is associated as CF-Pollable shall operate as follows in a BSS with an active PC to
receive BUs from the AP during the CFP:
a) The STA shall enter the awake state so as to receive the Beacon frame (which contains a DTIM) at
the start of each CFP.
b) To receive group addressed BUs, the STA shall wake up early enough to be able to receive either
every non-STBC DTIM or every STBC DTIM that may be sent during the CFP. A STA receiving
group addressed BUs shall elect to receive all group addressed non-STBC transmissions or all group
addressed STBC transmissions and remain awake until the More Data subfield of the frames
containing the group addressed BUs indicates there are no further buffered group addressed BUs of
that type, or until a TIM is received indicating there are no more group addressed BUs of that type
buffered or until an FMS Descriptor element is received indicating that there are no further buffered
group addressed BUs for which the STA has previously received an FMS Response element in a
frame that has an Address 1 value that matches its MAC address or that has an Address 1 value that
is a group address corresponding to a group of which it is a member and that was transmitted by the
AP with which it is associated and which had an Element Status value in the FMS Status subelement
of “Accept”. See also 10.3.6.
c) When the STA detects that the bit corresponding to its AID is 1 in the DTIM at the start of the CFP
(or in a subsequent TIM during the CFP), the STA shall remain in the awake state for at least that
portion of the CFP through the time that the STA receives an individually addressed BU from the
AP carried in a frame with the More Data subfield in the Frame Control field indicating that no
further traffic is buffered.
d) If the More Data subfield in the Frame Control field of the last MPDU containing all or part of the
BU received from the AP indicates that more traffic for the STA is buffered, then, when the CFP
ends, the STA may remain in the awake state and transmit PS-Poll frames during the CP to request
the delivery of additional buffered BUs, or may enter the doze state during the CP (except at TBTTs
for DTIMs expected during the CP), awaiting the start of the next CFP.
11.2.3.10 Receive operation using APSD
A STA using APSD shall operate as follows to receive a BU from the AP:
a) If a scheduled SP has been set up, the STA wakes up at its scheduled start time. (The STA shall
wake up early enough to receive transmissions at the scheduled SP.)
b) If the STA is initiating an unscheduled SP, the STA wakes up and transmits a trigger frame to the
AP. When one or more ACs are not delivery-enabled, the STA may retrieve BUs using those ACs by
sending PS-Poll frames to the AP.
1612
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) The STA shall remain awake until it receives a QoS Data frame or QoS Null frame addressed to it,
with the EOSP subfield equal to 1.
d) The STA may send additional PS-Poll frames if the More Data subfield is 1 in a downlink individu-
ally addressed MPDU containing all or part of a BU that does not use a delivery-enabled AC. The
STA may send additional trigger frames if the More Data subfield is 1 in a downlink individually
addressed MPDU containing all or part of a BU that uses a delivery-enabled AC.
For receive operation using the U-APSD coexistence mechanism, see additional procedures in 11.2.3.5.2.
11.2.3.11 STAs operating in the active mode
A STA operating in this mode shall have its receiver activated continuously; such STAs do not need to
interpret the TIM elements in Beacon frames.
11.2.3.12 AP aging function
Any AP aging function shall not cause the buffered BU to be discarded after any period that is shorter than
that indicated by the STA for which the BUs are buffered, in the Listen Interval field of its (Re)Association
Request frame. The exact specification of the aging function is beyond the scope of this standard.
NOTE—This aging function is independent of (i.e., in addition to) other causes of MSDU discard within the MAC, such
as due to the operation of a per-TS MSDU lifetime, or related to dot11QAPEDCATableMSDULifetime.
11.2.3.13 PSMP power management
An AP transmits a PSMP frame containing a schedule only for STAs that are awake.
A STA with an established PSMP session (see 11.4.6) shall be awake at the start of the session’s SP and
shall remain awake until the end of the SP unless permitted to return to sleep as described in this subclause.
NOTE—A STA in power save mode can also be determined to be awake following receipt of a trigger frame according
to the operation of the U-APSD protocol (as defined in 11.2.3.5), following receipt of a PS-Poll frame (as defined in
11.2.3.8), or following a DTIM Beacon (as defined in 11.2.3.8).
The AP may signal the end of the SP for all awake associated PSMP-capable STAs by setting the More
PSMP field to 0 or by sending CF-End frame instead of the next PSMP frame.
NOTE 1—The AP can also signal the end of an SP on a per-STA basis using the EOSP subfield set to 1 in the QoS
Control field, as defined in 9.2.4.5.3 and 11.2.3.6. This field remains set to 1 for any retransmissions of the same frame,
and no more new frames are sent to this particular STA in the current SP.
NOTE 2—If a STA is awake at the start of a scheduled PSMP session, the operation of the More Data subfield in the
Frame Control field and the TIM element are defined by the S-APSD rules in 11.2.3.5, 11.2.3.6, and 11.2.3.10.
A STA shall wake up at the start of the next PSMP frame if the More PSMP field is equal to 1 in the current
PSMP frame, unless the STA has been permitted to return to sleep through the reception of a frame
addressed to it with the EOSP subfield equal to 1 or the maximum SP interval has elapsed.
Within a PSMP sequence, a PPDU containing MPDUs addressed to a STA shall not start after the expiration
of the STA’s PSMP-DTT. A STA completes the reception of any PPDU that starts before the end of the
PSMP-DTT. If no frames addressed to a STA begin within a PSMP-DTT, it can assume that no frame
addressed to it will arrive during this PSMP sequence.
The STA shall be awake to receive at the start of the PSMP-DTT determined from a STA_INFO field that
has the STA_INFO Type subfield equal to 2 and the AID field matching the STA’s AID where the PSMP-
DTT Duration subfield is not equal to 0.
1613
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.2.3.14 TDLS peer power save mode
TDLS peer power save mode (TDLS peer PSM) is a power save mechanism that can be used between TDLS
peer STAs, and which is based on a periodic wakeup schedule. A STA supports TDLS peer PSM if
dot11TDLSPeerPSMActivated is true. A STA supporting this capability may indicate support through any
TDLS Setup Request frame or TDLS Setup Response frame. A STA indicating this support shall signal this
by setting the TDLS Peer PSM Support subfield in the Extended Capabilities element included in the TDLS
Setup Request frame or TDLS Setup Response frame to 1. A station that signals support for this capability is
capable of acting in both the TDLS peer PSM initiator and the TDLS peer PSM responder role.
A STA that intends to enter TDLS peer PSM (TDLS peer PSM initiator) shall send a TDLS Peer PSM
Request frame to the TDLS peer STA (TDLS peer PSM responder), including a proposed periodic Wakeup
Schedule. A TDLS Peer PSM Request frame shall not be transmitted to a STA that did not indicate support
for TDLS peer PSM. When the TDLS peer PSM responder accepts the proposed Wakeup Schedule, it shall
respond with a TDLS Peer PSM Response frame indicating status code SUCCESS. Otherwise, the TDLS
peer PSM responder shall respond with a TDLS Peer PSM Response frame indicating the appropriate status
code for rejecting the schedule. An alternative schedule shall be included in the TDLS Peer PSM Response
frame when the status code is equal to TDLS_REJECTED_ALTERNATIVE_PROVIDED. The alternative
schedule may be used by the TDLS peer PSM initiator to generate a new TDLS Peer PSM Request frame.
After successfully transmitting or receiving a TDLS Peer PSM Response frame indicating status code
SUCCESS, the TDLS peer PSM initiator and TDLS peer PSM responder have established a periodic
wakeup schedule between them. The wakeup schedule remains valid until one of the following occurs:
— The TDLS direct link is torn down;
— The STAs explicitly update the existing wakeup schedule; or
— No MPDUs containing data have been exchanged for Idle Count consecutive Awake Windows.
A STA transmitting a TDLS Peer PSM Request frame shall remain in the awake state until it received the
corresponding TDLS Peer PSM Response frame. A TDLS Peer PSM Request frame may be transmitted via
the AP path or via the direct path (which is up to the implementer to decide). A TDLS Peer PSM Response
frame shall be transmitted over the direct path.
The timing of the periodic schedule of the TDLS Peer PSM Awake Windows is based on the Offset field,
the Interval field, the Awake Window Slots field, and the Maximum Awake Window Duration field of the
Wakeup Schedule element that is contained in the TDLS Peer PSM Request frame that established TDLS
peer PSM operation on the link.
Awake Windows begin at TSF values that satisfy the equation TSF mod Interval = Offset. The interval
between the start of two successive Awake Windows is equal to the time in microseconds of the Interval
field. The periodic wakeup schedule may be unrelated to the target beacon transmission time (TBTT) or the
beacon interval.
Awake Windows end when the Awake Window Slot Counter reaches 0 or when the Maximum Awake
Window Duration has been reached, whichever comes first.
The Awake Window Slot Counter counts down backoff slots that are determined using AIFS[AC_BE] in the
same manner that normal backoff slots are determined according to 10.22.2.4.
The initial value of the Awake Window Slot Counter at the start of the Awake Window shall be equal to the
value in the Awake Window Slots field of the Wakeup Schedule element that is contained in the TDLS Peer
PSM Request frame that established TDLS peer PSM operation on the link.
The Awake Window Slot Counter begins counting at the beginning of the Awake Window and stops
counting when it reaches 0.
1614
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A value of 0 in the Maximum Awake Window Duration field of the Wakeup Schedule element that is
contained in the TDLS Peer PSM Request frame that established TDLS peer PSM operation on the link
means that the end of the Awake Window duration is determined only by the Awake Window Slot Counter.
A value of 0 in the Awake Window Slots field of the Wakeup Schedule element that is contained in the
TDLS Peer PSM Request frame that established TDLS peer PSM operation on the link means that the
duration of the Awake Window is determined only by the Maximum Awake Window Duration.
The Maximum Awake Window Duration field and the Awake Window Slots field shall not both be set to 0
in a TDLS Peer PSM Request frame.
The Awake Window Slots field in a TDLS Peer PSM Request frame should be set to a value that is larger
than CWmin[AC_BE].
A TDLS peer PSM service period is a period of time during which one or more individually addressed
frames are transmitted between two TDLS peer STAs when at least one STA employs TDLS peer PSM. A
TDLS peer PSM service period may be initiated during an Awake Window. A TDLS peer STA in power
save mode may enter a doze state when it has successfully transmitted to and received from the
corresponding TDLS peer STA in power save mode a QoS frame with the EOSP subfield equal to 1, ending
the TDLS peer PSM service period. A TDLS peer STA in power save mode may enter a doze state when it
has successfully received from the corresponding TDLS peer STA in active mode a QoS frame with the
EOSP subfield equal to 1.
Either STA may update an existing schedule by initiating a TDLS Peer PSM Request/Response exchange. If
the TDLS Peer PSM Response frame indicates status code SUCCESS, a new wakeup schedule is established
for the TDLS direct link. Otherwise, the existing schedule still applies. The new schedule takes effect after
the termination of the current TDLS peer PSM service period.
After the successful PSM setup, a STA informs its TDLS peer STA that it will enter power save mode per
direct link by setting the Power Management subfield to 1 in an MPDU requiring acknowledgment. The
STA enters power save mode after successful transmission of the MPDU. The power save status on one
direct link is independent of the power save status on other links (direct or with the AP) the STA may have.
If a TDLS peer STA enters power save mode when a Wakeup Schedule is active, it shall be awake at the
beginning of each scheduled periodic Awake Window, and stay awake for the duration of the Awake
Window or until the end of a TDLS peer PSM service period. Otherwise, it may enter a doze state,
depending on the current requirements to be awake, imposed by other links. A TDLS peer STA that did not
enter power save mode shall remain in the awake state.
When both TDLS peer STAs set the More Data Ack subfield in their QoS Capability element to 1, then the
More Data subfield inside an Ack frame set to 0 shall have the same function as the EOSP subfield inside a
QoS frame set to 1. Transmission of an Ack frame with the More Data subfield set to 0 under these
conditions is equivalent to a successful transmission of a QoS frame with the EOSP subfield set to 1.
When waking up at the beginning of an Awake Window, if a STA has no buffered BU to send to a TDLS
Peer STA that had the More Data Ack subfield in its QoS Capability element equal to 1 during the TDLS
setup exchange, the TDLS STA may send a QoS Null frame with the EOSP subfield of the QoS Control
field set to 1, and the More Data subfield of the Frame Control field set to 0. If the TDLS peer STA that is
the recipient of this QoS Null frame also has no buffered BU to deliver either, and it had the More Data Ack
subfield in its QoS Capability element equal to 1 during the TDLS setup exchange, then the TDLS peer STA
shall respond with an Ack frame that has the More Data subfield set to 0. The STA may discard the QoS
Null frame if it has not been successfully transmitted at the end of the Awake Window. Before the
successful transmission of the QoS Null frame, if a Data or QoS Null frame with an EOSP subfield equal to
1615
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
1 is received from the TDLS peer STA the STA may cancel the pending transmission of the QoS Null frame
after the transmission of an Ack frame with the More Data subfield set to 0.
To keep track of the connectivity over the direct link and to maintain the wakeup schedule, a TDLS peer
STA may start an acknowledged frame exchange at least once per Idle Count consecutive Awake Windows,
as a keepalive. For instance a QoS Null frame may be used as a keepalive frame. When a TDLS Peer PSM
Response frame was successfully transmitted or received and no subsequent TDLS peer PSM service period
has started for Idle Count consecutive wakeup periods, a TDLS peer STA shall delete the wakeup schedule
for this link, which means that the related periodic wakeup no longer occurs (i.e., the TDLS peer STA no
longer has to wake up during this period) and that a wakeup schedule no longer exists for this link. When
traffic arrives at a TDLS peer STA in TDLS peer PSM mode for a link with no existing wakeup schedule,
the STA shall send a TDLS Peer PSM Request frame through the AP path to the TDLS peer STA to activate
a new wakeup schedule. When both TDLS peer STAs enter active mode while a wakeup schedule is active,
no more TDLS peer PSM service periods will occur, causing the wakeup schedule to be deleted.
If a TDLS peer STA does not receive an acknowledgment to an individually addressed QoS frame sent with
the EOSP subfield equal to 1 that terminates a TDLS peer PSM service period, it shall retransmit that frame
at least once within the same service period, subject to the applicable retry or lifetime limit. The maximum
number of retransmissions within the same service period is the lesser of the maximum retry limit and
dot11TDLSPeerSTAMissingAckRetryLimit. If an acknowledgment to the retransmission of this last frame
in the same service period is not received, the TDLS peer STA may wait until the next Awake Window to
further retransmit that frame, subject to its applicable retry or lifetime limit. When the TDLS peer STA has
transmitted an individually addressed frame that terminates a TDLS peer PSM service period then, except
for retransmissions of that frame, the TDLS peer STA shall not transmit any more frames to the TDLS peer
STA until the next Awake Window.
A TDLS peer STA that has an active Wakeup Schedule shall not decrement a backoff count outside the
Awake Windows, if that backoff precedes a frame that is destined for transmission on the related TDLS
direct link.
At the start of an Awake Window, the backoff procedure shall be invoked at an EDCAF if there is a frame
available for transmission at that EDCAF, and the backoff timer for that EDCAF has been 0 for at least one
backoff slot.
Outside of its Awake Windows, and during Awake Windows when on the base channel, a TDLS peer STA
can engage in communications with the AP.
11.2.3.15 TDLS peer U-APSD (TPU)
11.2.3.15.1 General
A STA supports the TPU buffer STA function if dot11TDLSPeerUAPSDBufferSTAActivated is true. A
non-QoS STA shall set dot11TDLSPeerUAPSDBufferSTAActivated to false. A STA supporting this
capability may indicate support through any TDLS Setup Request frame or TDLS Setup Response frame. A
STA indicates support by setting the TPU Buffer STA Support subfield in the Extended Capabilities element
included in the TDLS Setup Request frame or TDLS Setup Response frame to 1. Support for the TPU buffer
STA function means that the STA has the capability to buffer BUs destined to the TPU sleep STA, and to
deliver them during unscheduled service periods.
To operate as the TPU sleep STA in TPU, a STA shall configure its TPU capable TDLS peer STA by setting
one or more U-APSD Flag subfields inside the QoS Info subfield of the QoS Capability element carried in a
TDLS Setup Response frame to 1, or by setting one or more U-APSD Flag subfields inside the QoS Info
subfield of the EDCA Parameter Set element carried in a TDLS Setup Confirm frame to 1.
1616
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA that configured TPU at a TDLS peer STA enters power save mode on a TDLS direct link after the
successful transmission to the TDLS peer STA over the direct link of an acknowledged MPDU with the
Power Management subfield equal to 1. The STA that transmitted the frame with the Power Management
subfield equal to 1 is then referred to as a TPU sleep STA. The STA that received the frame with the Power
Management subfield equal to 1 is referred to as a TPU buffer STA. A TPU sleep STA may be a TPU buffer
STA at the same time and on the same link, by sending a frame to the TDLS peer STA with the Power
Management subfield of the Frame Control field set to 1 (this transmission will be preceded by the
transmission of a Peer Traffic Indication frame and the subsequent receipt of a trigger frame that starts a
service period). The power save status on one direct link is independent of the power save status on other
links (direct or with the AP) the STA may have.
The procedure to trigger and terminate an unscheduled SP between TPU buffer STA and a TPU sleep STA
are described in 11.2.3.5 and 11.2.3.6, where the TPU buffer STA shall take the role of the AP and the TPU
sleep STA shall take the role of the non-AP STA using U-APSD, except that a frame with the EOSP subfield
equal to 1 shall not act as a trigger frame.
11.2.3.15.2 TPU at the TPU buffer STA
BUs at a TPU buffer STA destined for a TPU sleep STA shall be temporarily buffered at the TPU buffer
STA. The algorithm to manage this buffering is beyond the scope of this standard, except that the TPU
buffer STA shall preserve the order of buffered BUs on a per-TID, per-STA basis.
A TPU buffer STA shall transmit an individually addressed TDLS Peer Traffic Indication frame to a TPU
sleep STA, through the AP, if and only if all of the following conditions are met:
— A BU destined for a TPU sleep STA was placed into a buffer at the TPU buffer STA;
— The buffer into which the BU was placed contained no other frames with the same RA; and
— One or more periods of dot11TDLSPeerUAPSDIndicationWindow beacon intervals have expired
after the last service period.
The TDLS Peer Traffic Indication frame shall be transmitted through the AP path.
The transmitted TDLS Peer Traffic Indication frame shall indicate the nonempty AC(s), by setting the
corresponding AC Traffic Available subfield of the TDLS Peer Traffic Indication frame to 1.
A PTI Control element may be included in the TDLS Peer Traffic Indication frame, to allow the TPU sleep
STA to not start a service period when the indicated traffic has already been received by the TPU sleep STA.
The TID field contained in the PTI Control element (if included) shall be set to the TID of the latest MPDU
that has been transmitted over the TDLS direct link to the TPU sleep STA that is the destination of the TDLS
Peer Traffic Indication frame that contains the PTI Control element.
The Sequence Control field contained in the PTI Control element (if included) shall be set to the sequence
number of the latest MPDU that has been transmitted over the TDLS direct link to the TPU sleep STA that is
the destination of the TDLS Peer Traffic Indication frame that contains the PTI Control element.
After transmitting a TDLS Peer Traffic Indication frame without a PTI Control element, the TPU buffer
STA shall stay awake at least until the corresponding or a subsequent TDLS Peer Traffic Response frame is
received.
After transmitting a TDLS Peer Traffic Indication frame without a PTI Control element, the TPU buffer
STA shall stay awake at least until the MPDU following the MPDU indicated in the Sequence Control field
of the PTI Control element is successfully transmitted.
1617
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When no corresponding TDLS Peer Traffic Response frame has been received within
dot11TDLSResponseTimeout after sending a TDLS Peer Traffic Indication frame, the STA shall tear down
the direct link.
11.2.3.15.3 TPU at the TPU sleep STA
When a TPU sleep STA receives a TDLS Peer Traffic Indication frame without a PTI Control element, the
TPU sleep STA shall initiate a service period with the TPU buffer STA during which it shall transmit at least
a TDLS Peer Traffic Response frame. The TDLS Peer Traffic Response frame shall echo the values of the
Dialog Token and Link Identifier fields from the corresponding TDLS Peer Traffic Indication frame. The
TDLS Peer Traffic Response frame shall be sent via the direct path.
When a TPU sleep STA receives a TDLS Peer Traffic Indication frame with a PTI Control element, and the
TPU sleep STA has not received from the TPU buffer STA the MPDU following the MPDU that is indicated
in the TDLS Peer Traffic Indication frame, the TPU sleep STA shall initiate a service period with the TPU
buffer STA to retrieve the buffered traffic for the AC(s) for which no unscheduled SP is currently active.
11.2.3.16 FMS power management
11.2.3.16.1 General
Implementation of FMS is optional for a WNM STA. A STA whose dot11FMSActivated is true shall
support FMS and shall set to 1 the FMS field of the Extended Capabilities elements that it transmits.
11.2.3.16.2 FMS general procedures
When dot11FMSActivated is true at the AP, the AP shall include the FMS Descriptor element in every
Beacon frame. The FMS Descriptor indicates the FMS group addressed buffered BUs at the AP. If there are
no buffered BUs for FMS streams accepted by the AP, the AP shall set the Length field in the FMS
Descriptor element to 1. The AP shall include the FMS Descriptor element for a nontransmitted BSSID in
the Multiple BSSID element sent in a Beacon frame.
When dot11FMSActivated is true at the AP, the AP shall support from one to eight different FMS Stream
delivery intervals for any number of FMS streams. Corresponding to these eight delivery intervals are eight
FMS counters. More than one FMSID may have the same delivery interval and therefore will share the same
FMS Counter. An FMS Counter corresponds to each unique delivery interval of one or more FMS Streams.
Each FMS counter decrements once per DTIM beacon and when the FMS counter reaches 0, buffered group
addressed BUs assigned to that particular interval are scheduled for delivery immediately following the next
Beacon frame containing the DTIM transmission. After transmission of the buffered group addressed BUs,
the AP shall reset the FMS counter to the delivery interval for the FMS streams associated with that FMS
counter.
A non-AP STA that does not use FMS wakes every DTIM interval and follows group addressed BU
reception rules as defined in 11.2.3.8.
A STA that supports FMS shall be capable of supporting a delivery interval of 1 for any stream.
11.2.3.16.3 FMS Request procedures
A non-AP STA that supports FMS may request use of FMS by sending an FMS Request frame or
Reassociation Request frame that includes one or more FMS Request elements to an AP that supports FMS.
Each FMS Request element includes one or more FMS subelements. Each FMS subelement identifies an
1618
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
FMS stream, the requested delivery interval and the maximum delivery interval for that stream. The FMS
delivery interval shall be an integer multiple of the DTIM period.
Upon reception of an FMS Request frame or Reassociation Request frame, the AP shall transmit a
corresponding single FMS Response frame or Reassociation Response frame that contains a corresponding
FMS Response element for each FMS Request element in the same order received. Each FMS Response
element shall contain an FMS Status subelement and zero or more other subelements drawn from Table 9-
197 that corresponds to each FMS subelement in the FMS Request element, in the same order.
For each FMS subelement, the following rules apply:
If the AP accepts the FMS subelement and the requested delivery interval, the Element Status in the
corresponding FMS Status subelement shall be set to “Accept” and the FMSID is assigned to a nonzero
value. In addition:
— If the FMS stream identified in the FMS subelement matches a delivery interval already in use at the
AP, the AP shall assign the FMS stream to use the FMS Counter ID assigned for that delivery
interval.
— When an FMS Stream is accepted by the AP, the Current Count value for that FMS Stream is
decremented by 1 for each DTIM Beacon frame in which the Current Count field appears.
— The AP may reschedule transmission of the FMS Stream identified by an FMSID to align the
transmission time of the FMS stream to the transmission time of other FMS streams that the STA is
already receiving at the same delivery interval. The AP has the following two options:
— Notify the STAs using that FMS Stream. The AP shall keep the nonzero Current Count value
the same across two consecutive Beacon frames in which the Current Count field appears. The
algorithm by which the AP chooses to align or offset the different FMS counters is unspecified.
— Transmit an unsolicited FMS Response frame to the group address included in the original
FMS Response frame for the stream with the updated Delivery Interval field when the Current
Count field value reaches 0. Since the AP transmits this FMS Response frame as a group
addressed frame, the frame will be scheduled for delivery at the appropriate DTIM interval
when all non-AP STAs are awake to receive the frame.
— An AP may terminate the use of FMS and resume default (non-FMS) transmission rules for any
FMS stream identified by FMSID for any reason. To terminate the FMS stream, the AP shall send
an unsolicited FMS Response frame to the group address included in the original FMS Response
frame with Delivery Interval set to 0 and the Element Status in the FMS Status subelement set to one
of “Terminate, due to AP policy change”, “Terminate, due to lack of resources of AP,” and
“Terminate, due to other FMS stream with higher priority”.
— If the FMS subelement contained a nonzero delivery interval and the non-AP STA specified a
maximum delivery interval as part of the FMS request, the AP shall not modify the delivery interval
for the stream greater than the maximum delivery interval specified by the non-AP STA.
— An AP shall transmit MSDUs belonging to the same FMSID in the same order that they were
received at the MAC Data SAP. MSDUs belonging to the different FMSIDs are transmitted by the
AP at the appropriate DTIM in the order received at the MAC data SAP based on the interval
configured for the FMS stream.
If the AP denies the FMS subelement for any reason, including requested delivery interval, maximum
delivery interval and TCLAS, the Element Status in the corresponding FMS Status subelement shall be set
to one of “Deny, due to request format error or ambiguous classifier”, “Deny, due to lack of resources on
AP”, “Deny, due to requested classifier(s) matching 2 or more existing streams on different intervals,”
“Deny, by policy, requested stream or filter is not permitted to participate in the service”, and “Deny, reason
unspecified”.
1619
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the AP selects an alternate delivery interval or alternate maximum delivery interval from the value
specified in the FMS Request, the Element Status field in the corresponding FMS Status subelement shall be
set to one of “Alternate proposed, due to existing stream with different delivery interval”, “Alternate
proposed, due to policy limits on AP”, “Alternate proposed, because the AP changed the delivery interval”,
and “Alternate proposed, because the AP changed the maximum delivery interval” and the FMS subelement
shall indicate the AP selected value(s).
To terminate the use of FMS for an FMS Stream identified by FMSID, the non-AP STA shall transmit an
FMS Request frame with an FMS Request element and FMS subelement with the FMSID matching the
FMS stream and the delivery interval set to 0.
The AP shall respond to a malformed FMS Request frame or Reassociation Request frame with an FMS
Response frame or Reassociation Response frame that denies all FMS Request elements by including an
FMS Status code “Deny, due to request format error or ambiguous classifier” in the Element Status field in
each FMS Status subelement in the FMS Response element.
11.2.3.16.4 FMS Response procedures
Upon reception of an FMS Response element in a frame that has a value in Address 1 that matches its MAC
address or that is a group address corresponding to a group of which it is a member and that was transmitted
by the AP with which it is associated, a non-AP STA that supports FMS shall use the following procedures,
based on the value of the Element Status value in the FMS Status subelement in the received FMS Response
element.
— If the Element Status value in the FMS Status subelement is “Accept”:
— The AP has accepted the FMS subelement contained within the FMS Request element. If the
FMS Request element specified a nonzero delivery interval, the AP will deliver the requested
streams at the delivery interval as specified by the non-AP STA in the FMS Request element.
— After receiving the FMS Response element, the non-AP STA shall be awake for the next
DTIM beacon so that the non-AP STA can synchronize with the FMS Current Count for the
requested FMS Stream. Once synchronized with the FMS Current Count, the non-AP STA
need not wake up at every DTIM interval to receive group addressed BUs.
— If the Element Status value in the FMS Status subelement is one of “Deny, due to request format
error or ambiguous classifier”, “Deny, due to lack of resources on AP”, “Deny, due to requested
classifier(s) matching 2 or more existing streams on different intervals”, “Deny, by policy, requested
stream or filter is not permitted to participate in the service”, and “Deny, reason unspecified”:
— The AP does not deliver the requested streams at the delivery interval as specified by the non-
AP STA in the FMS Request element. The AP delivers the requested stream at every DTIM
interval.
— If the Element Status value in the FMS Status subelement is one of “Alternate proposed, due to
existing stream with different delivery interval”, “Alternate proposed, due to policy limits on AP”,
“Alternate proposed, because the AP changed the delivery interval”, and “Alternate proposed,
because the AP changed the maximum delivery interval”:
— The AP does not deliver the requested streams at the delivery interval and maximum delivery
interval as specified by the non-AP STA in the FMS Request element. The FMS Status
subelement specifies a delivery interval and a maximum delivery interval that the AP is willing
to accept for the specified streams if the non-AP STA sends another FMS Request with that
delivery interval and maximum delivery interval specified.
— The non-AP STA may submit a new FMS Request that includes the delivery interval value
received from the AP. If the AP accepts this new FMS Request, it shall respond as described in
11.2.3.16.2.
1620
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— If the Element Status value in the FMS Status subelement is “Alternate proposed, because the AP is
unable to provide requested TCLAS-based classifiers”:
— The AP does not deliver the requested streams at the delivery interval as specified by the non-
AP STA in the FMS Request element. The TCLAS element(s) or TCLAS Processing element
in the TCLAS Status subelement contains one or more fields or subfields whose values have
been modified by the AP. The AP may include fewer TCLAS elements in the FMS Response
element than were present in the request; when the AP’s response includes a single TCLAS
element, it does not include a TCLAS Processing element. If the AP changes a TCLAS
element’s Classifier Type field in the FMS Response element but is unable to suggest a value
for the Classifier Mask field, it shall set that field to 0. If the AP changes a TCLAS element’s
Classifier Type field or Classifier Mask field in the FMS Response element but is unable to
suggest values for one or more Classifier Parameter subfields, it shall set those fields to 0.
— A non-AP STA receiving a modified TCLAS element having a Classifier Mask field equal to 0
or Classifier Parameter subfields equal to 0 shall interpret these values as meaning that no
suggested value has been provided by the AP.
— If the Element Status value in the FMS Status subelement is one of “Terminate, due to AP policy
change”, “Terminate, due to lack of resources of AP”, and “Terminate, due to other FMS stream
with higher priority”:
— The AP will terminate the use of FMS transmission rules for any FMS stream identified by
FMSID. If the AP terminates the usage of FMS for a particular stream, the stream is
transmitted at DTIM interval.
— The non-AP STA shall wake up at every DTIM interval to receive group addressed BUs after
receiving the FMS Response element.
11.2.3.17 TIM Broadcast
Implementation of TIM Broadcast is optional for a WNM STA. A STA that implements TIM Broadcast
has dot11TIMBroadcastImplemented equal to true. When dot11TIMBroadcastImplemented is true,
dot11WirelessManagementImplemented shall be true. A STA whose dot11TIMBroadcastActivated value is
true shall support TIM Broadcast and shall set to 1 the TIM Broadcast field of the Extended Capabilities
elements that it transmits. This subclause describes TIM broadcast procedures for STAs whose
dot11TIMBroadcastActivated is true.
TIM frames have shorter duration than Beacon frames and are potentially transmitted at a higher data rate.
TIM Broadcast allows a non-AP STA to receive a TIM element without receiving a Beacon frame that may
reduce the required wake time in a power save mode. The shorter receive time reduces the power
consumption for non-AP STAs in a power save mode. The shorter receive time may reduce the power
consumption for stations in a standby mode.
A non-AP STA may activate the TIM broadcast service by including a TIM Broadcast Request element in a
TIM Broadcast Request frame, Association Request frame or Reassociation Request frame that is
transmitted to the AP, which specifies the requested interval between TIM frame transmissions (the TIM
broadcast interval). On receipt of a properly formatted TIM Broadcast Request element in a TIM Broadcast
Request frame, Association Request frame or Reassociation Request frame, the AP shall include a TIM
Broadcast Response element in the corresponding TIM Broadcast Response frame, Association Response
frame or Reassociation Response frame, when dot11TIMBroadcastActivated is true. When the requested
TIM broadcast interval is acceptable, the AP shall include a TIM Broadcast Response element specifying
the requested TIM broadcast interval and a Status field indicating “Accept” when no valid TSF timestamp is
present in the TIM frames, or “Accept, valid timestamp present in TIM frames” when a valid TSF timestamp
is present in the TIM frames. When the AP overrides the requested TIM broadcast interval, it shall include a
TIM Broadcast Response element specifying a different TIM broadcast interval and a Status field indicating
“Overridden” when no valid TSF timestamp is present in the TIM frames, or “Overridden, valid timestamp
present in TIM frames” when a valid TSF timestamp is present in the TIM frames, and include in the TIM
1621
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Broadcast Response element the smallest TIM broadcast interval that is currently active. Otherwise, the AP
shall include a TIM Broadcast Response element with a Status field indicating “Denied.” The Status field in
a TIM Broadcast Response element that is included in an Association Response frame or Reassociation
Response frame has implications only for the TIM Broadcast negotiation.
NOTE—The STA might ignore the TIM Broadcast Interval field in the TIM Broadcast Response element if the Status
field indicates “Accept” or “Accept, valid timestamp present in TIM frames”, because the TIM broadcast interval is the
requested one.
An AP transmitting a TIM frame with a valid TSF timestamp shall set the value of the TIM frame timestamp
as defined in 11.1.3, for the Beacon frame timestamp.
If the AP accepted at least one TIM Broadcast Request with a nonzero TIM Broadcast Interval field, and at
least one non-AP STA in PS mode still associated with the AP received in its latest TIM Broadcast Response
a status field value equal to 0 (Accepted) in response to a TIM Broadcast Request with a nonzero TIM
Broadcast Interval field, the AP shall transmit one or two TIM frames per TIM Broadcast Interval. The AP
shall not transmit TIM frames otherwise. When TIM broadcast intervals overlap, a transmitted TIM frame
serves both intervals and does not need to be duplicated.
If the AP transmits two TIM frames per TIM Broadcast Interval, the AP shall transmit the high data rate
TIM frame first, followed by the low data rate TIM frame.
The AP shall transmit the low data rate TIM frame at the same data rate or MCS as the Beacon frame. The
AP shall transmit the high data rate TIM frame at a higher data rate or using an MCS that corresponds to a
higher data rate. For Clause 18 and Clause 19 PHYs, if the Beacon frame is transmitted using ERP-DSSS/
CCK, the AP shall transmit the high data rate TIM frame and shall transmit it using ERP-OFDM. Otherwise,
transmitting the high data rate TIM frame is optional. If the high data rate TIM is not transmitted, the AP
shall set the High Data Rate TIM field to 0 in the TIM Broadcast Response element.
The value of the TIM Broadcast Interval field from the latest received TIM Broadcast Response element
(N_TBI) together with dot11BeaconPeriod define a series of target TIM transmission times (TTTTs) N_TBI
dot11BeaconPeriod TUs apart. Time 0 is a TTTT. A non-AP STA may use the information in the High
Rate TIM Rate and Low Rate TIM Rate fields to determine which of the two TIM frames they will be
receiving. The first TIM frame per TIM broadcast interval is scheduled to be transmitted at the TTTT plus
the indicated TIM broadcast offset. The offset may have a negative value that allows the TIM frame(s) to be
transmitted before the TBTT. The value of the offset shall not be changed as long as an associated non-AP
STA is using the TIM broadcast service.
The AP should accept new TIM broadcast interval requests if this implies transmitting TIM frames more
frequently. For instance, if the AP currently transmits TIM frames every fourth beacon period and it receives
a new request for every 3 beacon periods, then the AP should accept the new request and transmit TIM
frames both every 3 and every 4 beacon periods. The AP may override incongruent requests once available
resources (such as counters) have been depleted. An incongruent request is a request that contains an
interval that is not an integer divide or a multiple of a currently active TIM Broadcast interval.
The AP shall accept a TIM broadcast interval of 1.
NOTE—The DTIM Period subfield in a TIM element in a TIM frame indicates the period for DTIM Beacon frames and
is unrelated to any TIM Broadcast Interval(s).
The AP shall increase the value (modulo 256) of the Check Beacon field in the next transmitted TIM
frame(s) when a critical update occurs to any of the elements inside the Beacon frame. The following events
shall classify as a critical update:
a) Inclusion of a Channel Switch Announcement element
b) Inclusion of an Extended Channel Switch Announcement element
1622
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) Modification of the EDCA parameters element
d) Inclusion of a Quiet element
e) Modification of the DSSS Parameter Set
f) Modification of the CF Parameter Set element
g) Modification of the HT Operation element
h) Inclusion of a Wide Bandwidth Channel Switch element
i) Inclusion of a Channel Switch Wrapper element
j) Inclusion of an Operating Mode Notification element
k) Inclusion of a Quiet Channel element
l) Modification of the VHT Operation element
An AP may classify other changes in the Beacon frame as critical updates.
The non-AP STA shall attempt to receive the next Beacon frame when it receives a Check Beacon field that
contains a value that is different from the previously received Check Beacon field.
When dot11MultiBSSIDActivated is true, the bitmap of the TIM element is interpreted as specified in
9.4.2.6.
When dot11MultiBSSIDActivated is true, the A1 field of the TIM frame is the Broadcast address, the A2
field and the A3 field are set to the transmitted BSSID.
11.2.3.18 WNM sleep mode
11.2.3.18.1 WNM sleep mode capability
Implementation of the WNM sleep mode capability is optional for a WNM STA. A STA that implements
WNM sleep mode has dot11WNMSleepModeImplemented equal to true. When
dot11WNMSleepModeImplemented is true, dot11WirelessManagementImplemented shall be true. A STA
where dot11WNMSleepModeActivated is true is defined as a STA that supports WNM sleep mode. A STA
supporting WNM sleep mode shall set the WNM Sleep Mode field of the Extended Capabilities element to
1. When dot11WNMSleepModeActivated is true, dot11TFSActivated shall be true.
A STA in which dot11WNMSleepModeActivated is true may send a WNM Sleep Mode Request or WNM
Sleep Mode Response frame to a STA within the same infrastructure BSS whose last received Extended
Capabilities element contained a value of 1 for the WNM Sleep Mode field in the Extended Capabilities
field. WNM sleep mode is a service that may be provided by an AP to its associated STAs. The WNM sleep
mode is not supported in an IBSS.
WNM sleep mode enables an extended power save mode for non-AP STAs in which a non-AP STA need
not listen for every DTIM Beacon frame, and need not perform GTK/IGTK updates. A non-AP STA can
sleep for extended periods as indicated by the WNM Sleep Interval field of the WNM Sleep Mode element,
which is present in WNM Sleep Mode Request frames transmitted by the non-AP STA.
11.2.3.18.2 WNM sleep mode non-AP STA operation
To use the WNM sleep mode service, the non-AP STA’s SME shall issue an MLME-SLEEPMODE.request
primitive to send a WNM Sleep Mode Request frame. The MLME-SLEEPMODE.request primitive shall
include a valid SleepMode parameter with a WNM Sleep Mode element. The Action Type field in the
WNM Sleep Mode element shall be set to “Enter WNM sleep mode” and the WNM Sleep Interval field shall
be included. The WNM Sleep Interval field shall be less than the BSS max idle period (see 11.24.13). The
1623
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-SLEEPMODE.request primitive shall also include a valid TFSRequest parameter as defined in the
TFS Request element that the AP shall use as triggers to set the STA’s TIM bit.
When a traffic filter for group addressed frames is enabled at the AP, the STA may request a notification
frame (see 11.24.12.2) be sent when requesting the establishment of the traffic filtering agreement.
The receipt of an MLME-SLEEPMODE.confirm primitive with a valid SleepMode parameter indicates to
the STA’s SME that the AP has processed the corresponding WNM Sleep Mode Request frame. The content
of the WNM sleep mode parameter in the WNM Sleep Mode Response frame provides the status of WNM
Sleep Mode elements processed by the AP. The non-AP STA shall delete the GTKSA if the response
indicates success. If RSN is used with management frame protection, the non-AP STA shall delete the
IGTKSA if the response indicates success.
While in WNM sleep mode, the non-AP STA need not wake up every DTIM interval for group addressed
frames.
The STA wakes up at intervals not longer than the value indicated by the WNM Sleep Interval field to check
whether the corresponding TIM bit is set or group addressed traffic is pending. The non-AP STA does not
participate in GTK/IGTK updates.
To exit WNM sleep mode, the non-AP STA’s SME shall issue an MLME-SLEEPMODE.request primitive
to send a WNM Sleep Mode Request frame with an Action Type field in the WNM Sleep Mode element set
to “Exit WNM sleep mode” If a STA receives an unsolicited WNM Sleep Mode Response frame with the
WNM Sleep Mode Response status value (see Table 9-204) equal to 1, the STA exits WNM sleep mode.
11.2.3.18.3 WNM sleep mode AP operation
When an AP’s SME receives an MLME-SLEEPMODE.indication primitive with a valid SleepMode
parameter and an Action Type in the WNM Sleep Mode element of “Enter WNM sleep mode” it shall issue
an MLME-SLEEPMODE.response primitive with SleepMode parameters indicating the status of the
request.The value of the Action Type field of the WNM Sleep Mode element in the WNM Sleep Mode
Response frame shall be set to “Enter WNM sleep mode”.
When WNM sleep mode is enabled for an associated STA, the AP shall stop sending all individually
addressed MPDUs to the non-AP STA. The AP may disassociate or deauthenticate the STA at any time for
any reason while the non-AP STA is in WNM sleep mode. An AP shall perform the TFS AP operation, as
specified in 11.24.12 for non-AP STAs for which it has received TFS Request elements. The AP shall set the
TIM bit corresponding to the AID of the associated STA for which the AP has queued either a TFS Notify
frame or matching frame. An AP shall not perform GTK/IGTK updates for the STAs in WNM sleep mode.
When an AP’s SME receives an MLME-SLEEPMODE.indication primitive with a valid SleepMode
parameter and an Action Type in the WNM Sleep Mode element of “Exit WNM sleep mode” the AP shall
disable WNM sleep mode service for the requesting STA, and the AP’s SME shall issue an MLME-
SLEEPMODE.response primitive with a SleepMode parameter indicating the status of the associated
request. When all traffic filter sets established for a STA are deleted upon frame matches, the AP shall also
disable the WNM sleep mode service and transmit to the STA an unsolicited WNM Sleep Mode Response
frame with the WNM Sleep Mode Response status value (see Table 9-204) set to 1.
If RSN is used with management frame protection and a valid PTK is configured for the STA, the current
GTK and IGTK shall be included in the WNM Sleep Mode Response frame. If a GTK/IGTK update is in
progress, the pending GTK and IGTK shall be included in the WNM Sleep Mode Response frame. If RSN is
used without management frame protection and a valid PTK is configured for the STA, the current GTK
shall be sent to the STA using a group key handshake (see 12.7.7) immediately following the WNM Sleep
Mode Response frame.
1624
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.2.3.19 VHT TXOP power save
A VHT AP supports the operation of non-AP VHT STAs in TXOP power save mode in a BSS when the
dot11VHTTXOPPowerSaveOptionImplemented at the AP is true. Non-AP VHT STAs that are in active
mode and have dot11VHTTXOPPowerSaveOptionImplemented equal to true operate in TXOP power save
mode. A STA that has dot11VHTTXOPPowerSaveOptionImplemented equal to true shall set the TXOP PS
field in the VHT Capabilities element to 1; otherwise, the STA shall set the field to 0. A VHT AP may allow
non-AP VHT STAs in TXOP power save mode to enter the doze state during a TXOP, which the AP does
by transmitting a VHT PPDU with the TXVECTOR parameter TXOP_PS_NOT_ALLOWED set to 0. The
value of this parameter in the TXVECTOR of all VHT PPDUs transmitted by the VHT AP may be changed
from 1 to 0 during the TXOP to enable TXOP power save mode for the remainder of the TXOP. The value
of this parameter in the TXVECTOR of all VHT PPDUs transmitted by VHT AP shall not be changed from
0 to 1 during the TXOP. If the dot11VHTTXOPPowerSaveOptionImplemented at VHT AP is false then the
VHT AP shall set the TXOP_PS_NOT_ALLOWED to 1 in the TXVECTOR of the frames with FORMAT
VHT.
If the AP allows non-AP VHT STAs to enter doze state during a TXOP, then a non-AP VHT STA that is in
TXOP power save mode may enter the doze state until the end of that TXOP when one of the following
conditions is met:
— On receipt of a VHT MU PPDU, the STA determines that it is not a member of the group indicated
by the RXVECTOR parameter GROUP_ID.
— On receipt of an SU PPDU, the STA determines that the RXVECTOR parameter PARTIAL_AID is
not equal to 0 nor does it match the STA’s partial AID.
— The STA finds that the PARTIAL_AID in the RXVECTOR matches its partial AID but the RA in
the MAC header of the corresponding frame that is received correctly does not match the MAC
address of the STA.
— The STA receives a frame with an RXVECTOR parameter NUM_STS equal to 0 if it is a member
of group indicated by RXVECTOR GROUP_ID.
— In a received VHT NDP Announcement frame, the STA finds that the RXVECTOR parameter
PARTIAL_AID is 0 and the AID in the STA Info field is not its AID.
— The STA receives a frame intended for it with the More Data subfield equal to 0 and the Ack Policy
subfield in the QoS Control field is equal to No Ack or sends an acknowledgment if Ack Policy
subfield is not equal to No Ack.
The VHT AP shall include a nav-set sequence (e.g., RTS/CTS) (see G.4 at the beginning of such a TXOP
with the Duration/ID value set to the remainder of the TXOP duration. A VHT AP shall not transmit frames
to a non-AP VHT STA that has been allowed to enter doze state according to the conditions above for the
remainder of the TXOP.
NOTE—A VHT AP does not transmit VHT SU PPDUs in the current TXOP if the AP has already transmitted a VHT
PPDU with the TXVECTOR parameter TXOP_PS_NOT_ALLOWED set to 0 in the same TXOP and does not want the
STAs that are in awake state to enter the doze state.
If a VHT AP truncates the TXOP in which it allowed STAs to enter doze state, then the VHT AP shall not
transmit frames to the STAs that were allowed to enter the doze state until the NAV set at the start of the
TXOP has expired.
Under all of the following conditions:
— an AP transmitted a PPDU;
— the PPDU contains individually addressed frame that contains all or part of an MSDU, A-MSDU or
MMPDU;
— the frame is addressed to a non-AP VHT STA that is in TXOP power save mode;
1625
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— the value of the frame’s More Data subfield is 0;
— the transmitted PPDU’s TXVECTOR parameter TXOP_PS_NOT_ALLOWED is 0;
— the AP did not receive an acknowledgment to this transmission;
then the AP shall retransmit that frame one or more times within the same TXOP, subject to applicable
transmission restrictions. These restrictions include retry and lifetime limits, the TXOP limit and the rules on
TXOP sharing (see 10.22.2.6). If an acknowledgment to the retransmission of this last frame in the same
TXOP is not received, it may wait until the next TXOP to further retransmit that frame, subject to its
applicable retry or lifetime limit.
NOTE—An AP that receives from a VHT STA in TXOP power save mode a BlockAck frame that is a response to an A-
MPDU containing MPDUs with the More Data subfield equal to 0 cannot expect to receive a response to subsequent
MPDUs retransmitted in the same TXOP because the VHT STA might be in the doze state.
A VHT STA that is in TXOP power save mode and has entered doze state shall continue to operate its NAV
during doze state and shall transition into awake state on the expiration of the NAV.
NOTE—The STA can contend for access to the medium immediately on the expiration of the NAV.
11.2.4 Power management in an IBSS
11.2.4.1 Introduction
Subclause 11.2.4 specifies the power management mechanism for use within an IBSS.
11.2.4.2 Basic approach
A STA can be in one of two power management modes:
— Active mode: The STA receives and transmits frames at any time. The STA remains in the awake
state.
— Power save (PS) mode: The STA enters the awake state to receive or transmit frames. The STA
remains in the doze state otherwise.
The basic approach is similar to the infrastructure case in that the STAs are synchronized, and group
addressed BUs and the BUs that are to be transmitted to a power-conserving STA are first announced during
a period when all STAs are awake. The announcement is done via an ATIM frame sent in an ATIM window.
A STA in the PS mode shall listen for these announcements to determine if it needs to remain in the awake
state. The presence of the ATIM window in the IBSS indicates if the STA may use PS mode. To maintain
correct information on the power save state of other IBSS STAs, a STA needs to remain awake during the
ATIM window. At other times the STA may enter the doze state except as indicated in the following
procedures.
When a BU is to be transmitted to a destination STA that is in a PS mode, the transmitting STA first
transmits an ATIM frame during the ATIM window, in which all of the STAs including those operating in a
PS mode are awake. The ATIM window is defined as a specific period of time, defined by the value of the
ATIM Window field in the IBSS Parameter Set supplied to the MLME-START.request primitive, following
a TBTT, during which only Control frames that are RTS, CTS, or Ack frames; Management frames that are
Beacon or ATIM frames; or (QoS) Null frames shall be transmitted. ATIM frame transmission times are
randomized, after a Beacon frame is either transmitted or received by the STA, using the backoff procedure
with the CW equal to aCWmin. Individually addressed ATIM frames shall be acknowledged. If a STA
transmitting an individually addressed ATIM frame does not receive an acknowledgment, the STA shall
execute the backoff procedure for retransmission of the ATIM frame. Group addressed ATIM frames shall
not be acknowledged.
1626
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If a STA receives an individually addressed ATIM frame during the ATIM window, it shall acknowledge
the individually addressed ATIM frame and stay awake to receive the announced BUs for the entire beacon
interval or until it has completed successful transmission to and reception from the source STA of the
received ATIM frame, a frame with the EOSP subfield equal to 1. If a STA does not receive an ATIM frame,
it may enter the doze state at the end of the ATIM window. Transmissions of BUs announced by ATIM
frames are randomized after the ATIM window, using the backoff procedure described in Clause 10.
It is possible that an ATIM frame may be received from more than one STA, and that a STA that receives an
ATIM frame may receive more than a single BU from the transmitting STA. ATIM frames are only
addressed to the destination STA of the BU.
An ATIM frame for a BU shall have a destination address identical to that of the BU.
After the ATIM interval, only individually addressed BUs that have been successfully announced with an
acknowledged ATIM frame and group addressed BUs that have been announced with an ATIM frame shall
be transmitted to STAs in the PS mode. These frames shall be transmitted using the DCF (for non-QoS
STAs) or EDCAF (for QoS STAs).
Figure 11-8 illustrates the basic PS operation.
Figure 11-8—Power management in an IBSS—basic operation
The estimated power-saving state of another STA may be based on the power management information
transmitted by that STA and on additional information available locally, such as a history of failed
transmission attempts. The use of RTS/CTS in an IBSS may reduce the number of transmissions to a STA
that is in PS mode. If an RTS frame is sent and a CTS frame is not received, the transmitting STA may
assume that the destination STA is in PS mode. The method of estimating the power management state of
other STAs in the IBSS is outside the scope of this standard.
1627
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.2.4.3 Initialization of power management within an IBSS
The following procedure shall be used to initialize power management within a new IBSS, or to learn about
the power management being used within an existing IBSS:
a) A STA joining an existing IBSS by the procedure in 11.1.4.4 shall update its ATIM window with the
value contained in the ATIM Window field of the IBSS Parameter Set element within the Beacon or
Probe Response frame received during the scan procedure.
b) A STA creating a new IBSS by the procedure in 11.1.4.4 shall set the value of the ATIM Window
field of the IBSS Parameter Set element within the Beacon frames transmitted to the value of its
ATIM window.
c) The start of the ATIM window shall be the TBTT, defined in 11.1.3.5. The end of the ATIM
window shall be defined as
TSF timer mod dot11BeaconPeriod = ATIMWindow,
where ATIMWindow is the value of the ATIM Window field of the IBSS Parameter Set from the
MLME-START.request or MLME-JOIN.request primitives.
d) The ATIM window period shall be static during the lifetime of the IBSS.
e) An ATIM window value of 0 shall indicate that power management is not usable within the IBSS.
11.2.4.4 STA power state transitions
A STA may enter PS mode if the value of the ATIM window in use within the IBSS is greater than 0. A STA
shall not enter PS mode if the value of the ATIM window in use within the IBSS is equal to 0.
A STA shall indicate its power management mode in the Power Management subfield of the Frame Control
field of frames containing all or part of a BU or individually addressed Probe Request frame, or (QoS) Null
frames, that it transmits.
A STA in PS mode shall transition between awake state and doze state according to the following rules:
a) If a STA is operating in PS mode, it shall enter the awake state prior to each TBTT.
b) If a STA receives a group addressed ATIM frame during the ATIM window, the STA shall remain
in the awake state until either the STA receives a group addressed frame from the source STA with
the EOSP subfield equal to 1 or the end of the next ATIM window, whichever occurs first.
c) If a STA receives at least one individually addressed ATIM frame containing the STA’s individual
address in the RA field during the ATIM window then the STA shall remain in the awake state at
least until the earlier of the completion of the successful transmission to and reception from the
source STA of each received ATIM frame, a frame with the EOSP subfield equal to 1, and the end of
the next ATIM window.
d) If a STA transmits at least one individually addressed ATIM frame containing a STA’s individual
address in the RA field during the ATIM window then the STA shall remain in the awake state at
least until the earlier of the completion of the successful transmission to and reception from the
destination STA of each transmitted ATIM frame, a frame with the EOSP subfield equal to 1, and
the end of the next ATIM window.
e) If a STA transmits a Beacon, the STA shall remain in the awake state until the end of the next ATIM
window.
f) If the STA has not transmitted an ATIM frame and does not receive either an individually addressed
ATIM frame containing the STA’s individual address, or a group addressed ATIM frame during the
ATIM window, the STA may return to the doze state following the end of the current ATIM
window.
1628
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.2.5 Power management in an MBSS
Power management in an MBSS is described in 14.14.
11.2.6 SM power save
A STA consumes power on all active receive chains, even though they are not necessarily required for the
actual frame exchange. The SM power save feature allows a non-AP HT STA in an infrastructure BSS to
operate with only one active receive chain for a significant portion of time.
The STA controls which receive chains are active through the PHY-RXCONFIG.request primitive
specifying a PHYCONFIG_VECTOR parameter ACTIVE_RXCHAIN_SET that indicates which of its
receive chains should be active.
In dynamic SM power save mode, the STA enables its multiple receive chains when it receives the start of a
frame exchange sequence addressed to it. Such a frame exchange sequence shall start with a single-spatial
stream individually addressed frame that requires an immediate response and that is addressed to the STA in
dynamic SM power save mode. An RTS/CTS sequence may be used for this purpose. The STA shall,
subject to its spatial stream capabilities (see 9.4.2.56.4 and 9.4.2.158.3) and operating mode (see 11.42), be
capable of receiving a PPDU that is sent using more than one spatial stream a SIFS after the end of its
response frame transmission. The STA switches to the multiple receive chain mode when it receives the
frame addressed to it and switches back immediately when the frame exchange sequence ends.
NOTE—A STA in dynamic SM power save mode cannot distinguish between an RTS/CTS sequence that precedes a
MIMO transmission and any other RTS/CTS and, therefore, always enables its multiple receive chains when it receives
the RTS addressed to it.
The STA can determine the end of the frame exchange sequence through any of the following:
— It receives an individually addressed frame addressed to another STA.
— It receives a frame with a TA that differs from the TA of the frame that started the TXOP.
— The CS mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot boundary
(defined in 10.3.7).
In static SM power save mode, the STA maintains only a single receive chain active.
The STA may use the SM Power Save frame to communicate its SM power save state. The STA may also
use SM Power Save subfield in the HT Capabilities element of its (Re)Association Request frame to achieve
the same purpose. The latter allows the STA to use only a single receive chain immediately after
(re)association.
A STA that has one or more DLS or TDLS links shall not operate in SM power save mode.
Changes to the number of active receive chains are made only after the SM power save mode indication has
been successfully delivered (i.e., by acknowledgment of a frame carrying the HT Capabilities element or by
acknowledgment of a SM Power Save frame). The SM power save mode indication shall be transmitted
using an individually addressed frame.
1629
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.2.7 Power management in a PBSS and DMG infrastructure BSS
11.2.7.1 General
Power save mechanisms in this subclause enable non-AP STAs to sleep for one or more beacon intervals or
for parts of a beacon interval.
The non-AP and non-PCP STA power save mechanisms defined in 11.2.7.2 enable a non-AP and non-PCP
STA to sleep after signaling the AP or PCP, or to sleep according to a periodic schedule that is negotiated
with the AP or PCP. A non-AP and non-PCP STA may use both mechanisms in conjunction to increase its
power save opportunity.
Similarly, the PCP power save mechanisms defined in 11.2.7.3 enable a PCP to sleep after signaling at least
one non-AP and non-PCP STA, or to sleep according to a wakeup schedule that is available to all STAs
associated with the PCP.
A non-AP STA can be in one of two power management modes:
— Active mode: The STA does not use any of the scheduled or unscheduled power save mechanisms
defined in this subclause and operates in the awake state, except during time intervals that it
determines it is not the target of any transmission by other STAs, where it may operate in doze state.
— Power save (PS) mode: The STA uses at least one of the scheduled or unscheduled power save
mechanisms defined in this subclause and switches between awake and the doze states.
A non-AP STA shall be in active mode upon (re)association.
For scheduled power save, the DMG Wakeup Schedule element (9.4.2.131) is used to communicate the
sleep and wakeup pattern of a DMG STA, referred to as the STA wakeup schedule (WS). A STA wakeup
schedule defines a periodic routine of cycling between a set of contiguous beacon intervals referred to as
awake BIs and a set of contiguous beacon intervals referred to as doze BIs. The rules for alternating between
awake and doze power states during awake BIs and doze BIs are defined in 11.2.7.2.3 and 11.2.7.3.3. An
overview of these rules is given in Table 11-2 and Table 11-3.
A STA in PS mode that is following a wakeup schedule and has also exercised unscheduled power save shall
follow the doze BI rules in this subclause and shall follow the ATIM rules in 11.2.7.4 for a non-AP STA
without wakeup schedule.
An AP or PCP keeps track of the wakeup schedules of all associated non-AP and non-PCP STAs. A non-AP
and non-PCP STA keeps track of the wakeup schedule of all associated non-AP and non-PCP STAs that it is
communicating with. There is no end time to a wakeup schedule. Once a STA enters PS mode according to
its wakeup schedule it stays indefinitely in PS mode until it leaves the PS mode through mechanisms defined
in this subclause. Once a STA is made aware of the wakeup schedule of another STA, it is able to keep track
of the wakeup schedule on its own. Each STA delivers traffic to a peer STA only when the peer STA is in
awake state.
A STA that has transmitted a frame to an AP or PCP with which it is not associated and from which it
expects a response shall remain in the awake state until such a response is received or until the procedure has
timed out.
An AP shall buffer BUs addressed to non-AP STAs in doze state. The buffered BUs shall be transmitted
only at designated times (11.2.7.2). A non-AP STA shall defer delivery of BUs addressed to other non-AP
STAs in doze state. The BUs shall be transmitted only at designated times (11.2.7.2).
1630
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If a PCP sets the BSS Type field within a transmitted DMG Beacon frame to PBSS or the AP or PCP
includes a Nontransmitted BSSID Capability element in a transmitted DMG Beacon, Announce, or Probe
Response frames and the BSS Type field within the Nontransmitted BSSID Capability element is equal to
PBSS, then the AP or PCP shall follow the PCP power management rules described in 11.2.7.3 if the AP or
PCP chooses to employ power management.
An AP or PCP may include an Antenna Sector ID Pattern element in Power Save Configuration Response
and Probe Response frames transmitted to a non-AP and non-PCP STA. If a non-AP and non-PCP STA uses
the information contained in the Antenna Sector ID Pattern element received from its AP or PCP, then
during the BTI of an awake BI, the STA might stay awake just to receive DMG Beacon frames transmitted
through specific DMG antenna and sector and switch to doze state during other periods in the BTI.
Table 11-2 lists the power states for a non-AP and non-PCP STA in PS mode and a PCP in PS mode during
an awake BI. Each entry indicates the state, either awake or doze, for the non-AP and non-PCP STA or the
PCP in PS mode at various times during the awake BI.
Table 11-2—Power states for an awake BI
PS non-AP and
Portion of the beacon interval PPS PCP
non-PCP STA
BHI BTI Awake Awake or doze
A-BFT Awake Awake or doze
ATI Awake Awake
DTI CBAP with the PCP Active field set to 1 in the schedule Awake or doze Awake or doze
CBAP with the PCP Active field set to 0 in the schedule Doze Awake or doze
SP with Destination AID set to broadcast AID Awake Awake
Nontruncatable or nonextensible SP with non-PCP STA as Awake or doze Awake or doze
Source AID or Destination AID
Truncatable SP or extensible SP with non-AP and non-PCP Awake Awake or doze
STA (excluding the PS STA) as Source AID or Destination
AID
SPs allocated to itself Awake or doze Awake or doze
All other SPs Awake or doze Awake or doze
Awake window Awake Awake
DTI with CBAP Only subfield set to 1 Awake or doze Awake or doze
Destination AID field of a CBAP equal to the broadcast AID Awake or doze Awake or doze
in the schedule
Table 11-3 lists the power states for a non-AP and non-PCP STA in PS mode and a PCP in PS mode during
a doze BI. Each entry indicates the state, either awake or doze, for the non-AP and non-PCP STA or the PCP
in PS mode at various times during the doze BI.
1631
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-3—Power states for a doze BI
PS non-AP and
Portion of the beacon interval PPS PCP
non-PCP STA
BHI BTI N/A Awake or doze
A-BFT N/A Awake or doze
ATI Awake Awake
DTI CBAP with the PCP Active field set to 1 in the schedule Doze Doze
CBAP with the PCP Active field set to 0 in the schedule Doze Doze
SP with Destination AID set to broadcast AID Doze Doze
SP with individually addressed destination AID Doze Awake
Nontruncatable or nonextensible SP with non-PCP STA as Doze Doze
Source AID or Destination AID
Truncatable SP or extensible SP with non-AP and non-PCP Doze Doze
STA (excluding the PS STA) as Source AID or Destination
AID
SPs allocated to itself Doze Doze
All other SPs Doze Doze
DTI with CBAP Only subfield set to 1 Doze Doze
Destination AID field of a CBAP equal to the broadcast AID Doze Doze
in the schedule
The source DMG STA and the destination DMG STA of a nontruncatable SP or allocated CBAP with
individually addressed destination AID may go to doze state within the SP or within the CBAP, respectively,
after the source DMG STA transmitted a frame to the destination DMG STA of the SP or the CBAP,
respectively, with the EOSP subfield set to 1 and received the following response frame from the destination
DMG STA of the SP or the CBAP, respectively.
If the MM-SME Power Mode field within the MMS element sent by an MM-SME coordinated STA is 1, all
STAs advertised in the MMS element shall switch to the doze state when the wakeup schedule of any one
STA or a successful frame exchange as described in Annex G brings the STA to the doze state.
If the MM-SME Power Mode field within the MMS element sent by an MM-SME coordinated STA is 0, all
STAs advertised in the MMS element shall switch to the awake state when the wakeup schedule of any one
STA or a successful frame exchange as described in Annex G brings the STA to the awake state.
11.2.7.2 Non-AP and non-PCP STA power management mode
11.2.7.2.1 General
The power management mode of a non-AP and non-PCP STA is selected by the PowerManagementMode
parameter of the MLME-POWERMGT.request primitive. Once the STA updates its power management
mode, the MLME shall issue an MLME-POWERMGT.confirm primitive indicating the result of the
operation. While the STA is in PS mode it may exercise the unscheduled and scheduled power save
mechanisms described in this subclause.
1632
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 11-9 illustrates a finite state machine that shows the state transition of a STA in active and PS mode,
and also the transition between active and PS modes when the non-AP and non-PCP STA has set up a
wakeup schedule.
NOTE—In Figure 11-9, the notations PSC-REQ(X) and PSC-RSP(Y) indicate that the PSC-REQ and PSC-RSP frames,
respectively, are transmitted with the setting as indicated by their corresponding X and Y parameters. The transitions
shown “As per T1” are defined in Table 11-2. The transitions shown “As per T2” are defined in Table 11-3.
As per STA
o p e r a t io n
P S C ‐R E Q (D P M = 1 , W S ) S c h e d u le d a n d w it h o u t a
& & P S C ‐ R S P (R e je c t , A c t iv e S c h e d u le d U n s c h e d u le d
U n s c h e d u le d P S w akeu p
W S_new ) m ode P S C ‐ R E Q (D P M = 1 ,W S ) PS m ode PS m ode
m ode s c h e d u le
& & P S C ‐R S P
As per W S
e le m e n t
U n s c h e d u le d
A w ake BI D oze BI
PS m ode BI
As per W S
e le m e n t As per
A T IM fr a m e u s a g e fo r
As per T1 pow er m anagem ent of
L o c a l d e c is io n As per T2
n o n ‐A P S T A s
A w ake D oze
Aw ake D oze pow er pow er A w ake D oze A w ake D oze
pow er pow er sta te sta te pow er pow er pow er pow er
sta te sta te sta te sta te sta te sta te
As per T1 As per T2 As per
L o c a l d e c is io n
A T IM f r a m e u s a g e
fo r p o w e r
m anagem ent of
n o n ‐A P S T A s
Figure 11-9—State transition diagram of non-AP and non-PCP STA in active and
PS modes
11.2.7.2.2 Non-AP and non-PCP STA operation without a wakeup schedule
To change its power state without a wakeup schedule, a non-AP and non-PCP STA shall inform the AP or
PCP by completing a successful frame exchange (as described in Annex G) that is initiated by the STA and
that includes a Management frame, Extension frame or Data frame, and also an Ack or a BlockAck frame
from the AP or PCP. The Power Management subfield(s) in the Frame Control field of the frame(s) sent by
the STA in this exchange that contain a BU or are QoS Null frame indicate the power state that the STA
shall adopt upon successful completion of the entire frame exchange. A non-AP and non-PCP STA shall not
change its power state using a frame exchange that does not receive an Ack or BlockAck frame from the AP
or PCP, or using a BlockAckReq frame.
A non-AP and non-PCP STA in doze state shall limit the frames it transmits to the following:
— A Management, Extension or Data frame that triggers an Ack or a BlockAck frame from the AP or
PCP, with the Power Management subfield in the Frame Control field of the frame set to 0, i.e., a
frame to indicate the STA intent to transition out of unscheduled PS mode.
— A Management, Extension or Data frame that triggers an Ack or a BlockAck frame from the AP or
PCP, plus Ack and Block Ack frames that respond to the frames sent by the AP or PCP during the
reverse direction grant, if the following conditions apply:
— the Power Management subfield in the Frame Control field of the frame sent by the non-AP
and non-PCP STA is set to 1
1633
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— the AP or PCP has transmitted a Capability Information field in which the Triggered
Unscheduled PS subfield is equal to 1
— An RTS, DMG CTS-to-self, CF-End, Grant, BRP, SSW or SSW-Feedback frame.
NOTE—A DMG STA in doze state may need to perform beamforming to restore its links with other DMG STAs.
As long as there is at least one STA that has entered doze state through the unscheduled power save
mechanism, the AP or PCP shall establish an awake window by transmitting an Awake Window element,
and shall include a UPSIM element in every DMG Beacon and Announce frame it transmits. The AP or PCP
may establish an awake window and/or include a UPSIM element in a DMG Beacon or Announce frame it
transmits even if no STA is in doze state. The absence of a UPSIM element in a DMG Beacon or Announce
frame is equivalent to presence of the UPSIM element in the frame with all bits of the Power Save Indication
Bitmap field in the UPSIM element set to 0. The UPSIM element in every DMG Beacon or Announce frame
transmitted by the AP or PCP shall indicate the power state of all STAs at the time of frame transmission.
NOTE—Transmitting a DMG Beacon frame with the Discovery Mode subfield set to 0, or an Announce frame, without
including the UPSIM element in the frame, indicates that no STA is in unscheduled PS mode at the time of the frame
transmission.
A non-AP and non-PCP STA may also indicate its power state to another non-AP and non-PCP STA
through the Power Management subfield in the Frame Control field of any frame that contains all or part of
a BU. The non-AP and non-PCP STA shall indicate its correct power state in the Frame Control field of any
frame it transmits that contains all or part of a BU.
When a non-AP and non-PCP STA that has not set up a wakeup schedule with the AP or PCP enters PS
mode, every beacon interval shall be an awake BI for that STA. A non-AP and non-PCP STA that has not set
up a wakeup schedule with the AP or PCP and that is in PS mode shall be awake during any allocated SP for
which the STA is either the source DMG STA or destination DMG STA during an awake BI. During an
awake BI, a non-AP and non-PCP STA that has not set up a wakeup schedule with the AP or PCP and that is
in PS mode shall be awake during any allocated CBAP for which the STA is the source DMG STA or
destination DMG STA, or the source AID of the CBAP is equal to the broadcast AID or the destination AID
of the CBAP is equal to the broadcast AID.
A non-PCP and non-AP STA that has used unscheduled power save to enter doze state may offer an RDG to
its AP or PCP if the following conditions apply:
— the AP or PCP has transmitted a Capability Information field in which the Triggered Unscheduled
PS field is equal to 1
— the non-AP and non-PCP has transmitted a Capability Information field in which the Reverse
Direction subfield is equal to 1
The AP or the PCP may use the offered RDG to transmit one or more BUs to the non-PCP and non-AP STA
using the reverse direction protocol defined in 10.28.
The non-PCP and non-AP STA should continue to offer an RDG to the AP or to the PCP within the current
TXOP while the Buffered AC subfield of the QoS Control field in frames transmitted by the AP or by the
PCP indicates that one or more BUs are buffered for the AC for which the TXOP was gained.
11.2.7.2.3 Non-AP and non-PCP STA operation with a wakeup schedule
To transition from active mode to PS mode, a non-AP and non-PCP STA that is associated with an AP or
PCP shall establish a wakeup schedule (WS) with the AP or PCP. A WS is established with the AP or PCP
following the successful transmission of a PSC-REQ frame to the AP or PCP with the DPM field set to 1 and
an acknowledged receipt of the corresponding PSC-RSP frame from the AP or PCP provided that the PSC-
RSP frame contained a status code indicating success. After receiving a PSC-RSP frame from the AP or
PCP with a status code indicating success and responding with an acknowledgment, the STA switches to the
1634
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PS mode at the instant specified by the BI Start Time field of the DMG Wakeup Schedule element
transmitted to the AP or PCP. In PS mode, the STA shall cycle between awake BIs and doze BIs following
the WS that the STA has established with the AP or PCP.
As long as there is at least one STA that is in PS mode, the AP or PCP shall establish an awake window. The
AP or PCP may include an Awake Window element in a DMG Beacon or Announce frame it transmits even
if no STA in the BSS has entered PS mode.
A DMG Wakeup Schedule element shall be included in any PSC-REQ frame that the STA transmits to the
AP or PCP as an explicit request for a WS. An Awake Window element may also be included in the same
PSC-REQ frame to indicate a requested duration for the awake window. If the AP or PCP accepts the
proposed WS and the optionally present awake window duration in the PSC-REQ frame, it shall reply with a
PSC-RSP frame indicating a status code of SUCCESS. Otherwise, it shall respond with a PSC-RSP frame
with a status code indicating the reason for rejecting the request. The AP or PCP may suggest an alternative
WS and optionally an awake window duration in the PSC-RSP frame and set the status code to
REJECT_WITH_SCHEDULE. If the STA accepts the alternative WS, it shall include this WS in a
subsequently transmitted PSC-REQ frame. If the non-AP and non-PCP STA does not accept the alternative
WS, it shall not send a PSC-REQ frame for dot11PSRequestSuspensionInterval beacon intervals following
the receipt of the PSC-RSP frame from the AP or PCP.
NOTE 1—The AP or PCP can recommend an alternative WS, for example to align the awake BIs of some or all non-AP
and non-PCP STAs.
NOTE 2—The awake window duration sent by the AP or PCP in a PSC-RSP frame is to assist the STA for awake
window planning. The awake window duration is always set by the Awake Window element in the most recent DMG
Beacon or Announce frame received from the AP or PCP.
If a non-AP and non-PCP STA has established a WS with the AP or PCP and the non-AP and non-PCP STA
is in PS mode, the non-AP and non-PCP STA shall have m successive awake BIs repeating every n beacon
interval, where n is the value of the Sleep Cycle field of the DMG Wakeup Schedule element contained in
the PSC-RSP frame received from the AP or PCP during the frame exchange that established the WS, and m
is the value of the Number of Awake BIs field in the DMG Wakeup Schedule element contained in that
PSC-RSP frame. During each of its awake BIs, the non-AP and non-PCP STA shall be awake during the
awake window if it is present, and during all allocated SPs in which it is either the source or destination
DMG STA.
An AP or PCP may send an unsolicited PSC-RSP frame without a WS and indicating a status code of
success to a non-AP and non-PCP STA in PS mode. Upon receiving the unsolicited PSC-RSP frame
meeting these conditions, the non-AP and non-PCP STA shall switch to active mode.
11.2.7.2.4 Non-AP and non-PCP STA operation with or without a wakeup schedule
A non-AP and non-PCP STA in PS mode shall stay awake for dot11MinBHIDuration starting from the
beginning of each awake BI and may switch to the doze state after the expiration of this time. The only
exception is when the Power Save Configuration Response or Probe Response frame received from the AP
or PCP includes an Antenna Sector ID Pattern element, in which case the non-AP and non-PCP STA may
use the Antenna Sector ID Pattern element to receive DMG Beacon frames transmitted through a specific
DMG antenna and sector, and may switch to doze state during other periods in the BTI.
An AP or PCP shall transmit SP allocation announcements for STAs in PS mode during each of the STAs’
awake BIs and may transmit those SP allocation announcements in other beacon intervals. New SPs shall be
allocated to begin either within or after the later awake BI of the source DMG STA and destination DMG
STA of the SP.
To transition from PS mode to active mode, a non-AP and non-PCP STA that has an established WS with
the AP or PCP shall send a PSC-REQ frame with the DPM field set to 0 to the AP or PCP and enter active
1635
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
mode following the reception of the Ack frame response. The AP or PCP shall not send a PSC-RSP frame if
the DPM field is 0 in the PSC-REQ frame.
In order for a STA to learn the WS of another STA within the BSS, the STA may send an Information
Request frame to the other STA or to the AP or PCP as defined in 11.30.1. The AP or PCP maintains a WS
distribution table for the lifetime of the BSS, and upon receiving an Information Request frame that contains
a request for the WS of a STA identified by the Subject Address field within the frame, shall add an entry to
the WS distribution table made up of the STA that transmitted the Information Request frame (the
requesting STA) and the STA identified by the Subject Address field within the Information Request frame
(the target STA). If the AP or PCP moves the TBTT, changes the duration of the beacon interval, or resets
the TSF, the AP or PCP shall transmit an unsolicited Information Response frame with the updated DMG
Wakeup Schedule element. When transmitting the DMG Wakeup Schedule element for a STA that is in PS
mode, the transmitting STA shall use a value for the BI Start Time field that points to a TBTT that is earlier,
but not more than 231 µs minus aDMGDWSValidPeriod earlier, than the TBTT of the beacon interval
during which the BI Start Time field is transmitted, so that the receiving STA can correctly identify the
power management mode of the STA the WS belongs to.
If the Information Request frame is transmitted to the AP or PCP and the STA indicated in the Information
Request’s Subject Address field does not have an established WS with the AP or PCP, the AP or PCP shall
set the length of the DMG Wakeup Schedule element to 0 in the Information Response frame.
11.2.7.3 PCP power management mode
11.2.7.3.1 General
The power management mode of a PCP is selected by the PowerManagementMode parameter of the
MLME-POWERMGT.request primitive. Once the PCP updates its power management mode, the MLME
shall issue an MLME-POWERMGT.confirm primitive indicating the result of the operation. While the PCP
is in PS mode it may exercise the unscheduled and scheduled power save mechanisms described in this
subclause.
11.2.7.3.2 PCP operation without a wakeup schedule
To change its power state without a wakeup schedule, the PCP shall include a UPSIM element in or remove
the UPSIM element from every DMG Beacon frame with the Discovery Mode subfield set to 0 and
Announce frame that it transmits, and shall indicate its new power state in the UPSIM element if it is
included in the frame
NOTE—The UPSIM element in a DMG Beacon frame with the Discovery Mode subfield set to 0, or in an Announce
frame, includes the power state of the PCP at the time of the frame transmission. Transmitting a DMG Beacon frame
with the Discovery Mode subfield set to 0 or an Announce frame, without including the UPSIM element in the frame,
indicates that no STA (including the PCP) is in unscheduled PS mode at the time of the frame transmission.
Alternatively, to change its power state without a wakeup schedule, the PCP shall inform all associated
STAs by completing a successful frame exchange (as described in Annex G) that is initiated by the PCP and
that includes a Management frame, Extension frame or Data frame, and also an Ack or a BlockAck frame
from the associated STA. The Power Management subfield(s) in the Frame Control field of the frame(s) sent
by the PCP in this exchange that contain a BU or are QoS Null frame indicate the power state that the PCP
shall adopt upon successful completion of the entire frame exchange. The PCP shall not change its power
state using a frame exchange that does not receive an Ack or BlockAck frame from the associated STA, or
using a BlockAckReq frame.
When attempting to enter doze state, the PCP shall not enter doze state unless it has received an Ack or
BlockAck from each associated STA. When attempting to leave doze state, the PCP shall enter awake state
as soon as it receives an Ack or BlockAck from one associated STA.
1636
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A PCP in doze state shall limit the frames it transmits to the following:
— A Management, Extension or Data frame that triggers an Ack or a BlockAck frame from a non-AP
and non-PCP STA, with the Power Management subfield in the Frame Control field of the frame set
to 0, i.e., a frame to indicate the PCP intent to transition out of unscheduled PS mode.
— A Management, Extension or Data frame that triggers an Ack or a BlockAck frame from a non-AP
and non-PCP STA, plus Ack and BlockAck frames that respond to the frames sent by the non-
AP and non-PCP STA during the reverse direction grant, if the following conditions apply:
— the Power Management subfield in the Frame Control field of the frame sent by the PCP is set
to 1
— the non-AP and non-PCP STA has transmitted a Capability Information field in which the
Triggered Unscheduled PS subfield is equal to 1
— An RTS, DMG CTS-to-self, CF-End, Grant, BRP, SSW or SSW-Feedback frame.
NOTE—A DMG STA in doze state may need to perform beamforming to restore its links with other DMG STAs.
The PCP shall indicate the correct power state in the Frame Control field of any frame it transmits to an
associated STA that contains all or part of a BU.
11.2.7.3.3 PCP operation with a wakeup schedule
A PCP in PPS mode (PPS PCP) may enter the doze state for one or more consecutive beacon intervals in
order to minimize its energy consumption. Figure 11-10 illustrates a finite state machine that shows the state
transition of the PCP power management mode.
NOTE—Figure 11-10 uses the following terminology: “As per T1” means that the transitions are specified in
Table 11-2, “As per T2” means that the transitions are specified in Table 11-3.
As per STA
operation
Scheduled and without a
Active Scheduled Unscheduled
DMG Wakeup Schedule Unscheduled PS wakeup
mode PS mode PS mode
element in DMG Beacon or mode schedule
Announce frames
As per WS
element
Unscheduled
Awake BI Doze BI
PS mode BI
As per WS
element As per
ATIM frame usage for
As per T1 power management of
As per T2
non‐AP STAs
Awake Doze
power power Awake Doze Awake Doze
state state power power power power
state state state state
As per T1 As per T2 As per
ATIM frame usage
for power
management of
non‐AP STAs
Figure 11-10—State transition diagram of PCP power management mode
1637
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
To enter PPS mode, or to modify an established WS, the PCP announces a WS through a DMG Wakeup
Schedule element (9.4.2.131) included in a DMG Beacon, Announce, or any Action frame.
The PCP can assume that all associated STAs have received a WS and the Awake Window element that can
optionally be transmitted with the WS at the earlier of the following events:
— The PCP has transmitted the DMG Wakeup Schedule element in DMG Beacon or Announce frames
for at least dot11MaxLostBeacons successive beacon intervals.
— The PCP has confirmed that each associated STA has received the DMG Wakeup Schedule element
by receiving an ACK or a response frame from each associated STA in response to a request frame
that includes the DMG Wakeup Schedule element.
The first PCP Awake BI of a sleep cycle in a WS starts at the instant specified by the value of the BI Start
Time field of the announced DMG Wakeup Schedule element, and the number of successive PCP Awake
BIs is specified by the Number of Awake BIs field of the DMG Wakeup Schedule element.Once in PPS
mode, the PCP transitions between awake BI and doze BI according to the WS it has established.
NOTE—The PCP may need to behave as it is in active mode or in an awake BI to some associated STAs for a number of
planned successive PCP doze BIs if it has not been able to confirm the reception of its WS by each associated STA, and
it has not transmitted its WS through DMG Beacon or Announce frames over dot11MaxLostBeacons successive beacon
intervals.
In order to transition from PPS mode to active mode, the PCP stops including the DMG Wakeup Schedule
element in DMG Beacon and Announce frames. A DMG STA that has received a PCP WS shall assume the
PCP WS is in effect until it either receives a DMG Beacon or Announce frame that does not include a DMG
Wakeup Schedule element or receives a different PCP WS.
In a PCP doze BI, the PCP should schedule a BTI or ATI. If scheduling an ATI, the PCP should transmit an
Announce frame during the ATI to associated STAs.
NOTE—The PCP provides the PBSS timing synchronization function (TSF). Transmitting frequent TSF information
through DMG Beacon or Announce frames is important when there are non-PCP STAs in the PBSS that rely on TSF
information to communicate directly with each other.
The PCP may include in the Extended Schedule element the schedule for the beacon intervals during the
PCP doze BIs. The PCP may schedule a SP or CBAP within a doze BI by setting the Allocation Start field of
the new SP or CBAP in the Extended Schedule element to a value within a doze BI. If the Extended
Schedule element is transmitted, the PCP shall transmit it at least dot11MaxLostBeacons times before the
PPS PCP enters the doze state.
The PCP shall check that the schedule of pseudo-static allocations transmitted in the last Extended Schedule
element before the PCP entered PPS mode is valid during the PCP doze BIs. Thus, a STA participating in
such a pseudo-static allocation assumes that the allocation is present during the following consecutive PCP
doze BIs.
The PCP may enter and remain in the doze state for any portion of an SP if it is not a source or a destination
of the SP. The PCP shall remain in the awake state for any portion of a truncatable or extendable SP
(9.4.2.132). The availability of the PCP during a CBAP in the awake BI shall be announced by setting the
PCP Active subfield within the Allocation Control field to 1 for a CBAP allocation made through the
Extended Schedule element.
NOTE—A PCP that indicates availability during a CBAP that includes an awake window can exchange ATIM frames
with non-AP and non-PCP STAs during the awake window and possibly enter the doze state for the remainder of the
CBAP outside the awake window (see 11.2.7.4).
Figure 11-11 shows an example of the basic operation of a PCP in PPS mode when the PCP sleep interval
equals one beacon interval (i.e., PCP sleeps every other beacon interval) and the PCP sleep interval starts
1638
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
right after the first beacon interval. In this example, the first beacon interval and the second beacon interval
have the same schedule, but the third beacon interval and the fourth beacon interval have different
schedules. The first beacon interval is the awake BI in which the PPS PCP is in the awake state to serve non-
PCP STAs. In the first beacon interval, the PCP transmits the Extended Schedule element for the current
beacon interval with the pseudo-static subfield set to 1 for all allocations within the Extended Schedule
element to indicate that the schedule of the first beacon interval also applies to the second beacon interval. In
addition, the PCP transmits the DMG Wakeup Schedule element with the information of the start time and
the length of the PCP sleep interval, and the STA Availability element to indicate the availability of the PCP
for the CBAP of the awake BI. Following the CBAP of the first beacon interval, the PCP enters the doze
state and sleeps for more than one beacon interval. The PCP switches from the doze state to the awake state
after sleeping through the remainder of the first beacon interval and through the entire second beacon
interval, which is the start of the third beacon interval in Figure 11-11. Since in this example the schedule of
the third beacon interval and the fourth beacon interval are different, the PCP transmits the Extended
Schedule element containing the individual allocations for the third beacon interval and fourth beacon
interval. The PCP enters the doze state after it completes all exchanges in the third beacon interval and
wakes up at the start of the fifth beacon interval.
Beacon or Announce Applied to both Beacon or Announce Applied to both
beacon intervals beacon intervals
Extended Schedule element Extended Schedule element
DMG Wakeup Schedule element DMG Wakeup Schedule element
STA Availability element STA Availability element
SP CBAP SP CBAP SP CBAP SP CBAP
PCP doze interval PCP doze interval
Awake BI = 1 beacon interval Awake BI = 1 beacon interval
PCP AWAKE PCP DOZE PCP AWAKE PCP DOZE
Figure 11-11—Example operation of PPS mode
11.2.7.4 ATIM frame usage for power management of non-AP STAs
An awake window is present within the first CBAP of a beacon interval that is scheduled through the
Extended Schedule element and has the Source AID and Destination AID fields in that Extended Schedule
element equal to the broadcast AID, or in a CBAP that is scheduled through the CBAP Only field in the
DMG Parameters field (9.4.1.47) set to 1, for dot11MaxLostBeacons beacon intervals following the most
recent transmission of the Awake Window element (9.4.2.137) by the AP or PCP with the Awake Window
Duration field set to a nonzero value.
NOTE—Transmission rules during the awake window are the same as the transmission rules for the CBAP that the
awake window belongs to.
A non-AP and non-PCP STA delivers the Awake Window element to an AP or PCP as defined in 11.2.7.2.3.
An AP or PCP delivers the Awake Window element to a non-AP and a non-PCP STA as defined 11.2.7.3.
If present, the awake window starts from the beginning of a CBAP and has a duration that is defined by the
value of the Awake Window Duration field in the Awake Window element or the CBAP duration,
whichever is smaller. During the awake window, a STA shall transmit only ATIM frames. A DMG STA in
PS mode shall be in the awake state during each awake window that lies within each awake BI for that STA.
BUs that are to be transmitted to a STA that is in PS mode are first announced through ATIM frames during
the awake window. A STA in PS mode that is awake during an awake window shall listen for these
announcements to determine if it needs to change its power state. If during the awake window the STA does
not receive or transmit an ATIM frame with BSSID equal to the BSSID of the BSS of the STA is a member,
1639
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
then it may enter the doze state at the end of the awake window. If a STA receives an ATIM frame during
the awake window, it shall acknowledge the ATIM frame. Any two STAs that successfully complete an
ATIM frame exchange with each other during the awake window become peer STAs.
A STA that is in PS mode and following a wakeup schedule and has not performed unscheduled power save
to enter doze state and receives an ATIM frame during the awake window shall be awake during allocations
within the current beacon interval that have the Source AID equal to broadcast AID or have a Source AID
that identifies a STA whose MAC address is equal to the TA field of the received ATIM frame, or during
any DTI that is scheduled through the CBAP Only field in the DMG Parameters field (9.4.1.47) set to 1. If a
STA transmits an ATIM frame during the awake window, it shall attempt to deliver its BUs during
allocations within the current beacon interval that have a Destination AID equal to broadcast AID or have a
Destination AID that identifies a STA whose MAC address is equal to the RA field of the transmitted ATIM
frame, or during any DTI that is scheduled through the CBAP Only field in the DMG Parameters field
(9.4.1.47) set to 1. A STA that receives or transmits an ATIM frame during the awake window may enter the
doze state when it has successfully transmitted to and received from all corresponding peer STAs for this
beacon interval a QoS Data frame with the EOSP subfield set to 1; otherwise it shall stay active until the end
of the current beacon interval. ATIM frame transmissions and MSDU transmissions follow the rules defined
in 11.2.8.
NOTE—A STA that has performed unscheduled power save to enter doze state and receives an ATIM frame during an
awake window can use the unscheduled power save mechanism to leave doze state following the procedure in
11.2.7.2.2or 11.2.7.3.2.
Figure 11-12 illustrates an example of a DMG STA response to an ATIM frame. For illustration purposes
the 5 beacon intervals shown in the figure are numbered from 0 to 4. The PCP is following a wakeup
schedule, with 1 awake BI out of every 4 beacon intervals. The non-PCP STA A is also following a wakeup
schedule, with 1 awake BI out of every 2 beacon intervals. In addition, STA A performs unscheduled power
save during BI 0, and also during BI 2 through BI 4. STA A is required to stay awake during the following
CBAP after receiving an ATIM frame in BI 2. An ATIM frame received during BI 4 however serves as a
traffic indication and PCP will transmit frames to STA A only after STA A has performed unscheduled
power save to leave doze state.
Wakeup Schedule: Number of Awake BIs = 1, Sleep Cycle = 4
PCP BI 0: Awake BI BI 1: Awake BI BI 2: Awake BI BI 3: Doze BI BI 4: Awake BI
Following a
wakeup Awake Awake Awake Awake
BTI CBAP BTI CBAP BTI CBAP BTI CBAP
window window window window
schedule
STA can skip
PM=1
PM=0
PM=1
PM=0
ATIM
ATIM
ATIM
ATIM
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
transmitting ATIM to
PCP if it receives the
ATIM from PCP first
STA in scheduled PS mode STA in scheduled and unscheduled PS mode
STA in scheduled and
unscheduled PS mode
Non-PCP
BI 0: Awake BI BI 1: Doze BI BI 2: Awake BI BI 3: Doze BI BI 4: Awake BI
STA
Following a Awake Awake Awake
BTI CBAP BTI CBAP BTI CBAP
wakeup window window window
schedule and
STA in unscheduled PS
also Wakeup Schedule: Number of Awake BIs = 1, Sleep Cycle = 2
mode can be in doze state
performing despite receiving an ATIM
unscheduled frame from PCP
power save
Awake Doze Awake Doze Awake Doze Awake Doze Awake
Figure 11-12—Example of ATIM frame response behavior in PS mode
The ATIM frame transmission result and EOSP notification result between a MAC address pair can be used
for other MAC pairs that are members of the same MMSL cluster.
1640
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.2.8 ATIM frame and frame transmission in IBSS, DMG infrastructure BSS, and PBSS
If power management is in use within an IBSS, a STA shall buffer individually addressed BUs for STAs that
are known to be in PS mode.
The following rules describe operation of the ATIM frame and frame transmission to STAs in PS mode in an
IBSS, DMG infrastructure BSS and PBSS:
a) Following the reception or transmission of the Beacon frame in a non-DMG IBSS, during the ATIM
window, the STA shall queue for transmission an individually addressed ATIM frame to each STA
for which it has one or more buffered individually addressed BUs and for which an ATIM frame is
not already queued. Following the BTI or ATI in a DMG BSS, during the Awake Window, the STA
shall queue for transmission an individually addressed ATIM frame to each STA for which it has
one or more buffered individually addressed BUs and for which an ATIM frame is not already
queued. If the STA has one or more buffered group addressed MSDUs (excluding those with a
service class of StrictlyOrdered) or has one or more buffered group addressed MMPDUs, it shall
queue for transmission an appropriately addressed group addressed ATIM frame if such an ATIM
frame is not already queued.
b) In a non-DMG IBSS, a STA shall use the backoff procedure defined in 10.3.4.3 for transmission of
the first ATIM frame following the Beacon frame. In a DMG BSS, a STA shall use the backoff
procedure defined in 10.3.4.3 for transmission of the first ATIM frame following the BTI or ATI.
All remaining ATIM frames shall be transmitted using the DCF (for non-QoS STAs) or the EDCAF
(for QoS STAs).
c) ATIM frames shall be transmitted only during the ATIM window/Awake Window.
d) A non-DMG STA shall transmit no frame types other than RTS, CTS, Ack, Beacon, ATIM and
(QoS) Null frames during the ATIM window.
e) Individually addressed ATIM frames shall be acknowledged. If no acknowledgment is received, the
ATIM frame shall be retransmitted using either the DCF (for non-QoS STAs) or the EDCAF (for
QoS STAs). Group addressed ATIM frames shall not be acknowledged.
f) If a STA is unable to transmit an ATIM frame during the ATIM window/Awake Window, for
example due to contention with other STAs, the STA should retain the buffered BUs and either
discard the ATIM frame or attempt to transmit the ATIM frame during the next ATIM window/
Awake Window.
g) Immediately following the ATIM window/Awake Window, a STA shall begin transmission of any
buffered group addressed frames for which an ATIM frame was previously transmitted. Following
the transmission of any group addressed frames, any BUs addressed to STAs for which an
acknowledgment for a previously transmitted ATIM frame was received shall be transmitted. A
STA shall use the backoff procedure defined in 10.3.4.3 for transmission of the first frame following
the ATIM window/Awake Window. All remaining frames shall be transmitted using either the DCF
(for non-QoS STAs) or the EDCAF (for QoS STAs).
h) If a buffered BU is transmitted using fragmentation and if the BU has been partially transmitted
when the next Beacon frame is sent in a non-DMG IBSS or when the next beacon interval begins in
a DMG BSS, the STA shall retain the buffered BU and announce the remaining fragments by
transmitting an ATIM frame during the next ATIM window/Awake Window.
i) If a STA is unable to transmit a buffered BU during the beacon interval in which it was announced,
for example due to contention with other STAs, the STA shall retain the buffered BU and announce
the BU again by transmitting an ATIM frame during the next ATIM window/Awake Window.
j) Following the transmission of all buffered BUs, a STA may transmit BUs without announcement to
STAs that are known to be in the awake state for the current beacon interval.
k) A STA may discard BUs buffered for later transmission to power-saving STAs if the STA
determines that the BU has been buffered for an excessive amount of time or if other conditions
internal to the STA implementation make it desirable to discard buffered BUs (e.g., buffer
1641
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
starvation). A BU should not be discarded that has been buffered for less than dot11BeaconPeriod.
The algorithm to manage this buffering is beyond the scope of this standard.
l) In order to indicate its intent to change power management modes, a STA shall transmit individually
addressed or group addressed (QoS) Null frames within the ATIM window.
The STA shall not transition into or out of PS mode unless it has received acknowledgments from all
recipients to which individually addressed (QoS) Null frames have been transmitted or after it has
transmitted a sufficient number of group addressed (QoS) Null frames.
NOTE—The choice between individually addressed and group addressed transmissions, the peer STAs
addressed for individually addressed transmissions, and the number of transmissions for group addressed
transmissions are implementation choices outside the scope of the standard. A STA might base its choices on
factors such as the number of peer STAs it is aware of in the IBSS, the expected traffic from each of these peer
STAs, and the reliability of frame exchanges with these peer STAs.
11.3 STA authentication and association
11.3.1 State variables
A STA (local) for which dot11OCBActivated is false keeps an enumerated state variable for each STA
(remote) with which direct communication via the WM is needed. In this context, direct communication
refers to the transmission of any Class 2 or Class 3 frame with an Address 1 field that matches the MAC
address of the remote STA.
A STA for which dot11MeshActivated is true (i.e., a mesh STA) does not use procedures described in
11.3.5. Instead, a mesh STA uses a mesh peering management protocol (MPM) or a authenticated mesh
peering exchange (AMPE) to manage states and state variables for each peer STA. See 14.3 and 14.5 for
details.
A STA for which dot11OCBActivated is true does not use MAC sublayer authentication or association and
does not keep this state variable.
For nonmesh STAs, this state variable expresses the relationship between the local STA and the remote
STA. It takes on the following values:
— State 1: Initial start state for non-DMG STAs and for DMG STAs that perform IEEE 802.11
authentication. Unauthenticated and unassociated.
— State 2: Initial start state for DMG STAs that do not perform IEEE 802.11 authentication.
Authenticated (except DMG STAs that do not perform IEEE 802.11 authentication, which are
unauthenticated) but unassociated.
— State 3: Authenticated (except DMG STAs that did not perform IEEE 802.11 authentication, which
are unauthenticated) and associated (Pending RSNA Authentication). The IEEE 802.1X Controlled
Port is blocked.
— State 4: Authenticated (except DMG STAs that did not perform IEEE 802.11 authentication, which
are unauthenticated) and associated (RSNA Established or Not Required). The IEEE 802.1X
Controlled Port is unblocked, or not present.
The state variable is kept within the MLME (i.e., is written and read by the MLME). The SME may also read
this variable using the MLME-GETAUTHASSOCIATE.request primitive.
Mesh STAs manage the state variable as described in 14.3.2.
1642
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.3.2 State transition diagram for nonmesh STAs
Figure 11-13 shows the state transition diagram for nonmesh STA states. Note that only events causing state
changes are shown. The state of the sending STA given by Figure 11-13 is with respect to the intended
receiving STA.
NOTE—A transition to State 1 might occur for other reasons such as no frames having been received from a STA for a
period of time.
State 1
Unauthenticated,
Unassociated
Class 1 Frames
Successful
IEEE Std 802.11 authentication 1. Successful (Re)Association –
No RSNA Required
Deauthentication
(except DMG STAs that 2. Fast BSS Transition
State 2
did not perform
IEEE Std 802.11 authentication) Authenticated (except DMG STAs that do 3. PBSS 4-way handshake
not perform IEEE Std 802.11 authentication, Successful
which are unauthenticated), Unassociated
Class 1 & 2 Frames
Successful
(Re)Association – RSNA Required
1. Unsuccessful (Re)Association
(Non-AP and non-PCP STA)
State 3
2. Disassociation Authenticated (except DMG STAs that did not
perform IEEE Std 802.11 authentication,
Deauthentication which are unauthenticated), Associated
(except DMG STAs that (Pending RSNA Authentication)
did not perform IEEE
Std 802.11 Class 1, 2 & 3 Frames
authentication) IEEE 802.1X Controlled Port Blocked
4-way handshake Successful
1. Unsuccessful (Re)Association
(Non-AP and non-PCP STA) State 4
2. Disassociation Authenticated (except DMG STAs that did not
perform IEEE Std 802.11 authentication,
which are unauthenticated), Associated
(RSNA Established or Not Required)
Deauthentication
(except DMG STAs that did not Class 1, 2, & 3 Frames
perform IEEE Std 802.11 IEEE 802.1X Controlled Port Unblocked
authentication)
Figure 11-13—Relationship between state and services between a given pair of nonmesh
STAs
11.3.3 Frame filtering based on STA state
The current state existing between the transmitter and receiver STAs determines the IEEE 802.11 frame
types that may be exchanged between that pair of STAs (see Clause 9). A unique state exists for each pair of
transmitter and receiver STAs. The allowed frame types are grouped into classes and the classes correspond
to the STA state. In State 1, only Class 1 frames are allowed. In State 2, either Class 1 or Class 2 frames are
1643
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
allowed. In State 3 and State 4, all frames are allowed (Classes 1, 2, and 3). In the definition of frame
classes, the following terms are used:
— Within an infrastructure BSS: both the transmitting STA and the recipient STA participate in the
same infrastructure BSS
— Within a PBSS: both the transmitting STA and the recipient STA participate in the same PBSS
— Within an IBSS: both the transmitting STA and the recipient STA participate in the same IBSS
— dot11RSNAActivated: reference to the setting of dot11RSNAActivated at the STA that needs to
determine whether a transmission or reception is permitted.
NOTE—The phrase “within a BSS” comprises “within a PBSS,” “within an IBSS,” “within a MBSS,” or “within an
infrastructure BSS.”
STA A participates in the same infrastructure BSS as STA B if at least one of the following conditions is
met:
— STA A is associated with STA B, and either STA A or STA B is an AP.
— STA A receives a frame with the value of its TA field equal to the MAC address of STA B and with
the value of its BSSID field equal to the BSSID of the BSS with which STA A is associated.
— STA A receives an Information Response frame from the AP with which it is associated containing
an explicit indication that STA B is a member of the BSS with which STA A is associated.
STA A participates in the same PBSS as STA B if at least one of the following conditions is met:
— STA A is associated with STA B, and either STA A or STA B is a PCP.
— STA A receives a frame with the value of its TA field equal to the MAC address of STA B and with
the value of its BSSID field equal to the BSSID of the PBSS that STA A has joined or started.
— STA A receives a frame, i.e., an Information Response frame, from its PCP containing an explicit
indication that STA B is a member of the PBSS that STA A has joined.
STA A participates in the same IBSS as STA B if STA A receives a frame with the value of its TA field
equal to the MAC address of STA B and with the value of its BSSID field equal to the BSSID of the IBSS
that STA A has joined or started.
The frame classes are defined as follows:
a) Class 1 frames
1) Control frames
i) RTS
ii) CTS
iii) DMG Clear to send (DMG CTS)
iv) Ack
v) Grant
vi) SSW
vii) SSW-Feedback
viii) SSW-Ack
ix) Grant Ack
x) CF-End +CF-Ack
xi) CF-End
xii) In an IBSS and in a PBSS when dot11RSNAActivated is false, Block Ack (BlockAck)
xiii) In an IBSS and in a PBSS when dot11RSNAActivated is false, Block Ack Request
(BlockAckReq)
1644
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
2) Management frames
i) Probe Request/Response
ii) Beacon
iii) Authentication
iv) Deauthentication
v) ATIM
vi) Public Action
vii) Self-protected Action
viii) In an IBSS, all Action frames and all Action No Ack frames
vi) Unprotected DMG Action frames
vii) In a DMG BSS, Link Measurement Request and Link Measurement Report frames
viii) In a PBSS when dot11RSNAActivated is false, all Action and Action No Ack frames
except the following frames:
1) ADDTS Request
2) ADDTS Response
3) DELTS
3) Data frames
i) Data frames between IBSS STAs
ii) Data frames between peers using DLS
iii) Data frames within a PBSS
4) Extension frames
i) DMG Beacon
b) Class 2 frames
1) Management frames
i) Association Request/Response
ii) Reassociation Request/Response
iii) Disassociation
c) Class 3 frames
1) Data frames
i) Data frames between STAs in an infrastructure BSS or in an MBSS
2) Management frames
i) In an infrastructure BSS, an MBSS, or a PBSS, all Action and Action No Ack frames
except those that are declared to be Class 1 or Class 2 frames
3) Control frames
i) PS-Poll
ii) Poll
iii) SPR
iv) DMG DTS
v) Block Ack (BlockAck), except those that are declared to be Class 1
vi) Block Ack Request (BlockAckReq), except those that are declared to be Class 1 (above)
Class 2 and Class 3 frames are not allowed in an IBSS. If an IBSS STA receives a Class 2 or Class 3 frame,
it shall ignore the frame.
1645
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA shall not transmit Class 2 frames unless in State 2 or State 3 or State 4.
A STA shall not transmit Class 3 frames unless in State 3 or State 4.
A multi-band capable device that uses OCT to move from State 2 to either State 3 or State 4 shall not
transmit frames before the transmitting STA becomes over-the-WM enabled (see 11.33.4).
The use of the word “receive” in 11.3 refers to a frame that meets all of the filtering criteria specified in
Clause 12 and Clause 10.
11.3.4 Authentication and deauthentication
11.3.4.1 General
This subclause describes the procedures used for IEEE 802.11 authentication and deauthentication. The
states used in this description are defined in 11.3.1.
Successful authentication sets the STA’s state to State 2, if it was in State 1. Unsuccessful authentication
leaves the STA’s state unchanged.
Deauthentication notification sets the STA’s state to State 1. Deauthentication notification when in State 3
or 4 implies disassociation as well. A STA may deauthenticate a peer STA at any time, for any reason.
If STA A in an infrastructure BSS receives a Class 2 or Class 3 frame from STA B that is not authenticated
with STA A (i.e., the state for STA B is State 1), STA A shall discard the frame. If the frame has an
individual address in the Address 1 field, the MLME of STA A shall send a Deauthentication frame to
STA B.
Authentication is optional in an IBSS. In a non-DMG infrastructure BSS, authentication is required. In a
DMG infrastructure BSS and PBSS, the Open System authentication algorithm is not used (see 12.3.3.1).
APs do not initiate authentication.
11.3.4.2 Authentication—originating STA
Upon receipt of an MLME-AUTHENTICATE.request primitive that is part of an on-channel tunneling (see
11.33.4), the originating STA shall follow the rules in 11.33.4 in addition to the authentication procedure
described below.
Upon receipt of an MLME-AUTHENTICATE.request primitive, the originating STA shall authenticate
with the indicated STA using the following procedure:
a) If the STA is in an IBSS, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys
held for communication with the indicated STA by using the MLME-DELETEKEYS.request
primitive (see 12.6.18).
b) The STA shall execute one of the following:
1) For the Open System or Shared Key authentication algorithm, the authentication mechanism
described in 12.3.3.2 or 12.3.3.3, respectively.
2) For the fast BSS transition (FT) authentication algorithm in an ESS, the authentication
mechanism described in 13.5, or, if resource requests are included, 13.6.
3) For SAE authentication in an infrastructure BSS, IBSS, or MBSS, the authentication
mechanism described in 12.4.
1646
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) If the authentication was successful within the AuthenticateFailureTimeout, the state for the
indicated STA shall be set to State 2 if it was State 1; the state shall remain unchanged if it was other
than State 1.
d) The MLME shall issue an MLME-AUTHENTICATE.confirm primitive to inform the SME of the
result of the authentication.
11.3.4.3 Authentication—destination STA
Upon receipt of an Authentication frame with authentication transaction sequence number equal to 1, the
destination STA shall authenticate with the originating STA using the following procedure:
a) If Open System or Shared Key authentication algorithm is being used, the STA shall execute the
procedure described in 12.3.3.2 or 12.3.3.3, respectively. These result in the generation of an
MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication request.
b) If FT authentication is being used, the MLME shall issue an MLME-AUTHENTICATE.indication
primitive to inform the SME of the authentication request, including the FT Authentication
Elements, and the SME shall execute the procedure as described in 13.5 or 13.6.
c) If SAE authentication is being used in an infrastructure BSS, IBSS, or MBSS, the MLME shall issue
an MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication request,
including the SAE authentication elements, and the SME shall execute the procedure as described in
12.4
d) If the STA is in an IBSS and management frame protection was not negotiated when the PTKSA(s)
were created, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for
communication with the originating STA by using the MLME-DELETEKEYS.request primitive
(see 12.6.18).
e) Upon receipt of an MLME-AUTHENTICATE.response primitive, if the ResultCode is not
SUCCESS, the MLME shall transmit an Authentication frame with the corresponding status code,
as defined in 9.4.1.9, and the state for the originating STA shall be left unchanged. The
Authentication frame is constructed using the appropriate procedure in 12.3.3.2, 12.3.3.3, 13.5 or
13.6.
f) Upon receipt of an MLME-AUTHENTICATE.response primitive, if the ResultCode is SUCCESS,
the MLME shall transmit an Authentication frame that is constructed using the appropriate
procedure in 12.3.3.2, 12.3.3.3, 13.5 or 13.6, with a status code of SUCCESS, and the state for the
originating STA shall be set to State 2 if it was in State 1.
If the STA is in an IBSS, if the SME decides to initiate an RSNA, and if the SME does not know the security
policy of the peer, it may issue an individually addressed Probe Request frame to the peer by invoking an
MLME-SCAN.request primitive to discover the peer’s security policy.
11.3.4.4 Deauthentication—originating STA
The originating STA shall deauthenticate with the indicated STA using the following procedure:
a) The SME shall generate an MLME-DEAUTHENTICATE.request primitive containing the
appropriate reason code for the STA deauthentication, as defined in Table 9-45 of 9.4.1.7.
b) On receipt of the MLME-DEAUTHENTICATE.request primitive, if the state for the indicated STA
is State 2, State 3, or State 4, the MLME shall generate a Deauthentication frame to be transmitted to
the indicated STA.
NOTE—As the Deauthentication frame is a bufferable MMPDU, the transmission of this frame might be
delayed by the operation of a power-saving protocol. The AID and the PTKSA are maintained (when
applicable) until the frame is acknowledged or attempts to transmit the frame are abandoned.
c) The state for the indicated STA shall be set to State 1.
1647
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
d) Once the Deauthentication frame is acknowledged or attempts to transmit the frame are abandoned,
the MLME shall issue an MLME-DEAUTHENTICATE.confirm primitive to inform the SME of the
deauthentication.
e) The SME, upon receipt of an MLME-DEAUTHENTICATE.confirm primitive, shall delete any
PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the indicated STA by
using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by generating an MLME-
SETPROTECTION.request(None) primitive.
f) If the STA is contained within an AP, its SME, upon receipt of an MLME-
DEAUTHENTICATE.confirm primitive, shall release the AID assigned for the indicated STA, if
the state for the indicated STA was State 3 or State 4.
g) If the STA is contained within an AP, its SME shall inform the DS of the disassociation, if the state
for the indicated STA was State 3 or State 4.
h) If the STA is a mesh STA, its SME shall inform the mesh peering instance controller (see 14.3.4) of
the deauthentication.
11.3.4.5 Deauthentication—destination STA
A DMG STA in State 2, State 3 or State 4 that receives a Deauthentication frame shall remain in the same
state if it did not perform an IEEE 802.11 authentication exchange.
Otherwise, upon receipt of a Deauthentication frame from a STA for which the state is State 2, State 3, or
State 4, the destination STA shall deauthenticate with the originating STA using the following procedure:
a) If management frame protection was not negotiated when the PTKSA(s) were created, or if
management frame protection is in use and the frame is not discarded per management frame
protection processing, the MLME shall issue an MLME-DEAUTHENTICATE.indication primitive
to inform the SME of the deauthentication, and set the state for the originating STA to State 1.
b) Upon receiving an MLME-DEAUTHENTICATE.indication primitive, the SME shall
1) Delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the
originating STA by using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by
generating an MLME-SETPROTECTION.request(None) primitive.
2) If the STA is contained within an AP, release the AID assigned for the indicated STA and shall
inform the DS of the disassociation, if the state for the originating STA was State 3 or State 4.
3) If the STA is a mesh STA, inform the mesh peering instance controller (see 14.3.4) of the
deauthentication.
11.3.5 Association, reassociation, and disassociation
11.3.5.1 General
Subclause 11.3.5 describes the procedures used for IEEE 802.11 association, reassociation and
disassociation.
The states used in this description are defined in 11.3.1.
Successful association enables a STA to exchange Class 3 frames. Successful association sets the STA’s
state to State 3 or State 4.
Successful reassociation enables a STA to exchange Class 3 frames. Unsuccessful reassociation when not in
State 1 leaves the STA’s state unchanged (with respect to the AP or PCP that was sent the Reassociation
Request (which may be the current STA)). Successful reassociation sets the STA’s state to State 3 or State 4
(with respect to the AP or PCP that was sent the Reassociation Request). Successful reassociation when not
1648
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
in State 1 sets the STA’s state to State 2 (with respect to the current AP or PCP, if this is not the AP or PCP
that was sent the Reassociation Request). Reassociation shall be performed only if the originating STA is
already associated in the same ESS.
Disassociation notification when not in State 1 sets the STA’s state to State 2. The STA shall become
associated again prior to sending Class 3 frames. A STA may disassociate a peer STA at any time, for any
reason.
If non-DMG STA A in an infrastructure BSS receives a Class 3 frame from STA B that is authenticated but
not associated with STA A (i.e., the state for STA B is State 2), STA A shall discard the frame. If the frame
has an individual address in the Address 1 field, the MLME of STA A shall send a Disassociation frame to
STA B.
If DMG STA A in an infrastructure BSS receives a Class 3 frame from STA B that is not associated with
STA A (i.e., the state for STA B is State 2), STA A shall discard the frame. If the frame has an individual
address in the Address 1 field, the MLME of STA A shall send a Disassociation frame to STA B.
If an MM-SME coordinated STA receives an Association Response frame with a result code equal to
SUCCESS and with the value of the Single AID field within MMS element equal to 1, then
— For each of its MAC entities advertised within the MMS element and for which
dot11RSNAActivated is true, the state is set to State 3. Progress from State 3 to State 4 occurs
independently in each such MAC entity.
— For each of its MAC entities advertised within the MMS element and for which
dot11RSNAActivated is false, the state is set to State 4.
If the MM-SME coordinated STA in State 3 is assigned an AID for only the MAC entity identified by the
RA field of the Association Response with result code equal to SUCCESS, the MM-SME may repeat the
association procedure for any other MAC entity coordinated by the MM-SME.
Association is not applicable in an IBSS. In an infrastructure BSS, association is required. In a PBSS,
association is optional. APs do not initiate association.
11.3.5.2 Non-AP and non-PCP STA association initiation procedures
The SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the
AP or PCP by using MLME-DELETEKEYS.request primitive (see 12.6.18) before invoking MLME-
ASSOCIATE.request primitive.
If dot11InterworkingServiceActivated is true, the STA does not have credentials for the AP, and the STA is
initiating an emergency services association procedure, the SME shall submit the MLME-
ASSOCIATE.request primitive with EmergencyServices parameter set to true.
The MM-SME of a non-AP and non-PCP STA may include an MMS element in an MLME-
ASSOCIATE.request primitive. The MM-SME shall include in the MMS element the MAC address
associated with the MLME SAP instance to which the primitive is submitted.
Upon receipt of an MLME-ASSOCIATE.request primitive that is part of an on-channel tunneling (see
11.33.4), a non-AP and non-PCP STA shall follow the rules in 11.33.4 in addition to the association
procedures described below.
Upon receipt of an MLME-ASSOCIATE.request primitive, a non-AP and non-PCP STA shall associate
with an AP or PCP using the following procedure:
1649
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) If the state for the AP is State 1, the MLME shall inform the SME of the failure of the association by
issuing an MLME-ASSOCIATE.confirm primitive, and this procedure ends.
b) The MLME shall transmit an Association Request frame to the AP or PCP. If the MLME-
ASSOCIATE.request primitive contained an RSNE with only one pairwise cipher suite and only
one authenticated key suite, this RSNE shall be included in the Association Request frame. If the
MLME-ASSOCIATE.request primitive contained the EmergencyServices parameter equal to true,
an Interworking element with the UESA field set to 1 shall be included in the Association Request
frame.
c) If an Association Response frame is received with a status code of SUCCESS, a DMG STA shall
write to each of the following MIB attributes the value of the corresponding subfield of the DMG
BSS Parameter Configuration field of the DMG Operation element received from the AP or PCP to
which it requested association:
1) dot11PSRequestSuspensionInterval from the PSRequestSuspensionInterval subfield
2) dot11MinBHIDuration from the MinBHIDuration subfield
3) dot11BroadcastSTAInfoDuration from the BroadcastSTAInfoDuration subfield
4) dot11AssocRespConfirmTime from the AssocRespConfirmTime subfield
5) dot11MinPPDuration from the MinPPDuration subfield
6) dot11SPIdleTimeout from the SPIdleTimeout subfield
7) dot11MaxLostBeacons from the MaxLostBeacons subfield
d) If an Association Response frame is received with a status code of SUCCESS, the state for the AP or
PCP shall be set to State 4 or, if dot11RSNAActivated is true, State 3. The state for any other AP or
PCP which is State 3 or State 4 prior to the association request shall be set to State 2, and the MLME
shall issue an MLME-ASSOCIATE.confirm primitive to inform the SME of the successful
completion of the association.
e) An MM-SME coordinated STA that receives an Association Response frame with a status code of
SUCCESS containing an MLME element with the Single AID field equal to 1, all of the STAs
coordinated by the MM-SME are associated with the AP or PCP (i.e., shall be set to State 4 or, if
dot11RSNAActivated is true, State 3).
f) If an Association Response frame is received with a status code other than SUCCESS or the
association fails to complete within dot11AssociationResponseTimeout the state for the AP or PCP
shall be set to State 2, and the MLME shall issue an MLME-ASSOCIATE.confirm primitive to
inform the SME of the failure of the association. The status code returned in the Association
Response frame indicates the cause of the failed association attempt. Any misconfiguration or
parameter mismatch, e.g., data rates required as basic rates that the STA did not indicate as
supported in the STA’s Supported Rates and BSS Membership Selectors element, shall be corrected
before the SME issues an MLME-ASSOCIATE.request primitive for the same AP or PCP. If the
status code indicates the association failed because of a reason that is not related to configuration
(e.g., the AP or PCP is unable to support additional associations) and the Association Response
frame does not include a Timeout Interval element with Timeout Interval Type equal to 3 the SME
shall not issue an MLME-ASSOCIATE.request primitive for the same AP or PCP until a period of
at least 2 s has elapsed. If the status code indicates the association failed and the Association
Response frame contains a Timeout Interval element with Timeout Interval Type equal to 3, the
SME shall not issue an MLME-ASSOCIATE.request primitive for the same AP or PCP until the
period specified in the Timeout Interval element has elapsed.
g) If an MLME-ASSOCIATE.confirm primitive is received with a ResultCode of SUCCESS, and
RSNA is required, then the SME shall perform a 4-way handshake to establish an RSNA. As a part
of a successful 4-way handshake, the SME enables protection by generating an MLME-
SETPROTECTION.request(Rx_Tx) primitive.
h) Upon receipt of the MLME-SETPROTECTION.request(Rx_Tx) primitive, the MLME shall set the
state of the STA to State 4.
1650
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.3.5.3 AP or PCP association receipt procedures
Upon receipt of an Association Request frame from a STA the AP or PCP shall use the following procedure:
a) The MLME shall issue an MLME-ASSOCIATE.indication primitive to inform the SME of the
association request. The SME shall issue an MLME-ASSOCIATE.response primitive addressed to
the STA identified by the PeerSTAAddress parameter of the MLME-ASSOCIATE.indication
primitive. If the association is not successful, the SME shall indicate a specific reason for the failure
to associate in the ResultCode parameter. Upon receipt of the MLME-ASSOCIATE.response
primitive, the MLME shall transmit an Association Response frame.
b) If the state for the STA is 1 and the STA is a non-DMG STA, the SME shall refuse the association
request by issuing an MLME-ASSOCIATE.response primitive with ResultCode
NOT_AUTHENTICATED.
c) AP with dot11InterworkingServiceActivated true only: If the MLME-ASSOCIATE.indication
primitive has the EmergencyServices parameter set to true and the RSN parameter does not include
an RSNE, the SME shall not reject the association request on the basis that dot11RSNAActivated is
true, thereby granting access, using unprotected frames (see 9.2.4.1.9), to the network for emergency
services purposes.
d) Otherwise, in an RSNA the SME shall check the values received in the RSN parameter to see
whether the values received match the security policy. If they do not, the SME shall refuse the
association by issuing an MLME-ASSOCIATE.response primitive with a ResultCode indicating the
security policy mismatch.
e) Otherwise, if the state for the STA is 4, the STA has a valid security association, the STA has
negotiated management frame protection, and there has been no earlier, timed out SA Query
procedure with the STA (which would have allowed a new association process to be started, without
an additional SA Query procedure):
1) The SME shall refuse the association request by issuing an MLME-ASSOCIATE.response
primitive with ResultCode REFUSED_TEMPORARILY and TimeoutInterval containing a
Timeout Interval element with the Timeout Interval Type field set to 3 (Association Comeback
time). If the SME is in an ongoing SA Query with the STA, the Timeout Interval Value field
shall be set to the remaining SA Query period, otherwise it shall be set to
dot11AssociationSAQueryMaximumTimeout.
2) The state for the STA shall be left unchanged.
3) Following this, if the SME is not in an ongoing SA Query with the STA, the SME shall issue
one MLME-SA-QUERY.request primitive addressed to the STA every
dot11AssociationSAQueryRetryTimeout TUs until an MLME-SA-QUERY.confirm primitive
for the STA is received or dot11AssociationSAQueryMaximumTimeout TUs from the
beginning of the SA Query procedure have passed. The SME shall increment the
TransactionIdentifier by 1 for each MLME-SA-QUERY.request primitive, rolling it over the
value to 0 after the maximum allowed value is reached.
4) If no MLME-SA-QUERY.confirm primitive for the STA is received within the
dot11AssociationSAQueryMaximumTimeout period, the SME shall allow a subsequent
association process with the STA to be started without starting an additional SA Query
procedure, except that the SME may deny a subsequent association process with the STA if an
MSDU was received from the STA within this period.
NOTE—Reception of an MSDU implies reception of a valid protected frame, which obviates the need for
the SA Query procedure.
f) The SME shall refuse an association request from a STA that does not support all of the rates in the
BSSBasicRateSet parameter in the MLME-START.request primitive.
1651
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
g) The SME shall refuse an association request from an HT STA that does not support all of the MCSs
in the Basic HT-MCS Set field of the HT Operation parameter in the MLME-START.request
primitive.
h) The SME shall refuse an association request from a VHT STA that does not support all of the
tuples indicated by the Basic VHT-MCS And NSS Set field of the VHT
Operation parameter in the MLME-START.request primitive.
i) The SME shall generate an MLME-ASSOCIATE.response primitive with the PeerSTAAddress
parameter set to the MAC address of the STA identified by the PeerSTAAddress parameter of the
MLME-ASSOCIATE.indication primitive. If the ResultCode in the MLME-ASSOCIATE.response
primitive is SUCCESS, the SME has an existing SA with the STA, and an SA Query procedure with
that STA has failed to receive a valid response (i.e., has not received an MLME-SA-
QUERY.confirm primitive within the dot11AssociationSAQueryMaximumTimeout period), the
SME shall issue an MLME-DISASSOCIATE.request primitive addressed to the STA with
ReasonCode INVALID_AUTHENTICATION.
NOTE—This MLME-DISASSOCIATE.request primitive generates a protected Disassociation frame. If the
association request was genuine, the STA has deleted the PTKSA by this point and so the protected
Disassociation frame is ignored. The purpose is to inform a STA which has for some reason failed to respond to
an SA Query procedure triggered by a forged association request.
j) If the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS, the SME shall
delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the STA by
using the MLME-DELETEKEYS.request primitive (see 11.5.18 (RSNA security association
termination)).
k) If the MLME-ASSOCIATE.indication primitive includes an MMS parameter, the AP or PCP shall
generate the MLME-ASSOCIATE.response primitive directed to the MLME of the STA identified
by the PeerSTAAddress parameter of the MLME-ASSOCIATE.request primitive and take the
following additional action, as appropriate:
1) If the Single AID field in the MMS parameter of the MLME-ASSOCIATE.indication primitive
is equal to 1, the AP or PCP may allocate a single AID for all of the STAs included in the MMS
element. If the AP or PCP allocates the same AID to each STA whose MAC address was
included in the MMS element, it shall include the MMS element received from the MM-SME
coordinated STA in the MLME-ASSOCIATION.response primitive.
2) If the Single AID field is 0, the AP or PCP shall allocate a distinct AID for each STA specified
in the MMS element.
l) If an Association Response frame with a status code of SUCCESS is acknowledged by the STA, the
state for the STA shall be set to State 4 or, if dot11RSNAActivated is true, State 3.
m) If the ResultCode in the MLME-ASSOCIATE.response primitive is not SUCCESS and
management frame protection is in use the state for the STA shall be left unchanged. If the
ResultCode is not SUCCESS and management frame protection is not in use the state for the STA
shall be set to State 3 if it was State 4.
n) If the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS and RSNA
establishment is required, the SME shall attempt a 4-way handshake. Upon a successful completion
of a 4-way handshake, the SME shall enable protection by issuing an MLME-
SETPROTECTION.request(Rx_Tx) primitive and the state for the STA shall be set to State 4.
o) AP only: The SME shall inform the DS of any changes in the state of the STA.
11.3.5.4 Non-AP and non-PCP STA reassociation initiation procedures
Except when the association is part of a fast BSS transition, the SME shall delete any PTKSA, GTKSA,
IGTKSA and temporal keys held for communication with the AP or PCP by using the MLME-
DELETEKEYS.request primitive (see 12.6.18) before invoking an MLME-REASSOCIATE.request
primitive.
1652
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If dot11InterworkingServiceActivated is true and the STA was associated to the ESS for unsecured access to
emergency services, the SME shall submit the MLME-REASSOCIATE.request primitive with
EmergencyServices parameter set to true.
The MM-SME of a non-AP and non-PCP STA may include an MMS element in an MLME-
REASSOCIATE.request primitive. The MM-SME shall include in the MMS element the MAC address
associated with the MLME SAP instance to which the primitive is submitted.
Upon receipt of an MLME-REASSOCIATE.request primitive that is part of an on-channel tunneling (see
11.33.4), a non-AP and non-PCP STA shall follow the rules in 11.33.4 in addition to the reassociation
procedures described below.
Upon receipt of an MLME-REASSOCIATE.request primitive, a non-AP and non-PCP STA shall
reassociate with an AP or PCP using the following procedure:
a) If the STA is not associated in the same ESS or the state for the new AP is State 1, the MLME shall
inform the SME of the failure of the reassociation by issuing an MLME-REASSOCIATE.confirm
primitive, and this procedure ends.
b) The MLME shall transmit a Reassociation Request frame to the new AP or PCP. If the MLME-
REASSOCIATE.request primitive contained an RSNE with only one pairwise cipher suite and only
one authenticated key suite, this RSNE shall be included in the Reassociation Request frame. If the
MLME-REASSOCIATE.request primitive contained the EmergencyServices parameter equal to
true, an Interworking element with the UESA field set to 1 shall be included in the Reassociation
Request frame.
c) If a Reassociation Response frame is received with a status code of SUCCESS, the state variable for
the new AP or PCP shall be set to State 4 or to State 3 if dot11RSNAActivated is true and the FT
protocol is not used with respect to the new AP or PCP and, unless the old AP or PCP and new AP
or PCP are the same, to State 2 with respect to the old AP or PCP, and the MLME shall issue an
MLME-REASSOCIATE.confirm primitive to inform the SME of the successful completion of the
reassociation.
If the MLME-REASSOCIATION.request primitive has the new AP’s MAC address in the
CurrentAPAddress parameter (reassociation to the same AP), the following states, agreements and
allocations shall be deleted or reset to initial values:
1) All EDCAF state
2) Any block ack agreements
3) Sequence number
4) Packet number
5) Duplicate detection caches
6) Anything queued for transmission
7) Fragmentation and reassembly buffers
8) Power management mode
9) WNM sleep mode
10) SMKSAs, STKSAs and TPKSAs established with any peers.
The following states, agreements and allocations are not affected by the reassociation procedure:
1) PSMP sessions
2) Enablement/Deenablement
3) GDD enablement
4) STSL, DLS and TDLS agreements
5) MMSLs
1653
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
6) GCR agreements
7) DMS agreements
8) TFS agreements
9) FMS agreements
10) Triggered autonomous reporting agreements
11) FTM sessions
12) DMG SP and CBAP allocations.
d) If a Reassociation Response frame is received with a status code of SUCCESS, a DMG STA shall
write to each of the following MIB attributes the value of the corresponding subfield of the DMG
BSS Parameter Configuration field of the DMG Operation element received from the AP or PCP to
which it requested reassociation:
1) dot11PSRequestSuspensionInterval from the PSRequestSuspensionInterval subfield
2) dot11MinBHIDuration from the MinBHIDuration subfield
3) dot11BroadcastSTAInfoDuration from the BroadcastSTAInfoDuration subfield
4) dot11AssocRespConfirmTime from the AssocRespConfirmTime subfield
5) dot11MinPPDuration from the MinPPDuration subfield
6) dot11SPIdleTimeout from the SPIdleTimeout subfield
7) dot11MaxLostBeacons from the MaxLostBeacons subfield
e) An MM-SME coordinated STA that receives a Reassociation Response frame with a status code of
SUCCESS containing an MLME element with the Single AID field equal to 1, all of the STAs
coordinated by the MM-SME are reassociated with the AP or PCP (i.e., shall be set to State 4 or, if
dot11RSNAActivated is true, State 3).
f) If a Reassociation Response frame is received with a status code other than SUCCESS or the
reassociation fails to complete within dot11AssociationResponseTimeout:
1) Except when the association is part of a fast BSS transition, the state for the AP or PCP shall be
set to State 2 with respect to the new AP or PCP.
2) The MLME shall issue an MLME-REASSOCIATE.confirm primitive to inform the SME of
the failure of the reassociation. The ResultCode returned in the MLME-
REASSOCIATE.confirm primitive indicates the cause of the failed reassociation attempt. Any
misconfiguration or parameter mismatch, e.g., data rates required as basic rates that the STA
did not indicate as supported in the STA’s Supported Rates and BSS Membership Selectors
element, shall be corrected before the SME issues an MLME-REASSOCIATE.request
primitive for the same AP or PCP. If the status code indicates the reassociation failed because
of a reason that is not related to configuration (e.g., the AP or PCP is unable to support
additional associations) and the Reassociation Response frame does not include a Timeout
Interval element with Timeout Interval Type equal to 3 the SME shall not issue an MLME-
REASSOCIATE.request primitive for the same AP or PCP until a period of at least 2 s has
elapsed. If the status code indicates the reassociation failed and the Reassociation Response
frame contains a Timeout Interval element with Timeout Interval Type equal to 3, the SME
shall not issue an MLME-REASSOCIATE.request primitive for the same AP or PCP until the
period specified in the Timeout Interval element has elapsed.
g) If an MLME-REASSOCIATE.confirm primitive is received with a ResultCode of SUCCESS, and
RSNA is required, and the STA is in State 3, then the SME shall perform a 4-way handshake to
establish an RSNA. As a part of a successful 4-way handshake, the SME shall enable protection by
generation an MLME-SETPROTECTION.request(Rx_Tx) primitive
h) Upon receipt of the MLME-SETPROTECTION.request(Rx_Tx), the MLME shall set the state of
the STA to State 4.
1654
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.3.5.5 AP or PCP reassociation receipt procedures
Upon receipt of a Reassociation Request frame from a STA the AP or PCP shall use the following
procedure:
a) The MLME shall issue an MLME-REASSOCIATE.indication primitive to inform the SME of the
reassociation request. The SME shall issue an MLME-REASSOCIATE.response primitive
addressed to the STA identified by the PeerSTAAddress parameter of the MLME-
REASSOCIATE.indication primitive. If the reassociation is not successful, the SME shall indicate a
specific reason for the failure to reassociate in the ResultCode parameter. Upon receipt of the
MLME-REASSOCIATE.response primitive, the MLME shall transmit a Reassociation Response
frame.
b) If the state for the STA is 1 and the STA is a non-DMG STA, the SME shall refuse the reassociation
request by issuing an MLME REASSOCIATE.response primitive with ResultCode
NOT_AUTHENTICATED.
c) AP with dot11InterworkingServiceActivated true only: If the MLME-REASSOCIATE.indication
primitive has the EmergencyServices parameter set to true and the RSN parameter does not include
an RSNE, the SME shall not reject the reassociation request on the basis that dot11RSNAActivated
is true and dot11PrivacyInvoked is true thereby granting access, using unprotected frames (see
9.2.4.1.9), to the network for emergency services purposes.
d) Otherwise, in an RSNA the SME shall check the values received in the RSN parameter to see
whether the values received match the security policy. If they do not, SME shall refuse the
reassociation by issuing an MLME-REASSOCIATE.response primitive with a ResultCode
indicating the security policy mismatch.
e) Otherwise, if the state for the STA is 4, the STA has a valid security association, the STA has
negotiated management frame protection, the reassociation is not a part of a fast BSS transition, and
there has been no earlier, timed out SA Query procedure with the STA (which would have allowed a
new reassociation process to be started, without an additional SA Query procedure):
1) The SME shall refuse the reassociation request by issuing an MLME-
REASSOCIATE.response primitive with ResultCode REFUSED_TEMPORARILY and
TimeoutInterval containing a Timeout Interval element with the Timeout Interval Type field
set to 3 (Association Comeback time). If the SME is in an ongoing SA Query with the STA, the
Timeout Interval Value field shall be set to the remaining SA Query period, otherwise it shall
be set to dot11AssociationSAQueryMaximumTimeout.
2) The state for the STA shall be left unchanged.
3) Following this, if the SME is not in an ongoing SA Query with the STA, the SME shall issue
one MLME-SA-QUERY.request primitive addressed to the STA every
dot11AssociationSAQueryRetryTimeout TUs until an MLME-SA-QUERY.confirm primitive
for the STA is received or dot11AssociationSAQueryMaximumTimeout TUs from the
beginning of the SA Query procedure have passed. The SME shall increment the
TransactionIdentifier by 1 for each MLME-SA-QUERY.request primitive, rolling it over to 0
after the maximum allowed value is reached.
4) If no MLME-SA-QUERY.confirm primitive for a STA is received within the
dot11AssociationSAQueryMaximumTimeout period, the SME shall allow a subsequent
reassociation process to be started without starting an additional SA Query procedure, except
that the SME may deny a subsequent reassociation process with the STA if an MSDU was
received from the STA within this period.
NOTE—Reception of an MSDU implies reception of a valid protected frame, which obviates the need for
the SA Query procedure.
f) The SME shall refuse a reassociation request from a STA that does not support all the rates in the
BSSBasicRateSet parameter in the MLME-START.request primitive.
1655
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
g) The SME shall refuse a reassociation request from an HT STA that does not support all of the MCSs
in the Basic HT-MCS Set field of the HT Operation parameter in the MLME-START.request
primitive.
h) The SME shall refuse a reassociation request from a VHT STA that does not support all of the
tuples indicated by the Basic VHT-MCS And NSS Set field of the VHT
Operation parameter in the MLME-START.request primitive.
i) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS, the SME has an
existing SA with the STA, and an SA Query procedure with that STA has failed to receive a valid
response (i.e., has not received an MLME-SA-QUERY.confirm primitive within the
dot11AssociationSAQueryMaximumTimeout period), the SME shall issue an MLME-
DISASSOCIATE.request primitive addressed to the STA with ReasonCode
INVALID_AUTHENTICATION.
NOTE—This MLME-DISASSOCIATE.request primitive generates a protected Disassociation frame. If the
reassociation request was genuine, the STA has deleted the PTKSA by this point and so the protected
Disassociation frame is ignored. The purpose is to inform a STA which has for some reason failed to respond to
an SA Query procedure triggered by a forged reassociation request.
j) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the
reassociation is not part of a fast BSS transition, the SME shall delete any PTKSA, GTKSA,
IGTKSA and temporal keys held for communication with the STA by using the MLME-
DELETEKEYS.request primitive (see 11.5.18 (RSNA security association termination)).
k) If the MLME-REASSOCIATE.indication primitive includes an MMS parameter, the AP or PCP
shall take the following additional action, as appropriate:
1) If the Single AID field in the MMS parameter of the MLME-REASSOCIATE.indication
primitive is equal to 1, the AP or PCP may allocate a single AID for all of the STAs included in
the MMS element. If the AP or PCP allocates the same AID to all STAs whose MAC address
was included in the MMS element, it shall include the MMS element received from the MM-
SME coordinated STA in the MLME-REASSOCIATE.response primitive.
2) If the Single AID field is 0, the AP or PCP shall allocate a distinct AID for each STA specified
in the MMS element.
l) If a Reassociation Response frame with a status code of SUCCESS is acknowledged by the STA, the
state for the STA shall be set to State 4, or to State 3 if dot11RSNAActivated is true and the
reassociation is not part of a fast BSS transition.
m) If the ResultCode in the MLME-REASSOCIATE.response primitive is not SUCCESS and
management frame protection is in use the state for the STA shall be left unchanged. If the
ResultCode is not SUCCESS, management frame protection is not in use, and the reassociation is
part of a fast BSS transition, the state for the STA shall be left unchanged. If the ResultCode is not
SUCCESS, management frame protection is not in use, and the reassociation is not part of a fast
BSS transition, the state for the STA shall be set to State 3 if it was State 4.
n) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS, RSNA
establishment is required, and the reassociation is not part of a fast BSS transition, the SME shall
attempt a 4-way handshake. Upon a successful completion of a 4-way handshake, the SME shall
enable protection by issuing an MLME-SETPROTECTION.request(Rx_Tx) primitive and the state
for the STA shall be set to State 4.
o) AP only: The SME shall inform the DS of any changes in the state of the STA.
p) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the
CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive had the new
AP’s MAC address in the CurrentAPAddress parameter (reassociation to the same AP), the AP shall
match the non-AP STAs treatment of the listed agreements and allocations as described in 11.3.5.4
list item c). The AP deletes or resets to initial values those items that the non-AP STA is required in
1656
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.3.5.4 list item c) to delete or reset to initial values, and the AP does not modify the states,
agreements and allocations that are listed as not affected by the reassociation procedure.
11.3.5.6 Non-AP and non-PCP STA disassociation initiation procedures
The SME shall issue an MLME-DISASSOCIATE.request primitive that includes an appropriate Reason
Code as defined in Table 9-45 of 9.4.1.7.
Upon receipt of an MLME-DISASSOCIATE.request primitive, a non-AP and non-PCP STA’s MLME shall
disassociate from an AP or PCP using the following procedure:
a) If the state for the AP or PCP is State 3 or State 4, the MLME shall transmit a Disassociation frame
to the AP or PCP.
b) The state for the AP or PCP shall be set to State 2 if it was not State 1. In the case of an MM-SME
coordinated STA, the MLME shall perform this for each STA whose address was included in the
MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive
that established the association.
c) The MLME shall issue an MLME-DISASSOCIATE.confirm primitive to inform the SME of the
successful completion of the disassociation.
d) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall delete any PTKSA,
GTKSA, IGTKSA and temporal keys held for communication with the AP or PCP by using the
MLME-DELETEKEYS.request primitive (see 12.6.18) and by invoking an MLME-
SETPROTECTION.request(None) primitive. In the case of an MM-SME coordinated STA, the
MLME shall perform this for each STA whose address was included in the MMS parameter of the
MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the
association.
11.3.5.7 Non-AP and non-PCP STA disassociation receipt procedure
Upon receipt of a Disassociation frame from an AP or PCP for which the state is State 3 or State 4, if
management frame protection was not negotiated when the PTKSA(s) were created, or if management frame
protection is in use and the frame is not discarded per management frame protection processing, a non-AP
and non-PCP STA shall disassociate from the AP or PCP using the following procedure:
a) The state for the AP or PCP shall be set to State 2.
b) The MLME shall issue an MLME-DISASSOCIATE.indication primitive to inform the SME of the
disassociation.
c) Upon receiving the MLME-DISASSOCIATE.indication primitive, the SME shall delete any
PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the AP or PCP by
using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by invoking an MLME-
SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each
STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or
MLME-REASSOCIATE.request primitive that established the association.
d) If the reason code indicates a configuration or parameter mismatch as the cause of the
disassociation, the SME shall not attempt to associate or reassociate with the AP or PCP until the
configuration or parameter mismatch has been corrected.
e) If the reason code indicates the STA was disassociated for a reason other than configuration or
parameter mismatch, the SME shall not attempt to associate or reassociate with the AP or PCP until
a period of 2 s has elapsed.
1657
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.3.5.8 AP or PCP disassociation initiation procedure
The SME shall issue an MLME-DISASSOCIATE.request primitive that includes an appropriate Reason
Code as defined Table 9-45 of 9.4.1.7.
Upon receipt of an MLME-DISASSOCIATE.request primitive, an AP or PCP shall disassociate a STA
using the following procedure:
a) If the state for the STA is State 3 or State 4, the AP or PCP shall generate a Disassociation frame to
be transmitted to the indicated STA.
NOTE—As the Disassociation frame is a bufferable MMPDU, the transmission of this frame might be delayed
by the operation of a power-saving protocol. The AID and the PTKSA are maintained (when applicable) until
the frame is acknowledged or attempts to transmit the frame are abandoned.
b) The state for the STA shall be set to State 2, if it was not State 1. The MM-SME shall perform this
process for each STA whose address was included in the MMS parameter of the MLME-
ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association.
c) Once the Disassociation frame is acknowledged or attempts to transmit the frame are abandoned, the
MLME shall issue an MLME-DISASSOCIATE.confirm primitive to inform the SME of the
disassociation.
d) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall delete any PTKSA,
GTKSA, IGTKSA and temporal keys held for communication with the STA by using the
MLME-DELETEKEYS.request primitive (see 12.6.18) and by invoking an MLME-
SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each
STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or
MLME-REASSOCIATE.request primitive that established the association.
e) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall release the AID
assigned for the indicated STA, if the state for the indicated STA was State 3 or State 4.
f) AP only: The SME shall inform the DS of the disassociation.
11.3.5.9 AP or PCP disassociation receipt procedure
Upon receipt of a Disassociation frame from a STA for which the state is State 3 or State 4, if management
frame protection was not negotiated when the PTKSA(s) were created, or if management frame protection is
in use and the frame is not discarded per management frame protection processing, the AP or PCP shall
disassociate the STA using the following procedure:
a) The state for the STA shall be set to State 2. The MM-SME shall perform this process for each STA
whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-
REASSOCIATE.request primitive that established the association.
b) The MLME shall issue an MLME-DISASSOCIATE.indication primitive to inform the SME of the
disassociation.
c) Upon receiving an MLME-DISASSOCIATE.indication primitive the SME shall delete any PTKSA,
GTKSA, IGTKSA and temporal keys held for communication with the STA by using the
MLME-DELETEKEYS.request primitive (see 12.6.18) and by invoking an MLME-
SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each
STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or
MLME-REASSOCIATE.request primitive that established the association.
d) AP only: The SME shall inform the DS of the disassociation.
e) The SME shall release the AID assigned for the indicated STA.
1658
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.3.5.10 PBSS procedures for nonassociated STAs
In a PBSS, there are four types of relationships between a PCP and the members of a PBSS:
— Nonassociated, non-RSNA (when dot11RSNAActivated is false)
— Associated, non-RSNA (when dot11RSNAActivated is false)
— Associated, RSNA (when dot11RSNAActivated is true)
— Nonassociated, RSNA (when dot11RSNAActivated is true)
The following rules apply in the last case:
a) In a PBSS, when a STA is in State 2 and dot11RSNAActivated is true, successful RSNA
establishment changes the STA to State 4. Unsuccessful RSNA establishment leaves the state
unchanged.
b) In a PBSS, when a STA is in State 4, the STA’s receipt of a disassociation notification changes the
state to State 2.
11.3.6 Additional mechanisms for an AP collocated with a mesh STA
If a STA to AP mapping is added to the DS with the STA being a non-AP STA in an infrastructure BSS and
the AP being an access point that interconnects through a DS with a mesh gate (that is, AP and mesh gate are
collocated; see Figure 4-10), this mesh gate shall verify that the MAC address of the STA does not belong to
a mesh STA in the MBSS. See 4.5.3.3 and Clause 7 for association and STA to AP mapping in the DS. If the
mesh gate determines that the authenticated STA has a MAC address that is a MAC address of a mesh STA
in the MBSS, then the collocated access point shall deauthenticate the STA with Reason Code
UNSPECIFIED_REASON or MACADDRESS-ALREADY-EXISTS-IN-MBSS.
The mechanism for verifying the MAC address of the authenticated STA depends on the active path
selection protocol and might be vendor specific. See 14.10.13 when HWMP is the active path selection
protocol.
11.3.7 Communicating PBSS information
Following the association or security association of a STA with a PCP, the PCP shall send an unsolicited
Information Response frame (9.6.20.5 to all STAs associated with the PCP. The PCP shall send a broadcast
Information Response frame and/or shall send individually addressed Information Response frames to each
STA associated with the PCP. The PCP shall set the Subject Address field of the Information Response
frame to the broadcast address and shall include in the Information Response frame the DMG Capabilities
element for the PCP and each STA associated with the PCP. This process is referred to as PBSS information
distribution.
The PCP shall perform a PBSS information distribution at least once every
dot11BroadcastSTAInfoDuration beacon intervals.
11.3.8 Neighbor report information upon rejection with suggested BSS transition
An AP may provide neighbor report information to a STA that requests authentication or association by
responding with an Authentication or (Re)Association Response frame that has the Reason Code field set to
REJECTED_WITH_SUGGESTED_BSS_TRANSITION and that includes one or more Neighbor Report
elements.
1659
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.4 TS operation
11.4.1 Introduction
There are three types of traffic specifications: the TSPEC, the DMG TSPEC, and the PTP TSPEC.
A TSPEC describes the traffic characteristics and the QoS requirements of a TS. The main purpose of the
TSPEC is to reserve resources within the HC and, in the case of HCCA and HEMM access policies, to
modify the HC’s scheduling behavior. It also allows other parameters to be specified that are associated with
the TS, such as a traffic classifier and acknowledgment policy.
The DMG TSPEC (9.4.2.134) describes an allocation (also known as DMG allocation) within either a PBSS
or a DMG infrastructure BSS. The purpose of the DMG TSPEC is to create or modify an allocation for the
transmission of frames between DMG STAs that are members of a PBSS or that are members of an
infrastructure BSS (10.36.6).
To communicate between STAs in a PBSS or between non-AP DMG STAs in an infrastructure BSS, a
TSPEC (as defined in 9.4.2.30) is used to create or modify a TS between those STAs. This TSPEC is
referred to as a PTP TSPEC.
In a DMG BSS, a TSPEC includes parameters that are associated with the TS such as maximum MSDU
size, delay bound, and optionally the allocation carrying the TS. A single allocation can carry multiple TSs.
Each TS is carried in one allocation, except when
— The TS has an access policy of EDCA, where it can use all CBAP allocations with Source AID
equal to the broadcast AID, all CBAP allocations with Source AID matching the source STA of the
TS, and all CBAP allocations with Destination AID matching the destination STA of the TS; or
— The TS has an access policy of SEMM, where it can use exactly one SP allocation as well as all
CBAP allocations with Source AID equal to the broadcast AID, all CBAP allocations with Source
AID matching the source STA of the TS, and all CBAP allocations with Destination AID matching
the destination STA of the TS.
A TS may have one or more TCLAS (within the discretion of the STA that sets up the stream) associated
with it. A DMG STA or AP uses the parameters in the TCLAS elements to filter the MSDUs belonging to
this TS for delivery as part of the TS. An Intra-Access Category Priority element may be associated with a
TS by the inclusion of an Intra-Access Category Priority element in an ADDTS Request frame. The User
Priority subfield of the Intra-Access Category Priority element shall be set to the same UP as specified in the
User Priority subfield of the TS Info field. If dot11AlternateEDCAActivated is true, the Alternate Queue
subfield is used to select the appropriate EDCA transmit queue when the Access Policy subfield of the TS
Info field in the TSPEC is EDCA or HEMM. When an Intra-Access Category Priority element is associated
with a TS, the Drop Eligibility subfield is used to indicate the drop eligibility of the MSDUs of this TS.
TS may have zero or one Expedited Bandwidth Request (EBR) element associated with it. An AP uses the
parameters in the EBR to understand the precedence level requested by a non-AP STA (see R.5.4). For
example, the precedence level may be used to convey to the AP that the requested TS is for the purposes of
placing an emergency call. Support for precedence levels greater than 18 is optional for STAs.
TSPEC, PTP TSPEC, optional TCLAS, optional EBR, and optional Intra-Access Category Priority elements
are transported over the WM by the ADDTS Request frame and the ADDTS Response frame, and across the
MLME SAP by the MLME-ADDTS primitives. In addition, a TS could be created if a STA sends a resource
request to an AP or PCP prior to initiating a transition to that AP or PCP, as part of performing FST (11.33),
or in the Reassociation Request frame to that AP or PCP.
1660
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DMG TSPEC is transported over the air within DMG ADDTS Request and DMG ADDTS Response
frames and across the MLME SAP by the MLME-ADDTS primitives.
Following a successful negotiation, a TS is created, identified within the non-AP STA by its TSID and
direction, and identified within the HC by a combination of TSID, direction, and STA address.
Following a successful negotiation of a DMG TSPEC in a PBSS or in a DMG infrastructure BSS, a new
allocation is created, or an existing allocation is modified. Within a PBSS or infrastructure BSS, each
allocation is uniquely identified by a combination of allocation ID, source AID, and destination AID.
Following a successful negotiation of a PTP TSPEC or a TSPEC in a DMG BSS, the frames corresponding
to the PTP TSPEC or TSPEC are identified within the STA by the combination of TSID, requesting non-AP
DMG STA address, and responding non-AP DMG STA address and direction.
It is always the responsibility of the non-AP STA to initiate the creation of a TS regardless of its direction. A
STA that is not a DMG STA shall not transmit a PTP TSPEC or a DMG TSPEC. A non-AP DMG STA that
is not the source DMG STA of a specific TS shall not initiate the exchange of a TSPEC to the AP DMG
STA or PCP DMG STA to create that TS. Any non-AP DMG STA can issue a PTP TSPEC to any other
non-AP DMG STA to create a TS.
In the direct-link or TDLS direct-link case, it is the responsibility of the STA that is going to send the data to
create the TS. In this case, the STA negotiates with the HC to gain TXOPs that it uses to send the data. There
is no negotiation between the originator and recipient STAs concerning the TS: the originator can discover
the capabilities of the recipient (rates, Block Ack) using the DLS.
In the case of traffic relayed by an AP or PCP, the sending and receiving non-AP and non-PCP STAs may
both create individual TS for the traffic. In an infrastructure BSS, any traffic classifier created for the
downlink TS applies equally regardless of whether the source is in the same BSS or reached through the DS.
In a non-DMG infrastructure BSS, a non-AP STA may simultaneously support up to eight TSs from the HC
to itself and up to eight TSs from itself to other STAs, including the HC. The actual number it supports may
be less due to implementation restrictions.
In a non-DMG infrastructure BSS, an HC may simultaneously support up to eight downlink TSs and up to
eight uplink TSs per associated STA. The actual number it supports may be less due to implementation
restrictions.
In a DMG BSS there may be up to 16 TSs from a source DMG STA to a destination DMG STA. An
additional 16 TSs may be created between the two DMG STAs by reversing the roles of source and
destination. The actual number supported in any direction may be less due to implementation restrictions in
either the source or destination DMG STA.
In a non-DMG BSS, the traffic admitted in the context of a TSPEC can be sent using EDCA, HCCA, or
HEMM. This depends on the access policy set in the TS Info field in the TSPEC. A TSPEC request may be
set so that both HCCA and EDCA mechanisms (i.e., HEMM) are used.
In a DMG BSS, the traffic admitted in the context of a PTP TSPEC or TSPEC is sent according to the access
policy set in the TS Info field of the PTP TSPEC or TSPEC, respectively. Specifically, the traffic is sent
during one or more CBAP allocations if the access policy is EDCA, during an SP allocation if the access
policy is SPCA, and during one SP allocation as well as zero or more CBAP allocations if the access policy
is SEMM.
A DMG STA transmitting a DMG TSPEC shall set the LP SC Used subfield within the DMG TSPEC to 1 to
indicate that the low-power SC mode described in 21.7 is used during the allocation. All frames sent during
1661
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
such an allocation shall use the low-power SC mode. The STA shall set the LP SC Used subfield to 1 only if
the STA identified in the Destination AID field within the DMG TSPEC supports the low-power SC mode
(9.4.2.128.2). In all other cases, the LP SC Used subfield shall be set to 0.
When dot11SSPNInterfaceActivated is true, TSPEC processing by the HC may be subject to limitations
received from the SSPN interface. The SSPN may limit access to certain QoS priorities, and further restrict
the data rate and delay used with any priority.
11.4.2 TSPEC construction
TSPECs and DMG TSPECs are constructed at the SME, from application requirements supplied via the
SME, and with information specific to the MAC layer.
The value of the Minimum PHY Rate in a TSPEC shall satisfy the following constraints:
a) For an uplink TS, it
— Is included in dot11SupportedDataRatesTxTable and in the AP’s operational rate set, or
— Corresponds to an HT MCS included in dot11SupportedMCSTxTable, if present, and in the
AP’s operational HT MCS set, if defined, at a bandwidth and guard interval supported by the
non-AP STA on transmission and permitted in the BSS, or
— Corresponds to a VHT-MCS and NSS for which support is indicated by the combination of the
Tx VHT-MCS Map subfield in the VHT Operation parameter of the MLME-
(RE)ASSOCIATE.request primitive, if present, and the AP’s operational VHT-MCS and NSS
set, if defined, and the VHT Capabilities Information field, at a bandwidth and guard interval
supported by the non-AP STA on transmission and permitted in the BSS.
b) For a downlink TS, it
— Is included in the OperationalRateSet parameter of the MLME-JOIN.request primitive and
supported by the AP on transmission,43 or
— Corresponds to an HT MCS included in dot11SupportedMCSRxTable, if present, and
supported by the AP on transmission, at a bandwidth and guard interval supported by the non-
AP STA on reception and permitted in the BSS,44 or
— Corresponds to a VHT-MCS and NSS for which support is indicated by the Rx VHT-MCS
Map subfield in the VHT Operation parameter of the MLME-(RE)ASSOCIATE.request
primitive, if present, and the Tx VHT-MCS Map subfield of the VHT Operation element
advertised by the AP, if present, and the VHT Capabilities Information field, at a bandwidth
and guard interval supported by the non-AP STA on reception and permitted in the BSS.
c) For a bidirectional TS, it satisfies both a) and b) above.
See K.4 for a description of the parameter choice for the TSPEC.
NOTE—This standard states no requirements on how a DMG TSPEC is to be generated.
11.4.3 TS life cycle
Figure 11-14 summarizes the TS life cycle (using the HMSC syntax defined in ITU-T Recommendation
Z.120 (2004).
43How a non-AP STA determines an AP’s non-HT rate transmission support is implementation dependent. The non-AP STA might
conservatively use the basic rate set, or it might use knowledge of past transmissions by the AP, or it might use other means.
44
How a non-AP STA determines an AP’s HT MCS transmission support, if the Tx MCS Set subfield in the HT Capabilities element
advertised by the AP is equal to 0 or if the Tx Rx MCS Set Not Equal subfield in that element is equal to 1, is implementation depen-
dent. The non-AP STA might conservatively use the basic HT-MCS set, or it might use knowledge of past transmissions by the AP, or
it might use other means.
1662
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Inactive
FT Resource
Failed TS Setup
Request
Reassociation
Accepted TS Setup
Deadline
Reassociation
Active
Failed
TS Suspension TS Renegotiation
TS Renegotiation
Rx: Frame Suspended
TS Timeout TS Deletion
Figure 11-14—TS life cycle
Initially a TS is inactive. A STA shall not transmit any QoS Data frames in which the TID subfield of the
QoS Control field matches an inactive TS.
A TS may be established by a Resource Request appearing in a message as part of a fast BSS transition from
a STA. Such a TS is created in the accepted state. If the STA subsequently reassociates with this AP, then
the TS becomes active. If the STA does not reassociate prior to the expiration of the reassociation timeout,
then the TS becomes inactive.
Unless stated otherwise, in a DMG BSS, the owner of an SP is the source DMG STA for that SP, and the
owner of a TXOP is the TXOP holder. A STA that owns an SP or a TXOP is said to have the ownership of
the SP or the TXOP, respectively. The rules applicable to an SP or TXOP owner are defined in 10.36 and
11.4.
1663
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Following a successful TS setup initiated by a non-AP STA, the TS becomes active, and either the non-AP
STA or the HC may transmit QoS Data frames whose TID contains this TSID (according to the Direction
field). In the case of EDCA, the TID contains the UP value.
While the TS is active, the non-AP STA can attempt to renegotiate the parameters of the TSPEC
characterizing the TS or the parameters of the DMG TSPEC characterizing the allocation carrying the TS.
An active TS becomes inactive following a TS deletion process initiated at either non-AP STA or HC. It also
becomes inactive following a TS timeout detected at the HC, or if the HC within an AP when
dot11SSPNInterfaceActivated is true determines as defined in 11.25.5 that the non-AP STA’s TS has
exceeded the transmitted MSDU limit for the access category in which the TS was admitted. In a DMG BSS,
a TS timeout is detected at a non-AP STA and causes the TS deletion process to be initiated at the non-AP
STA. When an active TS becomes inactive, all of the resources allocated for the TS are released.
An active TS may become suspended if no activity is detected for a duration of a suspension interval. Upon
detection of activity, the TS may be reinstated. While the TS is in the suspended state, the HC shall not
reclaim the resources assigned to the TS. In a DMG BSS, a TS in which both the source and destination are
non-AP and non-PCP STAs shall not be suspended.
11.4.4 TS setup
11.4.4.1 General
A TS setup may be initiated by a non-AP STA or an AP.
11.4.4.2 Non-AP-STA-initiated TS setup
Figure 11-15 shows the sequence of messages occurring at a TS setup initiated by a non-AP STA. This
message sequence in this figure and in the subsequent figures does not show the acknowledgment.
non-AP STA non-AP STA HC/non-AP STA HC/non-AP STA
SME MAC MAC SME
loop <1,n>
MLME -
ADDTS . request
ADDTS Request
MLME -
ADDTS . indication
MLME -
ADDTS . response
ADDTS Response
MLME ADDTS . confirm
Figure 11-15—TS setup
1664
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.4.4.3 AP-initiated TS setup
Figure 11-16 shows the sequence of messages occurring at a TS setup initiated by the AP. This message
sequence in this figure and in the subsequent figures does not show the acknowledgments.
Non-AP Non-AP
STA SME STA MAC HC MAC HC SME
Higher Layer QoS
Reservation Request
(includes Higher layer
Stream ID)
MLME.ADDTS
Reserve
Request
ADDTS Reserve Request
MLME.ADDTS
Reserve
Indication
loop <0,n>
ADDTS Request
ADDTS Response
MLME.ADDTS
Reserve ADDTS Reserve Response MLME.ADDTS
Response Reserve
Confirm
Higher Layer QoS
Reservation Response
Frame includes Higher Layer Stream ID
Figure 11-16—TS setup when initiated by the AP
TS setup may be initiated by an AP in response to a request originating from higher layer protocols. An AP
in which dot11RobustAVStreamingImplemented is true shall not send ADDTS Reserve Request frames to
an associated STA that has set the RobustAVStreaming bit in the Extended Capabilities element in its
(Re)Association Request frame to 0.
The higher layer stream ID is defined by the higher layer protocol. The Higher Layer Stream ID element
shall be included in the ADDTS Reserve Request frame sent by the AP to the non-AP STA. This Higher
Layer Stream ID is used in the TS setup procedure between the AP and the non-AP STA.
The AP initiates the TS setup by sending an ADDTS Reserve Request frame that includes the Higher Layer
Stream ID element to the non-AP STA. On receipt of the ADDTS Reserve Request frame from the AP, the
non-AP STA shall perform one of the following:
a) Complete the AP-initiated TS setup procedure by sending an ADDTS Reserve Response frame that
includes the Higher Layer Stream ID corresponding to the AP-initiated TS setup procedure and with
the status code set to “SUCCESS.”
1665
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) Send an ADDTS Reserve Response frame with a status code not equal to SUCCESS and abort the
AP-initiated TS setup. The Higher Layer Stream ID field in this ADDTS Reserve Response frame
shall be set to the Higher Layer Stream ID corresponding to the AP-initiated TS setup procedure.
c) Send an ADDTS Request frame to the AP. There might be multiple ADDTS Request/ADDTS
Response exchanges between the non-AP STA and the AP, as described in 11.4.4.4, to negotiate the
TSPEC parameters. The Higher Layer Stream ID shall be included in all frames corresponding to
the AP-initiated TS setup procedure that are exchanged between the non-AP STA and the AP. The
AP-initiated TS setup procedure is completed by sending an ADDTS Reserve Response frame that
includes the Higher Layer Stream ID corresponding to the AP-initiated TS setup procedure and with
the status code set to indicate the result of the TSPEC negotiation.
NOTE 1 Stream Reservation Protocol (SRP) as described in Clause 35 of IEEE Std 802.1Q-2011 is an example of a
higher layer protocol. The IEEE 802.11 subsystem at a non-AP STA does not interpret the SRP reservation request but
simply sends it to the AP with which it is associated. A higher layer agent called Designated Multiple Stream
Registration Protocol (MSRP) Node (DMN) is co-located with the AP in the device that supports SRP. All incoming
SRP reservation requests are forwarded to the MSRP DMN. The MSRP DMN interprets the SRP reservation request and
invokes appropriate IEEE 802.11 primitives in order for the AP to invoke the MLME-ADDTSRESERVE.request
primitive. The MSRP DMN responds to the originator of the SRP Reservation request with the outcome of the
AP-initiated TS setup procedure. The procedures performed by the MSRP DMN are described in C.3 of IEEE
Std 802.1Q-2011.
NOTE 2 If the higher layer SRP Reservation Request message is lost within the IEEE 802.11 subsystem, the
corresponding retry/recovery procedure is the responsibility of the SRP protocol. These procedures are described in
Clause 35 of IEEE Std 802.1Q-2011.
11.4.4.4 TS setup procedures for both AP and non-AP STA initiation
The non-AP STA’s SME decides that a TS needs to be created. How it does this, and how it selects the
TSPEC or DMG TSPEC parameters, is beyond the scope of this standard. The SME generates an MLME-
ADDTS.request primitive containing a TSPEC or DMG TSPEC. A TSPEC or DMG TSPEC may also be
generated autonomously by the MAC without any initiation by the SME.
NOTE—Such a TPSEC or DMG TPSEC might be overridden as a result of a subsequent MLME-ADDTS.request
primitive from the SME (see 11.4.4.5)
The STA’s MLME transmits the TSPEC or DMG TSPEC in an ADDTS Request frame to the HC/non-AP
STA. If the non-AP STA’s MLME is in power save mode, the STA shall include its DMG Wakeup Schedule
element in the ADDTS Request frame variant and in the DMG ADDTS Request frame variant.
The HC/non-AP STA’s MLME receives this Management frame and generates an MLME-
ADDTS.indication primitive to its SME containing the TSPEC or DMG TSPEC.
The SME in the HC/non-AP STA decides whether to admit the TSPEC or DMG TSPEC with its associated
TCLAS element(s) (if present) and TCLAS Processing element (if present), as specified, refuse the TSPEC
or DMG TSPEC, or not admit but suggest an alternative TSPEC, DMG TSPEC, or TCLAS element(s), or
TCLAS Processing element.
A DMG STA that responds with an ADDTS Response frame and an HC may change the value of parameters
that have been set unspecified by the STA to any value that it deems appropriate, including leaving them
unspecified.
If the TSPEC or DMG TSPEC is received from a non-AP STA by an AP when
dot11SSPNInterfaceActivated is true, the HC shall use the permissions stored in dot11InterworkingEntry for
that STA in the decision to admit or deny the request (see 11.25.5.3). The SME then generates an MLME-
ADDTS.response primitive containing the TSPEC or DMG TSPEC, zero or more TCLAS element(s) (only
if present in the request) and TCLAS Processing element (only if present in the request) and a ResultCode
value. The contents of the TSPEC or DMG TSPEC field, TCLAS element(s) (if present), TCLAS
1666
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Processing element (if present), and ResultCode field contain values specified in 6.3.26.5.2. The SME may
include fewer TCLAS elements in the MLME-ADDTS.response primitive than were present in the request;
when the SME’s response includes a single TCLAS element, it shall not include a TCLAS Processing
element. If the SME changes a TCLAS element’s Classifier Type field in the MLME-ADDTS.response
primitive but is unable to suggest a value for the Classifier Mask field, it shall set that field to 0. If the SME
changes a TCLAS element’s Classifier Type field or Classifier Mask field in the MLME-ADDTS.response
primitive but is unable to suggest values for one or more Classifier Parameter subfields, it shall set those
subfields to 0.
When the HC in an AP that has dot11SSPNInterfaceActivated equal to true receives a TSPEC, the AP shall
inspect it to determine the requested access policy, user priority, and mean data rate as follows:
a) The access category shall be determined from the user priority according to Table 10-1. For a TS to
be admitted when the requested access policy is EDCA, both of the following shall be true:
1) The field corresponding to this access category in dot11NonAPStationAuthAccessCategories
from the non-AP STA’s dot11InterworkingEntry is equal to 1.
2) The sum of the mean data rate of all of the requesting STA’s active TSs in this access category
plus the mean data rate in the TSPEC is less than or equal to the non-AP STA’s
dot11InterworkingEntry for dot11NonAPStationAuthMaxVoiceRate, dot11NonAPStation-
AuthMaxVideoRate, dot11NonAPStationAuthMaxBestEffortRate, or dot11NonAPStation-
AuthMaxBackgroundRate depending on whether the derived access category is AC_VO,
AC_VI, AC_BE or AC_BK, respectively.
b) For a TS to be admitted when the requested access policy is HCCA, all of the following shall be
true:
1) The dot11NonAPStationAuthHCCAHEMM value is true.
2) The sum of the mean data rate of all of the requesting STA’s active TSs having
access policy set to HCCA plus the mean data rate in the TSPEC is less than
or equal to dot11NonAPStationAuthMaxHCCAHEMMRate in the non-AP STA’s
dot11InterworkingEntry.
3) The delay bound that will be provided by the HC in the TSPEC response is less than or equal to
dot11NonAPStationAuthHCCAHEMMDelay in the non-AP STA’s dot11InterworkingEntry.
If the DMG TSPEC is admitted, the AP or PCP shall set the ResultCode to SUCCESS_STA_IN_PS_MODE
if the STA identified by destination AID is in power save mode and shall include in the ADDTS Response
frame the DMG Wakeup Schedule element of the destination DMG STA if one is established. In this case,
the AP or PCP should defer including the TS schedule in the Extended Schedule element until both source
DMG STA and destination DMG STA are in active mode.
The HC/non-AP STA’s MLME transmits an ADDTS Response frame containing this TSPEC or
DMG TSPEC and status. The encoding of the ResultCode values to Status Code field values is defined in
Table 9-46. The AP or PCP shall transmit the ADDTS Response frame to the STAs identified as source and
destination AID of the DMG TSPEC contained in the ADDTS Request frame if the ADDTS request is sent
by a non-AP and non-PCP STA. If the ResultCode is SUCCESS, the AP or PCP shall announce the creation
of the allocation by setting the Allocation ID subfield in the TSPEC element sent in the ADDTS Response
frame to a nonzero value and also by delivering the Extended Schedule element as defined in 10.36.6. In an
AP when dot11SSPNInterfaceActivated is true, the HC shall set the dot11NonAPStationAddtsResultCode
in the non-AP STA’s dot11InterworkingEntry equal to the ResultCode.
The STA’s MLME receives this Management frame. It generates an MLME-ADDTS.confirm primitive to
its SME containing the TSPEC or DMG TSPEC and status.
The SME decides whether the response meets its needs. How it does this is beyond the scope of this
standard. A SME receiving a modified TCLAS element having a Classifier Mask field equal to 0 or
1667
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Classifier Parameter subfields equal to 0 should regard these values as meaning that no suggested value has
been provided by the HC.
— If the result code is SUCCESS, the TS enters into an active state.
— If the result code is REJECTED_WITH_SUGGESTED_BSS_TRANSITION, the non-AP STA may
try to transition to other BSSs. In case that the non-AP STA is recommended to transition to other
BSSs, it should do so according to the process defined in 11.24.7. Once the transition is completed,
it should proceed with a TS setup process with the new HC.
— Otherwise, the whole process can be repeated using the same TSID and direction, a modified
TSPEC or DMG TSPEC, optional TCLAS element(s), and an optional TCLAS Processing element
until the SME decides that the granted medium time is adequate or inadequate and cannot be
improved.
The above rules also apply to the negotiation of the PTP TSPEC and to the negotiation of the DMG TSPEC.
The parameters that are set for a TS may be renegotiated in a similar manner (see 11.4.4.5).
If the HC/PCP grants medium time for an ADDTS Request frame with the Ack Policy subfield equal to
Block Ack and the Direction field equal to either downlink or bidirectional, then it shall initiate a block ack
negotiation by sending an ADDBA Request frame to the STA that originated the ADDTS Request frame. If
a non-DMG STA is granted medium time for an ADDTS Request frame with the Ack Policy subfield equal
to Block Ack and the Direction field equal to other than downlink, then it shall initiate a block ack
negotiation by sending an ADDBA Request frame to the recipient of the TS.
In a non-DMG BSS, the combination of the TSID and Direction subfields identify the TS, in the context of
the STA, to which the TSPEC applies. A bidirectional link request is equivalent to a downlink TS and an
uplink TS, each with the same TSID and parameters. In a DMG BSS, the combination of the TSID, source
DMG STA AID, destination DMG STA AID, and Direction subfields identifies the TS, in the context of the
non-AP STA, to which the TSPEC applies.
The same TSID may be used for multiple TSs at different STAs. A STA can use the same TSID subfield
value for a downlink TSPEC and either an uplink or a direct-link TSPEC at the same time. In a non-DMG
BSS, a non-AP STA shall not use the same TSID for both uplink and direct-link TS. In a DMG BSS, a non-
AP STA as a source DMG STA can use the TSID subfield value for an uplink PTP TSPEC, and at the same
time the non-AP STA as a destination DMG STA can use the same TSID subfield value for a downlink PTP
TSPEC.
If the TS Info Ack Policy subfield of a TSPEC or DMG TSPEC element is Block Ack and the type of Block
Ack policy is unknown to the HC, the HC assumes, for TXOP scheduling, that the immediate block ack
policy is being used (see 10.24).
An HC shall be capable of receiving an ADDTS Request frame that contains a TCLAS element and capable
of generating an indication that contains this as a parameter.
When a STA requests service at a higher priority than authorized by its dot11InterworkingTableEntry, the
HC may provide a suggested TSPEC or DMG TSPEC with a data rate and lower priority that would be
authorized. Usage of the TSPEC in an Interworking environment is described in Annex K.
A STA may include a U-PID element in ADDTS Request, DMG ADDTS Request, ADDTS Response and
DMG ADDTS Response frames it transmits. The U-PID element is used to indicate the upper layer protocol
responsible for handling MSDUs corresponding to the TID indicated within the frame carrying the U-PID
element. If a U-PID element is not included in an ADDTS Request, DMG ADDTS Request, ADDTS
Response or DMG ADDTS Response frame, MSDUs corresponding to the TID contain an LLC header that
is used for upper layer protocol identification.
1668
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A U-PID element shall not be included in an ADDTS Response or DMG ADDTS Response frame if a U-
PID element was not included in the corresponding ADDTS Request or DMG ADDTS Request frame. If a
U-PID element was included in an ADDTS Request or DMG ADDTS Request frame, the same U-PID
element shall be included in the corresponding ADDTS Response or DMG ADDTS Response frame if that
frame has a Status Code of SUCCESS. The Status Code field shall be set to REJECT_U-PID_SETTING in
the ADDTS Response or DMG ADDTS Response frame if the request is rejected frame due to the setting of
the U-PID element received; this frame may contain an alternative U-PID element that is acceptable to the
STA sending the ADDTS Response or DMG ADDTS Response frame.
11.4.4.5 TS renegotiation
A non-AP STA may attempt to modify the parameters of a TSPEC or DMG TSPEC by
transmitting an ADDTS Request or DMG ADDTS Request frame. If the Status Code in the
corresponding ADDTS Response or DMG ADDTS Response frame is SUCCESS, then any
TSPEC with the same TSID or DMG TSPEC with the same allocation ID is overridden with the
TSPEC or DMG TSPEC in that frame, the HC and non-AP STA shall reset the inactivity interval
timer, and the HC shall reset the suspension interval timer.
11.4.5 TS setup by resource request during a fast BSS transition
A QoS STA may transmit a TSPEC as part of a RIC-Request in a resource request message. The SME in the
hybrid coordinator (HC) decides whether to accept the TSPEC as specified, or refuse the TSPEC, or not
accept but suggest an alternative TSPEC. It then generates a RIC-Response, according to the procedures
given in 13.11.
Each TS established by this resource request is placed in the accepted state. This state is an intermediate
state between inactive and active. In the accepted state, the inactivity and suspension timers shall not be
started for the TS. For a TS based on hybrid coordination function (HCF) controlled channel access
(HCCA), the HC shall not generate CF-Poll for the TS.
The SME may take the resource/timing requirements of the TS in the accepted state into consideration
before assigning any further resources to any other admitted or accepted TS, and in calculating the available
admission capacity for the BSS Load element.
The TS is moved to the active state once the STA performs a reassociation to the AP (see 13.11.3). Once the
TS becomes active, the inactivity and suspension timers are started. In an AP when
dot11SSPNInterfaceActivated is true, the HC shall set the dot11NonAPStationAddtsResultCode in the non-
AP STA’s dot11InterworkingEntry equal to the Status Code in the corresponding RDE.
If the reassociation timer times out and the TS is not yet in the active state, the TS goes back to the inactive
state.
11.4.6 PSMP management
A STA may attempt to create a scheduled PSMP session with its AP only if the AP has the S-PSMP Support
field in the Extended Capabilities element equal to 1.
The TSPEC reserves resources within the AP and modifies the AP’s scheduling behavior. The parameters in
the TSPEC can be grouped into two categories: PSMP scheduling and PSMP reservation. The scheduling
parameters are used by the AP to schedule a suitable SI. The reservation parameters are used by the AP to
reserve time in the PSMP-UTT and PSMP-DTT.
The service start time and SI specify the PSMP schedule in the response’s Schedule element. All other
parameters result in a reservation for the PSMP-UTT and PSMP-DTT within the scheduled PSMP sequence.
1669
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An AP shall terminate the PSMP session only when the last TS associated with the particular PSMP session
is terminated.
Once created, a PSMP session can be extended by another TSPEC setup. A STA that has an established
PSMP session may issue an additional TSPEC request with the following:
— The Aggregation field set to 1
— The Scheduled field set to 1 and APSD field set to 0 (S-PSMP)
— The Minimum Service Interval and Maximum Service Interval fields both set to the Service Interval
field value from the Schedule element specified when the PSMP session was established
The AP shall return an identical Schedule element for all TSPEC response frames related to the same PSMP
session.
NOTE—A STA that does not have an established PSMP session might send a TSPEC request specifying S-PSMP
session with the same SI. The AP is free to choose between aggregating this request with an existing PSMP session of
the same SI or creating a new PSMP session.
The parameters of a TS already associated with the PSMP session may be changed; however, the SI shall not
be changed. The start time of existing STAs in the PSMP schedule shall not be changed by the addition of a
TSPEC from a new STA.
A TSPEC that reserves resources for a STA under scheduled PSMP shall have the APSD and Scheduled
fields set to indicate Scheduled PSMP as defined in Table 9-142.
The non-AP STA’s SME decides that a PSMP session needs to be established. How it makes this decision
and how it selects the related TSPEC parameters are beyond the scope of this standard.
The Minimum Service Interval field of the TSPEC element of an ADDTS Request frame shall be a multiple
of the SI granularity indicated by the AP in its Extended Capabilities element.
11.4.7 Failed TS setup
There are three possible types of failed TS setup:
a) The transmission of ADDTS Request frame failed.
b) No ADDTS Response frame is received from the HC/non-AP STA (e.g., because of delay due to
congestion or because the response frame cannot be transmitted).
c) An ADDTS Response frame is received that contains the Status Code field equal to
REJECTED_FOR_DELAY_PERIOD. In this case, if the Delay field of the TS Delay element of the
ADDTS Response frame is nonzero, the STA that transmitted the ADDTS Request frame shall not
transmit another ADDTS Request frame to the same AP until the time indicated by the Delay field
has elapsed.
Figure 11-17 summarizes the two cases. In either case in a non-DMG BSS, if the request is not for an
existing TS, the SME shall issue a DELTS.request to the HC specifying the TSID and direction of the failed
request just in case the HC had received the request and it was the response that was lost. In either case in a
DMG BSS, if the request is not for an existing allocation or TS, the SME shall issue a DELTS.request to the
non-AP STA specifying the allocation ID or TSID and destination DMG STA of the failed request just in
case the AP or PCP had received the request and it was the response that was lost.
1670
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
non-AP non-AP HC/non-AP STA HC/non-AP STA
STA SME STA MAC MAC SME
MLME-ADDTS.request
ADDTS Request
Failed
ADDTS Request
MLME-DELTS.request Failed
DELTS Request
MLME-DELTS.indication
(a) case 1
non-AP non-AP HC/non-AP STA HC/non-AP STA
STA SME STA MAC MAC SME
MLME-ADDTS.request
ADDTS Request
MLME-ADDTS.indication
MLME-ADDTS.response
ADDTS Response
Failed
MLME-DELTS.request
DELTS Request
MLME-DELTS.indication
(b) case 2
Figure 11-17—Failed TS setup detected within non-AP STA’s MLME
11.4.8 Data transfer
After the setup of a TSPEC or PTP TSPEC, MSDUs are classified above the MAC and are sent to the MAC
through the MAC SAP using the MA-UNITDATA.request primitive with the priority parameter encoded to
the TID.
In a DMG BSS, MSDUs are transmitted using QoS Data frames. During each CBAP allocation, the MAC
delivers MSDUs based on the priority of the transmitted QoS Data frames. The MAC can transmit all
MSDUs having a TSID with an associated TSPEC with an access policy of EDCA or SEMM, provided that
the source AID of the CBAP allocation is equal to the source AID of the TS, or the source AID of the CBAP
allocation is equal to broadcast AID, or the destination AID of the CBAP matches the destination AID of
the TS.
During each SP allocation, the MAC delivers MSDUs whose TSIDs identify TSPECs that have been set up
to use the SP allocation. Relative prioritization of multiple TSPECs mapped to the same SP allocation is
implementation dependent and outside the scope of this standard.
1671
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When an MSDU arrives from the MAC SAP with a TSID for which there is no associated TSPEC, the
MSDUs shall be sent using EDCA with the access category AC_BE.
The generation of the associated TID is done by a classifier above the MAC, and it may use the associated
TCLAS elements if any are present. When there are multiple TCLAS elements and if the Processing
subfield of TCLAS Processing element is 0, the priority parameter in the associated MA-
UNITDATA.request primitive is set to TID if the classifier matches the parameters in all of the TCLAS
elements associated with the TS. When there are multiple TCLAS elements and if the Processing subfield of
the TCLAS Processing element is 1, the priority parameter in the associated MA-UNITDATA.request
primitive is set to TID if the classifier matches the parameters in at least one of the TCLAS elements
associated with the TS. When there is no TCLAS element and if the Processing subfield of the TCLAS
Processing element is 2, the priority parameter in the associated MA-UNITDATA.request primitive is set to
TID if the classifier cannot match the parameters to any of the TCLAS elements. An incoming MSDU that is
not classified to a particular TS may be classified to another active TS based on the frame classifier for that
TS. If, however, all of the frame classifiers for the active TS have been exhausted, the MSDU does not
belong to any active TS and is classified to be a best-effort MSDU. See 5.1.1.3 for the treatment of an
MSDU with a TSID for which there is no associated TSPEC.
When an MSDU is classified using a TCLAS element, the original UP cannot be recovered by the receiver.
If dot11AlternateEDCAActivated is true, if an Intra-Access Category Priority element was provided when
the TS was created, and if the Access Policy subfield of the TS Info field in the TSPEC is EDCA or HEMM,
the value from the Alternate Queue subfield is used to select the appropriate EDCA transmit queue.
If an Intra-Access Priority element was provided when the TS was created, the Drop Eligibility subfield is
used to determine the drop eligibility of the MSDU.
11.4.9 TS deletion
11.4.9.1 Deletion of a TS established between an HC, DMG AP, or PCP and a non-AP and
non-PCP STA
The STA may delete a TS in either of two ways: using non-PCP / non-AP STA initiation or using HC, DMG
AP or PCP initiation. In both methods, the SME entity above the MAC generates an MLME-DELTS.request
primitive specifying the TS to be deleted and the reason for deleting the TS. This causes the MAC to send a
DELTS frame. The encoding of ReasonCode values to Reason Code field values is defined in Table 9-45.
Having transmitted a DELTS frame, the initiating MAC deletes the TS identified in the DELTS frame when
it receives an Ack frame that responds to this DELTS frame. There is no Management frame response.
Figure 11-18 shows the case of TS deletion initiated by a non-PCP and non-AP STA and the case of TS
deletion initiated by an HC, DMG AP, or PCP.
An HC should not delete a TSPEC without a request from the SME, except for inactivity (see 11.4.10) or an
HC service change that precludes the HC from continuing to meet the requirements of the TSPEC.
All TSPECs that have been set up shall be deleted upon disassociation and reassociation. Reassociation
causes the non-PCP and non-AP STA and HC, DMG AP, or PCP to clear their states, and the non-PCP and
non-AP STA may then reinitiate the setup.
1672
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Non-PCP and Non-AP Non-PCP and Non-AP HC, DMG AP, or PCP HC, DMG AP, or PCP
STA SME STA MAC MAC SME
MLME - DELTS . request
DELTS Request
MLME -
DELTS . indication
(a) Initiated by non-PCP and non-AP STA
HC, DMG AP, or PCP HC, DMG AP, or PCP Non-PCP and Non-AP Non-PCP and Non-AP
SME MAC STA MAC STA SME
MLME - DELTS . request
DELTS Request
MLME -
DELTS . indication
(b) Initiated by HC, DMG AP, or PCP
Figure 11-18—TS deletion
11.4.9.2 Peer-to-peer TS deletion and deletion of an allocation
This subclause describes deletion of a TS established between non-AP and non-PCP DMG STAs (i.e.,
established using a PTP TSPEC) and deletion of an allocation (i.e., established using a DMG TSPEC).
In this subclause the following procedures for deletion of an allocation or TS are described:
— Deletion of a TS established using a PTP TSPEC by either source or destination STAs
— Deletion of an allocation by either source or destination STAs of that allocation, which might result
in the deletion of one or more associated TSs
— Deletion of an allocation (either SP or CBAP) by the AP or PCP
The SME entity above the MAC generates an MLME-DELTS.request primitive specifying either the TS or
the allocation to be deleted and the reason for deleting the TS or allocation, respectively. If generated within
a non-AP and non-PCP STA, this primitive causes the MAC to send a single DELTS frame. If generated
within an AP or PCP, this primitive causes the MAC to send one or two DELTS frames, as described below.
The encoding of ReasonCode values to Reason Code field (see 9.4.1.7) values is defined in Table 9-45.
A STA that receives an MLME-DELTS.request primitive for a TS that was established using a PTP TSPEC
causes the MAC to send a DELTS frame to the peer STA of the TS. This is shown in Figure 11-19.
NOTE—The AP or PCP is unaware of the deletion of the TS.
1673
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Non-PCP/Non-AP Non-PCP/Non-AP Non-PCP/Non-AP Non-PCP/Non-AP
STA SME STA MAC STA MAC STA SME
MLME - DELTS . request
DELTS Request
MLME -
DELTS . indication
Figure 11-19—Deletion of a TS established using a PTP TSPEC
A non-AP and non-PCP STA that receives an MLME-DELTS.request primitive for an allocation causes the
MAC to send a DELTS frame to the AP or PCP. If it is transmitted by the STA identified by the Source AID
of the allocation and if the Destination AID of the allocation is different from the broadcast AID, the AP or
PCP shall send a DELTS frame to the STA identified by the Destination AID of the allocation. If it is
transmitted by the STA identified by the Destination AID of the allocation and if the Source AID of the
allocation is different from the broadcast AID, the AP or PCP shall send a DELTS frame to the STA
identified by the Source AID of the allocation. The AP or PCP shall also delete the scheduling information
corresponding to the allocation, identified by the DMG Allocation Info field of the DELTS frame.
Figure 11-20 shows the deletion of an allocation in which both Source AID and Destination AID are not the
broadcast AID.
Source or Source or Peer Peer
Destination Destination Non-AP/ Non-AP/
Non-AP/ Non-AP/ AP/PCP AP/PCP Non-PCP Non-PCP
Non-PCP Non-PCP MAC HC SME STA MAC STA SME
STA SME STA MAC
MLME-DELTS.request
(allocation)
DELTS Request DELTS Request
(allocation) (allocation)
MLME-DELTS.indication MLME-DELTS.indication
(allocation) (allocation)
STA deletes any resources associated with STA deletes any resources associated with STA deletes any resources associated with
allocation allocation allocation
Figure 11-20—Deletion of an allocation in which both Source AID and Destination AID
are not the broadcast AID
An AP or PCP that receives an MLME-DELTS.request primitive for an allocation causes the MAC to send
one or two DELTS frames. If the Destination AID of the allocation is different from the broadcast AID, the
AP or PCP shall send a DELTS frame to the STA identified by the Destination AID of the allocation. If the
Source AID of the allocation is different from the broadcast AID, the AP or PCP shall send a DELTS frame
to the STA identified by the Source AID of the allocation. The AP or PCP shall also delete the scheduling
information corresponding to the allocation, identified by the DMG Allocation Info field of the DELTS
frame.
An SME that deletes an allocation (using a MLME-DELTS.request primitive) or is notified that an
allocation has been deleted (by receiving an MLME-DELTS.indication primitive) also locally deletes (i.e.,
updates it own resources, but does not cause any MAC frames to be transmitted) any TS that is dependent on
that allocation as follows:
1674
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Deleting an SP allocation shall also locally delete any TS with access policy SPCA or SEMM using
the allocation.
— Deleting a CBAP allocation with Source AID different from the broadcast AID shall also locally
delete any TS with access policy EDCA using the allocation.
— Deleting a CBAP allocation with Source AID equal to the broadcast AID shall also locally delete
any TS with access policy EDCA using the allocation, unless there is another CBAP allocation the
TS could use.
A non-AP and non-PCP STA that associates, disassociates or reassociates (except for reassociation to the
same AP) shall locally delete all existing allocations and all TSs that have been established using a PTP
TSPEC.
An AP or PCP that receives an MLME-ASSOCIATE.indication, MLME-REASSOCIATE.indication
(except when the MLME-REASSOCIATE.indication primitive has this AP’s MAC address in the
CurrentAPAddress parameter) or MLME-DISASSOCIATE.indication primitive from a STA (the
“resetting” STA) with which it has an existing association shall locally delete all allocations that have been
established by the resetting STA using a PTP TSPEC. When deleting an allocation in which the Source AID
or Destination AID correspond to the resetting STA and the peer STA is not identified by the broadcast AID,
the AP or PCP shall send a DELTS to the peer STA to delete that allocation.
NOTE—If both Source AID and Destination AID are equal to the broadcast AID, the AP or PCP transmits no DELTS
frames. It deletes scheduling information corresponding to the allocation, which is reflected in its subsequent
transmission of frames containing an Extended Schedule element.
A STA that generates an MLME-ASSOCIATE.request, MLME-REASSOCIATE.request (except when the
MLME-REASSOCIATE.request primitive has the target AP’s MAC address in the CurrentAPAddress
parameter) or MLME-DISASSOCIATE.request primitive shall locally delete all allocations and all TSs that
have been established using a PTP TSPEC.
NOTE—Reassociation causes a STA to clear any state related to allocations and TSs that have been established using a
PTP TSPEC. A non-PCP and non-AP STA might need to repeat the establishment of any allocations or TSs after
reassociation needed to support applications active before the reassociation.
In all of the cases listed above, the TS or allocation is deleted within the initiating MAC when the Ack frame
to the Action frame is received. No Action frame response is generated.
11.4.10 TS timeout
TS timeout is detected within the HC/non-AP STA’s MAC when no traffic is detected on the TS within the
inactivity timeout specified when the TS was created.
For an uplink TS in a non-DMG BSS or for a TS that has the AP or PCP as the destination DMG STA in a
DMG BSS, the timeout is based on the arrival of received MSDUs that belong to the TS, after any
decryption and reassembly.
For a downlink TS in a non-DMG BSS or for a TS that has the AP or PCP as the source DMG STA in a
DMG BSS, the timeout is based on the following:
— Arrival of valid MA-UNITDATA.request primitives using this TS at the MAC SAP when the QoS
Data frames are sent with the Ack Policy subfield equal to No Ack
— Confirmation of correctly sent MSDUs that belong to the TS within the MAC when the QoS Data
frames are sent with the Ack Policy subfield set other than to No Ack
In a DMG BSS and in the case of a TS that is established between non-AP STAs (PTP TSPEC), the timeout
of the recipient is based on the arrival of MSDUs that belong to the TS within the MAC after any decryption,
A-MSDU unpacking, and reassembly.
1675
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In a TS established between non-AP STAs (PTP TSPEC), the timeout of the originator is based on the
following:
— Arrival of valid MA-UNITDATA.request primitives using this TS at the MAC SAP when the QoS
Data frames are sent with the Ack Policy subfield set to No Ack
— Confirmation of correctly sent MSDUs that belong to the TS within the MAC when the QoS Data
frames are sent with the Ack Policy subfield set other than to No Ack
In a direct-link TS in a non-DMG BSS, inactivity is considered to have happened if one of the two following
events occurs:
— The HC transmits a QoS CF-Poll frame and the polled STA returns a QoS Null immediately after a
SIFS that contains a QoS Control field in which the Queue Size subfield contains 0.
— The HC transmits a QoS CF-Poll frame, and no QoS Null frame is received within the granted
TXOP duration that indicates the queue size for the related TSID. This is to confirm that the STA is
actually using the assigned TXOP for the given TSID.
In a non-DMG BSS, any other use of a polled TXOP delivered to the STA is considered to be activity on all
direct-link TS associated with that STA. Detection of inactivity of this type is optional.
In response to an inactivity timeout, an HC shall send a DELTS frame to the STA with the Reason Code set
to TIMEOUT and inform its SME using the MLME-DELTS.indication primitive. In response to an
inactivity timeout, a DMG AP shall send a DELTS frame to the non-AP DMG STA with the result code set
to TIMEOUT and inform its SME using the MLME-DELTS.indication primitive. In response to an
inactivity timeout, a PCP shall send a DELTS frame to the non-PCP DMG STA with the result code set to
TIMEOUT and inform its SME using the MLME-DELTS.indication primitive.
In a DMG BSS when a TS is established between non-AP STAs (PTP TSPEC), then in response to a TS
timeout detected within the originator non-AP STA the non-AP STA shall send a DELTS frame to the
recipient non-AP STA with the result code set to TIMEOUT and inform its SME using the MLME-
DELTS.indication primitive. If the TS timeout is detected within the recipient non-AP STA, the STA shall
send a DELTS frame to the originator non-AP STA with the result code set to TIMEOUT and inform its
SME using the MLME-DELTS.indication primitive.
The case of uplink TS timeout is shown in Figure 11-21.
11.4.11 TS suspension
TS suspension occurs within the HC’s MAC when no traffic is detected on the TS within the suspension
interval specified when the TS was created. In the suspended state, the generation of QoS (+)CF-Poll frames
is stopped for the related TS.
11.4.12 TS reinstatement
A suspended TS may be reinstated following activity for that TS.
For uplink and direct link, a suspended TS may be reinstated by a STA by sending a QoS Data or QoS Null
frame. This frame may be sent at the highest priority using EDCA. The generation of successive QoS (+)CF-
Poll frames shall then be resumed by the HC.
For downlink, a suspended TS is reinstated by the HC when the AP receives an MSDU from a higher layer.
1676
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
non - AP non - AP HC STA HC STA
STA SME STA MAC MAC SME
QoS CF - poll
I na ctivity
Ti me r
QoS CF -poll
QoS CF - poll
DELTS QoS Action
Request
MLME -DELTS.indication
MLME -DELTS.indication
(a) No response from STA
non -AP non -AP HC STA HC STA
STA SME STA MAC MAC SME
QoS CF - poll
Inactiv ity
QoS DATA Tim er
Ack
QoS Null
QoS CF - poll
QoS Null
QoS CF -poll
QoS Null
DELTS QoS Action
Request
MLME -DELTS.indication
MLME -DELTS.indication
(b) No Data frames from STA
Figure 11-21—TS timeout
1677
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.4.13 DMG allocation formats
11.4.13.1 General
A DMG STA manages allocations and TSs as described in 11.4.1 to 11.4.14. Using the DMG TSPEC, a
DMG STA can indicate two types of allocation scheduling: isochronous and asynchronous. It should
establish an isochronous allocation if it needs periodic access to the channel and does not expect to change
the amount of time allocated frequently. It should establish an asynchronous allocation if it expects to make
requests for channel time and wishes to reserve a minimum amount of channel time to satisfy for those
requests when they occur.
11.4.13.2 Isochronous allocations
In order to request the setup of an isochronous allocation, a DMG STA shall set the Allocation Format field
in the DMG TSPEC element to 1.
Following the successful admittance of a DMG TSPEC with an isochronous allocation, the AP or PCP
should allocate time in the beacon interval to meet the periodicity and minimum allocation requirements
specified in the DMG TSPEC element.
Referring to fields in the DMG TSPEC element, the AP or PCP should check that over each Allocation
Period the sum of the time allocations is at least the Minimum Allocation. In addition, the AP or PCP should
check that each individual allocation has a minimum duration of at least Minimum SP Duration. See
9.4.2.134, 10.36.6, and 10.36.6.4.
With an isochronous DMG TSPEC, the allocation period defines the period over which the channel time
allocation repeats. The scheduler should check that at least the minimum allocation is made within each
allocation period. The allocation may be composed of multiple SPs. The scheduler also checks that each SP
making up the allocation is no shorter than the minimum SP duration. The scheduler is free to position the
SPs that make up the allocation anywhere in the allocation period. The scheduler may allocate up to the
maximum allocation each allocation period if resources permit.
11.4.13.3 Asynchronous allocations
A DMG STA uses the SPR frame to request channel time for asynchronous traffic.
For each TID, source DMG STA, and destination DMG STA tuple, the AP or PCP can maintain the amount
of outstanding channel time that needs to be allocated. Each time it receives an SPR frame, the amount of
outstanding channel time is set to the value received in the SPR frame from the source DMG STA for the
identified TID and destination DMG STA. The amount of outstanding channel time is decreased by the
amount allocated when channel time is scheduled for that TID, source DMG STA, and destination DMG
STA tuple.
A DMG STA may also use a DMG TSPEC to reserve resources for asynchronous traffic. In this case, the
STA shall set the Allocation Format field in the DMG TSPEC element to 0. The AP or PCP should admit an
asynchronous DMG TSPEC only if it is able to meet the minimum allocation requirements specified in the
DMG TSPEC element.
With an asynchronous DMG TSPEC, a DMG STA registers the minimum allocation it expects within the
allocation period while an SP request is in effect that is greater than the minimum allocation specified. In
addition, the STA expects that each allocation is at least of duration specified by the Minimum Duration
field of the DMG TSPEC, provided the outstanding SP request is at least that long. In admitting a DMG
TSPEC, the AP or PCP should check that there are sufficient resources available to meet the TSPEC
requirements.
1678
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.4.14 PTP TS operation
The ADDTS Request frame containing the PTP TSPEC may be sent to the peer non-AP DMG STA directly
or through a DMG AP or PCP.
A non-AP DMG STA may add TSs to an existing allocation with a peer non-AP DMG STA. To do this, the
non-AP DMG STA transmits an ADDTS Request frame to the peer STA to include the additional TS. The
ADDTS Request frame shall contain a PTP TSPEC with the Allocation ID subfield set to indicate the
allocation for the additional TS. A TS with EDCA access policy does not need to be added to any CBAP
allocation and can use any CBAP allocation as long as the source AID of the CBAP allocation matches the
source AID of the TS, or the source AID of the CBAP allocation is equal to the broadcast AID, or the
destination AID of the CBAP matches the destination AID of the TS.
A non-AP DMG STA transmits an ADDTS Request frame to a peer non-AP DMG STA to add a TS to an
existing allocation and to possibly communicate traffic-specific parameters such as A-MSDU subframe and
Maximum MSDU Size with the peer non-AP DMG STA. The non-AP DMG STA may transmit the ADDTS
Request frame directly to the peer STA or to the AP or PCP. In the latter case, the ADDTS Request frame
shall contain a TCLAS element with the classifier type set to Ethernet parameters; the Source Address field
shall contain the address of the STA that sends the ADDTS Request frame; and the Destination Address
field shall contain the address of the peer STA, which is used by the AP or PCP to forward to the peer STA.
The AP STA or PCP STA shall forward the received ADDTS Request frame to the STA with Address equal
to the Destination Address field of the Classifier. If an ADDTS Response frame is received by the AP STA
or PCP STA in response to the forwarded ADDTS Request frame, then the AP STA or PCP STA shall
forward the ADDTS Response frame to the STA with Address equal to the Source Address field of the
Classifier. The AP DMG STA and the PCP DMG STA shall not change the content of the elements included
in the ADDTS Request and ADDTS Response frames.
If a STA sets the Direction field to a value equal to downlink in the PTP TSPEC included in the ADDTS
Request frame, the parameters apply to the STA as the destination DMG STA of that TS. For example, in
this case, the Maximum MSDU Size field indicates that the STA is not able to receive MSDUs longer than
the value presented in the MSDU Size field. Similarly, if the Direction field indicates uplink, the parameters
apply to the STA as the source DMG STA of that TS. In this case, the STA that issued the ADDTS Request
frame does not send MSDUs longer than the value of the Maximum MSDU Size field.
11.5 Block ack operation
11.5.1 Introduction
Block ack may be set up at the MAC (see 10.24.2) or by the initiation of SME. The setup and deletion of
block ack at the initiation of the SME is described in this subclause.
11.5.2 Setup and modification of the block ack parameters
11.5.2.1 General
The procedures for setting up and modifying the block ack parameters are described in 11.5.2.2 and
11.5.2.3, respectively, and illustrated in Figure 11-22.
1679
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Originator Recipient
STA SME STA MAC STA MAC STA SME
MLME -
ADDBA . request
ADDBA Request
MLME -
ADDBA . indication
MLME -
ADDBA . response
ADDBA Response
MLME -
ADDBA . confirm
Figure 11-22—Block ack setup
11.5.2.2 Procedure at the originator
Upon receipt of an MLME-ADDBA.request primitive, an initiating STA that intends to send QoS Data
frames under the block ack mechanism shall set up the Block Ack using the following procedure:
a) If the initiating STA is an HT STA, is a member of an IBSS, and has no other existing block ack
agreement with the recipient STA, then the initiating STA shall transmit a Probe Request frame to
the recipient STA and shall not transmit an ADDBA Request frame unless it receives a Probe
Response frame from the recipient.
NOTE—When the block ack agreement is being established between a non-AP STA and its AP, then the
originator and the recipient have exchanged capability information during the association exchange that allows
them to determine whether the other STA is an HT STA. If the STA is establishing a block ack agreement with
another STA through DLS, then the DLS setup procedure includes the exchange of capability information that
allows both STAs to determine whether the other STA is an HT STA.
b) If the peer STA is a non-DMG STA, check whether the intended peer STA is capable of
participating in the block ack mechanism by discovering and examining its Delayed Block Ack and
Immediate Block Ack capability bits. If the recipient is capable of participating, the originator sends
an ADDBA Request frame indicating the TID and the buffer size. If the recipient is capable of
participating and the GCRGroupAddress parameter of the MLME-ADDBA.request primitive is
present, the originator sends an ADDBA Request frame that includes a GCR Group Address
element. All DMG STAs are capable of participating in the block ack mechanism.
c) If an ADDBA Response frame is received with the matching dialog token and the TID and with a
status code equal to SUCCESS, the STA has established a block ack mechanism with the recipient
STA; and the MLME shall issue an MLME-ADDBA.confirm primitive indicating the successful
completion of the Block Ack setup.
d) If an ADDBA Response frame is received with the matching dialog token and the TID and with a
status code not equal to SUCCESS, the STA has not established a block ack mechanism with the
recipient STA; and the MLME shall issue an MLME-ADDBA.confirm primitive indicating the
failure of the Block Ack setup.
1680
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.5.2.3 Procedure at the recipient
A recipient shall operate as follows in order to support Block Ack initialization and modification:
a) When an ADDBA Request frame is received from another STA, the MLME shall issue an MLME-
ADDBA.indication primitive.
b) Upon receipt of the MLME-ADDBA.response primitive, the STA shall respond by an ADDBA
Response frame with a result code as defined in 9.6.5.3.
1) If the result code is SUCCESS, the block ack agreement is considered to be established with the
originator. Contained in the frame are the type of Block Ack and the number of buffers that
have been allocated for the support of this block.
2) If the result code is REFUSED, the block ack agreement is not considered to have been
established.
The encoding of ResultCode values to Status Code field values is defined in Table 9-46.
11.5.2.4 Procedure common to both originator and recipient
Once a block ack agreement has been successfully established between two STAs, the type of agreement
thus established is dependent on the capabilities of the STAs and the contents of the ADDBA Request and
ADDBA Response frames used to establish this agreement as defined in Table 11-4 for non-DMG STAs
and in Table 11-5 for DMG STAs.
Table 11-4—Types of block ack agreement based on capabilities and ADDBA conditions for
non-DMG STAs
Type of block ack
Capabilities condition ADDBA condition
agreement
One or both of the STA are non-HT. Block Ack Policy subfield equal to 1 Immediate
See NOTE 1.
Block Ack Policy subfield equal to 0 Delayed
Both STAs are HT STAs. Block Ack Policy subfield equal to 1 HT-immediate
Both STAs are HT STAs, and both of the Block Ack Policy subfield equal to 0 HT-delayed
STAs set the HT-delayed Block Ack subfield See NOTE 2.
of the HT Capabilities element to 1.
Both STAs are HT STAs, and at least one of Block Ack Policy subfield equal to 0 Delayed
the STAs sets the HT-delayed Block Ack
subfield of the HT Capabilities element to 0.
Both STAs are robust AV streaming STAs, Block Ack Policy subfield equal to 1 GCR Block Ack
and the agreement was established using
ADDBA Request/Response frames that
included GCR Group Address elements.
NOTE 1—Non-HT block ack agreement is obsolete. Support for this mechanism might be removed in a later
revision of the standard.
NOTE 2—HT-delayed block ack agreement is obsolete. Support for this mechanism might be removed in a later
revision of the standard.
NOTE—If the BlockAckReq and BlockAck variant is Extended Compressed and the Type of block ack agreement is
HT-immediate, use of the RBUFCAP field is implementation dependent.
1681
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-5—Types of block ack agreement based on capabilities and ADDBA conditions for
DMG STAs
Type of
BlockAckReq
ADDBA Type of block
Capabilities condition and
condition ack agreement
BlockAck
variant
Both STAs have the BlockAck with Flow Control field in Block Ack Compressed HT-immediate
the DMG Capabilities element equal to 1. Policy subfield
set to 0
At least one of the STAs has the BlockAck with Flow Block Ack Compressed HT-immediate
Control field in the DMG Capabilities element equal to 0. Policy subfield
set to 0
At least one of the STAs has the BlockAck with Flow Block Ack Extended HT-immediate
Control field in the DMG Capabilities element equal to 0. Policy subfield Compressed
set to 1
Both STAs have the BlockAck with Flow Control field in Block Ack Extended HT-immediate
the DMG Capabilities element equal to 1. Policy subfield Compressed + flow control
set to 1
11.5.3 Teardown of the block ack mechanism
11.5.3.1 General
The procedure at the two STAs is described in 11.5.3.2 and 11.5.3.3 and illustrated in Figure 11-23.
Initiator of deletion Responder
STA SME STA MAC STA MAC STA SME
MLME -
DELBA . request
DELBA Request
MLME -
DELBA . indication
Figure 11-23—Block ack deletion
11.5.3.2 Procedure at the initiator of the block ack teardown
Upon receipt of an MLME-DELBA.request primitive, the MLME shall tear down the block ack by
transmitting a DELBA frame.
The encoding of ReasonCode values to Reason Code field (see 9.4.1.7) values is defined in Table 9-45.
11.5.3.3 Procedure at the recipient of the DELBA frame
A STA shall issue an MLME-DELBA.indication primitive with the parameter ReasonCode having a value
of REQUESTED when a DELBA frame is received.
1682
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.5.4 Error recovery upon a peer failure
Every STA shall maintain an inactivity timer for every negotiated block ack setup, unless the block ack
agreement is set up for a GCR group address. The inactivity timer at a recipient is reset when MPDUs
corresponding to the TID for which the block ack policy is set are received and the Ack Policy subfield in
the QoS Control field of that MPDU header is Block Ack or Implicit Block Ack Request. The inactivity
timer is not reset when MPDUs corresponding to other TIDs are received. The inactivity timer at the
recipient is also reset when a BlockAckReq frame corresponding to the TID for which the block ack policy
is set is received. The inactivity timer at the originator is reset when a BlockAck frame corresponding to the
TID for which the block ack policy is set is received. When a timeout of BlockAckTimeout is detected, the
STA shall send a DELBA frame to the peer STA with the Reason Code field set to TIMEOUT and shall
issue an MLME-DELBA.indication primitive with the ReasonCode parameter having a value of TIMEOUT.
The procedure is illustrated in Figure 11-24.
STA SME STA MAC STA MAC STA SME
QoS DATA
BlockAck
QoS DATA
QoS DATA
BlockAckReq
BlockAckReq
MLME
DELBA . indication DELBA MLME
DELBA . indication
(a) At the originator
STA SME STA MAC STA MAC STA SME
Inactivity
QoS DATA Timer
MLME
MLME
DELBA DELBA . indication
DELBA . indication
(b) At the recipient
Figure 11-24—Error recovery by the receiver upon a peer failure
1683
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When a recipient does not have an active block ack for a TID, but receives Data frames with the Ack Policy
subfield equal to Block Ack, it shall discard them and shall send a DELBA frame within its own TXOP. If
such a STA receives a BlockAckReq frame, it may respond with an Ack frame and shall respond with a
DELBA frame within its own TXOP. The originator may attempt to set up the use of block ack or may send
the MPDUs using an alternative acknowledgment mechanism. When the recipient transmits a DELBA
frame, it shall set the last sequence number received value to the sequence number of the last received
MPDU, regardless of the acknowledgment policy used in that frame. When the originator receives a
DELBA frame, it shall
a) Discard any MPDU that has been transmitted and not acknowledged, with the possible exception if
it was the last MPDU to be sent and it was not a retransmission, and
b) Set the sequence number to either that of the last MPDU that is sent if it intends to retransmit or one
beyond the last MPDU sent.
11.6 Higher layer timer synchronization
11.6.1 Introduction
Higher layer timer synchronization is beyond the scope of this standard. However, explanation of how the
constructs in this standard might be used to support such capabilities might be useful to the designer.
One way to accomplish synchronization across a BSS is by multicasting synchronization (Sync) packets
from the higher layers containing a time stamp and a sequence number. These packets would be opaque to
the MAC and would be transported in the same way as any other MSDU (most likely addressed to the group
address). Sync packets would be treated as a type of management packet by the higher layers. The time
stamp in the Sync packet would contain the higher layer clock value at the time when the previous Sync
packet was transmitted. The sequence number parameter has a value equal to the sequence number of the
MSDU in which the time stamp is provided.
The reason the packet would contain the time stamp for the previous Sync packet (rather than the current
packet) is that hardware and layering constraints would prohibit the ability to provide a time stamp for the
exact instant the current packet is transmitted within that packet. However, an MLME-HL-SYNC.indication
primitive allows the transmitting STA to know exactly when each Sync packet is transmitted. A receiving
STA might note the time when each Sync packet is received as well as the sequence number for that frame.
The receiving STA would save this receive time indication for each packet along with its sequence number
and compare the indication of the previously received Sync packet to the time stamp in the most currently
received packet. This comparison allows the STA to compute an offset, which can be used to adjust its time
reference to match that of the synchronization source. A check of the sequence number verifies that the
correct packet is being used for time stamp comparison. It is possible a packet is lost; in this case, the
received time stamp for the lost packet should be discarded.
The last symbol of the Sync frame is indicated by the PHY using the PHY-TXEND.confirm and PHY-
RXEND.indication primitives in the transmitter and receiver of the Sync frame, respectively. Practical limits
on the coincidence of this indication and the last symbol of the Sync frame are implementation dependent.
The accuracy of this technique also depends on the propagation delay between the source and receiving
channel. However, both the time difference (between the PHY indication and the last symbol of the Sync
frame) and the propagation delay can be considered as fixed-delay components. Therefore, they contribute
only to the fixed time difference between the transmitter and receiver STAs’ clocks and do not contribute to
jitter. An implementation dependent scheme might be used to cancel or minimize this fixed time difference.
The Sync frame may also be relayed through the AP. In this case, the STA that generates the time stamps
notes the reception of the group addressed Sync frame from the AP as the indication to save the higher clock
value for the next Sync frame. Receiving STAs would also similarly note the time when each Sync packet is
1684
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
received from the AP. The sequence number would include a value corresponding to the frame received
from the AP.
This is an example implementation using the higher layer timer synchronization feature. Other
implementations are possible.
11.6.2 Procedure at the STA
In order to determine whether to provide an MLME-HL-SYNC.indication primitive for a particular Data
frame, a MAC that supports MLME-HL-SYNC primitives compares the Address 1 field in a Data frame’s
MAC header to a list of group addresses previously registered by an MLME-HL-SYNC.request primitive. If
the MAC and the transmitter of the Sync frame are collocated within the same STA, the MLME-HL-
SYNC.indication primitive shall occur when the last symbol of the PPDU carrying a matching Data frame is
transmitted. Otherwise, the indication shall occur when the last symbol of the PPDU carrying the matching
Data frame is received. In both cases, the MLME-HL-SYNC.indication primitive provided is simultaneous
(within implementation dependent delay bounds) with the indication provided to other STAs within the BSS
for the same Data frame.
11.7 DLS operation
11.7.1 General
The STSL mechanism is obsolete. Consequently, the DLS protocol might be removed in a later revision of
the standard.
DLS is a protocol that enables a STA in an infrastructure network to transmit frames directly to another STA
in the same infrastructure network. The need for this protocol is motivated by the fact that the intended
recipient may be in PS mode, in which case it can be awakened only by the AP. The second feature of DLS
is to exchange rate set and other information between the sender and the receiver.
A DMG STA shall not use the DLS protocol.
This protocol prohibits the STAs going into PS mode for the duration of the direct stream as long as there is
an active DLS between the two STAs.
DLS does not apply in an IBSS, where frames are always sent directly from one STA to another. DLS does
not apply in an MBSS, because frames in an MBSS are always sent directly from one mesh STA to another.
The handshake involved in the setup is illustrated in Figure 11-25.
AP
STA-1 STA-2
Figure 11-25—The four steps involved in direct-link handshake
1685
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The handshake involves the following steps:
a) A STA, STA-1, that intends to exchange frames directly with another non-AP STA and
dot11DLSAllowed is true, STA-2, invokes DLS and sends a DLS Request frame to the AP (step 1a
in Figure 11-25). This request contains the rate set, capabilities of STA-1, and the MAC addresses of
STA-1 and STA-2. If STA-1 is an HT STA, this request also contains the HT capabilities of STA-1.
If STA-1 is a VHT STA, this response also contains a VHT Capabilities element representing the
VHT capabilities of STA-1.
b) If STA-2 is associated in the BSS, direct streams are allowed in the policy of the BSS (as determined
by dot11DLSAllowedInQBSS), and STA-2 is indeed a QoS STA, then the AP forwards the DLS
Request frame, independently of whether the AP is capable of decoding all of the fields in the body
of the frame, to the recipient, STA-2 (step 1b in Figure 11-25).
c) If STA-2 has dot11DLSAllowed true and accepts the direct stream, it sends a DLS Response frame
to the AP (step 2a in Figure 11-25), which contains the rate set, (extended) capabilities of STA-2,
and the MAC addresses of STA-1 and STA-2. If STA-2 is an HT STA, this response also contains
an HT Capabilities element representing the HT capabilities of STA-2. If STA-2 is a VHT STA, this
response also contains a VHT Capabilities element representing the VHT capabilities of STA-2.
d) The AP forwards the DLS Response frame to STA-1 (step 2b in Figure 11-25), independently of
whether the AP is capable of decoding all of the fields in the body of the frame.
e) If the DLS Response frame contained a status code of SUCCESS, the direct link becomes active and
frames may be sent from STA-1 to STA-2 and from STA-2 to STA-1.
When a STA transitions to a different AP after a DLS is set up, the DLS shall be torn down as described in
11.7.5.
11.7.2 DLS procedures
11.7.2.1 General
The DLS message flow is illustrated in Figure 11-26.
Initiating STA AP Recipient STA
SME MAC MAC SME MAC SME
MLME-
DLS.request
DLS request
DLS request
MLME-
DLS.indication
DLS response
DLS response
MLME-
DLS.confirm
Figure 11-26—DLS message flow
1686
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.7.2.2 Setup procedure at the QoS STA
A STA shall maintain a list of all STAs with which a direct link has been established.
Upon receipt of an MLME-DLS.request primitive from the SME, the STA shall do one of the following
actions:
— Issue an MLME-DLS.confirm primitive with a result code of SUCCESS if the peer MAC address of
MLME-DLS.request primitive is in the list of STAs with which direct link has been established; or
— Initiate the setup of the direct link by sending the DLS Request frame to the AP (step 1a in
Figure 11-25).
Upon receipt of the DLS Request frame from the AP (step 1b in Figure 11-25), the MLME shall send to the
AP a DLS Response frame (step 2a in Figure 11-25) with a result code of
— SUCCESS if the STA is willing to participate in the direct link with the source STA. The STA shall
also issue an MLME-DLS.indication primitive to the SME and shall add the source STA to the list
of the STAs, if not already present, with which direct link has been established.
— REFUSED if the STA is not willing to participate in the direct link.
Upon receipt of the DLS Response frame from the AP (step 2b in Figure 11-25), the STA shall issue an
MLME-DLS.confirm primitive.
— If the result code is SUCCESS, the direct link is considered to be established with the destination
STA in the DLS Response frame, and the MAC shall add the destination STA to the list of STAs
with which direct link has been established.
— If the result code is REFUSED, the direct links is not considered to have been established.
11.7.2.3 Setup procedure at the AP
Upon receipt of the DLS Request frame (step 1a in Figure 11-25), the AP shall
— Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not
Allowed in the BSS, if direct links are not allowed in the BSS (step 2b in Figure 11-25), or for the
AP with dot11SSPNInterfaceActivated equal to true with a result code of Not Allowed by SSP if the
dot11NonAPStationAuthDls in either of the non-AP STA’s dot11InterworkingTable is false.
— Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not
Present, if the destination STA is not present in the BSS (step 2b in Figure 11-25).
— Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not a
QoS STA, if the destination STA does not have QoS facility (step 2b in Figure 11-25).
— Send the DLS Request frame, with all fields having the same value as the DLS Request frame
received by the AP, to the destination STA (step 1b in Figure 11-25), independently of whether the
AP is capable of decoding all of the fields in the body of the frame.
Upon receipt of the DLS Response frame from a STA (step 2a in Figure 11-25), the AP shall send DLS
Response frame to the source STA (step 2b in Figure 11-25).
The mapping of Status Code field values to ResultCode parameter values in an MLME-DLS.confirm
primitive is defined in Table 9-46.
11.7.2.4 Operation of the DLS Timeout Value field
The DLS Timeout Value field within the DLS Request frame contains the duration, in seconds, after which
the direct link is terminated, if there are no frame exchanges within this duration with the peer. A value of 0
implies that the direct link is never to be terminated based on a timeout.
1687
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.7.3 Data transfer after setup
For each active direct link, a STA shall record the MAC and PHY features, rates, and MCSs that are
supported by the other STA participating in the direct link, according to the Supported Rates and BSS
Membership Selectors, Extended Supported Rates and BSS Membership Selectors, Capability Information,
HT Capabilities, and VHT Capabilities fields within the DLS Request and DLS Response frames that were
used to establish the direct link.
A STA transmitting frames within a direct link shall not transmit frames using features, rates, or MCSs that
are not supported by the other STA in the direct link. After establishing protection as required by 10.26 or
10.3.2.8, STAs may use features, rates, or MCSs that are supported by both of the STAs in the direct link,
even when the AP does not support those features, except for transmission of a 40 MHz mask PPDU, which
is governed by the rules found in 11.16.4.
STAs participating in a direct link may set up a block ack agreement, if needed. The STAs may set up TSs
with the HC to provide enough bandwidth or use polled TXOPs for data transfer. A protective mechanism
(such as transmitting using HCCA, RTS/CTS, or the mechanism described in 10.26) should be used to
reduce the probability of other STAs interfering with the direct-link transmissions.
11.7.4 DLS teardown
11.7.4.1 General
The DLS teardown procedure is divided into STA-initiated and AP-initiated DLS teardown. The STA-
initiated DLS teardown message flow is illustrated in Figure 11-27.
Initiating STA AP Recipient STA
SME MAC MAC SME MAC SME
MLME-DLS-
TEARDOWN.request
DLS Teardown
DLS Teardown
MLME- DLS-
TEARDOWN .indication
Figure 11-27—STA-initiated DLS teardown message flow
11.7.4.2 STA-initiated DLS teardown procedure
Upon receipt of MLME-DLS-TEARDOWN.request primitive from the SME, the STA shall initiate the
teardown of the direct link by sending the DLS Teardown frame to the AP. The applicable values of
ReasonCode are defined in Table 11-6. The encoding of the Reason Code field is defined in Table 9-45.
Upon receipt of the DLS Teardown frame (from the AP), the STA shall issue an MLME-DLS-
TEARDOWN.indication primitive to the SME and shall delete the STA from the list of the STAs with
which direct link has been established.
1688
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-6—ReasonCode values for DLS teardown
ReasonCode Applicable at
STA_LEAVING Non-AP STA
END_DLS Non-AP STA
UNKNOWN_DLS Non-AP STA
TIMEOUT Non-AP STA
PEERKEY_MISMATCH AP
PEER_INITIATED AP and Non-AP STA
AP_INITIATED Non-AP STA
The DLS teardown procedure shall apply to a specific DLS session, as each STA may have multiple
simultaneous DLS sessions with other STAs.
Prior to disassociation/deauthentication from the AP, the STA (STA1) shall initiate the teardown of any
direct links it has by sending a DLS Teardown frame to the AP. If the DLS Teardown frame’s Max Retry
Limit was reached with no response from the AP, the STA shall send a DLS Teardown frame to its peer
DLS STA (STA2).
A recipient STA (STA2), on receipt of a DLS Teardown frame with ReasonCode equal to
PEER_INITIATED (from STA1), shall send a DLS Teardown frame to the AP with ReasonCode set to
PEER_INITIATED.
An AP that receives a DLS Teardown frame with ReasonCode equal to PEER_INITIATED should send a
DLS Teardown frame to any STAs that have a DLS link established with STA1.
NOTE—The failed STA can reestablish its DLS link according to 11.7.
11.7.4.3 Teardown procedure at the AP
Upon receipt of the DLS Teardown frame from a STA, the AP shall send a DLS Teardown frame to the
destination STA.
Upon receipt of MLME-DLS-TEARDOWN.request primitive from the SME, the AP shall announce the
tearing down of the direct link by sending the DLS Teardown frame to the two STAs using the direct link.
The only applicable values of the ReasonCode are PEERKEY_MISMATCH and STA_LEAVING. The
encoding to Reason Code field values is defined in Table 11-6.
11.7.4.4 AP-initiated DLS teardown procedure
The AP-initiated DLS teardown procedure may be used when the STA is unable to initiate the DLS
teardown. The AP should initiate a DLS teardown procedure when the AP detects that either end of a DLS
link has left the BSS without teardown of the DLS link, e.g., through receipt of a Deauthentication frame or
receipt of a Disassociation frame.
If there are one or more STAs with open DLS connections with the STA being removed, the AP shall send a
DLS Teardown frame to each such STA with ReasonCode AP_INITIATED.
NOTE—The AP can also initiate DLS teardown for implementation dependent reasons.
1689
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.7.5 Error recovery upon a peer failure
Every STA shall maintain an inactivity timer for every negotiated direct link (i.e., STAs on both sides of the
link maintain these timers). The DLS inactivity timer shall be reset for every successful frame transmission
or reception for that direct link. The DLS timeout value is set according to the value of the DLS Timeout
Value field in the DLS Request frame that initiated the direct link. If, for the period of time specified by the
DLS timeout value, no frames are exchanged as part of the direct link, then the direct link becomes inactive.
When the direct link becomes inactive due to timeout, the MLME issues an MLME-DLS-
TEARDOWN.indication primitive to the SME and sends a DLS Teardown frame to the AP, with the peer
MAC address as the destination MAC address and the reason code set to TIMEOUT. All frames shall
henceforth be sent via the AP.
If there has been a TS setup for the data transfer, it is the responsibility of the STAs to renegotiate the
parameters of the TSPEC with the HC.
When two STAs have set up a direct link, either STA may send DLS Request frames in order to update the
DLS timeout value. If the updated DLS Request frame is accepted, both STAs initialize the timer to detect
DLS timeout. Even if the updated DLS Request frame is not accepted, the original direct link remains active.
11.7.6 Secure DLS operation
PeerKey handshake, defined in 12.7.8, is used to establish the keys needed to enable secure DLS.
The PeerKey message exchange shall start after the DLS establishment and completed prior to initiation of
the DLS Data frame exchange.
The STKSA remains valid even if the STA disassociates from the originating AP, but the STKSA shall be
deleted before a STA attempts another (re)association. If an AP transmits a Deauthenticate or Disassociate
frame to a STA, the AP shall also initiate teardowns for any existing DLS. The DLS STKs shall be deleted
when the DLS Teardown frames are sent or received.
11.8 TPC procedures
11.8.1 General
Regulations that apply to the 5 GHz band in most regulatory domains require RLANs operating in the 5 GHz
band to use transmitter power control, involving specification of a regulatory maximum transmit power and
a mitigation requirement for each allowed channel. This standard describes such a mechanism, referred to as
transmit power control (TPC).
This subclause describes TPC procedures intended to satisfy needs in many regulatory domains and other
frequency bands. These procedures might be useful for other purposes (e.g., reduction of interference, range
control, reduction of power consumption).
A STA shall use the TPC procedures defined in 11.8 if dot11SpectrumManagementRequired is true.
dot11SpectrumManagementRequired shall be set to true when regulatory authorities require TPC. It may
also be set to true in other circumstances. The TPC procedures provide for the following:
— Association of STAs with an AP or PCP in a BSS based on the STAs’ power capability (see 11.8.2)
— Peering of mesh STAs based on the mesh STAs’ power capability (see 11.8.3)
— Specification of regulatory and local maximum transmit power levels for the current channel (see
11.8.5)
— Selection of a transmit power for each transmission in a channel within constraints imposed by
regulatory and local requirements (see 11.8.6)
1690
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Adaptation of transmit power based on a range of information, including path loss and link margin
estimates (see 11.8.7)
If dot11SpectrumManagementRequired is true, a non-DMG STA shall not join an infrastructure BSS,
MBSS or IBSS unless the Spectrum Management bit is 1 in the Capability Information field in Beacon
frames and Probe Response frames or in the Condensed Capability Information field in Measurement Pilot
frames received from other STAs in the BSS, with the following exceptions:
— A STA may operate when the Spectrum Management bit is 0 if the STA determines that it is in a
regulatory domain that does not require TPC or determines that it meets regulatory requirements
even if TPC is not employed. Potential methods for determining the regulatory domain include
receiving a country indication in the Beacon frame, Measurement Pilot frame, user confirmation, or
configuration information within the device. Potential methods to meet regulations even if TPC is
not employed include using a transmit power that is below the legal maximum (including any
mitigation factor).
— A STA shall set dot11SpectrumManagementRequired to true before associating with a BSS in
which the Spectrum Management bit is 1 in the Capability Information field in Beacon frames and
Probe Response frames or in the Condensed Capability Information field in Measurement Pilot
frames received from the BSS.
— An AP may allow association of devices that do not have the Spectrum Management bit equal to 1 in
the Capability Information field in Association Request frames and Reassociation Request frames
received from the STA to account for the existence of legacy devices that do not support TPC, but
do meet regulatory requirements.
A mesh STA shall set dot11SpectrumManagementRequired to true before becoming a member of an MBSS
in which the Spectrum Management bit is equal to 1 in the Capability Information field in Beacon frames
and Probe Response frames received from the MBSS.
11.8.2 Association based on transmit power capability
A STA shall inform an AP or PCP of its minimum and maximum transmit power capability for the current
channel when associating or reassociating, using a Power Capability element in (Re)Association Request
frames.
An AP or PCP might use the minimum and maximum transmit power capability of associated STAs as an
input into an algorithm used to determine the local transmit power constraint for any BSS it maintains. The
specification of the algorithm is beyond the scope of this standard.
An AP or PCP may reject a (re)association request from a STA if it considers the STA’s minimum or
maximum transmit power capability to be unacceptable. For example, a STA’s power capability might be
unacceptable if it violates local regulatory constraints or increases the probability of hidden STAs by a
significant degree. The criteria for accepting or rejecting a (re)association on the basis of transmit power
capability are beyond the scope of this standard.
If a STA sends a Country element, a Power Constraint element, and a Transmit Power Envelope element,
where the interpretation of the Maximum Transmit Power Level field in the Country element for a 20 MHz
or 40 MHz Subband Triplet field is the same as the Local Maximum Transmit Power Unit Interpretation
subfield, then at least one of local power constraints indicated by the Local Maximum Transmit Power For
20 MHz and Local Maximum Transmit Power For 40 MHz fields in the Transmit Power Envelope element
shall be the same as the indicated local power constraint expressed by the combination of Country element
and Power Constraint element.
NOTE—An example of the interpretation of the Maximum Transmit Power Level field in the Country element for a 20
MHz or 40 MHz Subband Triplet field being the same as the Local Maximum Transmit Power Unit Interpretation
subfield is when both are EIRP.
1691
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.8.3 Peering based on transmit power capability
A mesh STA shall provide a candidate peer mesh STA with its minimum and maximum transmit power
capability for the current channel when becoming a member of an MBSS, using a Power Capability element
in Mesh Peering Open frames.
A mesh STA may use the minimum and maximum transmit power capability of a neighbor peer mesh STA
as an input into the algorithm used to determine the local transmit power constraint. The specification of the
algorithm is beyond the scope of this standard.
A mesh STA may reject a Mesh Peering Open request from a candidate mesh STA if it considers the
candidate mesh STA’s minimum or maximum transmit power capability to be unacceptable. For example, a
candidate mesh STA’s power capability might be unacceptable if it violates local regulatory constraints. The
criteria for establishing or rejecting a Mesh Peering Open request on the basis of transmit power capability
are beyond the scope of this standard.
If a STA sends a Country element, a Power Constraint element, and a Transmit Power Envelope element,
where the interpretation of the Maximum Transmit Power Level field in the Country element for a 20 MHz
or 40 MHz Subband Triplet field is the same as the Local Maximum Transmit Power Unit Interpretation
subfield, then at least one of the local power constraints indicated by a) the Local Maximum Transmit Power
For 20 MHz field or b) Local Maximum Transmit Power For 40 MHz field in the Transmit Power Envelope
element shall be the same as the indicated local power constraint expressed by the combination of Country
element and Power Constraint element.
11.8.4 Interpretation of transmit power capability
As regards the units of the Minimum Transmit Power Capability and Maximum Transmit Power Capability
fields within the Power Capability element sent in a STA’s (Re)Association Request frame to an AP, if all of
the following apply
— The STA is extended spectrum management capable.
— The STA has dot11SpectrumManagementRequired or dot11RadioMeasurementActivated equal to
true.
— A Beacon or Probe Response frame has been received from the AP by the STA.
— The Beacon or Probe Response frame includes one or more Transmit Power Envelope elements.
then
— The units shall be interpreted according to the Local Maximum Transmit Power Unit Interpretation
subfield in the Transmit Power Information field in the Transmit Power Envelope element (see
9.4.2.162) sent in the most recently received Beacon or Probe Response frame.
otherwise
— The units shall be interpreted as EIRP.
If the Beacon or Probe Response frame most recently received from a neighbor mesh STA by a mesh STA
that is extended spectrum management capable and that has dot11SpectrumManagementRequired or
dot11RadioMeasurementActivated equal to true includes one or more Transmit Power Envelope elements,
then the units of the Minimum Transmit Power Capability and Maximum Transmit Power Capability fields
within the Power Capability element sent in the Mesh Peering Open frame to the neighbor mesh STA shall
be interpreted according to the Local Maximum Transmit Power Unit Interpretation subfield in the Transmit
Power Information field in the Transmit Power Envelope element (see 9.4.2.162) sent in the most recently
received Beacon or Probe Response frame. Otherwise, the units of the Minimum Transmit Power Capability
1692
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
and Maximum Transmit Power Capability fields within the Power Capability element sent in the mesh
STA’s Mesh Peering Open frame to the neighbor mesh STA shall be interpreted as EIRP.
11.8.5 Specification of regulatory and local maximum transmit power levels
A STA shall determine a regulatory maximum transmit power for the current channel by selecting the
minimum of the following:
— Any regulatory maximum transmit power received in a Country element from the AP in its BSS,
PCP in its PBSS, another STA in its IBSS, or a neighbor peer mesh STA in its MBSS
— Any regulatory maximum transmit power for the channel in the current regulatory domain known by
the STA from other sources
A STA shall determine a local maximum transmit power for the current channel by selecting the minimum
of the following:
— Unless the STA is extended spectrum management capable and has received a Transmit Power
Envelope element for a channel width of 20 MHz and 40 MHz, any local maximum transmit power
received in the combination of a Country element and a Power Constraint element from the AP in its
BSS, PCP in its PBSS, another STA in its IBSS, or a neighbor peer mesh STA in its MBSS
— If the STA is extended spectrum management capable, any local maximum transmit power received
in a Transmit Power Envelope element from the AP in its BSS, another STA in its IBSS, or a
neighbor peer mesh STA in its MBSS
— Any local maximum transmit power for the channel regulatory domain known by the STA from
other sources
The Local Power Constraint field of any transmitted Power Constraint element and each Local Maximum
Transmit Power For X MHz field (where X = 20, 40, 80, or 160/80+80) in the Transmit Power Envelope
element shall each be set to its respective value that allows the mitigation requirements to be satisfied in the
current channel.
NOTE—The local maximum transmit power for the channel needs to meet the mitigation requirements for the channel
in the current regulatory domain. The conservative approach is to set the local maximum transmit power level equal to
the regulatory maximum transmit power level minus the mitigation requirement. However, it might be possible to satisfy
the mitigation requirement using a higher local maximum transmit power level. A lower local maximum transmit power
level might be used for other purposes (e.g., range control, reduction of interference).
The regulatory and local maximum transmit powers may change in a STA during the life of an infrastructure
BSS and an MBSS. However, network stability needs to be considered when deciding how often or by how
much these maximums are changed. The regulatory and local maximum transmit powers shall not change
during the life of an IBSS.
An AP, IBSS STA, or mesh STA shall advertise the regulatory maximum transmit power for that STA’s
operating channel in Beacon frames and Probe Response frames using a Country element. An AP, IBSS
STA or mesh STA shall advertise the local maximum transmit power for that STA’s operating channel in
Beacon frames and Probe Response frames using the combination of a Country element and a Power
Constraint element.
If an AP, IBSS STA, or mesh STA is extended spectrum management capable, it shall advertise the local
maximum transmit power for that STA’s operating channel in Beacon frames and Probe Response frames
using one Transmit Power Envelope element for each distinct value of the Local Maximum Transmit Power
Unit Interpretation subfield that is supported by the BSS, IBSS, or MBSS, respectively. Each Transmit
Power Envelope element shall include a local power constraint for all channel widths supported by the BSS.
STAs that are extended spectrum management capable and have dot11RadioMeasurementActivated equal to
true should be able to reduce their EIRP to 0 dBm.
1693
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—When the local maximum transmit power is set by an AP for radio resource management, a typical low value
for the local power constraint is 0 dBm. A STA that cannot reduce its transmit power to this level or below will not be
able to associate to the AP.
The PCP in a PBSS shall advertise both the regulatory maximum transmit power and the local maximum
transmit power for its operating channel in Announce and Probe Response frames (using a Country element
for the regulatory maximum and a combination of a Country element and a Power Constraint element for the
local maximum). In addition, it should advertise both regulatory and local maximum transmit power in
DMG Beacon frames.
When dot11SpectrumManagementRequired is false and dot11RadioMeasurementActivated is true, an AP or
a PCP may include a Power Constraint element and a Transmit Power Envelope element in Beacon, DMG
Beacon, Announce, and Probe Response frames.
11.8.6 Transmit power selection
A STA may select any transmit power for transmissions in a channel within the following constraints:
— A STA shall determine a regulatory maximum transmit power and a local maximum transmit power
for a channel in the current regulatory domain before transmitting in the channel.
— An AP shall use a transmit power less than or equal to the regulatory maximum transmit power level
for the channel. The AP shall also meet any regulatory mitigation requirement.
— A non-AP STA shall use a transmit power less than or equal to the local maximum transmit power
level for the channel.
11.8.7 Transmit power adaptation
A STA may use any criteria, and in particular any path loss and link margin estimates, to dynamically adapt
the transmit power for transmissions of an MPDU to another STA. The adaptation methods or criteria are
beyond the scope of this standard.
A STA may use a TPC Request frame to request another STA to respond with a TPC Report frame reporting
link margin and transmit power information. A STA that receives a TPC Request frame shall respond with a
TPC Report frame that contains a TPC Report element in which the Transmit Power field indicates the
power used to transmit the response and the Link Margin field indicates the estimated link margin. A DMG
STA may also use the link measurement procedure and the DMG Link Margin element to exchange TPC
information.
An AP, PCP, or IBSS STA shall autonomously include a TPC Report element with the Link Margin field set
to 0 in Beacon frames, DMG Beacon frames, Announce frames, or Probe Response frames.
11.9 DFS procedures
11.9.1 General
Regulations that apply to the 5 GHz band in most regulatory domains require RLANs operating in the 5 GHz
band to implement a mechanism to avoid co-channel operation with radar systems and to uniformly utilize
available channels. This standard describes such a mechanism, referred to as dynamic frequency selection
(DFS).
This subclause describes DFS procedures that can be used to satisfy these and similar future regulatory
requirements. The procedures might also satisfy comparable needs in other frequency bands and might be
useful for other purposes. For example, some of the procedures described in this subclause could be used for
channel selection in a DMG BSS.
1694
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA shall use the DFS procedures defined in 11.9.1 to 11.9.9 if dot11SpectrumManagementRequired is
true.
A STA shall use the DFS procedures defined in 11.9.10 if dot11SpectrumManagementRequired and
dot11FutureChannelGuidanceActivated are true.
Attribute dot11SpectrumManagementRequired shall be set to true when regulatory authorities require DFS.
It may also be set to true in other circumstances. The DFS procedures provide for the following:
— Associating STAs with an AP based on the STAs’ supported channels (see 11.9.2)
— Quieting the current channel so it can be tested for the presence of radar with less interference from
other STAs (see 11.9.3)
— Testing channels for radar before using a channel and while operating in a channel (see 11.9.4)
— Discontinuing operations after detecting radar in the current channel to avoid further interference
with radar (see 11.9.5)
— Detecting radar in the current and other channels, based on regulatory requirements (see 11.9.6)
— Requesting and reporting measurements in the current and other channels (see 11.9.7)
— Selecting and advertising a new channel to assist the migration of a BSS after radar is detected (see
11.9.8)
— Guiding STAs about the likely future channel should the AP leave this channel (see 11.9.10).
In a DMG BSS, the following DFS procedures apply:
— Associating a STA with an AP or a PCP based on the STA’s supported channels (see 11.9.2)
— Quieting the current channel so it can be tested for interference with less interference from
associated STAs (see 11.9.3)
— Requesting and reporting measurements in the current and other channels (see 11.9.7)
— Selecting and advertising a new channel to assist the migration of an infrastructure BSS, IBSS, or
PBSS (see 11.9.8)
For the purposes of DFS in a non-DMG BSS, the following statements apply:
— A STA with dot11SpectrumManagementRequired true shall not operate in a BSS unless the
Spectrum Management bit is 1 in the Capability Information field in Beacon frames and Probe
Response frames received from other STAs in the BSS, with the following exception.
— A STA may operate when the Spectrum Management bit is 0 if the STA determines that it is in
a regulatory domain that does not require DFS or determines that it meets regulatory
requirements even if DFS is not employed. Potential methods for determining the regulatory
domain include receiving a country indication in the Beacon frame, user confirmation, or
configuration information within the device. Potential methods to enable regulations to be met
even if DFS is not employed include independently detecting radar and ceasing operation on
channels on which radar is detected.
— A STA shall set dot11SpectrumManagementRequired to true before associating with an
infrastructure BSS, IBSS, or MBSS in which the Spectrum Management bit is 1 in the Capability
Information field in Beacon frames and Probe Response frames received from the infrastructure
BSS, IBSS, or MBSS.
— An AP may allow association of devices that do not have the Spectrum Management bit equal to 1 in
the Capability Information field in Association Request frames and Reassociation Request frames
received from a STA to account for the existence of legacy devices that do not support DFS, but do
meet regulatory requirements.
1695
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.9.2 Association based on supported channels
11.9.2.1 Association based on supported channels in a non-DMG BSS
A STA shall provide an AP with a list of the channels in which the STA can operate when associating or
reassociating by including a Supported Channels element in its (Re)Association Request frames.
An AP may use the supported channels list for associated STAs as an input into an algorithm used to select a
new channel for the BSS. The specification of this algorithm is beyond the scope of this standard.
An AP may reject an (re)association request from a STA if it considers the STA’s supported channel list to
be unacceptable. For example, a STA’s supported channel list might be unacceptable if it can operate only in
a limited number of channels. The criteria for accepting or rejecting (re)associations are beyond the scope of
this standard.
11.9.2.2 Providing supported channels upon association in a DMG BSS
An AP or PCP may advertise the regulatory domain in which it is located via a Country element in the DMG
Beacon, Announce, or Information Response frames if dot11MultiDomainCapabilityActivated is true.
When it (re)associates, the STA shall provide to the AP or PCP a list of channels in which the STA can
operate. The STA does this by including a Supported Channels element in the Information Request or
(Re)Association frames that it transmits. An AP or PCP can use the supported channels list for associated
STAs as an input into an algorithm used to select a new channel for the BSS. The specification of this
algorithm is beyond the scope of this standard.
The AP or PCP may advertise the supported channels of associated STAs via an Information Response
frame with Subject Address field set to the broadcast address and a Supported Channels element that lists the
intersection of channels supported by STAs associated with the BSS, as indicated by their Supported
Channels elements.
11.9.3 Quieting channels for testing
When the AP Quiet Mode field of a Quiet Channel element has the value 1, the Quiet Channel element is
called a mode set Quiet Channel element.
An AP may schedule quiet intervals by transmitting one or more mode set Quiet Channel elements or one or
more Quiet elements in Beacon frames and Probe Response frames.
A mesh STA may schedule quiet intervals by transmitting one or more Quiet elements in Beacon frames and
Probe Response frames.
A non-VHT AP shall not transmit a Quiet Channel element. An AP shall not transmit a Quiet Channel
element with the AP Quiet Mode field value equal to 0 in frames that do not include at least one Quiet
element. An AP shall not transmit more than one Quiet Channel element with the AP Quiet Mode field equal
to 0. An AP shall not transmit a Quiet Channel element if the BSS bandwidth is neither 160 MHz nor
80+80 MHz.
An AP may stop scheduling quiet intervals, or may transmit Quiet elements with changes in the Quiet
Period, Quiet Duration and Quiet Offset fields, or may transmit mode set Quiet Channel elements. A mesh
STA may stop scheduling quiet intervals, or may transmit Quiet elements with changes in the Quiet Period,
Quiet Duration and Quiet Offset fields. Only the most recently received Beacon frame or Probe Response
frame defines all future quiet intervals; therefore, all schedules for quiet intervals based on older Beacon
frames or Probe Response frames shall be discarded.
1696
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An AP or PCP in a DMG BSS may measure one or more channels itself, or the AP or PCP may request
associated non-AP and non-PCP STAs in the same BSS to measure one or more channels, either in a
dedicated measurement interval or during normal operation. The AP or PCP in a DMG BSS may schedule a
service period allocated to itself to quiet the associated STAs and use the self-allocated SP for measurement.
An IBSS STA may schedule quiet intervals only if it is the DFS owner. In order to set a quiet interval
schedule, the STA transmits one or more Quiet elements in the first Beacon frame establishing the IBSS. All
IBSS STAs shall continue these quiet interval schedules by including appropriate Quiet elements in any
transmitted Beacon frames or Probe Response frames.
Multiple independent quiet intervals may be scheduled, so that not all quiet intervals have the same timing
relationship to TBTT, by including multiple Quiet elements or, in an infrastructure BSS, mode set Quiet
Channel elements in Beacon frames or Probe Response frames.
Control of the channel is lost at the start of a quiet interval, and the following quieting rules apply:
— The NAV is set by all of the non-VHT STAs in the BSS for the length of the quiet interval
established by a Quiet element.
— The NAV is set by all of the VHT STAs in the BSS for the duration of the quiet interval established
by a Quiet element if a Quiet Channel element was not sent or received with the Quiet element.
— A VHT STA in the BSS shall not transmit PPDUs that occupy the secondary 80 MHz channel or, in
an infrastructure BSS, transmit PPDUs to the AP during the quiet interval established by a Quiet
element if a Quiet Channel element with the AP Quiet Mode field equal to 0 was sent or received
with the Quiet element.
— A VHT STA in an infrastructure BSS shall not transmit PPDUs that occupy the secondary 80 MHz
channel during the quiet interval established by a Quiet Channel element with the AP Quiet Mode
field in the Quiet Channel element equal to 1.
— Transmission by any non-VHT STA in the BSS of any MPDU and any associated acknowledgment
within either the primary channel or the secondary channel (if present) shall complete before the
start of the quiet interval.
— Transmission by any VHT STA in the BSS of any MPDU and any associated acknowledgment of
the BSS shall complete before the start of the quiet interval established by a Quiet element if a Quiet
Channel element was not sent or received with the Quiet element.
— Transmission by any VHT STA in the BSS of any PPDUs that occupy the secondary 80 MHz
channel or, in an infrastructure BSS, are directed to the AP, and any associated acknowledgment of
the BSS, shall complete before the start of the quiet interval established by a Quiet element if a Quiet
Channel element with the AP Quiet Mode field equal to 0 was sent or received with the Quiet
element.
— Transmission by any VHT STA in the infrastructure BSS of any PPDUs that occupy the secondary
80 MHz channel and any associated acknowledgment of the BSS shall complete before the start of
the quiet interval established by a Quiet Channel element with the AP Quiet Mode field in the Quiet
Channel element equal to 1.
Before starting transmission of an MPDU, a STA shall check if there is enough time for the exchange to
complete within the time allowed by the quieting rules. If there is not enough time, the STA shall defer the
transmission by selecting a random backoff time, using the present CW (without advancing to the next value
in the series). The short retry counter and long retry counter for the MSDU or A-MSDU are not affected.
11.9.4 Testing channels for radar
A STA does not transmit in a channel unless the channel has been tested for the presence of radar
transmissions according to regulatory requirements.
1697
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.9.5 Discontinuing operations after detecting radar
If a STA is operating in a channel and detects radar operating in the channel or accepts that another STA has
detected radar operating in the channel, then the STA discontinues transmissions according to regulatory
requirements.
11.9.6 Detecting radar
The methods that satisfy regulatory requirements to detect radar transmissions are beyond the scope of this
standard.
11.9.7 Requesting and reporting of measurements
The response to a Basic request is a Basic report. A STA in an infrastructure BSS or PBSS shall generate a
Basic report in response to a Basic request if the request is received from the AP or PCP with which it is
associated, except as specified in this subclause.
A STA may measure one or more channels itself or a STA may request other STAs in the same BSS to
measure one or more channels on its behalf. These measurements may occur either during a quiet interval or
during normal operation.
In order to request other STAs to measure one or more channels, a STA shall use a Measurement Request
frame containing one or more Measurement Request elements. The measurement request may be sent to an
individual or group destination address. Addressing requests to multiple STAs should be used with care to
avoid a reply storm.
The measurement requests effectively allowed by these rules are shown in Table 11-7.
Table 11-7—Allowed measurement requests
Source of Destination of Type of measurement request
Service set
request request allowed
BSS AP STA Individual or group
STA AP Individual only
STA STA None
IBSS, MBSS STA STA Individual or group
PBSS PCP Non-PCP STA Individual or group
Non-PCP STA PCP Individual
Non-PCP STA Non-PCP STA None
A STA that successfully requests another STA to perform a measurement on another channel should not
transmit MSDUs, A-MSDUs, or MMPDUs to that STA during the interval defined for the measurement plus
any required channel switch intervals. In determining this period, a STA shall assume that any required
channel switches take dot11ChannelSwitchTime per switch.
1698
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA that receives an individually addressed Measurement Request frame from a STA in its BSS shall
parse the frame’s Measurement Request elements in order, with measurements starting at the times specified
by the Measurement Request elements.
Any result of a measurement request shall be returned without undue delay to the requesting STA in
Measurement Report elements using one or more Measurement Report frames. The result may be the
completed measurement or an indication that the STA is unable to complete the measurement request.
A STA shall report it is too late to undertake a measurement request if it receives the request after the
specified starting time for the measurement.
A STA shall report it is refusing a measurement request if all of the following conditions exist:
— The STA is capable of undertaking a measurement request.
— The STA does not want to undertake the measurement request at this time.
— The measurement request is not mandatory.
NOTE—Measurements are specified as mandatory or optional in 9.4.2.21).
A STA shall report it is incapable of performing a measurement request if any of the following conditions
exists:
— The STA is incapable of undertaking an optional measurement request.
— The STA does not support the channel specified in a mandatory measurement request.
— The STA does not support any requested parallel measurements in the same or different channels.
A Measurement Report frame shall contain the same value in its Dialog Token field as the value of the
Dialog Token field in the corresponding Measurement Request frame, and each Measurement Report
element shall contain the same value in its Measurement Token field as the value of the Measurement Token
field in the corresponding Measurement Request element.
A STA may autonomously report measurements to another STA in its BSS by transmitting a Measurement
Report frame that includes a Dialog Token field set to 0 and one or more Measurement Report elements. An
IBSS STA may also autonomously report measurements to other STAs in the IBSS using the Channel Map
field in the IBSS DFS element in a Beacon frame or Probe Response frame.
A STA may enable or disable measurement requests or autonomous measurement reports from another STA
by transmitting Measurement Request elements with the Enable bit set to 1 and the Request bit and Report
bit set to 0 or 1, as appropriate. These elements do not require a corresponding Measurement Report element
in a Measurement Report frame. All measurement requests and reports shall be enabled by default. An AP or
PCP may ignore a request to disable a mandatory measurement request. All other such requests shall be
honored.
The measurement request and report procedures are defined in 11.11.
11.9.8 Selecting and advertising a new channel
11.9.8.1 General
A channel switch is an attempt to move a BSS to a new operating channel. It is an objective that disruption
to the BSS be minimized in this process, although it should be recognized that a channel switch might not
successfully move all STAs.
Two procedures are defined for switching channels: the channel switching procedure, which is defined in
11.9.8 and 11.9.9, and the extended channel switching procedure, which is defined in 11.10.
1699
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It should also be stressed that both the channel switching procedure and the extended channel switching
procedure are distinct from the regulatory requirement to cease transmission on a particular channel in the
presence of radar.
11.9.8.2 Selecting and advertising a new channel in a non-DMG infrastructure BSS
This subclause describes operation in an infrastructure BSS that is a non-DMG BSS. For a DMG
infrastructure BSS, see 11.9.8.6.
The decision to switch to a new operating channel in an infrastructure BSS shall be made only by the AP. An
AP may make use of the information in Supported Channel elements and the results of measurements
undertaken by the AP and other STAs in the BSS to assist the selection of the new channel. The algorithm to
choose a new channel is beyond the scope of this standard. The AP shall attempt to select a new channel that
is supported by all associated STAs.
An AP shall inform associated STAs that the AP is moving to a new channel and shall maintain the
association by advertising the switch using Channel Switch Announcement elements in Beacon frames,
Probe Response frames, and Channel Switch Announcement frames until the intended channel switch time.
The AP may force STAs in the BSS to stop transmissions until the channel switch takes place by setting the
Channel Switch Mode field in the Channel Switch Announcement element to 1. The channel switch should
be scheduled so that all STAs in the BSS, including STAs in power save mode, have the opportunity to
receive at least one Channel Switch Announcement element before the switch. The AP may send the
Channel Switch Announcement frame in a BSS without performing a backoff, after determining the WM is
idle for one PIFS (see 10.3.2.3).
If a Channel Switch Announcement element in a Beacon or Probe Response frame is used to announce a
switch to a 20 MHz BSS bandwidth, then a Wide Bandwidth Channel Switch subelement in a Channel
Switch Wrapper element shall not be present in the same frame.
If a Channel Switch Announcement element in a Beacon or Probe Response frame is used to announce a
switch to a 40 MHz BSS bandwidth, then a Wide Bandwidth Channel Switch subelement in a Channel
Switch Wrapper element shall also be present in the same frame if the STA sending the frame is extended
spectrum management capable.
A Channel Switch Wrapper element shall not be included in Beacons and Probe Response frames if the
element contains zero subelements.
A STA that receives a Channel Switch Announcement element may choose not to perform the specified
switch, but to take alternative action. For example, it may choose to move to a different BSS.
A non-AP STA in an infrastructure BSS shall not transmit the Channel Switch Announcement element.
11.9.8.3 Selecting and advertising a new channel in an IBSS
DFS in an IBSS is complicated by the following:
— There is no central AP function for collating measurements or coordinating a channel switch. If
STAs make independent decisions to switch channel in the presence of radar, there is a danger that
all STAs announce switches to different channels if several of them detect the radar.
— There is no association protocol that can be used to
— Exchange supported channel information
— Determine membership of the IBSS at a given instant for requesting measurements.
1700
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Beaconing is a shared process; therefore, there is no guarantee that a STA that has something to send
(e.g., a channel switch message) will be the next STA to transmit a Beacon frame.
— A 20/40 MHz IBSS cannot be changed to a 20 MHz IBSS, and a 20 MHz IBSS cannot be changed
to a 20/40 MHz IBSS.
The DFS owner service, IBSS DFS element, and Channel Switch Announcement frame address these
complications:
— The DFS owner service provides a central point of coordination for a channel switch. It attempts to
minimize the probability that multiple STAs concurrently decide to switch to different channels. The
DFS Owner field and DFS Recovery Interval field in the IBSS DFS element support the DFS owner
service.
— Each STA shall include a Channel Map field in the IBSS DFS elements that it transmits. The
channel map communicates the STA-supported channel set and basic measurement reports for that
STA.
— Each STA shall have the ability to send a Channel Switch Announcement element in a Management
frame other than a Beacon frame or Probe Response frame.
The potential for hidden nodes within an IBSS means that an IBSS channel switching procedure might not
move all STAs. In some regulatory domains, each STA in an IBSS is required by regulation to detect radar
and cease transmission, after a required interval, on any channel on which the presence of radar is detected.
A STA at which an IBSS is started shall be a DFS owner in that IBSS. That STA shall include its MAC
address in the DFS Owner field of the IBSS DFS element and DFS Recovery Interval field from the
MLME.START.request primitive parameter. The purpose of the DFS owner is to coordinate a channel
switch. All STAs in an IBSS shall have the ability to become DFS owner.
Each IBSS STA shall adopt the DFS Owner field and the DFS Recovery Interval field from any valid IBSS
DFS element when the received frame contains a matching SSID and the value of the timestamp is later than
the STA’s TSF timer. The STA shall include the adopted values in the IBSS DFS elements it transmits.
Because all IBSS STAs participate in sending Beacon frames, this process always, over a number of beacon
intervals, results in a unified view of one DFS owner throughout the IBSS.
In order to attempt a channel switch using the DFS owner, a STA that detects radar shall broadcast one or
more Measurement Report frames indicating the presence of the radar.
A DFS owner receiving a Measurement Report frame indicating the presence of radar in the current channel
shall select and advertise a new operating channel (including the possibility of no change). The DFS owner
may make use of information received in Channel Map fields and from measurements undertaken by other
members of the IBSS to assist the selection of the new channel. The algorithm to choose a new channel is
beyond the scope of this standard, but shall satisfy any regulatory requirements, including uniform spreading
rules and channel testing rules. The DFS owner shall attempt to select a new channel that is supported by all
members of the IBSS. Note that this process might be imperfect in that the DFS owner might have
incomplete knowledge and there might not be a suitable channel.
The DFS owner shall attempt to make the members of the IBSS aware of the new operating channel by
broadcasting at least one Channel Switch Announcement frame. The DFS owner may transmit the Channel
Switch Announcement frame in an IBSS without performing a backoff, after determining that the WM is
idle for one PIFS (see 10.3.2.3). The DFS owner shall also include the Channel Switch Announcement
element in all Beacon frames, Probe Response frames, or Channel Switch Announcement frames until the
intended channel switch time. A STA that receives a valid Channel Switch Announcement element that is
not a superseded Channel Switch Announcement element (see 11.16.3.3) shall repeat this element in all
Beacon frames and Probe Response frames that it transmits. The DFS owner may attempt to silence STAs in
the IBSS until the channel switch takes place using the Channel Switch Mode field in the Channel Switch
1701
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Announcement element. If possible, the channel switch should be scheduled so that all STAs in the IBSS,
including STAs in power save mode, have the opportunity to receive at least one Channel Switch
Announcement element before the switch.
If a STA does not receive a valid Channel Switch Announcement element from the DFS owner within the
DFS recovery time, then it shall enter DFS recovery mode. DFS recovery time is measured from the end of
the frame that first announced radar presence, whether that frame was transmitted by the STA or received
from another STA. In DFS recovery mode the STA shall assume the role of DFS owner, shall select a new
operating channel, and shall advertise the new channel by transmitting a Channel Switch Announcement
frame using the contention resolution algorithm defined for beacon transmission at TBTT in 11.1.3.5. The
STA shall also include the Channel Switch Announcement element in all Beacon frames and Probe
Response frames until the intended channel switch time. A STA that is not the DFS owner shall not initiate a
channel switch.
If the STA receives a valid Channel Switch Announcement element that is not a superseded Channel Switch
Announcement element (see 11.16.3.3 from another member of the IBSS, the STA shall leave DFS owner
recovery mode prior to the channel switch and adopt the received channel switch information. If the Channel
Switch Announcement element was in a Beacon frame or Probe Response frame, the STA shall also adopt
the STA identified by the DFS owner address of the IBSS DFS element as the DFS owner. If the Channel
Switch Announcement element was in a Channel Switch Announcement frame, the receiving STA shall
adopt the STA that transmitted the frame as the DFS owner.
There are several circumstances when DFS owner recovery is needed (e.g., if the original DFS owner has
left the network or if the original measurement report was not received by the initial DFS owner). Note that
DFS owner recovery might temporarily give rise to more than one DFS owner in the IBSS. This risk is
mitigated by the random nature of the IBSS DFS recovery mechanism. However, because all IBSS STAs
participate in sending Beacon frames, over a number of beacon periods, there will be convergence from
multiple DFS owners to one DFS owner.
11.9.8.4 MBSS channel switching
11.9.8.4.1 General
A mesh channel switch might be triggered by the need to avoid interference to a detected radar signal, or to
reassign mesh STA channels to maintain MBSS connectivity.
A mesh STA may make use of the information in Supported Channel elements, Supported Operating
Classes elements, and the results of measurements undertaken by the mesh STAs in the MBSS to assist the
selection of the new channel. The algorithm for choosing a new channel is beyond the scope of this standard.
A 20/40 MHz MBSS may be changed to a 20 MHz MBSS and a 20 MHz MBSS may be changed to a 20/40
MHz MBSS.
When an MBSS switches from a 20 MHz MBSS to a 20/40 MHz MBSS or switches from a 20/40 MHz
MBSS to a 20 MHz MBSS, a mesh STA might need to do path maintenance to find an optimized path.
11.9.8.4.2 Initiating MBSS channel switch
A mesh STA shall not initiate a new channel switch attempt if there is an ongoing channel switch attempt by
this mesh STA.
A mesh STA shall inform each of the peer mesh STAs that the mesh STA is moving to a new channel while
maintaining mesh peerings by including Channel Switch Announcement elements together with the Mesh
Channel Switch Parameters element in all Beacon frames, Probe Response frames, and Channel Switch
1702
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Announcement frames that it transmits until the intended channel switch time. The channel switch should be
scheduled so that all mesh STAs in the MBSS, including mesh STAs in power save mode, have the
opportunity to receive at least one Channel Switch Announcement element before the switch.
The fields in the Channel Switch Announcement element are set as follows:
— The Channel Switch Count field shall be set to the time period until the mesh STA sending the
Channel Switch Announcement element switches to the new channel.
— The Channel Switch Mode field is reserved.
— The New Channel Number field shall be set to the number of the channel to which the mesh STA is
moving.
The fields in the Mesh Channel Switch Parameters element are set as follows:
— The Precedence Value field shall be set to a random value selected from a uniform distribution in the
range 0 to 65 535.
— The mesh STA may force mesh STAs in the MBSS to stop transmissions of frames (except frames
containing Channel Switch Announcement element) until the channel switch takes place by setting
the Transmit Restrict subfield of the Flags field to 1.
— The Reason subfield in the Flags field shall be set to 1 to indicate that the content of the Reason
Code field (as defined in Table 9-45) is valid. The Reason Code field shall be set to MESH-
CHANNEL-SWITCH-REGULATORY-REQUIREMENTS when the channel switch is initiated to
meet regulatory requirement; otherwise, the Reason Code field shall be set to MESH-CHANNEL-
SWITCH-UNSPECIFIED.
— The Initiator subfield of the Flag field shall be set to 1.
— The Time To Live field should be set to the maximum number of hops (e.g.,
dot11MeshHWMPnetDiameter) for which this Channel Switch attempt is intended.
11.9.8.4.3 Processing channel switch announcement
Upon receipt of a Channel Switch Announcement frame or Extended Channel Switch Announcement frame,
a mesh STA shall not accept and shall not process the received Channel Switch Announcement element or
Extended Channel Switch Announcement element, if any of the following is true:
— The Mesh Channel Switch Parameters element is not present in the received frame containing the
Channel Switch Announcement element or the Extended Channel Switch Announcement element.
— The Time To Live field in the received Mesh Channel Switch Parameters element is 0.
— A mesh channel switch is already running and the mesh STA has not yet moved into the new
channel and/or operating class and the current precedence value is greater than or equal to the value
of the received Precedence Value field.
A mesh STA that receives a Channel Switch Announcement element may choose not to perform the
specified switch, but to take alternative action. For example, it may choose to move to a different MBSS.
When a mesh STA accepts a channel switch, it shall adopt the information received in the Channel Switch
Announcement element and the Mesh Channel Switch Parameters element. The mesh STA shall schedule
the channel switch according to this information. If the Time To Live field value in the received Mesh
Channel Switch Parameters element is greater than 1, the mesh STA shall transmit a Channel Switch
Announcement frame and shall include a Channel Switch Announcement element together with a Mesh
Channel Switch Parameters element in the Beacon and Probe Response frames until the intended channel
switch time. The Channel Switch Mode and New Channel Number fields in the transmitted Channel Switch
Announcement element(s) are set to the same values as in the received Channel Switch Announcement
element. The Channel Switch Count field is set to indicate the time remaining until the channel switch, as
specified in 9.4.2.19. The Reason Code and Precedence Value fields in the transmitted Mesh Channel
Switch Parameters element(s) are set to the same values as in the received Mesh Channel Switch Parameters
1703
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
element. The Time to Live and Flags fields are set as specified in 9.4.2.103. The Time To Live field shall be
set to the received Time To Live field minus 1. The Initiator field shall be set to 0. The Transmit Restrict
field shall be set to 1 when the mesh STA requires neighboring mesh STAs not to transmit (until the
scheduled channel switch occurs) further frames that do not contain the Channel Switch Announcement
element on the current channel. The Transmit Restrict subfield shall be set to 0 otherwise.
It is possible that a channel switch is not successful in moving all of the mesh STAs in MBSS to the new
operating channel. Transitioning to a new channel does not tear down mesh peerings and, as long as the
mesh peers move to the new operating channel, their peerings are maintained in the new channel.
After moving into a new operating channel, the mesh STA shall perform CCA until a frame is detected by
which it can set its NAV, or until a period of time indicated by the NAVSyncDelay parameter from the most
recent MLME-START.request primitive has transpired.
11.9.8.4.4 Channel switch across an operating class
When dot11OperatingClassesImplemented is true and the mesh STA is capable of operation in more than
one operating class, the mesh STA shall include the Supported Operating Classes element within its Mesh
Peering Open frames. The Supported Operating Classes element announces the operating classes that the
mesh STA supports.
When dot11OperatingClassesImplemented is true, a mesh STA may switch from the operating channel to a
channel in a different operating class.
11.9.8.5 HT-greenfield transmissions in operating classes that include a behavior limit of
DFS_50_100_Behavior
The requirements described in this subclause apply only when an HT STA is operating in an operating class
for which the behavior limits set listed in Annex E includes the value DFS_50_100_Behavior; i.e., the
operating class is subject to DFS with 50–100 µs radar pulses.
A non-HT OBSS scan operation is a passive or active scan of the primary channel and of the secondary
channel if the STA conducting the scan is in a 20/40 MHz BSS that the STA currently uses or intends to use.
During a non-HT OBSS scan operation, the channel scan duration shall be a minimum of
dot11OBSSScanPassiveTotalPerChannel TUs when scanning passively and a minimum of
dot11OBSSScanActiveTotalPerChannel TUs when scanning actively.
Before an HT STA starts a BSS with the OBSS Non-HT STAs Present field of the HT Operation element
equal to 0, the HT STA shall perform a non-HT OBSS scan in order to search for any existing non-HT
OBSSs.
When an HT STA detects that there are one or more non-HT OBSSs, and if the HT STA starts a BSS on that
channel, then the HT STA shall set to 1 the OBSS Non-HT STAs Present field of the HT Operation element
it transmits; otherwise, the HT STA may set to 0 the OBSS Non-HT STAs Present field of the HT Operation
element it transmits.
NOTE—Detection of a non-HT OBSS can be achieved by the reception of a Beacon or Probe Response frame that does
not contain an HT Capabilities element or HT Operation element.
An HT AP shall not transmit a PPDU with the FORMAT parameter of the TXVECTOR set to HT_GF if the
OBSS Non-HT STAs Present field of the HT Operation element is equal to 1 in the most recently
transmitted Management frame that contained that element.
1704
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An HT non-AP STA shall not transmit a PPDU with the FORMAT parameter of the TXVECTOR set to
HT_GF if the most recent frame received from its AP containing an HT Operation element has the OBSS
Non-HT STAs Present field equal to 1.
NOTE—This requirement applies also to PPDUs transmitted on a direct link between two non-AP STAs.
When moving the BSS to a new channel or set of channels and before completing a non-HT OBSS scan of
the new channel or set of channels, an HT AP shall set to 1 the OBSS Non-HT STAs Present field of the HT
Operation element it transmits. After the HT AP completes one non-HT OBSS scan of the new channel or
set of channels and if the HT AP has detected that there are zero non-HT OBSSs, then the HT AP may set to
0 the OBSS Non-HT STAs Present field of the HT Operation element it transmits.
11.9.8.6 Selecting and advertising a new channel in a DMG BSS
The decision to switch to a new operating channel in a DMG BSS shall be made only by an AP or PCP. An
AP or PCP may make use of the information in received Supported Channel elements and the results of
measurements undertaken by the AP or PCP and other STAs in the BSS to assist the selection of the new
channel. The algorithm to choose a new channel is beyond the scope of this standard.
An AP or PCP shall inform associated STAs that the AP or PCP is changing to a new channel and shall
maintain the association by advertising the switch using the Extended Channel Switch Announcement
element in its transmitted DMG Beacon frames, Announce frames, and Information Response frames until
the intended channel switch time. The channel switch should be scheduled so that all non-AP and non-PCP
STAs in the BSS, including STAs in power save mode, have the opportunity to receive at least one Extended
Channel Switch Announcement element before the switch. A STA may ignore the Channel Switch Mode
field and either cease transmissions or attempt new transmissions in the operating channel until the channel
change occurs.
A STA that receives an Extended Channel Switch Announcement element may choose not to perform the
specified switch, but to take alternative action. For example, it may choose to move to a different BSS. A
non-AP and non-PCP STA in an infrastructure BSS or PBSS shall not transmit the Extended Channel
Switch Announcement element.
11.9.9 Channel Switch Announcement element operation
If a non-DMG STA in a BSS that is not an IBSS receives a Channel Switch Mode field that has the value 1,
it shall not transmit any more frames on the channel until the scheduled channel switch occurs. An IBSS
STA may treat a Channel Switch Mode field equal to 1 as advisory. A Channel Switch Mode equal to 0 does
not impose any requirement on the STA that receives the Channel Switch Announcement frame.
11.9.10 Future Channel Guidance operation
This subclause defines a mechanism to create, communicate and act on the Future Channel Guidance
element.
When dot11FutureChannelGuidanceActivated is true, a STA shall follow these procedures for future
channel guidance operation.
A STA transmitting Beacon frames transmits the Future Channel Guidance element in (Re)Association
Response frames and optionally in Beacon frames.
In some bands, the channel clearing time will be much less than one second for all STAs, and future channel
guidance permits all STAs know what channels will be used if the current channels are cleared.
1705
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In some bands, Beacon frames are an enabling signal, and some STAs are not allowed to transmit in the
band before receiving an enabling signal. When Beacon frame reception stops, some STAs are no longer
enabled to transmit in the band. In these bands, when Beacon frame reception stops, it is an implicit message
to switch from current channels to other channels according to prior future channel guidance.
Future channel guidance indicates future channels that the Beaconing STA switches to while maintaining
associations and mesh peering relationships (see 11.9.8.2, 11.9.8.3, 11.9.8.4.2, 11.9.8.6, 11.10.3.2, 11.10.3.3
and 11.10.3.4).
A STA receiving the Future Channel Guidance element shall retain the information until it receives a
different Future Channel Guidance element from the same STA, it receives a Channel Switch
Announcement element or a Channel Switch Announcement frame from the same STA, or it chooses
alternative action. For example, it may choose to move to a different BSS.
11.10 Extended channel switching (ECS)
11.10.1 General
This subclause describes ECS procedures that change the BSS operating channel frequency and bandwidth.
When the STA’s dot11ExtendedChannelSwitchActivated value is true, the enabling STAs (see 11.12), APs,
DFS owners, and mesh STAs may construct and transmit frames that contain Extended Channel Switch
Announcement elements.
A STA shall use the ECS procedures defined in this subclause if dot11ExtendedChannelSwitchActivated is
true. To indicate that it can perform ECS procedures, a STA shall set
dot11ExtendedChannelSwitchActivated, dot11MultiDomainCapabilityActivated and
dot11OperatingClassesRequired to true and shall set to 1 the value of the Extended Channel Switching field
in the Extended Capabilities elements it transmits. When dot11ExtendedChannelSwitchActivated is false,
the STA shall not use ECS procedures. When an AP is switching to a different channel and one or more of
its associated STAs do not support extended channel switching capability, then both the Extended Channel
Switch Announcement and the Channel Switch Announcement elements and frames may be used.
If dot11ExtendedChannelSwitchActivated and dot11LCIDSERequired are true, frames containing Channel
Switch Announcement elements shall not be transmitted.
An enabling STA may send frames containing Extended Channel Switch Announcement elements to
dependent STAs (see 11.12.5). If dot11DSERequired is true, a STA shall perform ECS procedures to switch
at the time indicated by the channel switch count, or the STA shall change its enablement state for the
enabling STA to unenabled.
11.10.2 Advertising supported operating classes
When dot11ExtendedChannelSwitchActivated is true, the Current Operating Class field in the Supported
Operating Classes element shall indicate the operating class in use for transmission and reception. The
Operating Classes field shall list all operating classes with which the STA is capable of operating for the
country that is specified in the Country element (9.4.2.9).
11.10.3 Selecting and advertising a new channel and/or operating class
11.10.3.1 General
An attempt may be made to move a BSS to a new operating channel and/or new operating class using
extended channel switching. An objective during this process is to minimize disruption to the BSS. It is
1706
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
possible, however, that an extended channel switch is not successful in moving all STAs to the new channel
and/or operating class.
11.10.3.2 Selecting and advertising a new channel in an infrastructure BSS
When an AP with dot11DSERequired true receives frames containing Extended Channel Switch
Announcement elements from the enabling STA, it shall advertise an extended channel switch with the same
channel switch mode, new operating class, new channel number, and channel switch count as received in the
Extended Channel Switch Announcement elements.
The decision to switch to a new operating channel and/or operating class in an infrastructure BSS is made by
the AP when dot11DSERequired is false. An AP may make use of the information in the Supported
Channels element, Supported Operating Classes element, and the results of measurements undertaken by the
AP and other STAs in the BSS to assist the selection of the new channel and/or operating class. A method to
make the decision and to select a new channel is defined in 11.9.8.2.
When an AP is switching to a different operating class and dot11ExtendedChannelSwitchActivated is true,
then the AP shall use the Extended Channel Switch Announcement element and frame. In addition, the AP
may also send Channel Switch Announcement elements and frames when the requirements signified by the
new operating class are met by all associated STAs.
When an AP is switching to a new channel within the same operating class and
dot11ExtendedChannelSwitchActivated is true, then the AP shall send the Extended Channel Switch
Announcement element and frame, or both the Extended Channel Switch Announcement and the Channel
Switch Announcement elements and frames. If dot11ExtendedChannelSwitchActivated is false, the AP
shall send the Channel Switch Announcement element and frame, or both the Extended Channel Switch
Announcement and the Channel Switch Announcement elements and frames.
When dot11ExtendedChannelSwitchActivated is true, an AP shall inform associated STAs that the AP is
moving to a new channel and/or operating class and maintain the association by advertising the switch using
Extended Channel Switch Announcement elements in any transmitted Beacon frames, Probe Response
frames, and Extended Channel Switch Announcement frames until the intended channel switch time. The
AP may request STAs in the BSS to stop transmissions until the channel switch takes place by setting the
Extended Channel Switch Mode field to 1 in the Extended Channel Switch Announcement element. If
possible, the channel switch should be scheduled so that all STAs in the BSS, including STAs in power save
mode, have the opportunity to receive at least one Extended Channel Switch Announcement element before
the switch. The AP may send the Extended Channel Switch Announcement frame without performing a
backoff, after determining the WM is idle for one PIFS (see 10.3.2.3). When both the Extended Channel
Switch Announcement and the Channel Switch Announcement elements are transmitted in Public Action
frames, they shall be sent in separate frames.
If an Extended Channel Switch Announcement element in a Beacon or Probe Response frame is used to
announce a switch to a 40 MHz BSS bandwidth, then a Wide Bandwidth Channel Switch subelement in a
Channel Switch Wrapper element may be present in the same frame if the STA sending the frame is
extended spectrum management capable.
When a STA with dot11DSERequired equal to false receives an Extended Channel Switch Announcement
element, it may choose not to perform the specified switch, but to take alternative action. For example, it
might choose to move to a different BSS.
A non-AP STA in an infrastructure BSS shall not transmit the Extended Channel Switch Announcement
element.
1707
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.10.3.3 Selecting and advertising a new channel in an IBSS
When a DFS owner with dot11DSERequired true receives frames containing Extended Channel Switch
Announcement elements from the enabling STA, it shall advertise an extended channel switch with the same
channel switch mode, new operating class, new channel number, and channel switch count as received in the
Extended Channel Switch Announcement elements.
The DFS owner that advertises a channel switch shall follow the rules defined in 11.9.8.3 with the following
extensions:
a) If a DFS owner is switching to a new channel or to the same channel in a different operating class
and dot11ExtendedChannelSwitchActivated is true, then the DFS owner shall use the Extended
Channel Switch Announcement element and frame. Alternatively, both the Extended Channel
Switch Announcement and the Channel Switch Announcement elements and frames may be used
when Channel Switch Announcement elements and frames are permitted for operation in the band
signified by the new operating class.
b) If a DFS owner is switching to a new channel within the same operating class and
dot11ExtendedChannelSwitchActivated is true, then the DFS owner shall send the Extended
Channel Switch Announcement element and frame, or both the Extended Channel Switch
Announcement and the Channel Switch Announcement elements and frames. If
dot11ExtendedChannelSwitchActivated is false, the DFS owner shall send the Channel Switch
Announcement element and frame, or both the Extended Channel Switch Announcement and the
Channel Switch Announcement elements and frames.
c) If both the Extended Channel Switch Announcement and the Channel Switch Announcement
elements are transmitted in Public Action frames, they shall be sent in separate frames.
The DFS owner may transmit the Extended Channel Switch Announcement frame in an IBSS without
performing a backoff, after determining that the WM is idle for one PIFS (see 10.3.2.3).
11.10.3.4 Selecting and advertising a new channel in an MBSS
A mesh STA may make use of the information in the Supported Channels element, Supported Operating
Classes element, and the results of measurements undertaken by this mesh STA and other mesh STAs in the
MBSS to assist the selection of the new channel and/or operating class.
If dot11ExtendedChannelSwitchActivated is true, the mesh STA that advertises a channel switch shall
follow the rules defined in 11.9.8.4 with the following extensions:
a) If a mesh STA is switching to a different operating class, then the mesh STA shall use the Extended
Channel Switch Announcement element and frame. Alternatively, both the Extended Channel
Switch Announcement and the Channel Switch Announcement elements and frames may be used
when Channel Switch Announcement elements and frames are permitted for operation in the band
signified by the new operating class.
b) If a mesh STA is switching to a new channel within the same operating class, then the mesh STA
shall send the Channel Switch Announcement element and frame, or both the Extended Channel
Switch Announcement and the Channel Switch Announcement elements and frames.
c) If both the Extended Channel Switch Announcement and the Channel Switch Announcement
elements are transmitted in Public Action frames, they shall be sent in separate frames.
d) The Extended Channel Switch Announcement element shall be included in the Beacon and Probe
Response frames until the intended channel switch time.
1708
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.11 Radio measurement procedures
11.11.1 General
This subclause describes the radio measurements and the procedures for requesting and reporting radio
measurements between STAs. When a STA implements support for one or more of the procedures described
in this subclause, it shall set dot11RadioMeasurementActivated to true. When
dot11RadioMeasurementActivated is true, dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated, dot11OperatingClassesImplemented, and
dot11OperatingClassesRequired shall be true.
NOTE—A key issue in radio measurement is network operation and management, considering each STA’s service load,
power state, and operating conditions. Timely measurement reports might be more important than percentage of wireless
capacity or STA capacity used by radio measurements. The measurement requester might consider traffic load and
application requirements, regulatory requirements, and specific measurement states from every STA in support of
wireless network management. There are no typical scenarios that describe IEEE 802.11 operation in all bands. Off-
channel measurements are desirable to gather timely information about the channel to which to switch BSS operation,
and the noisier the operating environment, the more urgent the need for radio measurements off the serving channel. In
any case, the measuring STA might refuse any measurement request.
11.11.2 Measurement on operating and nonoperating channels
Measurements on nonoperating channels might need the measuring STA to interrupt its data services on the
operating channel, switch channels, and make measurements. Measurements on the operating channel might
not require the STA to interrupt its data services.
All stations are responsible for maintaining data services and an association or membership with the BSS on
the operating channel while performing measurements on nonoperating channels.
A STA shall determine the time between successive nonoperating channel measurements. This time may be
a fixed length, or it may be determined by the STA using application-specific (or other) knowledge.
11.11.3 Measurement start time
A Radio Measurement Request frame may contain a single Measurement Request element or a sequence of
Measurement Request elements. A STA that accepts the first or only measurement request within a Radio
Measurement Request frame shall start the measurement as soon as practical after receiving the request.
Subsequent measurement requests in the Radio Measurement Request frame that are accepted shall start as
soon as practical after processing the previous request in the frame. Such measurement start times shall be
subject to any specified randomization interval.
The radio measurement category permits a randomization interval to be specified for measurement start
times. The intent of this is to avoid traffic storms that could arise with synchronized group addressed
measurements. Prior to making each measurement in the requested sequence, the STA shall calculate a
random delay distributed uniformly in the range 0 to the randomization interval specified in the
measurement request. The STA shall not start the measurement until this delay has expired. Randomization
interval is specified in units of TUs. A randomization interval field value of 0 in a measurement request
indicates that no random delay is to be used.
NOTE—It is important that designers recognize the need for statistical independence among the pseudorandom number
streams among STAs.
A number of repetitions may be specified in the Radio Measurement Request frame. In this case, the
measurements in the frame are repeated as detailed further in 11.11.7. Each time a measurement is repeated,
the STA shall recalculate the random delay as described above.
1709
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When a Measurement Start Time field is present in a measurement report, the measuring STA shall report
the value of its TSF timer at the time the measurement started to an accuracy of ±1 TU.
11.11.4 Measurement Duration
The values of Request Measurement Duration and Duration Mandatory in the received measurement request
and the dot11RMMaxMeasurementDuration setting in the receiving STA determine if the receiving STA
accepts the measurement request and for how long the measurement is performed.
dot11RMMaxMeasurementDuration indicates a measurement duration using the following formula:
Maximum Measurement Duration in TUs = 2(dot11RMMaxMeasurementDuration – 4) BeaconInterval
Table 11-8 describes how a STA responds to a measurement request depending on the values of
dot11RMMaxMeasurementDuration, Measurement Duration, and Duration Mandatory.
Table 11-8—Measurement Duration
Measurement
dot11RMMaxMeasure Duration
Duration in the Notes
mentDuration Mandatory
Measurement Request
0 Any value 1 The STA shall perform measurements for
the requested measurement duration.
0 Any value 0 The STA may perform measurements for a
duration shorter than the requested
measurement duration
Nonzero Any value 0 The STA shall perform measurements for
a maximum duration that is equal to the
minimum of the requested measurement
duration and the
dot11RMMaxMeasurementDuration.
Nonzero Requested measurement 1 The STA shall reject the measurement
duration > Maximum request with the Measurement Report
Measurement Duration in Mode set to “refused.”
TUs
Nonzero Requested measurement 1 The STA shall perform the measurement
duration Maximum for the requested duration.
Measurement Duration in
TUs
Measurement duration on nonoperating channels is defined by
dot11RMNonOperatingChannelMaxMeasurementDuration. If this attribute is 0, the STA does not support
RM measurements on nonoperating channels; on receipt of a Measurement Request frame requesting a
measurement on nonoperating channels, the STA shall reject the measurement request by returning a
Measurement Report element in which the Incapable bit in the Measurement Report Mode field is 1. The
interpretation rules defined in Table 11-8 also apply for all nonzero values of
dot11RMNonOperatingChannelMaxMeasurementDuration for measurements on nonoperating channels.
NOTE—Measurement duration on nonoperating channels is subject to further limitations due to maximum off-operating
channel time.
If the Duration Mandatory bit is 1 in the Measurement Request mode field of a measurement request, the
requested STA, if it accepts the request, shall perform the measurement over the Measurement Duration
1710
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
specified in the request. If the STA is unable to commit to making the measurement over the requested
duration, it shall refuse the request by sending a measurement report in which the refused bit in the
Measurement Report Mode field is set to 1. The measurement duration in the measurement report is equal to
the requested measurement duration.
If the Duration Mandatory bit is 0 in the Measurement Request mode field of a measurement request, the
requested STA, if it accepts the request, shall attempt a measurement using the requested duration as a
maximum measurement duration, and may report results with an actual measurement duration less than the
requested duration. The duration over which the measurement was made will be included in the
measurement duration field of the measurement report.
Each separate measurement within the Radio Measurement Request frame shall be performed over a
continuous measurement duration time period. In Measurement Request frames the requested Measurement
Duration value shall not be set to 0 except when the request frame is a Beacon request in which the
Measurement Mode field value is Beacon Table, or is a STA Statistics request, or is a request for triggered
autonomous measurements.
11.11.5 Station responsibility for conducting measurements
A radio measurement-capable STA shall decode and interpret each Radio Measurement Request frame that
it receives and shall assess the contents against its capabilities and the impact on its own performance. A
measurement request may be refused by the receiving STA by sending a Radio Measurement Report frame
in which the refused bit in the Measurement Report Mode field is set to 1. The reasons for refusing a
measurement request are outside the scope of this standard but may include reduced quality of service,
unacceptable power consumption, measurement scheduling conflicts, or other significant factors.
In assessing the performance impact of each Measurement Request element, a STA may use application-
specific knowledge or other knowledge to limit the time it spends away from the operating channel. In doing
so, the STA may either:
— Reject any Measurement Request element in which the Duration Mandatory bit is 1 and that has a
mandatory measurement duration exceeding the maximum allowed off-operating channel time, or
— Measure for a reduced duration if the Duration Mandatory bit is 0.
A STA shall cancel all in-process radio measurements and shall delete all pending, unprocessed radio
measurement requests upon receipt of a Disassociation frame or upon (re)association with a BSSID different
from its most recent association.
11.11.6 Requesting and reporting of measurements
A STA may perform radio measurements on one or more channels itself or a STA may request STAs in the
same BSS to perform measurements on its behalf.
A STA advertises its radio measurement capability using the RM Enabled Capabilities element. If a STA
advertises that it is capable of a measurement, it shall not reject a request for the corresponding measurement
by sending a Radio Measurement Report frame in which the Incapable bit in the Measurement Report Mode
field is set to 1, except as specified in 11.11.9.7. Measurement requests for radio measurements that the STA
has advertised it is not capable of shall be rejected, and the corresponding report shall have the Incapable bit
in the Measurement Report Mode field set to 1.
When requesting other STAs to measure one or more channels, a STA shall use a Radio Measurement
Request frame containing one or more Measurement Request elements. The measurement request may be
sent to an individual or group destination address. The permitted measurement requests are shown in
Table 11-9.
1711
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-9—Allowed measurement requests
Destination of Receiver address of Measurement
Service set Source of request
request Request frame
Infrastructure BSS AP Non-AP STA Individual or group
Non-AP STA AP Individual only
Non-AP STA Non-AP STA Individual only for Direct Link
within a BSS served by QoS AP,
otherwise not allowed
IBSS Non-AP STA Non-AP STA Individual or group
PBSS PCP STA Individual or group
STA PCP Individual only
STA STA None
The source and destination of a measurement request shall both be a member of the same infrastructure BSS,
a member of the same PBSS, or a member of the same IBSS. Measurement requests with an individual
Receiver Address shall be sent only to STAs that have indicated radio measurement capability.
The set of requested measurements received in the most recently received Radio Measurement Request
frame of highest precedence is active. The precedence order for measurement requests shall be as follows
(highest precedence first):
— Measurement requests received in individually addressed Radio Measurement Request frames
— Measurement requests received in Multicast-group addressed Radio Measurement Request frames
— Measurement requests received in Broadcast addressed Radio Measurement Request frames
The Measurement Request elements shall be processed in sequence by default, with certain Measurement
Request elements processed in parallel according to the parallel bit field setting: see 9.4.2.21. A STA shall
accept a measurement request with the parallel bit field enabled if dot11RMParallelMeasurementsActivated
is true; otherwise, the STA shall reject the Measurement Request by returning a Measurement Report with
the Incapable bit in the Measurement Report Mode field set to 1.
If dot11RMParallelMeasurementsActivated is true and if measurement resources are available, the STA
processes each element by setting up and making the specified measurement. If measurement resources are
not available to perform the requested parallel measurements, the STA shall return a Measurement Report
with the Refused bit in the Measurement Report Mode field set to 1.
The Measurement Request elements within a Radio Measurement Request frame may specify multiple
measurement types across multiple channels.
A STA may receive another Radio Measurement Request frame while the measurements requested in a
previous Radio Measurement Request frame are pending or in progress. If this request is accepted, the set of
measurement requests in the new frame supersedes any previous requests received in a Radio Measurement
Request frame of the same or lower precedence. The measuring STA shall report the results of any
completed measurements and terminate any pending or in-progress measurements. Results from a
terminated in-progress measurement may be valid and reported if Duration Mandatory was not equal to 1 in
the corresponding request. It is permissible for the superseding Radio Measurement Request frame to
contain no new measurement requests. This has the effect of canceling all pending or in-progress
measurements of the same or lower priority. If a station receives a Radio Measurement Request frame with
1712
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
lower precedence than the currently active Radio Measurement Request frame, the station shall discard the
measurement requests in the new Radio Measurement Request frame. Measurement Request elements that
have the Enable bit equal to 1 shall be processed in all received Radio Measurement Request frames
regardless of these precedence rules.
If a STA receives a Measurement Request frame with Measurement Type field equal to 0 (Basic request),
this shall take priority over any pending or in-progress radio measurements.
A STA that issues a radio measurement request to another STA to perform a measurement on the operating
channel may continue to transmit MPDUs and MMPDUs to that STA while the measurement is being
processed.
A STA that issues a radio measurement request to another STA to perform a measurement on a nonoperating
channel is not required to take any special action to suspend traffic to that STA. All stations shall maintain
state information such that data services and association or membership with the BSS continue when
returning from a nonoperating channel measurement.
A single Measurement Request element may generate a large quantity of measurement report data. The
measurement report data may be reported using multiple measurement report elements in multiple
measurement report frames. The result of each measurement requested in a Measurement Request element
shall be reported in one or more Measurement Report elements of type corresponding to the request. Each
Measurement Report element returned shall have the same Measurement Token as in the corresponding
Measurement Request element, and the same Actual Measurement Start Time field, if present, as in the first
returned Measurement Report element. The results of each measurement should be returned without undue
delay to the requesting STA.
Measurement Report elements shall be returned to the requesting STA in one or more Radio Measurement
Report frames. Each Radio Measurement Report frame shall contain the same Dialog Token field value as
the corresponding Radio Measurement Request frame, and the same Actual Measurement Start Time field,
if present, as in the first returned Measurement Report element.
When a STA is permanently unable to make a requested measurement, the STA shall respond to such a
measurement request received within an individually addressed Radio Measurement Request frame with a
measurement report indicating that it is incapable of completing the measurement request. A STA shall not
respond to requests received in group addressed frames in this manner. Examples of when a response of
incapable is appropriate are:
— The requested measurement type is not supported.
— The measuring STA cannot support requested parallel measurements due to the requests relating to
different channels.
A STA that receives a response with an incapable indication shall not make the same request to the
responding STA during the lifetime of the current association, or IBSS membership. This is logically the
same as the responding STA using the Enable and Request bits in a measurement request to indicate that it
does not accept measurement requests of a certain type. A STA that has indicated an incapable response to a
requesting STA may discard further requests of the same type from that STA without responding.
A STA may refuse to make any requested measurement. A STA refusing a measurement request within an
individually addressed Radio Measurement Request frame shall respond with a measurement report
indicating that it is refusing the measurement request. A STA shall not respond to measurement requests
received in Radio Measurement Request frames in this manner.
By default, a STA may send a radio measurement request of any defined measurement type. A STA that
receives a Measurement Request element with the Enable bit equal to 1 and the Request bit equal to 0 shall
1713
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
not issue a measurement request of the type specified in the request to the STA from which the element was
received.
Since measurements on nonoperating channels interrupt normal operation on the operating channel, the
requesting STA should consider each STA’s service load, power state, and operating conditions. Since
measurements on the operating channel execute concurrently with normal traffic processing, operating
channel measurements can be requested more frequently and for longer durations.
11.11.7 Repeated Measurement Request frames
Radio Measurement Request frames contain a field specifying the number of repetitions for the Radio
Measurement Request frame.
If the Radio Measurement Request frame includes a nonzero value for the Number of Repetitions and
dot11RMRepeatedMeasurementsActivated is false, the STA shall reject the measurement request by
returning a Measurement Report with the Incapable bit in the Measurement Report Mode field set to 1.
If the Radio Measurement Request frame includes a nonzero value for the Number of Repetitions and
dot11RMRepeatedMeasurementsActivated is true, the STA shall iterate (repeat) the processing of all of the
Measurement Request elements in the frame as specified by the value in the Number of Repetitions field. A
value of 0 in the Number of Repetitions field indicates Measurement Request elements are executed once
without repetition; a value of 1 in the Number of Repetitions field indicates Measurement Request elements
are executed twice, one initial execution and one repetition; and so on. When completing the initial
processing of the last Measurement Request element in the frame, the STA shall begin processing of the first
Measurement Request element in the frame to repeat the frame until the number of iterations reaches the
value in the Number of Repetitions field. Measurement Request elements with the Enable bit equal to 1 shall
be processed once regardless of the value in the Number of Repetitions in the measurement request.
Each repeated measurement result shall include the same Measurement Token value as in the Measurement
Token field of the corresponding Measurement request element and the same value of the Dialog Token
field as in the Dialog Token field of the corresponding Radio Measurement Request frame.
Measurement results shall be reported for each repetition of a repeated measurement request subject to any
conditional reporting requirement.
STAs responding with incapable or refused indications to measurement requests within a Radio
Measurement Request frame with a nonzero value for Number of Repetitions shall respond only once.
11.11.8 Triggered autonomous reporting
Autonomous reporting is defined for spectrum management measurements supporting DFS; see 11.9.7. It
allows a STA to report the results of measurements to a peer STA for which there was no explicit
measurement request. In this case, the transmission of autonomous reports shall be entirely the decision of
the STA at which such reporting has been enabled. An example of this use would be to report a change in
conditions at the STA observed as a result of background measurement, e.g., the presence of a radar signal.
In radio measurement, triggered autonomous reporting shall be subject to trigger conditions set by the
enabling STA that determine when measurement reports are issued. Triggered autonomous reporting
provides a method for conditional reporting during continuous background measurements. An example of
the use of triggered autonomous measurement is for reporting problem conditions in continuous,
noninvasive statistical monitoring.
Triggered autonomous reporting is defined for the Transmit Stream/Category Measurement measurement
type; see 11.11.9.8. When dot11MulticastDiagnosticsActivated is true, triggered autonomous reporting is
1714
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
used for Multicast Diagnostics reports (11.11.19). When dot11TriggerSTAStatisticsActivated is true,
triggered autonomous reporting is used for STA Statistics reports (11.11.9.5).
If dot11RMTriggeredTransmitStreamCategoryMeasurementActivated is true, a STA indicates that it wishes
to accept triggered autonomous reports by sending a Measurement Request element with the Enable and
Report bits set to 1; see 9.4.2.21. The type of measurement is indicated in the Measurement Type field.
Trigger conditions that determine when measurement reports are to be generated shall be specified in the
Measurement Request field. A Measurement Request element that is being used to control triggered
autonomous reporting shall be sent within a Radio Measurement Request frame. Measurement Request
elements being used to request measurements may also appear in the same Radio Measurement Request
frame. The Radio Measurement Request frame may be sent to a group receiver address to enable triggered
autonomous reports at more than one STA.
A STA shall not send autonomous reports for radio measurement types having triggered autonomous
reporting enabled without a requested trigger condition having been met.
If a request to enable triggered autonomous reporting is sent to an individual address and the recipient STA
does not support measurements of the type indicated or the recipient STA has
dot11RMTriggeredTransmitStreamCategoryMeasurementActivated equal to false, a Measurement Report
element shall be returned to the requesting STA with the Incapable bit set to 1. A STA may also refuse to
enable triggered autonomous reporting. In this case a Measurement Report element shall be returned to the
requesting STA with the refused bit set to 1. Such responses shall not be issued if the request to enable
triggered autonomous reporting was sent to a group address.
A STA receiving a request to enable triggered autonomous reporting from another STA may send reports of
the appropriate type, addressed to the individual address of the STA that sent the enable request.
Autonomous reports shall be sent only to the individual addresses of STAs from which a valid enable
request has been received and shall be issued only when a requested trigger condition has been met. The
Measurement Token in each Measurement Report element and the value of the Dialog Token field in the
Measurement Report frame shall both be set to 0 in a triggered autonomous report.
A STA may update the trigger conditions set for triggered autonomous reports by issuing a new
Measurement Request element with the Enable and Report bits both set to 1, the Measurement Type field set
to the appropriate type and the Measurement Request field indicating the new trigger conditions. A STA
disables all triggered autonomous measurement reports by sending a Measurement Request element with the
Enable bit set to 1 and the Report bit set to 0; see 9.4.2.21.
A STA in an infrastructure BSS or PBSS shall cease all triggered autonomous reporting if it disassociates, or
reassociates to a different BSS (reassociation to the same BSS shall not affect triggered reporting). An IBSS
STA shall cease all triggered autonomous reporting if it leaves the BSS.
Triggered autonomous reporting and requested measurements are independent: a STA may request
measurements from another STA even if it has enabled triggered autonomous reporting from that STA. All
Measurement Request elements received in Radio Measurement Request frames that have the Enable bit
equal to 1 shall be processed without regard for the measurement precedence rules for requested
measurements in 11.11.6.
A number of triggered measurements may run concurrently at a non-AP STA. The number of simultaneous
triggered measurements supported is outside the scope of the standard. Each triggered measurement is
logically separate; reporting conditions such as Trigger Timeout periods apply only to the measurement for
which they are established.
1715
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.11.9 Specific measurement usage
11.11.9.1 Beacon report
If a STA accepts a Beacon request it shall respond with a Radio Measurement Report frame containing
Beacon reports for all observed BSSs matching the BSSID and SSID in the Beacon request, at the level of
detail requested in the Reporting Detail. If the Reporting Detail is 1 and the optional Request subelement is
included in the Beacon request, the corresponding Beacon report shall include the list of elements listed in
the Request subelement. The RCPI in the Beacon report indicates the power level of the received Beacon,
Measurement Pilot, or Probe Response frame. For repeated measurements (when the Measurement Request
frame contains a nonzero value for the Number of Repetitions field), the transmission of the Beacon report
may be conditional on the measured RCPI or RSNI value. If the Measurement Request frame contains a 0
value for the Number of Repetitions field, the Beacon Reporting subelement shall not be included in the
Beacon request. If the Measurement Request frame contains a nonzero value for the Number of Repetitions
field, and if both dot11RMBeaconMeasurementReportingConditionsActivated and
dot11RMRepeatedMeasurementsActivated are true, and if a Beacon Reporting subelement is included in a
Beacon request, the STA shall respond with a Beacon report if the indicated Beacon reporting condition is
true. Otherwise, the STA shall not respond with a Beacon report. Table 9-89 lists the reporting conditions
that are based on the measured RCPI or RSNI levels.
If the requested Beacon report includes the Supported Operating Classes element, then the channel number,
operating class, and/or reported frame information for that measurement may be included in the beacon
report; otherwise these fields shall be set to 255 in the beacon report. The STA shall use the Reporting Detail
specified in the measurement request to determine the data to be included in the measurement report. If the
STA has no beacon information available then the STA may either refuse the request or send an empty
Beacon report.
If dot11RMBeaconPassiveMeasurementActivated is true and the Measurement Mode in the measurement
request is Passive, the measuring STA shall perform the following procedure (or an equivalent procedure)
on the requested channel:
— Set a measurement duration timer.
— At the end of the measurement duration, process all received Beacons or Probe Response frames
with the requested SSID and BSSID to compile the measurement report. The STA shall use the
Reporting Detail specified in the measurement request to determine the data to be included in the
measurement report. If no Beacon or Probe Response frames with the requested SSID and BSSID
were received in the measurement duration, then process all Measurement Pilot frames with the
requested BSSID to compile the measurement report. Otherwise, compile an empty Beacon report.
If dot11RMBeaconPassiveMeasurementActivated is false and the Measurement Mode in the measurement
request is Passive, the measuring STA shall reject the measurement request by returning a Beacon report
with the Incapable bit in the Measurement Report Mode field set to 1.
If dot11RMBeaconActiveMeasurementActivated is true and the Measurement Mode in the measurement
request is Active, the measuring STA shall perform the following procedure (or an equivalent procedure) on
the requested channel:
— If the channel is not the operating channel, wait for dot11RMMeasurementNavSync, or until a PHY-
RXSTART.indication primitive has been received.
— Using the basic access protocol in 10.3.4.2, send a Probe Request frame to the broadcast destination
address (DA). The BSSID field in the Probe Request frame shall be set to the BSSID field in the
measurement request. The SSID element in the Probe Request frame shall be set to the SSID
element in the measurement request.
— Set a measurement duration timer.
1716
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— At the end of the measurement duration, process all received Probe Response and Beacon frames
with the requested SSID and BSSID to compile the measurement report. The STA shall use the
Reporting Detail specified in the measurement request to determine the data to be included in the
measurement report. If no Beacons or Probe Response frames were received in the measurement
duration and Measurement Pilot frames with the requested BSSID were received in the
measurement duration, then process all these Measurement Pilot frames to compile the measurement
report. Otherwise, compile an empty Beacon report.
If dot11RMBeaconActiveMeasurementActivated is false and the Measurement Mode in the measurement
request is Active, the measuring STA shall reject the measurement request by returning a Beacon report with
the Incapable bit set in the Measurement Report Mode field.
When more than one Beacon or Probe Response from a BSS is received in the measurement duration, the
contents of the Beacon report shall be based on the latest received. If only Measurement Pilot frames were
received in the measurement duration, the contents of the Beacon report shall be based on the latest
Measurement Pilot frame received.
If the BSSID field in the Measurement Request contains a wildcard BSSID, all observed BSSs with the
requested SSID shall be reported in a separate Beacon report for each BSSID. If the SSID subelement is not
included in the Beacon request, all observed BSSs shall be reported in a separate Beacon report for each
BSSID. In active mode, Probe Response frames shall be evaluated regardless of whether the Probe Response
frame was triggered by the measuring STA’s Probe Request.
On accepting an active or passive mode Beacon request, a STA shall conduct measurements as follows:
— If the Channel Number is 0 and the Operating Class identifies the location of the primary channel,
then a STA shall conduct iterative measurements on all supported channels in the specified
Operating Class where the measurement is permitted on the channel and the channel is valid for the
current regulatory domain.
— If the Channel Number is 0 and if the Operating Class encompasses a primary channel but does not
identify the location of the primary channel, then a STA shall conduct iterative measurements on all
primary channel positions within all requested and supported channels where the measurement is
permitted on the channel and the channel is valid for the current regulatory domain.
— If the Channel Number is 255, the Operating Class identifies the location of the primary channel,
and the Beacon request includes AP Channel Report subelements, a STA shall conduct iterative
measurements on all supported channels listed in the AP Channel Report subelements that are valid
for the current regulatory domain. If there is no AP Channel Report subelement included in the
Beacon request, a STA shall conduct iterative measurements on all supported channels listed in the
latest AP Channel Report received from the serving AP that are valid for the current regulatory
domain. If there are no AP Channel Report subelements included in the Beacon request, and no AP
Channel Report included in last received AP Beacon frame, the STA shall reject the Beacon request.
— If the Channel Number is 255, the Operating Class encompasses a primary channel but does not
identify the location of the primary channel, and the Beacon request includes AP Channel Report
subelements, then a STA shall conduct iterative measurements on all primary channel positions
within all requested (in the AP Channel Report) and supported channels that are valid for the current
regulatory domain. If there are no AP Channel Report subelements included in the Beacon request,
the STA shall reject the Beacon request.
— If the Channel Number is a value other than 0 or 255, a STA shall conduct iterative measurements
on the requested channel, where the measurement is permitted on the channel and the channel is
valid for the current regulatory domain.
Except when the Measurement Mode field is equal to Beacon Table, measurements shall be made using the
specified Measurement Duration with the time between each consecutive measurement as defined in
1717
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.11.2. Iterative measurements shall cease when all channels have been measured. While the STA is
processing a Beacon request for iterative channel measurements, the STA shall not begin processing the
next measurement request in the Measurement Request frame.
If dot11RMBeaconTableMeasurementActivated is true and the Measurement Mode in the measurement
request is Beacon Table, the measuring STA shall return a Beacon report containing the current contents of
any stored beacon information for any supported channel with the requested SSID and BSSID without
performing additional measurements. The receiving STA shall ignore the channel and measurement duration
specified in the Beacon request when the Measurement Mode field contains Beacon Table. The beacon
information accumulated may be the result of any operation that caused the STA to acquire these results. If
the stored beacon information is based on a measurement made by the reporting STA, and if the actual
measurement start time, measurement duration, and Parent TSF are available for this measurement, then the
beacon report shall include the actual measurement start time, measurement duration, and Parent TSF;
otherwise the actual measurement start time, measurement duration, and Parent TSF shall be set to 0. The
RCPI and RSNI for that stored beacon measurement may be included in the beacon report; otherwise the
beacon report shall indicate that RCPI and RSNI measurements are not available.
If dot11RMBeaconTableMeasurementActivated is false and the Measurement Mode in the measurement
request is Beacon Table, the measuring STA shall reject the measurement request by returning a Beacon
report with the Incapable bit set in the Measurement Report Mode field.
For repeated measurements, the Beacon request may include a Beacon Reporting subelement that
determines when the measuring STA is to send a Beacon report for a measured Beacon, Measurement Pilot,
or Probe Response frame with the requested SSID and BSSID. When the requested Reporting Condition
value is nonzero, and dot11RMBeaconMeasurementReportingConditionsActivated is true, the STA shall
create and transmit a Beacon report for that measured frame if the condition indicated in Table 9-89 is true.
Otherwise, the STA shall not transmit a Beacon report for that measured frame. If multiple Beacons,
Measurement Pilots, or Probe Response frames with the requested specific BSSID are received during the
measurement duration, the reporting condition shall be applied only to the latest received Beacon,
Measurement Pilot, or Probe Response frame. If multiple Beacons, Measurement Pilots, or Probe Response
frames are received during the measurement duration when a wildcard BSSID is requested, the STA shall
generate one Beacon report for each BSSID occurring in frames that satisfy the reporting condition; the
Beacon report shall be based on the latest received Beacon, Measurement Pilot, or Probe Response frame for
that specific BSSID. For reporting conditions 5–10, the serving AP’s reference RCPI level and the serving
AP’s reference RSNI level referred to in Table 9-89 are average values of the RCPI or RSNI of the 16 most
recent Beacon frames received from the measuring STA’s serving AP. The serving AP’s reference RCPI
level and the serving AP’s reference RSNI level are so averaged to provide a more accurate and stable
indication of the signal level from the serving AP. For reporting conditions 5–10, the STA shall use the
serving AP’s reference RCPI level or reference RSNI level (with offset, if any) to test the measured RCPI or
RSNI to determine whether to create and send a Beacon report for this measured Beacon, Measurement
Pilot, or Probe Response frame.
The STA shall return a Beacon report with the Incapable bit set in the Measurement Report Mode field in the
following cases:
— Reporting Condition in the Beacon request is nonzero and dot11ReportingConditionsActivated is
false,
— Reporting Condition in the Beacon request is nonzero and the Number of Repetitions in the
Measurement Request frame is 0.
NOTE—Reporting conditions described here for repeated Beacon request measurements are distinct from the conditions
defined elsewhere for triggered measurements.
A STA that is not extended spectrum management capable shall not include a Wide Bandwidth Channel
Switch subelement in a Beacon request or Beacon report. A STA shall not include a Wide Bandwidth
1718
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Channel Switch subelement in a Beacon request or Beacon report sent to a STA that is not extended
spectrum management capable. If the Wide Bandwidth Channel Switch subelement is included in a Beacon
request or Beacon report, then the Operating Class shall indicate a 40 MHz channel spacing.
If N (where N 1) AP Channel Report subelements containing an Operating Class with an 80+ behavior
limit (the 80+ behavior limit is defined in Table D-2, the operating classes that might use this limit are
defined in E.1) are included contiguously in a Beacon request, then the N subelements shall be followed by
one AP Channel Report subelement containing an Operating Class without an 80+ behavior limit (as defined
in Annex E). All N+1 Channel List fields in each of these subelements shall contain the same number L of
channel numbers. This sequence of N+1 AP Channel Report subelements indicates a list of L noncontiguous
channels comprising N+1 frequency segments, where the lth channel number in the nth Channel List field
identifies the channel center frequency of the nth frequency segment.
NOTE—To identify the BSS bandwidth, the Beacon request might include a Request subelement listing the element IDs
of the HT Operation and VHT Operation elements. The Beacon report would then include the requested elements, which
contain fields defining the BSS bandwidth.
11.11.9.2 Frame report
If dot11RMFrameMeasurementActivated is true, and a station accepts a Frame request, it shall respond with
a Radio Measurement Report frame containing one or more Measurement Report elements with the
Measurement Type field set to Frame. (See 9.4.2.22.8.)
If the MAC Address field included in the Frame request was not set to the broadcast address, a Frame Report
Entry field where Transmitter Address (TA) matching the MAC address field value shall be included in the
Frame report if at least one Data or Management frame was received with this Transmitter Address during
the measurement duration. If the MAC address field included in the Frame request was set to the broadcast
address, the measuring station shall report all Data or Management frames received during the measurement
duration in one or more Frame reports.
If the Frame Request Type of the corresponding Frame request equals 1, then each Frame report contains
one Frame Count subelement that contains in turn one or more Frame Report Entries.The measuring station
shall count the number of individually addressed Data and Management frames received from one transmit
address during the measurement duration and shall summarize this traffic in a frame report entry.
Each Frame Report Entry field contains the Transmit Address, BSSID, PHY Type, Average RCPI, Last
RSNI, Last RCPI, Antenna ID, and Frame Count for the frames counted in this Frame Report Entry field.
The reported Average RCPI shall be an average of the RCPI values of frames received and counted in the
Frame Report Entry field. If there are up to 32 frames, then the Average RCPI indicates the mean of the
RCPI of each of the frames. If there are more than 32 frames, then the Average RCPI indicates an
exponentially weighted average, initialized by the mean RCPI of the first 32 frames and exponentially
updated by new RCPI values. The averaging is calculated as depicted as follows.
If the number of frames received is less than or equal to 32:
Average RCPI = Sum of RCPI values / Number of frames
For 33 received frames and above:
Average RCPI = (Last Average RCPI 31 / 32) + (Current frame RCPI / 32)
The Last RCPI shall be the RCPI value of the most recently received frame counted in the Frame Report
Entry field. The Antenna ID field contains the identifying number for the antenna(s) used to receive the most
recently received frame included in this Frame Report Entry field as defined in 9.4.2.40. If different
1719
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
antennas are used to receive the frame preamble and the frame body, this Antenna ID shall contain the
identifying number for the antenna(s) used to receive the frame body.
If dot11RMFrameMeasurementActivated is false, a station shall reject the received Frame request by
returning a Frame report in which the Incapable bit in the Measurement Report Mode field is 1.
A STA that is not extended spectrum management capable shall not include a Wide Bandwidth Channel
Switch subelement in a Frame request or Frame report. A STA shall not include a Wide Bandwidth Channel
Switch subelement in a Frame request or Frame report sent to a STA that is not extended spectrum
management capable. If the Wide Bandwidth Channel Switch subelement is included in a Frame request or
Frame report, then the Operating Class shall include a 40 MHz channel spacing.
11.11.9.3 Channel load report
If dot11RMChannelLoadMeasurementActivated is true and a station accepts a Channel Load request, it
shall respond with a Radio Measurement Report frame containing one Measurement (Channel Load) Report
element. The Channel Load field is defined as the percentage of time, linearly scaled with 255 representing
100%, the STA sensed the medium was busy, as indicated by either the virtual carrier sense mechanism or
the physical carrier sense mechanism over the requested channel width (together referred to as the CS
mechanism). This percentage is computed using the following formula:
channel busy time
Channel Load = -----------------------------------------------------------------------
- 255
MeasurementDuration 1024
where channel busy time is defined to be the number of microseconds during which the CS mechanism, as
defined in 10.3.2.1, has indicated a channel busy indication for the requested channel width.
If dot11RMChannelLoadMeasurementActivated is false, a station shall reject the received Channel Load
request by returning a Channel Load report with the Incapable bit in the Measurement Report Mode field set
to 1.
If dot11RMChannelLoadMeasurementActivated is true and if a Channel Load Reporting subelement is
included in a Channel Load request, the STA shall respond with a Channel Load report if the indicated
channel load reporting condition is true. Otherwise, the STA shall not respond with a Channel Load report.
A STA that is not extended spectrum management capable shall not include a Wide Bandwidth Channel
Switch subelement in a Channel Load request or Channel Load report. A STA shall not include a Wide
Bandwidth Channel Switch subelement in a Channel Load request or Channel Load report sent to a STA that
is not extended spectrum management capable. If the Wide Bandwidth Channel Switch subelement is
included in a Channel Load request or a Channel Load report, then the Operating Class shall indicate a
40 MHz channel spacing.
11.11.9.4 Noise Histogram report
If dot11RMNoiseHistogramMeasurementActivated is true and a station accepts a Noise Histogram request,
it shall respond with a Radio Measurement Report frame containing one Measurement (Noise Histogram)
Report element. The Noise Histogram report shall contain the IPI densities observed in the channel for the
IPI levels defined in Table 9-110.
To compute the IPI densities, a STA shall measure the amount of time, in microseconds, during which the
IPI is in each IPI range specified in Table 9-110. These IPI measurements shall be taken over the entire
associated channel bandwidth, and during the requested measurement duration except for those time
intervals during which the NAV is not equal to 0 (when virtual CS mechanism indicates channel busy), or
1720
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
during which frame transmission or reception is occurring. The IPI densities are then computed for each of
the nine possible IPI values using:
255 D IPI
IPI Density = Integer ------------------------------------------------------------------------------
-
1024 D M – T NAV – T TX – T RX
where
DIPI is the duration receiving at the specified IPI value ( s)
DM is the measurement duration (TU)
TNAV is the total time that NAV is nonzero during the Measurement Duration ( s)
TTX is the frame transmission time during the Measurement Duration ( s)
TRX is the frame reception time during the Measurement Duration ( s)
The sum of the IPI densities is approximately 255. If either the NAV is nonzero, or if there is frame
transmission, or if there is frame reception throughout the entire measurement duration period, no reportable
IPI values are measured, and all IPI Densities shall be set to 0 in the Measurement Report element.
A STA shall include in the Noise Histogram report an average noise power indicator (ANPI) value
representing the average noise plus interference power on the measured channel at the antenna connector
during the measurement duration. The STA may use Noise Histogram IPI density values to calculate ANPI.
The IPI densities in the Noise Histogram report may be used to calculate an average noise power for the
channel during the measurement duration. This calculated average IPI power value may be reported as the
value for ANPI. Any equivalent method to measure ANPI may also be used. ANPI power is defined in dBm
using the same accuracy as defined for RCPI.
ANPI may be calculated over any period and for any received frame. ANPI may be calculated in any period
and at any time by filtering all PHY IPI values in a MAC filter to exclude IPI values received when NAV is
nonzero. These filtered IPI values represent idle channel noise and may be stored in a first-in-first-out
(FIFO) buffer to facilitate ANPI calculation over a fixed number of IPI samples. ANPI may be so calculated
upon receipt of any frame and may be used with RCPI to calculate RSNI for any received frame. Any
equivalent method to measure ANPI may also be used to calculate RSNI for any received frame.
If dot11RMNoiseHistogramMeasurementActivated is false, a station shall reject the received Noise
Histogram request by returning a Noise Histogram report with the Incapable bit in the Measurement Report
Mode field set to 1.
If dot11RMNoiseHistogramMeasurementActivated is true and if a Noise Histogram Reporting subelement
is included in a Noise Histogram request, the STA shall respond with a Noise Histogram report if the
indicated noise histogram reporting condition is true. Otherwise the STA shall not respond with a Noise
Histogram report.
A STA that is not extended spectrum management capable shall not include a Wide Bandwidth Channel
Switch subelement in a Noise Histogram request or Noise Histogram report. A STA shall not include a Wide
Bandwidth Channel Switch subelement in a Noise Histogram request or Noise Histogram report sent to a
STA that is not extended spectrum management capable. If the Wide Bandwidth Channel Switch
subelement is included in a Noise Histogram request or a Noise Histogram report, then the Operating Class
shall indicate a 40 MHz channel spacing.
11.11.9.5 STA Statistics report
If dot11RMStatisticsMeasurementActivated is true and a station accepts a STA Statistics request, it shall
respond with a Radio Measurement Report frame including one STA Statistics report. If the Requested
1721
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Measurement Duration value is 0, the STA shall report the current values for the requested Statistics Group
Data. If the Requested Measurement Duration value is greater than 0, the STA Statistics report reports the
change in the requested Statistics Group Data measured within that nonzero Measurement Duration. The
reported change in data value shall be the value of the data at the end of the actual Measurement Duration
minus the value of the data at the beginning of the actual Measurement Duration. If a STA accepts a STA
Statistics request measurement with nonzero, positive Measurement Duration, the STA shall perform the
measurement over the requested Measurement Duration without regard to the Duration Mandatory bit in the
Measurement Request Mode field. If a STA cannot measure over the requested Measurement Duration, the
STA shall refuse the Statistics request measurement.
If dot11RMStatisticsMeasurementActivated is false, a station shall reject the received STA Statistics request
by returning a Statistics Measurement Report with the Incapable bit in the Measurement Report Mode field
set to 1.
A STA may request that a STA Statistics report be sent when statistics of interest reach a threshold as
defined in the Measurement Request element of the STA Statistics request frame (see 9.4.2.21.9). This is
termed a triggered STA Statistics measurement. Implementation of Triggered STA Statistics Reporting is
optional for a WNM STA. A STA that implements Triggered STA Statistics Reporting has
dot11TriggerSTAStatisticsImplemented equal to true. When dot11TriggerSTAStatisticsImplemented is
true, dot11WirelessManagementImplemented shall be true.
A triggered STA Statistic measurement shall be requested by setting the Enable and Report bits to 1 within a
Measurement Request element with the Measurement Type field set to STA Statistics. The Measurement
Request field shall contain a STA Statistics request with the trigger conditions specified in the Triggered
Reporting subelement, as defined in 9.4.2.21.9. One or more trigger conditions shall be set with specified
thresholds. See 11.11.8. To prevent generation of too many triggered reports, the value of the Trigger
Timeout field shall be set to a value greater or equal to dot11MinTriggerTimeout. If the value of the Trigger
Timeout field is less than dot11MinTriggerTimeout, the STA shall reject the measurement request by
returning a report where the Measurement Report Mode field is “Incapable.”
A STA accepting a triggered STA Statistics measurement shall measure the requested statistics. If a trigger
condition occurs, the measuring STA shall send a STA Statistics measurement report to the requesting STA.
The measuring STA shall not send further triggered STA Statistics reports for that trigger condition to the
requesting STA until the Trigger Timeout period specified in the request frame has expired. The STA
Statistics measurement report is defined in 9.4.2.21.9. If the number of MPDUs or MSDUs indicated in the
Measurement Count field are transmitted or received without any of the counted statistics meeting the
corresponding trigger threshold then the measuring STA shall restart measuring for another measurement
count window.
If a STA receives a STA Statistics request from the same STA for which a triggered STA Statistics
measurement is in progress, the in-progress triggered measurement shall be terminated.
STA Statistics reported in a triggered STA Statistics report shall be the values accumulated over the number
of transmitted or received MSDUs or MPDUs before the trigger condition is met. Measurement duration
shall not be specified when requesting a triggered STA statistics measurement and the Measurement
Duration field in the corresponding Measurement Request shall be set to 0.
All triggered STA Statistics measurements shall be terminated at a measuring STA by receiving a STA
Statistics request with the Enable bit equal to 1 and the Report bit equal to 0. A STA requesting a triggered
STA Statistics measurement may update the trigger conditions by sending a STA Statistics request
specifying the new trigger conditions.
1722
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Once accepted by a measuring STA, a triggered STA Statistics measurement continues to be active until the
measurement request is superseded by a STA Statistics request from the requesting STA or the measuring
STA disassociates or reassociates.
11.11.9.6 LCI report (Location configuration information report)
If dot11RMLCIMeasurementActivated is true, a STA that receives an LCI request for location information
that is not available shall respond with a Radio Measurement Report frame including a Radio Measurement
Report element with the Refused bit set to 1. If dot11RMLCIMeasurementActivated is true and a STA
accepts an LCI request that does not include an azimuth request, it shall respond with a Radio Measurement
Report frame including one LCI subelement (LCI report). If both dot11RMLCIMeasurementActivated and
dot11RMLCIAzimuthActivated are true, and the STA accepts an LCI request that includes an azimuth
request, it shall respond with a Radio Measurement Report frame that includes one LCI subelement (LCI
report) and the requested Azimuth Report, if available. If dot11RMLCIAzimuthActivated is false, a STA
that receives an LCI request that includes an azimuth request shall respond with a Radio Measurement
Report frame including an Radio Measurement Report element with the Incapable bit set to 1.
The Datum value shall be 1 (World Geodetic System 1984), unless another datum is required for operation
in the regulatory domain.
If the Altitude Type is 2 (Floors of Altitude), the value reported shall be as required for operation in the
regulatory domain.
An LCI request shall indicate a location request for the requesting STA, the reporting STA, or a third STA
with the MAC address specified in the Target MAC Address subelement, by setting the LCI request
Location Subject field to indicate a Local, a Remote, or a third-party request, respectively. Local LCI
request is used by the requesting STA to obtain its own location by asking “Where am I?” Remote LCI
request is used by requesting STA to obtain location of reporting STA by asking “Where are you?” Third-
party location request is used by requesting STA to obtain location of a STA with the MAC address
specified in the Target MAC Address subelement.
The Latitude, Longitude, and Altitude fields of the LCI report shall be reported at their best known
resolutions unless otherwise configured.
If the STA receiving an LCI request has no location information about the requested LCI subject’s physical
location, the STA shall send a LCI subelement indicating an unknown LCI (see 9.4.2.22.10). If the STA
receiving an LCI request has no location information about the requested Azimuth, the STA shall omit the
Azimuth Report subelement. If the STA receiving an LCI request that contains a Maximum Age subelement
has already determined the requested LCI within the indicated maximum age, the STA may respond with its
already determined LCI; otherwise, the STA shall update its LCI before the STA responds with its LCI. The
method by which the physical location and azimuth information in the LCI report is generated is outside the
scope of this standard.
A STA that receives an LCI report that contains a Usage Rules/Policy subelement shall process the LCI
information in compliance with the retransmission and retention permissions in the Usage-rules subelement.
NOTE—A STA that requested an LCI including an Azimuth Request, and received an LCI report in which the Incapable
bit is 1 might alternatively request the LCI with no Azimuth requested.
If dot11RM3rdPartyMeasurementActivated is false, a STA that receives an LCI request that includes an LCI
request with the Location Subject field equal to 2 shall respond with a Radio Measurement Report frame
including an Radio Measurement Report element with the Incapable bit set to 1.
1723
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is optional for a STA to support an LCI request and an LCI report with the Location Subject field equal
to 2. If dot11RM3rdPartyMeasurementActivated is true and a STA supports LCI request and LCI report, the
following procedure shall be followed:
— When a non-AP STA requests the geospatial location of a STA with the MAC address specified in
the Target MAC address field, it shall also include its own MAC address in the Originator
Requesting STA MAC address field. When an AP receives an LCI request with the Location Subject
field value equal to 2, the AP shall generate an LCI request to the STA with the MAC address
specified in the Target MAC address field. If the AP does not have an association with the STA with
the MAC address specified in the Target MAC address field, the AP shall reject the received LCI
request by returning an LCI report where the Incapable bit is set in the MeasurementReport Mode
field. The AP shall copy the Originator Requesting STA MAC address and Target MAC address
fields into the request from the received LCI request.
— When a STA receives an LCI request with the Location Subject field value equal to 2, the STA may
generate an LCI report if the MAC address in the Target MAC address field is its own MAC
address; it shall not generate an LCI report otherwise. When an LCI report is generated, the
reporting STA shall include its MAC address into the Target MAC address field and the MAC
address present in the Originator Requesting STA MAC address field of the corresponding LCI
request into the Originator Requesting STA MAC address field. When an AP receives an LCI report
with an Originator Requesting STA MAC address field present, the AP shall generate an LCI report
to the associated STA with the MAC address specified in the Originator Requesting MAC address
field. The AP shall copy the Originator Requesting STA MAC address and Target MAC address
fields into the LCI report being transmitted to the originating requesting STA.
If dot11RMLCIMeasurementActivated is false, a station shall reject the received LCI request by returning
an LCI report with the Incapable bit in the Measurement Report Mode field set to 1.
If dot11RMLCIMeasurementActivated is true and a STA has its own location configured in LCI format
excluding an unknown LCI as defined in 9.4.2.21.10, the STA shall set dot11RMLCIConfigured to true.
NOTE—It is recommended that User Applications not send location information to other stations without the express
permission of the user. User agents acquire permission through a user interface, unless they have prearranged trust
relationships with users. Those permissions that are acquired through the user interface and that are preserved beyond
the current browsing session (i.e., beyond the time when the BSS connection is terminated) are revocable and receiving
stations should respect revoked permissions. Some user applications might have prearranged trust relationships that do
not require such user interfaces. For example, while a social networking application might present a user interface when
a friend performs a location request, a VOIP telephone might not present any user interface when using location
information to perform an E911 function.
11.11.9.7 Measurement Pause
A measurement pause is used within a Measurement Request frame to provide a time delay between the
processing of two other Measurement Request elements within the sequence of Measurement Request
elements in that frame.
If a STA accepts a Measurement Pause request it shall delay processing of the next measurement request in
the Measurement Request frame. If the Measurement Pause request is the last Measurement Request
element in a repeated Measurement Request frame, the STA shall delay processing the first Measurement
Request element in the Measurement Request frame for the next repeat. In each case the delay shall be no
less than the Pause Time value specified in the Measurement Pause request.
NOTE—Measurement pause is always supported by a STA implementing radio measurements.
A measurement pause shall not be sent as the only Measurement Request element in a Measurement Request
frame. A measurement pause shall not be included as the last Measurement Request element in a
Measurement Request frame that has the Number of Repetitions field equal to 0.
1724
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A measurement pause cannot be processed in parallel to other measurements. If the Parallel bit is 1 in the
Measurement Request element immediately prior to a measurement pause, an incapable response shall be
returned even if dot11RMParallelMeasurementsActivated is true.
There is no measurement report associated with a Measurement Pause request.
11.11.9.8 Transmit Stream/Category Measurement report
The Transmit Stream/Category Measurement applies to TIDs for Traffic Streams associated with TSPECs
and also to TIDs for Traffic Categories for QoS traffic without TSPECs.
If dot11RMTransmitStreamCategoryMeasurementActivated is true and has no resource constraint that
prevents it from being able to make the requested measurement, a QoS STA receiving a Transmit Stream/
Category Measurement request shall respond with a Radio Measurement Report frame containing one
Measurement (Transmit Stream/Category Measurement) Report element. If the traffic stream (TS) that is
corresponding to the Traffic Identifier is deleted, either by a DELTS frame or by disassociation, the STA
shall cease sending Radio Measurement Reports.
If dot11RMTransmitStreamCategoryMeasurementActivated is false, a STA shall reject the received
Transmit Stream/Category Measurement request by returning a Transmit Stream/Category Measurement
report with the Incapable bit in the Measurement Report Mode field set to 1.
The transmit stream/category measurement shall be made on traffic that is transmitted from the measuring
QoS STA to the peer QoS STA and TID indicated in the request. The Peer STA Address may be the MAC
address of the QoS STA from which the Measurement Request was sent, the MAC address of another QoS
STA within the BSS, or the broadcast address. This enables a QoS AP to query Transmit Stream/Category
Measurement metrics for DLS links. A broadcast address shall be used only with a TID corresponding to a
TC. In the case of a broadcast address, measurement shall be made on all traffic for the specified TC.
Depending on policy, a QoS AP may disallow transmit stream/category measurement requests for traffic to
other QoS STAs in the BSS. In this case the QoS AP shall respond with a matching Measurement Report
frame with the Incapable subfield of the Measurement Report Mode field set to 1.
If, during the course of a Transmit Stream/Category Measurement, any counter that is included in the
Transmit Stream/Category Measurement report increments to a value of 232–1, the Transmit Stream/
Category Measurement shall terminate, and the Transmit Stream/Category Measurement report shall
indicate the shortened, actual measurement duration.
If the measurement request included multiple transmit stream/category measurement requests for multiple
TIDs, the corresponding measurement report shall include a transmit stream/category measurement report
for each unique TID in the request that has been admitted. If the measurement request is for a TID that has
not been admitted yet, a report is generated only after the TID becomes admitted.
The requesting and reporting STAs are QoS STAs. A non-QoS STA receiving a Transmit Stream/Category
Measurement request shall reject the request by returning an indication of incapable.
A QoS STA may request that a measuring QoS STA send a transmit stream/category measurement report
when the number of TID-specified MSDUs are discarded or delayed reaches a specified threshold. This is
termed a triggered transmit stream/category measurement and shall be requested by setting the Enable
and Report bits to 1 within a Measurement Request element containing the Transmit Stream/Category
Measurement Type. The Measurement Request field shall contain a Transmit Stream/Category
Measurement request with the trigger conditions specified in the Triggered Reporting subelement. One or
more trigger conditions may be set with specified thresholds. See 9.4.2.21.11.
1725
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Depending on policy, a QoS AP might not permit the establishment of triggered transmit stream/category
measurement. Such a QoS AP receiving a triggered transmit stream/category measurement request shall
give an incapable indication. The number of simultaneous triggered transmit stream/category measurements
supported at a QoS STA is outside the scope of the standard. A STA shall respond to further requests with a
refused indication if the number of simultaneous triggered QoS measurements supported by the STA is
reached.
If dot11RMTriggeredTransmitStreamCategoryMeasurementActivated is true, a QoS STA shall accept a
triggered Transmit Stream/Category Measurement and shall reject it otherwise. A QoS STA accepting a
triggered QoS measurement shall measure the requested TC or TS. If a trigger condition occurs, the
measuring QoS STA shall send a Transmit Stream/Category Measurement report to the requesting QoS
STA. The measuring QoS STA shall not send further triggered QoS reports until the Trigger Timeout period
specified in the request has expired or new trigger conditions have been requested. Measurement of transmit
stream/category metrics shall continue during the reporting timeout period. Reporting shall resume
following the Trigger Timeout period, or immediately following the acceptance of new trigger conditions.
If a QoS STA receives a Transmit Stream/Category Measurement request for a TC, or TS that is already
being measured using a triggered transmit stream/category measurement, the triggered traffic stream
measurement shall be suspended for the duration of the requested traffic stream measurement. When
triggered measurement resumes, the traffic stream metrics shall be reset.
Traffic stream metrics reported in a triggered transmit stream/category measurement report shall be the
values accumulated over the number of successfully and unsuccessfully transmitted MSDUs prior to the
trigger event given in the Measurement Count field of the transmit stream/category measurement request
that established the trigger condition. It is possible that a consecutive or delay trigger event occurs after
acceptance of a triggered transmit stream/category measurement but before the number of MSDUs in
Measurement Count has been transmitted. In this case the report shall be the values accumulated since
measurement started. The measurement count value appears in the Transmitted MSDU Count field of a
triggered transmit stream/category measurement report. Measurement duration shall not be used in triggered
QoS measurement, and the Measurement Duration field in both the Measurement Request and any
Measurement Report shall be set to 0.
The Measurement Start Time field of a triggered transmit stream/category measurement report shall contain
the value of the QoS STA TSF timer at the time the trigger condition occurred to an accuracy of 1 TU.
Once accepted by a measuring QoS STA, a triggered QoS measurement continues to be active until
— The relevant TS is deleted,
— The measuring QoS STA or QoS STA that requested the measurement disassociates or successfully
reassociates, or
— The measurement is terminated by the requesting QoS STA.
All triggered QoS measurements shall be terminated at a measuring QoS STA by receiving a triggered
transmit stream/category measurement request with the Enable bit equal to 1 and the Report bit equal to 0. A
triggered QoS measurement request with no trigger conditions specified in the Trigger Conditions field shall
terminate a triggered QoS measurement for the TC or TS specified in the request. A QoS STA requesting a
triggered QoS measurement may update the trigger conditions by sending a triggered transmit stream/
category measurement request specifying the new trigger conditions.
11.11.9.9 Location Civic report
If dot11RMCivicMeasurementActivated is true and civic location information is not available, the STA
shall reject a Location Civic request by returning a Measurement Report frame including a Measurement
Report element with the Refused bit set to 1. If dot11RMCivicMeasurementActivated is true and civic
1726
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
location information is available, the STA shall respond with a Measurement Report frame including one
Location Civic report.
A Location Civic request shall indicate a location request for the requesting STA, the reporting STA, or a
third STA with the MAC address specified in the Target MAC address field, by setting the Location Civic
request Location Subject field to indicate a Local, a Remote, or a third-party request respectively. Local
Location Civic request is used by requesting STA to obtain its own location by asking “Where am I?”
Remote Location Civic request is used by requesting STA to obtain location of the reporting STA by asking
“Where are you?” Third-party Location request is used by requesting STA to obtain location of a STA with
the MAC address specified in the Target MAC address field.
If dot11RMCivicMeasurementActivated is false, a STA that receives the received Location Civic request
shall respond with a Location Civic report where the Incapable bit is set in the Measurement Report Mode
field.
If dot11RM3rdPartyMeasurementActivated is false, a STA shall reject any LCI request that includes an LCI
request with the Location Subject field equal to 2 by returning a Radio Measurement Report frame including
an Radio Measurement Report element with the Incapable bit set to 1.
It is optional for a STA to support a Location Civic request and a Location Civic report with the Location
Subject field equal to 2. If dot11RM3rdPartyMeasurementActivated is true and a STA supports Location
Civic request and Location Civic report, the following procedure shall be followed:
— When a non-AP STA requests the civic location of a STA with the MAC address specified in the
Target MAC address field, it shall also include its own MAC address in the Originator Requesting
STA MAC address field. When an AP receives a Location Civic request with the Location Subject
field value equal to 2, the AP shall generate a Location Civic request to the STA with the MAC
address specified in the Target MAC address field. If the AP does not have an association with the
STA with the MAC address specified in the Target MAC address field, the AP shall reject the
received Location Civic request by returning a Location Civic report where the Incapable bit is set in
the Measurement Report Mode field. The AP shall copy the Originator Requesting STA MAC
address and Target MAC address fields into the request from the received Location Civic request.
— When a STA receives a Location Civic request with the Location Subject field value equal to 2, the
STA may generate a Location Civic report if the MAC address in the Target MAC address field is
its own MAC address; it shall not generate a Location Civic report otherwise. When a Location
Civic report is generated, the reporting STA shall include its MAC address into the Target MAC
address field and the MAC address present in the Originator Requesting STA MAC address field of
the corresponding Location Civic request into the Originator Requesting STA MAC address field.
When an AP receives a Location Civic report with an Originator Requesting STA MAC address
field present, the AP shall generate a Location Civic report to the associated STA with the MAC
address specified in the Originator Requesting MAC address field. The AP shall copy the Originator
Requesting STA MAC address and Target MAC address fields into the Location Civic report being
transmitted to the originating requesting STA.
When a STA receives a Location Civic request with the subject field equal to 2, but does not support third-
party location, it shall respond with a Radio Measurement Report frame including a Radio Measurement
Report element with the Incapable bit set to 1.
If dot11RMCivicMeasurementActivated is true and a STA has its own location configured in civic format,
excluding an unknown civic location as defined in 9.4.2.22.13, the STA shall set dot11RMCivicConfigured
to true.
1727
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If dot11RMCivicMeasurementActivated is true and a STA has its own location available in one or more
location formats, as defined in Table 9-100, and includes Civic Location Type field value 0, indicating
“IETF RFC 4776,” it shall set the Civic Location field to 1 in the Extended Capabilities element.
NOTE—The Location Civic field’s size limit constrains the amount of information that can be carried.
If the Location Civic report contains the Location Reference and Location Shape subelements, the receiving
STA may use the information specified in those subelements in combination with the Civic Location field
value for additional granularity on the position reported in the Civic Location field.
If the Location Civic report contains the Map Image subelement, the receiving STA’s SME can retrieve the
floor plan specified by the Map URL field. The method to retrieve the floor plan specified by the Map URL
field is out of scope of this document.
11.11.9.10 Location Identifier report
The Location Identifier report provides the ability for a STA to receive one or more:
— Indirect URI references and forward a subset of those references to an external agent for the
purposes of that agent gathering the STA’s location value. The protocol used to query for a location
report based on the Public Identifier URI/FQDN provided in the Location Identifier report is
indicated by the URI/FQDN Descriptor field.
— FQDNs, one per location server, that can be used to discover the location server and establish
communications with it. The protocol used with the location server is indicated by the URI/FQDN
Descriptor field.
If dot11RMIdentifierMeasurementActivated is true and location information is not available, the STA that
receives a Location Identifier request shall respond with a Measurement Report frame including a
Measurement Report element with the Incapable bit set to 1. If dot11RMIdentifierMeasurementActivated is
true and location information is available, the STA shall respond with a Measurement Report frame
including one Measurement Report element containing a Location Identifier report that carries one or more
Public Identifier URI/FQDN subelements.
A Location Identifier request shall indicate a location request for the requesting STA, the reporting STA, or
a third-party STA with the MAC address specified in the Target MAC address field, by setting the Location
Identifier request Location Subject field to indicate a Local, a Remote, or a Third-party request respectively.
Local Location Identifier request is used by requesting STA to obtain its own location by asking “Where am
I?” Remote Location Civic request is used by requesting STA to obtain location of the reporting STA by
asking “Where are you?” Third-party Location request is used by requesting STA to obtain location of a
STA with the MAC address specified in the Target MAC address field.
If dot11RM3rdPartyMeasurementActivated is false, a STA that receives an LCI request that includes an LCI
request with the Location Subject field equal to 2 shall respond with a Radio Measurement Report frame
including an Radio Measurement Report element with the Incapable bit set to 1.
It is optional for a STA to support a Location Identifier request and a Location Identifier report with the
Location Subject field equal to 2. If dot11RM3rdPartyMeasurementActivated is true and a STA supports
Location Identifier request and Location Identifier report, the following procedure shall be followed:
— When a non-AP STA requests the location identifier of a STA with the MAC address specified in
the Target MAC address field, it shall also include its own MAC address in the Originator
Requesting STA MAC address field. When an AP receives a Location Identifier request with the
Location Subject field value equal to 2, the AP shall generate a Location Identifier request to the
STA with the MAC address specified in the Target MAC address field. If the AP does not have an
association with the STA with the MAC address specified in the Target MAC address field, the AP
shall reject the received Location Identifier request by returning a Location Identifier report where
1728
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the Incapable bit is set in the Measurement Report Mode field. The AP shall copy the Originator
Requesting STA MAC address and Target MAC address fields into the request from the received
Location Identifier request.
— When a STA receives a Location Identifier request with the Location Subject field value equal to 2,
the STA may generate a Location Identifier report if the MAC address in the Target MAC address
field is its own MAC address; it shall not generate a Location Identifier report otherwise. When a
Location Identifier report is generated, the reporting STA shall include its MAC address into the
Target MAC address field and the MAC address present in the Originator Requesting STA MAC
address field of the corresponding Location Identifier request into the Originator Requesting STA
MAC address field. When an AP receives a Location Identifier report with an Originator Requesting
STA MAC address field present, the AP shall generate a Location Identifier report to the associated
STA with the MAC address specified in the Originator Requesting MAC address field. The AP shall
copy the Originator Requesting STA MAC address and Target MAC address fields into the
Location Identifier report being transmitted to the originating requesting STA.
When a STA receives an Location Identifier request with the subject field equal to 2, but does not support
third-party location, it shall respond with a Radio Measurement Report frame including a Radio
Measurement Report element with the Incapable bit set to 1.
If dot11RMIdentifierMeasurementActivated is false, a STA shall reject the received Location Identifier
request by returning a Location Identifier report where the Incapable bit is set in the Measurement Report
Mode field.
If dot11RMIdentifierMeasurementActivated is true and a STA has its own location available in one or more
location formats, as defined in Table 9-100, and includes Civic Location Type field value 0, indicating
“IETF RFC 4776” or geospatial format that can be referenced by a location identifier, it shall set the
Identifier Location field to 1 in the Extended Capabilities element.
11.11.9.11 Fine Timing Measurement Range report
The Fine Timing Measurement Range report provides a means for a requesting STA to request a responding
STA that advertises FTM Range Report Capability Enabled equal to true in the RM Enabled Capabilities
element to measure and report the ranges between the responding STA and other nearby APs where the
ranges are determined using the FTM procedure (see 11.24.6).
If dot11RMFineTimingMsmtRangeRepActivated is true, dot11FineTimingMsmtInitActivated shall be true
also.
If dot11RMFineTimingMsmtRangeRepActivated is false, a STA shall reject any Fine Timing Measurement
Range request by responding with a Radio Measurement Report frame that includes a Measurement Report
element with the Incapable field set to 1.
If a responding STA with dot11RMFineTimingMsmtRangeRepActivated equal to true accepts a Fine
Timing Measurement Range request, then:
— If the request includes a maximum age subelement, and the STA has already determined FTM
ranges to C APs listed in the Neighbor Report subelements field in the Measurement Request field
within the indicated Maximum Age, then the STA may use these ranges instead of initiating new
FTM procedures with the C APs.Define Csub as the subset of APs selected by the STA from the C
eligible APs.
— Considering the remaining listed APs in the Neighbor Report subelements field in the Measurement
Request field, if Minimum AP Count exceeds Csub, the responding STA shall wait a random delay
up to the value of Randomization Interval field in the Measurement Request element (see 11.11.3)
then initiate the FTM procedure with at least Minimum AP Count – Csub remaining listed APs. The
1729
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
responding STA should initiate the FTM procedure with the remaining listed APs until either the
responding STA has successfully measured the range between the responding STA with at least
Minimum AP Count APs or has attempted the FTM procedure with all remaining listed APs. For
each FTM procedure that is attempted with a remaining listed AP without success, the responding
STA shall record an error entry.
For procedures related to listed APs that operate on non-operating channels, see 11.11.2.
The responding STA shall transform the measurements obtained from each FTM procedure with an
AP into a range and a maximum error between itself and the AP, while accounting for any clock
offsets between the responding STA and the AP.
At the completion of all of the FTM procedures and transformations, the responding STA shall send the all
computed range information between itself and other APs, and all error entries, to the requesting STA using
a Measurement Report element with Measurement Type field set to Fine Timing Measurement Range in a
Measurement Report frame.
A requesting STA may request a single set of range measurements by setting the Number of Repetitions
field to 0 in the Measurement Request frame, or request a regular sequence of range measurements by
— setting the Number of Repetitions field greater than 0 in the Measurement Request frame, and
— including a Measurement Request element with Measurement Type field equal to Fine Timing
Measurement Range and a Measurement Request element with Measurement Type field equal to
Measurement Pause (see 11.11.9.7).
11.11.10 Usage of the neighbor report
11.11.10.1 General
A neighbor report is sent by an AP and it contains information on neighboring APs that are members of
ESSs requested in the neighbor report request. A neighbor report might not be exhaustive either by choice,
or due to the fact that there might be neighbor APs not known to the AP. The neighbor report contents are
derived from the NeighborListSet parameter of the MLME-NEIGHBORREPRESP.request primitive. The
mechanism by which the contents of this table are determined is outside the scope of this standard, but it
may include information from measurement reports received from the STAs within the BSS, information
obtained via a management interface, or the DS.
NOTE—The purpose of the neighbor report is to enable the STA to optimize aspects of neighbor service set transition
and ESS operation. A Neighbor Report element contains information on APs that the STA might use as candidates for a
service set transition. Since the information in the neighbor report might be stale, it is advisory; information obtained by
the report recipient through a scan or other sources might also be considered, possibly overriding information in the
neighbor report. For example, where information contained within a neighbor report is contradicted by information in a
Measurement Pilot, Beacon, or Probe Response frame, that response information needs to take precedence.
An AP in which dot11RMNeighborReportActivated is false shall not transmit a Fine Timing Measurement Range
request. An AP in which dot11RMNeighborReportActivated is false should not transmit a Measurement Request with
the Measurement Type field equal to LCI and the Location Subject field of the LCI request set to Location Subject
Remote.
11.11.10.2 Requesting a neighbor report
A STA requesting a neighbor report from an AP shall send a Neighbor Report Request frame to its
associated AP.
A STA can request LCI information of an AP and its neighboring APs, if the AP advertises the FTM
responder capability (Extended Capabilities element with the Fine Timing Measurement Responder field set
to 1), the geospatial location capability (Extended Capabilities element with the Geospatial Location field
set to 1), and the neighbor report capability (RM Enabled Capabilities element with the Neighbor Report
1730
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Capability Enabled field set to 1). A STA can request Civic Location information of an AP and its
neighboring APs, if the AP advertises the FTM responder capability (Extended Capabilities element with
the Fine Timing Measurement Responder field set to 1), the location civic capability (Extended Capabilities
element with the Civic Location field set to 1), and the neighbor report capability (RM Enabled Capabilities
element with the Neighbor Report Capability Enabled field set to 1).
To request the LCI of neighboring APs, the STA shall transmit a Neighbor Report Request frame that
includes a Measurement Request element with the value of its Measurement Type field equal to LCI. To
request the location civic of neighboring APs, the STA shall transmit a Neighbor Report Request frame that
includes a Measurement Request element with the value of its Measurement Type field equal to Location
Civic.
11.11.10.3 Responding to a neighbor report request
If dot11RMNeighborReportActivated is true, an AP receiving a neighbor report request shall respond with a
Neighbor Report Response frame containing zero or more Neighbor Report elements. If an SSID element is
specified in the corresponding Neighbor Report Request frame, the Neighbor Report element(s) shall
contain information only concerning neighbor APs that are members of the current ESS identified by the
SSID element contained within the neighbor report request. If the SSID element is omitted, the Neighbor
Report element(s) shall contain information concerning neighbor APs that belong to the same ESS as the
requesting STA. If the wildcard SSID element is specified in the corresponding Neighbor Request frame, the
Neighbor Report element(s) shall contain information concerning all neighbor APs. If there are no neighbor
APs available, the AP shall send a Neighbor Report Response frame with no Neighbor Report elements.
If dot11RMNeighborReportActivated is true and dot11FineTimingMsmtRespActivated is true, an AP
receiving a neighbor report request shall respond with a Neighbor Report Response frame containing one or
more Neighbor Report elements.
If dot11RMNeighborReportActivated is false in an AP receiving a neighbor report request, it shall ignore
the request.
A serving AP shall include a TSF subelement in the Neighbor Report element if it is able to guarantee an
accumulated error of 1.5 TU or better on the TSF Offset subfield. Otherwise, the AP shall not include a TSF
subelement in the Neighbor Report element.
When the SSID element is omitted, the SSID element is specified by the wildcard SSID, or the SSID
element is present and indicates the AP’s own SSID and either of the following is true:
— An AP that has both dot11FineTimingMsmtRespActivated and dot11RMLCIConfigured equal to
true receives a Measurement Request element with Measurement Type field equal to LCI.
— An AP that has both dot11FineTimingMsmtRespActivated and dot11RMCivicConfigured equal to
true receives a Measurement Request element with Measurement Type field equal to Location
Civic.
within a Neighbor Report Request frame then the AP shall include a Neighbor Report element for the AP’s
own BSSID in the Neighbor Report Response frame (i.e., in this case the Neighbor Report Response frame
contains one or more Neighbor Report elements). If dot11RMLCIConfigured is equal to true, the Neighbor
Report element shall include a Measurement Report subelement with the Measurement Type field equal to
LCI. If dot11RMCivicConfigured is equal to true, the Neighbor Report element shall include a
Measurement Report sub element with the Measurement Type field equal to Location Civic.
When both of the following are true:
— the SSID element specified in the Neighbor Report Request does not include the AP’s own SSID
and an AP that has at least one of dot11FineTimingMsmtRespActivated and
1731
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMLCIConfigured equal to false receives a Measurement Request element with the
Measurement Type field equal to LCI within a Neighbor Report Request frame
— an AP that has at least one of dot11LciCivicInNeighborReport and dot11RMLCIConfigured equal
to false receives a Neighbor Report Request frame
then the AP shall not include a Neighbor Report element containing a Measurement Report subelement with
the Measurement Type field set to LCI describing the reporting AP in the Neighbor Report Response frame.
In this case the Neighbor Report Response frame contains zero or more Neighbor Report elements.
When both of the following are true:
— the SSID element specified in the Neighbor Report request does not include the AP’s own SSID and
an AP that has at least one of dot11FineTimingMsmtRespActivated and dot11RMCivicConfigured
equal to false receives a Measurement Request element with the Measurement Type field equal to
Location Civic within a Neighbor Report Request frame
— an AP that has at least one of dot11LciCivicInNeighborReport and dot11RMCivicConfigured equal
to false receives a Neighbor Report Request frame
then the AP shall not include a Neighbor Report element containing a Measurement Report subelement with
Measurement Type set to Location Civic describing the reporting AP in the Neighbor Report Response
frame (i.e., in this case the Neighbor Report Response frame contains zero or more Neighbor Report
elements). In this case the Neighbor Report Response frame contains zero or more Neighbor Report
elements.
NOTE—The Neighbor Report Response frame includes a list Neighbor Report elements one for each neighbor. The
criteria for the selection of an AP as a neighbor AP is beyond the scope of this specification.
The Neighbor Report Response frame shall also include a Neighbor Report element for each neighbor AP.
When either of the following is true in a neighbor AP of the AP (reporting AP) that receives a Measurement
Request element with the Measurement Type field equal to LCI within a Neighbor Report Request frame:
— the neighbor AP has both FTM responder capability (Extended Capabilities element with the Fine
Timing Measurement Responder field set to 1) and LCI measurement capability (RM Enabled
Capabilities element with the LCI Measurement Capability Enabled field set to 1)
— the reporting AP has dot11LciCivicInNeighborReport equal to true and the neighbor AP has LCI
measurement capability (RM Enabled Capabilities element with the LCI Measurement Capability
Enabled field set to 1)
then the reporting AP shall include a Neighbor Report element in the Neighbor Report Response frame. In
addition if the neighbor AP has Geospatial Location capability (Extended Capabilities element with the
Geospatial Location field set to 1), the Neighbor Report element shall include a Measurement Report
subelement with Measurement Type equal to LCI. If the maximum horizontal or vertical location error of
the neighbor AP relative to a reference AP is known to the AP and this relative error is smaller than the
absolute error indicated in the LCI subelement, then the AP may include a Relative Location Error subfield
in the Measurement Report field.
When either of the following is true in a neighbor AP of the AP (reporting AP) that receives a Measurement
Request element with the Measurement Type equal to Location Civic within a Neighbor Report Request
frame:
— The neighbor AP has both FTM responder capability (Extended Capabilities element with the Fine
Timing Measurement Responder field set to 1) and civic location measurement capability (RM
Enabled Capabilities element with Civic Location Measurement Capability Enabled set to 1)
— The reporting AP has dot11LciCivicInNeighborReport equal to true and the neighbor AP has civic
location measurement capability (RM Enabled Capabilities element with Civic Location
Measurement Capability Enabled set to 1)
1732
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
then the reporting AP shall include a Neighbor Report element in the Neighbor Report Response frame. In
addition if the neighbor AP has Civic Location (Extended Capabilities element with the Civic Location field
set to 1), the Neighbor Report element shall include a Measurement Report subelement with the
Measurement Type field equal to Location Civic.
Each Measurement Report subelement returned shall have the same Measurement Token value as in the
Measurement Token field of the corresponding Measurement Request element, or if there is no
corresponding Measurement Request then the Measurement Token value shall be set to 0.
If an AP determines that the LCI and/or civic location of a neighboring AP changes, the AP may send an
unsolicited Neighbor Report Response frame containing complete neighbor information including the
updated neighboring AP location information. The Dialog Token field is set to 0 as defined in 9.6.7.7.
A STA that receives an LCI report that contains a Usage Rules/Policy subelement shall process the LCI
information in compliance with the retransmission and retention permissions in the Usage-rules subelement.
The Wide Bandwidth Channel subelement shall not be included in the Neighbor Report element when either
the HT Operation subelement or the VHT Operation subelement is included in the Neighbor Report element.
A VHT AP in which dot11FineTimingMsmtRespActivated is true that transmits a Neighbor Report element
containing an HT Operation subelement shall include a VHT Operation subelement in the Neighbor Report
element.
A non-DMG AP in which dot11FineTimingMsmtRespActivated is true that transmits a Neighbor Report
element containing neither an HT Operation subelement nor a VHT Operation subelement shall include a
Wide Bandwidth Channel subelement in the Neighbor Report element.
11.11.11 Link Measurement
A STA may use a Link Measurement Request frame to request another STA to respond with a Link
Measurement Report frame containing a TPC report element. If dot11RMLinkMeasurementActivated is
true, a STA receiving a Link Measurement Request frame shall respond with a Link Measurement Report
frame containing a TPC Report element indicating the power used to transmit the Link Measurement report.
The Link Measurement report also contains antenna ID and signal quality (RCPI and RSNI).
If dot11RMLinkMeasurementActivated is false in an AP or PCP receiving a Link Measurement Request, it
shall ignore the request.
11.11.12 Measurement of the RPI histogram
To compute RPI densities for an RPI Histogram report (see 9.4.2.22.4), the STA shall measure the received
power level on the specified channel, as detected at the antenna connector, as a function of time over the
measurement duration. The maximum tolerance of the received power measurements shall be ± 5 dB.
Furthermore, the received signal power measurement should be a monotonic function of the actual power at
the antenna. The time resolution of the received power measurements is in microseconds. The received
power measurements are converted to a sequence of RPI values by quantizing the measurements according
to Table 9-108. The RPI densities are then computed for each of the eight possible RPI values using
255 D RPI
RPI Density = ---------------------------
1024 D M
1733
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
DRPI is the duration receiving at the specified RPI value ( s)
DM is the measurement duration (TU).
The sum of the RPI densities is approximately 255, but could be up to 262 because of rounding effects.
11.11.13 Operation of the Max Transmit Power field
The maximum tolerance for the value reported in Max Transmit Power field shall be 5 dB. The value of the
Max Transmit Power field shall be less than or equal to the Max Regulatory Power value for the current
channel.
11.11.14 Multiple BSSID set
A multiple BSSID set is characterized as follows:
— All members of the set use a common operating class, channel, Channel Access Functions, and
antenna connector.
— The set has a maximum range of 2n for at least one n, where 1 n 46.
— Members of the set have the same 48-n MSBs in their BSSIDs.
— All BSSIDs within the multiple BSSID set are assigned in a way that they are not available as MAC
addresses for STAs using a different operating class, channel or antenna connector.
NOTE—For example, if the APs within BSSs with BSSIDs 16, 17, and 27 share the operating class, channel and
antenna connector, and the range of MAC addresses from 16–31 inclusive are not assigned to other STAs using a
different antenna connector, then the BSSIDs 16, 17, and 27 are members of a multiple BSSID set. The set is described
by n = 4 (2n = 16) with BSSIDs in the range 0x00000000001X. The set cannot be described by n = 8 for instance since at
least one of the BSSIDs in the range 0x0000000000XX might be used as a BSSID by an AP that does not share the same
operating class, channel, and antenna connector.
When the multiple BSSID set contains two or more members, the transmission of Measurement Pilots is
constrained as described in 11.11.15.
A Multiple BSSID element, with or without optional subelements, indicates that all APs and PCPs within
the indicated range of BSSIDs transmit using a common class, channel, and antenna connector.
A single Beacon frame may contain elements for the multiple BSSID set members; see 11.1.3.8.
11.11.15 Measurement Pilot frame generation and usage
11.11.15.1 General
The Measurement Pilot frame is a compact Action frame transmitted pseudo-periodically by an AP at a
small interval relative to a Beacon Interval. The Measurement Pilot frame provides reduced information
relative to a Beacon frame to allow for the required small interval. The purpose of the Measurement Pilot
frame is to assist a STA with the following functions:
— Rapid discovery of the existence of a BSS via passive scanning
— Rapid collection of neighbor AP signal strength measurements via passive scanning
— Enable transmission of a Probe Request frame
A STA’s dot11RMMeasurementPilotActivated determines the level of support for measurement pilot at the
STA. Table 11-10 describes permitted values for dot11RMMeasurementPilotActivated and what they
signify.
1734
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-10—Measurement pilot activated definition
dot11RM-
Device function MeasurementPilot Notes
Activated
AP and non-AP 0 If the STA is contained within an AP, it does not generate MPs and if
STA the device is a non-AP STA, it ignores the MPs it receives
AP and non-AP 1 If the STA is contained within an AP, it can transmit MPs, and if the
STA device is a non-AP STA, it can receive the MPs and can use the
information contained in MPs.
Non-AP STA 2 The non-AP STA is making use of the MPs it receives or would
receive if they were being transmitted.
Non-AP STA 3–7 Reserved
AP The AP is transmitting MPs and using the information contained in
them, and the AP is actively transmitting MPs with MP interval set
to a value within the range as shown below.
MP Interval with respect to Beacon Interval:
2 > 3% and < 5% of Beacon
Interval
3 5% and < 10%
4 10% and < 15%
5 15% and < 20%
6 20% and < 25%
7 25% and < 50%
11.11.15.2 Measurement Pilot frame generation by an AP
The AP shall determine if it is a member of a multiple BSSID set with two or more members. If so, at most
one AP of the multiple BSSID set shall have dot11RMMeasurementPilotActivated set to a value between 2
and 7. How this occurs is out of scope of this standard.
If dot11RMMeasurementPilotActivated is between 2 and 7, the following statements apply:
— If the AP is a member of a multiple BSSID set with two or more members, then the BSSIDs of all
members of the multiple BSSID set shall be indicated in the Beacon and Probe Response frames by
the Multiple BSSID subelement.
— The AP shall maintain a Measurement Pilot frame generation function, which transmits
Measurement Pilot frames at a basic rate according to dot11RMMeasurementPilotPeriod.
— The AP defines a series of TMPTTs exactly dot11RMMeasurementPilotPeriod apart. A TMPTT
arrives when the AP’s local TSF timer (in µs) modulo the Measurement Pilot Interval equals 0.
— At each TMPTT, the AP shall schedule a Measurement Pilot frame as the next frame for
transmission ahead of other queued frames using the AC_VO EDCA parameters unless the TMPTT
satisfies:
T MPP T MPP
TBTT – ------------ TMPTT TBTT + ------------
2 2
where TMPP is dot11RMMeasurementPilotPeriod, for any TBTT of members of the multiple
BSSID set, in which case the AP shall not generate the Measurement Pilot. This is illustrated in
1735
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 11-28. How the AP determines the TBTTs of members of the multiple BSSID set is out of
scope of this standard.
TBTT of Multiple BSSID Set member #1
TBTT of Multiple BSSID Set member #2
TBTT of Multiple BSSID Set member #3
TMPTT of Multiple BSSID Set member
Allowed Measurement Pilot transmissions
Figure 11-28—Example of Measurement Pilot frame scheduling
In case the medium is determined by the carrier-sense mechanism (see 10.3.2.1) to be unavailable at
the TMPTT, the AP shall delay the actual transmission of a Measurement Pilot frame according to
the basic medium access rules specified in Clause 10 for a maximum period of one dot11RMMea-
surementPilotPeriod and drop the delayed Measurement Pilot frame at the next TMPTT. In this way,
a continuously busy medium causes multiple successive Measurement Pilots to be delayed, then
dropped. An AP shall transmit Measurement Pilots to the broadcast address. An AP shall not
retransmit or buffer Measurement Pilots as part of the PSP mechanisms.
— If the AP is a member of a multiple BSSID set with two or more members, then the BSSIDs of all
members of the multiple BSSID set shall be indicated in the Measurement Pilot frame using the
Multiple BSSID subelement.
NOTE 1—APs are advised to enable Measurement Pilots judiciously due to the possibility of excessive medium time
being consumed by Measurement Pilots from multiple overlapping APs. For instance
dot11RMMeasurementPilotTransmissionInformationActivated might be set to false:
a) When enabling Measurement Pilots would cause:
1) More than 10% of the medium time at the AP to be consumed by beacons and Measurement Pilots
transmitted by any source, or
2) More than 5% of the medium time at the AP to be consumed by Measurement Pilots transmitted by any
source.
b) When STAs are not expected to be using Measurement Pilots. How this is determined is out of the scope of this
standard, but may depend upon many STAs setting the Measurement Pilot Capability field in the RM Enabled
Capabilities element to 0 or 1 upon association at any member of the multiple BSSID set recently or at similar
times in the past.
c) When all members of the multiple BSSID set are within ESSs that contain one BSS only.
d) When the AP’s operating regulatory domain is not subject to DFS regulations.
e) When the AP’s operating regulatory domain is subject to DFS regulations but compliance with the regulations
is impaired by Measurement Pilots.
f) When the number of channels valid for the AP’s operating regulatory domain or frequency band is small.
g) When no members of the multiple BSSID set are located at ingress or egress points of an ESS, so are less useful
for roaming between an IEEE 802.11 ESS and other networks.
NOTE 2—For efficient use of the medium, it is recommended that Measurement Pilots not be sent using a PHY
specified in Clause 15 or Clause 16.
An AP that is not extended spectrum management capable shall not include a Wide Bandwidth Channel
Switch subelement in a Measurement Pilot frame. If the Wide Bandwidth Channel Switch subelement is
included in a Measurement Pilot frame, then the Operating Class shall include a 40 MHz channel spacing.
1736
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.11.15.3 Measurement pilot usage by a STA
Whenever testing a requested BSSID for equality against the BSSID of a Measurement Pilot, the following
statements apply:
— If the Measurement Pilot frame does not contain the Multiple BSSID element, then equality shall be
true if the requested BSSID equals the BSSID of the Measurement Pilot frame, and otherwise false.
— If the Measurement Pilot frame contains the Multiple BSSID element, and the requested BSSID is a
non-wildcard BSSID, then equality shall be true if the requested BSSID equals any BSSID indicated
by the Multiple BSSID element present in the Measurement Pilot, and otherwise false.
— If the Measurement Pilot frame contains the Multiple BSSID element, and the requested BSSID is
the wildcard BSSID, then equality shall be true.
NOTE—STAs are advised that due to considerations such as those noted in the prior subclause, APs might not transmit
Measurement Pilots at all times or in all bands.
11.11.16 Access Delay Measurement
Access delay is measured by the AP’s or PCP’s MAC layer being the average medium access delay for
transmitted frames measured from the time the MPDU is ready for transmission (i.e., begins CSMA/CA
access or SP access, as appropriate) until the actual frame transmission start time. Access delay
measurement results are included in the BSS Average Delay element and in the BSS AC Access Delay
element.
For the BSS Average Delay measurement, the AP or PCP shall measure and average the medium access
delay for all transmit frames using the DCF or EDCAF over a continuous 30 s measurement window. For
the infrastructure BSS AC Access Delay measurement, the QoS AP or PCP shall measure and average the
medium access delay for all transmit frames of the indicated AC (see Figure 9-308) using EDCA
mechanism over a continuous 30 s measurement window. The accuracy for the average medium access
delay shall be ± 100 µs or better when averaged over at least 200 frames. Accuracy is not defined for
measurements averaged over less than 200 frames.
11.11.17 BSS Available Admission Capacity
BSS Available Admission Capacity provides a means for an AP to advertise admission capacity available
for explicit admission control in any UP or AC. This information may assist STAs in making service set
transition decisions.
The transmitted BSS Available Admission Capacity value represents a proportion of time on the wireless
medium scaled linearly in units of 32 µs/s from 0 (0% available time) to 31 250 (100% available time). If an
AP transmits a BSS Load element, the values for any transmitted BSS Available Admission Capacity values
shall be less than or equal to the Available Admission Capacity field value of the BSS Load value. If an AP
transmits a BSS Available Admission Capacity element, the transmitted values should be current or recently
calculated. The AP recalculates Available Admission Capacity values according to local policy. An
Available Admission Capacity value of 0 transmitted in the BSS Available Admission Capacity element
indicates that no admission capacity is available at the calculation time and that no explicit admissions can
be granted by the AP for that UP or AC unless additional capacity becomes available. An AP that receives a
TSPEC admission request for total medium time (in both directions, if applicable) that is less than or equal
to the current available admission capacity for the requested UP or AC local policy may apply additional
local policy before admitting the requested TSPEC.
NOTE 1—Available Admission Capacity values are dynamic in a BSS and the transmitted values cannot always reflect
the actual values currently used by the AP for explicit admission control. Thus an AP should recalculate the Available
Admission Capacity values regularly or after changes in the environment or the admitted capacity.
NOTE 2—STAs are advised that requesting admission for any TSPEC at an UP or AC that requires more medium time
than is reported as available for the requested UP or AC is possible yet unlikely to be successful.
1737
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.11.18 AP Channel Report
The AP Channel Report element contains a list of channels in an operating class where a STA is likely to
receive the Beacon or Probe Response frames sent by an AP, excluding the AP transmitting the AP Channel
report. An AP Channel Report element only includes channels that are valid for the regulatory domain in
which the AP transmitting the element is operating and consistent with the Country element in the frame in
which it appears. One AP Channel Report element is included in the Beacon frame for each regulatory
domain, which includes channels on which a STA is likely to receive the Beacon or Probe Response frames
sent by an AP.
The contents of the AP Channel Report elements may be compiled from the list of unique operating/channel
pairs found in the neighbor report. The contents of the AP channel report may be configured or obtained by
other means beyond the scope of this standard.
11.11.19 Multicast diagnostic reporting
Multicast diagnostic reporting enables an AP to collect statistics on group addressed traffic at associated
STAs. The method an AP uses to determine the multicast groups to which an associated STA is a member of
is outside the scope of the standard and is typically performed by higher layer protocols. The Multicast
Diagnostic request and Multicast Diagnostic report are defined in 9.4.2.21.13 and 9.4.2.22.12, respectively.
A STA whose dot11MulticastDiagnosticsActivated is true shall support multicast diagnostics reporting and
shall set to 1 the Multicast Diagnostics field of the Extended Capabilities elements that it transmits. When
the Multicast Diagnostics field in the Extended Capabilities field is 1, the Incapable bit in the Measurement
Report Mode field of a Multicast Diagnostic report shall not be set to 1.
Multicast diagnostic reporting may use the triggered autonomous reporting capability described in 11.11.8.
The Measurement Start Time field of a triggered diagnostic report shall contain the value of the STA TSF
Timer at the time the trigger condition started to occur to an accuracy of ±1 TU.
An AP may send a Multicast Diagnostic request consisting of one or more Multicast Diagnostic requests in
a Radio Measurement Request frame to a non-AP STA that has indicated support of the multicast diagnostic
capability or to a multicast group address if all associated non-AP STAs support the multicast diagnostic
capability. If the STA accepts the request it shall count the number of received MSDUs with the specified
group address and the STA shall record the maximum observed PHY data rate of the frames that contained
these MSDUs during the requested Measurement Duration. These two values shall be returned in a
Multicast Diagnostic report in a Radio Measurement Report frame, as defined in 9.4.2.22.12. A non-AP
STA shall not transmit a Radio Measurement Request frame containing a Multicast Diagnostic request. A
STA shall not respond to a Radio Measurement Request frame containing a Multicast Diagnostic request
received from a STA other than the AP with which it is associated.
An AP may request that triggered multicast diagnostic reporting be enabled at associated non-AP STAs that
have indicated support of the multicast diagnostic capability. To enable multicast diagnostic reporting, the
AP shall send a Measurement Request element containing the Request Type field set to Multicast
Diagnostics and with the Enable and Report bits set to 1 within a Radio Measurement Request frame. See
11.11.8. For triggered multicast diagnostic reporting, the Multicast MAC Address and trigger conditions for
diagnostic reporting shall be specified in the request.
Multicast diagnostic reporting may be requested for broadcast traffic by setting the Multicast MAC Address
field to the broadcast address.
A non-AP STA accepting a request for triggered multicast diagnostic reporting shall send a Multicast
Diagnostics report to the requesting STA if the specified trigger condition occurs. The measuring non-AP
1738
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA shall not send further triggered Multicast Diagnostics reports until the period specified in the
Reactivation Delay field in the Multicast Diagnostic Request has expired, or the non-AP STA receives a
revised trigger condition from a Multicast Diagnostic Request. To prevent generation of too many triggered
reports, the minimum value of the Reactivation Delay field shall be set to a value greater or equal to A
STA’s MinTriggerTimeout.
Once accepted, Multicast Diagnostic reporting continues to be active for the specified Multicast MAC
address until one of the following occurs:
— The STA receives a Measurement Request element containing a Multicast Diagnostic Request Type
and with the Enable bit equal to 1 and the Report bits equal to 0 within a Radio Measurement
Request frame.
— Receipt of a Measurement Request element containing a Multicast Diagnostic Request Type, with
the Enable and Report bits equal to 1, but with no trigger conditions.
— The STA leaves the Multicast Group or disassociates.
— The STA sends a Measurement Report element with the Measurement Result bit set to 1.
The STA shall maintain an inactivity timer for every multicast diagnostic request accepted by the STA in
which the Inactivity Timeout Request field is 1. When a timeout of the inactivity timer is detected, the STA
shall send a multicast diagnostic report with the inactivity Timeout Trigger field in the Multicast Reporting
Reason field set to 1. The inactivity timer at a recipient is reset when MSDUs corresponding to the
monitored group address are received.
A STA that declines a request for triggered multicast diagnostic reporting sends a Measurement Report
element (as described in 9.4.2.22) in a Radio Measurement Report frame (as described in 9.6.2.3) with the
Measurement Report Mode field set appropriately to indicate the reason for a failed or rejected request.
11.11.20 CCA request and report
The response to a CCA request is a CCA report. A STA may support the generation of a CCA report. A STA
may generate a CCA report in response to a CCA request.
11.11.21 RPI Histogram request and report
The response to an RPI Histogram request is an RPI histogram report. A STA may support the generation of
an RPI histogram. A STA may generate an RPI histogram report in response to an RPI Histogram request.
11.12 DSE procedures
11.12.1 General
Regulations that apply to the U.S. 3650 MHz band require enabling STAs to implement a mechanism to
enable mobile and portable STA operation. Similar regulations exist in other regulatory domains. This
standard describes such a mechanism, referred to as dependent STA enablement (DSE).
Subclause 11.12 describes DSE procedures that can be used to satisfy the U.S. 3650 MHz band and similar
regulatory requirements. Regulations that apply to the U.S. 3650 MHz band require fixed STAs and
enabling STAs to have their operating locations registered. Licensees with STAs suffering or causing
harmful interference are expected to cooperate and resolve problems by mutually satisfactory arrangements.
The DSE procedures provide the location of the enabling STA and unique identifiers to assist licensees in
the resolution of interference issues. The DSE procedures might also satisfy needs in other frequency bands
and be useful for other purposes.
1739
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA shall use the DSE procedures defined in this subclause if dot11LCIDSERequired is true.
dot11DSERequired and dot11ExtendedChannelSwitchActivated shall be true when regulatory authorities
require DSE, with the following exceptions: dot11DSERequired shall be set to false to configure STAs to
operate as registered STAs, and dot11ExtendedChannelSwitchActivated may be set to false when operating
as a fixed STA. A summary of STA attributes and these MIB attributes are shown in Table 11-11.
Table 11-11—DSE STA attributes
dot11Extended
Registered dot11LCIDSERequired and dot11DSERe
Type of STA ChannelSwitch
STA dot11LCIDSEImplemented quired
Activated
Fixed STA Yes true true or false false
Enabling STA Yes true true false
Dependent STA No true true true
A fixed STA is a registered STA that broadcasts its registered location and is restricted from enabling other
STAs (see 11.12.3). An enabling STA is a registered STA that broadcasts its registered location, and
regulatory authorities permit it to enable operation of unregistered STAs (see 11.12.4). A dependent STA is
an unregistered STA that operates under the control of an enabling STA (see 11.12.5). When management
frame protection is negotiated, stations shall use Protected Dual of Public Action frames instead of
individually addressed Public Action frames for DSE procedures.
The DSE procedures provide for the following:
— Registered STA operation
— Creation of a DSE service area for dependent STA operation
— Dependent STA operation with DSE
11.12.2 Enablement and deenablement
11.12.2.1 General
This subclause describes the procedures used for IEEE 802.11 enablement and deenablement. A STA keeps
a state variable for each STA with which enablement communication is needed:
— Enablement state with a value of unenabled or
— Enablement state with a value of enabled
NOTE—Refer to 11.12.5 for description of dependent STA operation in either enablement state.
Enablement utilizes a two-frame transaction sequence. The first frame asserts identity and requests
enablement. The second frame returns the enablement result. In the description in 11.12.2.2 and 11.12.2.3,
the STA initiating the enablement is referred to as enablement requester, and the STA to which the initial
frame in the exchange is addressed is referred to as enablement responder. The specific items in each of the
frames described in the following subclauses are defined in 9.6.8.4 and 9.6.8.5. An enabling STA may
decline to enable a requesting STA. If the result is “successful,” the requesting STA shall be enabled.
Deenablement utilizes a one-frame transaction sequence. In the description in 11.12.2.4 and 11.12.2.5, the
STA initiating the deenablement is referred to as deenablement requester, and the STA to which the frame is
addressed is referred to as deenablement responder.
1740
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.12.2.2 Enablement requester STA
Upon receipt of an MLME-ENABLEMENT.request primitive, the enablement requester STA shall perform
the following procedure:
a) Construct and transmit a DSE Enablement frame requesting enablement.
1) Specific information items in the enablement frame are as follows.
i) STA identity assertion (in RequesterSTAAddress)
ii) Enabling STA identity assertion (in ResponderSTAAddress)
iii) Reason result code = 2
iv) Enablement identifier = 0
2) Specific items in the enablement frame sent by the enablement responder STA are described in
11.12.2.3.
b) On receipt of a matching DSE Enablement frame (i.e., the Requester STA Address and Responder
STA Address match the pending request) that acknowledges the DSE Enablement frame, issue an
MLME-ENABLEMENT.confirm primitive to inform the SME of the result of the enablement.
1) The primitive may contain information from an DSE Enablement frame received from the
enabling STA (see 11.12.2.3), or it may be issued for another reason (see 9.6.8.4).
2) The reason result code in the enablement confirmation frame indicates when the enablement is
successful.
3) If the enablement was successful, the enablement state variable for the enablement responder
STA shall be set to Enabled.
c) If no matching DSE Enablement frame is received for the DSE Enablement frame within a period of
EnablementTimeLimit TUs measured from the receipt of the MLME-ENABLEMENT.request
primitive, issue an MLME-ENABLEMENT.confirm primitive with ResultCode set to TIMEOUT.
11.12.2.3 Enablement responder STA
Upon receipt of a Public Action DSE Enablement frame with a reason result code of 2, the enablement
responder STA may enable the enablement requester STA using the following procedure:
a) Create and transmit a response frame with the enablement status as defined in 9.6.8.4 set in the
Reason Result Code field and with a dependent enablement identifier chosen to be unique among all
dependent enablement identifiers that have been assigned if enablement was successful. The
enablement responder shall transmit the ResultCode parameter from the .confirm primitive mapped
as specified in Table 9-310 of 9.6.8.4 to indicate the result of the enablement request.
1) Specific information items in the enablement frame response are as follows:
i) STA identity assertion (in RequesterSTAAddress)
ii) Enabling STA identity assertion (in ResponderSTAAddress)
iii) The result of the requested enablement as defined in 9.6.8.4
iv) Enablement identifier
b) Issue an MLME-ENABLEMENT.indication primitive to inform the SME of the enablement.
1) If the enablement is successful, the enablement state variable for the enablement requester STA
shall be set to Enabled.
11.12.2.4 Deenablement requester STA
Upon receipt of an MLME-DEENABLEMENT.request primitive, the deenablement requester STA shall
create and transmit a DSE Deenablement frame to the deenablement responder STA. Specific information
items in the deenablement frame are as follows:
a) Enabling STA identity assertion (in RequesterSTAAddress)
1741
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) STA identity assertion (in ResponderSTAAddress)
c) Reason result code = 2
11.12.2.5 Deenablement responder STA
Upon receipt of a DSE Deenablement frame, the deenablement responder STA shall deenable with the
deenablement requester STA by issuing an MLME-DEENABLEMENT.indication primitive to inform the
SME of the deenablement. The enablement state variable for the deenablement requester STA shall be set to
Unenabled.
11.12.3 Registered STA operation
A registered STA shall have dot11DSERequired equal to false. They shall transmit the DSE Registered
Location element in every Beacon frame and shall set the Dependent STA bit in the DSE Registered
Location element to 0. If the registered STA is located within a national policy area, such as a Fixed Satellite
Service exclusion zone, or within an international agreement area near a national border, the RegLoc
Agreement bit in the DSE Registered Location element shall be set to 1, signifying to other STAs that
additional restrictions on STAs with directional antennas may apply; otherwise, it shall be set to 0.
The Latitude, Longitude, and Altitude fields of the DSE Registered Location element shall be reported at
their best known resolutions, which might exceed the resolutions required by regulatory authorities. The
Altitude Type field value shall be 3 (i.e., height above ground is in meters or, in other words, the altitude is
in meters above adjacent terrain), unless another altitude type is required for operation in the regulatory
domain. The Datum field value shall be 1 (World Geodetic System 1984), unless another datum is required
for operation in the regulatory domain.
An enabling STA is a registered STA that broadcasts its registered location, and regulatory authorities
permit it to enable operation of unregistered STAs (see 11.12.4). A dependent STA is an unregistered STA
that operates under the control of an enabling STA (see 11.12.5).
A fixed STA is a registered STA that broadcasts its registered location and is restricted from enabling other
STAs. A fixed STA shall have dot11LCIDSERequired set to true, and
dot11ExtendedChannelSwitchActivated may be true or false. A fixed STA shall set dot11RegLocDSE to
false and the RegLoc DSE bit in the DSE Registered Location element to 0, signifying that it is not creating
a DSE service area. A fixed STA may operate in an infrastructure BSS or IBSS. A registered STA that is not
an enabling STA may operate as an AP and relay Public Action frames (specifically, DSE Enablement, DSE
Deenablement, DSE Measurement Request, DSE Measurement Report, DSE Power Constraint) from a
dependent STA to its enabling STA. The specification of the algorithm by which Public Action frames are
relayed is beyond the scope of this standard. Note that the enabling signal is not a Public Action frame and is
not relayed (see 11.12.4).
11.12.4 Enabling STA operation with DSE
A registered STA may create and manage a DSE service area for dependent STA operation where regulatory
requirements permit. A registered STA operating in this manner is referred to as an enabling STA. An
enabling STA sets dot11RegLocDSE to true and signifies the creation of a DSE service area by setting the
RegLoc DSE bit in the DSE Registered Location element to 1. Dependent STA transmission of any frames
is conditional on receiving directly over the air and decoding a DSE Registered Location element with
RegLoc DSE bit equal to 1, sent from an enabling STA. Before attempting enablement with any one
enabling STA, a dependent STA may have detected several enabling STAs, may attempt enablement with
one and fail, and then attempt enablement with another. An enabling STA shall assign dependent
enablement identifiers in a way that makes them unique among STAs enabled by this enabling STA to help
identify sources of interference.
1742
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An enabling STA may issue a DSE measurement request to any of its dependent STAs in order to receive a
DSE measurement report that may have reported DSE LCI fields received from nearby STAs. The licensed
operator may be able to use these reports to identify interfering STAs or map overlapping coverage in a
multiple BSS situation. Because reported DSE LCI fields may refer to any destination address, a single DSE
report may contain elements received from STAs that are not yet associated with a BSS.
An enabling STA may issue an ECS announcement to any of its dependent STAs in order to have their radio
operation changed in frequency, channel bandwidth, and other operational parameters. A dependent AP or
DFS owner with dot11DSERequired true and receiving an ECS announcement from its enabling STA shall
perform the extended channel switching procedure as specified in 11.10.
An enabling STA may issue a DSE power constraint announcement to any of its dependent STAs in order to
have their transmit power reduced from the regulatory limit. A dependent AP or DFS owner with
dot11DSERequired true and receiving a DSE power constraint announcement from its enabling STA shall
perform the power constraint procedure as specified in 11.12.5.
11.12.5 Dependent STA operation with DSE
A dependent STA shall set dot11DSERequired to true.
A typical state machine implementation of dependent STA operation with DSE is provided in Figure 11-29.
Unenabled
Enablement attempt failed
Wait
Enabling frame received dot11EnablementFailHoldTime
Becoming enabled
Failed enablement within
dot11DSEEnablementTimeLimit
Receive DSE(MDR) Deenablement frame
from the enabling STA with which it is attempting to
become enabled
Become enabled within
dot11DSEEnablementTimeLimit
Enabled
Receive DSE(MDR) Deenablement frame
from the enabling STA with which it is enabled
Failure to receive Enabling Signal
from the enabling STA with which it is enabled within
dot11DSERenewalTime
Figure 11-29—Dependent STA state machine
1743
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For DSE, the following statements apply:
— A STA with dot11DSERequired true shall not transmit any frames unless it has received a Beacon
frame from an enabling STA with the Spectrum Management bit equal to 1 in the Capability
Information field and with the RegLocDSE bit equal to 1 in the DSE Registered Location element.
A dependent STA that is not enabled shall not transmit, except to attain enablement with an enabling
STA, unless such action is mandated to be allowed in the regulatory domain (e.g., emergency
services).
— A dependent STA shall not attempt enablement with an enabling STA unless the enabling STA is
transmitting Beacon frames with the RegLoc DSE bit equal to 1 in the DSE Registered Location
element.
— A dependent STA creates a dependent DSE Registered Location element containing the enabling
STA’s DSE Registered Location element and having the RegLoc DSE bit set to 0 and the Dependent
STA bit set to 1. Before enablement, the Dependent Enablement Identifier field shall be set to 0.
Upon attaining enablement, the Dependent Enablement Identifier field shall be set to the dependent
enablement identifier value received by the dependent STA from the enabling STA in the MLME-
ENABLEMENT.response primitive.
— The dependent STA shall send a Public Action DSE Registered Location Announcement frame to
the broadcast address whenever the sum of dot11TransmittedFragmentCount,
dot11GroupTransmittedFrameCount, and dot11ReceivedFragmentCount, modulo
dot11DSETransmitDivisor equals 0, possibly delayed by the completion of the sending of the
frames of the current MSDU or MMPDU or by the completion of the current transmission
opportunity (TXOP).
— A dependent STA that has not attained enablement shall not transmit beyond dot11DSEEnablement-
TimeLimit (in seconds), measured from the time of the first PHY-TXSTART.request primitive,
while attempting to attain enablement. Then if it is not enabled, it shall not transmit for
dot11DSEEnablementFailHoldTime (in seconds), before it again attempts to attain enablement.
— A dependent STA receiving a DSE Deenablement frame with the RequesterSTAAddress field
matching the enabling STA with which it last attempted enablement and the ResponderSTAAddress
field matching its own IEEE MAC address shall change its enablement state with the enabling STA
to unenabled and set all fields of its DSE Registered Location Information field (see 9.4.2.52) to 0.
— A dependent STA shall return a DSE measurement report in response to a DSE measurement
request if the request is received from the AP with which it is associated or the enabling STA with
which it last attempted enablement and the ResponderSTAAddress field matches its own IEEE
MAC address. The result may be the completed measurement or an indication that the STA is unable
to complete the measurement request. A STA shall report it is too late to undertake a measurement
request if it receives the request after the specified starting time for the measurement. The
Measurement Report Mode field of a frame that is sent in response to a DSE Measurement Request
frame shall not contain a value of 1 for the Incapable subfield and shall not contain a value of 1 for
the Refused subfield of the Measurement Report Mode field of the DSE measurement report.
— A dependent STA receiving an ECS frame from the enabling STA with which it last attempted
enablement or an ECS element from the AP with which it is associated shall perform the ECS
procedure (see 11.10.3).
— A dependent STA receiving a DSE Power Constraint frame with the RequesterSTAAddress field
matching the enabling STA with which it last attempted enablement and the ResponderSTAAddress
field matching its own IEEE MAC address shall constrain its transmit power to be less than or equal
to the maximum transmit power level specified for the current channel in the Country element minus
the local power constraint specified in the DSE Power Constraint frame.
— An enabled dependent STA shall cease transmission within dot11DSERenewalTime (in seconds) if
it has not received either a Beacon frame or a Probe Response frame from its enabling STA with the
RegLoc DSE bit equal to 1 in the DSE Registered Location element. It shall then change its
1744
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
enablement state with the enabling STA to unenabled and set all fields of its DSE Registered
Location Information field (see 9.4.2.52) to 0.
11.13 Group addressed robust management frame procedures
When management frame protection is negotiated, the MLME shall provide an encapsulation service for
group addressed robust Management frames. All group addressed robust Management frames shall be
submitted to this service for encapsulation and transmission.
For group addressed Management frames that are specified with “Yes” in the “Group Addressed Privacy”
column of Table 9-47, the group addressed frame protection service shall take the following actions:
— The frames shall be encapsulated and protected with the MGTK using the group cipher negotiated
during the AMPE exchange.
For all other group addressed Management frames, the group addressed frame protection service shall take
the following actions:
— Management frame protection for multicast/broadcast shall be set using the MLME-
SETPROTECTION.request primitive with the Protectlist including a Key Type value of IGTK. A
non-AP STA shall also set the Protect Type value to Rx. In an IBSS, a STA shall set the ProtectType
value to Rx_Tx. An AP shall set the Protect Type value to Tx.
— The IGTK shall be installed using the MLME-SETKEYS.request primitive with the value IGTK for
the Key Type subfield in the Key Information field in the IEEE 802.11 Key Descriptor.
— The frames shall be encapsulated and protected using BIP (see 12.5.4).
11.14 SA Query procedures
If dot11RSNAProtectedManagementFramesActivated is true, then the STA shall support the SA Query
procedure.
To send an SA Query Request or SA Query Response frame to a peer STA, the SME shall issue an MLME-
SA-QUERY.request or MLME-SA-QUERY.response primitive respectively. Reception of an SA Query
Request or SA Query Response frame is signaled to the SME with an MLME-SA-QUERY.indication or
MLME-SA-QUERY.confirm primitive respectively.
A STA that supports the SA Query procedure and receives an SA Query Request frame shall respond with
an SA Query Response frame unless either of the following are true:
— the STA is not currently associated to the STA that sent the SA Query Request frame
— the STA has sent a (Re)Association Request frame within dot11AssociationResponseTimeOut but
has not received a corresponding (Re)Association Response frame
NOTE—A non-AP and non-PCP STA does not respond if it is trying to reassociate with the AP or PCP that sent the SA
Query Request frame (since, except in the case of FT to the same AP, it no longer has the PTKSA) or to another AP or
PCP (it could maintain the old association and PTKSA until the reassociation is completed). There is no such restriction
for an AP or PCP.
If a non-AP and non-PCP STA that has an SA with its AP or PCP for an association that negotiated
management frame protection receives an unprotected Deauthentication or Disassociation frame with reason
code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME from the AP or PCP, the non-AP and
non-PCP STA may use this as an indication that there might be a mismatch in the association state between
itself and the AP or PCP. In such a case, the non-AP and non-PCP STA’s SME may initiate the SA Query
procedure with the AP or PCP to verify the validity of the SA by issuing one MLME-SA-QUERY.request
primitive every dot11AssociationSAQueryRetryTimeout TUs until a matching
1745
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-SA-QUERY.confirm primitive is received or dot11AssociationSAQueryMaximumTimeout TUs
from the beginning of the SA Query procedure has passed. If the AP or PCP responds to the SA Query
request with a valid SA Query response, the non-AP STA should continue to use the SA. If no valid SA
Query response is received, the non-AP and non-PCP STA’s SME may delete the SA and temporal keys
held for communication with the STA by issuing an MLME-DELETEKEYS.request primitive and the non-
AP and non-PCP STA may move into State 1 (or State 2, for a DMG STA) with the AP.
11.15 HT BSS Operation
An HT STA that is creating or joining a BSS shall be able to receive and transmit at each of the MCS values
listed in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request
primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the
MLME-JOIN.request primitive.
A STA that transmits a frame that contains both an HT Operation element and a DSSS Parameter Set
element shall set the Primary Channel field in the HT Operation element to the same value as the Current
Channel field in the DSSS Parameter Set element.
11.16 20/40 MHz BSS operation
11.16.1 Rules for operation in 20/40 MHz BSS
The rules described in 11.16.1 through 11.16.12 are applicable to STAs that are either a STA 5G or a
STA 2G4.
A 40MC STA shall support 20/40 BSS coexistence management.
NOTE—A 40MC HT STA that transmits a frame containing an Extended Capabilities element sets the 20/40 BSS
Coexistence Management Support field of this element to 1.
An HT STA 2G4 that is a member of an IBSS and that transmits a frame containing an HT Operation
element or Secondary Channel Offset element shall set the Secondary Channel Offset field of this element to
SCN.
11.16.2 Basic 20/40 MHz BSS functionality
An HT AP declares its channel width capability (20 MHz only or 20/40 MHz) in the Supported Channel
Width Set subfield of the HT Capabilities element.
An HT AP shall set the STA Channel Width field to 1 in frames in which it has set the Secondary Channel
Offset field to SCA or SCB. An HT AP shall set the STA Channel Width field to 0 in frames in which it has
set the Secondary Channel Offset field to SCN.
A non-AP HT STA declares its channel width capability (non-40MC HT STA or 40MC HT STA) in the
Supported Channel Width Set subfield in the HT Capabilities element.
NOTE 1—A 20/40 MHz BSS might include any mixture of 40MC HT STAs, non-40MC HT STAs, and non-HT STAs.
Protection requirements for mixed networks are defined in 10.26.
NOTE 2—A non-AP HT STA can switch between 40MC HT STA and non-40MC HT STA operation by disassociation
followed by association.
An HT STA shall not indicate support for 40 MHz unless it supports reception and transmission of
40 MHz PPDUs using all MCSs within the Basic HT-MCS Set field of the HT Operation parameter of the
MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the
1746
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SelectedBSS parameter of the MLME-JOIN.request primitive and all MCSs that are mandatory for the
attached PHY.
An HT STA shall not transmit a 20 MHz PPDU containing one or more Data frames using the secondary
channel of a 20/40 MHz BSSs. The Notify Channel Width frame may be used by a STA to notify another
STA that the STA wishes to receive frames in the indicated channel width.
An HT STA that is a member of an IBSS adopts the value of the Secondary Channel Offset field in received
frames according to the rules in 11.1.5 and shall not transmit either of the following:
— A value in the Secondary Channel Offset field that differs from the most recently adopted value
— An operating class in the Extended Channel Switch Announcement frame or element with a
different behavior than the currently adopted PrimaryChannelLowerBehavior or
PrimaryChannelUpperBehavior
11.16.3 Channel scanning and selection methods for 20/40 MHz operation
11.16.3.1 General
An HT STA shall set the following MIB attributes to true: dot11OperatingClassesImplemented,
dot11OperatingClassesRequired, and dot11ExtendedChanneSwitchActivated.
An AP operating a 20/40 MHz BSS, on detecting an OBSS whose primary channel is the AP’s secondary
channel, switches to 20 MHz BSS operation and may subsequently move to a different channel or pair of
channels. A DFS owner (DO) operating a 20/40 MHz IBSS, on detecting an OBSS whose primary channel
is the DO’s secondary channel, may choose to move to a different pair of channels.
NOTE—The setting up of a 40 MHz off-channel TDLS direct link is specified in 11.23.6.3.
11.16.3.2 Scanning requirements for a 20/40 MHz BSS
Before an AP or DO starts a 20/40 MHz BSS, it shall perform a minimum of
dot11BSSWidthChannelTransitionDelayFactor OBSS scans (see 11.16.5) to search for existing BSSs.
If the AP or DO starts a 20/40 MHz BSS in the 5 GHz band and the BSS occupies the same two channels as
any existing 20/40 MHz BSSs, then the AP or DO shall select a primary channel of the new BSS that is
identical to the primary channel of the existing 20/40 MHz BSSs and a secondary channel of the new 20/40
MHz BSS that is identical to the secondary channel of the existing 20/40 MHz BSSs, unless the AP
discovers that on these two channels are existing 20/40 MHz BSSs with different primary and secondary
channels.
If an AP or DO starts a 20/40 MHz BSS in the 5 GHz band, the selected secondary channel should
correspond to a channel on which no beacons are detected during the dot11BSSWidthChannelTransition-
DelayFactor OBSS scan time performed by the AP or DO, unless there are beacons detected on both the
selected primary and secondary channels.
NOTE—The 20/40 MHz channel sets and their corresponding behavior limits (i.e., choice of primary and secondary
channels) permissible in each operating class are defined in Annex E and Annex D, respectively.
An HT AP or a DO that is also an HT STA should not start a 20 MHz BSS in the 5 GHz band on a channel
that is the secondary channel of a 20/40 MHz BSS.
The AP or DO may continue to periodically scan after the BSS has been started. Information obtained
during such scans is used as described within this subclause and within 11.16.2.
1747
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
After starting a 20 MHz BSS, a 40MC HT AP 2G4 shall perform a minimum of
dot11BSSWidthChannelTransitionDelayFactor OBSS scans, either by itself or through its associated STAs
before making a transition from a 20 MHz BSS to a 20/40 MHz BSS. When the AP performs the scanning
and the secondary channel for the 20/40 MHz BSS has been selected, then the scan shall be performed over
the set of channels that are allowed operating channels within the current operational regulatory domain and
whose center frequency falls within the affected frequency range given by Equation (11-1). When the AP
performs the scanning without an intended secondary channel for the 20/40 MHz BSS or when the AP’s
associated STA(s) perform the scanning, then the scan shall be performed on all channels in the frequency
band.
NOTE—A 40MC HT AP can change from operating a 20 MHz BSS to a 20/40 MHz BSS while maintaining
associations by making a change to the transmitted value of the Secondary Channel Offset field.
fP + fS fP + fS
affected frequency range = [ -------------- – 25 MHz, -------------- + 25 MHz] (11-1)
2 2
where
fP is the center frequency of channel P
fS is the center frequency of channel S
A 40MC HT AP 2G4 shall maintain a local boolean variable 20/40 Operation Permitted that can have either
the value true or false. The initial value of 20/40 Operation Permitted shall be false. The value of 20/40
Operation Permitted is recomputed according to Equation (11-2) whenever a BSS channel width trigger
event is detected or whenever a period of time has elapsed with no BSS channel width triggers being
detected and no overlap being reported, as defined in 11.16.12.
20/40 Operation Permitted = (P == OPi for all values of i) AND
(P == OTi for all values of i) AND
(S == OSi for all values of i) (11-2)
where
P is the operating or intended primary channel of the 20/40 MHz BSS
S is the operating or intended secondary channel of the 20/40 MHz BSS
OPi is member i of the set of channels that are members of the channel set C and that are the primary
operating channel of at least one 20/40 MHz BSS that was detected within the AP’s BSA during the
previous dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidthTriggerScanInterval seconds
OSi is member i of the set of channels that are members of the channel set C and that are the secondary
operating channel of at least one 20/40 MHz BSS that was detected within the AP’s BSA during the
previous dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidthTriggerScanInterval seconds
OTi is member i of the set that comprises all channels that are members of the channel set C that were
listed at least once in the Channel List fields of 20/40 BSS Intolerant Channel Report elements
received during the previous dot11BSSWidthChannelTransitionDelayFactor ×
dot11BSSWidthTriggerScanInterval seconds and all channels that are members of the channel set C
and that are the primary operating channel of at least one 20 MHz BSS that was detected within the
AP’s BSA during the previous dot11BSSWidthChannelTransitionDelayFactor ×
dot11BSSWidthTriggerScanInterval seconds
C is the set of all channels that are allowed operating channels within the current operational
regulatory domain and whose center frequency falls within the affected frequency range given by
Equation (11-1)
If either side of “==” above is the empty set or has a null value, then the expression is defined to have
a boolean value of true.
1748
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A 40MC HT AP 2G4 shall not start a 20/40 MHz BSS in the 2.4 GHz band if the value of the local variable
20/40 Operation Permitted is false (see Equation (11-2)).
A 40MC HT AP 2G4 may transmit a frame containing a Secondary Channel Offset field set to a value of
SCA or SCB only if 20/40 Operation Permitted is true.
In addition to information obtained by the 40MC HT AP 2G4 through its own scanning, a 40MC HT AP
2G4 shall use 20/40 BSS Intolerant Channel Report element information from received 20/40 BSS
Coexistence Management frames with a value of the Address 1 field that matches the 40MC HT AP 2G4
using either individual or group addressing, but with no qualification of the Address 3 value, when
determining if 20/40 Operation Permitted is true or false. The information from the Channel List fields of
received 20/40 BSS Intolerant Channel Report elements is used in generating the OT set for Equation (11-2).
After initial establishment of the 20/40 MHz BSS, if the value of 20/40 Operation Permitted becomes false,
the 40MC HT AP 2G4 reverts to 20 MHz BSS operation (see 11.16.12). The 40MC HT AP 2G4 might
subsequently move the BSS to a pair of channels where the value of 20/40 Operation Permitted evaluates to
true.
11.16.3.3 Channel management at the AP and in an IBSS
While operating a 20/40 MHz BSS, a DO or an AP may move its BSS, and an AP may switch the BSS to 20
MHz operation either alone or in combination with a channel move. These channel moving or BSS width
switching operations might occur if, for example, another BSS starts to operate in either or both of the
primary or secondary channels, or if radar is detected in either or both of the primary or secondary channels,
or for other reasons that are beyond the scope of this standard. Specifically, the AP or DO may move its BSS
to a different pair of channels, and the AP may separately, or in combination with the channel switch,
change from a 20/40 MHz BSS to a 20 MHz BSS using either the primary channel of the previous channel
pair or any other available 20 MHz channel. While operating a 20 MHz BSS, a DO or an AP may move its
BSS, and an AP may switch the BSS to a 20/40 MHz BSS, either alone or in combination with a channel
move.
When switching a 20/40 MHz BSS to 20 MHz BSS mode, the AP may recalculate the TS bandwidth budget
and may delete one or more active TSs by invoking the MLME-DELTS.request primitive with a
ReasonCode value of SERVICE_CHANGE_PRECLUDES_TS.
An AP switches between 20/40 MHz BSS and 20 MHz BSS as follows:
— By changing the value of the Secondary Channel Offset field of the HT Operation element in the
Beacon frame, and/or
— By changing the value of the Secondary Channel Offset field of the Secondary Channel Offset
element, and/or
— Through the New Operating Class field of transmitted Extended Channel Switch Announcement
elements.
In order to maintain existing associations and/or minimize disruption to communications with other STAs
while making a channel width change or while performing a channel pair relocation, an AP may inform HT
STAs within its BSS that it is making the change by including an Extended Channel Switch Announcement
element in Beacon, Probe Response, and Extended Channel Switch Announcement frame transmissions
until the intended channel switch time. A DO may inform HT STAs within its BSS that it is performing a
channel pair relocation by including an Extended Channel Switch Announcement element in Beacon, Probe
Response, and Extended Channel Switch Announcement frame transmissions until the intended channel
switch time. The New Channel Number field of the Extended Channel Switch Announcement
element represents the new channel (when the BSS after relocation/width change will be a 20 MHz
BSS) or the primary channel of the new pair of channels (when the BSS after relocation/width change will
1749
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
be a 20/40 MHz BSS). When changing to a new pair of channels, the New Operating Class field specifies
the position of the secondary channel relative to the new primary channel, i.e., either above or below.
When transmitting HT Operation elements, Channel Switch Announcement elements, and/or Extended
Channel Switch Announcement elements, the AP moving the BSS or changing its channel width selects a
combination of operating parameters from any single row of any one of the tables in Annex E that is
appropriate for the current operating domain of the AP. Similarly, when transmitting HT Operation
elements, Channel Switch Announcement elements, and/or Extended Channel Switch Announcement
elements, the DO moving the BSS selects a combination of operating parameters from any single row of any
one of the tables in Annex E that is appropriate for the current operating domain of the DO. The AP or DO
selects one channel number from the “Channel set” column of the selected row. The AP or DO includes the
selected information in subsequently transmitted frames that contain any combination of the following four
elements:
— HT Operation element
— Channel Switch Announcement element
— Extended Channel Switch Announcement element
— Secondary Channel Offset element
The AP or DO shall set the Secondary Channel Offset field of transmitted HT Operation elements and
transmitted Secondary Channel Offset elements to SCA if the Behavior limits set column of the selected row
contains the value PrimaryChannelLowerBehavior. The AP or DO shall set the Secondary Channel Offset
field of transmitted HT Operation elements and transmitted Secondary Channel Offset elements to SCB if
the Behavior limits set column of the selected row contains the value PrimaryChannelUpperBehavior. The
AP or DO shall set the Secondary Channel Offset field of transmitted HT Operation elements and
transmitted Secondary Channel Offset elements to SCN if the Behavior limits set column of the selected row
contains neither the value PrimaryChannelLowerBehavior nor the value PrimaryChannelUpperBehavior.
The AP or DO shall set the New Channel Number field of transmitted Channel Switch Announcement
elements and Extended Channel Switch Announcement elements to the value of the selected channel from
the selected row.
The AP or DO shall set the New Operating Class field of transmitted Extended Channel Switch
Announcement elements to the value of the “Operating class” column of the selected row.
Movement of a 20/40 MHz BSS from one channel pair to a different channel pair and changing between
20 MHz and 20/40 MHz operation should be scheduled so that all STAs in the BSS, including STAs in
power save mode, have the opportunity to receive at least one Extended Channel Switch Announcement
element or Channel Switch Announcement element before the switch.
When the Extended Channel Switch Announcement element and Extended Channel Switch Announcement
frame are transmitted in bands where dot11SpectrumManagementRequired is true, the Channel Switch
Announcement element and Channel Switch Announcement frame may also be transmitted. A STA that
announces a channel switch using both the Extended Channel Switch Announcement element and the
Channel Switch Announcement element shall set the New Channel Number field of both elements to the
same value. An HT STA that receives a channel switch announcement through both the Extended Channel
Switch Announcement element and the Channel Switch Announcement element ignores the received
Channel Switch Announcement element; this is called a superseded Channel Switch Announcement
element.
For 20 MHz operation when the new operating class signifies 40 MHz channel spacing, the 20 MHz channel
is the primary channel of the 40 MHz channel.
1750
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.16.4 40 MHz PPDU transmission restrictions
11.16.4.1 Fields used to determine 40 MHz PPDU transmission restrictions
Several fields from various frames are used to convey information between STAs regarding the support for
40 MHz PPDU transmission and reception and regarding any current prohibition against the transmission
and reception of 40 MHz PPDUs.
The rules defined in 11.16.4.2, 11.16.4.3, and 11.16.4.4 describe the behavior that accompanies those fields.
The fields that are used to determine the status of the transmission and reception of 40 MHz PPDUs are as
follows:
— The Supported Channel Width Set subfield of the HT Capabilities element
— The Secondary Channel Offset field of the HT Operation element
— The STA Channel Width field of the HT Operation element
— The Channel Width field of the Notify Channel Width frame
— The Extended Channel Switch Announcement element
The Supported Channel Width Set subfield is used to indicate whether the transmitting STA is capable of
transmitting and receiving 40 MHz PPDUs.
NOTE—The Supported Channel Width Set subfield transmitted by an AP is constant for the lifetime of its BSS as it is a
parameter of the MLME-START.request primitive.
In addition to the restrictions on transmission of 40 MHz mask PPDUs found in 11.16.4.1 through 11.16.4.4,
if a STA operating in the 2.4 GHz industrial, scientific, and medical (ISM) band has no means of
determining the presence of non-IEEE-802.11 communication devices operating in the area, then the STA
shall not transmit any 40 MHz mask PPDUs.
In addition to the restrictions on transmission of 40 MHz mask PPDUs found in 11.16.4.1 through 11.16.4.4,
if a STA operating in the 2.4 GHz ISM band has a means of determining the presence of non-IEEE-802.11
communication devices operating in the area and determines either that no non-
IEEE-802.11 communication device is operating in the area or that non-IEEE-802.11 communication
devices are operating in the area but the STA implements a coexistence mechanism for these non-
IEEE-802.11 communication devices, then the STA may transmit 40 MHz mask PPDUs; otherwise, the
STA shall not transmit any 40 MHz mask PPDUs.
11.16.4.2 Infrastructure non-AP STA restrictions
A STA that is associated with an AP shall not transmit a value in the Supported Channel Width Set subfield
that differs from a previously transmitted value during its current association.
The Secondary Channel Offset field is used to indicate whether the BSS is occupying a 40 MHz wide pair of
channels and, when a secondary channel exists, whether it is above or below the primary channel in
frequency. The Extended Channel Switch Announcement frame and the Extended Channel Switch
Announcement element can each be used to indicate a transition from 20/40 MHz BSS operation to 20 MHz
BSS operation and vice versa and to indicate whether a secondary channel, when it exists, is above or below
the primary channel in frequency.
A 40MC HT STA shall maintain a local boolean variable 40MHzOperatingClass as described here. The
initial value of 40MHzOperatingClass shall be false. The value of 40MHzOperatingClass is recomputed
according to the rules in this subclause at every TBTT and following the reception of a frame transmitted by
the AP associated with the STA when that frame contains either of the following fields:
1751
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Current Operating Class field
— New Operating Class field
The local boolean variable 40MHzOperatingClass becomes true upon reception of a frame transmitted by
the associated AP if the frame contained a Current Operating Class field with a value that corresponds to an
operating class that corresponds to a channel spacing value of 40 MHz, as specified in Annex E.
The local boolean variable 40MHzOperatingClass becomes false upon reception of a frame transmitted by
the associated AP if the frame contained a Current Operating Class field with a value that corresponds to an
operating class that does not correspond to a channel spacing value of 40 MHz.
The local boolean variable 40MHzOperatingClass becomes true at the nth TBTT following reception of a
frame transmitted by the associated AP that contains an Extended Channel Switch Announcement element
with a value of n in the Channel Switch Count field and a value in the New Operating Class field that
corresponds to an operating class that corresponds to a channel spacing value of 40 MHz provided that the
frame is the most recently received frame meeting the above conditions.
The local boolean variable 40MHzOperatingClass becomes false at the nth TBTT following reception of a
frame transmitted by the associated AP that contains an Extended Channel Switch Announcement element
with a value of n in the Channel Switch Count field and a value in the New Operating Class field that
corresponds to an operating class that does not correspond to a channel spacing value of 40 MHz provided
that the frame is the most recently received frame meeting the above conditions.
A STA can choose to dynamically constrain its operating channel width to 20 MHz while being a member of
a 20/40 MHz BSS. Transitions to and from this constrained state are indicated using the transmission of a
frame that carries the Channel Width field. A Channel Width field value of 0 indicates that the transmitting
STA is not currently able to receive 40 MHz PPDUs, beginning at the end of the transmission of the frame
that contained the Channel Width field.
A STA shall not transmit a frame containing a STA Channel Width field or a Channel Width field set to 1 if
the value of its Supported Channel Width Set subfield is 0.
A STA that is associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU containing
one or more frames addressed to another STA (STA2) unless the following three conditions are true:
— The Supported Channel Width Set subfield of the HT Capabilities element of both STAs is equal
to 1
— The Secondary Channel Offset field of the most recently received HT Operation element sent by the
AP of the BSS has a value of SCA or SCB
— The local boolean variable 40MHzOperatingClass is true.
If the above three conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more
frames addressed to STA2 unless the following two conditions are true:
— Either STA1 has not received a Notify Channel Width frame that was transmitted by STA2, or the
Channel Width field of the most recently received Notify Channel Width frame at STA1 that was
transmitted by STA2 is nonzero.
— If STA2 is an AP, the STA Channel Width field of the most recently received HT Operation element
that was transmitted by STA2 is equal to 1.
11.16.4.3 AP restrictions
An AP shall not transmit a 40 MHz PPDU containing one or more frames addressed to another STA unless
the following three conditions are true:
1752
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The Supported Channel Width Set subfield of the HT Capabilities element of the AP and all
associated STAs are equal to a nonzero value.
— The Secondary Channel Offset field of the AP’s most recently transmitted HT Operation element
has a value of SCA or SCB
— The local boolean variable 40MHzOperatingClass is true.
If the above three conditions are met, the AP should not transmit a 40 MHz PPDU containing frames
addressed to another STA unless either the AP has not received a Notify Channel Width frame that was
transmitted by the STA or the Channel Width field of the most recently received Notify Channel Width
frame at the AP that was transmitted by the STA is nonzero.
An AP shall not transmit a 40 MHz PPDU containing one or more frames with a group address in the
Address 1 field unless the following three conditions are true:
— The Supported Channel Width Set subfield of the HT Capabilities element of the AP is equal to 1
— The Secondary Channel Offset field of the AP’s most recently transmitted HT Operation element
has a value of SCA or SCB
— The local boolean variable 40MHzOperatingClass is true.
If the above three conditions are met, the AP should not transmit a 40 MHz PPDU containing one or more
frames with a group address in the Address 1 field unless either the AP has not received a Notify Channel
Width frame from any STA in the BSS or the Channel Width field of the most recently received Notify
Channel Width frame from each STA that transmitted a Notify Channel Width frame is nonzero.
11.16.4.4 Restrictions on non-AP STAs that are not infrastructure BSS members
An HT STA 2G4 that is not a member of an infrastructure BSS shall not transmit a 40 MHz mask PPDU.
An HT STA 5G that is not associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU
containing frames addressed to another STA (STA2) unless the following three conditions are true:
— The Supported Channel Width Set subfield of the HT Capabilities element of both STAs is equal
to 1
— The Secondary Channel Offset field of the most recently received HT Operation element sent by
STA2 has a value of SCA or SCB
— The Secondary Channel Offset field of the most recently transmitted HT Operation element sent by
STA1 has a value of SCA or SCB
If the above three conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more
frames addressed to STA2 unless STA1 has not received a STA Channel Width field that was transmitted by
STA2 or the value of the most recently received STA Channel Width field at STA1 that was transmitted by
STA2 is nonzero.
An HT STA 5G that is not associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU
containing one or more frames with a group address in the Address 1 field unless the following two
conditions are true:
— The Supported Channel Width Set subfield of the HT Capabilities element transmitted by STA1 is
equal to 1.
— The Secondary Channel Offset field of the HT Operation element most recently transmitted by
STA1 has a value of SCA or SCB.
1753
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the above two conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more
frames with a group address in the Address 1 field unless the most recently received STA Channel Width
field for each other known member of the BSS of which STA1 is a member is equal to 1.
11.16.5 Scanning requirements for 40-MHz-capable STA
An OBSS scan operation is a passive or active scan of a set of channels that are potentially affected by
20/40 MHz BSS operation, i.e., the 20 MHz channels that wholly or partly overlap the 40 MHz signal. Each
channel in the set may be scanned more than once during a single OBSS scan operation. OBSS scans are
performed by STAs that are 40MC HT STA 2G4. STAs that are 40MC HT STA 5G are not required to
perform OBSS scan operations.
NOTE—STAs that perform OBSS scans report discovered BSSs and received 20/40 BSS coexistence information to
their associated AP (see 11.16.12).
During an individual scan within an OBSS scan operation, the minimum per-channel scan duration is
dot11OBSSScanPassiveDwell TU (when scanning passively) or dot11OBSSScanActiveDwell TU (when
scanning actively). During an OBSS scan operation, each channel in the set is scanned at least once per
dot11BSSWidthTriggerScanInterval seconds, and the minimum total scan time (i.e., the sum of the scan
durations) per channel within a single OBSS scan operation is dot11OBSSScanPassiveTotalPerChannel TU
for a passive scan and dot11OBSSScanActiveTotalPerChannel TU for an active scan.
NOTE—The values provided in the previous paragraph indicate the minimum requirements. For some combinations of
parameter values, it is necessary to exceed the minimum values of some parameters in order to meet the minimum value
constraints of all parameters.
When an AP transmits an Overlapping BSS Scan Parameters element, the value of each of the fields of the
element shall be set to the value of the MIB attribute from the transmitting AP’s MIB according to the
mapping between the frame fields and MIB attributes as defined in 9.4.2.59.
Upon receipt of a frame containing an Overlapping BSS Scan Parameters element from the AP with which a
40MC HT STA 2G4 is associated, the MLME of the receiving 40MC HT STA 2G4 shall update each of the
values of the MIB attributes used during OBSS scanning operations according to the mapping between the
frame fields and MIB attributes as defined in 9.4.2.59.
A 40MC HT AP 2G4 may transmit frames containing an Overlapping BSS Scan Parameters element to any
or all associated STAs in order to provide OBSS scan parameter values that are different from the default
values.
A 40MC HT STA 2G4 that is associated with a 40MC HT AP 2G4 shall perform at least one OBSS scan
every dot11BSSWidthTriggerScanInterval seconds, unless the 40MC HT STA 2G4 satisfies the conditions
described in 11.16.6.
11.16.6 Exemption from OBSS scanning
A 40MC HT STA 2G4 shall maintain a local variable ActivityFraction. The value of ActivityFraction is
defined by Equation (11-3).
T ACTIVE
ActivityFraction = -------------------------------------
- (11-3)
T MEASURE-ACTIVE
where
T ACTIVE is the total duration of transmitted MSDUs and received individually addressed MSDUs during
the previous T MEASURE-ACTIVE seconds
1754
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
T MEASURE-ACTIVE is dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidthTriggerScan-
Interval seconds.
A 40MC HT STA 2G4 may transmit to its associated AP a 20/40 BSS Coexistence Management frame with
the Scanning Exemption Request field in the 20/40 Coexistence element set to 1.
If the last 20/40 BSS Coexistence Management frame received by a 40MC HT STA 2G4 in an individually
addressed frame from its associated AP has the Scanning Exemption Grant field equal to 1, the STA is
exempted from scanning whenever the value of its local variable ActivityFraction is less than
dot11OBSSScanActivityThreshold/10 000.
A 40MC HT AP 2G4 shall not transmit a 20/40 BSS Coexistence Management frame with the Scanning
Exemption Grant field set to 1 addressed to a 40MC HT STA if the following condition is true:
— The 40MC HT STA has transmitted one or more channel report elements and is the only STA in the
BSS that has indicated one or more channels on which a STA has found conditions that disallow the
use of a 20/40 MHz BSS.
If there is more than one 40MC HT STA in the BSS that has indicated conditions that disallow the use
of 20/40 MHz BSS on a specific channel, then the following apply:
— If all of the 40MC HT STAs that have indicated unavailability of a channel have also requested to be
exempt from scanning, the AP shall disallow at least one of the 40MC HT STA to be exempt from
scanning.
— If, from the group of 40MC HT STAs that have indicated unavailability of a channel, there is at least
one 40MC HT STA that has not requested to be exempt from scanning, the AP may allow all of the
STAs that have requested to be exempt from scanning to be exempted from scanning.
11.16.7 Communicating 20/40 BSS coexistence information
In addition to the 20/40 BSS Coexistence Management frame, a STA can include the 20/40 BSS Coexistence
element in transmitted Beacon, Probe Request, Probe Response, (Re)Association Request, and
(Re)Association Response frames.
11.16.8 Support of DSSS/CCK in 40 MHz
Transmission and reception of PPDUs using DSSS/CCK by 40MC HT STAs is managed using the DSSS/
CCK Mode in 40 MHz subfield of the HT Capability Information field in the HT Capabilities element (see
9.4.2.56.2).
An HT STA declares its capability to use DSSS/CCK rates while it has a 40 MHz operating channel width
through the DSSS/CCK Mode in 40 MHz subfield of its (Re)Association Request frames.
If the DSSS/CCK Mode in 40 MHz subfield is equal to 1 in Beacon and Probe Response frames, an
associated HT STA in a 20/40 MHz BSS may generate DSSS/CCK transmissions. If the subfield is equal
to 0, then the following apply:
— An associated HT STA shall not generate DSSS/CCK transmissions.
— The AP shall not include an ERP element in its Beacon and Probe Response frames.
— The AP shall not include DSSS/CCK rates in the Supported Rates and BSS Membership Selectors
element.
— The AP shall refuse association requests from a STA that includes only DSSS/CCK rates in its
Supported Rates and BSS Membership Selectors element and Extended Supported Rates and BSS
Membership Selectors element.
1755
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA not operating in the 2.4 GHz band shall set the DSSS/CCK Mode in 40 MHz subfield to 0.
11.16.9 STA CCA sensing in a 20/40 MHz BSS
This subclause defines CCA sensing rules for an HT STA that is not a VHT STA. For rules related to a VHT
STA, see 10.3.2.6, 10.22.2.6, and 10.22.3.
A STA may transmit a 20 MHz mask PPDU in the primary channel following the rules in 10.22.2.
A STA transmitting a 40 MHz mask PPDU that begins a TXOP using EDCA as described in 10.22.2.4 or
that is using a PIFS as permitted in 10.3.2.3.4 shall sense CCA on both the 20 MHz primary channel and the
20 MHz secondary channel before the 40 MHz mask PPDU transmission starts.
Unless explicitly stated otherwise, a STA may treat a PHY-CCA.indication(BUSY) primitive as a PHY-
CCA.indication(IDLE) primitive in the following cases:
— If the channel-list parameter is present and equal to {secondary} and the STA is transmitting a
20 MHz mask PPDU on the primary channel, or
— If the channel-list parameter is present and equal to {primary} and the STA is transmitting a 20 MHz
mask PPDU on the secondary channel.
NOTE—Transmission of PPDUs on the secondary channel is also subject to constraints in 11.16.2.
At the specific slot boundaries (see Figure 10-26) determined by the STA based on the 20 MHz primary
channel CCA, when the transmission begins a TXOP using EDCA (as described in 10.22.2.4), the STA may
transmit a pending 40 MHz mask PPDU only if the secondary channel has also been idle during the times
the primary channel CCA is performed (defined in 10.22.2.4) during an interval of a PIFS for the 5 GHz
band and DIFS for the 2.4 GHz band immediately preceding the expiration of the backoff counter. If a STA
was unable to transmit a 40 MHz mask PPDU because the secondary channel was occupied during this
interval, it may take one of the following steps:
a) Transmit a 20 MHz mask PPDU on the primary channel.
b) Restart the channel access attempt. In this case, the STA shall invoke the backoff procedure as
specified in 10.22.2 as though the medium is busy as indicated by either physical or virtual CS and
the backoff timer has a value of 0.
NOTE—As a result of this rule, the STA selects a new random number using the current value of CW[AC], and
the retry counters are not updated.
When a TXOP is obtained for a 40 MHz PPDU, the STA may transmit 40 MHz PPDUs and/or 20 MHz
PPDUs during the TXOP. When the TXOP is obtained by the exchange of 20 MHz PPDUs only in the
primary channel, the STA shall not transmit 40 MHz PPDUs during the TXOP.
11.16.10 NAV assertion in 20/40 MHz BSS
An HT STA shall update its NAV using the Duration/ID field value in any frame received in a 20 MHz
PPDU in the primary channel or received in a 40 MHz PPDU and that does not have an RA matching the
STA’s MAC address.
NOTE—A STA need not set its NAV in response to 20 MHz frames received on the secondary channel or any other
channel that is not the primary channel, even if it is capable of receiving those frames.
11.16.11 Signaling 40 MHz intolerance
An HT STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted HT Capabilities elements if
dot11FortyMHzIntolerant is true; otherwise, the field shall be set to 0.
1756
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted 20/40 BSS Coexistence fields if
dot11FortyMHzIntolerant is true; otherwise, the field shall be set to 0. A STA 2G4 that is not an HT STA
2G4 shall include a 20/40 BSS Coexistence element in Management frames in which the element may be
present if dot11FortyMHzIntolerant is present and dot11FortyMHzIntolerant is true.
A STA 5G shall set the Forty MHz Intolerant field to 0 in transmitted HT Capabilities elements and
20/40 BSS Coexistence fields.
11.16.12 Switching between 40 MHz and 20 MHz
A VHT STA is not required to perform any of the behavior described in this subclause associated with
Information Request and 20 MHz BSS Width Request.
The following events are defined to be BSS channel width trigger events (TEs):
— TE-A: On any of the channels of the channel set defined in Clause 18, reception of a Beacon frame
that does not contain an HT Capabilities element.
— TE-B: On any of the channels of the channel set defined in Clause 18, reception of a 20/40 BSS
Coexistence Management, Beacon, Probe Request, or Probe Response frame that contains a value of
1 in a Forty MHz Intolerant field and that has the Address 1 field equal to the receiving STA’s
address or to a group address value, with no further addressing qualifications.
— TE-C: Reception of a 20/40 BSS Coexistence Management frame with the 20 MHz BSS Width
Request field equal to 1 and with a value of the Address 1 field that matches the receiving STA
using either individual or group addressing and with a value of the TA field that corresponds to the
MAC address of a STA with which the receiver is associated.
— TE-D: Reception of a 20/40 BSS Coexistence Management frame containing at least one 20/40 BSS
Intolerant Channel Report element with a nonzero length and with a value of the Address 1 field
equal to the receiving STA’s address or to a group address value, but with no qualification of the
Address 3 value.
A 40MC HT AP 2G4 shall reevaluate the value of the local variable 20/40 Operation Permitted (see
11.16.3.2) when either of the following events occurs:
— A BSS channel width trigger event TE-A is detected.
— A BSS channel width trigger event TE-D is detected.
A 40MC HT AP 2G4 may reevaluate the value of the local variable 20/40 Operation Permitted (see
11.16.3.2) when either of the following situations occurs:
— No BSS channel width trigger events TE-A are detected for a period of time equal to
dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidthTriggerScanInterval seconds.
— No BSS channel width trigger events TE-D are detected for a period of time equal to
dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidthTriggerScanInterval seconds.
A 40MC HT AP 2G4 that detects either BSS channel width trigger event TE-B or TE-C or that determines
that the value of its variable 20/40 Operation Permitted has changed from true to false shall set the
Secondary Channel Offset field to SCN in transmitted HT Operation elements beginning at the next DTIM
or next TBTT if no DTIMs are transmitted to indicate that no secondary channel is present (i.e., that the BSS
operating width is 20 MHz).
A 40MC HT AP 2G4 shall not set the Secondary Channel Offset field to a value of SCA or SCB in
transmitted HT Operation elements unless the following two conditions have been met:
— A period of dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidthTriggerScanInterval
seconds have elapsed during which no BSS channel width trigger events TE-B or TE-C are detected.
— The value of the local variable 20/40 Operation Permitted (see 11.16.3.2) is true.
1757
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
To request an update of the status of the 20 MHz BSS Width Request field, a 40MC HT AP 2G4 can
transmit a 20/40 BSS Coexistence Management frame with a value of 1 in the Information Request field as
described in 11.18.
A 40MC HT STA 2G4 that is associated with a 40MC HT AP 2G4 shall maintain a record of detected BSS
channel width trigger events as follows:
— For each detected BSS channel width trigger event TE-A:
— If a DSSS Parameter Set field is present in the received Beacon frame, the channel of the BSS
channel width trigger event is the value of the Current Channel field of the DSSS Parameter
Set field; otherwise, the channel of the BSS channel width trigger event is the channel on
which the detecting STA received the Beacon frame.
— If a Supported Operating Classes element is present in the received Beacon frame, the
operating class of the BSS channel width trigger event is the value of the Current Operating
Class field of the Supported Operating Classes element of the received Beacon frame;
otherwise, the operating class of the BSS channel width trigger event is “unknown.”
— For each detected BSS channel width trigger event TE-A of a unique combination of operating class
and channel, the 40MC HT STA 2G4 shall maintain a record containing two variables:
— The operating class of the BSS channel width trigger event
— The channel of the BSS channel width trigger event
NOTE—If a BSS channel width trigger event TE-A is detected for an operating class and channel combination for
which no record exists, the STA creates such a record.
If a BSS channel width trigger event TE-A is detected for an operating class and channel combination for
which a record already exists, the information in that record shall be updated with the information
determined from the new trigger event.
For all BSS channel width trigger events TE-B, the 40MC HT STA 2G4 shall maintain a single record
containing an indication of whether one or more trigger events TE-B have been detected.
At the completion of an OBSS scan operation (i.e., at the end of the period of time equal to
dot11BSSWidthTriggerScanInterval) or when it receives a 20/40 BSS Coexistence Management frame from
its associated AP that contains a value of 1 in the Information Request field, a 40MC HT STA 2G4 that is
associated with a 40MC HT AP 2G4 shall create a 20/40 BSS Coexistence Management frame by including
a value of 0 for all fields of a 20/40 BSS Coexistence Management frame and then transferring information
from the BSS channel width trigger event TE-A and TE-B records to the frame according to the following
four steps:
— For each unique operating class that is stored in the set of BSS channel width trigger event TE-A
records, the STA shall create a 20/40 BSS Intolerant Channel Report element for inclusion in the
frame and include all of the unique channels associated with the operating class in the channel list of
that element.
— The STA sets the Forty MHz Intolerant field of the 20/40 BSS Coexistence element based on A
STA’s FortyMHzIntolerant (see 11.16.11).
— The STA shall set to 1 the 20 MHz BSS Width Request field of the 20/40 BSS Coexistence element
for inclusion in the frame if a record for BSS channel width trigger event TE-B exists and indicates
that at least one trigger event TE-B has been detected.
— The STA may set to 1 the Information Request field.
Upon completion of these four steps, the 40MC HT STA 2G4 shall delete all records for trigger events TE-
A and TE-B. Subsequently detected trigger events cause the creation of new records as necessary to be used
in subsequently generated 20/40 BSS Coexistence Management frames. Following the record deletion, the
1758
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
40MC HT STA 2G4 shall transmit to its associated 40MC HT AP 2G4 the 20/40 BSS Coexistence
Management frame if any of the following conditions is true:
— At least one 20/40 BSS Intolerant Channel Report element with the Length field equal to a nonzero
value is included.
— The Forty MHz Intolerant field is equal to 1.
— The 20 MHz BSS Width Request field is equal to 1.
— The Information Request field is equal to 1.
— The frame was created in response to the reception of an Information Request field that was equal
to 1.
11.17 Phased coexistence operation (PCO)
11.17.1 General description of PCO
The PCO mechanism is obsolete. Consequently, this subclause might be removed in a later revision of this
standard.
PCO is an optional coexistence mechanism in which a PCO active AP divides time into alternating 20 MHz
and 40 MHz phases (see Figure 11-30). The PCO active AP reserves the 20 MHz primary channel and the
20 MHz secondary channel in turn to start the 40 MHz phase and resets the NAV in the 20 MHz channels in
the opposite order to start the 20 MHz phase. Due to the protection of the 40 MHz period in both channels, it
is tolerant of OBSSs on both 20 MHz halves of a 40 MHz channel.
Beacon
Set PCO
or CTS-to-self CF-End CF-End
Phase
Set PCO Phase
20 MHz
ch_a phase
40 MHz
(primary) phase
ch_b
(secondary)
20 MHz STA NAV
in ch_a
20 MHz STA NAV
in ch_b
PCO active STA NAV NAV
Figure 11-30—Phased coexistence operation (PCO)
A PCO active STA that does not know the current PCO phase shall transmit using a 20 MHz PPDU.
During the 40 MHz phase, a PCO active STA shall transmit Data frames using a 40 MHz HT PPDU and
Control frames using a non-HT duplicate or a 40 MHz HT PPDU, with the following exceptions:
— Any CF-End frame shall be sent using only a 40 MHz HT PPDU.
— A PCO active AP may transmit 20 MHz group addressed frames as defined in 10.7.5.3.
A PCO active STA shall transmit Management frames in 20 MHz or 40 MHz PPDUs according to 10.7.5
during the 40 MHz phase, except that Set PCO Phase frames shall be sent following the rules specified in
11.17.2.
1759
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
During the 40 MHz phase, a PCO active STA may act as though the HT Protection field were equal to no
protection mode, as defined in 10.26.3.1.
During the 20 MHz phase, a PCO active STA shall not transmit frames using a 40 MHz (HT or non-HT
duplicate) PPDU. The protection of a PCO active STA during the 20 MHz phase is the same as protection in
a 20 MHz BSS.
During the 20 MHz phase, a STA may transmit a 40 MHz mask PPDU that is not also a 40 MHz PPDU.
NOTE—This rule allows a STA to transmit 20 MHz PPDUs without requiring it to change to a 20 MHz transmit mask.
A PCO-capable AP may set the PCO Active field to 1 only if it is in a 20/40 MHz BSS.
NOTE—A non-PCO-capable 20/40 STA regards the PCO active BSS as a PCO inactive BSS. A non-PCO-capable
20/40 STA that associates with a PCO active BSS protects its transmissions as though the BSS were a PCO inactive
BSS.
The value indicated by the PCO Transition Time field in the HT Extended Capabilities field is measured
from the end of the PPDU carrying the Set PCO Phase frame. The PCO active STA shall be able to receive a
PPDU using the new channel width no later than the value specified by the PCO Transition Time field after
the end of the PPDU carrying the Set PCO Phase frame.
A VHT STA shall not transmit VHT PPDUs during a PCO 40 MHz phase.
11.17.2 Operation at a PCO active AP
A PCO-capable AP activates PCO if it decides that PCO active BSS is more appropriate than either PCO
inactive BSS or 20 MHz BSS in the current circumstances. The algorithm for making this decision is beyond
the scope of this standard.45
A PCO active AP shall set the PCO Active field in the HT Operation element to 1.
When a PCO active AP detects that PCO is not providing a performance benefit, the PCO active AP may
deactivate PCO and operate in either a PCO inactive BSS or 20 MHz BSS. A PCO-capable AP shall set the
PCO Active field in the HT Operation element to 0 when PCO operation is disabled. Since the AP advertises
the current mode in its Beacon and Probe Response frames, its associated STAs are informed of the mode
change.
Values of the PCO Transition Time field in the HT Extended Capabilities field from 1 to 3 indicate the
maximum time the PCO active STA takes to switch between a 20 MHz channel width and a 40 MHz
channel width. A PCO active AP may set the PCO Transition Time field to 0 when it requires the associated
PCO active STAs to be able to receive 40 MHz frames and respond with 40 MHz frames during the 20 MHz
phase.
The PCO active AP shall increase the value of the PCO Transition Time field if the PCO active AP accepts
the association of a PCO-capable STA whose value of the PCO Transition Time field exceeds the one
currently used by the PCO active AP. If the PCO active AP decides not to extend its transition time to meet
the value of the requesting STA, the PCO active AP shall deny the association. The AP may choose to
continue PCO when a non-PCO-capable 20/40 STA requests association, and in such cases, the PCO active
AP shall be able to receive 40 MHz frames and respond using 40 MHz frames during the 20 MHz phase.
45
A PCO-capable AP might consider the performance impact, e.g., throughput and jitter, caused by and given to STAs based on their
capabilities, traffic types, or load to determine the BSS’s PCO mode. STAs under consideration might be not only associated STAs but
also those that were detected in OBSSs.
1760
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A PCO active AP that indicates a switch to the 40 MHz phase by a PCO Phase field in a Beacon frame or by
a PCO Phase Control field in a Set PCO Phase frame and that transmits a nonzero value of the PCO
Transition Time field shall wait for at least the transition time specified by the PCO Transition Time field
before sending a CF-End frame in the 40 MHz channel to start the 40 MHz operating phase.
When switching to the 40 MHz phase, a PCO active AP indicates a NAV duration either in the CF
Parameter Set element of a Beacon frame or in the Duration/ID field of a Set PCO Phase frame sent on the
primary channel that shall protect up to the end of the intended 40 MHz phase plus a transition time. A PCO
active AP may continue the CFP after the 40 MHz phase by setting a longer duration for the CFP. The value
of the Duration/ID field in a CTS-to-self frame sent to protect a 40 MHz phase shall be set to protect up to
the intended end of the 40 MHz phase plus a transition time. The CTS-to-self frame shall be sent in a non-
HT duplicate PPDU. The transmission of the CTS-to-self frame shall be delayed until the secondary channel
CCA has indicated idle for at least a PIFS. It need not sense the primary channel because it is already
reserved by a Beacon frame or a Set PCO Phase frame.
If the PCO Transition Time field is nonzero, a PCO active AP shall start a timer with a timeout value equal
to the time specified by the PCO Transition Time field after transmitting a Beacon frame or a Set PCO Phase
frame. If this timer expires while attempting to reserve the secondary channel, the AP shall transmit a Set
PCO Phase frame indicating a switch back to the 20 MHz phase and shall transmit a CF-End frame on the
primary channel.
NOTE—If this timer expires while attempting to reserve the secondary channel, the AP abandons switching to the
40 MHz phase to avoid an unexpectedly long delay.
A PCO active AP may transmit a Set PCO Phase frame in a non-HT duplicate PPDU followed by a CF-End
frame in a 40 MHz HT PPDU to reserve both the primary and secondary channels again for the 40 MHz
phase or to extend the 40 MHz phase. The value of the Duration/ID field in a Set PCO Phase frame
contained in a non-HT duplicate PPDU for this intent shall protect up to the end of the intended 40 MHz
phase plus the transition time.
To start the 20 MHz phase, a PCO active AP shall send a Set PCO Phase frame in a 40 MHz HT PPDU or in
a non-HT duplicate PPDU with the Duration/ID field set to cover the transition time. It may also send a
CF-End frame in both primary and secondary channels following the Set PCO Phase frame, where a CF-End
frame in the primary channel shall be sent out at least after the transition time. The Duration/ID field of the
Set PCO Phase frame for this case shall cover the transition time plus the duration of a CF-End frame.
A PCO active AP may broadcast a Set PCO Phase frame to advertise the current PCO phase to PCO active
STAs.
Although PCO improves throughput in some circumstances, PCO might also introduce jitter. To minimize
the jitter, the maximum duration of 40 MHz phase and 20 MHz phase is dot11PCOFortyMaxDuration and
dot11PCOTwentyMaxDuration, respectively. Also in order for the PCO active AP to give opportunities for
each STA to send frames, the minimum duration of 40 MHz phase and 20 MHz phase is
dot11PCOFortyMinDuration and dot11PCOTwentyMinDuration, respectively.
11.17.3 Operation at a PCO active non-AP STA
If the PCO field in the Association Request frame to a PCO active AP is equal to 1 and the association
succeeds, the STA shall operate in PCO mode. When requesting association, a PCO-capable STA shall set
the PCO Transition Time field to 0 if the PCO active AP has set the PCO Transition Time field to 0. A PCO-
capable STA may attempt to associate with a transition time that is larger than one currently advertised by
the PCO active AP. If such an association fails, the PCO-capable non-AP STA may regard the BSS as a
PCO inactive BSS and may attempt an association as a non-PCO-capable 20/40 STA.
1761
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—A STA that does not support the PCO transition time indicated by an AP might still attempt association with
that AP. The AP will either refuse the association based on PCO transition time or respond by adjusting its PCO
transition time to suit the STA.
A PCO active non-AP STA may transmit a Probe Request frame to the associated PCO active AP to
determine the current PCO phase. A PCO active STA associated with a PCO active AP shall switch its
operating phase from 20 MHz channel width to 40 MHz channel width when it receives from its AP a
Beacon frame or a Probe Response frame that contains the PCO Phase field equal to 1 or a Set PCO Phase
frame with the PCO Phase Control field equal to 1. The value of the CFP DurRemaining field in the CF
Parameter Set element of a Beacon frame or the value of the Duration/ID field of a Set PCO Phase frame
shall be interpreted as the duration of the PCO 40 MHz phase.
A PCO active STA associated with a PCO active AP shall switch its operating phase from 40 MHz channel
width to 20 MHz channel width when it receives a Beacon frame or a Probe Response frame that contains
the PCO Phase field equal to 0 or a Set PCO Phase frame with the PCO Phase Control field equal to 0. It also
may switch from 40 MHz channel width to 20 MHz channel width based on the expiration of the value in the
Duration/ID field of a Set PCO Phase frame that indicated a 40 MHz phase or based on the expiration of the
value in the CFP DurRemaining field of the CF Parameter Set element of a Beacon frame that indicated a
40 MHz phase.
A PCO active STA shall halt PCO operation if it receives an HT Operation element from its AP with the
PCO Active field equal to 0.
NOTE—An HT STA might change its PCO capabilities by disassociating followed by associating with an AP.
11.18 20/40 BSS Coexistence Management frame usage
A STA that supports the 20/40 BSS Coexistence Management frame type shall set the 20/40 BSS
Coexistence Management Support field to 1 in transmitted Extended Capabilities elements.
A STA that supports the 20/40 BSS Coexistence Management frame type shall include an Extended
Capabilities element in transmitted Beacon, (Re)Association Request, (Re)Association Response, Probe
Request, and Probe Response frames.
A STA shall not transmit to another STA a 20/40 BSS Coexistence Management frame with an individual
address in the Address 1 field if the Extended Capabilities element from the recipient STA contained a value
of 0 in the 20/40 BSS Coexistence Management Support field. A STA that transmits a 20/40 BSS
Coexistence Management frame may set the Address 1 field to a group address.
NOTE—A 20/40 BSS Coexistence Management frame is a Class 1 frame and, therefore, can be sent to a STA that
supports reception of such frames and that is not a member of the same BSS as the transmitting STA. In such a case, the
BSSID of the frame is set to the wildcard BSSID value, regardless of whether the Address 1 field contains an individual
or group address value.
A STA may transmit a 20/40 BSS Coexistence Management frame that contains a value of 1 for the Request
Information field to another STA that supports the transmission of and reception of the 20/40 BSS
Coexistence Management frame, except when the frame is a response to a 20/40 BSS Coexistence
Management frame that contains a value of 1 for the Request Information field.
A non-VHT STA that receives a 20/40 BSS Coexistence element with the Information Request field equal
to 1, a value of the Address 1 field that matches the receiving STA using an individual address, and a
nonwildcard BSSID field that matches the STA’s BSS shall immediately queue for transmission a 20/40
BSS Coexistence Management frame with the transmitting STA as the recipient.
1762
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.19 RSNA A-MSDU procedures
When dot11RSNAActivated is true, a STA indicates support for payload protected A-MSDUs
(PP A-MSDUs) or signaling and payload protected A-MSDUs (SPP A-MSDUs) during (re)association. On
either (re)association, the associating STA and its peer STA both determine and maintain a record of
whether an encrypted A-MSDU sent to its peer is to be a PP A-MSDU or an SPP A-MSDU based on the
value of the SPP A-MSDU Capable and SPP A-MSDU Required subfields of the RSN Capabilities field of
the RSNE (see 9.4.2.25.4).
Table 11-12 defines behavior related to the transmission and reception of individually addressed A-MSDUs
of a first HT STA (STA1) that has successfully negotiated an RSNA (re)association with a second HT STA
(STA2). Reception and transmission of A-MSDUs using a non-RSN association is unaffected by the values
of the SPP A-MSDU Capable and SPP A-MSDU Required subfields.
Table 11-12—A-MSDU STA behavior for RSN associations
STA1 state STA2 state
SPP SPP SPP SPP STA1 action with respect to STA2
A-MSDU A-MSDU A-MSDU A-MSDU
capable required capable required
0 0 X 0 May transmit PP A-MSDU.
Shall not transmit SPP A-MSDU.
Shall receive PP A-MSDU.
Received SPP A-MSDU MIC fails.
0 0 X 1 Shall not transmit PP A-MSDU.
Shall not transmit SPP A-MSDU.
Shall discard received (PP and SPP) A-MSDU.
0 1 X X Shall not transmit PP A-MSDU.
Shall not transmit SPP A-MSDU.
Shall discard received (PP and SPP) A-MSDU.
1 0 0 0 May transmit PP A-MSDU.
Shall not transmit SPP A-MSDU.
Shall receive PP A-MSDU.
Received SPP A-MSDU MIC fails.
1 0 0 1 Shall not transmit PP A-MSDU.
Shall not transmit SPP A-MSDU.
Shall discard received (PP and SPP) A-MSDU.
1 X 1 X Shall not transmit PP A-MSDU.
May transmit SPP A-MSDU.
Received PP A-MSDU MIC fails.
Shall receive SPP A-MSDU.
1 1 0 X Shall not transmit PP A-MSDU.
Shall not transmit SPP A-MSDU.
Shall discard received (PP and SPP) A-MSDU.
NOTE—X = Not significant.
An AP may transmit an SPP A-MSDU for a GCR group address if it has successfully negotiated RSNA
(re)associations with all associated STAs that have an active GCR agreement for this group address.
1763
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.20 Public Action frame addressing
A STA that is a member of a BSS and that transmits an individually addressed Public Action frame to a STA
that is not a member of the same BSS shall set the BSSID field of the frame as follows:
— If the recipient STA is known to be a member of another BSS (including being an AP) and that
BSS’s BSSID is known, the BSSID field shall be set to the BSS’s BSSID or the wildcard BSSID
value.
— Otherwise, the BSSID field of the frame shall be set to the wildcard BSSID value.
A STA that is a member of a BSS and that transmits a group addressed Public Action frame shall set the
BSSID field of the frame to the BSS’s BSSID or the wildcard BSSID value.
A STA that is a member of a BSS and that transmits an individually addressed Public Action frame to a STA
that is a member of the same BSS shall set the BSSID field of the frame to the BSS’s BSSID.
A STA that is not a member of a BSS and that transmits a Public Action frame shall set the BSSID field of
the frame as follows:
— If the frame is individually addressed, the recipient STA is known to be a member of a BSS
(including being an AP), and that BSS’s BSSID is known, the BSSID field shall be set to the BSS’s
BSSID or the wildcard BSSID value.
— Otherwise, the BSSID field of the frame shall be set to the wildcard BSSID value.
11.21 STAs communicating Data frames outside the context of a BSS
When dot11OCBActivated is true in a STA:
a) Synchronization, authentication, association, and frame classes as defined in 11.1 and 11.3 are not
used. Data confidentiality as defined in Clause 12 is not used. The STA may send Action frames
and, if the STA maintains a TSF Timer, Timing Advertisement frames.
b) The STA may send Control frames, except those of subtype PS-Poll, CF-End, and CF-End +CF-
Ack.
c) The STA may send Data frames of subtype Data, Null, QoS Data, and QoS Null.
d) The STA shall set the BSSID field in all Management and Data frames to the wildcard BSSID value.
A STA with dot11OCBActivated equal to true shall not join or start a BSS.
Whenever MAC sublayer and PHY parameters are changed in a STA in which dot11OCBActivated is true,
MAC sublayer and PHY operation shall resume with the appropriate MIB attributes in less than 2 TU.
A STA shall use information from the CF Parameter Set element of all received Beacon frames, without
regard for the BSSID, to update its NAV as specified in 10.4.3.3.
11.22 Timing Advertisement
11.22.1 Introduction
A STA that sends a Timing Advertisement frame shall maintain a TSF Timer in order to set the Timestamp
field in this frame. When a STA transmits the Timing Advertisement, Probe Response, or Beacon frame, the
Timestamp shall be set to the value of the STA’s TSF timer at the time that the data symbol containing the
first bit of the Timestamp is transmitted to the PHY plus the transmitting STA’s delays through its local
PHY from the MAC-PHY interface to its interface with the WM (e.g., antenna).
1764
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA may advertise a time standard by transmitting a Timing Advertisement element in one of the
following frames: Timing Advertisement, Probe Response, or Beacon. As defined in 9.4.2.61 the Time
Advertisement element contains two estimates. The Time Value field contains an estimate of the difference
between a time standard and the timestamp included in the same frame. The Time Error field contains an
estimate of the standard deviation of the error in the estimate in the Time Value field. The time standard
might be derived from an external time source. A STA with an external time source might implement an
estimator in a variety of ways, which are beyond the scope of this standard.
11.22.2 Timing advertisement frame procedures
The SME provides the Time Advertisement element to the MLME when it requests the MLME to send a
Timing Advertisement frame. When a Timing Advertisement frame is received by a STA, its MLME reports
the Timestamp, Local Time, Time Advertisement element, and estimates of propagation delay to the SME.
For a STA that maintains a TSF Timer and receives a Timing Advertisement frame, Local Time is the value
of the STA’s TSF timer at the start of reception of the first octet of the Timestamp field of the frame.
Otherwise, the Local Time is unspecified. The receiving STA’s SME might use the Timestamp, Local Time,
and Time Advertisement element to align its estimate of the time standard to the transmitting STA’s estimate
of the corresponding time standard.
11.22.3 UTC TSF Offset procedures
When dot11UTCTSFOffsetActivated is true, the Time Advertisement and Time Zone elements shall be
included in all Probe Response frames, and the Time Advertisement element shall be included in the
Beacon frame every dot11TimeAdvertisementDTIMInterval DTIMs. When the
dot11UTCTSFOffsetActivated is false, the Time Advertisement and Time Zone elements shall not be
included in Beacon and Probe Response frames.
The AP should periodically synchronize to a UTC reference clock [B51] so that the UTC TSF offset can
account for drift. The AP shall increment the Time Update Counter field value in the Time Advertisement
element each time the synchronization occurs. The method the AP uses to synchronize with a UTC reference
clock is out of scope of the standard.
11.23 Tunneled direct-link setup
11.23.1 General
Tunneled direct-link setup (TDLS) is characterized by encapsulating setup frames in Data frames, which
allows them to be transmitted through an AP transparently. Therefore, the AP does not need to be direct-
link capable, nor does it have to support the same set of capabilities that are used on the direct link between
the two TDLS peer STAs. TDLS also includes power saving, in the form of TDLS peer PSM (scheduled)
and TPU (unscheduled). STAs that set up a TDLS direct link remain associated with their BSS, but have the
option of transmitting frames directly to the other TDLS peer STA.
Transmitting a TDLS frame through the AP means that the frame’s RA is set to the BSSID. Transmitting a
frame over the direct path means that the frame’s RA is set to the MAC address of the TDLS peer STA.
To set up and maintain a direct link, both TDLS peer STAs shall be associated with the same infrastructure
BSS.
A DMG STA shall not use the TDLS protocol.
A TDLS peer STA may be involved in direct links with multiple TDLS peer STAs at the same time.
Simultaneous operation of DLS and TDLS between the same pair of STAs is not allowed. A DLS Request
1765
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
frame shall not be transmitted to a STA with which a TDLS direct link is currently active. A DLS Request
frame received from a STA with which a TDLS direct link is currently active shall be discarded.
The channel on which the AP operates is referred to as the base channel. If the AP operates in a 40 MHz
channel, then the base channel refers to the primary channel. If the direct link is switched to a channel that is
not the base channel, then this channel is referred to as the off-channel.
Features, excluding PCO, that are not supported by the BSS but that are supported by both TDLS peer STAs
may be used on a TDLS direct link between those STAs. An example is the use of an HT MCS on a TDLS
direct link between HT STAs when these STAs are associated with a non-HT BSS. Features that are
supported by the BSS shall follow the BSS rules when they are used on a TDLS direct link on the base
channel. The channel width of a TDLS direct link on the base channel shall not exceed the channel width of
the BSS to which the TDLS peer STAs are associated, except when the TDLS Wider Bandwidth subfield in
the Extended Capabilities element of the TDLS Setup Request frame or the TDLS Setup Response frame is
1 for both TDLS peer STAs.
A VHT STA with a TDLS link that is not an off-channel direct link shall use as its primary channel the
primary channel or the only channel of its BSS. The channel width of a VHT TDLS link shall not be wider
than the maximum channel width supported by either the TDLS initiator STA or the TDLS responder STA.
A 160 MHz bandwidth is defined to be identical to an 80+80 MHz bandwidth (i.e., one bandwidth is not
wider than the other).
A STA shall not participate in a TDLS direct link with the same primary 80 MHz channel as the
infrastructure BSS or another TDLS direct link of the STA but with a different secondary 80 MHz channel.
When admission control is required for an AC on the base channel, then the TDLS peer STA that intends to
use this AC for direct-link transmissions on the base channel is responsible for setting up a TS with
Direction of ‘Direct Link’ with the AP, as defined in 10.22.4.2.
A non-AP STA may act as TDLS initiator STA or TDLS responder STA when
dot11TunneledDirectLinkSetupImplemented is true.
TDLS frames shall use the formatting as specified in 11.23.2 when they are transmitted through the AP and
when they are transmitted over the TDLS direct link. A STA shall not transmit a TDLS Action field in a
frame with the Type field of the frame set to Management. A received TDLS Action field in a frame with the
Type field equal to Management shall be discarded. Note that the TDLS Discovery Response frame is not a
TDLS frame but a Public Action frame.
TDLS shall not be used in an IBSS.
TDLS shall not be used in an MBSS.
Security is available on the TDLS direct link only when both TDLS peer STAs have an RSNA with the BSS.
TDLS shall not be used when the TDLS Prohibited subfield included in the Extended Capability element of
the Association Response frame or Reassociation Response frame that led to the current association is equal
to 1.
The HT Operation element shall be present in a TDLS Setup Confirm frame when both STAs are HT
capable.
1766
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The VHT Operation element shall be present in a TDLS Setup Confirm frame when both STAs are VHT
capable and the TDLS direct link is not established in the 2.4 GHz band. When the TDLS Setup Confirm
frame includes a VHT Operation element, the Basic VHT-MCS And NSS Set field is reserved.
11.23.2 TDLS payload
TDLS uses Ethertype 89-0d frames, as defined in Annex H. The TDLS payload contains a TDLS Action
field as is specified in 9.6.13. The UP shall be AC_VI, unless otherwise specified.
11.23.3 TDLS Discovery
To discover TDLS capable STAs in the same BSS, a TDLS initiator STA may send a TDLS Discovery
Request frame to an individual DA, through the AP. The TDLS responder STA Address field contained in
the Link Identifier element of the TDLS Discovery Request frame shall be set to the Destination Address of
the TDLS Discovery Request frame. A TDLS capable STA that receives a TDLS Discovery Request frame
with a matching BSSID in the Link Identifier element shall send a TDLS Discovery Response frame to the
requesting STA, via the direct path. The TDLS responder STA Address field contained in the Link Identifier
element of the TDLS Discovery Response frame shall be set to the MAC address of the STA sending the
TDLS Discovery Response frame. A TDLS Discovery Request frame shall not be sent within
dot11TDLSDiscoveryRequestWindow DTIM intervals after transmitting TDLS Discovery Request frame.
A TDLS STA may send an individually addressed TDLS Discovery Response frame via the direct path
without prior reception of a TDLS Discovery Request frame. A TDLS STA that receives such an unsolicited
TDLS Discovery Response frame may respond with an individually addressed TDLS Discovery Response
frame.
A TDLS Discovery Request frame shall not be sent to a group address. A TDLS Discovery Response frame
shall not be sent to a group address.
A TDLS STA may also send a TDLS Setup Request frame to a STA in the same BSS to discover whether
the TDLS peer STA is TDLS capable or not. A TDLS Setup Response frame transmitted in response to
TDLS Setup Request frame indicates that the TDLS peer STA sending the TDLS Setup Response frame is
TDLS capable.
An alternative mechanism to discover TDLS capable STAs in the same BSS, is provided by the TDLS
Capability ANQP-element, as described in 11.25.3.3.10. This mechanism allows the ANQP request/
response frames to use the direct path between the peer STAs.
11.23.4 TDLS direct-link establishment
To establish a TDLS direct link, the TDLS initiator STA shall send a TDLS Setup Request frame to the
intended TDLS responder STA.
TDLS Setup Request frames, TDLS Setup Response frames, and TDLS Setup Confirm frames shall be
transmitted through the AP and shall not be transmitted to a group address.
Upon receipt of a TDLS Setup Request frame, the following options exist at the TDLS responder STA:
a) The TDLS responder STA accepts the TDLS Setup Request frame, in which case the TDLS
responder STA shall respond with a TDLS Setup Response frame with status code SUCCESS.
b) The TDLS responder STA declines the TDLS Setup Request frame, in which case the TDLS
responder STA shall respond with a TDLS Setup Response frame with status code
REQUEST_DECLINED. A TDLS setup request shall be declined when the BSSID in the received
Link Identifier does not match the BSSID of the TDLS responder STA.
1767
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) The TDLS Setup Request frame is received after sending a TDLS Setup Request frame and before
receiving the corresponding TDLS Setup Response frame, and the source address of the received
TDLS Setup Request frame is higher than its own MAC address, in which case the TDLS responder
STA shall discard the frame and the TDLS responder STA shall send no TDLS Setup Response
frame.
d) The TDLS Setup Request frame is received after sending a TDLS Setup Request frame and before
receiving the corresponding TDLS Setup Response frame, and the source address of the received
TDLS Setup Request frame is lower than its own MAC address. In this case, the TDLS responder
STA shall terminate the TDLS setup it initiated. The TDLS responder STA shall send a response
according to item a) or item b) above in this case.
e) If a TDLS Setup Request frame is received from a TDLS responder STA with which a currently
active TDLS session exists, then the receiving STA shall tear down the existing TDLS direct link as
if a TDLS Teardown frame was received, and respond with a TDLS Setup Response frame.
If no TDLS Setup Response frame is received within dot11TDLSResponseTimeout, or if a TDLS Setup
Response frame is received with a status code not equal to SUCCESS, the TDLS initiator STA shall
terminate the setup procedure and discard the TDLS Setup Response frame. Otherwise, the TDLS initiator
STA shall send a TDLS Setup Confirm frame to the TDLS responder STA to confirm the receipt of the
TDLS Setup Response frame.
When the BSS does not support EDCA, EDCA may be used on the direct link (on the base channel and on
the off-channel), with the default EDCA Parameter Set, per 10.2.4.2.
If the STA has security enabled on the link with the AP, then the TPK handshake messages are included in
the TDLS Setup frames, as follows:
— TPK handshake message 1 shall be included in the TDLS Setup Request frame.
— TPK handshake message 2 shall be included in the TDLS Setup Response frame.
— TPK handshake message 3 shall be included in the TDLS Setup Confirm frame.
When the TDLS setup handshake has been completed, the TDLS initiator STA and the TDLS responder
STA are TDLS peer STAs. A TDLS peer STA shall accept Data frames received from the respective TDLS
peer STA directly and Data frames destined for the respective TDLS peer STA may be transmitted over the
direct link.
Subsequent to the successful completion of the TPK handshake, all frames transmitted and received on the
TDLS direct link shall be protected using the TPKSA, per the procedures defined in Clause 12.
To avoid possible reordering of MSDUs, a TDLS initiator STA shall cease transmitting MSDUs to the
TDLS responder STA through the AP after sending a TDLS Setup Request frame, and a TDLS responder
STA shall cease transmitting MSDUs to the TDLS initiator STA through the AP after sending a TDLS Setup
Response frame indicating status code SUCCESS.
The TDLS Setup Request frame and the TDLS Setup Response frame shall be transmitted using the lowest
AC that was used for transmitting MSDUs to the respective TDLS peer STA during the previous
dot11TDLSACDeterminationInterval seconds, or at AC_BK. When no MSDUs were transmitted during the
previous dot11TDLSACDeterminationInterval seconds, then the TDLS Setup Request frame and the TDLS
Setup Response frame may be sent at any AC, subject to applicable Admission Control rules.
If no TDLS Setup Response frame is received within dot11TDLSResponseTimeout, or if a TDLS Setup
Response frame is received with status code other than SUCCESS, the TDLS initiator STA may resume
transmitting MSDUs to the TDLS responder STA through the AP.
1768
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If a TDLS Setup Confirm frame is transmitted with a status code other than SUCCESS, the TDLS initiator
STA may resume transmitting MSDUs to the TDLS responder STA through the AP.
If a TDLS Setup Confirm frame is received with a status code other than SUCCESS, the TDLS responder
STA may resume transmitting MSDUs to the TDLS initiator STA through the AP.
A TDLS peer STA shall not transmit MSDUs over the direct link before transmitting or receiving a TDLS
Setup Confirm frame with status code SUCCESS.
11.23.5 TDLS direct-link teardown
To tear down a direct link, a TDLS peer STA shall send a TDLS Teardown frame to the respective TDLS
peer STA. A TDLS peer STA shall disable the direct link and delete the related security parameters after
successfully transmitting TDLS Teardown frame. If the STA has security enabled on the link with the AP,
then the FTE shall be included in the TDLS Teardown frame.
The TDLS Teardown frame shall be sent over the direct path and the reason code shall be set to
TDLS_UNSPECIFIED_REASON except when the TDLS peer STA is unreachable via the TDLS direct
link, in which case, the TDLS Teardown frame shall be sent through the AP and the reason code shall be set
to TDLS_PEER_UNREACHABLE. If the direct link is on an off-channel when this condition occurs, then
the TDLS peer STA may switch back to the base channel without initiating a channel switch frame
exchange, before transmitting the TDLS Teardown frame.
If present, the contents of the FTE in the TDLS Teardown frame shall be the same as that included in the
TPK handshake message 3 with the exception of the MIC field. The MIC shall be calculated on the
concatenation, in the following order, of:
— Link Identifier element
— Reason Code
— Dialog token that was used in the MIC calculation for TPK handshake message 3
— Transaction Sequence number (1 octet) which shall be set to the value 4
— FTE, with the MIC field of the FTE set to 0
The MIC shall be calculated using the TPK-KCK and the AES-128-CMAC algorithm. The output of the
AES-128-CMAC shall be 128 bits.
If the TPK handshake was successful for this TDLS session, then a receiving STA shall validate the MIC in
the TDLS Teardown frame prior to processing the TDLS Teardown frame; a TDLS Teardown frame in
which the MIC validation fails is called an invalid TDLS Teardown frame. A TDLS peer STA that receives
a TDLS Teardown frame that is not an invalid TDLS Teardown frame shall disable the direct link and delete
the related security parameters.
When a TDLS direct link gets torn down, any related TSs shall be deleted by the TDLS peer STAs.
A TDLS Teardown frame with Reason Code LEAVING_NETWORK_DEAUTH shall be transmitted to all
TDLS peer STAs (via the AP or via the direct path) prior to transmitting a Disassociation frame or a
Deauthentication frame to the AP. After receiving a Deauthentication frame or a Disassociation frame from
the AP, a Deauthentication frame with Reason Code LEAVING_NETWORK_DEAUTH shall be
transmitted via the direct path to all TDLS peer STAs that are in the awake state, if robust management
frame protection has not been negotiated on the TDLS direct link.
1769
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.23.6 TDLS channel switching
11.23.6.1 General
When a STA enables support for TDLS channel switching, it shall set dot11TDLSChannelSwitching-
Activated, dot11MultiDomainCapabilityActivated and dot11ExtendedChannelSwitchActivated to true.
When TDLS channel switching is enabled, the STA may set TDLS Channel Switching capability field to 1.
The STA shall include a Supported Channels element and a Supported Operating Classes element in all
TDLS Setup Request and TDLS Setup Response frames that have a TDLS Channel Switching capability
field equal to 1. The STA shall include only channels in the Supported Channels element for which it can
adhere to the local power constraint. A channel switch shall not be initiated by a STA when the TDLS peer
STA did not set the TDLS Channel Switching capability field to 1 in the transmitted TDLS Setup Request
frame or the TDLS Setup Response frame that caused the TDLS direct link to be set up.
TDLS Channel Switch Request frames and TDLS Channel Switch Response frames shall be transmitted
over the TDLS direct link.
TDLS channel switching is different from (I)BSS channel switching as defined in 11.9.8.
The target channel is the destination channel of an intended channel switch. The target channel is specified
by the STA that initiates a channel switch, from the set of operating classes supported by both TDLS peer
STAs. The target channel and operating class are specified in the TDLS Channel Switch Request frame. The
Country and Coverage Class settings on the target channel are the same as in the BSS to which both TDLS
peer STAs are currently associated. Both STAs are entitled to request a channel switch. The events
occurring for a channel switch are illustrated in Figure 11-31.
In Figure 11-31, the TDLS peer STAs (STA1 and STA2) are operating on an initial channel. After
contending for the medium, STA1 transmits a TDLS Channel Switch Request frame to STA2, via the direct
link, indicating a requested switch to a target channel. STA2 transmits an Ack frame (denoted ACK1 in
Figure 11-31) after SIFS, and processes the TDLS Channel Switch Request frame. After contending for the
medium, STA2 transmits a TDLS Channel Switch Response frame to STA1, possibly also after entering
power save mode with the AP. STA1 responds with an Ack frame (denoted ACK2 in Figure 11-31) after
SIFS. If the TDLS Channel Switch Response frame indicated with status code REQUEST_DECLINED,
then both STAs continue to operate on the current channel. If the TDLS Channel Switch Response frame
indicated with status code SUCCESS, then both STAs shall be listening on the target channel not later than
SwitchTime after the end of the last symbol of ACK2, as measured on the WM. After switching channels,
each TDLS peer STA shall perform a clear channel assessment (CCA) on the target channel, until a frame is
detected by which it can set its NAV, or until a period of time equal to at least dot11TDLSNavSync has
transpired (this combined event is indicated as “ProbeTime” in Figure 11-31). The first transmission on the
target channel shall be preceded by a random backoff, which shall start at the end of the ProbeTime. The
first transmission on the new channel shall not start before the end of SwitchTime. The initiator of the
channel switch shall transmit a Data frame on the target channel, unless the SwitchTimeout has expired or
the responder to the channel switch transmitted a Data frame on the target channel.
If no successful frame exchange has occurred on an off-channel within SwitchTimeout after the end of the
last symbol of ACK2, as measured on the WM, a STA shall go back to the base channel, where they shall be
listening not later than SwitchTime after the end of the SwitchTimeout. After changing channels (either
from the base channel to the off-channel or from the off-channel to the base channel), a TDLS peer STA
shall perform CCA until a frame is detected by which it can set its NAV, or until a period of time equal to
the ProbeTime has transpired.
1770
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 11-31—Events occurring for a TDLS direct-link channel switch
1771
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Both the TDLS Channel Switch Request frame and the TDLS Channel Switch Response frame shall contain
a Channel Switch Timing element. The SwitchTime and SwitchTimeout values in the TDLS Channel
Switch Timing element included in the TDLS Channel Switch Request frame shall specify the values
required at the STA sending the TDLS Channel Switch Request frame. The SwitchTime and SwitchTimeout
values specified in the TDLS Channel Switch Timing element included in the TDLS Channel Switch
Response frame shall meet the requirements at the STA sending the TDLS Channel Switch Response frame
and shall be equal to or larger than the values specified in the TDLS Channel Switch Request frame. The
timing parameters specified in the Channel Switch Timing element included in the TDLS Channel Switch
Response frame shall be used for the TDLS channel switching procedure. This procedure causes the larger
of the two switch times to become the value that is transmitted in the TDLS Channel Switch Response
frame.
The TDLS peer STA shall be in PS mode with the AP and shall not be involved in an active Service Period
with the AP before sending a TDLS Channel Switch Request frame or a TDLS Channel Switch Response
frame with Status Code set to SUCCESS. The TDLS peer STA that receives a TDLS Channel Switch
Request frame may enter PS mode with the AP prior to sending the TDLS Channel Switch Response frame.
Because there is at least a backoff between the TDLS Channel Switch Request frame and the TDLS Channel
Switch Response frame, there is a (small) probability that two STAs issue a TDLS Channel Switch Request
frame at more or less the same time. To reduce the probability for this event to occur, a TDLS peer STA
should not transmit a TDLS Channel Switch Request frame when a TDLS Channel Switch Request frame is
received and no TDLS Channel Switch Response has been transmitted in response. If a TDLS Channel
Switch Request frame is received from the TDLS peer STA to which a pending TDLS Channel Switch
Request frame was previously sent before receiving TDLS Channel Switch Response, the TDLS initiator
STA shall not reply to the TDLS Channel Switch Request frame and the TDLS responder STA shall reply to
the TDLS Channel Switch Request frame.
If a TDLS Channel Switch Response frame does not imply a channel switch because the STAs already are
on the requested channel, then the SwitchTime and ProbeTime may be skipped and both TDLS peer STAs
continue to operate on the requested channel. To cross means that a TDLS Channel Switch Request frame is
received from a peer STA after transmitting a TDLS Channel Switch Request frame to the TDLS peer STA,
instead of the expected TDLS Channel Switch Response frame.
When a TDLS peer STA does not receive an acknowledgment to a TDLS Channel Switch Response frame,
it may retransmit the frame but the number of retransmissions shall be lesser of the maximum retry limit and
dot11TDLSPeerSTAMissingAckRetryLimit.
A channel switch from an off-channel to the base channel may be accomplished by sending a TDLS Channel
Switch Response frame indicating the base channel as the target channel, without prior TDLS Channel
Switch Request frame. The Channel Switch Timing element shall be the same as contained in the Channel
Switch Response frame that caused the switch to the off-channel.
TDLS Channel Switching shall not be used when the TDLS Channel Switching Prohibited subfield included
in the Extended Capability element of the Association Response frame or Reassociation Response frame
that led to the current association is equal to 1.
11.23.6.2 General behavior on the off-channel
If dot11SpectrumManagementRequired is true, a TDLS peer STA shall not transmit a TDLS Channel
Switch request specifying an off-channel where radar detection is required, unless the STA has tested that
channel for the presence of radar, according to regulatory requirements. If a TDLS peer STA that is
operating in such a channel detects radar, the TDLS peer STA shall discontinue transmissions according to
regulatory requirements, and it shall send a TDLS Channel Switch Request frame indicating a switch to the
base channel. The channel switch avoids an interruption on the direct link.
1772
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The TDLS peer STA initiating the switch to the channel where radar detection is required by regulation shall
be the DFS owner.
The secondary channel of an existing 40 MHz network shall not be selected as an off-channel.
On an off-channel, the TDLS peer STAs remain associated with their BSS, so the BSSID remains the same.
It is recommended that in general TDLS STAs propose target channels that have no detectable medium
occupancy. If no such channel is available, then it is recommended that the TDLS STA propose a target
channel where beacons are detected but with little or no additional medium occupancy. It is further
recommended that TDLS STAs do not propose a target channel where the presence of beacons indicate that
ACM bits are set, unless little or no additional medium occupancy is detected.
11.23.6.3 Setting up a 40 MHz direct link
11.23.6.3.1 General
A 40 MHz off-channel direct link may be started if both TDLS peer STAs indicated 40 MHz support in the
Supported Channel Width Set field of the HT Capabilities element (which is included in the TDLS Setup
Request frame and the TDLS Setup Response frame).
Switching to a 40 MHz off-channel direct link is achieved by including the following information in the
TDLS Channel Switch Request frame:
— Operating Class field indicating 40 MHz Channel Spacing
— Secondary Channel Offset field indicating SCA or SCB
A 40 MHz off-channel direct link shall not be established in the 2.4 GHz band.
The TDLS peer STA initiating the switch to the 40 MHz off-channel shall be the DO.
11.23.6.3.2 Basic 40 MHz functionality
TDLS peer STAs may transmit 40 MHz PPDUs on a 40 MHz direct link. A TDLS peer STA shall not
transmit a 20 MHz PPDU in the secondary channel of its 40 MHz direct link.
11.23.6.3.3 Channel selection for a 40 MHz direct link
If a TDLS peer STA chooses to start a 40 MHz direct link that occupies the same two channels as an existing
40 MHz network (i.e., a 20/40 MHz BSSs or a 40 MHz direct link), then it shall select primary and
secondary channels of the new direct link that are identical to the primary and secondary channels of the
existing 40 MHz network, unless the TDLS peer STA discovers that on these two channels there are existing
40 MHz networks with different primary and secondary channels.
If a TDLS peer STA chooses to start a 40 MHz direct link, the selected secondary channel should
correspond to a channel on which no beacons are detected.
11.23.6.3.4 Switching from a 40 MHz to a 20 MHz direct link
Switching from a 40 MHz off-channel direct link to a 20 MHz off-channel direct link is established through
a TDLS channel switch. When on a 40 MHz off-channel direct link, a requested switch to a 20 MHz direct
link shall always be accepted.
1773
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.23.6.3.5 CCA sensing and NAV assertion in a 40 MHz direct link
When active on a 40 MHz direct link, a TDLS peer STA shall follow the CCA rules as defined in 11.16.9
and the NAV rules as defined in 11.16.10.
11.23.6.4 TDLS channel switching and power saving
A TDLS direct link shall not be switched to an off-channel during a TPU service period. While on an off-
channel, a TDLS peer STA shall not enter TPU power save mode.
A TDLS direct link may be switched to an off-channel when TDLS peer PSM is active on the link. The
wakeup windows occur on the off-channel in the same way they would have occurred had the STAs
remained on the base channel. Suspension of the wakeup windows implies a switch back to the base
channel.
11.23.6.5 Setting up a wide bandwidth off-channel direct link
11.23.6.5.1 General
A wideband off-channel TDLS direct link is a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz off-channel
TDLS direct link.
A wideband off-channel TDLS direct link may be started if both TDLS peer STAs indicated wideband
support in the VHT Capabilities element VHT Capabilities Information field included in the TDLS Setup
Request frame or the TDLS Setup Response frame.
Switching to a wideband off-channel direct link is achieved by including any of the following information in
the TDLS Channel Switch Request frame:
— An Operating Class element indicating 40 MHz Channel Spacing and a Secondary Channel Offset
element indicating SCA or SCB
— A Wide Bandwidth Channel Switch element indicating 80 MHz, 160 MHz, or 80+80 MHz channel
width
The operating class in TDLS Channel Switch Request frame shall have a value representing 5 GHz for the
channel starting frequency.
A TDLS peer STA that is extended spectrum management capable and that announces new TPC parameters
that come into effect at the same time as the switch to an off-channel direct link, shall include at least one
Transmit Power Envelope element in the transmitted the TDLS Channel Switch Request frame. The
recipient TDLS peer STA that is extended spectrum management capable and that has
dot11SpectrumManagementRequired or dot11RadioMeasurementActivated equal to true shall use the
parameters in these received element(s) in the recipient STA’s TPC calculations for the off-channel direct
link.
When announcing new operating classes or both a new operating class table index and new operating classes
that come into effect at the same time as the switch to the direct link and that express new regulatory
requirements, the TDLS peer VHT STA initiating the switch shall include a Country element in a
transmitted TDLS Channel Switch Request frame. The Country element shall contain all of the Operating
Classes for the off-channel direct link in Operating Triplet fields and zero Subband Triplet fields. The
Country element shall include one Operating Triplet field that contains the same Operating Class as the
Operating Class field in the same frame. The country indicated by the Country string in the TDLS Channel
Switch Request frame shall be equal to the country indicated by the Country string of the BSS.
The recipient TDLS peer VHT STA that has dot11MultiDomainCapabilityActivated,
1774
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11SpectrumManagementRequired, or dot11RadioMeasurementActivated equal to true shall use the
parameters in the received Country element in the TDLS Channel Switch Request frame in order to maintain
regulatory compliance.
The TDLS peer STA initiating the switch to the wideband off-channel shall be the DO on that channel.
11.23.6.5.2 Basic wideband functionality
TDLS peer STAs may transmit up to 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz PPDUs on a 40 MHz,
80 MHz, 160 MHz, or 80+80 MHz direct link, respectively. A TDLS peer STA shall not transmit a 20 MHz
PPDU in the nonprimary channel of its 80 MHz, 160 MHz, or 80+80 MHz direct link.
A TDLS peer STA shall not transmit a 40 MHz PPDU that does not use the primary 40 MHz channel of its
80 MHz, 160 MHz, or 80+80 MHz direct link. A TDLS peer STA shall not transmit an 80 MHz PPDU that
does not use the primary 80 MHz channel of its 160 MHz or 80+80 MHz direct link.
11.23.6.5.3 Channel selection for a wideband off-channel direct link
If a TDLS peer STA chooses to start a wideband direct link, the TDLS peer STA shall follow the primary
channel selection rules defined in 11.40.2 and 11.24.15 and the secondary 80 MHz channel rule defined in
11.23.1.
11.23.6.5.4 Switching from a wideband to a 20 MHz direct link
Switching from a wideband off-channel direct link to a 20 MHz off-channel direct link is established
through a TDLS channel switch. A STA operating on a wideband off-channel direct link shall accept a
requested switch to a 20 MHz direct link.
11.23.6.5.5 CCA sensing and NAV assertion in a 20 MHz, 40 MHz, 80 MHz, 160 MHz, or
80+80 MHz direct link
TDLS peer VHT STAs shall follow the CCA rules defined in 10.3.2.6, 10.22.2.7, and 10.22.3 and the NAV
rules defined in 11.40.5.
11.24 Wireless network management procedures
11.24.1 Wireless network management dependencies
When dot11WirelessManagementImplemented is true, the STA is a WNM STA and
dot11ExtendedChannelSwitchActivated and dot11RadioMeasurementActivated shall be true. This
subclause describes WNM procedures for requesting and reporting WNM capabilities between STAs that
support WNM procedures.
When dot11WirelessManagementImplemented is true, and one or more of bit 7 to bit 27 in the Extended
Capabilities element have the value 1, the Extended Capabilities element shall be included in Beacon
frames, Association Request and Response frames, Reassociation Request and Response frames, and Probe
Request and Response frames. When dot11WirelessManagementImplemented is true, for each bit 7 to bit 27
in the received Extended Capabilities element that is 0, a STA shall not request the corresponding feature
from the sending STA. A WNM STA receiving a request for a WNM feature from another STA shall reject
the request if the receiving WNM STA has not advertised support for the corresponding WNM feature.
1775
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.24.2 Event request and report procedures
11.24.2.1 Event request and event report
The Event Request and Event Report frames enable network real-time diagnostics. A STA whose
dot11EventsActivated is true shall support event requests and reports and shall set to 1 the Event field of the
Extended Capabilities elements that it transmits. If dot11EventsActivated is true, a STA shall log all
Transition, RSNA, peer-to-peer, and WNM log events, including the corresponding TSF, UTC Offset and
Event Time Error.
The STA log of events shall not be cleared as a result of BSS transitions. However, if the STA moves to a
different ESS or IBSS, the STA shall delete all event log entries.
A STA that supports event reporting may send an Event Request or Event Report frame to a STA within the
same infrastructure BSS or the same IBSS whose last received Extended Capabilities element contained a
value of 1 for the Event bit in the Extended Capabilities field; it shall not send an Event Request or Event
Report frame otherwise. If the STA receives an Event Request frame without error and it supports event
reporting, it shall respond with an Event Report frame that includes a value of the Dialog Token field that
matches the one in the Event Request frame.
The permitted source and destination STAs for an Event Request frame are shown in Table 11-9.
An AP may include zero or more Event Request elements in an Event Request frame. Each Event Request
element contains an Event Token that associates this Event Request with any subsequent Event Report
elements. When sending Event Report elements, a STA shall use the same Event Token that was included in
the original request.
Only a single Event Request frame from a STA is outstanding at a given STA at any time. If a STA that
supports event reporting receives a subsequent Event Request frame with a different dialog token before
completing the Event Report for the previous request from the requesting STA, the receiving STA may
respond to the most recent request frame; it shall not respond to a request frame that is not the most recent
one.
Upon a BSS transition, the STA shall cancel any event requests in the latest Event Request frame.
The Event Request elements can contain conditions that specify events to be reported and conditions that
establish event reporting when a STA experiences problems or failures. A STA sends an Event Request
frame containing one or more Event Request elements, each of which contains zero or more subelements.
Subelements are defined for each event type. A STA shall include in the corresponding Event Report
element only those events that meet the specified event conditions within the current ESS or IBSS.
In each Event Report element, a STA shall include a Status field that indicates the result of the event request/
report transaction. If the STA is able to return one or more Event Report elements, then the STA shall return
a value of “Successful” in the Event Report element. If the STA has no logged events of the requested type,
the STA shall return a value of Successful in the Event Report element without an event included in the
Event Report field. If the STA is unable to process the request at that time, the STA shall return a value of
“Request failed” in the Event Report element. If a STA refuses an event request, the STA shall return a value
of “Request refused” in the Event Report element. The reasons for refusing an event request are outside the
scope of this standard but may include reduced quality of service, unacceptable power consumption,
measurement scheduling conflicts, or other significant factors. If the STA is incapable of generating an
Event Report of the type specified in the Event Request frame, the STA shall return a value of “Request
incapable” indicating that the requester should not request again.
1776
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the Event Report elements do not fit into a single MMPDU, the reporting STA shall send the remaining
elements in additional Event Report frames until all Event Report elements have been returned to the
requesting STA. In any subsequent Event Report frame and for all remaining Event Report elements a
reporting STA shall include the same values of the Dialog Token and Event Token fields, respectively, that
was sent in the corresponding Event Request frame. When multiple MMPDUs are required, the non-AP
STA shall include complete Event Report elements and shall not fragment an element across multiple
MMPDUs.
A STA shall transmit both the Event Request frame and the Event Report frame only with an individually
addressed destination address. In an infrastructure BSS, only an AP shall transmit an Event Request frame to
a non-AP STA. An AP that supports event reporting shall discard received Event Request frames.
When a STA transmits an Event Request frame to another STA it shall indicate the types of events requested
by setting the Event Type field and shall indicate the maximum number of logged events to report by using
the Event Response Limit field in each included Event Request element. If the number of available logged
events of the requested type exceeds the Event Response Limit, the STA shall report an Event Response
Limit number of the most recent events. If there are no available logged events of the type specified in the
Event Request frame, the STA shall send the Event Report frame without any Event Report element. The
reporting STA shall send all available Event Report elements for the requested Event Type when the Event
Request field is not present in the Event Request element.
A STA may include a Destination URI element in the Event Request frame. The AP includes the URI in the
Destination URI element that the reporting non-AP STA may use to send Event Reports, upon the loss or
interruption of connectivity to the BSS.
On receipt of an Event Request frame with an Destination URI element, the reporting non-AP STA SME
may send the Event Report to the AP using the Destination URI with another network interface (if
available). The non-AP STA SME shall not send the Event Report to the URI contained in the Destination
URI element except after detecting loss of BSS connection.
The non-AP STA shall determine loss of connection to the AP that issued the Event Request frame when it
has not detected any Beacon frames from the AP for a period no less than the ESS Detection Interval.
If the BSS connection is reestablished to the AP that transmitted the Event Request frame, the non-AP STA
shall transmit the corresponding Event Report frame to the AP without using the Destination URI.
When the non-AP STA uses the Destination URI mechanism, it shall transport the Frame Body field of the
Event Report frame using the URI given in the Destination URI Element. An example use of the Destination
URI is given in Annex Q.
11.24.2.2 Transition event request and report
The Transition Event report provides information on the previous transition events for a given non-AP STA.
The Transition Event request and report are only permitted in the infrastructure BSS.
Each STA supporting the Transition Event shall log up to the last five Transition events occurring since the
STA associated to the ESS. A STA may log more than five of the most recent Transition events.
Upon receipt of an Event Request frame containing an Event Request element including a Transition Event
request, the non-AP STA shall respond with an Event Report frame that includes available Event Report
elements within the current ESS for the Transition event type.
Transition Event Request subelements are used to specify conditions for reporting of transition events. If
any Transition Event Request subelements are present in the Event Request frame, the reporting non-AP
1777
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA shall include in the Event Report frame only those available Transition Event Report elements that
meet the transition event reporting condition(s) specified in the Event Request frame. If no transition event
subelements are present in the Event Request field, the reporting STA shall include all available Transition
Event Report elements.
A Frequent Transition subelement in an Event Request frame defines conditions for frequent transition.
Frequent transition occurs when the number of BSS transitions exceeds the value of the Frequent Transition
Count Threshold within the indicated Time Interval value as defined in the Frequent Transition subelement
in 9.4.2.67.2. A STA that receives a Frequent Transition subelement shall, at each BSS transition, apply the
conditions for frequent transition to the log of transition events. If the logged transition events meet the
conditions for frequent transition, the STA shall send an Event Report frame including a Transition Event
Report element with Event Report Status set to Detected Frequent Transition and include in that Event
Report element the last logged transition event.
For transition logging and reporting purposes, the transition time is defined as the time difference between
the starting time and the ending time of a transition between APs, even if the transition results in remaining
on the same AP.
The starting time is one of the following items:
— The start of a search for an AP, when the transition reason is 4 (first association to WLAN).
— The latest time that a frame could have been transmitted or received on the source BSS.
— The start of a search for an AP, after determination that a transition has failed.
The ending time is one of the following items:
— The earliest time that a Data frame can be transmitted or received on the target BSS, after
completion of RSN, IEEE 802.1X, or other authentication and key management transmissions,
when such are required by the target BSS.
— The time that a determination is made that the transition has failed.
11.24.2.3 RSNA event request and report
The RSNA Event Report provides authentication events for a given non-AP STA. The RSNA Event Request
and Report are only permitted in an infrastructure BSS.
Each STA supporting the RSNA Event shall log up to the last five RSNA events occurring since the STA
associated to the ESS. A STA may log more than five of the most recent RSNA events.
Upon receipt of an Event Request frame containing an Event Request element including an RSNA Event
request, the non-AP STA shall respond with an Event Report frame that includes available Event Report
elements within the current ESS for the RSNA event type.
If an RSNA Event Request subelement is present in the Event Request field, the reporting non-AP STA shall
include available Event Report elements that meet the specified condition for the RSNA event type. If no
RSNA Event Request subelement is present in the Event Request field, the reporting STA shall include all
available RSNA Event Report elements.
11.24.2.4 Peer-to-peer link event request and report
The peer-to-peer link event report provides peer-to-peer connectivity events for a given non-AP STA. A
peer-to-peer event occurs when a peer-to-peer link is initiated or terminated.
1778
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Each STA supporting the peer-to-peer event shall log up to the last five peer-to-peer events occurring since
the STA associated to the ESS or IBSS. A STA may log more than five of the most recent peer-to-peer
events. When a link is initiated, a STA shall log and record the TSF time of the peer-to-peer event without a
connection time. When a peer-to-peer link is terminated, a STA shall log the peer-to-peer link event
including the connection time for the terminated link and shall delete from the log any initiation event for the
same peer-to-peer link.
Upon receipt of an Event Request frame containing an Event Request element including a peer-to-peer link
event request, the non-AP STA shall respond with an Event Report frame that includes available Event
Report elements within the current ESS or IBSS for the peer-to-peer event type. When a STA includes a
Peer-to-Peer Event Report element for a link initiation, the STA shall include a connection time for the event
report element which indicates the time difference from the event timestamp to the current time.
If a Peer-to-Peer Link Event Request subelement is present in the Event Request field, the reporting non-AP
STA shall include available Event Report elements that meet the specified condition for the Peer-to-Peer
event type. If no Peer-to-Peer Link Event Request subelements are present in the Event Request field, the
reporting STA shall include all available Peer-to-Peer Event Report elements.
11.24.2.5 WNM log event request and report
The WNM log event report is intended to capture PHY and MAC layer events related to the operation of
those layers in vendor-specific, human-readable (ASCII text) form. The WNM log is a general reporting
mechanism that can apply to configuration or monitoring behavior for PHY and MAC. The WNM log is
particularly useful for logging success or failure events across areas such as driver status, IEEE 802.11 or
IEEE 802.1X authentication, authorization, status changes while associated or unassociated.
For example:
<0>Oct 03 17:47:00 00:01:02:03:04:05 Adapter DLL Service initialized
<1>Oct 03 17:48:40 00:01:02:03:04:05 Authentication started
<1>Oct 03 17:48:46 00:01:02:03:04:05 IEEE 802.1X Authentication Failed, credential failure
<1>Oct 03 17:49:00 00:01:02:03:04:05 Authentication success
A non-AP STA that supports event reporting may be queried at any time for its current set of WNM log
messages. The WNM log messages returned by the non-AP STA may provide insight into the trouble being
experienced by non-AP STA.
Upon receipt of an Event Request frame containing an Event Request element including a WNM log event
request, the non-AP STA shall respond with an Event Report frame that includes WNM Log Event Report
elements.
11.24.2.6 Vendor Specific event request and report
The procedures for use of the Vendor Specific Event Request and Report are vendor specific and are not part
of this standard.
11.24.3 Diagnostic request and report procedures
11.24.3.1 Diagnostic request and diagnostic report
The Diagnostic Request and Diagnostic Report protocol provides a tool to diagnose and debug
complex network issues. A STA whose dot11DiagnosticsActivated is true shall support diagnostic reporting
and shall set to 1 the Diagnostics field of the Extended Capabilities elements that it transmits.
1779
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA that supports diagnostics reporting shall send a Diagnostics Request or Diagnostics Report frame to
a STA within the same infrastructure BSS or the same IBSS whose last received Extended Capabilities
element contained a value of 1 for the Diagnostics bit in the Extended Capabilities field; it shall not send a
Diagnostics Request or Diagnostics Report frame otherwise.
The Diagnostic Request frame contains a unique Dialog Token. A value of the Dialog Token field of 0 is a
reserved value and shall not be used. The source and destination of a Diagnostic Request frame shall both be
members of the same BSS. The permitted source and destination STAs for a Diagnostic Request frame are
shown in Table 11-9. A STA may include one or more Diagnostic Request elements in a Diagnostic Request
frame. Each Diagnostic Request element contains a unique Diagnostic Token that identifies the element
within the Diagnostic Request frame.
If a STA that supports diagnostic reporting receives a Diagnostic Request frame without error, the STA shall
respond with a Diagnostic Report frame that includes a value of the Dialog Token field that matches the one
in the Diagnostic Request frame. Each Diagnostic Report element that corresponds to the Diagnostic
Request element shall contain the same Diagnostic Token that was included in the original request.
Only a single Diagnostic Request frame from a STA is outstanding at a given STA at any time. If a STA
receives a subsequent Diagnostic Request frame with a different dialog token before completing the
Diagnostic Report for the previous request from the requesting STA, the STA shall respond to the most
recent Diagnostic Request frame; the STA shall not respond to a Diagnostic Request frame that is not the
most recent one.
All outstanding diagnostic requests, as indicated by received MLME-DIAGREQUEST.indication
primitives, are canceled upon a BSS transition, except when the BSS transition occurs as a result of
responding to or initiating a diagnostic request. All outstanding diagnostic requests, as indicated by received
MLME-DIAGREQUEST.indication primitives, are canceled after the time indicated in the Diagnostic
Timeout field, in the Diagnostic Request frame. When a STA that supports diagnostic reporting receives a
Diagnostic Request frame with a Diagnostic Request Type of Cancel Diagnostic Request, the STA cancels
all outstanding diagnostic requests, and discards all pending diagnostic reports, as indicated by received
MLME-DIAGREQUEST.indication primitives.
All Diagnostic Report elements shall include a Status field that indicates the overall result of the transaction.
If the STA is able to complete the diagnostic request made in the Diagnostic Request element, then a value
of “Successful” shall be returned. If the STA is unable to process the request at that time a value of “Fail”
shall be returned. If the STA is incapable of generating a report of the type specified, it shall return a value of
“Incapable.” If the STA cannot support the request for any other reason, the value of Refused shall be
returned.
A STA shall transmit both the Diagnostic Request frame and the Diagnostic Report frame with an
individually addressed destination address.
A STA may include a Destination URI element in the Event Request frame. The AP includes the URI in the
Destination URI element that the reporting non-AP STA may use to send Diagnostic Reports, upon the loss
or interruption of connectivity to the BSS.
On receipt of an Diagnostic Request frame with an Destination URI element, the reporting non-AP STA
SME may send the Diagnostic Report to the AP using the Destination URI with another network interface (if
available).
The non-AP STA shall determine loss of connection to the AP that issued the Diagnostic Request frame
when it has not detected any Beacon frames from the AP for a period no less than the ESS Detection
Interval.
1780
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the BSS connection is reestablished to the AP that transmitted the Diagnostic Request frame, the non-AP
STA shall transmit the corresponding Diagnostic Report frame to the AP without using the Destination URI.
When the non-AP STA uses the Destination URI mechanism, it shall transport the payload of the Diagnostic
Report frame using the URI given in the Destination URI Element. An example use of the Destination URI
is given in Annex Q.
If a non-AP STA that receives an Destination URI subelement in an Diagnostic Request fails to detect any
Beacon frames, belonging to the AP that issued the request for a Diagnostic report, for the period specified
by the ESS detection interval, it may use the URI specified in the Destination URI subelement to transport
the Diagnostic Report to the AP.
If the Diagnostic Report elements do not fit into a single MMPDU, the reporting STA shall send the
remaining elements in additional frames until all Diagnostic Report elements have been returned to the
requesting STA. A STA shall include the same values of the Dialog Token and Diagnostic Token fields that
were transmitted in the corresponding Diagnostic Request frame in each subsequent Diagnostic Report
frame and Diagnostic Report elements. When multiple MMPDUs are required, the STA shall include
complete Diagnostic Report elements and shall not fragment an element across multiple MMPDUs.
A STA that supports diagnostic reporting may cancel a previously sent Diagnostic Request frame for which
it has not yet received a Diagnostic Report frame by sending a Diagnostic Request frame with the Diagnostic
Request Type field value of 0, indicating “Canceled,” to the STA to which it previously sent the Diagnostic
Request frame. A STA that supports diagnostic reporting shall inform a STA from which it has previously
received a Diagnostic Request frame that the request has been locally canceled by sending a Diagnostic
Report frame with the Diagnostic Status field set to a value of 4, indicating “Canceled,” to the requesting
STA. In a Diagnostic Request frame with the Diagnostic Request Type field value of 0, and a Diagnostic
Report frame with the Diagnostic Status field set to a value of 4, no Diagnostic subelements are included in
the Diagnostic Request or Response element.
11.24.3.2 Configuration Profile report
The Configuration Profile report enables an AP to discover the current profile in use for an associated
device, and additional profiles for the current ESS. A non-AP STA that supports diagnostic reporting and
receives a Configuration Profile report request type shall respond with a Diagnostic Report frame that
includes all available Diagnostic elements allowed for the type.
Devices that support multiple configuration profiles for an ESS may include multiple Diagnostic Report
elements in a single Diagnostic Report frame (or multiple frames if required). Each Diagnostic Report
element shall contain a Profile ID element that uniquely identifies the configuration profile(s) for the current
ESS that are available on the device.
11.24.3.3 Manufacturer information STA report
The Manufacturer Information STA Report enables an AP to discover static manufacturer specific data
about an associated STA device. A non-AP STA that supports diagnostic reporting and receives a
Manufacturer Information STA Report request type shall respond with a Diagnostic Report frame that
includes all available Diagnostic elements allowed for the type.
When more than one Antenna Type/Antenna Gain pair is enabled, multiple Antenna Type subelements shall
be included in the Manufacturer Information STA Report Diagnostic Report element.
When more than one Collocated Radio Type, or Device Type is supported, multiple Collocated Radio Type
subelements, or Device Type subelements shall be included in the Manufacturer Information STA Report
1781
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Diagnostic Report element. If the existence or the type of collocated radio is unknown, no Collocated Radio
Type subelements shall be included.
11.24.3.4 Association diagnostic
The purpose of the association diagnostic is to determine that a STA is able to associate with a designated
BSS. This test directs an association to be completed with a specific AP.
To initiate the test, an AP that supports diagnostic reporting shall send a Diagnostic Request frame
containing a Diagnostic Request Type field set to 3 (i.e., Association Diagnostic) to a STA that supports
diagnostic reporting. The AP shall not send an association diagnostic request with a designated BSS that is
not part of the ESS and the STA receiving an association diagnostic request shall reject requests to perform
diagnostics on a BSS that is not part of the ESS. All parameters required to complete the association are
included in the Diagnostic Request element.
Upon receipt of the Diagnostic Request frame containing a Diagnostic Request element specifying an
association request, the STA determines whether to accept the request. If the STA declines the request, it
shall send a Diagnostic Report frame with the Status field of a Diagnostic Report element set to Refused. If
the STA accepts the request, it shall cause an authentication to occur to the AP indicated in the Diagnostic
Request element and the STA’s SME shall issue an MLME-DIAGREPORT.request primitive, indicating the
results of the diagnostic.
One means to cause an authentication to occur is for the STA’s SME to issue an MLME-
DEAUTHENTICATE.request primitive to deauthenticate from the current AP, and an MLME-
AUTHENTICATE.request primitive to authenticate to the AP indicated in the Diagnostic Request element.
If successful, the STA shall issue an MLME-(RE)ASSOCIATE.request primitive to associate with the AP
indicated in the Diagnostic Request element. If successful, the STA’s SME shall then issue an MLME-
DEAUTHENTICATE.request primitive to deauthenticate from the AP indicated in the Diagnostic Request
element, reassociate with the AP from which it received the Diagnostic Request, and issue an MLME-
DIAGREPORT.request primitive, indicating the results of the diagnostic.
11.24.3.5 IEEE 802.1X authentication diagnostic
The purpose of the IEEE 802.1X authentication diagnostic is to determine that the STA is able to complete
an IEEE 802.1X authentication with a designated BSS. This test directs an association and IEEE 802.1X
authentication to be completed with a specific AP. If a STA that supports diagnostic reporting also supports
RSN, the STA shall support the IEEE 802.1X authentication diagnostic.
To initiate the test, an AP that supports diagnostic reporting shall send a Diagnostic Request frame
containing a Diagnostic Request Type field set to 4 (i.e., IEEE 802.1X Authentication Diagnostic) to a STA
that supports diagnostic reporting. A STA that supports diagnostic reporting in an IBSS or an AP that
supports diagnostic reporting shall not send an IEEE 802.1X authentication diagnostic request with a
designated BSS that is not part of the ESS, or IBSS and a STA that supports diagnostic reporting which
receives a diagnostic request shall reject requests to perform diagnostics on other networks. The AP, EAP
method and credential type values included in the AP Descriptor, EAP Method and Credential Type
subelements in the Diagnostic Request element shall be used to complete the association and IEEE 802.1X
authentication.
Upon receipt of the Diagnostic Request frame containing a Diagnostic Request element specifying an
IEEE 802.1X Authentication Diagnostic request, the STA determines whether to accept the request. If the
STA declines the request, it shall send a Diagnostic Report frame with the Status field of a Diagnostic
Report element set to Refused. If the STA accepts the request, it shall cause an IEEE 802.1X authentication
to occur to the AP indicated in the Diagnostic Request element and the STA’s SME shall issue an MLME-
DIAGREPORT.request primitive indicating the results of the diagnostic.
1782
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
One means to cause an authentication to occur is for the STA’s SME to issue an MLME-
DEAUTHENTICATE.request primitive to deauthenticate from the current AP, and an MLME-
AUTHENTICATE.request primitive to authenticate to the AP indicated in the Diagnostic Request element.
If successful, the STA shall issue an MLME-(RE)ASSOCIATE.request primitive to the AP indicated in the
Diagnostic Request element. If (re)association succeeds, the STA shall try to complete IEEE 802.1X
authentication using parameters specified in the Diagnostic Request element. The STA shall then issue an
MLME-DEAUTHENTICATE.request primitive to deauthenticate from the AP indicated in the Diagnostic
Request element, reassociate with the AP from which it received a diagnostic request, and issue an MLME-
DIAGREPORT.request primitive, indicating the results of the diagnostic.
11.24.4 Location track procedures
11.24.4.1 Location track configuration procedures
A STA whose dot11LocationTrackingActivated is true shall support location tracking and shall set to 1 the
Location field of the Extended Capabilities elements that it transmits.
In an infrastructure BSS, a non-AP STA shall not transmit Location Configuration Request frames.
A STA that supports location may configure another STA to transmit Location Track Notification frames for
the purpose of tracking the receiving STA’s location by sending Location Indication Channels, Location
Indication Interval and Location Indication Broadcast Data Rate subelements in a Location Parameters
element in a Location Configuration Request frame. The minimum Normal and In-Motion Report Interval in
a Location Configuration Request frame is 500 ms.
A STA may transmit the Location Configuration Request frame as a broadcast or individually addressed
frame. A STA that supports location and receives a broadcast Location Configuration Request frame shall
send a Location Configuration Response frame if the STA does not accept the parameters included in the
Location Configuration request; the STA shall not send a Location Configuration Response frame if it
accepts the parameters included in the Location Configuration request.
A STA that supports location and receives an individually addressed Location Configuration Request frame
shall respond with a Location Configuration Response frame. Upon reception of a new Location
Configuration Request frame, the STA shall override any information from a previously received Location
Configuration Request frame with the new frame. If all Location Parameter subelements included in the
Location Configuration Request frame are successfully configured on the receiving STA, then the STA shall
include in the Location Configuration Response frame a single Location Status subelement indicating
success. Upon successful configuration, the receiving STA shall start transmitting the Location Track
Notification frames based on the Location Configuration Request frame parameters, as described in
11.24.4.2. If one or more Location Parameter subelements are unsuccessfully configured, then the STA shall
include in the Location Configuration Response frame a Location Status subelement for each failed
subelement indicating the subelement ID, the status value and the corresponding Location Parameter
subelement as described in the paragraphs that follow.
The Location Status subelement has four possible status values: Success, Fail, Refused and Incapable. When
the requesting STA receives a Location Configuration Response frame with Location Status indicating
anything other than Success, the requesting STA shall assume the original request was not processed and no
configuration took effect on the receiving STA and the requesting STA should take appropriate action based
on the status value returned.
1783
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For Location Status Fail:
— If the receiving STA has been configured successfully prior to the current Location Configuration
Request and continues to transmit Location Track Notification frames based on those parameters,
the STA shall respond with its current Location Parameters subelements values.
— If the STA has no previously configured value, the STA shall respond with its minimum Location
Parameters subelements that it is capable of supporting.
— The configuring STA may either retry the original request or send an alternate request.
For Location Status Incapable:
— The STA responding to the configuration request may include the minimum Location Parameters
subelements that it is capable of supporting.
— The configuring STA shall not send another configuration request matching the previous
configuration request while the reporting STA is associated to the same BSS.
— The configuring STA may send an alternate request.
For Location Status Refuse:
— The STA responding to the configuration request may include the minimum Location Parameters
subelements that it is capable of supporting.
— The configuring STA may send an alternate request.
The location configuration methods, from highest to lowest precedence, are as follows: 1) an individually
addressed Location Configuration Request frame, 2) broadcast Location Configuration Request frame.
When a STA receives a new Location Configuration frame at the same or higher precedence than the
previous it shall cancel the previous configuration and begin using the newest configuration.
The Location Indication Broadcast Data Rate subelement included in Location Configuration Request
frames indicates the target data rate at which the STA shall transmit Location Track Notification frames.
The Location Indication Broadcast Data Rate included in the Location Configuration Request frame should
be a data rate defined in the basic data rate set.
The Indication Multicast Address field configured in the Location Indication Parameters subelement shall be
a multicast locally administered IEEE MAC address as defined in IEEE Std 802 that is shared across all APs
in the same ESS. The STA shall transmit Location Track Notification frames to the Indication Multicast
Address with the BSSID field set to the wildcard BSSID. An AP shall discard Location Track Notification
frames that are not addressed to the Indication Multicast Address field configured for the ESS.
A non-AP STA shall terminate the transmission of Location Track Notification frames for any of the
following reasons:
— The non-AP STA receives a Location Configuration Request frame from the STA to which it is
currently associated that includes a Location Parameters element with a Location Indication
Parameters subelement specifying an interval of 0.
— The non-AP STA fails to detect any Beacon frames, belonging to the same ESS that originally
configured the non-AP STA, for the period specified by the essDetectionInterval value included in
the Location Parameters element transmitted in the Location Configuration Request frame.
— dot11LocationTrackingActivated is false.
— The non-AP STA is disassociated for any reason from the ESS that configured it, including power
off, or is configured by a different ESS.
— In an IBSS when the STA detects that it is no longer connected to the other STA that formed the
IBSS.
1784
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—All Public Action frames, including the Location Track Notification frames, are Class 1 frames and the
treatment of Public Action frames upon reception by STAs is defined in 11.3.
11.24.4.2 Location track notification procedures
Implementation of location track notification is optional for a WNM STA. A STA that implements location
track notification has dot11LocationTrackingImplemented equal to true. When
dot11LocationTrackingImplemented is true, dot11WirelessManagementImplemented shall be true. A STA
in which dot11LocationTrackingActivated is true is defined as a STA that supports location track
notification. When location track notification is supported, a STA configured by another STA as described
in the previous subclause shall transmit Location Track Notification frames as shown in the informative
diagram in Figure 11-32.
Normal Transmit Interval
Channel 1
Normal
Number of
Frames per Burst
Channel Interframe
or “burst” Interval
Channel 6
Channel 11
Figure 11-32—STA transmission on three channels, three frames per channel with
Normal Report Interval
Implementation of Motion Detection or the Time of Departure reporting is optional for a WNM STA. A
STA that implements motion detection shall set dot11MotionDetectionImplemented to true. When
dot11MotionDetectionImplemented is true, dot11WirelessManagementImplemented shall be true. A STA
whose dot11MotionDetectionActivated is true shall support motion detection. A STA that implements the
time of departure capability shall set its dot11TODImplmented to true. When dot11TODImplemented is
true, dot11WirelessManagementImplemented shall be true. A STA whose dot11TODActivated is true shall
support time of departure for location tracking.
The STA transmits Location Track Notification frames based on the following parameters and procedures
described in 11.24.4.1:
a) Location Indication Channels. This subelement indicates the channels on which the STA shall
transmit Location Track Notification frames.
b) Indication Multicast Address
1) A non-IBSS STA shall transmit the Location Track Notification frames to the Indication Multi-
cast Address field in the Location Indication Parameters subelement configured by the Loca-
tion Configuration Request frame.
2) An AP shall discard any Location Track Notification frame received from a STA that does not
match the Indication Multicast Address field value for the AP’s ESS.
1785
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
3) An IBSS STA shall transmit the Location Track Notification frames to the destination address
of the STA that configured the STA using Location Configuration Request frames.
c) Location Indication Interval
1) When the STA is stationary or dot11MotionDetectionActivated is false, the STA shall transmit
a sequence of groups of Location Track Notification frames on each channel. Each group of
frames shall contain Normal Number of Frames Per Channel field frames. The first frame in
each group of Location Track Notification frames shall be separated from the first frame in the
previous group of Location Track Notification frames by a minimum time duration indicated
by the value of the Normal Report Interval field times the value of the Normal Report Interval
Units field.
2) When the STA is in motion and dot11MotionDetectionActivated is true, the STA shall transmit
a sequence of groups of Location Track Notification frames on each channel. Each group of
frames shall contain In-Motion Number of Frames Per Channel field frames. The first frame in
each group of Location Track Notification frames shall be separated from the first frame in the
previous group of Location Track Notification frames by a minimum time duration indicated
by the value of the In-Motion Report Interval times the value of the In-Motion Report Interval
Units field.
3) If a STA is configured to transmit on multiple channels, the STA shall transmit the frames on a
single channel before continuing onto the next channel in the configured list of channels.
4) All Location Track Notification frames transmitted on a single channel shall be transmitted
with a minimum gap specified by the Burst Interframe Interval field.
5) A STA can never be stationary and in-motion at the same time, and therefore only the Normal
Interval field or the In-Motion Interval field apply at any given moment.
d) Tracking Duration
1) The STA shall transmit Location Track Notification frames until the Tracking Duration
duration is reached.
2) The duration starts as soon as the STA sends a Configuration Location Response frame with a
Location Status value of Success.
3) If the Tracking Duration is a nonzero value the STA shall transmit Location Track Notification
frames, based on the Normal and In-Motion Report Interval field values, until the duration ends
or is configured to terminate transmission as described in 11.24.4.1.
4) If the Tracking Duration is 0 the STA shall continuously transmit Location Track Notification
frames as defined by Normal and In-Motion Report Interval field values until configured to
terminate transmission as described 11.24.4.1.
e) ESS Detection
1) The ESS Detection Interval field is specified in the Location Indication Parameters subelement
configured by the Location Configuration Request frame. The ESS Detection Interval defines
how often the STA should check for beacons transmitted by one or more APs belonging to the
same ESS that configured the STA.
2) If no beacons from the ESS are received during this interval, the STA shall terminate
transmission of Location Track Notification frames.
f) Location Indication Options
1) The RM Enabled Capabilities element contained in (Re)Association Request frames indicates
the STA’s ability to perform radio measurements as described in 9.4.2.45. The Location
Indication Options subelement Options Used field Beacon Measurement Mode Used bit shall
be set to 0 by the AP when the RM Enabled Capabilities element bits (defined in Table 9-157),
Beacon Passive Measurement Capability Enabled, Beacon Active Measurement Capability
Enabled and Beacon Table Measurement Capability Enabled are all set to 0. If any of RM
Enabled Capabilities element bits Beacon Passive Measurement capability enabled, Beacon
Active Measurement Capability Enabled or Beacon Table Measurement Capability Enabled are
1786
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
equal to 1 then the Location Indication Options subelement Options Used field Beacon
Measurement Mode Used bit may be set to 1.
2) If the Location Indication Options subelement is included and the Options Used field with the
Beacon Measurement Mode Used bit equal to 1 in the most recently received Location
Configuration Request frame, the STA shall include in the Location Track Notification frames,
the result of the most recent successful beacon measurement that was performed using the
requested Beacon Measurement Mode contained in the Location Indications Options
subelement.
3) If the STA has never performed a successful beacon measurement using the requested Beacon
Measurement Mode prior to transmission of the Location Track Notification frame, the STA
shall perform the beacon measurement using the requested Beacon Measurement Mode and
include the results of that measurement in Location Track Notification frames.
4) After a successful Location Configuration Request frame that included the Location Indication
Options subelement and Options Used field with Beacon Measurement Mode Used bit equal to
1, a STA should continue to perform beacon measurement as defined by the Beacon Measure-
ment Mode periodically. How often and under what circumstances the STA performs this mea-
surement is out of scope of this standard.
5) Whenever a STA includes the beacon measurement in the Location Track Notification frames,
the STA shall set the Measurement Token field in the Measurement Report element to the same
value as the Dialog Token field in the Location Configuration Request frame that initiated the
transmission of the location track notification frames by the STA.
6) If the Location Indication Options subelement is not included in the most recently received
Location Configuration Request frame or the Location Indication Options subelement is
included with the Options Used field with Beacon Measurement Mode Used bit equal to 0, the
STA shall not include any beacon measurements in the Location Track Notification frame
g) Location Indication Broadcast Data Rate. The STA shall transmit Location Track Notification
frames at the data rate specified in this subelement.
h) Time of Departure
1) If dot11TODActivated is true, the STA shall transmit this subelement in the Location Track
Notification frame.
2) In all location tracking frames transmitted by a STA following a successful configuration, the
Time of Departure subelement TOD Clock Rate field shall be set to the same value.
3) If the STA has multiple antennas, it shall transmit using an approximation to an
omnidirectional pattern.
NOTE—The values of the fields in the Time of Departure subelement are measured by the PHY in real time, then passed
without real-time requirements to the MAC via the TXSTATUS parameter of the PHY-TXSTART.confirm primitive.
The diagram in Figure 11-32 shows an example of Location Track Notification frame transmission, for a
STA configured to transmit on three channels, with three frames per channel. In this example, a Normal
Transmit Interval and Normal number of frames per channel are shown. When a STA is capable of motion
detection and is in motion, the In-Motion Report Interval and In-Motion number of frames per channel
would apply.
11.24.5 Timing measurement procedure
Implementation of timing measurement is optional for a WNM STA. A STA in which
dot11TimingMsmtActivated is true is defined as a STA that supports timing measurement.
A STA in which dot11TimingMsmtActivated is true shall set the Timing Measurement field of the Extended
Capabilities element to 1.
1787
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA in which dot11TimingMsmtActivated is false shall set the Timing Measurement field of the
Extended Capabilities element to 0.
A STA that supports the timing measurement procedure may transmit a Timing Measurement Request frame
to a peer STA to request it to initiate or to stop an ongoing timing measurement procedure, depending on the
value of the Trigger field in the request frame. See Figure 11-33.
t1 = ToD(M)
Action frame M contains: t2 = ToA (M)
Dialog Token = n
Follow On Dialog Token = 0 t3 = ToD(Ack)
t4 = ToA(Ack)
Action frame M Contains: t1 and t4 are known
Dialog Token = m (0, n)
Follow On Dialog Token = n
ToD Timestamp = t1 SME at receiving STA estimates
TOA Timestamp = t4 offset of the local clock relative to that
at sending STA using:
[(t2 – t1) – (t4 – t3)]/2
.
.
Sending Receiving
STA . STA
Figure 11-33—Timing measurement procedure
A STA that supports the timing measurement procedure may transmit Timing Measurement frames
addressed to a peer STA that also supports the timing measurement procedure. One higher-layer protocol for
synchronizing a local clock time between STAs using this feature is specified in IEEE Std 802.1AS.
For non-DMG STAs, both the Timing Measurement frame and the corresponding Ack frame shall be
transmitted using a single transmit chain.
A sending STA transmits Timing Measurement frames in overlapping pairs. The first Timing Measurement
frame of a pair contains a nonzero value in the Dialog Token field. The follow up Timing Measurement
frame contains a Follow Up Dialog Token field set the value of the Dialog Token field in the first frame of
the pair. With the first Timing Measurement frame, both STAs capture timestamps. The sending STA
captures the time at which the Timing Measurement frame is transmitted (t1). The receiving STA captures
the time at which the Timing Measurement frame arrives (t2) and the time at which the Ack frame response
is transmitted (t3). The sending STA captures the time at which the Ack frame arrives (t4). See Figure 6-16
in 6.3.57. In the follow up Timing Measurement frame, the sending STA transfers the timestamp values it
captured (t1 and t4) to the receiving STA.
1788
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—A Timing Measurement frame can contain nonzero values in both the Dialog Token and Follow Up Dialog
Token fields, meaning that the Action frame contains follow up information from a previous measurement, and new
Timestamp values are captured to be sent in a future follow up Timing Measurement frame.
The offset of the clock at the receiving STA with respect to the clock at the sending STA is calculated using
Equation (11-4) (assuming a symmetric wireless channel). See Figure 6-16 in 6.3.57.
Clock offset at receiving STA relative to sending STA = [(t2 – t1) – (t4 – t3)]/2 (11-4)
NOTE—An example of state machines and other computations for synchronizing a local clock time between
IEEE 802.11 STAs using the values of t1, t2, t3, and t4 provided by the Timing Measurement feature is found in
Clause 12 of IEEE Std 802.1AS.
The acknowledgment procedure for Timing Measurement frames is the same as that for other Management
frames (see 10.3.2.9). If the Ack frame for a transmitted Timing Measurement frame is not received, the
sending STA may retransmit the frame. The sending STA shall capture a new set of timestamps for the
retransmitted frame and its Ack frame.
On receiving a Timing Measurement frame with a Dialog Token for which timestamps have previously been
captured, the receiving STA shall discard previously captured timestamps and capture a new set of
timestamps.
11.24.6 Fine timing measurement (FTM) procedure
11.24.6.1 Overview
The FTM procedure allows a STA to determine its distance from another STA. In order for a STA to obtain
its location, the STA may perform this procedure with multiple STAs whose locations are known.
An FTM session is an instance of a FTM procedure between an initiating STA and a responding STA along
with the associated scheduling and operational parameters of that instance (see 9.4.2.168). An FTM session
is composed of a negotiation, measurement exchange and termination. A STA might have multiple
concurrent FTM sessions. Concurrent FTM sessions might occur with responding STAs that are members of
different BSSs and possibly different ESSs, or possibly outside of a BSS, each session using its own
scheduling, channel and operational parameters.
A responding STA might be required to establish overlapping FTM sessions with a large number of
initiating STAs (e.g., an AP providing measurements to STAs at a mall or a store). On the other hand, an
initiating STA might have multiple ongoing FTM sessions on the same or different channels with different
responding STAs, while being associated with an AP for the exchange of data or signaling.
To support the constraints of both the initiating and responding STAs, during the negotiation phase the
initiating STA initially requests a preferred periodic time window allocation. The responding STA
subsequently responds by accepting or overriding the allocation request based on its resource availability
and capability.
Since some of the initiating STA’s activities may be nondeterministic and might have higher precedence
than the FTM session (e.g., data transfer interaction with an associated AP), a conflict might prevent the
initiating STA from being available at the beginning of the burst instance determined by the responding
STA.
Figure 11-34 shows an example of such scheduling conflicts.
1789
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Responding STA 1 Responding STA 2
Initiating STA
Channel A Channel B
Legend:
Scheduled burst instance
Conflicting duration of
burst instances
FTM Frame exchange
Figure 11-34—Concurrent FTM sessions
The initiating STA in Figure 11-34 establishes sessions with responding STA 1 and responding STA 2 on
different channels. The sessions’ burst instance periodicity might be different as well as the STAs’ clock
offsets and thus, over time, some temporal conflicts may occur. To overcome this, during each burst instance
the initiating STA indicates its availability by transmitting a Fine Timing Measurement Request frame (see
11.24.6.4). During each burst instance, the responding STA transmits one or more Fine Timing
Measurement frames as negotiated.
11.24.6.2 FTM capabilities
Implementation of FTM is optional for a WNM STA. A STA in which
dot11FineTimingMsmtRespActivated is true is defined as a STA that supports FTM as a responder. A STA
in which dot11FineTimingMsmtInitActivated is true is defined as a STA that supports FTM as an initiator.
When dot11FineTimingMsmtRespActivated is true, dot11WirelessManagementImplemented shall be true.
When dot11FineTimingMsmtInitActivated is true, dot11WirelessManagementImplemented shall be true.
A STA in which dot11FineTimingMsmtRespActivated is true shall set the Fine Timing Measurement
Responder field of the Extended Capabilities element to 1.
1790
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA in which dot11FineTimingMsmtInitActivated is true shall set the Fine Timing Measurement Initiator
field of the Extended Capabilities element to 1.
A STA in which dot11FineTimingMsmtRespActivated is false shall set the Fine Timing Measurement
Responder field of the Extended Capabilities element to 0.
A STA in which dot11FineTimingMsmtInitActivated is false shall set the Fine Timing Measurement
Initiator field of the Extended Capabilities element to 0.
11.24.6.3 Fine timing measurement procedure negotiation
In order to initiate a FTM procedure, a STA that supports the FTM procedure as an initiator (referred to as
an initiating STA) shall transmit a Fine Timing Measurement Request frame. This frame is called the initial
Fine Timing Measurement Request frame. After transmission of this frame, the initiating STA shall be ready
to receive a Fine Timing Measurement frame.
A STA that supports the FTM procedure as a responder (referred to as a responding STA) shall not transmit
Fine Timing Measurement frames addressed to a peer STA unless the responding STA has received an
initial Fine Timing Measurement Request frame from the peer STA.
The initial Fine Timing Measurement Request frame shall have:
— the Trigger field set to 1,
— a set of scheduling parameters in a Fine Timing Measurement Parameters element that describe the
initiating STA’s availability for measurement exchange.
The first Fine Timing Measurement frame in the FTM session is called the initial Fine Timing Measurement
frame. The responding STA should transmit an initial Fine Timing Measurement frame within 10 ms in
response to the initial Fine Timing Measurement Request frame. This initial Fine Timing Measurement
frame shall include the Fine Timing Measurement Parameters element. The value of the Status Indication
field indicates the outcome of the request.
NOTE—In an initial Fine Timing Measurement frame, the responding STA might indicate that the request for an FTM
session is successful, even if the initial Fine Timing Measurement frame includes at least one of
— A Measurement Report element that indicates an unknown LCI or
— A Measurement Report element that indicates an unknown civic location.
In the case of requests for 160 MHz bandwidth, the initiating STA shall indicate in the Format And
Bandwidth field whether it uses a single or two separate RF LOs. In the cases when the responding STA
indicates use of 160 MHz bandwidth, the responding STA shall indicate in the Format And Bandwidth field
whether it uses a single or two separate RF LOs.
The initiating STA shall indicate, in the Format and Bandwidth field, a format and bandwidth that it
supports. The responding STA shall indicate, in the Format and Bandwidth field, a format and bandwidth
that it supports. The responding STA should indicate the same format and bandwidth in the Format and
Bandwidth field as that requested by the initiating STA, if the responding STA supports this. The responding
STA shall not indicate a bandwidth wider than requested. The responding STA shall not indicate a VHT
format if DMG, HT-mixed or non-HT format was requested. The responding STA shall not indicate an HT
format if DMG or non-HT format was requested. The responding STA shall not indicate a DMG format if
VHT, HT-mixed or non-HT format was requested.
If the request was successful
— The initiating STA shall indicate, in the Format and Bandwidth field, a format and bandwidth it
supports. The responding STA shall indicate, in the Format and Bandwidth field, a format and
1791
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
bandwidth that it supports. The responding STA should indicate the same format and bandwidth in
the Format and Bandwidth field as that requested by the initiating STA, if the responding STA
supports this. The responding STA shall not indicate a bandwidth wider than requested. The
responding STA shall not indicate a VHT format if DMG, HT-mixed or non-HT format was
requested. The responding STA shall not indicate a DMG format if VHT, HT-mixed or non-HT
format was requested.
— An initiating STA performing a FTM procedure with a responding STA that is an AP shall support
non-ASAP operation.
— A responding STA that is an AP shall support and select non-ASAP operation when so requested by
an initiating STA.
— An initiating STA performing a FTM procedure with a responding STA that is not an AP shall
support ASAP operation.
— A responding STA that is not an AP shall support and select ASAP operation when so requested by
an initiating STA.
— If the responding STA is ASAP capable, the responding STA’s selection of ASAP should be the
same as that requested by the initiating STA.
— The responding STA’s selection of the Min Delta FTM field value shall be greater than or equal to
the value requested by the initiating STA.
— The responding STA’s selection of the Number of Bursts Exponent field value shall be 0 if the
initiating STA requested it to be 0.
— The responding STA’s selection of the Burst Duration field value should be less than or equal to the
one requested by the initiating STA if the requested FTMs per Burst field value is set to a value
indicating no preference, subject the recommendations below and the responding STA’s policy on
the maximum and minimum Burst Duration field values.
— If the Number of Bursts Exponent field is set to 0 and the ASAP field is set to 1, the Burst
Duration field value should be set to indicate the value BD1, defined as follows:
BD 1 = N FTMPB K+1 –1 T MDFTM + T FTM + aSIFSTime + T Ack
where
NFTMPB is the value of the FTMs per Burst field
K is the maximum number of Fine Timing Measurement frame retransmissions the
responding STA might attempt
TMDFTM is the duration indicated by the Min Delta FTM field of the Fine Timing
Measurement Parameters field of the initial Fine Timing Measurement frame
(FTM_1)
TFTM is the duration of the initial Fine Timing Measurement frame if the FTMs per Burst
field of the Fine Timing Measurement Parameters field of FTM_1 is set to 1, and
the duration of the non initial Fine Timing Measurement frame otherwise
TAck is the duration of the Ack frame expected as a response
— Otherwise, the Burst Duration field value should be set to indicate a value greater than or equal
to the following value:
BD 1 + T FTMR + aSIFSTime + T Ack + T ACCESS_FTM
where
TFTMR is the duration of a Fine Timing Measurement Request frame without a
Measurement Request element and without a Fine Timing Measurement
Parameters element
1792
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TACCESS_FTM is the estimated medium access time for the first FTM frame in a burst
— The responding STA’s selection of the value of the FTMs per Burst field should be the same as the
one requested by the initiating STA if the requested value of the Burst Duration field is set to a value
indicating no preference (see Table 9-257), subject to the responding STA’s policy on the maximum
value of the FTMs per Burst field.
— The responding STA’s selection of Burst Period shall be greater than or equal the responding STA’s
selection of Burst Duration.
NOTE—Apart from the Status Indication, Value, ASAP, Number of Bursts Exponent, Min Delta FTM, and Burst Period
fields, the other fields in the Fine Timing Measurement Parameters element in the initial Fine Timing Measurement
frame have no constraints.
When the responding STA cannot support the initiator’s Min Delta FTM or Number of Bursts Exponent
constraints, the responding STA shall set the Status Indication field to Request incapable and the FTM
session ends. When the responding STA is unable to fulfill the request by the initiating STA, the responding
STA shall set the Status Indication field to Request failed and the FTM session ends.
11.24.6.4 Measurement exchange
Fine Timing Measurement frames are sent during time windows called burst instances. The timing of the
burst instances is defined by the following parameters:
— Partial TSF Timer – The partial TSF timer, as defined in 9.4.2.168, at the beginning of the first burst
instance
— Burst Duration – The duration of each burst instance starting at the boundary of a burst period
— Burst Period – The interval from the beginning of one burst instance to the beginning of the
following burst instance.
The initiating STA shall transmit a Fine Timing Measurement Request frame without a Measurement
Request element, without a Fine Timing Measurement Parameters element and with the Trigger field set to 1
as soon as it is available on channel during a burst instance. This indicates to the responding STA its
availability for the remainder of the burst instance. In response, the responding STA shall transmit an Ack
frame and should transmit FTMs per Burst Fine Timing Measurement frames before the end of the burst
instance. In addition, the initiating STA shall be ready to receive a Fine Timing Measurement frame. The
first Fine Timing Measurement frame and its retransmissions in the burst instance from the responding STA
shall include an FTM Synchronization Information element in the FTM Synchronization Information field.
The TSF Sync Info field in the FTM Synchronization Information element contained in the Fine Timing
Measurement frame might be used by the initiating STA to synchronize its TSF with the responding STA’s
in order to determine the start of subsequent burst instances. Subsequent Fine Timing Measurement frames
within the burst instance shall not include a Fine Timing Measurement Parameters element and shall not
include an FTM Synchronization Information field (for additional constraints on the Fine Timing
Measurement frame see 11.24.6.7). Consecutive Fine Timing Measurement frames to a given peer STA
shall be spaced at least Min Delta FTM apart. Within a burst instance the initiating STA shall perform FTM
on each Fine Timing Measurement frame addressed to it, except the last Fine Timing Measurement frame.
The initiating STA may perform FTM on the last Fine Timing Measurement frame in a burst instance.
NOTE—If the initiating STA successfully transmits a non-initial Fine Timing Measurement Request frame late in a
burst instance, fewer than FTMs per burst might be successfully transmitted by the responding STA in the burst instance.
If a Fine Timing Measurement frame, except for the initial Fine Timing Measurement frame in the ASAP=0 case, is sent
outside a burst instance, it might not be acknowledged.
The first burst instance shall start at the value indicated by the value of the Partial TSF Timer field in the
initial Fine Timing Measurement frame, regardless of the ASAP field’s value. When ASAP is set to 1 by the
responding STA, the Partial TSF Timer field value shall be set to a value less than 10 ms from the reception
of the most recent initial Fine Timing Request frame.
1793
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The scheduling parameters of an FTM session are illustrated in Figure 11-35.
Responding STA Initiating STA
<= 10 ms
(recommended)
NOTE 1 –
TSF (Responding STA) [10:25] =
Partial TSF Timer
See NOTE 1
t1_2 t2_2 Burst
t4_2 t3_2 Duration
Burst >= Min
Delta
Period
FTM
t1_3 t2_3
t4_3 t3_3
t1_4 t2_4 Burst
t4_4 t3_4 Duration
t1_5 t2_5
t4_5 t3_5
Figure 11-35—Example negotiation and measurement exchange sequence, ASAP=0, and
FTMs per Burst = 2
1794
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The initiating STA can request the responding STA to start the burst instances “as soon as possible” by
setting the ASAP field to 1. The scheduling in this case is illustrated in Figure 11-36.
Responding STA Initiating STA
NOTE 1 –
TSF (Responding STA) [10:25] =
Partial TSF Timer
< 10 ms
<= 10 ms
(recommended) See NOTE 1
t1_1 t2_1
>=Min t3_1
Delta t4_1
FTM
t1_2 t2_2 Burst
t3_2 Duration
Burst t4_2
Period
t1_3 t2_3 Burst
t4_3 t3_3 Duration
t1_4 t2_4
t4_4 t3_4
Figure 11-36—Example negotiation and measurement exchange sequence, ASAP=1, and
FTMs per Burst = 2
1795
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The initiating STA may also request a single burst of FTMs to be taken as soon as possible, in which case it
sets the Number of Bursts Exponent field to 0 and the ASAP field to 1. This is illustrated in Figure 11-37.
Responding STA Initiating STA
<= 10 ms < 10 ms
(recommended)
See NOTE 1
t1_1 t2_1
>= Min t4_1 t3_1
NOTE 1 – Delta
FTM Burst
TSF (Responding STA) [10:25] = Duration
Partial TSF Timer
t1_2 t2_2
t3_2
t4_2
NOTE 2 – See NOTE 2
Initiating STA can compute an
RTT and a clock offset
t1_3 t2_3
t4_3 t3_3
Figure 11-37—Example negotiation and measurement exchange sequence for a single
burst instance, ASAP=1, and FTMs per Burst = 3
For non-DMG STAs, both the Fine Timing Measurement frame and the corresponding Ack frame shall be
transmitted using a single transmit chain.
The responding STA shall not transmit Fine Timing Measurement frames using Clause 15 or Clause 16
formats, MCS 32 format, or HT-greenfield format.
The responding STA should transmit Fine Timing Measurement frames with the format and bandwidth it
indicated.
For the Fine Timing Measurement frames transmitted during the FTM session:
— The responding STA shall not use a bandwidth wider than that indicated by the STA in the initial
Fine Timing Measurement frame.
— The responding STA shall not use a VHT format if the STA indicated HT-mixed or non-HT format
in the initial Fine Timing Measurement frame.
— The responding STA shall not use an HT format if the STA indicated non-HT format in the initial
Fine Timing Measurement frame.
The ASAP Capable field shall be set to 1 in the initial Fine Timing Measurement frame if a responding STA
is ASAP-capable; otherwise it shall be set to 0.
A responding STA transmits Fine Timing Measurement frames in overlapping pairs of consecutive frames.
For example, in Figure 11-36, FTM_1 and FTM_2, FTM_2 and FTM_3, and FTM_3 and FTM_4 are
overlapping pairs of consecutive frames. The first Fine Timing Measurement frame of a pair of consecutive
Fine Timing Measurement frames contains a nonzero value in the Dialog Token field. The follow up Fine
Timing Measurement frame contains a Follow Up Dialog Token field set to the value of the Dialog Token
field in the first frame of the consecutive pair. Dialog Token field values of consecutive Fine Timing
1796
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Measurement frames shall be consecutive, except when the value wraps around to 1 or in the last Fine
Timing Measurement frame in an FTM session. With the first Fine Timing Measurement frame, both STAs
capture timestamps. The responding STA captures the time at which the Fine Timing Measurement frame is
transmitted (t1). The initiating STA captures the time at which the Fine Timing Measurement frame arrives
(t2) and the time at which the Ack response is transmitted (t3). The responding STA captures the time at
which the Ack frame arrives (t4). See Figure 6-17. In the follow up Fine Timing Measurement frame, in the
same or the subsequent burst, the responding STA transfers the timestamp values it captured (t1 and t4) to
the initiating STA. In this follow up Fine Timing Measurement frame, the timestamp values (t1 and t4) shall
be the measurement according to the responding STA’s clock (i.e., without applying any frequency offset
correction to the time bases).
NOTE—A Fine Timing Measurement frame can contain nonzero values in both the Dialog Token and Follow Up
Dialog Token fields, meaning that the Action frame contains follow up information from a previous measurement, and
new Timestamp values are captured to be sent in a future follow up Fine Timing Measurement frame.
When the ASAP field is set to 0 by a responding STA, the Follow Up Dialog Token, TOD, TOA, TOD
Error, and TOA Error fields in the Fine Timing Measurement frame following the initial Fine Timing
Measurement frame shall be reserved.
When the ASAP field is set to 1 by a responding STA, the timestamps for the initial Fine Timing
Measurement frame shall be captured and sent in the following Fine Timing Measurement frame. In the Fine
Timing Measurement frame following the initial Fine Timing Measurement frame, the TOD and TOA fields
shall be set to the timestamps associated with the initial Fine Timing Measurement frame.
The round trip time (RTT) is defined by Equation (11-5).
RTT = [(t4' – t1') – (t3 – t2)] (11-5)
where t1' and t4' are the time at which the Fine Timing Measurement frame was transmitted and the time at
which the Ack was received, respectively, as determined by the initiating STA.
At the initiating STA, the mechanism by which t1' and t4' are derived from the TOD and TOA fields is
implementation dependent.
The Fine Timing Measurement protocol can also be used to synchronize a local clock between STAs. One
higher-layer protocol for synchronizing a local clock time between STAs is specified in IEEE Std 802.1AS.
The SME at the initiating STA may estimate the offset of the local clock relative to that at the responding
STA using clock offset as defined by Equation (11-6).
clock offset = [(t2 - t1') - (t4' - t3)]/2 (11-6)
NOTE—The initiating STA might track this clock offset over time to derive an estimate of the difference between the
initiating STA’s time base and the responding STA’s time base, and thereby improve the accuracy of its derivation of t1'
and t4' from the TOD and TOA fields.
If the Ack frame for a transmitted Fine Timing Measurement frame is not received, the responding STA
shall not retry the frame. In order to send the frame again, the responding STA shall send a Fine Timing
Measurement frame with the same Action frame body as the Fine Timing Measurement frame for which the
Ack was not received, except for updating the Dialog Token if it was nonzero. The Sequence Number in the
MAC header is also updated. This is called an FTM retransmission.
A responding STA that transmits a Fine Timing Measurement frame with the ASAP field set to 0 shall set
the Partial TSF Timer field to an offset value DTSF from the partial value of the responding STA’s TSF timer
at the time of the transmission of the Ack to the last Fine Timing Measurement Request frame from the
initiating STA, subject to
1797
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DTSF >= K_1 x TMDFTM + TFTM_1 + aSIFSTime + TAck + TACCESS_FTM1
where
K_1 is the maximum number of initial Fine Timing Measurement frame (FTM_1)
retransmissions the responding STA might attempt.
TMDFTM is the value of the Min Delta FTM field of the Fine Timing Measurement Parameters
field of FTM_1.
TFTM_1 is the duration of the FTM_1.
TAck is the duration of the Ack frame expected as a response.
TACCESS_FTM1 is the estimated medium access time for FTM_1.
NOTE—This value of the Partial TSF Timer field ought to result in the Fine Timing Measurement Request frame not
being transmitted before a successful transmission of FTM_1.
When neither an Ack to the initial Fine Timing Measurement frame nor a Fine Timing Measurement
Request frame has been received by the responding STA, the responding STA shall not terminate the FTM
session before the time indicated by the Partial TSF timer plus the Burst Duration.
The responding STA shall set the Follow Up Dialog Token field to 0 in the initial Fine Timing Measurement
frame and its FTM retransmissions.
The responding STA shall set the Dialog Token field to 0 in the last Fine Timing Measurement frame and its
FTM retransmissions.
11.24.6.5 Fine timing measurement parameter modification
During an FTM session, an initiating STA may terminate the current session and request a new session with
modified session parameters by transmitting a Fine Timing Measurement Request frame with Trigger field
set to 1 and including a new Fine Timing Measurement Parameters element. The existing FTM session is
terminated upon reception of such a Fine Timing Measurement Request frame. This Fine Timing
Measurement Request frame is an initial Fine Timing Measurement Request frame for the new FTM
session, which follows the behavior described in 11.24.6.3.
11.24.6.6 Fine timing measurement termination
An FTM session terminates after the last burst instance, as indicated in the Number of Bursts Exponent,
Burst Duration, FTMs per Burst and Burst Period fields in the initial Fine Timing Measurement frame.
An FTM session may be terminated before then through one of the following:
— At any time during the FTM session when the responding STA is permitted to transmit a Fine
Timing Measurement frame (see 11.24.6.4), the responding STA sends a Fine Timing Measurement
frame with the Dialog Token field set to 0.
— At any time during the FTM session when the initiating STA is permitted to transmit a Fine Timing
Measurement frame (see 11.24.6.4), the initiating STA sends a Fine Timing Measurement Request
frame with the Trigger field set to 0. This frame shall not include:
— a Measurement Request element
— a Fine Timing Measurement Parameters element
— At any time during the FTM session when the initiating STA is permitted to transmit a Fine Timing
Measurement frame (see 11.24.6.4), the initiating STA terminates the current session and requests a
new session with modified Fine Timing Measurement parameters (see 11.24.6.5).
1798
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— After the number of burst instances indicated in the Number of Bursts Exponent field in the initial
Fine Timing Measurement frame has been reached.
11.24.6.7 LCI and Location Civic retrieval using FTM procedure
Within the FTM procedure, a STA, to request the LCI of a responding STA that transmits an Extended
Capabilities element with the Fine Timing Measurement Responder field set to 1, shall include a
Measurement Request element with Measurement Type field equal to LCI within the Fine Timing
Measurement Request frame.
Within the FTM procedure, a STA, to request the Location Civic of a responding STA that transmits an
Extended Capabilities element with the Fine Timing Measurement Responder field set to 1, shall include a
Measurement Request element with Measurement Type field equal to Location Civic within the Fine
Timing Measurement Request frame.
A Measurement Request element with Measurement Type field equal to LCI shall not be included in a Fine
Timing Measurement Request frame unless the Fine Timing Measurement Request frame also includes a
Fine Timing Measurement Parameters element. A Measurement Request element with Measurement Type
field equal to Location Civic shall not be included in a Fine Timing Measurement Request frame unless the
Fine Timing Measurement Request frame also includes a Fine Timing Measurement Parameters element.
When a responding STA that has both dot11FineTimingMsmtRespActivated and dot11RMLCIConfigured
equal to true receives a Measurement Request element with Measurement Type field equal to LCI within an
initial Fine Timing Measurement Request frame, the responding STA shall include a Measurement Report
element with Measurement Type field equal to LCI in the initial Fine Timing Measurement frame. If the
maximum horizontal or vertical location error of the responding STA relative to a reference STA is known
and this relative error is smaller than the absolute error indicated in the LCI subelement, then the responding
STA may include a Relative Location Error subfield in the Measurement Report field. The responding STA
shall not include a Measurement Report element with Measurement Type field equal to LCI in the Fine
Timing Measurement frame in the current FTM session unless the responding STA’s LCI has changed since
the last time it was reported to the initiating STA.
When a responding STA that has at least one of dot11FineTimingMsmtRespActivated and
dot11RMLCIConfigured equal to false receives a Measurement Request element with Measurement Type
field equal to LCI within a Fine Timing Measurement Request frame, the responding STA shall include a
Measurement Report element with the Incapable field set to 1 in the initial Fine Timing Measurement frame.
When a responding STA that has both dot11FineTimingMsmtRespActivated and dot11RMCivicConfigured
equal to true receives a Measurement Request element with Measurement Type field equal to Location Civic
within an initial Fine Timing Measurement Request frame, the responding STA shall include a
Measurement Report element with Measurement Type field equal to Location Civic in the initial Fine
Timing Measurement frame. The responding STA shall not include a Measurement Report element with
Measurement Type field equal to Location Civic in the Fine Timing Measurement frame in the current FTM
session unless the responding STA’s civic location has changed since the last time it was reported to the
initiating STA.
When a responding STA that has at least one of dot11FineTimingMsmtRespActivated and
dot11RMCivicConfigured equal to false receives a Measurement Request element with Measurement Type
equal to Location Civic within a Fine Timing Measurement Request frame, the responding STA shall
include a Measurement Report element with the Incapable field set to 1 in the initial Fine Timing
Measurement frame.
Each Measurement Report element returned shall have the same Measurement Token value as in the
Measurement Token field of the corresponding Measurement Request element. The Fine Timing
1799
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Measurement frame containing the Measurement Report element(s) should be returned without undue delay
to the STA.
A STA that receives an LCI report that contains a Usage Rules/Policy subelement shall process the LCI
information in compliance with the retransmission and retention permissions in the Usage Rules/Policy
subelement.
11.24.7 BSS transition management for network load balancing
11.24.7.1 BSS transition capability
The BSS transition capability enables improved throughput, effective data rate and/or QoS for the aggregate
of STAs in a network by shifting (via transition) individual STA traffic loads to more appropriate points of
association within the ESS. In addition, the BSS transition capability provides accounting session control
information to a non-AP STA, which might be used to provide an alert to the non-AP STA’s user that the
STA’s session is almost over and the STA will be disassociated from the ESS.
The BSS Transition Management Query, BSS Transition Management Request, BSS Transition
Management Response frames provide a means and a protocol to exchange the information needed to enable
an AP to inform associated STAs that the BSS will be terminated and to enable a network to manage BSS
loads by influencing STA transition decisions. A STA may provide neighbor report information to its
associated AP for BSSs that it considers to be transition targets. This information enables the AP to request
that the STA transition to a BSS that the STA also prefers.
Implementation of BSS transition management is optional for a WNM STA. A STA that implements BSS
transition management has dot11BSSTransitionImplemented equal to true. When
dot11BSSTransitionImplemented is true, dot11WirelessManagementImplemented shall be true. A STA
whose dot11BSSTransitionActivated is true shall support BSS transition management and shall set to 1 the
Transition field of the Extended Capabilities elements that it transmits.
The provisions in this clause for BSS transition management and network load balancing do not apply in an
IBSS.
11.24.7.2 BSS transition management query
A non-AP STA supporting BSS transition management may request a BSS Transition Candidate list by
sending a BSS Transition Management Query frame to its associated AP if the associated AP indicates that
it supports the BSS Transition capability in the Extended Capabilities element. A non-AP STA should
include the BSS Transition Candidate List Entries field in the BSS Transition Management Query frame to
indicate the non-AP STA’s transition preferences. If the non-AP STA transmits a BSS Transition Query
frame only to provide transition preferences to the AP, then the BSS Transition Query Reason field of the
BSS Transition Management Query frame shall be set to a value of 19, indicating “Preferred BSS Transition
Candidate List Included.”
The BSS Transition Candidate List Entries field of a BSS Transition Management Query frame contains
zero or more Neighbor Report elements describing the non-AP STA’s preferences for target BSS
candidates. The Preference field value of a Neighbor Report element used in a BSS Transition Management
Query frame shall be between 1 and 255. The value of 0 is reserved. The values between 1 and 255 provide
the indication of order, with 255 indicating the most preferred BSS within the given candidate list,
decreasing numbers representing decreasing preference relative only to entries with lower values of the
Preference field, and equal numbers representing equal preference.
1800
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.24.7.3 BSS transition management request
An AP that supports BSS transition management shall respond to a BSS Transition Management Query
frame with a BSS Transition Management Request frame. The AP may send an unsolicited BSS Transition
Management Request frame to a non-AP STA at any time if the non-AP STA indicates in the Extended
Capabilities element that it support BSS transition management; otherwise the AP shall not send an
unsolicited BSS Transition Management Request frame to the STA. The AP may transmit a group addressed
BSS Transition Management Request frame to associated non-AP STAs if all associated non-AP STAs
support the BSS transition management; otherwise the AP shall not transmit a group addressed BSS
Transition Management Request frame. When the BSS Transition Management Request frame is
transmitted as a group addressed frame, a receiving non-AP STA shall not respond with a BSS Transition
Management Response frame. A non-AP STA that supports BSS transition management shall respond to an
individually addressed BSS Transition Management Request frame with a BSS Transition Management
Response frame.
The AP shall include the BSS Transition Candidate List Entries field in the BSS Transition Management
Request frame if the AP has information in response to the BSS Transition Management Query frame. The
BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements describing the
preferences for target BSS candidates. A Preference field value of 0 indicates that the BSS listed is an
excluded BSS. The STA should refrain from associating to an AP corresponding to an excluded BSS. The
Preference field values are used to establish the relative order of entries within the given list at the given
time, and for the given AP.
The values between 1 and 255 provide the indication of order, with 255 indicating the most preferred BSS
within the given candidate list, decreasing numbers representing decreasing preference relative only to
entries with lower values of the Preference field, and equal numbers representing equal preference. The
Preference field value is valid only before the validity interval has expired. The AP may include zero or
more subelements in the BSS Transition Candidate List Entries field.
Upon reception of a BSS Transition Management Query frame or BSS Transition Response frame from a
non-AP STA that contains a nonempty BSS Transition Candidate List Entries field, the AP should include at
least one BSS candidate from that list with a nonzero Preference field value in the BSS Transition Candidate
List Entries field of any subsequent BSS Transition Management Request frame with the Preferred
Candidate List Included field set to 1 transmitted to the non-AP STA. The AP shall evaluate the BSSs
indicated in the BSS Transition Candidate List Entries field in the latest BSS Transition Management Query
frame or BSS Transition Management Response frame received from the non-AP STA as BSS transition
candidate(s) for the non-AP STA. The means by which the AP evaluates and determines BSS
transition candidates is outside the scope of this standard.
A STA that receives a BSS Transition Management Request frame with the Preferred Candidate List
Included subfield of the Request Mode field equal to 0 may ignore the BSS Transition Candidate
List Entries field of the frame.
A non-AP STA that receives the Abridged bit with a value of 1 shall treat any BSSID in the current ESS that
does not appear in the BSS Transition Candidate List as if it were present in the BSS Transition Candidate
List with a Preference value of 0.
The AP may include one BSS Termination Duration subelement for each BSS in the BSS Transition
Candidate List Entry field, including the BSS Termination Duration value and a BSS Termination TSF
value. The BSS Termination Duration value may be different for each BSS.
When the AP transmits a BSS Transition Management Request frame with the Disassociation Imminent
field set to 1 to a non-AP STA, the Disassociation Timer field in the BSS Transition Management Request
frame shall be set to 0 or set to the number of TBTTs that will occur prior to the AP disassociating the
1801
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
non-AP STA. The AP shall start a timer for the non-AP STA with the initial timer value set to the
Disassociation Timer field value. The AP shall decrement the timer by one after transmitting each Beacon
frame until the timer has value of 0. In subsequent BSS Transition Management Request frames that the AP
transmits to the non-AP STA, the Disassociation Timer field shall be set to the value of the timer.
If the most recent BSS Transition Management Request frame that an AP has transmitted to a non-AP STA
has the Disassociation Imminent field set to 1, then the AP shall not transmit a Disassociation frame to the
non-AP STA unless the timer for the non-AP STA has value of 0.
An AP’s SME may have accounting session control information, such as a notice of session expiration. The
means by which the AP’s SME obtains accounting session control information is out of scope of this
standard. Accounting session control information might include a time duration after which the non-AP
STA will be disassociated from the ESS and an optional session information URL at which information may
be obtained to extend the accounting session. When an AP’s SME has accounting session control
information, it shall issue an MLME-BTM.request primitive to the AP’s MLME and shall encode the time to
session expiration in the Disassociation Timer parameter and shall encode the URL, if available, in the
SessionInformationURL parameter. A non-AP STA’s SME that has received an MLME-BTM.indication
primitive forwards the MLME-BTM.indication parameters to the appropriate entity within the device (e.g.,
web browser) to inform the end user; the means and protocol by which the SME accomplishes this is outside
the scope of this standard.
A STA’s SME receiving an MLME-BTM.indication primitive containing the BSS Transition Candidate List
Entries field should use this list of candidates, with individual transition preference values, to make BSS
transition decisions. Upon receiving an MLME-BTM.indication primitive, the STA’s SME shall disregard
any previous MLME-BTM.indication primitive received from the same AP. The STA shall not use the
corresponding BSS Transition Candidate List Entries field information after the indicated validity interval.
The STA may send a BSS Transition Management Query frame at any time to obtain an updated BSS
Transition Candidate List Entries field or to indicate the STA’s BSS transition candidates.
A STA’s SME receiving an MLME-BTM.indication primitive containing a nonzero value of the
Disassociation Timer field should attempt to find a suitable AP with which to reassociate before the
indicated disassociation time.
11.24.7.4 BSS transition management response
When the STA’s SME receives an MLME-BTM.indication primitive, it may issue an MLME-
BTM.response primitive.
The STA’s SME may include the result of its BSS transition decision in the Target BSSID field and BTM
Status Code field in the MLME-BTM.response primitive. A BTM Status Code field set to a value of 0 (i.e.,
Accept) indicates the STA will transition from the current BSS. The STA’s SME receiving an MLME-
BTM.indication primitive may issue an MLME-BTM.response primitive with a valid status code not equal
to a value of 0 (i.e., Accept) indicating rejection if it is unable to comply with this BSS transition
management request.
When a non-AP STA’s SME receives an MLME-BTM.indication primitive with the BSS Termination
Included field in the Request Mode field equal to 1 it may issue an MLME-BTM.response primitive with the
BTM Status Code field set to one of the following values:
— 0 – Accept. Accept the BSS Termination request.
— 4 – Reject, BSS Termination Undesired. Request for deferral of BSS Termination, interval not
specified.
— 5 – Reject, BSS Termination Delay. Request for deferral of BSS Termination interval specified in
the BSS Termination Delay field in the BSS Transition Management Response frame.
1802
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The AP’s SME may terminate or delay BSS Termination based on policies that are out of the scope of this
standard. The MLME-RESET.request primitive is invoked to terminate the BSS. The AP shall disassociate
all STAs immediately prior to termination of the BSS.
When a non-AP STA’s SME receives an MLME-BTM.indication primitive with both the Disassociation
Imminent and Preferred Candidate List Included fields equal to 0, the non-AP STA’s SME shall issue an
MLME-BTM.response primitive with the BTM Status Code field set to one of the following values:
— 0 – Accept.
— 2 – Reject, Insufficient Beacon or Probe Response frames received from all candidates.
— 3 – Reject, Insufficient available capacity from all candidates.
— 6 – Reject, STA BSS Transition Candidate List provided.
— 7 – Reject, No suitable BSS transition candidates.
— 8 – Reject, Leaving ESS.
When an AP’s SME receives an MLME-BTM.confirm primitive with the BTM Status Code field equal to a
value of 2, indicating “Reject, Insufficient Beacon or Probe Response frames received from all candidates,”
the AP’s SME should generate an MLME-BTM.request primitive with both the Disassociation Imminent
and Preferred Candidate List Included fields set to 0 after providing sufficient time for the non-AP STA to
perform its scanning procedures.
If the BTM Status Code field is a value of 6, indicating “Reject, STA BSS Transition Candidate List
provided,” the non-AP STA shall include a nonempty BSS Transition Candidate List Entries field in the
BSS Transition Management Response frame to indicate the non-AP STA’s transition preferences. The
BTM Status Code field is a value of 8, indicating “Reject, Leaving ESS” if the non-AP STA intends to
disassociate from the ESS.
The BSS Transition Candidate List Entries field of a BSS Transition Management Response frame contains
zero or more Neighbor Report elements describing the non-AP STA’s preferences for target BSS
candidates. The Preference field value of a Neighbor Report element used in a BSS Transition Management
Response frame shall be between 1 and 255. The value of 0 is reserved. The values between 1 and 255
provide the indication of order, with 255 indicating the most preferred BSS within the given candidate list,
decreasing numbers representing decreasing preference relative only to entries with lower values of the
Preference field, and equal numbers representing equal preference. The non-AP STA should not list any
BSS that is not considered as a target BSS candidate.
When a non-AP STA receives a BSS Transition Management Request frame that has both the
Disassociation Imminent and Preferred Candidate List Included fields equal to 1 and a nonempty BSS
Transition Candidate List Entries field, if the non-AP STA transmits a BSS Transition Management
Response frame to the AP with the BTM Status Code field set to 0 (Accept), then the non-AP STA shall
either disassociate from the AP or attempt to (re)associate with an AP corresponding to one of the
nonexcluded BSSs in the BSS Transition Candidate List Entries field of the received BSS Transition
Management Request frame.
Prior to transitioning to an excluded BSS listed in the BSS Transition Candidate List Entries field of a
received BSS Transition Management Request frame, the non-AP STA shall transmit a BSS Transition
Management Response frame to the AP indicating the reject reason.
11.24.8 FMS multicast rate processing
An AP that supports FMS indicates its ability to deliver group addressed frames at alternate delivery
intervals by its advertisement of the FMS capability. A STA that supports FMS includes the FMS Request
element in FMS Request frames to indicate a request to use the FMS service, including use of a higher
1803
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
multicast rate. The AP selects the TXVECTOR parameters to use with the STA and indicates the rate that
these parameters produce and the multicast address in the FMS Response element in the FMS Response
frame.
The AP selects TXVECTOR parameters that will be used for transmission to the currently associated STAs
requesting FMS service from the AP for the same FMS stream identified by FMSID (the “existing STAs”),
and to the requesting STA subject to the following constraints:
— The rate shall not be higher than the lowest rate value provided by the existing STAs and the
requesting STA
— The selection of the following TXVECTOR parameters shall be compatible with capabilities
declared by the existing STAs and the requesting STA:
— FORMAT
— NON_HT_MODULATION
— PREAMBLE_TYPE
— MCS
— CH_BANDWIDTH
— STBC
— FEC_CODING
— GI_TYPE
The STA’s SME may request membership in a multicast group or changes in multicast data rate by issuing
an MLME-FMS.request primitive. Upon receipt of an FMS Request frame at the AP’s SME as indicated by
reception of the MLME-FMS.indication primitive the AP’s SME shall issue an MLME-FMS.response
primitive, indicating the FMS Request element, including the multicast address. The AP may send an FMS
Response frame to the STA to change the STA’s multicast rate. When the AP sends an FMS Response frame
to the STA with an Element Status field, indicating “Multicast rate changes not allowed,” the STA shall not
send further FMS Request frames to request a change in the multicast rate while the STA is associated to
the AP.
11.24.9 Collocated interference reporting
Collocated interference may cause degradation of IEEE 802.11 STA performance either periodically or
continuously. Collocated interference reporting allows a requesting STA to receive information concerning
the collocated interference being experienced by another STA that is operating on the same channel as the
requesting STA. Such interference might be due to an interaction between radios where a reporting STA is
collocated with another radio device. Collocated interference information might be used by the requesting
STA to manage communication to the reporting STA such that the effect of the interference might be
limited.
Implementation of Collocated interference reporting is optional for a WNM STA. A STA that implements
Collocated Interference reporting has dot11CoLocIntfReportingImplemented equal to true. When
dot11CoLocIntfReportingImplemented is true, dot11WirelessManagementImplemented shall be true. A
STA whose dot11CoLocIntfReportingActivated is true shall support collocated interference reporting and
shall set to 1 the Collocated Interference Reporting field of the Extended Capabilities elements that it
transmits.
A requesting STA may request that collocated interference reporting is enabled at another STA that has
indicated support for the interference reporting capability. To enable collocated interference reporting, the
STA shall send a Collocated Interference Request frame with Automatic Response Enabled bit set to the
value representing the requested reporting type; see 9.6.14.13. A STA accepting a request for collocated
interference reporting shall send the first report when it has knowledge of collocated interference.
1804
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Subsequently, a STA accepting a request with the Automatic Response Enabled subfield equal to 1 shall
send a collocated interference report when the temporal characteristics of the interference or the level of the
interference caused by collocated interferer significantly change to provide updated information, subject to
meeting the Report Timeout requirement. A STA accepting a request with the Automatic Response Enabled
subfield equal to 2 or 3 shall send the collocated interference reports periodically using the period included
in the Report Period field in the Collocated Interference Reporting element in the report frames. In addition
to sending reports periodically, a STA accepting a request with the Automatic Response Enabled field equal
to 3 shall send a collocated interference report when the temporal characteristics of the interference or the
level of the interference caused by collocated interferer significantly change, subject to meeting the Report
Timeout requirement.
The criteria a reporting STA uses for determining significant changes are internal to the reporting STA and
outside the scope of this standard. When the reporting STA sends a collocated interference report, it shall
restart the Report Period timer for periodic reporting. For either periodic reporting or reporting due to the
changes in collocated interference, the reporting STA shall not generate collocated interference reports more
frequently than indicated by the Report Timeout field in Interference Request field in the Collocated
Interference Request frame.
The requesting STA may disable reporting by sending a Collocated Interference Request frame with the
Automatic Response Enabled subfield set to 0. The collocated interference reporting shall be terminated on
receipt of a Collocated Interference Request frame with the Automatic Response Enabled subfield equal to
0. All outstanding collocated interference requests are canceled upon a BSS transition and/or channel
switch. A new collocated interference request included in the new collocated Interference Request frame
supersedes any previously received requests sent by the same STA.
A STA that supports collocated interference reporting may send a Collocated Interference Request frame to
another STA that supports collocated interference reporting immediately after they are associated, so that
the reporting STA can send a collocated interference report as soon as it has knowledge of collocated
interference. The Dialog Token field is the nonzero value received in the corresponding Collocated
Interference Request frame which was used to enable reporting.
The reporting STA shall use the Interference Index field in the Collocated Interference Report frame to
indicate different types of interference. The reporting STA shall select a unique interference index value for
each collocated interference source. For example if the reporting STA has knowledge of collocated
interference originating from two interference sources the reporting STA shall report both type of
interference using separate Collocated Interference Report elements having separate Interference Index
field. Both Collocated Interference Report elements can be sent in the same Collocated Interference Report
frame and both can have the same report period. A report with the Interference Index field in the Collocated
Interference Report element equal to 0 indicates that no collocated interference is present.
The characteristics of the interference are known a priori without requiring interference detection,
measurement, and characterization by the IEEE 802.11 STA. The methods used by a reporting STA to know
the periodicity, level of interference, accuracy of the reported interference level, interference center
frequency and interference bandwidth are outside the scope of this standard.
11.24.10 QoS Traffic capability procedure
Implementation of the QoS Traffic capability is optional for a WNM STA. A STA that implements
QoS Traffic capability has dot11QoSTrafficCapabilityImplemented equal to true. When
dot11QoSTrafficCapabilityImplemented is true, dot11WirelessManagementImplemented shall be true. A
STA whose dot11QoSTrafficCapabilityActivated is true shall support QoS traffic capability and shall set
to 1 the QoS Traffic Capability field of the Extended Capabilities elements that it transmits.
1805
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If dot11QoSTrafficCapabilityActivated is true, a QoS AP may use the QoS Traffic Capability field values
received from a non-AP QoS STA as one of the factors when determining association, reassociation, and the
BSS transition of the STA. A non-AP STA in which dot11QoSTrafficCapabilityActivated is true may send
an Association Request, a Reassociation Request or QoS Traffic Capability Update frame to an AP whose
last received Extended Capabilities element contained a value of 1 for the QoS Traffic Capability bit in the
Extended Capabilities field.
If dot11QoSTrafficCapabilityActivated is true, a non-AP QoS shall construct the QoS Traffic Capability
Flags as specified in 9.4.2.78 and 9.6.14.23. QoS Traffic Capability Flags are constructed at the SME of the
non-AP QoS STA, from application requirements supplied to the SME. The QoS Traffic Capability Flags
are constructed from two application requirements: whether generation of traffic is required for applications
and whether a specific UP is required for the generated traffic. If such requirements are supplied to the SME,
the SME shall set the flag corresponding to the specific UP to 1.
NOTE—The requirements might be known before the traffic is actually generated. For example, a phone application
might configured to generate UP 6 traffic upon the initiation of a voice session.
Unless application requirements for a specific UP are supplied to the SME, the SME shall set the flag
corresponding to the UP to 0.
If dot11QoSTrafficCapabilityActivated is true, a non-AP QoS STA shall include the QoS Traffic Capability
element in an Association Request frame or in a Reassociation Request frame when it is sending such a
frame to associate or reassociate with an AP. If there is any change in QoS Traffic Capability Flags while
associated with an AP, the non-AP STA shall send a QoS Traffic Capability Update frame (see 9.6.14.23)
including the updated QoS Traffic Capability Flags to the AP.
11.24.11 AC Station Count
Implementation of AC Station Count is optional for a WNM STA. A STA that implements AC
Station Count has dot11ACStationCountImplemented equal to true. When
dot11ACStationCountImplemented is true, dot11WirelessManagementImplemented and
dot11QoSTrafficCapabilityImplemented shall be true. When dot11ACStationCountActivated is true, the
STA shall set the AC Station Count field to 1 in the Extended Capabilities element to indicate that the STA
supports the AC station count capability. When dot11ACStationCountActivated is false, the STA shall set
the AC Station Count field in the Extended Capabilities element to 0 to indicate that the STA does not
support this capability.
If dot11ACStationCountActivated is true, a QoS AP shall construct the QoS Traffic Capability Bitmask and
AC STA Count list as specified in 9.4.2.78. The AP shall construct the STA Count List value based on the
UP-to-AC mappings as defined in Table 10-1, the QoS Traffic Capability Bitmask/Flags of the non-AP
STAs that are currently associated with it, and additional information. If dot11ACStationCountActivated is
true, a QoS AP shall include the QoS Traffic Capability element in a Probe Response frame and in a Beacon
frame.
If dot11ACStationCountActivated is true, a non-AP QoS STA may use the STA Count field values as one of
the factors when determining association, reassociation, and the BSS transition. If
dot11ACStationCountActivated is false, a non-AP QoS STA shall not use the STA Count field values as one
of the factors when determining association, reassociation, and the BSS transition.
11.24.12 TFS procedures
11.24.12.1 TFS capability
Implementation of the TFS capability is optional for a WNM STA. A STA that implements TFS shall set
dot11TFSImplemented to true. If dot11TFSImplemented value is true, then
1806
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WirelessManagementImplemented shall be true. A STA whose dot11TFSActivated is true shall
support TFS and shall set to 1 the TFS field in the Extended Capabilities elements that it transmits.
A STA in which dot11TFSActivated is true may send a TFS Request, TFS Response, TFS Notify frame, or
TFS Notify Response frame to a STA within the same infrastructure BSS whose last received Extended
Capabilities element contained a value of 1 for the TFS bit in the Extended Capabilities field. The traffic
filtering service is not supported in an IBSS.
A traffic filtering agreement is established using a TFS Request frame transmitted from a non-AP STA to an
AP STA and a TFS Response frame transmitted from the AP STA to the non-AP STA. At most one traffic
filtering agreement can exist at any one time between a STA and its associated AP.
A traffic filtering agreement comprises one or more traffic filter sets, with a logical OR operation on the
match conditions of each traffic filter set.
A traffic filter set contains one or more traffic filters, with a logical AND operation on the match conditions
of each traffic filter, and also includes a traffic filter set action. The traffic filter set action defines the actions
taken at the AP when a frame match occurs. A frame match occurs when a frame matches to the filtering
parameters for a TFS traffic filter set.
NOTE—The frame match can occur when the matched frames are either individually addressed or group addressed.
A TFS Request frame contains one or more TFS Request elements. Each traffic filter set is conveyed by one
TFS Request element, within a TFS Request frame.
One TFS Request element contains one or more TFS Request subelements. A TFS Request subelement
might be a TFS subelement, in which case it contains the filtering parameters for one traffic filter.
A TFS subelement contains one or more TCLAS elements and an optional TCLAS Processing element that
defines the relationship among multiple TCLAS elements within the TFS subelement. The TCLAS
Processing element shall be present if more than one TCLAS element is included in the TFS subelement.
A TFS Response frame contains the status of the traffic filters requested in the corresponding TFS Request
frame.
An AP may propose alternative filtering parameters by returning a TFS subelement in the corresponding
TFS Response subelement. (See 11.24.12.2 and 11.24.12.3). When an AP proposes alternative filtering
parameters it shall ensure that the TFS subelements related to the traffic filter set specified by a single TFS
Request element all fit within a single TFS Response element.
When an AP transmits a TFS Response frame to a STA in which the Status for all traffic filter requests is
“Accept”, it shall enable TFS for the STA. The previously established filter parameters, if any, remain in
effect when the AP transmits a TFS Response frame with any other Status.
When a traffic filter for group addressed frames is enabled at the AP, the group addressed frames are still
delivered, without regard to the frames matching the traffic filter, since other associated STAs may also
receive these frames. Because a STA using TFS can be in power save mode for an extended period of time,
group addressed frames that match the traffic filter might be delivered before the STA is aware that the
traffic filter has been matched. It is likely (but not guaranteed) that the STA does not receive those group
addressed frames matching the traffic filter at the scheduled group addressed delivery time. To detect when
this might have happened, the STA can request a notification frame be sent when requesting the
establishment of the traffic filter. If negotiated with the AP, a frame match is indicated to the non-AP STA
via a notification frame.
1807
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.24.12.2 TFS non-AP STA operation
To use the TFS, the non-AP STA’s SME that supports TFS shall issue an MLME-TFS.request primitive to
send a TFS Request frame. The MLME-TFS.request primitive shall include a valid TFSRequest parameter
as defined in the TFS Request elements.
The receipt of an MLME-TSF.confirm primitive with a valid TFSResponse parameter indicates to the
STA’s SME that the AP has processed the corresponding TFS request. The content of the TFSResponse
parameter provides the status of each of the TFS Request elements processed by the AP. A TFSResponse
parameter optionally contains modified filtering parameters for the corresponding TFS request.
A TFS Response frame in which the Status for all traffic filter requests is “Accept” indicates to the non-AP
STA that the filtering operation at the AP has started. Otherwise, the STA might use the information in the
TFS Response frame to form a new TFS request.
In order to request the AP to delete a traffic filter set (identified by a unique TFS ID) when a frame matches
to the traffic filter set, a non-AP STA shall set the Delete After Match subfield of the TFS Action Code field
of the TFS Request element in the TFS Request frame to 1.
In order to request a TFS Notify frame to be sent by the AP upon a frame match, a non-AP STA shall set the
Notify subfield of the TFS Action Code field of the TFS Request element in the TFS Request frame to 1.
After receiving a TFS Notify frame, in order to request the AP to resume generation of the TFS Notify frame
upon a future frame match, a non-AP STA shall transmit to the AP a TFS Notify Response frame containing
one or more TFS IDs.
The non-AP STA may indicate that it is no longer using a particular TFS Request element by transmitting a
TFS Request frame without that TFS Request element. The AP shall send a TFS Response frame with the
corresponding Status field value set to Accept, upon receipt of the TFS Request frame.
The non-AP STA may choose to terminate use of the TFS service by sending a TFS Request frame with no
TFS Request elements in the request thereby canceling all traffic filters at the AP.
11.24.12.3 TFS AP operation
When an AP’s SME receives an MLME-TFS.indication primitive with a valid TFSRequest parameter, it
shall issue an MLME-TFS.response primitive with a TFSResponse parameter indicating the status of the
associated request.
An AP establishes a traffic filtering agreement and starts the filtering operation defined by that traffic
filtering agreement when it receives a MLME-TFS.response primitive in which the Status for all traffic filter
requests is “Accept”.
When the AP establishes a traffic filtering agreement for a requesting STA, the AP shall add to the traffic
filtering agreement a traffic filter set that matches individually addressed EAPOL-Key frames addressed to
the requesting STA, with bits 0 and 1 of the TFS Action Code field set to 0, without any status indication for
this traffic filter set in the TFS Response frame.
When an AP’s SME receives an MLME-TFS.indication primitive with a valid TFSRequest parameter
having a requested TCLAS-based classifier which it is unable to provide, the SME shall issue an MLME-
TFS.response primitive indicating the status of the corresponding request and may include a TFSResponse
parameter having a suggested alternative TCLAS-based classifier.
1808
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When a traffic filtering agreement is established for a STA, the AP shall discard all individually addressed
frames destined for the STA until a frame is found that matches one or more traffic filter sets within the
traffic filtering agreement. When a frame is found that matches one or more of the traffic filter sets within
the traffic filtering agreement (a matching frame), the AP shall perform the following actions:
— If the traffic filter set action specifies both Delete After Match and Notify, then the AP shall generate
a single individually addressed TFS Notify frame for the frames matching to the traffic filter set
identified by the corresponding TFS ID. Subsequently, the AP shall delete the traffic filtering
agreement.
— If the traffic filter set action specifies Notify but not Delete After Match, then the AP shall generate
a single individually address TFS Notify frame for all frames matching to the traffic filter set
identified by the corresponding TFS ID. All traffic filter sets established at the AP for the non-AP
STA remain to be effective upon a match. If the AP receives a TFS Notify Response frame from
the corresponding non-AP STA, the AP resumes generation of a single individually addressed TFS
Notify frame for the next frame matching to the traffic filter sets identified by the TFS IDs included
in the TFS Notify Response frame. Otherwise, the AP shall not send additional TFS Notify frames
upon frame matches.
NOTE—Due to the operation of group addressed frame delivery, a group addressed frame that matches a traffic filter
might result in the STA receiving indication of the group addressed frame either before or after the group addressed
frame is transmitted by the AP, if the TFS Notify frame is queued in the STA’s power save queue. This might result in
the STA receiving the group addressed frame in some cases and not receiving it in other cases.
Upon receiving an MLME-TFS.indication primitive, the AP’s SME shall disregard any previous MLME-
TFS.indication primitive received from the same STA.
The AP shall terminate any TFS operation for a STA when no traffic filters remain for a STA or if the AP’s
SME receives an MLME-TFS.indication primitive with a null TFSRequest.
11.24.13 BSS max idle period management
If dot11BssMaxIdlePeriod is a nonzero, the STA shall include the BSS Max Idle Period element in the
Association Response frame or the Reassociation Response frame. Otherwise, the STA shall not include the
BSS Max Idle Period element in the Association Response frame or the Reassociation Response frame. A
STA may send protected or unprotected keepalive frames, as indicated in the Idle Options field.
The Max Idle Period field of the BSS Max Idle Period element indicates the time period during which a STA
can refrain from transmitting frames to its associated AP without being disassociated. A non-AP STA is
considered inactive if the AP has not received a Data frame, PS-Poll frame, or Management frame (protected
or unprotected as specified in this paragraph) of a frame exchange sequence initiated by the STA for a time
period greater than or equal to the time specified by the Max Idle Period field. If the Idle Options field
requires protected keepalive frames, then the AP may disassociate the STA if no protected frames are
received from the STA for a period indicated by the Max Idle Period field of the BSS Max Idle Period
element. If the Idle Options field allows unprotected or protected keepalive frames, then the AP may
disassociate the STA if no protected or unprotected frames are received from the STA for a duration
indicated by the Max Idle Period field of the BSS Max Idle Period element.
NOTE—The AP can disassociate or deauthenticate the STA at any time for other reasons even if the STA satisfies the
keep-alive frame transmission requirements.
11.24.14 Proxy ARP (including Proxy Neighbor Discovery) service
Implementation of the proxy ARP service is optional for a WNM STA. A STA that implements the proxy
ARP service has dot11ProxyARPImplemented equal to true. When dot11ProxyARPImplemented is true,
dot11WirelessManagementImplemented shall be true. When dot11ProxyARPActivated is true, the Proxy
ARP Service bit in the Extended Capabilities field shall be set to 1 to indicate that the AP supports the proxy
1809
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ARP service. When dot11ProxyARPActivated is false, the Proxy ARP Service bit shall be set to 0 to
indicate that the AP does not support the proxy ARP service.
When the AP sets the Proxy ARP field to 1 in the Extended Capabilities element, the AP shall maintain a
Hardware Address to Internet Address mapping for each associated station, and shall update the mapping
when the Internet Address of the associated station changes. When the IPv4 address being resolved in the
ARP request packet (IETF RFC 826) is used by a non-AP STA currently associated to the BSS, the proxy
ARP service shall respond on behalf of the STA to an ARP request (IETF RFC 925) or an ARP Probe (IETF
RFC 5227).
When an AP receives an ARP Request from one associated STA or from the DS with a Target IP Address
that corresponds to a second associated STA, the AP shall insert the second STA MAC address as the
Sender’s MAC Address in the ARP Response packet.
When an IPv6 address is being resolved, the Proxy Neighbor Discovery service shall respond with a
Neighbor Advertisement message (Section 4.4, IETF RFC 4861) on behalf of an associated STA to an
Internet Control Message Protocol version 6 (ICMPv6) Neighbor Solicitation message (Section 4.3, IETF
RFC 4861). When MAC address mappings change, the AP may send unsolicited Neighbor Advertisement
Messages on behalf of a STA.
NOTE—The Neighbor Solicitation message is used for both address discovery and duplicate address detection (IETF
RFC 4862).
11.24.15 Channel usage procedures
Channel Usage information is a set of channels provided by an AP to non-AP STAs for operation of a
noninfrastructure network or an off-channel TDLS direct link. The Channel Usage information provided by
the AP to the non-AP STA is to advise the STA on how to co-exist with the infrastructure network.
Implementation of Channel Usage is optional for a WNM STA. A STA that implements Channel
Usage has dot11ChannelUsageImplemented equal to true. When dot11ChannelUsageImplemented is true,
dot11WirelessManagementImplemented shall be true, or the STA shall be capable of acting as an S-AP
within a CCSS. A STA whose dot11ChannelUsageActivated is true shall support channel usage and shall set
to 1 the Channel Usage field of the Extended Capabilities elements that it transmits.
A non-AP STA that supports Channel Usage and is not associated to an AP prior to using a noninfrastructure
network or an off channel TDLS direct link may transmit a Probe Request frame including both Supported
Operating Classes and Channel Usage elements. A non-AP STA supporting Channel Usage may send a
Channel Usage Request frame at any time after association to the AP that supports the use of Channel Usage
to request the Channel Usage information for supported operating classes.
Upon receipt of a Channel Usage element in the Probe Request frame, the AP supporting Channel Usage
shall send a Probe Response frame including one or more Channel Usage elements. Upon receiving a
Channel Usage Request frame, the AP supporting Channel Usage shall send a Channel Usage Response
frame including one or more Channel Usage elements. Channel Usage elements shall include channels that
are valid for the regulatory domain in which the AP transmitting the element is operating and consistent with
the Country element in the Beacon or Probe Response frame; the Channel Usage elements shall not include
any other channels. When the Channel Usage element in a received Probe Request or Channel Usage
Request frame includes one or more Operating Class/Channel Pair fields, the Operating Class/Channel Pair
field(s) indicate(s) the requested non-AP STA operating class/channels for the usage mode indicated in the
frame.
The AP may send an unsolicited group addressed or individually addressed Channel Usage Response frame
to the STAs that have requested Channel Usage information if the corresponding Channel Usage
information needs to be updated. The Country element shall be included in the unsolicited and/or group
1810
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
addressed Channel Usage Response frame. The AP may include the Power Constraint information and
EDCA Parameter in the Channel Usage Response frame. The values of the fields in the Power Constraint
and EDCA Parameter Set elements included in the Channel Usage Response frame shall be the same values
of the fields in the Power Constraint and EDCA Parameter Set elements that are transmitted by the AP.
Upon receipt of a Channel Usage element in the Probe Response or Channel Usage Response frame, the
receiving STA may use the following:
— The channel usage information as part of channel selection processing to start a noninfrastructure
network or an off-channel TDLS direct link
— The Power Constraint element, if present, as part of determining its maximum transmit power for
transmissions for the noninfrastructure network or an off-channel TDLS direct link
— The EDCA Parameter Set element, if present, as part of determining its EDCA parameters for
transmissions for the noninfrastructure network or an off-channel TDLS direct link
— The QMF Policy element, if present and dot11QMFActivated is true, as part of determining its
classification of Management frames for transmissions for the noninfrastructure network or an
off-channel TDLS direct link
If either a recommended operating class, or a recommended channel, or both are not supported or
understood by the recipient, or if the operating country of the sender is unknown, the recipient shall discard
the corresponding channel usage recommendation. A STA that has not requested Channel Usage
information shall discard an unsolicited group addressed Channel Usage Response frame.
11.24.16 Group addressed transmission service
11.24.16.1 General
The group addressed transmission service provides delivery of group addressed frames and comprises the
two services, DMS and GCR. DMG STAs do not use GCR.
11.24.16.2 DMS procedures
In this subclause, the following terms are used:
— DMS provider: An AP, PCP, or DMG STA associated with a PCP that provides DMS.
— DMS recipient: A non-AP STA that uses DMS.
Directed multicast service (DMS) is a service that may be provided by a DMS provider to its associated
DMS recipients that support DMS, where the DMS provider transmits group addressed MSDUs as
individually addressed A-MSDUs.
In a PBSS, DMS is a service that may be provided by any STA to other STAs associated in the same PBSS
that support DMS, where the STA transmits group addressed MSDUs as individually addressed A-MSDUs.
If the PCP of the PBSS has the PCP Forwarding field within the PCP’s DMG Capabilities element set to 0, a
non-PCP STA in the PBSS shall not use the PCP as a DMS provider in the PBSS.
Implementation of DMS is optional for a WNM STA and mandatory for a robust AV streaming STA (as
defined in 11.27.1). A STA that implements DMS has dot11DMSImplemented equal to true. When
dot11DMSImplemented is true, at least one of dot11WirelessManagementImplemented and
dot11RobustAVStreamingImplemented shall be true When dot11DMSImplemented is true, either
dot11HighThroughputOptionImplemented or dot11DMGOptionImplemented shall be true. A STA whose
dot11DMSActivated is true shall support DMS and shall set to 1 the DMS field of the Extended Capabilities
elements that it transmits.
1811
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A DMS recipient that supports DMS may request use of DMS of one or more flows by sending a DMS
Request frame or Reassociation Request frame that includes a DMS Request element containing one or
more DMS Descriptors with the Request Type field set to “Add” per flow. Each DMS Descriptor field in the
DMS Request element identifies group addressed frames that shall be transmitted to the requesting DMS
recipient as individually addressed frames in addition to the group address frame transmission. In the
TCLAS element, the Classifier Type subfield shall be set to the value 0, 1, or 4, and the Destination Address
or Destination IP Address subfield shall be set to the multicast address of the flow that the STA requests to
receive as individually addressed frames. In the TSPEC element, the STA may define the characteristics and
QoS expectations of the corresponding traffic flow.
Upon receipt of a DMS Request frame or Reassociation Request frame from a DMS recipient, the DMS
provider shall respond with a corresponding DMS Response frame or Reassociation Response frame. The
response frame shall contain a matching (i.e., as the same DMSID) DMS Status field for each received DMS
Descriptor field preserving the order present in the request frame.
NOTE—There is no requirement that the number of DMS Request elements and the number of DMS Response elements
match. There is no requirement that the number of DMS Descriptor fields within any DMS Request element matches the
number of DMS Status fields within any DMS Response element.
If the DMS provider accepts a DMS request identified by a DMS Descriptor, the Response Type field of the
corresponding DMS Status field in the DMS Response element shall be set to “Accept” and a nonzero
DMSID is assigned. A Response Type value of “Deny” shall be set in the corresponding Response Type
field of the DMS Status field in the DMS Response element when the DMS provider denies a DMS request
identified by a DMS Descriptor, and the DMSID shall be set to 0. If the Response Type field is set to
“Accept” or “Denied,” then the TCLAS Elements, TCLAS Processing Element, TSPEC Element and
Optional Subelements fields of a DMS Status field in a DMS Response element shall be copied from the
respective TCLAS Elements, TCLAS Processing Element, TSPEC Element and Optional Subelements
fields of the corresponding DMS request. When one or more STAs send a DMS request to an DMS provider,
containing a DMS descriptor with a set of TCLAS element and TCLAS Processing elements that are
identical irrespective of ordering to another successfully received DMS request that is not yet terminated,
the DMS provider shall assign the same DMSID as was assigned to the previous DMS request.
When the DMS provider denies the DMS Request, it may suggest an alternative TCLAS-based classifier by
including one or more TCLAS elements and an optional TCLAS Processing element. The DMS provider
may include fewer TCLAS elements in the DMS Response element than were present in the request; when
the DMS provider’s response includes a single TCLAS element, it shall not include a TCLAS Processing
element. If the DMS provider changes a TCLAS element’s Classifier Type field in the DMS Response
element but is unable to suggest a value for the Classifier Mask field, it shall set that field to 0. If the DMS
provider changes a TCLAS element’s Classifier Type field or Classifier Mask field in the DMS Response
element but is unable to suggest values for one or more Classifier Parameter subfields, it shall set those
subfields to 0.
A DMS recipient receiving a DMS Response frame containing a modified TCLAS element having a
Classifier Mask field equal to 0 or having one or more Classifier Parameter subfields equal to 0 shall
interpret the values of 0 to mean that no suggested value has been provided by the DMS provider.
If the requested DMS is accepted by the DMS provider, the DMS provider shall send subsequent group
addressed MSDUs that match the frame classifier specified in the DMS Descriptors to the requesting STA as
A-MSDU subframes within an individually addressed A-MSDU frame (see 9.3.2.2 and 10.12). The
A-MSDU shall be formatted as specified in 9.3.2.2 which includes the A-MSDU subframe headers’ DA
address set to the multicast address for the corresponding MSDUs. The DMS provider shall continue to
transmit the matching frames as group addressed frames (see 10.3.6, and 11.2.3.16) if at least one associated
STA has not requested DMS for these frames.
1812
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A DMS recipient may request modification of the traffic characteristics or attributes of one or more accepted
DMS traffic flows by sending a DMS Request frame or Reassociation Request frame containing one or more
DMS Descriptors with the Request Type set to “Change” and with the DMSIDs that identify the DMS traffic
flows to be modified. If the Request Type of a DMS Descriptor is set to “Change,” then the values of at least
one of the TSPEC Element and Optional Subelement fields shall be different from those of the accepted
DMS traffic flow corresponding to the DMSID.
If the DMS provider accepts a DMS change request identified by a DMS Descriptor, the Response Type
field of the corresponding DMS Status field in the DMS Response element shall be set to “Accept” and the
DMSID shall be set to that of the DMS Descriptor. If the DMS provider denies a DMS change request
identified by a DMS Descriptor, the Response Type field of the corresponding DMS Status field in the DMS
Response element shall be set to “Deny” and the DMSID shall be set to that of the DMS Descriptor. When
the DMS provider denies a DMS change request identified by a DMS Descriptor, the existing DMS traffic
flow of the corresponding DMSID shall remain unchanged.
The DMS recipient may request removal of one or more accepted DMS traffic flows by sending a DMS
Request frame or Reassociation Request frame that includes a DMS Request element containing one or
more DMS Descriptors with the Request Type set to “Remove” and the DMSID field set to that the DMSID
of the accepted DMS traffic flow to be removed. The DMS Length field in this DMS Descriptor is set to 1.
The TLCAS Elements, TCLAS Processing Element TSPEC Element and Optional Subelements fields shall
not be included in the DMS Descriptor if the Request Type is set to “Remove.” The DMS provider shall
terminate individually addressed frame delivery for the requested group addressed frames identified by the
DMSID for the requesting DMS recipient upon receipt of a DMS Request frame or Reassociation Request
frame with the Request Type field equal to “Remove.” The DMS provider shall respond to the termination
request by sending a DMS Response frame including the corresponding DMSID and a Response Type value
of “Terminate” in the Response Type field of the corresponding DMS Status field. The DMS Length field in
this DMS Status field is set to 3. The TLCAS Elements, TCLAS Processing Element, TSPEC Element and
Optional Subelement fields shall not be included in the DMS Status field if the Response Type field is set to
“Terminate.”
The DMS provider may send an unsolicited DMS Response frame at any time to cancel a granted DMS
identified by the DMSID by including the DMSID and a Response Type value of “Terminate” in the DMS
Status field. The DMS provider may reject a new DMS or cancel a granted DMS at any time based on
network condition, for example the number of associated STAs and channel load.
The DMS recipient shall keep a list of group addresses for which the DMS recipient has requested DMS and
that have been accepted by the DMS provider. The requesting STA shall discard group addressed frames
that match a group address in this list until the DMS has been terminated. When the DMS is terminated, and
if the sequence number value is provided in the Last Sequence Control field in the DMS Response frame,
using the value of the Last Sequence Control field, the DMS recipient shall discard the group addressed
frames that are the duplicates of the individually addressed frames.
NOTE—When the Last Sequence Control field in the DMS Response frame is not supported at the DMS provider (i.e.,
the sequence number value is not provided in the field), and a multicast MSDU that has sent using both individually
addressed and group addressed frame transmission, termination of the DMS stream by the DMS provider might result in
a DMS recipient receiving undetectable duplicate MSDUs that are not filtered out by the MAC.
If the length of the DMS Descriptors exceeds 255 octets, then multiple DMS Request elements shall be
included, each containing only those DMS Descriptors that are completely contained within 255 octets. If
the length of the DMS status fields exceeds 255 octets, then multiple DMS Response elements shall be
included, each containing only those DMS Status fields that are completely contained within the first 255
octets.
1813
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the DMS recipient supports both DMS and FMS, the DMS recipient shall not request both services for the
same group addressed frames simultaneously. The DMS recipient may request the different service (DMS
vs. FMS) for different group addressed frames.
If the DMS provider supports both DMS and TFS, the DMS provider shall first apply TFS to the frame and
then apply DMS.
11.24.16.3 GCR procedures
11.24.16.3.1 Overview
Groupcast with retries (GCR) is a flexible service to improve the delivery of group addressed frames while
optimizing for a range of criteria. GCR service may be provided by the AP to associated STAs in an
infrastructure BSS or by a mesh STA to its peer mesh STAs in a mesh BSS. GCR uses the setup,
modification, and termination procedures defined 11.24.16.2. The differences between GCR procedures and
DMS procedures are as follows:
a) A GCR agreement applies to a single group address and, if a TCLAS Processing element is present,
it has the Processing subfield value set to 0, whereas a DMS flow is not restricted to a single group
address.
b) DMS offers multicast-to-unicast conversion only, whereas GCR includes several retransmission
policies and delivery methods.
A non-DMG STA with dot11RobustAVStreamingImplemented true shall implement the GCR procedures
defined in 11.24.16.3.2 to 11.24.16.3.6. When dot11RobustAVStreamingImplemented is true,
dot11DMSImplemented and dot11HighThroughputOptionImplemented shall be true. A STA that
implements advanced GCR supports GCR block ack (11.24.16.3.7) and GCR-SP (11.24.16.3.8) and has
dot11AdvancedGCRImplemented equal to true. When dot11AdvancedGCRImplemented is true,
dot11RobustAVStreamingImplemented shall be true. In a mesh BSS, a STA that implements GCR has
dot11MeshGCRImplemented equal to true. When dot11MeshGCRImplemented is true,
dot11HighThroughputOptionImplemented shall be true.
DMS allows the transmission of group addressed MSDUs as individually addressed A-MSDUs and is
particularly suited to small numbers of group members. It provides a high level of reliability but has low
scalability as the efficiency decreases and delay increases proportionally to the number of group members.
GCR employs the DMS Request and DMS Response elements with the addition of GCR Request and
Response subelements, respectively, for administering the announcement, setup, modification, and teardown
of GCR services between an AP and non-AP STAs or between peer mesh STAs. The DMS procedures and
state machine of 11.24.16.2 shall apply to GCR with the extensions and constraints specific to GCR
described below in 11.24.16.3.3 to 11.24.16.3.8.
Along with the No-Ack/No-Retry or non-GCR (defined in 10.3.6) and the DMS (defined in 11.24.16.2)
retransmission mechanisms, GCR defines two additional retransmission policies for group addressed
frames:
— GCR unsolicited retry
— GCR block ack
When using the GCR unsolicited retry retransmission policy for a group address, the STA providing GCR
service retransmits an MSDU one or more times (subject to applicable retry or lifetime limits) to increase the
probability of correct reception at STAs that are listening to this group address. The decision to retransmit
these MSDUs is implementation dependent. GCR unsolicited retry is particularly suited to use with large
numbers of group members as it has moderate delay, efficiency, and reliability, but high scalability.
1814
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The GCR block ack retransmission policy extends the block acknowledgment mechanism to group
addressed frames. The STA providing the GCR service initiates block ack agreements with each STA
receiving GCR frames that supports GCR block ack for a particular group address. Once this block ack
agreement is in place, the STA providing GCR service regularly sends BlockAckReq frames to the STAs
receiving the frames to ascertain the reception status of MSDUs related to this group address, as described in
10.24.10. This allows the STA providing GCR service to discover MSDUs that have not been received and
to schedule their retransmission. GCR block ack is particularly suited to use with moderate numbers of
group members as it has moderate delay, high efficiency, and moderate scalability and reliability.
The GCR service has two delivery methods for group addressed frames:
— Non-GCR-SP
— GCR-SP (see 11.24.16.3.8)
The non-GCR-SP delivery method may be provided using one or more of the following:
— FMS (see 11.2.3.16)
— Transmit frames in a GCR stream after the DTIM Beacon frame if any STA in the GCR group is in
PS mode
— Transmit frames at any time if all STAs in the GCR group are in active mode in an infrastructure
BSS
— In accordance with 14.14 in a mesh BSS
GCR-SP transmits GCR group addressed frames at intervals, where the interval between transmissions
might be smaller than the beacon interval. Compared to non-GCR-SP, GCR-SP might provide lower delay
and jitter.
11.24.16.3.2 GCR group membership procedures
The procedures described in 11.24.16.3.3 to 11.24.16.3.8 depend upon the AP or mesh STA knowing the
membership of the multicast groups of STAs that support GCR.
One method for an AP to discover the multicast groups that its associated STAs are receiving or for a mesh
STA to discover the multicast groups that its peer mesh STAs are receiving is to use the Group Membership
Request frame (as defined in 9.6.19.4) to request the contents of the dot11GroupAddressesTable of its
associated STAs or peer mesh STAs.
Other methods of group membership detection are also possible, using information that is outside the scope
of this standard. For example, group membership detection could be achieved by inspecting the protocol
messages of IETF RFC 3376.46
An AP may transmit a Group Membership Request frame as an individually addressed frame to an
associated STA that has indicated that it supports robust AV streaming (as indicated by the Robust AV
Streaming bit equal to 1 in the Extended Capabilities element) to request the associated STA’s
dot11GroupAddressesTable. An AP shall not send a Group Membership Request frame to an associated
STA that has the Robust AV Streaming bit equal to 0 in its Extended Capabilities element.
A STA for which dot11GCRActivated or dot11MeshGCRActivated is true shall reply to a Group
Membership Request frame by sending a Group Membership Response frame with the Dialog Token field
set to the value from the Group Membership Request frame, the Address Count field set to the number of
entries in the dot11GroupAddressesTable, and the Group Address List field set to the group MAC addresses
in the dot11GroupAddressesTable. A STA for which dot11GCRActivated or dot11MeshGCRActivated is
46
IETF RFC 3376, Internet Group Management Protocol (IGMP).
1815
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
true shall set dot11GCRGroupMembershipAnnouncementActivated to true upon reception of a Group
Membership Request frame.
A STA for which dot11GCRGroupMembershipAnnouncementActivated and at least one of
dot11MeshGCRActivated and dot11GCRActivated are true shall send an unsolicited Group Membership
Response frame with the Dialog Token field set to 0, the Address Count field set to the number of entries in
the dot11GroupAddressesTable, and the Group Address List field set to the group MAC addresses in the
dot11GroupAddressesTable, every time the contents of the dot11GroupAddressesTable is modified.
If an unsolicited Group Membership Response frame is sent by an associated STA, the frame shall be
transmitted as an individually addressed frame to the AP with which it is associated. If an unsolicited Group
Membership Response frame is sent by a mesh station in a mesh BSS, the frame shall be transmitted as a
broadcast frame.
11.24.16.3.3 GCR setup procedures
An AP with dot11GCRActivated true may transmit to an associated non-AP STA an unsolicited individually
addressed DMS Response frame that contains one DMS Status field with a GCR Response subelement per
group address, if it detects that the associated non-AP STA meets all of the following conditions:
— Robust AV Streaming was equal to 1 in the Extended Capabilities element in the most recently
received (Re)Association Request frame from the non-AP STA.
— The non-AP STA is receiving one or more group addresses for which there is an active GCR service.
— The non-AP STA does not have a GCR agreement for one or more of these group addresses.
A mesh STA with dot11MeshGCRActivated true may transmit to a peer mesh STA an unsolicited
individually addressed DMS Response frame that contains one DMS Status field with a GCR Response
subelement per group address, if it detects that the peer mesh STA meets all of the following conditions:
— Mesh GCR was equal to 1 in the Extended Capabilities element in the most recently received mesh
beacon from the peer mesh STA.
— The peer mesh STA is receiving one or more group addresses for which there is an active GCR
service.
— The peer mesh STA does not have a GCR agreement for one or more of these group addresses.
Each DMS Status field includes a TCLAS element to identify the GCR group address, the DMSID
corresponding to this GCR traffic flow, and other associated parameters. The Status subfield of this DMS
Status field shall be set to “GCR Advertise.” A STA that receives this DMS Response frame from its AP
may initiate a GCR agreement for one or more of the group addresses contained in the frame.
A STA requests use of the GCR service for a group address by sending a DMS Descriptor (as described in
11.24.16.2) with the following modifications:
— The DMS Descriptor shall contain one TCLAS element with the frame classifier type equal to 0
(Ethernet parameters), one TSPEC element, and one GCR Request subelement.
— In addition, the DMS Descriptor may contain other TCLAS elements.
— When there are multiple TCLAS elements, a TCLAS Processing element shall be present, and the
Processing subfield in the TCLAS Processing element shall be set to 0. Otherwise, no TCLAS
Processing elements shall be present in the DMS Descriptor.
— The TSID subfield within the TS Info field of the TSPEC element shall be reserved. Since the AP
might choose a delivery method of GCR-SP, the non-AP STA should set the Minimum Service
Interval, Maximum Service Interval, and Service Start Time fields in the TSPEC element to indicate
the STA’s preferred wakeup schedule. In a mesh BSS, the Delivery Method field shall not be set to
“GCR-SP.”
1816
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The GCR Request subelement specifies the retransmission policy and delivery method requested by
the non-AP STA for the group addressed stream.
A STA shall not request transmission of a group address via the GCR service while it has an active DMS for
this group address. A STA shall not request transmission of a group address via DMS while it has an active
GCR service for this group address.
An AP or mesh STA accepts a GCR request by sending a DMS Response frame with a DMS Response
element that contains a DMS Status field with the Response Type field set to “Accept” (as described in
11.24.16.2) with the following modifications:
— The DMS Status field shall include a GCR Response subelement indicating the retransmission
policy, delivery method, and GCR concealment address for the group addressed stream. The
Retransmission Policy field shall not be set to “No Preference.” The Delivery Method field shall not
be set to “No Preference.” The GCR Concealment Address field of the GCR Response subelement
shall be set to dot11GCRConcealmentAddress. In a mesh BSS, the Delivery Method field shall not
be set to “GCR-SP.”
— If the GCR group addressed stream is subject to the GCR-SP delivery method, then the AP shall also
include a Schedule element in the DMS Status field indicating the wakeup schedule for the group
addressed stream.
— If a TSPEC Element is included, the TSID subfield shall be set to 0.
For each GCR Request subelement, the AP or mesh STA may
— Adopt the requested retransmission policy and delivery method, or
— Maintain its existing retransmission policy and delivery method, or
— Select an alternate retransmission policy and delivery method, or
— Deny GCR service for the group addressed stream.
In an infrastructure BSS, the retransmission policy shall not be GCR block ack for a GCR group address
while the AP has a GCR agreement for the group address with a non-AP STA that had the Advanced GCR
field equal to 0 in the Extended Capabilities element in the (Re)Association Request frame most recently
received by the AP.
In a mesh BSS, the retransmission policy shall not be GCR block ack for a GCR group address while the
mesh STA has a GCR agreement for the group address with a peer mesh STA that had the Mesh GCR field
equal to 0 in the Extended Capabilities element.
An AP or mesh STA denies a GCR request by sending a DMS Response frame with a DMS Response
element that contains a DMS Status field with
— The Response Type field set to “Deny” (as described in 11.24.16.2) and
— An empty GCR Response subelement.
If an AP or mesh STA denies a GCR request, it may suggest an alternative TCLAS-based classifier by
including one or more TCLAS elements and an optional TCLAS Processing element (as described in
9.4.2.33). One TCLAS element shall be included in the DMS Descriptor with the frame classifier type equal
to 0 (Ethernet parameters). Other TCLAS elements may be included in the DMS Descriptor, but, if present,
a TCLAS Processing element with the Processing subfield equal to 0 shall also be included.
If a STA requesting GCR service determines that one or more GCR Response subelements are unacceptable,
then the STA shall discard any received ADDBA Request frames for the unacceptable GCR streams and
shall send a new DMS Request frame containing a DMS Request element with one DMS Descriptor for each
1817
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
unacceptable GCR stream. The DMSID fields shall be set to the DMSIDs of the unacceptable streams, and
the Request Type field shall be set to “Remove.”
In an infrastructure BSS, if the non-AP STA accepts the response to its GCR request, the non-AP STA shall
set dot11GCRConcealmentAddress to the value contained in the GCR Concealment Address field of the
GCR Response subelement.
In a mesh BSS, if a STA requesting GCR service accepts the response to its GCR request, it shall add to
dot11GroupAddressesTable the value contained in the GCR Concealment Address field of the GCR
Response subelement.
In a mesh BSS, a GCR agreement instance is identified by a GCR agreement instance identifier. The mesh
GCR agreement instance consists of the DMSID, localMAC, peerMAC, and concealment address.
For each group addressed stream requested by the non-AP STA and accepted by the AP, the AP shall
immediately initiate a block ack negotiation if both of the following conditions are true:
— The AP advertised an Advanced GCR field equal to 1 in its Extended Capabilities element.
— The non-AP STA advertised an Advanced GCR field equal to 1 in the Extended Capabilities
element in the (Re)Association Request frame most recently received by the AP.
For each group addressed stream requested by a mesh STA’s peer (STA1), the mesh STA (STA2) receiving
the request shall immediately initiate a block ack negotiation if STA2 transmitted a Mesh GCR field equal to
1 in the Extended Capabilities element in its mesh Beacon frame and STA2 received a mesh Beacon frame
from STA1 in which the Mesh GCR field in the Extended Capabilities element is equal to 1.
If all of the above conditions are true, the AP or mesh STA shall immediately initiate a block ack negotiation
by sending an ADDBA Request frame to the STA that originated the GCR request. The Block Ack Policy
subfield in the Block Ack Parameter Set field within the ADDBA Request frame shall not be set to 0. The
TID subfield in the Block Ack Parameter Set field within the ADDBA Request frame shall be set to 0. The
A-MSDU Supported subfield within the ADDBA Request frame shall be set to 1 (A-MSDU permitted). The
Starting Sequence Number field within the ADDBA Request frame shall be greater than (modulo 4096) the
last sequence number of the last group address frame transmitted before the ADDBA Request frame. A STA
shall maintain this block ack agreement for the duration of its GCR agreement, irrespective of whether GCR
block ack is the current retransmission policy. While the retransmission policy of the GCR group addressed
stream is DMS, the STA receiving GCR frames shall suspend its block ack processing for the group
addressed stream.
NOTE Having a block ack agreement with all members of a GCR group address allows the AP or mesh STA to change
the GCR retransmission policy dynamically.
For each GCR agreement, there shall be only one retransmission policy and delivery method active at any
time. A GCR agreement between a non-AP STA and an AP or between peer mesh STAs shall begin when
the STA providing GCR service successfully transmits an individually addressed DMS Response frame with
a DMS Response element containing a DMS Status field that has the Status field set to “Accept” (as
described in 11.24.16.2) with the DMS Status field including a GCR Response subelement.
11.24.16.3.4 GCR frame exchange procedures
In an infrastructure BSS, a GCR block ack agreement exists between a non-AP STA and an AP for a group
addressed stream from when the non-AP STA successfully transmits an ADDBA Response frame until one
of the following situations occurs:
— The AP or non-AP STA successfully transmits a DELBA frame to the other party.
— The GCR agreement no longer exists.
1818
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In a mesh BSS, a GCR block ack agreement exists between a mesh STA and its peer mesh STA for a group
addressed stream from the time when the mesh STA successfully transmits an ADDBA Response frame to
the peer mesh STA until one of the following situations occurs:
— The mesh STA or the peer mesh STA successfully transmits a DELBA frame to the other party.
— This GCR block ack agreement expires (see 10.24.5).
— The GCR agreement is terminated.
An AP or a mesh STA may transmit a group addressed stream via the No-Ack/No-Retry (non-GCR; see
10.3.6) service and GCR service simultaneously. Each frame shall be transmitted via the No-Ack/No-Retry
retransmission policy before it is transmitted via the GCR service, except when using the GCR-SP delivery
method. The AP may transmit each frame via the No-Ack/No-Retry retransmission policy before or after it
transmits the frame via the GCR service when using the GCR-SP delivery method. A STA providing GCR
service may switch between the DMS, GCR block ack, or GCR unsolicited retry retransmission policies, but
only one delivery mode may be active at any given time for each GCR group address.
An AP or mesh STA shall transmit a frame belonging to a group address via the GCR service if any
associated STA or peer mesh STA has a GCR agreement for the group address and, otherwise, does not
transmit the frame via the GCR service.
In an infrastructure BSS, an AP shall transmit a frame belonging to a group address via the No-Ack/No-
Retry service if one or more of the following situations occur:
— The group address is the broadcast address.
— The group address is not the broadcast address, and at least one associated STA has the Robust AV
Streaming bit equal to 0 in the Extended Capabilities element of the STA’s most recent
(Re)Association Request frame and has been determined by the AP to be a member of the group
address (how this determination is made is out of the scope of this standard).
— The group address is not the broadcast address, at least one non-AP STA has a block ack agreement
for the group address, and the frame precedes the start of the block ack agreement (the sequence
number of the frame is less than the starting sequence number of the block ack agreement, as
described in 10.24.2).
In a mesh BSS, a mesh STA providing GCR service shall transmit a frame belonging to a group address via
the No-Ack/No-Retry service if one or more of the following situations occur:
— The group address is the broadcast address.
— The group address is not the broadcast address, and at least one peer mesh STA has the Mesh GCR
bit equal to 0 in the Extended Capabilities element of the STA’s most recent mesh Beacon frame and
has been determined to be a member of the group address (how this determination is made is out of
the scope of this standard).
— The group address is not the broadcast address, at least one peer mesh STA has a block ack
agreement for the group address, and the frame precedes the start of the block ack agreement (the
sequence number of the frame is less than the starting sequence number of the block ack agreement,
as described in 10.24.2).
When the AP updates the retransmission policy, the AP shall set the Last Sequence Control field in the GCR
Response subelement to the sequence number of the MPDU corresponding to the GCR traffic flow that is
being updated that was delivered prior to the change in retransmission policy.
To avoid undetected retries being passed up at a receiver’s MAC SAP, duplicate detection and removal for
group addressed frames is required in STAs with dot11RobustAVStreamingImplemented true or
dot11MeshGCRImplemented true (see 10.3.2.11).
GCR frames shall be QoS Data frames (with QoS subfield of the Subtype subfield set to 1).
1819
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the block ack agreement is successfully established for the group addressed stream and the delivery
method for the group addressed stream is GCR-SP, then the non-AP STA is awake for subsequent SPs (see
11.24.16.3.8).
A STA may request a change of GCR service for a group addressed stream by sending a DMS Descriptor
with the DMSID identifying the group address and the Request Type field set to “Change” (as described in
11.24.16.2) with the following modifications:
— The DMS Descriptor shall contain zero TCLAS elements, zero TCLAS Processing elements, one
TSPEC element, and one GCR Request subelement.
— The TSPEC element and GCR Request subelement of this DMS Descriptor shall together contain at
least one field that is different from the original TSPEC element and GCR Request subelement
identified by the DMSID.
An AP or mesh STA may update the retransmission policy, delivery method, and schedule for any reason,
such as the size of the group changes, the capabilities of the members of the group change, GCR Request
subelements for the group are received, or multicast diagnostics are needed. The AP or mesh STA advertises
the current settings upon a change and periodically by either of the following methods:
— Transmitting an unsolicited DMS Response frame with the current settings addressed to the GCR
concealment address. This DMS Response frame shall be scheduled for delivery at the appropriate
DTIM interval or SP in which all STAs within the group are awake to receive the frame. One
TCLAS element shall be included with the frame classifier type equal to 0 (Ethernet parameters).
Other TCLAS elements may be present, but if present, a TCLAS Processing element with the
Processing subfield equal to 0 shall also be included. One TSPEC element and one GCR subelement
shall be included per DMS Descriptor in the DMS Response element of the DMS Response frame to
identify each GCR stream. The DMSID that identifies the GCR stream shall be included in the DMS
Descriptor. Each Status field in the DMS Status fields included in the frame shall be set to “GCR
Advertise.”
— Transmitting unsolicited DMS Response frames with the current settings individually addressed to
each GCR group member. Each GCR stream is identified by the DMSID in a DMS Status field in
the DMS Response element of the DMS Response frame. These DMS Status fields shall not include
a TCLAS element, TSPEC element, or GCR subelement. Each Status field in the DMS Status fields
included in the frame shall be set to “GCR Advertise.”
A STA receiving GCR frames shall recover from missing group addressed DMS Response frames
containing GCR Response subelements that advertise a changed retransmission policy or delivery method
according to Table 11-13 or Table 11-14, respectively.
Table 11-13—STA recovery procedures for a changed retransmission policy
Actual retransmission
Current retransmission
policy being used by the
policy state at STA Recovery procedure
AP or mesh STA
receiving GCR frames
providing GCR service
GCR unsolicited retry or No-Ack/No-Retry A STA receiving GCR frames shall cancel the GCR
GCR block ack service for the group address by sending a DMS
Response frame that contains a DMS Descriptor with
the Request Type set to “Remove” when no frames for
the group address are received via the GCR service
after a period of dot11GCRPolicyChangeTimeout.
1820
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-13—STA recovery procedures for a changed retransmission policy (continued)
Actual retransmission
Current retransmission
policy being used by the
policy state at STA Recovery procedure
AP or mesh STA
receiving GCR frames
providing GCR service
DMS GCR unsolicited retry or A STA receiving GCR frames shall update its current
GCR block ack retransmission policy of the GCR stream to GCR
unsolicited retry upon receiving an A-MSDU for the
DMS group address concealed via the GCR
concealment address.
GCR unsolicited retry or DMS A STA receiving GCR frames shall update its current
GCR block ack retransmission policy of the GCR stream to DMS upon
receiving an A-MSDU with the RA field equal to the
non-AP STA’s individual address and the DA field of
the A-MSDU subframe equal to the GCR group
address.
GCR unsolicited retry GCR block ack A STA receiving GCR frames shall update its current
retransmission policy of the GCR stream to GCR block
ack upon receiving a BlockAckReq frame with a GCR
Group Address subfield equal to the GCR group
address.
GCR block ack GCR unsolicited retry A STA receiving GCR frames shall update its current
retransmission policy of the GCR stream to GCR
unsolicited retry if MSDUs for the GCR group address
concealed via the GCR concealment address are being
received yet no BlockAckReq frames for the GCR
group address are received after a period of
dot11GCRPolicyChangeTimeout.
Table 11-14—Non-AP STA recovery procedures for a changed delivery method
Current delivery method Actual delivery method
Recovery procedure
state at non-AP STA being used by the AP
Non-GCR-SP GCR-SP A non-AP STA shall update the current delivery
method state of the GCR stream to GCR-SP if
a) No frames with the More Data subfield in the
Frame Control field equal to 1 for the GCR
stream are received for a period of
dot11GCRPolicyChangeTimeout, and
b) At least one frame for the GCR stream with the
More Data subfield in the Frame Control field
equal to 0 is received.
Note that upon detecting condition a), the STA should
enter the awake state in order to assist with detecting
condition b).
GCR-SP Non-GCR-SP A non-AP STA shall update the current delivery
method of the GCR stream to Non-GCR-SP if no
frames with the More Data subfield in the Frame
Control field equal to 0 for the GCR stream are
received for a period of
dot11GCRPolicyChangeTimeout and at least one
frame for the GCR stream with the More Data subfield
in the Frame Control field equal to 1 is received.
1821
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A GCR agreement between a non-AP STA and an AP or between peer mesh STAs shall end (as described in
11.24.16.2) when one of the following situations occurs:
— In an infrastructure BSS, the AP deauthenticates or disassociates the non-AP STA, or
— In a mesh BSS, the mesh STA providing GCR service tears down the peer link to the mesh STA
receiving GCR frames, or
— The non-AP STA or mesh STA receiving GCR frames successfully transmits a DMS Request frame
to the AP or mesh STA providing GCR service containing a DMS Request element that has a DMS
Descriptor with the DMSID identifying the group addressed stream and the Request Type field set
to “Remove,” or
— The AP or a mesh STA providing GCR service successfully transmits an individually addressed
DMS Response frame with a DMS Response element containing a DMS Status field with the
DMSID identifying the group addressed stream that has the Status field set to “Terminate.”
A GCR agreement between a non-AP STA and an AP or between peer mesh STAs shall end (as described in
11.24.16.2) with the following modifications:
— The DMS Status field shall include a GCR Response subelement.
— The DMS Response frame may be transmitted by an AP to the GCR concealment address or as an
individually addressed frame to each STA that has an active GCR agreement for this GCR group
address. The DMS Response frame shall be transmitted by a non-AP STA or mesh STA as an
individually addressed frame to the STA that it has an active GCR agreement for this GCR group
address.
A cancellation of a GCR agreement shall also cause the block ack agreement to be canceled for the GCR
stream.
11.24.16.3.5 Concealment of GCR transmissions
Concealment prevents group addressed frames transmitted via the GCR unsolicited retry or GCR block ack
retransmission policies from being passed up through the MAC SAPs of GCR-incapable STAs.
GCR group addressed MSDUs shall be sent in an A-MSDU when
— Retransmitted via the GCR unsolicited retry or GCR block ack retransmission policies or
— Transmitted via the GCR-SP delivery method.
The MPDU containing this A-MSDU shall have the Address 1 field set to dot11GCRConcealmentAddress
and the Retry subfield of the Frame Control field set to 1. The DA field in the A-MSDU subframe shall
contain the GCR group address that is being concealed (i.e., the same value as the DA field for non-GCR
group addressed delivery). One A-MSDU subframe shall be contained within one A-MSDU frame. GCR
group addressed MSDUs retransmitted via the GCR unsolicited retry or GCR block ack retransmission
policies shall set the Sequence Control field of the MPDU containing this A-MSDU to the same value as the
Sequence Control field of the frame that contained the corresponding MSDU that was transmitted with the
Retry subfield equal to 0. The first transmission attempt of a GCR group addressed MSDU transmitted via
the GCR-SP delivery method shall set the Sequence Control field of the MPDU containing this A-MSDU
according to the procedures defined in 10.3.2.11.
A STA with dot11RobustAVStreamingImplemented true or dot11MeshGCRImplemented true shall not use
its GCR concealment address for any purpose other than the transmission of GCR streams.
A STA with dot11RobustAVStreamingImplemented true or dot11MeshGCRImplemented true and with a
GCR agreement shall add the GCR concealment address from the GCR Response subelement to the STA’s
dot11GroupAddressesTable.
1822
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An AP with dot11RobustAVStreamingImplemented true shall not send an MSDU to the DS that has the DA
field set to the GCR concealment address.
The Individual/Group Address bit (LSB of octet 0) of dot11GCRConcealmentAddress shall be set to 1.
11.24.16.3.6 GCR unsolicited retry
A STA supports the GCR unsolicited retry retransmission policy if dot11RobustAVStreamingImplemented
or dot11MeshGCRImplemented is true; otherwise, the STA does not support the GCR service with
retransmission policy equal to GCR unsolicited retry.
An AP or a mesh STA adopting the GCR unsolicited retry retransmission policy for a GCR group address
chooses a lifetime limit for the group address. The AP or a mesh STA may vary the lifetime limit for the
group address at any time and may use different lifetime limits for different GCR group addresses. An AP
adopting the GCR unsolicited retry retransmission policy for a GCR group address shall transmit each
MSDU according to 11.24.16.3.5, subject to the lifetime and retry limits. Transmission uses the backoff
procedure described in 10.22.2.11.2.
If a block ack agreement has successfully been established for a group addressed stream that is delivered
using the GCR unsolicited retry retransmission policy, the STA shall follow the duplicate detection
procedures defined in 10.3.2.11 and 10.24.4.
If a block ack agreement has successfully been established for all STAs receiving a GCR group address, for
a group delivered using the GCR unsolicited retry retransmission policy, the AP may retransmit any of the
last m A-MSDUs that have the DA field in the A-MSDU subfield set to the GCR group address, where m is
GCR buffer size (as defined in 11.24.16.3.7), subject to the lifetime limits.
If there is a STA with an active GCR agreement for a group address that does not have an active block ack
agreement, the AP shall not retransmit a preceding A-MSDU for that group address. A preceding A-MDSU
is defined as an A-MSDU with a sequence number value that precedes, using the modulo 212 rules defined
in 10.24.1, the sequence number value of the last transmitted A-MSDU for the GCR group address.
11.24.16.3.7 GCR block ack
A STA supports the GCR block ack retransmission policy if dot11AdvancedGCRImplemented is true or
dot11MeshGCRImplemented is true; otherwise, the STA does not support the GCR service with
retransmission policy equal to GCR Block Ack.
The AP shall maintain a set of the most recently received values of the Buffer Size subfield from the Block
Ack Parameter Set field in the ADDBA Response frame received from each member of a specific group
address. The minimum of that set of values is defined to be the GCR buffer size for that group address (see
10.24.10).
11.24.16.3.8 GCR-SP
The GCR-SP delivery method transmits GCR group addressed frames at intervals that might be smaller than
the beacon interval.
A STA supports the GCR-SP delivery method if dot11AdvancedGCRImplemented is true; otherwise, the
STA does not support the GCR service with the delivery method equal to GCR-SP.
NOTE Group addressed traffic transmitted at the end of a DTIM beacon might be an impediment to providing QoS for
uplink transmissions and in OBSSs. Therefore, APs in an overlapped environment are advised to make use of GCR-SP
for group addressed traffic that consumes appreciable medium time.
1823
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Group addressed MSDUs shall not be transmitted via the GCR-SP delivery method policy if a non-GCR-SP
delivery method is active for that group address.
All MSDUs transmitted via the GCR-SP delivery method shall be concealed using the procedures described
in 11.24.16.3.5. A STA receiving group addressed MSDUs transmitted via the GCR-SP delivery method
shall discard all nonconcealed MSDUs for this group address.
An AP advertises that a group addressed stream is subject to GCR-SP within a GCR Response subelement.
The subelement indicates the start of each SP. See 11.2.3.5. When the Service Interval field in the Schedule
element of the DMS Response frame is greater than 0, at every scheduled SP, the AP schedules for
transmission buffered GCR-SP group addressed frames assigned to that particular group address.
An AP shall not establish both a GCR-SP and an FMS agreement for a group addressed stream with a single
non-AP STA.
An AP may use the GCR-SP delivery method for an accepted GCR service when all of the non-AP STAs
that requested the GCR service for the group address have the Robust AV Streaming bit in the Extended
Capabilities element equal to 1 and the Advanced GCR bit in the Extended Capabilities element equal to 1.
Otherwise, the AP shall not use the GCR-SP delivery method for the accepted GCR service.
When the Service Interval field in the Schedule element of the DMS Response frame is 0, the AP may
transmit group addressed frames that are subject to this GCR agreement at any time without regard to the
power state of non-AP STAs in the group. This delivery method is called GCR-A, where all members of the
group need to stay in the awake state to receive these group addressed frames.
11.24.17 WNM notification
Implementation of the WNM notification capability is optional for a WNM STA. A STA that implements
the WNM notification capability has dot11WNMNotificationImplemented equal to true. When
dot11WNMNotificationImplemented is true, dot11WirelessManagementImplemented shall be true. A STA
in which dot11WNMNotificationActivated is true is defined as a STA that supports WNM notification. The
STA shall set to 1 the WNM Notification field of the Extended Capabilities elements that it transmits.
A STA that supports WNM notification reporting may send a WNM Notification Request or Response
frame to a STA within the same infrastructure BSS or the same IBSS whose last received Extended
Capabilities element contained a value of 1 for the WNM Notification field in the Extended Capabilities
field; it shall not send a WNM Notification Request or Response frame otherwise.
A STA shall transmit both the WNM Notification Request frame and the WNM Notification Response
frame with an individually addressed destination address.
The WNM notification capability enables a STA to indicate management information, including information
about its firmware to a peer STA. Use of the information provided is outside the scope of this standard. A
non-AP STA that supports WNM notification and receives a WNM Notification Request frame with the
Type field equal to 0 shall respond with a WNM Notification Response frame with the Response Status field
set to 0.
11.25 WLAN interworking with external networks procedures
11.25.1 General
This subclause describes the actions and the procedures that provide interworking capabilities between IEEE
802.11 infrastructure and external networks.
1824
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.25.2 Interworking capabilities and information
STAs indicate their support for interworking service by setting dot11InterworkingServiceActivated to true.
When dot11InterworkingServiceActivated is true, STAs include the Interworking element in Beacon and
Probe Response frames, and non-AP STAs include the Interworking element in Probe Request frames.
When dot11InterworkingServiceActivated and dot11ExtendedChannelSwitchActivated are both true in an
infrastructure BSS, the AP may provide its operating channel and operating class to an Interworked SSPN
using the values from dot11OperatingClassesTable.
In an infrastructure BSS, the Interworking element contains signaling for Homogeneous ESSs. The HESSID
is a 6-octet MAC address that identifies the homogeneous ESS. The HESSID value shall be identical to one
of the BSSIDs in the homogeneous ESS. Thus, it is a globally unique identifier that, in conjunction with the
SSID, may be used to provide network identification for an SSPN.
NOTE—This standard assumes that the HESSID field in the Interworking element is administered consistently across
all BSSs in a homogeneous ESS.
The Interworking element also provides an access network type in Beacon and Probe Response frames to
assist the non-AP STA with network discovery and selection.
11.25.3 Interworking procedures: generic advertisement service (GAS)
11.25.3.1 Introduction
This subclause describes the actions and procedures that are used to invoke GAS. GAS may be used to
enable network selection for STAs when dot11InterworkingServiceActivated is true. GAS provides
transport mechanisms for advertisement services while STAs are in the unassociated state as well as the
associated state. This is accomplished via the use of Public Action frames, which are Class-1 frames. GAS
information shall be transmitted using individually addressed Public Action frames. When management
frame protection is negotiated, stations shall use individually addressed Protected Dual of Public Action
frames instead of individually addressed Public Action frames.
A GAS frame exchange may take place between two STAs; one STA transmits a GAS Query Request and
the other STA transmits the GAS Query Response as described in 11.25.3.2. The Advertisement Protocol
transported by the GAS is one of the query protocols in Table 9-215.
GAS shall be supported by a STA when dot11InterworkingServiceActivated is true. ANQP shall be
supported by a STA when dot11InterworkingServiceActivated is true. Other advertisement protocols shall
be supported when the corresponding dot11GASAdvertisementID is present.
A STA shall not transmit a GAS Query for any Advertisement Protocol unless that Advertisement Protocol
ID is included in the Advertisement Protocol element in a Beacon or Probe Response frame. The
Advertisement Protocol element specifies the Advertisement Protocols that a STA may use to communicate
with Advertisement Servers, which may be collocated with a STA or in an external network. The
Advertisement Protocol identifies the query language used by the Advertisement Server. The GAS protocol,
which is used to transport Queries and Query Responses, is transparent to the Advertisement Protocol.
1825
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.25.3.2 GAS Protocol
11.25.3.2.1 General
The presence of the Interworking element in Beacon or Probe Response frames indicates support for the GAS
protocol. The presence of the Advertisement Protocol element in Beacon or Probe Response frames indicates
the Advertisement Protocol IDs supported in the BSS or IBSS. A STA transmits a GAS Query Request in a
GAS Initial Request frame and the responding STA provides the GAS Query Response or information on how
to receive the GAS Query Response in a GAS Initial Response frame. The GAS Query Response shall be
delivered in a single GAS Initial Response frame or in one or more GAS Comeback Response frames; the
GAS Query Response shall not be split between a GAS Initial Response frame and one or more GAS
Comeback Response frames. The GAS message sequence diagrams are shown in Figure 11-38, Figure 11-
39, and Figure 11-40.
Figure 11-38 describes the GAS frame exchange sequence when dot11GASPauseForServerResponse is true
and the result of the GAS query fits within one MMPDU.
Requesting Responding Advertisement
STA STA Server
GAS Initial Request Query Request
Query Response
GAS Initial Response
Outside the scope of this standard
Figure 11-38—GAS frame sequence with dot11GASPauseForServerResponse
equal to true
1826
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 11-39 describes the GAS frame exchange sequence when dot11GASPauseForServerResponse is true
and the result of the GAS query is too large to fit in one MMPDU and GAS fragmentation is used for
delivery. The number of GAS Comeback Request and GAS Comeback Response frames depends on the
number of GAS fragments required for delivery of the result of the GAS query.
Requesting Responding Advertisement
STA STA Server
GAS Initial Request Query Request
GAS Initial Response Query Response
Comeback
delay =
1TU GAS Comeback Request
GAS Comeback Response
GAS Comeback Request
GAS Comeback Response
GAS Comeback Request
GAS Comeback Response
Optional GAS frame
Outside the scope of this standard
Figure 11-39—GAS frame sequence with GAS fragmentation and
dot11GASPauseForServerResponse equal to true
1827
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 11-40 describes the GAS frame exchange sequence when dot11GASPauseForServerResponse is
false. The number of GAS Comeback Request and GAS Comeback Response frames depends on the
number of GAS fragments required for delivery of the GAS Query Response.
Requesting Responding Advertisement
STA STA Server
GAS Initial Request Query Request
GAS Initial Response
Comeback
delay
Query Response
GAS Comeback Request
GAS Comeback Response
GAS Comeback Request
GAS Comeback Response
GAS Comeback Request
GAS Comeback Response
Optional GAS frame
Outside the scope of this standard
Figure 11-40—GAS frame sequence with GAS fragmentation and
dot11GASPauseForServerResponse equal to false
11.25.3.2.2 STA procedures to transmit a GAS Query
Upon receipt of an MLME-GAS.request primitive, the requesting STA shall engage in the following
procedure to transmit a query:
a) The requesting STA sends a GAS Query by transmitting a GAS Initial Request frame containing a
Dialog Token, an Advertisement Protocol element containing an Advertisement Protocol ID and the
GAS Query in the Query Request field. If the GAS Initial Request frame requests information
relating to a frequency band different from the frequency band in which the frame is transmitted, the
STA shall include a Multi-band element in the GAS Initial Request frame with the Band ID,
Operating Class, and Channel Number fields set to indicate to which frequency band the GAS Initial
Request frame applies, with other fields in the Multi-band element being reserved. If the frame
requests information relating to the frequency band in which the frame is transmitted, a Multi-band
element shall not be included in the frame.
1828
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) Upon transmission of the GAS Initial Request frame, the STA shall set a timer, referred to as the
dot11GASResponseTimer, equal to dot11GASResponseTimeout or the QueryFailureTimeout
parameter provided in the MLME-GAS.request primitive. If both values are present, the timer shall
be set to the lesser of the two values.
c) If the requesting STA is not in the associated state, it shall remain in active mode until the receipt of
a GAS Initial Response frame with the same value of the Dialog Token field as in the GAS Initial
Request frame or until the expiration of the timer, whichever occurs first. If the requesting STA is in
the associated state, it may go into power save state until the GAS Initial Response frame is
available for receipt or the timer expiration, whichever occurs first.
d) If the dot11GASResponseTimer expires before a GAS Initial Response frame is received, the GAS
Query was not successful and the MLME shall issue an MLME-GAS.confirm primitive with
ResultCode equal to GAS_QUERY_TIMEOUT and shall set the Query Response Length field to 0.
11.25.3.2.3 STA procedures to post a GAS Query to an Advertisement Server
Upon receipt of a GAS Initial Request frame, an MLME-GAS.indication primitive shall be issued to the
STA’s SME. Upon receipt of an MLME-GAS.response primitive, the STA shall transmit a GAS Initial
Response frame to the requesting STA according to the following procedures. If the requesting STA is in the
associated state and in the power save mode, the responding STA shall buffer the MMPDU for transmission
according to the procedures in 11.2.3; otherwise the STA shall queue the MMPDU for transmission as
follows:
a) If the Advertisement Protocol ID in the Advertisement Protocol element does not equal the value
contained in any dot11GASAdvertisementID, then the STA shall not post the query to an
Advertisement Server. The STA shall transmit an individually addressed GAS Initial Response
frame to the requesting STA containing a dialog token whose value is identical to the dialog token in
the GAS Initial Request frame, a Status Code equal to
GAS_ADVERTISEMENT_PROTOCOL_NOT_SUPPORTED (see Table 9-46), an Advertisement
Protocol element containing the Advertisement Protocol ID used in the GAS Initial Request frame
and a Comeback Delay and Query Response Length both set to 0.
b) If the query request corresponds to an Advertisement Protocol whose server is currently
unreachable, the responding STA shall transmit an individually addressed GAS Initial Response
frame to the requesting STA containing a dialog token whose value is identical to the dialog token in
the GAS Initial Request frame, a Status Code equal to SERVER_UNREACHABLE, an
Advertisement Protocol element containing an Advertisement Protocol ID equal to the
Advertisement Protocol ID contained in the GAS Initial Request frame and a Comeback Delay and
Query Response Length both set to 0. The method used by the AP to determine the server is
unreachable is out of scope of this standard. A STA receiving a status code indicating
SERVER_UNREACHABLE should wait at least 1 minute before transmitting any further queries
using the same Advertisement Protocol ID to the responding STA.
c) If the Advertisement Protocol ID in the Advertisement Protocol element equals the value contained
in any dot11GASAdvertisementID, then the STA shall initialize a timer, referred to as the
PostReplyTimer, to the value in dot11GASResponseTimeout and post the query to the
Advertisement Server identified by the Advertisement Protocol ID. The methods and protocols the
STA uses to post the query are outside the scope of this standard.
d) If dot11GASPauseForServerResponse is false, the responding STA shall transmit an individually
addressed GAS Initial Response frame to the requesting STA containing a dialog token whose value
is identical to the dialog token in the GAS Initial Request frame, a Status Code set to SUCCESS, an
Advertisement Protocol element containing the Advertisement Protocol ID used in the GAS Initial
Request frame, a GAS Comeback Delay set to the value in dot11GASComebackDelay for this
Advertisement Protocol and a Query Response Length set to 0.
e) If dot11GASPauseForServerResponse is true, the GAS Query Response is delivered as defined in
11.25.3.2.4.
1829
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.25.3.2.4 STA procedures for transmitting the GAS Query Response
After receiving a query response from the Advertisement Server, the responding STA shall buffer the query
response for a minimum of dot11GASResponseBufferingTime after the expiration of the GAS Comeback
Delay or until the query response is delivered. If the responding STA does not receive a GAS Comeback
Request frame whose source MAC address and dialog token match the source MAC address and value of the
Dialog Token field respectively of the corresponding GAS Initial Response frame within this time, it may
drop the query response. If the query response received from the Advertisement Server is larger than
dot11GASQueryResponseLengthLimit for the matching dot11GASAdvertisementID or is larger than the
value of the Query Response Length Limit field received from the requesting STA, the responding STA
shall discard the response and instead return a status code of GAS_QUERY_RESPONSE_TOO_ LARGE in
the GAS Comeback Response frame. This behavior helps to prevent abuses of the medium that may be
caused by overly general queries, which evoke a very large query response.
The GAS protocol supports Query Responses whose length is greater than the IEEE 802.11 maximum
MMPDU size by the STA’s use of the GAS Query Response Fragment ID field in the GAS Comeback
Response frame; the Query Response Fragment ID shall be set to 0 for the initial fragment and incremented
by 1 for each subsequent fragment in a multi-fragment query response. If the Query Response is a multi-
fragment response (i.e., contains more than 1 fragment), the STA shall transmit all fragments that belong to
the same Query Response until all fragments are exhausted. The STA shall set the More GAS Fragments
field of the GAS Query Response Fragment ID to 0 when the transmitted fragment is the final fragment.
If the GAS Initial Request frame that initiated the GAS transaction contains a Multi-band element, but the
GAS Initial Response frame transmitted as a response does not contain a copy of the same Multi-band
element, the Status Code in the GAS Initial Response frame shall be set to REQUEST_DECLINED.
Otherwise, the requesting and responding STAs shall include a copy of the same Multi-band element in all
subsequent GAS Initial Response, GAS Comeback Request, and GAS Comeback Response frames
transmitted as part of the GAS transaction. Inclusion of the Multi-band element indicates to which frequency
band the GAS transaction applies. If the GAS Initial Request frame that initiated the GAS transaction does
not contain a Multi-band element, then none of the subsequent GAS Initial Response, GAS Comeback
Request, and GAS Comeback Response frames transmitted as part of the GAS transaction shall include a
Multi-band element.
The following procedures shall be used by the responding STA to deliver the query response to the
requesting STA:
a) If dot11GASPauseForServerResponse is true:
1) If the PostReplyTimer expires before the GAS Query Response is received from the
Advertisement Server, then the responding STA shall transmit an individually addressed GAS
Initial Response frame to the requesting STA containing a dialog token whose value is identical
to the dialog token in the GAS Initial Request frame, a Status Code set to
GAS_QUERY_TIMEOUT (see Table 9-46), an Advertisement Protocol element containing
the Advertisement Protocol ID used in the GAS Initial Request frame, a GAS Comeback Delay
set to 0 and a Query Response Length set to 0. If the query response is subsequently received
from the Advertisement Server, it shall be dropped by the responding STA.
2) If the Query Response received from the Advertisement Server is larger than
dot11GASQueryResponseLengthLimit or requires more than 128 fragments for transmission
to the requesting STA, it shall be dropped by the responding STA. Then the responding STA
shall transmit an individually addressed GAS Initial Response frame to the requesting STA
containing a dialog token whose value is identical to the dialog token in the GAS Initial
Request frame, a Status Code set to GAS_QUERY_RESPONSE_TOO_ LARGE (see Table 9-
46), an Advertisement Protocol element containing the Advertisement Protocol ID used in the
GAS Initial Request frame, a GAS Comeback Delay set to 0 and a Query Response Length set
to 0.
1830
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
3) If the query response’s length is less than or equal to the maximum MMPDU size, the STA
shall transmit an individually addressed GAS Initial Response frame to the requesting STA
containing a dialog token whose value is identical to the dialog token in the GAS Initial
Request frame, a Status Code set to SUCCESS, an Advertisement Protocol element containing
the Advertisement Protocol ID used in the GAS Initial Request frame, a GAS Comeback Delay
set to 0, the Query Response and a Query Response Length set to the query response length.
This completes the GAS Query and GAS Query Response exchange.
4) If the query response’s length is larger than the maximum MMPDU size, the responding STA
shall transmit an individually addressed GAS Initial Response frame to the requesting STA
containing a dialog token whose value is identical to the dialog token in the GAS Initial
Request frame, a Status Code set to SUCCESS, an Advertisement Protocol element containing
the Advertisement Protocol ID used in the GAS Initial Request frame, a GAS Comeback Delay
set to 1 TU, and a Query Response Length set to 0; this indicates the query response will be
transmitted using GAS Comeback Request and Response frames that support GAS
fragmentation as follows.
b) If dot11GASPauseForServerResponse is false:
1) If the PostReplyTimer expires before the GAS Query Response is received from the
Advertisement Server then the responding STA shall buffer for transmission a GAS Comeback
Response frame with a status code equal to GAS_QUERY_TIMEOUT (see Table 9-46). If the
query response is subsequently received from the Advertisement Server, it shall be dropped by
the STA.
2) If the Query Response received from the Advertisement Server is larger than dot11GASQue-
ryResponseLengthLimit, it shall be dropped by the responding STA. Then the STA shall buffer
for transmission a GAS Comeback Response frame with status code set to GAS_QUERY_RE-
SPONSE_TOO_ LARGE.
c) If the Query Response is received before the expiration of the PostReplyTimer and its length is less
than dot11GASQueryResponseLengthLimit, then the Query Response shall be buffered in one or
more GAS Comeback Response frames with status code set to SUCCESS. The responding STA
transmits one GAS Comeback Response frame in response to each GAS Comeback Request frame.
If the Query Response received from the Advertisement Server is less than or equal to the maximum
MMPDU size, then the GAS Query Response Fragment ID shall be set to 0 and the More GAS
Fragments field in the GAS Query Response Fragment ID shall be set to 0. If the Query Response
received from the Advertisement Server is greater than the maximum MMPDU size, then the GAS
Query Response Fragment ID shall be set to 0 if this is the first fragment of the Query Response
transmitted; otherwise it shall be incremented by 1; the More GAS Fragments field in the GAS
Query Response Fragment ID shall be set to 1 if there are more fragments of the Query Response to
be transmitted; otherwise it shall be set to 0 (i.e., this fragment is the last fragment of the Query
Response).
d) If a responding STA receives a GAS Comeback Request frame whose source MAC address and
dialog token match the destination MAC address and value of the Dialog Token field respectively of
an outstanding GAS Initial Response frame and the query response has not been received from the
Advertisement Server and the PostReplyTimer has not expired, the responding STA shall transmit a
GAS Comeback Response frame with status code equal to
GAS_RESPONSE_NOT_RECEIVED_FROM _SERVER (see Table 9-46) and GAS Comeback
Delay set to the value in dot11GASComebackDelay for this Advertisement Protocol to indicate
when the requesting STA should come back to obtain its Query Response.
e) If a responding STA receives a GAS Comeback Request frame whose source MAC address and
Dialog Token do not match the destination MAC address and value of the Dialog Token field
respectively of an outstanding GAS Initial Response frame, the STA should transmit a GAS
Comeback Response frame with a status code equal to NO_OUTSTANDING_GAS_REQUEST.
1831
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A requesting STA shall transmit a GAS Comeback Request frame including the Dialog Token (drawn from
the corresponding GAS Initial Response frame) immediately after the expiration of the GAS Comeback
Delay. In response, the responding STA provides the Query Response in one or more GAS Comeback
Response frames with the corresponding Dialog Token.
If a requesting STA receives a GAS Comeback Response frame with status equal to
QUERY_RESPONSE_OUTSTANDING, the requesting STA shall wait for the GAS Comeback Delay from
that frame and upon expiration of the GAS Comeback Delay, transmit another GAS Comeback Request
frame. If the requesting STA’s dot11GASResponseTimer (set in 11.25.3.2.2 step b) expires prior to
receiving a GAS Comeback Response frame whose source MAC address and dialog token match those in
the corresponding GAS Initial Response frame, the STA shall issue an MLME-GAS.confirm primitive with
ResultCode equal to GAS_QUERY_TIMEOUT and shall set the Query Response Length to 0.
If a requesting STA receives a GAS Comeback Response frame with status equal to SUCCESS and the
More GAS Fragments field in the GAS Query Response Fragment ID equal to 1, it shall transmit another
GAS Comeback Request frame in order to retrieve the next GAS fragment of a multi-fragment query
response.
If a requesting STA receives a GAS Comeback Response frame with status equal to SUCCESS and the
More GAS Fragments field in the GAS Query Response Fragment ID equal to 0, the requesting STA’s
MLME shall determine that all fragments have been received by confirming that all fragment IDs from 0 to
the value in the GAS Query Response Fragment ID when the More GAS Fragments field was equal to 0
have been received. Upon receipt of the first GAS Comeback Response frame and every GAS Comeback
Response frame thereafter, the dot11GASResponseTimer shall be reset. If all of the query response
fragments were received before the expiration of the dot11GASResponseTimer, then the MLME shall issue
an MLME-GAS.confirm primitive with result code set to SUCCESS along with the query response. If not
all of the query response fragments were received before the expiration of the dot11GASResponseTimer,
then the MLME shall issue an MLME-GAS.confirm primitive with ResultCode equal to
GAS_QUERY_TIMEOUT and shall set the Query Response Length to 0.
After a requesting STA receives the first GAS fragment of a multi-fragment query response, it shall continue
retrieving the query response until all GAS fragments are received or until a transmission failure is detected;
the requesting STA shall not commence the retrieval of a another GAS Query Response from the same STA
until all GAS fragments are received or until a transmission failure is detected on the first GAS Query
Response.
If a requesting STA receives a GAS Comeback Response with status equal to GAS_QUERY_TIMEOUT or
GAS_QUERY_RESPONSE_TOO_ LARGE then the MLME shall issue an MLME-GAS.confirm primitive
with result code so indicating and shall set the Query Response Length to 0.
If a requesting STA receives a GAS Comeback Response with status equal to
NO_OUTSTANDING_GAS_REQUEST, then the MLME shall issue an MLME-GAS.confirm primitive
with result code set to NO_OUTSTANDING_GAS_REQUEST and shall set the Query Response Length
to 0.
11.25.3.2.5 GAS procedures interaction with multiple BSSID set
Non-AP STAs in the unassociated state may use GAS procedures to query Advertisement Servers for
information. As described in 11.25.3.2, APs indicate their support for a particular GAS Advertisement
Protocol by including an Advertisement protocol element with that Advertisement protocol ID in Beacon
and Probe Response frames as described in 9.3.3.3 and 9.3.3.11 respectively. Non-AP STAs receiving
Beacon or Probe Response frames from different APs may choose to engage in GAS frame exchange
sequences with one or more of these APs. In some deployment scenarios, these APs may be operating as a
multiple BSSID set (as defined in 11.11.14) and may relay the GAS queries to the same Advertisement
1832
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Server. Depending on the configuration of the IEEE 802.11 access network, the external network and the
Advertisement Server, a query response from the Advertisement Server might or might not be dependent on
the BSSID used in the GAS frame exchange sequence and thus the STA from which the query was relayed.
If the GAS Query Response is dependent on the BSSID, a requesting STA may choose to post queries using
GAS procedures to more than one STA and expect possibly different Query Responses. If the Query
Response is not dependent on the BSSID, then a requesting STA may choose to post queries using GAS
procedures to only one STA in the multiple BSSID set (i.e., posting the same query to another member of
the multiple BSSID set would yield the same response).
When a Multiple BSSID (as defined in 11.11.14) set contains two or more members and
dot11InterworkingServiceActivated is true and dot11GASAdvertisementID is present and a query to the
Advertisement Server corresponding to dot11GASAdvertisementID is not dependent on the BSSID value
used in the GAS frame exchange sequence to post the query, then the PAME-BI bit in the Advertisement
Protocol tuple of the Advertisement Protocol element corresponding to dot11GASAdvertisementID shall be
set to 1; otherwise this bit shall be set to 0.
11.25.3.3 ANQP procedures
11.25.3.3.1 General
A STA may use ANQP to retrieve information as defined in Table 9-271 from a peer STA.
A non-AP STA shall not transmit an ANQP request to an AP for any ANQP-element unless the ANQP
Advertisement Protocol ID is included in the Advertisement Protocol element in a Beacon or Probe
Response frame from that AP.
The ANQP request consists of one or more ANQP elements drawn from Table 9-271 having an element
type of Q in Table 11-15 and shall be ordered by nondecreasing Info ID. A Query List ANQP-element
included in an ANQP request is formed as described in 11.25.3.2.2. The ANQP request is transported in the
Query Request field of GAS Request frames as described in 11.25.3.2.4.
The ANQP response should consist of ANQP elements having Info IDs present in the Query List ANQP-
element response (if present) plus zero or more responses to other query elements; these ANQP elements
shall be chosen from among those listed in Table 9-271 having an element type of S in Table 11-15 and shall
be ordered by non-decreasing Info ID. The ANQP response is transported in the Query Response field of
GAS Response frames, as described in 11.25.3.2.4.
Table 11-15—ANQP usage
BSS IBSS
ANQP-element ANQP-
ANQP-element name
(subclause) element type Non-AP
AP STA
STA
Query List 9.4.5.2 Q T, R T, R T, R
Capability List 9.4.5.3 S T, R T, R T, R
Venue Name 9.4.5.4 S T R —
Emergency Call Number 9.4.5.5 S T R —
Network Authentication Type 9.4.5.6 S T R —
Roaming Consortium 9.4.5.7 S T R —
1833
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-15—ANQP usage (continued)
BSS IBSS
ANQP-element ANQP-
ANQP-element name
(subclause) element type Non-AP
AP STA
STA
Vendor Specific 9.4.5.8 Q, S T, R T, R T, R
IP Address Type Availability 9.4.5.9 S T, R T, R T, R
NAI Realm 9.4.5.10 S T R T, R
3GPP Cellular Network 9.4.5.11 S T R —
AP Geospatial Location 9.4.5.12 S T R T, R
AP Civic Location 9.4.5.13 S T R T, R
AP Location Public Identifier 9.4.5.14 S T R T, R
URI/FQDN
Domain Name 9.4.5.15 S T R —
Emergency Alert Identifier URI 9.4.5.16 S T R T, R
TDLS Capability 9.4.5.18 Q, S T,R T,R T, R
Emergency NAI 9.4.5.17 S T R —
Neighbor Report 9.4.5.19 S T R —
Venue URL 9.4.5.20 S T T —
Advice of Charge 9.4.5.21 S T T —
Local Content 9.4.5.22 S T T —
Network Authentication Type 9.4.5.23 S T R —
with Timestamp
Symbols
Q element is an ANQP request
S element is an ANQP response
T ANQP-element may be transmitted by MAC entity
R ANQP-element may be received by MAC entity
— ANQP-element is neither transmitted nor received by MAC entity
ANQP usage for infrastructure BSSs and IBSSs shall be in accordance with Table 11-15. ANQP usage
defines the entities permitted to transmit and receive particular ANQP-elements.
A STA having dot11InterworkingServiceActivated equal to true shall be capable of using the Query List
ANQP-element to request the Capability List ANQP-element; support for all other ANQP-elements is
optional.
A STA that encounters an unknown or reserved ANQP Info ID value in a GAS frame (see 9-307) received
without error shall ignore that ANQP Info ID and shall parse any remaining ANQP Info IDs.
A STA that encounters an unknown vendor-specific OI field or subfield in a GAS frame (see 9-307)
received without error shall ignore that field or subfield respectively, and shall parse any remaining fields or
subfields for additional information with recognizable field or subfield values.
1834
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.25.3.3.2 Query list procedure
The Query List ANQP-element is used by a requesting STA to perform an ANQP request using the
procedures defined in 11.25.3.3.1. The requesting STA may include Info IDs in the Query List ANQP-
element that have the sole ANQP-element type of S as shown in Table 11-15; the STA shall not include
other Info IDs.
A responding STA that encounters an unknown or reserved ANQP Info ID value in an Query List ANQP-
element received without error shall ignore that ANQP Info ID and shall parse any remaining ANQP Info IDs.
11.25.3.3.3 Roaming Consortium procedure
The Roaming Consortium ANQP-element, which contains a set of OIs, can be retrieved from an AP by a
non-AP STA using the query list procedure defined in 11.25.3.3.2. The list of OIs included in the Roaming
Consortium ANQP-element shall be those OIs in the dot11RoamingConsortiumTable. An AP may include
an OI in the dot11RoamingConsortiumTable, if in conjunction with an AS, it is capable of successfully
authenticating a non-AP STA having valid security credentials for the SSPN identified by that OI; the AP
shall not include an OI otherwise. Methods used by the AP to authenticate the non-AP STA include, but are
not limited to, RSNA algorithms and Open System authentication.
Each OI identifies an SSP or group of SSPs (i.e., a roaming consortium). An SSP or group of SSPs can
register for and obtain an OI using the procedures described in [B19].
A non-AP STA might have a locally stored binding between an OI and a set of security credentials with
which it can authenticate to the network identified by the OI, that is, the SSPN. The method by which this
binding is obtained is outside the scope of this standard. A non-AP STA can select from that list of
credentials when authenticating to the BSS.
11.25.3.3.4 AP procedure for advertising EAP Method associated with an NAI Realm
When dot11RSNAActivated is true, NAI realms along with their supported authentication methods may be
advertised using the NAI Realm ANQP-element (see 9.4.5.10). Each realm may be optionally associated
with a set of EAP methods. Each EAP method may be optionally associated with a set of Authentication
Parameters. The NAI realm ANQP-element provides a hint on the methods a STA might use to establish an
association in an RSN IEEE 802.1X environment. If the non-AP STA recognizes the NAI realm, it may
attempt authentication even if it believes the EAP methods are incorrect.
When dot11RSNAActivated is false and the Network Authentication Type (see 9.4.5.6) contains a Network
Authentication Type Unit having a Network Authentication Type Indicator field equal to http/https
redirection or DNS redirection, NAI realms without supported authentication methods may be advertised
using the NAI Realm ANQP-element (see 9.4.5.10).
A non-AP STA having dot11InterworkingServiceActivated equal to true may process the NAI Realm
ANQP-element. The selection of the NAI realm the non-AP STA uses for authentication is outside the scope
of this standard. A non-AP STA requests the NAI Realm ANQP-element using Query List procedures
defined in 11.25.3.3.2.
A non-AP STA having dot11InterworkingServiceActivated equal to true may process the EAP Method list
as follows:
— The EAP Method list provided by the AP shall be in priority order (the most preferred EAP Method
is listed first).
— The credential types help the STA to determine what credentials to use for authentication.
1835
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The STA should confirm the GAS advertisement after an RSNA is established by performing a GAS
Query for the NAI Realm ANQP-element using Protected Dual of Public Action frames.
NOTE—The advertisements should be confirmed after the RSNA is established to avoid downgrade attacks.
The policy that determines whether a non-AP STA should attempt authentication and/or association with
any particular IEEE 802.11 Access Network is outside the scope of this standard.
11.25.3.3.5 3GPP Cellular Network procedure
A STA may retrieve 3GPP Cellular Network information using the Query List procedure in 11.25.3.3.2.
Realms referenced in the 3GPP Cellular Network ANQP-element should not be included in the NAI Realm
ANQP-element (see 9.4.5.10).
11.25.3.3.6 AP Geospatial Location procedure
A STA may retrieve an AP’s geospatial location using the Query List procedure in 11.25.3.3.2. A STA in
the associated state should retrieve Geospatial location information from the AP using the procedures in
11.11.9.6.
11.25.3.3.7 AP Civic Location procedure
A STA may retrieve an AP’s civic location using the Query List procedure in 11.25.3.3.2. A STA in the
associated state should retrieve civic location information from the AP using the procedures in 11.11.9.9.
11.25.3.3.8 AP Location Public Identifier URI/FQDN procedures
A STA when dot11InterworkingServiceActivated is true may retrieve an AP’s Location Public Identifier
URI or a location server’s FQDN using ANQP procedures in 11.25.3.3. A STA in the associated state should
retrieve Location Public Identifier URI/FQDN information from the AP using the procedures in 11.11.9.10.
Due to security concerns, there are some URI schemes that should be cautiously processed when received by
a STA. For example, URIs using the scheme names “data:” and “http:” may direct applications (e.g., a
browser) on the STA to Internet pages that contain active scripts. Therefore, URIs received via this ANQP
procedure should not be processed in a general manner, as these scripts may be inadvertently activated.
Instead of listing all of the types of URIs that might be misused or potentially have harmful affects,
Section 3.3 IANA registers acceptable URI schemes.
11.25.3.3.9 Emergency NAI procedure
A STA that does not have valid credentials to authenticate to a network may use the information in the
Emergency NAI ANQP-element as its EAP identity.
The Emergency NAI ANQP-element can be retrieved from the AP using the Query List procedure in
11.25.3.3.2.
The STA uses the emergency NAI procedure to indicate its intention to access the network without peer
authentication by using the emergency NAI information as its identity in the authentication process, as
described in IETF RFC 5216.
11.25.3.3.10 TDLS Capability procedure
A STA may use the TDLS Capability ANQP-element (see 9.4.5.18) to discover TDLS capabilities of
another TDLS capable STA using the Query List procedure in 11.25.3.3.2.
1836
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An example of TDLS capability discovery using ANQP is given in Figure 11-41.
STA1 STA2
Both STAs are currently in the same BSS
ANQP request (TDLS Capability({Mode=TDLS; BSSID= 00-01-02-03-04-05; MAC= 00-01-02-03-04-05;
DHCP=No; IP=192.168.2.1; Netmask=255.255.255.253})
ANQP response(TDLS Capability({Mode=TDLS; BSSID= 00-01-02-03-04-05; MAC= 00-01-02-03-04-06;
DHCP=No; IP=192.168.2.2; Netmask=255.255.255.253})
STA1 Initiates a TDLS link to STA2
Figure 11-41—Example TDLS Capability discovery using ANQP
The mechanism shall work as follows:
a) STA1 determines the MAC address of STA2.
b) STA1 sends an ANQP request to STA2. The ANQP request includes a TDLS Capability ANQP-
element.
c) STA2 receives the ANQP request and updates the TDLS Capability ANQP-element based on its
own capabilities that is returned in the ANQP response to STA1.
11.25.3.3.11 Venue URL procedure
The Venue URL ANQP-element is used to provide web page advertising services or information particular
to the venue.
This ANQP-element is to be used in conjunction with the Venue Name ANQP-element, to provide extra
information about the venue. Typical operation is to use the Venue Name ANQP-element to determine the
list of available venues advertised by a STA, and then the Venue URL ANQP-element is used, if required, to
determine a list of Venue URLs, each entry corresponding to the Venue Name entry in the list returned by
the Venue Name ANQP-element.
11.25.3.3.12 Advice of Charge procedure
The Advice of Charge ANQP-element is used to provide financial cost advertisements in the form of Advice
of Charge plan information. The plan information is provided on a per NAI realm basis, so that each
authentication realm can advertise the charge associated with obtaining network access. This information
might assist with a decision about proceeding with access.
The use and operation of the Plan information schema is outside the scope of this standard.
As ANQP-elements are transmitted in the clear, prior to STA association, one or more protected dual of
public action frames should be used after association to verify this information.
1837
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.25.3.3.13 Local Content procedure
The Local Content ANQP-element is used to provide local content URLs. Each URL points to local content
information that might be relevant, for example by providing information about terms and conditions for
BSS access, when automated login procedures are being used.
Several URLs can be provided in the Local Content ANQP-element, each corresponding to a separate state.
This allows the STA to display differing local content (e.g., terms and conditions, failure warning
information, help page), through the STA association procedure.
For example, the Local Content ANQP-element may return two Local Content Duple fields with values of
the State field corresponding to “Not authenticated” and “Failure during authentication.” The requesting
STA may display the contents of the local web page indicated by the first URL (“Not authenticated”)
showing terms and conditions of BSS access. If a subsequent association fails, then the requesting STA may
display the contents of the local web-page indicated by the second URL (“Failure during authentication”)
showing a help page.
11.25.3.4 Registered location query protocol (RLQP) procedures
When dot11GDDActivated is true, a STA may use RLQP to retrieve information as defined in Table 9-215
from a peer STA that has transmitted an Advertisement Protocol element indicating support for RLQP (see
9.4.2.93) in a Beacon or Probe Response frame.
If information is not configured for a particular RLQP-element, then a query for that element returns that
element with no optional fields.
When RLQP is transmitted between the GDD enabling STA and the RLSS, it uses Ethertype 89-0d frames,
as defined in Annex H. The RLQP payload contains RLQP-elements as specified in 9.4.6 and the
Advertising Protocol element with an Advertising Protocol tuple whose Advertisement Protocol ID is set to
the value of RLQP specified in Table 9-215. When RLQP is transmitted between the GDD dependent STA
and its GDD enabling STA, it uses protected Action frames, but does not use Ethertype 89-0d frames.
In some regulatory domains, the GDD enabling STA may be required to have secured connection with the
RLSS. When security is required by regulation, the Ethertype 89-0d frame body may employ corresponding
security features. Alternatively, various security protocols may also be selected by setting the Ethertype field
to respective values. A webpage maintained by the IEEE Registration Authority Committee allowing search
of the public values of the Ethertype field is found at http://standards.ieee.org/develop/regauth/ethertype/
public.html.
11.25.4 Interworking procedures: IEEE 802.21 MIH support
IEEE Std 802.21-2008, the “MIH standard,” supports handovers across heterogeneous networks. STAs with
dot11InterworkingServiceActivated equal to true and dot11GasAdvertisementId equal to MIH Information
Service (see Table 9-215) shall support the transmission and reception of IEEE 802.21 MIIS queries for
STAs in all states. STAs with dot11InterworkingServiceActivated equal to true
and dot11GasAdvertisementId equal to MIH Command and Event Services Capability Discovery (see
Table 9-215) shall provide support for IEEE 802.21 MICS/MIES capability discovery for non-AP STAs in
all states.
Additionally, support for IEEE 802.21 MIIS query and IEEE 802.21 MICS/MIES capability discovery to
non-AP STA’s in the associated state is provided by the STA forwarding IP datagrams destined for the MIH
point of service to the IEEE 802.21 MIIS server.
1838
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A non-AP STA discovers support for these services by receiving Beacon or Probe Response frames with an
Advertisement Protocol element having Advertisement Protocol ID(s) for MIH Information Service and/or
IEEE 802.21 MICS/MIES capability discovery.
A non-AP STA forms an IEEE 802.21 IS query by creating its query request according to the procedures
defined in IEEE Std 802.21-2008 and formatting that request into an IEEE 802.21 MIH protocol frame as
defined in 8.4 of IEEE Std 802.21-2008. The non-AP STA, using the procedures in 11.25.3.2, posts the
query to an IEEE 802.21 IS server by transmitting the MIH formatted frame in the Query Request field of a
GAS Initial Request frame. The Advertisement Protocol ID field in the GAS Initial Request frame is set to
the value of IEEE 802.21 MIH Information Service (Table 9-215).
Non-AP STAs in the unauthenticated or unassociated or associated states can use GAS procedures to
discover MIH Command and Event Services Capability as specified in Table 9-215.
A non-AP STA forms an IEEE 802.21 MIH Command and Event Service discovery request by
encapsulating an MIH_Capability_Discover request (see IEEE Std 802.21-2008) into an MIH protocol
frame as defined in 8.4 of IEEE Std 802.21-2008. The non-AP STA, using the procedures in 11.25.3.2, posts
the discovery request to the network by transmitting the MIH formatted frame in the Query Request field of
a GAS Initial Request frame. The Advertisement Protocol ID field in the GAS Initial Request frame is set to
the value of MIH Command and Event Services Capability Discovery (Table 9-215). The method by which
the AP relays the discovery request to the network is defined in IEEE Std 802.21-2008 and is outside the
scope of this standard.
A non-AP STA retrieves the IEEE 802.21 MIH Command and Event Service discovery response according
to the procedures in 11.25.3.2. The discovery response is an MIH protocol frame as defined in 8.4 of
IEEE Std 802.21-2008.
11.25.5 Interworking procedures: interactions with SSPN
11.25.5.1 General operation
To provide SSPN Interface services, the IEEE 802.11 network interacts with the SSPN corresponding to the
user of the non-AP STA either directly or via a roaming relationship. As part of setting up the RSN security
association, user policies are communicated to the AP. If dot11SSPNInterfaceActivated is true, these
permissions shall be stored in the AP’s dot11InterworkingTableEntry for that STA. Thereafter, the AP shall
use the dot11InterworkingTableEntry for controlling the service provision to that non-AP STA. User
policies from the SSPN affect authentication, authorization, and admission control decisions at the AP. In
addition, the AP collects statistics about the non-AP STA and reports the statistics to the SSPN when
requested. The SSPN may also send service provision instructions to the AP, e.g., to terminate the
connection to a non-AP STA. Non-AP STAs do not support the SSPN Interface.
Network deployments typically provide that the AP and the server in the SSPN have a trustworthy channel
that can be used to exchange information, without exposure to or influence by any intermediate parties. The
establishment of this secure connection between the IEEE 802.11 infrastructure and the SSPN is outside the
scope of this standard.
11.25.5.2 Authentication and cipher suites selection with SSPN
When the non-AP STA initiates IEEE 802.1X authentication, the EAP messages are forwarded to the SSPN
based on the home realm information provided by the non-AP STA. If the IEEE 802.11 infrastructure is
unable to forward the EAP message, the AP when dot11SSPNInterfaceActivated is true shall disassociate
the non-AP STA with Reason Code NO_SSP_ROAMING_AGREEMENT.
1839
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In addition to the EAP messages, the IEEE 802.11 infrastructure also provides extra information regarding
the non-AP STA to the SSPN as defined in R.4.2, e.g., the Cipher Suite supported by non-AP STA, the
location of the AP to which the non-AP STA is associated, etc. Such information may be used by the SSPN
to make authentication and service provisioning decisions.
In the SSPN Interface Service, the SSPN uses more information than is carried over EAP to decide on the
authentication result. The SSPN might reject a connection request if the cipher suites supported by non-AP
STA does not meet its security requirements. In this situation, the SME of the AP when
dot11SSPNInterfaceActivated is true shall invoke a disassociation procedure as defined in 11.3.5.8 by
issuing the MLME-DISASSOCIATE.request primitive. The AP disassociates the corresponding non-AP
STA with Reason Code BAD_CIPHER_OR_AKM.
The SSPN might reject the association request based on the location of the non-AP STA, e.g., if the non-AP
STA is requesting association to an AP or associated to an AP located in a forbidden zone. In this situation,
the SME of the AP when dot11SSPNInterfaceActivated is true shall invoke a disassociation procedure as
defined in 11.3.5.8 by issuing the MLME-DISASSOCIATE.request primitive. The AP disassociates the
corresponding non-AP STA with Reason Code NOT_AUTHORIZED_THIS_LOCATION.
11.25.5.3 Reporting and session control with SSPN
An AP with dot11SSPNInterfaceActivated equal to true shall create a dot11InterworkingEntry in its
dot11InterworkingTable for each STA that successfully associates. Permissions received from the SSPN for
each associated STA shall be populated into the table; if no permissions are received from the SSPN for a
particular non-AP STA, then the default permissions or an AP’s locally defined policy may be used for that
STA’s dot11InterworkingEntry. If the AP’s local policy is more restrictive than an object’s permission value
received from the SSPN Interface, then the AP’s local policy may be enforced instead.
In an AP when dot11SSPNInterfaceActivated is equal to true, the following procedure occurs:
— The non-AP STA’s state contained in the dot11InterworkingEntry shall be transmitted to the new
AP after a successful transition. The state definition and the protocol used to transfer the state are
beyond the scope of this standard. The new AP shall not forward any frames for that non-AP STA
until it receives the dot11InterworkingEntry from the prior AP.
— After the state is successfully transmitted to the new AP, the dot11InterworkingEntry for that non-
AP STA shall be deleted from the prior AP’s dot11InterworkingTable.
An AP with dot11SSPNInterfaceActivated equal to true shall delete the dot11InterworkingEntry for a non-
AP STA when it disassociates from the BSS.
An AP with dot11SSPNInterfaceActivated equal to true shall enforce the dot11InterworkingEntry limits for
a particular non-AP STA by comparing the values of octet counters to authorized access limits:
— dot11NonAPStationVoiceOctetCount is compared to dot11NonAPStationAuthMaxVoiceOctets.
When the value of the authorized maximum octet count is exceeded, if the ACM field for AC_VO is
equal to 1 then the HC shall delete all admitted TSs on this access category and deny all subsequent
ADDTS Request frames with TID set 6 or 7, or if the ACM field for AC_VO is equal to 0 then the
non-AP STA shall be disassociated using the MLME-DISASSOCIATE.request primitive with a
reason code of PEER_INITIATED.
— dot11NonAPStationVideoOctetCount is compared to dot11NonAPStationAuthMaxVideoOctets.
When the value of the authorized maximum octet count is exceeded, if the ACM field for AC_VI is
equal to 1 then the HC shall delete all admitted TSs on this access category and deny all subsequent
ADDTS Request frames with TID set 4 or 5, or if the ACM field for AC_VI is equal to 0 then the
non-AP STA shall be disassociated using the MLME-DISASSOCIATE.request primitive with a
reason code of PEER_INITIATED.
1840
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— dot11NonAPStationBestEffortOctetCount is compared to dot11NonAPStationAuthMaxBestEffort-
Octets. When the value of the authorized maximum octet count is exceeded, if the ACM field for
AC_BE is equal 1 then the HC shall delete all admitted TSs on this access category and deny all
subsequent ADDTS Request frames with TID set 0 or 3, or if the ACM field for AC_BE is equal 0
then the non-AP STA shall be disassociated using the MLME-DISASSOCIATE.request primitive
with a reason code of PEER_INITIATED.
— dot11NonAPStationBackgroundOctetCount is compared to
dot11NonAPStationAuthMaxBackgroundOctets. When the value of the authorized maximum octet
count is exceeded, if the ACM field for AC_BK is equal 1 then the HC shall delete all admitted TSs
on this access category and deny all subsequent ADDTS Request frames with TID set 1 or 2, or if
the ACM field for AC_BK is equal 0 then the non-AP STA shall be disassociated using the MLME-
DISASSOCIATE.request primitive with a reason code of PEER_INITIATED.
— dot11NonAPStationHCCAHEMMOctetCount is compared to
dot11NonAPStationAuthMaxHCCAHEMMOctets. When the value of the authorized maximum
octet count is exceeded, then the HC shall delete all admitted TSs with access policy of HCCA or
HEMM and deny all subsequent ADDTS Request frames with access policy equal HCCA or
HEMM.
— The sum of dot11NonAPStationVoiceOctetCount, dot11NonAPStationVideoOctetCount,
dot11NonAPStationBestEffortOctetCount, dot11NonAPStationAuthMaxBackgroundOctets, and
dot11NonAPStationHCCAHEMMOctetCount is compared to dot11NonAPStationAuthMaxTotal-
Octets. When the value of the authorized maximum octet count is exceeded, the non-AP STA shall
be disassociated using the MLME-DISASSOCIATE.request primitive with a reason code of
PEER_INITIATED.
11.25.6 Interworking procedures: emergency services support
Emergency services support provides STAs with the ability to contact authorities in an emergency situation.
The following procedures allow the STA to determine whether emergency services are supported by the AP
or mesh STA, and whether unauthenticated emergency service access is allowed.
In an AP, when dot11ESNetwork is true, the network is dedicated and limited to accessing emergency
services. When dot11ESNetwork is true, the Access Network Type field in the Interworking element shall be
set to the value for “Emergency services only network” (see Table 9-214). When dot11ESNetwork is false,
the network is not limited to accessing emergency services, and the Access Network Type field in the
Interworking element shall be set to a value other than “Emergency services only network.” See Table 11-16.
Table 11-16—ESR and UESA field settings
Description ESR UESA
It is unspecified whether emergency services are reachable. 0 0
Emergency services are only reachable for authenticated STAs. 1 0
Reserved 0 1
Emergency services are reachable for STAs. 1 1
When an AP is located in a regulatory domain that requires emergency location capabilities, the ESR field
shall be set to 1; otherwise the ESR field shall be set to 0. When an AP is located in a regulatory domain that
requires emergency location capabilities and location capability is enabled on the AP, the Network Type shall
be set to “Emergency services only network” (see Table 9-214), if location capability is enabled on the AP;
1841
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
otherwise the ESR field shall not be set to 1 and the Network Type shall not be set to “Emergency services
only network”. In Beacon and Probe Response frames, location capability is advertised when the Civic
Location or Geo Location field in the Extended Capabilities Element is set to 1.
In an MBSS, if location capability is supported, the mesh STA shall report its location for emergency services.
When dot11ESNetwork is true in a mesh STA, the ESR shall be set to 1. When that mesh STA receives a
Mesh Peering Open frame that includes the Interworking element with the ASRA field equal to 1, it allows
access to emergency services and forwards MSDUs to an emergency server.
NOTE—The ASRA bit set to 1, informs the mesh STA to prioritize resources for the emergency call, to proactively find
a better path before the link conditions deteriorate below a certain threshold, and/or to change some of the mesh STA’s
behavior (for example, to disable any power save features).
When dot11ESNetwork is false in a mesh STA, the ESR shall be set to 0. When that mesh STA receives a
Mesh Peering Open frame that includes the Interworking element with the ASRA field equal to 1, it is unable
to support the mesh peering of emergency services and does not forward MDSUs to an emergency server.
11.25.7 Interworking procedures: emergency alert system (EAS) support
The EAS provides alerts, typically issued by authorities. The Interworking Procedures EAS support enables
the alerts to be transmitted upon request from APs to non-AP STAs. Subsequent to advertisement in Beacon
and Probe Response frames, a non-AP STA uses GAS queries to retrieve an EAS message from the network
according to the following procedures.
When dot11EASActivated is true, EAS operation shall be supported. When EAS operation is not supported,
dot11EASActivated shall be equal to false.
When the IEEE 802.11 infrastructure is informed of the availability of an EAS message (the mechanism by
which is outside the scope of this standard), an AP with dot11EASActivated equal true shall advertise the
availability of the EAS message by including an Emergency Alert Identifier element (see 9.4.2.97) for that
message in its Beacon and Probe Response frames. The AP shall include one instance of an Emergency
Alert Identifier element in its Beacon and Probe Response frames for each active EAS Message. The
Emergency Alert Identifier element provides an Alert Identifier Hash value, a unique indicator of the EAS
Message of the alert to the non-AP STA. The Alert Identifier Hash value allows the non-AP STA to
determine whether this is a new alert.
NOTE—The same value of hash will be computed by each AP in an ESS and by each AP in different ESSs. Thus a non-
AP STA, which can download emergency alert messages when in a preassociated state, can unambiguously determine
that it has already downloaded the message, avoiding unnecessary duplicates.
When an EAS Message has expired (the mechanism by which is outside the scope of this standard), an AP
with dot11EASActivated equal true shall remove the corresponding instance of an Emergency Alert Identifier
element from its Beacon and Probe Response frames.
The Alert Identifier Hash in the Emergency Alert Identifier element shall be computed using HMAC-SHA-
1-64 hash algorithm as shown in 9.4.2.97.
After receiving an Alert Identifier Hash value for an EAS Message that has not already been retrieved from
the network, a non-AP STA having dot11EASActivated equal true can retrieve the EAS message from the
AP as follows
— The procedures defined in 11.25.3.2, transmit the Alert Identifier Hash of the desired message in the
Query request field of a GAS Initial Request frame. The Advertisement Protocol ID field in the GAS
Initial Request frame is set to the value for EAS (see Table 9-215).
— The Query response is a message formatted in accordance with OASIS EDXL.
1842
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— A URI is formed by concatenating the Emergency Alert URI with the hexadecimal numerals of the
Alert Identifier Hash converted to lowercase ASCII encoded characters and the “.xml” file
extension. For example, if the Emergency Alert URI is http://eas.server.org and the Alert Identifier
Hash is 0x1234567890abcdef, then the URI would be http://eas.server.org/1234567890abcdef.xml
(the mechanism by which the URI is retrieved is outside the scope of this standard). The XML file is
formatted in accordance with OASIS EDXL. The non-AP STA retrieves the Emergency Alert URI
(see 9.4.5.16) using an ANQP request according to the procedures in 11.25.3.3. This method is
recommended for non-AP STAs in the associated state.
11.25.8 Interworking procedures: support for the advertisement of roaming consortiums
APs can assist non-AP STAs performing network discovery and selection through the advertisement of a
Roaming Consortium element. The Roaming Consortium element contains information identifying an SSP
or group of SSPs (i.e., a roaming consortium) whose security credentials might be used to authenticate with
the AP transmitting this element. An SSP or group of SSPs can register for and obtain an OI using the
procedures described in [B19]. Note that a non-AP STA may also use GAS procedures defined in
11.25.3.3.3 to retrieve a Roaming Consortium ANQP-element, which might contain more OIs than the
Roaming Consortium element.
APs having dot11InterworkingServiceActivated equal true and having one or more entries in the
dot11RoamingConsortiumTable shall include the Roaming Consortium element in Beacon and Probe
Response frames. An AP shall only include an OI in the dot11RoamingConsortiumTable, if, in conjunction
with an AS, the AP is capable of successfully authenticating a non-AP STA that holds valid security
credentials for the SSPN identified by that OI. Methods used by the AP to authenticate the non-AP STA
include, but are not limited to, RSNA algorithms and Open System authentication.
A non-AP STA might have a locally stored binding between an OI and a set of security credentials with
which it can authenticate to the network identified by the OI, that is, the SSPN. The method by which this
binding is obtained is outside the scope of this standard. A non-AP STA might select from that list of
credentials when authenticating to the BSS.
11.25.9 Interworking procedures: support for QoS mapping from external networks
Maintaining proper end-to-end QoS is an important factor when providing interworking service. This is
because the external networks might employ different network-layer (Layer 3) QoS practices. For example,
the use of a particular differentiated services code point (DSCP) for a given service might be different
between different networks. To provide proper QoS over-the-air in the IEEE 802.11 infrastructure, the
mapping from DSCP to UP for the corresponding network needs to be identified and made known to the
STAs. If an inconsistent mapping is used then:
— Admission control at the AP may incorrectly reject a service request, because the non-AP STA used
the incorrect UP.
— Non-AP STAs might use the incorrect value for User Priority in TSPEC and TCLAS elements.
— The user might be given a different QoS over the IEEE 802.11 network than expected, e.g., a lower
QoS might be provided than the STA expected.
Therefore, APs with dot11QosMapActivated equal true shall set the QoS Map field in the Extended
Capabilities element to 1; APs with dot11QosMapActivated equal false shall set the QoS Map field in the
Extended Capabilities element to 0. The AP’s SME causes the QoS mapping to be available to higher layer
protocols or applications so they will be able to set the correct priority in an MA-UNITDATA.request
primitive.
1843
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For frames transmitted by an AP belonging to an admitted TS, the UP obtained from the TS’s TCLAS
element shall be used instead of the UP derived from the QoS mapping. For frames transmitted by an AP
belonging to an admitted TS not having a TCLAS element, the UP shall be derived from the QoS mapping.
Non-AP STAs when dot11QosMapActivated is equal true shall set the QoS Map field in the Extended
Capabilities element to 1. An AP receiving an Association Request frame or Reassociation Request frame
when the QoS Map field in the Extended Capabilities element is equal 1 shall include the QoS Map element
in the corresponding Association Response frame or Reassociation Response frame as defined in 9.3.3.7 or
9.3.3.9 respectively. Upon receiving the QoS Map element, the non-AP STA’s SME causes the QoS
mapping to be available to higher layer protocols or applications so they will be able to set the correct
priority in an MA-UNITDATA.request primitive.
When the AP’s SME detects a change in the QoS mapping information, it shall update the non-AP STA with
the new QoS Map element. It accomplishes this update by invoking the MLME-QOS-MAP.request
primitive.
When the MAC entity at the non-AP STA receives a QoS Map Configure frame from the AP, the MLME
shall issue an MLME-QOS-MAP.indication primitive to its SME.
When the non-AP STA’s SME receives the QoS Map response, it shall make the QoS Map available to
higher layers so that in turn, they can invoke the MA-UNITDATA.request primitive with the correct priority.
11.26 Quality-of-service management frame (QMF)
11.26.1 General
11.26.1.1 Overview
A QMF STA shall set dot11QMFActivated and dot11QosOptionImplemented to true. The QMF STA shall
assign an access category to each Management frame according to the access category assignments
indicated in the QMF policy that has been configured using the configuration procedures described in
11.26.2.
A QMF STA shall set the QMFActivated subfield in the Extended Capabilities element to 1.
A Management frame shall be transmitted as an IQMF when all five of the following conditions are met:
— The RA of the Management frame corresponds to an individual MAC address.
— The frame is transmitted by a QMF STA.
— The transmitting STA has previously received an Extended Capabilities element from the STA
corresponding to the RA of the frame being transmitted.
— The most recently received such Extended Capabilities element indicated that the STA is a QoS
STA and has the value of 1 in the QMFActivated subfield.
— The frame is not a time priority Management frame.
A QMF AP shall transmit a Management frame as a GQMF when all three of the following conditions are
met:
— The RA of the Management frame corresponds to a group MAC address.
— The transmitting STA has received an Extended Capabilities element that has the QMFActivated
subfield equal to 1 from every member of the BSS corresponding to the BSSID of the Management
frame.
— The frame is not a time priority Management frame.
1844
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A non-AP QMF STA shall transmit a Management frame as a GQMF when all three of the following
conditions are met:
— The RA of the Management frame corresponds to a group MAC address.
— The transmitting STA has received an Extended Capabilities element that has the QMFActivated
subfield equal to 1 from its associated AP.
— The frame is not a time priority Management frame.
A Management frame shall not be transmitted as an IQMF or GQMF, except as defined above.
NOTE—This standard assumes that all APs in an ESS are configured consistently for QMF service when GQMF has
been enabled for use by associated non-AP STAs.
When the QMFActivated subfield is zero in the most recently received Extended Capabilities element from
a destination STA, or when an Extended Capabilities element has not been received from a destination STA,
a transmitting QMF STA shall transmit individually addressed Management frames to that destination STA
using access category AC_VO.
If the QMFActivated subfield in the most recently received Extended Capabilities element from a
destination QMF STA is equal to 1, but no QMF Policy element has been received from the destination
QMF STA, and, if associated, no QMF Policy element has been received from the QMF AP with which the
STA is associated, then a QMF STA shall transmit all IQMFs to the destination QMF STA using the default
QMF policy access categories defined in Table 11-17. Otherwise, the QMF STA shall transmit individually
addressed Management frames as defined in the QMF policy included in the QMF Policy element accepted
from the destination QMF STA. In either case, the transmitted Management frames are IQMFs, and the
transmitting QMF STA shall indicate the access category used to transmit the frame in the ACI subfield of
the sequence number field.
A QMF STA in an unassociated state shall transmit all group-addresses Management frames as non-QMF.
An associated QMF STA shall follow the QMF policy dictated by its associated AP for transmitting GQMFs
as described in 11.26.2. The specific access category assignments of different Management frames in a
nondefault QMF policy are beyond the scope of this document. The transmitting QMF STA shall indicate
the access category used to transmit GQMFs in the ACI subfield of the sequence number field.
Time-priority Management frames, when not sent as an immediate response, shall be transmitted using
AC_VO.
11.26.1.2 Default QMF policy
The default QMF policy is as defined in Table 11-17. It defines the access category of each Management
frame based on management subtype value, category value, and action value. QMFs not included in this
table shall be assigned an access category AC_BE.
Table 11-17—Default QMF policy
Management Frame
Category value QMF access
Description Subtype value from Action field
from Table 9-47 category
Table 9-1
(Re)Association Request/ 0000–0011 N/A N/A AC_VO
Response
Probe Request 0100 N/A N/A AC_VO
(individually addressed
1845
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-17—Default QMF policy (continued)
Management Frame
Category value QMF access
Description Subtype value from Action field
from Table 9-47 category
Table 9-1
Probe Request (group 0100 N/A N/A AC_BE
addressed)
Probe Response 0101 N/A N/A AC_BE
Timing Advertisement 0110 N/A N/A AC_BE
Beacon, ATIM, 1000–1100 N/A N/A AC_VO
Disassociation,
Authentication,
Deauthentication
Spectrum management 1101 0 0–3 AC_BE
Spectrum management— 1101 0 4 AC_VO
channel switch
announcement
QoS 1101 1 0–3 AC_VO
DLS 1101 2 0–2 AC_BE
Block Ack 1101 3 0–2 AC_VO
Public 1101 4 0, 1, 3, 5–6, AC_BE
8–9
Public—DSE 1101 4 2, 4 AC_VO
deenablement, extended
channel switch
announcement
Public—measurement 1101 4 7 AC_VO
pilot
Public—TDLS 1101 4 14 AC_VO
Discovery Response
Public—Fine Timing 1101 4 32 AC_VO
Measurement Request
Public—Fine Timing 1101 4 33 AC_VO
Measurement
Radio measurement 1101 5 0–5 AC_BE
Fast BSS Transition 1101 6 0–4 AC_VO
HT 1101 7 0–3 AC_VO
HT 1101, 1110 7 4–7 AC_VO
SA Query 1101 8 0–1 AC_VO
Protected Dual of Public 1101 9 1–2, 5–6, AC_BE
Action 8–9
Protected Dual of Public 1101 9 4 AC_VO
Action—extended channel
switch announcement
WNM 1101 10 0–24 AC_BE
1846
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-17—Default QMF policy (continued)
Management Frame
Category value QMF access
Description Subtype value from Action field
from Table 9-47 category
Table 9-1
Unprotected WNM 1101 11 0–1 AC_BE
Mesh Action—HWMP 1101 13 1 AC_VO
Mesh Path Selection
Mesh Action— 1011 13 3 AC_VO
Congestion Control
Mesh Action 1101 13 0, 2, 4–10 AC_BE
Multihop Action 1101 14 0–1 AC_BE
Self Protected 1101 15 0–5 AC_VI
DMG 1101 16 0–22 AC_BE
Reserved (used by (used 1101 17 All AC_BE
by the Wi-Fi Alliance a))
Fast Session Transfer 1101 18 0–5 AC_VO
Robust AV Streaming 1101 19 0–3 AC_BE
Unprotected DMG 1101 20 0–1 AC_VO
VHT 1101, 1110 21 0–2 AC_VO
Vendor-specific Protected 1101 126 N/A AC_BE
Vendor-specific 1101 127 N/A AC_BE
aSee
http://www.wi-fi.org.
11.26.2 QMF policy advertisement and configuration procedures
11.26.2.1 Overview
QMF policies are exchanged and implemented between two QMF STAs. A STA’s QMF policy is advertised
and exchanged using the QMF Policy element described in 9.4.2.120.
A non-AP QMF STA operating in a BSS shall not transmit a QMF Policy frame to an AP.
The access category for a QMF that is transmitted by a non-AP QMF STA to a peer QMF STA shall be
determined from the QMF policy received from the peer if a QMF policy has been received from the peer.
Otherwise, the default policy shall be used. The access category for a QMF that is transmitted by a QMF AP
is determined from the QMF policy configured at that AP.
In a BSS or MBSS, the access category for any Management frame may be reconfigured. For example,
vendor-specific and vendor-specific protected Management frames might be reconfigured to suit the vendor
application requirements.
1847
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.26.2.2 QMF policy change in an infrastructure BSS or in an MBSS
A QMF Policy Change frame is transmitted by a QMF STA to request a change to the QMF policy that the
requesting QMF STA will use for transmitting Management frames to the peer QMF STA in an infrastruc-
ture BSS or in an MBSS.
A STA may transmit a QMF Policy Change frame to request a change in the QMF policy for transmitting to
a peer STA. A non-AP QMF STA that receives a QMF Policy Change frame may either accept or reject the
request. An associated non-AP QMF STA may transmit a QMF Policy Change to the QMF AP in its BSS
only if the Extended Capabilities element received from the AP has its QMFReconfigurationActivated
subfield equal to 1. If the AP rejects the request, the associated QMF STA shall not request the same policy
reconfiguration from the AP during the lifetime of its association.
An AP shall respond to a QMF Policy Change frame received from an associated STA by transmitting a
QMF Policy frame. If the QMFReconfigurationActivated subfield is zero in the Extended Capabilities
element in the Beacon frame, an AP that receives a QMF Policy Change frame from an associated STA shall
respond with a QMF Policy frame, with Status Code set to REQUEST_DECLINED. If the
QMFReconfigurationActivated subfield is 1 in the Extended Capabilities element in the Beacon frame, an
AP that receives a QMF Policy Change frame from an associated STA shall evaluate the QMF Policy
included in the frame, and shall respond to the request with the resulting QMF Policy element and Status
Code set to SUCCESS if it accepts the policy change, or REQUEST_DECLINED if it rejects the policy
change. A QMF AP may transmit a QMF Policy frame with Status Code set to SUCCESS to an associated
QMF STA without having first received a QMF Policy Change frame from that STA.
If an accept status is received in a QMF Policy frame within dot11QMFPolicyChangeTimeout of having
transmitted a QMF Policy Change frame with the same dialog token to the STA that transmitted the QMF
Policy frame, then the requesting QMF STA shall transmit any subsequently queued Management frames to
the peer QMF STA in accordance with the changes to the QMF policy that were indicated in the QMF
Policy Change frame.
If a reject status is received in a QMF Policy frame within dot11QMFPolicyChangeTimeout of having
transmitted a QMF Policy Change frame with the same dialog token to the STA that transmitted the QMF
Policy frame as a response to a QMF Policy Change frame, then the configuration change request is rejected
and the requesting QMF STA shall continue to transmit Management frames to the peer QMF STA in
accordance with the previously configured QMF policy. The requesting QMF STA shall not transmit a QMF
Policy Change frame with a previously rejected QMF policy to a peer QMF STA within
dot11QMFPolicyChangeTimeout from the time the requesting STA received the rejection frame.
If the requesting STA does not receive a QMF Policy frame in response to a QMF Policy Change frame
within dot11QMFPolicyChangeTimeout, then the requesting STA shall continue to transmit frames
according to the previously configured QMF policy.
If a QMF STA has received an Extended Capabilities element with the QMFReconfigurationActivated
subfield equal to 0 or has not received an Extended Capabilities element from a destination QMF STA, the
QMF STA shall not transmit a QMF Policy Change frame to the destination QMF STA.
A QMF mesh STA or a QMF AP may set dot11QMFReconfigurationActivated to true or false. A non-AP
QMF STA in an infrastructure BSS shall set dot11QMFReconfigurationActivated to true and shall set the
QMFReconfigurationActivated subfield to 1 in transmitted (re)association requests. A non-AP QMF STA
with dot11QMFReconfigurationActivated equal to true shall accept any received QMF Policy frame from
its associated AP. A QMF STA with dot11QMFReconfigurationActivated equal to false shall respond with
a QMF Policy frame, with the current QMF Policy element and Status Code set to REQUEST_DECLINED.
1848
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The QMFReconfigurationActivated subfield shall be set to one in the Extended Capabilities element when
dot11QMFReconfigurationActivated is true. The QMFReconfigurationActivated subfield shall be set to 0 in
the Extended Capabilities element when dot11QMFReconfigurationActivated is false.
The SME of a peer QMF STA uses the MLME-QMFPOLICY primitives (see 6.3.85.2 to 6.3.85.3) to
transmit a QMF Policy frame to a peer STA. The SME of a peer STA uses the MLME-
QMFPOLICY.request primitive to transmit a QMF Policy frame to a peer STA. The MLME of a peer QMF
STA shall set the dialog token to 0 and set the Status Code to SUCCESS when the QMF Policy frame is
transmitted unsolicited to the peer STA.
The SME of a peer QMF STA uses the MLME-QMFPOLICYCHANGE primitives (see 6.3.85.4 to
6.3.85.7) to exchange the QMF Policy Change and QMF Policy frames. The SME of a peer STA uses the
MLME-QMFPOLICYCHANGE.request primitive to transmit a QMF Policy Change frame to a peer STA.
The value of the dialog token in the MLME-QMFPOLICYCHANGE.request primitive shall be set to a
value in the range 1 to 255.
The SME of the peer STA evaluates the QMF policy and uses the MLME-
QMFPOLICYCHANGE.response primitive to transmit a QMF Policy frame to the STA including the result
of the QMF policy change. The value of the dialog token in the MLME-QMFPOLICYCHANGE.response
primitive shall be set to the value of the dialog token received in the corresponding MLME-
QMFPOLICYCHANGE.indication primitive.
When the QMF STA SME receives an MLME-QMFPOLICYCHANGE.confirm primitive or MLME-
QMFPOLICY.indication primitive with Result Code of SUCCESS, it shall set the new QMF policy using
the MLME-QMFPOLICYSET.request primitive.
An AP for which dot11AlternateEDCAActivated is true shall not use the alternate video (A_VI) nor
alternate voice (A_VO) transmit queues in its QMF policy.
11.26.2.3 QMF policy configuration in an infrastructure BSS
A QMF AP shall include the QMF Policy element in Beacon frames that it transmits. Non-AP QMF STAs
acquire QMF policy configuration information from QMF Policy elements received in Beacon, Association
Response, Reassociation Response, Probe Response, and QMF Policy frames. The interpretation of the
QMF Policy element is described in 11.26.3.
An associated QMF STA transmitting QMFs shall transmit those frames in accordance with the QMF policy
received from its associated AP in the following order of precedence, from highest to lowest:
— QMF policy defined in an unsolicited QMF Policy frame from the associated QMF AP or the QMF
Policy Change frame that resulted in a successful response QMF Policy frame from the associated
AP, whichever occurred most recently
— QMF policy defined in the QMF Policy element received in the successful (Re)Association
Response frame
All unassociated QMF STAs transmitting Management frames to a QMF AP shall transmit those frames to
the AP in accordance with the QMF policy in the most recently received Beacon or Probe Response frame
from that AP. If no frame containing a QMF Policy element has been received from the AP prior to the
transmission of the Management frame(s), then the Management frame(s) shall be transmitted using the
access categories of the default QMF policy defined in Table 11-17.
A QMF STA shall transmit all Management frames that are individually addressed to non-QMF STAs using
access category AC_VO.
1849
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A QMF AP shall set a QMF policy for the transmission of QMFs to its associated STAs. The QMF policy
used by the AP for transmission of QMFs to associated STAs is not required to be the same as the QMF
policy it advertises.
If the QMFReconfigurationActivated subfield is equal to 1 in the Extended Capabilities element of the
Beacon or Probe Response frame transmitted by the AP, an associated QMF STA may use the QMF Policy
Change frame to request a change in its existing QMF policy.
11.26.2.4 QMF policy configuration in an IBSS or OCB
QMF STAs in an IBSS or OCB shall use the default QMF policy for all individually addressed Management
frames transmitted to other QMF STAs in the IBSS or OCB.
11.26.2.5 QMF policy configuration in an MBSS
A QMF STA operating in an MBSS shall set the QMFActivated subfield in the Extended Capabilities
element to true. The Mesh Beacon frame shall not include a QMF Policy element. The QMF in an MBSS
policy shall be set on a per link basis between two QMF STAs.
The QMF Policy Change and QMF Policy frames are used by QMF STAs in an MBSS to configure QMF
policy. See 11.26.2.2.
A QMF STA shall always accept the QMF policy from the QMF Policy frame transmitted by the peer QMF
STA and shall transmit all individually addressed Management frames destined to the peer QMF STA using
the received QMF policy.
A QMF STA may request a change in the QMF policy from a peer QMF STA by transmitting a QMF Policy
Change to the peer QMF STA. The peer QMF STA may accept or reject this change request. If the peer
QMF STA accepts the change, it shall respond with a QMF Policy frame with Status Code set to SUCCESS
and the QMF STA shall transmit IQMFs using the new QMF policy to the peer QMF STA. If the peer QMF
STA rejects the change, it shall respond with QMF Policy frame with Status Code set to
REQUEST_DECLINED and the QMF STA shall continue transmitting IQMFs according to the previously
configured QMF policy.
If a QMF STA does not receive a QMF Policy frame from a peer QMF STA, it shall transmit Management
frames to that peer STA using the default QMF policy.
QMF STAs in an MBSS shall not include policies for group addressed Management frames in the QMF
Policy Config Request.
11.26.3 Interpreting QMF access categories
The QMF Policy element, as defined in 9.4.2.120, indicates the transmit access categories of different
Management frames. A QMF Policy element with Length field of value 1 means that the access category of
all Management frames is as defined in the default QMF policy in Table 11-17.
When the value of the Individually Addressed subfield is 1, then the QACM applies to IQMFs. When the
value of the Group Addressed subfield is 1, then the QACM applies to GQMFs. A STA shall not transmit a
QMF Policy element with both the Individually Addressed and Group Addressed subfields set to 0 in any of
the included QACM subfields.
The QMF Policy element contains zero or more QACM fields. When included in the QMF Policy element,
each QACM field indicates the access category of a group of Management frames. Using the description
from Table 11-18, access categories for all Management frames belonging to either a given subtype or a
1850
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
given action category may be indicated in a single QACM field. When multiple Action frames of the same
Category are to be mapped to the same Access Category, this is indicated by setting multiple bits in the
Action Value Bitmap. For example, setting Bit 0 and Bit 1 indicates Event Request/Response frames when
the Management Frame Subtype subfield refers to Management frames of subtype Action and the Category
Value subfield refers to the WNM category. The QACM field also may be used to indicate the access
category of a single management frame subtype.
A QMF STA that received a QMF Policy element from its associated QMF AP shall discard any previously
received QMF Policy elements. If a Management frame is indicated in multiple QACM fields, the access
category of the Management frame is determined by the access category defined in the last QACM field in
the QMF Policy that contains the access category assignment of the corresponding Management frame. For
example, if an QACM field sets the entire WNM category to access category AC_BE and a later QACM
field sets Event Request/Report of WNM category to AC_BK, then all Action frames of WNM category are
transmitted using access category AC_BE with the exception of Event Requests/Reports, which are
transmitted using access category AC_BK.
Table 11-18—QMF policy description for valid combination of optional fields
in the QACM field
QACM field
Action frame Action Value
Length Description
category Bitmap subfield
subfield
0 Not included Not included Policy to be applied to all Management frames of
the corresponding subtype
1 Included Not included Policy to be applied to all Action frames of
corresponding category value
2 Included Included Policy to be applied only to Action frames
indicated via the action value bitmap for
Management frames of the subtype indicated in
the Management Frame Subtype subfield and the
category value indicated in the Action Frame
Category subfield in the corresponding QACM
field
11.27 Robust AV streaming
11.27.1 Robust AV streaming dependencies
When dot11RobustAVStreamingImplemented is true, the STA is a robust AV streaming STA. The attribute
dot11QosOptionImplemented shall be true in a robust AV streaming STA.
11.27.2 SCS procedures
The stream classification service (SCS) is a service that may be provided by an AP to its associated STAs
that support SCS. In SCS, the AP classifies incoming unicast MSDUs based upon parameters provided by
the non-AP STA.
The classification allows the UP, drop eligibility, and EDCA transmit queue to be selected for all MSDUs
matching the classification.
1851
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Implementation of SCS is optional for a STA. A STA that implements SCS shall set its
dot11SCSImplemented to true. A STA whose dot11SCSActivated value is true shall support stream
classification and shall set to 1 the SCS field of the Extended Capabilities elements that it transmits. If
dot11SCSActivated is true, dot11SCSImplemented shall be true.
A non-AP STA that supports SCS may request use of SCS by sending an SCS Request frame that includes
an SCS Descriptor element with the Request Type field set to “Add” or “Change.” The SCS Descriptor List
field in the SCS Descriptor element identifies how MSDUs are classified and the priority to assign to
MSDUs that match this classification. If the TCLAS Processing element is present in an SCS Descriptor
element, the Processing subfield shall have a value of 0 or 1. An AP shall decline any SCS Request frame
where a TCLAS Processing element is present and the Processing subfield does not have a value of 0 or 1.
Each SCS stream is identified by an SCSID. This SCSID is used by a non-AP STA to request creation,
modification, or deletion of an SCS stream. The SCSID is used by an AP to identify an SCS stream in SCS
responses.
Upon receipt of an SCS Request frame from an associated non-AP STA, the AP shall respond with a
corresponding SCS Response frame. A value of “SUCCESS” shall be set in the corresponding Status field
of the SCS Status duple in the SCS Response frame when the AP accepts the SCS request for the requested
SCSID. A value of “REQUEST_DECLINED,” “REQUESTED_TCLAS_NOT_SUPPORTED_BY_AP,” or
“INSUFFICIENT_TCLAS_PROCESSING_RESOURCES” shall be set in the corresponding SCS Status
field of the SCS Status duple in the SCS Response frame when the AP denies the SCS request for the
requested SCSID.
If the AP declines a request to change a previously accepted SCSID, the previously accepted classification
for this SCSID continues to operate.
If the requested SCS is accepted by the AP, the AP shall process subsequent incoming unicast MSDUs from
the DS or WM that match the TCLAS elements and optional TCLAS Processing element classifier specified
in the SCS Descriptor element.
A match of the classifier is defined as follows:
— When the Processing subfield of the TCLAS Processing element is 0, the classifier matches all of
the parameters in the TCLAS elements in the SCS Descriptor element.
— When the Processing subfield of the TCLAS Processing element is 1 or the TCLAS Processing
element is not present, the classifier matches if the parameters match at least one of the TCLAS
elements in the SCS Descriptor element.
The processing of matching MSDUs depends upon the access policy assigned to the MSDU:
— For matching MSDUs that are not part of a TS (as described in 11.4), the User Priority subfield of
the Intra-Access Category Priority element is used as the UP of these MSDUs.
— For matching MSDUs that are part of a TS (as described in 11.4), the TID and UP classification of
these MSDUs shall follow the rules specified in 11.4.8.
— If dot11AlternateEDCAActivated is true, for matching MSDUs that are not part of a TS (as
described in 11.4) or for MSDUs that are part of a TS that uses EDCA or HEMM as the access
policy, the Alternate Queue subfield of the Intra-Access Category Priority element is used to select
whether the primary EDCA transmit queue or alternate EDCA transmit queue is used for these
MSDUs.
— All matching MSDUs have their DEI set using the value from the Drop Eligibility subfield of the
Intra-Access Category Priority element in the DEI subfield of the HT Control field, as defined in
9.2.4.6.
1852
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A non-AP STA may request the termination of an accepted SCS stream by sending an SCS Request frame
with the Request Type field set to “Remove” and the requested SCSIDs in the SCS Descriptor element. The
Length field of the SCS Descriptor element is set to 0; and no Intra-Access Priority, TCLAS, or TCLAS
Processing elements shall be included in the SCS Descriptor element.
Upon reception of a request to terminate a previously accepted SCS stream, the AP shall cease to apply the
classifier related to this SCSID. The AP shall send an SCS Response frame to confirm the termination of the
SCS stream identified by the SCSID, by including the SCSID and a value of “Terminate” in the Status field
of an SCS Status duple in an SCS Response frame and the dialog token in the SCS Response frame set to the
value from the SCS Request frame that requested termination.
The AP may send an unsolicited SCS Response frame at any time to cancel a granted SCS stream identified
by the SCSID, by including the SCSID and a value of “Terminate” in the Status field of an SCS Status duple
in an SCS Response frame and the dialog token in the SCS Response frame set to 0.
11.28 Procedures to manage OBSS
11.28.1 General
QLoad Report elements, HCCA TXOP Update Count elements, HCCA TXOP Advertisement action frames,
and HCCA TXOP Response frames are designed to mitigate the effects of OBSSs and provide the means to
— Advertise QoS load information for channel selection
— Extend the admission control and scheduled mechanisms to a distributed environment
— Enable the coordination of scheduled HCCA TXOPs between HCs operating with OBSSs
OBSS APs are APs that are using the same primary channel and that are able to receive or obtain frames
from each other, including Beacon frames. These frames are received directly or via associated STAs that
support the Beacon request capability (as indicated by the Beacon Passive Measurement Capability Enabled
bit or the Beacon Active Measurement Capability Enabled bit being set in the RM Enabled Capabilities
element in the (Re)Association frame). An AP might scan other channels as part of its channel selection
process or might request associated STAs that support the Beacon request capability to perform an off-
channel Beacon request measurement, and these procedures might provide QLoad Report elements received
from APs operating on other channels. Subclause T.3 provides an example of using QLoad Reports from
adjacent channels.
NOTE 1 These OBSS procedures might use unauthenticated Beacon frames and Public Action frames.
Implementations might choose to use additional heuristics (e.g., a history of collaboration and traffic monitoring) to
determine the authenticity of this information.
NOTE 2 These OBSS procedures are intended for stationary and portable APs (see 4.2.4).
11.28.2 QLoad Report element
11.28.2.1 Introduction
The QLoad Report element is contained in QLoad Report frames or Protected QLoad Report frames that are
provided by an AP and, optionally, periodically in the Beacon frame. The QLoad Report frame is
transmitted, upon the receipt of a QLoad Request frame by an AP for which dot11QLoadReportActivated is
true, to the STA that sent the QLoad Request frame. An AP shall not send a QLoad Request frame or
Protected QLoad Request frame to another AP that has QLoad Report field set to 0 in its Extended
Capability element. The Protected QLoad Report frame is transmitted, upon the receipt of a Protected
QLoad Request frame when dot11ProtectedQLoadReportActivated is true, to the STA that sent the
Protected QLoad Request frame. An AP for which dot11ProtectedQLoadReportActivated is false shall
discard any received Protected QLoad Request or Protected QLoad Report frames.
1853
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Whenever there is a change in the contents of the QLoad Report element and there is no pending delay
period for an unsolicited QLoad Report frame, an unsolicited QLoad Report frame should be transmitted
with the RA field set to the broadcast address, after a randomly selected delay between 1 and
dot11QLoadReportDelay seconds. After this delay, the AP shall transmit an unsolicited QLoad Report
frame that contains the most recently available QLoad information. When dot11QLoadReportActivated is
true, the QLoad Report element shall be included in the Beacon frame every
dot11QLoadReportIntervalDTIM DTIMs. When dot11QLoadReportActivated is false, the QLoad Report
element shall not be included in Beacon frames.
11.28.2.2 Calculating field values
The value of the Potential Traffic Self field represents the potential QoS traffic of this BSS; therefore, the
value in the Mean subfield shall always be greater than or equal to the value of the Mean subfield in the
Allocated Traffic Self field.
The AP shall include in the Allocated Traffic Self field all accepted and not deleted TSPECs as they are sent
by non-AP STAs. At the deletion of each such TSPEC, the AP shall remove the TSPEC from its Allocated
Traffic Self field.
The number of active AC_VI and AC_VO streams shall be provided in the Allocated Traffic Self field. For
each admitted admission control TSPEC, the AP calculates a medium time, as described in K.2.2. This
medium time, however, does not include the medium access overhead that, in turn, is related to the number
of streams. This access overhead is further discussed in T.2.7, and a recommendation is given for its value.
An example of a method of calculating the values for the Mean and Standard Deviation subfields in the
Potential Traffic Self field is given in T.2.3.
The Sharing Policy field is used to indicate the currently active policy for sharing the medium with OBSSs.
Setting the Sharing Policy field to “Static” indicates that the share of the total available medium time of an
AP does not change when the value of the Allocated Traffic Shared field changes. Setting the Sharing Policy
field to “Dynamic” indicates that the share of the total available medium time of an AP might change when
the value of the Allocated Traffic Shared field changes. If the Sharing Policy field has the value “Vendor
Specific,” then the QLoad Report element shall contain a Vendor Specific subelement.
If the value of the Overlap field changes, the share of the total available medium time of an AP might change
for both static and dynamic sharing policies.
The value of the Potential Traffic Self field represents the potential QoS traffic of this AP and, therefore,
shall always be greater than or equal to the values represented by the Allocated Traffic Self field.
The Allocated Traffic Self field contains the mean and standard deviation values of the total EDCA
admission control and HCCA traffic that the AP has allocated at any one time and contains the number of
AC_VI and AC_VO EDCA admission control streams. As each stream is added or deleted, the AP shall
calculate the new value of the Allocated Traffic Self field. A recommended method for calculating the
Allocated Traffic Self field mean and standard deviation values is given in T.2.4.
The Allocated Traffic Shared field is calculated from the Allocated Traffic Self field values for all APs that
overlap with the AP performing the calculation, including the Allocated Traffic Self field value of the AP
performing the calculation. A recommended method for summing the Allocated Traffic Self field values is
given in T.2.4.
The EDCA Access Factor is the total traffic bandwidth requirement for all of the OBSSs expressed as a
fraction that may be greater than 1. An implementation might calculate the EDCA Access Factor from the
summation of the Potential Traffic Self field values of all of the APs that are overlapping, as follows:
1854
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) Sum all of the Potential Traffic Self field values for all OBSSs, including self, in order to calculate
the peak traffic requirement in multiples of 32 µs per second. As the Potential Traffic Self field
value is expressed in terms of mean and standard deviations, it is possible to sum the Potential
Traffic Self field values as a composite stream. A suggested method for this summation is given in
T.2.3.
b) Sum all of the HCCA Peak field values from all OBSSs, including self, in order to calculate the peak
HCCA traffic requirement, in multiples of 32 µs per second.
c) Subtract the value derived in step b) from the value derived in step a). This value is the EDCA
traffic.
d) Sum the AC_VO and AC_VI streams reported in its own QLoad report and all of the QLoad reports
of OBSSs. Based upon the number of EDCA streams, an EDCA Overhead Factor can be estimated
to account for the medium access time requirements. EDCA Overhead Factor is further discussed in
T.2.3, and a recommendation is given for its value.
e) Multiply together the EDCA traffic from step c) and the EDCA Overhead Factor to obtain a value
that represents the total peak bandwidth requirement for the OBSSs. This value is in multiples of
32 µs per second.
f) Convert the total peak bandwidth requirement to a fraction that is rounded down to a multiple of
1/64 (8 bits). This value is the EDCA Access Factor. An example for this conversion is given in
T.2.6.
The HCCA Peak field value is the sum of the all of the medium times of active TS that use the HCCA or
HEMM access policy over a 1 s period for all of the HCCA TSPECs included in the QLoad field. The TXOP
time, scheduled by the HC, multiplied by the reciprocal of its SI, is termed the HCCA medium time. The
HCCA Peak field value is the summation of the HCCA medium times that the HC has scheduled, in
multiples of 32 µs.
The HCCA Access Factor is the total HCCA TXOP medium time requirement for all of the OBSSs
expressed as a fraction that may be greater than 1. An implementation might calculate the HCCA Access
Factor from the summation of the HCCA Peak field values of all of the APs that in an OBSS, by summation
of all of the HCCA Peak field values for all APs in OBSSs and converting this summation to a fraction that
is rounded down to 1/64 (8 bits). An example for this conversion is given in T.2.8.
11.28.2.3 Requesting QLoad Reports using radio measurement requests
If an AP has associated STAs that support passive or active beacon measurement (as indicated by the
Beacon Passive Measurement Capability Enabled bit or the Beacon Active Measurement Capability
Enabled bit being set in the RM Enabled Capabilities element), it may use the neighbor report capability of
these associated STAs to attempt to retrieve QLoad Report elements from APs with which the AP is unable
to exchange frames directly.
The AP sends a Radio Measurement Request frame that contains a Measurement Request element to an
associated STA that supports neighbor reporting and beacon reporting. This Measurement Request element
has the Measurement Type field set to “Beacon request” (as defined in Table 9-82), and the BSSID field of
the Measurement Request field of the Beacon request frame (as defined in Figure 9-156) is set to the
wildcard BSSID. There shall be a Request subelement in the Measurement Request field of the Beacon
request frame that contains the Element ID of the QLoad Report element (as defined in Table 9-77) and may
contain other element IDs. The SSID subelement shall not be included in the Request subelement of the
Measurement Request field of the Beacon request.
Depending upon the signaled enabled radio measurement capabilities of the associated STA, the AP may
use either the passive or active measurement mode. The Channel Number field should be set to the primary
1855
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
channel number that is currently being used by the AP, but may be set to other values if off-channel beacon
measurement is supported by the STA to which the measurement request is to be sent.
If the measurement request is accepted, the requested STA performs the measurement request (as described
in 11.11). The subsequent Radio Measurement Report frame contains beacon reports for successful
measurements. These beacon reports might contain QLoad Report elements inside a Reported Frame Body
subelement, if the reporting STA received QLoad Report elements from the Beacon or Probe Response
frames that it received from neighboring APs. The contents of these QLoad Report elements can then be
used in calculating Allocated Traffic Shared, EDCA Access Factor, and HCCA Access Factor field values
as described in 11.28.2.2.
11.28.3 HCCA TXOP negotiation
The procedures described in this subclause allow HCCA APs to cooperatively create new HCCA schedules
that do not collide.
When sharing with at least one other HCCA AP, each sharing AP for which
dot11RobustAVStreamingImplemented is true shall set its dot11HCCWmax to a value of at least 3.
HCCA APs that are able to directly exchange frames without the use of a third-party STA and signal support
for unprotected or protected TXOP negotiation (as indicated by the Unprotected TXOP Negotiation or
Protected TXOP Negotiation field equal to 1 in the Extended Capabilities element in Beacon frames)
coordinate their TXOP schedules using HCCA TXOP Advertisement and HCCA TXOP Response frames.
In this subclause, an HCCA AP in an OBSS that is able to directly exchange frames without the use of a
third-party STA is referred to as a collaboration candidate.
The HCCA TXOP Update Count element is included in the Beacon frame to indicate that an HCCA TXOP
schedule has changed. The Update Count field of the HCCA TXOP Update Count element is incremented
(modulo 256) each time a TS with an access policy of HCCA or HEMM is created or deleted. An HCCA AP
for which dot11PublicHCCATXOPNegotiationActivated is true or
dot11ProtectedHCCATXOPNegotiationActivated is true shall advertise the Duration, Service Interval, and
Start Time subfields for each HCCA TXOP reservation in a TXOP Reservation field as described in
9.4.1.44.
An HCCA AP for which dot11PublicTXOPNegotiationActivated is true or
dot11ProtectedTXOPNegotiationActivated is true shall be able to maintain one or more dot11APCEntry(s)
for each collaboration candidate in the dot11APCTable. These fields indicate the schedules that the AP
should try to avoid using when creating schedules for new TS requests.
Before accepting a TSPEC request that has the Access Policy subfield of the TSPEC element equal to
“HCCA” or “HEMM,” an HC for which dot11PublicTXOPNegotiationActivated is true or
dot11ProtectedTXOPNegotiationActivated is true should examine all dot11APCEntry(s) that are present in
the dot11APCTable.
When an AP with dot11PublicHCCATXOPNegotiationActivated true or with
dot11ProtectedHCCATXOPNegotiationActivated true receives a TSPEC request that has the Access Policy
subfield of the TSPEC element equal to “HCCA” or “HEMM,” it shall send an HCCA TXOP advertisement
to each collaboration candidate. These HCCA TXOP advertisements shall have the TXOP Reservation field
set to the TXOP that the AP is attempting to schedule.
An AP with dot11ProtectedTXOPNegotiationActivated true shall send the HCCA TXOP advertisement
using a Protected HCCA TXOP Advertisement frame to each collaboration candidate that indicates support
for protected HCCA TXOP negotiation (as indicated by the Protected TXOP Negotiation field equal to 1 in
the Extended Capabilities element in Beacon frames from the collaboration candidate).
1856
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An AP with dot11PublicTXOPNegotiationActivated true shall send the HCCA TXOP advertisement using
an HCCA TXOP Advertisement frame to each collaboration candidate that indicates support for unprotected
HCCA TXOP negotiation (as indicated by the Unprotected TXOP Negotiation field equal to 1 in the
Extended Capabilities element in Beacon frames from the collaboration candidate) unless the HCCA TXOP
advertisement has already been transmitted to this collaboration candidate using a Protected HCCA TXOP
Advertisement frame.
NOTE When peer APs have both unprotected and protected TXOP negotiation activated, protected TXOP negotiation
is used.
The AP shall not send an ADDTS Response frame to the requesting STA until one of the following
conditions occurs:
a) The AP has received an HCCA TXOP Response frame, with the Status field equal to “SUCCESS,”
from all of the APs to which HCCA TXOP advertisements were sent.
b) At least two Beacon frames have been received from all of the APs to which HCCA TXOP
advertisements were sent.
c) A Beacon frame containing the HCCA TXOP Update Count element is received from all of the APs
to which HCCA TXOP advertisements were sent.
d) A period of three dot11BeaconPeriod TU has elapsed.
If an AP receives another TSPEC request while waiting for one of the above conditions to occur, it shall
delay processing this additional TSPEC request until one of the above conditions occurs.
An AP with dot11PublicTXOPNegotiationActivated false shall discard any received HCCA TXOP
Advertisement frames. An AP with dot11ProtectedTXOPNegotiationActivated true shall discard any
received unprotected HCCA TXOP Advertisement frames from a peer AP with which it has an active
security association.
Upon reception of an unprotected HCCA TXOP Advertisement frame, an AP with
dot11PublicTXOPNegotiationActivated true shall discard all dot11APCEntry(s) from the dot11APCTable
that have dot11APCEntryMACAddress equal to the MAC address of the AP that sent the HCCA TXOP
Advertisement frame and shall prepare a response using the procedures below.
An AP with dot11ProtectedTXOPNegotiationActivated false shall discard any received Protected HCCA
TXOP Advertisement frames.
An AP with dot11ProtectedTXOPNegotiationActivated true that does not have an active security
association with a peer AP that indicates support for protected HCCA TXOP negotiation shall use the AP
PeerKey protocol (as defined in 12.11.2) and authenticated mesh peering exchange (AMPE) (as defined in
13.5) to negotiate security parameters and create a new SMKSA and STKSA to secure the Protected HCCA
TXOP Advertisement frames. The use of AMPE proves possession of the PMK (generated using the
procedures described in 12.11.2) and implicitly the private key that corresponds to the peer’s public key.
Upon reception of a valid Protected HCCA TXOP Advertisement frame, an AP with
dot11ProtectedTXOPNegotiationActivated true shall discard all dot11APCEntry(s) from the
dot11APCTable that have dot11APCEntryMACAddress equal to the MAC address of the AP that sent the
Protected HCCA TXOP Advertisement frame and shall prepare a response using the procedures below.
If the (Protected) HCCA TXOP Advertisement frame has not been discarded due to the procedures above,
the AP shall create a dot11APCEntry in the dot11APCTable for each TXOP reservation in the Active TXOP
Reservations field of the (Protected) HCCA TXOP Advertisement frame.
1857
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the (Protected) HCCA TXOP Advertisement frame has not been discarded due to the procedures above,
the AP shall inspect its HCCA schedule to check whether the TXOP reservations number given in the
Pending TXOP Reservations field of the HCCA TXOP Advertisement frame is in conflict with an existing
accepted HCCA TXOP, allocated by itself. If there is no conflict, the AP shall send an HCCA TXOP
Response frame with the Status field set to “SUCCESS” and create a dot11APCEntry for each TXOP
reservation in the Pending TXOP Reservations field in the HCCA TXOP Advertisement frame.
If the HCCA advertisement was sent using an unprotected Public Action frame, the HCCA TXOP response
shall be sent using an unprotected Public Action frame.
If the HCCA advertisement was sent using a Protected HCCA TXOP Advertisement frame, the HCCA
TXOP response shall be sent using a Protected HCCA TXOP Response frame.
If the AP detects that the TXOP given in the (Protected) HCCA TXOP Advertisement frame is in conflict
with an existing accepted HCCA TXOP and this AP is not itself currently processing an ADDTS request, it
shall send a (Protected) HCCA TXOP Response frame with the Status field set to
“TS_SCHEDULE_CONFLICT,” the Alternate Schedule field set to a period of time that does not conflict
with any currently accepted HCCA TXOPs, and the Avoidance Request field absent. The Duration subfield
of the Alternate Schedule field should be greater than or equal to the Duration subfield of the Schedule field
in the (Protected) HCCA TXOP Advertisement frame. The Duration subfield of the Alternate Schedule field
may be less than the Duration subfield of the Schedule field in the (Protected) HCCA TXOP Advertisement
frame when there is an insufficient period of time that does not conflict with currently accepted HCCA
TXOPs.
If the AP detects that the TXOP given in the (Protected) HCCA TXOP Advertisement frame is in conflict
with an in-progress ADDTS request for an HCCA TXOP for which HCCA TXOP Response frames have
not been received, it shall send a (Protected) HCCA TXOP Response frame with the Status field set to
“TS_SCHEDULE_CONFLICT” and the Alternate Schedule and Avoidance Request fields set according to
the following rules:
— If MIX(MACr) < MIX(MACi), the Alternate Schedule field is set to a value that does not conflict
with any accepted HCCA TXOPs and also does not conflict with the TXOP of the in-progress
ADDTS request. The Avoidance Request field is set to the TXOP of the in-progress ADDTS
request.
— If MIX(MACr) > MIX(MACi), the Alternate Schedule field is set to the value from the TXOP
Reservation field from the HCCA TXOP Advertisement frame. The Avoidance Request field is set
to a time period that does not conflict with any accepted HCCA TXOPs nor the TXOP in the
Alternate Schedule field and has sufficient duration and service interval to meet the requirements of
the in-progress ADDTS request.
where
MACr is the MAC address of the AP that received the HCCA TXOP Advertisement frame
MACi is the MAC address of the AP that sent the HCCA TXOP Advertisement frame
The MIX function takes the 6 octets of a MAC address and computes a new 6 octet value:
MIX(MAC) = MAC[4] || MAC[5] || MAC[0] || MAC[1] || MAC[2] || MAC[3]
For the purpose of the comparisons shown above, the resulting 6 octet value is converted to a positive
integer treating the first octet as the most significant octet of the integer.
1858
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-19 provides a summary of the values used in an HCCA TXOP Response frame.
Table 11-19—Contents of HCCA TXOP Response frame
Alternate Schedule Avoidance Request
Case Status code
field field
No conflict with SUCCESS Not present Not Present
existing or in-progress
schedules
Conflicts with existing TS_SCHEDULE_ Period of time that does not Not Present
schedule; no ADDTS CONFLICT conflict with any currently
request in progress accepted HCCA TXOPs
Conflict with TS_SCHEDULE_ Period of time that does not Schedule of in-progress
in-progress schedules, CONFLICT conflict with any currently ADDTS request
MIX(MACr) < accepted HCCA TXOPs nor
MIX(MACi) the in-progress ADDTS
request
Conflict with TS_SCHEDULE_ Same schedule that was in Period of time that does not
in-progress schedules, CONFLICT the HCCA TXOP conflict with any currently
MIX(MACr) > Advertisement frame accepted HCCA TXOPs nor
MIX(MACi) the period given in the
Alternate Schedule field
The AP shall keep a record of the TXOP proposed in the Alternate Schedule field in a TXOP avoidance
record and should avoid scheduling any new HCCA TXOPs in this proposed period until any of the
following conditions occurs:
— A period of dot11HCCATXOPBeaconTimeout multiplied by dot11BeaconPeriod TUs has elapsed.
— The AP with dot11PublicTXOPNegotiationActivated true receives an unprotected HCCA TXOP
Advertisement frame from the AP to which the unprotected HCCA TXOP Response frame was sent.
— The AP with dot11ProtectedTXOPNegotiationActivated true receives a Protected HCCA TXOP
Advertisement frame from the AP to which the Protected HCCA TXOP Response frame was sent.
If an AP with dot11PublicTXOPNegotiationActivated true receives an unprotected HCCA TXOP Response
frame with the Status field equal to “TS_SCHEDULE_CONFLICT,” the AP should create a new schedule
for the TSPEC request using the suggestion provided in the HCCA TXOP Response frame. If an AP with
dot11ProtectedTXOPNegotiationActivated true receives a Protected HCCA TXOP Response frame with the
Status field equal to “TS_SCHEDULE_CONFLICT,” the AP should create a new schedule for the TSPEC
request using the suggestion provided in the Protected HCCA TXOP Response frame.
If an AP creates a new schedule in response to a (Protected) HCCA TXOP Response frame, it shall send a
new HCCA TXOP advertisement to each collaboration candidate, using the procedures previously defined
in this subclause.
After one or more HCCA TXOP Advertisement frame transmissions that cause the reception of an HCCA
TXOP Response frame with the Status field equal to “TS_SCHEDULE_CONFLICT,” the AP may
terminate the HCCA TXOP advertisement procedure and respond to the ADDTS Request frame with a
status code not equal to SUCCESS (decline the ADDTS Request) or a status code equal to SUCCESS
(accept the ADDTS request regardless of potential HCCA TXOP conflicts).
1859
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.28.4 HCCA AP timing synchronization for HCCA TXOP advertisement
11.28.4.1 General
HCCA APs in OBSSs for which dot11PublicHCCATXOPNegotiationActivated is true or
dot11ProtectedHCCATXOPNegotiationActivated is true synchronize their TSF timing so that the HCCA
TXOP advertisement scheme does not suffer from time differences between the clocks of the overlapping
APs.
In order to use HCCA TXOP advertisement, the AP maintains synchronization with its APs in OBSSs.
HCCA APs that use HCCA TXOP advertisement shall use a DTIM interval with a duration of 2n × 100 TU
where n a non-negative integer less than or equal to 5.
NOTE—The DTIM interval of the form 2n × 100 TU has been chosen to facilitate the verification that HCCA TXOP
reservations do not overlap. The restriction that n be less than or equal to 5 has been chosen so that the range of the
HCCA TXOP start time in the reservation (see 9.4.1.44) is compatible with the maximal DTIM interval length.
11.28.4.2 Timing offset
An HCCA AP with dot11PublicHCCATXOPNegotiationActivated true or
dot11ProtectedHCCATXOPNegotiationActivated true shall update the timing offset value based on time
stamps from the received Beacon frames from HCCA APs that have an entry in the dot11APCTable. The
timing offset value is calculated using Equation (11-7).
Toffset = TT – TR (11-7)
where
Toffset is the timing offset value
TT is the value in the Timestamp field in the received Beacon frame from the overlapping HCCA AP
TR is the Beacon frame reception time measured using the HCCA AP’s TSF timer
The offset value is represented as 2s complement. The unit of the offset value is microseconds. The HCCA
AP shall keep the Toffset value calculated from the latest Beacon frame received from each AP in an OBSS.
11.28.4.3 Clock drift adjustment
When dot11RobustAVStreamingImplemented is true and dot11PublicHCCATXOPNegotiationActivated is
true, the HCCA AP shall examine the reception time of the Beacon frames from overlapping HCCA APs
with which it maintains synchronization and adjust its TSF timer to compensate the relative timing error
among overlapping HCCA APs caused by the clock drift. The HCCA AP adjusts its TSF so that its TSF
counting frequency is aligned to the AP with the lowest TSF counting frequency.
The HCCA AP shall operate the following clock drift compensation procedure:
a) If the HCCA AP does not have a valid Toffset value obtained from the previous Beacon frame
reception from a particular overlapping HCCA AP, it shall not operate the clock drift compensation
for that AP.
b) When the HCCA AP receives a Beacon frame from one of the overlapping HCCA APs with which it
maintains synchronization, the HCCA AP shall calculate the clock drift amount TClockDrift by
comparing the Toffset obtained previously for this overlapping HCCA AP and the Toffset obtained
from the Beacon frame reception. See Equation (11-8).
TClockDrift = Toffset,1 – Toffset,0 (11-8)
1860
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
TClockDrift is the clock drift amount represented as 2s complement, in microseconds
Toffset,1 is the Toffset obtained from the previous reception
Toffset,0 is the Toffset obtained from the current frame reception
c) The HCCA AP shall calculate the TClockDrift value for all overlapping HCCA APs with which it
maintains synchronization and select the largest TClockDrift value. If the largest TClockDrift is greater
than zero, it shall suspend its TSF timer for the duration of the largest TClockDrift. The HCCA AP
shall suspend its TSF timer frequently enough that the delay during a single beacon period does not
exceed 0.08% of its beacon interval.
NOTE—This clock drift compensation procedure is not intended to maintain a strict synchronization. It aims to stop
TBTT drifting away among overlapping HCCA APs to allow some jitter of TSF timer.
11.29 DMG beamformed link and BSS maintenance
11.29.1 Beamformed link maintenance
A pair of DMG STAs that have established a beamformed link can maintain this link. This subclause
describes procedures that allow a pair of DMG STAs to maintain a beamformed link that was established
between them.
A beamformed link is established as a result of the most recent success of the procedures specified in
10.38.2 if the STAs completed the SLS phase or as a result of the most recent success of the procedures
specified in 10.38.6.4 if the STAs completed the BRP phase.
A DMG STA shall negotiate the value of dot11BeamLinkMaintenanceTime using the procedures specified
in 10.38.6.2 or may leave it undefined as specified in 9.5.6.
If the dot11BeamLinkMaintenanceTime has been defined as described in 9.5.6, a DMG STA shall
implement a beam link maintenance timer to control each beamformed link. The STA shall keep one beam
link maintenance timer per beamformed link. After it is set, the beam link maintenance timer shall count
down. The timer shall be stopped when it reaches the value zero. The beam link maintenance timer of a
beamformed link shall be halted during the following periods of time:
— BTI and A-BFT of a beacon interval
— SPs and CBAPs in which the STA does not participate
— When any of the STAs involved in the beamformed link is in doze state
The beam link maintenance timer shall be set to dot11BeamLinkMaintenanceTime when the source DMG
STA and destination DMG STA successfully complete the BRP if the beam refinement phase is performed
(10.36.3) or the source DMG STA and destination DMG STA successfully complete the SLS (10.38.2) if the
beam refinement phase is skipped as defined in 10.36.3.
A DMG AP or PCP shall set the beam link maintenance timer to dot11BeamLinkMaintenanceTime when it
receives a response from the non-AP and non-PCP DMG STA during the ATI or when it receives an SPR
frame as a response to a Poll frame, if these frames are received using the beamformed link established with
the non-AP and non-PCP DMG STA.
The non-AP and non-PCP DMG STA shall set the beam link maintenance timer to the
dot11BeamLinkMaintenanceTime when it receives a request from the DMG AP or PCP during the ATI or
when it receives a Poll or a Grant frame, if these frames are received using the beamformed link established
with the DMG AP or PCP.
1861
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The initiator DMG STA shall set the beam link maintenance timer to the dot11BeamLinkMaintenanceTime
when an immediate response or acknowledgment (Ack, BlockAck, DMG CTS, DMG DTS) has been
received from the recipient DMG STA of the beamformed link.
The recipient DMG STA shall set the beam link maintenance timer to the dot11BeamLinkMaintenanceTime
after the transmission of the immediate response or acknowledgment (Ack, BlockAck, DMG CTS, DMG
DTS) has been completed to the initiator DMG STA of the beamformed link.
To prevent expiration of the beam link maintenance timer when a DMG STA does not have MSDUs to send,
the STA shall transmit QoS Null frames to maintain a beamformed link.
Following the expiration of the beamlink maintenance time (specified by the current value of
dot11BeamLinkMaintenanceTime), the destination DMG STA of the SP shall configure its receive antenna
to a quasi-omni antenna pattern for the remainder of the SP and during any SP following the expiration of
the beamlink maintenance time.
Any time after dot11BeamLinkMaintenanceTime has elapsed, the source DMG STA of the SP may initiate
an ISS to restore the beamformed link with the destination DMG STA of the SP following the rules defined
in 10.38.2. The source DMG STA may initiate the ISS before expiration of
dot11BeamLinkMaintenanceTime.
The responder DMG STA of the beamformed link in the CBAP shall configure its receive antenna to a
quasi-omni antenna pattern following the expiration of dot11BeamLinkMaintenanceTime except when it is
involved in a frame exchange with another STA.
Any time after dot11BeamLinkMaintenanceTime has elapsed, the initiator DMG STA of the beamformed
link in the CBAP may initiate an ISS to restore the beamformed link with the responder STA following the
rules defined in 10.38.2. The initiator STA may initiate the ISS before expiration of
dot11BeamLinkMaintenanceTime.
If a DMG STA detects degradation in the link quality between itself and another STA, the STA can use
beam tracking or beam refinement to improve the link quality. The STA can request the AP or PCP to
schedule an SP to perform BF with the other STA or use a CBAP to perform BF. The STA can use the A-
BFT to perform BF if the other STA is its AP or PCP. A DMG AP or PCP can perform BF with a non-AP
and non-PCP STA during a CBAP or by scheduling an SP between the AP or PCP and the non-AP and non-
PCP STA through an Extended Schedule element transmitted in a DMG Beacon or Announce frame.
If the link quality between a DMG AP or PCP and a non-AP and non-PCP DMG STA degrades, but the STA
can still receive DMG Beacon frames with the Next A-BFT field equal to 0, the STA should improve the
link quality by performing RSS during the A-BFT period as described in 10.38.5.
A DMG STA may use the value of the parameter LAST_RSSI in the RXVECTOR of a received frame to
decide to initiate beamforming with a peer STA if the value of the LAST_RSSI parameter is different from
zero (10.3.2.3.3).
Figure 11-42 illustrates the operation of the beam link maintenance timer for an example involving STA-A
and STA-B. In beacon interval n, STA-A and STA-B successfully perform beamforming and set up the
beam link maintenance timer. In beacon interval n+1, the STAs have two SPs established between them.
The beam link maintenance timer is halted and released according to the rules described above. Once the
timer beam link maintenance timer expires, the STAs redo beamforming.
1862
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
beacon interval n beacon interval n+1
STA-A & STA-B SP (STA-A,
BTI A-BFT SP (STA-A, STA-B)
beamforming STA-B)
Beam Link Last successful Ack/BA,
Maintenance Timer beamformed link broken
Ack/BA transmitted and
0 received
Time
Setup and halt Beam Link Release Beam Link
Maintenance Timer Maintenance Timer
Setup and Release Beam Link Halt Beam Link
Maintenance Timer Maintenance Timer
Release Beam Link
Maintenance Timer
Beam Link Maintenance Timer
expires. Re-beamforming starts.
Figure 11-42—Example of beamformed link maintenance
11.29.2 PCP Handover
11.29.2.1 General
A STA is PCP handover capable if the PCP Handover field in the STA’s DMG Capabilities element
(9.4.2.128) is 1. The STA is PCP handover incapable otherwise.
The PCP handover process allows the information pertinent to the operation of the PBSS to be distributed to
suitable PCP handover capable STA(s) and for a PCP handover capable STA to take over the PCP
responsibilities from the PCP explicitly or implicitly.
The information pertinent to the operation of a PBSS includes STA information and pseudo-static
scheduling information.
The STA information comprises the STA’s AID, MAC address, and DMG Capabilities element. The PCP
may relay the information to all STAs in the PBSS by using the Information Response frame.
The pseudo-static scheduling information comprises pseudo-static SP and CBAP allocations carried in the
Extended Schedule element (9.4.2.132).
A PCP handover capable STA supports two types of PCP Handover, explicit and implicit. In explicit PCP
handover, the PCP explicitly selects and schedules the transfer of PCP responsibilities to another PCP
handover capable STA as described in 11.29.2.2. In implicit PCP handover the PCP distributes the Next
PCP List element (9.4.2.140) in its DMG Beacon or Announce frames and maintains the content of the
NextPCP List element to facilitate the implicit handover process described in 11.29.2.3. The PCP may
determine the priority of next PCPs and update the next PCP list based on information contained within a
STA’s DMG Capabilities element.
1863
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If there is at least one PCP handover capable STA in the PBSS, the NextPCP List element contains an
ordered list of one or more PCP handover capable STAs that can take over the role of the PCP during
implicit handover. The ordering of STAs in the NextPCP List is specified in decreasing priority order and
the criteria for updating the NextPCP List are implementation specific. The PCP shall increment the Token
field of the NextPCP List by 1 every time the list is changed. If there are no PCP handover capable STAs in
the PBSS, the length of the NextPCP List element is 0, and implicit PCP handover cannot be performed.
When a PCP handover capable STA takes over the PCP responsibilities of a PBSS, the pseudo-static
scheduling information shall remain unchanged. Any outstanding request for resource allocation is lost and
STAs that have outstanding requests for allocation may re-request the resource allocation.
In explicit PCP handover, the PCP shall use the value of the PCP factor when selecting the candidate PCP
(see 11.1.4.3.6).
Following a PCP handover, a non-PCP STA shall attempt to transmit a frame to the new PCP within
dot11MaxLostBeacons beacon intervals. If the new PCP does not receive at least one frame from an
associated non-PCP STA for dot11MaxLostBeacons beacon intervals following a PCP handover, it should
disassociate the STA from the PBSS.
11.29.2.2 Explicit handover procedure
The PCP may transmit a Handover Request frame to a non-PCP STA that is handover capable. Upon
receiving a Handover Request, a non-PCP STA becomes the candidate PCP. If the handover request is
accepted, the candidate PCP shall transmit a Handover Response frame to the PCP with the Handover Result
field set to 0. If the handover request is rejected, the candidate PCP shall transmit a Handover Response
frame to the PCP with the Handover Result field set to 1, 2, or 3 and cease to be the candidate PCP.
A non-PCP STA that is handover capable may transmit a Handover Request frame to the PCP of the PBSS if
the PCP is handover capable. Upon transmission of the Handover Request frame, the non-PCP STA
becomes the candidate PCP. If the handover request is accepted, the PCP shall transmit a Handover
Response frame to the candidate PCP with the Handover Result field set to 0. If the handover request is
rejected, the PCP shall transmit a Handover Response frame to the candidate PCP with the Handover Result
field set to 1, 2, or 3, and the candidate PCP shall cease to be a candidate PCP.
Following the transmission or reception of a successful Handover Response frame, a candidate PCP should
request STA information and pseudo-static scheduling information from the PCP using an Information
Request frame within the next dot11NbrOfChangeBeacons beacon intervals. The candidate PCP should also
request SPs to perform beamforming and, if appropriate, establish a security association with other
associated STAs prior to the completion of PCP handover.
Following the reception or transmission of a Handover Response frame, the PCP shall transmit a PCP
Handover element within every DMG Beacon or Announce frame for each of the next
dot11NbrOfChangeBeacons beacon intervals with the Old BSSID field set to the BSSID of the PBSS, the
New PCP Address field set to the MAC address of the candidate PCP, and the Remaining BIs field set to the
number of beacon intervals remaining until the candidate PCP takes over the role of PCP for the PBSS. The
initial value of the Remaining BIs field shall be equal to the Remaining BI field value last transmitted by the
PCP in a Handover Request frame to the candidate PCP or equal to the Remaining BI field value last
received by the PCP in a Handover Request frame from the candidate PCP, whichever is later. A non-PCP
STA receiving a DMG Beacon or Announce frame containing the PCP Handover element shall set the
STA’s local countdown counter to the value of the Remaining BIs field contained in the PCP Handover
element. The STA shall then decrease the local countdown counter by one at each TBTT, and shall use the
candidate PCP’s address contained in the New PCP Address field within the PCP Handover element as the
new beacon filter address once the STA’s local countdown reaches zero. When the countdown timer equals
zero, the candidate PCP shall assume the role of PCP.
1864
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.29.2.3 Implicit handover procedure
Upon receiving the NextPCP List element, a PCP handover capable STA that finds its AID as the AID entry
i in the NextPCP List element received from the PCP becomes the implicit candidate PCP i. Upon detecting
a Token value contained in the NextPCP List element that is different from the value of the last Token
received from the PCP, each implicit candidate PCP should request STA information and pseudo-static
scheduling information from the PCP by transmitting an Information Request frame addressed to the PCP
(11.30.1).
The implicit handover process is triggered at the implicit candidate PCP i when the implicit candidate PCP i
fails to receive a DMG Beacon or Announce frames from the PCP for (i ×
dot11ImplicitHandoverLostBeacons) beacon intervals. When triggered, the implicit candidate PCP i shall
send at least one DMG Beacon frame during each of the next dot11MaxLostBeacons BTIs if the following
conditions are met:
— No DMG Beacon or Announce frames are received from the PCP.
— No DMG Beacon frame carrying a PCP Handover element with the value of the Old BSSID field
equal to the BSSID of the PBSS is received from an implicit candidate PCP with a smaller index on
the NextPCP List.
Each DMG Beacon frame sent by the implicit candidate PCP i shall contain a PCP Handover element with
the Old BSSID field set to the BSSID of the PBSS from which control is being taken, i.e., the previous
PBSS, the New PCP Address field set to its MAC address, and the Remaining BIs field initially set to
dot11MaxLostBeacons and decremented by 1 at each TBTT. A member non-PCP STA of the PBSS, after
failing to receive a DMG Beacon or Announce frame for dot11MaxLostBeacons beacon intervals, should
associate with the new PCP sending a DMG Beacon frame containing the PCP Handover element with Old
BSSID field equal to the BSSID of the previous PBSS and the smallest Remaining BIs field value. The
implicit candidate PCP that successfully transmits a DMG Beacon frame with the Remaining BIs field
within the PCP Handover element equal to 0 completes the implicit handover by scheduling, if appropriate,
pseudo-static SPs between its member STAs following the pseudo-static scheduling information it obtained
from the previous PBSS.
To avoid disruptions to pseudo-static SPs due to implicit handover, the value of
dot11ImplicitHandoverLostBeacons should be lower than dot11MaxLostBeacons.
11.30 DMG BSS peer and service discovery
11.30.1 Information Request and Response
A STA may request information about either a single STA in the BSS or about all of the STAs in the BSS by
sending an Information Request frame (9.6.20.4). If the STA is requesting information about only a single
STA in the BSS, it shall set the Subject Address field in the Information Request frame to the MAC address
of that STA. If the STA is requesting information about all of the STAs in the Infrastructure BSS and PBSS,
it shall set the Subject Address field in the Information Request frame to the broadcast address and shall
transmit the Information Request frame to the AP and PCP.
A STA may transmit an Information Request frame with the Length field of the Request element set to 0 and
with no Extended Request element present to another STA in the BSS to determine if the destination DMG
STA is still present in the PBSS and is within range of the sending STA.
A STA may transmit an Information Request frame including its STA Capability element and other
elements. A non-PCP and non-AP STA shall not include in the Information Request frame the capability
information corresponding to another STA.
1865
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The STA may transmit an Information Response frame (9.6.20.4) either unsolicited or as a response to an
Information Request frame. If a STA is providing information about a single STA in the BSS, it shall set the
Subject Address field in the Information Response frame to the MAC address of that STA. If a STA is
providing information about all of the STAs in the PBSS, it shall set the Subject Address field in the
Information Response frame to the broadcast address.
A STA processes a received Information Request frame as follows:
— Each element that is listed in a Request element or Extended Request element and that is supported
by the STA shall be included in the Information Response frame. An element that is listed in a
Request element or Extended Request element and that is not supported by the STA shall not be
included.
— If dot11RadioMeasurementActivated is true and the RCPI element was requested, an RCPI element
containing the RCPI of the Probe Request frame shall be included. If no measurement result is
available, the RCPI value shall be set to indicate “Measurement not available” (see Table 9-154).
— If dot11RadioMeasurementActivated is true and the RSNI element was requested, an RSNI element
containing the RSNI of the Probe Request frame shall be included. If no measurement result is
available, the RSNI value shall be set to indicate that a measurement is not available (see 9.4.2.41).
A STA shall send an Information Response frame with no requested or provided elements in response to a
received Information Request frame that solicits information about a single target STA, as identified by the
Subject Address field within the Information Request frame, if
— The target STA is not a member of the PBSS and the STA sending the Information Response frame
is the PCP of the PBSS, or AP of the Infrastructure BSS and PBSS, or
— The STA sending the Information Response frame is a non-PCP and non-AP STA and is not the
target STA.
In all other cases, the STA shall send the Information Response frame with the information requested by the
requesting STA.
11.30.2 Peer Service Discovery
An AP or PCP may provide different types of information to a non-AP and non-PCP STA upon request. To
query available services in a BSS, a non-AP and non-PCP STA shall send either an Information Request
frame or a Probe Request frame to the AP or PCP (11.30.1). The Information Request and Information
Response frames are robust Management frames, while the Probe Request and Probe Response frames are
not.
Upon receiving the Information Request frame, the AP or PCP shall respond with an Information Response
frame only if all of the following three criteria are true:
a) The SSID in the Information Request frame is the wildcard SSID or the specific SSID of the AP or
PCP.
b) The BSSID field in the Information Request frame is the wildcard BSSID or the BSSID of the AP or
PCP.
c) The DA field in the Information Request frame is the MAC address of the AP or PCP.
The AP or PCP transmits the Information Response frame to the address of the non-AP and non-PCP STA
that generated the Information Request.
The Information Response frame may include vendor-specific elements.
1866
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.31 Changing DMG BSS parameters
11.31.1 General
This subclause describes the methods used by the AP or PCP to change certain key characteristics of the
BSS. It also describes a method for a non-AP and non-PCP STA to make a recommendation on those
characteristics to the AP or PCP.
The AP or PCP delivers the DMG BSS Parameter Change element to STAs holding pseudo-static SPs and
STAs in power save mode before a DMG BSS parameter change.
The AP or PCP shall initiate a DMG BSS parameter change by including a DMG BSS Parameter Change
element (9.4.2.127) in its DMG Beacon or Announce frames. The AP or PCP places the DMG BSS
Parameter Change element in every DMG Beacon or Announce frame after the DMG BSS Parameter
Change element is first included in the frame, stopping in the DMG Beacon or Announce frame immediately
after the DMG BSS parameter change takes effect.
11.31.2 Moving the TBTT
The AP or PCP may move the TBTT and hence move the entire beacon interval. Moving the beacon interval
means that except for the beacon interval in which the change takes effect, the beacon interval duration is
unchanged while the position of the TBTT is moved.
The TBTT shall not be moved by an amount that is larger than the value in the Beacon Interval field present
in DMG Beacon and Announce frames in which the DMG BSS Parameter Change element is sent.
To move the TBTT to an intended new TBTT, the AP or PCP shall insert the DMG BSS Parameter Change
element in DMG Beacon frames and/or Announce frames with the Move field set to 1 (9.4.2.127). The
DMG Beacon frames and/or the Announce frames containing the DMG BSS Parameter Change element
shall be sent at each TBTT dot11NbrOfChangeBeacons times before the TBTT is changed as indicated in
the TBTT offset field.
At each transmission of the DMG BSS Parameter Change element, the TBTT Offset field shall be set to a
value equal to the lower order 4 octets of the intended new TBTT.
The value of dot11NbrOfChangeBeacons shall be greater than dot11MaxLostBeacons.
NOTE—As defined in 11.1.2.1, the PCP transmits at least one DMG Beacon frame to each associated STA within a time
interval that is not longer than dot11BeaconPeriod × dot11MaxLostBeacons TUs.
Announce frames shall be used to deliver the DMG BSS Parameter Change element to all STAs
participating in pseudo-static SPs.
The value of the Beacon Interval field of DMG Beacon frames and the Announce frames sent at the
dot11NbrOfChangeBeacons+1 TBTT shall be set to the difference of the intended new TBTT and the TBTT
where the DMG Beacon or Announce frames were sent.
STAs associated with an AP or PCP that moves the TBTT shall not transmit during the beacon interval that
precedes a new TBTT if the transmission time ends at the TBTT or later, even if the SP or the CBAP were
scheduled in the beacon interval.
At the intended new TBTT that is dot11NbrOfChangeBeacons+2 TBTTs after the DMG BSS Parameter
Change element is first transmitted, the TSF timer is reset to 0 as defined in 11.1.3.3.
1867
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An AP or PCP member of an AP or PCP cluster that wishes to move its TBTT shall set the TBTT Offset
field to an empty Beacon SP allocated by its S-AP or S-PCP as defined in 10.37.
Figure 11-43 illustrates the process in moving the TBTT position.
DMG BSS parameter change
Beacon interval duration
First announcement of
TBTT position change
New TBTT
Figure 11-43—Moving the TBTT position
11.31.3 Changing beacon interval duration
The AP or PCP may change the duration of its beacon interval during the BSS operation.
To change its beacon interval, the AP or PCP shall insert the DMG BSS Parameter Change element into
DMG Beacon frames and/or Announce frames with the Size field set to 1 and the BI Duration field set to the
duration of the beacon interval following this DMG BSS parameter change. The TBTT Offset field shall be
set to the lower order 4 octets of the TBTT at dot11NbrOfChangeBeacons+1 TBTT position when this
DMG BSS parameter change takes effect.
The DMG Beacon frames and/or the Announce frames shall be sent at each TBTT
dot11NbrOfChangeBeacons times before the beacon interval is changed as indicated in the BI Duration field
of the DMG BSS Parameter Change element.
At each transmission of the DMG BSS Parameter Change element the TBTT Offset field shall be set to a
value equal to the lower order 4 octets of the intended TBTT.
The value of dot11NbrOfChangeBeacons shall be greater than dot11MaxLostBeacons.
Announce frames shall be used to deliver the DMG BSS Parameter Change element to all STAs
participating in pseudo-static SPs.
The AP or PCP that shortens the beacon interval shall not schedule SP and CBAP allocations that use more
time than allowed in the beacon interval indicated in the BI Duration field of the DMG BSS Parameter
Change element.
The value of the beacon interval shall be set to the BI Duration field of the DMG BSS Parameter Change
element at the dot11NbrOfChangeBeacons+1 TBTT. At this TBTT, the TSF timer is reset to 0 as defined in
11.1.3.3.
If the AP or PCP sets the Move and the Size fields to 1 in the same DMG BSS Parameter Change element, it
shall set the TBTT Offset field and proceed as defined in 11.31.2. The value of the beacon interval shall be
set to the BI Duration field of the DMG BSS Parameter Change element at the new TBTT as defined in
11.31.2.
Figure 11-44 illustrates the process in changing the beacon interval duration.
1868
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Old beacon New beacon
interval duration interval duration
First announcement of TBTT
beacon interval duration
change
Figure 11-44—Changing beacon interval duration
11.31.4 Maintaining synchronization in an AP or PCP cluster
A S-AP or S-PCP shall update the Clustering Control field transmitted in the DMG Beacon frame if the
DMG BSS parameter change modifies the allocation of the Beacon SPs (10.37). If the Clustering Control
field is modified as a result of a DMG BSS parameter change, the S-AP or S-PCP shall transmit the updated
Clustering Control field in every DMG Beacon frame in which the DMG BSS Parameter Change element is
transmitted.
An AP or PCP member of an AP or PCP cluster receiving a S-AP or S-PCP DMG Beacon frame with a
DMG BSS Parameter Change element indicating a change in the beacon interval duration or TBTT time
shall immediately insert the appropriate DMG BSS Parameter Change element into its DMG Beacons if the
S-AP or S-PCP’s DMG BSS parameter change causes a modification in the allocation of the Beacon SPs.
If an AP or PCP is required to change the beacon interval or/and TBTT to participate in an AP or PCP
cluster or to change the beacon interval or/and TBTT as a result of its S-AP’s or S-PCP’s parameters change
(see 10.37), it shall follow the procedures in 11.31.2 and 11.31.3.
11.31.5 Recommending DMG BSS parameters to the AP or PCP
A non-AP and non-PCP STA may make a recommendation for DMG BSS parameters to the AP or PCP by
including a DMG BSS Parameter Change element in an Information Request or Information Response
frame sent to the AP or PCP.
A non-AP and non-PCP STA may recommend a shift in TBTT by setting the Move subfield in the Change
Type Bitmap field of the DMG BSS Parameter Change element to 1 and setting the TBTT Offset field to the
lower order 4 octets of the non-AP and non-PCP STA’s TSF timer at the recommended first changed TBTT.
The non-AP and non-PCP should select a value for the TBTT Offset field that gives the AP or PCP enough
time to exercise the change. Similarly, a non-AP and non-PCP STA may recommend a beacon interval
duration to the AP or PCP by setting the Size subfield in the Change Type Bitmap field of the DMG BSS
Parameter Change element to 1 and setting the BI Duration field to the recommended beacon interval
duration in TUs.
An AP or PCP that receives an Information Request frame or an unsolicited Information Response frame
from a non-AP and non-PCP STA containing a DMG BSS Parameter Change element may use the
information within the element to change the DMG BSS parameters. When receiving an Information
Request frame that includes the DMG BSS Parameter Change element, AP or PCP responds with an
Information Response frame as specified in 11.30.1. If the AP or PCP changes the BSS parameters in the
transmitted Information Response frame, the AP or PCP shall include a DMG BSS Parameter Change
element reflecting the BSS parameter changes and shall use the procedure defined in 11.31.2 and 11.31.3, as
appropriate, to change the BSS parameters. If the AP or PCP decides not to change the BSS parameters, it
shall not include a DMG BSS Parameter Change element in the transmitted Information Response frame.
1869
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.32 Spatial sharing and interference mitigation for DMG STAs
11.32.1 General
This subclause describes mechanisms to enable spatial sharing and interference mitigation within a PBSS/
infrastructure BSS and in a uncoordinated OBSS environment.
Spatial sharing mechanisms allow SPs belonging to different STAs in the same spatial vicinity to be
scheduled concurrently over the same channel, and for interference mitigation. Alternatively, the AP or PCP
can use CBAPs to mitigate interference.
The SPSH and Interference Mitigation field in the DMG Capabilities element indicates whether a STA
supports spatial sharing.
A STA that supports spatial sharing, as indicated in the SPSH and Interference Mitigation field equal to 1 in
the STA’s DMG Capabilities element, shall support the directional channel quality measurements described
in 9.4.2.21.16 and 9.4.2.22.15.
11.32.2 Spatial sharing and interference assessment
The AP or PCP should request STAs to perform and report spectrum and radio resource measurements
described in 11.11 to assess the possibility to perform spatial sharing and for interference mitigation.
The AP or PCP should use the directional channel quality described in 9.4.2.21.16 and 9.4.2.22.15 to assess
the possibility for spatial sharing of SPs.
An SP to be assessed for spatial sharing with other scheduled (existing) SPs or considered to be reallocated
in the beacon interval is hereby termed as a candidate SP. There might be multiple candidate and existing
SPs at one time, and an SP may simultaneously assume the role of candidate and existing SP depending
upon the context it is used for spatial sharing and interference assessment.
STAs that participate in an SP and that support spatial sharing should perform beamforming training with
each other before engaging in any other communication or performing any measurements described in this
subclause.
The AP or PCP should request source DMG STA and destination DMG STA involved in a candidate SP to
perform measurements for the purpose of spatial sharing with an existing SP only after the STAs have
beamforming trained with each other. The AP or PCP can infer that the STAs in a candidate SP have a
beamformed link with each other if the Beamforming Training field within the DMG TSPEC used to set up
the candidate SP was set to 1 and at least one beacon interval has elapsed since the candidate SP was first
scheduled.
If the AP or PCP transmits a Directional Channel Quality request to a STA involved in a candidate SP to
assess the possibility for spatial sharing with another existing SP, it shall set the Target STA to the
corresponding peer STA’s MAC address involved in the candidate SP and shall set the Measurement
Method field to indicate ANIPI.
If the candidate SP has already been allocated channel time, the AP or PCP should additionally transmit a
Directional Channel Quality request to the STAs involved in the existing SP to assess the possibility for
spatial sharing with the candidate SP. In the Directional Channel Quality request, the AP or PCP shall set the
Target STA to the corresponding peer STA involved in the existing SP and shall set the Measurement
Method field to indicate ANIPI.
1870
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—When the AP or PCP transmits a Directional Channel Quality request to a STA of an existing SP, it intends to
assess the channel quality during transmission by STAs belonging to the candidate SP. Similarly, when the AP or PCP
transmits a Directional Channel Quality request to a STA of a candidate SP, it intends to assess the channel quality
during transmission by STAs belonging to the existing SP.
If a recipient STA that receives a Directional Channel Quality request frame is already beamformed trained
with the target STA specified by the AID field within the frame, then the recipient STA shall carry out the
measurement employing the same receive antenna configuration as is used by the recipient STA when
receiving frames from the target STA. If the AID field is set to the broadcast AID or an unknown AID, then
the recipient STA shall perform the measurements using a quasi-omni antenna pattern.
Figure 11-45 illustrates an example of spatial sharing assessment between two SPs. In this example, SP1 is
the existing SP and SP2 is the candidate SP. The AP or PCP transmits a Directional Channel Quality request
to STAs C and D to measure over SP1’s channel allocation, and transmits a Directional Channel Quality
request to STAs A and B to measure over SP2’s channel allocation. The relation of the Measurement Start
Time and Measurement Duration fields in the Directional Channel Quality request message is shown in
Figure 11-45, while the field Number of Time Blocks is the ratio (Measurement Duration/Measurement
Unit).
STAs C and D measure STAs A and B measure
during the existing during the candidate
reservation (SP1) reservation (SP2)
STA STA STA STA
C D A B
Measurement Duration Measurement Duration
SP1 (Existing): SP2 (Candidate):
BTI ATI
STA A <-> STA B STA C <-> STA D
Time
Measurement Measurement
unit unit
Measurement Measurement
Start Time Start Time
Figure 11-45—Example of spatial sharing assessment
If a non-AP and non-PCP STA receives a Directional Channel Quality request from its AP or PCP, it should
perform the measurements as indicated in the request and shall report back to the AP or PCP using the
Directional Channel Quality report. The report shall be formatted and transmitted as per specified in the
Directional Channel Quality request. The non-AP and non-PCP STA shall set the Report Mode field
(9.4.2.22) in the report frame to indicate whether it performed the measurement as requested by the AP or
PCP.
11.32.3 Achieving spatial sharing and interference mitigation
An AP or PCP can estimate the channel quality across STAs participating in the BSS and implement spatial
sharing and interference mitigation based on the results of the measurements performed by the STAs
associated with the AP or PCP.
An AP or PCP should schedule a candidate SP that overlaps with an existing SP in its beacon interval only
after it receives a Directional Channel Quality report from the STAs involved in the candidate SP.
1871
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If a candidate SP is already scheduled in the beacon interval, the AP or PCP should schedule this candidate
SP time-overlapping with an existing SP in its beacon interval only after it receives a Directional Channel
Quality report from the STAs involved in the existing SP.
The AP or PCP should schedule a candidate SP during a period of time in the beacon interval where the
PBSS/infrastructure BSS performance is expected to be maximized. The determination of performance
maximization should be based on measurement reports received by the AP or PCP, but is implementation
dependent and beyond the scope of this standard.
The decision process at the AP or PCP to perform spatial sharing of a candidate and an existing SP is
implementation dependent and beyond the scope of this standard.
The candidate SP is referred to as a time-overlapped SP following the allocation by the AP or PCP of a
candidate SP overlapping in time with an existing SP.
Figure 11-46 illustrates an example of the resulting SP schedule in the beacon interval for the spatial sharing
between the two SPs shown in Figure 11-45.
SP1:
BTI ATI
STA A STA B
SP2: Time
STA C STA D
Figure 11-46—Example of spatial sharing between SP1 and SP2
The AP or PCP should periodically transmit a Directional Channel Quality request to each spatial sharing
capable STA involved in a time-overlapped and existing SP scheduled under spatial sharing. In the
Directional Channel Quality request that the AP or PCP transmits to each STA, the AP or PCP shall set the
Target STA to the peer STA involved in the same SP and shall set the Measurement Method field to indicate
RSNI.
If a spatial sharing capable non-AP and non-PCP STA receives a Directional Channel Quality request from
its AP or PCP, it should perform the measurements as indicated in the request and shall report the results
back to the AP or PCP using the Directional Channel Quality report. The report shall be formatted and
transmitted as per specified in the corresponding Directional Channel Quality request.
The AP or PCP should stop the spatial sharing of two or more SPs if it determines that the link quality of any
of the links involved in the spatial sharing has dropped below acceptable levels. This determination should
be based on Directional Channel Quality reports received by the AP or PCP, but is implementation
dependent and beyond the scope of this standard.
The STA may include the Traffic Scheduling Constraint Set field with the ADDTS Request frame sent to the
AP or PCP for the purpose of interference mitigation. The AP or PCP should consider the information in the
Traffic Scheduling Constraint Set field specified by a STA in its SP schedule.
Specific algorithms to realize spatial sharing and interference mitigation among SPs between different STAs
is implementation dependent and beyond the scope of this standard.
1872
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.32.4 PBSS and infrastructure BSS stability in OBSS scenarios
Except when performing FST (11.33), the AP or PCP limits the frequency with which it changes the
operating PBSS/infrastructure BSS channel to alleviate the instability and ripple effect that might result
from frequent channel changes in OBSS scenarios. Upon a channel switch, the AP or PCP of a PBSS/
infrastructure BSS shall select a random number, N, uniformly distributed between [0, SwitchInterval-1]
and shall not attempt a new channel switch until N beacon intervals have elapsed since the preceding
channel switch. The initial value of SwitchInterval is aMinSwitchInterval and it is doubled upon every new
channel switch up to a maximum value of aMaxSwitchInterval. The AP or PCP resets SwitchInterval to
aMinSwitchInterval if it remains on the same operating channel for a minimum of aMaxSwitchInterval
consecutive beacon intervals.
NOTE—The AP or PCP can keep the SP schedule stable across beacon intervals and minimize schedule changes. This is
to allow for STAs to associate with the PBSS/infrastructure BSS or add or modify their SP reservations. Stability in the
allocation schedule in a beacon interval allows a PBSS/infrastructure BSS to assess the interference pattern produced by
OBSSs and adapt to the environment by scheduling SPs over periods of time in the beacon interval when less
interference is expected.
11.33 Multi-band operation
11.33.1 General
A device is multi-band capable if the value of dot11MultibandImplemented is true. A multi-band capable
device is said to be a member of a BSS when one or more of the STAs in the device is a member of the BSS.
A STA that is part of a multi-band capable device advertises the capability by including the Multi-band
element in Beacon, DMG Beacon, (Re)Association Request, (Re)Association Response, Information
Request, Information Response, Probe Request, Probe Response, Announce, FST Setup Request, FST Setup
Response, TDLS Discovery Request, TDLS Discovery Response, TDLS Setup Request, and TDLS Setup
Response frames.
Except for the FST Setup Request and FST Setup Response frames, which shall not include more than one
Multi-band element, a STA may include more than one Multi-band element in any one of these frames if it is
part of a device that supports more than two bands or channels. If an AP or PCP includes one or more Multi-
band elements within a (Re)Association Response frame with Status Code equal to
DENIED_WITH_SUGGESTED_BAND_AND_CHANNEL or a Probe Response frame, the order in which
these elements appear in the frame indicate the order, in terms of frequency band and channel number, that
the device that includes the STA addressed by the frame should attempt join the BSS following the rules
applicable to the respective frequency band and channel (see 11.1). For each Multi-band element contained
in the frame starting from the first one and proceeding in increasing order, the STA should attempt to join
the BSS using the BSSID indicated by the BSSID field, frequency band indicated by the Band ID field and
channel number indicated by the Channel Number field provided the Beacon Interval and the Channel
Number fields in the Multi-band element are both nonzero.
NOTE—The first Multi-band element in the frame can refer to the current operating frequency band and channel.
A multi-band capable device shall set the Band ID and Operating Class fields within a Multi-band element
to specify a frequency band it supports. If the multi-band capable device is or intends to operate in the band
indicated within the Multi-band element, it shall set the Channel Number field to indicate the channel of
operation within that band. If the multi-band capable device is a member of a BSS both on the channel
indicated in the Channel Number field within the Multi-band element and also in the channel on which this
element is transmitted, then the multi-band capable device shall set the TSF Offset field within a Multi-band
element to the difference between the TSF of the BSS of which the STA is member on the channel indicated
in the Channel Number field of this element and the TSF of the BSS corresponding to the BSSID indicated
in the Address 3 field of the MPDU in which this element is transmitted. In all other cases, the TSF Offset
field shall be set to 0.
1873
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The FST session transition is managed by the FST session setup protocol. A multi-band capable device
participates as an initiator or as a responder in the FST session setup. Depending on the STA’s behavior
during the FST session setup, the FST session can be operational in one band, or may be transferred to
another band or channel in the same band, or can be operational in multiple bands and/or channels
simultaneously and in this case MSDUs can be transmitted in different bands and/or channels any time an
MSDU arrives at the MAC SAP. If a multi-band capable device is operational in more than one band/
channel simultaneously, the STA may use the FST session setup protocol to change the operation to a single
channel.
An FST session between an initiator and a responder is identified by an FSTS ID. The value of the FSTS ID
is allocated by the initiator of an FST session and shall remain unchanged whether the FST session is
operational in one band or more than one band simultaneously. The value of the FSTS ID shall be unique for
an initiator and responder pair, and there shall be no more than one FST session between an initiator and
responder pair. An initiator or responder may change the FSTS ID of its existing FST session by tearing
down the existing FST session (11.33.3) and setting up a new one with a different FSTS ID value.
In each band/channel, a multi-band capable device may use the same or different MAC addresses. When the
STA MAC Address Present field is equal to 1 in a Multi-band element, the STA MAC Address field in the
Multi-band element specifies the MAC address that the STA uses in the band and channel that are indicated
in the Multi-band element. If the STA MAC Address Present field is 0, the MAC address that the STA uses
in the frequency band and channel that are indicated in the Multi-band element is the same as the address the
STA uses in the current operating band and channel.
The FST session addressing mode is transparent if both initiator and responder of the FST session use the
same MAC address in the frequency bands/channels involved in the FST. The FST session addressing mode
is nontransparent if either the initiator or responder use different MAC addresses in the different frequency
bands/channels involved in the FST session. When transparent FST is used, the STA shall present a single
MAC SAP to higher layers for all frequency bands/channels in which it uses that MAC address.
An FST is allowed if the FST Setup Request and FST Setup Response frames are permitted to be transmitted
as indicated in 11.3.3.
A multi-band capable device should deliver all fragments, if any, of an MSDU of an FST session before it
transfers the FST session.
A multi-band capable device shall include, in any transmitted FST Setup Request frame and in any
transmitted FST Setup Response frame, the Capabilities element, the Operation element, the EDCA
Parameter Set element, Supported Rates and BSS Membership Selectors element, Extended Supported
Rates and BSS Membership Selectors element, and Supported Channels element that are applicable to the
band and channel number indicated within its most recently transmitted Multi-band element that was
transmitted on the same band and channel number on which it is transmitting the FST Setup Request or FST
Setup Response frames. If a Multi-band element is present in the transmitted FST Setup Request or FST
Setup Response frames, the Multi-band element is considered as the most recently transmitted Multi-band
element.
If a Session Transition element and a Multi-band element are present in the same frame and the values of the
Operating Class and Channel Number fields within the Multi-band element are both nonzero, the value of
the Band ID field related to the new band within the Session Transition element shall be the same as the
Band ID field within the Multi-band element.
1874
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.33.2 FST setup protocol
11.33.2.1 General
The FST setup protocol comprises four states and rules for how to move from one state to the next. The
states are Initial, Setup Completed, Transition Done, and Transition Confirmed. In the Initial state, the FST
session is operational in one or both bands/channels. In the Setup Completed state, both initiator and
responder are ready to change their currently operating band(s)/channel(s). An FST session can be fully or
partially transferred to another band/channel. The Transition Done state enables both initiator and responder
to operate in the other band/channel if the value of the LLT was zero. Both initiator and responder have to
successfully communicate in the new band/channel to reach the Transition Confirmed state. The state
transition diagram of the FST setup protocol is shown in Figure 11-48.
Figure 11-47 depicts the procedure of the FST setup protocol that drives the state machine shown in
Figure 11-48. The figure is an example of only the basic procedure and is not meant to be exhaustive of all
possible uses of the protocol. In the figure, MLME 1 and MLME 2 represent any two MLMEs of a multi-
band capable device according to the reference model described in 4.9.4. The FST Setup Request and FST
Setup Response frame exchange is repeated as necessary until both the FST initiator and FST responder
successfully move to the Setup Completed state, as described below. Figure 11-47 illustrates this behavior.
FST initiator STA FST responder STA
SME MLME 1 MLME 2 MLME 2 MLME 1 SME
loop <1,
inf> MLME-FST- FST Setup MLME-FST-
SETUP.request Request frame SETUP.indication
Process FST Setup
Request action
MLME-FST- FST Setup MLME-FST-
SETUP.confirm Response frame SETUP.response
Process FST Setup
Response action
Decision to perform Decision to perform
FST FST
MLME-FST- MLME-FST-
INCOMING.request INCOMING.request
MLME- FST Ack MLME-
FST-ACK.request Request frame FST-ACK.indication
Process FST Ack
Request action
MLME- FST Ack MLME-
FST-ACK.confirm Response frame FST-ACK.response
Figure 11-47—Procedure of the FST setup protocol
1875
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
To establish an FST session in the Initial state and transfer it to the Setup Completed state of the FST setup
protocol (Figure 11-48), an initiator and responder shall exchange FST Setup Request and FST Setup
Response frames. An FST session exists in Setup Completed state, Transition Done state, or Transition
Confirmed state. In the Initial and in the Setup Completed states, the old band/channel represents the
frequency band/channel from which the FST session is to be transferred, and the new band/channel
represents the frequency band/channel to which the FST session is to be transferred. In the Transition Done
state, the new band/channel represents the frequency band/channel on which the FST Ack Request and FST
Ack Response frames, if any, are transmitted, and the old band/channel represents the frequency band/
channel from which the FST session is being transferred.
Status 0
or
Operation (New Band)=0
Initial state Transition Confirmed state
New Band/Channel becomes
Communicating in Old Band/ Old Band/Channel Full connectivity in New Band/
Channel Channel
Timeout, rejection or FST Ack Request, FST Ack Response,
FST Setup Request,
FST Tear Down; or successful frame exchange
FST Setup Response
initiated by any STA (excluding FST Tear Down)
Setup Completed state Transition Done state
LLT=0 in FST Setup Request
Communicating in Old Band/ or Communicating in New Band/
Channel LLT transitions from one to zero Channel
LLT>0
Figure 11-48—States of the FST setup protocol
The responder shall set the Status Code field to SUCCESS if it accepts the FST Setup Request, shall set the
Status Code to REJECTED_WITH_SUGGESTED_CHANGES (see 9.4.1.9) to indicate that one or more
parameters of the FST Setup Request frame are invalid and shall suggest alternative parameters, shall set the
Status Code to PENDING_ADMITTING_FST_SESSION or PENDING_GAP_IN_BA_WINDOW to
indicate that an FST setup request is pending, and shall set the Status Code field to REQUEST_DECLINED
to reject an FST Setup Request frame.
A responder that is also an enabling STA (see 11.12) may set the Status Code to REJECT_DSE_BAND to
indicate that the FST Setup Request frame is rejected because it was initiated by a dependent STA (see
11.12) that is requesting transition to a frequency band subject to DSE procedures. In this case, if the
responder is the enabling STA for the dependent STA, the responder may include a Timeout Interval
element in the FST Setup Response frame to indicate the period in TUs before which it initiates an FST
Setup with the dependent STA. The Timeout Interval Type field within the Timeout Interval element shall
1876
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
be set to 4. The responder can use the parameters in the FST Setup Request frame received from the
dependent STA to initiate an FST Setup with the initiator.
A responder that is also a dependent STA and not enabled shall reject all received FST Setup Request
frames for transitioning to a frequency band subject to DSE procedures, except if the transmitter of the FST
Setup Request frame is the enabling STA of the dependent STA.
11.33.2.2 Transitioning between states
A state transition within the FST setup protocol is controlled by the State Transition Timer (STT). Each STA
maintains an STT for each FST session. A STA shall move to the Initial state when the STT moves from 1 to
0 (other than set to 0) or upon reception or transmission of an FST Teardown frame.
The initiator shall set the STT to the value of the FSTSessionTimeout field at successful transmission of an
FST Setup Request frame and at each Ack frame sent in response to a received FST Setup Response frame
with the Status Code field equal to PENDING_ADMITTING_FST_SESSION or
PENDING_GAP_IN_BA_WINDOW. The initiator shall set the STT to 0 at the transmission of an Ack
frame sent in response to a received FST Setup Response frame with the value of the Status Code field equal
to SUCCESS.
The responder shall set the STT to the value of the FSTSessionTimeout field at successful transmission of an
FST Setup Response frame. The responder shall set the STT to 0 at each transmission of an Ack frame sent
in response to the reception of an FST Setup Request. The responder should send an FST Setup Response
frame no later than FSTSessionTimeout after the transmission of an Ack frame sent in response to a received
FST Setup Request frame or successful transmission of an FST Setup Response frame with the status code
field equal to PENDING_ADMITTING_FST_SESSION or PENDING_GAP_IN_BA_WINDOW. In the
latter case, the responder shall transmit the unsolicited FST Setup Response frame to the initiator.
There might be multiple FST Setup Request and FST Setup Response frame transmissions by the initiator
and the responder, respectively, until the FST session between these STAs becomes established. At each
transition, or attempt to transition, from the Initial state to the Setup Completed state, the initiator and
responder shall perform the following procedure:
a) The initiator sends an FST Setup Request frame to the responder.
b) Upon receipt of an FST Setup Request frame, the responder shall respond with an FST Setup
Response frame unless it has a pending FST Setup Request frame addressed to the initiator and the
responder has a numerically larger MAC address (see 12.7.1.1 for comparison of MAC addresses)
than the initiator’s MAC address, in which case, the responder shall ignore the received FST Setup
Request.
c) If, after the reception of the acknowledgment to the initiator’s FST Setup Request frame, the
initiator receives an FST Setup Request frame from the responder, the initiator shall not respond
with an FST Setup Response frame if its MAC address is numerically larger (see 12.7.1.1 for
comparison of MAC addresses and see 11.1.4.3.6) than the responder’s MAC address. Otherwise, if
its MAC address is numerically smaller than the responder’s MAC address, it becomes the
responder and shall respond with an FST Setup Response frame and shall not send the FST Setup
Request frame during the current FST session transition.
d) The initiator shall not move to the Setup Completed state if at least one of the following conditions
is met:
1) The initiator does not successfully receive an FST Setup Response frame from the responder
within the STT.
2) The value of the Status Code field in the received FST Setup Response frame from the
responder is different from SUCCESS.
3) A state-specific exception in Table 11-20 takes place.
1877
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
e) The initiator shall move to the Setup Completed state if none of conditions d(1), d(2), and d(3) is
met.
f) The responder shall not move to the Setup Completed state if at least one of the following conditions
is met:
1) The responder does not receive the acknowledgment to its transmitted FST Setup Response
frame
2) The value of the Status Code field in the FST Setup Response frame it transmitted to the
initiator was different from SUCCESS
3) The value of the Setup and Operation subfields within the Session Transition element in the
transmitted FST Setup Response frame results in a status different from any of the rows shown
in Figure 11-21, in which case the responder shall set the Status Code field with the transmitted
FST Setup Response frame to REQUEST_DECLINED.
4) The resulting status of the Operation subfield in the New Band field is 0.
g) The responder shall move to the Setup Completed state if none of conditions f(1), f(2), f(3) and f(4)
is met.
Table 11-20—Exceptions for the initiator
State Condition Meaning Next state
Initial FST Setup Response frame Pending, responder in process of admitting Initial
with Status Code FST session.
PENDING_ADMITTING_F
ST_SESSION
Initial FST Setup Response frame Pending, block ack window at the responder Initial
with Status Code has gaps.
PENDING_GAP_IN_BA_WI
NDOW
Initial FST Setup Response frame One or more parameters of the FST Setup Initial
with Status Code Request frame is invalid and the responder
REJECTED_WITH_SUGGE suggests alternative parameters.
STED_CHANGES
Initial FST Setup Response frame Responder rejects the request. One particular Initial
with Status Code case is that values of the operating class and
REQUEST_DECLINED channel number fields within the Multi-band
element, if any, received in the FST Setup
Request frame is different from the value of
the corresponding fields within the Multi-
band element, if any, transmitted in the
following FST Setup Response.
Initial FST Setup Response frame Responder rejects the request since the Initial
with Status Code initiator is a dependent STA and the request
REJECT_DSE_BAND is for transitioning to a frequency band
subject to DSE procedures. In the rejection,
the responder can include a Timeout Interval
element.
Initial Resulting status is different The responder is not able to complete the Initial
from shown in Table 11-21 setup.
Initial Resulting status of the The operation in the new band is disabled. Initial
Operation field in the New
Band field is 0 in Table 11-21
1878
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-20—Exceptions for the initiator (continued)
State Condition Meaning Next state
Setup FST Setup Response frame The STA is ready to switch to the new band if Setup
Completed with Status Code SUCCESS the link is lost in the old band. Completed
and value of the LLT field
within the FST Setup Request
frame is greater than zero
Setup Transmission or reception of Termination of FST session. Initial
Completed FST Teardown frame
If, upon transition to the Setup Completed state, the value of the LLT field within the last successful FST
Setup Request frame received by the responder or transmitted by the initiator was equal to 0, the initiator
and responder shall immediately move to the Transition Done state.
If, upon transition to the Setup Completed state, the value of the LLT field within the last successful FST
Setup Request frame received by the responder or transmitted by the initiator was greater than 0, the initiator
and responder shall proceed as follows:
— If the last FST Setup Request or FST Setup Response frames exchanged between the initiator and
responder included a Switching Stream element, then all of the streams within the Switching Stream
element that have the LLT Type field set to 1 shall be switched using the Stream-based Link Loss
Countdown, and all of the streams within the Switching Stream element that have the LLT Type
field set to 0 shall be switched using the STA-based Link Loss Countdown.
— If the neither the FST Setup Request nor the FST Setup Response frames exchanged between the
initiator and responder included a Switching Stream element, then the streams shall be switched
using the STA-based Link Loss Countdown.
The FST transition for the STA, if STA-based, or the stream, if stream-based, from the Setup Completed
state to the Transition Done state shall occur immediately after the corresponding Link Loss countdown
timer transitions from 1 to 0 within any of the initiator or responder of the FST session.
An initiator and responder shall perform the STA-based and stream-based Link Loss Countdown as follows:
— STA-based Link Loss Countdown: Both initiator and responder shall remain in the Setup Completed
state and start a Link Loss countdown timer with an initial value of LLT×32 µs. The Link Loss
countdown is reloaded with the value of LLT×32 µs every time that an individually addressed frame
is received from the peer STA of the FST session.
— Stream-based Link Loss Countdown: Both the initiator and responder shall start a Link Loss
countdown timer with an initial value of LLT×32 µs for each stream identified within the Switching
Stream element. The Link Loss countdown for a stream is reloaded with the value of LLT×32 µs
every time that an individually addressed frame for that stream is received from the peer STA of the
FST session.
Before leaving the Setup Completed state, an initiator and/or responder that is performing a full FST may
transmit an FST Setup Response frame in the old band/channel with the Status Code field set to
PERFORMING_FST_NOW and with the RA field set to the broadcast address to notify other STAs in the
BSS of the STA’s forthcoming full FST.
Table 11-21 shows the FST session status at each state transition. The Setup and Operation subfields shown
in Table 11-21 are present within the Session Transition element. When the value of a subfield in the FST
Setup Request frame is different from the value of that same subfield in the following FST Setup Response
1879
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
frame, the resulting status shall be the logical AND of the value of the corresponding subfields in both the
FST Setup Request and the FST Setup Response frames.
Table 11-21—FST status at state transition
Old band resulting New band resulting
status status
From State To State Definition
Setup Operation Setup Operation
Initial 1 1 0 0 Initial New band setup and
operation are disabled.
Initial 1 1 1 0 Initial New band operation is
disabled, the setup is
kept alive.
Initial 0 0 1a 1 Setup FST session is
Completed operational in new
band.
Initial 1a 1 1a 1 Setup FST session is
Completed operational in both
bands.
Initial 1 0 1a 1 Setup FST session is
Completed operational in new
band; FST session in
old band is kept alive.
Setup Unchanged Unchanged Unchanged Unchanged Transition No status changes.
Completed Done
Transition Unchanged Unchanged Unchanged Unchanged Transition No status changes.
Done Confirmed
a
The value of this field remains unchanged during the FST session transition.
Upon transition to the Transition Done state and if transparent FST is used, the association state (see 11.3.1)
of the STA corresponding to the old band/channel is transferred to the STA corresponding to the new band/
channel.
To transition from the Transition Done state to the Transition Confirmed state, the initiator and responder
shall perform the following procedure within the channel number of the operating class and band ID
specified in the Multi-band element negotiated during the FST session setup:
a) The State transition is controlled by the State Transition Timer (STT). Each STA of the FST session
has its own STT. The initiator shall transition to the Initial state when its STT transitions from 1 to 0,
but not when the STT is set to 0. The responder shall transition to the Initial state when its STT
transitions from 1 to 0, but not when the STT is set to 0.
The initiator shall set the STT to the value of the FSTSessionTimeout field at successful
transmission of an FST Ack Request frame or at transmission of any individually addressed MPDU
to the responder. The initiator shall set the STT to 0 at the transmission of an Ack frame sent in
response to a received FST Ack Response from the responder or at reception of an Ack frame
received in response to a frame sent to the responder.
The responder shall set the STT to FSTSessionTimeout at transmission of an FST Ack Response
frame or at transmission of any other individually addressed MPDU to the initiator. The responder
shall set the STT to 0 at the reception of an Ack frame received in response to a transmitted FST Ack
1880
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Response frame or at the reception of any individually addressed frame sent by the initiator. The
responder shall transmit an FST Ack Response frame to the initiator no later than
FSTSessionTimeout after the transmission of an Ack frame sent in response to a received FST Ack
Request from the initiator.
b) The SME of both the initiator and responder generates an MLME-FST-INCOMING.request
primitive that includes the parameters of the FST. This primitive shall be generated to the MLME
associated with the channel number, operating class, and band ID specified in the Multi-band
element negotiated during the FST session setup. This primitive notifies the MLME of an impending
FST.
c) The initiator shall send an FST Ack Request frame or may send any other individually addressed
MPDU to the responder.
NOTE—Depending on the BSS configuration in the new band/channel, the initiator might have to associate
and/or authenticate with the BSS before it is allowed to transmit a frame to the responder.
d) Upon receipt of an FST Ack Request frame, the responder shall respond to the initiator with an FST
Ack Response frame.
NOTE—Depending on the BSS configuration in the new band/channel, the responder might have to associate
and/or authenticate with the BSS before it is allowed to transmit a frame to the initiator.
e) The initiator shall move to the Transition Confirmed state
1) Upon transmission of an Ack frame sent in response to any individually addressed frame,
including an FST Ack Response frame, received from the responder; or
2) When the initiator receives an Ack frame from the responder to any non-FST Ack Request
frame the initiator transmitted to the responder.
f) The responder shall move to the Transition Confirmed state
1) When the responder receives an Ack frame in response to any individually addressed frame,
including an FST Ack Response frame, sent to the initiator; or
2) Upon transmission of an Ack frame sent in response to any individually addressed non-FST
Ack Request frame.
Following the transition to the Transition Confirmed state, a STA shall adopt the role indicated in the STA
Role field corresponding to the channel number, operating class and band ID that was last transmitted to the
peer STA within the Multi-band element. If the STA was operating within a PBSS, was the initiator of the
FST session, and the new role of the STA is as an IBSS STA, then the STA shall be a DFS Owner of the
IBSS.
In case the transition to the Transition Confirmed state was the result of a Stream-based Link Loss
Countdown, the stream shall remain in the Transition Confirmed state until all of the streams included
within the corresponding Switching Stream element reach the Transition Confirmed state. Once all streams
within the corresponding Switching Stream element reach the Transition Confirmed state or the FST session
ceases to exist, the STA moves to the Initial state.
If neither the initiator nor the responder perform in the role of AP or PCP as indicated through the STA Role
field within the Multi-band element corresponding to the new band for that STA, one of the STAs can
initialize a new BSS (11.1) on the new band for communication between the STAs.
If the value of the Switch intent field in the last Session Transition element transmitted to a responder is 1,
an initiator may switch to the new band and channel indicated in the last transmitted FST Setup Request
frame and Multi-band element, respectively, if at least one of the following conditions is satisfied:
— The value of the Status Code field within the FST Setup Response frame received in response to the
transmitted FST Setup Request frame is equal to REQUEST_DECLINED.
1881
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The initiator moves to the Initial state due to the STT at the initiator moving from 1 to 0.
— The initiator moves to the Initial state due to the reception of an FST Teardown frame from the
responder.
Immediately before an initiator switches to a new band and/or channel, the initiator shall disassociate and
delete all TS and block ack agreement(s) it has with a responder for which at least one of the above
conditions is met.
Following the successful FST transition to a new band, the STA of the FST session shall follow the medium
access rules applicable to the new band.
11.33.2.3 FST TS switching
If a STA transmitting an FST Setup Request frame or an FST Setup Response frame does not intend to
switch all its streams, then the STA shall include the Switching Stream element in the transmitted frame to
indicate which streams are requested to be transferred to the other band/channel. If the FST Setup Request
frame includes a Switching Stream element, the FST Setup Response frame should include a Switching
Stream element. If the FST Setup Request frame does not include a Switching Stream element, the FST
Setup Response frame may include a Switching Stream element. If the STA transmitting the Switching
Stream element has not set up a stream in the band indicated in the New Band ID field within this element, it
shall set the Stream ID In New Band Valid field to 0. A STA may set up a stream in any band/channel by
transmitting ADDBA Request or ADDTS Request frames that include the Multi-band element.
If a STA transmits an ADDTS Request frame to another STA with which it has established an FST session
and the ADDTS Request frame is transmitted in a band or channel different from the band or channel to
which the ADDTS request is intended to apply, the ADDTS Request frame shall include the Multi-band
element with the Band ID, Operating Class, and Channel Number fields set to indicate to which channel the
ADDTS Request frame applies. In addition, if these STAs use the nontransparent mode for FST, the STA
transmitting the ADDTS Request frame sets the STA MAC Address Present field to 1 and the STA MAC
Address field to the MAC address that the STA uses in the band and channel number that are indicated in the
Multi-band element contained in the ADDTS Request frame. Similar to the ADDTS Request frame, the
Multi-band element shall be included in the ADDBA Request, ADDTS Response, ADDBA Response,
DELTS, and DELBA frames when these frames are transmitted in a band or channel different from the band
or channel to which they are intended to apply.
When using transparent mode to transfer an FST session corresponding to a TID/TSID, the Direction
subfield within the TSPEC element, if any, used to set up the TID/TSID should not be set to indicate a
bidirectional link. This enables the SME to use the TID/TSID in conjunction with the source and destination
MAC addresses in both the old and new frequency band/channel to uniquely identify the FST session.
If any of the ADDTS variants is used to switch the TS, then the PTP TSPEC or the DMG TSPEC shall be
used when the TS is being established to operate in a DMG BSS, and the Basic TSPEC shall be used when
the TS is being established to operate in a non-DMG BSS irrespective of the band and channel used to
communicate the ADDTS frames and the DMG ADDTS frames.
The rules defined below apply when the ADDTS frames or the DMG ADDTS frames are used to switch TS.
When the ADDTS frames and the DMG ADDTS frames are used, then the ADDTS requester and the
ADDTS responder provide the functions defined for the ADDBA originator and the ADDBA recipient,
respectively.
If the ADDBA recipient includes the Switching Stream element in any of the FST Setup Request or FST
Setup Response frames and if the Stream ID In New Band Valid field within the Switching Stream element
is 0, the ADDBA originator should issue the DELBA frame to reject the BlockAck agreements indicated in
1882
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the Stream ID In Old Band field. If the originator intends to establish new BlockAck agreements in the band
indicated in the Multi-band element sent by the recipient and with the recipient MAC address indicated in
the Multi-band element sent by the recipient, the originator shall transmit an ADDBA Request frame
addressed to the recipient.
The originator may include the Multi-band element and the Ethernet type TCLAS element in the ADDBA
Request frame. If the MAC Addresses of the originator and recipient to be used in the new band are different
from the MAC addresses used in the old band, then the ADDBA Request frame sent in the old band to
establish a block ack agreement in the new band shall include the Multi-band and the TCLAS elements. The
resulting block ack agreement, if established, applies to the band and channel identified in the Multi-band
element included in the ADDBA Request frame. The BlockAck is identified by the TID/TSID and MAC
addresses of the originator and the recipient used in the band and channel indicated in the Multi-band
element included in ADDBA Request and ADDBA Response frames.
The ADDBA Request frame may be issued in the old band and channel, and the corresponding ADDBA
Response frame may be transmitted in the band and channel indicated in the Multi-band element within the
ADDBA Request frame.
The following rules for establishment of a multi-band block ack agreement shall apply:
a) If the TA and/or the RA fields of the ADDBA Request frame are different from the originator MAC
address and/or the recipient MAC address, respectively, used in the channel and band where the
block ack agreement should operate, then the originator shall set the Source Address field and the
Destination Address field of the classifier to the originator MAC address and the recipient MAC
address, respectively, to be used in the band and channel indicated in the Multi-band element
included in the ADDBA Request frame.
b) If the TA and RA are equal to the originator MAC address and the recipient MAC address,
respectively, then the Multi-band element, if any, included in the ADDBA Request frame shall
indicate the band and channel over which the established block ack agreement is operating. The
TCLAS element shall not be included in this ADDBA Request frame.
c) The Multi-band element should not be included in the ADDBA Request frame if in the case b) the
ADDBA Request frame is issued in the same band and channel over which the block ack agreement
shall operate.
d) If the TA and/or the RA fields of the ADDBA Response frame are different from the recipient MAC
address and/or the originator MAC address, respectively, to be used in the channel and band where
the block ack agreement should operate, then the recipient shall set the Source Address field and the
Destination Address field of the classifier to the recipient MAC Address and the originator MAC
address, respectively, to be used in the band and channel indicated in the Multi-band element
included in the ADDBA Response frame. The indicated band and channel shall be equal to the band
and channel indicated in the Multi-band element of the ADDBA Request frame.
e) If the TA and RA fields are equal to the recipient MAC address and the originator MAC address,
respectively, then the Multi-band element, if any, included in the ADDBA Response frame shall
indicate the band and channel over which the established block ack agreement is operating. The
indicated band and channel shall be equal to the band and channel indicated in the Multi-band
element of the ADDBA Request frame. The TCLAS element shall not be included in the ADDBA
Response frame.
f) The Multi-band element should not be included in the ADDBA Response frame if in case e) the
ADDBA Response frame is issued in the same band and channel over which the block ack
agreement, if established, shall operate.
1883
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.33.3 FST teardown
At the Setup Completed state or Transition Done state, a STA may transmit an FST Teardown frame to its
peer STA of the FST session in order to tear down an FST session that was previously set up using the FST
Setup Request/Response frame exchange. Upon transmission or reception of an FST Teardown frame, the
initiator and responder move to the Initial state (11.33.2). When moving to the Initial state and if the value of
the Switch intent field in the last Session Transition element transmitted to a responder is 1, the initiator
behaves as described in 11.33.2.2.
11.33.4 On-channel Tunneling (OCT) operation
OCT allows a STA of a multi-band capable device to transmit an MMPDU that was constructed by a
different STA of the same device. An MMPDU transmitted this way is referred to as an OCT MMPDU. The
MLME of the nontransmitting STA that constructs or is the destination of an OCT MMPDU is referred to as
an NT-MLME. The MLME of the STA that transmits or receives an OCT MMPDU over the air is referred to
as a TR-MLME.
NOTE—OCT can be used in conjunction with or independent from the FST setup protocol.
Figure 11-49 depicts the overall OCT procedure. In this figure, refers to the name of any of the
MLME primitives defined in 6.3 that meets all of the following conditions:
— Defines request, indication, response, and confirm primitives, or just request and indication
primitives.
— Includes a peer Multi-band element. The peer Multi-band element is used to identify the peer NT-
MLME.
— Includes a local Multi-band element. The local Multi-band element is used to identify the local
NT-MLME.
Multi-band capable device Multi-band capable device
SME NT-MLME TR-MLME TR-MLME NT-MLME SME
MLME-
.req
(Tunnel=TR-MLME)
MLME-
OCTunnel.req
(tunneled MMPDU)
On-channel Tunnel Request
frame MLME-
OCTunnel.ind
(tunneled MMPDU) MLME-
.ind
(Tunnel=TR-MLME)
MLME-
.rsp
MLME- (Tunnel=TR-MLME)
OCTunnel.rsp
(tunneled MMPDU)
On-channel Tunnel Response
MLME- frame
OCTunnel.cfm
(tunneled MMPDU)
MLME-
.cfm
(Tunnel=TR-MLME)
Figure 11-49—On-channel tunneling procedure
An MLME primitive meeting all of the above conditions is referred to as an OCT MLME primitive.
NOTE—MLME-AUTHENTICATE, MLME-ASSOCIATE, and MLME-REASSOCIATE are examples of primitives
that are OCT MLME primitives.
1884
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
To transmit a tunneled MMPDU, the SME of a multi-band capable device generates an OCT MLME request
primitive that includes the peer Multi-band element and the local Multi-band element.
A NT-MLME receiving an OCT MLME request primitive shall
— As defined in this standard, process the request and construct an OCT MMPDU corresponding to the
primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.
— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU and
the peer Multi-band element. The MLME-OCTunnel.request primitive shall be generated to the TR-
MLME identified by the local Multi-band element which is contained within the OCT MMPDU.
A TR-MLME receiving an MLME-OCTunnel.request primitive shall transmit an On-channel Tunnel
Request frame addressed to the peer TR-MLME and which includes the tunneled MMPDU.
A TR-MLME receiving an On-channel Tunnel Request frame shall generate an MLME-
OCTunnel.indication primitive. The MLME-OCTunnel.indication primitive shall be generated to the NT-
MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request
frame.
A NT-MLME receiving an MLME-OCTunnel.indication primitive shall
— As defined in this standard, process the OCT MMPDU parameter of the primitive as if the MMPDU
had been received over the air.
— Generate an OCT MLME indication primitive corresponding to the frame type of tunneled
MMPDU. This primitive is generated to the SME of the STA, which processes the MMPDU as
defined in this standard.
In the case of a .request/.indication primitive, the process stops here. Otherwise, the process continues as
described below.
The peer SME responds to the reception of an OCT MLME indication primitive by generating the
corresponding OCT MLME response primitive. This response includes the peer Multi-band element and the
local Multi-band element.
A NT-MLME receiving an OCT MLME response primitive shall
— As defined in this standard, process the response and construct an OCT MMPDU corresponding to
the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.
— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU and
the peer Multi-band element. The MLME-OCTunnel.request primitive shall be generated to the TR-
MLME identified by the local Multi-band element which is contained within the OCT MMPDU.
A TR-MLME receiving an MLME-OCTunnel.request primitive transmits an On-channel Tunnel Request
frame addressed to the peer TR-MLME that includes the tunneled MMPDU.
A TR-MLME receiving an On-channel Tunnel Request frame generates an MLME-OCTunnel.indication
primitive. The MLME-OCTunnel.indication primitive is generated to the NT-MLME identified by the peer
Multi-band element contained within the received On-channel Tunnel Request frame.
A NT-MLME receiving an MLME-OCTunnel.indication primitive
— Processes the OCT MMPDU parameter of the primitive as if the MMPDU had been received over
the air.
— Generates an OCT MLME confirm primitive corresponding to the frame type of the OCT MMPDU.
This primitive is directed at the SME.
1885
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.33.5 FST payload
When FST action frames are forwarded by an AP, FST uses Ethertype 89-0d frames as defined in Annex H.
In this case, the FST payload contains an FST Action frame body as is specified in 9.6.21.
11.34 MMSL cluster operation
11.34.1 Introduction
A STA is MMSL cluster capable if it includes an MMS element in its most recent transmission of
(Re)Association Request, (Re)Association Response, ADDTS Request, ADDTS Response, Probe Request,
Probe Response, Information Request, or Information Response frames.
An MM-SME coordinated STA shall be MMSL cluster capable, except for an MM-SME that coordinates
two STAs where one STA is a member AP or member PCP in a centralized AP or PCP cluster and the other
STA is associated to the S-AP of the centralized AP or PCP cluster.
NOTE—In the centralized clustering case, the two STAs in the MM-SME are communicating with different MAC
entities with different SMEs, so there is no individual link for MMSL.
A non-MM-SME coordinated STA may be MMSL cluster capable.
An MMSL cluster capable STA shall include an MMS element in transmitted (Re)Association Request and
(Re)Association Response frames.
As described in 4.9.3, an MM-SME may coordinate multiple MACs (and their respective STAs).
Each STA coordinated by the same MM-SME may be used for the MMSL cluster setup and maintenance.
The PCP may deliver an MMS element that includes a MAC address that is equal to the BSSID and other
MAC addresses that are not equal to the BSSID. The MAC addresses that are not the BSSID shall not be
used to request and respond to association, reassociation, probing, and scheduling services provided by the
PCP.
If a non-AP and non-PCP STA has delivered an MMS element to the AP or PCP, the non-AP and non-PCP
STA shall not send an ADDTS Request frame to the AP or PCP with the TA field equal to a MAC address
that was not included in the delivered MMS element.
If an MM-SME coordinated STA is associated with an AP or PCP that allocates one single AID to all STAs
advertised in the MMS element sent by the MM-SME coordinated STA, the AID can be also used to identify
the MMSL cluster. If the AID is provided for one of the advertised STAs of the MM-SME coordinated STA,
then the same AID applies to all STAs whose addresses are referenced in the delivered MMS element and
the Single AID field is set as per Table 9-247.
Table 11-22 covers the possible cases of the AID use for MMSL cluster identification.
1886
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-22—Setting of Single AID field
Is the Single Is the Single
AID allocated to AID allocated to AID
MMSL cluster configuration the MM-SME the MM-SME identification of
coordinated coordinated MMSL cluster
STA A? STA B?
Non-AP and non-PCP MM-SME coordinated STA Yes Yes Yes
A is associated to PCP MM-SME coordinated STA
B.
Non-AP and non-PCP MM-SME coordinated STA Yes Yes Yes
A and non-AP and non-PCP MM-SME coordinated
STA B are both associated to the same BSS.
Non-AP and non-PCP MM-SME coordinated STA Yes No No
A is associated to a BSS and non-AP and non-PCP
MM-SME coordinated STA B is not associated to
the BSS.
Non-AP and non-PCP MM-SME coordinated STA Yes NA Yes
A and non-AP and non-PCP STA B are both
associated to the same BSS.
Non-AP and non-PCP MM-SME coordinated STA Yes NA Yes
A is associated to a BSS and one MAC entity of
non-AP and non-PCP MM-SME coordinated STA B
is associated to the same BSS.
11.34.2 MMSL cluster setup
11.34.2.1 General
To establish an MMSL cluster, an MMS element of an MM-SME coordinated STA that lists its advertised
STAs shall be delivered to the peer STA. The peer STA may be an MM-SME coordinated STA or a non-
MM-SME coordinated STA. An MMSL cluster is identified by one of the following:
a) Advertised MAC addresses of the MAC entities of two MM-SME coordinated STAs
b) Advertised MAC addresses of the MAC entities of an MM-SME coordinated STA and of a non-
MM-SME coordinated STA
In both cases, the MMS element shall be exchanged between the STAs to set up the MMSL cluster
agreement.
If an MMSL cluster capable non-MM-SME coordinated STA receives an ADDTS Request frame that
includes an MMS element, the SME of the non-MM-SME coordinated STA shall include the received MMS
element in the MLME-ADDTS.response primitive used to send the ADDTS Response frame if the SME
accepts the MMSL cluster setup. The SME of the non-MM-SME coordinated STA may set the MMS
Element Owner field to “no Owner” in the MMS element included in an MLME-ASSOCIATE.request
primitive and MLME-ADDTS.request primitive to establish the MMSL cluster with an MM-SME
coordinated STA.
The MMS element shall be exchanged between the STAs of the MMSL cluster only once per MMSL cluster
setup.
1887
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.34.2.2 MMSL cluster setup of non-AP and non-PCP MM-SME coordinated STA with AP or
PCP
The Association Request and Response frames are used to establish an MMSL cluster between a non-AP
and non-PCP MM-SME coordinated STA and an AP or PCP. If the AP or PCP is not an MM-SME
coordinated STA, the AP or PCP shall include the MMS element received from the non-AP and non-PCP
MM-SME coordinated STA in the Association Response frame sent as response. If the AP or PCP is an
MM-SME coordinated STA, the AP or PCP should include its own MMS element that contains its
advertised MAC entities in the Association Response frame and shall not include the MMS element received
from the non-AP and non-PCP MM-SME coordinated STA in the Association Response frame. The AP or
PCP shall not respond with any MMS element if it is not MMSL cluster capable.
The setup of the MMSL cluster fails if the Association Response frame does not contain the MMS element.
11.34.2.3 MMSL cluster setup of non-AP and non-PCP STA with another non-AP and non-
PCP STA
If a non-AP and non-PCP MM-SME coordinated STA associated with an AP or PCP has established an AID
identified MMSL cluster with the AP or PCP, the non-AP and non-PCP MM-SME coordinated STA shall
not use a MAC address that was not included in the MMS element delivered to the AP or PCP to establish an
MMSL cluster with another non-AP and non-PCP MM-SME coordinated STA associated with the same AP
or PCP.
An ADDTS Request/Response frame exchange with a PTP TSPEC shall be used to establish the MMSL
cluster between non-AP and non-PCP MM-SME coordinated STAs and between a non-AP and non-PCP
MM-SME coordinated STA and a non-AP and non-PCP non-MM-SME coordinated STA.
A non-AP and non-PCP MM-SME coordinated STA shall include an MMS element that contains its
advertised MAC entities in transmitted ADDTS Request frames. If the non-AP and non-PCP STA is not an
MM-SME coordinated STA, the non-AP and non-PCP STA should include the MMS element with the
MMS Element Owner field set to “no Owner” in the ADDTS Request frame.
The non-AP and non-PCP MM-SME coordinated STA shall include its own MMS element that contains its
advertised MAC entities in transmitted ADDTS Response frames. The non-MM-SME coordinated STA
may include the MMS element of the MM-SME coordinated STA from which it received an ADDTS
Request frame in the ADDTS Response frame sent as response. The non-MM-SME coordinated STA shall
not respond with any MMS element if it is not MMSL cluster capable.
The setup of the MMSL cluster fails if the ADDTS Response frame does not contain the MMS element.
11.35 DMG coexistence with non-IEEE-802.11 systems
This subclause describes the features available in this standard to improve coexistence with other DMG
systems, including IEEE Std 802.15.3c™.
The same common channelization that is defined in other DMG standards and specifications is adopted
(20.3.1). In regulatory domains where 2 or more channels are defined, a DMG STA should support at least
2 channels.
An AP should not start an infrastructure BSS on a channel where the signal level is at or above
aDMGDetectionThres or upon detecting a valid IEEE 802.15.3c™ CMS preamble at a receive level greater
than or equal to –60 dBm.
1888
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If a DMG STA is capable of performing directional channel measurements (11.32) to detect non-IEEE-Std-
802.11 transmissions on a channel, it can report the results of the measurements to the STA’s AP or PCP.
If a DMG STA detects a non-IEEE-802.11 transmission on its channel or if the AP or PCP receives a report
(11.11) from a DMG STA on a non-IEEE-802.11 transmission, the following mechanisms might be used to
mitigate interference:
— Change operating channel (11.9)
— Beamforming (10.38)
— Reduce transmit power (11.8)
— Perform FST (11.33)
— Move the TBTT (11.31.2), and thus the beacon interval, in the case of an AP or PCP
— Change the schedule of SPs and CBAPs in the beacon interval (9.4.2.132) in the case of an AP or
PCP
— Defer transmission for a later time
— For periods of time in the beacon interval where the STA experiences poor channel quality, the STA
can use the Traffic Scheduling Constraint Set field within the DMG TSPEC element (9.4.2.134) to
request its AP or PCP to avoid scheduling an SP for that DMG STA during those periods of time in
the beacon interval.
11.36 DMG relay procedures
11.36.1 General
Relaying allows a source relay endpoint DMG STA (REDS) to transmit frames to a destination REDS with
the assistance of another DMG STA called the relay DMG STA (RDS). Relaying can improve the reliability
of communication in a DMG BSS in case the direct link between the source REDS and the destination
REDS is disrupted.
A STA is a REDS if both dot11REDSActivated and dot11RelayActivated are true. A REDS shall set the
Relay Client field within its Relay Capabilities element to 1. A STA is an RDS if both dot11RDSActivated
and dot11RelayActivated are true. An RDS shall set the Relay Supporter field within its Relay Capabilities
element to 1. A STA is relay capable if dot11RelayActivated is true and it is either a REDS or an RDS or
both, and it is relay incapable otherwise.
A relay capable STA shall advertise its capability by including the Relay Capabilities element in
(Re)Association Request, (Re)Association Response, Probe Request, Probe Response, Information Request,
and Information Response frames. An AP or relay capable PCP may include the Relay Capabilities element
in DMG Beacon frames.
For a STA to operate as a REDS or an RDS in an Infrastructure BSS or PBSS, the following conditions shall
be met:
— The STA is a member of the Infrastructure BSS or PBSS.
— The TDDTI field within the DMG STA Capabilities element of the AP or PCP of the BSS is 1.
— The Relay permission field within the Relay Capabilities element of the AP or PCP of the BSS is 1.
A source REDS, a destination REDS and an RDS can establish the types of relay operation as specified in
10.40.
1889
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
As needed, in the following subclauses, source REDS, RDS, and destination REDS are expressed as ‘S’,
‘R’, and ‘D’, respectively. Also, a direct link between STA S and STA D can be simply referred to as S-D
link.
11.36.2 Common relay setup procedures
11.36.2.1 Introduction
This subclause describes the procedures that a source REDS, a destination REDS, and an RDS employ to set
up a relay operation among these STAs. These procedures are used for both link switching and link
cooperation relays, and shall be performed in the order shown in this subclause.
11.36.2.2 Relay capabilities and RDS discovery procedures
A source REDS can obtain the capabilities of other STAs in the BSS following the STA’s association with
the BSS or with the transmission of an Information Request frame as described in 11.30.1.
A source DMG STA that intends to set up relay operation with a destination DMG STA shall obtain the
capabilities of the destination DMG STA prior to initiating the relay setup procedure with the destination
DMG STA. The source DMG STA may attempt to set up relay operation with the destination DMG STA
only if both the source DMG STA and destination DMG STA are REDS, and there exists at least one RDS
in the BSS.
Upon receiving an MLME-RELAY-SEARCH.request primitive, the source DMG STA can discover a list of
RDSs in the BSS by transmitting a Relay Search Request frame to the AP or PCP with the destination REDS
AID field set to the AID of the destination DMG STA. The MLME of the AP or PCP receiving a Relay
Search Request frame shall generate an MLME-RELAY-SEARCH.indication primitive. Upon receiving an
MLME-RELAY-SEARCH.response primitive, the AP or PCP shall transmit a Relay Search Response
frame addressed to the requesting STA and shall include in the transmitted frame a list of RDSs in the BSS.
The MLME of the source DMG STA receiving a Relay Search Response frame shall generate an MLME-
RELAY-SEARCH.confirm primitive. After the transmission of the Relay Search Response frame to the
source DMG STA, the AP or PCP shall transmit an unsolicited Relay Search Response frame to the
destination DMG STA with the Relay Capable STA Info field of the source DMG STA and the list of RDSs
that the AP or PCP included in the last Relay Search Response frame transmitted to the source DMG STA.
11.36.2.3 RDS selection procedure
Following the transmission of a Relay Search Response frame, the AP or PCP should schedule within its
Extended Schedule element two SPs for each RDS included in the transmitted Relay Search Response
frame:
— An SP having as source DMG STA the source REDS and as destination DMG STA the RDS, and
with the Beamforming Training field set to 1. The duration of the SP should be such that the source
REDS and RDS can complete BF as described in 10.38.
— An SP having as source DMG STA the RDS and as destination DMG STA the destination REDS,
and with the Beamforming Training field set to 1. The duration of the SP should be such that the
RDS and the destination REDS can complete BF as described in 10.38.
After the RDS completes BF with both the source REDS and destination REDS, the source REDS shall send
a Multi-Relay Channel Measurement Request frame to the RDS, which shall respond with the transmission
of a Multi-Relay Channel Measurement Report frame back to the source REDS. Following the reception of
this frame, the source REDS should perform BF with the destination REDS as described in 10.38, and once
BF is completed the source REDS shall transmit a Multi-Relay Channel Measurement Request frame to the
destination REDS. In response, the destination REDS shall transmit a Multi-Relay Channel Measurement
1890
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Report frame to the source REDS including the channel measurement information between the destination
REDS and all RDSs known to the destination REDS. To shorten the time it takes to complete this procedure,
STAs can limit BF to the SLS phase only.
Once this procedure is completed, the source REDS becomes aware of all the channel measurement
information between the source REDS and zero or more RDSs and between the destination REDS and zero
or more RDSs. The source REDS shall then select a single STA to operate as the RDS between the source
REDS and the destination REDS. The selection of the RDS is implementation dependent, and it can be
based on information contained within an RDS’s Relay Capabilities element and channel measurements.
11.36.2.4 RLS procedure
Following the selection of the RDS to be used between the source REDS and the destination REDS, the
source REDS receiving an MLME-RLS.request primitive initiates the RLS procedure by sending an RLS
Request frame to the selected RDS. The RLS Request frame includes the capabilities and the AIDs of the
source REDS, the destination REDS, and the RDS, and the relay transfer parameter set. Upon receiving the
RLS Request frame, the RDS shall transmit an RLS Request frame to the destination REDS containing the
same information as received within the frame body of the source REDS’s RLS Request frame.
The MLME of the destination REDS receiving a Relay Search Request frame shall generate an MLME-
RLS.indication primitive. Upon receiving an MLME-RLS.response primitive, the destination REDS shall
transmit an RLS Response frame to the RDS with the destination status code field set to SUCCESS if the
destination REDS is willing to participate in the RLS, and set to REQUEST_DECLINED if the destination
REDS is not willing to participate in the RLS. Upon receiving the RLS Response frame, the RDS shall
transmit an RLS Response frame to the source REDS containing the same information as received within the
destination REDS’s RLS Response frame, with the exception that the RDS shall set the relay status code
field to SUCCESS if the RDS is willing to participate in the RLS, and shall set it to REQUEST_DECLINED
if the RDS is not willing to participate in the RLS.
The MLME of the source DMG STA receiving an RLS Response frame from the RDS shall generate an
MLME-RLS.confirm primitive. Upon receiving an RLS Response frame with the destination status code
and relay status code fields set to SUCCESS, the source DMG STA may transmit an RLS Announcement
frame to the AP or PCP to indicate that the RLS procedure was successfully completed. If either or both of
the destination status code and relay status code fields are nonzero, the RLS procedure is unsuccessful.
Upon the completion of RLS procedure, the source REDS, the destination REDS, and the RDS can redo BF
among them.
11.36.3 Relay operation-type change procedure
The source REDS may change the relay operation type from link switching to link cooperation, and vice-
versa, if either one of S-D, or S-R, or R-D links becomes unavailable or for other reasons. Link
unavailability can be determined by the source DMG STA not receiving expected frames from the
destination REDS. To assist in this decision, the source REDS can use the link adaptation procedure
(10.41.4) to obtain the quality of a link.
To change the relay operation type within an SP from link cooperation to link switching in a case that the S-
D link becomes unavailable, the source REDS shall transmit a ROC Request frame to the RDS with the Link
Cooperation subfield set to 0 and the relay-link subfield set to 1. Upon receiving a ROC Request frame, the
RDS shall transmit a ROC Request frame to the destination REDS containing the same information as
received within the frame body of the source REDS’s ROC Request frame. Following the reception of a
ROC Request frame, the destination REDS shall respond with a ROC Response frame to the RDS with the
status code field set to SUCCESS if the destination REDS accepts to change the operation into link
switching, and set to REQUEST_DECLINED if the destination REDS rejects the request. Upon receiving
1891
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the ROC Response frame, the RDS shall transmit a ROC Response frame to the source REDS with the status
code field set to SUCCESS only if the RDS accepts to change the operation into link switching and the
status code field set to SUCCESS in the ROC Response frame received from destination REDS. Otherwise,
the RDS shall set the status code field to REQUEST_DECLINED. Upon reception of a ROC Response from
the RDS with the status code field set to SUCCESS, the source REDS immediately starts to transmit frames
to the destination REDS via the RDS relay link.
To change the relay operation type from link cooperation to link switching in other case that the S-R link
becomes unavailable, the source REDS shall a ROC Request frame to the destination REDS with the Link
Cooperation subfield set to 0 and the relay-link subfield set to 0. Following the reception of a ROC Request
frame, the destination REDS shall respond with a ROC Response frame to the source REDS with the status
code field indicating the acceptance or rejection of the request. Upon reception of a ROC Response from the
destination REDS with the status code field set to SUCCESS, the source REDS starts to transmit frames to
the destination REDS via the direct link in link switching.
To change the relay operation type within an SP from link switching to link cooperation, the source REDS
shall transmit a ROC Request frame to the destination REDS via the RDS with the Link Cooperation
subfield set to 1. Following the reception of a ROC Request frame from the RDS, the destination REDS
shall respond with a ROC Response frame to the source REDS via the RDS with the status code field
indicating the acceptance or rejection of the request. Upon reception of a ROC Response frame from the
RDS with the status code field set to SUCCESS, the source REDS immediately starts to transmit frames to
the destination REDS using the RDS in link cooperation. If a TPA procedure was not performed beforehand
since the link switching operation has been continued from the start of relay operation, the STA shall
perform the TPA procedure before transmitting using link cooperation.
NOTE—As described in 10.40, during the SP in link cooperation operation the destination REDS has its receive antenna
pattern such that it simultaneously covers the links toward both the source REDS and the RDS.
11.36.4 Relay teardown
A source REDS that has successfully completed the RLS procedure with a destination REDS may teardown
the relay operation between the source REDS, destination REDS and RDS. To do that, the source REDS
shall transmit an RLS Teardown frame to the RDS, destination REDS and AP or PCP of the BSS. Within the
RLS Teardown frame, the source REDS shall set the source AID field to the AID of the source REDS, the
destination AID field to the AID of the destination REDS and the relay AID field to the AID of the RDS.
A RDS may teardown the relay operation between the source REDS, destination REDS and RDS. To do
that, the RDS shall transmit an RLS Teardown frame to the source REDS, destination REDS and AP or PCP
of the BSS. Within the RLS Teardown frame, the RDS shall set the source AID field to the AID of the
source REDS, the destination AID field to the AID of the destination REDS and the relay AID field to the
AID of the RDS.
11.37 Quieting adjacent DMG BSSs
11.37.1 General
An AP that supports QAB shall set the QAB Capability field within the AP’s Extended Capabilities element
to 1 and shall set the QAB Capability field to 0 otherwise. In addition, if an AP supports QAB, the AP shall
also support scheduling SPs as defined in 10.36.6.
1892
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.37.2 Procedure at the requester AP
Upon receipt of an MLME-QAB.request primitive, an AP shall perform the following procedure to start the
Quiet Adjacent BSS operation (Figure 11-50):
a) If both the requester and responder APs are QAB capable as indicated by the QAB Capability field
within the Extended Capabilities element, the requester AP sends a QAB Request frame indicating
the duration, period, offset, and number of the quiet intervals. The requester AP may include
multiple Quiet Period Request elements in one frame targeting multiple responder APs.
b) If a QAB Response frame is received with the matching dialog token and request token with a status
code set to a value of SUCCESS, the AP has confirmed the responder AP has scheduled the
requested quiet periods, and the MLME shall issue an MLME-QAB.confirm primitive indicating the
success of the procedure.
c) If a QAB Response frame is received with the matching dialog and request token with a status code
set to a value other than SUCCESS, the procedure is considered to have failed, and the MLME shall
issue an MLME-QAB.confirm primitive indicating the failure of the procedure.
NOTE—The GAS protocol can be used by an AP to verify the capabilities of another AP.
11.37.3 Procedure at the responder AP
A responder AP shall operate as follows (Figure 11-50):
a) When a QAB Request frame matching the BSSID is received from another AP, the MLME shall
issue an MLME-QAB.indication primitive.
b) Upon receipt of the MLME-QAB.response primitive, the AP shall respond by transmitting a QAB
Response frame.
1) If the result code is SUCCESS, the request is accepted. The AP shall use SPs to schedule the
quiet period(s) according to the accepted request. The SPs shall have the AP as both source and
destination and the AP shall not transmit during the SP. The QAB procedure shall be
terminated if the number of quiet intervals exceeds the value of the Repetition Count field
specified. Contained in the transmitted QAB Response frame is the copy of the request token
and the BSSID of the AP.
2) If the result code is REJECTED, the request has not been fulfilled.
AP SME AP MAC AP MAC AP SME
MLME-QAB.request
QAB Request
MLME-
QAB.indication
MLME-
QAB.response
QAB Response
MLME-QAB.confirm
Figure 11-50—Quieting adjacent BSS operation
1893
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.38 DMG beamforming
Upon receipt of an MLME-BF-TRAINING.request primitive, a STA shall undertake beamforming training
with the STA indicated by the PeerSTAAddress parameter according to the procedures defined in 10.38.
This training shall start with the SLS and shall include the BRP if and only if the RequestBRP parameter of
the MLME-BF-TRAINING.request primitive is true.
A STA receiving MLME-BF-TRAINING.request primitive may act as either initiator or responder in the
beamforming training.
If the STA indicated by the PeerSTAAddress parameter of a received MLME-BF-TRAINING.request
primitive is an AP or PCP of a BSS in which a STA is a member, the STA receiving the MLME-BF-
TRAINING.request primitive may perform beamforming training during the A-BFT as described in 10.38.5.
Alternatively, the STA receiving the MLME-BF-TRAINING.request primitive may use an SP or a TXOP to
perform ISS as described in 10.38.2.2.
A STA receiving the MLME-BF-TRAINING.request primitive shall issue an MLME-BF-
TRAINING.confirm primitive on completion of the requested beamforming training or on timeout as
specified in 10.38.
A STA that performs beamforming training with a peer STA at the request of the peer STA shall issue an
MLME-BF-TRAINING.indication primitive on completion of that beamforming training, or on timeout as
specified in 10.38.
Figure 11-51 illustrates an example of the beamforming training procedure in the DTI for a case where the
STA receiving the MLME-BF-TRAINING.request primitive acts as initiator.
Figure 11-52 illustrates an example of the beamforming training procedure in the context of a non-AP and
non-PCP STA joining an infrastructure BSS or PBSS. In this scenario, the MLME-BF-TRAINING.request
primitive is issued by the STA attempting to associate in order that the link be trained to a degree that allows
the over-the-air exchanges necessary for association to succeed.
1894
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SME MAC Peer MAC Peer SME
MLME-BF-TRAINING.request
SSW
SSW
.
ISS .
.
SSW
SSW
SSW
.
RSS .
.
SSW
SSW-Feedback
SSW-Ack
If BRP requested
BRP frame
BRP frame
.
.
.
BRP frame
MLME-BF-TRAINING.confirm MLME-BF-TRAINING.indication
Figure 11-51—Beamforming training procedure in the DTI
Non-AP and Non-AP and
AP or PCP MAC AP or PCP SME
non-PCP SME non-PCP MAC
MLME-SCAN.request
Scan detects an AP or PCP of interest
MLME-SCAN.confirm
MLME-JOIN.request
MLME-JOIN.confirm DMG Beacon
DMG Beacon
MLME-BF-TRAINING.request .
.
.
SLS (possibly as responder using initiator
TXSS from BTI and with RSS in A-BFT or DTI),
followed by BRP if requested by either side.
MLME-BF-TRAINING.confirm MLME-BF-TRAINING.indication
MLME-ASSOCIATE.request Association Request MLME-ASSOCIATE.indication
MLME-ASSOCIATE.confirm Association Response MLME-ASSOCIATE.response
Figure 11-52—Beamforming training when joining an infrastructure BSS or PBSS
1895
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.39 DMG MAC sublayer attributes
The attributes that define some of the MAC characteristics are given in Table 11-23.
Table 11-23—DMG MAC sublayer attribute values
Attribute Value
aMaxBIDuration 1000 TUs
aMinChannelTime aMaxBIDuration
aMinBTIPeriod 4
aMinSwitchInterval 2×aMinBTIPeriod
aMaxSwitchInterval 16×aMinSwitchInterval
aTSFResolution 1 µs
aDMGPPMinListeningTime 150 µs
aSSFramesPerSlot 4
aSSDuration (FSS – 1) × SBIFS + FSS × TXTIME(SSW)
aSSFBDuration TXTIME(SSW-Feedback)
aRTSTimeoutTime TXTIME(RTS) + aAirPropagationTime + aRxPHYDelay +
aMACProcessingDelay
aDMGTSFAccuracy 20 ppm
aMinNAVTimersNumber 2
aCWminDMGIBSS 3
aMinAllocationDeliveryTime 300 µs
aMaxABFTAccessPeriod 2
aDtime aSBIFSTime+TXTIME(TPA Request frame)
aRelayTPATime aSBIFSTime+2×aAirPropagationTime+2×aDtime+
TXTIME(TPA Request frame)+2×TXTIME(TPA Response frame)
aMinPPDUDurationForDMGMeasurement 5.27 µs
aDMGDWSValidPeriod 60 seconds
11.40 VHT BSS operation
11.40.1 Basic VHT BSS functionality
A VHT STA has dot11VHTOptionImplemented equal to true.
A STA that is starting a VHT BSS shall be able to receive and transmit at each of the
tuple values indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter of the
MLME-START.request primitive and shall be able to receive at each of the tuple values
indicated by the Supported VHT-MCS and NSS Set field of the VHT Capabilities parameter of the MLME-
START.request primitive.
1896
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA for which dot11VHTOptionImplemented is true shall set dot11HighThroughputOptionImplemented
to true.
A STA that is a VHT AP or a VHT mesh STA declares its channel width capability in the VHT Capabilities
element VHT Capabilities Information field as described in Table 9-249.
A VHT STA shall set the Supported Channel Width Set subfield in its HT Capabilities element HT
Capability Information field to 1, indicating that both 20 MHz operation and 40 MHz operation are
supported.
At a minimum, a VHT STA sets the Rx MCS Bitmask of the Supported MCS Set field of its HT Capabilities
element according to the setting of the Rx VHT-MCS Map subfield of the Supported VHT-MCS and NSS
Set field of its VHT Capabilities element as follows: for each subfield Max VHT-MCS For n SS, 1 n 4 ,
of the Rx VHT-MCS Map field with a value other than 3 (no support for that number of spatial streams), the
STA shall indicate support for MCSs 8(n–1) to 8(n–1)+7 in the Rx MCS Bitmask, where n is the number of
spatial streams, except for those MCSs marked as unsupported as described in 10.7.12.3.
A STA that is a VHT AP or a VHT mesh STA shall set the STA Channel Width subfield in the HT
Operation element HT Operation Information field and the Channel Width, Channel Center Frequency
Segment 0 and Channel Center Frequency Segment 1 subfields in the VHT Operation element VHT
Operation Information field to indicate the BSS bandwidth as defined in Table 11-24.
Table 11-24—VHT BSS bandwidth
HT Operation
VHT Operation VHT Operation element
element STA
element Channel Channel Center Frequency BSS bandwidth
Channel Width
Width field Segment 1 subfield
field
0 0 0 20 MHz
1 0 0 40 MHz
1 1 0 80 MHz
1 1 CCFS1 > 0 and 160 MHz
| CCFS1 - CCFS0 | = 8
1 1 CCFS1 > 0 and 80+80 MHz
| CCFS1 - CCFS0 | > 16
1 2 0 160 MHz
(deprecated)
1 3 CCFS1 > 0 and 80+80 MHz
| CCFS1 - CCFS0 | > 16 (deprecated)
NOTE 1—CCFS0 represents the value of the Channel Center Frequency Segment 0 subfield.
NOTE 2—CCFS1 represents the value of the Channel Center Frequency Segment 1 subfield.
The setting of the Channel Center Frequency Segment 0 and Channel Center Frequency Segment 1 subfields
is shown in Table 11-25.
A VHT STA shall determine the channelization using the combination of the information in the HT
Operation element Primary Channel field and the VHT Operation element VHT Operation Information field
Channel Center Frequency Segment 0 and Channel Center Frequency Segment 1 subfields (see 21.3.14).
1897
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 11-25—Setting of Channel Center Frequency Segment 0, Channel Center
Frequency Segment 1, and Channel Center Frequency Segment 2 subfields
VHT
Setting of the Setting of the
Operation
BSS Setting of the Channel Center Frequency Channel Center Channel Center
element
bandwidth Segment 0 subfield Frequency Segment Frequency Segment
Channel
1 subfield 2 subfield
Width field
20, 40 MHz 0 dot11CurrentChannelCenterFrequencyIndex0 0 0
80 MHz 1 dot11CurrentChannelCenterFrequencyIndex0 0 0
160 MHz 1 if dot11CurrentPrimaryChannel is greater dot11CurrentChanne 0
(At least than lCenterFrequencyIn
Max VHT dot11CurrentChannelCenterFrequencyIndex0 dex0
NSS then
support) dot11CurrentChannelCenterFrequencyIndex0
+ 8, else
dot11CurrentChannelCenterFrequencyIndex0
–8
160 MHz 1 if dot11CurrentPrimaryChannel is greater 0 dot11CurrentChanne
(Less than than lCenterFrequencyIn
Max VHT dot11CurrentChannelCenterFrequencyIndex0 dex0
NSS then
support) dot11CurrentChannelCenterFrequencyIndex0
+ 8, else
dot11CurrentChannelCenterFrequencyIndex0
–8
80+80 MHz 1 dot11CurrentChannelCenterFrequencyIndex0 dot11CurrentChanne 0
(At least lCenterFrequencyIn
Max VHT dex1
NSS
support)
80+80 MHz 1 dot11CurrentChannelCenterFrequencyIndex0 0 dot11CurrentChanne
(Less than lCenterFrequencyIn
Max VHT dex1
NSS
support)
160 MHz 2 dot11CurrentChannelCenterFrequencyIndex0 0 0
(deprecated)
80+80 MHz 3 dot11CurrentChannelCenterFrequencyIndex0 dot11CurrentChanne 0
(deprecated) lCenterFrequencyIn
dex1
NOTE 1—“At least Max VHT NSS support” means that the NSS support at 160 or 80+80 MHz is at least Max VHT NSS,
and therefore the secondary 80 or 160 MHz channel center frequency is signaled through CCFS1.
NOTE 2—“Less than Max VHT NSS support” means that the NSS support at 160 or 80+80 MHz is less than Max VHT
NSS, and therefore the secondary 80 or 160 MHz channel center frequency is signaled through CCFS2.
NOTE 3—For NSS support, see Table 9-75 and Table 9-250.
A VHT AP or a VHT mesh STA shall set the HT Operation element HT Operation Information field
Secondary Channel Offset subfield to indicate the secondary 20 MHz channel as defined in Table 9-168, if
the BSS bandwidth is more than 20 MHz.
A VHT STA that is a member of a VHT BSS shall not transmit a 20 MHz VHT PPDU on a channel other
than the primary 20 MHz channel, except for a 20 MHz VHT PPDU transmission on an off-channel TDLS
direct link as constrained by 11.23.6.5.2.
1898
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A VHT STA that is a member of a VHT BSS with a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz BSS
bandwidth shall not transmit a 40 MHz VHT PPDU that does not use the primary 40 MHz channel, except
for a 40 MHz VHT PPDU transmission on an off-channel TDLS direct link.
A VHT STA that is a member of a VHT BSS with an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth
shall not transmit an 80 MHz VHT PPDU that does not use the primary 80 MHz channel, except for an
80 MHz VHT PPDU transmission on an off-channel TDLS direct link.
A VHT STA that is a member of a VHT BSS with a 160 MHz or 80+80 MHz BSS bandwidth shall not
transmit a 160 MHz or 80+80 MHz VHT PPDU that does not use the primary 80 MHz channel and the
secondary 80 MHz channel, except for a 160 MHz or 80+80 MHz VHT PPDU transmission on an off-
channel TDLS direct link.
A VHT STA shall not transmit to a second VHT STA using a bandwidth that is not indicated as supported in
the Supported Channel Width Set subfield in the HT Capabilities element or in the VHT Capabilities
Information field of the VHT Capabilities element received from that VHT STA.
A STA shall not transmit an MPDU in a VHT PPDU to a STA that exceeds the maximum MPDU length
capability indicated in the VHT Capabilities element received from the recipient STA.
A VHT AP shall set the RIFS Mode field in the HT Operation element to 0.
VHT BSS operation with less than Max VHT NSS support is enabled as defined in Table 11-26 and disabled
otherwise, in which case the Channel Center Frequency Segment 2 subfield of the HT Operation element
shall be 0.
Table 11-26—Extended NSS channel width
HT Operation
VHT Operation VHT Operation
element STA HT Operation element Extended NSS
element Channel element CCFS1
Channel Width CCFS2 field channel width
Width field field
field
CCFS2 > 0 and
1 1 0 |CCFS2 – CCFS0| = 8 160 MHz
(40 MHz apart)
CCFS2 > 0 and
1 1 0 |CCFS2 - CCFS0| > 16 80+80 MHz
(> 80 MHz apart)
CCFS2 > 0 and
1 1 0 |CCFS2 – CCFS0| < 8 Reserved
(< 40 MHz apart)
CCFS2 > 0 and
8 < |CCFS2 – CCFS0| ≤ 16
1 1 0 Reserved
(> 40 MHz and ≤ 80 MHz
apart)
NOTE 1—CCFS0 represents the value of the Channel Center Frequency Segment 0 subfield of the VHT Operation
element.
NOTE 2—CCFS2 represents the value of the Channel Center Frequency Segment 2 subfield of the HT Operation
element.
1899
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When VHT BSS operation with less than Max VHT NSS support is enabled, the NSS support is
determined based on the Extended NSS channel width and the VHT Capabilities element per Table 9-250
and Table 9-75.
11.40.2 Channel selection methods for a VHT BSS
Before a STA starts a VHT BSS, the STA shall perform a minimum of dot11VHTOBSSScanCount OBSS
scan operations to search for existing BSSs (see 11.40.3).
If an AP or a mesh STA starts a VHT BSS that occupies some or all channels of any existing BSSs, the AP
or mesh STA may select a primary channel of the new VHT BSS that is identical to the primary channel of
any one of the existing BSSs.
If an AP or a mesh STA selects a primary channel for a new VHT BSS with a 40 MHz, 80 MHz, 160 MHz,
or 80+80 MHz BSS bandwidth from among the channels on which no beacons are detected during the
OBSS scans, then the selected primary channel meets the following conditions:
— It shall not be identical to the secondary 20 MHz channel of any existing BSSs with a 40 MHz,
80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth.
— It should not overlap with the secondary 40 MHz channel of any existing BSSs with a 80 MHz,
160 MHz or 80+80 MHz BSS bandwidth.
A STA that is an AP or mesh STA should not start a VHT BSS with a 20 MHz BSS bandwidth on a channel
that is the secondary 20 MHz channel of any existing BSSs with a 40 MHz, 80 MHz, 160 MHz, or
80+80 MHz BSS bandwidth, or is overlapped with the secondary 40 MHz channel of any existing BSSs
with a 160 MHz or 80+80 MHz BSS bandwidth.
NOTE—An AP or a mesh STA operating a VHT BSS with a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz BSS
bandwidth, on detecting an OBSS whose primary channel is the AP’s or the mesh STA’s secondary 20 MHz channel,
might switch to 20 MHz BSS operation and/or move to a different channel.
11.40.3 Scanning requirements for VHT STA
An OBSS scan operation is a passive or active scan of a set of channels that are potentially affected by VHT
BSS operation (see 11.1.4.1). Each channel in the set may be scanned more than once during a single OBSS
scan operation. OBSS scans are performed by STAs that start a VHT BSS.
During an individual scan within an OBSS scan operation, the minimum per-channel scan duration is
dot11OBSSScanPassiveDwell TUs (for a passive scan) or dot11OBSSScanActiveDwell TUs (for an active
scan). During an OBSS scan operation, each channel in the set is scanned at least once per
dot11BSSWidthTriggerScanInterval seconds, and the minimum total scan time (i.e., the sum of the scan
durations) per channel within a single OBSS scan operation is dot11OBSSScanPassiveTotalPerChannel
TUs (for a passive scan) or dot11OBSSScanActiveTotalPerChannel TUs (for an active scan).
NOTE—The values provided in the previous paragraph are minimum requirements. For some combinations of
parameter values the minimum might be exceeded for some parameters in order to meet the minimum value constraints
of other parameters.
11.40.4 Channel switching methods for a VHT BSS
A VHT AP announces a switch of operating channel by either of the following:
— Using the Channel Switch Announcement element, Channel Switch Announcement frame, or both,
following the procedure described in 11.9.8.2
— Using the Extended Channel Switch Announcement element, Extended Channel Switch
Announcement frame, or both, following the procedure described in 11.10
1900
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A VHT mesh STA announces a switch attempt of operating channel by either of the following:
— Using the Channel Switch Announcement element, Channel Switch Announcement frame, or both,
following the procedure described in 11.9.8.4
— Using the Extended Channel Switch Announcement element, Extended Channel Switch
Announcement frame, or both, following the procedure described in 11.10
A VHT AP or a VHT mesh STA may also announce a switch of BSS bandwidth, a new Country String field
(possibly including a new Operating Class table number), new operating classes, or new TPC parameters for
the BSS that come into effect at the same time as the switch of operating channel.
The New Channel Number field in the Channel Switch Announcement element, Extended Channel Switch
Announcement element, Channel Switch Announcement frame, or Extended Channel Switch
Announcement frame identifies the primary 20 MHz channel after the switch. The value of the New
Channel Number field is set to the value that dot11CurrentPrimaryChannel (see 21.3.14) will have after the
switch.
If a Channel Switch Announcement frame is used to announce a switch to a 20 MHz BSS bandwidth, then
neither a Wide Bandwidth Channel Switch element nor a Secondary Channel Offset element shall be present
in the frame, except that a Secondary Channel Offset element may be present in a Channel Switch
Announcement frame if the Secondary Channel Offset field within the Secondary Channel Offset element is
set to SCN.
If a Channel Switch Announcement element is used to announce a switch to a 20 MHz BSS bandwidth, then
a Wide Bandwidth Channel Switch subelement in a Channel Switch Wrapper element shall not be present in
the same frame.
If an Extended Channel Switch Announcement element in a Beacon or Probe Response frame or an
Extended Channel Switch Announcement frame is used to announce a switch to a 20 MHz BSS bandwidth,
then neither a Wide Bandwidth Channel Switch element nor a Wide Bandwidth Channel Switch subelement
shall be present in the same frame.
NOTE—A Secondary Channel Offset element is never present with the Extended Channel Switch Announcement
element or in the Extended Channel Switch Announcement frame. Instead, the indicated operating class within the
Extended Channel Switch Announcement element or frame is used to differentiate between a BSS BSS bandwidth of
20 MHz and a BSS bandwidth greater than 20 MHz as well as indicate the location of the secondary 20 MHz channel.
For a switch to a 20 MHz BSS bandwidth, the operating class indicated within the Extended Channel Switch
Announcement element or frame has a channel spacing of 20 MHz. For a switch to an BSS bandwidth greater than
20 MHz, the operating class indicated within the Extended Channel Switch Announcement element or frame has a
channel spacing of 40 MHz.
If a Channel Switch Announcement frame is used to announce a switch to a 40 MHz BSS bandwidth, then
the following apply:
— The Secondary Channel Offset element shall be present in the frame.
— The Wide Bandwidth Channel Switch shall not be present in the frame.
If a Channel Switch Announcement element in a Beacon or Probe Response frame is used to announce a
switch to a 40 MHz BSS bandwidth, then the Wide Bandwidth Channel Switch subelement in the Channel
Switch Wrapper element shall also be present in the same frame.
If an Extended Channel Switch Announcement element in a Beacon or Probe Response frame is used to
announce a switch to a 40 MHz BSS bandwidth, then the Wide Bandwidth Channel Switch subelement in
the Channel Switch Wrapper element may be present in the same frame.
1901
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—The indicated operating class within the Extended Channel Switch Announcement element identifies the
bandwidth and the relative position of the primary 20 MHz and secondary 20 MHz channels. Hence a Wide Bandwidth
Channel Switch subelement is unnecessary when the Extended Channel Switch Announcement element is used for a
channel switch to a 40 MHz bandwidth.
If a Channel Switch Announcement frame is used to announce a switch to an 80 MHz, 80+80 MHz, or
160 MHz BSS bandwidth, then both the Secondary Channel Offset element and the Wide Bandwidth
Channel Switch element shall be present in the frame.
If a Channel Switch Announcement element or an Extended Channel Switch Announcement element is used
to announce a switch to an 80 MHz, 80+80 MHz, or 160 MHz BSS bandwidth, then a Wide Bandwidth
Channel Switch subelement in the Channel Switch Wrapper element shall be present in the same frame.
If an Extended Channel Switch Announcement frame is used to announce a switch to an 80 MHz,
80+80 MHz, or 160 MHz BSS bandwidth, then the Wide Bandwidth Channel Switch element shall be
present in the frame.
If an Extended Channel Switch Announcement element or Extended Channel Switch Announcement frame
is used to announce a switch to an 80 MHz, 80+80 MHz, or 160 MHz BSS BSS bandwidth, then
— The value of the New Operating Class field identifies the primary 40 MHz channel, and
— The Operating Triplet fields within the New Country subelement or element, respectively, shall
indicate all of the operating classes for the switched BSS.
If new BSS TPC parameters are announced that come into effect at the same time as the channel switch, then
if an AP, IBSS STA or mesh STA is extended spectrum management capable, it shall include
— At least one New Transmit Power Envelope element in a transmitted Channel Switch
Announcement frame or Extended Channel Switch Announcement frame and
— At least one New Transmit Power Envelope subelement in a transmitted Channel Wrapper element
in Beacon and Probe Response frames.
A recipient STA in the BSS that is extended spectrum management capable and that has
dot11SpectrumManagementRequired or dot11RadioMeasurementActivated equal to true and that maintains
association with the BSS after the switch shall use the parameters in these received elements and
subelements in the recipient STA’s TPC calculations for the new operating channel and BSS bandwidth (see
11.8). If both New Transmit Power Envelope elements and New Transmit Power Envelope subelements are
transmitted for the switch, the set of New Transmit Power Envelope elements and set of subelements shall
contain the same set of values for the Local Maximum Transmit Power Unit Interpretation subfield, and
New Transmit Power Envelope elements and subelements that have the same value of the Local Maximum
Transmit Power Unit Interpretation subfield shall also have the same values for their other fields.
If a new country string, new operating classes or both, are coming into effect at the same time as the channel
switch, then if an AP, IBSS STA or mesh STA is extended spectrum management capable, it shall include
— A New Country element in a transmitted Extended Channel Switch Announcement frame and
— A New Country subelement in a transmitted Channel Wrapper element.
The New Country element or subelement shall contain all of the Operating Classes for the BSS after the
switch. The New Country element or subelement, transmitted in an Extended Channel Switch
Announcement frame or in the same frame as an Extended Channel Switch Announcement element,
respectively, shall include one Operating Triplet field that contains the same Operating Class as the New
Operating Class field in the Extended Channel Switch Announcement frame or Extended Channel Switch
Announcement element. A recipient STA in the BSS that is extended spectrum management capable and
that has dot11MultiDomainCapabilityActivated, dot11SpectrumManagementRequired, or
dot11RadioMeasurementActivated equal to true and that maintains association with the BSS after the switch
1902
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
shall use the parameters in these received elements and subelements in order to maintain regulatory
compliance. If both New Country elements and New Country subelements are transmitted for the switch,
their fields shall be the same.
A Channel Switch Wrapper element shall not be included in Beacon or Probe Response frames if the
element contains zero subelements.
NOTE—Channel Switch Wrapper is not defined to carry subelements in the case of a switch to 20 MHz and when no
change to the country string, operating classes or TPC parameters are announced.
A VHT STA uses only the Transmit Power Envelope element, not the Power Constraint element, for TPC of
80 MHz, 160 MHz, and 80+80 MHz transmissions. In the Country element, a VHT STA shall include zero
Subband Triplet fields in an Operating/Subband Sequence field that contains an Operating Class field for
which the “Channel Spacing (MHz)” column in the applicable table in Annex E equals 80 or 160.
An AP that switches the BSS to a lower BSS bandwidth may recalculate the TS bandwidth budget and may
delete one or more active TSs by invoking the MLME-DELTS.request primitive with a ReasonCode value
of SERVICE_CHANGE_PRECLUDES_TS.
A VHT STA that is a member of an IBSS shall not transmit values in the Wide Bandwidth Channel Switch
element that change the frequency ordering of the primary 40 MHz channel and the secondary 40 MHz
channel from the ordering of the most recently adopted operating channel, if the operating channel includes
a secondary 40 MHz channel. A VHT STA that is a member of an IBSS shall not transmit values in the
Wide Bandwidth Channel Switch element that change the frequency ordering of the primary 80 MHz
channel and the secondary 80 MHz channel from the ordering of the most recently adopted operating
channel, if the operating channel includes a secondary 80 MHz channel.
11.40.5 NAV assertion in a VHT BSS
A VHT STA shall update its NAV as described in 10.3.2.4 using the Duration/ID field value in any frame
that does not have an RA matching the STA’s MAC address and that was received in a 20 MHz PPDU in the
primary 20 MHz channel or received in a 40 MHz PPDU in the primary 40 MHz channel or received in an
80 MHz PPDU in the primary 80 MHz channel or received in a 160 MHz or 80+80 MHz PPDU.
NOTE—The PHY might filter out a PPDU as described in 21.3.20 or not receive a PPDU due to VHT TXOP power
saving described in 11.2.3.19. If so, frames in the PPDU are not received by the MAC and have no effect on the NAV.
11.40.6 VHT STA antenna indication
A VHT STA that does not change its Rx antenna pattern after association shall set the Rx Antenna Pattern
Consistency subfield in the VHT Capabilities Information field to 1; otherwise, the STA shall set the Rx
Antenna Pattern Consistency subfield in the VHT Capabilities Information field to 0.
A VHT STA that does not change its Tx antenna pattern after association shall set the Tx Antenna Pattern
Consistency subfield in the VHT Capabilities Information field to 1; otherwise, the STA shall set the Tx
Antenna Pattern Consistency subfield in the VHT Capabilities Information field to 0.
11.40.7 Basic VHT-MCS and NSS set operation
The basic VHT-MCS and NSS set is the set of tuples that are supported by all VHT
STAs that are members of a VHT BSS. It is established by the STA that starts the VHT BSS, indicated by
the Basic VHT-MCS And NSS Set field of the VHT Operation parameter in the MLME-START.request
primitive. Other VHT STAs determine the basic VHT-MCS and NSS set from the Basic VHT-MCS And
NSS Set field of the VHT Operation element in the BSSDescription derived through the scan mechanism
(see 11.1.4.1).
1903
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A VHT STA shall not attempt to join (MLME-JOIN.request primitive) a BSS unless it supports (i.e., is able
to both transmit and receive using) all of the tuples in the basic VHT-MCS and NSS set.
NOTE—A VHT STA does not attempt to (re)associate with a VHT AP unless the STA supports (i.e., is able to both
transmit and receive using) all of the tuples in the Basic VHT-MCS And NSS Set field in the VHT
Operation element transmitted by the AP because the MLME-JOIN.request primitive is a necessary precursor to
(re)association.
11.40.8 Extended NSS BW Support Signaling
If dot11VHTExtendedNSSBWCapable is false, a STA shall set the Extended NSS BW Support subfield of
the VHT Capabilities Information field to 0 in VHT Capability elements that it transmits, otherwise, the
subfield may be set to 1, 2 or 3 as indicated in 9.4.2.158.2.
If dot11VHTExtendedNSSBWCapable is false, a STA shall set the VHT Extended NSS BW Capable
subfield of the Supported VHT-MCS and NSS Set field to 0 in VHT Capability elements that it transmits,
otherwise, the subfield shall be set to 1.
11.41 Group ID management operation
An AP determines the possible combinations of STAs that can be addressed by a VHT MU PPDU by
assigning STAs to groups and to specific user positions within those groups.
Assignments or changes of user positions corresponding to one or more Group IDs shall be performed using
a Group ID Management frame defined in 9.6.23.3.
A STA may be assigned to multiple groups by setting multiple subfields of the Membership Status Array
field (see 9.4.1.54) to 1 in the Group ID Management frame addressed to that STA.
A STA’s user position in each group of which the STA is a member is indicated by the associated subfield in
the User Position Array field (see 9.4.1.55) in the Group ID Management frame addressed to the STA. For
each Group ID, an AP may assign the same user position to multiple STAs. A STA shall have only one user
position in each group of which the STA is a member.
An AP may transmit a Group ID Management frame only if dot11VHTOptionImplemented is true. A Group
ID Management frame shall not be sent to a VHT STA that does not have the MU Beamformee Capable
field in the VHT Capabilities element equal to 1.
A Group ID Management frame shall be sent as an individually addressed frame.
A STA’s MLME that receives a Group ID Management frame with a RA matching its MAC address shall
issue a PHYCONFIG_VECTOR primitive with the GROUP_ID_MANAGEMENT parameter based on the
content of the received Group ID Management frame in order to configure the following lookup tables in the
PHY:
a) group ID to Membership Status, denoted by MembershipStatusInGroupID[g] for 1 g 62
b) group ID to User Position, denoted by UserPositionInGroupID[g] for 1 g 62
Group ID values of 0 and 63 are used for SU PPDU and the PHY filtering of such PPDUs is controlled by
the PHYCONFIG_VECTOR primitive LISTEN_TO_GID00 and LISTEN_TO_GID63 parameters. The
User Position in Group ID information is interpreted by a STA receiving a VHT MU PPDU as explained in
21.3.11.4.
Transmission of a Group ID Management frame to a STA and any associated acknowledgment from the
STA shall complete before the transmission of a VHT MU PPDU to the STA.
1904
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A VHT MU PPDU shall be transmitted to a STA based on the content of the Group ID Management frame
most recently transmitted to the STA and for which an acknowledgment was received.
11.42 Notification of operating mode changes
A STA in which dot11OperatingModeNotificationImplemented is true shall set the Operating Mode
Notification field in the Extended Capabilities element to 1. A VHT STA shall set
dot11OperatingModeNotificationImplemented to true. A STA in which
dot11OperatingModeNotificationImplemented is true is referred to as operating mode notification capable.
A STA that is operating mode notification capable and that transmits an Association Request, Reassociation
Request, TDLS Setup Response, TDLS Setup Confirm, Mesh Peering Open, or Mesh Peering Confirm
frame to a STA that is operating mode notification capable should notify the recipient STA of a change in its
operating mode by including the Operating Mode Notification element in the frame.
A first STA that is operating mode notification capable should notify a second STA that is operating mode
notification capable of a change in its operating mode by transmitting an Operating Mode Notification frame
to the second STA if the first STA has established any of the following with a second STA:
— An association with an AP
— A TDLS link
— A DLS link
— A Mesh Peer relationship
NOTE—Notify Channel Width frames and elements are used to signal STA operating channel width changes to and
from STAs that are not operating mode notification capable.
The Operating Mode field in the Operating Mode Notification frame or the Operating Mode Notification
element together with the Supported Channel Width set field and the Extended NSS BW Support field of the
VHT Capabilities element indicates the transmitting STA’s receive bandwidth and NSS capabilities. See
10.7.12.1.
The notification of a change in supported spatial streams should occur prior to a decrease in the maximum
number of spatial streams and following an increase in the maximum number of spatial streams.
The notification of a change in operating bandwidth should occur prior to a decrease in the operating
channel width and following an increase in the operating channel width.
A STA shall not transmit an individually addressed frame that contains the Operating Mode field unless the
recipient is operating mode notification capable.
An AP should notify associated STAs of a change in the maximum number of spatial streams it is able to
receive through one or more of the following mechanisms:
— Using individually addressed Operating Mode Notification frames
— Including the Operating Mode Notification element in Beacon frames for a period of time to allow
STAs in PS mode to receive the notification
NOTE—An AP cannot change the maximum number of spatial streams it is able to receive from HT STAs that are not
operating mode notification capable.
The notification should occur prior to a decrease in the maximum number of spatial streams and following
an increase in the maximum number of spatial streams.
1905
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An AP should notify associated STAs of a change in its operating channel width through one or more of the
following mechanisms:
— Using the Channel Switch Announcement element, Channel Switch Announcement frame or both
following the procedure defined in 11.9.8.2
— Using the Extended Channel Switch Announcement element, Extended Channel Switch
Announcement frame or both, following the procedure described in 11.10
— Using individually addressed Operating Mode Notification frames and/or Notify Channel Width
frames
— Using the STA Channel Width field in the HT Operation element and/or Channel Width field in the
VHT Operation element
The notification should occur prior to a decrease in the operating channel width and following an increase in
the operating channel width.
A VHT AP that has at least one VHT STA associated and that indicates a channel width change using
management action frame(s) shall transmit Operating Mode Notification frame(s) to signal the channel
width change. A VHT AP that has at least one non-VHT HT STA associated and that indicates a channel
width change using management action frame(s) shall transmit Notify Channel Width frame(s) to signal the
channel width change.
A VHT STA shall not transmit an individually addressed Notify Channel Width frame to a VHT STA.
A VHT STA associated with a VHT AP shall ignore Notify Channel Width frames received from the VHT
AP.
An HT AP that is not a VHT AP that changes its operating channel width shall indicate the new operating
channel width in the STA Channel Width field in the HT Operation element. A VHT AP that changes its
operating channel width shall indicate the new operating channel width in the Channel Width field in the
VHT Operation element and STA Channel Width field in the HT Operation element (see Table 11-24).
An AP shall not include the Operating Mode Notification element in Beacon, Probe Response, Association
Response, and Reassociation Response frames when not changing the maximum number of spatial streams
the AP is able to receive.
A STA shall not transmit an Operating Mode field with the value of the Rx NSS subfield indicating a
number of spatial streams not supported by the recipient STA. The number of spatial streams supported by
the recipient STA is reported in the Supported Rates and BSS Membership Selectors element, Extended
Supported Rates and BSS Membership Selectors element, Supported MCS Set, or Supported VHT-MCS
and NSS Set field transmitted in Management frames by the recipient STA.
A STA shall not transmit an Operating Mode field with the value of the Channel Width subfield indicating a
bandwidth not supported by the STA, as reported in the Supported Channel Width Set subfield in the HT
Capability Information field or in the VHT Capabilities Information field in Management frames transmitted
by the STA.
A STA that is operating mode notification capable shall not transmit a PPDU to a STA that uses a bandwidth
that is greater than the channel width indicated in the most recently received Operating Mode Notification
element or Operating Mode Notification frame from that STA. A STA that is operating mode notification
capable shall not transmit a PPDU to a STA that uses a greater number of spatial streams than indicated in
the most recently received Operating Mode Notification element or Operating Mode Notification frame
received from that STA.
NOTE 1—The number of spatial streams might be further restricted if the receiving STA is in SM power save mode (see
11.2.6).
1906
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 2—To avoid possible frame loss, a VHT STA that sends an individually addressed Operating Mode Notification
frame to a second VHT STA indicating reduced operating channel width and/or reduced active receive chains can
continue with its current operating channel width and active receive chains until it infers that the second STA has
processed this notification. The first VHT STA might make this inference from either of the following:
— By receiving a frame addressed to itself from the second VHT STA in a PPDU with a bandwidth and NSS that
are less than or equal to the channel width and NSS, respectively, indicated in the Operating Mode Notification
frame
— Based on the passage of time in some implementation dependent way, which is outside the scope of this
standard
NOTE 3—It might take a long time for a STA to change its operating mode following the transmission of the Operating
Mode Notification frame and during that time the STA might not be able to receive frames resulting in frame loss. If a
non-AP STA cannot tolerate frame loss during that period it can set the Power Management subfield of the Frame
Control field of the Operating Mode Notification frame to 1 to indicate that the STA has entered power save. When the
non-AP STA has completed its operating mode change, it can send another frame (such as a QoS Null) with the Frame
Control Power Management subfield set to 0 to indicate that the STA has exited power save.
11.43 Basic TVHT BSS functionality
The STA that is creating a TVHT BSS shall be able to receive and transmit at each of the tuple values indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter of
the MLME-START.request primitive and shall be able to receive at each of the tuple
values indicated by the Supported VHT-MCS and NSS Set field of the VHT Capabilities parameter of the
MLME-START.request primitive. A STA for which dot11TVHTOptionImplemented is true shall set
dot11VHTOptionImplemented to true.
A TVHT AP declares its channel width capability in the VHT Capabilities element VHT Capabilities
Information field, as defined in 9.4.2.158.
A TVHT AP shall set the Channel Width subfield in the TVHT Operation Information field to indicate the
BSS bandwidth and transmitted PPDU type as defined in Table 11-27.
Table 11-27—TVHT BSS bandwidth
TVHT Operation
element Channel Width BSS bandwidth PPDU type
field
0 TVHT_W TVHT_MODE_1
1 TVHT_2W TVHT_MODE_1
TVHT_MODE_2C
2 TVHT_W+W TVHT_MODE_1
TVHT_MODE_2N
3 TVHT_4W TVHT_MODE_1
TVHT_MODE_2C
TVHT_MODE_4C
4 TVHT_2W+2W TVHT_MODE_1
TVHT_MODE_2C
TVHT_MODE_4N
1907
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A TVHT non-AP STA that receives a frame containing a TVHT Operation element shall determine the
channelization based on the Channel Center Frequency Segment0, Channel Center Frequency Segment1,
and Primary Channel Number subfields of the TVHT Operation Information field (see 22.3.14).
A TVHT STA that is a member of a TVHT BSS shall transmit a TVHT_MODE_1 PPDU only on the
primary TVHT_W channel, except for a TVHT_MODE_1 PPDU transmission on an off-channel TDLS
direct link.
A TVHT STA that is a member of a TVHT BSS with a TVHT_2W, TVHT_4W, or TVHT_W+W BSS
bandwidth shall not transmit a TVHT_MODE_2C or TVHT_MODE_2N PPDU that does not use the
primary TVHT_W channel and the secondary TVHT_W channel, except for a TVHT_MODE_2C,
TVHT_MODE_4C, or TVHT_MODE_2N PPDU transmission on an off-channel TDLS direct link.
A TVHT STA that is a member of a TVHT BSS with a TVHT_4W or TVHT_2W+2W BSS bandwidth shall
not transmit a TVHT_MODE_4C or TVHT_MODE_4N PPDU that does not use the primary TVHT_2W
channel and the secondary TVHT_2W channel, except for a TVHT_MODE_4C or TVHT_MODE_4N
PPDU transmission on an off-channel TDLS direct link.
A TVHT STA shall not transmit to a TVHT STA using a bandwidth that is not indicated as supported in the
VHT Capabilities element or Operating Mode Notification frame recently received from that TVHT STA.
In a TVHT BSS, the primary TVHT_W channel is the primary channel.
11.44 Operation under the control of a GDB
11.44.1 General
When a STA implements support for one or more of the procedures described in this subclause, it shall set
dot11TVHTOptionImplemented to true. When dot11TVHTOptionImplemented is true and a STA is
initialized for operation in a band that requires GDB control, then dot11GDDActivated shall be true.
In some regulatory domains, STAs shall consult a GDB to determine permissible operating frequencies and
parameters before transmitting. Such STAs may operate as geolocation database dependent (GDD) enabling
STAs, which are required by regulation to provide their identification, geolocation, and other information to
the GDB as specified by regulatory authorities. Other STAs are permitted to transmit when enabled by a
GDD enabling STA. Such STAs operate as GDD dependent STAs.
Subclause 11.44 describes procedures for STAs when they are operating under the control of a GDB to
satisfy regulatory requirements. For operation under such restrictions, GDD dependent STAs operate
according to the control procedures of a GDD enabling STA that enables their operation. The frame
exchange sequence between GDD enabling STA and GDD dependent STAs for enabling their operation
occurs in State 4 (see 11.3.1).
A GDD enabling STA is a STA that is able to access a GDB and to obtain the information about the
permitted frequencies and other information for use in its location. A GDD enabling STA or geolocated non-
AP STA populates its dot11STALCITable with location information by a means that has received regulatory
approval and is outside the scope of this standard. When location information is set in dot11STALCITable,
1908
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the STA sets dot11GeolocationCapabilityActivated. The current dot11STALCITable allows management
access to the location information that is the basis for operation. A GDD enabling STA may transmit a GDD
enabling signal and may enable operations of GDD dependent STAs.
A GDD dependent STA is a STA that is under the control of a GDD enabling STA.
The GDD enablement procedure for GDD dependent STAs and the operating rules for GDD enabling and
GDD dependent STAs are defined in the following subclauses.
11.44.2 GDD enabling STA operation
A GDD enabling STA may transmit a GDD enabling signal in-band on an available frequency to indicate
that it offers GDD enablement service.
The GDD enabling signal is a Beacon frame with an Extended Capabilities element that contains a
Geodatabase Inband Enabling Signal field with a value of ‘1’. A GDD dependent STA shall not transmit any
frames before it receives a GDD enabling signal over the air directly from a GDD enabling STA.
In some regulatory domains the GDD enabling STA may be required to have secure authentication or
association with the GDD dependent STA before it sends the GDD Enablement Response frame. If required
by regulation, the GDD enabling STA may contact a GDB to verify that the requesting GDD dependent STA
is authorized to operate in the frequency band.
Upon receipt of a GDD Enablement Request frame from a GDD dependent STA, the GDD enabling STA
sends a GDD Enablement Response frame with either of the following results:
a) The Status Code field set to SUCCESS to indicate the successful enablement of the requesting GDD
dependent STA
b) The Status Code field set to ENABLEMENT DENIED or INVALID_PARAMETERS or
RESTRICTION FROM AUTHORIZED GDB, in which case the GDD enablement request has been
denied
A GDD enabling STA may issue an unsolicited GDD Enablement Response frame with a Status Code
AUTHORIZATION DEENABLED to notify a GDD dependent STA to cease its transmissions and change
its GDD enablement state to Unenabled. When an unsolicited GDD Enablement Response frame with a
Status Code AUTHORIZATION DEENABLED is transmitted, the WSM element is not included.
11.44.3 GDD dependent STA operation
A GDD dependent STA is configured with a GDD enablement state variable which is set to one of the
following three states: Unenabled, AttemptingGDDEnablement, or GDDEnabled. A GDD dependent STA
begins operation by setting its GDD enablement state variable to Unenabled and operates in receive-only
mode within the band, passively scanning channels for a GDD enabling signal from a GDD enabling STA.
A typical state machine implementation of GDD dependent STA operation under GDD is provided in
Figure 11-53.
1909
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Unenabled
Receive GDD enabling signal and Wait for
transmit GDD Enablement Request frame dot11GDDEnablementFailHoldTime
Receive GDD Enablement Response frame with Status
AttemptingGDDEnablement ENABLEMENT DENIED, RESTRICTION FROM AUTHORIZED GDB,
INVALID_PARAMETERS, or otherwise failed enablement attempt within
dot11GDDEnablementTimeLimit
Receive GDD Enablement
Response frame with Status
Code SUCCESS
Receive GDD Enablement Response frame with
Status Code AUTHORIZATION DEENABLED
dot11GDDEnablementValidityTimer has expired
GDDEnabled
Figure 11-53—GDD dependent STA state transition diagram
A GDD dependent STA shall not transmit any frames unless it has received a valid GDD enabling signal
from a GDD enabling STA.
A GDD dependent STA that is able to receive a valid GDD enabling signal, but has not been enabled by a
GDD enabling STA shall not transmit, except to perform GDD enablement with a GDD enabling STA
transmitting the GDD enabling signal.
A GDD dependent STA shall not transmit any frames other than GDD enablement-related frames and
authentication and association frames before it performs the following GDD enablement procedure:
a) The GDD dependent STA changes its GDD enablement state variable to
AttemptingGDDEnablement after receiving a GDD enabling signal.
b) After authentication and association, the GDD dependent STA securely sends a GDD Enablement
Request frame to a GDD enabling STA from which it has received a GDD enabling signal. Based on
the input received from the GDD dependent STA, the GDD enabling STA responds with a GDD
Enablement Response frame indicating the result for the enablement request.
c) When a GDD dependent STA receives a GDD Enablement Response frame with the Status Code
SUCCESS within dot11GDDEnablementTimeLimit, the GDD enablement state variable of the
GDD dependent STA is set to GDDEnabled. Once it becomes enabled, the GDD dependent STA
maintains a GDD enablement validity timer, which is initialized to
dot11ContactVerificationSignalInterval.
1910
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A GDD dependent STA that has not attained GDD enablement from a GDD enabling STA shall not transmit
beyond dot11GDDEnablementTimeLimit, measured from the time of the first PHY-TXSTART.request
primitive, while attempting to attain GDD enablement. Then, when the GDD enablement attempt fails
within the allowed maximum time, it shall not transmit for dot11GDDEnablementFailHoldTime, before it
may again attempt to attain GDD enablement.
NOTE—A GDD dependent STA might detect several GDD enabling STAs. If the GDD dependent STA is unable to
obtain a GDD Enablement Response frame from one GDD enabling STA, it might make further attempts with additional
GDD enabling STAs within the maximum time limit of dot11GDDEnablementTimeLimit.
Once in GDDEnabled state, the following rules apply to a GDD dependent STA during its operations:
— The GDD dependent STA shall maintain a GDD enablement validity timer by decrementing
dot11GDDEnablementValidityTimer. The procedures for maintaining the GDD enablement validity
timer are defined in 11.44.9, 11.44.6, and 11.44.4.
— A GDD dependent STA shall cease all transmission when the dot11GDDEnablementValidityTimer
has expired. It then changes its GDD enablement state to Unenabled.
— A GDD dependent STA shall immediately cease all transmission if it receives an unsolicited GDD
Enablement Response frame with a Status Code of AUTHORIZATION DEENABLED from the
GDD enabling STA that enabled its operation.
11.44.4 Channel availability query (CAQ) procedure
11.44.4.1 Introduction
This subclause describes a channel availability query procedure that can be used to obtain the list of
available channels for the operation of a GDD STA. A STA shall not use the CAQ procedure specified here
unless dot11GDDActivated is true.
A GDD dependent STA sends the channel availability query request to a GDD enabling STA to obtain the
list of available channels. The CAQ procedure might be initiated by the GDD dependent STA in order to
remain in the GDDEnabled state during its normal operational mode, as specified in 11.44.3.
The GDD dependent STA sends the Channel Availability Query frame to obtain the new channel
availability information when it receives an indication of change in the available channel list for its use, such
as from a recent CVS signal (see 11.44.6).
Once the GDD dependent STA successfully receives the response for its Channel Availability Query frame
from the GDD enabling STA, it reinitializes the dot11GDDEnablementValidityTimer to
dot11ContactVerificationSignalInterval.
A GDD STA that acquires its geolocation position with the accuracy required by the regulatory domain sets
dot11GeolocationCapabilityActivated to true. Any STA that operates as a GDD enabling STA might have
its geolocation position before it initiates the CAQ procedure. Such a STA might transmit a channel
availability query request to another GDD enabling STA. The responding STA generates the CAQ response
after communicating to the RLSS, if the Channel Availability Query frame was received in a Channel
Availability Query RLQP-element.
NOTE—A GDD enabling STA can send the Channel Availability Query frame to another GDD enabling STA. The
responding GDD enabling STA, in such a case, can contact a GDB with the location and identifying parameters sent by
the requesting STA.
A GDD enabling STA performs the CAQ procedure to update its channel availability when it determines
that its geolocation position has moved beyond the permitted distance or beyond the validity time since its
last query, as required by regulation.
1911
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STAs might transmit a channel availability query request in the protected dual of a CAQ Public Action
frame (see 9.6.8.25, or in a GAS Initial Request frame containing an Channel Availability Query RLQP-
element (see 9.4.6.2).
The procedures for channel availability query requesting STA and channel availability query responding
STA are specified in 11.44.4.2 and 11.44.4.3.
In some regulatory domains, CAQ procedures may be conducted in other bands with properly implemented
security to meet regulatory requirements. In such cases, CAQ RLQP rather than CAQ protected duals of
Public Action frames shall be used.
11.44.4.2 CAQ requesting STA
A GDD dependent STA or a GDD enabling STA may initiate a CAQ procedure as a CAQ requesting STA.
A CAQ requesting STA may use RLQP to transmit a CAQ request when it detects RLQP support by its
intended CAQ responder in a Beacon or Probe Response frame and to transmit a CAQ request to a STA with
which it is associated when the requesting STA detects RLQP support.
Upon receipt of the MLME-GAS.request primitive with an AdvertisementProtocolID value of RLQP and
Query parameters with the values of the fields in the RLQP Channel Availability Query element, the
requesting STA performs the procedure specified in 11.25.3.2.2 to transmit a GAS Initial Request frame that
contains the Channel Availability Query RLQP-element. The specific information items in the Query
Request field of the GAS Initial Request frame are defined in 9.4.6.2.
The CAQ requesting STA may send the protected dual of a Channel Availability Query frame where the
CAQ responding STA does not support RLQP capability. Upon receipt of the MLME-
CHANNELAVAILABILITYQUERY.request primitive with Reason Result Code of 1, the MLME
schedules for transmission a Channel Availability Query frame. The specific information items in the
protected dual of a CAQ Public Action are defined in 9.6.8.25.
The CAQ requesting STA sets the Reason Result Code field to 1 and provides the Query Info field, as
shown in Figure 9-631, to indicate if the Device Identification or Location Information fields are included in
the Channel Availability Query frame.
A GDD enabling STA sending the Channel Availability Query frame should provide its device identification
information in a format specified in 9.4.4.2.2.
A GDD enabling STA with dot11GeolocationCapabilityActivated equal to true should provide one or more
Location Information fields in its Channel Availability Query frame.
A CAQ requesting STA may request a common channel list applicable to a bounded geographic area by
providing more than one Device Location Information field in the Channel Availability Query frame. The
bounded geographic area is defined by the area surrounded by the given sets of geographic coordinates in
the multiple Device Location Information fields.
11.44.4.3 CAQ responding STA
A GDD enabling STA that receives the Channel Availability Query frame performs the role of the CAQ
responding STA.
1912
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When a GDD enabling STA that has dot11RLSSActivated true receives a Channel Availability Query
RLQP-element request, it generates and transmits the Channel Availability Query RLQP-element response
to the requesting STA. Upon receipt of the MLME-GAS.response primitive with ResponseInfo parameter
having a value of the corresponding field in the CAQ element, the responding STA transmits a Channel
Availability Query RLQP-element response.
The CAQ responding STA generates the response to the CAQ requesting STA based on the result obtained
from the RLSS. The specific information items in the Channel Availability Query RLQP-element response
are defined in 9.4.6.2 and are set as follows:
— Requester STA Address field set to the MAC address of the STA from which the query was
received.
— If no security method is enabled on the connection between the CAQ requesting STA and the CAQ
responding STA, the Reason Result Code field is set to 4 (REFUSED).
— Reason Result Code field set to 2 or 3 for successful result or to 4 or 5 for failure, as defined in
9.4.6.2.
— WSM Information field, as defined in 9.4.4.2.5 when the Reason Result Code is set to 2 or 3.
NOTE—For the CAQ process, the RLSS provides the list of available channels for the location(s) provided by the
requesting STA in the Query Response. In some regulatory domains, the RLSS can perform access to a GDB to derive
its response for channel query request and the associated information it provides in its Query Response.
A CAQ responding STA might receive a Channel Availability Query frame or its protected dual. Upon
receipt of the MLME-CHANNELAVAILABILITYQUERY.response primitive, the MLME schedules for
transmission of the response in a Channel Availability Query frame. The Channel Availability Query frame
or its protected dual is generated based on the ResultCode and other parameters received from the SME for
the Channel Availability Query frame, as follows:
— Requester STA Address field set to the value of the PeerSTAAddress parameter.
— If no security method is enabled on the connection between the CAQ framing STA and the CAQ
responding STA, the Reason Result Code field is set to 4 (REFUSED).
— Reason Result Code field set to 2 or 3 for successful result or to 4 or 5 for failure, as defined in
9.4.6.2.
— WSM Information field, as defined in 9.4.4.2.5 when the Reason Result Code is set to 2 or 3.
When a CAQ Responding STA receives the Channel Availability Query frame from a GDD dependent
STA, it sets the Reason Result Code field to 2 when the query is successful and provides the WSM
information it has obtained for its own location.
When a CAQ Responding STA receives the Channel Availability Query frame from another GDD enabling
STA that includes one or more Device Location Information fields in the Channel Availability Query frame,
it sets the Reason Result Code field to 2 or 3 when the query is successful and provides the WSM
information that is valid for the location of the requesting STA.
When the Channel Availability Query frame contains multiple Device Location Information fields, the
WSM information in the CAQ response is applicable for any location within the bounded area defined by
the multiple locations. When the Channel Availability Query frame contains two Device Location
Information fields, the WSM information in the CAQ response is applicable for any location within the
bounded area determined by the uncertainty values of the coordinates of the second Device Location
Information field. If no common channels are available to the bounded geographic area defined by multiple
locations, CAQ responding STA responds with Reason Result Code field set to 2 (Success with the available
1913
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
channel list result for Device Location Information field) and WSM information applicable to the first
Device Location Information field in the Channel Availability Query frame. If one or more common
channels are available to the bounded geographic area defined by multiple locations, the CAQ responding
STA responds with Reason Result Code field set to 3 (Success with an available channel list result for a
bounded geographic area defined by multiple Device Location Information fields) and a corresponding
WSM Information field.
When a CAQ responding STA receives the protected Channel Availability Query frame, the response shall
be sent using the protected Channel Availability Query frame.
11.44.5 Channel schedule management (CSM) procedures
11.44.5.1 Introduction
This subclause describes a channel schedule management procedure that can be used to obtain the list of
available channels for the operation of a GDD STA. STAs can use the CSM procedure specified here when
dot11GDDActivated is true.
Upon receipt of MLME-CHANNELSCHEDULEMANAGEMENT.request primitive, the MLME schedules
transmission for a CSM request frame. If the parameter Protected of the MLME-
CHANNELSCHEDULEMANAGEMENT.request primitive has the value true, then the CSM request frame
as defined in 9.6.8.26 is transmitted in a Protected Dual of Public Action frame; otherwise the CSM request
frame is transmitted in a Public Action frame.
Upon receipt of MLME-GAS.request primitive with an AdvertisementProtocolID parameter value of RLQP
and Query parameter for a Channel Schedule Management RLQP-element, the requesting STA performs the
procedure specified in 11.25.3.2.2 to transmit a GAS Initial Request frame that contains the Channel
Schedule Management RLQP-element.
A GDD enabling STA transmits a CSM request to a RLSS to query the schedule information on TV
channels. By default, a RLSS is able to provide channel schedule information on TV channels. However, the
RLSS may reject the request by responding with Reason Result Code field set to the value for “Request
declined by RLSS for unspecified reason.”
A GDD enabling STA transmits a CSM request to a RLSS to query the schedule information on WLAN
channels. The RLSS maps channel schedule information from TV channels to WLAN channels and
provides the schedule information, as defined in 9.4.4.2.4, to the GDD enabling STA that sent the query to
facilitate WLAN operation. A RLSS that is not capable of providing WLAN channel schedule information
responds to a request using the CSM response with the Reason Result Code field set to the value for
“Request declined by RLSS because of no capability for providing schedule information on WLAN
channels.”
A GDD enabling STA transmits a CSM request to another GDD enabling STA that is capable of database
access as indicated in the GDD enabling signal. The GDD enabling STA that is capable of database access is
able to access the RLSS and obtain the channel schedule information on TV channels. The GDD enabling
STA may respond to a request by sending the CSM response with Reason Result Code field set to the value
for “Request Declined by the GDD enabling STA because of no capability for providing schedule
information on WLAN channels.”
A GDD enabling STA may transmit a CSM request to query WLAN channel information from another
GDD enabling STA. A GDD enabling STA responds to a CSM request using a CSM response with the
Reason Result Code field set to the value for “Success” if it is capable of providing channel schedule
information on WLAN channels obtained from a RLSS and responds with the Reason Result Code field set
1914
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
to the value for “Request declined by the GDD enabling STA because of no capability for providing
schedule information on WLAN channels,” otherwise.
When the information in a CSM response is identical to the information in the most recently transmitted
CSM response to the same requesting STA, the responding STA can set the Reason Result Code field value
CSM element in a query response to “Successful” with no channel schedule changes from the last query of
the RLSS and omit both the Channel Schedule Management Mode and Channel Schedule Descriptor fields.
A GDD enabling STA with dot11ChannelScheduleManagementActivated true may send a CSM frame to
update the channel schedule information of another GDD enabling STA that receives an available channel
list from it.
The GDD dependent STA shall not transmit a CSM request.
The details of requesting and responding with CSM are provided in 11.44.5.2 and 11.44.5.3.
11.44.5.2 CSM requesting STA
A STA employing RLQP uses the GAS protocol for its CSM procedure with a RLSS. Upon receipt of the
MLME-GAS.request primitive with an AdvertisementProtocolID value of RLQP and Query parameter with
the value of Channel Schedule Management RLQP-element, the CSM requesting STA transmits an RLQP-
element with RLQP ID for CSM in the Query Request field in a GAS Initial Request frame. The specific
information items in the Query Request field of the GAS Initial Request frame are generated as follows:
— Reason Result Code field = 0 or 1 as defined in 9.6.8.26.
— Channel Schedule Management Mode field = 0 or 1 as defined in 9.6.8.26.
— Channel Schedule Descriptor field, as defined in 9.4.4.2.4, containing the channel that the STA
wants to query.
A STA uses the CSM Public Action frame or its protected dual to query another STA for channel schedule
information. Upon receipt of the MLME-CHANNELSCHEDULEMANAGEMENT.request primitive with
the CSM parameter of CSM element, the requesting STA transmits a CSM frame. The request frame is
generated as follows:
— Reason Result Code field = 0 or 1 as defined in 9.6.8.26.
— Channel Schedule Management Mode field = 0 or 1 as defined in 9.6.8.26.
— Channel Schedule Descriptor field, as defined in 9.4.4.2.4, contains only the channel that the STA
wants to query.
11.44.5.3 CSM responding STA
A STA employing RLQP uses the GAS protocol for its CSM procedure with a RLSS. Upon receipt of the
MLME-GAS.request primitive with an ResponseInfo parameter value of Channel Schedule Management
RLQP-element, the CSM responding STA transmits a RLQP-element with RLQP ID for CSM in the Query
Response field in a GAS Initial Response frame or one or more GAS Comeback Response frames. The
responding RLQP CSM shall be transmitted in a Protected Dual of Public Action frame if the received CSM
is protected. The specific information items in the Query Response field of the GAS Initial Response frame
are generated as follows:
— Reason Result Code field = values 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 as defined in 9.6.8.26.
— Channel Schedule Descriptor field, as defined in 9.4.4.2.4, contains the channel and related channel
schedule information.
1915
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA uses CSM Public Action frame or its protected dual to respond to another STA with channel
schedule information. Upon receipt of the MLME-CHANNELSCHEDULEMANAGEMENT.request
primitive with CSM parameter value of CSM element, the CSM responding STA transmits a CSM frame in
response. The responding CSM shall be transmitted in a Protected Dual of Public Action frame if the
received CSM is protected. The CSM response frame is generated as follows:
— Reason result code field = values 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 as defined in 9.6.8.26.
— Channel Schedule Descriptor field, as defined in 9.4.4.2.4, contains the channel and related channel
schedule information.
11.44.6 Contact verification signal (CVS)
The Contact Verification Signal frame is transmitted by a GDD enabling STA to establish that its GDD
dependent STAs are within the reception range of the GDD enabling STA and to validate the available
channel list. A GDD enabling STA with dot11ContactVerificationSignalActivated true shall transmit an
individually addressed Protected CVS frame (see 9.6.8.27) to its GDD dependent STAs.
A GDD dependent STA receives a CVS frame transmitted from its GDD enabling STA that provided the
WSMs to verify that it is within reception range of that GDD enabling STA. The CVS frame has a Map ID
field that indicates whether the WSM has been changed. A GDD dependent STA compares values of the
Map ID field in the CVS frame with the Map ID of its existing WSM. If they are the same, then the GDD
dependent STA assumes that its WSM is valid, and it sets dot11GDDEnablementValidTimer equal to
dot11ContactVerificationSignalInterval. If they are different, the WSM is invalid because WSM
information has changed. The STA should transmit a Channel Availability Query frame and receive a
response in a Channel Availability Query frame that contains an updated WSM. If the GDD dependent STA
fails to retrieve the updated WSM, it shall change its GDD enablement state to unenabled and stop
transmitting over the air after dot11GDDEnablementValidTimer has expired.
11.44.7 Network channel control (NCC) procedures
11.44.7.1 Introduction
This subclause describes network channel control procedures that can be used to manage channels for
operation of a GDD STA. A STA may use the NCC procedures specified here when dot11GDDActivated is
true.
Network channel control utilizes a two-message transaction sequence to allow an NCC responding STA to
control the frequency usage in TV bands of an NCC requesting STA’s WLAN network channels. The first
MMPDU sent by the NCC requesting STA asserts identity and requests NCC information. The NCC
requesting STA may select its preferred frequencies from its WSM and request usage. The MMPDU sent by
the NCC responding STA returns the NCC result. The NCC responding STA might grant permission to use
the selected frequencies for multiple WLAN network channels to the NCC requesting STA by responding
with a Network Channel Control frame (see 9.6.8.30). When responding, the NCC responding STA provides
the confirmed WLAN network channels and the transmit power constraints as well. The WLAN network
channels that the NCC responding STA confirms might be the same as or a subset of the network channels
listed in the Network Channel Control frame received from the NCC requesting STA.
An NCC requesting STA employing RLQP may send an Network Channel Control frame to the RLSS to
request its preferred frequencies given by the WSM for WLAN network channels. The NCC requesting STA
accomplishes this by transmitting an RLQP-element with the RLQP ID for NCC in the Query Request field
in a GAS Initial Request frame. After it receives this frame the NCC responding STA forwards the NCC
request to the RLSS. After receiving the NCC request, the RLSS responds and sends an NCC response via
1916
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the NCC responding STA to the NCC requesting STA. When responding, the RLSS also provides the
confirmed WLAN network channels and the transmit power constraints. The WLAN network channels that
the RLSS confirms might be the same as or a subset of the network channels listed in the Network Channel
Control request frame received from the NCC requesting STA.
Whenever the WSM has changed due to the update of the database information or detection of the primary
service signals, an NCC requesting STAs may transmit a new Network Channel Control frame.
11.44.7.2 NCC requesting STA
An NCC requesting STA may be a GDD dependent STA. An NCC requesting STA employing RLQP may
use the GAS protocol for its NCC procedure with a RLSS. Upon receipt of the MLME-GAS.request
primitive with an AdvertisementProtocolID value of RLQP and Query parameter with the value of Network
Channel Control RLQP-element, the NCC requesting STA transmits an RLQP-element with Info ID for
NCC in the Query Request field in a GAS Initial Request frame. The specific information items in the Query
Request field of the GAS Initial Request frame are generated as follows:
— The Requester STA Address field is set to the MAC address of the NCC requesting STA.
— The Responder STA Address field is set to the MAC address of the NCC responding STA.
— The Reason Result code is REQUEST, as defined in 9.4.6.4.
— The Number of Network Channel Control Triplets field, as defined in 9.4.6.4, gives the number of
triplets of Operating Class, Channel Number, and Transmit Power Constraint fields.
— The Operating Class and Channel Number fields, with the values defined in E.1, together specify the
channel frequency and channel bandwidth for WLAN network channels selected by the NCC
requesting STA.
— The Maximum Transmit Power field, as defined in 9.4.6.4, is set to the intended maximum transmit
power in dBm for operation of the requesting STA.
An NCC Requesting STA might use the Network Channel Control frame or its protected dual to query
another STA to request frequency usage in TV bands for WLAN network channels. Upon receipt of the
MLME-NETWORKCHANNELCONTROL.request primitive, the requesting STA transmits a (protected)
Network Channel Control frame. The request frame is generated as follows:
— The Requester STA Address field is set to the MAC address of the NCC requesting STA.
— The Responder STA Address field is set to the MAC address of the NCC responding STA.
— The Reason Result Code is REQUEST, as defined in 9.4.6.4.
— The Number of Network Channel Control Triplets field, as defined in 9.4.6.4, gives the number of
triplets of Operating Class, Channel Number, and Transmit Power Constraint fields.
— The Operating Class and Channel Number fields, with the values defined in E.1, together specify the
channel frequency and channel bandwidth for WLAN network channels selected by the NCC
requesting STA.
— The Maximum Transmit Power field, as defined in 9.4.6.4, is set to the intended maximum transmit
power in dBm for operation of the requesting STA.
1917
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
11.44.7.3 NCC responding STA
An NCC responding STA may be a GDD enabling STA. An NCC responding STA employing RLQP may
use the GAS protocol for its NCC procedure with a RLSS. Upon receipt of the MLME-GAS.response
primitive with a ResponseInfo parameter value of Network Channel Control RLQP-element, the NCC
responding STA transmits a RLQP-element with Info ID for NCC in the Query Response field in a GAS
Initial Response frame or one or more GAS Comeback Response frames. The specific information items in
the Query Response field of the GAS Initial Response frame are generated as follows:
— Requester STA Address field set to the MAC address of the NCC requesting STA.
— Responder STA Address field set to the MAC address of the NCC responding STA.
— Reason Result Code field = values SUCCESS, REFUSED,
TOO_MANY_SIMULTANEOUS_REQUESTS, or Continuation frame as defined in 9.4.6.4.
— The Number of Network Channel Control Triplets field, as defined in 9.4.6.4, gives the number of
triplets of Operating Class, Channel Number, and Transmit Power Constraint fields.
— The Operating Class and Channel Number fields, with the values defined in E.1, together specify the
channel frequency and channel bandwidth that the NCC responding STA has granted permission to
the NCC requesting STA for WLAN operation.
— The Maximum Transmit Power field, as defined in 9.4.6.4, sets to maximum allowable transmit
power in dBm of the requesting STA’s WLAN operation.
An NCC responding STA may use an Network Channel Control frame or its protected dual to respond to
another STA with NCC information. Upon receipt of the MLME-
NETWORKCHANNELCONTROL.response primitive with NCC parameter value of NCC element, the
NCC responding STA transmits a Network Channel Control frame containing an NCC element. The
response frame is generated as follows:
— Requester STA Address field set to the MAC address of the NCC requesting STA.
— Responder STA Address field set to the MAC address of the NCC responding STA.
— Reason Result Code = values SUCCESS, REFUSED,
TOO_MANY_SIMULTANEOUS_REQUESTS, or Continuation frame as defined in 9.4.6.4.
— The Number of Network Channel Control Triplets field, as defined in 9.4.6.4, gives the number of
triplets of Operating Class, Channel Number, and Transmit Power Constraint fields.
— The Operating Class and Channel Number fields, with the values defined in E.1, together specify the
channel frequency and channel bandwidth that the NCC responding STA has granted permission to
the NCC requesting STA for WLAN operation.
— The Maximum Transmit Power field, as defined in 9.4.6.4, sets to maximum allowable transmit
power in dBm of the requesting STA’s WLAN operation.
11.44.8 Reduced neighbor report
In Beacon and Probe Response frames, a Reduced Neighbor Report element may be transmitted by an AP
with dot11TVHTOptionImplemented true. A Reduced Neighbor Report element contains information on
neighbor APs. A Reduced Neighbor Report element might not be exhaustive either by choice or by the fact
that there may be neighbor APs not known to the AP.
The Reduced Neighbor Report element contains a list of operating classes and primary channels along with
TBTT information for the reported neighbor APs on each operating class and primary channel. The
operating class is selected from values in Table E-4 filtered by the requirement that, together with the
Channel Number field, the primary channel be identifiable.
1918
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—For instance, this excludes operating class 128–130.
When the reporting AP cannot obtain an operating class that, together with the Channel Number field,
identifies the primary channel from the neighboring AP, then the reporting AP shall report an operating class
that, together with a channel number, identifies the primary channel of the reported BSS. Given a choice of
operating classes that preserve the identification of the primary channel, the reporting AP should select an
operating class that preserves as many behavior limits as possible are known to the reporting AP.
NOTE—An operating class might be unavailable because the neighboring AP does not transmit an operating class or the
transmitted operating class does not indicate a primary channel.
A Reduced Neighbor Report element includes only channels that are consistent with the Country element in
the frame in which the Reduced Neighbor Report element appears. The Reduced Neighbor Report element
contents may be derived from the NeighborListSet parameter of the MLME-NEIGHBORREPRESP.request
primitive. The contents of the Reduced Neighbor Report element might also be configured or obtained by
other means beyond the scope of this standard.
If the Supported Operating Classes element of the STA is included in the Probe Request frame, the reduced
neighbor report contains information on neighbor APs whose current operating class matches the supported
operating classes in the Probe Request frame.
The Reduced Neighbor Report element shall include the information on neighbor APs whose SSID matches
the specific SSID in the Probe Request frame if the Filtered Neighbor AP bit in the Neighbor AP
Information field is set to 1.
A serving AP shall include a value less than 255 in the Neighbor AP TBTT Offset subfield if it is able to
guarantee an accumulated error of 1.5 TU or better.
A STA receiving a Reduced Neighbor Report element may use the report to schedule passive scanning for
faster AP discovery. The scheduling process is beyond the scope of this standard. A STA receiving a
Reduced Neighbor Report element with an unknown subelement identifier shall ignore the unknown
subelement and continue to process the remaining subelements.
11.44.9 White space map (WSM)
This subclause describes WSM procedures that can be used to obtain lists of available channels for operation
of a GDD STA. STAs can use the WSM procedure specified here when dot11GDDActivated is true.
When dot11WhiteSpaceMapActivated is true, a GDD STA shall follow the procedures in this subclause.
If dot11WhiteSpaceMapActivated is true, a GDD enabling STA transmits a WSM, and a GDD dependent
STA can transmit frames only on the available channels indicated in its valid WSM. GDBs can be different
according to each regulatory domain and its regulatory requirements. A WSM Type field value of 1
indicates that the WSM is generated from the GDB and the WSM Information field of the WSM element
specifies the available information for TVWS, which is country-specific and defined in 9.4.4.2.5.
A GDD enabling STA contacts a GDB to obtain the permissible frequencies and operating parameters
before it begins its transmissions. After receiving the WSM information from a GDB, a GDD enabling STA
operates in TVWS only in the frequencies that the GDB indicates are available. The GDD enabling STA
generates WSMs based on the information from the GDB. It may update WSMs when STAs perform a
measurement or receive a measurement report in which a primary service signal is measured on a channel,
which is indicated as available from the GDB.
1919
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A WSM element includes a list of identified available channels and corresponding maximum allowed
transmission powers for each available channel.
When a GDD enabling STA retrieves updated available frequency information, it is able to transmit
individually addressed Protected WSM Announcement frames with an updated WSM element to its GDD
dependent STAs.
A GDD dependent STA receiving a WSM element operates on the channels indicated in the WSM. A GDD
dependent STA that receives an updated WSM from its GDD enabling STA shall move its channel of
operation if it is operating on a channel that has become unavailable in the updated WSM.
A GDD enabling STA transmits a WSM within a GDD Enablement Response frame, CAQ response frame,
and WSM Announcement frame. A Device Class field of a WSM in a GDD Enablement Response frame
and CAQ response frame is set to a value of a Device Class field in a GDD Enablement Request frame and
Channel Availability Query frame, respectively. A Device Class field of WSM in a WSM Announcement
frame is set to a value of the Device Class field of a WSM in a GDD Enablement Request frame.
The value of the Map version bits in the Map ID field is increased by 1 (modulo 127) whenever the GDD
enabling STA transmits the updated WSM. The most recently received WSM is used by the WSM receiving
STAs. A WSM with a Map version value of 127 indicates that the WSM is informative and it does not affect
the GDD enablement states of a GDD dependent STA. If the Type bit in the Map ID field is set to 1, the
following channel list is a full channel list; and if the Type bit is set to 0, the following channel list is a
partial channel list. If a STA receives several WSMs with the same Map version and the Type bit is equal
to 0, the STA should construct the whole channel list using the multiple WSMs having the same Map
version.
GDD dependent STAs receiving a WSM should scan for existing BSSs on the available channels identified
within received WSM element. In TVWS a GDD dependent STA receiving a WSM element shall operate on
the channels indicated in the WSM. A GDD dependent STA that has previously received a WSM and that
receives an updated WSM from its AP or GDD enabling STA shall move its channel of operation if it is
operating on a channel that has become unavailable in the updated WSM.
If dot11WhiteSpaceMapActivated is true, then the enabled GDD dependent STA may send a Probe Request
frame on any channel identified in the received WSM element. An AP that has
dot11WhiteSpaceMapActivated true and that receives a Probe Request frame should respond with a Probe
Response frame containing a WSM element.
11.45 Beacon RSSI
Upon receiving a Beacon frame, a STA measures the received signal strength of the Beacon frame
(dot11BeaconRssi). If the Beacon frame is received using multiple receive chains, the Beacon RSSI is
averaged in linear domain over all active receive chains. The Beacon RSSI is reported in dBm. When
operating in frequency bands below 6 GHz, the Beacon RSSI has an accuracy of ± 5 dB (95% confidence
interval) within the specified dynamic range of the receiver. Beacon RSSI may be averaged over time using
a vendor specific smoothing function.
11.46 Estimated throughput
A STA that has a value of true for dot11EstimatedServiceParametersOptionImplemented is an estimated
service parameters (ESP) STA.
1920
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Entities outside the scope of this standard that might control the traffic steering decision of a device benefit
by being able to predict the throughput that might be obtained through a link with a STA. Those same
entities also need to know what the current estimate of throughput is for network selection purposes (by
comparing an estimated throughout with existing throughout). The MLME-ESTIMATED-
THROUGHPUT.request and MLME-ESTIMATED-THROUGHPUT.confirm primitives together provide
an interface to allow such entities, operating through the SME, to obtain an estimate of throughput for
MSDUs sent between the STA that corresponds to the PeerMACAddress indicated in the parameter list of
the MLME-ESTIMATED-THROUGHPUT.request primitive and this STA.
When an MLME-ESTIMATED-THROUGHPUT.request primitive is received at the MLME, the MLME
can use the parameters provided in the primitive plus the following information to create estimates of
throughput per access category to deliver to the SME in the EstimatedThroughputOutbound parameter of the
MLME-ESTIMATED-THROUGHPUT.confirm primitive:
— RSSI measured during reception of Beacon or Probe Response frames transmitted by the STA that
corresponds to the MAC entity with the MAC address equal to the PeerMACAddress in the MLME-
ESTIMATED-THROUGHPUT.request primitive to this STA
— Number of spatial streams that is expected to be supported on the link between this STA and the
STA
— Channel bandwidth
— Estimated air fractional time
— Block ack window size
If the MLME is incapable of determining a value for the EstimatedThroughputOutbound or
EstimatedThroughputInbound parameter for any access category, then the MLME shall return a value of 0
for the value of that parameter for that access category in the MLME-ESTIMATED-
THROUGHPUT.confirm primitive. If the AverageMSDUSizeOutbound parameter for an access category is
equal to –1 in the MLME-ESTIMATED-THROUGHPUT.request primitive, the STA shall include a value of
0 in the EstimatedThroughputOutbound parameter for the corresponding access category in the MLME-
ESTIMATED-THROUGHPUT.confirm primitive. If the AverageMSDUSizeOutbound parameter for an
access category is equal to 0 in the MLME-ESTIMATED-THROUGHPUT.request primitive, the STA may
use any value for the average MSDU size used in calculating the estimated throughput to be included in the
corresponding access category in the EstimatedThroughputOutbound parameter of the MLME-
ESTIMATED-THROUGHPUT.confirm primitive, but should use a value of 1500 octets. If the
AverageMSDUSizeInbound parameter for an access category is equal to –1 in the MLME-ESTIMATED-
THROUGHPUT.request primitive, the STA shall include a value of 0 in the EstimatedThroughputInbound
parameter for the corresponding access category in the MLME-ESTIMATED-THROUGHPUT.confirm
primitive. If the AverageMSDUSizeInbound parameter for an access category is equal to 0 in the MLME-
ESTIMATED-THROUGHPUT.request primitive, the STA may use any value for the average MSDU size
used in calculating the estimated throughput to be included in the corresponding access category in the
EstimatedThroughputInbound parameter of the MLME-ESTIMATED-THROUGHPUT.confirm primitive,
but should use a value of 1500 octets.
An ESP STA should determine a value for EstimatedThroughputOutbound for each AC of a current or
potential link with a STA using the equation found in R.7.
An ESP STA or a mesh STA may include a Request element that includes the element ID of the Estimated
Service Parameters element in transmitted Probe Requests.
1921
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An ESP STA that is an AP or a mesh STA shall include the Estimated Service Parameters element within
Probe Response frames transmitted in response to a Probe Request frame that included a Request element
that includes the element ID of the Estimated Service Parameters element. An ESP STA that is not an AP
may include the Estimated Service Parameters element within Probe Response frames transmitted in
response to a Probe Request frame that included a Request element that includes the element ID of the
Estimated Service Parameters element. An ESP STA may include the Estimated Service Parameters element
within Probe Response frames transmitted in response to a Probe Request frame that did not include a
Request element, or included a Request element that did not include the element ID of the Estimated Service
Parameters element.
An ESP STA that is an AP or a mesh STA shall include the Estimated Service Parameters element within
Beacon frames. An ESP STA that is not an AP may include the Estimated Service Parameters element
within Beacon frames.
1922
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12. Security
12.1 Conventions
Reserved fields and subfields are set to 0 upon transmission and are ignored upon reception.
ASCII strings are defined in 9.2.2.
12.2 Framework
12.2.1 Classes of security algorithm
This standard defines two classes of security algorithms for IEEE 802.11 networks:
— Algorithms for creating and using an RSNA, called RSNA algorithms
— Pre-RSNA algorithms
NOTE—This standard does not prohibit STAs from simultaneously operating pre-RSNA and RSNA algorithms.
The use of WEP for confidentiality, authentication, or access control is deprecated. The WEP algorithm is
unsuitable for the purposes of this standard.
The use of TKIP is deprecated. The TKIP algorithm is unsuitable for the purposes of this standard.
12.2.2 Security methods
Pre-RSNA security comprises the following algorithms and procedures:
— WEP, described in 12.3.2
— IEEE 802.11 entity authentication, described in 12.3.3
RSNA security comprises the following algorithms and procedures:
— TKIP, described in 12.5.2
— CCMP, described in 12.5.3
— GCMP, described in 12.5.5
— BIP, described in 12.5.4
— RSNA establishment and termination procedures, including use of IEEE 802.1X authentication,
described in 12.6 and SAE authentication described in 12.4
— Key management procedures, described in 12.7
12.2.3 RSNA STA capabilities
When dot11RSNAActivated is true, an RSNA STA shall include the RSNE in Beacon, Probe Response,
Information Response, and (Re)Association Request frames and in message 2 and message 3 of the 4-way
handshake; shall set the DMG Privacy subfield to 1 within transmitted DMG Beacons; and may include the
RSNE in DMG Beacon and Announce frames. A pre-RSNA STA is not capable of creating RSNAs.
All STAs implementing RSNA shall support the RSNE described in 9.4.2.25.
12.2.4 RSNA establishment
An SME establishes an RSNA in one of six ways:
1923
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) If an RSNA uses authentication negotiated over IEEE Std 802.1X in an infrastructure BSS, an
RSNA-capable STA’s SME establishes an RSNA as follows:
1) It identifies the AP as RSNA-capable from the AP’s Beacon, DMG Beacon, Announce,
Information Response, or Probe Response frames.
2) It shall invoke Open System authentication if the STA is a non-DMG STA.
3) It negotiates cipher suites during the association process, as described in 12.6.2 and 12.6.3.
4) It uses IEEE Std 802.1X-2010 to authenticate, as described in 12.6.10 and 12.6.11.
5) It establishes one or more temporal keys by executing a key management algorithm, using the
protocol defined by 12.7 or 13.
6) It protects the data link by programming the negotiated cipher suites and the established
temporal key into the MAC and then invoking protection. See, for example, 12.5.3 for a
description of the RSNA data protection mechanisms.
7) If the STAs negotiate management frame protection, the SME programs the TK and pairwise
cipher suite into the MAC for protection of individually addressed robust Management frames.
It also installs the IGTK and IPN for protection of group addressed robust Management frames.
b) If an RSNA is based on a PSK or password in an infrastructure BSS, the SME establishes an RSNA
as follows:
1) It identifies the AP as RSNA-capable from the AP’s Beacon, DMG Beacon, Announce,
Information Response, or Probe Response frames.
2) If the RSNA-capable AP advertises support for SAE authentication in its Beacon or Probe
Response frames, and the STA has a group defined in the dot11RSNAConfigDLCGroupTable
and a password for the AP in the dot11RSNAConfigPasswordValueTable, the STA shall
invoke SAE authentication to establish a PMK. If the RSNA-capable AP does not advertise
support for SAE authentication in its Beacon and Probe Response frames but advertises support
for the alternate form of PSK authentication (see 4.10.3.4), and the STA also supports the
alternate form of PSK authentication, the non-DMG STA may invoke Open System
authentication and use the PSK as the PMK with the key management algorithm in step 4)
below.
3) It negotiates cipher suites during the association process, as described in 12.6.2 and 12.6.3.
4) It establishes one or more temporal keys by executing a key management algorithm, using the
protocol defined by 12.7.
5) It protects the data link by programming the negotiated cipher suites and the established
temporal key into the MAC and then invoking protection.
6) If the STAs negotiate management frame protection, the STA programs the TK and pairwise
cipher suite into the MAC for protection of individually addressed robust Management frames.
It also installs the IGTK and IPN for protection of group addressed robust Management frames.
c) If an RSNA is based on a PSK or password in an IBSS the SME executes the following sequence of
procedures:
1) It identifies the peer as RSNA-capable from the peer’s Beacon, DMG Beacon, Announce,
Information Response, or Probe Response frames.
NOTE—STAs might respond to a Data frame from an unrecognized STA by sending a Probe Request frame to find out
whether the unrecognized STA is RSNA-capable.
2) If the RSNA-capable peer advertises support for SAE authentication in its Beacon and Probe
Response frames and the STA has a group defined in the dot11RSNAConfigDLCGroupTable
and a password for the peer in the dot11RSNAConfigPasswordValueTable, the STA shall
invoke SAE authentication and establish a PMK. If the RSNA-capable peer does not advertise
support for SAE authentication but advertises support for the alternate form of PSK
authentication (see 4.10.3.4), and the STA also supports the alternate form of PSK
1924
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
authentication the STA may invoke Open System authentication if the STA is a non-DMG
STA and use a PSK as the PMK with the alternate form of PSK authentication.
3) Each STA uses the procedures in 12.7, to establish one or more temporal keys and to negotiate
cipher suites. Note that two peer STAs might follow this procedure simultaneously. See
12.6.15.
4) It protects the data link by programming the negotiated cipher suites and the established
temporal key and then invoking protection.
d) If an RSNA uses authentication negotiated over IEEE Std 802.1X in an IBSS, an RSNA-capable
STA’s SME establishes an RSNA as follows:
1) It identifies the peer as RSNA-capable from the peer’s Beacon, DMG Beacon, Announce,
Information Response, or Probe Response frames.
NOTE—STAs might respond to a Data frame from an unrecognized STA by sending a Probe Request frame to find out
whether the unrecognized STA is RSNA-capable.
2) It may invoke Open System authentication if the STA is a non-DMG STA.
3) Each STA uses IEEE Std 802.1X-2010 to authenticate with the AS associated with the other
STA’s Authenticator, as described in 12.6.10 and 12.6.11.
NOTE—Two peer STAs might follow this procedure simultaneously.
4) Each SME establishes one or more temporal keys by executing a key management algorithm,
using the protocol defined in 12.7. Hence two such key management algorithms are happening
in parallel between any two STA’s Supplicants and Authenticators.
5) Both STAs use the agreed-upon temporal key portion of the PTK and pairwise cipher suite
from one of the exchanges to protect the link. Each STA uses the GTK established by the
exchange it initiated to protect the group addressed frames it transmits.
e) In order to associate with a PCP in a PBSS, an RSNA-capable STA’s SME establishes an RSNA
with the PCP following the RSNA establishment steps in an infrastructure BSS in accordance with
method a) and b) above, as appropriate, with the PCP taking the role of the AP.
f) When an RSNA-capable STA chooses not to associate with a peer in a PBSS, its SME establishes an
RSNA with the peer following the RSNA establishment steps in an IBSS in accordance with method
c) or d) above, as appropriate, with the caveat that the RSNA authentication and key management
algorithm is executed only once between the peers.
The time a security association takes to set up shall be less than dot11RSNAConfigSATimeout. The security
association setup starts when initiated by the SME and completes when the MLME-
SETPROTECTION.request primitive is invoked. The action the STA takes on the timeout is a policy
decision. Some options include retrying the security association setup or trying another STA. This timeout
allows recovery when one of the STAs setting up a security association fails to respond correctly to setting
up the security association. It also allows recovery in IBSS when one of the two security associations fails
because of a security association timeout.
Only Authentication frames with the authentication algorithm equal to Open System authentication or FT
authentication may be used within an RSNA. An RSNA STA shall not associate if Shared Key
authentication was invoked prior to RSN association.
12.2.5 RSNA PeerKey Support
The STSL mechanism is obsolete. Consequently, the PeerKey protocol components that do not support the
AP PeerKey protocol might be removed in a later revision of the standard.
1925
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PeerKey protocol provides mutual authentication, session identification, and data confidentiality for a
station-to-station connection. A PeerKey association, composed of an SMKSA and an STKSA, shall be
allowed only within the context of an existing RSNA by both peers with a common AP, or between peer
APs that implement the AP PeerKey protocol. An initiator STA or peer STA shall not initiate an STSL
master key (SMK) handshake and STSL transient key (STK) handshake if dot11RSNAActivated is false.
An initiator STA or peer STA shall not establish a security association if dot11RSNAActivated is false.
A STSL session may chose to allow unprotected communication between STAs. In this case, the PeerKey
protocol is not used.
12.2.6 RSNA assumptions and constraints
An RSNA assumes the following:
a) Each STA can generate cryptographic-quality random numbers. This assumption is fundamental, as
cryptographic methods require a source of randomness. See J.5 for suggested hardware and software
methods to achieve randomness suitable for this purpose.
b) When IEEE 802.1X authentication is used, the specific EAP method used performs mutual
authentication. This assumption is intrinsic to the design of RSN in IEEE 802.11 LANs and cannot
be removed without exposing both the STAs to man-in-the-middle attacks. EAP-MD5 is an example
of an EAP method that does not meet this constraint (see IETF RFC 3748 [B42]). Furthermore, the
use of EAP authentication methods where server and client credentials are not differentiated reduces
the security of the method to that of a PSK due to the fact that malicious insiders might masquerade
as servers and establish a man-in-the-middle attack.
In particular, the mutual authentication requirement implies an unspecified prior enrollment process
(e.g., a long-lived authentication key or establishment of trust through a third party such as a
certification authority), as the STA needs to be able to identify the ESS or IBSS as a trustworthy
entity and vice versa. The STA shares authentication credentials with the AS utilized by the selected
AP or, in the case of PSK, the selected AP. The SSID provides an unprotected indication that the
selected AP’s authentication entity shares credentials with the STA. Only the successful completion
of the IEEE 802.1X EAP or PSK authentication, after association, validates any such indication that
the AP is connected to an authorized network or service provider.
c) The mutual authentication method needs to be strong, meaning impersonation attacks are
computationally infeasible when based on the information exposed by the authentication. This
assumption is intrinsic to the design of RSN.
d) The AP and AS have a trustworthy channel between them that can be used to exchange
cryptographic keys without exposure to any intermediate parties.
e) An IEEE 802.1X AS never exposes the common symmetric key to any party except the AP with
which the STA is currently communicating. This is a very strong constraint. It implies that the AS
itself is never compromised. It also implies that the IEEE 802.1X AS is embedded in the AP or that
the AP is physically secure and the AS and the AP lie entirely within the same administrative
domain. This assumption follows from the fact that if the AP and the AS are not collocated or do not
share pairwise key encryption keys directly, then it is impossible to assure the non-AP STA that its
key, which is distributed by the AS to the AP, has not been compromised prior to use.
f) Similarly, a STA never shares with a third party a common symmetric key that it shares with a peer.
Doing so destroys the utility of the key for detecting MPDU replay and forgery.
g) The Supplicant and the Authenticator generate a different, fresh PTK for each session between the
pair. This assumption is fundamental, as reuse of any PTK would enable compromise of all the data
protected by that key.
h) The destination STA chosen by the transmitter is the correct destination. For example, Address
Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) are methods of
determining the destination STA’s MAC address that are not secure from attacks by other members
1926
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
of the ESS. One of the possible solutions to this problem might be for the STA to send or receive
only frames whose final DA or SA are the AP and for the AP to provide a network layer routing
function. However, such solutions are outside the scope of this standard.
An HT STA shall not use either of the pairwise cipher suite selectors: “Use group cipher suite” or TKIP to
communicate with another HT STA.
NOTE—Because a VHT STA is also an HT STA, the elimination of TKIP also applies to VHT STAs.
12.2.7 Requirements for the Protected Frame field
The Protected Frame field shall be set to 1 in:
— Data frames that are protected using the mechanisms specified in Clause 12.
— Individually addressed robust Management frames.
— Authentication frames with Authentication Algorithm Number field equal to 1 (Shared Key) and
Authentication Transaction Sequence Number field equal to 3.
It shall be set to 0 in all other frames.
12.2.8 Requirements for robust management frame protection
The robust Management frames are Disassociation, Deauthentication, and robust Action frames.
Action frames specified with “No” in the “Robust” column of Table 9-47 are not robust Management frames
and shall not be protected.
When management frame protection is negotiated, all group addressed robust Management frames shall be
encapsulated using the procedures defined in 11.13.
12.2.9 Emergency service establishment in an RSN
An AP or mesh STA that supports RSNAs and has the ESR bit set to 1 and the UESA bit set to 1 in the
Interworking element in Beacon and Probe Response frames supports both RSNAs and emergency services
associations (see 11.3.5.2) simultaneously.
In an infrastructure BSS, the STAs with emergency services association should discard all group addressed
frames they receive, as they do not possess the Group Key and therefore are not able to decrypt group
addressed frames. In an RSNA enabled BSS that has one or more STAs associated with an emergency
services association, an AP should avoid transmitting unprotected group addressed frames in order not to
disturb the operation of STAs that are in possession of Group Key. One possible way of achieving this is to
support Proxy-ARP in the AP, as defined in 11.24.14. In addition, it is recommended that an AP supporting
emergency services association should also support DMS to convert group addressed frames to individually
addressed frames and transmit them to STAs associated using the emergency services association. STAs
using emergency services association might request DMS if needed.
12.3 Pre-RSNA security methods
12.3.1 Status of Pre-RSNA security methods
Except for Open System authentication, all pre-RSNA security mechanisms are obsolete. Support for them
might be removed in a later revision of the standard.
Open System Authentication and Open System Deauthentication shall not be used between mesh STAs.
1927
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.3.2 Wired equivalent privacy (WEP)
12.3.2.1 WEP overview
WEP-40 was defined as a means of protecting (using a 40-bit key) the confidentiality of data exchanged
among authorized users of a WLAN from casual eavesdropping. Implementation of WEP is optional. The
same algorithms have been widely used with a 104-bit key instead of a 40-bit key in fielded
implementations; this is called WEP-104. The WEP cryptographic encapsulation and decapsulation
mechanics are the same whether a 40-bit or a 104-bit key is used. The term WEP by itself refers to either
WEP-40 or WEP-104.
12.3.2.2 WEP MPDU format
Figure 12-1 depicts the encrypted frame body as constructed by the WEP algorithm.
Encrypted(Note)
IV Data ICV
4 ≥1 4
Sizes in Octets
Init. Vector 1 octet
3 Pad Key ID
6 bits 2 bits
Figure 12-1—Construction of expanded WEP MPDU
The WEP ICV field shall be 32 bits in length. The expanded frame body shall start with a 32-bit IV field.
This field shall contain three subfields: a 3-octet subfield that contains the IV, a 2-bit Key ID subfield, and a
6-bit Pad subfield. The ordering conventions defined in 9.2.2 apply to the IV field and its subfields and to
the ICV field. The Key ID subfield contents select one of four possible secret key values for use in
decrypting this frame body. When key-mapping keys are used, the Key ID field is reserved.
Interpretation of these bits is discussed further in 12.3.2.3. The contents of the Pad subfield shall be 0. The
Key ID subfield occupies the 2 MSBs of the last octet of the IV field, while the Pad subfield occupies the
6 LSBs of this octet.
12.3.2.3 WEP state
WEP uses encryption keys only; it performs no data authentication. Therefore, it does not have data integrity
keys. WEP uses two types of encryption keys: key-mapping keys and default keys.
A key-mapping key is an unnamed key corresponding to a distinct transmitter address-receiver address
pair. Implementations shall use the key-mapping key if it is configured for a pair. In
other words, the key-mapping key shall be used to WEP-encapsulate or -decapsulate MPDUs transmitted by
TA to RA, regardless of the presence of other key types. When a key-mapping key for an address pair is
present, the WEP Key ID subfield in the MPDU is reserved.
1928
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A default key is an item in a four-element MIB array called dot11WEPDefaultKeys, named by the value of a
related array index called dot11WEPDefaultKeyID. If a key-mapping key is not configured for a WEP
MPDU’s pair, WEP shall use a default key to encapsulate or decapsulate the MPDU. On transmit,
the key selected is the element of the dot11DefaultKeys array given by the index
dot11WEPDefaultKeyID—a value of 0, 1, 2, or 3—corresponding to the first, second, third, or fourth
element, respectively, of dot11WEPDefaultKeys. The value the transmitter encodes in the WEP Key ID
subfield of the transmitted MPDU shall be the dot11WEPDefaultKeyID value. The receiver shall use the
Key ID subfield of the MPDU to index into dot11WEPDefaultKeys to obtain the correct default key. All
WEP implementations shall support default keys.
NOTE—Many implementations also support 104-bit WEP keys. These are used exactly like 40-bit WEP keys: a 24-bit
WEP IV is prepended to the 104-bit key to construct a 128-bit WEP seed, as explained in 12.3.2.4.3. The resulting 128-
bit WEP seed is then consumed by the ARC4 stream cipher. This construction based on 104-bit keys affords no more
assurance than the 40-bit construction, and its implementation and use are in no way condoned by this standard. Rather,
the 104-bit construction is noted only to document de facto practice.
The default value for all WEP keys shall be null. WEP implementations shall discard the MSDU and
generate an MA-UNITDATA-STATUS.indication primitive with transmission status indicating that a frame
shall not be encapsulated with a null key in response to any request to encapsulate an MPDU with a null key.
12.3.2.4 WEP procedures
12.3.2.4.1 WEP ICV algorithm
The WEP ICV shall be computed using the CRC-32, as defined in 9.2.4.7, calculated over the plaintext
MPDU Data (PDU) field.
12.3.2.4.2 WEP encryption algorithm
A WEP implementation shall use the ARC4 stream cipher from RSA Security, Inc., as its encryption and
decryption algorithm. ARC4 uses a pseudorandom number generator (PRNG) to generate a key stream that
it exclusive-ORs (XORs) with a plaintext data stream to produce cipher text or to recover plaintext from a
cipher text.
12.3.2.4.3 WEP seed construction
A WEP implementation shall construct a per-MPDU key, called a seed, by concatenating an encryption key
to an IV.
For WEP-40, bits 0–39 of the WEP key correspond to bits 24–63 of the seed, and bits 0–23 of the IV
correspond to bits 0–23 of the seed, respectively. The bit numbering conventions in 9.2.2 apply to the seed.
The seed shall be the input to ARC4, in order to encrypt or decrypt the WEP Data and ICV fields.
NOTE—For WEP-104, bits 0–103 of the WEP key correspond to bits 24–127 of the seed, and bit 0–23 of the IV
correspond to bits 0–23 of the seed, respectively.
The WEP implementation encapsulating an MPDU’s plaintext data should select a new IV for every MPDU
it WEP-protects. The IV selection algorithm is unspecified. The algorithm used to select the encryption key
used to construct the seed is also unspecified.
The WEP implementation decapsulating an MPDU shall use the IV from the received MPDU’s Init Vector
subfield. See 12.3.2.4.5 for the specification of how the decapsulator selects the key to use to construct the
per-MPDU key.
1929
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.3.2.4.4 WEP MPDU cryptographic encapsulation
WEP shall apply three transformations to the plaintext MPDU to effect the WEP cryptographic
encapsulation. WEP computes the ICV over the plaintext data and appends this after the MPDU data. WEP
encrypts the MPDU plaintext data and ICV using ARC4 with a seed constructed as specified in 12.3.2.4.3.
WEP encodes the IV and key identifier into the IV field, prepended to the encrypted Data field.
Figure 12-2 depicts the WEP cryptographic encapsulation process. The ICV shall be computed and
appended to the plaintext data prior to encryption, but the IV encoding step may occur in any order
convenient for the implementation.
IV
Initialization
Seed ARC4 Key Stream
Vector (IV)
|| PRNG
Cipher
WEP Key
text
Plaintext
||
CRC-32
Integrity Check Value (ICV)
Message
Figure 12-2—WEP encapsulation block diagram
12.3.2.4.5 WEP MPDU decapsulation
WEP shall apply three transformations to the WEP MPDU to decapsulate its payload. WEP extracts the IV
and key identifier from the received MPDU. If a key-mapping key is present for the pair, then this
shall be used as the WEP key. Otherwise, the key identifier is extracted from the Key ID subfield of the
WEP IV field in the received MPDU, identifying the default key to use.
WEP uses the constructed seed to decrypt the Data field of the WEP MPDU; this produces plaintext data and
an ICV. Finally WEP recomputes the ICV and bitwise compares it with the decrypted ICV from the MPDU.
If the two are bitwise identical, then WEP removes the IV and ICV from the MPDU, which is accepted as
valid. If they differ in any bit position, WEP generates an error indication to MAC management. MSDUs
with erroneous MPDUs (due to inability to decrypt) shall not be passed to LLC.
Figure 12-3 depicts a block diagram for WEP decapsulation. Unlike cryptographic encapsulation, the
decapsulation steps shall be in the indicated order.
WEP Key
Key
|| Seed Plaintext
ARC4 Stream
PRNG
IV
ICV'
Integrity algorithm
ICV' = ICV?
Cipher ICV
text
Message
Figure 12-3—WEP decapsulation block diagram
1930
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.3.3 Pre-RSNA authentication
12.3.3.1 Overview
In an infrastructure BSS, a non-DMG STA shall complete an IEEE 802.11 authentication exchange prior to
association. A DMG STA not in an IBSS shall complete an IEEE 802.11 authentication exchange prior to
association when an authentication algorithm other than the Open System authentication algorithm is
requested. A DMG STA shall not perform an IEEE 802.11 authentication exchange using the Open System
authentication algorithm. An IEEE 802.11 authentication exchange is optional in an IBSS.
All Authentication frames shall be individually addressed, as IEEE 802.11 authentication is performed
between pairs of STAs, i.e., group addressed authentication is not allowed. Deauthentication frames are
advisory and may be sent as group addressed frames.
Shared Key authentication is deprecated and should not be implemented except for backward compatibility
with pre-RSNA STAs.
12.3.3.2 Open System authentication
12.3.3.2.1 General
Open System authentication is a null authentication algorithm.
Any non-DMG STA requesting Open System authentication can be authenticated if
dot11AuthenticationAlgorithmsTable at the peer STA includes an entry with dot11AuthenticationAlgorithm
equal to openSystem and dot11AuthenticationAlgorithmActivated equal to true.
A STA may decline to authenticate with another requesting STA. Open System authentication is the default
authentication algorithm for a pre-RSNA STA.
Open System authentication utilizes a two-message authentication transaction sequence. The first message
asserts identity and requests authentication. The second message returns the authentication result. If the
result is “successful,” the STAs shall be declared mutually authenticated.
In the description in 12.3.3.2.2 and 12.3.3.2.3, the STA initiating the authentication exchange is referred to
as the requester, and the STA to which the initial frame in the exchange is addressed is referred to as the
responder. The specific items in each of the messages described in the following subclauses are defined in
9.3.3.12, Table 9-35, and Table 9-36.
12.3.3.2.2 Open System authentication (first frame)
Upon receipt of an Open System MLME-AUTHENTICATE.request primitive, the requester shall construct
an Open System authentication request carried in an Authentication frame and transmit it to the responder.
12.3.3.2.3 Open System authentication (final frame)
Upon receipt of an Authentication frame requesting Open System authentication, the responder may
authenticate the requester using the following procedure:
a) Issue an MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication
request.
b) Construct and transmit a response carried in an Authentication frame with the fields as defined in
9.3.3.12 and the status field as defined in 9.4.1.9.
1931
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If dot11AuthenticationAlgorithmTable does not include an entry with dot11AuthenticationAlgorithm equal
to openSystem and dot11AuthenticationAlgorithmActivated equal to true, the result code shall not take the
value “successful.”
12.3.3.3 Shared Key authentication
12.3.3.3.1 General
Shared Key authentication seeks to authenticate STAs as either a member of those who know a shared secret
key or a member of those who do not.
Shared Key authentication may be used if WEP has been selected and shall not be used otherwise.
This mechanism uses a shared key delivered to participating STAs via a secure channel that is independent
of IEEE Std 802.11. This shared key is set in a write-only MIB attribute with the intent to keep the key value
internal to the STA.
A STA shall not initiate a Shared Key authentication exchange unless dot11PrivacyOptionImplemented is
true.
In the description in 12.3.3.3.2 to 12.3.3.3.6, the STA initiating the authentication exchange is referred to as
the requester, and the STA to which the initial frame in the exchange is addressed is referred to as the
responder. The specific items in each of the messages described in the following subclauses are defined in
9.3.3.12, Table 9-35, and Table 9-36.
12.3.3.3.2 Shared Key authentication (first frame)
Upon receipt of a Shared Key MLME-AUTHENTICATE.request primitive, the requester shall construct a
Shared Key authentication request carried in an Authentication frame and transmit it to the responder.
12.3.3.3.3 Shared Key authentication (second frame)
Upon receipt of an Authentication frame requesting Shared Key authentication, the responder may
authenticate the requester using the procedure here and in the following two frames:
a) Issue an MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication
request.
b) Before sending the second frame in the Shared Key authentication sequence, the responder shall use
WEP to generate a string of octets to be used as the authentication challenge text.
c) Construct and transmit to the requester a response carried in an Authentication frame with the fields
as defined in 9.3.3.12 and the status field as defined in 9.4.1.9.
If the status code is not SUCCESS, this shall be the last frame of the transaction sequence; and the content of
the challenge text field is unspecified.
If the status code is SUCCESS, the following additional information items shall have valid contents:
— Authentication algorithm dependent information = The challenge text
— This authentication result shall be of fixed length of 128 octets. The field shall be filled with octets
generated by the WEP PRNG. The actual value of the challenge field is unimportant, but the value
shall not be a static value.
1932
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.3.3.3.4 Shared Key authentication (third frame)
The requester shall copy the challenge text from the second frame into a third Authentication frame. The
third frame shall be transmitted to the responder after cryptographic encapsulation by WEP, as defined in
12.3.2, using the shared key.
12.3.3.3.5 Shared Key authentication (final frame)
The responder shall WEP-decapsulate the third frame as described in 12.3.2. If the WEP ICV check is
successful, the responder shall compare the decrypted contents of the Challenge Text field with the
challenge text sent in second frame. If they are the same, then the responder shall transmit an Authentication
frame to the requester with a successful status code in the final frame of the sequence. If the WEP ICV check
fails or challenge text comparison fails, the responder shall respond with an unsuccessful status code in final
frame.
12.3.3.3.6 Shared key MIB attributes
To transmit a Management frame of subtype Authentication, with an Authentication Transaction Sequence
Number field value of 2, the MAC shall operate according to the following decision tree:
if dot11PrivacyOptionImplemented is false then
the MMPDU is transmitted with a sequence of 0 octets in the Challenge Text field and a status
code value of UNSUPPORTED_AUTH_ALGORITHM
else
the MMPDU is transmitted with a sequence of 128 octets generated using the WEP PRNG and
a key whose value is unspecified and beyond the scope of this standard and a randomly chosen
IV value (note that this is typically selected by the same mechanism for choosing IV values for
transmitted Data frames) in the Challenge Text field and a status code value of SUCCESS (the
IV used is immaterial and is not transmitted). Note that there are cryptographic issues involved
in the choice of key/IV for this process as the challenge text is sent unencrypted and, therefore,
provides a known output sequence from the PRNG.
endif
To receive a Management frame of subtype Authentication, with an Authentication Transaction Sequence
Number field value of 2, the MAC shall operate according to the following decision tree:
if the Protected Frame subfield of the Frame Control field is 1 then
respond with a status code value of CHALLENGE_FAILURE
else
if dot11PrivacyOptionImplemented is true then
if there is a mapping in dot11WEPKeyMappings matching the MSDU’s TA then
if that key is null then
respond with a frame whose Authentication Transaction Sequence Number field
is 3 that contains the appropriate authentication algorithm number, a status code
value of CHALLENGE_FAILURE, and no Challenge Text field, without
encrypting the contents of the frame
else
respond with a frame whose Authentication Transaction Sequence Number field
is 3 that contains the appropriate authentication algorithm number, a status code
value of SUCCESS, and the identical Challenge Text field, encrypted using that
key, and setting the Key ID subfield in the IV field to 0
endif
else
if dot11WEPDefaultKeys[dot11WEPDefaultKeyID] is null then
1933
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
respond with a frame whose Authentication Transaction Sequence Number field
is 3 that contains the appropriate authentication algorithm number, a status code
value of CHALLENGE_FAILURE, and no Challenge Text field, without
encrypting the contents of the frame
else
respond with a frame whose Authentication Transaction Sequence Number field
is 3 that contains the appropriate authentication algorithm number, a status code
value of SUCCESS, and the identical Challenge Text field, WEP-encapsulating
the frame under the key dot11WEPDefaultKeys[dot11WEPDefaultKeyID], and
setting the Key ID subfield in the IV field to dot11WEPDefaultKeyID
endif
endif
else
respond with a frame whose Authentication Transaction Sequence Number field is 3 that
contains the appropriate authentication algorithm number, a status code value of
UNSUPPORTED_AUTH_ALGORITHM, and no Challenge Text field, without
encrypting the contents of the frame
endif
endif
When receiving a Management frame of subtype Authentication, with an Authentication Transaction
Sequence Number field value of 3, the MAC shall operate according to the following decision tree:
if the Protected Frame subfield of the Frame Control field is 0 then
respond with a status code value of CHALLENGE_FAILURE
else
if dot11PrivacyOptionImplemented is true then
if there is a mapping in dot11WEPKeyMappings matching the MSDU’s TA then
if that key is null then
respond with a frame whose Authentication Transaction Sequence Number field
is 4 that contains the appropriate authentication algorithm number and a status
code value of CHALLENGE_FAILURE without encrypting the contents of the
frame
else
WEP-decapsulate with that key, incrementing dot11WEPICVErrorCount and
responding with a status code value of CHALLENGE_FAILURE if the ICV
check fails
endif
else
if dot11WEPDefaultKeys[dot11WEPDefaultKeyID] is null then
respond with a frame whose Authentication Transaction Sequence Number field
is 4 that contains the appropriate authentication algorithm number and a status
code value of CHALLENGE_FAILURE without encrypting the contents of the
frame
else
WEP-decapsulate with dot11WEPDefaultKeys[dot11WEPDefaultKeyID],
incrementing dot11WEPICVErrorCount and responding with a status code
value of CHALLENGE_FAILURE if the ICV check fails
endif
endif
else
respond with a frame whose Authentication Transaction Sequence Number field is 4 that
contains the appropriate authentication algorithm number and a status code value of
CHALLENGE_FAILURE
1934
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
endif
endif
dot11PrivacyInvoked shall not take the value of true if dot11PrivacyOptionImplemented is false. Setting
dot11WEPKeyMappings to a value that includes more than dot11WEPKeyMappingLengthImplemented
entries is illegal and shall have an implementation-specific effect on the operation of the data confidentiality
service. Note that dot11WEPKeyMappings may contain from zero to
dot11WEPKeyMappingLengthImplemented entries, inclusive.
The values of the attributes in the aPrivacygrp should not be changed during the authentication sequence, as
unintended operation may result.
12.4 Authentication using a password
12.4.1 SAE overview
STAs, both AP STAs and non-AP STAs, may authenticate each other by proving possession of a password.
Authentication protocols that employ passwords need to be resistant to off-line dictionary attacks.
Simultaneous authentication of equals (SAE) is a variant of Dragonfly, a password-authenticated key
exchange based on a zero-knowledge proof. SAE is used by STAs to authenticate with a password; it has the
following security properties:
— The successful termination of the protocol results in a PMK shared between the two STAs.
— An attacker is unable to determine either the password or the resulting PMK by passively observing
an exchange or by interposing itself into the exchange by faithfully relaying messages between the
two STAs.
— An attacker is unable to determine either the password or the resulting shared key by modifying,
forging, or replaying frames to an honest, uncorrupted STA.
— An attacker is unable to make more than one guess at the password per attack. This implies that the
attacker cannot make one attack and then go offline and make repeated guesses at the password until
successful. In other words, SAE is resistant to dictionary attack.
— Compromise of a PMK from a previous run of the protocol does not provide any advantage to an
adversary attempting to determine the password or the shared key from any other instance.
— Compromise of the password does not provide any advantage to an adversary in attempting to
determine the PMK from the previous instance.
Unlike other authentication protocols SAE does not have a notion of an “Initiator” and “Responder” or of a
“Supplicant” and “Authenticator.” The parties to the exchange are equals, with each side being able to
initiate the protocol. Each side may initiate the protocol simultaneously such that each side views itself as
the “initiator” for a particular run of the protocol. Such a peer-to-peer protocol may be used in a traditional
client-server (or Supplicant/Authenticator) fashion but the converse does not hold. This requirement is
necessary to address the unique nature of MBSSs.
The parties involved are called STA-A and STA-B. They are identified by their MAC addresses, STA-
A-MAC and STA-B-MAC, respectively. STAs begin the protocol when they discover a peer by receiving
Beacon or Probe Response frame(s), or when they receive an Authentication frame indicating SAE
authentication from a peer.
SAE is an RSNA authentication protocol and is selected according to 12.6.2.
SAE shall be implemented on all mesh STAs to facilitate and promote interoperability.
1935
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.4.2 Assumptions on SAE
SAE uses various functions and data to accomplish its task and assumes certain properties about each
function. These are as follows:
— H is an “extractor” function (see IETF RFC 5869) that concentrates potentially dispersed entropy
from an input to create an output that is a cryptographically strong, pseudorandom key. This
function takes as input a non-secret “salt” and a secret input keying material “ikm” and produces a
fixed-length output.
— CN is a confirmation function that takes a secret key and data to confirm and bind to the exchange.
— A finite cyclic group is negotiated for which solving the discrete logarithm problem is
computationally infeasible.
When used with AKMs 00-0F-AC:8 or 00-0F-AC:9 from Table 9-133, H is instantiated as HMAC-
SHA-256:
H(salt, ikm) = HMAC-SHA-256(salt, ikm)
When used with AKMs 00-0F-AC:8 or 00-0F-AC:9 from Table 9-133, CN is instantiated as a function that
takes a key, a counter, and a sequence of data. Each piece of data is converted to an octet string and
concatenated together before being concatenated to the counter and passed, along with the key, to HMAC-
SHA-256:
CN(key, counter, X, Y, Z, …) = HMAC-SHA-256(key, counter || D2OS(X) || D2OS(Y) || D2OS(Z) || …)
where D2OS() represents the data to octet string conversion functions in 12.4.7.2. Each invocation of CN()
specifies the format of the counter.
Other instantiations of functions H and CN require creation of a new AKM identifier.
12.4.3 Representation of a password
Passwords are used in SAE to deterministically compute a secret element in the negotiated group, called a
password element. The input to this process needs to be in the form of a binary string. For the protocol to
successfully terminate, it is necessary for each side to produce identical binary strings for a given password,
even if that password is in character format. There is no canonical binary representation of a character and
ambiguity exists when the password is a character string. To eliminate this ambiguity, a STA shall represent
a character-based password as an ASCII string. Representation of a character-based password in another
character set or use of a password preprocessing technique (to map a character string to a binary string) may
be agreed upon, in an out-of-band fashion, prior to beginning SAE. If the password is already in binary form
(e.g., it is a binary preshared key) no character set representation is assumed. The binary representation of
the password, after being transformed from a character representation or directly if it is already in binary
form, is stored in the dot11RSNConfigPasswordValueTable. When a “password” is called for in the
description of SAE that follows the credential from the dot11RSNConfigPasswordValueTable is used.
12.4.4 Finite cyclic groups
12.4.4.1 General
SAE uses discrete logarithm cryptography to achieve authentication and key agreement. Each party to the
exchange derives ephemeral public and private keys with respect to a particular set of domain parameters
that define a finite cyclic group. Groups may be based on either Finite Field Cryptography (FFC) or on
Elliptic Curve Cryptography (ECC). Each component of a group is referred to as an element. Groups are
negotiated using an identifying number from a repository maintained by IANA as “Group Description”
1936
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
attributes for IETF RFC 2409 (IKE) [B17][B31]. The repository maps an identifying number to a complete
set of domain parameters for the particular group. For the purpose of interoperability, a STA shall support
group 19, an ECC group defined over a 256-bit prime order field.
More than one group may be configured on a STA for use with SAE by using the
dot11RSNAConfigDLCGroup table. Configured groups are prioritized in ascending order of preference. If
only one group is configured, it is, by definition, the most preferred group.
NOTE—The preference of one group over another is a local policy issue.
SAE uses three arithmetic operators defined for both FFC and ECC groups, an operation that takes two
elements to produce a third element (called the element operation), an operation that takes an integer (called
scalar) and an element to produce a second element (called the scalar operation), and an operation that
takes an element to produce a second element (called the inverse operation). The convention used here is to
represent group elements in uppercase bold italic and scalar values in lowercase italic. The element
operation takes two elements, X and Y, to produce a third element, Z, and is denoted Z = elem-op(X,Y); the
scalar operation takes a scalar, x, and an element, Y, to produce a second element Z and is denoted Z =
scalar-op(x,Y); the inverse operation takes an element, X, to produce a second element, Z, and is denoted Z =
inverse-op(X).
scalar-op(x,Y) is defined as successive iterations of elem-op(Y, Y). That is, it is possible to define scalar-
op(1, Y) = Y and for x > 1, scalar-op(x, Y) = elem-op(scalar-op(x-1, Y), Y). The specific definition of elem-
op(X,Y) depends on the type of group, either ECC or FFC.
12.4.4.2 Elliptic curve cryptography (ECC) groups
12.4.4.2.1 ECC group definition
ECC groups used by SAE are defined by the sextuple (p, a, b, G, r, h) where p is a prime number, a and b
specify the elliptic curve defined by the equation, y2 = x3 + ax + b mod p, G is a generator (a base point on
the elliptic curve), r is the prime order of G, and h is the co-factor. Elements in ECC groups are the points on
the elliptic curve defined by their coordinates—(x, y)—that satisfy the equation for the curve and the identity
element, the so-called “point at infinity.”
The IANA registry used to map negotiated numbers to group domain parameters includes some ECC groups
defined over a characteristic 2 finite field and may include some ECC groups with a co-factor greater than 1.
These groups shall not be used with SAE. Only ECC groups defined over an odd prime finite field with a co-
factor equal to 1 shall be used with SAE.
The element operation in an ECC group is addition of two points on the curve resulting in a third point on
the curve. For example, the point X is added to the point Y to produce the point Z:
Z = X + Y = elem-op(X,Y)
The scalar operation in an ECC group is multiplication of a point on the curve by a scalar resulting in a
second point on the curve. For example, the point Y is multiplied by the scalar x to produce the point Z:
Z = xY = scalar-op(x,Y)
The inverse operation in an ECC group is inversion of a point on a curve resulting in a second point on the
curve. A point on an elliptic curve is the inverse of a different point if their sum is the “point at infinity.” In
other words:
elem-op(X, inverse(X)) = “point at infinity”
1937
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ECC groups make use of a mapping function, F, that maps a point (x, y) that satisfies the curve equation to
its x-coordinate—i.e., if P = (x, y) then F(P) = x. Function F is not defined with the identity element as input.
NOTE—SAE protocol operations preclude function F from ever being called with the identity element, i.e., the “point at
infinity.”
12.4.4.2.2 Generation of the password element with ECC groups
The password element of an ECC group (PWE) shall be generated in a random hunt-and-peck fashion. The
password and a counter, represented as a single octet and initially set to 1, are used with the peer identities to
generate a password seed. The password seed shall then be stretched using the key derivation function
(KDF) from 12.7.1.7.2 to a length equal to the bit length of the prime number, p, from the elliptic curve
domain parameters with the Label being the string “SAE Hunting and Pecking” and with the Context being
the prime number. If the resulting password value is greater than or equal to the prime number, the counter
shall be incremented, a new password seed shall be derived and the hunting-and-pecking shall continue.
Otherwise, it shall be used as the x-coordinate of a candidate point (x, y) on the curve satisfying the curve
equation, if such a point exists. If no solution exists, the counter shall be incremented, a new password-seed
shall be derived and the hunting-and-pecking shall continue. Otherwise, there are two possible solutions: (x,
y) and (x, p – y). The password seed shall be used to determine which one to use: if the least-significant bit
(LSB) of the password seed is equal to that of y, the PWE shall be set to (x, y); otherwise, it shall be set to (x,
p – y).
In order to minimize the possibility of side-channel attacks that attempt to determine the number of
interactions of the “hunting-and-pecking” loop required for a given tuple, implementations should perform at least k iterations regardless of whether PWE is discovered
or not. The value k may be set to any non-negative value and should be set to a sufficiently large number to
effectively guarantee the discovery of PWE in less than k iterations. If PWE is discovered in less than k
iterations a random “password” can be used in subsequent iterations to further obfuscate the true cost of
discovering PWE.
NOTE—The probability that one requires more than n iterations of the “hunting and pecking” loop to find PWE is
roughly (r/2p)n, which rapidly approaches 0 as n increases.
Algorithmically this process is described as follows:
found = 0;
counter = 1
Length = len(p)
base = password
do {
pwd-seed = H(MAX(STA-A-MAC, STA-B-MAC) || MIN(STA-A-MAC, STA-B-MAC),
base || counter)
pwd-value = KDF-Hash-Length(pwd-seed, “SAE Hunting and Pecking”, p)
if (pwd-value < p)
then
if (pwd-value3 + a × pwd-value + b) is a quadratic residue modulo p
then
if (found==0)
then
x = pwd-value
save = pwd-seed
found = 1
base = a new random number
fi
fi
fi
1938
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
counter = counter + 1
} while ((counter <= k) or (found==0))
y = sqrt(x3 + ax + b) mod p
if (LSB(save) == LSB(y))
then
PWE = (x, y)
else
PWE = (x, p – y)
fi
where
KDF-Hash-Length is the key derivation function defined in 12.7.1.7.2 using the hash algorithm iden-
tified by the AKM suite selector (see Table 9-133)
len() returns the length of its argument in bits
Checking whether a value is a quadratic residue modulo a prime can leak information that can be used in
launching a side-channel attack. Therefore, a STA should use this blinding technique in determining a
quadratic residue to address the possibility of a side-channel attack.
The blinding technique involves multiplication of the value with a random number so the value being
checked for quadratic residue modulo a prime can take on all numbers between 1 and p–1 with equal
probability. The blinded value is multiplied by a quadratic residue or quadratic non-residue depending on
the value of a coin flip and the result is checked whether the result is a quadratic residue or quadratic non-
residue, respectively.
This technique involves creation of a quadratic residue, qr, and quadratic non-residue, qnr, prior to
beginning of the hunting-and-pecking loop. These values can be chosen at random by checking their
legendre symbol:
do {
qr = random() mod p
} while ( LGR(qr | p) is not equal to –1)
do {
qnr = random() mod p
} while ( LGR(qnr | p) is not equal to 1)
The blinding technique of determining whether a value, v, is a quadratic residue modulo a prime, p, is then:
r = (random() mod (p – 1)) + 1
num = (v × r × r) mod p
if (LSB(r) == 1)
then
num = (num × qr) mod p
if (LGR(num | p) == 1)
then
v is a quadratic residue modulo p
fi
else
num = (num × qnr) mod p
if (LGR(num | p) == –1)
then
v is a quadratic residue modulo p
1939
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
fi
fi
v is a quadratic non-residue modulo p
The values qr and qnr may be used for all loops in the hunting-and-pecking process but a new value for r
shall be generated each time a quadratic residue is checked.
12.4.4.3 Finite field cryptography (FFC) groups
12.4.4.3.1 FFC group definition
FFC groups used by SAE are defined by the triple (p, G, r), where p is a prime number, G is a generator, and
r is the prime order of G mod p. An element, B, in an FFC group satisfies B = Gi mod p for some integer i.
This special property differentiates elements from scalars, even though both elements and scalars can be
represented as non-negative integers less than the prime modulus p. The notation convention of 12.4.4
signifies this difference between an element and a scalar in an FFC group. The identity element for an FFC
group is the value 1 mod p.
The element operation in an FFC group is modular multiplication of two elements of this group resulting in
a third element of this group. For example, the element X is multiplied by the element Y to product the
element Z:
Z = (XY) mod p = elem-op(X,Y)
The scalar operation in an FFC group is modular exponentiation of an element of this group by a scalar
resulting in a second element of this group. For example, the point Y is raised to the power x to produce the
element Z:
Z = Yx mod p = scalar-op(x,Y)
Some FFC groups in the IANA repository are based on safe primes, i.e., a prime, p, of the form p = 2q + 1,
where q is also a prime number. For these FFC groups, the group generated by G always has order r = (p –
1)/2 and thus is uniquely derived from context. For other FFC groups, the parameter r shall be explicitly
stated as part of the domain parameters.
The inverse operation in an FFC group is modular inversion of an element of this group producing a second
element in this group. An element Z is the inverse of a second element X of this group if their modular
product is the identity element of the FFC group. In other words:
elem-op(X, inverse(X)) = 1 mod p
In contrast to ECC groups, FFC groups do not need a mapping function that maps an element of the FFC
group to an integer (since those elements are already non-negative integers less than the prime number, p).
However, for sake of uniform protocol definition, function F with FFC groups is defined as the identity
function—i.e., if x is an element of the FFC group then F(x) = x.
12.4.4.3.2 Generation of the password element with FFC groups
The password element of an FFC group (PWE) shall be generated in a random hunt-and-peck fashion
similar to the technique for an ECC group. The password and a counter, represented as a single octet and
initially set to 1, are used with the two peer identities to generate a password seed. The password seed shall
then be stretched using the key derivation function (KDF) from 12.7.1.7.2 to a length equal to the bit length
1940
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
of the prime number, p, from the group domain parameters with the Label being the string “SAE Hunting
and Pecking” and the Content being the prime number. If the resulting password value is greater than or
equal to the prime number, the counter shall be incremented, a new password seed shall be derived, and the
hunting-and-pecking shall continue. Otherwise, it shall be raised to the power (p – 1) / r (where p is the
prime number and r is the order) modulo the prime number to produce a candidate PWE. If the candidate
PWE is greater than 1, the candidate PWE becomes the PWE; otherwise, the counter shall be incremented, a
new password seed shall be derived, and the hunting-and-pecking shall continue.
Algorithmically this process is described as follows:
found = 0;
counter = 1
Length = len(p)
do {
pwd-seed = H(MAX(STA-A-MAC, STA-B-MAC) || MIN(STA-A-MAC, STA-B-MAC),
password || counter)
pwd-value = KDF-Hash-Length(pwd-seed, “SAE Hunting and Pecking”, p)
if (pwd-value < p)
then
PWE = pwd-value(p-1)/r mod p
if (PWE > 1)
then
found = 1
fi
fi
counter = counter + 1
} while (found==0)
where
KDF-Hash-Length is the key derivation function defined in 12.7.1.7.2 using the hash algorithm iden-
tified by the AKM suite selector (see Table 9-133)
len() returns the length of its argument in bits
12.4.5 SAE protocol
12.4.5.1 Message exchanges
The protocol consists of two message exchanges, a commitment exchange and a confirmation exchange.
The commitment exchange is used to force each party to the exchange to commit to a single guess of the
password. The confirmation exchange is used to prove that the password guess was correct. Authentication
frames are used to perform these exchanges (see 9.3.3.12 and 12.4.7.3). The rules for performing these
exchanges are specified by the finite state machine in 12.4.8.
When a party has sent its message in the commit exchange it is said to have committed and when it has sent
its message in the confirmation exchange it has confirmed. The following rules are ascribed to the protocol:
— A party may commit at any time
— A party confirms after it has committed and its peer has committed
— A party accepts authentication after a peer has confirmed
— The protocol successfully terminates after each peer has accepted
1941
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.4.5.2 PWE and secret generation
Prior to beginning the protocol message exchange, the secret element PWE and two secret values are
generated. First, a group is selected, either the most preferred group if the STA is initiating SAE to a peer, or
the group from a received SAE Commit message if the STA is responding to a peer. The PWE shall be
generated for that group (according to 12.4.4.2.2 or 12.4.4.3.2, depending on whether the group is ECC or
FFC, respectively) using the identities of the two STAs and the configured password.
After generation of the PWE, each STA shall generate a secret value, rand, and a temporary secret value,
mask, each of which shall be chosen randomly such that 1 < rand < r and 1 < mask < r and (rand + mask)
mod r is greater than 1, where r is the (prime) order of the group. If their sum modulo r is not greater than 1,
they shall both be irretrievably deleted and new values shall be randomly generated. The values rand and
mask shall be random numbers produced from a quality random number drawn from a uniform distribution
generator. These values shall never be reused on distinct protocol runs.
12.4.5.3 Construction of an SAE Commit message
An SAE Commit message consists of a scalar and an element that shall be produced using the PWE and
secrets generated in 12.4.5.2, as follows:
commit-scalar = (rand + mask) mod r
COMMIT-ELEMENT = inverse(scalar-op(mask, PWE))
This message shall be transmitted to the peer as described in 12.4.7. The temporary secret mask may be
deleted at this point.
12.4.5.4 Processing of a peer’s SAE Commit message
Upon receipt of a peer’s SAE Commit message both the scalar and element shall be verified.
If the scalar value is greater than 0 and less than the order, r, of the negotiated group, scalar validation
succeeds; otherwise, it fails. Element validation depends on the type of group. For FFC groups, the element
shall be an integer greater than 1 and less than the prime number p minus 1, (p – 1), and the scalar operation
of the element and the order of the group, r, shall equal 1 modulo the prime number p. If either of these
conditions does not hold, element validation fails; otherwise, it succeeds. For ECC groups, both the x- and y-
coordinates of the element shall be non-negative integers less than the prime number p, and the two
coordinates shall produce a valid point on the curve satisfying the group’s curve definition, not being equal
to the “point at the infinity.” If either of those conditions does not hold, element validation fails; otherwise,
element validation succeeds.
If either scalar validation or element validation fails, the STA shall reject the peer’s authentication. If both
the scalar and element from the peer’s SAE Commit message are successfully validated, a shared secret
element, K, shall be derived using the scalar and element (peer-commit-scalar and PEER-COMMIT-
ELEMENT, respectively) from the peer’s SAE Commit message and the STA’s secret value.
K = scalar-op(rand, (elem-op(scalar-op(peer-commit-scalar, PWE),
PEER-COMMIT-ELEMENT)))
If the shared secret element, K, is the identity element for the negotiated group (the value one for an FFC
group or the point-at-infinity for an ECC group) the STA shall reject the peer’s authentication. Otherwise, a
secret value, k, shall be computed as:
k = F(K)
1942
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The entropy of k shall then be extracted using H to produce keyseed. The key derivation function from
12.7.1.7.2 shall then be used with the hash algorithm identified by the AKM suite selector (see Table 9-133)
to derive a key confirmation key, KCK, and a pairwise master key, PMK, from keyseed. When used with
AKMs 8 or 9, the salt shall consist of thirty-two (32) octets of the value 0 (indicated below as <0>32) and
both the KCK and PMK shall be 256 bits in length, and therefore the length of keying material derived is
512. Use of other AKMs require definition of the lengths of the salt, the KCK, and the PMK.
keyseed = H(<0>32, k)
kck_and_pmk = KDF-Hash-512(keyseed, “SAE KCK and PMK”,
(commit-scalar + peer-commit-scalar) mod r)
KCK = L(kck_and_pmk, 0, 256)
PMK = L(kck_and_pmk, 256, 256)
where
KDF-Hash-512 is the key derivation function defined in 12.7.1.7.2 using the hash algorithm defined by
the negotiated AKM in Table 9-133.
The PMK identifier is defined as follows:
PMKID = L((commit-scalar + peer-commit-scalar) mod r, 0, 128)
12.4.5.5 Construction of an SAE Confirm message
A peer generates an SAE Confirm message by passing the KCK, the current value of the send-confirm
counter (see 9.4.1.38), the scalar and element from the sent SAE Commit message, and the scalar and
element from the received SAE Commit message to the confirmation function CN.
confirm = CN(KCK, send-confirm, commit-scalar, COMMIT-ELEMENT, peer-commit-scalar,
PEER-COMMIT-ELEMENT)
The send-confirm counter shall be in the format specified in subclause 9.2.2 in the order in which it is
transmitted over the air. The message shall be transmitted to the peer as described in 12.4.7.
12.4.5.6 Processing of a peer’s SAE Confirm message
Upon receipt of a peer’s SAE Confirm message a verifier is computed, which is the expected value of the
peer’s confirmation, peer-confirm, extracted from the received an SAE Confirm message. The verifier is
computed by passing the KCK, the peer’s send-confirm counter from the received an SAE Confirm message
(see 9.4.1.38), the scalar and element from the received SAE Commit message, and scalar and element from
the sent SAE Commit message to the confirmation function CN.
verifier = CN(KCK, peer-send-confirm, peer-commit-scalar, PEER-COMMIT-ELEMENT,
commit-scalar, COMMIT-ELEMENT)
The peer-send-confirm shall be in the format in subclause 9.2.2, as extracted out of the received frame. If the
verifier equals peer-confirm, the STA shall accept the peer’s authentication and set the lifetime of the PMK
to the value dot11RSNAConfigPMKLifetime. If the verifier differs from the peer-confirm, the STA shall
reject the peer’s authentication and delete the PMK.
12.4.6 Anti-clogging tokens
A STA is required to do a considerable amount of work upon receipt of an SAE Commit message. This
opens up the possibility of a distributed denial-of-service attack by flooding a STA with bogus SAE Commit
1943
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
messages from forged MAC addresses. To prevent this from happening, a STA shall maintain an Open
counter in its SAE state machine indicating the number of open and unfinished protocol instances (see
12.4.5.1). When that counter hits or exceeds dot11RSNASAEAntiCloggingThreshold, the STA shall
respond to each SAE Commit message with a rejection that includes an Anti-Clogging Token statelessly
bound to the sender of the SAE Commit message. The sender of the SAE Commit message shall then
include this Anti-Clogging Token in a subsequent SAE Commit message.
The Anti-Clogging Token is a variable-length value that statelessly binds the MAC address of the sender of
an SAE Commit message. The length of the Anti-Clogging Token needs not be specified because the
generation and processing of the Anti-Clogging Token is solely up to one peer. To the other peer in the SAE
protocol, the Anti-Clogging Token is merely an opaque blob whose length is insignificant. It is suggested
that an Anti-Clogging Token not exceed 256 octets.
NOTE—A suggested method for producing Anti-Clogging Tokens is to generate a random secret value each time the
state machine variable hits dot11RSNASAEAntiCloggingThreshold and pass that secret and the MAC address of the
sender of the SAE Commit message to the random function H to generate the token.
As long as the state machine variable Open is greater than or equal to
dot11RSNASAEAntiCloggingThreshold all SAE Commit messages that do not include a valid Anti-
Clogging Token shall be rejected with a request to repeat the SAE Commit message and include the token
(see 12.4.5.1).
Since the Anti-Clogging Token is of fixed size and the size of the peer-commit-scalar and PEER-
COMMIT-ELEMENT are inferred from the finite cyclic group being used, it is straightforward to
determine whether a received SAE Commit message includes an Anti-Clogging Token or not.
Encoding of the Anti-Clogging Token and its placement with respect to the peer-commit-scalar and PEER-
COMMIT-ELEMENT is described in 12.4.7.4.
12.4.7 Framing of SAE
12.4.7.1 General
SAE Commit messages and SAE Confirm messages are sent and received by a SAE protocol using
Authentication frames.
12.4.7.2 Data type conversion
12.4.7.2.1 General
This protocol requires elements in finite cyclic groups to be converted to octet strings prior to transmission
and back again upon receipt. To convert an element into an octet string, the first step is to represent the
element in integer format and then employ an integer-to-octet string conversion prior to transmission. To
convert an octet string into an element requires an octet string to integer conversion and then representing
the integer(s) as an element.
12.4.7.2.2 Integer to octet string conversion
An integer, x, shall be converted into an octet string of length m such that 28m > x by first representing x in
its binary form and then converting the result to an octet-string.
Given x, m, represent x as a sequence of xm-i base 28:
x = xm-1 28(m-1) + xm-2 28(m-2) + … + x1 28 + x 0
1944
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
then let the octet Mi have the value xi for 0 i m–1, and the octet string shall be Mm-1 || Mm-2 || ... || M1 ||
M0.
12.4.7.2.3 Octet string to integer conversion
An octet string shall be converted into an integer by viewing the octet string as the base 28 representation of
the integer.
m
x= 28(m-i) Mm-i
i=1
12.4.7.2.4 Element to octet string conversion
For ECC groups, each element, except the “point at infinity,” is a point on the elliptic curve satisfying the
curve equation and consists of two components: an x-coordinate and a y-coordinate. To convert this point to
an octet string, each component shall be treated as an integer and converted into an octet string whose length
is the smallest integer m such that 28m > p, where p is the prime number specified by the elliptic curve
domain parameters, according to 12.4.7.2.2. The point shall be represented as the concatenation of the x-
coordinate and the y-coordinate, each represented as an octet string of length m octets, and is 2m octets long.
For FFC groups each element is a non-negative integer less than the prime number p specified by the FFC
domain parameters. To convert this element into an octet string, it shall be treated directly as an integer and
converted into an octet string whose length is the smallest integer m such that 28m > p, where p is the prime
number specified by the domain parameters, according to 12.4.7.2.2.
12.4.7.2.5 Octet string to element conversion
To convert an octet string into a point on an elliptic curve it is necessary to divide it into two octet strings of
equal length m. If the length of the octet string does not evenly divide by two, conversion shall fail. Each
octet string of length m shall be converted to an integer according to 12.4.7.2.3. The first octet string
conversion produces an integer that becomes the x-coordinate of the point and the second octet string
conversion produces an integer that becomes the y-coordinate of the point. If either integer equals 0 or is
greater than or equal to p, the prime from the elliptic curve domain parameters, conversion shall fail. If the
resulting (x, y) point does not satisfy the equation of the curve, or produces the “point at infinity,”
conversion shall fail.
To convert an octet string into an element in a prime modulus group the octet string shall be converted into
an integer according to 12.4.7.2.3 and the integer shall be used directly as the group element.
12.4.7.3 Authentication transaction sequence number for SAE
An SAE Commit message shall use authentication transaction sequence number 1. an SAE Confirm
message shall use authentication transaction sequence number 2.
12.4.7.4 Encoding and decoding of SAE Commit messages
An SAE Commit message shall be encoded as an Authentication frame with an Authentication Algorithm
Number field set to 3, a Transaction Sequence Number of 1 and a Status Code of SUCCESS Status codes
not equal to SUCCESS indicate a rejection of a peer’s SAE Commit message and are described in 12.4.7.6.
An SAE Commit message shall consist of a Finite Cyclic Group field (9.4.1.43) indicating a group, a Scalar
field (9.4.1.40) containing the scalar, and an FFE field containing the element (9.4.1.41). If the SAE Commit
1945
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
message is in response to an Anti-Clogging Token request (see 12.4.7.6), the Anti-Clogging Token is
present (see 9.4.1.39).
When transmitting an SAE Commit message, the scalar and element shall be converted to octet strings and
placed in the Scalar field and FFE field, respectively. The scalar shall be treated as an integer and converted
into an octet string of length m such that 28m > r, where r is the order of the group, according to 12.4.7.2.2,
and the element shall be converted into (an) octet string(s) according to 12.4.7.2.4. When receiving an SAE
Commit message the component octet strings in the Scalar field and Element field shall be converted into a
scalar and element, respectively, according to 12.4.7.2.3 and 12.4.7.2.5, respectively.
12.4.7.5 Encoding and decoding of SAE Confirm messages
An SAE Confirm message shall be encoded as an Authentication frame with an Authentication Algorithm
Number field set to 3, a Transaction Sequence Number of 2 and a Status Code of SUCCESS. Status codes
not equal to SUCCESS indicate rejection of a peer’s SAE Confirm message and are described in 12.4.7.6.
An SAE Confirm message shall consist of a Send-Confirm field (9.4.1.38) and a Confirm field (9.4.1.42)
containing the output of the random function as described in 12.4.5.5. When transmitting an SAE Confirm
message the output of the random function shall be treated as an integer and converted into an octet string of
length m, where m is the block size of the random function, according to 12.4.7.2.2 and placed in the
Confirm field. When receiving an SAE Confirm message, the octet string in the Confirm field shall be
converted into an integer representing the peer’s Confirm according to 12.4.7.2.3.
12.4.7.6 Status codes
An SAE Commit message with a status code not equal to SUCCESS shall indicate that a peer rejects a
previously sent SAE Commit message. An unsupported finite cyclic group is indicated with a status code of
UNSUPPORTED_FINITE_CYCLIC_GROUP, “Authentication is rejected because the offered finite cyclic
group is not supported.” An Anti-Clogging Token is requested by transmitting an SAE Commit message
with a status code of ANTI_CLOGGING_TOKEN_REQUIRED, “Anti-Clogging Token Requested,” with
the Anti-Clogging Token occupying the Token field of the Authentication frame.
An SAE Confirm message, with a status code not equal to SUCCESS, shall indicate that a peer rejects a
previously sent SAE Confirm message. An SAE Confirm message that was not successfully verified is
indicated with a status code of CHALLENGE_FAILURE.
12.4.8 SAE finite state machine
12.4.8.1 General
The protocol is instantiated by the finite state machine in Figure 12-4. Each instance of the protocol is
identified by a tuple consisting of the local MAC address and the peer MAC address. The model in which
SAE is defined consists of a parent process, managed by the SME, which receives messages, and dispatches
them to the appropriate protocol instance, also managed by the SME. The parent process manages a database
of protocol instances indexed by the peer identity. Protocol instances maintain state, receive events from the
parent process, send events to itself, and output data.
NOTE—Figure 12-4 does not show all state machine transitions. A full description of the SAE finite state machine is in
12.4.8.6.2 to 12.4.8.6.6.
The parent process instantiates protocol instances upon receipt of SAE messages and initiation by SME. The
parent process also maintains a counter of the number of protocol instances created.
1946
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(Com,BadGrp)/(1(77),Del)
Rej(76)/Del
Rej(77)/Del
Init/(zero(Sync), zero(Sc),
Zero(Rc), 1(0), set(t0)) Nothing (Com,!BadGrp)/zero(Sync),
zero(Sc), zero(Rc),inc(Sc),
1(0),2,set(t0))
(Com,BadGrp, !big(Sync))/ big(Sync)/Del
(1(77), inc(Sync), (Com,!big(Sync)/(inc(Sc),
set(t0)) Rej(77), big(sync)/Del inc(Sync), 1(0),2,set(t0))
(Rej(77),moregroups)/ !moregroups/Del
(zero(Sync), Rej(76)/
1(0), set(t0)) set(t0)
(Con,BadAuth)/Del
(Con,!big(Sync))/
(inc(Sync),
Committed Confirmed
1(0),set(t0))
(fire(t0),!big(Sync)/
(inc(Sync),1(0),set(t0)) (Com,!BadGrp,!DiffGrp)/
Rej(76)/ (fire(t0),!big(Sync))/
(inc(Sc),
(Com,DiffGrp,highmac)/ (zero(Sync), (inc(Sc),inc(Sync),2,set(t0))
2,set(t0))
(1(0), set(t0)) 1(0),set(t0))
(Com,DiffGrp,lowmac)/
(zero(Sync), inc(Sc),
1(0),2,set(t0))
(Con,!BadAuth)/set(t1))
Accepted
big(Sync)/Del
(Con,!Big(Rc),!big(Sync))/
-
fire(t1)/Del
(Con,!BadAuth,!big(Sync))/
(inc(Sync), 2)
Figure 12-4—SAE finite state machine
12.4.8.2 States
12.4.8.2.1 Parent process states
The parent process is in a continuous quiescent state.
12.4.8.2.2 Protocol instance states
Each protocol instance is in one of the following four states:
— Nothing—The Nothing state represents the initial state of a freshly allocated protocol instance or the
terminal state of a soon-to-be deallocated protocol instance. Freshly created protocol instances will
immediately transition out of Nothing state depending on the reason for their creation. Protocol
instances that transition into Nothing state shall immediately be irretrievably deleted.
— Committed—In the Committed state, the finite state machine has sent an SAE Commit message and
is awaiting an SAE Commit message and an SAE Confirm message from the peer.
— Confirmed—In the Confirmed state, the finite state machine has sent both an SAE Commit message
and an SAE Confirm message and received an SAE Commit message. It awaits an SAE Confirm
message.
— Accepted—In the Accepted state, the protocol instance has both sent and received an SAE Commit
message and an SAE Confirm message and the protocol instance has finished.
1947
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.4.8.3 Events and output
12.4.8.3.1 Parent process events and output
The parent process receives events from three sources: the SME, protocol instances, and received frames.
The SME signals the following events to the parent SAE process:
— Initiate—An Initiate event is used to instantiate a protocol instance to begin SAE with a designated
peer.
— Kill—A Kill event is used to remove a protocol instance with a designated peer.
Protocol instances send the following events to the SAE parent process:
— Fail—The peer failed to be authenticated.
— Auth—The peer was successfully authenticated.
— Del—The protocol instance has had a fatal event.
Receipt of frames containing SAE messages signals the following events to the SAE parent process:
— Authentication frame with Transaction Sequence number 1—This event indicates that an SAE
Commit message has been received from a peer STA.
— Authentication frame with Transaction Sequence number 2—This event indicates that an SAE
Confirm message has been received from a peer STA.
The parent process generates Authentication frames with Authentication transaction sequence 1 and a Status
of 76 indicating rejection of an Authentication attempt because an Anti-Clogging Token is required.
12.4.8.3.2 Protocol instance events and output
The protocol instance receives events from the parent SAE process.
— Com—Indicates receipt of an SAE Commit message (authentication transaction sequence number 1)
with a status of 0.
— Con—Indicates receipt of an SAE Confirm message (authentication transaction sequence number 2)
with a status of 0.
— Init—Indicates that the protocol instance should begin negotiation with a specified peer.
— Rej(N)—Indicates receipt of a rejected SAE Commit message with status N.
In addition, protocol instances receive fire(X) events indicating the expiration of timer X. Upon expiration of
a timer and generation of a fire() event, the expired timer is not reset.
The protocol instance generates output from the following events:
— 1(N)—Indicates generation of an SAE Commit message (authentication transaction sequence
number 1) with status N.
— 2—Indicates generation of an SAE Confirm message (authentication transaction sequence number
2).
12.4.8.4 Timers
The parent SAE process does not use timers. Each protocol instance can set timers that result in fire() events
to be sent to itself. The following timers can be set:
— t0—A retransmission timer.
— t1—A PMK expiration timer.
1948
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Timers are set by the protocol instance issuing a set() for the particular timer.
12.4.8.5 Variables
12.4.8.5.1 Parent process variables
The parent SAE process maintains a counter, Open, which indicates the number of protocol instances in
either Committed or Confirmed state. When the parent SAE process starts up, Open is set to 0.
The parent process maintains a database of protocol instances.
NOTE—Depending on how Anti-Clogging Tokens (see 12.4.6) are constructed, the parent SAE process might also
maintain a random secret used for token creation.
12.4.8.5.2 Protocol instance variables
Each protocol instance maintains the following three variables:
— Sync—The number of state resynchronizations that have occurred.
— Sc—The number of SAE Confirm messages that have been sent. This is the send-confirm counter
used in the construction of SAE Confirm messages (see 12.4.5.5).
— Rc—The received value of the send-confirm counter in the last received SAE Confirm message. In
other words, this is the value of the peer’s send-confirm counter.
Function zero(X) assigns the value 0 to the variable X, inc(X) increments the variable X, and big(X) indicates
that the variable X has exceeded a maximum value.
In addition, protocol instances maintain the following six indicators that are not maintained as state variables
but, instead, indicate the cause of certain behavior.
— BadGrp—The group specified in an SAE Commit message is not supported.
— DiffGrp—The group specified in an SAE Commit message is supported but differs from the one
offered.
— BadConf—The contents of a confirm frame were incorrect.
— highmac—The peer identity is numerically less than the local identity.
— lowmac—The peer identity is numerically greater than the local identity.
— moregroups—There are finite cyclic groups in the configuration that have not been offered to the
peer.
A negative indication is shown with an exclamation point (!)—e.g., “the group specified in an SAE Commit
message is supported” would be !BadGrp, which is read as “not BadGrp.”
12.4.8.6 Behavior of state machine
12.4.8.6.1 Parent process behavior
For any given peer identity, there shall be only one protocol instance in Committed or Confirmed state.
Similarly, for any given peer identity, there shall be only one protocol instance in Accepted state.
The parent process creates protocol instances based upon different actions. Creating a protocol instance
entails allocation of state necessary to maintain the protocol instance state machine, putting the protocol
instance in Nothing state, incrementing the Open counter, and inserting the protocol instance into its
database indexed by the MAC address of the peer with whom the protocol instance will communicate.
1949
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The parent process shall delete protocol instances irretrievably.
Upon receipt of an Initiate event, the parent process shall check whether there exists a protocol instance for
the peer MAC address (from the Init event) in either Committed or Confirmed state. If there is, the Initiate
event shall be ignored. Otherwise, a protocol instance shall be created, and an Init event shall be sent to the
protocol instance.
Upon receipt of a Kill event, the parent process shall delete all protocol instances indexed by the peer MAC
address (from the Kill event) in its database. For each protocol instance in Committed or Confirmed state, the
Open counter shall be decremented.
Upon receipt of a Sync, Del, or Fail event from a protocol instance, the parent process shall decrement the
Open counter and deletes the protocol instance.
Upon receipt of an Auth event from a protocol instance, the parent process shall decrement the Open
counter. If another protocol instance exists in the database indexed by the same peer identity as the protocol
instance that sent the Auth event, the other protocol instance shall be deleted.
Upon receipt of an SAE Commit message, the parent process checks whether a protocol instance for the peer
MAC address exists in the database. If one does, and it is in either Committed state or Confirmed state the
frame shall be passed to the protocol instance. If one does and it is in Accepted state, the scalar in the
received frame is checked against the peer-scalar used in authentication of the existing protocol instance (in
Accepted state). If it is identical, the frame shall be dropped. If not, the parent process checks the value of
Open. If Open is greater than dot11RSNASAEAntiCloggingThreshold, the parent process shall check for
the presence of an Anti-Clogging Token. If an Anti-Clogging Token exists and is correct, the parent process
shall create a protocol instance. If the Anti-Clogging Token is incorrect, the frame shall be silently
discarded. If Open is greater than or equal to dot11RSNASAEAntiCloggingThreshold and there is no Anti-
Clogging Token in the received frame, the parent process shall construct a response as an Authentication
frame with the Authentication Transaction Sequence Number field set to 1, the Status Code field set to
ANTI_CLOGGING_TOKEN_REQUIRED, and the body of the frame consisting of an Anti-Clogging
Token (see 12.4.6). If Open is less than dot11RSNASAEAntiCloggingThreshold, the parent process shall
create a protocol instance and the frame shall be sent to the protocol instance as a Com event.
Upon receipt of an SAE Confirm message, the parent process checks whether a protocol instance for the
peer MAC address (as indicated by the SA in the received frame) exists in the database. If there is a single
protocol instance, the frame shall be passed to it as a Con event. If there are two protocol instances indexed
by that peer MAC address, the frame shall be passed, as a Con event, to the protocol instance that is not in
Accepted state. If there are no protocol instances indexed by that peer MAC address, the frame shall be
dropped.
12.4.8.6.2 Protocol instance behavior—General
State machine behavior is illustrated in Figure 12-4. The protocol instance receives events from the parent
process and from itself. It generates SAE messages that are transmitted to a peer and sends events to itself
and the parent process.
The semantics of the state diagram are “occurrence/behavior” where “occurrence” is a comma-separated list
of events and/or indicators, or the special symbol “—” indicating no occurrence; and, “behavior” is a
comma-separated list of outputs and/or functions, or the special symbol “—” indicating no behavior.
When the state machine calls for the t0 (retransmission) timer to be set, it shall be set to
dot11RSNASAERetransPeriod. When the state machine calls for the t1 (key expiration) timer to be set, it
shall be set to dot11RSNAConfigPMKLifetime.
1950
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.4.8.6.3 Protocol instance behavior - Nothing state
In Nothing state a protocol instance has just been allocated.
Upon receipt of an Init event, the protocol instance shall zero its Sync variable, Rc, and Sc variables, select a
group from local configuration and generate the PWE and the secret values according to 12.4.5.2, generate
an SAE Commit message (see 12.4.5.3), and set its t0 (retransmission) timer. The protocol instance
transitions into Committed state.
Upon receipt of a Com event, the protocol instance shall check the Status of the Authentication frame. If the
Status code is not SUCCESS, the frame shall be silently discarded and a Del event shall be sent to the parent
process. Otherwise, the frame shall be processed by first checking the finite cyclic group field to see if the
requested group is supported. If not, BadGrp shall be set and the protocol instance shall construct and
transmit a an Authentication frame with Status code UNSUPPORTED_FINITE_CYCLIC_GROUP
indicating rejection with the finite cyclic group field set to the rejected group, and shall send the parent
process a Del event. If the group is supported, the protocol instance shall zero the Sc and Rc counters and it
shall generate the PWE and the secret values according to 12.4.5.2. It shall then process the received SAE
Commit message (see 12.4.5.4). If validation of the received SAE Commit message fails, the protocol
instance shall send a Del event to the parent process; otherwise, it shall construct and transmit an SAE
Commit message (see 12.4.5.3) followed by an SAE Confirm message (see 12.4.5.5). The Sync counter shall
be set to 0 and the t0 (retransmission) timer shall be set. The protocol instance transitions to Confirmed state.
NOTE—A protocol instance in Nothing state will never receive an SAE Confirm message due to state machine behavior
of the parent process.
12.4.8.6.4 Protocol instance behavior - Committed state
In Committed state, a protocol instance has sent its peer an SAE Commit message but has yet to receive (and
accept) anything.
Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. Then the following is
performed:
— The protocol instance shall check the Status code of the Authentication frame. If the Status code is
ANTI_CLOGGING_TOKEN_REQUIRED, a new SAE Commit message shall be constructed with
the Anti-Clogging Token from the received Authentication frame, and the commit-scalar and
COMMIT-ELEMENT previously sent. The new SAE Commit message shall be transmitted to the
peer, Sync shall be zeroed, and the t0 (retransmission) timer shall be set.
— If the Status code is UNSUPPORTED_FINITE_CYCLIC_GROUP, the protocol instance shall
check the finite cyclic group field being rejected. If the rejected group does not match the last
offered group the protocol instance shall silently discard the message and set the t0 (retransmission)
timer. If the rejected group matches the last offered group, the protocol instance shall choose a
different group and generate the PWE and the secret values according to 12.4.5.2; it then generates
and transmits a new SAE Commit message to the peer, zeros Sync, sets the t0 (retransmission) timer,
and remains in Committed state. If there are no other groups to choose, the protocol instance shall
send a Del event to the parent process and transitions back to Nothing state.
— If the Status is some other nonzero value, the frame shall be silently discarded and the t0
(retransmission) timer shall be set.
— If the Status is zero, the finite cyclic group field is checked. If the group is not supported, BadGrp
shall be set and the value of Sync shall be checked.
— If Sync is greater than dot11RSNASAESync, the protocol instance shall send a Del event to the
parent process and transitions back to Nothing state.
— If Sync is not greater than dot11RSNASAESync, Sync shall be incremented, an SAE Commit
message with Status code equal to UNSUPPORTED_FINITE_CYCLIC_GROUP indicating
1951
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
rejection, and the Algorithm identifier set to the rejected algorithm shall be sent to the peer, the
t0 (retransmission) timer shall be set and the protocol instance shall remain in Committed state.
— If the group is supported but does not match that used when the protocol instance constructed its
SAE Commit message, DiffGrp shall be set and the local identity and peer identity shall be checked.
— The mesh STA, with the numerically greater of the two MAC addresses, drops the received
SAE Commit message, retransmits its last SAE Commit message, and shall set the t0
(retransmission) timer and remain in Committed state.
— The mesh STA, with the numerically lesser of the two MAC addresses, zeros Sync, shall
increment Sc, choose the group from the received SAE Commit message, generate new PWE
and new secret values according to 12.4.5.2, process the received SAE Commit message
according to 12.4.5.4, generate a new SAE Commit message and SAE Confirm message, and
shall transmit the new Commit and Confirm to the peer. It shall then transition to Confirmed
state.
— If the group is supported and matches that used when the protocol instance constructed its SAE
Commit message, the protocol instance checks the peer-commit-scalar and PEER-COMMIT-
ELEMENT from the message. If they match those sent as part of the protocol instance’s own SAE
Commit message, the frame shall be silently discarded (because it is evidence of a reflection attack)
and the t0 (retransmission) timer shall be set. If the received element and scalar differ from the
element and scalar offered, the received SAE Commit message shall be processed according to
12.4.5.4, the Sc counter shall be incremented (thereby setting its value to one), the protocol instance
shall then construct an SAE Confirm message, transmit it to the peer, and set the t0 (retransmission)
timer. It shall then transition to Confirmed state.
If the t0 (retransmission) timer fires, the value of the Sync counter is checked. If Sync is greater than
dot11RSNASAESync, the protocol instance shall send a Del event to the parent process and transition back
to Nothing state. If Sync is not greater than dot11RSNASAESync, the Sync counter shall be incremented, the
last message sent shall be sent again, and the t0 (retransmission) timer shall be set.
Upon receipt of a Con event, the t0 (retransmission) timer shall be canceled. Then the protocol instance
checks the value of Sync. If it is greater than dot11RSNASAESync, the protocol instance shall send a Del
event to the parent process and transition back to Nothing state. If Sync is not greater than
dot11RSNASAESync, the protocol instance shall increment Sync, transmit the last SAE Commit message
sent to the peer, and set the t0 (retransmission) timer.
12.4.8.6.5 Protocol instance behavior - Confirmed state
In Confirmed state, a protocol instance has sent its peer an SAE Commit message and SAE Confirm
message. It has received an SAE Commit message from its peer.
Rejection frames received in Confirmed state shall be silently discarded.
Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. If the Status is nonzero, the
frame shall be silently discarded, the t0 (retransmission) timer set, and the protocol instance shall remain in
the Confirmed state. If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent
process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync,
the protocol instance shall verify that the finite cyclic group is the same as the previously received Commit
frame. If not, the frame shall be silently discarded. If so, the protocol instance shall increment Sync,
increment Sc, and transmit its Commit and Confirm (with the new Sc value) messages. It then shall set the t0
(retransmission) timer.
Upon receipt of a Con event, the t0 (retransmission) timer shall be canceled and the SAE Confirm message
shall be processed according to 12.4.5.6. If processing is successful and the SAE Confirm message has been
1952
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
verified, the Rc variable shall be set to the send-confirm portion of the frame, Sc shall be set to the value
216 – 1, the t1 (key expiration) timer shall be set, and the protocol instance shall transition to Accepted state.
If the t0 (retransmission) timer fires, the value of the Sync counter shall be checked. If Sync is greater than
dot11RSNASAESync, the protocol instance shall send a Del event to the parent process and transition back
to Nothing state. If Sync is not greater than dot11RSNASAESync, the Sync counter shall be incremented, Sc
shall be incremented, and the protocol instance shall create a new Confirm (with the new Sc value) Message,
transmit it to the peer, and set the t0 (retransmission) timer.
12.4.8.6.6 Protocol instance behavior - Accepted state
In Accepted state, a protocol instance has sent an SAE Commit message and an SAE Confirm message to its
peer and received an SAE Commit message and SAE Confirm message from the peer. Unfortunately, there
is no guarantee that the final SAE Confirm message sent by the STA was received by the peer.
Upon receipt of a Con event, the Sync counter shall be checked. If the value is greater than
dot11RSNASAESync, the protocol instance shall send a Del event to the parent process and shall transition
to Nothing state. If the value of Sync is not greater than dot11RSNASAESync, the value of send-confirm
shall be checked. If the value is not greater than Rc or is equal to 216 – 1, the received frame shall be silently
discarded. Otherwise, the Confirm portion of the frame shall be checked according to 12.4.5.6. If the
verification fails, the received frame shall be silently discarded. If the verification succeeds, the Rc variable
shall be set to the send-confirm portion of the frame, the Sync shall be incremented and a new SAE Confirm
message shall be constructed (with Sc set to 216 – 1) and sent to the peer. The protocol instance shall remain
in Accepted state.
If the t1 (key expiration) timer fires, the protocol instance shall send the parent process a Del event and
transition to Nothing state.
12.5 RSNA confidentiality and integrity protocols
12.5.1 Overview
This standard defines the following RSNA data confidentiality and integrity protocols: TKIP, CCMP, and
GCMP. This standard defines one integrity protocol for Management frames: BIP.
Implementation of TKIP is optional for an RSNA and used only for the protection of Data frames. A design
aim for TKIP was that the algorithm should be implementable within the capabilities of most devices
supporting only WEP, so that many such devices would be field-upgradable by the supplier to support TKIP.
BIP is a mechanism that is used only when management frame protection is negotiated. BIP provides
integrity protection for group addressed robust Management frames. BIP is used only to protect
Management frames within the BSS.
12.5.2 Temporal key integrity protocol (TKIP)
12.5.2.1 TKIP overview
12.5.2.1.1 General
The TKIP is a cipher suite enhancing WEP on pre-RSNA hardware. TKIP modifies WEP as follows:
a) A transmitter calculates a keyed cryptographic message integrity code (MIC) over the MSDU SA
and DA, the MSDU priority (see 12.5.2.3), and the MSDU plaintext data. TKIP appends the
computed MIC to the MSDU data prior to fragmentation into MPDUs. The receiver verifies
1953
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the MIC after decryption, ICV checking, and defragmentation of the MPDUs into an MSDU and
discards any received MSDUs with invalid MICs. TKIP’s MIC provides a defense against forgery
attacks.
b) Because of the design constraints of the TKIP MIC, it is still possible for an adversary to
compromise message integrity; therefore, TKIP also implements countermeasures. The
countermeasures bound the probability of a successful forgery and the amount of information an
attacker can learn about a key.
c) TKIP uses a per-MPDU TKIP sequence counter (TSC) to sequence the MPDUs it sends. The
receiver drops MPDUs received out of order, i.e., not received with increasing sequence numbers.
This provides replay protection. TKIP encodes the TSC value from the sender to the receiver as a
WEP IV and extended IV.
d) TKIP uses a cryptographic mixing function to combine a temporal key, the TA, and the TSC into the
WEP seed. The receiver recovers the TSC from a received MPDU and utilizes the mixing function
to compute the same WEP seed needed to correctly decrypt the MPDU. The key mixing function is
designed to defeat weak-key attacks against the WEP key.
TKIP defines additional MIB variables; see Annex C.
12.5.2.1.2 TKIP cryptographic encapsulation
TKIP enhances the WEP cryptographic encapsulation with several additional functions, as depicted in
Figure 12-5.
W E P seed(s)
TA (represented as W E P
P hase 1 TTA K IV
TK
key + A R C 4 key)
m ixing IV
P hase 2
ARC 4 key
TS C key m ixing
C iphertext
W EP M P D U (s)
DA + SA +
E ncapsulation
P riority +
P laintext M S D U
Fragm ent(s)
D ata
M ichael
P laintext
M IC K ey MSDU +
M IC
Figure 12-5—TKIP encapsulation block diagram
a) TKIP MIC computation protects the MSDU Data field and corresponding SA, DA, and Priority
fields. The computation of the MIC is performed on the ordered concatenation of the SA, DA,
Priority, and MSDU Data fields. The MIC is appended to the MSDU Data field. TKIP discards any
MIC padding prior to appending the MIC.
b) If needed, the MSDU with MIC is fragmented into one or more MPDUs. TKIP assigns a
monotonically increasing TSC value to each MPDU, taking care that all of the MPDUs generated
from the same MSDU have the same value of extended IV (see 12.5.2.2).
c) For each MPDU, TKIP uses the key mixing function to compute the WEP seed.
d) TKIP represents the WEP seed as a WEP IV and ARC4 key and passes these with each MPDU to
WEP for generation of the ICV (see 9.2.4.7), and for encryption of the plaintext MPDU, including
all or part of the MIC, if present. WEP uses the WEP seed as a WEP default key, identified by a key
identifier associated with the temporal key.
1954
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—When the TSC space is exhausted, the choices available to an implementation are to replace the temporal key
with a new one or to end communications. Reuse of any TSC value compromises already sent traffic. Note that
retransmitted MPDUs reuse the TSC without any compromise of security. The TSC is large enough, however, that TSC
space exhaustion is not expected to be an issue.
In Figure 12-5, the TKIP-mixed transmit address and key (TTAK) denotes the intermediate key produced by
Phase 1 of the TKIP mixing function (see 12.5.2.5).
12.5.2.1.3 TKIP decapsulation
TKIP enhances the WEP decapsulation process with the following additional steps:
a) Before WEP decapsulates a received MPDU, TKIP extracts the TSC sequence number and key
identifier from the WEP IV and the extended IV. TKIP discards a received MPDU that violates the
sequencing rules (see 12.5.2.6) and otherwise uses the mixing function to construct the WEP seed.
b) TKIP represents the WEP seed as a WEP IV and ARC4 key and passes these with the MPDU to
WEP for decapsulation.
c) If WEP indicates the ICV check succeeded, the implementation reassembles the MPDU into an
MSDU. If the MSDU defragmentation succeeds, the receiver verifies the TKIP MIC. If MSDU
defragmentation fails, then the MSDU is discarded.
d) The MIC verification step recomputes the MIC over the MSDU SA, DA, Priority, and MSDU Data
fields (but not the TKIP MIC field). The calculated TKIP MIC result is then compared bitwise to the
received MIC.
e) If the received and the locally computed MIC values are identical, the verification succeeds, and
TKIP shall deliver the MSDU to the upper layer. If the two differ, then the verification fails; the
receiver shall discard the MSDU and shall engage in appropriate countermeasures.
Figure 12-6 depicts this process.
MIC Key
TA
Phase 1
key mixing
TK TTAK
Phase 2 WEP Seed
key mixing
TKIP TSC Unmix TSC DA + SA + Priority Michael
TSC + Plaintext MSDU
WEP MIC'
Reassemble
In-sequence Decapsulation
MPDU Plaintext MIC
Ciphertext MPDU MIC =
MPDU MIC'?
MSDU with failed
Out-of-sequence TKIP MIC
MPDU
Countermeasures
Figure 12-6—TKIP decapsulation block diagram
1955
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.5.2.2 TKIP MPDU formats
TKIP reuses the pre-RSNA WEP MPDU format. It extends the MPDU by 4 octets to accommodate an
extension to the WEP IV, denoted by the Extended IV field, and extends the MSDU format by 8 octets to
accommodate the new MIC field. TKIP inserts the Extended IV field immediately after the WEP IV field
and before the encrypted data. TKIP appends the MIC to the MSDU Data field; the MIC becomes part of the
encrypted data.
Once the MIC is appended to the MSDU data, the added MIC octets are considered part of the MSDU for
subsequent fragmentation.
Figure 12-7 depicts the layout of the encrypted MPDU when using TKIP. Note that the figure only depicts
the case when the MSDU can be encapsulated in a single MPDU.
Key ID
Figure 12-7—Construction of expanded TKIP MPDU
The ExtIV bit in the Key ID octet indicates the presence or absence of an extended IV. If the ExtIV bit is 0,
only the nonextended IV is transferred. If the ExtIV bit is 1, an extended IV of 4 octets follows the original
IV. For TKIP the ExtIV bit shall be set to 1, and the Extended IV field shall be supplied. The ExtIV bit shall
be 0 for WEP frames. The Key ID field shall be set to the key index supplied by the MLME-
SETKEYS.request primitive for the key used in cryptographic encapsulation of the frame.
TSC5 is the most significant octet of the TSC, and TSC0 is the least significant. Octets TSC0 and TSC1
form the IV sequence number and are used with the TKIP Phase 2 key mixing. Octets TSC2–TSC5 are used
in the TKIP Phase 1 key hashing and are in the Extended IV field. When the lower 16-bit sequence number
rolls over (0xFFFF 0x0000), the extended IV value, i.e., the upper 32 bits of the entire 48-bit TSC, shall
be incremented by 1.
NOTE—The rationale for this construction is as follows:
— Aligning on word boundaries eases implementation on legacy devices.
— Adding 4 octets of extended IV eliminates TSC exhaustion as a reason to rekey.
— Key ID octet changes. Bit 5 indicates that an extended IV is present. The receiver/transmitter interprets the 4
octets following the Key ID as the extended IV. The receiving/transmitting STA also uses the value of octets
TSC0 and TSC1 to detect that the cached TTAK needs to be updated.
The Extended IV field shall not be encrypted.
WEPSeed[1] is not used to construct the TSC, but is set to (TSC1 | 0x20) & 0x7f.
TKIP shall encrypt all of the MPDUs generated from one MSDU under the same temporal key.
1956
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.5.2.3 TKIP MIC
12.5.2.3.1 General
Flaws in the IEEE 802.11 WEP design cause it to fail to meet its goal of protecting data traffic content from
casual eavesdroppers. Among the most significant WEP flaws is the lack of a mechanism to defeat message
forgeries and other active attacks. To defend against active attacks, TKIP includes a MIC, called michael.
This MIC offers only weak defenses against message forgeries, but it constitutes the best that can be
achieved with the majority of legacy hardware. TKIP uses different MIC keys depending on the direction of
the transfer as described in 12.8.1 and 12.8.2.
Annex J contains an implementation of the TKIP MIC. It also provides test vectors for the MIC.
12.5.2.3.2 Motivation for the TKIP MIC
Before defining the details of the MIC, it is useful to review the context in which this mechanism operates.
Active attacks enabled by the original WEP design include the following:
— Bit-flipping attacks
— Data (payload) truncation, concatenation, and splicing
— Fragmentation attacks
— Iterative guessing attacks against the key
— Redirection by modifying the MPDU DA or RA field
— Impersonation attacks by modifying the MPDU SA or TA field
The MIC makes it more difficult for any of these attacks to succeed.
All of these attacks remain at the MPDU level with the TKIP MIC. The MIC, however, applies to the
MSDU, so it blocks successful MPDU-level attacks. TKIP applies the MIC to the MSDU at the transmitter
and verifies it at the MSDU level at the receiver. If a MIC check fails at the MSDU level, the
implementation shall discard the MSDU and invoke countermeasures (see 12.5.2.4).
Informative Figure 12-8 depicts different peer layers communicating.
Figure 12-8—TKIP MIC relation to IEEE 802.11 processing (informative)
This figure depicts an architecture where the MIC is logically appended to the raw MSDU in response to the
MA-UNITDATA.request primitive. The TKIP MIC is computed over
— The MSDU DA
— The MSDU SA
— The MSDU Priority
— The entire unencrypted MSDU data (payload)
1957
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The DA field, SA field, three reserved octets, and a 1-octet Priority field are used only for calculating the
MIC. The Priority field refers to the priority parameter of the MA-UNITDATA.request primitive. The fields
in Figure 12-9 are treated as an octet stream using the conventions described in 9.2.2.
6 6 1 3 M 1 1 1 1 1 1 1 1 octets
DA SA Priority 0 Data M M M M M M M M
0 1 2 3 4 5 6 7
Figure 12-9—TKIP MIC processing format
TKIP appends the MIC at the end of the MSDU. The MIC is 8 octets in size for michael. The IEEE 802.11
MAC then applies its normal processing to transmit this MSDU-with-MIC as a sequence of one or more
MPDUs. In other words, the MSDU-with-MIC can be partitioned into one or more MPDUs, the WEP ICV is
calculated over each MPDU, and the MIC can even be partitioned to lie in two MPDUs after fragmentation.
The TKIP MIC augments, but does not replace, the WEP ICV. Because the TKIP MIC is a weak
construction, TKIP protects the MIC with encryption, which makes TKIP MIC forgeries more difficult. The
WEP ICV helps to prevent false detection of MIC failures that would cause countermeasures to be invoked.
The receiver reverses this procedure to reassemble the MSDU; and, after the MSDU has been logically
reassembled, the IEEE 802.11 MAC verifies the MIC prior to delivery of the MSDU to upper layers. If the
MIC validation succeeds, the MAC delivers the MSDU. If the MIC validation fails, the MAC shall discard
the MSDU and invoke countermeasures (see 12.5.2.4).
NOTE—TKIP calculates the MIC over the MSDU rather than the MPDU, because doing so increases the
implementation flexibility with preexisting WEP hardware.
Note that a MIC alone cannot provide complete forgery protection, as it cannot defend against replay
attacks. Therefore, TKIP provides replay detection by TSC sequencing and ICV validation. Furthermore, if
TKIP is utilized with a GTK, an insider STA can masquerade as any other STA belonging to the group.
12.5.2.3.3 Definition of the TKIP MIC
Michael generates a 64-bit MIC. The michael key consists of 64 bits, represented as an 8-octet sequence,
k0...k7. This is converted to two 32-bit words, K0 and K1. Throughout this subclause, all conversions
between octets and 32-bit words shall use the little endian conventions, given in 9.2.2.
Michael operates on each MSDU including the Priority field, 3 reserved octets, SA field, and DA field. An
MSDU consists of octets m0...mn–1 where n is the number of MSDU octets, including SA, DA, Priority, and
Data fields. The message is padded at the end with a single octet with value 0x5a, followed by between 4
and 7 zero octets. The number of zero octets is chosen so that the overall length of the padded MSDU is a
multiple of four. The padding is not transmitted with the MSDU; it is used to simplify the computation over
the final block. The MSDU is then converted to a sequence of 32-bit words M0 ...MN–1, where N = (n+5)/
4 . By construction, MN–1 = 0 and MN–2 0.
The MIC value is computed iteratively starting with the key value (K0 and K1) and applying a block function
b for every message word, as shown in Figure 12-10. The algorithm loop runs a total of N times (i takes on
the values 0 to N–1 inclusive), where N is as above, the number of 32-bit words composing the padded
MSDU. The algorithm results in two words (l and r), which are converted to a sequence of 8 octets using the
least-significant-octet-first convention:
— M0 = l & 0xff
— M1 = (l/0x100) & 0xff
— M2 = (l/0x10000) & 0xff
— M3 = (l/0x1000000) & 0xff
1958
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— M4 = r & 0xff
— M5 = (r/0x100) & 0xff
— M6 = (r/0x10000) & 0xff
— M7 = (r/0x1000000) & 0xff
This is the MIC value. The MIC value is appended to the MSDU as data to be sent.
Input: Key (K0, K1) and padded MSDU (represented as 32-bit words) M0 ... MN–1
Output: MIC value (V0, V1)
MICHAEL((K0, K1) , (M0, ... , MN))
(l,r) (K0, K1)
for i = 0 to N–1 do
l I Mi
(l,r) b(l,r)
return (l,r)
Figure 12-10—Michael message processing
Figure 12-11 defines the michael block function b. It is a Feistel-type construction with alternating additions
and XOR operations. It uses <<< to denote the rotate-left operator on 32-bit values, >>> for the rotate-right
operator, and XSWAP for a function that swaps the position of the 2 least significant octets. It also uses the
position of the two most significant octets in a word.
In p u t: (l,r)
O u tp u t: ( l,r)
b ( L ,R )
r r (l < < < 1 7 )
l (l + r ) m o d 2 32
r r X S W A P (l )
l (l + r ) m o d 2 32
r r (l < < < 3 )
l (l + r ) m o d 2 32
r r (l > > > 2 )
l (l + r ) m o d 2 32
re tu r n (l , r )
Figure 12-11—Michael block function
12.5.2.4 TKIP countermeasures procedures
12.5.2.4.1 General
The TKIP MIC trades off security in favor of implementability on pre-RSNA STAs. Michael provides only
weak protection against active attacks. A failure of the MIC in a received MSDU indicates a probable active
attack. A successful attack against the MIC would mean an attacker could inject forged Data frames and
perform further effective attacks against the encryption key itself. If TKIP implementation detects a
probable active attack, TKIP shall take countermeasures as specified in this subclause. These
countermeasures accomplish the following goals:
— MIC failure events should be logged as a security-relevant matter. A MIC failure is an almost certain
indication of an active attack and warrants a follow-up by the system administrator.
— The rate of MIC failures needs to be kept below two per minute. This implies that STAs and APs
detecting two MIC failure events within 60 s need to disable all receptions using TKIP for a period
of 60 s. The slowdown makes it difficult for an attacker to make a large number of forgery attempts
in a short time.
1959
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— As an additional security feature, the PTK and, in the case of the Authenticator, the GTK should be
changed.
Before verifying the MIC, the receiver shall check the FCS, ICV, and TSC for all related MPDUs. Any
MPDU that has an invalid FCS, an incorrect ICV, or a TSC value that is less than or equal to the TSC replay
counter shall be discarded before checking the MIC. This avoids unnecessary MIC failure events. Checking
the TSC before the MIC makes countermeasure-based denial-of-service attacks harder to perform. While the
FCS and ICV mechanisms are sufficient to detect noise, they are insufficient to detect active attacks. The
FCS and ICV provide error detection, but not integrity protection.
A single counter or timer shall be used to log MIC failure events. These failure events are defined as
follows:
— In an Authenticator:
— Detection of a MIC failure on a received individually addressed frame.
— Receipt of Michael MIC Failure Report frame.
— In a Supplicant:
— Detection of a MIC failure on a received individually addressed or group addressed frame.
— Attempt to transmit a Michael MIC Failure Report frame.
The number of MIC failures is accrued independent of the particular key context. Any single MIC failure,
whether detected by the Supplicant or the Authenticator and whether resulting from a group MIC key failure
or a pairwise MIC key failure, shall be treated as cause for a MIC failure event.
The Supplicant uses a single Michael MIC Failure Report frame to report a MIC failure event to the
Authenticator. A Michael MIC Failure Report is an EAPOL-Key frame with the following Key Information
field bits set to 1: MIC bit, Error bit, Request bit, Secure bit. The Supplicant protects this message with the
current PTK; the Supplicant uses the KCK portion of the PTK to compute the IEEE 802.1X EAPOL MIC.
The MLME-MICHAELMICFAILURE.indication primitive is used by the IEEE 802.11 MAC to attempt to
indicate a MIC failure to the local IEEE 802.1X Supplicant or Authenticator. MLME-EAPOL.request
primitive is used by the Supplicant to send the EAPOL-Key frame containing the Michael MIC Failure
report. MLME-EAPOL.confirm primitive indicates to the Supplicant when the EAPOL-Key frame has been
transmitted.
The first MIC failure shall be logged, and a timer initiated to enable enforcement of the countermeasures. If
the MIC failure event is detected by the Supplicant, it shall also report the event to the AP by sending a
Michael MIC Failure Report frame.
If a subsequent MIC failure occurs within 60 s of the most recent previous failure, then a STA whose
IEEE 802.1X entity has acted as a Supplicant shall deauthenticate (as defined in 11.3.4.4) itself or
deauthenticate all of the STAs with a security association if its IEEE 802.1X entity acted as an
Authenticator. In an IBSS STA, both Supplicant and Authenticator actions shall be taken. Furthermore, the
device shall not receive or transmit any TKIP-encrypted Data frames, and shall not receive or transmit any
unencrypted Data frames other than IEEE 802.1X messages, to or from any peer for a period of at least 60 s
after it detects the second failure. If the device is an AP, it shall disallow new associations using TKIP
during this 60 s period; at the end of the 60 s period, the AP shall resume normal operations and allow STAs
to (re)associate. If the device is an IBSS STA, it shall disallow any new security associations using TKIP
during this 60 s period. If the device is a Supplicant, it shall first send a Michael MIC Failure Report frame
prior to revoking its PTKSA and deauthenticating itself.
The aMICFailTime attribute shall contain the sysUpTime value at the time the MIC failure was logged.
1960
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.5.2.4.2 TKIP countermeasures for an Authenticator
The countermeasures used by an Authenticator are depicted in Figure 12-12 and described as follows:
Wait for Michael MIC failure
Wait for MIC failure
Timer
Timer No
< Timer
Timer==00
60ssec Logevent
60 Logevent
Yes
Disassociate all STAs
Deauthenticate if notifan
all STAs IBSS
not an IBSS
Revoke
RevokeallallPTKs
PTKs and GTK
and GTK
Generate
GeneratenewnewGTKGTK
Wait 60 Sec
Wait 60 s
Plumb new new
Configure GTK GTK
Enable associations
Enable associations if not anan
if not IBSS
IBSS
Figure 12-12—Authenticator MIC countermeasures
a) In an Authenticator’s STA that receives a frame with a MIC error,
1) Discard the frame.
2) Increment the MIC failure counter, dot11RSNAStatsTKIPLocalMICFailures.
3) Generate an MLME-MICHAELMICFAILURE.indication primitive.
b) In an Authenticator that receives an MLME-MICHAELMICFAILURE.indication primitive or a
Michael MIC Failure Report frame,
1) If it is a Michael MIC Failure Report frame, then increment dot11RSNAStatsTKIP-
RemoteMICFailures.
2) If this is the first MIC failure within the past 60 s, initialize the countermeasures timer.
3) If less than 60 s have passed since the most recent previous MIC failure, the Authenticator shall
deauthenticate and delete all PTKSAs for all STAs using TKIP. If the current GTKSA uses
TKIP, that GTKSA shall be discarded, and a new GTKSA constructed, but not used for 60 s.
The Authenticator shall refuse the construction of new PTKSAs using TKIP as one or more of
the ciphers for 60 s. At the end of this period, the MIC failure counter and timer shall be reset,
and creation of PTKSAs accepted as usual.
4) If the Authenticator is using IEEE 802.1X authentication, the Authenticator shall transition the
state of the IEEE 802.1X Authenticator state machine to the INITIALIZE state. This restarts
the IEEE 802.1X state machine. If the Authenticator is instead using PSKs, this step is omitted.
Note that a Supplicant’s STA may deauthenticate with a reason code of MIC_FAILURE if it is an ESS STA.
The Authenticator shall not log the deauthenticate as a MIC failure event to prevent denial-of-service attacks
through deauthentications. The Supplicant’s STA reports the MIC failure event through the Michael MIC
Failure Report frame so that the AP can log the event.
1961
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The requirement to deauthenticate all STAs using TKIP includes those using other pairwise ciphers if they
are using TKIP as the group cipher.
12.5.2.4.3 TKIP countermeasures for a Supplicant
The countermeasures used by a Supplicant are depicted in Figure 12-13 and described as follows:
Wait for MIC failure
Send Michael MIC Failure Report
frame
Timer No
< Timer = 0
60 s Logevent
Yes
Stop receiving Class 3 frames if not an IBSS
Stop receiving Class 1 frames if in an IBSS
Wait for MLME-EAPOL.confirm
Deauthenticate the AP if not in IBSS
Revoke PTK and GTK
Wait 60 s before associating to same AP
or roam to a new AP if not IBSS, or
sending data in an IBSS
Figure 12-13—Supplicant MIC countermeasures
a) In a Supplicant’s STA that receives a frame with a MIC error,
1) Increment the MIC failure counter, dot11RSNAStatsTKIPLocalMICFailures.
2) Discard the offending frame.
3) Generate an MLME-MICHAELMICFAILURE.indication primitive.
b) In a Supplicant that receives an MLME-MICHAELMICFAILURE.indication primitive from its
STA,
1) Send a Michael MIC Failure Report frame to the AP.
2) If this is the first MIC failure within the past 60 s, initialize the countermeasures timer.
3) If less than 60 s have passed since the most recent previous MIC failure, delete the PTKSA and
GTKSA. Deauthenticate from the AP and wait for 60 s before (re)establishing a TKIP
association with the same AP. A TKIP association is any IEEE 802.11 association that uses
TKIP for its pairwise or group cipher suite.
c) If a STA receives a deauthenticate frame with the reason code MIC_FAILURE it is unable to verify
that the frame has not been forged, since the frame does not contain a MIC. The STA may attempt
association with this, or another, AP. If the frame was genuine, then it is probable that attempts to
1962
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
associate with the same AP requesting the use of TKIP will fail because the AP is conducting
countermeasures.
12.5.2.5 TKIP mixing function
12.5.2.5.1 General
Annex J defines a C-language reference implementation of the TKIP mixing function. It also provides test
vectors for the mixing function.
The mixing function has two phases. Phase 1 mixes the appropriate temporal key (pairwise or group) with
the TA and TSC. A STA may cache the output of this phase to reuse with subsequent MPDUs associated
with the same temporal key and TA. Phase 2 mixes the output of Phase 1 with the TSC and temporal key
(TK) to produce the WEP seed, also called the per-frame key. The WEP seed may be precomputed before it
is used. The two-phase process may be summarized as follows:
TTAK := Phase1 (TK, TA, TSC)
WEP seed := Phase2 (TTAK, TK, TSC)
12.5.2.5.2 S-Box
Both Phase 1 and Phase 2 rely on an S-box, defined in this subclause. The S-box substitutes one 16-bit value
with another 16-bit value. This function may be implemented as a table look up.
NOTE—The S-box is a nonlinear substitution. The table look-up is be organized as either a single table with 65 536
entries and a 16-bit index (128K octets of table) or two tables with 256 entries and an 8-bit index (1024 octets for both
tables). When the two smaller tables are used, the high-order octet is used to obtain a 16-bit value from one table, the
low-order octet is used to obtain a 16-bit value from the other table, and the S-box output is the XOR of the two 16-bit
values. The second S-box table is an octet-swapped replica of the first.
#define _S_(v16) (Sbox[0][Lo8(v16)] ^ Sbox[1][Hi8(v16)])
/* 2-byte by 2-byte subset of the full AES S-box table */
const u16b Sbox[2][256]= /* Sbox for hash (can be in ROM) */
{ {
0xC6A5,0xF884,0xEE99,0xF68D,0xFF0D,0xD6BD,0xDEB1,0x9154,
0x6050,0x0203,0xCEA9,0x567D,0xE719,0xB562,0x4DE6,0xEC9A,
0x8F45,0x1F9D,0x8940,0xFA87,0xEF15,0xB2EB,0x8EC9,0xFB0B,
0x41EC,0xB367,0x5FFD,0x45EA,0x23BF,0x53F7,0xE496,0x9B5B,
0x75C2,0xE11C,0x3DAE,0x4C6A,0x6C5A,0x7E41,0xF502,0x834F,
0x685C,0x51F4,0xD134,0xF908,0xE293,0xAB73,0x6253,0x2A3F,
0x080C,0x9552,0x4665,0x9D5E,0x3028,0x37A1,0x0A0F,0x2FB5,
0x0E09,0x2436,0x1B9B,0xDF3D,0xCD26,0x4E69,0x7FCD,0xEA9F,
0x121B,0x1D9E,0x5874,0x342E,0x362D,0xDCB2,0xB4EE,0x5BFB,
0xA4F6,0x764D,0xB761,0x7DCE,0x527B,0xDD3E,0x5E71,0x1397,
0xA6F5,0xB968,0x0000,0xC12C,0x4060,0xE31F,0x79C8,0xB6ED,
0xD4BE,0x8D46,0x67D9,0x724B,0x94DE,0x98D4,0xB0E8,0x854A,
0xBB6B,0xC52A,0x4FE5,0xED16,0x86C5,0x9AD7,0x6655,0x1194,
0x8ACF,0xE910,0x0406,0xFE81,0xA0F0,0x7844,0x25BA,0x4BE3,
0xA2F3,0x5DFE,0x80C0,0x058A,0x3FAD,0x21BC,0x7048,0xF104,
0x63DF,0x77C1,0xAF75,0x4263,0x2030,0xE51A,0xFD0E,0xBF6D,
0x814C,0x1814,0x2635,0xC32F,0xBEE1,0x35A2,0x88CC,0x2E39,
0x9357,0x55F2,0xFC82,0x7A47,0xC8AC,0xBAE7,0x322B,0xE695,
0xC0A0,0x1998,0x9ED1,0xA37F,0x4466,0x547E,0x3BAB,0x0B83,
0x8CCA,0xC729,0x6BD3,0x283C,0xA779,0xBCE2,0x161D,0xAD76,
0xDB3B,0x6456,0x744E,0x141E,0x92DB,0x0C0A,0x486C,0xB8E4,
0x9F5D,0xBD6E,0x43EF,0xC4A6,0x39A8,0x31A4,0xD337,0xF28B,
0xD532,0x8B43,0x6E59,0xDAB7,0x018C,0xB164,0x9CD2,0x49E0,
1963
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
0xD8B4,0xACFA,0xF307,0xCF25,0xCAAF,0xF48E,0x47E9,0x1018,
0x6FD5,0xF088,0x4A6F,0x5C72,0x3824,0x57F1,0x73C7,0x9751,
0xCB23,0xA17C,0xE89C,0x3E21,0x96DD,0x61DC,0x0D86,0x0F85,
0xE090,0x7C42,0x71C4,0xCCAA,0x90D8,0x0605,0xF701,0x1C12,
0xC2A3,0x6A5F,0xAEF9,0x69D0,0x1791,0x9958,0x3A27,0x27B9,
0xD938,0xEB13,0x2BB3,0x2233,0xD2BB,0xA970,0x0789,0x33A7,
0x2DB6,0x3C22,0x1592,0xC920,0x8749,0xAAFF,0x5078,0xA57A,
0x038F,0x59F8,0x0980,0x1A17,0x65DA,0xD731,0x84C6,0xD0B8,
0x82C3,0x29B0,0x5A77,0x1E11,0x7BCB,0xA8FC,0x6DD6,0x2C3A,
},
{ /* second half of table is byte-reversed version of first! */
0xA5C6,0x84F8,0x99EE,0x8DF6,0x0DFF,0xBDD6,0xB1DE,0x5491,
0x5060,0x0302,0xA9CE,0x7D56,0x19E7,0x62B5,0xE64D,0x9AEC,
0x458F,0x9D1F,0x4089,0x87FA,0x15EF,0xEBB2,0xC98E,0x0BFB,
0xEC41,0x67B3,0xFD5F,0xEA45,0xBF23,0xF753,0x96E4,0x5B9B,
0xC275,0x1CE1,0xAE3D,0x6A4C,0x5A6C,0x417E,0x02F5,0x4F83,
0x5C68,0xF451,0x34D1,0x08F9,0x93E2,0x73AB,0x5362,0x3F2A,
0x0C08,0x5295,0x6546,0x5E9D,0x2830,0xA137,0x0F0A,0xB52F,
0x090E,0x3624,0x9B1B,0x3DDF,0x26CD,0x694E,0xCD7F,0x9FEA,
0x1B12,0x9E1D,0x7458,0x2E34,0x2D36,0xB2DC,0xEEB4,0xFB5B,
0xF6A4,0x4D76,0x61B7,0xCE7D,0x7B52,0x3EDD,0x715E,0x9713,
0xF5A6,0x68B9,0x0000,0x2CC1,0x6040,0x1FE3,0xC879,0xEDB6,
0xBED4,0x468D,0xD967,0x4B72,0xDE94,0xD498,0xE8B0,0x4A85,
0x6BBB,0x2AC5,0xE54F,0x16ED,0xC586,0xD79A,0x5566,0x9411,
0xCF8A,0x10E9,0x0604,0x81FE,0xF0A0,0x4478,0xBA25,0xE34B,
0xF3A2,0xFE5D,0xC080,0x8A05,0xAD3F,0xBC21,0x4870,0x04F1,
0xDF63,0xC177,0x75AF,0x6342,0x3020,0x1AE5,0x0EFD,0x6DBF,
0x4C81,0x1418,0x3526,0x2FC3,0xE1BE,0xA235,0xCC88,0x392E,
0x5793,0xF255,0x82FC,0x477A,0xACC8,0xE7BA,0x2B32,0x95E6,
0xA0C0,0x9819,0xD19E,0x7FA3,0x6644,0x7E54,0xAB3B,0x830B,
0xCA8C,0x29C7,0xD36B,0x3C28,0x79A7,0xE2BC,0x1D16,0x76AD,
0x3BDB,0x5664,0x4E74,0x1E14,0xDB92,0x0A0C,0x6C48,0xE4B8,
0x5D9F,0x6EBD,0xEF43,0xA6C4,0xA839,0xA431,0x37D3,0x8BF2,
0x32D5,0x438B,0x596E,0xB7DA,0x8C01,0x64B1,0xD29C,0xE049,
0xB4D8,0xFAAC,0x07F3,0x25CF,0xAFCA,0x8EF4,0xE947,0x1810,
0xD56F,0x88F0,0x6F4A,0x725C,0x2438,0xF157,0xC773,0x5197,
0x23CB,0x7CA1,0x9CE8,0x213E,0xDD96,0xDC61,0x860D,0x850F,
0x90E0,0x427C,0xC471,0xAACC,0xD890,0x0506,0x01F7,0x121C,
0xA3C2,0x5F6A,0xF9AE,0xD069,0x9117,0x5899,0x273A,0xB927,
0x38D9,0x13EB,0xB32B,0x3322,0xBBD2,0x70A9,0x8907,0xA733,
0xB62D,0x223C,0x9215,0x20C9,0x4987,0xFFAA,0x7850,0x7AA5,
0x8F03,0xF859,0x8009,0x171A,0xDA65,0x31D7,0xC684,0xB8D0,
0xC382,0xB029,0x775A,0x111E,0xCB7B,0xFCA8,0xD66D,0x3A2C,
}
};
12.5.2.5.3 Phase 1 Definition
The inputs to Phase 1 of the temporal key mixing function shall be a temporal key (TK), the TA, and the
TSC. The temporal key shall be 128 bits in length. Only the 32 MSBs of the TSC and all of the temporal key
are used in Phase 1. The output, TTAK, shall be 80 bits in length and is represented by an array of 16-bit
values: TTAK0 TTAK1 TTAK2 TTAK3 TTAK4.
The description of the Phase 1 algorithm treats all of the following values as arrays of 8-bit values: TA0..TA5,
TK0..TK15. The TA octet order is represented according to the conventions from 9.2.2, and the first 3 octets
represent the OUI.
1964
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The XOR operation, the bitwise-and (&) operation, and the addition (+) operation are used in the Phase 1
specification. A loop counter, i, and an array index temporary variable, j, are also employed.
One function, Mk16, is used in the definition of Phase 1. The function Mk16 constructs a 16-bit value from
two 8-bit inputs as Mk16(X,Y) = (256 X)+Y.
Two steps make up the Phase 1 algorithm. The first step initializes TTAK from TSC and TA. The second step
uses an S-box to iteratively mix the keying material into the 80-bit TTAK. The second step sets the
PHASE1_LOOP_COUNT to 8. See Figure 12-14.
Input: transmit address TA0…TA5, Temporal Key TK0..TK15, and TSC0..TSC5
Output: intermediate key TTAK0..TTAK4
PHASE1-KEY-MIXING(TA0…TA5, TK0..TK15, TSC0..TSC5)
PHASE1_STEP1:
TTAK0 MK16(TSC3, TSC2)
TTAK1 MK16(TSC5, TSC4)
TTAK2 Mk16(TA1,TA0)
TTAK3 Mk16(TA3,TA2)
TTAK4 Mk16(TA5,TA4)
PHASE1_STEP2:
for i = 0 to PHASE1_LOOP_COUNT-1
j 2 (i & 1)
TTAK0 TTAK0 + S[TTAK4 Mk16(TK1+j,TK0+j)]
TTAK1 TTAK1 + S[TTAK0 Mk16(TK5+j,TK4+j)]
TTAK2 TTAK2 + S[TTAK1 Mk16(TK9+j,TK8+j)]
TTAK3 TTAK3 + S[TTAK2 Mk16(TK13+j,TK12+j)]
TTAK4 TTAK4 + S[TTAK3 Mk16(TK1+j,TK0+j)] + i
Figure 12-14—Phase 1 key mixing
NOTE 1—The TA is mixed into the temporal key in Phase 1 of the hash function. Implementations might achieve a
significant performance improvement by caching the output of Phase 1. The Phase 1 output is the same for 216 = 65 536
consecutive frames from the same temporal key and TA. Consider the simple case where a STA communicates only
with an AP. The STA performs Phase 1 using its own address, and the TTAK is used to protect traffic sent to the AP. The
STA performs Phase 1 using the AP address, and it is used to unwrap traffic received from the AP.
NOTE 2—The cached TTAK from Phase 1 needs to be updated when the lower 16 bits of the TSC wrap and the upper
32 bits need to be updated.
12.5.2.5.4 Phase 2 definition
The inputs to Phase 2 of the temporal key mixing function shall be the output of Phase 1 (TTAK) together
with the temporal key and the TSC. The TTAK is 80 bits in length. Only the 16 LSBs of the TSC are used in
Phase 2. The temporal key is 128 bits. The output is the WEP seed, which is a per-frame key, and is 128 bits
in length. The constructed WEP seed has an internal structure compliant with the WEP specification. In
other words, the first 24 bits of the WEP seed shall be transmitted in plaintext as the WEP IV. As such, these
24 bits are used to convey lower 16 bits of the TSC from the sender (encryptor) to the receiver (decryptor).
The rest of the TSC shall be conveyed in the Extended IV field. The temporal key and TTAK values are
represented as in Phase 1. The WEP seed is treated as an array of 8-bit values: WEPSeed0…WEPSeed15.
The TSC shall be treated as an array of 8-bit values: TSC0 TSC1 TSC2 TSC3 TSC4 TSC5.
The pseudocode specifying the Phase 2 mixing function employs one variable: PPK, which is 96 bits long.
The PPK is represented as an array of 16-bit values: PPK0..PPK5. The pseudocode also employs a loop
counter, i. As detailed in this subclause, the mapping from the 16-bit PPK values to the 8-bit WEPseed
values is explicitly little endian to match the endian architecture of the most common processors used for
this application.
1965
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The XOR ( ) operation, the addition (+) operation, the AND (&) operation, the OR (|) operation, and the
right bit shift (>>) operation are used in the specification of Phase 2. See Figure 12-15.
Input: intermediate key TTAK0…TTAK4, TK, and TKIP sequence counter TSC
Output: WEP Seed WEPSeed0…WEPSeed15
PHASE2-KEY-MIXING(TTAK0…TTAK4, TK0…TK15, TSC0…TSC5)
PHASE2_STEP1:
PPK0 TTAK0
PPK1 TTAK1
PPK2 TTAK2
PPK3 TTAK3
PPK4 TTAK4
PPK5 TTAK4 + Mk16(TSC1, TSC0)
PHASE2_STEP2:
PPK0 PPK0 + S[PPK5 Mk16(TK1,TK0)]
PPK1 PPK1 + S[PPK0 Mk16(TK3,TK2)]
PPK2 PPK2 + S[PPK1 Mk16(TK5,TK4)]
PPK3 PPK3 + S[PPK2 Mk16(TK7,TK6)]
PPK4 PPK4 + S[PPK3 Mk16(TK9,TK8)]
PPK5 PPK5 + S[PPK4 Mk16(TK11,TK10)]
PPK0 PPK0 + RotR1(PPK5 Mk16(TK13,TK12))
PPK1 PPK1 + RotR1(PPK0 Mk16(TK15,TK14))
PPK2 PPK2 + RotR1(PPK1)
PPK3 PPK3 + RotR1(PPK2)
PPK4 PPK4 + RotR1(PPK3)
PPK5 PPK5 + RotR1(PPK4)
PHASE2_STEP3:
WEPSeed0 TSC1
WEPSeed1 (TSC1 | 0x20) & 0x7F
WEPSeed2 TSC0
WEPSeed3 Lo8((PPK5 Mk16(TK1,TK0)) >> 1)
for i = 0 to 5
WEPSeed4+(2 i) Lo8(PPKi)
WEPSeed5+(2 i) Hi8(PPKi)
end
return WEPSeed0…WEPSeed15
Figure 12-15—Phase 2 key mixing
The algorithm specification relies on four functions:
— The first function, Lo8, references the 8 LSBs of the 16-bit input value.
— The second function, Hi8, references the 8 MSBs of the 16-bit value.
— The third function, RotR1, rotates its 16-bit argument 1 bit to the right.
— The fourth function, Mk16, is already used in Phase 1, defined by Mk16(X,Y) = (256 X)+Y, and
constructs a 16-bit output from two 8-bit inputs.
NOTE—The rotate and addition operations in STEP2 make Phase 2 particularly sensitive to the endian architecture of
the processor, although the performance degradation due to running this algorithm on a big endian processor is expected
to be minor.
Phase 2 comprises three steps:
— STEP1 makes a copy of TTAK and brings in the TSC.
— STEP2 is a 96-bit bijective mixing, employing an S-box.
— STEP3 brings in the last of the temporal key TK bits and assigns the 24-bit WEP IV value.
The WEP IV format carries 3 octets. STEP3 of Phase 2 determines the value of each of these three octets.
The construction was selected to preclude the use of known ARC4 weak keys. The recipient can reconstruct
1966
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the 16 LSBs of the TSC used by the originator by concatenating the third and first octets, ignoring the
second octet. The remaining 32 bits of the TSC are obtained from the Extended IV field.
12.5.2.6 TKIP replay protection procedures
TKIP implementations shall use the TSC field to defend against replay attacks by implementing the
following rules:
a) Each MPDU shall have a unique TKIP TSC value.
b) Each transmitter shall maintain a single TSC (48-bit counter) for each PTKSA, GTKSA, and
STKSA.
c) The TSC shall be implemented as a 48-bit strictly increasing counter, initialized to 1 when the
corresponding TKIP temporal key is initialized or refreshed.
d) The WEP IV format carries the 16 LSBs of the 48-bit TSC, as defined by the TKIP mixing function
(Phase 2, STEP3). The remainder of the TSC is carried in the Extended IV field.
e) A receiver shall maintain a separate set of TKIP TSC replay counters for each PTKSA, GTKSA, and
STKSA.
f) TKIP replay detection takes place after the MIC verification and any reordering required by ack
processing. Thus, a receiver shall delay advancing a TKIP TSC replay counter until an MSDU
passes the MIC check, to prevent attackers from injecting MPDUs with valid ICVs and TSCs, but
invalid MICs.
NOTE—This works because if an attacker modifies the TSC, then the encryption key is modified and hence both the
ICV and MIC decrypt incorrectly, causing the received MPDU to be dropped.
g) For each PTKSA, GTKSA, and STKSA, the receiver shall maintain a separate replay counter for
each frame priority and shall use the TSC in a received frame to detect replayed frames, subject to
the limitations on the number of supported replay counters indicated in the RSN Capabilities field,
as described in 9.4.2.25. A replayed frame occurs when the TSC in a received frame is less than or
equal to the current replay counter value for the frame’s priority. A transmitter shall not reorder
TKIP protected frames with different priorities without ensuring that the receiver supports the
required number of replay counters. The transmitter shall not reorder TKIP protected frames within
a replay counter, but may reorder TKIP protected frames across replay counters. One possible
reason for reordering frames is the IEEE 802.11 MSDU priority.
h) A receiver shall discard any MPDU that is received out of order and shall increment
dot11RSNAStatsTKIPReplays for this key.
i) For MSDUs sent using the block ack feature, reordering of received MSDUs according to the block
ack receiver operation (described in 10.24.4) is performed prior to replay detection.
12.5.3 CTR with CBC-MAC protocol (CCMP)
12.5.3.1 General
Subclause 12.5.3 specifies all variants of CCMP, which provides data confidentiality, authentication,
integrity, and replay protection. A non-DMG RSNA STA shall support CCMP-128.
CCMP is based on the CCM of the AES encryption algorithm. CCM combines CTR for data confidentiality
and CBC-MAC for authentication and integrity. CCM protects the integrity of both the MPDU Data field
and selected portions of the IEEE 802.11 MPDU header.
The AES algorithm is defined in FIPS PUB 197. AES processing used within CCMP uses AES with either a
128-bit key (CCMP-128) or a 256-bit key (CCMP-256).
1967
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
CCM is defined in IETF RFC 3610. CCM is a generic mode that can be used with any block-oriented
encryption algorithm. CCM has two parameters (M and L).
CCMP-128 uses the following values for the CCM parameters:
— M = 8; indicating that the MIC is 8 octets.
— L = 2; indicating that the Length field is 2 octets, which is sufficient to hold the length of the largest
possible IEEE 802.11 MPDU, expressed in octets.
CCMP-256 uses the following values for the CCM parameters:
— M = 16; indicating that the MIC is 16 octets.
— L = 2; indicating that the Length field is 2 octets, which is sufficient to hold the length of the largest
possible IEEE 802.11 MPDU, expressed in octets.
CCM requires a fresh temporal key for every session. CCM also requires a unique nonce value for each
frame protected by a given temporal key, and CCMP uses a 48-bit packet number (PN) for this purpose.
Reuse of a PN with the same temporal key voids all security guarantees.
Annex J provides a test vector for CCM.
When CCMP is selected as the RSN pairwise cipher and management frame protection is negotiated,
individually addressed robust Management frames and the group addressed Management frames that receive
“Group Addressed Privacy” as indicated in Table 9-47 shall be protected with CCMP.
12.5.3.2 CCMP MPDU format
Figure 12-16 depicts the MPDU when using CCMP.
Encrypted
CCMP Header Data (PDU) MIC FCS
MAC Header
8 octets ≥ 1 octet variable 4 octets
Ext Key
PN0 PN1 Rsvd Rsvd PN2 PN3 PN4 PN5
IV ID
B0 B4 B5 B6 B7
Key ID octet
Figure 12-16—Expanded CCMP MPDU
CCMP-128 processing expands the original MPDU size by 16 octets, 8 octets for the CCMP Header field
and 8 octets for the MIC field. CCMP-256 processing expands the original MPDU size by 24 octets, 8 octets
for the CCMP Header field, and 16 octets for the MIC field. The CCMP Header field is constructed from the
PN, ExtIV, and Key ID subfields. PN is a 48-bit PN represented as an array of 6 octets. PN5 is the most
significant octet of the PN, and PN0 is the least significant. Note that CCMP does not use the WEP ICV.
The ExtIV subfield (bit 5) of the Key ID octet signals that the CCMP Header field extends the MPDU
header by a total of 8 octets, compared to the 4 octets added to the MPDU header when WEP is used. The
ExtIV bit (bit 5) is always set to 1 for CCMP.
Bits 6–7 of the Key ID octet are for the Key ID subfield.
1968
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.5.3.3 CCMP cryptographic encapsulation
12.5.3.3.1 General
The CCMP cryptographic encapsulation process is depicted in Figure 12-17.
Key ID
Figure 12-17—CCMP encapsulation block diagram
CCMP encrypts the Frame Body field of a plaintext MPDU and encapsulates the resulting cipher text using
the following steps:
a) Increment the PN, to obtain a fresh PN for each MPDU, so that the PN never repeats for the same
temporal key. Note that retransmitted MPDUs are not modified on retransmission.
b) Use the fields in the MPDU header to construct the additional authentication data (AAD) for CCM.
The CCM algorithm provides integrity protection for the fields included in the AAD. MPDU header
fields that may change when retransmitted are muted by being masked to 0 when calculating the
AAD.
c) Construct the CCM Nonce block from the PN, A2, and the priority value of the MPDU where A2 is
MPDU Address 2. If the Type field of the Frame Control field is 10 (Data frame) and there is a QoS
Control field present in the MPDU header, the priority value of the MPDU is equal to the value of
the QC field TID (bits 0 to 3 of the QC field). If the Type field of the Frame Control field is 00
(Management frame), and the frame is a QMF, the priority value of the MPDU is equal to the value
in the ACI subfield of the Sequence Number field. Otherwise, the priority value of the MPDU is
equal to the fixed value 0.
d) Place the new PN and the key identifier into the 8-octet CCMP header.
e) Use the temporal key, AAD, nonce, and MPDU data to form the cipher text and MIC. This step is
known as CCM originator processing.
f) Form the encrypted MPDU by combining the original MPDU header, the CCMP header, the
encrypted data and MIC, as described in 12.5.3.2.
The CCM reference describes the processing of the key, nonce, AAD, and data to produce the encrypted
output. See 12.5.3.3.2 to 12.5.3.3.6 for details of the creation of the AAD and nonce from the MPDU and the
associated MPDU-specific processing.
12.5.3.3.2 PN processing
The PN is incremented by a positive number for each MPDU. The PN shall be incremented in steps of 1 for
constituent MPDUs of fragmented MSDUs and MMPDUs. The PN shall never repeat for a series of
encrypted MPDUs using the same temporal key.
1969
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—When a group addressed MSDU is retransmitted using GCR, it is concealed from non-GCR capable STAs
using the procedures described in 11.24.16.3.5. The MPDU containing this concealed A-MSDU has a different PN from
the MPDU that contained the original transmission of the group addressed MSDU.
12.5.3.3.3 Construct AAD
The format of the AAD is shown in Figure 12-18.
FC A1 A2 A3 SC A4 QC
Octets: 2 6 6 6 2 6 2
Figure 12-18—AAD construction
The length of the AAD varies depending on the presence or absence of the QC and A4 fields and is shown in
Table 12-1.
Table 12-1—AAD length
AAD length
QC field A4 field
(octets)
Absent Absent 22
Present Absent 24
Absent Present 28
Present Present 30
The AAD is constructed from the MPDU header. The AAD does not include the header Duration field,
because the Duration field value might change due to normal IEEE 802.11 operation (e.g., a rate change
during retransmission). The AAD includes neither the Duration/ID field nor the HT Control field because
the contents of these fields might change during normal operation (e.g., due to a rate change preceding
retransmission). The HT Control field might also be inserted or removed during normal operation (e.g.,
retransmission of an A-MPDU where the original A-MPDU included an MRQ that has already generated a
response). For similar reasons, several subfields in the Frame Control field are masked to 0. AAD
construction is performed as follows:
a) FC – MPDU Frame Control field, with
1) Subtype subfield (bits 4 5 6) in a Data frame masked to 0
2) Retry subfield (bit 11) masked to 0
3) Power Management subfield (bit 12) masked to 0
4) More Data subfield (bit 13) masked to 0
5) Protected Frame subfield (bit 14) always set to 1
6) +HTC/Order subfield (bit 15) as follows:
i) Masked to 0 in all Data frames containing a QoS Control field
ii) Unmasked otherwise
b) A1 – MPDU Address 1 field.
c) A2 – MPDU Address 2 field.
d) A3 – MPDU Address 3 field.
1970
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
e) SC – MPDU Sequence Control field, with the Sequence Number subfield (bits 4–15 of the Sequence
Control field) masked to 0. The Fragment Number subfield is not modified.
f) A4 – MPDU Address field, if present.
g) QC – QoS Control field, if present, a 2-octet field that includes the MSDU priority. The QC TID is
used in the construction of the AAD. When in a non-DMG BSS and both the STA and its peer have
their SPP A-MSDU Capable fields equal to 1, bit 7 (the A-MSDU Present field) is used in the
construction of the AAD. The remaining QC fields are masked to 0 for the AAD calculation (bits 4
to 6, bits 8 to 15, and bit 7 when either the STA or its peer has the SPP A-MSDU Capable field equal
to 0). When in a DMG BSS, the A-MSDU Present bit 7 and A-MSDU Type bit 8 are used in the
construction of the AAD, and the remaining QC fields are masked to 0 for the AAD calculation (bits
4 to 6, bits 9 to 15).
12.5.3.3.4 Construct CCM nonce
The Nonce field occupies 13 octets, and its structure is shown in Figure 12-19. The structure of the Nonce
Flags subfield of the Nonce field is shown in Figure 12-20.
Nonce Flags A2 PN
Octets: 1 6 6
Figure 12-19—Nonce construction
B0 B3 B4 B5 B7
Priority Management Zeros
Bits: 4 1 3
Figure 12-20—Nonce Flags subfield
The Nonce field has an internal structure of Nonce Flags || A2 || PN, where
— The Priority subfield of the Nonce Flags field shall be set to the priority value of the MPDU.
— When management frame protection is negotiated, the Management field of the Nonce Flags field
shall be set to 1 if the Type field of the Frame Control field is 00 (Management frame); otherwise it
shall be set to 0.
— Bits 5 to 7 of the Nonce Flags field shall be set to 0.
— MPDU address A2 field occupies octets 1–6. This shall be encoded with the octets ordered with A2
octet 0 at octet index 1 and A2 octet 5 at octet index 6.
— The PN field occupies octets 7–12. The octets of PN shall be ordered so that PN0 is at octet index 12
and PN5 is at octet index 7.
12.5.3.3.5 Construct CCMP header
The format of the 8-octet CCMP header is given in 12.5.3.2. The header encodes the PN, Key ID, and ExtIV
field values used to encrypt the MPDU.
12.5.3.3.6 CCM originator processing
CCM is a generic authenticate-and-encrypt block cipher mode, and in this standard, CCM is used with the
AES block cipher.
1971
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
There are four inputs to CCM originator processing:
a) Key: the temporal key (16 octets).
b) Nonce: the nonce (13 octets) constructed as described in 12.5.3.3.4.
c) Frame body: the plaintext frame body of the MPDU.
d) AAD: the AAD (22–30 octets) constructed from the MPDU header as described in 12.5.3.3.3.
The CCM originator processing provides authentication and integrity of the frame body and the AAD as
well as data confidentiality of the frame body. The output from the CCM originator processing consists of
the encrypted data and an encrypted MIC (see Figure 12-16).
The PN values sequentially number each MPDU. Each transmitter shall maintain a single PN (48-bit
counter) for each PTKSA, GTKSA, and STKSA. The PN shall be implemented as a 48-bit strictly
increasing integer, initialized to 1 when the corresponding temporal key is initialized or refreshed.
A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priority if this would cause the total number
of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the
receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA. The transmitter shall not
reorder CCMP protected frames that are transmitted to the same RA within a replay counter, but may
reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU
or A-MSDU priority.
The transmitter shall preserve the order of protected robust Management frames that are transmitted to the
same DA without the QMF service. When the QMF service is used, the transmitter shall not reorder robust
IQMFs within an AC when the frames are transmitted to the same RA.
A CCMP protected individually addressed robust Management frame shall be protected using the same TK
as a Data frame.
12.5.3.4 CCMP decapsulation
12.5.3.4.1 General
Figure 12-21 depicts the CCMP decapsulation process.
Figure 12-21—CCMP decapsulation block diagram
1972
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
CCMP decrypts the Frame Body field of a cipher text MPDU and decapsulates a plaintext MPDU using the
following steps:
a) The encrypted MPDU is parsed to construct the AAD and nonce values.
b) The AAD is formed from the MPDU header of the encrypted MPDU.
c) The Nonce value is constructed from the A2, PN, and Nonce Flags fields.
d) The MIC is extracted for use in the CCM integrity checking.
e) The CCM recipient processing uses the temporal key, AAD, nonce, MIC, and MPDU cipher text
data to recover the MPDU plaintext data as well as to check the integrity of the AAD and MPDU
plaintext data.
f) The received MPDU header and the MPDU plaintext data from the CCM recipient processing are
concatenated to form a plaintext MPDU.
g) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is
greater than the replay counter maintained for the session.
See 12.5.3.4.2 to 12.5.3.4.4 for details of this processing.
When the received frame is a CCMP protected individually addressed robust Management frame, contents
of the MMPDU body after protection is removed shall be delivered to the SME via the MLME primitive
designated for that MMPDU rather than through the MA-UNITDATA.indication primitive.
12.5.3.4.2 CCM recipient processing
CCM recipient processing uses the same parameters as CCM originator processing. A CCMP protected
individually addressed robust Management frame shall use the same TK as a Data frame.
There are four inputs to CCM recipient processing:
— Key: the temporal key (16 octets).
— Nonce: the nonce (13 octets) constructed as described in 12.5.3.3.4.
— Encrypted frame body: the encrypted frame body from the received MPDU. The encrypted frame
body includes the MIC.
— AAD: the AAD (22–30 octets) that is the canonical MPDU header as described in 12.5.3.3.3.
The CCM recipient processing checks the authentication and integrity of the frame body and the AAD as
well as decrypting the frame body. The plaintext is returned only if the MIC check is successful.
There is one output from error-free CCM recipient processing:
— Frame body: the plaintext frame body, which is 8 octets (CCMP-128) or 16 octets (CCMP-256)
smaller than the encrypted frame body.
12.5.3.4.3 Decrypted CCMP MPDU
The decapsulation process succeeds when the calculated MIC matches the MIC value obtained from
decrypting the received encrypted MPDU. The original MPDU header is concatenated with the plaintext
data resulting from the successful CCM recipient processing to create the plaintext MPDU.
12.5.3.4.4 PN and replay detection
To effect replay detection, the receiver extracts the PN from the CCMP header. See 12.5.3.2 for a
description of how the PN is encoded in the CCMP header. The following processing rules are used to detect
replay:
1973
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) The receiver shall maintain a separate set of replay counters for each PTKSA, GTKSA, and STKSA.
The receiver initializes these replay counters to 0 when it resets the temporal key for a peer. The
replay counter is set to the PN value of accepted CCMP MPDUs.
b) For each PTKSA, GTKSA, and STKSA, the recipient shall maintain a separate replay counter for
each TID, subject to the limitation of the number of supported replay counters indicated in the RSN
Capabilities field (see 9.4.2.25), and shall use the PN from a received frame to detect replayed
frames. A replayed frame occurs when the PN from a received frame is less than or equal to the
current replay counter value for the frame’s MSDU or A-MSDU priority and frame type.
c) If dot11RSNAProtectedManagementFramesActivated is true, the recipient shall maintain a single
replay counter for received individually addressed robust Management frames that are received with
the To DS subfield equal to 0 and shall use the PN from the received frame to detect replays. If
dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each
ACI for received individually addressed robust Management frames that are received with the To
DS subfield equal to 1. The QMF receiver shall use the ACI encoded in the Sequence Number field
of the received frame to select the replay counter to use for the received frame, and shall use the PN
from the received frame to detect replays. A replayed frame occurs when the PN from the frame is
less than or equal to the current value of the management frame replay counter that corresponds to
the ACI of the frame.
d) The receiver shall discard any Data frame that is received with its PN less than or equal to the value
of the replay counter that is associated with the TA and priority value of the received MPDU. The
receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not
incrementing in steps of 1. If dot11RSNAProtectedManagementFramesActivated is true, the
receiver shall discard any individually addressed robust Management frame that is received with its
PN less than or equal to the value of the replay counter associated with the TA of that individually
addressed Management frame.
e) When discarding a frame, the receiver shall increment by 1 dot11RSNAStatsCCMPReplays for Data
frames or dot11RSNAStatsRobustMgmtCCMPReplays for robust Management frames.
f) For MSDUs or A-MSDUs sent using the block ack feature, reordering of received MSDUs or
A-MSDUs according to the block ack receiver operation (described in 10.24.4) is performed prior to
replay detection.
12.5.4 Broadcast/multicast integrity protocol (BIP)
12.5.4.1 BIP overview
BIP provides data integrity and replay protection for group addressed robust Management frames after
successful establishment of an IGTKSA (see 12.6.1.1.9).
BIP-CMAC-128 provides data integrity and replay protection, using AES-128 in CMAC Mode with a 128-
bit integrity key and a CMAC TLen value of 128 (16 octets). BIP-CMAC-256 provides data integrity and
replay protection, using AES-256 in CMAC Mode with a 256-bit integrity key and a CMAC TLen value of
128 (16 octets). NIST Special Publication 800-38B defines the CMAC algorithm, and NIST SP 800-38D
defines the GMAC algorithm. BIP processing uses AES with a 128-bit or 256-bit integrity key and a CMAC
TLen value of 128 (16 octets). The CMAC output for BIP-CMAC-256 is not truncated and shall be 128 bits
(16 octets). The CMAC output for BIP-CMAC-128 is truncated to 64 bits:
MIC = Truncate-64(CMAC Output).
BIP-GCMP-128 uses AES with a 128-bit integrity key, and BIP-GCMP-256 uses AES with a 256-bit
integrity key. The authentication tag for both BIP-GCMP-128 and BIP-GCMP-256 is not truncated and shall
be 128 bits (16 octets).
1974
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
BIP uses the IGTK to compute the MMPDU MIC. The authenticator shall distribute one new IGTK and
IGTK PN (IPN) whenever it distributes a new GTK. The IGTK is identified by the MAC address of the
transmitting STA plus an IGTK identifier that is encoded in the MME Key ID field.
12.5.4.2 BIP MMPDU format
The Management MIC element shall follow all of the other elements in the management frame body but
precede the FCS. See 9.4.2.55 for the format of the Management MIC element. Figure 12-22 shows the BIP
MMPDU.
IEEE 802.11 Header Management Frame Body including MME FCS
Figure 12-22—BIP Encapsulation
12.5.4.3 BIP AAD construction
The BIP Additional Authentication Data (AAD) shall be constructed from the MPDU header. The Duration
field in the AAD shall be masked to 0. The AAD construction shall use a copy of the IEEE 802.11 header
without the SC field for the MPDU, with the following exceptions:
a) FC—MPDU Frame Control field, with:
1) Retry subfield (bit 11) masked to 0
2) Power Management subfield (bit 12) masked to 0
3) More Data subfield (bit 13) masked to 0
b) A1—MPDU Address 1 field.
c) A2—MPDU Address 2 field.
d) A3—MPDU Address 3 field.
Figure 12-23 depicts the format of the AAD. The length of the AAD is 20 octets.
FC A1 A2 A3
Octets: 2 6 6 6
Figure 12-23—BIP AAD Construction
12.5.4.4 BIP replay protection
The MME Sequence Number field represents a sequence number whose length is 6 octets.
When management frame protection is negotiated, the receiver shall maintain a 48-bit replay counter for
each IGTK. The receiver shall set the receive replay counter to the value of the IPN in the IGTK key data
encapsulation (KDE) (see 12.7.2) provided by the Authenticator in either the 4-way handshake, FT 4-way
handshake, FT handshake, or group key handshake. The transmitter shall maintain a single IPN for each
IGTK. The IPN shall be implemented as a 48-bit strictly increasing integer, initialized to 1 when the
corresponding IGTK is initialized. The transmitter may reinitialize the sequence counter when the IGTK is
refreshed. See 12.5.4.5 and 12.5.4.6 for per packet BIP processing.
NOTE—When the IPN space is exhausted, the choices available to an implementation are to replace the IGTK or to end
communications.
When dot11QMFActivated is true, the receiver shall maintain an additional replay counter for each ACI for
received group addressed robust Management frames that use QMF. The receiver shall use the ACI encoded
in the Sequence Number field of received GQMFs protected by BIP to select the replay counter to use for
the received frame, and shall use the IPN from the received frame to detect replays.
1975
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If dot11RSNAProtectedManagementFramesActivated is true and dot11MeshSecurityActivated is true, the
recipient shall maintain a single replay counter for received group addressed robust Management frames that
do not use the QMF service and shall use the PN from the received frame to detect replays. If
dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each ACI for
received group addressed robust Management frames that use the QMF service. The QMF receiver shall use
the ACI encoded in the Sequence Number field of the received frame to select the replay counter to use for
the received frame, and shall use the PN from the received frame to detect replays. A replayed frame occurs
when the PN from the frame is less than or equal to the value of the management frame replay counter that
corresponds to the ACI of the frame. The transmitter shall preserve the order of protected robust
Management frames transmitted to the same DA without the QMF service. When the QMF service is used,
the transmitter shall not reorder robust GQMFs within an AC when the frames are transmitted to the
same RA.
12.5.4.5 BIP transmission
When a STA transmits a protected group addressed robust Management frame, it shall
a) Select the IGTK currently active for transmission of frames to the intended group of recipients and
construct the MME (see 9.4.2.55) with the MIC field masked to 0 and the Key ID field set to the
corresponding IGTK Key ID value. If the frame is not a GQMF, the transmitting STA shall insert a
strictly increasing integer into the MME IPN field. If the frame is a GQMF, then the transmitting
STA shall maintain a 48-bit counter for use as the IPN, the counter shall be incremented for each
GQMF until the two least significant bits of the counter match the ACI of the AC that is used to
transmit the frame, and the counter value shall be inserted into the MME IPN field of the frame. For
BIP-GMAC-128 and BIP-GMAC-256, the initialization vector passed to GMAC shall be a
concatenation of Address 2 from the MAC header of the MPDU and the non-negative integer
inserted into the MMP IPN field.
b) Compute AAD as specified in 12.5.4.3.
c) Compute an integrity value over the concatenation of AAD and the management frame body includ-
ing MME, and insert the output into the MME MIC field. For BIP-CMAC-128, the integrity value is
64 bits and is computed using AES-128-CMAC; for BIP-CMAC-256, the integrity value is 128 bits
and is computed using AES-256-CMAC; for BIP-GMAC-128, the integrity value is 128 bits and is
computed using AES-128-GMAC; and, for BIP-GMAC-256, the integrity value is 128 bits and is
computed using AES-256-GMAC.
d) Compose the frame as the IEEE 802.11 header, management frame body, including MME, and FCS.
The MME shall appear last in the frame body.
e) Transmit the frame.
12.5.4.6 BIP reception
When a STA with management frame protection negotiated receives a group addressed robust Management
frame protected by BIP-CMAC-128, BIP-CMAC-256, BIP-GMAC-128, or BIP-GMAC-256, it shall
a) Identify the appropriate IGTK and associated state based on the MME Key ID field. If no such
IGTK exists, silently drop the frame and terminate BIP processing for this reception.
b) Perform replay protection on the received frame. The receiver shall interpret the MME IPN field as
a 48-bit unsigned integer.
1) If the frame is not a GQMF, the receiver shall compare this MME IPN integer value to the
value of the receive replay counter for the IGTK identified by the MME Key ID field. If the
integer value from the received MME IPN field is less than or equal to the replay counter value
for this IGTK, the receiver shall discard the frame and increment the
dot11RSNAStatsCMACReplays counter by 1.
1976
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
2) If the frame is a GQMF, the receiver shall compare this MME IPN integer value to the value of
the receive replay counter for the IGTK identified by the MME Key ID field and the AC
represented by the value of the ACI subfield of the received frame. If the integer value from the
received MME IPN field is less than or equal to the replay counter value for this IGTK and AC,
the receiver shall discard the frame and increment the dot11RSNAStatsCMACReplays counter
by 1.
c) Compute AAD for this Management frame, as specified in 12.5.4.3. For BIP-GMAC-128 and BIP-
GMAC-256, an initialization vector for GMAC is constructed as the concatenation of Address 2
from the MAC header of the MPDU and the 48-bit unsigned integer from the MME IPN field.
d) Extract and save the received MIC value, and compute a verifier over the concatenation of AAD, the
management frame body, and MME, with the MIC field masked to 0 in the MME. For BIP-CMAC-
128, the integrity value is 64 bits and is computed using AES-128-CMAC; for BIP-CMAC-256, the
integrity value is 128 bits and is computed using AES-256-CMAC; for BIP-GMAC-128, the integ-
rity value is 128 bits and is computed using AES-128-GMAC; and, for BIP-GMAC-256, the integ-
rity value is 128 bits and is computed using AES-256-GMAC. If the result does not match the
received MIC value, then the receiver shall discard the frame, increment the dot11RSNAStatsBIP-
MICErrors counter by 1, and terminate BIP processing for this reception.
e) If the frame is not a GQMF, update the replay counter for the IGTK identified by the MME Key ID
field with the integer value of the MME IPN field.
f) If the frame is a GQMF, update the replay counter for the IGTK identified by the MME Key ID field
and the AC represented by the value of the ACI subfield of the received frame with the integer value
of the MME IPN field.
If management frame protection is negotiated, group addressed robust Management frames that are received
without BIP protection shall be discarded.
12.5.5 GCM protocol (GCMP)
12.5.5.1 GCMP overview
Subclause 12.5.5 specifies the GCMP, which provides data confidentiality, authentication, integrity, and
replay protection. A DMG RSNA STA shall support GCMP-128.
GCMP is based on the GCM of the AES encryption algorithm. GCM protects the integrity of both the
MPDU Data field and selected portions of the MPDU header.
The AES algorithm is defined in FIPS PUB 197. All AES processing used within GCMP uses AES with a
128-bit key (GCMP-128) or a 256-bit key (GCMP-256).
GCM is defined in NIST Special Publication 800-38D. GCM is a generic mode that can be used with any
block-oriented encryption algorithm.
GCM requires a fresh temporal key for every session. GCM also requires a unique nonce value for each
frame protected by a given temporal key, and GCMP uses a 96-bit nonce that includes a 48-bit packet
number (PN) for this purpose. Reuse of a PN with the same temporal key voids all security guarantees.
GCMP uses a 128-bit MIC.
Annex J provides test vectors for GCM.
When GCMP is selected as the RSN pairwise cipher and management frame protection is negotiated,
individually addressed robust Management frames and the group addressed Management frames that receive
“Group Addressed Privacy” as indicated in Table 9-47 shall be protected with GCMP.
1977
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.5.5.2 GCMP MPDU format
Figure 12-24 shows the MPDU format when using GCMP.
Encrypted
GCMP Header Data (PDU) MIC FCS
MAC Header
8 octets ≥ 1 octets 16 octets 4 octets
Ext Key
PN0 PN1 Rsvd Rsvd PN2 PN3 PN4 PN5
IV ID
b0 b4 b5 b6 b7
Key ID octet
Figure 12-24—Expanded GCMP MPDU
GCMP processing expands the original MPDU size by 24 octets, 8 octets for the GCMP Header field and 16
octets for the MIC field. The GCMP Header field is constructed from the PN and Key ID subfields. The 48-
bit PN is represented as an array of 6 octets. PN5 is the most significant octet of the PN, and PN0 is the least
significant.
The ExtIV subfield (bit 5) of the Key ID octet is always set to 1 for GCMP.
Bits 6–7 of the Key ID octet are for the Key ID subfield. The remaining bits of the Key ID octet are reserved.
12.5.5.3 GCMP cryptographic encapsulation
12.5.5.3.1 General
The GCMP cryptographic encapsulation process is depicted in Figure 12-25.
MAC Header
Construct
AAD
Plaintext MPDU
Encrypted
A2 Encrypted
Construct GCM Data, MIC
||
MPDU
Nonce encryption
Data
TK
PN Increment
PN Construct
Key ID GCMP header
Figure 12-25—GCMP encapsulation block diagram
GCMP encrypts the Frame Body field of a plaintext MPDU and encapsulates the resulting cipher text using
the following steps:
a) Increment the PN, to obtain a fresh PN for each MPDU, so that the PN never repeats for the same
temporal key.
NOTE—Retransmitted MPDUs are not modified on retransmission.
1978
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) Use the fields in the MPDU header to construct the additional authentication data (AAD) for GCM.
The GCM algorithm provides integrity protection for the fields included in the AAD. MPDU header
fields that may change when retransmitted are masked to 0 when calculating the AAD.
c) Construct the GCM Nonce block from the PN and A2, where A2 is MPDU Address 2.
d) Place the new PN and the key identifier into the 8-octet GCMP Header.
e) Use the temporal key, AAD, nonce, and MPDU data to form the cipher text and MIC. This step is
known as GCM originator processing.
f) Form the encrypted MPDU by combining the original MPDU header, the GCMP header, the
encrypted data and MIC, as described in 12.5.5.2.
The GCM reference describes the processing of the key, nonce, AAD, and data to produce the encrypted
output. See 12.5.5.3.2 to 12.5.5.3.6 for details of the creation of the AAD and nonce from the MPDU and the
associated MPDU-specific processing.
12.5.5.3.2 PN processing
The PN is incremented by a positive number for each MPDU. The PN shall be incremented in steps of 1 for
constituent MPDUs of fragmented MSDUs and MMPDUs. The PN shall never repeat for a series of
encrypted MPDUs using the same temporal key.
If the PN is larger than dot11PNExhaustionThreshold, an MLME-PN-EXHAUSTION.indication primitive
shall be generated.
NOTE—When a group addressed MSDU is retransmitted using GCR, it is concealed from non-GCR capable STAs
using the procedures described in 11.24.16.3.5. The MPDU containing this concealed A-MSDU has a different PN from
the MPDU that contained the original transmission of the group addressed MSDU.
12.5.5.3.3 Construct AAD
The AAD construction is as defined in 12.5.3.3.3.
12.5.5.3.4 Construct GCM nonce
The Nonce field occupies 12 octets, and its structure is shown in Figure 12-26.
A2 PN
Octets: 6 6
Figure 12-26—Nonce construction
The Nonce field has an internal structure of A2 || PN, where
— MPDU address A2 field occupies octets 0 to 5. This shall be encoded with the octets ordered with
A2 octet 0 at octet index 0 and A2 octet 5 at octet index 5.
— The PN field occupies octets 6 to 11. The octets of PN shall be ordered so that PN0 is at octet index
11 and PN5 is at octet index 6.
12.5.5.3.5 Construct GCMP header
The format of the 8-octet GCMP Header is given in 12.5.5.2. The header encodes the PN and Key ID field
values used to encrypt the MPDU.
1979
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.5.5.3.6 GCM originator processing
GCM is a generic authenticate-and-encrypt block cipher mode, and in this standard, GCM is used with the
AES block cipher.
There are four inputs to GCM originator processing:
a) Key: the temporal key (16 octets).
b) Nonce: the nonce (12 octets) constructed as described in 12.5.5.3.4.
c) Frame body: the plaintext frame body of the MPDU.
d) AAD: the AAD (22-30 octets) constructed from the MPDU header as described in 12.5.5.3.3.
The GCM originator processing provides authentication and integrity of the frame body and the AAD as
well as data confidentiality of the frame body. The output from the GCM originator processing consists of
the encrypted data and 16 additional octets of encrypted MIC (see Figure 12-24).
The PN values sequentially number each MPDU. Each transmitter shall maintain a single PN (48-bit
counter) for each PTKSA, GTKSA, and STKSA. The PN shall be implemented as a 48-bit strictly
increasing integer, initialized to 1 when the corresponding temporal key is initialized or refreshed.
A transmitter shall not use IEEE 802.11 MSDU or A-MSDU priorities without ensuring that the receiver
supports the required number of replay counters. The transmitter shall not reorder GCMP protected frames
that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters.
One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.
The transmitter shall preserve the order of protected robust Management frames that are transmitted to the
same DA without the QMF service. When the QMF service is used, the transmitter shall not reorder robust
IQMFs within an AC when the frames are transmitted to the same RA.
A GCMP protected individually addressed robust Management frame shall be protected using the same TK
as a Data frame.
12.5.5.4 GCMP decapsulation
12.5.5.4.1 General
Figure 12-27 shows the GCMP decapsulation process.
MAC Header
Construct
Encrypted AAD
MPDU ||
MIC
Plaintext
A2
Construct GCM Data
PN Nonce decryption
Data
Key
Plaintext
PN* Replay MPDU
check
Figure 12-27—GCMP decapsulation block diagram
1980
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
GCMP decrypts the Frame Body field of a cipher text MPDU and decapsulates a plaintext MPDU using the
following steps:
a) The encrypted MPDU is parsed to construct the AAD and nonce values.
b) The AAD is formed from the MPDU header of the encrypted MPDU.
c) The Nonce value is constructed from the A2 and PN fields.
d) The MIC is extracted for use in the GCM integrity checking.
e) The GCM recipient processing uses the temporal key, AAD, nonce, MIC, and MPDU cipher text
data to recover the MPDU plaintext data as well as to check the integrity of the AAD and MPDU
plaintext data.
f) The received MPDU header and the MPDU plaintext data from the GCM recipient processing are
concatenated to form a plaintext MPDU.
g) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is
greater than the replay counter maintained for the session.
See 12.5.5.4.2 to 12.5.5.4.4 for details of this processing.
When the received frame is a GCMP protected individually addressed robust Management frame, the
contents of the MMPDU body after protection is removed and shall be delivered to the SME via the MLME
primitive designated for that MMPDU rather than through the MA-UNITDATA.indication primitive.
12.5.5.4.2 GCM recipient processing
GCM recipient processing shall use the same parameters as GCM originator processing. A GCMP protected
individually addressed robust Management frame shall use the same TK as a Data frame.
There are four inputs to GCM recipient processing:
— Key: the temporal key (16 octets).
— Nonce: the nonce (12 octets) constructed as described in 12.5.5.3.4.
— Encrypted frame body: the encrypted frame body from the received MPDU. The encrypted frame
body includes a 16-octet MIC.
— AAD: the AAD (22-30 octets) that is the canonical MPDU header as described in 12.5.5.3.3.
The GCM recipient processing checks the authentication and integrity of the frame body and the AAD as
well as decrypting the frame body. The plaintext is returned only if the MIC check is successful.
There is one output from error-free GCM recipient processing:
— Frame body: the plaintext frame body, which is 16 octets smaller than the encrypted frame body.
12.5.5.4.3 Decrypted GCMP MPDU
The decapsulation process succeeds when the calculated MIC matches the MIC value obtained from
decrypting the received encrypted MPDU. The original MPDU header is concatenated with the plaintext
data resulting from the successful GCM recipient processing to create the plaintext MPDU.
12.5.5.4.4 PN and replay detection
To effect replay detection, the receiver extracts the PN from the GCMP header. See 12.5.5.2 for a
description of how the PN is encoded in the GCMP header. The following processing rules are used to detect
replay:
1981
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) The receiver shall maintain a separate set of replay counters for each PTKSA, GTKSA, and STKSA.
The receiver initializes these replay counters to 0 when it resets the temporal key for a peer. The
replay counter is set to the PN value of accepted GCMP MPDUs.
b) For each PTKSA, GTKSA, and STKSA, the recipient shall maintain a separate replay counter for
each TID, subject to the limitation of the number of supported replay counters indicated in the RSN
Capabilities field (see 9.4.2.25), and shall use the PN from a received frame to detect replayed
frames. A replayed frame occurs when the PN from a received frame is less than or equal to the
current replay counter value for the frame’s MSDU or A-MSDU priority and frame type.
c) If dot11RSNAProtectedManagementFramesActivated is true, the recipient shall maintain a single
replay counter for received individually addressed robust Management frames that are received with
the To DS subfield equal to 0 and shall use the PN from the received frame to detect replays. If
dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each
ACI for received individually addressed robust Management frames that are received with the To
DS subfield equal to 1. The QMF receiver shall use the ACI encoded in the Sequence Number field
of the received frame to select the replay counter to use for the received frame, and shall use the PN
from the received frame to detect replays. A replayed frame occurs when the PN from the frame is
less than or equal to the current value of the management frame replay counter that corresponds to
the ACI of the frame.
d) The receiver shall discard any Data frame that is received with its PN less than or equal to the value
of the replay counter that is associated with the TA and priority value of the received MPDU. The
receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not
incrementing in steps of 1. If dot11RSNAProtectedManagementFramesActivated is true, the
receiver shall discard any individually addressed robust Management frame that is received with its
PN less than or equal to the value of the replay counter associated with the TA of that individually
addressed Management frame.
e) When discarding a frame, the receiver shall increment by 1 dot11RSNAStatsGCMPReplays for
Data frames or dot11RSNAStatsRobustMgmtGCMPReplays for robust Management frames.
f) For MSDUs or A-MSDUs sent using the block ack feature, reordering of received MSDUs or
A-MSDUs according to the block ack receiver operation (described in 10.24.4) is performed prior to
replay detection.
12.6 RSNA security association management
12.6.1 Security associations
12.6.1.1 Security association definitions
12.6.1.1.1 General
IEEE Std 802.11 uses the notion of a security association to describe secure operation. Secure
communications are possible only within the context of a security association, as this is the context
providing the state—cryptographic keys, counters, sequence spaces, etc.—needed for correct operation of
the IEEE 802.11 cipher suites.
A security association is a set of policy(ies) and key(s) used to protect information. The information in the
security association is stored by each party of the security association, needs to be consistent among all
parties, and needs to have an identity. The identity is a compact name of the key and other bits of security
association information to fit into a table index or an MPDU. The following types of security associations
are supported by an RSNA STA:
— PMKSA: A result of a successful IEEE 802.1X exchange, SAE authentication, or preshared PMK
information. A PMKSA can be cached.
1982
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— PMK-R0 security association: A result of a successful FT initial mobility domain association.
— PMK-R1 security association: A result of a successful FT initial mobility domain association or FT
authentication sequence.
— Mesh PMKSA: A result of successful completion of the active authentication protocol.
— PTKSA: A result of a successful 4-way handshake, FT 4-way handshake, or FT authentication
sequence.
— Mesh TKSA: A result of a successful authenticated mesh peering exchange (AMPE).
— GTKSA: A result of a successful group key handshake, 4-way handshake, FT 4-way handshake, or
FT authentication sequence.
— IGTKSA: A result of a successful group key handshake, successful 4-way handshake, FT 4-way
handshake, or the Reassociation Response frame of the fast BSS transition protocol.
— Mesh GTKSA: A result of a successful AMPE or mesh group key handshake.
— SMKSA: A result of a successful initial SMK handshake.
— STKSA: A result of a successful 4-way STK handshake following the initial SMK handshake or
subsequent rekeying.
In order to set up a security association to a peer STA, a SME that does not know the security policy of the
peer should send a Probe Request frame to the peer STA to find its security policy before setting up a
security association to the peer STA.
In order to set up a security association to a peer STA, a STA that received a 4-way handshake but does not
know the security policy of the peer should send a Probe Request frame to the peer STA to find its security
policy before setting up a security association to the peer STA.
12.6.1.1.2 PMKSA
When the PMKSA is the result of a successful IEEE 802.1X authentication, it is derived from the EAP
authentication and authorization parameters provided by the AS. When the PMKSA is the result of a
successful SAE authentication, it is generated as a result of the successful completion of the SAE exchange.
This security association is bidirectional. In other words, both parties use the information in the security
association for both sending and receiving. The PMKSA is created by the Supplicant’s SME when the EAP
authentication completes successfully or the PSK is configured. The PMKSA is created by the
Authenticator’s SME when the PMK is created from the keying information transferred from the AS, when
IEEE 802.1X authentication is utilized, when the SAE exchange successfully completes, or when the PSK is
configured. The PMKSA is used to create the PTKSA. PMKSAs have a certain lifetime. The PMKSA
consists of the following:
— PMKID, as defined in 12.7.1.3. The PMKID identifies the security association.
— Authenticator’s or peer’s MAC address. For multi-band RSNA, the MAC address is associated with
the operating band in use when the PMKSA is established.
— PMK.
— Lifetime, as defined in 12.7.1.3.
— AKMP.
— All authorization parameters specified by the AS or local configuration. This might include
parameters such as the STA’s authorized SSID.
12.6.1.1.3 PMK-R0 security association
The PMK-R0 security association is the result of a successful completion of the IEEE 802.1X
authentication, SAE authentication, or use of PSK during the FT initial mobility domain association. This
security association is bidirectional. It consists of the following:
1983
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— SSID
— Mobility domain identifier (MDID)
— PMK-R0
— R0KH-ID
— PMKR0Name
— S0KH-ID
— PMK-R0 lifetime
— Pairwise cipher suite selector
— All authorization parameters specified by the AS or local configuration
12.6.1.1.4 PMK-R1 security association
The PMK-R1 security association is the result of
— A successful completion of the IEEE 802.1X authentication, SAE authentication, or use of PSK
during the FT initial mobility domain association or
— A successful completion of the authentication phase in the fast BSS transition to the target AP
This security association is bidirectional. It consists of the following:
— SSID
— MDID
— PMK-R1
— PMK-R1 lifetime
— PMKR1Name
— R1KH-ID
— R0KH-ID
— PMKR0Name
— S0KH-ID
— S1KH-ID
— Pairwise cipher suite selector
— All authorization parameters specified by the AS or local configuration
12.6.1.1.5 Mesh PMKSA
The mesh PMKSA is the result of successful completion of the active authentication protocol. This security
association is bidirectional. The two authenticated parties use the information in the security association for
both sending and receiving. The mesh PMKSA is created by the Mesh STA’s SME when the active
authentication protocol completes successfully with the peer mesh STA. The mesh PMKSA is used to create
the mesh TKSA. Mesh PMKSAs have a certain lifetime. Mesh PMKSAs contain the following, and are
identified by their PMKID.
— PMKID, as defined in 12.4.5.4
— Mesh STA’s MAC address
— Peer mesh STA’s MAC address
— PMK
— AEK, as defined in 14.5.7
— Lifetime, as defined in 12.7.1.3
— Selected AKM suite (see 9.4.2.25.3)
1984
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.6.1.1.6 PTKSA
The PTKSA is a result of the 4-way handshake, FT 4-way handshake, FT protocol, or FT resource request
protocol. This security association is also bidirectional. PTKSAs have the same lifetime as the PMKSA or
PMK-R1 security Association, whichever comes first. Because the PTKSA is tied to the PMKSA or to a
PMK-R1 security association, it only has the additional information from the 4-way handshake or FT
Protocol authentication. For the PTKSA derived as a result of the 4-way handshake, there shall be only one
PTKSA per band (see 12.6.19) with the same Supplicant and Authenticator MAC addresses. For the PTKSA
derived as a result of an initial mobility domain association or fast BSS transition, there shall be only one
PTKSA with the same STA’s MAC address and BSSID.
During the 4-way handshake defined in 12.7.6.5 and the FT 4-way handshake defined in 13.4.2, there is state
created between message 1 and message 3 of the handshake. This does not create a PTKSA until message 3
is validated by the Supplicant and message 4 is validated by the Authenticator.
During the FT authentication sequence defined in 13.8, the PTKSA is validated when message 3 is validated
by the R1KH and message 4 is validated by the S1KH.
The PTKSA consists of the following:
— PTK
— Pairwise cipher suite selector
— Supplicant MAC address or STA’s MAC address
— Authenticator MAC address or BSSID
— Key ID
— If FT key hierarchy is used,
— R1KH-ID
— S1KH-ID
— PTKName
12.6.1.1.7 Mesh TKSA
The mesh TKSA is a result of the AMPE. This security association is also bidirectional. The mesh TKSA
shall be deleted when the lifetime expires. The mesh TKSA contains the following:
— MTK, as defined in 14.5.7
— PMKID
— Local mesh STA MAC address
— Peer mesh STA MAC address
— Local Link ID
— Peer Link ID
— Local nonce
— Peer nonce
— Lifetime as defined in 12.6.16
— Pairwise cipher suite selector
12.6.1.1.8 GTKSA
The GTKSA results from a successful 4-way handshake, FT 4-way handshake, FT protocol, FT resource
request protocol or the group key handshake and is unidirectional. In an infrastructure BSS, there is one
GTKSA, used exclusively for encrypting group addressed MPDUs that are transmitted by the AP and for
1985
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
decrypting group addressed transmissions that are received by the STAs. In an IBSS or in a PBSS, each STA
defines its own GTKSA, which is used to encrypt its group addressed transmissions, and stores a separate
GTKSA for each peer STA so that encrypted group addressed traffic received from other STAs may be
decrypted. A GTKSA is created by the Supplicant’s SME when message 3 of the 4-way handshake is
received, when message 1 of the group key handshake is received, or when the Reassociation Response
frame of the FT handshake is received. The GTKSA is created by the Authenticator’s SME when the SME
changes the GTK and has sent the GTK to all STAs with which it has a PTKSA. A GTKSA consists of the
following:
— Direction vector (whether the GTK is used for transmit or receive).
— Group cipher suite selector.
— GTK.
— Authenticator MAC address.
— Key ID.
— All authorization parameters specified by local configuration. This might include parameters such as
the STA’s authorized SSID.
When the GTK is used to encrypt individually addressed traffic (the selectable cipher suite is “Use group
cipher suite”), the GTKSA is bidirectional.
12.6.1.1.9 IGTKSA
When management frame protection is enabled, a non-AP STA’s SME creates an IGTKSA when it receives
a valid message 3 of the 4-way handshake or FT 4-way handshake, the Reassociation Response frame of the
fast BSS transition protocol with a status code indicating success, a Mesh Peering Open Message of the
Authenticated Mesh Peering Exchange (AMPE) protocol, or a valid message 1 of the group key handshake.
The Authenticator’s SME creates an IGTKSA when it establishes or changes the IGTK with all STAs to
which it has a valid PTKSA or mesh TKSA.
An IGTKSA consists of the following:
— Direction vector (whether the IGTK is used for transmit or receive)
— Key ID
— IGTK
— Authenticator MAC address
12.6.1.1.10 Mesh GTKSA
The mesh GTKSA results from a successful AMPE or mesh group key handshake and is unidirectional. In
an MBSS, each mesh STA defines its own “transmit mesh GTKSA,” which is used to encrypt its group
addressed transmissions. Also, each mesh STA stores a separate “receive mesh GTKSA” for each peer mesh
STA so that encrypted group addressed traffic received from the peer mesh STAs may be decrypted.
A transmit mesh GTKSA is created by a mesh STA after the SME has changed the mesh GTK (MGTK) and
the new MGTK has been sent to all peer mesh STAs. A receive mesh GTKSA is created by a mesh STA
after successfully completing the AMPE in which a wrapped MGTK has been received, or after receiving a
valid message 1 of the mesh group key handshake. The receive mesh GTKSA shall be deleted when the
lifetime expires or a new receive mesh GTKSA is created with the same Key ID for the same MGTK source
mesh STA. See 14.6.1.
The MGTK and the GTK shall be independently selected from a uniform distribution. The MGTK source
mesh STA MAC address in the mesh GTKSA shall not be the same as the Authenticator MAC address in the
GTKSA.
1986
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—The use of a distinct Transmit MGTK and ESS GTK with identical transmit MAC addresses is precluded by
limitations on key rollover and reception by STAs in an infrastructure BSS (see 14.11.5 for collocated mesh STA rules).
If the distinct MGTKs were to use different Key IDs, then rollover would be impossible. Since Key ID 0 is reserved for
individually addressed frame transmission, there are at most three available Key IDs (only two if extended Key IDs for
individually addressed frames are in use), and the different MGTKs would contend for the single remaining Key ID
upon rollover. If the distinct MGTKs were to use the same Key IDs, then STAs would incorrectly attempt to decrypt
mesh broadcast traffic using the ESS GTK, causing error counters (such as dot11RSNAStatsCCMPDecryptErrors) to
continuously increment. (See 12.9.2.6 for a description of the procedure for receiving encrypted frames.)
The mesh GTKSA contains the following:
— MGTK
— MGTK source mesh STA MAC address (mesh STA that uses this GTK to encrypt transmissions)
— Group cipher suite selector
— Direction vector (whether this is a receive mesh GTKSA or transmit mesh GTKSA)
— Key Index
12.6.1.1.11 SMKSA
An SMKSA is the result of a successful SMK handshake by the initiator STA (described in 12.7.8 and
12.11). It is derived from parameters provided by the STAs and AP. This security association is bidirectional
between the initiator and the peer STA. In other words, both parties use the information in the security
association for both sending and receiving. The SMKSA is created as a result of a successful SMK
handshake (see 12.7.8 and 12.11). The SMKSA is used to create the STKSA. The SMKSA consists of the
following:
— SMKID, as defined in 12.7.8. The SMKID identifies the security association.
— BSSID
— Initiator MAC address
— Peer MAC address
— SMK
— Lifetime, as defined in 12.7.8.
— Pairwise cipher suite selector list, as proposed by initiator STA
— Pairwise cipher suite selector, as selected by peer STA
12.6.1.1.12 STKSA
The STKSA is a result of successful completion of the 4-way STK handshake. This security association is
bidirectional between the initiator and the peer STAs. The STKSA is used to create session keys to protect
this STSL. STKSAs have the same lifetime as the SMKSA or the STSL, whichever comes first. There shall
be only one STKSA with the same initiator STA and peer MAC addresses at any one time. STKSA is
created as a result of PeerKey handshake (see 12.7.8) or the AP PeerKey protocol (see 12.11). The STKSA
consists of the following:
— STK
— Pairwise cipher suite selector
— Initiator MAC address
— Peer MAC address
— Key ID
12.6.1.2 TPKSA
The TPKSA results from a successful completion of the TPK handshake. This security association is
bidirectional between the TDLS initiator STA and the TDLS responder STA. The TPKSA is used to create
1987
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
session keys to protect this TDLS session. The TPKSA has the lifetime indicated in the TPK handshake or
the lifetime of the TDLS direct link, whichever comes first.
The TPKSA consists of the following:
— MAC addresses of the TDLS initiator STA and the TDLS responder STA
— Pairwise cipher suite selector
— TPK Lifetime
— TPK
— Link Identifier
12.6.1.3 Security association life cycle
12.6.1.3.1 General
A STA can operate in an ESS, an IBSS, an MBSS, or a PBSS, and a security association has a distinct life
cycle for each. A STA that operates OCB does not have a security association life cycle.
12.6.1.3.2 Security association in an ESS
In an ESS there are two cases:
— Initial contact between the STA and the ESS
— Roaming by the STA within the ESS
A STA and AP establish an initial security association via the following steps:
a) The STA selects an authorized ESS by selecting among APs that advertise an appropriate SSID.
b) The STA then performs IEEE 802.11 authentication followed by association to the chosen AP.
Confirmation of security parameters takes place during association. A STA performing
IEEE 802.1X authentication uses Open System authentication. A STA performing password-based
authentication can use SAE authentication.
NOTE 1—It is possible for more than one PMKSA to exist. As an example, a second PMKSA might come into
existence through PMKSA caching. A STA might leave the ESS and flush its cache. Before its PMKSA expires in the
AP’s cache, the STA returns to the ESS and establishes a second PMKSA from the AP’s perspective.
NOTE 2—An attack altering the security parameters is detected by the key derivation procedure.
NOTE 3—IEEE 802.11 Open System authentication provides no security, but is included to maintain backward
compatibility with the IEEE 802.11 state machine (see 11.3).
c) SAE authentication provides mutual authentication and derivation of a PMK. If Open System
authentication is chosen instead, the Authenticator or the Supplicant initiates IEEE 802.1X
authentication. The EAP method used by IEEE Std 802.1X-2010 needs to support mutual
authentication, as the STA needs assurance that the AP is a legitimate AP.
NOTE 1—Prior to the completion of IEEE 802.1X authentication and the installation of keys, the IEEE 802.1X
Controlled Port in the AP blocks all Data frames. The IEEE 802.1X Controlled Port returns to the unauthorized state and
blocks all Data frames before invocation of an MLME-DELETEKEYS.request primitive. The IEEE 802.1X
Uncontrolled Port allows IEEE 802.1X frames to pass between the Supplicant and Authenticator. Although IEEE Std
802.1X-2010 does not require a Supplicant Controlled Port, this standard assumes that the Supplicant has a Controlled
Port in order to provide the needed level of security. Supplicants without a Controlled Port compromise RSN security
and are not used.
NOTE 2—Any secure network cannot support promiscuous association, e.g., an unsecured operation of IEEE Std
802.11. A trust relationship is needed between the STA and the AS of the targeted SSID prior to association and secure
operation, in order for the association to be trustworthy. The reason is that an attacker can deploy a rogue AP just as
easily as a legitimate network provider can deploy a legitimate AP, so some sort of prior relationship is necessary to
establish credentials between the ESS and the STA.
1988
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
d) The last step is key management. The authentication process, whether SAE authentication utilizing
Authentication frames or IEEE 802.1X authentication utilizing Data frames post association, creates
cryptographic keys shared between the cryptographic endpoints—the AP and STA, or the
IEEE 802.1X AS and the STA, when using SAE or IEEE Std 802.1X, respectively. When using
IEEE Std 802.1X, the AS transfers these keys to the AP, and the AP and STA uses one of the key
confirmation handshakes, e.g., the 4-way handshake or FT 4-way handshake, to complete security
association establishment. When using SAE authentication there is no AS and therefore no key
transfer; the 4-way handshake is performed directly between the AP and STA. The key confirmation
handshake indicates when the link has been secured by the keys and is ready to allow normal data
traffic and protected robust Management frames.
When FT is not enabled, a STA roaming within an ESS establishes a new PMKSA by one of the four
schemes:
— In the case of (re)association followed by IEEE 802.1X or PSK authentication, the STA repeats the
same actions as for an initial contact association, but its Supplicant also deletes the PTKSA when it
roams from the old AP. The Supplicant also deletes the PTKSA when it disassociates/
deauthenticates from all BSSIDs in the ESS.
— In the case of SAE authentication followed by (re)association, the STA repeats the same actions as
for initial contact association, but the non-AP STA also deletes the PTKSA when it roams from the
old AP. Note that a STA can take advantage of the fact that it can perform SAE authentication to
multiple APs while maintaining a single association with one AP, and then use any of the PMKSAs
created during authentication to effect a fast BSS transition.
— A STA (AP) can cache PMKSAs for APs (STAs) in the ESS to which it has previously performed a
full IEEE 802.1X authentication or SAE authentication. If a STA wishes to roam to an AP for which
it has cached one or more PMKSAs, it can include one or more PMKIDs in the RSNE of its
(Re)Association Request frame. An AP that has retained the PMK for one or more of the PMKIDs
can proceed with the 4-way handshake. The AP shall include the PMKID of the selected PMKSA in
message 1 of the 4-way handshake. If none of the PMKIDs of the cached PMKSAs matches any of
the supplied PMKIDs, or if the AKM of the cached PMKSA differs from that offered in the
(Re)Association Request, then the Authenticator, in the case of Open System authentication, shall
perform another IEEE 802.1X authentication and, in the case of SAE authentication, shall transmit a
Deauthentication frame to the STA. Similarly, if the STA fails to send a PMKID, the STA and AP
need to perform a full IEEE 802.1X authentication.
— A STA already associated with the ESS can request its IEEE 802.1X Supplicant to authenticate with
a new AP before associating to that new AP. The normal operation of the DS via the old AP
provides the communication between the STA and the new AP. The SME delays reassociation with
the new AP until IEEE 802.1X authentication completes via the DS. If IEEE 802.1X authentication
completes successfully, then PMKSAs shared between the new AP and the STA are cached, thereby
enabling the possible usage of reassociation without requiring a subsequent full IEEE 802.1X
authentication procedure.
The MLME-DELETEKEYS.request primitive deletes the temporal key(s) established for the security
association so that they cannot be used to protect subsequent IEEE 802.11 traffic. An SME uses this
primitive when it deletes a PTKSA, GTKSA, or IGTKSA.
12.6.1.3.3 Security association in an IBSS
In an IBSS utilizing IEEE 802.11 Open System authentication and IEEE Std 802.1X, when a STA’s SME
establishes a security association with a peer STA, it creates both an IEEE 802.1X Supplicant and
Authenticator for the peer. A STA in such an IBSS might also receive IEEE 802.1X messages from a
previously unknown MAC address.
1989
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In an IBSS utilizing IEEE 802.11 SAE authentication, a STA creates a security association for a peer upon
successful SAE authentication.
Any IBSS STA may decline to form a security association with a STA joining the IBSS. An attempt to form
a security association may also fail because, for example, the peer uses a different PSK or password from
what the STA expects.
In an IBSS each STA defines its own group key, i.e., GTK, to secure its group addressed transmissions.
Each STA shall use either the 4-way handshake or the group key handshake to distribute its transmit GTK to
its new peer STA. When the STA generates a new GTK, it also uses the group key handshake to distribute
the new GTK to each established peer.
12.6.1.3.4 Security association in an MBSS
In order to create a secure peering, mesh STAs first authenticate each other and create a mesh PMKSA. This
can be done using either SAE or IEEE Std 802.1X. A mesh STA shall support SAE authentication (see
12.4). A mesh STA may support IEEE 802.1X authentication (see 4.10).
When dot11MeshActiveAuthenticationProtocol is sae (1), the scanning mesh STA shall initiate SAE to the
candidate mesh STA. If SAE terminates unsuccessfully, the scanning mesh STA shall terminate the peering
establishment procedure. Otherwise, the PMK that results from successful SAE authentication shall be used
to create a mesh PMKSA.
When dot11MeshActiveAuthenticationProtocol is ieee8021x (2), then the scanning mesh STA shall initiate
the MPM protocol to establish a peering. If the MPM protocol fails then the scanning mesh STA shall
terminate the peering establishment procedure. Otherwise, IEEE 802.1X authentication shall be performed
between the two peers according to the following:
a) If only one mesh STA has the Connected to AS field set to 1, that STA shall act as the IEEE 802.1X
Authenticator and the other STA shall act as the IEEE 802.1X Supplicant;
b) If both mesh STAs have the Connected to AS field set to 1, then the mesh STA with the higher
MAC address shall act as the IEEE 802.1X Authenticator and the other mesh STA shall act as the
IEEE 802.1X Supplicant (see 12.7.1 for MAC address comparison).
If IEEE 802.1X authentication fails, the peering establishment procedure shall be terminated and the peering
established between the two mesh STAs shall be closed. Otherwise, the peering established between the two
mesh STAs shall be closed and a mesh PMKSA shall be created using the PMK that resulted from the
successful IEEE 802.1X authentication.
12.6.1.3.5 Security association in a PBSS
A STA and a peer establish an initial security association via the following steps:
a) The STA selects an authorized PBSS by identifying a peer from a DMG Beacon, Announce, Probe
Response, or Information Response frames.
b) A STA may associate with a peer if the peer is a PCP.
c) If authentication is required, the STA or the peer initiates IEEE 802.1X authentication. The EAP
method used by IEEE Std 802.1X-2010 shall support mutual authentication.
d) The last step is key management. The authentication process creates cryptographic keys shared
between the IEEE 802.1X AS and the STA. The AS transfers these keys to the peer and the peer and
the STA use one of the key confirmation handshakes, e.g., the 4-way handshake or FT 4-way
handshake, to complete security association establishment. The key confirmation handshake
indicates when the link has been secured by the keys and is ready to allow data traffic and protected
robust Management frames.
1990
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.6.2 RSNA selection
A STA prepared to establish RSNAs shall advertise its capabilities by including the RSNE in Beacon,
Information Response, and Probe Response frames and may also include the RSNE in DMG Beacon and
Announce frames. The included RSNE shall specify all of the authentication and cipher suites enabled by
the STA’s policy. A STA shall not advertise any authentication or cipher suite that is not enabled.
The SME shall utilize the MLME-SCAN.request primitive to identify neighboring STAs that assert robust
security and advertise an SSID identifying an authorized ESS, PBSS, or IBSS. A STA may decline to
communicate with STAs that fail to advertise an RSNE in their Beacon, Information Response, and Probe
Response frames or that do not advertise an authorized SSID. A STA may also decline to communicate with
other STAs that do not advertise authorized authentication and cipher suites within their RSNEs.
A STA shall advertise the same RSNE in its Beacon, DMG Beacon, Announce, Information Response, and
Probe Response frames.
NOTE—Whether a STA with robust security enabled attempts to communicate with a STA that does not include the
RSNE is a matter of policy.
A STA shall observe the following rules when processing an RSNE:
— A STA shall advertise the highest version it supports.
— A STA shall request the highest Version field value it supports that is less than or equal to the
version advertised by the peer STA.
— Two peer STAs without overlapping supported Version field values shall not use RSNA methods to
secure their communication.
— A STA shall ignore suite selectors that it does not recognize.
12.6.3 RSNA policy selection in an infrastructure BSS
RSNA policy selection in an infrastructure BSS utilizes the normal IEEE 802.11 association procedure.
RSNA policy selection is performed by the associating STA. The STA does this by including an RSNE in its
(Re)Association Requests.
In an RSN, an AP shall not associate with pre-RSNA STAs, i.e., with STAs that fail to include the RSNE in
the (Re)Association Request frame.
An SME initiating an association shall insert an RSNE into its (Re)Association Request via the MLME-
ASSOCIATE.request or MLME-REASSOCIATE.request primitive, when the targeted AP indicates RSNA
support. The initiating STA’s RSNE shall include one authentication and pairwise cipher suite from among
those advertised by the targeted AP in its Beacon and Probe Response frames. It shall also specify the group
cipher suite specified by the targeted AP. If at least one RSNE field from the AP’s RSNE fails to overlap
with any value the STA supports, the STA shall decline to associate with that AP. An HT STA shall
eliminate TKIP as a choice for the pairwise cipher suite if CCMP is advertised by the AP or if the AP
included an HT Capabilities element in its Beacon and Probe Response frames. The elimination of TKIP as
a choice for the pairwise cipher suite may result in a lack of overlap of the remaining pairwise cipher suite
choices, in which case the STA shall decline to create an RSN association with that AP.
If an RSNA-capable AP receives a (Re)Association Request frame that includes an RSNE and if it chooses
to accept the association as a secure association, then it shall use the authentication and pairwise cipher
suites in the (Re)Association Request frame, unless the AP includes an optional second RSNE in message 3
of the 4-way handshake. If the second RSNE is supplied in message 3, then the pairwise cipher suite used by
the security association, if established, shall be the pairwise cipher from the second RSNE.
1991
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In order to accommodate local security policy, a STA may choose not to associate with an AP that does not
support any pairwise cipher suites. An AP may indicate that it does not support any pairwise keys by
advertising 00-0F-AC:0 (Use group cipher suite) as the pairwise cipher suite selector.
NOTE—When an ESS uses PSKs, STAs negotiate a pairwise cipher. However, any STA in the ESS can derive the
pairwise keys of any other that uses the same PSK by capturing the first two messages of the 4-way handshake. This
provides malicious insiders with the ability to eavesdrop as well as the ability to establish a man-in-the-middle attack.
An RSNA-enabled AP shall use Table 12-2 and the values of the Management Frame Protection Capable
(MFPC) and Management Frame Protection Required (MFPR) bits advertised in the RSNEs to determine if
it may associate with a non-AP STA. An RSNA enabled non-AP STA shall use Table 12-2 and the values of
the Management Frame Protection Capable and Management Frame Protection Required bits advertised in
the RSNEs to determine if it may associate with an AP. Management frame protection is enabled when
dot11RSNAProtectedManagementFramesActivated is set to 1. Management frame protection is negotiated
when an AP and non-AP STA set the Management Frame Protection Capable field to 1 in their respective
RSNEs in the (re)association procedure, and both parties confirm the Management Frame Protection
Capable bit set to 1 in the 4-way handshake, FT 4-way handshake, or the FT fast BSS transition protocol.
Table 12-2—Robust management frame selection in an infrastructure BSS
AP AP STA STA
AP action STA action
MFPC MFPR MFPC MFPR
0 0 0 0 The AP may associate with the The STA may associate with the
STA AP
1 0 0 0 The AP may associate with the The STA may associate with the
STA AP
1 0 or 1 1 0 or 1 The AP may associate with the The STA may associate with the
STA AP
1 1 0 0 The AP shall reject associations The STA shall not associate
from the STA with the Status with the AP
Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION
0 0 1 1 No action The STA shall not try to
associate with the AP
0 0 1 0 The AP may associate with the The STA may associate with the
STA AP
1 0 or 1 0 1 The STA advertises an invalid The STA shall not try to
setting. The AP shall reject associate with the AP
associations from the STA with
the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION
0 1 1 0 or 1 No action The AP advertises an invalid
setting. The STA shall not try to
associate with the AP
12.6.4 TSN policy selection in an infrastructure BSS
In a TSN, an RSNA STA shall include the RSNE in its (Re)Association Requests.
1992
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An RSNA-capable AP configured to operate in a TSN shall include the RSNE and may associate with both
RSNA and pre-RSNA STAs. In other words, an RSNA-capable AP shall respond to an associating STA that
includes the RSNE just as in an RSN.
If an AP operating within a TSN receives a (Re)Association Request frame without an RSNE, its
IEEE 802.1X Controlled Port shall initially be blocked. The SME shall unblock the IEEE 802.1X Controlled
Port when WEP has been enabled.
12.6.5 RSNA policy selection in an IBSS and for DLS
In an IBSS all STAs use a single group cipher suite, and all STAs support a common subset of pairwise
cipher suites. However, the SMEs of any pair of non-HT STAs may negotiate to use any common pairwise
cipher suite they both support. Each STA shall include the group cipher suite and its list of pairwise cipher
suites in its Beacon and Probe Response frames. Two STAs shall not establish a PMKSA unless they have
advertised the same group cipher suite. Similarly, the two STAs shall not establish a PMKSA if the STAs
have advertised disjoint sets of pairwise cipher suites.
An HT STA that is in an IBSS or that is transmitting frames through a direct link shall eliminate TKIP as a
choice for the pairwise cipher suite if CCMP is advertised by the other STA or if the other STA included an
HT Capabilities element in any of its Beacon, Probe Response, DLS Request, or DLS Response frames.
NOTE—The elimination of TKIP as a choice for the pairwise cipher suite might result in a lack of overlap of the
remaining pairwise cipher suite choices, in which case the STAs do not exchange encrypted frames.
In order to set up a security association with a peer STA, the SME of an IBSS STA that does not know the
peer’s policy needs first to obtain the peer’s security policy using a Probe Request frame. The SME entities
of the two STAs select the pairwise cipher suites using one of the 4-way handshakes. The SMEs of each pair
of STAs within an IBSS may use the EAPOL-Key 4-way handshake to select a pairwise cipher suite. As
specified in 12.7.2, message 2 and message 3 of the 4-way handshake convey an RSNE. The message 2
RSNE includes the selected pairwise cipher suite, and message 3 includes the RSNE that the STA would
send in a Probe Response frame.
If the 4-way handshake is successfully completed, then the pair of STAs shall use the pairwise cipher suite
specified in message 2 of the 4-way handshake initiated by the Authenticator STA with the higher MAC
address (see 12.7.1).
The SME shall check that the group cipher suite and AKMP match those in the Beacon and Probe Response
frames for the IBSS.
NOTE 1—The RSNEs in message 2 and message 3 are not the same as in the Beacon frame. The group cipher and
AKMP are the same, but the pairwise ciphers might differ because Beacon frames from different STAs might advertise
different pairwise ciphers. Thus, IBSS STAs use the same AKM suite and group cipher, while different pairwise ciphers
might be used between STA pairs.
NOTE 2—When an IBSS uses PSKs, STAs can negotiate a pairwise cipher. However, any STA in the IBSS can derive
the PTKs of any other that uses the same PSK by capturing the first two messages of the 4-way handshake. This provides
malicious insiders with the ability to eavesdrop as well as the ability to establish a man-in-the-middle attack.
To establish a connection with a peer STA, an RSNA enabled STA that implements management frame
protection shall use Table 12-3 and the MFPC and MFPR values advertised in the RSNEs exchanged in the
4-way handshake initiated by the Authenticator of the STA with the larger MAC address to determine if the
communication is allowed. Management frame protection is enabled when
dot11RSNAProtectedManagementFramesActivated is set to 1. The STAs negotiate protection of
Management frames when the both STAs set the Management Frame Protection Capable subfield to 1
during the 4-way handshake.
1993
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 12-3—Robust management frame selection in an IBSS
Peer Peer
MFPC MFPR STA STA STA action
MFPC MFPR
0 0 0 0 The STA may exchange data with the peer STA.
1 0 0 0 The STA may exchange data with the peer STA.
1 0 or 1 1 0 or 1 The STA may exchange data with the peer STA.
1 1 0 0 The STA shall not exchange data with the peer STA and shall reject
security association attempts from the peer STA with the Status
Code ROBUST_MANAGEMENT_POLICY_VIOLATION.
0 0 1 1 The STA shall not exchange data with the peer STA and shall reject
security association attempts from the peer STA with the Status
Code ROBUST_MANAGEMENT_POLICY_VIOLATION.
0 0 1 0 The STA may establish a security association with the peer STA.
1 0 or 1 0 1 The STA shall not establish a security association with the peer STA
and shall reject security association attempts from the peer STA
with the Status Code
ROBUST_MANAGEMENT_POLICY_VIOLATION because the
peer STA is advertising an invalid setting. The STA shall not
exchange data with the peer STA.
0 1 1 0 or 1 The peer STA shall not establish a security association with the peer
STA and shall reject security association attempts from the STA
with the Status Code
ROBUST_MANAGEMENT_POLICY_VIOLATION because the
STA is advertising an invalid setting.
12.6.6 TSN policy selection in an IBSS
Pre-RSNA STAs generate Beacon and Probe Response frames without an RSNE and ignore the RSNE
because it is unknown to them. This allows an RSNA STA to identify the pre-RSNA STAs from which it
has received Beacon and Probe Response frames.
If an RSNA STA’s SME instead identifies a possible IBSS member on the basis of a received group
addressed message, via MLME-PROTECTEDFRAMEDROPPED.indication primitive, it cannot identify
the peer’s security policy directly. The SME might attempt to obtain the peer STA’s security policy via a
Probe Request frame.
12.6.7 RSNA policy selection in an MBSS
RSNA policy is advertised in Beacon frames and Probe Response frames. A mesh STA identifies a
candidate peer by parsing its neighbor STA’s Beacon frames and Probe Response frames (see 14.2). An HT
mesh STA shall eliminate TKIP as a choice for the pairwise cipher suite if CCMP is advertised by the peer
or if the peer included an HT Capabilities element in any of its Beacon or Probe Response frames.
All mesh STAs in an MBSS use the same group cipher suite. Mesh STAs establish authenticated peerings
with each other using the AMPE protocol (see 14.5). In AMPE, mesh STAs negotiate a pairwise cipher
suite, and establish a mesh TKSA, to protect individually addressed frames and state a group cipher suite
and establish a mesh GTKSA to process incoming group addressed frames from a peer.
1994
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The AMPE performs key confirmation of a secret, authenticated, and shared PMK derived by an
authenticated key management protocol (see 12.4) and derives pairwise symmetric keys.
12.6.8 RSNA policy selection in a PBSS
RSNA policy selection in a PBSS utilizes the association procedure (11.3.1) if the initiating STA chooses to
associate with a PCP. RSNA policy selection is performed by the associating STA. The STA does this by
including an RSNE in its (Re)Association Requests.
The STA follows the procedures in 12.5.3 to select RSNA policy with the PCP, with the PCP taking the role
of the AP. If the initiating STA chooses not to associate with a peer in a PBSS, it follows the procedures in
12.5.5 to select RSNA policy with the peer.
12.6.9 RSN management of the IEEE 802.1X Controlled Port
When the policy selection process chooses IEEE 802.1X authentication, this standard assumes that
IEEE 802.1X Supplicants and Authenticators exchange protocol information via the IEEE 802.1X
Uncontrolled port. The IEEE 802.1X Controlled Port is blocked from passing general data traffic between
the STAs until an IEEE 802.1X authentication procedure completes successfully over the IEEE 802.1X
Uncontrolled Port. The security of an RSNA depends on this assumption being true.
In an infrastructure BSS or PBSS, if the STA associates with the AP or PCP, the STA indicates the
IEEE 802.11 link is available by invoking the MLME-ASSOCIATE.confirm or MLME-
REASSOCIATE.confirm primitive. This signals the Supplicant that the MAC has transitioned from the
disabled to enabled state. At this point, the Supplicant’s Controlled Port is blocked, and communication of
all non-IEEE-802.1X MSDUs sent or received via the port is not authorized.
In an infrastructure BSS or PBSS, if the AP or PCP associates with a STA, the AP or PCP indicates that the
IEEE 802.11 link is available by invoking the MLME-ASSOCIATE.indication or MLME-
REASSOCIATE.indication primitive. At this point the Authenticator’s Controlled Port corresponding to the
STA’s association is blocked, and communication of all non-IEEE-802.1X MSDUs sent or received via the
Controlled Port is not authorized.
In an IBSS the STA shall block all IEEE 802.1X ports at initialization. Communication of all non-
IEEE 802.1X MSDUs sent or received via the Controlled Port is not authorized.
In a PBSS, if a STA chooses not to associate with the PCP, the STA shall block all IEEE 802.1X ports at
initialization. Communication of all non-IEEE-802.1X MSDUs sent or received via the Controlled Port is
not authorized.
This standard assumes each Controlled Port remains blocked until the IEEE 802.1X state variables
portValid and keyDone both become true. This assumption means that the IEEE 802.1X Controlled Port
discards MSDUs sent across the IEEE 802.11 channel prior to the installation of cryptographic keys into the
MAC. This protects the STA’s host from forged MSDUs written to the channel while it is still being
initialized.
The MAC does not distinguish between MSDUs for the Controlled Port, and MSDUs for the Uncontrolled
Port. In other words, EAPOL-Start frames and EAPOL-Key frames are encrypted only after invocation of
the MLME-SETPROTECTION.request primitive.
This standard assumes that IEEE Std 802.1X-2010 does not block the Controlled Port when authentication is
triggered through reauthentication. During IEEE 802.1X reauthentication, an existing RSNA can protect all
MSDUs exchanged between the STAs. Blocking MSDUs is not required during reauthentication over
an RSNA.
1995
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.6.10 RSNA authentication in an infrastructure BSS
12.6.10.1 General
When establishing an RSNA in a non-FT environment or during an FT initial mobility domain association, a
STA shall use IEEE 802.11 SAE authentication or Open System authentication prior to (re)association.
SAE authentication is initiated when a STA’s MLME-SCAN.confirm primitive finds another AP within the
current ESS that advertises support for SAE in its RSNE.
IEEE 802.1X authentication is initiated by any one of the following mechanisms:
— If a STA negotiates to use IEEE 802.1X authentication during (re)association, the STA’s
management entity may respond to the MLME-ASSOCIATE.confirm (or indication) or MLME-
REASSOCIATE.confirm (or indication) primitive by requesting the Supplicant (or Authenticator)
to initiate IEEE 802.1X authentication. Thus, in this case, authentication is driven by the STA’s
decision to associate and the AP’s decision to accept the association.
— If a STA’s MLME-SCAN.confirm primitive finds another AP within the current ESS, a STA may
signal its Supplicant to use IEEE Std 802.1X-2010 to preauthenticate with that AP.
NOTE—A roaming STA’s IEEE 802.1X Supplicant can initiate preauthentication by sending an EAPOL-Start frame via
its old AP, through the DS, to a new AP.
— If a STA receives an IEEE 802.1X message, it delivers this to its Supplicant or Authenticator, which
may initiate a new IEEE 802.1X authentication.
12.6.10.2 Preauthentication and RSNA key management
Preauthentication allows a STA to perform RSNA authentication with an AP prior to attempting
(re)association. This might reduce the time that the IEEE 802.1X port is not valid.
A STA shall not use preauthentication except when pairwise keys are employed. A STA shall not use
preauthentication within the same mobility domain if AKM suite type 00-0F-AC:3 or 00-0F-AC:4 is used in
the current association. Preauthentication shall not be used unless the new AP advertises the
preauthentication capability in the RSNE.
When preauthentication is used, then:
a) Authentication is independent of roaming.
b) The Supplicant may authenticate with multiple APs at a time.
NOTE—Preauthentication might be useful as a performance enhancement, as reassociation does not include the protocol
overhead of a full reauthentication when it is used.
Preauthentication uses the IEEE 802.1X protocol and state machines with EtherType 88-C7, rather than the
EtherType 88-8E. Only IEEE 802.1X frame types EAP-Packet and EAPOL-Start are valid for
preauthentication.
A Supplicant may initiate preauthentication when it has completed the 4-way handshake and configured the
required temporal key(s). To effect preauthentication, the Supplicant sends an EAPOL-Start frame with the
DA being the BSSID of a targeted AP and the RA being the BSSID of the AP with which it is associated.
The target AP shall use a BSSID equal to the MAC address of its Authenticator. As preauthentication frames
do not use the IEEE 802.1X EAPOL EtherType field, the AP with which the STA is currently associated
need not apply any special handling. The AP and the MAC in the STA shall handle these frames in the same
way as other frames with arbitrary EtherType field values that require distribution via the DS.
1996
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An AP’s Authenticator that receives an EAPOL-Start frame via the DS may initiate IEEE 802.1X
authentication to the STA via the DS. The DS forwards this message to the AP with which the STA is
associated.
The result of preauthentication may be a PMKSA, if the IEEE 802.1X authentication completes
successfully. The AKM shall be set to 00-0F-AC:1 in the PMKSA that results from preauthentication. If
preauthentication produces a PMKSA, then, when the Supplicant’s STA associates with the
preauthenticated AP, the Supplicant may use the PMKSA with the 4-way handshake.
Successful completion of EAP authentication over IEEE Std 802.1X establishes a PMKSA at the
Supplicant. The Authenticator has the PMKSA when the AS completes the authentication, passes the keying
information (the master session key (MSK), a portion of which is the PMK) to the Authenticator, and the
Authenticator creates a PMKSA using the PMK. The PMKSA is inserted into the PMKSA cache. Therefore,
if the Supplicant and Authenticator lose synchronization with respect to the PMKSA, the 4-way handshake
fails. In such circumstances, dot11RSNA4WayHandshakeFailures shall be incremented.
A Supplicant may initiate preauthentication with any AP within its present ESS with preauthentication
enabled regardless of whether the targeted AP is within radio range.
Even if a STA has preauthenticated, it is still possible that it may have to undergo a full IEEE 802.1X
authentication, as the AP’s Authenticator may have purged its PMKSA due to, for example, unavailability
of resources, delay in the STA associating, etc.
12.6.10.3 Cached PMKSAs and RSNA key management
In a non-FT environment, a STA might cache PMKSAs it establishes as a result of previous authentication.
The PMKSA shall not be changed while cached. The PMKSA in the PMKSA is used with the 4-way
handshake to establish fresh PTKs.
If a STA in an infrastructure BSS has determined it has a valid PMKSA with an AP to which it is about to
(re)associate, it performs Open System authentication to the AP, and then it includes the PMKID for the
PMKSA in the RSNE in the (Re)Association Request. When the PMKSA was not created using pre-
authentication, the AKM indicated in the RSNE by the STA in the (Re)Association Request shall be
identical to the AKM used to establish the cached PMKSA in the first place.
Upon receipt of a (Re)Association Request frame with one or more PMKIDs, an AP checks whether its
Authenticator has cached a PMKSA for the PMKIDs and whether the AKM in the cached PMKSA matches
the AKM in the (Re)Association Request; and if so, it shall assert possession of that PMKSA by beginning
the 4-way handshake after association has completed. If the Authenticator does not have a PMKSA for the
PMKIDs in the (Re)Association Request, its behavior depends on how the PMKSA was established. If SAE
authentication was used to establish the PMKSA, then the AP shall reject (re)association by sending a
(Re)Association Response frame with status code STATUS_INVALID_PMKID. Note that this allows the
non-AP STA to fall back to full SAE authentication to establish another PMKSA. If IEEE 802.1X
authentication was used to establish the PMKSA, the AP begins a full IEEE 802.1X authentication after
association has completed.
If both sides assert possession of a cached PMKSA, but the 4-way handshake fails, both sides may delete the
cached PMKSA for the selected PMKID.
If the lifetime of a cached PMKSA expires, the STA shall delete the expired PMKSA.
If a STA roams to an AP with which it is preauthenticating and the STA does not have a PMKSA for that
AP, the STA needs to initiate a full IEEE 802.1X EAP authentication.
1997
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.6.11 RSNA authentication in an IBSS
When authentication is used in an IBSS, it is driven by each STA wishing to establish communications. The
management entity of this STA chooses a set of STAs with which it might need to authenticate and then may
cause the MAC to send an IEEE 802.11 Open System authentication message to each targeted STA.
Candidate STAs can be identified from Beacon frames, Probe Response frames, and Data frames from the
same BSSID. Before communicating with STAs identified from Data frames, the security policy of the
STAs may be obtained, e.g., by sending a Probe Request frame to the STA and obtaining a Probe Response
frame. Targeted STAs that wish to respond may return an IEEE 802.11 Open System authentication
message to the initiating STA.
When IEEE 802.1X authentication is used, the STA management entity requests its local IEEE 802.1X
entity to create a Supplicant PAE for the peer STA. The Supplicant PAE initiates the authentication to the
peer STA by sending an EAPOL-Start frame to the peer. The STA management entity also requests its local
IEEE 802.1X entity to create an Authenticator PAE for the peer STA on receipt of the EAPOL-Start frame.
The Authenticator initiates authentication to the peer STA by sending an EAP-Request message or, if PSK
mode is in effect, message 1 of the 4-way handshake.
Upon initial authentication between any pair of STAs, Data frames, other than IEEE 802.1X messages, are
not allowed to flow between the pair of STAs until both STAs in each pair of STAs have successfully
completed AKM and have provided the supplied encryption keys.
Upon the initiation of an IEEE 802.1X reauthentication by any STA of a pair of STAs, Data frames continue
to flow between the STAs while authentication completes. Upon a timeout or failure in the authentication
process, the Authenticator of the STA initiating the reauthentication shall cause a Deauthentication message
to be sent to the Supplicant of the STA targeted for reauthentication. The Deauthentication message causes
both STAs in the pair of STAs to follow the deauthentication procedure defined in 11.3.4.4 and 11.3.4.5.
The IEEE 802.1X reauthentication timers in each STA are independent. If the reauthentication timer of the
STA with the higher MAC address (see 12.7.1 for MAC comparison) triggers the reauthentication via its
Authenticator, its Supplicant shall send an EAPOL-Start frame to the authenticator of the STA with the
lower MAC address (see 12.7.1 for MAC comparison) to trigger reauthentication on the other STA. This
process keeps the pair of STAs in a consistent state with respect to derivation of one or more fresh temporal
keys upon an IEEE 802.1X reauthentication.
When it receives an MLME-AUTHENTICATE.indication primitive due to an Open System authentication
request, the IEEE 802.11 management entity on a targeted STA shall, if it intends to set up a security
association with the peer STA, request its Authenticator to begin IEEE 802.1X authentication, i.e., to send
an EAP-Request/Identity message or message 1 of the 4-way handshake to the Supplicant.
The EAPOL-Key frame is used to exchange information between the Supplicant and the Authenticator to
negotiate a fresh PTK. The 4-way handshake produces a single PTK from the PMK. The 4-way handshake
and group key handshake use the PTK to protect the GTK as it is transferred to the receiving STA.
Password or PSK authentication may also be used in an IBSS. When a single password or PSK is shared
among the IBSS STAs, an SAE capable STA wishing to establish communication with a STA that
advertises support for SAE in Beacon and Probe Response frames invokes SAE authentication, and upon
successful conclusion of SAE, sends 4-way handshake message 1 to the target STA. If the STA does not
support SAE authentication or the target STA does not advertise support for SAE in Beacon and Probe
Response frames, the STA may use the PSK as a PMK and initiate the 4-way handshake by sending a 4-way
handshake message 1 to the target STA. In either case, the targeted STA responds to message 1 with
message 2 of the 4-way handshake and begins its 4-way handshake by sending message 1 to the initiating
STA. The two 4-way handshakes establish PTKSAs and GTKSAs to be used between the initiating STA and
1998
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the targeted STA. PSK PMKIDs have security vulnerabilities when used with low-entropy keys and should
be used only after taking this into account.
The model for security in an IBSS is not general. In particular, it assumes the following:
a) The sets of use cases for which the authentication procedures described in this subclause are valid
are as follows:
1) Password or PSK-based authentication using SAE to perform mutual authentication and
generation of a shared PMK.
2) An alternate form of PSK-based authentication, typically managed by the pass-phrase hash
method as described in J.4. This method has security vulnerabilities and should only be used
when SAE authentication is not possible.
3) EAP-based authentication, using credentials that have been issued and preinstalled on the STAs
within a common administrative domain, such as a single organization
b) All of the STAs are in direct radio communication. In particular, there is no routing, bridging, or
forwarding of traffic by a third STA to effect communication. This assumption is made, because the
model makes no provision to protect IBSS topology information from tampering by one of the
members.
12.6.12 RSNA authentication in an MBSS
When establishing an RSNA in an MBSS, a mesh STA shall use IEEE 802.11 SAE authentication (see
12.4), or optionally IEEE 802.1X authentication, prior to establishment of an authenticated peering. An
RSNA security association, called a mesh PMKSA, is created upon successful completion of authentication.
The mesh PMKSA is used with the AMPE to create a mesh TKSA.
A mesh PMKSA may be cached and used with the AMPE to establish a fresh mesh TKSA. A STA includes
the PMKID for the PMKSA in the Mesh Peering Open frame. If the PMKID in a received Mesh Peering
Open frame is unknown, the AMPE handshake fails. If both sides assert possession of a cached mesh
PMKSA but the AMPE handshake fails, a STA may delete the cached mesh PMKSA for the selected
PMKID. A mesh PMKSA shall not be changed while cached.
Authentication using IEEE 802.11 SAE authentication is based on a password. A password is required to be
shared between two mesh STAs in order to successfully complete authentication. This password can be
pairwise – each pair of mesh STAs in an MBSS has a unique password – or it can be shared-all mesh STAs
in the MBSS share the same password.
Due to the security properties of IEEE 802.11 SAE authentication, an adversary has no greater possibility in
determining a shared password than in determining a pairwise password. The potential for misuse, though, is
greater if a shared password becomes known to an adversary because an unlimited number of mesh STAs
under the control of the adversary can be added to the MBSS.
12.6.13 RSNA authentication in a PBSS
IEEE 802.11 Open System authentication is not used in a PBSS.
When establishing an RSNA with a PCP, a STA may associate to the PCP and initiate RSNA authentication
with the PCP following the procedures of 12.6.10, with the PCP taking the role of the AP. When a STA
chooses not to associate to a peer, it initiates RSNA authentication with the peer following the procedures of
12.6.11 with the following caveat: if both peers simultaneously initiate RSNA authentication, the peer with
the lower MAC address shall abandon the authentication it initiated in favor of the authentication initiated
by the peer with the higher MAC address.
1999
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.6.14 RSNA key management in an infrastructure BSS
When the IEEE 802.1X authentication completes successfully, this standard assumes that the STA’s
IEEE 802.1X Supplicant and the IEEE 802.1X AS share a secret, called a PMK. In a non-FT environment,
the AS transfers the PMK, within the MSK, to the AP, using a technique that is outside the scope of this
standard; the derivation of the PMK from the MSK is EAP-method-specific. With the PMK in place, the AP
initiates a key confirmation handshake with the STA. The key confirmation handshake sets the IEEE 802.1X
state variable portValid (as described in IEEE Std 802.1X-2010) to true.
When SAE authentication completes, both STAs share a PMK. With this PMK in place, the AP initiates the
key confirmation handshake with the STA.
The key confirmation handshake is implemented by the 4-way handshake. The purposes of the 4-way
handshake are as follows:
a) Confirm the existence of the PMK at the peer.
b) Ensure that the security association keys are fresh.
c) Synchronize the installation of one or more temporal keys into the MAC.
d) Transfer the GTK from the Authenticator to the Supplicant.
e) Confirm the selection of cipher suites.
NOTE 1—It is possible to forge message 1 of the 4-way handshake. However, the forgery attempt is detected in the
failure of the 4-way handshake.
NOTE 2—Neither the AP nor the STA can use the PMK for any purpose but the one specified herein without
compromising the key. If the AP uses it for another purpose, then the STA can masquerade as the AP; similarly if the
STA reuses the PMK in another context, then the AP can masquerade as the STA.
The Supplicant and Authenticator signal the completion of key management by utilizing the MLME-
SETKEYS.request primitive to configure the agreed-upon temporal pairwise key into the IEEE 802.11
MAC and by calling the MLME-SETPROTECTION.request primitive to enable its use.
A second key exchange, the group key handshake, is also defined. It distributes a subsequent GTK. The
AP’s Authenticator can use the group key handshake to update the GTK at the Supplicant. The group key
handshake uses the EAPOL-Key frames for this exchange. When it completes, the Supplicant can use the
MLME-SETKEYS.request primitive to configure the GTK into the IEEE 802.11 MAC.
12.6.15 RSNA key management in an IBSS
To establish a security association between two IBSS STAs, each STA’s SME has an accompanying
IEEE 802.1X Authenticator and Supplicant. Each SME initiates the 4-way handshake from the
Authenticator to the peer STA’s Supplicant (see 12.6.11). Two separate 4-way handshakes are conducted.
The 4-way handshake is used to negotiate the pairwise cipher suites, as described in 12.6.5. The
IEEE 802.11 SME configures the temporal key portion of the PTK into the IEEE 802.11 MAC. Each
Authenticator uses the KCK and KEK portions of the PTK negotiated by the exchange it initiates to
distribute its own GTK and if management frame protection is enabled, its own IGTK. Each Authenticator
generates its own GTK and if management frame protection is enabled, its own IGTK, and uses either the 4-
way handshake or the group key handshake to transfer the GTK and if management frame protection is
negotiated, the IGTK, to other STAs with whom it has completed a 4-way handshake. The pairwise key used
between any two STAs shall be the pairwise key from the 4-way handshake initiated by the STA with the
highest MAC address.
A STA joining an IBSS is required to adopt the security configuration of the IBSS, which includes the group
cipher suite, pairwise cipher suite, AKMP, and if management frame protection is enabled, group
2000
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
management cipher suite (see 12.6.5). The STA shall not set up a security association with any STA having
a different security configuration. The Beacon and Probe Response frames of the various STAs within an
IBSS need to reflect a consistent security policy, as the beacon initiation rotates among the STAs.
A STA joining an IBSS shall support and advertise in the Beacon frame the security configuration of the
IBSS, which includes the group cipher suite, advertised pairwise cipher suite, AKMP, and if management
frame protection is enabled, group management cipher suite (see 12.6.5). The STA may use the Probe
Request frame to discover the security policy of a STA, including additional individual cipher suites the
STA supports. If enabled, management frame protection shall only be used as a required feature (MFPR) in
an IBSS.
NOTE—Because of the requirement for a STA joining an IBSS to support the security configuration of the IBSS, all
Beacon frames transmitted in an IBSS have the same security policy.
12.6.16 RSNA key management in an MBSS
Upon successful completion of the AMPE, a secure mesh peering is established between two mesh STAs.
This secure mesh peering includes a mesh PMKSA and a mesh TKSA. Multiple mesh TKSAs may be
created using a single mesh PMKSA (a limit to that number is a policy decision outside the scope of this
standard).
A mesh TKSA is logically a child of the mesh PMKSA. A mesh TKSA shall be deleted if the corresponding
mesh PMKSA, which was used by the AMPE to create it, is deleted. Mesh PMKSAs are limited by their
lifetime (see 12.7.1.3).
12.6.17 RSNA key management in a PBSS
Upon successful association and authentication in a PBSS, a STA performs a key confirmation handshake
with the PCP, following the procedures in 12.6.14 with the PCP taking the role of the AP. If a STA chooses
not to associate to a peer, after successful authentication, it performs a key confirmation handshake with the
peer following the procedures in 12.6.15 with the following caveat: if both peers simultaneously initiate the
key confirmation handshake, the peer with the lower MAC address shall abandon the handshake it initiated
in favor of the handshake initiated by the peer with the higher MAC address.
12.6.18 RSNA security association termination
When a non-AP STA’s SME receives a successful MLME-ASSOCIATE.confirm or MLME-
REASSOCIATE.confirm primitive that is not part of a fast BSS transition or receives or invokes an MLME
Disassociation or Deauthentication primitive, it deletes some security associations. Similarly, when an AP’s
SME
— receives an MLME-ASSOCIATE.indication or MLME-REASSOCIATE.indication primitive from
a STA that has not negotiated management frame protection, or
— receives an MLME-ASSOCIATE.indication or MLME-REASSOCIATE.indication primitive from
a STA that has negotiated management frame protection that a) has resulted in an MLME
(re)association response that is successful, and b) is not part of a fast BSS transition, or receives an
MLME-DEAUTHENTICATE.indication or MLME-DISASSOCIATE.indication primitive or
issues an MLME-DEAUTHENTICATE.request or MLME-DISASSOCIATE.request primitive,
it deletes some security associations. In the case of an ESS, the non-AP STA’s SME shall delete the PTKSA,
GTKSA, IGTKSA, SMKSA, any TPKSA, and any STKSA, and the AP’s SME shall delete the PTKSA and
invoke an STSL application teardown procedure for any of its STKSAs. An example of an STSL application
teardown procedure is described in 11.7.4. In the case of an IBSS, the SME shall delete the PTKSA and the
receive GTKSA and IGTKSA. Once the security associations have been deleted, the SME then invokes
2001
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MLME-DELETEKEYS.request primitive to delete all temporal keys associated with the deleted security
associations.
If a STA loses key state synchronization, it can apply the following rules to recover:
a) Any protected frame(s) received shall be discarded, and MLME-
PROTECTEDFRAMEDROPPED.indication primitive is invoked.
b) If the STA is RSNA-enabled and has joined an IBSS, the SME shall execute the authentication
procedure as described in 11.3.4.2.
c) If the STA is RSNA-enabled and has joined an ESS, the SME shall execute the deauthentication
procedures as described in 11.3.4.4. However, if the STA has initiated the RSN security association,
but has not yet invoked the MLME-SETPROTECTION.request primitive, then no additional action
is required.
NOTE 1—There is a race condition between when MLME-SETPROTECTION.request primitive is invoked on the
Supplicant and when it is invoked on the Authenticator. During this time, the STA might receive an MPDU that it is
unable to decrypt; and the MPDU is discarded without a deauthentication occurring.
NOTE 2—Because the IEEE 802.11 Null frame does not derive from an MA-UNITDATA.request primitive, it is not
protected.
If the selected AKMP fails between a STA and an AP that are associated, then both the STA and the AP
shall invoke the MAC deauthentication procedure described in 11.3.4.4.
If the SMK handshake fails between a pair of associated STAs and AP, then the STAs and the AP shall
invoke an STSL application teardown procedure.
When a STA’s SME receives an MLME-PN-EXHAUSTION.indication primitive and the PN is associated
with a PTKSA, the STA’s SME shall invoke an MLME-DISASSOCIATE.request primitive and delete the
PTKSA.
When a STA’s SME receives an MLME-PN-EXHAUSTION.indication primitive and the PN is associated
with a GTKSA, the STA’s SME shall delete the GTKSA.
When a STA’s SME receives an MLME-PN-EXHAUSTION.indication primitive and the PN is associated
with a STKSA, the STA’s SME shall invoke a STSL application teardown procedure for the STKSA and
delete the STKSA.
Once the security associations have been deleted, the SME then invokes MLME-DELETEKEYS.request
primitive to delete all temporal keys associated with the deleted security associations.
12.6.19 Protection of robust Management frames
This subclause defines rules that shall be followed by STAs that implement Management Frame protection
and have dot11RSNAActivated equal to true.
A STA with dot11RSNAProtectedManagementFramesActivated equal to false shall transmit and receive
unprotected individually addressed robust Management frames to and from any associated STA and shall
discard protected individually addressed robust Management frames received from any associated STA.
A STA with dot11RSNAProtectedManagementFramesActivated equal to true and
dot11RSNAUnprotectedManagementFramesAllowed equal to true shall transmit and receive unprotected
individually addressed robust Management frames to and from any associated STA that advertised MFPC =
0 and shall discard protected individually addressed robust Management frames received from any
associated STA that advertised MFPC = 0.
2002
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA with dot11RSNAProtectedManagementFramesActivated equal to true and
dot11RSNAUnprotectedManagementFramesAllowed equal to true shall transmit and receive protected
individually addressed robust Management frames to and from any associated STA that advertised MFPC =
1, shall discard unprotected individually addressed robust Action frames received from any STA that
advertised MFPC = 1, and shall discard unprotected individually addressed Disassociation and
Deauthentication frames received from a STA that advertised MFPC = 1 after the PTK and IGTK have been
installed. The receiver shall process unprotected individually addressed Disassociation and Deauthentication
frames before the PTK and IGTK are installed.
A STA with dot11RSNAProtectedManagementFramesActivated equal to true and
dot11RSNAUnprotectedManagementFramesAllowed equal to false shall transmit and receive protected
individually addressed robust Action frames to and from any STA, shall not transmit unprotected
individually addressed robust Action frames to any STA, and shall discard unprotected individually
addressed robust Action frames received from a STA after the PTK and IGTK have been installed. The
receiver shall process unprotected individually addressed Disassociation and Deauthentication frames
before the PTK and IGTK are installed.
A STA with dot11RSNAProtectedManagementFramesActivated equal to true shall protect transmitted
group addressed robust Management frames using the group management cipher suite.
A STA with dot11RSNAProtectedManagementFramesActivated equal to true shall discard group addressed
robust Management frames received from any associated STA that advertised MFPC = 1 if the frames are
unprotected or if a matching IGTK is not available.
A STA with dot11RSNAProtectedManagementFramesActivated equal to true and
dot11RSNAUnprotectedManagementFramesAllowed equal to false shall discard received group addressed
robust Management frames that are unprotected or for which a matching IGTK is not available.
A STA with dot11RSNAProtectedManagementFramesActivated equal to false shall transmit group
addressed robust Management frames unprotected and shall ignore the protection on received group
addressed robust Management frames.
NOTE—BIP does not provide protection against forgery by associated and authenticated STAs. A STA that has left the
group can successfully forge Management frames until the IGTK is updated.
Protection of group addressed robust Management frames shall be provided by a service in the MLME as
described in 11.13.
Robust management frame protection cannot be applied until the PTK and IGTK has been established with
the STA. A STA shall not transmit robust Action frames until it has installed the PTK for the peer STA, or in
the case of group addressed frames, has installed the IGTK. The STA shall discard any robust Action frames
received before the PTK and IGTK are installed.
12.6.20 Robust management frame selection procedure
A STA with dot11RSNAProtectedManagementFramesActivated equal to true shall negotiate robust
management frame protection with a STA that advertised MFPC = 1.
When a Public Action frame is transmitted for which a Protected Dual of Public Action frame is defined,
(see 9.6.11), which variant (i.e., protected or not protected) is used depends on the setting of the “Protected”
parameter of the corresponding MLME .request or .confirm primitive. Where there is no such parameter, the
protected variant is used when management frame protection has been negotiated.
2003
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.6.21 RSNA rekeying
When a PTKSA is deleted, a non-AP and non-PCP STA may reassociate with the same AP or PCP and/or
establish a new RSNA with the AP or PCP. If the non-AP and non-PCP STA has cached one or more
PMKSAs, it may skip the PMKSA establishment and proceed with the creation of a new PTKSA by using 4-
way handshake.
When a GTKSA is deleted, an originating STA may create a new GTKSA by using 4-way handshake or
group key handshake.
When a STKSA is deleted, the STA_I may establish a new STSL with the STA_P. If the SMK between the
STA pair has not expired, the STA_I may initiate a 4-way handshake and create a new STKSA with STA_P.
If the SMK has expired, the STA_I shall create both a new SMKSA and a new STKSA with the STA_P.
An Authenticator/STA_I may initiate a 4-way handshake for the purpose of renewing the key associated
with a PTKSA or STKSA. A supplicant/STA_P may send an EAPOL request message to the authenticator/
STA_I to request rekeying. In addition, if both the Authenticator and the Supplicant support multiple keys
for individually addressed traffic, a smooth switchover to the new key is possible using the following
procedure.
The IEEE 802.11 MAC shall issue an MLME-PN-WARNING.indication primitive when the Packet
Number assignment for a particular PTKSA, GTKSA, or STKSA reaches or exceeds the threshold that is
defined in dot11PNWarningThresholdLow and dot11PNWarningThresholdHigh for the first time. The
indication shall be issued only once for a given PTKSA, GTKSA, or STKSA. The SME may use the
indication as a trigger to establish a new PTKSA, GTKSA, or STKSA before the Packet Number space is
exhausted.
A PTKSA or STKSA has a limited lifetime, either in absolute time or due to exhausting the PN space. To
maintain an uninterrupted security association, a STA should establish a new PTKSA or STKSA prior to the
expiration of the old PTKSA or STKSA.
When both ends of the link support extended Key IDs for individually addressed frames, it is possible to
install the new PTKSA or STKSA without data loss, provided the new PTKSA or STKSA uses a different
Key ID from the old PTKSA or STKSA. Data loss might occur if the same Key ID is used because it is not
possible to precisely coordinate (due to software processing delays) when the new key is used for transmit at
one end and when it is applied to receive at the other end. If a different Key ID is used for the new PTKSA
or STKSA, then provided the new key is installed at the receive side prior to its first use at the transmit side
there is no need for precise coordination. During the transition, received packets are unambiguously
identified using the Key ID as belonging to either the old or new PTKSA or STKSA.
12.6.22 Multi-band RSNA
12.6.22.1 General
A STA is multi-band capable and RSNA-capable if the values of both dot11MultibandImplemented and
dot11RSNAActivated are true.
A STA that is multi-band capable and RSNA-capable shall set the Pairwise Cipher Suite Present field of the
Multi-band element to 1 and shall include the Pairwise Cipher Suite Count field and the Pairwise Cipher
Suite List field in the Multi-band element. The STA may include the RSNE and the Multi-band element in
the DMG Beacon and Announce frames and shall include the RSNE and the Multi-band element in Beacon,
Probe Response, and Information Response frames. The included RSNE shall specify all of the
authentication and cipher suites enabled by the STA’s policy for the band where this element is transmitted,
and the included Multi-band element shall specify all of the pairwise cipher suites enabled by the STA’s
2004
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
policy for the band specified within the Multi-band element. A STA shall not advertise any cipher suite that
is not enabled.
A multi-band capable and RSNA-capable STA shall include the Multi-band element in the (Re)Association
Request frame and in message 2 and message 3 of the 4-way handshake.
In order to set up an RSNA with a peer STA for a supported band/channel, a STA that does not know the
peer’s policy for the band/channel shall first obtain the peer STA’s policy for the supported band/channel by
using a Probe Request frame or Information Request frame. The STA initiating RSNA establishment for a
supported band/channel is called RSNA initiator, and the targeted STA of the RSNA establishment is called
RSNA responder.
A multi-band capable device can create its own group key(s) for one or more supported bands/channels. If
the STA uses different MAC addresses in different bands/channels, different GTKSAs shall be created for
different bands. If the STA uses a same MAC address in all supported bands/channels, a single GTKSA
shall be created for all supported bands/channels.
If the pairwise and group cipher suites used by a pair of multi-band capable devices to communicate with
each other in the current operating band/channel is also supported after the transfer to another band/channel
that was performed using transparent FST, the devices shall continue using the same cipher suites to
communicate with each other after the transfer. In all other cases, a separate RSNA has to be established for
the other band/channel (see 12.6.22).
12.6.22.2 Nontransparent multi-band RSNA
An RSNA initiator can establish a nontransparent (11.33) multi-band RSNA with an RSNA responder for a
supported band/channel other than the current operating band/channel. The two STAs use the same PMKSA
for both the supported band/channel and the current operating band/channel and create different PTKSAs for
different bands/channels.
If the RSNA initiator does not have an existing PMKSA with the RSNA responder, the RSNA initiator shall
first establish a PMKSA with the RSNA responder in the current operating band/channel and then use the
PMKSA to create a PTKSA with the RSNA responder for the supported band/channel. If the RSNA initiator
has already established a PMKSA with the RSNA responder, the PMKSA shall be used to create a PTKSA
between the two STAs for the supported band/channel.
With the PMK in place, the RSNA initiator and RSNA responder can proceed in two ways depending on the
setting of the Joint Multi-band RSNA subfield within the RSN Capabilities field in the RSNE of both STAs.
If the Joint Multi-band RSNA subfield within the RSN Capabilities field of either the RSNA initiator or
RSNA responder is 0, the STA pair uses a 4-way handshake to establish a PTKSA for the current band/
channel and may start a separate 4-way handshake in the current operating band/channel to negotiate a
pairwise cipher suite for the supported band/channel and establish a PTKSA for the supported band/channel.
As specified in 12.7.6, message 2 and message 3 of the 4-way handshake convey the Multi-band element
associated with the supported band/channel. The Multi-band element in message 2 includes the selected
pairwise cipher suite for the supported band/channel. message 3 includes the Multi-band element that the
STA would send in a Beacon, DMG Beacon, Announce, Probe Response, or Information Response frame.
message 3 may include a second Multi-band element that indicates the STA’s pairwise cipher suite
assignment for the supported band/channel.
If the Joint Multi-band RSNA subfield within the RSN Capabilities field is 1 for both the RSNA initiator and
the RSNA responder and at least one of the STAs uses different MAC addresses for different bands/
channels, the STAs shall use a single 4-way handshake to negotiate pairwise cipher suites and establish
PTKSAs for both the current operating band/channel and the other supported band(s)/channel(s). As
2005
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
specified in 12.7.6, message 2 and message 3 of the 4-way handshake convey the RSNE and the Multi-band
element(s). The RSNE in message 2 includes the selected pairwise cipher suite for the current operating
band/channel, and the Multi-band element(s) in message 2 includes the selected pairwise cipher suite(s) for
the other supported band(s)/channel(s). message 3 includes the RSNE and the Multi-band element(s) that the
STA would send in a Beacon, DMG Beacon, Announce, Probe Response, or Information Response frame.
message 3 may include a second RSNE and Multi-band element(s) that indicate the STA’s pairwise cipher
suite assignments for the current operating band/channel and the other supported band(s)/channel(s). KCK
and KEK associated with the current operating band/channel shall be used in the 4-way handshake.
12.6.22.3 Transparent multi-band RSNA
An RSNA initiator can establish a transparent (11.33) multi-band RSNA with an RSNA responder for both
the current operating band/channel and the other supported band(s)/channel(s) if
a) Both STAs use the same MAC address in the current operating band/channel and the other
supported band(s)/channel(s); and
b) At least one common pairwise cipher suite is supported by both STAs in the current operating band/
channel and the other supported band(s)/channel(s).
Two STAs that establish a transparent multi-band RSNA create one PMKSA and one PTKSA for both the
current operating band/channel and other supported band(s)/channel.
A STA shall use a single PN counter (12.5.3.3 and 12.5.5.3) for transmission in both the current operating
band and the other supported band(s) when transparent multi-band RSNA is used.
If the RSNA initiator does not have an existing PMKSA with the RSNA responder, the RSNA initiator shall
first establish a PMKSA with the RSNA responder in the current operating band/channel and then use the
PMKSA to create a PTKSA with the RSNA responder for all involved bands/channels. If the RSNA initiator
has already established a PMKSA with the RSNA responder, the PMKSA shall be used to create a PTKSA
between the two STAs for all involved bands/channels.
With the PMK in place, the STA pair shall use a single 4-way handshake in the current operating band/
channel to negotiate a pairwise cipher suite for all involved bands/channels and also establish a single
PTKSA for all involved bands/channels. As specified in 12.7.6, message 2 and message 3 of the 4-way
handshake convey the RSNE and the Multi-band element(s). The RSNE and the Multi-band element(s) in
message 2 include one selected pairwise cipher suite for all involved bands/channels. message 3 includes the
RSNE and the Multi-band element(s) that the STA would send in a Beacon, DMG Beacon, Announce,
Probe Response, or Information Response frame. message 3 may include a second RSNE and Multi-band
element(s) that indicate the STA’s pairwise cipher suite assignment for all involved bands/channels.
12.6.22.4 Multi-band RSNA with TDLS in a non-DMG BSS
When two multi-band capable devices operate in a non-DMG BSS and set up a TDLS direct link in the BSS,
the TPK handshake protocol can be used to create a PTKSA for use in another supported band/channel that
is supported by both STAs and that was indicated in the Multi-band element in each of the STAs. Only TK
in PTKSA is required for the supported band/channel and it shall be equal to the TPK-TK of the TPK.
If at least one of the peer STAs has a different MAC address in the supported band/channel from that of the
current operating band/channel, the TPK handshake protocol may be used to establish a PTKSA for the
supported band/channel. In this case, the TPK creation method shall be used to calculate a different PTKSA
in the supported band/channel: the TDLS peer MAC addresses and cipher suite shall be replaced by the
MAC addresses and cipher suite indicated within the corresponding Multi-band elements contained in the
TDLS Setup Request and TDLS Setup Response frames used to establish the PTKSA for the supported
band/channel.
2006
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If two TDLS peer STAs use the same MAC addresses and pairwise cipher suites in the operating band/
channel and in the supported band/channel, the TPKSA that is acquired by the successful completion of the
TPK handshake protocol may be used as the PTKSA for the supported band/channel.
12.7 Keys and key distribution
12.7.1 Key hierarchy
12.7.1.1 General
RSNA defines the following key hierarchies:
a) Pairwise key hierarchy, to protect individually addressed traffic
b) GTK, a hierarchy consisting of a single key to protect group addressed traffic
NOTE—Pairwise key support with enhanced data cryptographic encapsulation mechanisms allows a receiving STA to
detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the
pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver
generates an error. GTKs do not have this property.
c) Integrity GTK (IGTK), a hierarchy consisting of a single key to provide integrity protection for
group addressed robust Management frames
The description of the key hierarchies uses the pseudorandom function producing n bits of output, PRF-n,
defined in 12.7.1.2.
In an infrastructure BSS, the IEEE 802.1X Authenticator MAC address (AA) and the AP’s MAC address are
the same, and the Supplicant’s MAC address (SPA) and the STA’s MAC address are equal. For the purposes
of comparison, the MAC address is encoded as 6 octets, taken to represent an unsigned integer. The first
octet of the MAC address shall be used as the most significant octet. The bit numbering conventions in 9.2.2
shall be used within each octet. This results in a 48-bit unsigned integer labeled B0 (least significant) to B47
(most significant), where the I/G bit is in B40.
An RSNA STA shall support at least one pairwise key for any pair for use with enhanced data
cryptographic encapsulation mechanisms. The identifies the pairwise key, which does not
correspond to any WEP key identifier.
In a a mixed environment, an AP may simultaneously communicate with some STAs using WEP with
shared WEP keys and to STAs using enhanced data cryptographic encapsulation mechanisms with pairwise
keys. The STAs running WEP use default keys 0–3 for shared WEP keys; the important point here is that
WEP can still use WEP default key 0. The AP might be configured to use the WEP key in WEP default key
0 for WEP; if the AP is configured in this way, STAs that cannot support WEP default key 0 simultaneously
with a TKIP pairwise key shall specify the No Pairwise subfield in the RSN Capabilities field. If an AP is
configured to use WEP default key 0 as a WEP key and a “No Pairwise” STA associates, the AP shall not set
the Install bit in the 4-way handshake. In other words, the STA does not install a pairwise temporal key and
instead uses WEP default key 0 for all traffic.
NOTE—The behavior of “No Pairwise” STAs is intended only to support the migration of WEP to RSNA.
TKIP STAs in a mixed environment are expected to support a single pairwise key either by using a key
mapping key or by mapping to default key 0. The AP uses a pairwise key for individually addressed traffic
between the AP and the STA. If a key mapping key is available, the pair identifies the key; if
there is no key mapping key, then the default key 0 is used because the key index in the message is 0.
2007
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA that cannot support TKIP keys and WEP default key 0 simultaneously advertises this deficiency by
setting the No Pairwise subfield in the RSNE it sends in the (Re)Association Request frame to the AP. In
response, the AP sets the Install bit to 0 in message 3 of the 4-way handshake to notify the STA not to install
the pairwise key. The AP instead sends the WEP shared key to the STA to be plumbed as the WEP default
key 0; this key is then used with WEP to send and receive individually addressed traffic between the AP and
the STA.
The TKIP STA that has this limitation might not know that it will be forced to use WEP for all transmissions
until it has associated with the AP and been given the keys to use. (The STA cannot know that the AP has
been configured to use WEP default key 0 for WEP communication.) If this does not satisfy the security
policy configured at the STA, the STA’s only recourse is to disassociate and try a different AP.
STAs using enhanced data cryptographic encapsulation mechanisms in a TSN shall support pairwise keys
and WEP default key 0 simultaneously. It is invalid for the STA to negotiate the No Pairwise subfield when
an enhanced data cryptographic encapsulation mechanism other than TKIP is one of the configured ciphers.
12.7.1.2 PRF
A PRF is used in a number of places in this standard. Depending on its use, it may need to output 128, 192,
256, 384, 512, or 704 bits. This subclause defines six functions:
— PRF-128, which outputs 128 bits
— PRF-192, which outputs 192 bits
— PRF-256, which outputs 256 bits
— PRF-384, which outputs 384 bits
— PRF-512, which outputs 512 bits
— PRF-704, which outputs 704 bits
In the following, K is a key; A is a unique label for each different purpose of the PRF, treated as an ASCII
string; B is a variable-length string; Y is a single octet containing 0; X is a single octet containing the loop
parameter i:
H-SHA-1(K, A, B, X) HMAC-SHA-1(K, A || Y || B || X)
PRF(K, A, B, Len)
for i 0 to Len
--------- do
160
R R || H-SHA-1(K, A, B, i)
return L(R, 0, Len)
PRF-128(K, A, B) = PRF(K, A, B, 128)
PRF-192(K, A, B) = PRF(K, A, B, 192)
PRF-256(K, A, B) = PRF(K, A, B, 256)
PRF-384(K, A, B) = PRF(K, A, B, 384)
PRF-512(K, A, B) = PRF(K, A, B, 512)
When the negotiated AKM is 00-0F-AC:5, 00-0F-AC:6, or 00-0F-AC:11, the KDF specified in 12.7.1.7.2
shall be used instead of the PRF construction defined here. In this case, A is used as the KDF label and B as
the KDF Context, and the PRF functions are defined as follows:
PRF-128(K, A, B) = KDF-SHA-256-128(K, A, B)
PRF-192(K, A, B) = KDF-SHA-256-192(K, A, B)
2008
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PRF-256(K, A, B) = KDF-SHA-256-256(K, A, B)
PRF-384(K, A, B) = KDF-SHA-256-384(K, A, B)
PRF-512(K, A, B) = KDF-SHA-256-512(K, A, B)
When the negotiated AKM is 00-0F-AC:12, the KDF specified in 12.7.1.7.2 shall be used instead of the PRF
construction defined here. In this case, A is used as the KDF label and B as the KDF Context, and the PRF
function is defined as follows:
PRF-704(K, A, B) = KDF-SHA-384-704(K, A, B)
When the negotiated AKM is 00-0F-AC:13, the KDF specified in 12.7.1.7.2 shall be used instead of the PRF
construction defined here. In this case, A is used as the KDF label and B as the KDF Context, and the PRF
functions are defined as follows:
PRF-384(K, A, B) = KDF-SHA-384-384(K, A, B)
PRF-512(K, A, B) = KDF-SHA-384-512(K, A, B)
PRF-704(K, A, B) = KDF-SHA-384-704(K, A, B)
12.7.1.3 Pairwise key hierarchy
Except when preauthentication is used, the pairwise key hierarchy utilizes PRF-384, PRF-512, or PRF-704
to derive session-specific keys from a PMK, as depicted in Figure 12-28. When using AKM suite selector
00-0F-AC:12, the length of the PMK, PMK_bits, shall be 384 bits. With all other AKM suite selectors, the
length of the PMK, PMK_bits, shall be 256 bits. The pairwise key hierarchy takes a PMK and generates a
PTK. The PTK is partitioned into KCK, KEK, and a temporal key, which is used by the MAC to protect
individually addressed communication between the Authenticator’s and Supplicant’s respective STAs.
PTKs are used between a single Supplicant and a single Authenticator.
Pairwise Master
Master
KeyKey
(PMK)
(PMK)
PRF-Length(PMK, “Pairwise key expansion” ,
Min(AA,S P A) || Max(AA,SP
Max(AA,SPA) ||
Min(ANonce ,SNonce ) ||
Max(ANonce ,SNonce))
Pairwise Transient
Transient
KeyKey
(PTK)
(PTK)
(Length bits)
EAPOL- Key EAPOL- Key Temporal Key
Key Key Encryption L(PTK,KCK_bits+KEK_bits,TK_bits)
Confirmation Key (TK)
Key L(PTK,KCK_bits,
L(PTK,128,128)
L(PTK,0,KCK_bits)
L(PTK,0,128) KEK_bits)
(KCK) (KEK)
(KEK)
Figure 12-28—Pairwise key hierarchy
When not using a PSK, the PMK is derived from the MSK. The PMK shall be computed as the first
PMK_bits bits (bits 0 to PMK_bits–1) of the MSK: PMK L(MSK, 0, PMK_bits).
2009
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PTK shall not be used longer than the PMK lifetime as determined by the minimum of the PMK lifetime
indicated by the AS, e.g., Session-Timeout + dot1xAuthTxPeriod or from dot11RSNAConfigPMK-
Lifetime. When RADIUS is used and the Session-Timeout attribute is not in the RADIUS Accept message,
and if the key lifetime is not otherwise specified, then the PMK lifetime is infinite.
NOTE 1—If the protocol between the Authenticator (or AP) and AS is RADIUS, then the MS-MPPE-Recv-Key
attribute (vendor-id = 17; see Section 2.4.3 in IETF RFC 2548 [B32]) is available to be used to transport the first
32 octets of the MSK to the AP, and the MS-MPPE-Send-Key attribute (vendor-id = 16; see Section 2.4.2 in IETF RFC
2548 [B32]) is available to be used to transport the remaining 32 octets of the MSK.
NOTE 2—When reauthenticating and changing the pairwise key, a race condition might occur when using TKIP. If a
frame is received while MLME-SETKEYS.request primitive is being processed, the received frame might be decrypted
with one key and the MIC checked with a different key. Two possible options to avoid this race condition are as follows:
the frame might be checked against the old MIC key, and the received frames might be queued while the keys are
changed.
NOTE 3—If the AKMP is RSNA-PSK, then a 256-bit PSK might be configured into the STA and AP or a pass-phrase
might be configured into the Supplicant or Authenticator. The method used to configure the PSK is outside this standard,
but one method is via user interaction. If a pass-phrase is configured, then a 256-bit key is derived and used as the PSK.
In any RSNA-PSK method, the PSK is used directly as the PMK. Implementations might support different PSKs for
each pair of communicating STAs.
Here, the following assumptions apply:
— SNonce is a random or pseudorandom value contributed by the Supplicant; its value is taken when a
PTK is instantiated and is sent to the PTK Authenticator.
— ANonce is a random or pseudorandom value contributed by the Authenticator.
— The PTK shall be derived from the PMK by
PTK = PRF-Length(PMK, “Pairwise key expansion”, Min(AA,SPA) || Max(AA,SPA) ||
Min(ANonce,SNonce) || Max(ANonce,SNonce))
where Length = KCK_bits + KEK_bits + TK_bits. The values of KCK_bits and KEK_bits are AKM
suite dependent and are listed in Table 12-8. The value of TK_bits is cipher-suite dependent and is
defined in Table 12-4. The Min and Max operations for IEEE 802 addresses are with the address
converted to a positive integer treating the first transmitted octet as the most significant octet of the
integer. The nonces are encoded as specified in 9.2.2.
NOTE—The Authenticator and Supplicant normally derive a PTK only once per association. A Supplicant or an
Authenticator use the 4-way handshake to derive a new PTK. Both the Authenticator and Supplicant create a new nonce
value for each 4-way handshake instance.
— The KCK shall be computed as the first KCK_bits bits (bits 0 to KCK_bits–1) of the PTK:
KCK= L(PTK, 0, KCK_bits)
The KCK is used by IEEE Std 802.1X-2010 to provided data origin authenticity in the 4-way
handshake and group key handshake messages.
— The KEK shall be computed as the next KEK_bits bits of the PTK:
KEK = L(PTK, KCK_bits, KEK_bits)
The KEK is used by the EAPOL-Key frames to provide data confidentiality in the 4-way handshake
and group key handshake messages.
— The temporal key (TK) shall be computed as the next TK_bits bits of the PTK:
TK = L(PTK, KCK_bits+KEK_bits, TK_bits)
The EAPOL-Key state machines (see 12.7.10 and 12.7.11) use the MLME-SETKEYS.request primitive to
configure the temporal key into the STA. The STA uses the temporal key with the pairwise cipher suite;
interpretation of this value is cipher-suite-specific.
2010
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the negotiated AKM is 00-0F-AC:5 or 00-0F-AC:6, the PMK identifier is defined as
PMKID = Truncate-128(HMAC-SHA-256(PMK, "PMK Name" || AA || SPA))
When the negotiated AKM is 00-0F-AC:11, the PMK identifier is defined as
PMKID = Truncate-128(HMAC-SHA-256(KCK, "PMK Name" || AA || SPA))
When the negotiated AKM is 00-0F-AC:12, and the PMK identifier is defined as
PMKID = Truncate-128(HMAC-SHA-384(KCK, "PMK Name" || AA || SPA))
Otherwise, the PMK identifier is defined as
PMKID = Truncate-128(HMAC-SHA-1(PMK, "PMK Name" || AA || SPA))
In all these cases, “PMK Name” is treated as an ASCII string.
When the PMKID is calculated for the PMKSA as part of preauthentication, the AKM has not yet been
negotiated. In this case, the HMAC-SHA-1 based derivation is used for the PMKID calculation.
12.7.1.4 Group key hierarchy
The group temporal key (GTK) shall be a random number. The following is an example method for deriving
a random GTK. Any other pseudorandom function, such as that specified in 12.7.1.2, could also be used.
A group master key (GMK) is an auxiliary key that may be used to derive a GTK at a time interval
configured into the AP to reduce the exposure of data if the GMK is ever compromised.
The Authenticator might update the GTK for a number of reasons:
— The Authenticator might change the GTK on disassociation or deauthentication of a STA.
— An event within the SME might trigger a group key handshake.
Figure 12-29 depicts an example of a relationship among the keys of the group key hierarchy. In this model,
the group key hierarchy takes a GMK and generates a GTK. The GTK is a temporal key, which is used
to protect group addressed communication. GTKs are used between a single Authenticator and all
Supplicants authenticated to that Authenticator. The Authenticator derives new GTKs when it needs to
update the GTKs.
In this example, the following assumptions apply:
a) Group nonce (GNonce) is a random or pseudorandom value contributed by the IEEE 802.1X
Authenticator.
b) The GTK is derived from the GMK by
c) GTK PRF-Length(GMK, “Group key expansion”, AA || GNonce)
d) Length = TK_bits. The value of TK_bits is cipher-suite dependent and is defined in Table 12-4. AA
is represented as an IEEE 802 address and GNonce as a bit string as defined in 9.2.2.
e) The temporal key (TK) is bits 0 to (TK_bits – 1) of the GTK:
TK L(GTK, 0, TK_bits)
f) The EAPOL-Key state machines (see 12.7.10 and 12.7.11) configure the temporal key into a STA
via the MLME-SETKEYS.request primitive. Its interpretation is cipher-suite-specific.
2011
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Group Master
Key (GMK)
PRF-Length (GMK ,“Group key expansion”,, AA || GNonce )
Group Temporal Key (GTK)
(Length bits )
Temporal Key
Temporal Key
L(GTK, 0, TK_bits)
CCMP:
L(GTK, 0, 128)
Figure 12-29—Group key hierarchy (informative)
12.7.1.5 Integrity group key hierarchy
The Authenticator shall select the IGTK as a random value each time it is generated.
The Authenticator may update the IGTK for any reason, including:
a) The disassociation or deauthentication of a STA.
b) An event within the SME that triggers a group key handshake.
The IGTK is configured via the MLME-SETKEYS.request primitive; see 6.3.19. IGTK configuration is
described in the EAPOL-Key state machines; see 12.7.10 and 12.7.11.
The IPN is used to provide replay protection.
12.7.1.6 PeerKey key hierarchy
The station-to-station key hierarchy utilizes PRF-384 or PRF-512 to derive session-specific keys from an
SMK, as depicted in Figure 12-30. The SMK shall be 256 bits. The pairwise key hierarchy takes an SMK
and generates an STK. The STK is partitioned into SKCK, SKEK, and a temporal key, which is used by the
MAC to protect individually addressed communication between the initiator and peer STAs. STKs are used
between a single initiator STA and a single peer STA.
2012
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STSL Master Key (SMK)
PRF-Length(SMK, “Peer key expansion”,
Min(MAC_I,MAC_P) || Max(MAC_I,MAC_P)
Min(INonce,PNonce) || Max(INonce,PNonce))
STSL Transient Key (STK)
(Length bits)
EAPOL-Key Key EAPOL-Key Key
Temporal Key
Confirmation Key Encryption Key
L(STK, 256, TK_bits)
L(STK, 0, 128) L(STK, 128, 128)
(TK)
SKCK SKEK
Figure 12-30—PeerKey hierarchy
The following apply and are depicted in Figure 12-30:
a) INonce is a random or pseudorandom value contributed by the initiator STA.
b) PNonce is a random or pseudorandom value contributed by the peer STA.
c) The STK shall be derived from the SMK by
STK PRF-Length(SMK, "Peer key expansion", Min(MAC_I,MAC_P) || Max(MAC_I,MAC_P)
|| Min(INonce,PNonce) || Max(INonce,PNonce))
where Length = 256 + TK_bits. The value of TK_bits is cipher-suite dependent and is defined in
Table 12-4. The Min and Max operations for IEEE 802 addresses are with the address converted to a
positive integer treating the first transmitted octet as the most significant octet of the integer. For the
Min and Max operations, nonces are encoded as specified in 9.2.2.
d) The SKCK shall be computed as the first 128 bits (bits 0–127) of the STK:
SKCK L(STK, 0, 128)
The SKCK is used to provide data origin authenticity in the 4-way STK handshake.
e) The SKEK shall be computed as bits 128–255 of the STK:
SKEK L(STK, 128, 128)
The SKEK is used by the EAPOL-Key frames to provide confidentiality in the 4-way STK
handshake.
f) The temporal key (TK) shall be computed as bits 256 to (255 + TK_bits) of the STK:
TK L(STK, 256, TK_bits)
The EAPOL-Key state machines (see 12.7.10 and 12.7.11) use the MLME-SETKEYS.request primitive to
configure the temporal key into the STA. The STA uses the temporal key with the pairwise cipher suite;
interpretation of this value is cipher-suite-specific.
2013
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the negotiated AKM is 00-0F-AC:5 or 00-0F-AC:6, the SMK identifier is defined as
SMKID = Truncate-128(HMAC-SHA-256(SMK, "SMK Name" || PNonce || MAC_P || INonce ||
MAC_I))
Otherwise, the SMK identifier is defined as
SMKID = Truncate-128(HMAC-SHA-1(SMK, "SMK Name" || PNonce || MAC_P || INonce || MAC_I))
In both these cases, “SMK Name” is treated as an ASCII string.
12.7.1.7 FT key hierarchy
12.7.1.7.1 Overview
This subclause describes the FT key hierarchy and its supporting architecture. The FT key hierarchy is
designed to allow a STA to make fast BSS transitions between APs without the need to perform an SAE or
IEEE 802.1X authentication at every AP within the mobility domain.
The FT key hierarchy can be used with SAE, IEEE 802.1X authentication, or PSK authentication.
A three-level key hierarchy provides key separation between the key holders. The FT key hierarchy for the
Authenticator is shown in Figure 12-31. An identical key hierarchy exists for the Supplicant, and identical
functions are performed by the corresponding S0KH and S1KH.
The FT key hierarchy shown in Figure 12-31 consists of three levels whose keys are derived using the key
derivation function (KDF) described in 12.7.1.7.2 as follows:
a) PMK-R0 – the first-level key of the FT key hierarchy. This key is derived as a function of the master
session key (MSK) or PSK. It is stored by the PMK-R0 key holders, R0KH and S0KH.
b) PMK-R1 – the second-level key of the FT key hierarchy. This key is mutually derived by the S0KH
and R0KH.
c) PTK – the third-level key of the FT key hierarchy that defines the IEEE 802.11 and IEEE 802.1X
protection keys. The PTK is mutually derived by the PMK-R1 key holders, R1KH and S1KH.
As shown in Figure 12-31, the R0KH computes the PMK-R0 from the key obtained from SAE
authentication (for the purposes of FT this key is identified as the Master PMK, or MPMK), from the PSK,
or from the MSK resulting (per IETF RFC 3748 [B42]) from a successful IEEE 802.1X authentication
between the AS and the Supplicant. Upon a successful authentication, the R0KH shall delete any prior
PMK-R0 security association for this mobility domain pertaining to this S0KH. The R0KH shall also delete
all PMK-R1 security associations derived from that prior PMK-R0 security association. The PMK-R1s are
generated by the R0KH and are assumed to be delivered from the R0KH to the R1KHs within the same
mobility domain. The PMK-R1s are used for PTK generation. Upon receiving a new PMK-R1 for an S0KH,
an R1KH deletes the prior PMK-R1 security association and PTKSAs derived from the prior PMK-R1.
It is assumed by this standard that the PSK is specific to a single S0KH and a single R0KH.
The lifetime of the PMK-R0, PMK-R1, and PTK are bound to the lifetime of the MPMK, PSK, or MSK
from which it was derived. For example, the AS may communicate the MSK lifetime with the MSK. If such
an attribute is provided, the lifetime of the PMK-R0 shall be not more than the lifetime of the MSK. The
lifetime of the PTK and PMK-R1 is the same as that of the PMK-R0. When the key lifetime expires, each
key holder shall delete its respective PMK-R0, PMK-R1 or PTKSA.
The FT key hierarchy derives its keys using the KDF defined in 12.7.1.7.2 with separate labels to further
distinguish derivations.
2014
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Authentication Server
SAE Authentication
(IEEE 802.1X Authentication only)
MSK PSK MPMK
R0 Key Holder (R0KH)
R0KH-ID
Derives PMK-R0
Derives PMK-R1s
PMK-R1A PMK-R1B
R1 Key Holder (R1KH) R1 Key Holder (R1KH)
R1KH-IDA R1KH-IDB
Derives PTKA Derives PTKB
PTK Key Holder PTK Key Holder
BSSIDA BSSIDB
Figure 12-31—FT key hierarchy at an Authenticator
During a fast BSS transition, a STA shall negotiate the same pairwise cipher suite with target APs as was
negotiated in the FT initial mobility domain association. Using the pairwise cipher suite selector value in the
PMK-R1 security association received from the R0KH, the target AP shall verify that the same pairwise
cipher suite selector is being used.
The distribution of keys from the R0KH to the R1KHs is outside the scope of this standard. It is assumed
that the PMK-R1s are distributed from the R0KH to the R1KHs following the requirements specified in
13.2.2.
The PMK-R0 may be deleted by the R0KH after PMK-R1s have been derived. When the PMK-R0 is
deleted, the R0KH needs only to maintain the PMK-R1 security associations.
12.7.1.7.2 Key derivation function (KDF)
The KDF is a variant of the pseudorandom function (PRF) defined in 12.7.1.2 and is defined as follows:
Output KDF-Hash-Length (K, Label, Context) where
Input: K, a derivation key whose length equals the block size of the hash function
Hash, a cryptographically strong hash function
Label, a string identifying the purpose of the keys derived using this KDF, treated as an
ASCII string
Context, a bit string that provides context to identify the derived key
Length, the length of the derived key in bits
Output: a Length-bit derived key
2015
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
result ""
iterations Length Hashlen
do i = 1 to iterations
result result || HMAC-Hash(K, i || Label || Context || Length)
od
return first Length bits of result, and irretrievably delete the other bits
where
i and Length are encoded as 16-bit unsigned integers, represented using the bit ordering conventions of
9.2.2
K, Label, and Context are bit strings and are represented using the ordering conventions of 9.2.2
Hashlen is the length, in bits, of the digest produced by Hash
12.7.1.7.3 PMK-R0
The first-level key in the FT key hierarchy, PMK-R0, is derived using the KDF defined in 12.7.1.7.2. The
PMK-R0 is the first level keying material used to derive the next level keys (PMK-R1s):
R0-Key-Data = KDF-Hash-Length(XXKey, "FT-R0", SSIDlength || SSID || MDID || R0KHlength ||
R0KH-ID || S0KH-ID)
PMK-R0 = L(R0-Key-Data, 0, Q)
PMK-R0Name-Salt = L(R0-Key-Data, Q, 128)
Length = Q + 128
where
— KDF-Hash-Length is the KDF as defined in 12.7.1.7.2 using the hash algorithm identified by the
AKM suite selector (see Table 9-133).
— If the AKM negotiated is 00-0F-AC:3, then Q shall be 256, and XXKey shall be the second 256 bits
of the MSK (which is derived from the IEEE 802.1X authentication), i.e., XXKey = L(MSK, 256,
256). If the AKM negotiated is 00-0F-AC:4, then Q shall be 256, and XXKey shall be the PSK. If
the AKM negotiated is 00-0F-AC:9, then Q shall be 256, and XXKey shall be the MPMK generated
as the result of SAE authentication. If the AKM negotiated is 00-0F-AC:13, then Q shall be 384, and
XXKey shall be the first 384 bits of the MSK (which is derived from the IEEE 802.1X
authentication), i.e., XXKey = L(MSK, 0, 384).
— SSIDlength is a single octet whose value is the number of octets in the SSID.
— SSID is the service set identifier, a variable-length sequence of octets, as it appears in the Beacon
and Probe Response frames.
— MDID is the Mobility Domain Identifier field from the Mobile Domain element (MDE) that was
used during FT initial mobility domain association.
— R0KHlength is a single octet whose value is the number of octets in the R0KH-ID.
— R0KH-ID is the identifier of the holder of PMK-R0 in the Authenticator.
— S0KH-ID is the Supplicant’s MAC address (SPA).
The PMK-R0 is referenced and named as follows:
PMKR0Name = Truncate-128(SHA-256("FT-R0N" || PMK-R0Name-Salt))
where
— "FT-R0N" is treated as an ASCII string.
2016
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PMKR0Name is used to identify the PMK-R0.
12.7.1.7.4 PMK-R1
The second-level key in the FT key hierarchy, PMK-R1, is a key used to derive the PTK. The PMK-R1 is
derived using the KDF defined in 12.7.1.7.2:
PMK-R1 = KDF-Hash-Length(PMK-R0, "FT-R1", R1KH-ID || S1KH-ID)
where
— KDF-Hash-Length is the KDF as defined in 12.7.1.7.2 using the hash algorithm identified by the
AKM suite selector (see Table 9-133) to generate a key whose length is equal to the length of the
hash algorithm’s digest.
— PMK-R0 is the first level key in the FT key hierarchy.
— R1KH-ID is a MAC address of the holder of the PMK-R1 in the Authenticator of the AP.
— S1KH-ID is the SPA.
The PMK-R1 is referenced and named as follows:
PMKR1Name = Truncate-128(SHA-256(“FT-R1N” || PMKR0Name || R1KH-ID || S1KH-ID))
where
— "FT-R1N" is treated as an ASCII string.
PMKR1Name is used to identify the PMK-R1.
12.7.1.7.5 PTK
The third-level key in the FT key hierarchy is the PTK. This key is mutually derived by the S1KH and the
R1KH used by the target AP, with the key length being a function of the negotiated cipher suite as defined
by Table 12-4 in 12.7.2.
Using the KDF defined in 12.7.1.7.2, the PTK derivation is as follows:
PTK = KDF-Hash-Length(PMK-R1, "FT-PTK", SNonce || ANonce || BSSID || STA-ADDR)
where
— KDF-Hash-Length is the KDF as defined in 12.7.1.7.2 using the hash algorithm identified by the
AKM suite selector (see Table 9-133).
— PMK-R1 is the key that is shared between the S1KH and the R1KH.
— SNonce is a 256-bit random bit string contributed by the S1KH.
— ANonce is a 256-bit random bit string contributed by the R1KH.
— STA-ADDR is the non-AP STA’s MAC address.
— BSSID is the BSSID of the target AP.
— Length is the total number of bits to derive, i.e., number of bits of the PTK. The length is dependent
on the negotiated cipher suites and AKM suites as defined by Table 12-4 in 12.7.2 and Table 12-8 in
12.7.3.
2017
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Each PTK has three component keys, KCK, KEK, and a temporal key, derived as follows:
The KCK shall be computed as the first KCK_bits bits (bits 0 to KCK_bits–1) of the PTK:
KCK = L(PTK, 0, KCK_bits).
The KCK is used to provide data origin authenticity in EAPOL-Key frames, as defined in 12.7.2, and in the
FT authentication sequence, as defined in 13.8.
The KEK shall be computed as the next KEK_bits of the PTK:
KEK = L(PTK, KCK_bits, KEK_bits)
The KEK is used to provide data confidentiality for certain fields (KeyData) in EAPOL-Key frames, as
defined in 12.7.2, and in the FT authentication sequence, as defined in 13.8.
The temporal key (TK) shall be computed as the next TK_bits (see Table 12-4) bits of the PTK:
TK = L(PTK, KCK_bits+KEK_bits, TK_bits)
For vendor-specific cipher suites, the length of the temporal key (and the value of Length) depend on the
vendor-specific algorithm.
The temporal key is configured into the STA by the SME through the use of the MLME-SETKEYS.request
primitive. The STA uses the temporal key with the pairwise cipher suite; interpretation of this value is
specific to the cipher suite.
The PTK is referenced and named as follows:
PTKName = Truncate-128(SHA-256(PMKR1Name || “FT-PTKN” || SNonce || ANonce || BSSID ||
STA-ADDR))
where
— "FT-PTKN" is treated as an ASCII string.
The PTKName is used to identify the PTK.
12.7.2 EAPOL-Key frames
IEEE Std 802.11 uses EAPOL-Key frames to exchange information between STAs’ Supplicants and
Authenticators. These exchanges result in cryptographic keys and synchronization of security association
state. EAPOL-Key frames are used to implement three different exchanges:
— 4-way handshake, to confirm that the PMK between associated STAs is the same and live and to
transfer the GTK to the STA.
— Group key handshake, to update the GTK at the STA.
— PeerKey initial SMK handshake to deliver the SMK and final 4-way STK handshake to deliver the
STK to the initiating and peer STAs.
When priority processing of Data frames is supported, an SME should send EAPOL-Key frames at the
highest priority.
2018
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The RSNA key descriptor used by IEEE Std 802.11 maps to the IEEE 802.1X Key Descriptor as described
in this subclause.
The bit and octet convention for fields in the EAPOL-Key frame are defined in 11.2 of IEEE Std 802.1X-
2010. EAPOL-Key frames containing invalid field values shall be silently discarded. Figure 12-32 depicts
the format of an EAPOL-Key frame.
Protocol
Packet Type Packet Body Length
Version
– 1 octet – 2 octets
– 1 octet
Descriptor Type – 1 octet
Key Information – 2 Key Length – 2 octets
octets
Key Replay Counter – 8 octets
Key Nonce – 32 octets
EAPOL - Key IV – 16 octets
Key RSC – 8 octets
Reserved - 8 octets
Key MIC – variable
Key Data Length – 2 Key Data – n octets
octets
Figure 12-32—EAPOL-Key frame
The fields of an EAPOL-Key frame body are as follows:
a) Descriptor Type. This field is 1 octet and has a value defined by IEEE Std 802.1X-2010,
identifying the IEEE 802.11 key descriptor.
b) Key Information. This field is 2 octets and specifies characteristics of the key. See Figure 12-33.
B0 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15
Key Key Reserved Install Key Key Se- Error Request Encrypted SMK Reserved
Descriptor Type Ack MIC cure Key Data Message
Version
Figure 12-33—Key Information bit layout
The bit convention used is as in 11.2 of IEEE Std 802.1X-2010. The subfields of the Key
Information field are as follows:
1) Key Descriptor Version (bits 0–2) shall be set to 0 on all transmitted EAPOL-Key frames
except under the following circumstances:
i) The value 1 shall be used for all EAPOL-Key frames to a STA when the negotiated AKM
is 00-0F-AC:1 or 00-0F-AC:2 and the pairwise cipher is TKIP or "Use group cipher suite"
for Key Descriptor 1. This value indicates the following:
— HMAC-MD5 is the EAPOL-Key MIC.
— ARC4 is the EAPOL-Key encryption algorithm used to protect the Key Data field.
— The MIC is 16 octets.
ii) The value 2 shall be used for all EAPOL-Key frames to a STA when the negotiated AKM
is 00-0F-AC:1 or 00-0F-AC:2 and either the pairwise or the group cipher is an enhanced
2019
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
data cryptographic encapsulation mechanism other than TKIP for Key Descriptor 2. This
value indicates the following:
— HMAC-SHA-1-128 is the EAPOL-Key MIC. HMAC is defined in IETF RFC 2104;
and SHA-1, by FIPS PUB 180-4. The output of the HMAC-SHA-1 shall be
truncated to its 128 MSBs (octets 0–15 of the digest output by HMAC-SHA-1), i.e.,
the last four octets generated shall be irretrievably deleted).
— The NIST AES key wrap is the EAPOL-Key encryption algorithm used to protect
the Key Data field. IETF RFC 3394 defines the NIST AES key wrap algorithm.
— The MIC is 16 octets.
iii) The value 3 shall be used for all EAPOL-Key frames to a STA when the negotiated AKM
is 00-0F-AC:3, 00-0F-AC:4, 00-0F-AC:5, or 00-0F-AC:6. This value indicates the follow-
ing:
— AES-128-CMAC is the EAPOL-Key MIC. AES-128-CMAC is defined by NIST
Special Publication 800-38B and also found in IETF RFC 4493. The output of the
AES-128-CMAC shall be 128 bits.
— The NIST AES key wrap is the EAPOL-Key encryption algorithm used to protect
the Key Data field. IETF RFC 3394 defines the NIST AES key wrap algorithm.
— The MIC is 16 octets.
2) Key Type (bit 3) specifies whether this EAPOL-Key frame is part of a 4-way handshake
deriving a PTK.
i) The value 0 (Group/SMK) indicates the message is not part of a PTK derivation.
ii) The value 1 (Pairwise) indicates the message is part of a PTK derivation.
3) Reserved (bits 4–5).
4) Install (bit 6).
i) If the value of Key Type (bit 3) is 1, then for the Install bit,
— The value 1 means the IEEE 802.1X component shall configure the temporal key
derived from this message into its IEEE 802.11 STA.
— The value 0 means the IEEE 802.1X component shall not configure the temporal key
into the IEEE 802.11 STA.
ii) If the value of Key Type (bit 3) is 0, then this bit is reserved.
5) Key Ack (bit 7) is set to 1 in messages from the Authenticator if an EAPOL-Key frame is
required in response to this message and is 0 otherwise. The Supplicant’s response to this
message shall use the same replay counter as this message.
6) Key MIC (bit 8) is set to 1 if a MIC is in this EAPOL-Key frame and is set to 0 if this message
contains no MIC.
7) Secure (bit 9) is set to 1 once the initial key exchange is complete.
The Authenticator shall set the Secure bit to 0 in all EAPOL-Key frames sent before the
Supplicant has the PTK and the GTK. The Authenticator shall set the Secure bit to 1 in all
EAPOL-Key frames it sends to the Supplicant containing the last key needed to complete the
Supplicant’s initialization.
The Supplicant shall set the Secure bit to 0 in all EAPOL-Key frames it sends before it has the
PTK and the GTK and before it has received an EAPOL-Key frame from the Authenticator
with the Secure bit equal to 1 (this should be before receiving message 3 of the 4-way
handshake). The Supplicant shall set the Secure bit to 1 in all EAPOL-Key frames sent after
this until it loses the security association it shares with the Authenticator.
8) Error (bit 10) is set by a Supplicant to report that a MIC failure occurred in a TKIP MSDU or
SMK handshake failure. In case of a MIC failure, a Supplicant shall set this bit to 1 only when
2020
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the Request (bit 11) is 1. When the SMK Message bit is 1, Error shall be set to 1 to indicate the
key data field contains an Error KDE.
9) Request (bit 11) is set to 1 by a Supplicant to request that the Authenticator initiate either a 4-
way handshake or group key handshake, is set to 1 by a Supplicant in a Michael MIC Failure
Report, and is set to 1 by the STSL peer STA to request initiator STA rekeying of the STK. The
Supplicant shall not set this bit to 1 in on-going 4-way handshakes, i.e., the Key Ack bit (bit 7)
shall not be set to 1 in any message in which the Request bit is 1. The Authenticator shall never
set this bit to 1.
In a Michael MIC Failure Report, setting the bit is not a request to initiate a new handshake.
However, the recipient may initiate a new handshake on receiving such a message.
If an EAPOL-Key frame in which the Request bit is 1 has a key type of Pairwise, the
Authenticator shall initiate a 4-way handshake. If the EAPOL-Key frame in which the Request
bit is 1 has a key type of Group/SMK, the Authenticator shall change the GTK, initiate a 4-way
handshake with the Supplicant, and then execute the group key handshake to all Supplicants.
If an EAPOL-Key frame in which the Request bit is 1 has the SMK Message bit equal to 1, the
initiator STA shall take appropriate action to create a new STK (based on 12.7.8).
10) Encrypted Key Data (bit 12) is set to 1 if the Key Data field is encrypted and is set to 0 if the
Key Data field is not encrypted. This subfield shall be set to 1, and the Key Data field shall be
encrypted, if any key material (e.g., GTK or SMK) is included in the frame.
11) SMK Message (bit 13) specifies whether this EAPOL-Key frame is part of an SMK handshake.
If the SMK handshake is not supported, the SMK Message subfield is reserved.
12) Reserved (bits 14–15).
c) Key Length. This field is 2 octets in length, represented as an unsigned integer. The value defines
the length in octets of the pairwise temporal key. See Table 12-4.
Table 12-4—Cipher suite key lengths
Key length TK_bits
Cipher suite
(octets) (bits)
WEP-40 5 40
WEP-104 13 104
TKIP 32 256
CCMP-128 16 128
BIP-CMAC-128 16 128
GCMP-128 16 128
GCMP-256 32 256
CCMP-256 32 256
BIP-GMAC-128 16 128
BIP-GMAC-256 32 256
BIP-CMAC-256 32 256
d) Key Replay Counter. This field is 8 octets, represented as an unsigned integer, and is initialized to
0 when the PMK is established. The Supplicant shall use the key replay counter in the received
2021
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
EAPOL-Key frame when responding to an EAPOL-Key frame. It carries a sequence number that the
protocol uses to detect replayed EAPOL-Key frames.
The Supplicant and Authenticator shall track the key replay counter per security association. The
key replay counter shall be initialized to 0 on (re)association. The Authenticator shall increment the
key replay counter on each successive EAPOL-Key frame.
When replying to a message from the Authenticator, the Supplicant shall use the Key Replay
Counter field value from the last valid EAPOL-Key frames received from the Authenticator. The
Authenticator should use the key replay counter to identify invalid messages to silently discard. The
Supplicant should also use the key replay counter and ignore EAPOL-Key frames with a Key
Replay Counter field value smaller than or equal to any received in a valid message. The local Key
Replay Counter field should not be updated until after the EAPOL-Key MIC is checked and is found
to be valid. In other words, the Supplicant never updates the Key Replay Counter field for message
1 in the 4-way handshake, as it includes no MIC. This implies the Supplicant needs to allow for
retransmission of message 1 when checking for the key replay counter of message 3.
The Supplicant shall maintain a separate key replay counter for sending EAPOL-Key request frames
to the Authenticator; the Authenticator also shall maintain a separate replay counter to filter received
EAPOL-Key request frames.
NOTE—The key replay counter does not play any role beyond a performance optimization in the 4-way handshake. In
particular, replay protection is provided by selecting a never-before-used nonce value to incorporate into the PTK. It
does, however, play a useful role in the group key handshake.
e) Key Nonce. This field is 32 octets. It conveys the ANonce from the Authenticator and the SNonce
from the Supplicant. It may contain 0 if a nonce is not required to be sent.
f) EAPOL-Key IV. This field is 16 octets. It contains the IV used with the KEK. It shall contain 0
when an IV is not required. It should be initialized by taking the current value of the global key
counter (see 12.7.11) and then incrementing the counter. Note that only the lower 16 octets of the
counter value are used.
g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the
GTK being installed. It is used in message 3 of the 4-way handshake and message 1 of the group key
handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the
Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC
failure. It shall contain 0 in other messages. The Key RSC field gives the current message number
for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8
octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN
should be in the first octet of the Key RSC field. The encoding of the Key RSC field is defined in
Table 12-5.
Table 12-5—Key RSC field
KeyRSC 0 KeyRSC 1 KeyRSC 2 KeyRSC 3 KeyRSC 4 KeyRSC 5 KeyRSC 6 KeyRSC 7
TSC0 TSC1 TSC2 TSC3 TSC4 TSC5 0 0
PN0 PN1 PN2 PN3 PN4 PN5 0 0
For WEP, the Key RSC field is reserved.
h) Key MIC. The EAPOL Key MIC is a MIC of the EAPOL-Key frames, from and including the
EAPOL protocol version field to and including the Key Data field, calculated with the Key MIC
field set to 0. If the Encrypted Key Data subfield (of the Key Information field) is 1, the Key Data
field is encrypted prior to computing the MIC. The length of this field depends on the negotiated
AKM as defined in 12.7.3.
2022
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
i) Key Data Length. This field is 2 octets in length, taken to represent an unsigned integer. This
represents the length of the Key Data field in octets. If the Encrypted Key Data subfield (of the Key
Information field) is 1, the length is the length of the Key Data field after encryption, including any
padding.
j) Key Data. This field is a variable-length field that is used to include any additional data required for
the key exchange that is not included in the fields of the EAPOL-Key frame. The additional data
may be zero or more element(s) (such as the RSNE) and zero or more key data cryptographic
encapsulation(s) (KDEs) (such as GTK(s) or PMKID(s)). Elements sent in the Key Data field
include the Element ID and Length subfields. KDEs shall be encapsulated using the format in
Figure 12-34.
Type (0xdd) Length OUI Data Type Data
Octets: 1 1 3 1 (Length – 4)
Figure 12-34—KDE format
The Type field shall be set to 0xdd. The Length field specifies the number of octets in the OUI, Data
Type, and Data fields. The OUI field contains either an OUI or CID. The order of the OUI field is
described in 9.2.2.
Table 12-6 lists the KDE selectors defined by this standard.
Table 12-6—KDE
OUI Data type Meaning
00-0F-AC 0 Reserved
00-0F-AC 1 GTK KDE
00-0F-AC 2 Reserved
00-0F-AC 3 MAC address KDE
00-0F-AC 4 PMKID KDE
00-0F-AC 5 SMK KDE
00-0F-AC 6 Nonce KDE
00-0F-AC 7 Lifetime KDE
00-0F-AC 8 Error KDE
00-0F-AC 9 IGTK KDE
00-0F-AC 10 Key ID KDE
00-0F-AC 11 Multi-band GTK KDE
00-0F-AC 12 Multi-band Key ID KDE
00-0F-AC 13–255 Reserved
Other OUI or CID Any Vendor specific
A STA shall ignore any elements and KDEs it does not understand.
If the Encrypted Key Data subfield (of the Key Information field) is 1, the entire Key Data field shall
be encrypted. If the Key Data field uses the NIST AES key wrap, then the Key Data field shall be
padded before encrypting if the key data length is less than 16 octets or if it is not a multiple of 8.
2023
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The padding consists of appending a single octet 0xdd followed by zero or more 0x00 octets. When
processing a received EAPOL-Key frame, the receiver shall ignore this trailing padding. Key Data
fields that are encrypted, but do not contain the GroupKey or SMK KDE, shall be accepted.
If the GroupKey or SMK KDE is included in the Key Data field, but the Key Data field is not
encrypted, the EAPOL-Key frames shall be ignored.
The format of the GTK KDE is shown in Figure 12-35
Key ID Tx Reserved Reserved GTK
bits 0–1 bit 2 bit 3–7 1 octet (Length – 6) octets
Figure 12-35—GTK KDE format
If the value of the Tx field is 1, then the IEEE 802.1X component shall configure the temporal key
derived from this KDE into its IEEE 802.11 STA for both transmission and reception.
If the value of the Tx field is 0, then the IEEE 802.1X component shall configure the temporal key
derived from this KDE into its IEEE 802.11 STA for reception only.
The format of the MAC address KDE is shown in Figure 12-36.
MAC Address
Octets: 6
Figure 12-36—MAC address KDE format
The format of the PMKID KDE is shown in Figure 12-37.
PMKID
Octets: 16
Figure 12-37—PMKID KDE format
The format of the SMK KDE is shown in Figure 12-38.
SMK Key Nonce
Octets: 32 32
Figure 12-38—SMK KDE format
The format of the Nonce KDE is shown in Figure 12-39.
Key Nonce
Octets: 32
Figure 12-39—Nonce KDE format
The format of the Lifetime KDE is shown in Figure 12-40. The Key Lifetime value is expressed in
seconds and uses big endian octet order.
2024
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Key Lifetime (in seconds)
Octets: 4
Figure 12-40—Lifetime KDE format
The format of the Error KDE is shown in Figure 12-41. The Error Type field is in big endian octet
order. Table 12-7 shows different values of SMK error types.
Reserved Error Type
Octets: 2 2
Figure 12-41—Error KDE format
Table 12-7—SMK error types
Error name Error type Error meaning
ERR_STA_NR 1 STA is not reachable from AP. See 12.7.8.5.2.
ERR_STA_NRSN 2 STA to AP secure network not present. See 12.7.8.5.3.
ERR_CPHR_NS 3 Cipher suites not supported. See 12.7.8.5.4.
ERR_NO_STSL 4 No STSL session present. See 12.7.8.5.5.
The format of the IGTK KDE is shown in Figure 12-42. The IPN corresponds to the last packet number used
by the broadcast/multicast transmitter, and it is used by the receiver as the initial value for the BIP replay
counter.
Key ID IPN IGTK
Octets: 2 6 (Length – 12)
Figure 12-42—IGTK KDE format
The following EAPOL-Key frames are used to implement the three different exchanges:
— 4-way handshake message 1 is an EAPOL-Key frame with the Key Type subfield equal to 1. The
Key Data field shall contain a PMKID for the PMK that is being used in this key derivation and need
not be encrypted.
— 4-way handshake message 2 is an EAPOL-Key frame with the Key Type subfield equal to 1. The
Key Data field shall contain an RSNE and need not be encrypted.
An ESS Supplicant’s SME shall insert the RSNE it sent in its (Re)Association Request frame. The
RSNE is included as transmitted in the Management frame. On receipt of message 2, the
Authenticator’s SME shall validate the selected security configuration against the RSNE received in
the IEEE 802.11 (Re)Association Request.
An IBSS Supplicant’s SME shall insert an RSNE containing a selected pairwise cipher suite. The
Authenticator’s SME shall validate that the pairwise cipher suite selected is one of its configured
cipher suites and that the group cipher suite and AKM are consistent.
2025
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— 4-way handshake message 3 is an EAPOL-Key frame with the Key Type subfield equal to 1. The
Key Data field shall contain one or two RSNEs. If a group cipher has been negotiated, this field shall
also include a GTK. This field shall be encrypted if a GTK is included.
An Authenticator’s SME shall insert the RSNE it sent in its Beacon or Probe Response frame. The
Supplicant’s SME shall validate the selected security configuration against the RSNE received in
message 3. If the second optional RSNE is present, the STA shall either use that cipher suite with its
pairwise key or deauthenticate. In either case, if the values do not match, then the receiver shall
consider the RSNE modified and shall use the MLME-DEAUTHENTICATE.request primitive to
break the association. A security error should be logged at this time.
It may happen, for example, that a Supplicant selects a pairwise cipher suite which is advertised by
an AP, but which policy disallows for this particular STA. An Authenticator may, therefore, insert a
second RSNE to overrule the STA’s selection. An Authenticator’s SME shall insert the second
RSNE, after the first RSNE, only for this purpose. The pairwise cipher suite in the second RSNE
included shall be one of the ciphers advertised by the Authenticator. All other fields in the second
RSNE shall be identical to the first RSNE.
A GTK shall be included and the unencrypted length of the GTK is six less than the length of the
GTK KDE in octets. The entire Key Data field shall be encrypted as specified by the Key Descriptor
Version.
— 4-way handshake message 4 is an EAPOL-Key frame with the Key Type subfield equal to 1. The
Key Data field can be empty.
— Group key handshake message 1 is an EAPOL-Key frame with the Key Type subfield equal to 0.
The Key Data field shall contain a GTK KDE and shall be encrypted.
— Group key handshake message 2 is an EAPOL-Key frame with the Key Type subfield equal to 0.
The Key Data field can be empty.
PeerKey handshake messages use EAPOL-Key frames as defined in 12.7.8.
The key wrap algorithm selected depends on the negotiated AKM as defined in 12.7.3.
The format of the Key ID KDE is shown in Figure 12-43.
B0 B1 B2 B15
Key ID Reserved
Bits: 2 14
Figure 12-43—Key ID KDE
The Key ID field contains the Authenticator selected Key ID.
The format of the Multi-band GTK KDE is shown in Figure 12-44.
B0 B1 B2 B3 B7 B8 B15 B16 B63
Key ID Tx Reserved Band ID GTK
Bits: 2 1 5 8 48
Figure 12-44—Multi-band GTK KDE
The definitions of the Key ID, Tx, and GTK fields are the same as in the GTK KDE described above.
The Band ID field contains the identification of the frequency band (see 9.4.1.46).
2026
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The format of the Multi-band Key ID KDE is shown in Figure 12-45.
B0 B1 B2 B7 B8 B15
Key ID Reserved Band ID
Bits: 2 6 8
Figure 12-45—Multi-band Key ID KDE
The definitions of the Key ID and Band ID fields are the same as in the Multi-band GTK KDE described
above.
12.7.3 EAPOL-Key frame construction and processing
EAPOL-Key frames are constructed and processed according to the AKM negotiated at association time.
The negotiated AKM determines what algorithm is used to construct and verify a MIC, the size of the MIC,
and the algorithm used to wrap and unwrap the Key Data field.
Table 12-8 indicates the particular algorithms to use when constructing and processing EAPOL-Key frames.
The AKM of “Deprecated” indicates an AKM of 00-0F-AC:1 or 00-0F-AC:2 when either TKIP or “Use
group cipher suite” is the negotiated pairwise cipher. For all other AKMs the negotiated pairwise cipher
suite does not influence the algorithms used to process EAPOL-Key frames.
Table 12-8—Integrity and key-wrap algorithms
Integrity Key-wrap
AKM KCK_bits Size of MIC KEK_bits
algorithm algorithm
00-0F-AC:1 HMAC-SHA-1-128 128 16 NIST AES Key 128
Wrap
00-0F-AC:2 HMAC-SHA-1-128 128 16 NIST AES Key 128
Wrap
00-0F-AC:3 AES-128-CMAC 128 16 NIST AES Key 128
Wrap
00-0F-AC:4 AES-128-CMAC 128 16 NIST AES Key 128
Wrap
00-0F-AC:5 AES-128-CMAC 128 16 NIST AES Key 128
Wrap
00-0F-AC:6 AES-128-CMAC 128 16 NIST AES Key 128
Wrap
00-0F-AC:8 AES-128-CMAC 128 16 NIST AES Key 128
Wrap
00-0F-AC:9 AES-128-CMAC 128 16 NIST AES Key 128
Wrap
00-0F-AC:11 HMAC-SHA-256 128 16 NIST AES Key 128
Wrap
00-0F-AC:12 HMAC-SHA-384 192 24 NIST AES Key 256
Wrap
00-0F-AC:13 HMAC-SHA-384 192 24 NIST AES Key 256
Wrap
2027
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.7.4 EAPOL-Key frame notation
The following notation is used throughout the remainder of 12.7 and 13.4 to represent EAPOL-Key frames:
EAPOL-Key(S, M, A, I, K, SM, KeyRSC, ANonce/SNonce, MIC, DataKDs)
where
S means the initial key exchange is complete. This is the Secure bit of the Key Informa-
tion field.
M means the MIC is available in message. This should be set in all messages except
message 1 of a 4-way handshake. This is the Key MIC bit of the Key Information
field.
A means a response is required to this message. This is used when the receiver should
respond to this message. This is the Key Ack bit of the Key Information field.
I is the Install bit: Install/Not install for the pairwise key. This is the Install bit of the
Key Information field.
K is the key type: P (Pairwise), G (Group/SMK). This is the Key Type bit of the Key
Information field.
SM is the SMK Message bit: indicates that this message is part of SMK handshake.
KeyRSC is the key RSC. This is the Key RSC field.
ANonce/SNonce is the Authenticator/Supplicant nonce. This is the Key Nonce field.
MIC is the integrity check, which is generated using the KCK. This is the Key MIC field.
DataKDs is a sequence of zero or more elements and KDEs, contained in the Key Data field,
which may contain the following:
RSNE is described in 9.4.2.25.
RSNE[KeyName] is the RSNE, with the PMKID field set to KeyName.
GTK[N] is the GTK, with the key identifier field set to N. The key identifier specifies
which index is used for this GTK. Index 0 shall not be used for GTKs,
except in mixed environments, as described in 12.7.1.
FTE is the Fast BSS Transition element, described in 9.4.2.48
MDE is the Mobility Domain element, described in 9.4.2.47
TIE[IntervalType] is a Timeout Interval element of type IntervalType, as described in 9.4.2.49,
containing e.g., for type KeyLifetime, the lifetime of the FT key hierarchy.
IGTK[M] is the IGTK, with key identifier field set to M.
IPN is the current IGTK replay counter value provided by the IGTK KDE
PMKID is of type PMKID KDE and is the key identifier used during 4-way PTK
handshake for PMK identification and during 4-way STK handshake for
SMK identification.
Lifetime is the key lifetime KDE used for sending the expiration timeout value for
SMK used during PeerKey handshake for SMK identification.
Initiator MAC is the Initiator MAC KDE used during PeerKey handshake
Peer MAC is the Peer MAC KDE used during PeerKey handshake
Initiator Nonce is the Initiator Nonce KDE used during PeerKey handshake. This is used
when multiple nonces need to be sent.
Peer Nonce is the Peer Nonce KDE used during PeerKey handshake. This is used when
multiple nonces need to be sent.
SMK KDE is the SMK during SMK handshake.
Error KDE is an error KDE used when error bit E is equal to 1 during PeerKey hand-
shake.
12.7.5 Nonce generation
The following is an informative description of Nonce generation.
2028
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
All STAs contain a global key counter, which is 256 bits in size. It should be initialized at system boot-up
time to a fresh cryptographic-quality random number. Refer to J.5 on random number generation. It is
recommended that the counter value is initialized to the following:
PRF-256(Random number, “Init Counter”, Local MAC Address || Time)
The local MAC address should be AA on the Authenticator and SPA on the Supplicant.
The random number is 256 bits in size. Time should be the current time from Network Time Protocol (NTP)
or another time in NTP format whenever possible. This initialization causes different initial key counter
values to occur across system restarts regardless of whether a real-time clock is available. The key counter
can be used as additional input data for nonce generation. A STA derives a random nonce for each new use.
12.7.6 4-way handshake
12.7.6.1 General
RSNA defines a protocol using EAPOL-Key frames called the 4-way handshake. The handshake completes
the IEEE 802.1X authentication process. The information flow of the 4-way handshake is as follows:
Message 1: Authenticator Supplicant: EAPOL-Key(0,0,1,0,P,0,0,ANonce,0,DataKD_M1)
where DataKD_M1 = 0 or PMKID for PTK generation, or PMKID KDE (for sending
SMKID) for STK generation
Message 2: Supplicant Authenticator: EAPOL-Key(0,1,0,0,P,0,0,SNonce,MIC,DataKD_M2)
where DataKD_M2 = RSNE for creating PTK generation or peer RSNE, Lifetime
KDE, SMKID KDE (for sending SMKID) for STK generation
Message 3: Authenticator Supplicant:
EAPOL-Key(1,1,1,1,P,0,KeyRSC,ANonce,MIC,DataKD_M3)
where DataKD_M3 = RSNE,GTK[N] for creating PTK generation or initiator RSNE,
Lifetime KDE for STK generation
Message 4: Supplicant Authenticator: EAPOL-Key(1,1,0,0,P,0,0,0,MIC,DataKD_M4)
where DataKD_M4 = 0.
The FT initial mobility domain association uses the FT 4-way handshake to establish an initial PTKSA,
GTKSA and, if management frame protection is enabled, an IGTKSA, that is based on this protocol. The FT
4-way handshake protocol is described in 13.4.
Here, the following assumptions apply:
— EAPOL-Key( ) denotes an EAPOL-Key frame conveying the specified argument list, using the
notation introduced in 12.7.4.
— ANonce is a nonce that the Authenticator contributes for PTK generation or that the initiator STA
contributes for STK generation. ANonce has the same value in message 1 and message 3.
— SNonce is a nonce from the Supplicant for PTK generation or from the peer STA for
STK generation.
— P means the pairwise bit is set.
— The MIC is computed over the body of the EAPOL-Key frame (with the Key MIC field first zeroed
before the computation) using the KCK defined in 12.7.1.3 for PTK generation or SKCK defined in
12.7.1.6.
— RSNE represents the appropriate RSNEs.
— GTK[N] represents the GTK with its key identifier.
— SMKID represents the SMKID key identifier used during STK generation.
— Lifetime represents the expiration timeout used for exchanging SMK expiration value.
2029
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—While the MIC calculation is the same in each direction, the Key Ack bit is different in each direction. It is set
in EAPOL-Key frames from the Authenticator and 0 in EAPOL-Key frames from the Supplicant. 4-way handshake
requests from the Supplicant have the Request bit equal to 1. The Authenticator and Supplicant need to check these bits
to stop reflection attacks. It is important that message 1 contents not be used to update state, in particular the keys in use,
until the data are validated with message 3.
12.7.6.2 4-way handshake message 1
Message 1 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0
Key Type = 1 (Pairwise)
SMK Message = 0
Install = 0
Key Ack = 1
Key MIC = 0
Secure = 0
Error = 0
Request = 0
Encrypted Key Data = 0
Reserved = 0 – unused by this protocol version
Key Length = Cipher-suite-specific; see Table 12-4
Key Replay Counter = n – to allow Authenticator or initiator STA to match the right message 2 from
Supplicant or peer STA
Key Nonce = ANonce
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = 0
Key Data Length = length of Key Data field in octets
Key Data = PMKID for the PMK being used during PTK generation or SMKID for SMK being used
during STK generation
Processing for PTK generation is as follows:
The Authenticator sends message 1 to the Supplicant at the end of a successful IEEE 802.1X authentication,
after (re)association completes for a STA that has authenticated with SAE or PSK authentication is
negotiated, when a cached PMKSA is used, or after a STA requests a new key. On reception of message 1,
the Supplicant determines whether the Key Replay Counter field value has been used before with the current
PMKSA. If the Key Replay Counter field value is less than or equal to the current local value, the Supplicant
discards the message. Otherwise, the Supplicant:
a) Generates a new nonce SNonce.
b) Derives PTK.
c) Constructs message 2.
Processing for STK generation is as follows:
2030
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The initiator STA (STA_I) sends message 1 to the peer STA (STA_P) at the end of a successful SMK
handshake, when SMKSA is created. On reception of message 1, the STA_P determines whether the Key
Replay Counter field value has been used before with the current SMKSA. If the Key Replay Counter field
value is less than or equal to the current local value, the STA_P discards the message. Otherwise, the STA_P
a) Generates a 256-bit random number following the recommendations of 12.7.5. That number is sent
as a peer nonce as part of the Key Nonce field. This Nonce is different from the peer nonce
generated as part of the SMK handshake message 3.
b) Derives STK.
c) Constructs message 2.
12.7.6.3 4-way handshake message 2
Message 2 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0 – same as message 1
Key Type = 1 (Pairwise) – same as message 1
SMK Message = 0 – same as message 1
Install = 0
Key Ack = 0
Key MIC = 1
Secure = 0 – same as message 1
Error = 0 – same as message 1
Request = 0 – same as message 1
Encrypted Key Data = 0
Reserved = 0 – unused by this protocol version
Key Length = 0
Key Replay Counter = n – to let the Authenticator or initiator STA know to which message 1 this
corresponds
Key Nonce = SNonce
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC(KCK, EAPOL) – MIC computed over the body of this EAPOL-Key frame with the
Key MIC field first initialized to 0
Key Data Length = length of Key Data field in octets
Key Data =
— included RSNE – the sending STA’s RSNE for PTK generation or peer RSNE for the
current operating band, and when this message 2 is part of a fast BSS transition initial
mobility domain association or an association started through the FT protocol, the
PMKR1Name calculated by the S1KH according to the procedures of 12.7.1.7.4 is
included in the PMKID field of the RSNE and the FTE and MDE are also included, or;
— The sending STA’s Multi-band element for PTK generation for a supported band other
than the current operating band if dot11MultibandImplemented is true, or;
— The sending STA’s RSNE and Multi-band element(s) for generating a single PTK for all
involved bands, if dot11MultibandImplemented is true and both the Authenticator and the
2031
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Supplicant use the same MAC address in the current operating band and the other
supported band(s); or;
— The sending STA’s RSNE and Multi-band element(s) for generating a different PTK for
each involved band, if dot11MultibandImplemented is true and the Joint Multi-band
RSNA subfield of the RSN capabilities field is 1 for both the Authenticator and the
Supplicant, and either the Authenticator or the Supplicant uses different MAC addresses
for different bands.
— Lifetime of SMK and SMKID for STK generation.
Processing for PTK generation is as follows:
The Supplicant sends message 2 to the Authenticator.
On reception of message 2, the Authenticator checks that the key replay counter corresponds to the
outstanding message 1. If not, it silently discards the message. Otherwise, the Authenticator:
a) Derives PTK.
b) Verifies the message 2 MIC.
1) If the calculated MIC does not match the MIC that the Supplicant included in the EAPOL-Key
frame, the Authenticator silently discards message 2.
2) If the MIC is valid and this message 2 is part of a fast BSS transition initial mobility domain
association or an association started through the FT protocol, the Authenticator checks that all
fields of the RSNE other than the PMKID field bitwise matches the fields from the
(Re)Association Request frame and that the FTE and MDE are the same as those provided in
the AP’s (Re)Association Response frame. If the MIC is valid and this message 2 is not part of
a fast BSS transition initial mobility domain association and this message 2 is not part of an
association started through the FT protocol, the Authenticator checks that the RSNE bitwise
matches that from the (Re)Association Request frame.
i) If these are not exactly the same, the Authenticator uses MLME-DEAUTHENTI-
CATE.request primitive to terminate the association.
ii) If they do match bitwise, the Authenticator constructs message 3.
c) If management frame protection is being negotiated, the AP initializes the SA Query Transaction
Identifier to an implementation-specific non-negative integer value, valid for the current pairwise
security association.
Processing for STK generation is as follows:
The STA_P sends message 2 to the STA_I. On reception of message 2, the STA_I checks that the key replay
counter corresponds to message 1. If not, it silently discards the message. Otherwise, the STA_I
a) Derives the STK.
b) Verifies the message 2 MIC using the SKCK. If the calculated MIC does not match the MIC that the
STA_P included in the EAPOL-Key frame, the STA_I silently discards message 2.
c) If the MIC is valid, the STA_I checks that the RSNE bitwise matches that from the SMK handshake
message 5. If these are not exactly the same, STA_I silently discards the message and restarts the 4-
way handshake after deleting the existing 4-way handshake states.
d) If they do match bitwise, the STA_I checks SMKID with the value of SMKID in the SMKSA. If
these are not exactly the same, STA_I silently discards the message and restarts the 4-way
handshake after deleting the existing 4-way handshake states.
e) If they do match, the STA_I constructs message 3. It also compares the Key Lifetime value from the
KDE with value in its SMKSA. If value in its SMKSA is less, it discards the value received in
message 2. Otherwise, it updates the value in the SMKSA with value in message 2.
2032
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.7.6.4 4-way handshake message 3
Message 3 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0 – same as message 1
Key Type = 1 (Pairwise) – same as message 1
SMK Message = 0 - same as message 1
Install = 0/1 – For PTK generation, 0 only if the AP does not support key mapping keys, or if
the STA has the No Pairwise bit (in the RSN Capabilities field) equal to 1and only the
group key is used. For STK generation, this bit is set to 1.
Key Ack = 1
Key MIC = 1
Secure = 1 (keys installed)
Error = 0 – same as message 1
Request = 0 – same as message 1
Encrypted Key Data = 1
Reserved = 0 – unused by this protocol version
Key Length = Cipher-suite-specific; see Table 12-4
Key Replay Counter = n+1
Key Nonce = ANonce – same as message 1
EAPOL-Key IV = 0 (Version 2) or random (Version 1)
Key RSC = For PTK generation, starting TSC or PN that the Authenticator’s STA uses in MPDUs
protected by GTK. For STK generation, this is set to 0.
Key MIC = MIC(KCK, EAPOL) or MIC(SKCK, EAPOL) – MIC computed over the body of this
EAPOL-Key frame with the Key MIC field first initialized to 0
Key Data Length = length of Key Data field in octets of included RSNEs and GTK
Key Data =
— For PTK generation for the current operating band, the AP’s Beacon/Probe Response
frame’s RSNE for the current operating band, and, optionally, a second RSNE that is the
Authenticator’s pairwise cipher suite assignment for the current operating band, and, if a
group cipher has been negotiated, the GTK and the GTK’s key identifier (see 12.7.2) for
the current operating band, and if management frame protection is negotiated, the IGTK
KDE, and when this message 3 is part of a fast BSS transition initial mobility domain
association or an association started through the FT protocol, the PMKR1Name calculated
according to the procedures of 12.7.1.7.4 in the PMKID field of the RSNE and the FTE
with the same contents as in the (Re)Association Response frame, the MDE with the same
contents as in the (Re)Association Response frame, the reassociation deadline timeout set
to the minimum of dot11FTReassociationDeadline and the key lifetime in the
TIE[ReassociationDeadline], and the PTK lifetime in the TIE[KeyLifetime]; or
— For PTK generation for a supported band other than the current operating band, the
Authenticator’s Beacon/DMG Beacon/Announce/Probe Response/Information Response
frame’s Multi-band element associated with the supported band, and optionally a second
Multi-band element that indicates the Authenticator’s pairwise cipher suite assignment for
the supported band, and, if group cipher for the supported band is negotiated, the Multi-
band GTK KDE for the supported band if dot11MultibandImplemented is true, or;
2033
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— For generating a single PTK for all involved bands, the Authenticator’s Beacon/DMG
Beacon/Announce/Probe Response/Information Response frame’s RSNE and Multi-band
element(s), and optionally, additional RSNE and Multi-band element(s) that indicate the
Authenticator’s assignment of one pairwise cipher suite for all involved bands; if a group
cipher for all involved bands is negotiated, the GTK and the GTK’s key identifier for all
involved bands, if dot11MultibandImplemented is true and both the Authenticator and the
Supplicant use the same MAC address in the current operating band and the other
supported band(s), or;
— For generating different PTKs for the current operating band and other supported band(s),
the Authenticator’s Beacon/DMG Beacon/Announce/Probe Response/Information
Response frame’s RSNE and Multi-band element(s), and optionally, additional RSNE and
Multi-band elements that are the Authenticator’s pairwise cipher suite assignments for one
or more involved bands; if group ciphers for the involved bands are negotiated, the Multi-
band GTK KDEs for the involved bands, if dot11MultibandImplemented is true and the
Joint Multi-band RSNA subfield is 1 for both the Authenticator and Supplicant, and either
the Authenticator or the Supplicant uses different MAC addresses for different bands.
— For STK generation Initiator RSNE, Lifetime of SMK is used.
— If the Extended Key ID for Individually Addressed Frames subfield of the RSN
Capabilities field is 1 for both the Authenticator/STA_I and Supplicant/STA_P, then the
Authenticator/STA_I includes the Key ID KDE with the assigned key identifier for the
current operating band; or the Authenticator includes the Multi-band Key ID KDE(s) with
the assigned key identifier(s) for one or more supported bands if
dot11MultibandImplemented is true.
Processing for PTK generation is as follows:
If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is 1 for
both the Authenticator and the Supplicant, then the Authenticator assigns a new Key ID for the PTKSA in
the range 0 to 1 that is different from the Key ID assigned in the previous handshake and uses the MLME-
SETKEYS.request primitive to install the new key to receive individually addressed MPDUs protected by
the PTK with the assigned Key ID. Otherwise Key ID 0 is used and installation of the key is deferred until
after message 4 has been received. The Authenticator sends message 3 to the Supplicant.
NOTE—If an existing PTK is still in effect, the Authenticator IEEE 802.11 MAC continues to transmit protected,
individually addressed MPDUs (if any) using the existing key. With the installation of the new key for receive, the
Authenticator is able to receive protected, individually addressed MPDUs using either the old key (if present) or the new
key.
On reception of message 3, the Supplicant silently discards the message if the Key Replay Counter field
value has already been used or if the ANonce value in message 3 differs from the ANonce value in
message 1. The Supplicant also:
a) Verifies the RSNE. If this message 3 is part of a fast BSS transition initial mobility domain
association or an association started through the FT protocol, the Supplicant verifies that the
PMKR1Name in the PMKID field of the RSNE is identical to the value it sent in message 2 and
verifies that all other fields of the RSNE are identical to the fields in the RSNE present in the Beacon
or Probe Response frames and verifies that the FTE and MDE are the same as in the (Re)Association
Response frame. Otherwise, the Supplicant verifies that the RSNE is identical to that the STA
received in the Beacon or Probe Response frame. If any of these verification steps indicates a
mismatch, the STA shall disassociate or deauthenticate. If a second RSNE is provided in the
message, the Supplicant uses the pairwise cipher suite specified in the second RSNE or
deauthenticates.
b) Verifies the message 3 MIC. If the calculated MIC does not match the MIC that the Authenticator
included in the EAPOL-Key frame, the Supplicant silently discards message 3.
2034
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) Updates the last-seen value of the Key Replay Counter field.
d) If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is
1 for both the Authenticator and Supplicant: Uses the MLME-SETKEYS.request primitive to
configure the IEEE 802.11 MAC to receive individually addressed MPDUs protected by the PTK
with the assigned Key ID.
e) Constructs message 4.
f) Sends message 4 to the Authenticator.
g) Uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to send and, if the
receive key has not yet been installed, to receive individually addressed MPDUs protected by the
PTK. The GTK is also configured by MLME-SETKEYS primitive.
Processing for STK generation is as follows:
If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is set to 1
for both the STA_I and the STA_P, then the Authenticator assigns a new Key ID for the STKSA in the range
0 to 1 that is different from the Key ID assigned in the previous handshake and uses the MLME-
SETKEYS.request primitive to install the new key to receive individually addressed MPDUs protected by
the STK with the assigned Key ID. Otherwise Key ID 0 is used and installation of the key is deferred until
after message 4 has been received. The STA_I sends message 3 to the STA_P.
NOTE—If an existing STK is still in effect, the STA_I IEEE 802.11 MAC continues to transmit protected, individually
addressed MPDUs (if any) using the existing key. With the installation of the new key for receive, the STA_I is able to
receive protected, individually addressed MPDUs using both the old key (if present) or the new key.
On reception of message 3, the STA_P silently discards the message if the Key Replay Counter field value
has already been used or if the INonce value in message 3 differs form the INonce value in message 1.
Otherwise,
a) The STA_P verifies the message 3 MIC using the SKCK in the SMKSA. If the calculated MIC does
not match the MIC that the STA_P included in the EAPOL-Key frame, the STA_I silently discards
message 3.
b) If the MIC is valid, the STA_P checks that the RSNE bitwise matches that from the 4-way
handshake message 2. If these are not exactly the same, STA_P silently discards the message and
deletes existing 4-way handshake states.
c) If they do match, the STA_P constructs message 4. It also compares the Key Lifetime value from
KDE with value in its SMKSA. If value in the SMKSA is less, it discards the value received in
message 3. Otherwise, it updates the value in the SMKSA with value in message 3.
d) If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is
1 for both the Authenticator and Supplicant then prior to sending message 4, STA_P uses the
MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to receive individually
addressed MPDUs protected by the STK with the assigned Key ID.
e) After sending message 4, STA_P uses the MLME-SETKEYS.request primitive to configure the
IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive individually
addressed MPDUs protected by the STK with the assigned Key ID.
12.7.6.5 4-way handshake message 4
Message 4 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0 – same as message 1
2035
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Key Type = 1 (Pairwise) – same as message 1
SMK Message = 0 - same as message 1
Install = 0
Key Ack = 0 – this is the last message
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 0
Reserved = 0 – unused by this protocol version
Key Length = 0
Key Replay Counter = n+1
Key Nonce = 0
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC(KCK, EAPOL) or MIC(SKCK, EAPOL) – MIC computed over the body of this
EAPOL-Key frame with the Key MIC field first initialized to 0
Key Data Length = length of Key Data field in octets
Key Data = none required
Processing for PTK generation is as follows:
The Supplicant sends message 4 to the Authenticator. Note that when the 4-way handshake is first used,
message 4 is sent in the clear.
On reception of message 4, the Authenticator verifies that the Key Replay Counter field value is one that it
used on this 4-way handshake; if it is not, it silently discards the message. Otherwise:
a) The Authenticator checks the MIC. If the calculated MIC does not match the MIC that the
Supplicant included in the EAPOL-Key frame, the Authenticator silently discards message 4.
b) If the MIC is valid, the Authenticator uses the MLME-SETKEYS.request primitive to configure the
IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive protected,
individually addressed MPDUs using for the new PTK.
c) The Authenticator updates the Key Replay Counter field so that it uses a fresh value if a rekey
becomes necessary.
Processing for STK generation is as follows:
The STA_P sends message 4 to the STA_I. On reception of message 4, the STA_I verifies that the Key
Replay Counter field value is one that it used on this 4-way handshake; if it is not, it silently discards the
message. Otherwise,
a) The STA_I checks the MIC. If the calculated MIC does not match the MIC that the STA_P included
in the EAPOL-Key frame, the STA_I silently discards message 4.
b) If the MIC is valid, the STA_I uses the MLME-SETKEYS.request primitive to configure the IEEE
802.11 MAC to send and, if the receive key has not yet been installed, to receive protected,
individually addressed MPDUs using for the new STK.
c) The STA_I updates the Key Replay Counter field so that it uses a fresh value if a rekey becomes
necessary.
2036
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.7.6.6 4-way handshake implementation considerations
When the 4-way handshake is used as part of the STK handshake, the initiator STA acts as Authenticator
and peer STA acts as Supplicant.
If the Authenticator does not receive a reply to its messages, it shall attempt
dot11RSNAConfigPairwiseUpdateCount transmits of the message, plus a final timeout. The retransmit
timeout value shall be 100 ms for the first timeout, half the listen interval for the second timeout, and the
listen interval for subsequent timeouts. If there is no listen interval or the listen interval is zero, then 100 ms
shall be used for all timeout values. If it still has not received a response after these retries, then for PTK
generation the Authenticator should deauthenticate the STA, and for STK generation the STAs should delete
the SMKSA and initiate an STSL application teardown procedure.
For PTK generation, if the STA does not receive message 1 within the expected time interval (prior to IEEE
802.1X timeout), it should disassociate, deauthenticate, and try another AP/STA. For STK generation, if the
peer STA does not receive message 1 or message 3 within the expected time interval (prior to
dot11RSNAConfigSATimeout as specified in 12.7.8), it deletes the SMKSA and invokes an STSL
application teardown procedure.
The Authenticator should ignore EAPOL-Key frames it is not expecting in reply to messages it has sent or
EAPOL-Key frames in which the Ack bit is 1. This stops an attacker from sending the first message to the
Supplicant who responds to the Authenticator.
An implementation should save the KCK and KEK beyond the 4-way handshake, as they are needed for
group key handshakes, STK Rekeying, and recovery from TKIP MIC failures.
The Supplicant uses the MLME-SETKEYS.request primitive to configure the temporal key from 12.7.1 into
its STA after sending message 4 to the Authenticator.
If the RSNE check for message 2 or message 3 fails, the SME should log an error and deauthenticate the
peer.
12.7.6.7 Sample 4-way handshake
The following is an informative sample of a 4-way handshake for illustration.
After IEEE 802.1X authentication completes by the AP sending an EAP-Success, the AP initiates the 4-way
handshake. See Figure 12-46.
The 4-way handshake consists of the following steps:
a) The Authenticator sends an EAPOL-Key frame containing an ANonce.
b) The Supplicant derives a PTK from ANonce and SNonce.
c) The Supplicant sends an EAPOL-Key frame containing SNonce, the RSNE from the
(Re)Association Request frame, and a MIC.
d) The Authenticator derives PTK from ANonce and SNonce and validates the MIC in the EAPOL-
Key frame.
e) The Authenticator sends an EAPOL-Key frame containing ANonce, the RSNE from its Beacon or
Probe Response frames, the MIC, the GTK, an indication of whether to install the temporal keys,
and if management frame protection is negotiated, the IGTK.
f) The Supplicant sends an EAPOL-Key frame to confirm whether the temporal keys were installed.
2037
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IEEE Std 802.11 Station
IEEE Std 802.11Access Point
IEEE Std 802.1X Supplicant
IEEE Std 802.1X Authenticator
SNonce = Random ANonce = Random
Calculate PTK using ANonce and
SNonce
EAPOL-Key (0, 1, 0, 0, P, 0, 0, SNonce, MIC, RSNE)
Calculate PTK using ANonce and SNonce
EAPOL-Key (1, 1, 0, 0, P, 0, 0,0, MIC, 0)
Set Temporal Encryption Key and (TKIP Set Temporal Encryption Key and (TKIP only)
only) MIC Key MIC Key
Set GTK for KeyIDGTK, IGTK for KeyIDIGTK
Figure 12-46—Sample 4-way handshake
12.7.6.8 4-way handshake analysis
The following is an informative analysis of the 4-way handshake.
This subclause makes the trust assumptions used in this protocol explicit. The protocol assumes the
following:
— The PMK is known only by the Supplicant’s STA and the Authenticator’s STA.
— The Supplicant’s STA uses IEEE 802 address SPA.
— The Authenticator’s STA uses IEEE 802 address AA.
In many instantiations the RSNA architecture immediately breaks the first assumption because the IEEE
802.1X AS also knows the PMK. Therefore, additional assumptions are required:
— The AS does not expose the PMK to other parties.
— The AS does not masquerade as the Supplicant to the Authenticator.
— The AS does not masquerade as the Authenticator to the Supplicant.
— The AS does not masquerade as the Supplicant’s STA.
— The AS does not masquerade as the Authenticator’s STA.
The protocol also assumes this particular Supplicant-Authenticator pair is authorized to know this PMK and
to use it in the 4-way handshake. If any of these assumptions are broken, then the protocol fails to provide
any security guarantees.
The protocol also assumes that the AS delivers the correct PMK to the AP with IEEE 802 address AA and
that the STA with IEEE 802 address SPA hosts the Supplicant that negotiated the PMK with the AS. None
2038
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
of the protocols defined by this standard and IEEE Std 802.1X-2010 permit the AS, the Authenticator, the
Supplicant, or either STA to verify these assumptions.
The PTK derivation step
PTK PRF-Length(PMK, “Pairwise key expansion”, Min(AA,SPA) || Max(AA,SPA) ||
Min(ANonce,SNonce) || Max(ANonce,SNonce))
performs a number of functions:
— Including the AA and SPA in the computation
— Binds the PTK to the communicating STAs and
— Prevents undetected man-in-the-middle attacks against 4-way handshake messages between
the STAs with these two IEEE 802 addresses.
— If ANonce is randomly selected, including ANonce
— Guarantees the STA at IEEE 802 address AA that PTK is fresh,
— Guarantees that message 2 and message 4 are live, and
— Uniquely identifies PTK as .
— If SNonce is randomly selected, including SNonce
— Guarantees the STA at IEEE 802 address SPA that PTK is fresh,
— Guarantees that message 3 is live, and
— Uniquely identifies PTK as .
Choosing the nonces randomly helps prevent precomputation attacks. With unpredictable nonces, a man-in-
the-middle attack that uses the Supplicant to precompute messages to attack the Authenticator cannot
progress beyond message 2, and a similar attack against the Supplicant cannot progress beyond message 3.
The protocol might execute further before an error if predictable nonces are used.
Message 1 delivers ANonce to the Supplicant and initiates negotiation for a new PTK. It identifies AA as the
peer STA to the Supplicant’s STA. If an adversary modifies either of the addresses or ANonce, the
Authenticator detects the result when validating the MIC in message 2. Message 1 does not carry a MIC, as
it is impossible for the Supplicant to distinguish this message from a replay without maintaining state of all
security associations through all time (PMK might be a static key).
Message 2 delivers SNonce to the Authenticator so it can derive the PTK. If the Authenticator selected
ANonce randomly, message 2 also demonstrates to the Authenticator that the Supplicant is live, that the
PTK is fresh, and that there is no man-in-the-middle attack, as the PTK includes the IEEE 802 MAC
addresses of both. Inclusion of ANonce in the PTK derivation also protects against replay. The MIC
prevents undetected modification of message 2 contents.
Message 3 confirms to the Supplicant that there is no man-in-the-middle attack. If the Supplicant selected
SNonce randomly, it also demonstrates that the PTK is fresh and that the Authenticator is live. The MIC
again prevents undetected modification of message 3.
While message 4 serves no cryptographic purpose, it serves as an acknowledgment to message 3. It is
required to inform the Authenticator that the Supplicant has installed the PTK and GTK and hence can
receive encrypted frames.
The PTK and GTK are installed by using MLME-SETKEYS.request primitive after message 4 is sent. The
PTK is installed before the GTK.
2039
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Then the 4-way handshake uses a correct, but unusual, mechanism to guard against replay. As noted earlier
in this subclause, ANonce provides replay protection to the Authenticator, and SNonce to the Supplicant. In
most session initiation protocols, replay protection is accomplished explicitly by selecting a nonce randomly
and requiring the peer to reflect the received nonce in a response message. The 4-way handshake instead
mixes ANonce and SNonce into the PTK, and replays are detected implicitly by MIC failures. In particular,
the Key Replay Counter field serves no cryptographic purpose in the 4-way handshake. Its presence is not
detrimental, however, and it plays a useful role as a minor performance optimization for processing stale
instances of message 2. This replay mechanism is correct, but its implicit nature makes the protocol harder
to understand than an explicit approach.
It is critical to the correctness of the 4-way handshake that at least one bit differs in each message. Within
the 4-way handshake, message 1 can be recognized as the only one in which the Key MIC bit is 0, meaning
message 1 does not include the MIC, while message 2 to message 4 do. Message 3 differs from message 2
by not asserting the Ack bit and from message 4 by asserting the Ack Bit. Message 2 differs from message 4
by including the RSNE.
Request messages are distinct from 4-way handshake messages because the former asserts the Request bit
and 4-way handshake messages do not. Group key handshake messages are distinct from 4-way handshake
messages because they assert a different key type.
12.7.7 Group key handshake
12.7.7.1 General
The Authenticator uses the Group key handshake to send a new GTK and, if management frame protection
is negotiated, a new IGTK to the Supplicant.
The Authenticator may initiate the exchange when a Supplicant is disassociated or deauthenticated.
Message 1: Authenticator Supplicant:
EAPOL-Key(1,1,1,0,G,0,Key RSC,0, MIC,GTK[N],IGTK[M])
Message 2: Supplicant Authenticator: EAPOL-Key(1,1,0,0,G,0,0,0,MIC,0)
Here, the following assumptions apply:
— Key RSC denotes the last TSC or PN sent using the GTK.
— GTK[N] denotes the GTK with its key identifier as defined in 12.7.2 using the KEK defined in
12.7.1.3 and associated IV.
— IGTK[M], when present, denotes the IGTK with its key identifier as defined in 12.7.2 using the
KEK defined in 12.7.1.3 and associated IV.
— The MIC is computed over the body of the EAPOL-Key frame (with the MIC field zeroed for the
computation) using the KCK defined in 12.7.1.3.
The Supplicant may trigger a group key handshake by sending an EAPOL-Key frame with the Request bit
set to 1 and the type of the Group Key bit.
An Authenticator shall do a 4-way handshake before a group key handshake if both are required to be done.
NOTE—The Authenticator cannot initiate the group key handshake until the 4-way handshake completes successfully.
2040
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.7.7.2 Group key handshake message 1
Message 1 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0
Key Type = 0 (Group/SMK)
SMK Message = 0
Install = 0
Key Ack = 1
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 1
Reserved = 0
Key Length = 0
Key Replay Counter = n+2
Key Nonce = 0
EAPOL-Key IV = 0 (Version 2) or random (Version 1)
Key RSC = last TSC or PN for the GTK
Key MIC = MIC(KCK, EAPOL)
Key Data Length = Cipher-suite-specific; see Table 12-4
Key Data = encrypted, encapsulated
— GTK and the GTK’s key identifier (see 12.7.2)
— When present, IGTK, IGTK’s key identifier, and IPN (see 12.7.2)
The Authenticator sends message 1 to the Supplicant.
On reception of message 1, the Supplicant:
a) Verifies that the Key Replay Counter field value has not yet been seen before, i.e., its value is
strictly larger than that in any other EAPOL-Key frame received thus far during this session.
b) Verifies that the MIC is valid, i.e., it uses the KCK that is part of the PTK to verify that there is no
data integrity error.
c) Uses the MLME-SETKEYS.request primitive to configure the temporal GTK and, when present,
IGTK into its IEEE 802.11 MAC.
d) Responds by creating and sending message 2 of the group key handshake to the Authenticator and
incrementing the replay counter.
NOTE—The Authenticator increments and uses a new Key Replay Counter field value on every message 1 instance,
even retries, because the message 2 responding to an earlier message 1 might have been lost. If the Authenticator did not
increment the replay counter, the Supplicant discards the retry, and no responding message 2 ever arrives.
2041
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.7.7.3 Group key handshake message 2
Message 2 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0 – same as message 1
Key Type = 0 (Group/SMK) – same as message 1
Install = 0
Key Ack = 0
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 0
Reserved = 0
Key Length = 0
Key Replay Counter = n+2 – same as message 1
Key Nonce = 0
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC(KCK, EAPOL)
Key Data Length = 0
Key Data = none required
On reception of message 2, the Authenticator:
a) Verifies that the Key Replay Counter field value matches one it has used in the group key
handshake.
b) Verifies that the MIC is valid, i.e., it uses the KCK that is part of the PTK to verify that there is no
data integrity error.
12.7.7.4 Group key handshake implementation considerations
If the Authenticator does not receive a reply to its messages, its shall attempt
dot11RSNAConfigGroupUpdateCount transmits of the message, plus a final timeout. The retransmit
timeout value shall be 100 ms for the first timeout, half the listen interval for the second timeout, and the
listen interval for subsequent timeouts. If there is no listen interval or the listen interval is zero, then 100 ms
shall be used for all timeout values. If it still has not received a response after this, then the Authenticator’s
STA should use the MLME-DEAUTHENTICATE.request primitive to deauthenticate the STA.
12.7.7.5 Sample group key handshake
The following is an informative sample of a group key handshake for illustration.
The state machines in 12.7.10 and 12.7.11 change the GTK and, when present, IGTK in use by the network.
See Figure 12-47.
2042
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IEEE Std 802.11 Station IEEE Std 802.11Access Point
IEEE Std 802.1X Supplicant IEEE Std 802.1X Authenticator
Gnonce = Get Next
Key Counter
EAPOL-Key( 1,1,1,0,GNonce,0, KeyRSC, 0, MIC, GTK[KeyIDGTK], IGTK[KeyIDIGTK])
Decrypt GTK and set KeyIDGTK
Decrypt IGTK and set KeyIDIGTK
EAPOL-Key( 1,1,0,0,GNonce,0, 0, 0, MIC,0)
Set GTK in KeyIDGTK
Set IGTK in KeyIDIGTK
Figure 12-47—Sample group key handshake
The following steps occur:
a) The Authenticator generates a new GTK and when management frame protection has been
negotiated, a new IGTK. It encapsulates the GTK and, as necessary, the IGTK, and sends an
EAPOL-Key frame containing the GTK and IGTK (message 1), along with the last TSC or PN used
with the GTK (RSC) and the last IPN used with the IGTK.
b) On receiving the EAPOL-Key frame, the Supplicant validates the MIC, decapsulates the GTK and,
when present, the IGTK, and uses the MLME-SETKEYS.request primitive to configure the GTK,
PN, IGTK, RSC, and IPN in its STA.
c) The Supplicant then constructs and sends an EAPOL-Key frame in acknowledgment to the
Authenticator.
d) On receiving the EAPOL-Key frame, the Authenticator validates the MIC. If the GTK and, if
present, the IGTK are is not already configured into IEEE 802.11 MAC, after the Authenticator has
delivered the GTK and IGTK to all associated STAs, it uses the MLME-SETKEYS.request
primitive to configure the GTK and IGTK.
12.7.8 PeerKey handshake
12.7.8.1 General
The PeerKey handshake occurs after any other STSL setup procedures and is used to create an STKSA
providing data confidentiality between the two STAs. The AP establishes an RSNA with each STA prior to
PeerKey setup. The initiator STA starts the PeerKey handshake, at the conclusion of which a key is
established to secure the connection.
STSL security PeerKey handshake is used to establish security for Data frames passed directly between two
STAs associated with the same AP. The AP establishes an RSNA with each STA prior to the PeerKey
handshake. After the STAs establish the STSL, the initiator STA starts the PeerKey handshake, at the
conclusion of which a key is established to secure the connection. The PeerKey handshake is used to create
an STKSA between the two STAs.
The PeerKey EAPOL-Key exchange provides a mechanism for obtaining the keys to be used for direct
station-to-station communication. The initiator STA shall start a timer when it sends the first EAPOL-Key
2043
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
frame, and the peer STA shall do the same on receipt of the first EAPOL-Key frame. On expiration of this
timer, the STA shall transition to the STKINIT state.
A STA should use the PeerKey handshake prior to transferring any direct station-to-station Data frames. The
STKSA should be deleted when the station-to-station connection is terminated.
Here, the following assumptions apply:
— EAPOL-Key() denotes an EAPOL-Key frame conveying the specified argument list, using the
notation introduced in 12.7.4.
— STA_I is the initiator STA.
— STA_P is the peer STA.
— AP is the access point with which both the STA_I and the STA_P are associated.
— MAC_I is the MAC address of the STA_I.
— MAC_P is the MAC address of the STA_I.
— INonce is the nonce generated by the STA_I.
— PNonce is the nonce generated by the STA_P.
The PeerKey handshake has two components:
a) SMK handshake: This handshake is initiated by the initiator STA, and as a result of this handshake,
the SMKSA is installed in both the STAs. This message exchange goes through the AP and is
protected using the PTK.
b) 4-way STK handshake: Using the installed SMKSA, the initiator STA initiates the 4-way
handshake (per 12.7.6), and as a result of this, the STKSA gets installed in both the STAs. The
STKSA is used for securing data exchange between the initiator STA and the peer STA. The 4-way
handshake analysis described in 12.7.6.8 applies to the 4-way STK handshake.
12.7.8.2 SMK handshake
12.7.8.2.1 General
The initiator STA initiates the SMK handshake by sending the first message to the AP to establish an
SMKSA between itself and another STA associated with the same AP. Unlike the 4-way handshake and the
group key handshake, the SMK handshake is initiated by the initiator STA.
Message 1: Initiator STA AP: EAPOL-Key(1,1,0,0,0,1,0, INonce, MIC, RSNE_I, MAC_P
KDE)
Message 2: AP Peer STA: EAPOL-Key(1,1,1,0,0,1,0, INonce, MIC, RSNE_I, MAC_I KDE)
Message 3: Peer STA AP: EAPOL-Key(1,1,0,0,0,1,0, PNonce, MIC, RSNE_P, MAC_I KDE,
Initiator Nonce KDE)
Message 4: AP Peer STA: EAPOL-Key(1,1,0,1,0,1,0, PNonce, MIC, MAC_I KDE, Initiator
Nonce KDE, SMK KDE, Lifetime KDE)
Message 5: AP Initiator STA: EAPOL-Key(1,1,0,0,0,1,0, INonce, MIC, RSNE_P, MAC_P
KDE, Peer Nonce KDE, SMK KDE, Lifetime KDE)
12.7.8.2.2 SMK handshake message 1
The initiator STA creates the RSNE (see 9.4.2.25) by including the Element ID, length, version, and
pairwise cipher suite list fields. Since the group cipher suit field is before the pairwise cipher suite list field
(so the STA needs to include it), the STA includes any value in this field, and the receiving STA ignores it.
The initiator STA also generates a 256-bit random number following the recommendations of 12.7.5. That
number is sent in the Key Nonce field.
2044
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Message 1 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all
other cases 0
Key Type = 0 (Group/SMK)
SMK Message = 1 (SMK)
Install = 0
Key Ack = 0
Key MIC = 1
Secure = 1
Error = 0
Request = 1
Encrypted Key Data = 0
Reserved = 0
Key Length = 0
Key Replay Counter = request EAPOL replay counter of initiating STA
Key Nonce = INonce
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC (initiating STA’s KCK, EAPOL)
Key Data Length = Length of Key Data field in octets
Key Data = Initiator RSNE, peer MAC address KDE
The STA_I sends message 1 to the AP.
On receipt of message 1, the AP checks that the key replay counter corresponds to message 1. If not, it
silently discards the message. Otherwise:
a) The AP verifies the message 1 MIC using the STA_I PTKSA. If the calculated MIC does not match
the MIC that the STA_I included in the EAPOL-Key frame, the AP silently discards message 1.
b) If the MIC is correct, the AP checks if the STA_P is reachable. If it is not reachable, the AP shall
send an error EAPOL-Key frame to STA_I per 12.7.8.5.2. After sending the message, AP silently
discards message 1.
c) The AP checks if the AP has a secure connection with STA_P. If not, the AP shall send an error
EAPOL-Key frame to STA_I per 12.7.8.5.3. After sending the message, AP silently discards
message 1.
d) If all checks succeed, the AP creates message 2 using the STA_P PTKSA. The AP copies the
contents of message 1 to create message 2.
12.7.8.2.3 SMK handshake message 2
Message 2 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
2045
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all
other cases 0
Key Type = 0 (Group/SMK)
SMK Message = 1 (SMK)
Install = 0
Key Ack = 1
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 0
Reserved = 0
Key Length = 0
Key Replay Counter = request EAPOL replay counter of AP and STA_P
Key Nonce = INonce
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC (KCK of the STA_P, EAPOL)
Key Data Length = Length of Key Data field in octets
Key Data = Initiator RSNE, initiator MAC address KDE
The AP sends message 2 to the STA_P. On receipt of message 2, the STA_P checks that the key replay
counter corresponds to message 2. If not, it silently discards the message. Otherwise,
a) The STA_P verifies the message 2 MIC using the STA_P PTKSA. If the calculated MIC does not
match the MIC that the AP included in the EAPOL-Key frame, the STA_P silently discards message
2.
b) If the MIC is correct, the STA_P checks if it supports at least one cipher suites proposed by the
STA_I. If it does not, the STA_P shall send an error EAPOL-Key frame to STA_I through the AP
per 12.7.8.5.4. After sending the error message, the STA_P silently discards message 2.
c) STA_O checks if it has already created an STSL with STA_I. If it has not, STA_P shall send an
error EAPOL-Key frame to STA_I through the AP per 12.7.8.5.5. After sending the error message,
the STA_P silently discards message 2.
d) If all checks succeed, the STA_P creates the state of PeerKey handshake and stores the INonce and
the RSNE received in message 2.
e) STA_P selects a support cipher suite from the cipher suite list proposed by the STA_I and creates
the peer RSNE, which is sent with message 3.
f) STA_P generates a 256-bit random number following the recommendations of 12.7.5. That number
is sent as the peer Nonce KDE with message 3.
g) Using all the information, STA_P creates message 3.
12.7.8.2.4 SMK handshake message 3
Message 3 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
2046
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all
other cases 0
Key Type = 0 (Group/SMK)
SMK Message = 1 (SMK)
Install = 0
Key Ack = 0
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 0
Reserved = 0
Key Length = 0
Key Replay Counter = request EAPOL replay counter of peer STA
Key Nonce = PNonce
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC (KCK of STA_I, EAPOL)
Key Data Length = Length of Key Data field in octets
Key Data = Peer RSNE, initiator MAC address KDE, initiator Nonce KDE
The STA_P sends message 3 to the AP. On receipt of message 3, the AP checks that the key replay counter
corresponds to message 3. If not, it silently discards the message. Otherwise,
a) The AP verifies the message 1 MIC using the STA_I PTKSA. If the calculated MIC does not match
the MIC that the STA_P included in the EAPOL-Key frame, the AP silently discards message 1.
b) If MIC is correct, the AP checks if the STA_I is reachable. If it is not reachable, the AP shall send an
error EAPOL-Key frame to the STA_P per 12.7.8.5.2. After sending the message, the AP silently
discards message 3.
c) The AP checks if the AP has secure connection with STA_I. If it does not, the AP shall send an error
EAPOL-Key frame to STA_P per 12.7.8.5.3. After sending the message, the AP silently discards
message 3.
d) If all checks succeed, the AP generates a 256-bit random number drawn from a uniform distribution
that is used as the SMK, which is sent with message 4 and message 5 as SMK KDEs.
e) Depending on the strength of random number generator, the AP sets the lifetime of the SMK, which
is sent with message 4 and message 5 as Lifetime KDEs.
f) Using all the information, the AP creates message 4 and message 5.
12.7.8.2.5 SMK handshake message 4
Message 4 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all
other cases 0
Key Type = 0 (Group/SMK)
2047
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SMK Message = 1 (SMK)
Install = 1
Key Ack = 0
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 1
Reserved = 0
Key Length = Cipher-suite-specific; see Table 12-4
Key Replay Counter = request EAPOL replay counter of AP
Key Nonce = PNonce
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC (KCK of the STA_I, EAPOL)
Key Data Length = Length of Key Data field in octets
Key Data = Encrypted initiator MAC address KDE, Initiator Nonce KDE, SMK KDE (contains
SMK and PNonce), Lifetime KDE
The AP sends message 4 to the STA_P. On receipt of message 4, the STA_P checks that the key replay
counter corresponds to message 4. If it does not, STA_P silently discards the message. Otherwise,
a) The STA_P verifies the message 4 MIC using STA_P PTKSA. If the calculated MIC does not match
the MIC that the AP included in the EAPOL-Key frame, the STA_P silently discards message 4.
b) If the MIC is correct, STA_P identifies the PeerKey session using the PNonce sent as part of the Key
Nonce field of message 4. If STA_P has an existing PeerKey state for this session, i.e., STA_P has
received message 2 and this message is a follow-up to that. If STA_P has an existing PeerKey state
for this session, STA_P silently discards message 4.
c) If all checks succeed, STA_P decrypts the Key Data field of message 4 and extracts the MAC_I, the
INonce, the PNonce, the SMK, and the lifetime from message 4. The STA_P verifies the extracted
INonce against the INonce originally received as part of message 2.
d) The STA_P calculates the SMKID per 12.7.1.6.
e) The STA_P checks the value of the lifetime with the maximum value it can support. If the lifetime
suggested by the AP is too long, the STA_P selects a lower value that it can support.
f) Using all the information, the STA_P creates the SMKSA for this PeerKey session.
12.7.8.2.6 SMK handshake message 5
Message 5 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all
other cases 0
Key Type = 0 (Group/SMK)
SMK Message = 1 (SMK)
Install = 0
2048
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Key Ack = 0
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 1
Reserved = 0
Key Length = Cipher-suite-specific; see Table 12-4
Key Replay Counter = request EAPOL replay counter of AP
Key Nonce = INonce
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC (KCK of the STA_I, EAPOL)
Key Data Length = Length of Key Data field in octets
Key Data = Encrypted peer RSNE, peer MAC address KDE, peer Nonce KDE, SMK KDE (contains
SMK and INonce), Lifetime KDE
The AP sends message 5 to the STA_I. On receipt of message 5, the STA_I checks that the key replay
counter corresponds to message 5. If it does not, the STA_I silently discards the message. Otherwise,
a) STA_I verifies the message 4 MIC using STA P PTKSA. If the calculated MIC does not match the
MIC that the AP included in the EAPOL-Key frame, the STA_I silently discards message 5.
b) If the MIC is correct, the STA_I identifies the PeerKey session using the INonce sent as part of the
Key Nonce field of message 5. If STA_I has an existing PeerKey state for this session, i.e., STA_I
has initiated this message exchange using message 1 and this message is a follow-up to that. If
STA_I has an existing PeerKey state for this session, STA_I shall silently discard message 5.
c) If all checks succeed, STA_I decrypts the Key Data field of message 5 and extracts the peer RSNE,
the MAC_P, the INonce, the PNonce, the SMK, and the lifetime from message 5.
d) The STA_I verifies that the peer RSNE includes a valid cipher (i.e., one that was included in an
initiator RSNE). If not, STA_I discards the message and sends an Error KDE ERR_CPHR_NS.
e) The STA_I calculates SMKID per 12.7.1.6.
f) The STA_I checks the value of the lifetime with the maximum value it can support. If the lifetime
suggested by the AP is too long, STA_I selects a lower value that can support.
g) Using all the information, the STA_I creates the SMKSA for this PeerKey session.
12.7.8.3 PeerKey setup and handshake error conditions
If the STA_P does not receive a valid SMK message 2 or a 4-way STK message 1 after sending the EAPOL-
Key request frame to initiate the PeerKey rekey within a 200 ms timeout, the STA_P shall invoke an STSL
application teardown procedure.
If the STA_I does not receive an SMK message 5 from the AP, the STA_I shall attempt
dot11RSNAConfigSMKUpdateCount transmits of the SMK handshake message 1 plus a final timeout. If
the STA_I still has not received a response after these retries, it shall invoke an STSL application teardown
procedure. The retransmit timeout value shall be 200 ms for the first timeout, the listen interval for the
second timeout, and twice the listen interval for subsequent timeouts. If there is no listen interval or the
listen interval is zero, then 200 ms shall be used for all timeout values.
2049
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
There is no specific recovery mechanism at the AP if the SMK message 3 is dropped. This results in a
timeout by the STA_I after nonreceipt of SMK message 5, as described in the preceding paragraph.
If the SMK message 4 is not received by the STA_P, a failure is detected during the 4-way STK handshake.
In this case, the STA_P discards the EAPOL-Key frames without the proper key. This failure is covered by
behavior described in 12.7.6.6 and results in teardown of the STSL.
Upon receipt of the SMK message 5, the STA_I transmits message 1 of the 4-way STK handshake to the
STA_P. If the STA_I does not receive message 2 of the 4-way STK handshake from the STA_P, it shall
attempt dot11RSNAConfigSMKUpdateCount transmits of 4-way STK handshake message 1, plus a final
timeout. If STA_I still has not received a response after these retries, it shall invoke an STSL application
teardown procedure. The retransmit timeout value shall be 100 ms for the first timeout, half the listen
interval for the second timeout, and the listen interval for subsequent timeouts. If there is no listen interval or
the listen interval is zero, then 100 ms shall be used for all timeout values.
There is no specific recovery mechanism at the STA_P if the SMK message 3 is lost. This results in a
timeout on the STA_I, as described in the preceding paragraph, and a subsequent reinitiation of the
SMK handshake. The STA_P shall allow reinitiation of the SMK handshake at any point prior to receipt of
SMK message 4.
12.7.8.4 STKSA rekeying
Rekeying is always initiated by the STA_I. When needed, the STA_P sends an EAPOL-Key request frame
to the STA_I to request rekeying. The STA_P shall wait a minimum of one half the IEEE 802.1X timeout
after the STSL setup before initiating a PeerKey rekey procedure. To perform rekeying, there are two cases:
a) If SMK timer has not expired, the STAs initiate a 4-way handshake to create a new STK. The 4-way
handshake is always initiated by the STA_I. In this case, the STA_P should not delete any existing
STKSA prior to verifying message 3 of the 4-way handshake with STA_I for this session.
b) If the SMK has expired, the STA_I shall not use an existing STKSA and shall start the SMK
handshake followed by a 4-way handshake to create new keys.
The format of the EAPOL-Key request frame in case a) from STA_P to STA_I is as follows:
Request message: STA_P STA_I: EAPOL-Key(1,1,0,0,1,0,0,0, MIC, PMKID KDE)
The request message uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all
other cases 0
Key Type = 1 (PTK)
SMK Message = 0
Install = 0
Key Ack = 0
Key MIC = 1
Secure = 1
Error = 0
Request = 1
Encrypted Key Data = 0
2050
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Reserved = 0
Key Length = 0
Key Replay Counter = request replay counter of peer STA
Key Nonce = 0
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC computed over the body of this EAPOL-Key frame
Key Data Length = Length of Key Data field in octets
Key Data = SMKID in SMKID KDE
12.7.8.5 Error reporting
12.7.8.5.1 General
Error reporting messages are defined in this subclause and used to report errors whenever STAs or an AP
detect an error during the SMK handshake.
The AP, upon receiving the error messages defined in this subclause or upon generating the error messages
defined in this subclause, should log the error. The STA, upon receipt of the error messages defined in this
subclause, shall tear down the STSL with the other STA and clear all of the PeerKey states.
The format of EAPOL-Key request frame for reporting an error message is as follows:
Error message: EAPOL-Key(1,1,0,0,0,1,0, 0, MIC, Error KDE, MAC Address KDE).
The request message uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 12.7.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0
Key Type = 0 (Group/SMK)
SMK Message = 1 (SMK)
Install = 0
Key Ack = 0
Key MIC = 1
Secure = 1
Error = 1
Request = 1 when the message is going from the STA to an AP or 0 when the message is going
from an AP to the STA
Encrypted Key Data = 0
Reserved = 0
Key Length = 0
Key Replay Counter = request EAPOL replay counter
Key Nonce = 0
EAPOL-Key IV = 0
Key RSC = 0
2051
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Key MIC = MIC computed over the body of this EAPOL-Key frame
Key Data Length = Length of Key Data field in octets
Key Data = Error KDE (different types defined in Table 12-7), MAC Address KDE
12.7.8.5.2 Error ERR_STA_NR
This error message is sent whenever an AP finds that the STA to which it needs to send a message is not
reachable. In response to this error, the AP creates an Error KDE with error type ERR_STA_NR and sends
the message back to the other STA involved in the handshake. The MAC address KDE contains the MAC
address of the unreachable STA.
12.7.8.5.3 Error ERR_STA_NRSN
This error message is sent whenever the AP finds that the STA to which it needs to send the message does
not have a secure RSNA connection. In response of this error, the AP creates an Error KDE with error type
ERR_STA_NRSN and sends the message back to the STA from which it received the last message. The
MAC address KDE contains the MAC address of the STA with which the AP does not have a secure RSNA
connection.
12.7.8.5.4 Error ERR_CPHR_NS
This error message is sent whenever a STA finds that it does not support any of the cipher suites proposed by
the other STA. In response to this error, the STA creates an Error KDE with error type ERR_CPHR_NS and
sends the message back to the other STA. The MAC address KDE contains the MAC address of the other
STA.
12.7.8.5.5 Error ERR_NO_STSL
This error message is sent whenever a STA finds that it does not have an existing STSL with the other STA.
In response of this error, the STA creates an Error KDE with error type ERR_NO_STSL and sends the
message back to the other STA. The MAC address KDE contains the MAC address of the other STA.
12.7.9 TDLS PeerKey (TPK) security protocol
12.7.9.1 General
The TPK security protocol is executed between the two non-AP STAs that intend to establish an RSNA for
direct-link communication. If any security method (pre-RSNA or RSNA) is enabled on the connection
between a STA and the AP, the STA shall require that the TPK security protocol complete successfully
before using a direct link. If no security method is enabled on the connection between a STA and the AP, the
STA shall not use the TPK security protocol on the direct link. A STA may refuse to set up a TDLS link
when the protection on the STA link to the AP is secured with a weak algorithm or when the link between
the STA and the AP is not using any security.
12.7.9.2 TPK handshake
The TPK handshake occurs as part of the TDLS direct-link setup procedure. The TPKSA is the result of the
successful completion of the TPK handshake protocol, which derives keys for providing confidentiality and
data origin authentication.
In order to maintain TPK confidentiality, both the TDLS initiator STA and the TDLS responder STAs
establish an RSNA with their common AP prior to executing the TPK handshake. To meet this criterion, a
STA may refuse to initiate the TDLS direct link if:
2052
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) The AP does not include an RSNE in its Beacon and Probe Response frames to advertise the
availability of security;
b) The AP’s RSNE indicates that WEP-40 (OUI 00-0F-AC:1) or WEP-104 (OUI 00-0F-AC:5) are
enabled as either pairwise or group cipher suites; or
c) The AP’s RSNE indicates that Use group cipher suite (00-0F-AC:0) is used as the pairwise cipher
suite.
Violation of any of these cases would cause the TPK handshake to leak the TPK.
The TDLS initiator STA and the TDLS responder STA perform the following exchange to set up a TPK:
TDLS PMK handshake message 1: TDLS initiator STA TDLS responder STA:
Link Identifier element, RSNE, Timeout Interval element, FTE
TDLS PMK handshake message 2: TDLS responder STA TDLS initiator STA:
Link Identifier element, RSNE, Timeout Interval element, FTE
TDLS PMK handshake message 3: TDLS initiator STA TDLS responder STA:
Link Identifier element, RSNE, Timeout Interval element, FTE
where
The TDLS initiator STA Address field of the Link Identifier element is the MAC address of the TDLS ini-
tiator STA
The TDLS responder STA Address field of the Link Identifier element is the MAC address of the TDLS
responder STA
The PairwiseCipherSuite field of the RSNE identifies the cipher suite used to protect the Data frames sent
over the direct link
The AKM suite list of the RSNE identifies which Authentication Method was used
The TimeoutIntervalType field of the Timeout Interval element is the key lifetime
The SNonce field of the FTE is a 256 bit value randomly generated by the TDLS initiator STA
The ANonce field of the FTE is a 256 bit value randomly generated by the TDLS responder STA (set to 0
in message 1)
The MIC field of the FTE is 0 for message 1 and computed as described in 12.7.9.4.3 and 12.7.9.4.4 for
messages 2 and 3 respectively
The TDLS PMK handshake message 1 shall be transmitted in the TDLS Setup Request frame.
TDLS PMK handshake message 2 shall be transmitted in the TDLS Setup Response frame.
TDLS PMK handshake message 3 shall be transmitted in the TDLS Setup Confirm frame.
The TPK shall be derived as follows:
TPK-Key-Input = Hash(min (SNonce, ANonce) || max (SNonce, ANonce))
TPK = KDF-Hash-Length(TPK-Key-Input, "TDLS PMK", min (MAC_I, MAC_R)
|| max (MAC_I, MAC_R) || BSSID)
where
Hash is the hash algorithm identified by the negotiated AKM suite selector specified in Table 9-133
KDF-Hash-Length is the key derivation function defined in 12.7.1.7.2 that uses Hash to generate a key
whose length is TK_bits + 128
TK_bits is cipher-suite specific and specified in Table 12-4
2053
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAC_I and MAC_R are the MAC addresses of the TDLS initiator STA and the TDLS responder STA,
respectively
SNonce and ANonce are the nonces generated by the TDLS initiator STA and TDLS responder STA,
respectively, for this instance of the TPK handshake. The BSSID is set to the BSSID of the
current association of the TDLS initiator STA.
Each TPK has two component keys—TPK-KCK and TPK-TK, defined as follows:
The Key Confirmation Key (KCK) shall be computed as the first 128 bits (bits 0–127) of the TPK
TPK-KCK = L(TPK, 0, 128)
The KCK is used to provide data origin authenticity in TDLS Setup Response and TDLS Setup Confirm
frames.
The temporal key (TK) shall be computed as the remaining bits (for CCMP-128, the second 128 bits, i.e.,
bits 128–255) of the TPK
TPK-TK = L(TPK, 128, Length – 128)
The TPK-TK is used to provide confidentiality for direct-link data.
The temporal key is configured into the STA by the SME through the use of the MLME-SETKEYS.request
primitive.
12.7.9.3 TPK handshake security assumptions
The security of the TDLS PMK handshake depends on the following:
a) The TDLS initiator STA and the TDLS peer STA each have an RSNA established with the AP that
is being used for TDLS Setup.
b) The AP does not expose the nonces exchanged by the TDLS initiator STA and the TDLS responder
STA to any external party.
c) The AP does not use these nonces to derive the TPK and attack the TDLS direct-link instance.
d) TDLS message security (encryption and integrity computations) processing at the AP is protected
from illegal eavesdropping, alterations, insertions and substitutions.
e) The TDLS initiator STA and TDLS responder STAs do not expose SNonce, ANonce, or the derived
key to a third party.
f) The TDLS initiator STA and the TDLS peer STA are associated to the same AP.
12.7.9.4 TPK Security Protocol handshake messages
12.7.9.4.1 Overview
The TPK handshake consists of three messages. Each message comprises a number of elements and is
included in the TDLS Setup Request, TDLS Setup Response, and TDLS Setup Confirm.
In an RSN, these handshake messages serve to provide a session identifier, are identified by the nonces, and
are used as association instance identifiers. These nonces are chosen randomly or pseudorandomly, and are
used to generate the TPK.
2054
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.7.9.4.2 TPK handshake message 1
If the TDLS initiator STA has security enabled on the link with the AP, it shall add an RSNE, FTE, and
Timeout Interval element to its TDLS Setup Request frame. The elements shall be formatted as follows:
The RSNE, if present, shall be set as follows:
Version shall be set to 1.
The pairwise cipher suite list field indicating the pairwise cipher suites the TDLS initiator STA
is willing to use with the TPKSA. WEP-40, WEP-104, and TKIP shall not be included in this
list.
The group cipher suite shall be set to 00-0F-AC:7.
The AKM suite count field shall be set to 1.
The AKM suite list field shall be set to indicate TPK handshake (00-0F-AC:7).
In the RSN Capabilities field, the No Pairwise subfield shall be set to 0 and the PeerKey
Enabled subfield shall be set to 1.
PMKID Count subfield, if present, shall be set to 0.
PMKID list shall not be present.
The Group Management Cipher Suite subfield, if present, shall be set to 00-0F-AC:7.
The Timeout Interval element indicates the lifetime of the TPKSA. The Lifetime Interval Type shall
be set to ‘2’ (Key Lifetime Interval). The minimum lifetime shall be 300 seconds.
The FTE shall be set as follows:
SNonce shall be set to a value chosen randomly by the TDLS initiator STA, following the
recommendations of 12.7.5.
All other fields shall be set to 0.
The TDLS initiator STA sends message 1 to the TDLS responder STA.
On reception of message 1, the TDLS responder STA checks whether the RSNE is present.
If the TDLS responder STA does not have security enabled on the link with the AP, it shall reject the
request with status code SECURITY_DISABLED.
If the TDLS responder STA has security enabled on the link with the AP, it checks whether the
request includes an RSNE and FTE. If not, the TDLS responder STA shall reject the request with
status code INVALID_PARAMETERS.
If the version field of the RSNE is 0, then the TDLS responder STA shall reject the request with
status code UNSUPPORTED_RSNE_VERSION.
Otherwise, the TDLS responder STA processes the message as follows:
If the contents of the RSNE do not indicate AKM of TPK handshake (suite type 00-0F-AC:7),
the TDLS responder STA shall reject the request with status code
STATUS_INVALID_AKMP.
If none of the pairwise cipher suites are acceptable, or pairwise ciphers include WEP-40, WEP-
104, or TKIP, then the TDLS responder STA shall reject the TDLS Setup Request frame with
status code STATUS_INVALID_PAIRWISE_CIPHER.
If the RSN Capabilities field has not set the subfields according to the described rules for this
message, then the TDLS responder STA rejects with status code
INVALID_RSNE_CAPABILITIES.
If the suggested lifetime is unacceptable or below the default value, the TDLS responder STA
shall reject the TDLS Setup Request frame with status code UNACCEPTABLE_LIFETIME.
If the contents of the FTE are not as per specified for this message, then the TDLS responder
STA shall reject the TDLS Setup Request frame with status code STATUS_INVALID_FTE.
2055
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The TDLS responder STA shall ignore the remaining fields in the RSNE, FTE, and Timeout
Interval element.
Otherwise, the TDLS responder STA shall respond as specified in 11.23.4.
12.7.9.4.3 TPK handshake message 2
If the TDLS responder STA validates the TPK handshake message 1 for this TDLS instance, the TDLS
responder STA may respond with TPK handshake message 2. To do so, the TDLS responder STA shall add
an RSNE, FTE, and Timeout Interval element to its TDLS Setup Response frame. The elements shall be
formatted as follows:
The RSNE shall include the following:
Include a pairwise cipher suite from one of those presented in RSNE of message 1 of this
sequence in the pairwise cipher suite list, and set the pairwise cipher suite count to 1.
The version number shall be the minimum of the maximum version supported by the TDLS
responder STA and the version number received in the RSNE of message 1.
All other RSNE fields shall be same as those received in message 1.
The Timeout Interval element shall be the same as that received in the TPK handshake message 1.
The FTE shall include the following:
ANonce shall be set to a value chosen randomly by the TDLS responder STA, following the
recommendations of 12.7.5.
SNonce shall be same as that received in message 1 of this sequence
The MIC shall be calculated on the concatenation, in the following order, of:
TDLS initiator STA MAC address (6 octets)
TDLS responder STA MAC address (6 octets)
Transaction Sequence number (1 octet) which shall be set to the value 2
Link Identifier element
RSNE
Timeout Interval element
FTE, with the MIC field of the FTE set to 0.
The MIC shall be calculated using the TPK-KCK and the AES-128-CMAC algorithm. The
output of the AES-128-CMAC shall be 128 bits.
All other fields shall be set to 0.
The TDLS responder STA shall use the MLME-SETKEYS.request primitive to configure the Temporal Key
into its STA prior to sending message 2.
The TDLS responder STA sends message 2 to the TDLS initiator STA. The TDLS initiator STA shall
process message 2 as follows:
If the TDLS initiator STA Address and TDLS responder STA Address of the Link Identifier element
do not match those for an outstanding TDLS Setup Request, the TDLS initiator STA shall silently
discard the received TDLS Setup Response frame.
If the SNonce field of the FTE does not match that of an outstanding request to the TDLS responder
STA, then the TDLS initiator STA shall silently discard the received TDLS Setup Response frame.
Otherwise, the TDLS initiator STA shall compute the TPK and then validate the MIC in the FTE as
specified in MIC calculation procedure for TPK handshake message 2. If invalid, the TDLS initiator
STA shall discard the message.
2056
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the version of the RSNE is 0 or is greater than the version of the RSNE sent in message 1, then the
TDLS initiator STA shall reject the response with status code UNSUPPORTED_RSNE_VERSION.
Otherwise,
If the contents of the RSNE, with the exception of the pairwise cipher suite count and pairwise
cipher suite list are not the same as those sent by the TDLS initiator STA in message 1 of this
sequence, then the TDLS initiator STA shall reject the response with status code
INVALID_RSNE.
If the pairwise cipher suite count is other than 1, then the TDLS initiator STA shall reject the
response with status code STATUS_INVALID_PAIRWISE_CIPHER.
If the selected pairwise cipher suite was not included in the Initiator’s request, then the TDLS
initiator STA shall reject the TDLS Setup Response frame with status code
STATUS_INVALID_PAIRWISE_CIPHER.
If the Timeout Interval element is not the same as that sent in message 1, the TDLS initiator
STA shall reject the TDLS Setup Response frame with status code
UNACCEPTABLE_LIFETIME.
If the BSSID in the Link Identifier element is different from the one sent in message 1, then the
TDLS initiator STA shall reject the response with status code NOT_IN_SAME_BSS.
If the TDLS initiator STA validates TDLS message 2, the TDLS initiator STA shall create a TPKSA and
respond with message 3 as defined in 11.23.4. The TDLS initiator STA shall use the MLME-
SETKEYS.request primitive to configure the Temporal Key into its STA prior to sending message 3.
12.7.9.4.4 TPK handshake message 3
If the TDLS initiator STA responds to message 2 for this TDLS instance, the TDLS initiator STA shall add
an RSNE, FTE, and Timeout Interval element to its TDLS Setup Confirm frame. The elements shall be
formatted as follows:
The RSNE shall be the same as the RSNE received in message 2.
The Timeout Interval element shall be the same as that received in the TPK handshake message 2.
With the exception of the MIC field, the contents of the FTE shall be the same as the FTE received
in message 2.
The MIC shall be calculated on the concatenation, in the following order, of:
TDLS initiator STA MAC address (6 octets)
TDLS responder STA MAC address (6 octets)
Transaction Sequence number (1 octet), which shall be set to the value 3
Link Identifier element
RSNE
Timeout Interval element
FTE, with the MIC field of the FTE set to 0.
The MIC shall be calculated using the TPK-KCK and the AES-128-CMAC algorithm. The output of
the AES-128-CMAC shall be 128 bits.
All other fields shall be set to 0.
The TDLS initiator STA sends message 3 to the TDLS responder STA. The TDLS responder STA shall
process message 3 as follows:
If the Source and Destination Addresses of the Link Identifier element do not match those for an
outstanding TDLS Setup Request, the TDLS responder STA shall discard the message.
If the ANonce and SNonce fields of the FTE do not match that of an outstanding request to the
TDLS initiator STA, then the TDLS responder STA shall discard the message.
2057
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Otherwise, the TDLS responder STA shall validate the MIC in the FTE as specified in the MIC
calculation procedure for TPK handshake message 3. If invalid, the TDLS responder STA shall
discard the message.
The TDLS responder STA shall discard the message, the TDLS responder STA shall abandon the
TPK handshake identified by the combination, and delete existing TPK
handshake key state for this sequence if any of the following checks fail:
The contents of the RSNE are not the same as that sent by the TDLS responder STA in
message 2
The Timeout Interval element is not the same as that sent in message 2
The BSSID from the Link Identifier element is not the same as that sent in message 2
On successful processing of message 3, the TPK handshake is considered successful.
The TPKSA shall be deleted by the TDLS responder STA if it does not receive a valid TPK handshake
message 3 from the TDLS Initiator STA within dot11TDLSResponseTimeout.
12.7.9.5 Supplicant state machine procedures
The following list summarizes the procedures used by the Supplicant state machine:
— STADisconnect – The Supplicant invokes this procedure to disassociate and deauthenticate its STA
from the AP.
— MIC(x) – The Supplicant invokes this procedure to compute a MIC of the data x.
— CheckMIC() – The Supplicant invokes this procedure to verify a MIC computed by the MIC()
function.
— StaProcessEAPOL-Key – The Supplicant invokes this procedure to process a received EAPOL-
Key frame. The pseudocode for this procedure is as follows:
StaProcessEAPOL-Key (S, M, A, I, K, RSC, ANonce, RSC, MIC, RSNE, GTK[N], IGTK[M], IPN)
TPTK PTK
TSNonce 0
PRSC 0
UpdatePTK 0
State UNKNOWN
if M = 1 then
if Check MIC(PTK, EAPOL-Key frame) fails then
State FAILED
else
State MICOK
endif
endif
if K = P then
if State FAILED then
if PSK exists then – PSK is a preshared key
PMK PSK
else
PMK L(MSK, 0, PMK_bits)
endif
TSNonce SNonce
if ANonce PreANonce then
TPTK Calc PTK(PMK, ANonce, TSNonce)
PreANonce ANonce
endif
2058
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
if State = MICOK then
PTK TPTK
UpdatePTK I
if UpdatePTK = 1 then
if no GTK then
PRSC RSC
endif
if MLME-SETKEYS.request(0, true, PRSC, PTK) fails then
invoke MLME-
DEAUTHENTICATE.request
endif
MLME-SETPROTECTION.request(TA, Rx)
endif
if GTK then
if (GTK[N] Decrypt GTK) succeeds then
if MLME-SETKEYS.request(N, 0, RSC, GTK[N]) fails then
invoke MLME-DEAUTHENTICATE.request
endif
else
State FAILED
endif
endif
if IGTK then
if (IGTK[M] Decrypt IGTK) succeeds then
if MLME-SETKEYS.request(M, 0, IPN, IGTK[M]) fails then
invoke MLME-DEAUTHENTICATE.request
endif
else
State FAILED
endif
endif
endif
endif
else if KeyData = GTK then
if State = MICOK then
if (GTK[N] Decrypt GTK) succeeds then
if MLME-SETKEYS.request(N, T, RSC, GTK[N]) fails then
invoke MLME-DEAUTHENTICATE.request
endif
else
State FAILED
endif
if (IGTK[M] Decrypt IGTK) succeeds then
if MLME-SETKEYS.request(M, T, IPN, IGTK[M]) fails then
invoke MLME-DEAUTHENTICATE request
endif
else
State FAILED
endif
else
State FAILED
endif
endif
if A = 1 && State Failed then
2059
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Send EAPOL-Key(0,1,0,0,K,0,0,TSNonce,MIC(TPTK),RSNE)
endif
if UpdatePTK = 1 then
MLME-SETPROTECTION.request(TA, Rx_Tx)
endif
if State = MICOK && S = 1 then
MLME-SETPROTECTION.request(TA, Rx_Tx)
if IBSS then
keycount++
if keycount = 2 then
802.1X::portValid true
endif
else
802.1X::portValid true
endif
endif
Here UNKNOWN, MICOK, and FAILED are values of the variable State used in the Supplicant
pseudocode. State is used to decide how to do the key processing. MICOK is set to 1 when the MIC
of the EAPOL-Key has been checked and is valid. FAILED is used when a failure has occurred in
processing the EAPOL-Key frame. UNKNOWN is the initial value of the variable State.
When processing 4-way handshake message 3, the GTK and IGTK are decrypted from the EAPOL-
Key frame and installed. The PTK shall be installed before the GTK and IGTK.
The Key Replay Counter field used by the Supplicant for EAPOL-Key frames that are sent in
response to a received EAPOL-Key frame shall be the received Key Replay Counter field. Invalid
EAPOL-Key frames such as invalid MIC, GTK without a MIC, etc., shall be ignored.
NOTE 1—TPTK is used to stop attackers changing the PTK on the Supplicant by sending the first message of the 4-way
handshake. An attacker can still affect the 4-way handshake while the 4-way handshake is being carried out.
NOTE 2—The PMK is supplied by the authentication method used with IEEE Std 802.1X-2010 if preshared mode is not
used.
NOTE 3—A PTK is configured into the encryption/integrity engine depending on the Tx/Rx bit, but if configured, is
always a transmit key. A GTK is configured into the encryption/integrity engine independent of the state of the Tx/Rx
bit, but whether the GTK is used as a transmit key is dependent on the state of the Tx/Rx bit.
— CalcGTK(x) – Generates the GTK.
— DecryptGTK(x) – Decrypt the GTK from the EAPOL-Key frame.
— DecryptIGTK(x) – Decrypt the IGTK from the EAPOL-Key frame.
12.7.9.6 Supplicant PeerKey state machine states
Figure 12-48 depicts the PeerKey handshake Supplicant key management state machine. The following list
summarizes the states the Supplicant state machine uses to support the PeerKey handshake:
— STKINIT: This state is the idle state and is entered when the IEEE 802.1X Supplicant completes
successful Authentication.
— SMKNEGOTIATING1: This state is entered when the MLME-STKSTART.request primitive is
received for the SMK handshake by the initiator STA.
— SMKNEGOTIATING2: This state is entered when the first EAPOL-Key frame of the
SMK handshake is received by the peer STA.
— SMKNEGOTIATING3: This state is entered when the fifth EAPOL-Key frame of the
SMK handshake is received by the initiator STA.
— SMKNEGOTIATING4: This state is entered when the fourth EAPOL-Key frame of the
SMK handshake is received by the peer STA.
2060
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PeerKeyInit
STKINIT
TimeoutCtr=0
MLME-PEERKEY-START EAPOLKeyReceived &&
.request (STA_P, RSNE) SMKMesgNo == 2 &&
MICVerified
TimeoutEvt
SMKNEGOTIATING1 SMKNEGOTIATING2
TimeoutCtr >N Send EAPOL-Key (SMKMesgNo=1)
Send EAPOL-Key(SMKMesgNo=3)
TimeoutCtr++
to StkInit
EAPOLKeyReceived&& EAPOLKeyReceived&&
SMKMesgNo == 5 && SMKMesgNo== 4 &&
MICVerified MICVerified
SMKNEGOTIATING3 SMKNEGOTIATING4
Install SMKSA
Install SMKSA
TimeoutCtr=0
EAPOLKeyReceived &&
TimeoutEvt UCT
STKMesgNo== 1
STKCALCNEGOTIATING1
STKSTART
TimeoutCtr >N Send EAPOL-Key (STKMesgNo=1) STKKey = Calc STK( INonce,
TimeoutCtr++ PNonce)
to StkInit
EAPOLKeyReceived &&
STKMesgNo== 2 && UCT
MICVerified
STKCALCNEGOTIATING3
STKCALCNEGOTIATING
STKKey = Calc STK( INonce, PNonce) Send EAPOL-Key (STKMesgNo=2)
TimeoutCtr= 0
EAPOLKeyReceived&&
TimeoutEvt
UCT STKMesgNo == 3 &&
MICVerified
STKCALCNEGOTIATING2
TimeoutCtr>N Send EAPOL-Key (STKMesgNo=3)
TimeoutCtr++
STKCALCNEGOTIATING4
to StkInit
Send EAPOL-Key (STKMesgNo=4)
EAPOLKeyReceived &&
STKMesgNo== 4 &&
UCT
MICVerified
STKINITDONE
If ( Initiator STA )
MLME- SETKEYS. request ( STKKey, length, 0, STA_P, 0, Initiator, RSNE)
MLME- SETPROTECTION . request( STA_P, Rx_Tx, STK)
Else
MLME- SETKEYS. request( STKKey, length, 0, STA_I, 0, Peer, RSNE)
MLME- SETPROTECTION . request( STA_I, Rx_ Tx, STK)
Figure 12-48—PeerKey handshake Supplicant key management state machine
2061
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— STKSTART: Once the SMKSA is created, the initiator STA enters this state. This is the start of
4-Way STK handshake.
— STKCALCNEGOTIATING: This state is entered when the second EAPOL-Key frame of the
4-Way STK handshake is received by the initiator STA and the MIC is verified.
— STKCALCNEGOTIATING1: This state is entered when the first EAPOL-Key frame of the
4-Way STK handshake is received by the peer STA and the MIC is verified.
— STKCALCNEGOTIATING2: This state is entered unconditionally by the initiator STA.
— STKCALCNEGOTIATING3: This state is entered unconditionally by the peer STA.
— STKCALCNEGOTIATING4: This state is entered when the third EAPOL-Key frame of the
4-Way STK handshake is received by the peer STA and the MIC is verified.
— STKINITDONE: This state is entered by the initiator STA when the fourth EAPOL-Key frame of
the 4-way STK handshake is received. This state is entered by the peer STA when the fourth
EAPOL-Key frame of the 4-way STK handshake is sent.
12.7.9.7 Supplicant PeerKey state machine variables
The following list summarizes the variables used by the Supplicant state machine:
— PeerKeyInit – This variable is used to initialize the PeerKey state machine.
— TimeoutEvt – This variable is set to true if the EAPOL-Key frame sent fails to obtain a response
from the Supplicant. The variable may be set by management action or set by the operation of a
timeout while in the different states.
— TimeoutCtr – This variable maintains the count of EAPOL-Key receive timeouts. It is incremented
each time a timeout occurs on EAPOL-Key receive event and is initialized to 0. The Key Replay
Counter field value for the EAPOL-Key frame shall be incremented on each transmission of the
EAPOL-Key frame.
— MICVerified – This variable is set to true if the MIC on the received EAPOL-Key frame is verified
and is correct. Any EAPOL-Key frames with an invalid MIC are dropped and ignored.
— SMKMesgNo – This variable indicates SMK handshake EAPOL-Key frame types. Details for each
message type (1-5) are provided in 12.7.8.
— STKMesgNo – This variable indicates 4-way STK handshake EAPOL-Key frame types. Details for
each message type (1-4) are provided in 12.7.6.
— STA_P – This variable indicates the MAC address of the peer STA participating in the PeerKey
handshake.
— STA_I – This variable indicates the MAC address of the initiator STA participating in the PeerKey
handshake.
— STKKey – The STK generated as a result of the 4-way STK handshake.
— EAPOLKeyReceived – The Supplicant sets this variable to true when it receives an EAPOL-Key
frame.
12.7.10 RSNA Supplicant key management state machine
12.7.10.1 General
The Supplicant shall reinitialize the Supplicant state machine whenever its system initializes. A Supplicant
enters the AUTHENTICATION state on an event from the MAC that requests another STA to be
authenticated. A Supplicant enters the STAKEYSTART state on receiving an EAPOL-Key frame from the
Authenticator. If the MIC or any of the EAPOL-Key frames fails, the Supplicant silently discards the frame.
Figure 12-49 depicts the RSNA Supplicant state machine.
2062
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
AuthenticationFailed dot11RSNAConfigSALifetime timeout
DeauthenticationRequest || Init
AuthenticationRequest
DISCONNECTED AUTHENTICATION
AuthenticationFailed = false
AuthenticationRequest = false
STADisconnect()
SNonce = Random
UCT PTK = GTK[0...N] = 0
IGTK[0...M] = 0
INITIALIZE 802.1X::portValid = false
802.1X::portControl = Auto
Keycount = 0
802.1X::portEnable = true
Init = false
DeauthenticationRequest = false
MSK = 0
802.1X::portEnable = false PeerKeyInit
MLME-DELETEKEYS.request( PTK )
MLME-DELETEKEYS.request( GTK[0...N] )
MLME-DELETEKEYS.request( IGTK[0...M] )
802.1X::portValid = false
Figure 12-49—RSNA Supplicant key management state machine
Unconditional transfer (UCT) means the event triggers an immediate transition.
This state machine does not use timeouts or retries. The IEEE 802.1X state machine has timeouts that
recover from authentication failures, etc.
In order to authenticate an Authenticator, the management entity sends an authentication request event. This
might be before or after the STA associates to the AP. In an IBSS environment, the event is generated when
a Probe Response frame is received.
12.7.10.2 Supplicant state machine states
The following list summarizes the states of the Supplicant state machine:
— AUTHENTICATION: A Supplicant enters this state when it sends an IEEE 802.1X
AuthenticationRequest to authenticate to an SSID.
— DISCONNECTED: A Supplicant enters this state when IEEE 802.1X authentication fails. The
Supplicant executes StaDisconnect and enters the INITIALIZE state.
— INITIALIZE: A Supplicant enters this state from the DISCONNECTED state, when it receives
Disassociation or Deauthentication messages or when the STA initializes, causing the Supplicant to
initialize the key state variables.
— STAKEYSTART: A Supplicant enters this state when it receives an EAPOL-Key frame. All the
information to process the EAPOL-Key frame is in the message and is described in the
StaProcessEAPOL-Key procedure.
12.7.10.3 Supplicant state machine variables
The following list summarizes the variables used by the Supplicant state machine:
— DeauthenticationRequest – The Supplicant sets this variable to true if the Supplicant’s STA reports
it has received Disassociation or Deauthentication messages.
— AuthenticationRequest – The Supplicant sets this variable to true if its STA’s IEEE 802.11
management entity reports that an SSID is to be authenticated. This might be on association or at
other times.
2063
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— AuthenticationFailed – The Supplicant sets this variable to true if the IEEE 802.1X authentication
failed. The Supplicant uses the MLME-DISASSOCIATE.request primitive to cause its STA to
disassociate from the Authenticator’s STA.
— EAPOLKeyReceived – The Supplicant sets this variable to true when it receives an EAPOL-Key
frame.
— IntegrityFailed – The Supplicant sets this variable to true when its STA reports that a fatal data
integrity error (e.g., michael failure) has occurred.
NOTE—A michael failure is not the same as MICVerified because IntegrityFailed is generated if the michael integrity
check fails; MICVerified is generated from validating the EAPOL-Key integrity check. Note also the STA does not
generate this event for ciphers other than TKIP because countermeasures are not required.
— MICVerified – The Supplicant sets this variable to true if the MIC on the received EAPOL-Key
frame verifies as correct. The Supplicant silently discards any EAPOL-Key frame received with an
invalid MIC.
— SNonce – This variable represents the Supplicant’s nonce.
— PTK – This variable represents the current PTK.
— TPTK – This variable represents the current PTK until message 3 of the 4-way handshake arrives
and is verified.
— GTK[] – This variable represents the current GTKs for each group key index.
— IGTK[] – This variable represents the current IGTKs for each group management key index.
— PMK – This variable represents the current PMK.
— keycount – This variable is used in IBSS mode to decide when all of the keys have been delivered
and an IBSS link is secure.
— 802.1X::XXX – This variable denotes another IEEE 802.1X state variable XXX not specified in this
standard.
12.7.11 RSNA Authenticator key management state machine
12.7.11.1 General
There is one state diagram for the Authenticator. In an infrastructure BSS, the Authenticator is always on the
AP; and in an IBSS environment, the Authenticator is on every STA.
The state diagram shown in parts in Figure 12-50 to Figure 12-53 consists of the following states:
a) The AUTHENTICATION, AUTHENTICATION2, INITPMK, INITPSK, PTKSTART,
PTKCALCNEGOTIATING, PTKCALCNEGOTIATING2, PTKINITNEGOTIATING, PTKINIT-
DONE, DISCONNECT, DISCONNECTED, and INITIALIZE states. These states handle the
initialization, 4-way handshake, teardown, and general clean-up. These states are per associated
STA.
b) The IDLE, REKEYNEGOTIATING, KEYERROR, and REKEYESTABLISHED states. These
states handle the transfer of the GTK to the associated client. These states are per associated STA.
c) The GTK_INIT, SETKEYS, and SETKEYSDONE states. These states change the GTK when
required, trigger all of the PTK group key state machines, and update the IEEE 802.11 MAC in the
Authenticator’s AP when all STAs have the updated GTK. These states are global to the
Authenticator.
Because there are two GTKs, responsibility for updating these keys is given to the group key state machine
(see Figure 12-52). In other words, this state machine determines which GTK is in use at any time.
2064
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
AuthenticationRequest
AUTHENTICATION
GNoStations++
PTK = 0
802.1X::portControl = Auto
802.1X::portEnable = true
AuthenticationRequest = false
UCT
ReAuthenticationRequest
AUTHENTICATION2
ANonce = Random
ReAuthenticationRequest= false
! PSK && PSK &&
802. 1X:: keyRun 802.1X:: keyRun
INITPMK INITPSK
! 802.1X:: keyAvailable PMK = PMK = PSK
L( MSK, 0, PMK_bits )
to DISCONNECT
802.1X:: keyAvailable 802.1X:: keyAvailable
TimeoutEvt
PTKSTART
Send EAPOL-Key( 0, 0, 1, 0, P, 0, 0, ANonce, 0, 0)
TimeoutCtr > N TimeoutCtr++ TimeoutEvt
to DISCONNECT
EAPOLKeyReceived && EAPOLKeyReceived &&
! Request && K == Pairwise ! Request&& K == Pairwise
PTKCALCNEGOTIATING
PTK = Calc PTK( ANonce , SNonce )
MICVerified
PTKCALCNEGOTIATING2
TimeoutCtr = 0
UCT
TimeoutEvt
PTKINITNEGOTIATING
Send EAPOL-Key(1,1,1,Pair,P,0,RSC,ANonce,MIC(PTK),RSNE,GTK[N],IGTK[M])
TimeoutCtr> N TimeoutCtr ++
to KEYERROR
EAPOLKeyReceived
&& ! Request
&& K == Pairwise
&& MICVerified
PTKINITDONE
if Pair == true
MLME-SETKEYS.request
. (0 , Tx/ Rx , PTK)
MLME-SETPROTECTION.request
.
. ( TA , Tx , Rx )
if IBSS == true then
keycount ++
if keycount == 2 then
802.1X:: PortValid = true
else
802.1X:: PortValid = true
endif
802.1X :: keyDone = true
Figure 12-50—Authenticator state machines, part 1
2065
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Disconnect dot11RSNAConfigSALifetime timeout
from INITPMK, PTKSTART
DISCONNECT
DeauthenticationRequest STADisconnect()
Disconnect = false
UCT
DISCONNECTED
GNoStations—
DeauthenticationRequest = false
Init
UCT
INITIALIZE
Keycount = 0
If GUpdateStationKeys == true
GKeyDoneStation—
GUpdateStationKeys = false
If Unicast cipher supported by Authenticator AND (ESS OR ((IBSS or
(FromDS==1 AND ToDS ==1)) and Local AA > Remote AA)))
Pair = true
IEEE 802.1X::portEnable = false
MLME-DELETEKEYS.request(PTK)
IEEE 802.1X::portValid = false
TimeoutCtr = 0
Figure 12-51—Authenticator state machines, part 2
Init
IDLE
GTimeoutCtr = 0
UCT
GUpdateStationKeys
TimeoutEvt
REKEYNEGOTIATING
Send EAPOL-Key (1, 1, 1, !Pair, G , 0, RSC, GNonce,MIC (PTK), GTK [GN])
GTimeoutCtr ++
EAPOLKeyReceived &&! Request
GTimeoutCtr > N && K == Group && MICVerified
UCT
REKEYESTABLISHED
KEYERROR
GKeyDoneStations — GUpdateStationKeys= false
GUpdateStationKeys= false GKeyDoneStations –-
Disconnect = true MLME-SETPROTECTION.request(TA, Rx_Tx)
Figure 12-52—Authenticator state machines, part 3
2066
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
GInit
GTK_INIT
GTK[0...N] = 0
GN = 1
GM = 2
GTK[GN] = CalcGTK()
IGTK[ 0... M] = 0
GN_igtk = 4
GM_igtk = 5
IGTK[ GN_igtk] = random key
GTKAuthenticator
SETKEYSDONE
MLME-SETKEYS .request (GN, Tx/Rx, GTK[ GN])
MLME-SETKEYS .request (GN_igtk, IGTK, IGTK[ GN_igtk] )
MLME-SETPROTECTION .request ( Rx_Tx, IGTK)
GTKRekey
GKeyDoneStations == 0
SETKEYS
GTKReKey = false
Swap( GM. GN)
GKeyDoneStations = GNoStations
GTK[ GN] = CalcGTK()
For each STA
if STA is in WNM sleep mode
GKeyDoneStations --
else
GUpdateStationsKeys = true GTKRekey
Swap(GM_igtk, GN_igtk )
IGTK[GN_igtk ] = random key
Figure 12-53—Authenticator state machines, part 4
When a second STA associates, the group key state machine is already initialized, and a GTK is already
available and in use.
When the GTK is to be updated the variable GTKReKey is set to 1. The SETKEYS state updates the GTK
and triggers all of the PTK group key state machines that currently exist—one per associated STA. Each
PTK group key state machine sends the GTK to its STA. When all of the STAs have received the GTK (or
failed to receive the key), the SETKEYSDONE state is executed which updates the APs encryption/integrity
engine with the new key.
Both the PTK state machine and the PTK group key state machine use received EAPOL-Key frames as an
event to change states. The PTK state machine only uses EAPOL-Key frames with the Key Type field equal
to Pairwise, and the PTK group key state machine only uses EAPOL-Key frames with the Key Type field
equal to Group.
2067
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.7.11.2 Authenticator state machine states
12.7.11.2.1 Authenticator state machine: 4-way handshake (per STA)
The following list summarizes the states the Authenticator state machine uses to support the 4-way
handshake:
— AUTHENTICATION: This state is entered when an AuthenticationRequest is sent from the
management entity to authenticate a BSSID.
— AUTHENTICATION2: This state is entered from the AUTHENTICATION state or from the
PTKINITDONE state.
— DISCONNECT: This state is entered if an EAPOL-Key frame is received and fails its MIC check.
It sends a Deauthentication message to the STA and enters the INITIALIZE state.
— DISCONNECTED: This state is entered when Disassociation or Deauthentication messages are
received.
— INITIALIZE: This state is entered from the DISCONNECTED state, when a deauthentication
request event occurs, or when the STA initializes. The state initializes the key state variables.
— INITPMK: This state is entered when the IEEE 802.1X backend AS completes successfully. If a
PMK is supplied, it goes to the PTKSTART state; otherwise, it goes to the DISCONNECTED state.
— INITPSK: This state is entered when a PSK is configured.
— PTKCALCNEGOTIATING: This state is entered when the second EAPOL-Key frame for the
4-way handshake is received with the key type of Pairwise.
— PTKCALNEGOTIATING2: This state is entered when the MIC for the second EAPOL-Key
frame of the 4-way handshake is verified.
— PTKINITNEGOTIATING: This state is entered when the MIC for the second EAPOL-Key frame
for the 4-way handshake is verified. When message 3 of the 4-way handshake is sent in state
PTKINITNEGOTIATING, the encrypted GTK shall be sent at the end of the data field, and the
GTK length is put in the GTK Length field.
— PTKINITDONE: This state is entered when the last EAPOL-Key frame for the 4-way handshake is
received with the key type of Pairwise. This state may call SetPTK; if this call fails, the AP
should detect and recover from the situation, for example, by doing a disconnect event for this
association.
— PTKSTART: This state is entered from INITPMK or INITPSK to start the 4-way handshake or if
no response to the 4-way handshake occurs.
12.7.11.2.2 Authenticator state machine: group key handshake (per STA)
The following list summarizes the states the Authenticator state machine uses to support the group key
handshake:
— IDLE: This state is entered when no group key handshake is occurring.
— KEYERROR: This state is entered if the EAPOL-Key acknowledgment for the group key
handshake is not received.
— REKEYESTABLISHED: This state is entered when an EAPOL-Key frame is received from the
Supplicant with the Key Type subfield equal to Group.
— REKEYNEGOTIATING: This state is entered when the GTK is to be sent to the Supplicant.
NOTE—The Rx_Tx flag for sending a GTK is always the opposite of whether the pairwise key is used for data
encryption/integrity or not. If a pairwise key is used for encryption/integrity, then the STA never transmits with the
GTK; otherwise, the STA uses the GTK for transmit.
2068
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.7.11.2.3 Authenticator state machine: group key handshake (global)
The following list summarizes the states the Authenticator state machine uses to coordinate a group key
update of all STAs:
— GTK_INIT: This state is entered on system initialization.
— SETKEYS: This state is entered if the GTK is to be updated on all Supplicants.
— SETKEYSDONE: This state is entered if the GTK has been updated on all Supplicants.
NOTE—SETKEYSDONE calls SetGTK to set the GTK for all associated STAs that are not in WNM sleep mode. If this
fails, all communication via this key fails, and the AP needs to detect and recover from this situation. A STA that is in
WNM sleep mode will not have the current GTK installed when it wakes up and will need to get new GTK as described
in the WNM sleep mode procedures in 11.2.3.18.
12.7.11.3 Authenticator state machine variables
The following list summarizes the variables used by the Authenticator state machine:
— AuthenticationRequest – This variable is set to true by the STA’s IEEE 802.11 management entity in
order to authenticate an association. This can be set to true when the STA associates or at other
times.
— ReAuthenticationRequest – This variable is set to true if the IEEE 802.1X Authenticator received an
eapStart or 802.1X::reAuthenticate is 1.
— DeauthenticationRequest – This variable is set to true if a Disassociation or Deauthentication
message is received.
— Disconnect – This variable is set to true when the STA should initiate a deauthentication.
— EAPOLKeyReceived – This variable is set to true when an EAPOL-Key frame is received. EAPOL-
Key frames that are received in response to an EAPOL-Key frame sent by the Authenticator shall
contain the same Key Replay Counter field value as the Key Replay Counter field in the transmitted
message. EAPOL-Key frames that contain different Key Replay Counter field values should be
discarded. An EAPOL-Key frame that is sent by the Supplicant in response to an EAPOL-Key
frame from the Authenticator shall not have the Ack bit set to 1. EAPOL-Key frames sent by the
Supplicant not in response to an EAPOL-Key frame from the Authenticator shall have the Request
bit set to 1.
EAPOL-Key frames with a key type of Pairwise and a nonzero key index should be ignored.
EAPOL-Key frames with a key type of Group and an invalid key index should be ignored.
NOTE—When an EAPOL-Key frame in which the Ack bit is 0 is received, then it is expected as a reply to a message
that the Authenticator sent, and the replay counter is checked against the replay counter used in the sent EAPOL-Key
frame. When an EAPOL-Key frame in which the Request bit is 1 is received, then a replay counter for these messages is
used that is a different replay counter than the replay counter used for sending messages to the Supplicant.
— GTimeoutCtr – This variable maintains the count of EAPOL-Key receive timeouts for the group key
handshake. It is incremented each time a timeout occurs on EAPOL-Key receive event and is
initialized to 0. Annex C details the timeout values. The Key Replay Counter field value for the
EAPOL-Key frame shall be incremented on each transmission of the EAPOL-Key frame.
— GInit – This variable is used to initialize the group key state machine. This is a group variable.
— Init – This variable is used to initialize per-STA state machine
— TimeoutEvt – This variable is set to true if the EAPOL-Key frame sent out fails to obtain a response
from the Supplicant. The variable may be set to 1 by management action or set to 1 by the operation
of a timeout while in the PTKSTART and REKEYNEGOTIATING states.
— TimeoutCtr – This variable maintains the count of EAPOL-Key receive timeouts. It is incremented
each time a timeout occurs on EAPOL-Key receive event and is initialized to 0. Annex C contains
details of the timeout values. The Key Replay Counter field value for the EAPOL-Key frame shall
be incremented on each transmission of the EAPOL-Key frame.
2069
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— MICVerified – This variable is set to true if the MIC on the received EAPOL-Key frame is verified
and is correct. Any EAPOL-Key frames with an invalid MIC are dropped and ignored.
— GTKAuthenticator – This variable is set to true if the Authenticator is on an AP or it is the
designated Authenticator for an IBSS.
— GKeyDoneStations – Count of number of STAs left to have their GTK updated. This is a global
variable.
— GTKRekey – This variable is set to true when a group key handshake is required. This is a global
variable.
— GUpdateStationKeys – This variable is set to true when a new GTK is available to be sent to
Supplicants.
— GNoStations – This variable counts the number of Authenticators so it is known how many
Supplicants need to be sent the GTK. This is a global variable.
— ANonce – This variable holds the current nonce to be used if the STA is an Authenticator.
— GN, GM – These are the current key indices for GTKs. Swap(GM, GN) means that the global key
index in GN is swapped with the global key index in GM, so now GM and GN are reversed.
— PTK – This variable is the current PTK.
— GTK[] – This variable is the current GTKs for each GTK index.
— PMK – This variable is the buffer holding the current PMK.
— 802.1X::XXX – This variable is the IEEE 802.1X state variable XXX.
— keycount – This variable is used in IBSS mode to decide when all of the keys have been delivered
and an IBSS link is secure.
— WNM sleep mode – This variable is true when the non-AP STA is in the WNM sleep mode, as
described in 11.2.3.18. Otherwise, it is false.
12.7.11.4 Authenticator state machine procedures
The following list summarizes the procedures used by the Authenticator state machine:
— STADisconnect() – Execution of this procedure deauthenticates the STA.
— CalcGTK(x) – Generates the GTK.
— MIC(x) – Computes a MIC over the plaintext data.
12.8 Mapping EAPOL keys to IEEE 802.11 keys
12.8.1 Mapping PTK to TKIP keys
See 12.7.1.3 for the definition of the EAPOL temporal key derived from PTK.
A STA shall use bits 0–127 of the temporal key as its input to the TKIP Phase 1 and Phase 2 mixing
functions.
A STA shall use bits 128–191 of the temporal key as the michael key for MSDUs from the Authenticator’s
STA to the Supplicant’s STA.
A STA shall use bits 192–255 of the temporal key as the michael key for MSDUs from the Supplicant’s
STA to the Authenticator’s STA.
12.8.2 Mapping GTK to TKIP keys
See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK.
2070
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A STA shall use bits 0–127 of the temporal key as the input to the TKIP Phase 1 and Phase 2 mixing
functions.
A STA shall use bits 128–191 of the temporal key as the michael key for MSDUs from the Authenticator’s
STA to the Supplicant’s STA.
A STA shall use bits 192–255 of the temporal key as the michael key for MSDUs from the Supplicant’s
STA to the Authenticator’s STA.
12.8.3 Mapping PTK to CCMP keys
See 12.7.1.3 for the definition of the EAPOL temporal key derived from PTK.
A STA shall use the temporal key as the CCMP key for MPDUs between the two communicating STAs.
12.8.4 Mapping GTK to CCMP keys
See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK.
A STA shall use the temporal key as the CCMP key.
12.8.5 Mapping GTK to WEP-40 keys
See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK.
A STA shall use bits 0–39 of the temporal key as the WEP-40 key.
12.8.6 Mapping GTK to WEP-104 keys
See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK.
A STA shall use bits 0–103 of the temporal key as the WEP-104 key.
12.8.7 Mapping IGTK to BIP keys
See 12.7.1.5 for the definition of the IGTK. A STA shall use bits 0–127 of the IGTK as the AES-128-CMAC
key, bits 0–127 of the IGTK as the AES-128-GMAC key, and bits 0–255 of the IGTK as the AES-256-
GMAC key.
12.8.8 Mapping PTK to GCMP keys
See 12.7.1.3 for the definition of the EAPOL temporal key derived from PTK.
A STA shall use the temporal key as the GCMP key for MPDUs between the two communicating STAs.
12.8.9 Mapping GTK to GCMP keys
See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK.
A STA shall use the temporal key as the GCMP key.
2071
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.9 Per-frame pseudocode
12.9.1 WEP frame pseudocode
A WEP-encapsulated MPDU is called a WEP MPDU. All other MPDUs are called non-WEP MPDUs.
A STA shall not transmit WEP MPDUs when dot11PrivacyInvoked is false. This MIB variable does not
affect the reception of frames containing all or part of an MSDU or MMPDU.
if dot11PrivacyInvoked is false then
the MPDU is transmitted without WEP cryptographic encapsulation
else
if (the MPDU has an individual RA and there is an entry in dot11WEPKeyMappings for that
RA) then
if that entry has WEPOn equal to false then
the MPDU is transmitted without WEP cryptographic encapsulation
else
if that entry contains a key that is null then
discard the MPDU’s entire MSDU and generate an MA-UNITDATA-
STATUS.indication primitive to notify LLC that the MSDU was
undeliverable due to a null WEP key
else
encrypt the MPDU using that entry’s key, setting the Key ID subfield of the IV
field to 0
endif
endif
else
if (the MPDU has a group RA and the Privacy subfield of the Capability Information field
in this BSS is 0) then
the MPDU is transmitted without WEP cryptographic encapsulation
else
if dot11WEPDefaultKeys[dot11WEPDefaultKeyID] is null then
discard the MPDU’s entire MSDU and generate an MA-UNITDATA-
STATUS.indication primitive to notify LLC that the MSDU was
undeliverable due to a null WEP key
else
WEP-encapsulate the MPDU using the key dot11WEPDefaultKeys-
[dot11WEPDefaultKeyID], setting the Key ID subfield of the IV field to
dot11WEPDefaultKeyID
endif
endif
endif
endif
When the boolean dot11ExcludeUnencrypted is true, MPDUs with the Type subfield equal to Data and the
Protected Frame subfield of the Frame Control field equal to 0 shall not be indicated at the MAC service
interface, and only MSDUs successfully reassembled from successfully decrypted MPDUs shall be
indicated at the MAC service interface. When receiving a frame with the Type subfield equal to Data, the
values of dot11PrivacyOptionImplemented, dot11WEPKeyMappings, dot11WEPDefaultKeys,
dot11WEPDefaultKeyID, and dot11ExcludeUnencrypted in effect at the time the PHY-
RXSTART.indication primitive is received by the MAC shall be used according to the following decision
tree:
if the Protected Frame subfield of the Frame Control field is 0 then
if dot11ExcludeUnencrypted is true then
2072
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
discard the frame body without indication to LLC and increment
dot11WEPExcludedCount
else
receive the frame without WEP decapsulation
endif
else
if dot11PrivacyOptionImplemented is true then
if (the MPDU has individual RA and there is an entry in dot11WEPKeyMappings
matching the MPDU’s TA) then
if that entry has WEPOn equal to false then
discard the frame body and increment dot11WEPUndecryptableCount
else
if that entry contains a key that is null then
discard the frame body and increment dot11WEPUndecryptableCount
else
WEP-decapsulate with that key, incrementing dot11WEPICVErrorCount if
the ICV check fails
endif
endif
else
if dot11WEPDefaultKeys[Key ID] is null then
discard the frame body and increment dot11WEPUndecryptableCount
else
WEP-decapsulate with dot11WEPDefaultKeys[Key ID], incrementing
dot11WEPICVErrorCount if the ICV check fails
endif
endif
else
discard the frame body and increment dot11WEPUndecryptableCount
endif
endif
12.9.2 RSNA frame pseudocode
12.9.2.1 General
STAs transmit protected MSDUs, A-MSDUs, and robust Management frames to an RA when a temporal
key has been configured with a MLME-SETKEYS.request primitive and an MLME-
SETPROTECTION.request primitive has been invoked with ProtectType parameter Tx or Rx_Tx to that
RA. STAs expect to receive protected MSDUs, A-MSDUs, and robust Management frames from a TA when
a temporal key has been configured with a MLME-SETKEYS.request primitive and an MLME-SET-
PROTECTION.request primitive has been invoked with ProtectType parameter Rx or Rx_Tx from that TA.
MSDUs, A-MSDUs, and robust Management frames that do not match these conditions are sent in the clear
and are received in the clear.
12.9.2.2 Per-MSDU/Per-A-MSDU Tx pseudocode
if dot11RSNAActivated = true then
if MSDU or A-MSDU has an individual RA and Protection for RA is off for Tx then
transmit the MSDU or A-MSDU without protections
else if (MPDU has individual RA and Pairwise key exists for the MPDU’s RA) or (MPDU has
a group addressed RA and network type is IBSS/PBSS and IBSS/PBSS GTK exists for
MPDU’s TA) then
// If we find a suitable Pairwise or GTK for the mode we are in…
2073
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
if key is a null key then
discard the entire MSDU or A-MSDU and generate one or more MA-UNITDATA-
STATUS.indication primitives to notify LLC that the MSDUs were undeliverable
due to a null key
else
// Note that it is assumed that no entry in the key
// mapping table is of an unsupported cipher type
Set the Key ID subfield of the IV field to 0.
if cipher type of entry is AES-CCM then
Transmit the MSDU or A-MSDU, to be protected after fragmentation using
AES-CCM
else if cipher type of entry is AES-GCM then
Transmit the MSDU or A-MSDU, to be protected after fragmentation using
AES-GCM
else if cipher type of entry is TKIP then
Compute MIC using michael algorithm and entry’s Tx MIC key.
Append MIC to MSDU
Transmit the MSDU, to be protected with TKIP
else if cipher type of entry is WEP then
Transmit the MSDU, to be protected with WEP
endif
endif
else // Else we did not find a key but we are protected, so handle the default key case or discard
if GTK entry for Key ID contains null then
discard the MSDU or A-MSDU and generate one or more MA-UNITDATA-
STATUS.indication primitives to notify the LLC that the MSDUs were
undeliverable due to a null GTK
else if GTK entry for Key ID is not null then
Set the Key ID subfield of the IV field to the Key ID.
if MPDU has an individual RA and cipher type of entry is not TKIP then
discard the entire MSDU or A-MSDU and generate one or more MA-
UNITDATA-STATUS.indication primitives to notify the LLC that the
MSDUs were undeliverable due to a null key
else if cipher type of entry is AES-CCM then
Transmit the MSDU or A-MSDU, to be protected after fragmentation using
AES-CCM
else if cipher type of entry is AES-GCM then
Transmit the MSDU or A-MSDU, to be protected after fragmentation using
AES-GCM
else if cipher type of entry is TKIP then
Compute MIC using michael algorithm and entry’s Tx MIC key.
Append MIC to MSDU
Transmit the MSDU, to be protected with TKIP
else if cipher type of entry is WEP then
Transmit the MSDU, to be protected with WEP
endif
endif
endif
endif
12.9.2.3 Per-MMPDU Tx pseudocode
if ((dot11RSNAActivated = true) and (frame is a robust Management frame)) then
2074
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
if ((dot11RSNAProtectedManagementFramesActivated = false) then
Transmit the MMPDU without protection
else // dot11RSNAProtectedManagementFramesActivated = true
if (dot11RSNAUnprotectedManagementFramesAllowed = true) then
if (MMPDU has an individual RA) then
if (peer STA advertised MFPC = 1) then
if (Pairwise key exists for the MMPDU’s RA) then
// Note that it is assumed that no entry in the key
// mapping table is of an unsupported cipher.
Transmit the MMPDU, to be protected after fragmentation
// see 12.9.2.5
else if (robust Action frame) then
// pairwise key was not found
Discard the MMPDU and generate an MLME.confirm primitive to
notify the SME that the MMPDU was not delivered
else // Disassociation or Deauthentication
Transmit the MMPDU without protection
endif
else // (peer STA didn’t advertised MFPC = 1)
Transmit the MMPDU without protection
endif
else // MMPDU has a group RA
if (IGTK exists) then
// if we find a suitable IGTK
Transmit the MMPDU with protection
// See 12.9.2.5
else if (MMPDU is Disassociate ||Deauthenticate ||(not a robust Action frame))
then
Transmit the MMPDU without protection
else
Discard the MMPDU and generate an MLME.confirm primitive to notify
the SME that the MMPDU was undeliverable
endif
endif
else // dot11RSNAUnprotectedManagementFramesAllowed = false
if (MMPDU has an individual RA) then
if (peer STA advertised MFPC = 1) then
if (Pairwise key exists for the MMPDU’s RA) then
// Note that it is assumed that no entry in the key
// mapping table is of an unsupported cipher.
Transmit the MMPDU, to be protected after fragmentation
// see 12.9.2.5
else if (robust Action frame) then
// pairwise key was not found
2075
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Discard the MMPDU and generate an MLME.confirm primitive to
notify the SME that the MMPDU was not delivered
else // FrameControlSubType is Disassociation or Deauthentication
Transmit the MMPDU without protection
endif
else // peer STA didn’t advertise MFPC = 1
Discard the MMPDU and generate an MLME.confirm primitive to notify
the SME that the MMPDU was not delivered
endif
else // MMPDU has a group RA
if (IGTK exists) then
// if we find a suitable IGTK
Transmit the MMPDU with protection
// See 12.9.2.5
else if (MMPDU is Disassociate || Deauthenticate || (not a robust Action frame))
then
Transmit the MMPDU without protection
else
Discard the MMPDU and generate an MLME.confirm primitive to notify
the SME that the MMPDU was undeliverable
endif
endif
endif
endif
else // (dot11RSNAActivated = false) or (not a robust Management frame)
Use 12.9.2.2 to transmit the frame
endif
12.9.2.4 Per-MPDU Tx pseudocode
if dot11RSNAActivated = true then
if MPDU is member of an MSDU that is to be transmitted without protections
transmit the MPDU without protections
else if MSDU or A-MSDU that MPDU is a member of is to be protected using AES-CCM
Protect the MPDU using entry’s key and AES-CCM
Transmit the MPDU
else if MSDU or A-MSDU that MPDU is a member of is to be protected using AES-GCM
Protect the MPDU using entry’s key and AES-GCM
Transmit the MPDU
else if MSDU that MPDU is a member of is to be protected using TKIP
Protect the MPDU using TKIP encryption
Transmit the MPDU
else if MSDU that MPDU is a member of is to be protected using WEP
Encrypt the MPDU using entry’s key and WEP
Transmit the MPDU
else
// should not arrive here
endif
2076
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
endif
12.9.2.5 Per-MPDU Tx pseudocode for MMPDU
if ((dot11RSNAActivated = true) then
if (MPDU is member of an MMPDU that is to be transmitted without protection) then
Transmit the MPDU without protection
else if (MPDU has an individual RA) then
Protect the MPDU using entry’s TK and selected cipher from RSNE
Transmit the MPDU
else
// MPDU has a group RA
Protect the MPDU using IGTK and BIP
Transmit the MPDU
endif
endif
12.9.2.6 Per-MPDU Rx pseudocode
if dot11RSNAActivated = true then
if the Protected Frame subfield of the Frame Control field is 0 then
if Protection for TA is off for Rx then
Receive the unencrypted MPDU without protections
else
discard the frame body without indication to LLC and increment
dot11WEPExcludedCount
endif
else if Protection is true for TA then
if ((MPDU has individual RA and Pairwise key exists for the MPDU’s TA) or (MPDU
has a group addressed RA and network type is IBSS/PBSS and IBSS/PBSS GTK
exists for MPDU’s RA)) then
if MPDU has individual RA then
lookup pairwise key using Key ID from MPDU
else
lookup group key using Key ID from MPDU
endif
if key is null then
discard the frame body and increment dot11WEPUndecryptableCount
else if entry has an AES-CCM key then
decrypt frame using AES-CCM key
discard the frame if the integrity check fails and increment dot11RSNAStats-
CCMPDecryptErrors
else if entry has an AES-GCM key then
decrypt frame using AES-GCM key
discard the frame if the integrity check fails
else if entry has a TKIP key then
prepare a temporal key from the TA, TKIP key and PN
decrypt the frame using ARC4
discard the frame if the ICV fails and increment dot11RSNAStatsTKIPLocal-
MicFailures
else if entry has a WEP key then
2077
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
decrypt the frame using WEP decryption
discard the frame if the ICV fails and increment dot11WEPICVErrorCount
else
discard the frame body and increment dot11WEPUndecryptableCount
endif
else if GTK for the Key ID does not exist then
discard the frame body and increment dot11WEPUndecryptableCount
else if GTK for the Key ID is null then
discard the frame body and increment dot11WEPUndecryptableCount
else if the GTK for the Key ID is a CCM key then
decrypt frame using AES-CCM key
discard the frame if the integrity check fails and increment dot11RSNAStatsCCMP-
DecryptErrors
else if the GTK for the Key ID is a GCM key then
decrypt frame using AES-GCM key
else if the GTK for the Key ID is a TKIP key then
prepare a temporal key from the TA, TKIP key and PN
decrypt the frame using ARC4
discard the frame if the ICV fails and increment dot11RSNAStatsTKIPICVErrors
else if the GTK for the Key ID is a WEP key then
decrypt the frame using WEP decryption
discard the frame if the ICV fails and increment dot11WEPICVErrorCount
endif
else
MLME-PROTECTEDFRAMEDROPPED.indication
discard the frame body and increment dot11WEPUndecryptableCount
endif
endif
12.9.2.7 Per-MPDU Rx pseudocode for an MMPDU
if ((dot11RSNAActivated = true) and (frame is a robust Management frame)) then
if ((dot11RSNAProtectedManagementFramesActivated = false) then
if (Protected Frame subfield of the Frame Control field is equal to 1) then
Discard the frame
else
Receive the MMPDU
endif
else // dot11RSNAProtectedManagementFramesActivated = true
if (dot11RSNAUnprotectedManagementFramesAllowed = true) then
if (STA with frame TA advertised MFPC = 0) then
if (Protected Frame subfield of the Frame Control field is equal to 1) then
Discard the frame
else
Make frame available for further processing
endif
else // STA with frame TA advertised MFPC = 1
if (MMPDU has an individual RA) then
if (Pairwise key does not exist) then
2078
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
if (frame is a Disassociation or Deauthentication) then
if (Protected Frame subfield of the Frame Control field is equal to 0) then
Make the MPDU available for further processing
else // encrypted
Discard the frame
endif
else // frame is not a Disassociation or Deauthenticate
Discard the frame
endif
else if (security association has an AES-CCM key) then
if (Protected Frame subfield of the Frame Control field is equal to 0) then
//unprotected frame
Discard the frame
else // frame is encrypted
if (PN is not sequential) then
Discard the MPDU as a replay
Increment dot11RSNAStatsCCMPReplays
else
Decrypt frame using AES-CCM key
if (the integrity check fails) then
Discard the frame
Increment dot11RSNAStatsCCMPDecryptErrors
else
Make the MPDU available for further processing
endif
endif
endif
else if (security association has AES-GCM key) then
if (Protected Frame subfield of the Frame Control field is equal to 0) then
//unprotected frame
Discard the frame
else //frame is encrypted
if (PN is not sequential) then
Discard the MPDU as a replay
Increment dot11RSNAStatsGCMPReplays
else
Decrypt frame using AES-GCM key
If (the integrity check fails) then
Discard the frame
else
Make the MPDU available for further processing
endif
endif
2079
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
endif
else // key for some other cipher—for future expansion
endif
else // MMPDU has a group RA
if (IGTK does not exist) then
if (Disassociation or Deauthentication) then
Make frame available for further processing
else
Discard the frame
endif
else // IGTK exists
if (MME is not present) then
Discard the frame
else // MME is present
if (AES-128-CMAC IGTK) then
if (IPN is not valid) then
Discard the frame as a replay
Increment dot11RSNAStatsCMACReplay
else if (integrity check fails) then
Discard the frame
Increment dot11RSNAStatsCMACICVError
else
Make frame available for further processing
endif
else // some other kind of key—for the future
endif
endif
endif
endif
endif
else // dot11RSNAUnprotectedManagementFramesAllowed = false
if (MMPDU has an individual RA) then
if (peer STA advertised MFPC = 1) then
if (Pairwise key exists for the MMPDU’s RA) then
if (security association has an AES-CCM key) then
if (Protected Frame subfield of the Frame Control field is equal to 0) then
Discard the frame
else // frame is encrypted
if (PN is not sequential) then
Discard the MPDU as a replay
Increment dot11RSNAStatsCCMPReplays
else
Decrypt frame using AES-CCM key
2080
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
if (the integrity check fails) then
Discard the frame
Increment dot11RSNAStatsCCMPDecryptErrors
else
Make the MPDU available for further processing
endif
endif
endif
else // key for some other cipher—for future expansion
endif
else if (Protected Frame subfield of the Frame Control field is set to 1) then
Discard the frame
else if (Deauthenticate || Disassociate) then
Make frame available for processing
else
Discard the frame
endif
else // peer STA didn’t advertise MFPC = 1
Discard the frame
endif
else // MMPDU has a group RA
if (IGTK exists) then
if (MME is not present) then
Discard the frame
else // MME is present
if (AES-128-CMAC IGTK) then
if (PN is not valid) then
Discard the frame as a replay
Increment dot11RSNAStatsCMACReplay
else if (security association has an AES-128-CMAC IGTK) then
Discard the frame
Increment dot11RSNAStatsCMACICVError
else
Make frame available for further processing
endif
else // some other kind of key—for the future
endif
endif
else // IGTK does not exist
if (Disassociation or Deauthentication) then
Make frame available for further processing
else
Discard the frame
2081
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
endif
endif
endif
endif
endif
else // (dot11RSNAActivated = false) or (not a robust Management frame)
Use 12.9.2.6 to receive the frame
endif
12.9.2.8 Per-MSDU/Per-A-MSDU Rx pseudocode
if dot11RSNAActivated = true then
if the frame was not protected then
Receive the MSDU or A-MSDU unprotected
Make MSDU(s) available to higher layers
else if Address 1 has an individual RA then // Have a protected MSDU or A-MSDU
if Pairwise key is an AES-CCM key then
Accept the MSDU or A-MSDU if its MPDUs had sequential PNs (or if it consists of
only one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and
increment dot11RSNAStatsCCMPReplays
Make MSDU(s) available to higher layers
else if Pairwise key is an AES-GCM key then
Accept the MSDU or A-MSDU if its MPDUs had sequential PNs (or if it consists of
only one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and
increment dot11RSNAStatsGCMPReplays
else if Pairwise key is a TKIP key then
Compute the MIC using the michael algorithm
Compare the received MIC to the computed MIC
discard the frame if the MIC fails increment dot11RSNAStatsTKIPLocalMIC-
Failures and invoke countermeasures if appropriate
compare TSC to replay counter, if replay check fails increment dot11RSNA-
StatsTKIPReplays
otherwise accept the MSDU
Make MSDU available to higher layers
else if dot11WEPKeyMappings has a WEP key then
Accept the MSDU since the decryption took place at the MPDU
Make MSDU available to higher layers
endif
else // Have a group addressed MSDU or A-MSDU
if GTK for the Key ID does not exist then
discard the frame body and increment dot11WEPUndecryptableCount
else if GTK for the Key ID is null then
discard the frame body and increment dot11WEPUndecryptableCount
else if GTK for the Key ID is a CCM key then
Accept the MSDU or A-MSDU if its MPDUs had sequential PNs (or if it consists of
only one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and
increment dot11RSNAStatsCCMPReplays
Make MSDU(s) available to higher layers
else if GTK for the Key ID is a GCM key then
Accept the MSDU or A-MSDU if its MPDUs have sequential PNs (or if it consists of
only one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and
increment dot11RSNAStatsGCMPReplays
2082
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
else if GTK for the Key ID is a TKIP key then
Compute the MIC using the michael algorithm
Compare the received MIC to the computed MIC
discard the frame if the MIC fails increment
dot11RSNAStatsTKIPLocalMICFailures and invoke countermeasures if
appropriate
compare TSC to replay counter, if replay check fails increment
dot11RSNAStatsTKIPReplays
otherwise accept the MSDU
Make MSDU available to higher layers
else if GTK for the Key ID is a WEP key then
Accept the MSDU since the decryption took place at the MPDU
Make MSDU available to higher layers
endif
endif
endif
12.9.2.9 Per-MMPDU Rx pseudocode
if (dot11RSNAActivated = true) then
if (dot11RSNAProtectedManagementFramesActivated = true) then
if (the MPDU was not protected) then
Receive the MMPDU unprotected
Make the MMPDU available to higher layers
else //Have a protected MMPDU
if ((MMPDU has individual RA) and (security association has an AES-CCM key))
then
if (the MPDU has only one MPDU or multiple MPDUs with sequential PNs)
then
Receive the MMPDU protected
Make the MMPDU available to higher layers
else
Discard the MMPDU as a replay
Increment dot11RSNAStatsRobustMgmtCCMPReplays
endif
else if ((MMPDU has individual RA) and (security association has an AES-GCM
key)) then
if (the MPDU has only one MPDU or multiple MPDUs with sequential PNs)
then
Receive the MMPDU protected
Make the MMPDU available to higher layers
else
Discard the MMPDU as a replay
Increment dot11RSNAStatsRobustMgmtGCMPReplays
else if ((MPDU has group addressed RA) and (security association has an AES-128-
CMAC IGTK)) then
Receive the MMPDU
Make the MMPDU available to higher layers
2083
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
else
if (any other cipher exists) then
Process the frame using other cipher
else
Discard the frame
endif
endif
endif
endif
endif
12.10 Authenticated mesh peering exchange (AMPE)
The authenticated mesh peering exchange is defined in 14.5.
12.11 AP PeerKey support
12.11.1 AP PeerKey overview
The AP PeerKey protocol provides session identification and creation of an AP PeerKey association to
provide for security of OBSS management communication between two APs. The result of a successful run
of the AP PeerKey protocol is an AP PeerKey association. An AP PeerKey association is composed of a
mesh PMKSA and a mesh TKSA.
Two APs perform the AP PeerKey protocol in order to protect HCCA TXOP Advertisement frames in an
OBSS. The AP PeerKey protocol is unauthenticated (neither peer has a verified identity of the other peer)
but an AP knows that only the peer AP that completed the AP PeerKey protocol is able to send protected
HCCA TXOP Advertisement frames protected by the resulting AP PeerKey association. This allows an AP
to determine whether a peer AP honors the HCCA TXOP avoidance schedule that is negotiated. In this
manner, an AP is able to honor the negotiated schedule of trusted peer APs and ignore peer APs that are not
trustworthy. This allows trustworthy APs to negotiate mutually beneficial schedules while allowing an AP
to not disadvantage itself in an OBSS in the presence of untrustworthy APs.
AP PeerKey uses various functions and data to accomplish its task and assumes certain properties about
each function as follows:
— H is an “extractor” function (see IETF RFC 5869) that concentrates potentially dispersed entropy
from an input to create an output that is a cryptographically strong, pseudorandom key. This
function takes as input a non-secret “salt” and a secret input and produces a fixed-length output.
— A finite cyclic group is negotiated for which solving the discrete logarithm problem is
computationally infeasible.
When using AKM suite selector 00-0F-AC:10 to indicate AP PeerKey, H shall be instantiated as HMAC-
SHA-256, taking as input a non-secret “salt” and a secret input keying material “ikm”:
H(salt, ikm) = HMAC-SHA-256(salt, ikm)
Other instantiations of function H require creation of a new AKM identifier.
2084
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
12.11.2 AP PeerKey protocol
AP PeerKey uses the same discrete logarithm cryptography as SAE (as described in 12.4) to achieve key
agreement. Each party to the exchange has a public and private key with respect to a particular set of domain
parameters that define a finite cyclic group. Groups may be based on elliptic curve cryptography (ECC) or
finite field cryptography (FFC). Each component of a group is referred to as an element. Groups are
negotiated using an identifying number from a repository maintained by IANA as “Group Description”
attributes for IETF RFC 2409 (IKE) [B17][B31]. The repository maps an identifying number to a complete
set of domain parameters for the particular group. For the purpose of interoperability, APs that have
dot11ProtectedHCCATXOPNegotiationImplemented true or dot11ProtectedQLoadReportImplemented true
shall support group 19, an ECC group defined over a 256-bit prime order field.
AP PeerKey uses one arithmetic operator that takes one element and one scalar value to produce another
element (called the scalar operation). The convention used here is to represent group elements in uppercase
bold italic and scalar values in lowercase italic. The scalar operation takes an element and a scalar and is
denoted scalar-op(x,Y).
The private key d shall be chosen randomly so that 1 < d < r, where r is the order of the group. The public
key Q shall be produced using Equation (12-1).
Q = scalar-op(d,G) (12-1)
where
G is the generator (also known as the base point) of the group
An AP for which dot11ProtectedTXOPNegotiationActivated is true or
dot11ProtectedQLoadReportActivated is true shall support at least one public key from cyclic group
nineteen and may support multiple public keys from multiple cyclic groups. An AP that supports the
Multiple BSSID capability and has dot11ProtectedTXOPNegotiationActivated true or
dot11ProtectedQLoadReportActivated true may use one public key across multiple BSSIDs, or it may
choose to generate a public key for each supported BSSID.
The AP PeerKey protocol consists of an exchange of public keys from an AP and a peer AP. An AP requests
the public key of a peer AP by sending a Public Key frame with the Public Key Frame Usage field set to
“Request.” This frame contains the public key of the initiating AP. The initiating AP awaits a response to its
request. The peer AP responds to the “Request” from the initiating AP with a Public Key frame with the
Public Key Frame Usage field set to “Response”, indicating an acceptable group was sent by the initiating
AP, or set to “NAK” indicating that the group sent by the initiating AP was unacceptable.
It is possible for multiple runs of the AP PeerKey protocol to be performed by an AP but there shall be only
one instance at a time of the AP PeerKey protocol to a peer AP for a particular group. The state associated
with each run of the AP PeerKey protocol is the group and the two public keys of the participating APs.
An AP for which dot11ProtectedTXOPNegotiationActivated is true or
dot11ProtectedQLoadReportActivated is true shall reply to a Public Key frame. An AP that has both
dot11ProtectedTXOPNegotiationActivated is false and dot11ProtectedQLoadReportActivated is false shall
drop all received Public Key frames. If the responding AP refuses to perform the AP PeerKey protocol with
the initiating AP it shall respond with a Public Key frame, setting the Public Key Frame Usage field to
“Refused”. Otherwise, if the Group field in the public key request is a group that is supported by the
responding AP, the AP shall reply with a public key of the same group as the request, generating such a key
pair if required, and setting the Public Key Frame Usage field to “Response”. The receiving AP shall
2085
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
generate a PMK and a mesh PMKSA, see below, and terminate the PeerKey protocol. If the group field in
the public key request is not supported by the responding AP, the responding AP shall respond with a Public
Key frame, setting the Public Key Frame Usage field to “NAK” and the group set to a group acceptable by
the receiving AP.
If the initiating AP does not receive a response to its request after five seconds, it should retransmit its
request. The initiating AP should attempt such retransmission a minimum of five times.
If the initiating AP receives a Public Key frame from a peer AP with the Public Key Frame Usage field set to
“NAK”, the initiating AP inspects the group field in the received “NAK”. If the group is supported, the
initiating AP should initiate to the peer AP using the indicated group. If the group is not supported, the AP
may choose to initiate to the peer AP using a different group from the dot11RSNAConfigDLCGroup table.
Receipt of a Public Key frame from a peer AP with the Public Key Frame Usage field set to “NAK”
terminates the PeerKey protocol.
If the initiating AP receives a Public Key frame from a peer AP with the Public Key Frame Usage field set to
“Refused”, the initiating AP shall terminate the PeerKey protocol.
An initiating AP that receives a refusal should delay sending another request for at least 5 seconds, and
should perform exponential back-off on all subsequent requests by doubling the delay with each subsequent
refusal.
NOTE—This standard does not specify a limit on the number of attempts an initiating AP makes to communicate with
another AP.
If the initiating AP receives a Public Key frame from a peer AP with the Public Key Frame Usage field set to
“Response” and the group set to the value in the initiating AP’s “Request”, the initiating AP shall generate a
PMK and a mesh PMKSA. This terminates the PeerKey protocol.
If the initiating AP receives a Public Key frame from a peer AP with the Public Key Frame Usage field set to
“Request” prior to receiving a “Response”, it checks the Group field in the request. If the Group in the
received “Request” is the same as the Group the initiating AP sent it its request, the AP shall construct a
Public Key frame with the Public Key Frame Usage field set to “Response” containing the public key it sent
in its “Request” and transmit it to the peer. The AP shall then generate a PMK and a mesh PMKSA, see
below, and terminate the PeerKey protocol. If the Group field differs and the group indicated is supported,
the AP shall respond to the peer AP by replying with a public key from that group, generating a key pair if
required, and setting the Public Key Frame Usage field to “Response”. The AP shall generate a PMK and a
mesh PMKSA, see below, and terminate this run of the PeerKey protocol.
Once the AP and peer AP have exchanged public keys from the same finite cyclic group they can compute
the Diffie-Hellman shared secret using scalar-op() and function F from 12.4.4:
k = F(scalor-op(d,Qp)) (12-2)
where
d is the private key of the AP that is calculating k
Qp is the public key of the peer AP
Entropy of the shared secret shall then be extracted using function H to produce keyseed using Equation (12-
3).
keyseed = H(<0>32, k) (12-3)
2086
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
<0>32 denotes 32 octets of the value zero
The PMK shall be derived according to Equation (12-4), and the PMKID shall be derived according to
Equation (12-5).
PMK = KDF-Hash-256(keyseed, "AP Peerkey Protocol",
0x00 || Max(LOCAL-MAC, PEER-MAC) || Min(LOCAL-MAC, PEER-MAC) ) (12-4)
PMKID = Truncate-128(SHA-256(Q1 || Q2 ||
Max(LOCAL-MAC, PEER-MAC) ||
Min(LOCAL-MAC, PEER-MAC)) (12-5)
where
KDF-Hash-256 is the key derivation function defined in 12.7.1.7.2 using the hash algorithm identified
by the AKM suite selector (see Table 9-133)
0x00 is a single octet with a value of zero
LOCAL-MAC is the AP’s MAC address
PEER-MAC is the peer AP’s MAC address
Q1 is the public key used by AP1 in the AP PeerKey protocol encoded as an octet stream
using the Element to Octet string conversion from 12.4.7.2.3.
Q2 is the public key used by AP2 in the AP PeerKey protocol encoded as an octet stream
using the Element to Octet string conversion from 12.4.7.2.3.
AP1 is the AP whose MAC address equals Max(LOCAL-MAC, PEER-MAC)
AP2 is the AP whose MAC address equals Min(LOCAL-MAC, PEER-MAC)
The Max and Min operations for IEEE 802 addresses are with the address converted to a positive integer
treating the first octet as the most significant octet of the integer.
keyseed shall be irretrievably deleted after the PMK is generated.
The lifetime of the mesh PMKSA shall be set to the value dot11RSNAConfigPMKLifetime.
Upon creation of the PMK, an AEK shall be created per 14.5.7. The mesh PMKSA for this instance of the
AP PeerKey protocol shall then be created using the AP’s MAC address as the STA’s MAC address, the
peer AP’s MAC address as the peer STA’s MAC address, the AEK, the lifetime, and the PMKID. If a mesh
PMKSA created by a prior run of the AP PeerKey protocol exists it shall be deleted upon creation of the new
PMKSA. All mesh TKSAs created by the old mesh PMKSA shall also be deleted.
Upon creation of the mesh PMKSA, the APME protocol (as defined in 14.5 shall be used to prove
possession of the PMK (and implicitly the private key that corresponds to the peer’s public key) and
generate the mesh TKSA.
Note that it is possible for two APs which simultaneously initiated to each other with different, but
acceptable, groups to end up with two mesh PMKSAs. In this unlikely case, the mesh PMKSA from a group
with the largest prime in its domain parameter set shall be used with the AMPE protocol. The other mesh
PMKSA shall be deleted.
2087
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the AMPE protocol completes successfully, Protected HCCA TXOP Advertisement frames and Protected
HCCA TXOP Response frames may be used in the HCCA TXOP negotiation procedures, as defined in
11.28.3 using the MTK from the mesh TKSA. If the AMPE procedure completes successfully, Protected
QLoad Request frames and Protected QLoad Report frames may be used in the QLoad report procedures, as
defined in 11.28.2 using the MTK from the mesh TKSA. If the AMPE protocol fails, the peer’s public key,
PMK, and PMKSA shall be deleted.
NOTE—The PMK, as well as any key derived from it, is not authenticated in any way nor is it bound to any identity.
This protocol protects an AP that cooperates in scheduling its HCCA TXOPs using Protected HCCA TXOP
Advertisement frames because no other entity knows its private key and cannot forge Protected HCCA
TXOP Advertisement frames. An AP that receives a Protected HCCA TXOP Advertisement frame is assured it was sent
by the holder of a particular private key, and no one else, and can, therefore, establish which APs are cooperating in their
HCCA TXOP scheduling. An AP that receives a Protected QLoad Report frame is assured it was sent by the holder of a
particular private key, and no other STA, and can, therefore, establish which APs are correctly reporting their QoS load.
2088
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13. Fast BSS transition
13.1 Overview
Fast BSS transition seeks to reduce the length of time that connectivity is lost between a STA and the DS
during a BSS transition. The FT protocols are part of the reassociation service and only apply to STA
transitions between APs within the same mobility domain within the same ESS.
The FT protocols require information to be exchanged during the initial association (or a later reassociation)
between a STA (known as the FT Originator (FTO)) and AP. The initial exchange is referred to as the FT
initial mobility domain association. Subsequent reassociations to APs within the same mobility domain may
make use of the FT protocols.
Two FT protocols are defined:
— FT protocol. This protocol is executed when an FTO makes a transition to a target AP and does not
require a resource request prior to its transition.
— FT resource request protocol. This protocol is executed when an FTO requires a resource request
prior to its transition.
For an FTO to move from its current AP to a target AP utilizing the FT protocols, the message exchanges are
performed using one of two methods:
— Over-the-Air. The FTO communicates directly with the target AP using IEEE 802.11 authentication
with the FT authentication algorithm.
— Over-the-DS. The FTO communicates with the target AP via the current AP. The communication
between the FTO and the target AP is carried in FT Action frames between the FTO and the current
AP. Between the current AP and target AP, communication is via an encapsulation method
described in 13.10.3. The current AP converts between the two encapsulations.
APs advertise both capabilities and policies for supporting the FT protocols and methods.
Throughout this clause, the notation Authentication-Request refers to an Authentication frame with the
Authentication Transaction Sequence Number field equal to 1; Authentication-Response refers to an
Authentication frame with the Authentication Transaction Sequence Number field equal to 2;
Authentication-Confirm refers to an Authentication frame with the Authentication Transaction Sequence
Number field equal to 3; Authentication-Ack refers to an Authentication frame with the Authentication
Transaction Sequence Number field equal to 4. The first parameter to the above four messages is the
authentication algorithm, such as Open System authentication algorithm (i.e., Open in figures in this clause)
or FT authentication algorithm (i.e., FTAA in figures in this clause).
13.2 Key holders
13.2.1 Introduction
The FT key holder architecture, shown in Figure 13-1, describes the FT key management entities and is
defined in the context of the IEEE 802.11 basic reference model (see Figure 4-19 in 4.9).
The R0KH and R1KH are part of AP’s SME RSNA key management. The computation of PMK-R0 and
PMK-R1, and all of the intermediate results in the computations, shall be restricted to the R0KH. The
computation of PTK, and all intermediate results in its computation, shall be restricted to the R1KH.
2089
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RSNA Key
Management
R0KH/S0KH
R1KH/S1KH
Figure 13-1—FT key holder architecture
The S0KH and S1KH are part of the FTO’s SME RSNA key management. The computation of PMK-R0 and
PMK-R1, and all of the intermediate results in the computations, shall be restricted to the S0KH. The
computation of PTK, and all intermediate results in its computation, shall be restricted to the S1KH.
13.2.2 Authenticator key holders
The R0KH and R1KH are responsible for the derivation of keys in the FT key hierarchy. For fast BSS
transition, the functions of the IEEE 802.1X Authenticator are distributed among the R0KH and R1KHs.
The R0KH interacts with the IEEE 802.1X Authenticator to receive the MSK resulting from an EAP
authentication. The R1KH interacts with the IEEE 802.1X Authenticator to open the Controlled Port. Both
the R0KH and R1KH interactions with the IEEE 802.1X Authenticator occur within the SME.
The R0KH derives the PMK-R0 for use in the mobility domain utilizing the MSK (when the AKM
negotiated is 00-0F-AC:3), the PSK (when the AKM negotiated is 00-0F-AC:4) or the PMK (when the
AKM negotiated is 00-0F-AC:9). The R0KH shall be responsible for deriving a PMK-R1 for each R1KH
within the mobility domain.
The R1KH and S1KH each derive the PTK.
Each R0KH-ID and R1KH-ID is assumed to be expressed as a unique identifier within the mobility domain.
This identifier is communicated to the FTO and other key holders. The R0KH-ID is bound into the PMK-R0
derivation and the R1KH-ID is bound into the PMK-R1 derivation.
The R0KH shall meet the following requirements:
— The R0KH shall be collocated with the network access server (NAS) Client functionality of the
IEEE 802.1X Authenticator.
— The R0KH-ID shall be set to the identity of the co-resident NAS Client (e.g., NAS-Identifier as
defined in IETF RFC 2865 if RADIUS is used as the backend protocol). R0KH-ID shall not be
longer than 48 octets to fit in the length limitation of the FTE.
— When the PMK-R0 lifetime expires, the R0KH shall delete the PMK-R0 security association and
shall revoke within the R0KH all PMK-R1s derived from the PMK-R0.
— The R0KH shall not expose the PMK-R0 to other parties.
— The R0KH shall not expose the PMK-R1 to parties other than the authorized R1KH.
2090
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The R1KH shall meet the following requirements:
— The R1KH-ID shall be set to a MAC address of the physical entity that stores the PMK-R1 and uses
it to generate the PTK. That same MAC address shall be used to advertise the PMK-R1 identity to
the STA and the R0KH.
— The R1KH shall derive and distribute the GTK and IGTK to all connected STAs.
— When the PMK-R1 lifetime expires, the R1KH shall delete the PMK-R1 PMKSA and shall revoke
all PTKSAs derived from the PMK-R1 using the MLME-DELETEKEYS primitive.
— The R1KH shall not expose the PMK-R1 to other parties.
dot11FTR0KeyHolderID and dot11FTR1KeyHolderID shall contain the values of R0KH-ID and R1KH-ID
as defined in this clause, respectively.
The R0KH and the R1KH are assumed to have a secure channel between them that can be used to exchange
cryptographic keys without exposure to any intermediate parties. The cryptographic strength of the secure
channel between the R0KH and R1KH is assumed to be greater than or equal to the cryptographic strength
of the channels for which the keys are used. This standard assumes that the key transfer includes the PMK-
R1, the PMK-R1 PMKSA, the PMK-R1 context, and the associated key authorizations. The protocol for
distribution of keying material from the R0KH to the R1KH is outside the scope of this standard.
The PMK-R1 distribution from the R0KH to the R1KHs within the same mobility domain shall satisfy the
following assumptions:
— The R0KH authenticates a potential R1KH with the same identity as is included in the PMK-R1
derivation. The cryptographic strength of the authentication is assumed to be greater than or equal to
the cryptographic strength of the authentication between the Supplicant and AS.
— The authorization of holding a PMK-R1 is based on the authentication of the R1KH.
— The protected channel provides confidentiality and integrity protection.
13.2.3 Supplicant key holders
The S0KH and S1KH are responsible for the derivation of keys in the FT key hierarchy. The S0KH and
S1KH are entities that are assumed to physically reside in the Supplicant.
The S0KH interacts with the IEEE 802.1X functional block (see Figure 4-19 in 4.9) to receive the MSK
resulting from an EAP authentication. The S1KH interacts with the IEEE 802.1X entity to open the
Controlled Port. Both the S0KH and S1KH interactions with the IEEE 802.1X entity occur within the SME
of a STA.
The S0KH derives the PMK-R0 for use in the mobility domain utilizing the MSK (when the AKM
negotiated is 00-0F-AC:3), the PSK (when the AKM negotiated is 00-0F-AC:4) or the PMK (when the
AKM negotiated is 00-0F-AC:9).
The S1KH shall derive the PTK mutually with the R1KH.
The S0KH and S1KH shall be identified by the SPA. The S0KH shall not expose the PMK-R0 to other
parties and shall not expose the PMK-R1 to parties other than the authorized S1KH. The S1KH shall not
expose the PMK-R1 to other parties.
2091
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.3 Capability and policy advertisement
The FT capability is advertised in the Beacon and Probe Response frames by including the MDE. The MDE
is advertised in the Beacon and Probe Response frames to indicate the MDID, FT capability, and the FT
policy.
The MDID field shall be dot11FTMobilityDomainID. The Fast BSS Transition Policy bits in the MDE, i.e.,
Fast BSS Transition over DS subfield and Resource Request Protocol Capability subfield, shall be set by
dot11FTOverDSActivated and dot11FTResourceRequestSupported, respectively.
NOTE—It is assumed by this standard that the Fast BSS Transition Policy bits in the MDE are administered consistently
across the mobility domain.
The capability is advertised in the Neighbor Report element. See 11.11 and 9.4.2.37.
If an FTE is included in a Request element in a Probe Request frame, the FTE in the Probe Response frame
shall contain the R0KH-ID and R1KH-ID (from dot11FTR0KeyHolderID and dot11FTR1KeyHolderID),
and all other fields shall be set to 0.
13.4 FT initial mobility domain association
13.4.1 Overview
The FT initial mobility domain association is the first (re)association in the mobility domain, where the
SME of the STA enables its future use of the FT procedures.
FT initial mobility domain association is typically the first association within the ESS. In addition to
Association frames, Reassociation frames are supported in the initial mobility domain association to enable
both FT and non-FT APs to be present in a single ESS.
13.4.2 FT initial mobility domain association in an RSN
A STA indicates its support for the FT procedures by including the MDE in the (Re)Association Request
frame and indicates its support of security by including the RSNE. The AP responds by including the FTE,
MDE, and RSNE in the (Re)Association Response frame. After a successful IEEE 802.1X authentication (if
needed) or SAE authentication, the STA and AP perform an FT 4-way handshake. At the end of the
sequence, the IEEE 802.1X Controlled Port is opened, and the FT key hierarchy has been established. The
message flow is shown in Figure 13-2.
A non-DMG STA initiates the FT initial mobility domain association procedures by performing an
IEEE 802.11 authentication using the Open System authentication algorithm.
STA AP: Authentication-Request (Open System authentication algorithm)
AP STA: Authentication-Response (Open System authentication algorithm, Status)
A DMG STA initiates the FT initial mobility domain association procedures by performing an IEEE 802.11
authentication using the SAE algorithm.
STA AP: Authentication-Request (SAE algorithm)
AP STA: Authentication-Response (SAE algorithm, Status)
The SME of the STA initiates the authentication exchange, through the use of the MLME-
AUTHENTICATE.request primitive, and the SME of the AP responds with MLME-
AUTHENTICATE.response primitive. See 11.3.4.
2092
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA AP
802.11 Authentication-Request (Open)
802.11 Authentication-Response (Open)
(Re)Association Request (MDE, RSNE)
(Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID])
802.1X EAP Authentication (bypassed if PSK is used)
EAPOL-Key (0, 0, 1, 0, P, 0, ANonce, 0)
EAPOL-Key (0, 1, 0, 0, P, 0, SNonce, MIC, RSNE[PMKR1Name], MDE, FTE)
EAPOL-Key (1, 1, 1, 1, P, 0, ANonce, MIC, RSNE[PMKR1Name], MDE, GTK[N],
IGTK[M], FTE, TE[ReassociationDeadline], TE[KeyLifetime])
EAPOL-Key (1, 1, 0, 0, P, 0, 0, MIC)
802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission
QoS Resource Allocations
Figure 13-2—FT initial mobility domain association in an RSN
Upon successful IEEE 802.11 Open System authentication, (if the suite type is 00-0F-AC:3 or 00-0F-AC:4)
or SAE authentication (if the suite type is 00-0F-AC:9), the STA shall send a (Re)Association Request frame
to the AP that includes the MDE. The contents of the MDE shall be the values advertised by the AP in its
Beacon or Probe Response frames. Additionally, the STA includes its security capabilities in the RSNE.
STA AP: (Re)Association Request (MDE, RSNE)
AP STA: (Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID])
The SME of the STA initiates the (re)association through the use of the MLME-ASSOCIATE.request or
MLME-REASSOCIATE.request primitive. The SME of the AP responds to the indication with MLME-
ASSOCIATE.response or MLME-REASSOCIATE.response primitive. See 11.3.5.
If the contents of the MDE received by the AP do not match the contents advertised in the Beacon and Probe
Response frames, the AP shall reject the (Re)Association Request frame with status code
STATUS_INVALID_MDE. If an MDE is present in the (Re)Association Request frame and the contents of
the RSNE do not indicate a negotiated AKM of fast BSS transition (suite type 00-0F-AC:3, 00-0F-AC:4, or
00-0F-AC:9), the AP shall reject the (Re)Association Request frame with status code
STATUS_INVALID_AKMP.
The (Re)Association Response frame from the AP shall contain an MDE, with contents as presented in
Beacon and Probe Response frames. The FTE shall include the key holder identities of the AP, the R0KH-ID
and R1KH-ID, set to the values of dot11FTR0KeyHolderID and dot11FTR1KeyHolderID, respectively. The
FTE shall have a MIC element count of zero (i.e., no MIC present) and have ANonce, SNonce, and MIC
fields set to 0.
On successful (re)association, the S0KH on the STA and the R0KH on the AP then proceed with an
IEEE 802.1X authentication using EAPOL frames carried in IEEE 802.11 Data frames if SAE
authentication was not performed (i.e., if the suite type is not 00-0F-AC:9). The S0KH shall use the value of
2093
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
R0KH-ID as the endpoint identifier of the NAS Client (NAS-Identifier if RADIUS is used) in the exchange
as defined in IETF RFC 3748 [B42].
If IEEE 802.1X authentication was performed, then upon successful completion of authentication, the
R0KH receives the MSK and authorization attributes. If SAE authentication was performed, the R0KH
receives the PMK, resulting in the successful completion of SAE. If a key hierarchy already exists for this
STA belonging to the same mobility domain (i.e., having the same MDID), the R0KH shall delete the
existing PMK-R0 security association and PMK-R1 security associations. It then calculates the PMK-R0,
PMKR0Name, and PMK-R1 and makes the PMK-R1 available to the R1KH of the AP with which the STA
is associated.
If the SME of the STA cannot authenticate the AS, then it shall disassociate with an MLME-
DISASSOCIATE.request primitive. If the AS signals the Authenticator that the STA cannot be
authenticated, then the SME of the AP shall disassociate with an MLME-DISASSOCIATE.request
primitive.
If the MSK lifetime attribute is provided by the AS, the lifetime of the PMK-R0 shall not be more than the
lifetime of the MSK. If the MSK lifetime attribute is not provided, the PMK-R0 lifetime shall be
dot11FTR0KeyLifetime. For PSK, the PMK-R0 lifetime shall be dot11FTR0KeyLifetime. The lifetime of
the PMK-R1s and PTK shall be the same as the lifetime of PMK-R0. When the key lifetime expires, each
key holder shall delete its respective PMK-R0, PMK-R1, and PTK SAs.
The R1KH and S1KH then perform an FT 4-way handshake. The EAPOL-Key frame notation is defined in
12.7.4.
R1KH S1KH: EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0)
S1KH R1KH: EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, RSNE[PMKR1Name], MDE, FTE)
R1KH S1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, RSNE[PMKR1Name], MDE,
GTK[N], IGTK[M], FTE, TIE[ReassociationDeadline],
TIE[KeyLifetime])
S1KH R1KH: EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC)
The message sequence is described in 12.7.6.
It is assumed by this standard that the reassociation deadline is administered consistently across the mobility
domain. The mechanism for such consistent administration is outside the scope of this standard.
The PTK shall be calculated by the R1KH and S1KH according to the procedures given in 12.7.1.7.5.
Upon completion of a successful FT 4-way handshake, the IEEE 802.1X Controlled Port shall be opened on
both the non-AP STA and the AP. Subsequent EAPOL-Key frames shall use the key replay counter to detect
replayed messages.
Upon completion of a successful FT 4-way handshake, the PTK lifetime timer is initiated. The operation of
this timer prevent the PTKSA being used for longer than the value provided in the TIE[KeyLifetime] sent in
message 3.
Once the PTKSA key lifetime expires, as indicated by the TIE[KeyLifetime], to continue its association in
the mobility domain the STA shall perform the FT initial mobility domain association procedures. If the AP
sends a Deauthentication or Disassociation frame to the STA with reason code
INVALID_AUTHENTICATION, then to continue its association in the mobility domain, the STA shall
perform the FT initial mobility domain association procedures with any AP in the mobility domain. If the
Supplicant EAPOL state machines are triggered to send an EAPOL-Start frame after a successful initial
mobility domain association, the STA shall perform the FT initial mobility domain association procedures.
2094
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.4.3 FT initial mobility domain association in a non-RSN
In this sequence, the STA utilizes the FT procedures by including the MDE in the (Re)Association Request
frame. The AP responds by including the MDE in the (Re)Association Response frame. The message flow is
shown in Figure 13-3.
STA AP
802.11 Authentication-Request (Open)
802.11 Authentication-Response (Open)
(Re)Association Request (MDE)
(Re)Association Response (MDE)
Successful Session & Data Transmission
QoS Resource Allocations
Figure 13-3—FT initial mobility domain association in a non-RSN
The STA initiates the FT initial mobility domain association procedures by performing an IEEE 802.11
authentication using the Open System authentication algorithm.
STA AP: Authentication-Request (Open System authentication algorithm)
AP STA: Authentication-Response (Open System authentication algorithm, Status)
The SME of the STA initiates the authentication exchange through the use of the primitive MLME-
AUTHENTICATE.request primitive, and the SME of the AP responds with MLME-
AUTHENTICATE.response primitive. See 11.3.4.
Upon successful IEEE 802.11 Open System authentication, the STA shall send a (Re)Association Request
frame to the AP and shall include the MDE. The contents of the MDE shall be the values advertised by the
AP in its Beacon or Probe Response frames.
STA AP: (Re)Association Request (MDE)
AP STA: (Re)Association Response (MDE)
The SME of the STA initiates the (re)association through the use of the MLME-ASSOCIATE.request or
MLME-REASSOCIATE.request primitive. The SME of the AP responds to the indication with MLME-
ASSOCIATE.response or MLME-REASSOCIATE.response primitive. See 11.3.5.
If the contents of the MDE received by the AP do not match the contents advertised in the Beacon and Probe
Response frames, the AP shall reject the (Re)Association Request frame with status code
STATUS_INVALID_MDE.
The (Re)Association Response frame from the AP shall contain an MDE, with contents as presented in
Beacon and Probe Response frames.
2095
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
On successful (re)association, the AP and the non-AP STA shall transition to State 4 (as defined in 11.3) to
enable Data frame transmission.
13.5 FT protocol
13.5.1 Overview
STAs with dot11FastBSSTransitionActivated equal to true shall support the FT protocol.
The FT protocol supports resource requests as part of the reassociation. The optional FT resource request
protocol (see 13.6) supports resource requests prior to reassociation.
A STA shall not use any authentication algorithm except the FT authentication algorithm when using the FT
protocol.
13.5.2 Over-the-air FT protocol authentication in an RSN
The over-the-air FT protocol in an RSN is shown in Figure 13-4.
Current Target
FTO
AP AP
Successful (secure) session & Data transmission
FTO determines it needs to transition to the Target AP
802.11 Authentication-Request (FTAA, RSNE[PMKR0Name], MDE,
FTE[SNonce, R0KH-ID])
802.11 Authentication-Response (FTAA, RSNE[PMKR0Name], MDE,
FTE[ANonce, SNonce, R1KH-ID, R0KH-ID])
A successful Reassociation occurs only when the time between the
Authentication-Request and the Reassociation Request does not exceed the
Reassociation Deadline Time
Reassociation Request (RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request)
Reassociation Response (RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N]], IGTK[M], RIC-Response)
802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission
Figure 13-4—Over-the-air FT protocol in an RSN
The FTO and AP use the FT authentication sequence to specify the PMK-R1 security association and to
provide values of SNonce and ANonce that enable a liveness proof, replay protection, and PTK separation.
This exchange enables a fresh PTK to be computed in advance of reassociation. The PTKSA is used to
protect the subsequent reassociation transaction, including the optional RIC-Request.
2096
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
To perform an over-the-air fast BSS transition to a target AP, the FTO and target AP shall perform the
following exchange:
FTO Target AP: Authentication-Request (FTAA, 0, RSNE[PMKR0Name], MDE, FTE[SNonce,
R0KH-ID])
Target AP FTO: Authentication-Response (FTAA, Status, RSNE[PMKR0Name], MDE,
FTE[ANonce, SNonce, R1KH-ID, R0KH-ID])
The SME of the FTO initiates the authentication exchange, through the use of the MLME-
AUTHENTICATE.request primitive, and the SME of the AP responds with an MLME-
AUTHENTICATE.response primitive. See 11.3.4. The MLME primitives for Authentication when the FT
authentication algorithm is selected use only authentication transaction sequence number values 1 and 2.
In the Authentication-Request frame, the SA field of the message header shall be set to the MAC address of
the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. The elements in
the frame, and their required contents, shall be as given in 13.8.2.
If the contents of the MDE received by the AP do not match the contents advertised in the Beacon and Probe
Response frames, the AP shall reject the authentication request with status code STATUS_INVALID_MDE.
If the Authentication-Request frame contains an authentication algorithm equal to FT authentication and the
contents of the RSNE do not indicate a negotiated AKM of fast BSS transition (suite type 00-0F-AC:3 or 00-
0F-AC:4), the AP shall reject the authentication request with status code STATUS_INVALID_AKMP. If the
FTE in the FT Request frame contains an invalid R0KH-ID, the AP shall reject the FT Request frame with
status code STATUS_INVALID_FTE. If the RSNE in the Authentication-Request frame contains an invalid
PMKR0Name and the AP has determined that it is an invalid PMKR0Name, the AP shall reject the
authentication request with status code STATUS_INVALID_PMKID. If the requested R0KH is not
reachable, the AP shall respond to the authentication request with status code R0KH_UNREACHABLE. If
the FTO selects a pairwise cipher suite in the RSNE that is different from the ones used in the Initial
mobility domain association, then the AP shall reject the authentication request with status code
STATUS_INVALID_PAIRWISE_CIPHER. Subsequent to a rejection of an authentication request, the FTO
may retry the authentication request.
In the Authentication-Response frame, the SA field of the message header shall be set to the BSSID of the
target AP, and the DA field of the message header shall be set to the MAC address of the FTO. The Status
Code field shall be a value from the options listed in 9.4.1.9. The elements in the frame, and their required
contents, shall be as given in 13.8.3.
The R1KH of the target AP uses the value of PMKR0Name and other information in the frame to calculate
PMKR1Name. If the target AP does not have the key identified by PMKR1Name, it may retrieve that key
from the R0KH identified by the FTO. See 13.2. Upon receiving a new PMK-R1 for a STA, the target AP
shall delete the prior PMK-R1 security association and PTKSAs derived from the prior PMK-R1.
The FTO and the target AP compute the PTK and PTKName using the PMK-R1, PMKR1Name, ANonce,
and SNonce, as specified in 12.7.1.7.5. The PTKSA shall be deleted by the target AP if it does not receive a
Reassociation Request frame from the FTO within the reassociation deadline timeout value.
If the FTO does not receive a response to the Authentication-Request frame, it may reissue the request
following the restrictions given for Authentication frames in 11.3. If the Status Code field value returned by
the target AP is SUCCESS, the FTO and target AP transition to State 2 (as defined in 11.3); the FTO may
continue with reassociation (13.7.1). Handling of errors returned in the Status Code field shall be as
specified in 11.3.
2097
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.5.3 Over-the-DS FT protocol in an RSN
A STA shall not initiate an over-the-DS FT authentication to a target AP whose MDE contains the Fast BSS
Transition over DS bit equal to 0.
The over-the-DS FT protocol in an RSN is shown in Figure 13-5.
Current Target
FTO
AP AP
Successful (secure) session & Data transmission
FTO determines it needs to transition to the Target AP
FT Request (FTO, TargetAP, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID])
FT Response (FTO, TargetAP, RSNE[PMKR0Name], MDE,
FTE[ANonce, SNonce, R1KH-ID, R0KH-ID])
A successful Reassociation occurs only when the time between the
FT Request and the Reassociation Request does not exceed the Reassociation
Deadline Time
Reassociation Request (RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request)
Reassociation Response(RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N]], IGTK[M], RIC-Response)
802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission
Figure 13-5—Over-the-DS FT protocol in an RSN
To perform an over-the-DS fast BSS transition to a target AP, the FTO and the target AP (through the current
AP) shall perform the following exchange:
FTO Target AP: FT Request (FTO address, TargetAP address, RSNE[PMKR0Name], MDE,
FTE[SNonce, R0KH-ID])
Target AP FTO: FT Response (FTO address, TargetAP address, Status, RSNE[PMKR0Name],
MDE, FTE[ANonce, SNonce, R1KH-ID, R0KH-ID])
The SME of the FTO initiates the FT Request frame to the target AP by issuing an MLME-REMOTE-
REQUEST.request primitive with parameters including the contents of the FT Request frame (FT Action
frame with an FT Action field value indicating FT Request) to be sent. The MAC of the FTO transmits this
Action frame. For processing at the current AP and target AP, see 13.10. When the MAC of the FTO
receives the FT Response frame (FT Action frame with an FT Action field value indicating FT Response), it
passes it to the SME by use of MLME-REMOTE-REQUEST.indication primitive, with parameters
including the contents of the received Action frame. The MLME interfaces on the FTO, current AP, and the
target AP for executing the over-the-DS fast BSS transition are shown in Figure 13-6.
The STA Address field of the FT Request frame shall be set to the MAC address of the FTO, and the Target
AP Address field of the FT Request frame shall be set to the BSSID of the target AP. The elements in the FT
Request frame, and their required contents, shall be as given in 13.8.2.
2098
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
FTO Current AP Target AP
SME MAC MAC SME MAC SME
MLME-REMOTE-REQUEST.request
FT Action Request (elements)
MLME-REMOTE-REQUEST.indication
RemoteRequest (elements)
Target AP processes
RemoteResponse (elements) the request
FT Action Response MLME-REMOTE-REQUEST.request
(elements)
MLME-REMOTE-REQUEST.indication
MLME-REASSOCIATE.request
Reassociation Request
(elements)
MLME-REASSOCATE.indication
Reassociation Response MLME-REASSOCATE.response
(elements)
MLME-REASSOCIATE.confirm
Figure 13-6—MLME interfaces for over-the-DS FT protocol messages
If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and
Probe Response frames, the target AP shall reject the FT Request frame with status code
STATUS_INVALID_MDE. If the contents of the RSNE do not indicate a negotiated AKM of fast BSS
transition (suite type 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9), the AP shall reject the FT Request frame
with status code STATUS_INVALID_AKMP. If the FTE in the FT Request frame contains an invalid
R0KH-ID, the AP shall reject the FT Request frame with status code STATUS_INVALID_FTE. If the RSNE
in the FT Request frame contains an invalid PMKR0Name, and the AP has determined that it is an invalid
PMKR0Name, the AP shall reject the authentication request with status code STATUS_INVALID_PMKID.
If the requested R0KH is not reachable, the AP shall respond to the FT Request frame with status code
R0KH_UNREACHABLE. The AP may reject the FT Request frame for limiting the FTO’s reassociation to
this AP by using the status code REQUEST_DECLINED. If the FTO selects a pairwise cipher suite in the
RSNE that is different from the ones used in the initial mobility domain association, then the AP shall reject
the FT Request frame with status code STATUS_INVALID_PAIRWISE_CIPHER.
The STA Address field of the FT Response frame shall be set to the MAC address of the FTO, and the Target
AP Address field of the FT Response frame shall be set to the BSSID of the target AP. The elements in the
FT Response frame, and their required contents, shall be as given in 13.8.3. The Status Code field shall be a
value from the options listed in 9.4.1.9.
The R1KH of the target AP uses the value of PMKR0Name and other information from the frame to
calculate PMKR1Name. If the target AP does not have the key identified by PMKR1Name, it may retrieve
that key from the R0KH identified by the STA. See 13.2. Upon receiving a new PMK-R1 for a STA, the
target AP shall delete the prior PMK-R1 security association and PTKSAs derived from the prior PMK-R1.
2099
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The FTO and the target AP compute the PTK and PTKName using the PMK-R1, PMKR1Name, ANonce,
and SNonce, as specified in 12.7.1.7.5. The PTKSA shall be deleted by the target AP if it does not receive a
Reassociation Request frame from the FTO within the reassociation deadline timeout value.
If the FTO does not receive a response to the FT Request frame, it may reissue the request following the
restrictions given for Authentication frames in 11.3. If the Status Code field value returned by the target AP
is SUCCESS, the FTO and target AP transition to State 2 (as defined in 11.3); the FTO may continue with
reassociation (13.7.1). Handling of errors returned in the Status Code field shall be as specified for
Authentication frames in 11.3.
13.5.4 Over-the-air FT protocol in a non-RSN
The over-the-air FT protocol in a non-RSN is shown in Figure 13-7.
Current Target
FTO
AP AP
Successful session & Data transmission
FTO determines it needs to transition to the Target AP
802.11 Authentication-Request (FTAA, MDE)
802.11 Authentication-Response (FTAA, MDE)
Reassociation Request (MDE, RIC-Request)
Reassociation Response (MDE, RIC-Response)
Successful Session & Data Transmission
Figure 13-7—Over-the-air FT protocol in a non-RSN
To perform an over-the-air fast BSS transition to a target AP in a non-RSN, the FTO and target AP shall
perform the following exchange:
FTO Target AP: Authentication-Request (FTAA, 0, MDE)
Target AP FTO: Authentication-Response (FTAA, Status, MDE)
In the Authentication-Request frame, the SA field of the message header shall be set to the MAC address of
the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. The elements in
the frame, and their required contents, shall be as given in 13.8.2.
If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and
Probe Response frames, the target AP shall reject the authentication request with status code
STATUS_INVALID_MDE.
In the Authentication-Response frame, the SA field of the message header shall be set to the BSSID of the
target AP, and the DA field of the message header shall be set to the MAC address of the FTO. The Status
Code field shall be a value from the options listed in 9.4.1.9. The elements in the frame, and their required
contents, shall be as given in 13.8.3.
2100
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the FTO does not receive a response to the Authentication-Request frame, it may reissue the request
following the restrictions given for Authentication frames in 11.3. If the Status Code field value returned by
the target AP is SUCCESS, the FTO and target AP transition to State 2 (as defined in 11.3); the FTO may
continue with reassociation (13.7.2). Handling of errors returned in the Status Code field shall be as
specified in 11.3.
13.5.5 Over-the-DS FT protocol in a non-RSN
The over-the-DS FT protocol in a non-RSN is shown in Figure 13-8.
Current Target
FTO
AP AP
Successful session & Data transmission
FTO determines it needs to transition to the Target AP
FT Request (FTO, Target AP, MDE)
FT Response (FTO, Target AP, MDE)
Reassociation Request (MDE, RIC-Request)
Reassociation Response (MDE, RIC-Response)
Successful Session & Data Transmission
Figure 13-8—Over-the-DS FT protocol in a non-RSN
To perform an over-the-DS fast BSS transition to a target AP in a non-RSN, the FTO and the target AP
(through the current AP) shall perform the following exchange:
FTO Target AP: FT Request(FTO, TargetAP, MDE)
Target AP FTO: FT Response(FTO, TargetAP, Status, MDE)
The STA Address field of the FT Request frame shall be set to the MAC address of the FTO, and the Target
AP Address field of the FT Request frame shall be set to the BSSID of the target AP. The elements in the FT
Request frame, and their required contents, shall be as given in 13.8.2.
If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and
Probe Response frames, the target AP shall reject the FT Request frame with status code
STATUS_INVALID_MDE.
The STA Address field of the FT Response frame shall be set to the MAC address of the FTO, and the Target
AP Address field of the FT Response frame shall be set to the BSSID of the target AP. The elements in the
FT Response frame, and their required contents, shall be as given in 13.8.3. The Status Code field shall be a
value from the options listed in 9.4.1.9.
If the FTO does not receive a response to the FT Request frame, it may reissue the request following the
restrictions given for Authentication frames in 11.3. If the Status Code field value returned by the target AP
2101
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
is SUCCESS, the FTO and target AP transition to State 2 (as defined in 11.3); the FTO may continue with
reassociation (13.7.2). Handling of errors returned in the Status Code field shall be as specified for
Authentication frames in 11.3.
13.6 FT resource request protocol
13.6.1 Overview
The FT resource request protocol involves an additional message exchange after the Authentication-
Request/Response frame, or FT Request/Response frame, and prior to reassociation.
APs capable of fast BSS transition may allow FTOs to request resources prior to reassociation. Availability
of the FT resource request protocol is advertised by the target AP in the MDE. If the Resource Request
Protocol Capability subfield is 0, then the FTO shall not send an Authentication-Confirm nor FT Confirm
frame to the AP. An AP that receives an Authentication-Confirm or FT Confirm frame from a STA and does
not support the FT resource request protocol shall respond with status code INVALID_PARAMETERS.
The additional message exchange for the FT resource request protocol shall be performed using the same
method (over-the-air or over-the-DS) as was used for the Authentication-Request/Response frame or
FT Request/Response frame. An AP that receives an FT Confirm frame that did not previously receive an
FT Request frame from the same STA shall reject the request with status code
STATUS_INVALID_FT_ACTION_FRAME_COUNT. An AP that receives an Authentication-Confirm
frame that did not previously receive an Authentication-Request frame from the same STA shall reject the
request with status code TRANSACTION_SEQUENCE_ERROR.
13.6.2 Over-the-air fast BSS transition with resource request
The over-the-air FT resource request protocol in an RSN is shown in Figure 13-9.
The over-the-air FT resource request protocol in a non-RSN is shown in Figure 13-10.
To perform an over-the-air FT resource request protocol to a target AP, after completing the Authentication-
Request/Response frame exchange given in 13.5.2 or 13.5.4, the FTO and target AP shall perform the
following exchange:
FTO Target AP: Authentication-Confirm (FTAA, 0, RSNE[PMKR1Name], MDE, FTE[MIC,
ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request)
Target AP FTO: Authentication-Ack (FTAA, Status, RSNE[PMKR1Name], MDE, FTE[MIC,
ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Response)
The SME of the FTO initiates the resource request exchange through the use of the primitive MLME-
RESOURCE-REQUEST.request primitive, and the SME of the AP responds with MLME-RESOURCE-
REQUEST.response primitive.
In the Authentication-Confirm frame, the SA field of the message header shall be set to the MAC address of
the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. In a non-RSN,
the FTE and RSNE shall not be present. The elements in the frame, the element contents, and MIC
calculation shall be as given in 13.8.4.
If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and
Probe Response frames, the target AP shall reject the Authentication-Confirm frame with status code
STATUS_INVALID_MDE.
2102
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Current Target
FTO
AP AP
Successful (secure) session & Data transmission
FTO determines it needs to transition to the Target AP
802.11 Authentication-Request (FTAA, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID])
802.11 Authentication-Response (FTAA, RSNE[PMKR0Name], MDE,
FTE[ANonce, SNonce, R1KH-ID, R0KH-ID])
802.11 Authentication-Confirm (FTAA, RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request)
802.11 Authentication-Ack(FTAA, RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Response)
A successful Reassociation occurs only when the time between the
Authentication-Request and the Reassociation Request does not exceed the
Reassociation Deadline Time
Reassociation Request (RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID])
Reassociation Response (RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N]], IGTK[M])
802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission
Figure 13-9—Over-the-air FT resource request protocol in an RSN
Current Target
FTO
AP AP
Successful session & Data transmission
FTO determines it needs to transition to the Target AP
802.11 Authentication-Request (FTAA, MDE)
802.11 Authentication-Response (FTAA, MDE)
802.11 Authentication-Confirm (FTAA, MDE, RIC-Request)
802.11 Authentication-Ack(FTAA, MDE, TIE(ReassociationDeadline), RIC-Response)
A successful Reassociation occurs only when the time between the
Authentication-Request and the Reassociation Request does not exceed the
Reassociation Deadline Time
Reassociation Request (MDE)
Reassociation Response (MDE)
Successful Session & Data Transmission
Figure 13-10—Over-the-air FT resource request protocol in a non-RSN
2103
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In an RSN, the R1KH of the target AP verifies the MIC in the FTE in the Authentication-Confirm frame and
shall discard the request if it is incorrect. If the FTE in the Authentication-Confirm frame contains a different
R0KH-ID, R1KH-ID, ANonce, or SNonce, the AP shall reject the Authentication-Confirm frame with status
code STATUS_INVALID_FTE. If the RSNE in the Authentication-Confirm frame contains an invalid
PMKR1Name, the AP shall reject the Authentication-Confirm frame with status code
STATUS_INVALID_PMKID.
In the Authentication-Ack frame, the SA field of the message header shall be set to the BSSID of the target
AP, and the DA field of the message header shall be set to the MAC address of the FTO. In a non-RSN, the
FTE and RSNE shall not be present. The Status Code field shall be a value from the options listed in 9.4.1.9.
The elements in the frame, the element contents, and MIC calculation shall be as given in 13.8.5.
In an RSN, the S1KH of the FTO verifies the MIC in the FTE in the Authentication-Ack frame and shall
discard the response if the MIC is incorrect.
The FTO may make a request for resources by including a RIC-Request (see 13.11) in the Authentication-
Confirm frame. The RIC-Request is generated by the procedures of 13.11.3.1, and the RIC-Response is
generated by the procedures of 13.11.3.2.
If the value of the Status Code field returned by the target AP in the Authentication-Ack frame is not
SUCCESS, then the FTO shall abandon this transition attempt.
In an RSN, on successful completion of the FT authentication exchange of the FT resource request protocol,
the PTKSA has been established and proven live. The key replay counter shall be initialized to 0, and the
subsequent EAPOL-Key frames (e.g., GTK and IGTK updates) shall use the key replay counter to detect
and discard replays. The PTKSA shall be deleted by the target AP if it does not receive a Reassociation
Request frame from the FTO within the reassociation deadline timeout value.
In a non-RSN, the Authentication-Ack frame contains a TIE with a reassociation deadline. If the FTO does
not send a Reassociation Request frame to the target AP within that interval, the FTO shall abandon this
transition attempt.
The exchange between the FTO and the target AP may continue with reassociation (13.7.1 or 13.7.2).
13.6.3 Over-the-DS fast BSS transition with resource request
The over-the-DS FT resource request protocol in an RSN is shown in Figure 13-11.
The over-the-DS FT resource request protocol in a non-RSN is shown in Figure 13-12.
To perform an Over-the-DS FT resource request protocol to a target AP, after completing the FT Request/
Response frame exchange given in 13.5.3 or 13.5.5, the FTO and target AP (through the current AP) shall
perform the following exchange, using the mechanism described in 13.10:
FTO Target AP: FT Confirm (FTO, TargetAP, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce,
SNonce, R1KH-ID, R0KH-ID], RIC-Request)
Target AP FTO: FT Ack (FTO, TargetAP, Status, RSNE[PMKR1Name], MDE, FTE[MIC,
ANonce, SNonce, R1KH-ID, R0KH-ID], TIE[ReassociationDeadline],
RIC-Response)
2104
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Current Target
FTO
AP AP
Successful (secure) session & Data transmission
FTO determines it needs to transition to the Target AP
FT Request (FTO, TargetAP, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID])
FT Response (FTO, TargetAP, RSNE[PMKR0Name], MDE,
FTE[ANonce, SNonce, R1KH-ID, R0KH-ID])
FT Confirm (FTO, TargetAP, RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request)
FT ACK (FTO, TargetAP, RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], TIE(ReassociationDeadline), RIC-Response)
,
A successful Reassociation occurs only when the time between the
FT Request and the Reassociation Request does not exceed the Reassociation
Deadline Time
Reassociation Request (RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID])
Reassociation Response (RSNE[PMKR1Name], MDE,
FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N]])
802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission
Figure 13-11—Over-the-DS FT resource request protocol in an RSN
Current Target
FTO
AP AP
Successful session & Data transmission
FTO determines it needs to transition to the Target AP
FT Request (FTO, TargetAP, MDE)
FT Response (FTO, TargetAP, MDE)
FT Confirm (FTO, TargetAP, MDE, RIC-Request)
FT ACK (FTO, TargetAP, MDE, TIE(ReassociationDeadline), RIC-Response)
,
A successful Reassociation occurs only when the time between the
FT Request and the Reassociation Request does not exceed the Reassociation
Deadline Time
Reassociation Request (MDE)
Reassociation Response (MDE)
Successful Session & Data Transmission
Figure 13-12—Over-the-DS FT resource request protocol in a non-RSN
2105
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SME of the FTO initiates the FT Confirm frame to the target AP by issuing an MLME-REMOTE-
REQUEST.request primitive with parameters including the contents of the FT Confirm frame (FT Action
frame with an FT Action field value indicating FT Confirm) to be sent. The MAC of the FTO transmits this
Action frame. For processing at the current AP and target AP, see 13.10. When the MAC of the FTO
receives the FT Ack frame (FT Action frame with an FT Action field value indicating FT Ack), it passes it to
the SME by use of an MLME-REMOTE-REQUEST.indication primitive, with parameters including the
contents of the received Action frame.
The STA Address field of the FT Confirm frame shall be set to the MAC address of the FTO, and the Target
AP Address field of the FT Confirm frame shall be set to the BSSID of the target AP. The elements in the FT
Confirm frame, the element contents, and the MIC calculation shall be as given in 13.8.4. In a non-RSN, the
FTE and RSNE shall not be present.
If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and
Probe Response frames, the target AP shall reject the FT Confirm frame with status code
STATUS_INVALID_MDE.
In an RSN, the R1KH of the target AP verifies the MIC in the FTE and shall discard the request if it is
incorrect. If the FTE in the FT Confirm frame contains a different R0KH-ID, R1KH-ID, ANonce, or
SNonce from the values sent in the FT Response frame, the AP shall reject the FT Confirm frame with status
code STATUS_INVALID_FTE. If the RSNE in the FT Confirm frame contains an invalid PMKR1Name,
the AP shall reject the FT Confirm frame with status code STATUS_INVALID_PMKID.
The STA Address field of the FT Ack frame shall be set to the MAC address of the FTO, and the Target AP
Address field of the FT Ack frame shall be set to the BSSID of the target AP. The elements in the FT Ack
frame, the element contents, and the MIC calculation shall be as given in 13.8.5. In a non-RSN, the FTE and
RSNE shall not be present. The Status Code field value shall be a value from the options listed in 9.4.1.9,
and a TIE may appear.
In an RSN, the S1KH of the FTO verifies the MIC in the FTE in the FT Ack frame and shall discard the
response if the MIC is incorrect.
The FTO may make a request for resources by including a RIC-Request (see 13.11) in the FT Confirm
frame. The RIC-Request is generated by the procedures of 13.11.3.1, and the RIC-Response is generated by
the procedures of 13.11.3.2.
In order to recover from over-the-DS packet losses, the FTO may retransmit the FT Confirm frame until the
reassociation deadline time is reached. If the FTO does not receive a response to the FT Confirm frame or if
the value of the Status Code field returned by the target AP in the FT Ack frame is not SUCCESS, then the
FTO shall abandon this transition attempt.
In an RSN, on successful completion of the FT Confirm/Acknowledgment frame exchange, the PTKSA has
been established and proven live. The key replay counter shall be initialized to 0, and the subsequent
EAPOL-Key frames (e.g., GTK and IGTK updates) shall use the key replay counter to detect and discard
replays. The PTKSA shall be deleted by the target AP if it does not receive a Reassociation Request frame
from the FTO within the reassociation deadline timeout value. Resource request procedures are specified in
13.11.
In a non-RSN, the FT Ack frame contains a TIE with a reassociation deadline. If the FTO does not send a
Reassociation Request frame to the target AP within that interval, the FTO shall abandon this transition
attempt.
The exchange between the FTO and the target AP may continue with reassociation (13.7.1 or 13.7.2).
2106
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.7 FT reassociation
13.7.1 FT reassociation in an RSN
If the FTO does not send a Reassociation Request frame to the target AP within the reassociation deadline
interval received during the FT initial mobility domain association, the target AP may delete the PTKSA,
and the FTO shall abandon this transition attempt.
The FTO shall perform a reassociation directly with the target AP via the following exchange:
FTO Target AP: Reassociation Request(RSNE[PMKR1Name], MDE, FTE[MIC, ANonce,
SNonce, R1KH-ID, R0KH-ID], RIC-Request)
Target AP FTO: Reassociation Response(RSNE[PMKR1Name], MDE, FTE[MIC, ANonce,
SNonce, R1KH-ID, R0KH-ID, GTK[N], IGTK[M]], RIC-Response)
The SME of the FTO initiates the reassociation through the use of the MLME-REASSOCIATE.request
primitive. The SME of the AP responds to the indication with MLME-REASSOCIATE.response primitive.
See 11.3.5.
In the Reassociation Request frame, the SA field of the message header shall be set to the MAC address of
the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. The elements in
the frame, the element contents, and the MIC calculation shall be as given in 13.8.4.
The R1KH of the target AP verifies the MIC in the FTE in the Reassociation Request frame and shall
discard the request if the MIC is incorrect. If the contents of the MDE received by the target AP do not
match the contents advertised in the Beacon and Probe Response frames, the target AP shall reject the
Reassociation Request frame with status code STATUS_INVALID_MDE. If the FTE in the Reassociation
Request frame contains a different R0KH-ID, R1KH-ID, ANonce, or SNonce, the AP shall reject the
Reassociation Request frame with status code STATUS_INVALID_FTE. If the RSNE in the Reassociation
Request frame contains an invalid PMKR1Name, the AP shall reject the Reassociation Request frame with
status code STATUS_INVALID_PMKID.
In the Reassociation Response frame, the SA field of the message header shall be set to the BSSID of the
target AP, and the DA field of the message header shall be set to the MAC address of the FTO. The Status
Code field shall be a value from the options listed in 9.4.1.9. The elements in the frame, the element
contents, and the MIC calculation shall be as given in 13.8.5.
The S1KH of the FTO verifies the MIC in the FTE in the Reassociation Response frame and shall discard
the response if the MIC is incorrect.
If an FTO is performing a reassociation exchange as part of the FT resource request protocol, then the FTO
shall not include the RIC-Request in the Reassociation Request frame, and the AP shall not include the RIC-
Response in the Reassociation Response frame. If the reassociation exchange is part of the FT resource
request protocol and the AP is unable to honor the resources that have been placed in the accepted state for
that FTO, then the AP shall reject the Reassociation Request frame and may use status code
DENIED_INSUFFICIENT_BANDWIDTH.
If the FTO did not utilize the FT resource request protocol, the FTO may make a request for resources by
including a RIC-Request (see 13.11) in the Reassociation Request frame. The RIC-Request is generated by
the procedures of 13.11.3.1, and the RIC-Response is generated by the procedures of 13.11.3.2.
2107
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the Status Code field value returned by the target AP in the response is
REFUSED_REASON_UNSPECIFIED, TRANSACTION_SEQUENCE_ERROR, or
REJECTED_SEQUENCE_TIMEOUT, then the FTO shall abandon this transition attempt. Handling of
other errors returned in the Status Code field shall be as specified in 11.3.
Upon a successful reassociation, the PTKSA has been established and proven live. The SME of the AP shall
open the IEEE 802.1X Controlled Port. The FTO shall transition to State 4 (as defined in 11.3). If the target
AP is distinct from the previous AP, the FTO shall enter State 1 with respect to the previous AP.
Upon a successful reassociation, the FTO shall delete any corresponding PTKSA with its previous AP. The
SME of the FTO shall issue an MLME-DELETEKEYS.request primitive to delete the pairwise keys with
the previous AP, and the FTO and the AP shall issue an MLME-SETKEYS.request primitive and MLME-
SETPROTECTION.request primitive to install the pairwise keys. The PTK lifetime timer shall be initialized
with the value calculated as the difference between the TIE[KeyLifetime] sent in message 3 of the FT initial
mobility domain association and the time since the completion of the FT 4-way handshake during the FT
initial mobility domain association.
When the IEEE 802.1X Controlled Port is opened, the EAPOL-Key frame replay counter shall be initialized
to 0. The R1KH shall increment the key replay counter on each successive EAPOL-Key frame that it
transmits.
13.7.2 FT reassociation in a non-RSN
The FTO shall perform a reassociation with the target AP via the following exchange:
FTO Target AP: Reassociation Request(MDE, RIC-Request)
Target AP FTO: Reassociation Response(MDE, RIC-Response)
The SME of the FTO initiates the reassociation through the use of the MLME-REASSOCIATE.request
primitive. The SME of the AP responds to the indication with MLME-REASSOCIATE.response primitive.
See 11.3.5.
In the Reassociation Request frame, the SA field of the message header shall be set to the MAC address of
the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. The elements in
Reassociation Request frame, and their required contents, shall be as given in 13.8.4.
If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and
Probe Response frames, the target AP shall reject the Reassociation Request frame with status code
STATUS_INVALID_MDE.
In the Reassociation Response frame, the SA field of the message header shall be set to the BSSID of the
target AP, and the DA field of the message header shall be set to the MAC address of the FTO. The elements
in Reassociation Response frame, and their required contents, shall be as given in 13.8.5. The Status Code
field shall be a value from the options listed in 9.4.1.9.
If the FTO is performing a reassociation exchange as part of the FT resource request protocol, then the FTO
shall not include the RIC-Request in the Reassociation Request frame, and the AP shall not include the RIC-
Response in the Reassociation Response frame.
If the FTO did not utilize the FT resource request protocol, the FTO may make a request for resources by
including a RIC-Request (see 13.11) in the Reassociation Request frame. The RIC-Request is generated by
the procedures of 13.11.3.1, and the RIC-Response is generated by the procedures of 13.11.3.2.
2108
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the Status Code field value returned by the target AP in the response is
REFUSED_REASON_UNSPECIFIED, TRANSACTION_SEQUENCE_ERROR, or
REJECTED_SEQUENCE_TIMEOUT, then the FTO shall abandon this transition attempt. Handling of
other errors returned in the Status Code field shall be as specified in 11.3.
If the AP has dot11RSNAActivated equal to true, upon a successful reassociation, the SME shall open the
IEEE 802.1X Controlled Port.
Upon a successful reassociation, the target AP and the FTO shall transition to State 4 (as defined in 11.3). If
the target AP is distinct from the previous AP, then the FTO shall enter State 1 with respect to the
previous AP.
13.8 FT authentication sequence
13.8.1 Overview
The FT authentication sequence comprises four sets of FT elements. Each set of FT elements is referred to in
13.8 as a message. These messages are included in the FT Protocol frames or FT Resource Request Protocol
frames to initiate a fast BSS transition. The FT authentication sequence is always initiated by the FTO and
responded to by the target AP.
In an RSN, the first two messages in the sequence allow the FTO and target AP to provide association
instance identifiers, SNonce and ANonce, respectively. SNonce and ANonce are chosen randomly or
pseudorandomly and are used to generate a fresh PTK. The first two messages also enable the target AP to
provision the PMK-R1 and the FTO and target AP to compute the PTK. The third and fourth messages
demonstrate liveness of the peer, authenticate the elements, and enable an authenticated resource request.
When an FTO invokes the FT protocol, then the first two messages of the sequence are both carried in
Authentication frames or both carried in Action frames, and these messages are described in 13.8.2 and
13.8.3. The third and fourth messages in the sequence are carried in the Reassociation Request and
Reassociation Response frames and are described in 13.8.4 and 13.8.5.
When the FTO invokes the FT resource request protocol, then the first four messages of the sequence are all
carried in Authentication frames or all carried in Action frames, and these messages are described in 13.8.2
to 13.8.5. The fifth and sixth frames of the FT resource request protocol are carried in the Reassociation
Request frame and Reassociation Response frame and are described in 13.8.4 and 13.8.5.
Regardless of the transport mechanism, the information contained in the FT authentication sequence
consists of the set of elements shown in Table 13-1.
The first message is used by the FTO to initiate a fast BSS transition. When RSNA is enabled, the FTO shall
include the R0KH-ID and the SNonce in the FTE and the PMKR0Name in the RSNE. The target AP can use
the PMKR0Name to derive the PMKR1Name, and if the target AP does not have the PMK-R1 identified by
PMKR1Name, it may attempt to retrieve that key from the R0KH identified by R0KH-ID. See 13.2. The
FTO includes a fresh SNonce as its contribution to the association instance identifier and to provide key
separation of the derived PTK; it is selected randomly to serve as a challenge that demonstrates the liveness
of the peer in the fourth message.
The second message is used by the target AP to respond to the requesting FTO. The target AP provides the
key holder identifiers and key names used to generate the PTK. The target AP also includes a fresh ANonce
as its contribution to the association instance identifier and to provide key separation of the derived PTK.
The response includes a status code.
2109
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 13-1—FT authentication elements
Information Presence in Authentication Sequence messages Description
RSN The RSNE is present if dot11RSNAActivated is true. 9.4.2.25
Mobility Domain The Mobility Domain element is present. 9.4.2.47
Fast BSS Transition The Fast BSS Transition element is present if 9.4.2.48
dot11RSNAActivated is true.
Timeout Interval The Timeout Interval element is optionally present in the 9.4.2.49
(reassociation fourth message of the sequence if dot11RSNAActivated is not
deadline) true.
RIC The RIC Data element is optionally present in the third and 9.4.2.50
fourth messages.
In an RSN, the third message is used by the FTO to assert to the target AP that it has a valid PTK. If no
resources are required, then the FTO omits inclusion of the RIC.
The fourth message is used by the target AP to respond to the requesting FTO. This message serves as final
confirmation of the transition, establishes that the AP possesses the PMK-R1 and is participating in this
association instance, and protects against downgrade attacks. Note, however, that the RIC is absent if no
resources were requested in the third message. This also includes a status code and may include a
reassociation deadline.
13.8.2 FT authentication sequence: contents of first message
The RSNE shall be present only if dot11RSNAActivated is true. If present, the RSNE shall be set as follows:
— Version field shall be set to 1.
— PMKID Count field shall be set to 1.
— PMKID List field shall contain the PMKR0Name.
— All other fields shall be as specified in 9.4.2.25 and 12.6.3.
The MDE shall contain the MDID field and the FT Capability and Policy field settings obtained from the
target AP, as advertised by the target AP in Beacon and Probe Response frames. The MDID shall be
identical to that obtained during the FT initial mobility domain association exchange.
The FTE shall be present only if dot11RSNAActivated is true. If present, the FTE shall be set as follows:
— R0KH-ID shall be the value of R0KH-ID obtained by the FTO during its FT initial mobility domain
association exchange.
— SNonce shall be set to a value chosen randomly by the FTO, following the recommendations of
12.7.5.
— All other fields shall be set to 0.
13.8.3 FT authentication sequence: contents of second message
If the status code is SUCCESS, then the following rules apply.
The RSNE shall be present only if dot11RSNAActivated is true. If present, the RSNE shall be set as follows:
— Version field shall be set to 1.
— PMKID Count field shall be set to 1.
2110
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— PMKID List field shall be set to the value contained in the first message of this sequence.
— All other fields shall be identical to the contents of the RSNE advertised by the AP in Beacon and
Probe Response frames.
The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be the same as the
MDE advertised by the target AP in Beacon and Probe Response frames.
The FTE shall be present only if dot11RSNAActivated is true. If present, the FTE shall be set as follows:
— R0KH-ID shall be identical to the R0KH-ID provided by the FTO in the first message.
— R1KH-ID shall be set to the R1KH-ID of the target AP, from dot11FTR1KeyHolderID.
— ANonce shall be set to a value chosen randomly by the target AP, following the recommendations of
12.7.5.
— SNonce shall be set to the value contained in the first message of this sequence.
— All other fields shall be set to 0.
13.8.4 FT authentication sequence: contents of third message
The RSNE shall be present only if dot11RSNAActivated is true. If present, the RSNE shall be set as follows:
— Version field shall be set to 1.
— PMKID Count field shall be set to 1.
— PMKID field shall contain the PMKR1Name.
— All other fields shall be as specified in 9.4.2.25 and 12.6.3.
The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be identical to the
MDE contained in the first message of this sequence.
The FTE shall be present only if dot11RSNAActivated is true. If present, the FTE shall be set as follows:
— ANonce, SNonce, R0KH-ID, and R1KH-ID shall be set to the values contained in the second
message of this sequence.
— The Element Count field of the MIC Control field shall be set to the number of elements protected in
this frame (variable).
— When the negotiated AKM is 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9, the MIC shall be calculated
using the KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC shall be 128
bits.
— The MIC shall be calculated on the concatenation of the following data, in the order given here:
— FTO’s MAC address (6 octets)
— Target AP’s MAC address (6 octets)
— Transaction sequence number (1 octet), which shall be set to the value 5 if this is a
Reassociation Request frame and, otherwise, set to the value 3
— RSNE
— MDE
— FTE, with the MIC field of the FTE set to 0
— Contents of the RIC-Request (if present)
— All other fields shall be set to 0.
If resources are being requested by the FTO, then a sequence of elements forming the RIC-Request shall be
included.
2111
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.8.5 FT authentication sequence: contents of fourth message
If the status code is SUCCESS, then the following rules apply.
The RSNE shall be present only if dot11RSNAActivated is true. If present, the RSNE shall be set as follows:
— Version field shall be set to 1.
— PMKID Count field shall be set to 1.
— PMKID field shall contain the PMKR1Name
— All other fields shall be identical to the contents of the RSNE advertised by the target AP in Beacon
and Probe Response frames.
The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be identical to the
MDE contained in the second message of this sequence.
The FTE shall be present only if dot11RSNAActivated is true. If present, the FTE shall be set as follows:
— ANonce, SNonce, R0KH-ID, and R1KH-ID shall be set to the values contained in the second
message of this sequence.
— The Element Count field of the MIC Control field shall be set to the number of elements protected in
this frame (variable).
— When this message of the authentication sequence appears in a Reassociation Response frame, the
Optional Parameter(s) field in the FTE may include the GTK and IGTK subelements. If a GTK or an
IGTK are included, the Key field of the subelement shall be encrypted using KEK and the NIST
AES key wrap algorithm. The Key field shall be padded before encrypting if the key length is less
than 16 octets or if it is not a multiple of 8. The padding consists of appending a single octet 0xdd
followed by zero or more 0x00 octets. When processing a received message, the receiver shall
ignore this trailing padding. Addition of padding does not change the value of the Key Length field.
Note that the length of the encrypted Key field can be determined from the length of the GTK or
IGTK subelement.
— When the negotiated AKM is 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9, the MIC shall be calculated
using the KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC algorithm
shall be 128 bits.
— The MIC shall be calculated on the concatenation of the following data, in the order given here:
— FTO’s MAC address (6 octets)
— Target AP’s MAC address (6 octets)
— Transaction sequence number (1 octet), which shall be set to the value 6 if this is a
Reassociation Response frame or, otherwise, set to the value 4
— RSNE
— MDE
— FTE, with the MIC field of the FTE set to 0
— Contents of the RIC-Response (if present)
— All other fields shall be set to 0.
If this message is other than a Reassociation Response frame and dot11RSNAActivated is false, a TIE may
appear. If this message is other than a Reassociation Response frame, includes a RIC-Response, and
dot11RSNAActivated is false, then a timeout interval shall appear. If it appears, it shall be set as follows:
— Timeout Interval Type field shall be set to 1 (reassociation deadline)
— Timeout Interval Value field shall be set to the reassociation deadline time.
If resources were requested by the FTO, then a RIC-Response shall be included.
2112
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.9 FT security architecture state machines
13.9.1 Introduction
The FT state machines describe the interaction between the RSNA key management and IEEE 802.11
architectural components.
RSNA key management uses the MA-UNITDATA service primitives to send/receive EAPOL-Key frames
for FT initial association; MLME interfaces described below for FT methods; and MLME-SETKEYS,
MLME-DELETEKEYS, and MLME-SETPROTECTION primitives. FT key management uses the
following primitives for key management delivery and reception:
— The MLME-REMOTE-REQUEST primitives for FT key management over the DS
— The MLME-AUTHENTICATE primitives for FT key management over the air
— The MLME-RESOURCE-REQUEST primitives for FT resource request over the air
— The MLME-REASSOCIATE primitives for FT key management over the air and over the DS
Some of the state machine design considerations are as follows:
— Details of error handling are not included in the state machines. See 13.4, 13.5, and 13.6.
— Retransmission of FT Authentication and (Re)Association frames are not included in the state
machines; see 13.5 and 13.6.
Various signals are used to communicate between the R0KH and the R1KH state machines. Note that these
interactions may be between separate entities, rather than within a single SME. These interactions are as
follows:
— In the R0KH state machine, FT-PMKR1-SA (PMKR1-SA) sends a PMK-R1 PMKSA to the R1KH.
— In the R1KH state machine, FT-FULL-AUTH (R1KH-ID) requests a key from the R0KH.
— In the R1KH state machine, FT-Transition-Auth (R1KH-ID) requests a key from the R0KH that was
used for the initial mobility domain association.
The interactions between the R0KH and IEEE Std 802.1X, between the R1KH and IEEE Std 802.1X, and
between the S1KH and IEEE Std 802.1X occur within the SME. At both the target AP and at the FTO, the
R1KH and S1KH initialize the IEEE 802.1X EAPOL state machines in the respective SMEs. The Controlled
Port is opened without an EAP exchange when the reassociation completes.
13.9.2 R0KH state machine
13.9.2.1 General
There is one R0KH state machine, which includes FT key management.
The state diagram in Figure 13-13 consists of a set of states that handle R0KH functions including key
hierarchy instantiation, key generation, and cleanup. This state machine interacts with the R1KH state
machine.
2113
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
FT-Full-Auth(R1KH-ID), from FT-INIT-GET-R1_SA
FT-R0-AUTH
Initial-Assoc = true
(802.1X::keyAvailable && 802.1X::keyRun) || PSK
CALC-PMK-R0
Derive-key-PMK-R0()
Invalidate previous PMK-R0-SA
UCT
CALC-PMK-R0-IDLE
PMK-R0-lifetime-expire
Check PMK-R0 lifetime
!PMK-R0-lifetime-expire !PMK-R0-lifetime-expire &&
&& Initial-Assoc FT-Transition-Auth(R1KH-ID) from R1 SM
&& Authorized(R1KH-ID)
CALC-PMK-R1 FT-R0-AUTH-CLEANUP
Remove PMK-R0-SA
Initial-Assoc = false
!Push-PMK-R1 Push-PMK-R1
FT-R0-SEND-PMKR1SA FT-PMK-R1-SA-PUSH
Derive-Key-PMK-R1() For each List-R1KH-ID:
FT-PMKR1-SA(PMK-R1-SA) to R1 SM Derive-Key-PMK-R1()
UCT Distribute(List-R1KH-IDs, PMK-R1-SA)
UCT
Figure 13-13—R0KH state machine
13.9.2.2 R0KH state machine states
The following list summarizes the states of the R0KH state machine:
— CALC-PMK-R0: This state is entered after the MSK from EAP authentication or PSK is available.
— CALC-PMK-R0-IDLE: This state is an intermediate state for the R0KH to wait for new requests
from R1KHs.
— CALC-PMK-R1: For FT initial association, this state is entered as an unconditional transfer. For
FT methods, this state is entered through the event from an R1KH state machine.
— FT-PMK-R1-SA-PUSH: This state is entered if Push-PMK-R1 is true. PMK-R1s are derived and
distributed to all of the configured R1KHs.
— FT-R0-AUTH-CLEANUP: This state is entered when the PMK-R0 lifetime expires.
— FT-R0-AUTH: This state is entered through the event from the R1KH state machine. The R1KH
state machine sends this event when it determines that a new PMK-R0 is needed.
— FT-R0-SEND-PMKR1SA: This state is entered from CALC-PMK-R1 when a request for the
PMK-R1 security association is received from an R1KH. PMK-R1 security association is derived
and distributed to the requesting R1KH.
2114
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.9.2.3 R0KH state machine variables
The following list summarizes the variables used by the R0KH state machine:
— Initial-Assoc – This variable is used to indicate whether the current authentication is the initial
association, in order to trigger the initial derivation of PMK-R1.
— List-R1KH-IDs – This variable contains a list of all of the R1KH-IDs in the mobility domain. This
list is populated by the key distribution protocol as required in 13.2.
— PMK-R0-lifetime-expire – This variable is set to true when PMK-R0 lifetime is deemed expired.
— PSK – This variable is set to true when authentication is performed by use of a preshared key.
— Push-PMK-R1 – This variable is set to true when R0KH can push the PMK-R1 security associations
to R1KHs.
13.9.2.4 R0KH state machine procedures
The following list summarizes the procedures used by the R0KH state machine:
— Authorized(R1KH-ID) – This procedure returns a value of true if the R1KH is a known key holder
in the mobility domain.
— Distribute (List-R1KH-IDs, PMK-R1 PMKSA) – Distributes the PMK-R1-SAs for the current
instance of the key hierarchy to the list of R1KH-IDs.
— Derive-Key-PMK-R0() – This procedure derives the PMK-R0 from the MSK or PSK, derives the
PMKR0Name (as described in 12.7.1.7.3), and creates PMK-R0 security association.
— Derive-Key-PMK-R1 (R1KH-ID) – From the PMK-R0, and the R1KH-ID (as described in
12.7.1.7.4) for the R1KH identified by R1KH-ID, this procedure derives the PMK-R1 and creates a
PMK-R1 security association.
13.9.3 R1KH state machine
13.9.3.1 General
The R1KH state machine includes functions for FT initial association and FT protocols. The R1KH states
performing FT initial association and the R1KH states performing FT protocol exchanges interact
differently with the R0KH state machine.
The R1KH state machine and other portions of the SME are defined in Figure 13-14 and Figure 13-15 and
consist of a set of states that handle FT initial mobility domain association, PMK-R1 reception, PTK
handshake and session establishment, FT protocols (including resource requests), and cleanup. This state
machine interacts with the R0KH state machine to generate a fresh FT key hierarchy for the initial mobility
domain association and to get the PMK-R1 security association (PMK-R1 PMKSA) for the FT protocols.
While the figures show the over-the-air message exchanges, the over-the-DS exchanges are handled
similarly.
A new instance of the R1KH state machine is created each time initial mobility domain association or fast
BSS transition is initiated.
2115
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Init
R1-START MLME-AUTHENTICATE.indication(FTAA,
SNonce,R0KH-ID, PMKR0Name)
MLME-AUTHENTI CATE.indication(Open) To FT-AUTH
FT-INIT-AUTH
MLME-AUTHENTICATE.res pons e(Open)
MLME-ASSOCIATE.indication ||
MLME-REASSOCIATE.indication
FT-INIT-ASSOC
802.1X::portControl = Auto
802.1X::portValid = false
802.1X::portEnabled = true
MLME-ASSOCIATE.res pons e() or
MLME-REASSOCIATE.res pons e()
Reass ocdeadlinetimerexpEv t
UCT
FT-INIT-GET-R1_SA
R0-TimeoutEvt
ReAuthenticationR equest = false
FT-Full-Auth(R1KH-ID), to FT-R0-AUTH R0KH SM
FT-PMKR1-SA(PMK-R1-SA) PTK-RekeyRequest
FT-INIT-R1_SA
Calculate ANonce
TimeoutCtr = 0
TimeoutEvt && PTK-Rekey Request = false
TimeoutCtr ≤ N
UCT
FT-PTK-START
TimeoutEvt &&
TimeoutCtr > N Send EAPOL-Key (0, 0, 1, 0, P, 0, ANonce, 0)
TimeoutCtr++
EAPOLKeyReceiv ed &&
EAPOLKeyReceiv ed && !Request &&
!Request && K == Pairwise
K == Pairwise
FT-PTK-CALC-NEGOTIATING
PTK= Calc FT-PTK ()
TimeoutCtr = 0
TimeoutEvt MIC-Verified
FT-PTK-CALC-NEGOTIATING3
Send EAPOL-Key (1, 1, 1, 1, P, 0, ANonce, MIC, RSNE[PMKR1Name],
MDE, GTK[N], IGTK[M], FTE, TE[ReassociationDeadline],
TE[KeyLifetime]))
TimeoutCtr > N TimeoutCtr ++
EAPOLKeyReceiv ed && !Request &&
K == Pairwise && MIC-Verified
DISCONNECT FT-PTK-INIT-DONE
Deauthenticate the STA MLME-SETKEYS.request(Pairwise)
Invalidate PT K MLME-SETPROTECTION.request(STA,Rx_Tx, pairwise)
MLME-DELETEKEYS.request(PTK) 802.1X::portEnabled = true
802.1X:portEnabled = false 802.1X::portValid = true
802.1X:portValid = false 802.1X::keyAvailable = false
802.1X::portControl = Auto 802.1X::keyDone = true
Figure 13-14—R1KH state machine, including portions of the SME (part 1)
2116
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
R1-START MLME-AUTHENTICATE.indication(Open)
to FT-INIT-AUTH
MLME-AUTHENTICATE.indication(FTAA,
SNonce,R0KH-ID, PMKR0Name)
FT-AUTH
FT-GET-PMK-R1-SA
802.1X::portControl = Auto
802.1X::portValid-= false !PMK-R1-SA FT-Transition-Auth(R1KH-ID) to
802.1X::portEnabled = false CALC-PMK-R0-IDLE R0KH SM
R0-TimeoutEvt
PMK-R1-SA
To DISCONNECT
FT-PMK-R1-SA-RECD
Calc. ANonce FT-PMKR1-SA(PMK-R1-SA) from FT-R0-SEND-
Reassocdeadlinetimerexp = Reassoc-deadline PMKR1SA R0KH SM && PMK-R1-SA
MLME-AUTHENTICATE.response(FTAA, ANonce, SNonce,
MD-ID, R1KH-ID, PMK-R1-Name)
PTK= Calc FT-PTK () MLME-RESOURCE_REQUEST.indication
MLME-SETKEYS.request(Pairwise) (ANonce, SNonce, MD-ID, RSNE,
PMKR1Name, RIC-Req) && MIC-Verified
MLME-SETPROTECTION.request(FTO,Rx_Tx, Pairwise)
FT-RV-HANDSHAKE-NEGOTIATING
MLME-REASSOCIATE.indication(ANonce, SNonce, MD-ID, Resv-Flow = true
R0KH-ID, R1KH-ID, PMK-R1Name, RIC) && MIC-Verified MLME-RESOURCE_REQUEST.response
(ANonce, SNonce, MD-ID, RSNE,
PMKR1Name, RIC-Resp)
FT-HANDSHAKE-DONE
MLME-REASSOCIATE.response(ANonce, SNonce, MD-ID, MLME-REASSOCIATE.indication(ANonce,
R0KH-ID, R1KH-ID, PMK-R1-Name, GTK, IGTK, RIC-Resp) SNonce, MD-ID, R0KH-ID, R1KH-ID, PMK-
(If Resv-Flow, then do not include RIC-Resp in this msg) R1Name) && MIC-Verified
802.1X::portEnabled = true
802.1X::portValid = true
802.1X::eapRestart
SKIP-EAP
802.1X::eapRestart = false
802.1X::eapSuccess = true
802.1X::eapFail = false
Figure 13-15—R1KH state machine, including portions of the SME (part 2)
13.9.3.2 R1KH state machine states
The following list summarizes the states of the R1KH state machine:
— DISCONNECT: This state is entered when the current session ends or when errors occur.
— FT-AUTH: This state is entered upon receipt of an indication that an FT protocol or FT resource
request protocol is invoked.
— FT-GET-PMK-R1-SA: This state is entered when R1KH sends a message to the R0KH to get the
PMK-R1-SA.
— FT-HANDSHAKE-DONE: This state is entered when reassociation indication parameters are
validated. The Reassociation Response frame is then sent.
— FT-INIT-ASSOC: This state is entered upon receipt of a (Re)Association Request frame during
initial mobility domain association.
2117
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— FT-INIT-AUTH: This state is entered upon receipt of an indication that initial association is
invoked.
— FT-INIT-GET-R1_SA: This state is entered when the R1KH determines that a new key hierarchy
is required.
— FT-INIT-R1_SA: This state is entered on receiving the PMK-R1-SA from the R0KH and when
rekeying the PTK.
— FT-PMK-R1-SA-RECD: This state is entered on receiving the PMK-R1-SA from the R0KH. An
FT Authenticate response is sent in this state. This state then calculates the PTK and delivers the key
to the MAC.
— FT-PTK-INIT-DONE: This state is entered on successful validation of the fourth EAPOL-Key
frame. In this state, keys are provided to the MAC.
— FT-PTK-CALC-NEGOTIATING: This state is entered when a second EAPOL-Key frame is
received.
— FT-PTK-CALC-NEGOTIATING3: This state is entered on successful validation of the second
EAPOL-Key frame. In this state, the third EAPOL-Key frame is sent.
— FT-PTK-START: This state is entered when the PMK-R1-SA is present. This state is the beginning
of the 4-way handshake to derive a fresh PTK.
— FT-RV-HANDSHAKE-NEGOTIATING: This state is entered when an FT resource request is
received. The FT resource response is sent.
— R1-START: This is the start of the R1KH state machine.
— SKIP-EAP: This state is entered after successful completion of the FT protocol. In this state, the
EAPOL state machine is triggered to open the IEEE 802.1X port.
13.9.3.3 R1KH state machine variables
The following list summarizes the variables used by the R1KH state machine:
— Init – This variable is set to true to initialize the R1KH the state machine.
— EAPOLKeyReceived – This variable is set to true when an EAPOL-Key frame is received.
— K – This variable is one of the values of the Key Type bit in the EAPOL-Key frame received and is
either Pairwise or Group.
— MIC-Verified – This variable is set to true when the message authentication code integrity check
passes.
— Pairwise – This variable is one of the values of the Key Type bit in the EAPOL-Key frame.
— PMK-R1-SA – This variable is set to true when a valid PMK-R1-SA is present at the R1KH.
— PTK-RekeyRequest – This variable is set to true when a PTK rekey request is received.
— Reassocdeadlinetimerexp – This variable contains the reassociation deadline timer value.
— ReassocdeadlinetimerexpEvt – This variable is set to true when the reassociation deadline timer
expires.
— Request – This variable is the value of the Request bit in the Key Information field in the EAPOL-
Key frame.
— Resv-flow – This variable is set to true when an indication of an FT resource request protocol is
received.
— R0-TimeoutEvt – This variable is set to true when the timeout for R0KH authentication expires (e.g.,
when the EAP authentication session timeout expires).
— TimeoutCtr – This variable contains the number of successive timeouts waiting for protocol
responses.
— TimeoutEvt – This variable is set to true when a timeout for receiving EAPOL-Key response expires.
2118
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.9.3.4 R1KH state machine procedures
The following list summarizes the procedure used by the R1KH state machine:
— Calc-FT-PTK() – This procedure calculates the PTK.
13.9.4 S0KH state machine
13.9.4.1 General
There is one S0KH state machine within the Supplicant, defined in Figure 13-16, which incorporates the FT
initial association and key management.
FT-Full-Auth(R1KH-ID) from
FT-INIT-START S1KH SM
FT-R0-AUTH
Initial-Assoc = true
802.1X::suppKeyAvailable && PSK
802.1X::keyRun
CALC-PMK-R0
Derive-Key-PMK-R0()
Invalidate previous PMK-R0-SA
UCT
CALC-PMK-R0-IDLE
Check PMK-R0 lifetime expiration
FT-Transition-Auth(R1KH-ID) from
Initial-Assoc FT-START S1KH SM
CALC-PMK-R1
Derive-Key-PMK-R1()
Initial-Assoc = false
FT-PMKR1-SA(PMK-R1-SA) to
FT-INIT-R1-SA S1KH SM
UCT
Figure 13-16—S0KH state machine
13.9.4.2 S0KH state machine states
The following list summarizes the states of the S0KH state machine:
— CALC-PMK-R0: This state is entered after the key is received, either from the EAP authentication
or from the PSK.
— CALC-PMK-R0-IDLE: This state is entered after the PMK-R0 has been calculated and either
continues with initial association or waits for requests from an S1KH for a PMK-R1.
2119
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— CALC-PMK-R1: For FT initial association, this state is entered as an unconditional transfer. For
FT protocols, this state is entered through the event from the S1KH state machine. In this state, the
PMK-R1 is sent to the S1KH.
— FT-R0-AUTH: This state is entered when the FT-Full-Auth event occurs during initial association
in the S1KH state machine. The S1KH state machine sends this event when it determines that a new
PMK-R0 is needed.
13.9.4.3 S0KH state machine variables
The following list summarizes the variables used by the S0KH state machine:
— Initial-Assoc – This variable is used to indicate whether the current authentication is the initial
association, in order to trigger the initial derivation of PMK-R1.
— PSK – This variable is set to true when authentication is performed by use of a preshared key.
13.9.4.4 S0KH state machine procedures
The following list summarizes the procedures used by the S0KH state machine:
— Derive-Key-PMK-R0() – This procedure derives the PMK-R0 and PMKR0Name and creates
PMK-R0 security association.
— Derive-Key-PMK-R1 (R1KH-ID) – This procedure derives the PMK-R1 and PMKR1Name from
PMK-R0 for the indicated R1KH and creates PMK-R1 security association.
13.9.5 S1KH state machine
13.9.5.1 General
The S1KH state machine includes functions for fast BSS transitions, including initial association. The S1KH
state machine and other portions of the SME are defined in Figure 13-17 and Figure 13-18 and consist of a
set of states that handle FT initial association, PTK handshake and session establishment, resource requests,
cleanup, and teardown. This state machine interacts with the S0KH state machine to generate a fresh key
hierarchy.
13.9.5.2 S1KH state machine states
The following list summarizes the states of the S1KH state machine:
— DISCONNECT: This state is entered when the current session expires.
— FT-AIR-REQUEST: This state is entered when it is determined that an over-the-air FT method is
to be executed. This state sends the Authentication-Request frame over the air.
— FT-DONE: This state is entered when a Reassociation Response frame is received.
— FT-DS-REQUEST: This state is entered when it is determined that an over-the-DS FT method is to
be executed. This state sends the Authentication-Request frame over the DS.
— FT-INIT: This state is entered when an FT method is initiated.
— FT-INIT-ASSOC: This state is entered when authentication for initial mobility domain association
has been completed.
— FT-INIT-AUTH: This state is entered when an FT initial association event is initiated.
— FT-INIT-START: This state is entered when association for initial mobility domain association has
been completed.
— FT-INIT-R1-SA: This state is entered on receiving the PMK-R1-SA from the S0KH and when the
Authenticator is starting PTK rekeying by sending out EAPOL-Key frame 1.
2120
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Init R1-START !FT-Initial-Association
To FT-INIT
FT-Initial-Association
FT-INIT-AUTH
MLME-AUTHENTICATE.request(Open)
MLME-AUTHENTICATE.confirm()
FT-INIT-ASSOC
MLME-ASSOCIATE.request() or
MLME-REASSOCIATE.request()
Reassocdeadlinetimerexp
MLME-ASSOCIATE.confirm() ||
MLME-REASSOCIATE.confirm()
FT-INIT-START
802.1X::portControl = Auto
802.1X::portValid = false
802.1X::portEnabled = true
FT-Full-Auth(R1KH-ID) to S0KH SM
FT-PMKR1-SA(PMK-R1-SA) from
FT-R0-SEND-PMKR1SA
FT-INIT-R1-SA
EAPOL-Key Received &&
!Request && MesgNo == 1
Calculate SNonce
&& !Initial-Assoc
EAPOL-Key Received && !Request &&
MesgNo == 1
FT-PTK-START
Process EAPOL-Key frame
EAPOL-Key Received && TPTK = Calc-FT-PTK()
!Request && MesgNo == 1 Send EAPOL-Key (0, 1, 0, 0, P, 0, SNonce,
MIC-KCK, RSNE[PMKR1Name], MDE, FTE)
EAPOL-Key Received && !Request &&
MIC-Verified && MesgNo == 3
FT-PTK-CALC-NEGOTIATING
EAPOL-Key Received &&
PTK = TPTK !Request && MIC-Verified
Send EAPOL-Key (1, 1, 0, 0, P, 0, 0, && MesgNo == 3
MIC-KCK)
UCT
FT-PTK-INIT-DONE
DISCONNECT
MLME-SETKEYS.request(Pairwise)
Deauthenticate the FTO
MLME-SETPROTECTION.request(FTO,Rx_Tx, Pairwise)
Invalidate PTK
802.1X::portEnabled = true
MLME-DELETEKEYS.request(PTK)
802.1X::portValid = true
802.1X::portEnable = false
802.1X::suppKeyAvailable = false
802.1X::portValid = false
802.1X::keyDone = true
Initial-Assoc = false
Figure 13-17—S1KH state machine, including portions of the SME (part 1)
2121
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Init
R1- START FT-Initial- Association
to FT- INIT - AUTH
!FT-Initial - Association
FT- INIT
802.1X:: portValid = false
802.1X:: portEnabled= false
802.1X:: portControl= Auto
UCT
FT- START
Calculate SNonce
802.1X:: portEnabled= true
TimeoutCtr=0
Over-the- Air && FT- PMK-R1- SA from S0KH SM Over-the- DS && FT- PMK-R1-SA from S0 KH SM
TimeoutEvt && TimeoutEvt &&
FT-AIR - REQUEST FT-DS - REQUEST
TimeoutCtr > N TimeoutCtr> N
MLME- AUTHENTICATE. request MLME- REMOTE- REQUEST. request
TimeoutEvt ( FTAA, MDE, FTE [SNonce], TimeoutEvt
( FTAA,MDE,FTE[ SNonce],RSNE
&& TimeoutCtr RSNE [ PMKR0Name ] ,R0KH-ID) && TimeoutCtr
[ PMKR0Name ], R0KH-ID) ≤N
≤N TimeoutCtr ++
TimeoutCtr ++
MLME- AUTHENTICATE.confirm MLME-REMOTE-REQ UEST.indication
FT- PTK -CALC
! PTK- Lifetime- Valid ||
! PMK-R1- lifetime- Valid Reassocdeadlinetimer = Reassoc deadline To DISCONNECT
FT - Transition-Auth(R1KH-ID ) to CALC-PMK-R 1 S0KH SM
Calc-FT- PTK() , TimeoutCtr =0
MLME-SETKEYS. request (P airwise)
MLME-SETPROTECTION.request (AP , Rx_Tx, Pairwise )
Resource- Request && Over- the- Air Resource - Request && Over- the- DS
! Resource- Request
FT- RV- AIR- CONFIRM FT- RV- DS- CONFIRM
MLME-RESOURCE - REQ UEST.request MLME-REMOTE- REQ UEST. request TimeoutCtr
TimeoutCtr >N ( ANonce, SNonce, MDE, RSNE, ( ANonce, SNonce, MDE, RSNE, >N
PMK-R1 Name, RIC- Req) PMK-R1 Name, RIC- Req)
TimeoutCtr ++ TimeoutCtr ++
TimeoutEvt TimeoutEvt
MLME- RESOURCE- REQ UEST.confirm ( ANonce, MLME-REMOTE- REQ UEST.indication
SNonce, MDE, RSNE, PMK-R1 Name, RIC- Resp)
( ANonce, SNonce, MDE, RSNE,
&& MIC - Verified FT- RESERVE PMK-R1 Name, RIC- Resp) && MIC-
TimeoutCtr=0 Verified
UCT
FT- NO- RV- CONFIRM FT- RESERVE -2
TimeoutCtr MLME - REASSOCIATE. request ( MDE, MLME- REASSOCIATE. request( MDE, TimeoutCtr
>N FTE( ANonce, SNonce, R0KH-ID , FTE( ANonce, SNonce,R0KH-ID , >N
PMK-R1 Name, MIC, RSNE, RIC- Req ) PMK-R1 Name, MIC, RSNE)
TimeoutCtr++ TimeoutCtr++
MLME -REASSOCIATE. confirm ( ANonce, MLME- REASSOCIATE. confirm( ANonce,
SNonce, MDE, R0KH-ID , R1KH-ID , PMK- TimeoutEvt TimeoutEvt SNonce, MDE, R0KH-ID , R1KH-ID , PMK-
R1 Name, RIC- Resp) && MIC- Verified R1 Name) && MIC- Verified
FT- DONE
To
802.1X:: portEnabled = true 802.1X:: portValid = true 802.1X:: eapolEap = true
DISCON -
802.1X:: eapRestart NECT
To SKIP-EAP
DISCONNECT 802.1X:: eapolEap = false 802.1X:: eapSuccess = true 802.1X:: eapNoResp = true
802.1X:: eapRestart = false 802.1X:: eapFail = false
Figure 13-18—S1KH state machine, including portions of the SME (part 2)
2122
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— FT-NO-RV-CONFIRM: This state is entered when performing FT protocol (i.e., not the FT
resource request protocol). This state is entered for both over-the-air and over-the-DS processing.
This state sends the Reassociation Request frame.
— FT-PTK-CALC: This state is entered when the over-the-air Authentication-Response frame is
received if an over-the-air Authentication-Request frame was sent or when over-the-DS FT
Response frame is received if an over-the-DS FT Request frame was sent. The PTK is calculated
and installed in the MAC.
— FT-PTK-INIT-DONE: This state is entered after sending the fourth EAPOL-Key frame. This state
establishes the PTK into the MAC.
— FT-PTK-CALC-NEGOTIATING: This state is entered when a valid, third EAPOL-Key frame is
received. This state sends the fourth EAPOL-Key frame.
— FT-PTK-START: This state is entered to derive a new PTK when the PMK-R1-SA is present and
when the EAPOL-Key 4-way handshake message 1 is received. This state sends the EAPOL-Key 4-
way handshake message 2.
— FT-RESERVE: This state is entered when the over-the-air Authentication-Ack frame is received if
an over-the-air Authentication-Confirm frame was sent or when over-the-DS FT Ack frame is
received if an over-the-DS FT Confirm frame was sent.
— FT-RESERVE-2: The Reassociation Request frame is sent in this state after completion of FT
resource request.
— FT-RV-AIR-CONFIRM: This state is entered for over-the-air FT resource request protocol
processing. The Authentication-Confirm frame containing the FT resource request is sent.
— FT-RV-DS-CONFIRM: This state is entered for over-the-DS FT resource request protocol
processing. The Authentication-Confirm frame containing the FT resource request is sent.
— FT-START: This state is entered when all FT parameters are validated and FT needs to be initiated.
— R1-START: This is the start of the S1KH state machine.
— SKIP-EAP: This state is entered after successful completion of the FT protocol. In this state, the
EAPOL state machine is triggered to open the IEEE 802.1X port.
13.9.5.3 S1KH state machine variables
The following list summarizes the variables used by the S1KH state machine:
— EAPOLKeyReceived – This variable is set to true when an EAPOL-Key frame is received.
— FT-Initial-Association – This variable is set to true when the S1KH is performing an initial
association.
— Init – This variable is set to true to initialize the S1KH state machine. In addition, this variable is
used to restart the state machine when transitioning to a new AP.
— MesgNo – In conjunction with EAPOLKeyReceived, this variable indicates which message in the 4-
way handshake has been received.
— MIC-Verified – This variable is set to true when the message authentication integrity check is valid.
— N – This variable contains the limit of timeout events before considering the transition a failure.
— Over-the-Air – This variable is set to true when the FT protocol is to be exchanged over the air. Note
that both Over-the-Air and Over-the-DS cannot be equal to true at the same time.
— Over-the-DS – This variable is set to true when the FT protocol is to be exchanged over the DS. Note
that both Over-the-Air or Over-the-DS cannot be equal to true at the same time.
— PMK-R1-Lifetime-Valid – This variable is set to true when the PMK-R1 lifetime is valid.
— PTK-Lifetime-Valid – This variable is set to true when the PTK lifetime is valid.
— Reassocdeadlinetimer – This variable contains the reassociation deadline timer value.
2123
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— ReassocdeadlinetimerExp – This variable is set to true when the reassociation deadline timer
expires.
— Resource-request – This variable is set to true when the FT resource request protocol is to be
executed.
— TimeoutCtr – This variable contains the number of successive timeouts waiting for protocol
responses.
— TimeoutEvt – This variable is set to true when a timeout event occurs.
— TPTK – This variable contains the newly calculated PTK, which is installed after receipt of message
3 of the 4-way handshake.
13.9.5.4 S1KH state machine procedures
The following list summarizes the procedure used by the S1KH state machine:
— Calc-FT-PTK() – This procedure calculates the PTK.
13.10 Remote request broker (RRB) communication
13.10.1 Overview
The RRB mechanism allows the FTO to communicate with a target AP through the FTO’s existing
association (with the current AP). The FTO transmits an FT Action frame (including the address of the FTO
and the BSSID of the target AP) to the current AP. The current AP includes the contents of the FT Action
frame (Request or Confirm) inside a Remote Request frame and transmits it to the target AP over the DS.
The target AP processes the remote request and responds to the FTO by sending an FT Action frame
(Response or Acknowledgment) through the current AP.
The SME of the FTO initiates an exchange with a target AP by issuing an MLME-REMOTE-
REQUEST.request primitive with parameters including the contents of the FT Action frame to be sent. The
MAC of the FTO transmits this Action frame. When the MAC of the current AP receives an FT Action
frame, it passes it to the RRB by use of an MLME-REMOTE-REQUEST.indication primitive, with
parameters including the contents of the received Action frame.
When the RRB of the current AP has received a response from the target AP, it uses the MLME-REMOTE-
REQUEST.request primitive to send the response, as an FT Action frame, to the requesting FTO. The MAC
of the current AP transmits this Action frame. When the MAC of the FTO receives an FT Action frame, the
MAC passes the Action frame to the SME by use of an MLME-REMOTE-REQUEST.indication primitive,
with parameters including the contents of the received Action frame.
13.10.2 Remote request broker (RRB)
The RRB resides in the SME on the APs and acts as a forwarding agent (at the current AP) and termination
point (at the target AP) for protocol messages over the DS.
The RRB allows APs that are part of the same mobility domain to exchange information over the DS. APs
that advertise the same MDID shall be reachable over the DS and support the over-the-DS communication.
As a termination point, when the RRB at the target AP receives a request frame from the current AP, it
interacts with the MAC and other parts of the SME to process the request and respond with a Remote
Response frame, through the RRB on the current AP, back to the requesting FTO.
As a forwarding agent, when the RRB at the current AP receives a request from an FTO directed to another
AP in the same mobility domain, the current AP forwards the request to that target AP. The RRB on the
2124
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
current AP converts Action frames into Remote Request frames and converts Remote Response frames into
Action frames.
The target AP and the current AP need to reside in the same mobility domain to successfully exchange
Remote Request frames. The RRB on the current AP shall transmit Remote Request frames to the target AP
based on the BSSID of the target AP (supplied in the FT Action frames) using the same procedures as
preauthentication, as described in 12.6.10.2.
The message flow for a resource request over the DS is given in Figure 13-19. The FTO indicates the
destination target AP BSSID as part of the FT Action frame. The RRB on the current AP encapsulates the
FT Action frame and supplies the current AP BSSID in the Remote Request frame.
FTO Current AP Target AP
Successful (secure) session & Data
transmission
FT Action Request
(Request elements)
RemoteRequest ( current AP Address,
FT Action Request )
The Request is forwarded
Target AP
from current AP to target AP.
processes
RemoteResponse ( current AP Address, request
FT Action Response )
FT Action Response
(Response elements)
FT Action Confirm
(Confirm elements)
RemoteRequest ( current AP Address,
FT Action Confirm ) Target AP
processes
RemoteResponse ( current AP Address,
confirmation.
FT Action Acknowledge )
FT Action Acknowledgment
(Acknowledgment elements)
Figure 13-19—Sample message flow for over-the-DS resource request
13.10.3 Remote Request/Response frame definition
This subclause defines a mechanism to transport the remote request and remote response between the
current AP and the target AP. Any other mechanism may be used.
The Remote Request frame is transmitted over the DS from the current AP to the target AP. The Payload for
the Remote Request/Response frame is given in Table 13-2. Remote Request/Response frames shall use an
Ethertype of 89-0d, as specified in Annex H. The Remote Request/Response frame contains Version, Type,
and Length fields, along with the AP Address.
2125
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 13-2—Remote Request/Response Payload format
Size Information
1 FT Packet Type
2 FT Action Length
6 AP Address
Variable FT Action Frame
The FT Packet Type field shall be set to 0 for remote request and to 1 for remote response.
The FT Action Length field shall be set to an unsigned number representing the length in octets of the FT
Action Frame field, following the bit ordering conventions of 9.2.2.
The AP Address field shall be set to the BSSID of the current AP. The target AP shall use this address as the
destination address when sending the Remote Response frame as a response to the Remote Request.
The FT Action Frame field shall be set to the contents of the FT Action frame, from the Category field to the
end of the Action frame body.
13.11 Resource request procedures
13.11.1 General
When using the resource request procedure, the FTO has the option to request a resource allocation at the
target AP. To request resources, the FTO creates a resource information container (RIC) and inserts it in an
appropriate request message to the target AP. The request message is sent to the target AP either directly
(over the air), or via the current AP (over the DS), according to the FT procedures described in 13.5 and
13.6. In an RSNA, resource requests and responses are exchanged only after the establishment of the PTK
and are protected by MICs.
The RIC contains a complete list of resources requested by the FTO. An AP that receives a resource request
from an FTO shall discard any previous resource request from that FTO. In an RSN, this resource request
shall first be authenticated by the AP through checking of the MIC before the AP discards any previous
resource request.
If an FTO is performing a fast BSS transition according to the FT protocol, described in 13.5, it shall
generate a RIC and process the RIC-Response according to the procedures of 13.11.3.1, performing the
exchange in the Reassociation Request/Response frames.
If an FTO is performing a fast BSS transition according to the FT resource request protocol, described in
13.6, it shall generate a RIC and process the RIC-Response according to the procedures of 13.11.3.1,
performing the exchange in the Authentication-Confirm/Authentication-Ack frames (over the air) or FT
Confirm/FT Ack frames (over the DS).
13.11.2 Resource information container (RIC)
The RIC refers to a collection of elements that are used to express a resource request or response.
When used in making a request, a RIC has one or more Resource Requests, as shown in Figure 13-20.
2126
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Resource Request Resource Request Resource Request
Figure 13-20—RIC-Request format
Each Resource Request consists of an RDE followed by one or more alternative Resource Descriptors. An
example of a Resource Request is shown in Figure 13-21.
RDE Resource Descriptor
Figure 13-21—Resource Request format
Each Resource Descriptor consists of one or more elements. The possible Resource Descriptors that may
appear in a RIC, and the elements that they contain, are given in Table 13-3.
Table 13-3—Resource types and resource descriptor definitions
Resource type Resource Descriptor definition Notes
802.11 QoS In a request: TSPEC (see 9.4.2.30), followed May be sent by a QoS STA that is an FTO to a
by zero or more TCLAS (see 9.4.2.31), QoS AP. Definition of TSPEC elements shall
followed by zero or one TCLAS Processing be as given in 11.4. Definition of TCLAS,
(see 9.4.2.33), followed by zero or one TCLAS Processing, Expedited Bandwidth
Expedited Bandwidth Request elements Request, and Schedule elements, and the rules
(see 9.4.2.94). for including them in requests and responses,
shall be as given in 11.4. Resource request
In a response: a TSPEC element (see procedures shall be as given in 11.4.
9.4.2.30), followed by zero or one Schedule
elements (see 9.4.2.34), followed by zero or
more Delay elements (see 9.4.2.32), followed
by other optional elements as specified in
11.4.
Block Ack In a request: RIC Descriptor (see 9.4.2.51), Resource request procedures shall be as given
Parameters containing a Resource Type field identifying in 11.5.
Block Ack.
In a response: RIC Descriptor (see 9.4.2.51),
containing a Resource Type field identifying
Block Ack.
Vendor Specific RDE is followed by any vendor-specific
elements required to specify this resource.
If there are multiple Resource Descriptors, then they are treated as choices by the target AP. The AP attempts
to allocate whatever is specified in the first Resource Descriptor; if this fails, the AP attempts to allocate
whatever is specified in the next Resource Descriptor instead, and so on until a successful allocation or the
AP reaches the end of the Resource Descriptor list. Thus, an OR relationship exists between Resource
Descriptors that follow an RDE, with the Resource Descriptors appearing in order of preference.
An example of a Resource Request consisting of two alternative Resource Descriptors is shown in
Figure 13-22.
RDE Resource Descriptor Resource Descriptor
Figure 13-22—Resource Request example #1
2127
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For example, when the resource being requested is QoS for downstream traffic, a TSPEC element may be
followed by one or more TCLAS elements and, when multiple TCLAS elements are present, a TCLAS
Processing element and an Expedited Bandwidth Request (EBR) element. Such an example Resource
Request with two alternative TSPECs, the second of which has an EBR, is shown in Figure 13-23.
RDE TSPEC TCLAS TCLAS TCLAS TSPEC TCLAS TCLAS TCLAS EBR
Processing Processing
Figure 13-23—Resource Request example #2
An example of a RIC with two resource requests, each with a single TSPEC, is given in Figure 13-24.
RDE TSPEC RDE TSPEC
Figure 13-24—RIC-Request example #1
An example of a RIC with one resource request, with a choice of two TSPECs, is given in Figure 13-25.
This indicates that the target AP can select one of the two TSPECs.
RDE TSPEC TSPEC
Figure 13-25—RIC-Request example #2
An example of a RIC with a RIC Descriptor is given in Figure 13-26. The target AP can acknowledge if the
resource specified in the RIC Descriptor is available.
RDE RIC Descriptor (BlockAck)
Figure 13-26—RIC-Request example #3
When sent by an AP in response to a RIC-Request, the RIC-Response consists of a list of one or more
Resource Responses including one response for each of the Resource Requests that was contained in the
RIC-Request. The basic format of a RIC-Response is shown in Figure 13-27.
Resource Response Resource Response Resource Response
Figure 13-27—RIC-Response format
Each Resource Response consists of an RDE with the RDE identifier matching the RDE identifier in the
request, in the same order as the RDEs appeared in the request. The RDE is followed by zero or one
Resource Descriptors. If the request was not successful (as indicated in the RDE status), then the AP may
include a suggestion that could have been successful. If the resource request was successful, then the
particular Resource Descriptor (of the alternatives given by the FTO) is included in the response, as
modified by the AP during the processing of the resource request. For example, when the resource being
requested is QoS for upstream traffic, the TSPEC element may be followed by a Schedule element.
An example of a RIC-Response with two QoS resource responses, each with a single TSPEC and Schedule
element, is given in Figure 13-28.
RDE TSPEC Schedule RDE TSPEC Schedule
Figure 13-28—Example QoS RIC-Response
2128
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.11.3 Creation and handling of a resource request
13.11.3.1 FTO procedures
The resource request enables an FTO to request resources based on specified Resource Descriptors (e.g.,
TSPECs) before or at the time the FTO associates with the target AP. In using TSPECs for requesting QoS
resources, the TSPECs in the request need not belong to only active TSs; the FTO can send TSPECs for any
TS that it intends to use after the transition and request the same resources that would be requested by a later
ADDTS exchange. For each resource, the FTO may provide the AP with a choice of Resource Descriptors in
order of preference, any one of which meets the needs of the application.
The FTO shall construct the RIC with a number of Resource Requests, each delineated by an RDE.
The FTO shall indicate the resources required at the target AP. For QoS resources, each TS shall be
requested by a separate RDE and associated TSPEC(s). The RDE Identifier field in the RDE shall be an
arbitrary value chosen by the FTO that uniquely identifies the RDE within the RIC. The Status Code field
shall be set to SUCCESS, and the Resource Count field shall be set to the number of alternative Resource
Descriptors that follow.
Following each RDE, the FTO shall include one or more Resource Descriptors that define the resources
required for this TS. When multiple TSPECs follow an RDE as part of a single QoS resource request, a
logical “OR” relationship exists between them, and at most one of these TSPECs shall be accepted by the
AP. The FTO shall order the Resource Descriptors in decreasing order of preference.
In generating the RDE for QoS resources for a TS, the procedures of 11.4 shall be followed for the
generation of TSPECs and inclusion of TCLAS, TCLAS Processing, and Expedited Bandwidth Request
elements. If the TS is a downstream flow, then the RDE may also include one or more TCLAS element(s)
(defined in 9.4.2.31) and a TCLAS Processing element (defined in 9.4.2.33) if multiple TCLAS elements are
included, and an optional Expedited Bandwidth Request (EBR) element, defined in 9.4.2.94. If present, the
TCLAS shall appear after the corresponding TSPEC. If present, an EBR element shall appear after the
corresponding TSPEC, TCLAS, and TCLAS Processing elements of the TSPEC.
A resource request is considered successful if the status code SUCCESS is returned in each RDE.
If the frame containing the response to the resource request contains a status code other than SUCCESS, the
FTO considers that the request has failed and that no resources are being held at the target AP.
The response from the target AP contains a RIC-Response, with the RDEs in the response indicating which
resources were considered by the target AP and the setting of the status code indicating which Resource
Descriptors were accepted by the AP.
The RDE Identifier field in the RDE enables the FTO to match the response with the RDE in the request.
The value of the Status Code field is interpreted as follows:
— Status code = SUCCESS indicates that the request has been accepted. The RDE may be followed by
the Resource Descriptor that was accepted.
— Status code = not SUCCESS (one of the values from 9.4.1.9) indicates that the resources could not
be accepted. The RDE may be followed by a suggested Resource Descriptor that could have been
accepted.
A response to a successful resource request (other than in a Reassociation Request frame) may contain a
reassociation deadline. If the FTO does not initiate a Reassociation Request frame with the target AP within
the reassociation deadline (if appropriate), then the AP releases resources held for that FTO.
2129
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
13.11.3.2 AP procedures
When a RIC appears in a request message, the AP shall check its ability to allocate one resource for each
RDE in the RIC in the order appearing in the RIC. In a Reassociation Request frame, the QoS Capability
element shall be processed prior to the QoS resource requests in the RIC.
The behavior of the AP shall be identical to that described in the flowchart in Figure 13-29.
Start
Select first
RDE
Select first
Resource
Descriptor
Able to
accept this
resource
No
request?
More Select next
Yes Resource Resource
Descriptors? Yes Descriptor
Set status value to 0
Skip rest of this RDE
No
Set status to an
appropriate value
given in 9.4.1.9
More
RDEs? No
Yes
Select next
Exit
RDE
Figure 13-29—Overview of RIC processing at an AP
As shown in Figure 13-29, the Resource Descriptors are examined by the AP in the order presented, and the
first that could have been allocated is accepted. Thus the preference ordering by the FTO is honored.
2130
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The target AP’s SME examines the resource requests in the RIC. For requests that require processing by the
MAC sublayer, the SME generates an MLME-RESOURCE-REQUEST-LOCAL.request primitive. The
MAC shall respond with MLME-RESOURCE-REQUEST-LOCAL.confirm primitive that indicates
whether the MAC has accepted the resource request. The SME may also send these resource requests to an
external entity such as a backend QoS module for its consideration; these procedures are beyond the scope
of this standard. The acceptance of a TSPEC by the target AP results in the resource allocation for a TS at
the target AP.
In response to a RIC-Request, the AP shall construct a RIC-Response. The RIC-Response shall contain one
RDE for each RDE in the RIC-Request. The RDEs shall be in the same order as in the request, and the RDE
Identifier field in each RDE shall be the value of the RDE Identifier field in the corresponding RDE in the
request. The Status Code field in the RDE shall be set according to the result of the allocation request as
follows:
— Status code = SUCCESS indicates that the resource request has been accepted. The RDE shall also
be followed by the Resource Descriptor that was accepted.
— Status code = not SUCCESS indicates that the resources could not be accepted. The Status Code
field contains a value from 9.4.1.9 indicating the reason for the failure. In this case, the AP may
include a single Resource Descriptor following the RDE indicating a suggested resource that could
have been accepted. The Resource Count field shall be set to 0 or 1 depending whether the suggested
Resource Descriptor is attached. A not SUCCESS status code in an RDE shall not cause a not
SUCCESS status code in the frame containing the RIC.
If the resource request included QoS resources and is successful, then the procedures for handling of
TSPEC, TCLAS, TCLAS Processing and Expedited Bandwidth Request elements shall be as specified in
11.4, and the AP shall place the TSs into the accepted state. The RIC-Response shall contain the updated
accepted TSPEC. Each RDE may also include a Schedule element (as defined in 9.4.2.34) after the accepted
TSPEC. Upon reassociation, AP shall move all of the TSs from the accepted state into the active state.
If the FTO does not invoke a reassociation within the reassociation deadline, then the TSs that had been
accepted shall become inactive, and the resources shall be released. At the point that the FTO reassociates
with the target AP (within the reassociation deadline, if appropriate), the TSs are put into the active state.
This may be immediate if the RIC-Request was part of a Reassociation Request frame.
2131
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14. MLME mesh procedures
14.1 Mesh STA dependencies
When dot11MeshActivated is true, the STA is a mesh STA.
When dot11MeshActivated is true, following MIB attributes shall be true.
— dot11QosOptionImplemented
— dot11ExtendedChannelSwitchActivated (only when dot11SpectrumManagementRequired is true)
When dot11MeshActivated is true, following MIB attributes shall be false.
— dot11OCBActivated
— dot11FastBSSTransitionActivated
A mesh STA does not support functionalities that depend on AP or are only available in an infrastructure
BSS, such as HCCA, traffic specifications (TSPECs), traffic stream (TS) management, admission control,
automatic power save delivery (APSD), direct-link setup (DLS), or tunneled direct-link setup (TDLS).
An HT mesh STA does not support PSMP, STBC, or PCO.
When dot11DMGOptionImplemented is true, dot11MeshActivated shall be false.
14.2 Mesh discovery
14.2.1 General
A mesh STA shall perform either active scanning or passive scanning to discover an operating mesh BSS
using the MLME-SCAN.request primitive (see 6.3.3). A mesh profile, a set of parameters identifying the
mesh BSS configuration, is also obtained through the scanning process, and it is used to determine the
scanning mesh STA’s active mesh profile. Based on the result of the scan, the mesh STA may establish a new
mesh BSS or become a member of the existing mesh BSS, using the START primitive (see 6.3.11). The
MLME-START.request primitive triggers beaconing that facilitates the discovery of the mesh STA by the
neighbor mesh STAs. A mesh STA that becomes a member of a mesh BSS should establish a mesh peering
with one or more neighbor mesh STAs that are in the same mesh BSS.
14.2.2 Mesh identifier
The Mesh ID is an identifier of an MBSS. The Mesh ID may be installed in mesh capable devices by a
variety of means that are beyond the scope of this standard. For example, the Mesh ID might be set by the
user, e.g., “Mike’s Mesh.” A mesh STA shall include the Mesh ID element (see 9.4.2.99) in its Beacon and
Probe Response frames, in order to advertise its identity. The mesh STA shall also include the Mesh ID
element in its Mesh Peering Open frames, Mesh Peering Confirm frames, and Mesh Peering Close frames.
The mesh STA shall set the SSID element (see 9.4.2.2) in Beacon, Probe Request, and Probe Response
frames to the wildcard SSID.
NOTE—The wildcard SSID is used to notify nonmesh STAs that the mesh STA is neither a part of an infrastructure BSS
nor an IBSS, so that the nonmesh STAs do not try to join the mesh BSS.
2132
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.2.3 Mesh profile
A mesh profile is a set of parameters that specifies the attributes of a mesh BSS. A mesh profile consists of
the following:
a) A Mesh ID—specified by dot11MeshID
b) A path selection protocol identifier—specified by dot11MeshActivePathSelectionProtocol
c) A path selection metric identifier—specified by dot11MeshActivePathSelectionMetric
d) A congestion control mode identifier—specified by dot11MeshActiveCongestionControlMode
e) A synchronization method identifier—specified by dot11MeshActiveSynchronizationMethod
f) An authentication protocol identifier—specified by dot11MeshActiveAuthenticationProtocol
In a mesh BSS all mesh STAs use the same mesh profile. Two mesh profiles are considered to be the same if
all of their parameters match.
Before establishing a mesh BSS or becoming a member of a mesh BSS, a mesh STA shall configure one
mesh profile. The mesh STA shall not change its mesh profile unless it leaves the mesh BSS of which it is a
member. When the mesh STA leaves the mesh BSS of which it is a member, it should explicitly close all of
its active mesh peerings using Mesh Peering Close frames (see 14.3.8) and shall discard all session
information obtained while the mesh profile was active, such as local forwarding information, security
associations (and related keys), etc. The MLME receives the mesh STA’s mesh profile from the SME upon
receipt of the MLME-START.request primitive.
The mesh profile is signaled by means of the Mesh ID element and the Mesh Configuration element. The
mesh profile is included in the Beacon and Probe Response frames, so that the mesh profile can be obtained
by its neighbor mesh STAs through scanning. Mesh Peering Open and Mesh Peering Confirm frames also
contain a mesh profile.
14.2.4 Mesh STA configuration
The mesh STA configuration consists of the mesh profile (see 14.2.3), the Supported Rates and BSS
Membership Selectors element, the Extended Supported Rates and BSS Membership Selectors element, the
HT Operations element (if present), and the VHT Operations element (if present).
Mesh STA configurations are identical if the following conditions hold:
— The mesh profiles are identical.
— The BSSBasicRateSet parameter of the MLME-START.request is identical to the basic rate set
indicated by the Supported Rates and BSS Membership Selectors element and Extended Supported
Rates and BSS Membership Selectors element, if present, received in the MLME-
MESHPEERINGMANAGEMENT.indication.
— For HT mesh STAs, the Basic HT-MCS Set field of the HT Operation parameter of the MLME-
START.request is identical to the HT Operation element received in the MLME-
MESHPEERINGMANAGEMENT.indication.
— For VHT mesh STAs, the Basic VHT-MCS and NSS fields in the VHT Operation element of the
MLME-START.request are identical to the Basic VHT-MCS and NSS fields in the VHT Operation
element received in the MLME-MESHPEERINGMANAGEMENT.indication.
14.2.5 Supplemental information for the mesh discovery
A mesh STA shall signal whether it is able to establish additional mesh peerings. A mesh STA signals its
ability to establish additional mesh peerings by setting the Accepting Additional Mesh Peerings subfield in
the Mesh Capability field in the Mesh Configuration element to 1 (see 9.4.2.98.8).
2133
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The mesh STA sets the Accepting Additional Mesh Peerings subfield in the Mesh Capability field in the
Mesh Configuration element to 0 when it is not able to accept new mesh peerings. This parameter is
dynamically controlled by the SME and given to the MLME by dot11MeshAcceptingAdditionalPeerings.
NOTE—This control is driven by internal policies. When the Accepting Additional Mesh Peering subfield is 1, the mesh
STA is assumed to have sufficient internal resources to accommodate more mesh peerings. The internal policy is outside
the scope of this standard. For instance, a mesh STA might be configured to be able to maintain only two mesh peerings.
A mesh STA shall announce its topological information through the Mesh Formation Info field in the Mesh
Configuration element. The contents of the Mesh Formation Info field shall be coded to reflect the current
configuration.
14.2.6 Scanning mesh BSSs
A mesh STA shall perform active scanning or passive scanning, depending on the value of the ScanMode
parameter of the MLME-SCAN.request primitive (see 11.1.4), to discover neighbor mesh STAs. Upon
receipt of an MLME-SCAN.request primitive with the Mesh ID parameter set to the wildcard Mesh ID, the
STA shall passively scan for any Beacon frames, or actively transmit Probe Request frames containing the
wildcard Mesh ID, as appropriate, depending on the value of ScanMode. Upon completion of scanning, an
MLME-SCAN.confirm primitive is issued by the MLME indicating all of the discovery information
received. Further, a mesh STA shall comply with the passive scan procedure as described in 11.1.4.2 and the
active scan procedure as described in 11.1.4.3.
14.2.7 Candidate peer mesh STA
When a mesh STA discovers a neighbor mesh STA through the scanning process and the discovered mesh
STA is considered a candidate peer mesh STA, it may become a member of the mesh BSS of which the
discovered mesh STA is a member and establish a mesh peering with the neighbor mesh STA.
The discovered neighbor mesh STA shall be considered a candidate peer mesh STA if and only if all of the
following conditions are met:
a) The mesh STA uses the same mesh profile as the received Beacon or Probe Response frame
indicates for the neighbor mesh STA.
NOTE—If the scanning mesh STA has not become a member of any MBSS yet, it might simply activate the
same mesh profile as the discovered neighbor mesh STA’s profile to fulfill this condition.
b) The Accepting Additional Mesh Peerings subfield in the Mesh Capability field in the received
Beacon or Probe Response frame equals 1.
c) The mesh STA supports the data rates indicated by the BSSBasicRateSet of the received Beacon or
Probe Response frame.
d) If both the scanning mesh STA and the discovered neighbor STA are HT STAs, the STA has the
same value in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-
START.request primitive as the received Beacon or Probe Response frame indicates for the neigh-
bor mesh STA.
e) If both the scanning mesh STA and the discovered neighbor STA are VHT STAs, the mesh STA
uses the same value for the Basic VHT-MCS And NSS Set field in its VHT Operation element as
received in the Beacon or Probe Response frame from the neighbor mesh STA.
f) If the scanning mesh STA has dot11MeshSecurityActivated equal to true and the
dot11MeshActiveAuthenticationProtocol is ieee8021x (2), either the scanning mesh STA has an
active connection to an AS or the discovered mesh STA has the Connected to AS subfield in the
Mesh Formation field in the Mesh Configuration element equal to 1 in the received Beacon or Probe
Response frame.
2134
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.2.8 Establishing or becoming a member of a mesh BSS
The Mesh Formation Info field in the Mesh Configuration element is available to assist scanning mesh STAs
in choosing the mesh BSS of which to become a member. The details of the usage of this information are
beyond the scope of this standard.
NOTE—Selection of the mesh BSS of which the scanning mesh STA becomes a new member is outside the scope of
this standard. That is, the mesh STA might freely select the mesh BSS of a candidate peer mesh STA of which it
becomes a new member.
After the determination of the active mesh profile, the mesh STA may establish a new mesh BSS or become
a new member to an existing mesh BSS.
When dot11MBCAActivated is true, the mesh STA shall perform the TBTT selection procedure described in
14.13.4.3 using TimeStamp, Local Time, Beacon Period, and Beacon Timing in the BSSDescriptionSet
parameter given by the MLME-SCAN.confirm primitive, before starting its beaconing.
When dot11MCCAActivated is true, the mesh STA shall choose a DTIM interval with a duration of 2n 100
TU with n a non-negative integer less than or equal to 17.
NOTE—It is allowed that a different value for the DTIM interval is used for mesh STAs that use MCCA in an MBSS
that is centrally controlled and the central authority provides a coordination of the DTIM interval of mesh STAs that use
MCCA in the MBSS.
The mesh STA establishes a new mesh BSS by activating a mesh profile that is different from any mesh
profile discovered during the scanning of mesh BSSs (see 14.2.6).
The mesh STA becomes a new member of an existing mesh BSS by activating the same mesh profile as
received from a candidate peer mesh STA of this mesh BSS (see 14.2.6 and 14.2.7).
In either case, the mesh STA shall start beaconing using the START primitive. Upon receipt of the MLME-
START.request primitive, the mesh STA shall initialize and start its TSF timer as specified by its active
synchronization method as described in 14.13.2, and begin transmitting Beacon frames as described in
14.13.3.
If the mesh STA has become a new member of an existing mesh BSS, it should establish a mesh peering
with one or more candidate peer mesh STAs of this mesh BSS (see 14.2.9) in order to form the MBSS.
If the mesh STA has become a new member of an existing mesh BSS, it shall adopt the BSSBasicRateSet
parameter from a candidate peer mesh STA of this mesh BSS.
After establishing or becoming a member of an MBSS, the mesh STA may continue the discovery procedure
described in 14.2.6 to discover other candidate peer mesh STAs.
14.2.9 Establishing mesh peerings
Mesh peerings shall be established only with candidate mesh STAs that are members of the same MBSS.
A mesh peering is established between the mesh STA and the candidate peer mesh STA after the successful
completion of the mesh peering management (MPM) protocol (see 14.3) or of the authenticated mesh
peering exchange (AMPE) (see 14.5). When establishing a secure mesh peering, mesh STAs authenticate
each other and create a mesh PMKSA before processing the AMPE (see 14.3.3).
A candidate peer mesh STA becomes a peer mesh STA when a mesh peering is established between the two
mesh STAs.
2135
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When dot11MeshActiveSynchronizationMethod is neighborOffsetSynchronization (1), a mesh STA may
establish mesh peerings with up to dot11MeshNbrOffsetMaxNeighbor mesh STAs (see 14.13.2.2.1).
14.3 Mesh peering management (MPM)
14.3.1 General
The mesh peering management (MPM) protocol is used to establish, maintain, and close mesh peerings
between mesh STAs when dot11MeshSecurityActivated is false. When dot11MeshSecurityActivated is true,
the peers establish an authenticated mesh peering using the authenticated mesh peering exchange (AMPE)
protocol. The AMPE protocol requires an existing mesh PMKSA. If a mesh PMKSA with the candidate peer
mesh STA exists, the AMPE shall use that mesh PMKSA. If no mesh PMKSA exists, the peers shall first
authenticate to establish a mesh PMKSA; see 14.5.
Figure 14-1 shows the logical flow of protocol interactions in the peering management framework.
Candidate peer discovery
N Security
enabled?
Y
N
MPM Shared PMK N N MPM N
API is SAE?
succeeds? exists? succeeds?
Y Y Y Y
SAE N
authentication
succeeds?
Y IEEE 802.1X N
authentication
succeeds?
Y
AMPE N
succeeds?
Y
Mesh peering
Mesh peering
security association
Figure 14-1—Logical flowchart of protocol interaction in the mesh peering management
framework
2136
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The MPM protocol uses Mesh Peering Open frames, Mesh Peering Confirm frames, and Mesh Peering
Close frames to establish, manage, and tear down a mesh peering.
The protocol succeeds in establishing a mesh peering when the following requirements are satisfied: 1) both
mesh STAs have sent and received (and correctly processed) a Mesh Peering Open frame for this mesh
peering; 2) both mesh STAs have sent and received (and correctly processed) a corresponding Mesh Peering
Confirm frame for this mesh peering.
A mesh STA that receives and accepts a Mesh Peering Open frame (see 14.3.6.2) shall assign a unique AID
among its neighbor peer mesh STAs to the transmitter of the frame. Since the AID is used in the encoding of
the TIM element in the Beacon frame (see 9.4.2.6), the setting of the AID value is constrained as described
in 9.4.1.8. AID 0 (zero) is reserved to indicate the presence of buffered group addressed MSDUs and
MMPDUs (see 14.14.4).
14.3.2 State variable management
A mesh STA keeps an enumerated state variable (see 11.3.1) for each neighbor STA with which direct
communication via the WM is needed. This state variable expresses the relationship between the local STA
and a neighbor STA that varies depending on the active authentication protocol. It takes on the values shown
in Table 14-1.
Table 14-1—State variables for mesh STAs
Active authentication
State
None SAE IEEE Std 802.1X
State 1 Initial start state, mesh peering Initial start state, Initial start state,
not established unauthenticated, mesh peering unauthenticated, mesh peering
not established not established
State 2 N/A Authenticated, mesh peering N/A
not established
State 3 Mesh peering established Authenticated, mesh peering Unauthenticated, mesh
established peering established (Pending
IEEE 802.1X authentication)
State 4 N/A N/A Authenticated, mesh peering
established
The state transitions in accordance with the protocol interaction shown in Figure 14-1.
The current state existing between the neighbor STAs determines the IEEE 802.11 frame types that may be
exchanged between that pair of STAs (see Clause 9). The allowed frame types are grouped into classes and
the classes correspond to the STA state. The allowed frame types and the frame classes in each state are
defined in 11.3.3.
A mesh STA shall not transmit frames other than the ones used for candidate peer mesh STA discovery,
MPM, and SAE to a neighboring mesh STA until a mesh peering has been established with the mesh STA.
14.3.3 Mesh authentication
See 12.6.1.3.4.
2137
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.3.4 Mesh peering instance controller
14.3.4.1 Overview
A mesh STA uses a mesh peering instance controller to manage all mesh peering instances.
The mesh peering instance controller performs the following functions:
— Create and delete MPM finite state machines and AMPE finite state machines
— Manage instance identifiers for each mesh peering instance
— Manage mesh TKSAs for each mesh peering instance when dot11MeshSecurityActivated is true
— Preprocess the incoming mesh peering Management frames and pass the frames to the finite state
machine with matching instance identifier
— Pass internal commands to the finite state machine with matching instance identifier
A mesh peering instance is identified by a mesh peering instance identifier. The mesh peering instance
identifier is the set of localLinkID, localMAC, and peerMAC.
A mesh peering instance consists of its identifier (the localLinkID, localMAC, peerMAC), a peerLinkID (an
integer generated by the peer mesh STA or candidate peer mesh STA), and the configuration and capability
negotiated and agreed upon by exchanging Mesh Peering Open frames (see 9.6.16.2) and Mesh Peering
Confirm frames (see 9.6.16.3). If dot11MeshSecurityActivated is true, the mesh peering instance also
contains a PMKID identifying the shared PMKSA, a localNonce chosen by the mesh STA and a peerNonce
chosen by the peer mesh STA or candidate peer mesh STA.
The localMAC is the MAC address of the mesh STA that is managing this mesh peering instance. The
peerMAC is the MAC address of the peer mesh STA or the candidate peer mesh STA. The localLinkID is an
integer generated by the mesh STA. The localLinkID shall be unique among all existing link identifiers used
by the mesh STA for its MPM finite state machines. The mesh STA selects the localLinkID to provide high
assurance that the same number has not been used to identify a recent MPM finite state machine. The
peerLinkID is the localLinkID of the peer mesh STA or candidate peer mesh STA and is supplied in the
Mesh Peering Management element (see 9.4.2.102) of the Mesh Peering Open and Mesh Peering Confirm
frames.
A mesh peering instance is controlled by an MPM finite state machine (see Table 14-2 in 14.4.5) or an
AMPE finite state machine (see Table 14-3 in 14.5.6.3).
14.3.4.2 Creating a new mesh peering instance
The mesh peering instance controller creates a new mesh peering instance after either of the following two
events:
— The receipt of a Mesh Peering Open frame from a candidate peer mesh STA according to the rules
of 14.3.5
— The receipt of an MLME-MESHPEERINGMANAGEMENT.request primitive with a Mesh Peering
Open frame
A unique localLinkID shall be generated for the mesh peering instance. If the mesh peering instance is
established by AMPE, a random local nonce shall also be generated.
A mesh STA may create multiple mesh peering instances to establish a peering with the same candidate peer
mesh STA.
2138
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.3.4.3 Deleting mesh peering instances
The mesh peering instance controller deletes a mesh peering instance after either:
— Expiration of a holding timer (see 14.4.4).
— The acceptance of a peer’s response to an existing request to close the peering (see 14.4.3).
— Indication from the SME that the peer mesh STA, or candidate peer mesh STA, has deauthenticated.
When the deletion occurs, the mesh TKSA that is bound to the mesh peering shall be deleted.
14.3.5 Mesh peering instance selection
The content of a mesh peering Management frame received from a candidate peer mesh STA, and the set of
mesh peering instances in the mesh peering instance controller determine whether
— A new mesh peering instance is created (see 14.3.4.2); or,
— An existing mesh peering instance is updated
If dot11MeshSecurityActivated is true and the mesh STA shares a PMK with the candidate peer mesh STA
but the Mesh Peering Protocol Identifier field in the Mesh Peering Management element of the frame
indicates “mesh peering management protocol,” the frame shall be silently discarded.
If dot11MeshSecurityActivated is true and the mesh STA shares a PMK with the candidate peer mesh STA
but either the Mesh Peering element or the MIC element are not present in the frame, the frame shall be
silently discarded.
If dot11MeshSecurityActivated is false but the Mesh Peering Protocol Identifier field in the Mesh Peering
Management element of the received frame indicates “authenticated mesh peering exchange,” the frame
shall be silently discarded.
If dot11MeshSecurityActivated is false but either the Mesh Peering element or the MIC element is present in
the frame, the frame shall be silently discarded.
If the frame contains a group address in TA or RA, it shall be silently discarded.
If the incoming mesh peering Management frame is for AMPE and the Chosen PMK from the received
frame contains a PMKID that does not identify a valid mesh PMKSA, the frame shall be silently discarded.
If the mesh peering Management frame has not been silently discarded, the mesh peering instance controller
attempts to locate a matching mesh peering instance identifier. A match is determined by comparing the
contents of the mesh peering Management frame with each peering instance. A match is found if all of the
following conditions are true:
— The transmitter’s MAC address (Address 2) is the same as the peerMAC of the mesh peering
instance
— The receiver’s MAC address (Address 1) is the same as the localMAC of the mesh peering instance
— The value of the Peer Link ID field is the same as the localLinkID of the mesh peering instance
If the incoming frame is a Mesh Peering Open frame and no matching peering instance was found, a new
mesh peering instance is created (and a new Mesh TSKA if dot11MeshSecurityActivated is true). See
14.3.4.2.
If the incoming frame is a Mesh Peering Confirm or Mesh Peering Close frame and no matching mesh
peering instance is found, it shall be silently discarded.
2139
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the incoming mesh peering Management frame is for AMPE and has not been discarded it shall be further
processed as follows:
— If the Peer Nonce field is present in the received frame, and the localNonce in the mesh peering
instance is different from the Peer Nonce field of the received frame, the frame shall be dropped.
— If the peerNonce in the mesh peering instance exists and is different from the Local Nonce field of
the received frame, the frame shall be dropped.
14.3.6 Mesh peering open
14.3.6.1 Generating Mesh Peering Open frames
A Mesh Peering Open frame is generated as a result of a sendOpen() action (see 14.4.3).
The contents of the frame are described in 9.6.16.2.2.
14.3.6.2 Mesh Peering Open frame processing
The mesh STA checks that the Mesh ID element and Mesh Configuration element of the Mesh Peering Open
frame is identical to its own mesh STA configuration as specified in 14.2.3 and 14.2.4. If a mismatch is
found the frame shall be rejected with a reason code of MESH-CONFIGURATION-POLICY-VIOLATION
and the mesh peering establishment attempt shall be terminated.
When the mesh STA has established a mesh PMKSA with the candidate peer mesh STA, the mesh peering
instance controller shall silently discard the Mesh Peering Open frame in the following two conditions:
— The Mesh Peering Open frame supports MPM protocol and the negotiated active authentication is
SAE, or
— The Mesh Peering Open frame supports AMPE but the PMKID in the Chosen PMK field in the
Authenticated Mesh Peering Exchange element does not identify a mesh PMKSA.
If the Mesh Peering Open frame is not discarded, the mesh peering instance controller actively rejects or
accepts the mesh peering open request (see 14.4). If dot11MeshAcceptingAdditionalPeerings is set to 0 the
Mesh Peering Open request shall be rejected with reason code MESH-MAX-PEERS.
If the peerLinkID in the mesh peering instance has not been set, the Local Link ID field of the Mesh Peering
Open request shall be copied into the peerLinkID in the mesh peering instance. If the incoming Mesh
Peering Open frame is for AMPE and the peerNonce in the mesh peering instance has not been set, the Local
Nonce field in the incoming Mesh Peering Open frame shall be copied into the peerNonce in the mesh
peering instance.
The mesh peering open request may be rejected due to an internal reason with a reason code of MESH-
PEERING-CANCELED.
NOTE—Example internal reasons to reject new mesh peering request could be the mesh STA is configured to reject
mesh peering request from another specific peer mesh STA.
If the Mesh Peering Open request is rejected, the REQ_RJCT event shall be passed with the specified reason
code to the protocol finite state machine to actively reject the mesh peering open request.
14.3.7 Mesh peering confirm
14.3.7.1 Generating Mesh Peering Confirm frames
A Mesh Peering Confirm frame is generated as a result of a sendConfirm() action (see 14.4.3).
2140
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The contents of the frame are described in 9.6.16.3.2.
14.3.7.2 Mesh Peering Confirm frame processing
The mesh STA shall check that the Mesh ID element and Mesh Configuration element of the Mesh Peering
Confirm frame match its own mesh STA configuration as specified in 14.2.3 and 14.2.4. If a mismatch is
found, the frame shall be rejected with the reason code of MESH-INCONSISTENT-PARAMETERS.
If the Mesh Peering Confirm frame is rejected, the REQ_RJCT event shall be passed with the specified
reason code to the protocol finite state machine to actively reject the mesh peering confirm.
Otherwise, the mesh STA accepts the Mesh Peering Confirm frame and performs the actions described
in 14.4.
If the peerLinkID in the mesh peering instance has not been set, the Local Link ID field of the Mesh Peering
Confirm request shall be copied into the peerLinkID in the mesh peering instance. If the incoming Mesh
Peering Confirm frame is for AMPE and the peerNonce in the mesh peering instance has not been set, the
Local Nonce field in the incoming Mesh Peering Confirm frame shall be copied into the peerNonce in the
mesh peering instance.
14.3.8 Mesh peering close
14.3.8.1 Generating Mesh Peering Close frames
A Mesh Peering Close frame is generated as a result of a sendClose() action (see 14.4.3).
The contents of the frame are described in 9.6.16.4.2.
When the Mesh Peering Close is generated as a result of a CNCL event, the reason code is MESH-
PEERING-CANCELED. When the Mesh Peering Close is generated as a result of a CLS_ACPT event, the
reason code is MESH-CLOSE-RCVD.
14.3.8.2 Mesh Peering Close frame processing
The mesh STA shall reject the Mesh Peering Close frame if the value in the Mesh ID element is not the same
as the mesh STA’s mesh profile. Otherwise, the mesh STA accepts the Mesh Peering Close frame and
performs the actions described in 14.4.
14.4 Mesh peering management finite state machine (MPM FSM)
14.4.1 General
Each mesh peering instance, including its states and resource, are managed by a mesh peering management
finite state machine (MPM FSM). The MPM FSM uses MLME primitives to control the mesh STA to send
and receive mesh peering Management frames.
14.4.2 States
The MPM FSM uses the following six states:
— IDLE—IDLE state is a terminal state. In the IDLE state, the MPM FSM is ready to start a new mesh
peering instance by either passively listening for an incoming Mesh Peering Open frame or actively
initiating a mesh peering instance.
2141
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— OPN_SNT—In the OPN_SNT state, the finite state machine has sent a Mesh Peering Open frame
and is waiting for a Mesh Peering Open frame and Mesh Peering Confirm frame from the candidate
peer mesh STA.
— CNF_RCVD—In the CNF_RCVD state, the finite state machine has received a Mesh Peering
Confirm frame, but has not received a Mesh Peering Open frame. The mesh STA has not sent the
corresponding Mesh Peering Confirm frame yet.
— OPN_RCVD—In the OPN_RCVD state, the finite state machine has received only the Mesh
Peering Open frame but not the Mesh Peering Confirm. The mesh STA has also sent a Mesh Peering
Confirm frame upon receiving a Mesh Peering Open frame.
— ESTAB—In the ESTAB state, the finite state machine has received both the Mesh Peering Open and
Mesh Peering Confirm frames. The mesh STA has also sent both the Mesh Peering Open frame and
Mesh Peering Confirm frame. The mesh peering is established and configured for exchanging
frames with the peer mesh STA in the ESTAB state.
— HOLDING—In the HOLDING state, the finite state machine is closing the mesh peering instance
with the peer mesh STA or the candidate peer mesh STA.
14.4.3 Events and actions
The finite state machine uses three types of events: 1) events for state machine transitions; 2) external events
generated by frame processing; and 3) events associated with internal timers.
The events for state machine transitions are as follows:
— CNCL(localLinkID, peerMAC, ReasonCode)—Used to instruct the mesh peering instance to cancel
the mesh peering with the peer mesh STA. localLinkID identifies the MPM FSM for the
corresponding mesh peering instance. peerMAC is the MAC address of the peer mesh entity.
ReasonCode is used to inform the reason to cancel the mesh peering instance. See 14.3.8.2.
— ACTOPN(peerMAC, localLinkID)—The SME uses this event to create a new mesh peering
instance to actively initiate the mesh peering establishment with the candidate peer mesh STA
whose MAC address is peerMAC. localLinkID identifies the MPM FSM.
The events generated by frame processing are as follows:
— OPN_ACPT—PeeringOpen_Accept(peerMAC, peerLinkID) event indicates that a Mesh Peering
Open frame meeting the correctness criteria of 14.3.6 has been received from peerMAC for the
mesh peering instance identified by peerLinkID.
— OPN_RJCT—PeeringOpen_Reject(peerMAC, peerLinkID, meshConfiguration, reasonCode) event
indicates that a Mesh Peering Open frame from peerMAC for the mesh peering instance identified
by peerLinkID is rejected due to incomplete or erroneous mesh STA configuration (see 14.2.4), as
indicated by meshConfiguration, with reasonCode being the specific reason for rejection of the
Mesh Peering Open frame. See 14.3.6.2.
— CNF_ACPT—PeeringConfirm_Accept(peerMAC, localLinkID, peerLinkID) event indicates that a
Mesh Peering Confirm frame meeting the correctness criteria of 14.3.7 has been received from
peerMAC for the mesh peering instance identified by localLinkID and peerLinkID.
— CNF_RJCT—PeeringConfirm_Reject(peerMAC, localLinkID, peerLinkID, reasonCode) event
indicates that a Mesh Peering Confirm frame from peerMAC for the mesh peering instance
identified by localLinkID and peerLinkID is rejected due to incomplete or erroneous configuration,
and reasonCode is the specific reason for rejection of the Confirm frame. See 14.3.7.2.
— CLS_ACPT—PeeringClose_Accept(peerMAC, localLinkID, peerLinkID, reasonCode) event
indicates that a Mesh Peering Close frame meeting the correctness criteria of 14.3.8 has been
received from peerMAC for the mesh peering instance identified by localLinkID and peerLinkID.
The reasonCode specifies the reason that caused the generation of the Mesh Peering Close frame.
See 14.3.8.2.
2142
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— REQ_RJCT—PeeringRequest_Reject(peerMAC, peerLinkID, reasonCode) event indicates a special
incidence that the mesh STA rejects the incoming Mesh Peering Open frame requesting to set up a
new mesh peering for some specified reason. The incoming request is identified by the peerMAC,
peerLinkID is the peerLinkID received from the Mesh Peering Open frame, and reasonCode is the
specific reason for rejection of the Mesh Peering Open frame. See 14.3.6.2.
The finite state machine may take an action triggered by an event. It uses two types of actions: sending a
mesh peering Management frame and handling a timer.
Actions related to sending a mesh peering Management frame are as follows:
— sndOPN—sendOpen(peerMAC, localLinkID, meshConfiguration) is the action that the mesh STA
takes to send its localLinkID and mesh STA Configuration in a Mesh Peering Open frame to the
candidate peer mesh STA, whose MAC address is peerMAC. The MLME-
MESHPEERINGMANAGEMENT.request primitive shall be invoked to send the frame to the peer
mesh entity.
— sndCNF—sendConfirm(peerMAC, localLinkID, peerLinkID, meshConfiguration) is the action that
the mesh STA takes to send its localLinkID and meshConfiguration in a Mesh Peering Confirm
frame to the candidate peer mesh STA, whose MAC address is peerMAC. peerLinkID is the
peerLinkID received from the Mesh Peering Open frame. The MLME-
MESHPEERINGMANAGEMENT.request primitive shall be invoked to send the frame to the peer
mesh entity.
— sndCLS—sendClose(peerMAC, localLinkID, peerLinkID, reasonCode) is the action that the mesh
STA takes to send its localLinkID in a Mesh Peering Close frame to the peer mesh STA or candidate
peer mesh STA, whose MAC address is peerMAC. peerLinkID is the peerLinkID received from the
Mesh Peering Open frame, and reasonCode is the specific reason for closing the mesh peering. The
MLME-MESHPEERINGMANAGEMENT.request primitive shall be invoked to send the frame to
the peer mesh entity.
14.4.4 Timers
The following three timers are used by the finite state machine:
a) The retryTimer triggers a resend of the Mesh Peering Open frame when a Mesh Peering Confirm
frame was not received as a response. The retryTimer is set to the dot11MeshRetryTimeout.
b) The confirmTimer signals that a link establishment attempt should be aborted because a Mesh
Peering Confirm frame responding to a Mesh Peering Open frame was never received. The confirm-
Timer is set to dot11MeshConfirmTimeout.
c) The holdingTimer signals that its mesh peering instance may be completely closed and facilitates
graceful shutdown. The holdingTimer is set to dot11MeshHoldingTimeout.
The events associated with internal timers are represented in the state machine table as acronyms that
indicate timer expiration. With each timer event there is an associated action.
— TOR1—This event indicates that the retryTimer has expired and dot11MeshMaxRetries has not
been reached. The Mesh Peering Open frame shall be resent, an action represented in the state
machine table by setR.
— TOR2—This event indicates that the retryTimer has expired and dot11MeshMaxRetries has been
reached. The mesh peering instance shall be closed when TOR2 occurs.
— TOC—This event indicates that the confirmTimer has expired. When TOC event occurs, the mesh
peering instance shall be closed, an action represented in the state machine table as setC.
— TOH—This event indicates that the holdingTimer has expired. When TOH occurs, the mesh peering
instance shall be closed and the finite state machine shall transition to IDLE state, an action
represented in the state machine table as setH.
2143
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.4.5 State transitions
Table 14-2 and Figure 14-2 summarize the state transitions for the MPM protocol.
In Table 14-2, each row represents state transitions from the state to all other states. A blank entry indicates
an impossible transition.
Table 14-2—MPM finite state machine
To State
IDLE OPN_SNT CNF_RCVD OPN_RCVD ESTAB HOLDING
IDLE REQ_RJCT ACTOPN / OPN_ACPT
/ sndCLS (sndOPN, / (sndOPN,
setR) sndCNF,
setR)
OPN_SNT TOR1 / CNF_ACPT OPN_ACPT CLS_ACPT,
(sndOPN, / (clR, setC) / (sndCNF) OPN_RJCT,
setR) CNF_RJCT,
TOR2,
CNCL /
(sndCLS,
clR, setH)
CNF_RCV OPN_ACPT CLS_ACPT,
D / (clC, OPN_RJCT,
sndCNF) CNF_RJCT,
CNCL /
(sndCLS,
clC, setH)
TOC /
From State
(sndCLS,
setH)
OPN_RCV OPN_ACPT CNF_ACPT CLS_ACPT,
D / sndCNF / clR OPN_RJCT,
TOR1 / CNF_RJCT,
(sndOPN, TOR2,
setR) CNCL /
(sndCLS,
clR, setH)
ESTAB OPN_ACPT CLS_ACPT,
/ sndCNF OPN_RJCT,
CNF_RJCT,
CNCL /
(sndCLS,
setH)
HOLDING TOH / —, OPN_ACPT,
CLS_ACPT CNF_ACPT,
/ clH OPN_RJCT,
CNF_RJCT /
sndCLS
2144
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In Figure 14-2, each arrow represents a state transition.
REQ_RJCT / sndCLS
IDLE
TOH / --,
,
R ) PN
CLS_ACPT / clH
AC
et O
TO
, s snd
PN
NF / (
dC T
/(
OPN_ACPT / sndCNF
sn ACP
sn
dO
_
PN
TOR1 / (sndOPN, setR)
PN
TOR1 / (sndOPN, setR)
O
,s
et
R)
OPN_RCV OPN_ACPT / sndCNF OPN_SNT
D
CNF_ACPT /
CNF_ACPT / clR (clR, setC)
OPN_ACPT /
sndCNF
OPN_ACPT / (clC, sndCNF)
ESTAB CNF_RCVD
T,
CLS_ACPT, CLS_ACPT,
etH JC
CL
OPN_RJCT, OPN_RJCT,
, s _R
S_
CNF_RJCT,
)
CNF_RJCT,
)
clC NF
etH
AC
TOR2, S, T, C TOR2,
PT
S, s
CNCL / CNCL /
, O CN , se
nd RJC
dCL
(sndCLS, clR, setH) (sndCLS, clR,
( sn
PN CL tH)
/ (s N _
setH)
CL
/ (sn
dC
_R /
CL OP
LS
JC
TOC
CN PT,
T,
CN
AC
F_
S_
RJ
CL
CT
,
HOLDING
OPN_ACPT,
CNF_ACPT,
OPN_RJCT,
CNF_RJCT
/ sndCLS
Figure 14-2—Finite state machine of the MPM protocol
The event/action representation is defined as the following. “E/A” string represents that the action A is taken
given that the event E occurs. “E1, E2/A” string represents that the action A is taken given that the event E1
or event E2 occurs. “E/(A1, A2)” string represents that the action A1 and A2 are taken at a time when event
E occurs.
Note that Table 14-2 and Figure 14-2 are used for illustration purposes. The protocol behavior is in the
following subclauses.
14.4.6 IDLE state
IDLE is a quiescent state the finite state machine enters prior to establishing a new mesh peering.
When ACTOPN event occurs, the mesh STA shall set the retryCounter to 0, and perform a sndOPN action.
The retryTimer shall be set and the finite state machine shall transition to OPN_SNT state.
2145
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When an OPN_ACPT event occurs, the mesh STA shall perform a sndOPN action and sndCNF action, and
set the retryTimer. The finite state machine shall transition to OPN_RCVD state.
When an REQ_RJCT event occurs, a Mesh Peering Close frame shall be sent to reject the mesh peering
open request. The reason code in the Mesh Peering Close frame shall be set to the reason code in
REQ_RJCT event. The finite state machine shall stay in the IDLE state.
All other events are ignored in this state.
14.4.7 OPN_SNT state
In the OPN_SNT state, the mesh STA waits for a Mesh Peering Confirm frame. In this state, the retryTimer
is set.
When a CNCL event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS using the reason
code specified by the CNCL event, and set the holdingTimer. The finite state machine shall transition to
HOLDING state.
When a CLS_ACPT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS using the
reason code specified by the CLS_ACPT event, and set the holdingTimer. The finite state machine shall
transition to HOLDING state.
When an OPN_ACPT event occurs, the mesh STA shall send perform a sndCNF action. The finite state
machine shall transition to OPN_RCVD state.
NOTE—The retryTimer is still in effect after the state transition.
When an OPN_RJCT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS using the
reason code specified by the OPN_RJCT event, and set the holdingTimer. The finite state machine shall
transition to HOLDING state.
When a CNF_ACPT event occurs, the mesh STA shall clear the retryTimer and shall set the confirmTimer
and the finite state machine shall transition to CNF_RCVD state.
When a CNF_RJCT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action using
the reason code specified by the CNF_RJCT event, and set the holdingTimer. The finite state machine shall
transition to HOLDING state.
When a TOR1 event occurs, the Mesh STA shall perform a sndOPN action and the retryCounter shall be
incremented. The retryTimer shall be and the finite state machine shall stay in the OPN_SNT state.
When a TOR2 event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH-
MAX-RETRIES. The holdingTimer shall be set, and the finite state machine shall transition to HOLDING
state.
All other events shall be ignored in this state.
14.4.8 CNF_RCVD state
In the CNF_RCVD state, the mesh STA has received a Mesh Peering Confirm frame and is waiting for a
Mesh Peering Open frame.
2146
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When a CNCL event occurs, the mesh STA shall clear the confirmTimer, perform a sndCLS action using the
reason code MESH-PEERING-CANCELED, and set the holdingTimer. The finite state machine shall
transition to HOLDING state.
When a CLS_ACPT event occurs, the mesh STA shall clear the confirmTimer, perform a sndCLS using the
reason code MESH-CLOSE-RCVD, and set the holdingTimer. The finite state machine shall transition to
HOLDING state.
When an OPN_ACPT event occurs, the mesh STA shall clear the confirmTimer and shall perform a sndCNF
action. The finite state machine shall transition to ESTAB state.
When an OPN_RJCT event occurs, the mesh STA shall clear the confirmTimer, perform a sndCLS action
using the reason code as specified by the OPN_RJCT event, and set the holdingTimer. The finite state
machine shall transition to HOLDING state.
When a CNF_RJCT event occurs, the mesh STA shall clear the confirmTimer, perform a sndCLS action
using the reason code as specified by the CNF_RJCT event, and set the holdingTimer The finite state
machine shall transition to HOLDING state.
When TOC event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH-
CONFIRM-TIMEOUT and set the holdingTimer. The finite state machine shall transition to HOLDING
state.
All other events shall be ignored in this state.
14.4.9 OPN_RCVD state
In the OPN_RCVD state, the mesh STA has received a Mesh Peering Open frame and sent a Mesh Peering
Open frame and the corresponding Mesh Peering Confirm frame. An incoming Mesh Peering Confirm is
expected.
When a CNCL event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action using the
reason code MESH-PEERING-CANCELED, and set the holdingTimer. The finite state machine shall
transition to HOLDING state.
When a CLS_ACPT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action, and
set the holdingTimer. The finite state machine shall transition to HOLDING state.
When an OPN_ACPT event occurs, the mesh STA shall perform a sndCNF action. The finite state machine
shall stay in the OPN_RCVD state.
When an OPN_RJCT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action using
the reason code as specified by the OPN_RJCT event, and set the holdingTimer. The finite state machine
shall transition to HOLDING state.
When a CNF_ACPT event occurs, the retryTimer shall be cleared. The finite state machine shall transition
to ESTAB state.
When a CNF_RJCT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action using
the reason code as specified by the CNF_RJCT event, and set the holdingTimer. The finite state machine
shall transition to HOLDING state.
When a TOR1 event occurs, the Mesh STA shall perform a sndOPN action, increment the retryCounter, and
set the retryTimer. The finite state machine shall stay in the OPN_RCVD state.
2147
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When a TOR2 event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH-
MAX-RETRIES. The holdingTimer shall be set, and the finite state machine shall transition to HOLDING
state.
All other events shall be ignored in this state.
14.4.10 ESTAB state
In the ESTAB state, mesh peering has been successfully established with the peer mesh STA.
When a CNCL event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH-
PEERING-CANCELED, and set the holdingTimer. The finite state machine shall transition to HOLDING
state.
When a CLS_ACPT event occurs, the mesh STA shall perform a sndCLS action using the reason code
MESH-CLOSE-RCVD, and set the holdingTimer. The finite state machine shall transition to HOLDING
state.
When an OPN_ACPT event occurs, the mesh STA shall respond by performing a sndCNF action. The finite
state machine shall stay in the ESTAB state.
All other events shall be ignored in this state.
14.4.11 HOLDING state
In HOLDING state, the mesh STA is closing the mesh peering. The holdingTimer has been set according to
the value of dot11MeshHoldingTimeout.
When a CLS_ACPT event occurs, the holdingTimer shall be cleared. The finite state machine shall
transition to IDLE state.
When any of the following four events occurs—OPN ACPT, CNF_ACPT, OPN_RJCT, CNF_RJCT—the
mesh STA shall send a Mesh Peering Close frame. The finite state machine shall stay in the HOLDING
state.
When a TOH event occurs, the finite state machine shall transition to IDLE state.
All other events are ignored in this state.
14.5 Authenticated mesh peering exchange (AMPE)
14.5.1 Overview
The authenticated mesh peering exchange (AMPE) establishes an authenticated mesh peering between the
mesh STAs, under the assumption that mesh PMKSA has already been established before the initiation of
the protocol. An authenticated mesh peering includes a mesh peering, corresponding mesh TKSA, and the
two mesh STAs mesh GTKSAs.
The AMPE is also used to establish an authenticated peering between two APs that support the AP PeerKey
protocol (as defined in 12.11) under the assumption that a PMK and PMKID have already been established
before the initiation of the AMPE exchange.
2148
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The AMPE uses mesh peering Management frames. Parameters are exchanged via the RSNE, the
Authenticated Mesh Peering Exchange element, and the MIC element.
The major functions provided by AMPE are security capabilities selection, key confirmation, and key
management.
— The security capabilities selection function (specified in 14.5.2) is performed by agreeing on the
security parameters used for the protocol instance.
— Key confirmation using the shared PMK is performed by verifying that the protection on the mesh
peering Management frame is correct.
— Key management (specified in 14.5.7) is performed by the derivation of the temporal key in the
mesh TKSA and the exchange of each mesh STA’s MGTK.
During the AMPE handshake, the mesh STAs generate nonces and transmit them via mesh peering
Management frames. The mesh STA shall generate a random value for its localNonce, as specified in 12.7.5.
The candidate peer mesh STA is expected to generate a random value for the peerNonce, which the mesh
STA receives from the candidate peer mesh STA in Confirm and Close Action frames.
Mesh peering Management frames used in the AMPE are protected using the deterministic authenticated
encryption mode of AES-SIV (IETF RFC 5297).
14.5.2 Security capabilities selection
14.5.2.1 Instance Pairwise Cipher Suite selection
Pairwise cipher suite selectors WEP-40, WEP-104, and TKIP shall not be used as the pairwise cipher suite
when dot11MeshSecurityActivated, dot11ProtectedTXOPNegotiationActivated, or
dot11ProtectedQLoadReportActivated is true.
If the pairwise cipher suite has not been selected, a STA shall attempt to reach the agreement on the pairwise
cipher suite using the following procedure in four steps:
a) The STA shall announce the list of pairwise cipher suites it supports using an ordered list in the
RSNE in the Mesh Peering Open frame. The first value in the list is the STA’s most preferred cipher
suite, and the last value the least preferred.
b) If the STA receives a Mesh Peering Open frame from the candidate peer STA, the STA shall make
its decision on the selected pairwise cipher suite based on the intersection of its own ordered list and
the received ordered list.
1) If the intersection is empty, the pairwise cipher suite selection fails and the STA generates the
failure reason code MESH-INVALID-SECURITY-CAPABILITY and then takes the
corresponding actions specified in 14.5.6.
2) If the intersection contains more than one value, the selected cipher suite shall be the entry in
the intersection list most preferred by the STA that has the largest MAC address in the
lexicographic ordering.
c) If the STA receives a Mesh Peering Confirm frame from the candidate peer STA before receiving a
Mesh Peering Open frame, the STA shall verify that it supports the pairwise cipher suite chosen by
the candidate peer STA. Otherwise, the selection fails and the STA shall generate the failure reason
code MESH-INVALID-SECURITY-CAPABILITY.
Furthermore, upon receiving a Mesh Peering Open frame, the STA shall verify that the accepted
selected pairwise cipher suite matches the pairwise cipher suite chosen in step b). If they do not
match, the selection fails and the STA shall generate the failure reason code MESH-INVALID-
SECURITY-CAPABILITY. Otherwise, the pairwise cipher suite selection succeeds, and the STA
shall proceed to step d).
2149
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
d) If the STA is generating a Mesh Peering Confirm frame, it shall set the Selected Pairwise Cipher
Suite to the selected pairwise cipher suite upon successful pairwise cipher suite selection.
14.5.2.2 Group cipher suite selection
Group cipher suite selectors WEP-40, WEP-104, and TKIP shall not be used as the group cipher suite when
dot11MeshSecurityActivated is true.
The mesh STA shall not use a different group cipher suite than the one used by the peer mesh STA or
candidate peer mesh STA in the same MBSS.
A mesh STA shall announce in a Mesh Peering Open frame the group cipher suite it uses for broadcast
protection. When it receives a Mesh Peering Open frame from a candidate peer, it shall verify that it supports
the candidate’s announced group cipher suite. In addition, if the mesh STA receives a Mesh Peering Confirm
frame, it shall verify that it supports the group cipher suite listed in that frame. If either selection fails, the
mesh STA shall issue the appropriate reply frame with the MESH-INVALID-SECURITY-CAPABILITY
reason code.
14.5.3 Construction and processing AES-SIV-protected mesh peering Management frames
AES-SIV performs deterministic authenticated encryption and takes additional data that is authenticated but
not encrypted (AAD). When encrypting and authenticating, AES-SIV takes a key, plaintext data to protect,
and multiple distinct components of AAD, to produce a synthetic initialization vector and a cipher text.
When verifying encrypted and authenticated data AES-SIV takes a key, a synthetic initialization vector,
cipher text data to decrypt and verify, and AAD, to produce either plaintext or the symbol “FAIL,” indicating
failure to decrypt and verify. Note that the AAD used in the encryption process shall be identical to the AAD
used in the decryption process and the synthetic initialization vector produced by the encryption process
shall be used in the decryption process.
When the mesh STA constructs a mesh peering Management frame, it shall follow the following procedure:
— The input key shall be the AEK
— The input plaintext shall be the Authenticated Mesh Peering element (see 9.6.16.2, 9.6.16.3,
9.6.16.4)
— The input AAD shall be three distinct components consisting of
1) The localMAC
2) The peerMAC
3) The contents of the mesh peering Management frame from the category (inclusive) to the MIC
element (exclusive)
— The output synthetic initialization vector shall be copied into the MIC field of the MIC element in
the mesh peering Management frame
— The output cipher text shall become the remainder of the mesh peering Management frame after the
MIC element
When the mesh STA verifies a mesh peering Management frame, it shall follow the following procedure:
— The input key shall be the AEK
— The input synthetic initialization vector shall be the MIC field of the MIC element in the mesh
peering Management frame
— The input cipher text shall be the part of the mesh peering Management frame following the MIC
element
— The input AAD shall be three distinct components consisting of
2150
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
1) The peerMAC
2) The localMAC
3) The contents of the mesh peering Management frame from the category (inclusive) to the MIC
element (exclusive)
— If AES-SIV returns the symbol “FAIL” processing of the frame shall be deemed a failure with a
behavior dependent on the type of mesh peering Management frame
— If AES-SIV returns plaintext it shall be treated as the components of the mesh peering Management
frame and processed accordingly
14.5.4 Distribution of group transient keys in an MBSS
The MGTK shall be a random or pseudorandom number. The mesh STA shall distribute the MGTK to the
peer mesh STA using the Mesh Peering Open frame during the AMPE. Upon successful completion of
AMPE, each mesh STA shall establish states for the peer mesh STA’s mesh GTKSA. The GTKData subfield
in the Authenticated Mesh Peering Exchange element shall contain the MGTK concatenated by the Key
RSC and the GTKExpirationTime (as specified in 9.4.2.118).
When dot11RSNAProtectedManagementFramesActivated is true, a mesh STA shall distribute the IGTK to
the peer mesh STA using the Mesh Peering Open frame during the AMPE. Upon successful completion of
AMPE, each mesh STA shall establish an IGTKSA (see 12.6.1.1.9) with the mesh peer.
14.5.5 Mesh peering Management frames for AMPE
14.5.5.1 General
The AMPE is inclusive of the mesh peering management (MPM) protocol. mesh peering Management
frames for AMPE have additional processing and construction requirements on top of those for mesh
peering Management frames.
The mesh peering Management frames shall be generated with additional information using the RSNE and
the Authenticated Mesh Peering Exchange element to support AMPE.
14.5.5.2 Mesh peering open for AMPE
14.5.5.2.1 Generating Mesh Peering Open frames for AMPE
In addition to contents for establishing a mesh peering as specified in 14.3.6.1, the Mesh Peering Open
frame, when used for the AMPE, shall contain the following:
— In the Mesh Peering Management element, the Mesh Peering Protocol Identifier shall be set to 1
“authenticated mesh peering exchange protocol.”
— In the Mesh Peering Management element, the Chosen PMK field shall be set to PMKID that
identifies the mesh PMKSA the mesh STA established with the candidate peer mesh STA.
— The RSNE shall be identical to the RSNE in the STA’s Beacon and Probe Response frames.
— In the Authenticated Mesh Peering Exchange element:
— The Selected Pairwise Cipher Suite field shall be set to the first cipher suite selector in the
Pairwise Cipher Suite List field in RSNE.
— The Local Nonce field shall be set to the localNonce value generated by the mesh STA for
identifying the current mesh peering instance.
— The Peer Nonce field shall be set to 0.
— If dot11MeshSecurityActivated is true, the GTKdata field shall be present and shall contain the
data for the mesh STA’s MGTK. The GTKdata field shall not be present when AMPE is being
2151
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
used as part of the AP PeerKey protocol (12.11.2). The components of the GTKdata field are
specified in 14.5.4.
The Mesh Peering Open frame shall be protected using AES-SIV as specified in 14.5.3.
14.5.5.2.2 Processing Mesh Peering Open frames for AMPE
On receiving a Mesh Peering Open frame, the mesh STA shall verify the received frame. If AES-SIV returns
the symbol “FAIL” the OPN_RJCT event shall be invoked to the corresponding AMPE finite state machine
and the reason code “MESH-INVALID-GTK” is generated. Otherwise, processing continues.
The received frame shall be rejected if the security capability selection fails (see 14.5.2). The OPN_RJCT
event shall be invoked to the corresponding AMPE finite state machine.
The peer mesh STA’s MGTK extracted from the Mesh Peering Open frame shall be added to the Receive
MGTK SA in which the peer’s MAC address equals the MGTK Source mesh STA MAC address.
If all operations succeed, the mesh STA shall proceed to process the Mesh Peering Open frame on basic
parameters as specified in 14.3.6.2.
14.5.5.3 Mesh peering confirm for AMPE
14.5.5.3.1 Generating Mesh Peering Confirm frames for AMPE
In addition to contents for establishing a mesh peering as specified in 14.3.7.1, the Mesh Peering Confirm
frame, when used with the AMPE, shall contain the following:
— In the Mesh Peering Management element, the Mesh Peering Protocol Identifier shall be set to 1
“authenticated mesh peering exchange protocol.”
— The RSNE shall be the same as sent in the Mesh Peering Open frame.
— In the Authenticated Mesh Peering Exchange element:
— The Selected Pairwise Cipher Suite field shall be set to the cipher suite selector that indicates
the successfully selected pairwise cipher suite (specified in 14.5.2.1).
— The Peer Nonce field shall be set to the nonce value chosen by the peer mesh STA as received
in the Local Nonce field in the Mesh Peering Open frame from the candidate peer mesh STA.
— The GTKdata field shall not be present.
— The IGTKdata field shall not be present.
— The rest of fields are set to the same values sent in the Mesh Peering Open frame.
The Mesh Peering Confirm frame shall be protected using AES-SIV as specified in 14.5.3.
14.5.5.3.2 Processing Mesh Peering Confirm frames for AMPE
On receiving a Mesh Peering Confirm frame, the mesh STA shall verify the received frame. The received
frame shall be discarded if AES-SIV returns the symbol “FAIL.”
If AES-SIV returns plaintext, the following operations shall be performed in order:
a) The Selected Pairwise Cipher Suite is checked. If the security capability selection has been done and
the received value from Chosen Pairwise Cipher Suite field is not the same as the agreed pairwise
cipher suite, the STA shall reject the received frame and the CNF_RJCT event is invoked to the cor-
responding AMPE finite state machine with the failure reason code MESH-INVALID-SECURITY-
CAPABILITY.
2152
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) If dot11MeshSecurityActivated is true the group cipher suite is checked. If the received group cipher
suite is not supported by the mesh STA, the mesh STA shall reject the received Mesh Peering Con-
firm frame and the CNF_RJCT event is invoked to the corresponding AMPE finite state machine
with the failure reason code MESH-INVALID-SECURITY-CAPABILITY.
If none of the cases is true, the mesh STA shall proceed to process the Mesh Peering Confirm Action frame
on basic parameters as specified in 14.3.7.2.
14.5.5.4 Mesh peering close for AMPE
14.5.5.4.1 Generating Mesh Peering Close frames for AMPE
In addition to contents for closing a mesh peering as specified in 14.3.8.1, the Mesh Peering Close frame,
when used for the AMPE, shall contain the following:
— In the Mesh Peering Management element, the Mesh Peering Protocol Identifier shall be set to 1
“authenticated mesh peering exchange protocol.”
— In the Mesh Peering Management element, the Chosen PMK field shall be set to the same value as
sent in the Mesh Peering Open frame.
— In the Authenticated Mesh Peering Exchange element:
— The Selected Pairwise Cipher Suite field shall be set to the same value as sent in the Mesh
Peering Open frame.
NOTE—If the reason for sending the Mesh Peering Close is the pairwise cipher suite selection failure,
the information in this field is used to inform the candidate peer mesh STA what was announced by the
mesh STA for the mesh peering instance.
— The Local Nonce field shall be set to the same value as sent in the Mesh Peering Open frame.
— The Peer Nonce field shall be set to the same value as received in the Local Nonce field of the
Authenticated Mesh Peering Exchange element of the incoming mesh peering Management
frame from the candidate peer mesh STA.
The Mesh Peering Close frame shall be protected using AES-SIV as specified in 14.5.3.
14.5.5.4.2 Processing Mesh Peering Close frames for AMPE
On receiving a Mesh Peering Close frame, the mesh STA shall verify the received frame. The received
frame shall be discarded if AES-SIV returns the symbol “FAIL.”
If AES-SIV returns plaintext, the mesh STA shall proceed to process the Mesh Peering Close frame on basic
parameters as specified in 14.3.8.2.
14.5.6 AMPE finite state machine
14.5.6.1 Overview
The finite state machine for AMPE supports all of the states, events, and actions defined for the finite state
machine for the MPM protocol. In addition, new events, actions, and state transitions are added to specify
the security functions for AMPE.
When a finite state machine is generated and activated for an AMPE instance, the localNonce shall be
generated and used together with a new localLinkID to identify the instance.
2153
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.5.6.2 Additional events and actions to MPM FSM
All events for rejecting or ignoring received Action frames shall report the corresponding reason code
related to AMPE functions as described in 14.5.5.
In addition, there is one new event as follows:
— TOR3—This event indicates that the retryTimer has expired, the dot11MeshMaxRetries has been
reached, the AMPE is enabled, but the mesh STA failed to confirm the selection of the shared mesh
PMKSA. When this event triggers, the protocol instance shall be closed, but no Mesh Peering Close
frame shall be sent.
The actions of sending mesh peering Management frames are updated as the following:
— sndOPN—Generate a Mesh Peering Open frame for the current AMPE protocol instance (as
specified in 14.5.5.2.1) and send it to the candidate peer mesh STA.
— sndCNF—Generate a Mesh Peering Confirm frame for the current AMPE protocol instance (as
specified in 14.5.5.3.1) and send it to the candidate peer mesh STA.
— sndClose—Generate a Mesh Peering Close frame for the current AMPE protocol instance (as
specified in 14.5.5.4.1) and send it to the candidate peer mesh STA.
14.5.6.3 State transitions
All state transitions specified in MPM FSM shall be used for AMPE finite state machine.
In OPN_SNT state, the following are additional state transitions and actions:
When TOR3 event occurs, the retryTimer shall be cleared and the holdingTimer shall be set. The finite
state machine shall transition to HOLDING state.
In OPN_RCVD state, the following are the additional actions:
When CNF_ACPT event occurs, in addition to the actions for MPM protocol, the mesh STA shall
signal the completion of key management by utilizing the MLME-SETKEYS.request primitive to
configure the agreed-upon mesh temporal pairwise key into the IEEE 802.11 MAC and by calling the
MLME-SETPROTECTION.request primitive to enable its use.
In CNF_RCVD state, the following are the additional actions:
When OPN_ACPT event occurs, in addition to the actions for MPM protocol, the mesh STA shall
signal the completion of key management by utilizing the MLME-SETKEYS.request primitive to
configure the agreed-upon mesh temporal pairwise key into the IEEE 802.11 MAC and received
MGTK and by calling the MLME-SETPROTECTION.request primitive to enable the usage.
Table 14-3 and Figure 14-3 specify the state transitions of the finite state machine for AMPE.
2154
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-3—AMPE finite state machine
To State
IDLE OPN_SNT CNF_RCVD OPN_RCVD ESTAB HOLDING
IDLE REQ_RJCT / ACTOPN / OPN_ACPT /
sndCLS (sndOPN, (sndOPN,
setR) sndCNF, setR)
OPN_SNT TOR1 / CNF_ACPT / OPN_ACPT / CLS_ACPT,
(sndOPN, (clR, setC) (sndCNF) OPN_RJCT,
setR) CNF_RJCT,
TOR2, CNCL
/ (sndCLS,
clR, setH)
TOR3 / (clR,
setH)
CNF_RCVD OPN_ACPT / CLS_ACPT,
(clC, sndCNF) OPN_RJCT,
CNF_RJCT,
CNCL /
(sndCLS, clC,
setH)
From State
TOC /
(sndCLS,
setH)
OPN_RCV TOR1 / CNF_ACPT / CLS_ACPT,
D (sndOPN, clR OPN_RJCT,
setR) CNF_RJCT,T
OPN_ACPT / OR2, CNCL /
sndCNF (sndCLS, clR,
setH)
ESTAB OPN_ACPT / CLS_ACPT,
sndCNF OPN_RJCT,
CNF_RJCT,
CNCL /
(sndCLS,
setH)
HOLDING TOH / —, OPN_ACPT,
CLS_ACPT / CNF_ACPT,
clH- OPN_RJCT,
CNF_RJCT /
sndCLS
2155
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
REQ_RJCT / sndCLS
IDLE
TOH / --,
,
R) PN
CLS_ACPT / clH
AC
et O
TO
, s snd
PN
NF / (
/(
dC T
OPN_ACPT / sndCNF
sn ACP
sn
dO
N_
PN
TOR1 / (sndOPN, setR) TOR1 / (sndOPN, setR)
OP
,
se
tR
)
OPN_RCV OPN_ACPT / sndCNF OPN_SNT
D
CNF_ACPT /
CNF_ACPT / clR (clR, setC)
OPN_ACPT /
sndCNF
OPN_ACPT / (clC, sndCNF)
ESTAB CNF_RCVD
CLS_ACPT,
OPN_RJCT,
CNF_RJCT,
T,
CLS_ACPT,
etH C
TOR2,
CL
OPN_RJCT,
, s _RJ
S_
CNF_RJCT, CNCL /
)
)
etH
clC CNF
AC
TOR2, (sndCLS, clR,
P
S, s
CNCL / setH)
T,
CL JCT,
OP CNC , setH
dCL
(sndCLS, clR, setH)
S,
( sn
/ (s N_R
TOR3 /
N_ L /
/ (sn
dC
(clR, setH)
RJ
nd
CL OP
LS
CT
TOC
CN Pt,
,C
AC
NF
)
S_
_R
CL
JC
T,
HOLDING
OPN_ACPT,
CNF_ACPT,
OPN_RJCT,
CNF_RJCT
/ sndCLS
Figure 14-3—Finite state machine of the AMPE protocol
14.5.7 Keys and key derivation algorithm for the authenticated mesh peering exchange
(AMPE)
To execute the AMPE and mesh group key handshake with a candidate peer STA, the local STA shall derive
an authenticated encryption key (AEK) and a mesh temporal key (MTK) using the PMK it shares with the
candidate peer STA.
The AEK is derived statically from the shared PMK. The MTK is derived from the shared PMK and
dynamic information provided by the STA and candidate peer STA.
The AEK is mutually derived by the local STA and the peer STA once a new PMK has been selected. The
AEK shall be derived from the PMK by
2156
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
AEK KDF-Hash-256(PMK, “AEK Derivation”, Selected AKM Suite ||
min(localMAC, peerMAC) || max(localMAC, peerMAC))
where
KDF-Hash-256 is the key derivation function defined in 12.7.1.7.2 using the hash algorithm identified by
the AKM suite selector (see Table 9-133)
Selected AKM Suite is a four octet string formed by concatenating the OUI or CID and suite type
The temporal key (MTK) shall be derived from the PMK by
MTK KDF-Hash-Length(PMK, “Temporal Key Derivation”, min(localNonce, peerNonce) ||
max(localNonce, peerNonce) || min(localLinkID, peerLinkID) || max(localLinkID, peerLinkID)
|| Selected AKM Suite || min(localMAC, peerMAC) || max(localMAC, peerMAC))
where
KDF-Hash-Length is the key derivation function defined in 12.7.1.7.2 using the hash algorithm identified
by the AKM suite selector (see Table 9-133)
Length is cipher-suite dependent and is defined by the TK_bits value in Table 12-4.
Selected AKM Suite is a four octet string formed by concatenating the OUI or CID and suite type
“min” and “max” operations for IEEE 802 addresses are with the address converted to a positive integer,
treating the first transmitted octet as the most significant octet of the integer as speci-
fied in 12.7.1.3
“min” and “max” operations for nonces are encoded as specified in 9.2.2
“min” and “max” operations for LinkIDs select the minimum and maximum, respectively, of the two
unsigned integers. In the KDF context, LinkIDs are encoded as 16-bit unsigned inte-
gers, represented using the bit ordering conventions of 9.2.2.
The MTK is used to protect communications between two peer STAs. The local STA and peer STA derive an
MTK per peering instance and may rekey the MTK using AMPE.
14.6 Mesh group key handshake
14.6.1 General
The mesh group key handshake may be used by either mesh STA, after a secure mesh peering has been
established, to update the MGTK that it uses to protect group addressed MPDUs that it transmits to its peer
mesh STAs.
The mesh STA may update its MGTK when a mesh peering is terminated.
To update the MGTK, the mesh STA shall execute the mesh group key handshake with each of its current
peer mesh STAs. The “MGTK source” is the mesh STA that is sending the MGTK to a peer mesh STA using
this protocol. A “MGTK recipient” is a mesh STA receiving the MGTK being sent by the MGTK Source.
The mesh group key handshake shall include the following two messages:
— Message 1: Mesh Group Key Inform frame
— Message 2: Mesh Group Key Acknowledge frame
Mesh Group Key Inform frame and Mesh Group Key Acknowledge frame are conventionally referred to as
mesh group key handshake frames.
2157
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The mesh STA shall do an AMPE handshake before a mesh group key handshake if both are required to be
done.
NOTE—It is impossible that the MGTK source initiates the mesh group key handshake before the AMPE completes
successfully.
14.6.2 Protection on mesh group key handshake frames
Mesh group key handshake frames used in mesh group key handshake are protected using the deterministic
authenticated encryption mode of AES-SIV (IETF-RFC 5297) when dot11MeshSecurityActivated is true.
When constructing protection on mesh group handshake frames, the following procedure shall be used:
— The key shall be the AEK from the current active security association with the peer mesh STA that
receives the mesh group key handshake frame.
— The input plaintext shall be the AMPE Authenticated Mesh Peering element (see 9.6.16.5 and
9.6.16.6).
— The plaintext shall be the Authenticated Mesh Peering Exchange element.
— AAD shall be three distinct components as follows:
1) The localMAC
2) The peerMAC
3) The contents of the mesh group key handshake frame from the category (inclusive) to the MIC
element (exclusive)
— The synthetic initialization vector produced by AES-SIV shall be copied into the MIC field of the
MIC element in the frame.
— The produced cipher text shall become the remainder of the mesh group key handshake frame after
the MIC element.
When verifying the protection on the mesh group handshake frames, the following procedure shall be used:
— The key shall be the AEK from the current active security association with the peer mesh STA that
receives the mesh group key handshake frame.
— AAD shall be three distinct components as follows:
1) The peerMAC
2) The localMAC
3) The contents of the mesh group key handshake frame from the category (inclusive) to the MIC
element (exclusive)
— The synthetic initialization vector shall be the MIC field of the MIC element in the frame.
— The cipher text shall be the content after the MIC element in the frame.
— If AES-SIV validation function takes above input.
— If the function returns the special symbol “FAIL,” the frame shall be discarded.
— If the plaintext is returned successfully, the produced plaintext shall be treated as the contents
after the MIC element in the frame.
14.6.3 Mesh Group Key Inform frame construction and processing
Mesh Group Key Inform frame shall be constructed as follows:
— The Authenticated Mesh Peering Exchange element shall be set as the following:
— The Selected Pairwise Cipher Suite field shall be set to four octets of zero.
— The Local Nonce field shall be set to the same value as sent in the Mesh Peering Open frame
that established the mesh peering instance.
2158
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The Peer Nonce field shall be set to the same value as received in the Local Nonce field of the
Authenticated Mesh Peering Exchange element of the incoming Mesh Peering Open frame that
established the peering instance.
— The Key Replay Counter field shall be set to the mesh STA’s local replay counter value,
incremented by 1, for the mesh peering. After setting this field, the local replay counter shall
also be incremented by 1.
— The GTKdata field shall be present and shall contain the data for the MGTK from MGTK
source. The components of the GTKdata are specified in 14.5.4.
— If management frame protection is used, the IGTKdata field shall be present and shall contain
the data for the IGTK from IGTK source. The components of the IGTKdata are specified in
9.4.2.118.
— The MIC element shall be set according to the protection mechanism in 14.6.2.
The construction of AES-SIV protection on Mesh Group Key Inform frame shall use the construction
procedure as in 14.6.2.
The MGTK source sends the Mesh Group Key Inform frame to the MGTK recipient.
On reception of Mesh Group Key Inform frame, the MGTK recipient shall use the verification procedure in
14.6.2 to validate the AES-SIV construction.
— If the validation recovers the plaintext successfully, the MGTK recipient shall proceed with the
following procedure:
— Verify that values in the Local Nonce field and the Peer Nonce field in the Authenticated Mesh
Peering Exchange element are the same as in the current valid mesh TKSA that the MGTK
recipient established with the sender of the Mesh Group Key Inform frame. If there is any
mismatch, the received Mesh Group Key Inform frame shall be discarded and no further action
shall be taken.
— Verify that the Key Replay Counter has not yet been seen before, i.e., its value is strictly larger
than that in any other mesh Group Key Inform frame received thus far during this security
association. If this verification fails, the received Mesh Group Key Inform frame shall be
discarded and no further action shall be taken.
— Use the MLME-SETKEYS.request primitive to configure the temporal MGTK into its IEEE
802.11 MAC.
— Respond by constructing and sending mesh group key handshake acknowledge to the MGTK
source and incrementing the replay counter.
NOTE—The MGTK source increments and uses a new Key Replay Counter field value on every Mesh Group
Key Inform frame, even retries, because the Mesh Group Key Acknowledge frame responding to an earlier
Mesh Group Key Inform frame might have been lost. If the MGTK source did not increment the replay counter,
the MGTK receiver discards the retry, and no responding Mesh Group Key Acknowledge frame will ever
arrive.
— If the AES-SIV validation returns a special symbol “FAIL,” the Mesh Group Key Inform frame
shall be discarded. No further action shall be taken.
14.6.4 Mesh Group Key Acknowledge frame construction and processing
Mesh Group Key Acknowledge frame shall be constructed as follows:
— The Authenticated Mesh Peering Exchange element shall be set as follows:
— The Selected Pairwise Cipher Suite field shall be set to four octets of zero.
— The Local Nonce field shall be set to the same value as sent in the Mesh Peering Open frame
that established the mesh peering instance.
2159
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The Peer Nonce field shall be set to the same value as received in the Local Nonce field of the
Authenticated Mesh Peering Exchange element of the incoming Mesh Peering Open frame that
established the peering instance.
— The Key Replay Counter shall be set to the same value as received in the Mesh Group Key
Inform frame.
— The GTKdata field shall not be present.
— The IGTKdata field shall not be present.
— The MIC element shall be set according to the protection mechanism in 14.6.2.
The construction of AES-SIV protection on Mesh Group Key Acknowledge frame shall use the construction
procedure as in 14.6.2.
The MGTK recipient sends the Mesh Group Key Acknowledge frame to the MGTK source.
On reception of Mesh Group Key Acknowledge frame, the MGTK source shall use the verification
procedure in 14.6.2 to validate the AES-SIV construction.
— If the validation recovers the plaintext successfully, the MGTK source shall set the content of the
Authenticated Mesh Peering Exchange element using the recovered plaintext and proceed with the
following procedure:
— Verify that values in the Local Nonce field and the Peer Nonce field in the Authenticated Mesh
Peering Exchange element are the same as in the current valid mesh TKSA that the MGTK
source established with the sender of the Mesh Group Key Acknowledge frame. If there is any
mismatch, the received Mesh Group Key Acknowledge frame shall be discarded and no
further action shall be taken.
— Verify that the Key Replay Counter value matches the one that it has used for the mesh group
key handshake. If this verification fails, the received Mesh Group Key Acknowledge frame
shall be discarded and the MGTK source may invoke a retry to send a new Mesh Group Key
Inform frame with a new Key Replay Counter value.
— If the validation returns a special symbol “FAIL,” the Mesh Group Key Acknowledge frame shall be
discarded and the MGTK source may invoke a retry to send a new Mesh Group Key Inform frame
with a new Key Replay Counter value.
14.6.5 Mesh group key implementation considerations
If the MGTK source does not receive a Mesh Group Key Acknowledge frame to its Mesh Group Key Inform
frames, it shall attempt dot11MeshConfigGroupUpdateCount additional transmissions of the Mesh Group
Key Inform frame. The retransmit timeout value shall be 100 ms for the first timeout, half the listen interval
for the second timeout, and the listen interval for subsequent timeouts. If there is no listen interval or the
listen interval is zero, then 100 ms shall be used for all timeout values. If it still has not received a response
after this, then the MGTK source shall tear down the mesh peering and mesh TKSA with this MGTK
recipient, by generating a CNCL event for the peering instance, and pass the event to the mesh peering
instance controller.
14.7 Mesh security
During the AMPE, the peers negotiate, and agree upon, a pairwise ciphersuite and a group cipher suite. They
also establish a mesh TKSA and mesh GTKSA to be used with the pairwise cipher suite and group cipher
suite, respectively.
When dot11MeshSecurityActivated is true, all individually addressed mesh Data frames and individually
addressed robust Management frames (see 12.2.8) shall be protected by the mesh TKSA, and all group
2160
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
addressed Data frames and group addressed Action frames that are indicated as “Group Addressed Privacy”
in Table 9-47 shall be protected by the mesh GTKSA.
When dot11RSNAProtectedManagementFramesActivated is true, group addressed robust Management
frames that are not protected by the mesh GTKSA shall be protected using BIP (see 11.13).
14.8 Mesh path selection and metric framework
14.8.1 General
The term mesh path selection is used to describe selection of multi-hop paths between mesh STAs at the link
layer. Mesh path selection creates forwarding information that is utilized for MSDU/MMPDU forwarding as
described in 10.35.
14.8.2 Extensible path selection framework
This standard allows for alternative and flexible implementations of path selection protocols and metrics.
A mesh STA may include multiple protocol implementations (that is, the default protocol, vendor-specific
protocols, etc.) as well as multiple metric implementations, but only one path selection protocol and only
one path selection metric shall be used by a mesh STA at a time.
As described in 14.2.3 and 14.2.7, mesh STAs use the Mesh Configuration element (9.4.2.98) to announce
the active path selection protocol and active path selection metric of the MBSS. This allows a neighbor mesh
STA to identify if it should become a member of the MBSS and how it should establish mesh peerings with
its members. This standard does not force an existing MBSS that is using a protocol other than the default
protocol to switch to the default protocol when a new mesh STA requests mesh peering establishment. While
it is possible, in principle, to implement such behavior, an algorithm to coordinate such reconfiguration is
beyond the scope of this standard.
Path selection protocol and path selection metric are identified by a unique identifier as defined in 9.4.2.98.2
and 9.4.2.98.3, respectively. Also, each path selection protocol and each path selection metric specifies the
following:
— Data type of metric values
— Length of the metric field
— Operator for aggregation of link metrics to a path metric; the symbol is used to identify an
arbitrary operator for aggregation
— Comparison operator for determining a better or worse path; how this is performed depends on the
actual comparison operator
— Initial value of the path metric (path selection metric only)
The standard defines a default path selection protocol (HWMP, 14.10) and a default path selection metric
(airtime link metric, 14.9). Both shall be implemented on all mesh STAs.
14.8.3 Link metric reporting
A mesh STA may submit a link metric report to or request a link metric report from its neighbor peer mesh
STA by transmitting a Mesh Link Metric Report frame. A mesh STA receiving a Mesh Link Metric Report
element with the Request subfield of the Flags field equal to 1 shall reply with a Mesh Link Metric
Report frame containing the link metric value for the corresponding link.
2161
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Upon reception of a Mesh Link Metric Report frame, the mesh STA may update its local link metric
information using the link metric information received. The procedure to update the local link
metric information with the link metric information received from a neighbor peer mesh STA is outside the
scope of the standard.
14.9 Airtime link metric
This subclause defines a default link metric that may be used by a path selection protocol to identify an
efficient radio-aware path. The extensibility framework allows this metric to be overridden by any path
selection metric as specified in the mesh profile.
Airtime reflects the amount of channel resources consumed by transmitting the frame over a particular link.
This measure is approximate and designed for ease of implementation and interoperability.
The airtime for each link is calculated as follows:
B 1
c a = O + -----t -------------
r 1 – ef
where
O and Bt are constants listed in Table 14-4
input parameter r is the data rate (in Mb/s)
input parameter ef is the frame error rate for the test frame size Bt
rate r represents the data rate at which the mesh STA would transmit a frame of standard
size Bt based on current conditions, and its estimation is dependent on local
implementation of rate adaptation
frame error rate ef is the probability that when a frame of standard size Bt is transmitted at the current
transmission bit rate r, the frame is corrupted due to transmission error; its estimation
is a local implementation choice. Frame failures due to exceeding Mesh TTL should
not be included in this estimate as they are not correlated with link performance.
The airtime link metric shall be encoded as an unsigned integer in units of 0.01 TU.
Table 14-4—Airtime cost constants
Parameter Recommended value Description
O Varies depending on Channel access overhead, which includes frame headers, training
PHY sequences, access protocol frames, etc.
Bt 8192 Number of bits in test frame
Table 14-5 gives the parameters of the airtime link metric for the extensible path selection framework.
An example of the airtime link metric is shown in S.5.
2162
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-5—Parameters of the airtime link metric for extensible path selection framework
Parameter Notes
Path Selection Metric ID See Table 9-218 in 9.4.2.98.3
Data type Unsigned integer, 0 metric value < 4 294 967 296
Length of metric field 4 octets
Operator for metric aggregation addition (+)
Comparison operator less than, equal to, greater than as used with integers
— metric a is better than metric b iff a < b
— metric a is equal to metric b iff a = b
— metric a is worse than metric b iff a > b
Initial value of path metric 0
14.10 Hybrid wireless mesh protocol (HWMP)
14.10.1 General
The hybrid wireless mesh protocol (HWMP) is a mesh path selection protocol that combines the flexibility
of on-demand path selection with proactive topology tree extensions. The combination of reactive and
proactive elements of HWMP enables efficient path selection in a wide variety of mesh networks (with or
without access to the infrastructure).
HWMP uses a common set of protocol elements, generation and processing rules inspired by Ad Hoc On-
Demand Distance Vector (AODV) protocol (IETF RFC 3561 [B38]) adapted for MAC address-based path
selection and link metric awareness. HWMP is completely specified herein and does not require reference to
AODV specifications or descriptions.
HWMP supports two modes of operation depending on the configuration. These modes provide different
levels of functionality as follows:
— On-demand mode: The functionality of this mode is always available, independent of whether a root
mesh STA is configured in the MBSS or not. It allows mesh STAs to communicate using peer-to-
peer paths.
— Proactive tree building mode: In this mode, additional proactive tree building functionality is added
to the on-demand mode. This can be performed by configuring a mesh STA as root mesh STA using
either the proactive PREQ mechanism or proactive RANN mechanism. The proactive PREQ
mechanism creates paths from the mesh STAs to the root, using only group addressed
communication. The RANN mechanism creates paths between the root and each mesh STA using
acknowledged communication.
These modes are not exclusive. On-demand and proactive modes are used concurrently, because the
proactive modes are extensions of the on-demand mode.
NOTE—One example of concurrent usage of on-demand and proactive mode is for two mesh STAs that are part of the
same mesh BSS (or STAs that are proxied by mesh STAs in the same MBSS) to begin communicating using the
proactively built tree but subsequently to perform an on-demand discovery for a direct path. This type of concurrent
usage of the proactive and on-demand modes allows communication to begin immediately (by forwarding all traffic to
the root, which knows all mesh STAs and addresses proxied by mesh STAs in the MBSS) while an on-demand
discovery finds a shorter path between two mesh STAs (or STAs that are proxied by mesh STAs in the same MBSS).
2163
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
All HWMP modes of operation utilize common processing rules and primitives. HWMP elements are the
PREQ (path request) element, PREP (path reply) element, PERR (path error) element, and RANN (root
announcement) element. The metric cost of the links determines which paths HWMP builds. In order to
propagate the metric information between mesh STAs, a Metric field is used in the PREQ, PREP, and RANN
elements.
Path selection in HWMP uses a sequence number mechanism to enable mesh STAs to distinguish current
path information from stale path information at all times in order to maintain loop-free connectivity. Each
mesh STA maintains its own HWMP SN, which is propagated to other mesh STAs in the HWMP elements.
Rules for maintaining HWMP SNs are given in 14.10.8.3.
14.10.2 Terminology
This subclause describes terminology for HWMP, especially for the process of path discovery. Terms such
as Path Originator or Path Target designate very specific entities within the path discovery process. They
stay with the same assigned entity for the whole path discovery process and other procedures related to this
path discovery. Figure 14-4 illustrates an example utilizing this terminology.
Forward path
Path Intermediate Intermediate Intermediate Path
originator 1 2 3 target
Reverse path
Figure 14-4—Illustration of definitions
NOTE—Both the path target and path originator are a path destination for the forward path and the reverse path
respectively.
The following terms are used within the context of a single PREQ element / PREP element pair, a so-called
HWMP path discovery:
— path originator: The path originator is the mesh STA that triggers the path discovery.
— path originator address: The MAC address of the path originator.
— path target: The path target is the entity to which the path originator attempts to establish a path.
NOTE—When an originator mesh STA initially attempts to establish a path to a target, it does not know
whether the target is a mesh STA in the mesh BSS or not. Only when the Originator receives a PREP element
does it learn if the target is a mesh STA in the mesh BSS or not. If the target is in the mesh BSS, it is referred to
as a target mesh STA. If the target is outside the mesh BSS, the term target proxy mesh gate refers to the mesh
gate proxying for the target.
— path target address: The MAC address of the path target.
— intermediate mesh STA: The intermediate mesh STA is the mesh STA that participates in path
selection and is neither path originator nor path target.
— intermediate mesh STA address: The MAC address of the intermediate mesh STA.
— forward path: The forward path is the mesh path to the path target, set up at the path originator and
intermediate mesh STAs.
— reverse path: The reverse path is the mesh path to the path originator, set up at the path target and
intermediate mesh STAs.
2164
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— HWMP sequence number (HWMP SN): Each mesh HWMP path selection element contains an
HWMP SN that allows recipients to distinguish newer from stale information. An HWMP SN is
specific to a mesh STA. See also 14.10.8.3.
— forwarding information: The forwarding information maintained by an originator mesh STA, an
intermediate mesh STA, or a target mesh STA that allows the mesh STA to perform its path
selection and forwarding functions.
The terminology used when discussing forwarding information is relative to the mesh STA
(reference mesh STA, given mesh STA or local mesh STA) and a particular mesh destination of the
path. The following terms are specific to a given instance of the forwarding information:
— destination mesh STA: The end station (mesh STA) of a (forward or reverse) path.
— destination mesh STA address: The MAC address of the destination mesh STA.
— destination HWMP SN: The HWMP SN of the destination mesh STA.
— next-hop mesh STA: The next-hop mesh STA is the next peer mesh STA on the mesh path to
the destination mesh STA.
— next-hop mesh STA address: The MAC address of the next-hop mesh STA.
— precursor mesh STA: A precursor mesh STA is a neighbor peer mesh STA on the mesh path
that identifies a given mesh STA as the next-hop mesh STA to the destination mesh STA.
— precursor mesh STA address: The MAC address of the precursor mesh STA.
— lifetime: The time during which forwarding information remains active (see 14.10.8.4)
— unreachable destination: A destination mesh STA is considered unreachable by a source mesh
STA or an intermediate mesh STA if the link to the next hop of the mesh path to this destination
mesh STA, as derived from its forwarding information, is no longer usable.
— element time to live (Element TTL): An integer number that is used to limit the number of hops an
HWMP element may be processed and propagated. Note that this Element TTL is different from the
Mesh TTL in the Mesh Control field (see 9.2.4.7.3).
— root mesh STA: A root mesh STA is configured to originate proactive PREQ elements or RANN
elements. It is the root of a path selection tree.
Table 14-6 and Table 14-7 show the roles of the various mesh STAs in the forward path and reverse path
generated as a result of the full PREQ element and PREP element processing as shown in Figure 14-4. Each
row in the table contains the roles of a forward/reverse path from the reference mesh STA’s perspective.
Table 14-6—Precursor and next hop examples (forward path)
Forward path (to Path Target)
Reference mesh Precursor mesh Next-hop mesh Destination mesh
STA STA STA STA
Path Originator N/A Intermediate 1 Path Target
Intermediate 2 Intermediate 1 Intermediate 3 Path Target
Path Target Intermediate 3 N/A Path Target
2165
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-7—Precursor and next hop examples (reverse path)
Reverse path (to Path Originator)
Reference mesh Precursor mesh Next-hop mesh Destination mesh
STA STA STA STA
Path Originator Intermediate 1 N/A Path Originator
Intermediate 2 Intermediate 3 Intermediate 1 Path Originator
Path Target N/A Intermediate 3 Path Originator
14.10.3 On-demand path selection mode
If a source mesh STA needs to find a path to a destination mesh STA using the on-demand path selection
mode, it broadcasts a PREQ element with the path target specified in the list of targets and the metric field
initialized to the initial value of the active path selection metric.
When a mesh STA receives a new PREQ element, it creates or updates its path information to the originator
mesh STA and propagates the PREQ element to its neighbor peer mesh STAs if the PREQ element contains
a greater HWMP SN, or the HWMP SN is the same as the current path and the PREQ element offers a better
metric than the current path. Each mesh STA may receive multiple copies of the same PREQ element that
originated at the originator mesh STA, each PREQ element traversing a unique path.
Whenever a mesh STA propagates a PREQ element, the metric field in the PREQ element is updated to
reflect the cumulative metric of the path to the originator mesh STA.
If the mesh STA that received a PREQ element is the target mesh STA, it sends a PREP element back to the
originator mesh STA after creating or updating a path to the originator mesh STA.
The PREQ element provides the TO (Target Only) subfield that allows path selection to take advantage of
existing paths to the target mesh STA by allowing an intermediate mesh STA to return a PREP element to
the originator mesh STA. If the TO (Target Only) subfield is 1, only the target mesh STA responds with a
PREP element. The effect of setting the TO (Target Only) subfield to 0 is the quick establishment of a path
using the PREP element generated by an intermediate mesh STA, allowing the forwarding of MSDUs with a
low path selection delay. In order to select (or validate) the best path during the path selection procedure, the
intermediate mesh STA that responded with a PREP element propagates the PREQ element with the TO
(Target Only) subfield set to 1. This prevents all other intermediate mesh STAs on the way to the target from
sending a PREP element.
Intermediate mesh STAs create a path to the target mesh STA on receiving the PREP element, and also
forward the PREP element toward the originator. When the originator receives the PREP element, it creates
a path to the target mesh STA. If the target mesh STA receives further PREQ elements with a better metric,
then the target updates its path to the originator with the new path and also sends a new PREP element to the
originator along the updated path. A bidirectional, best metric end-to-end path is established between the
originator and target mesh STA.
14.10.4 Proactive tree building mode
14.10.4.1 General
There are two mechanisms for proactively disseminating path selection information for reaching the root
mesh STA. The first method uses a proactive PREQ element and is intended to create paths between all
2166
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
mesh STAs and the root mesh STA in the network proactively. The second method uses a RANN element
and is intended to distribute path information for reaching the root mesh STA but there is no forwarding
information created.
A mesh STA configured as root mesh STA sends either proactive PREQ elements or proactive RANN
elements periodically.
14.10.4.2 Proactive PREQ mechanism
The PREQ tree building process begins with a proactive PREQ element sent by the root mesh STA, with the
Target Address set to all 1s and the TO subfield set to 1. The PREQ element contains the path metric (set to
the initial value of the active path selection metric by the root mesh STA) and an HWMP SN. The proactive
PREQ element is sent periodically by the root mesh STA, with increasing HWMP SNs.
A mesh STA receiving a proactive PREQ element creates or updates its forwarding information to the root
mesh STA, updates the metric and hop count of the PREQ element, records the metric and hop count to the
root mesh STA, and then transmits the updated PREQ element. Information about the presence of and
distance to available root mesh STA(s) is disseminated to all mesh STAs in the network.
Each mesh STA may receive multiple copies of a proactive PREQ element, each traversing a unique path
from the root mesh STA to the mesh STA. A mesh STA updates its current path to the root mesh STA if and
only if the PREQ element contains a greater HWMP SN, or the HWMP SN is the same as the current path
and the PREQ element offers a better metric than the current path to the root mesh STA. The processing of
the proactive PREQ element is the same as the processing of the PREQ element in the on-demand mode
described in 14.10.3.
If the proactive PREQ element is sent with the Proactive PREP subfield set to 0, the recipient mesh STA
may send a proactive PREP element. A proactive PREP element is necessary, for example, if the mesh STA
has data to send to the root mesh STA, thus requiring the establishment of a forward path from the root mesh
STA. During the time the forward path is required, the recipient mesh STA shall send a proactive PREP
element even if the Proactive PREP subfield is set to 0. Guidance on controlling the generation of proactive
PREQ elements in such a case is given in S.6.
If the PREQ element is sent with a Proactive PREP subfield set to 1, the recipient mesh STA shall send a
proactive PREP element. The proactive PREP element establishes the path from the root mesh STA to the
mesh STA.
14.10.4.3 Proactive RANN mechanism
The root mesh STA periodically propagates a RANN element into the network. The information contained
in the RANN element is used to disseminate path metrics to the root mesh STA, but reception of a RANN
element does not establish a path.
Upon reception of a RANN element, each mesh STA that has to create or refresh a path to the root mesh
STA sends an individually addressed frame containing a PREQ element to the root mesh STA via the mesh
STA from which it received the RANN element.
The root mesh STA sends a PREP element in response to each PREQ element. The individually addressed
frame containing a PREQ element creates the reverse path from the root mesh STA to the originator mesh
STA, while the PREP element creates the forward path from the mesh STA to the root mesh STA.
2167
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.10.5 Collocated STAs
HWMP terminology strictly refers to a STA whose address is used for destination mapping (i.e., the
originator address, the intermediate mesh STA address, or the target address). HWMP terminology does not
make any assumption about the address used for communication over the WM (i.e., the Transmitter Address
and the Receiver Address). For example, there is no requirement that the Path Originator or the Path Target
of an HWMP path are the same as the address used for transmitting the first and receiving the last
(respectively) HWMP Mesh Path Selection frame containing a PREQ element.
The corollary to this is that the first hop of a PREQ element may have a transmitter address that is not the
same as the Originator address in the PREQ element and that the first hop may have a transmitter address
that is not the same as the source address. In order to determine whether a transmission is a first hop or not,
mesh STAs should not compare the source and transmitter addresses. Instead, this determination can be
made by looking at the hop count field of the PREQ element (which is not used as an acceptance criterion).
14.10.6 Parameters for extensible path selection framework
Table 14-8 gives the parameters of HWMP for the extensible path selection framework (see 14.8.2).
Table 14-8—Parameters of HWMP for extensible path selection framework
Parameter Notes
Path Selection Protocol ID See Table 9-217 in 9.4.2.98.2
Data type of metric field As defined by active path selection metric
Length of metric field 4 octets
Operator for metric aggregation As defined by active path selection metric
Comparison operator As defined by active path selection metric
Initial value of path metric As defined by active path selection metric
14.10.7 Addressing of HWMP Mesh Path Selection frame
All HWMP elements are sent in an HWMP Mesh Path Selection frame (see 9.6.17.3). The RANN element
may also be sent in a Beacon frame. “Cases” refer to the different conditions that trigger the transmission of
an HWMP Mesh Path Selection frame. PREQ element cases are specified in 14.10.9.3. PREP element cases
are specified in 14.10.10.3. PERR element cases are specified in 14.10.11.3. RANN element cases are
specified in 14.10.12.3.
Note that the PREQ Addressing Mode subfield in the Flags field identifies the propagation mode of the
PREQ element; an Addressing Mode subfield equal to 0 indicates that the PREQ element is group
addressed, an Addressing Mode subfield equal to 1 indicates that the PREQ element is individually
addressed.
The addresses of the HWMP Mesh Path Selection frame shall be as follows:
— PREQ element group addressed—Addressing Mode subfield = 0 [Case A: Path Discovery (Original
transmission), Case B: Path Maintenance (Original transmission), Case C: Proactive PREQ element
(Original transmission), and Case E: PREQ element Propagation]:
— Address 1: Group address
— Address 2: Address of the mesh STA sending the PREQ element
— Address 3: Same as Address 2
2168
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— PREQ element individually addressed—Addressing Mode subfield = 1 [Case D: Root Path
Confirmation (Original transmission)]:
— Address 1: Address 2 of the frame containing the RANN element that triggered the PREQ
element
— Address 2: Address of the mesh STA sending the PREQ element
— Address 3: Same as Address 2
— PREQ element individually addressed—Addressing Mode subfield = 1 [Case E: PREQ element
Propagation]:
— Address 1: Next-hop MAC address to the mesh STA identified as the Target MAC address in
the PREQ element
— Address 2: Address of the mesh STA sending the PREQ element
— Address 3: Same as Address 2
— PREP element Case A: Original transmission, Case C: Intermediate reply, Case D: Proactive PREP
element in Proactive PREQ element mode:
— Address 1: Address of the next hop to the Originator Mesh STA Address in the PREQ element
that triggered the PREP element
— Address 2: Address of the mesh STA sending the PREP element
— Address 3: Same as Address 2
— PREP element Case B: PREP element Propagation:
— Address 1: Address of the next hop to the Originator Mesh STA Address in the PREP element
that triggered the PREP element
— Address 2: Address of the mesh STA sending the PREP element
— Address 3: Same as Address 2
— PERR element individually addressed [Case A: Original transmission—next hop is unusable]:
— Address 1: Address of each one of the precursors for which the active forwarding information
has been invalidated [see Case A, 14.10.11.3]
— Address 2: Address of the mesh STA sending the PERR element
— Address 3: Same as Address 2
— PERR element individually addressed [Case B: Original transmission—missing forwarding
information]:
— Address 1: Address of the transmitter of the frame that triggered the PERR element (see Case
B, 14.10.11.3)
— Address 2: Address of the mesh STA sending the PERR element
— Address 3: Same as Address 2
— PERR element individually addressed [Case C: Original transmission (proxy information is
unusable)]:
— Address 1: Address of each one of the neighbor peer mesh STAs
— Address 2: Address of the mesh STA sending the PERR element
— Address 3: Same as Address 2
— PERR element individually addressed [Case D: PERR element propagation]:
— Address 1: Address of each one of the precursors for which the active forwarding information
has been invalidated (see 14.10.11.4.3)
— Address 2: Address of the mesh STA sending the PERR element
— Address 3: Same as Address 2
— PERR element group addressed [all cases]:
— Address 1: Group address
— Address 2: Address of the mesh STA sending the PERR element
— Address 3: Same as Address 2
2169
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— RANN element all cases:
— Address 1: Group address
— Address 2: Address of the mesh STA sending the RANN element
— Address 3: Same as Address 2
Multiple HWMP elements may be sent in the same HWMP Mesh Path Selection frame if they share the
same intended Address 1.
14.10.8 General rules for processing HWMP elements
14.10.8.1 General
This subclause describes the rules for the processing of the following components of the HWMP elements:
— HWMP SN
— Element TTL
— Metric
14.10.8.2 HWMP propagation
The term propagate is used to describe the means by which elements are not transmitted “as is” across the
network but are processed and modified along the way. Many HWMP elements are intended to be processed
and propagated across an MBSS by mesh STAs. Each propagation is subject to certain rules or limitations as
explained in the following subclauses. Certain parameters in the HWMP elements are updated during the
propagation. See 14.10.9, 14.10.10, 14.10.11, and 14.10.12.
The originator of an HWMP element sets the initial value of the Element TTL. The mesh STA that receives
the HWMP element shall propagate it if the received value of Element TTL is greater than 1. Before
propagating the HWMP element, the mesh STA decrements the Element TTL value.
In general, the propagation of an HWMP element is not subject to a delay. Exception exists for the RANN
element as described in 14.10.12.
14.10.8.3 HWMP sequence numbering
HWMP uses sequence numbers to prevent the creation of path loops and to distinguish stale and fresh path
information. Each mesh STA keeps its own HWMP SN that it increments, uses in HWMP elements, and
processes according to the HWMP rules. HWMP SNs for other mesh STAs are maintained in the forwarding
information (see 14.10.8.4).
An HWMP SN is included in the PREQ, PREP, PERR, and RANN elements. The HWMP SN in the
forwarding information is updated whenever a mesh STA receives new (i.e., not stale) information about the
HWMP SN from a PREQ, PREP, or PERR element that may be received relative to that originator mesh
STA, target mesh STA, or destination mesh STA.
HWMP depends on each mesh STA in the network to own and maintain its HWMP SN to guarantee the
loop-freedom of all paths toward that mesh STA. A mesh STA increments its own HWMP SN in the
following two circumstances:
— If it is an originator mesh STA, it shall increment its own HWMP SN immediately before it starts a
path discovery. This prevents conflicts with previously established reverse paths toward the
originator mesh STA. However, it might be advantageous not to increment the HWMP SN too
frequently. An optional mechanism for achieving this is described in 14.10.8.6.
2170
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— If it is a target mesh STA, it shall update its own HWMP SN to maximum (current HWMP SN,
target HWMP SN in the PREQ element) + 1 immediately before it generates a PREP element in
response to a PREQ element. The target HWMP SN of the PREQ element is relevant when a link
was broken along the path and the stored sequence number was increased at an intermediate mesh
STA.
Comparing HWMP SNs is done using a circular modulo 232 comparison.
In general, when a mesh STA receives an element with an HWMP SN that is less than the HWMP SN in the
corresponding forwarding information, it discards the received element. If they are the same, the outcome
(element processed or not) depends on the type of the element and some additional conditions. These cases
are noted in the applicable element descriptions.
The only circumstance in which a mesh STA may change the HWMP SN of another mesh STA in the
forwarding information independently of the reception of an HWMP element originated by this mesh STA is
in response to a broken or no longer usable link to the next hop toward that destination mesh STA. The mesh
STA determines which destinations use a particular next hop by consulting its forwarding information. In
this case, for each destination that uses the next hop, the mesh STA increments the HWMP SN in the
forwarding information and marks the path as invalid (see also 14.10.11). Whenever any forwarding
information containing an HWMP SN greater than the recorded HWMP SN for an affected destination is
received by a mesh STA that has marked that recorded forwarding information as invalid, the mesh STA
shall update its forwarding information according to the information contained in the update.
14.10.8.4 Forwarding information
In addition to the parameters contained in the basic forwarding information as described in 10.35.2, the
forwarding information to a destination defined by HWMP also contains at least the destination HWMP SN,
the path metric, and the number of hops.
PREQ elements and PREP elements create or update the forwarding information of the mesh STAs that
process these elements as follows:
— The mesh STA may create or update its forwarding information to the transmitter of the element if
the path metric improves.
— The mesh STA shall create or update its forwarding information to the originator mesh STA, if it
received a PREQ element, and one of the following conditions is met:
— The Originator HWMP SN > HWMP SN in the forwarding information for this originator
mesh STA, or
— The Originator HWMP SN = HWMP SN in the forwarding information for this originator
mesh STA AND the updated path metric is better than the path metric in the forwarding
information.
— The mesh STA shall create or update its forwarding information to the target mesh STA, if it
received a PREP element, and one of the following conditions is met:
— The Target HWMP SN > HWMP SN in the forwarding information for this target mesh STA,
or
— The Target HWMP SN = HWMP SN in the forwarding information for this target mesh STA
AND the updated path metric is better than the path metric in the forwarding information.
Table 14-9 defines the values to be stored in the different fields of the forwarding information after a PREQ
element or PREP element has been received.
Changes to the forwarding information in other situations, for instance, when processing a PERR element
(see 14.10.11), are described in the corresponding clauses.
2171
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-9—Data for creation and update of forwarding information due to PREQ
element and PREP element
Received PREQ element Received PREP element
Field of
forwarding Forwarding Forwarding Forwarding
Forwarding
information information for information for information for
information for
transmitter of originator mesh transmitter of
target mesh STA
PREQ element STA PREP element
HWMP SN Invalid if created, no PREQ element Invalid if created, no PREP element
change if updated field change if updated field Target HWMP
Originator HWMP Sequence Number
Sequence Number
Next hop Transmitter address Transmitter address Transmitter address Transmitter address
of the Management of the Management of the Management of the Management
frame containing the frame containing the frame containing the frame containing the
PREQ element PREQ element PREP element PREP element
Path metric Accumulation of the Accumulation of the Accumulation of the Accumulation of the
initial value of the value of PREQ initial value of the value of PREP
path metric with the element field path metric with the element field
metric of the link to Metric with the metric of the link to Metric with the
the transmitter of metric of the link to the transmitter of metric of the link to
the PREQ element the transmitter of the PREP element the transmitter of
the PREQ element the PREP element
Number of hops 1 Value of PREQ 1 Value of PREP
element field Hop element field Hop
Count + 1 Count + 1
Precursor list No change No change except in No change See 14.10.10.4.3
case of an step d)
intermediate reply
[see 14.10.9.4.3
step f)]
Lifetime The longer one of The longer one of The longer one of The longer one of
the lifetime of the the lifetime of the the lifetime of the the lifetime of the
stored forwarding stored forwarding stored forwarding stored forwarding
information and the information and the information and the information and the
value of PREQ value of PREQ value of PREP value of PREP
element field element field element field element field
Lifetime Lifetime Lifetime Lifetime
14.10.8.5 Repeated attempts at path discovery
Repeated attempts by a mesh STA at path discovery toward a single target shall be limited to
dot11MeshHWMPmaxPREQretries. The minimum waiting time for the repeated attempt at path discovery
to a single target is 2 dot11MeshHWMPnetDiameterTraversalTime. For each attempt, the HWMP SN is
incremented and a new Path Discovery ID is chosen.
2172
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.10.8.6 Limiting the rate of HWMP SN increments
In order to improve path stability (and further reduce overhead), a mesh STA may use the same originator
HWMP SN for a certain time interval. In this case, the originator HWMP SN shall not be incremented until
at least dot11MeshHWMPnetDiameterTraversalTime has elapsed since the previous increment. This
mechanism prevents mesh STAs from changing the path frequently to the originator mesh STA every time
the originator mesh STA sends a burst of PREQ elements within a very short time. This element of the
protocol allows an originator mesh STA to immediately initiate on-demand path discovery to a new target
without affecting recently refreshed paths to the originator in other mesh STAs.
14.10.9 Path request (PREQ) mechanism
14.10.9.1 General
This subclause describes the function, generation, and processing of the PREQ element.
14.10.9.2 Function
The PREQ element, described in 9.4.2.113, is used for the following purposes:
— Discovering a path to one or more target mesh STAs
— Maintaining a path (optional)
— Building a proactive (reverse) path selection tree to the root mesh STA
— Confirming a path to a target mesh STA (optional)
14.10.9.3 Conditions for generating and sending a PREQ element
A mesh STA shall send a PREQ element in an HWMP Mesh Path Selection frame, as defined in 9.6.17.3, in
the following cases:
Case A: Path Discovery (Original Transmission)
All of the following conditions apply:
— The mesh STA needs to establish an on-demand path to one or more targets for which there is no
ongoing path discovery initiated by this mesh STA.
— The mesh STA has not sent a PREQ element for the target mesh STAs less than
dot11MeshHWMPpreqMinInterval TUs ago. If this is the case, the transmission of the PREQ
element has to be postponed until this condition becomes true.
— The mesh STA has not made more than (dot11MeshHWMPmaxPREQretries – 1) repeated attempts
at path discovery toward the target of the PREQ element.
The content of a PREQ element in Case A shall be as shown in Table 14-10.
2173
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-10—Contents of a PREQ element in Case A
Field Value
Element ID Value given in Table 9-77 for the PREQ element
Length 26 + N 11 (if Bit 6 (AE subfield) in the Flags field = 0)
32 + N 11 (if Bit 6 (AE subfield) in the Flags field = 1)
Flags Bit 0: 0 (gate announcement not applicable)
Bit 1: 0 (group addressed)
Bit 2: 0 (no proactive PREP element applicable)
Bit 3–5: Reserved
Bit 6: (1 – if external address present, 0 – otherwise)
Bit 7: Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for this element, e.g.,
dot11MeshHWMPnetDiameter.
Path Discovery ID New unique Path Discovery ID, for instance, previous Path
Discovery ID + 1
Originator Mesh STA Address MAC address of the path originator
Originator HWMP Sequence Previous Originator HWMP SN + 1. See 14.10.8.6
Number
Originator External Address Present only if Bit 6 in Flags field = 1. This value is set to the
external address, which is the source address of the MSDU (from
outside the mesh BSS) that triggered the path discovery at the
originator.
Lifetime The time for which mesh STAs receiving the PREQ element
consider the forwarding information to be valid, e.g.,
dot11MeshHWMPactivePathTimeout.
Metric Initial value of active path selection metric
Target Count N (N ≥ 1)
Per Target Per Target Bit 0 (TO): dot11MeshHWMPtargetOnly
Flags Bit 1: Reserved
Bit 2 (USN): 0 if forwarding information for Target Address with
valid HWMP SN exists, 1 otherwise
Bit 3–7: Reserved
Target Address MAC address of requested target
Target HWMP If Per Target Flags Bit 2 (USN) is 0, the latest HWMP SN stored by
Sequence the originator mesh STA for the target mesh STA from the
Number forwarding information (see 14.10.8.4). Otherwise, reserved.
2174
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case B: Path Maintenance (Original Transmission) (optional)
All of the following conditions apply:
— The mesh STA has a path to a given target mesh STA that is not a root mesh STA.
— The last PREQ element to this target was sent dot11MeshHWMPmaintenanceInterval TUs (or
more) ago.
The content of a PREQ element in Case B shall be as shown in Table 14-11.
Table 14-11—Contents of a PREQ element in Case B
Field Value
Element ID Value given in Table 9-77 for the PREQ element
Length 26 + N 11
Flags Bit 0: 0 (gate announcement not applicable)
Bit 1: 0 (group addressed)
Bit 2: 0 (no proactive PREP element applicable)
Bit 3–5: Reserved
Bit 6: 0 (no address extension)
Bit 7: Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for this element, e.g.,
dot11MeshHWMPnetDiameter
Path Discovery ID New unique Path Discovery ID, for instance, previous Path
Discovery ID + 1
Originator Mesh STA Address MAC address of the originator of the PREQ element
Originator HWMP Sequence Originator HWMP SN + 1. See 14.10.8.6
Number
Originator External Address Field not present
Lifetime The time for which mesh STAs receiving the PREQ element
consider the forwarding information to be valid, e.g.,
dot11MeshHWMPactivePathTimeout.
Metric Initial value of active path selection metric
Target Count N (N ≥ 1)
Per Target Per Target Bit 0 (TO): 1 (target only)
Flags Bit 1: Reserved
Bit 2 (USN): 0
Bit 3–7: Reserved
Target Address MAC Address of target mesh STA
Target HWMP The latest HWMP SN for this target known to the originator mesh
Sequence STA.
Number
2175
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case C: Proactive PREQ element (Original Transmission)
All of the following conditions apply:
— The root mesh STA is configured as root mesh STA using proactive PREQ elements
([dot11MeshHWMProotMode = proactivePREQnoPREP (2)] OR [dot11MeshHWMProotMode =
proactivePREQwithPREP (3)]).
— The root mesh STA sent its previous proactive PREQ element dot11MeshHWMProotInterval TUs
ago.
The contents of a PREQ element in Case C shall be as shown in Table 14-12.
Table 14-12—Contents of a PREQ element in Case C
Field Value
Element ID Value given in Table 9-77 for the PREQ element
Length 37
Flags Bit 0: 1 if dot11MeshGateAnnouncements is true (gate
announcement), 0 otherwise
Bit 1: 0 (group addressed)
Bit 2: 0 if dot11MeshHWMProotMode = proactivePREQnoPREP(2),
1 if dot11MeshHWMProotMode = proactivePREQwithPREP(3)
(proactive PREP)
Bit 3–5: Reserved
Bit 6: 0 (no address extension)
Bit 7: Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for this element, e.g.,
dot11MeshHWMPnetDiameter.
Path Discovery ID New unique Path Discovery ID, for instance, previous Path
Discovery ID + 1
Originator Mesh STA Address MAC address of the root mesh STA
Originator HWMP Sequence Originator HWMP SN + 1. See 14.10.8.6
Number
Originator External Address Field not present
Lifetime dot11MeshHWMPactivePathToRootTimeout
Metric Initial value of active path selection metric
Target Count 1
Per Target Per Target Bit 0 (TO): 1
Flags Bit 1: Reserved
Bit 2 (USN): 1
Bit 3–7: Reserved
Target Address Broadcast address
Target HWMP 0
Sequence
Number
2176
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case D: Root Path Confirmation (Original Transmission)
One of the following conditions applies:
— The mesh STA has received a RANN element and the metric (RANN metric metric to the
transmitter of the RANN element) is better than the metric to the root in the current forwarding
information.
— The mesh STA has a path to a root mesh STA and the last PREQ element to the root mesh STA was
sent dot11MeshHWMPconfirmationInterval TUs (or more) ago.
The content of a PREQ element in Case D shall be as shown in Table 14-13.
Table 14-13—Contents of a PREQ element in Case D
Field Value
Element ID Value given in Table 9-77 for the PREQ element
Length As required
Flags Bit 0: 0 (gate announcement not applicable)
Bit 1: 1 (individually addressed)
Bit 2: 0 (no proactive PREP element applicable)
Bit 3–5: Reserved
Bit 6: 0 (no address extension)
Bit 7: Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for this element, e.g.,
dot11MeshHWMPnetDiameter
Path Discovery ID Not used
Originator Mesh STA Address MAC address of the originator mesh STA
Originator HWMP Sequence Originator HWMP SN + 1. See 14.10.8.6
Number
Originator External Address Field not present
Lifetime The time for which mesh STAs receiving the PREQ element
consider the forwarding information to be valid, e.g.,
dot11MeshHWMPactivePathToRootTimeout.
Metric Initial value of active path selection metric
Target Count 1
Per Target Per Target Bit 0 (TO): 1
Flags Bit 1: Reserved
Bit 2 (USN): 0
Bit 3–7: Reserved
Target Address Root mesh STA MAC Address
Target HWMP The latest HWMP SN for this target known to the originator mesh
Sequence STA
Number
2177
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case E: PREQ element Propagation
Case E1 (target count = 1, no PREP element generation as intermediate mesh STA):
All of the following conditions apply:
— The mesh STA has received and accepted a PREQ element—see 14.10.9.4.2.
— dot11MeshForwarding is true.
— [The active forwarding information for the Originator Mesh STA was created or updated
according to the rules defined in 14.10.8.4] OR [{the Originator HWMP SN of the accepted
PREQ element = HWMP SN in the forwarding information for this originator mesh STA}
AND {the mesh STA has not previously received a PREQ element with the same Originator
Mesh STA Address and the same Path Discovery ID}].
— The Element TTL field is greater than 1—see 14.10.8.2.
— Target Count = 1.
— [The mesh STA is not the target of the PREQ element)]
OR
[the target of the PREQ element is the MAC broadcast address (all 1s)].
— The mesh STA is not the proxy of the target address.
— [The TO (Target Only) subfield of the target in the PREQ element is set (TO = 1)]
OR
[{the TO (Target Only) subfield of the target in the PREQ element is not set (TO = 0)} AND
{mesh STA has no active forwarding information for the requested target}].
The content of a PREQ element in Case E1 shall be as shown in Table 14-14.
Table 14-14—Contents of a PREQ element in Case E1
Field Value
Element ID Value given in Table 9-77 for the PREQ element
Length As received
Flags As received
Hop Count As received + 1
Element TTL As received – 1
Path Discovery ID As received
Originator Mesh STA Address As received
Originator HWMP Sequence As received
Number
Originator External Address As received. This field is present if Bit 6 of the Flags field (AE
subfield) is 1; it is not present otherwise.
Lifetime As received
Metric As received own metric toward transmitter of received PREQ
element
Target Count 1
2178
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-14—Contents of a PREQ element in Case E1 (continued)
Field Value
Per Target Per Target As received
Flags
Target MAC As received
Address
Target HWMP As received
Sequence
Number
Case E2 (target count = 1, PREP element generation as intermediate mesh STA):
All of the following conditions apply:
— The mesh STA has received and accepted a PREQ element—see 14.10.9.4.2.
— dot11MeshForwarding is true.
— [The active forwarding information for the Originator Mesh STA was created or updated
according to the rules defined in 14.10.8.4]
OR
[{the Originator HWMP SN of the accepted PREQ element = HWMP SN in the forwarding
information for this originator mesh STA} AND {the mesh STA has not previously received a
PREQ element with the same Originator Mesh STA Address and the same Path Discovery
ID}].
— The Element TTL field is greater than 1—see 14.10.8.2.
— Target Count = 1.
— The mesh STA is not the target of the PREQ element.
— The mesh STA is not the proxy of the target address.
— The mesh STA has active forwarding information for the requested target.
— [The TO (Target Only) subfield of the target in the PREQ element is not set (TO = 0)]
AND
[the mesh STA has active forwarding information for the requested target].
The contents of a PREQ element in Case E2 shall be as shown in Table 14-15.
Table 14-15—Contents of a PREQ element in Case E2
Field Value
Element ID Value given in Table 9-77 for the PREQ element
Length As received
Flags As received
Hop Count As received + 1
Element TTL As received – 1
Path Discovery ID As received
Originator Mesh STA Address As received
Originator HWMP Sequence As received
Number
2179
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-15—Contents of a PREQ element in Case E2 (continued)
Field Value
Originator External Address As received. This field is present if Bit 6 of the Flags field (AE
subfield) is 1; it is not present otherwise.
Lifetime As received
Metric As received own metric toward transmitter of received PREQ
element
Target Count 1
Per Target Per Target Bit 0 (TO): 1 (target only because mesh STA sent a PREP element)
Flags Bit 1: Reserved
Bit 2 (USN): As received
Bit 3–7: Reserved
Target MAC As received
Address
Target HWMP As received
Sequence
Number
Case E3 (target count > 1):
All of the following conditions apply:
— The mesh STA has received and accepted a PREQ element—see 14.10.9.4.2.
— dot11MeshForwarding is true.
— [The active forwarding information for the Originator Mesh STA was created or updated
according to the rules defined in 14.10.8.4
OR
[{the Originator HWMP SN of the accepted PREQ element = HWMP SN in the forwarding
information for this originator mesh STA} AND {the mesh STA has not previously received a
PREQ element with the same Originator Mesh STA Address and the same Path Discovery
ID}].
— The Element TTL field is greater than 1—see 14.10.8.2.
— Target Count > 1.
— There is at least one requested target that is neither the recipient MAC address nor an external
MAC address proxied by the recipient.
The contents of a PREQ element in Case E3 shall be as shown in Table 14-16.
Table 14-16—Contents of a PREQ element in Case E3
Field Value
Element ID Value given in Table 9-77 for the PREQ element
Length 26 + N 11
Flags As received
Hop Count As received + 1
Element TTL As received – 1
2180
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-16—Contents of a PREQ element in Case E3 (continued)
Field Value
Path Discovery ID As received
Originator Mesh STA Address As received
Originator HWMP Sequence As received
Number
Originator External Address As received. This field is present if Bit 6 of the Flags field (AE
subfield) is set to 1; it is not present otherwise.
Lifetime As received
Metric As received own metric toward the transmitter of the received
PREQ element
Target Count 1 target count received target count
received target count less the number of requested destinations, for
which the processing mesh STA
— is the target mesh STA or
— is the target proxy mesh gate
Per Target #A Per Target As received
Flags #A
Target MAC As received
Address #A
Target HWMP As received
Sequence
Number #A
Per Target #B Per Target Bit 0 (TO): 1 (target only because mesh STA sent PREP element)
Flags #B Bit 1: As received
Bit 2 (USN): As received
Bit 3–7: As received
Target MAC As received
Address #B
Target HWMP As received
Sequence
Number #B
For the per target fields (Per Target Flags, Target Address, Target HWMP Sequence Number) assume the
following:
— Target #A: If target A would have been the only requested target, it would generate a PREQ
element for propagation according to case E1.
— Target #B: If target B would have been the only requested target, it would generate a PREQ
element for propagation according to case E2.
2181
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.10.9.4 PREQ element processing
14.10.9.4.1 General
Received PREQ elements are subject to certain acceptance criteria. Processing and actions taken depend on
the contents of the PREQ element and the information available to the receiving mesh STA. See also
14.10.8.
14.10.9.4.2 Acceptance criteria
The PREQ element shall not be accepted (and shall not be processed as described in 14.10.9.4.3) if any of
the following is true:
— (The target address of the PREQ element is neither the recipient MAC address, broadcast address,
nor an external MAC address proxied by the recipient) AND (dot11MeshForwarding is false)
— (Bit 1 (Addressing Mode subfield) of the Flags field in the PREQ element is equal to 1) AND (there
is no valid forwarding information with the destination mesh STA address equal to the Target
Address of the PREQ element)
Otherwise, the PREQ element is accepted. See also 14.10.8.
14.10.9.4.3 Effect of receipt
A mesh STA receiving a PREQ element according to the acceptance criteria in 14.10.9.4.2 shall record the
Path Discovery ID and the Originator Mesh STA Address. The receiving mesh STA shall create or update
the active forwarding information it maintains for the originator mesh STA of the PREQ element according
to the rules defined in 14.10.8.4.
If the active forwarding information for the Originator Mesh STA was created or updated according to the
rules defined in 14.10.8.4 or if the Target HWMP SN of the PREQ element is the same as the HWMP SN in
the forwarding information for the Target Mesh STA and there has been no record of the Originator Mesh
STA and Path Discovery ID, the following applies:
a) If the mesh STA is the target of the PREQ element or is the proxy of the target MAC address it shall
initiate the transmission of a PREP element to the originator mesh STA (14.10.10.3 Case A). If the
PREQ element carries an external address (indicated by the AE subfield in the Flags field), the mesh
STA shall update its proxy information with the Originator External Address as external address, the
PREQ element Originator Mesh STA Address as the corresponding proxy, the HWMP Sequence
Number as proxy information sequence number, and for the proxy lifetime the longer one of the
value of the PREQ element Lifetime field and the proxy lifetime if the proxy information already
exists (see also 14.11.4.3).
b) If step a) was not applicable for the mesh STA and the AE subfield in the Flags field in the PREQ
element is 1, the mesh STA may update its proxy information with the Originator External Address
as external address, the PREQ element Originator Mesh STA Address as the corresponding proxy,
the HWMP Sequence Number as proxy information sequence number, and for the proxy lifetime the
longer one of the value of the PREQ element Lifetime field and the proxy lifetime if the proxy
information already exists (see also 14.11.4.3).
c) If the mesh STA has valid forwarding information to any of the requested targets and the TO (Target
Only) subfield for such a target is not set (TO = 0), it initiates the transmission of a PREP element
for each of these targets (see 14.10.10.3 Case C).
d) If the mesh STA is initiating a PREP element transmission on behalf of another target according to
step c) (intermediate reply), it shall process all of the following:
— Update the precursor list in its forwarding information for the target mesh STA with the next
hop from the forwarding information of the originator mesh STA.
2182
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Update the lifetime for this precursor that is the longer one of the lifetime of the forwarding
information of the target mesh STA.
— Update the lifetime of the precursor list entry in case it already exists.
— Update the precursor list in its forwarding information for the originator mesh STA with the
next hop toward the target mesh STA.
— Update the lifetime for this precursor that is the longer one of the lifetime of the forwarding
information of the originator mesh STA.
— Update the lifetime of the precursor list entry in case it already exists.
e) If the received PREQ element is a proactive PREQ element [target address is set to all 1s, TO
subfield is set (TO = 1)], the mesh STA generates a proactive PREP element to the root mesh STA
(see 14.10.10.3 Case D) depending on the setting of the Proactive PREP subfield. If the Proactive
PREP subfield is 1, a proactive PREP element is generated, if it is 0, a proactive PREP element is
generated only if a bidirectional path to the root mesh STA is required (see S.6).
f) If there are individually addressed targets in the PREQ element that have not been processed in step
a) or that have been processed in step c) or in step e), the receiving mesh STA shall propagate the
PREQ element as defined in 14.10.9.3 Case E.
14.10.10 Path reply (PREP) mechanism
14.10.10.1 General
Subclause 14.10.10 describes the function, generation, and processing of the PREP element.
14.10.10.2 Function
The PREP element is transmitted in individually addressed frames and is described in 9.4.2.114. The
purpose of the PREP element is as follows:
— To establish the forward path to a target mesh STA or target proxy mesh gate.
— To confirm the reverse path to the originator.
14.10.10.3 Conditions for generating and sending a PREP element
A mesh STA sends out a PREP element in an HWMP Mesh Path Selection frame, as defined in 9.6.17.3, in
the following cases:
Case A: Path Discovery (Original Transmission)
A PREP element is transmitted if the mesh STA has received and accepted a PREQ element (see
14.10.9.4.2) fulfilling any one of the following conditions:
— The Target Address of the PREQ element is the same as MAC address of the receiving mesh STA.
— The Target Address of the PREQ element is an external address currently proxied by the mesh STA.
The content of the generated PREP element in Case A shall be as shown in Table 14-17.
2183
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-17—Contents of a PREP element in Case A
Field Value
Element ID Value given in Table 9-77 for the PREP element
Length As required
Flags Bit 0–5: Reserved
Bit 6 (AE): (1 = external address present, 0 = otherwise)
Bit 7: Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for this element
Target Mesh STA Address MAC address of the target mesh STA or target proxy mesh gate
Target HWMP Sequence Number HWMP SN of the target mesh STA or target proxy mesh gate after it
has been updated according to 14.10.8.3
Target External Address External target address on behalf of which the PREP element is sent.
Present only if Bit 6 (AE subfield) in the Flags field is 1
Lifetime As per the PREQ element that triggered the transmission of this
PREP element
Metric Initial value of active path selection metric
Originator Mesh STA Address MAC address of the originator mesh STA
Originator HWMP Sequence HWMP SN of the originator mesh STA
Number
Case B: PREP element propagation
A PREP element is propagated if all of the following conditions apply:
— The mesh STA has received and accepted the PREP element—see 14.10.10.4.2.
— The mesh STA is not the path originator.
The contents of a PREP element in Case B shall be as shown in Table 14-18.
Table 14-18—Contents of a PREP element in Case B
Field Value
Element ID Value given in Table 9-77 for the PREP element
Length As received
Flags As received
Hop Count As received + 1
Element TTL As received – 1
Target Mesh STA Address As received
Target HWMP Sequence Number As received
Target External Address As received
2184
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-18—Contents of a PREP element in Case B (continued)
Field Value
Lifetime As received
Metric As received own metric toward the transmitting mesh STA
Originator Mesh STA Address As received
Originator HWMP Sequence As received
Number
Case C: Intermediate reply (Original Transmission)
A PREP element is transmitted if the mesh STA has received a PREQ element fulfilling all of the following
conditions:
— The TO (Target Only) subfield in the corresponding Per Target Flags field in the PREQ element is
not set (TO = 0)
— The receiving mesh STA has active forwarding information with
a)A destination that is the same as the Target Address of the PREQ element
b)An HWMP SN that is greater than or equal to the Target HWMP SN of the PREQ element
c)A nonzero lifetime
The content of the generated PREP element in Case C shall be as shown in Table 14-19.
Table 14-19—Contents of a PREP element in Case C
Field Value
Element ID Value given in Table 9-77 for the PREP element
Length 31
Flags Bit 0–5: Reserved
Bit 6 (AE): 0
Bit 7: Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for this element
Target Mesh STA Address Target MAC address from the PREQ element
Target HWMP Sequence Number HWMP SN of the stored forwarding information of the Target of the
PREQ element
Target External Address Not present
Lifetime As per the PREQ element that triggered the transmission of this
PREP element
Metric Value of path metric taken from the active forwarding information
for the target address of the PREQ element
Originator Mesh STA Address MAC address of the originator mesh STA
Originator HWMP Sequence Number HWMP SN of the originator mesh STA
2185
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case D: Proactive PREP element in Proactive PREQ element mode (Original Transmission)
One of the following conditions applies:
— The mesh STA has received a proactive PREQ element with the Proactive PREP subfield set to 0
AND the mesh STA needs to establish or update a bidirectional path to the root mesh STA.
— The mesh STA has received a proactive PREQ element with the Proactive PREP subfield set to 1.
Note that a proactive PREQ element is a PREQ element with a Target Address set to all 1s and its TO
subfield set (TO=1).
The content of the generated PREP element in Case D shall be as shown in Table 14-20.
Table 14-20—Contents of a PREP element in Case D
Field Value
Element ID Value given in Table 9-77 for the PREP element
Length 31
Flags Bit 0–5: Reserved
Bit 6 (AE): 0
Bit 7: Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for this element
Target Mesh STA Address MAC address of the mesh STA
Target HWMP Sequence Number HWMP SN of the mesh STA
Target External Address Not present
Lifetime Lifetime of the PREQ element that triggered the transmission of this
PREP element
Metric Initial value of active path selection metric
Originator Mesh STA Address MAC address of the root mesh STA (originator mesh STA of the PREQ
element)
Originator HWMP Sequence HWMP SN of the root mesh STA (originator HWMP SN of the PREQ
Number element)
14.10.10.4 PREP element processing
14.10.10.4.1 General
Received PREP elements are subject to certain acceptance criteria. Processing and actions taken depend on
the contents of the PREP element and the information available to the receiving mesh STA.
14.10.10.4.2 Acceptance criteria
The PREP element shall not be accepted (and shall not be processed as described in 14.10.10.4.3) if any of
the following is true:
— (The Originator Mesh STA Address of the PREP element is neither the recipient MAC address nor
an external MAC address proxied by the recipient) AND (dot11MeshForwarding is false).
2186
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Otherwise, the PREP element shall be accepted.
14.10.10.4.3 Effect of receipt
A mesh STA receiving a PREP element according to the acceptance criteria in 14.10.10.4.2 shall create or
update the active forwarding information it maintains for the target mesh STA of the PREP element
(according to the rules defined in 14.10.8.4). If the conditions for creating or updating the forwarding
information have not been met in those rules, no further steps are applied to the PREP element.
If the active forwarding information was created or updated according to the rules defined in 14.10.8.4, the
following apply:
a) If the receiving mesh STA is not the final destination of the PREP element (originator mesh STA)
and the field Element TTL > 1, the PREP element is propagated as defined in 14.10.10.3 Case B.
b) If the receiving mesh STA is the final destination of the PREP element (originator mesh STA) and
its AE subfield in the Flags field is 1, the mesh STA shall store the Target External Address, the
Target Mesh STA Address, and the HWMP Sequence Number as proxy information sequence
number in its proxy information. The proxy lifetime is the longer one of the value of the PREP
element Lifetime field and the proxy lifetime if the proxy information already exists (see also
14.11.4.3).
c) If the receiving mesh STA is not the final destination of the PREP element (originator mesh STA)
and its AE subfield in the Flags field is 1, the mesh STA may store the Target External Address, the
Target Mesh STA Address, and the HWMP Sequence Number as proxy information sequence
number in its proxy information. The proxy lifetime is the longer one of the value of the PREP
element Lifetime field and the proxy lifetime if the proxy information already exists (see also
14.11.4.3).
d) If the mesh STA propagates the PREP element, the precursor list for the Target Mesh STA Address
is updated by adding the next-hop mesh STA to which the PREP element is propagated. In addition,
at the mesh STA the precursor list for the originator mesh STA address is updated by adding the
next-hop mesh STA toward the Target Address. The lifetimes of these entries in the precursor lists
are the values of the lifetimes of the corresponding forwarding information.
14.10.11 Path error (PERR) mechanism
14.10.11.1 General
Subclause 14.10.11 describes the function, generation, and processing of the PERR element.
14.10.11.2 Function
The PERR element is used for announcing one or more unreachable destination(s). The announcement is
sent to all traffic sources that have a known active path to the destination(s). The active forwarding
information associated with the unreachable destination(s) should no longer be used for forwarding.
A PERR element may be either group addressed (if there are many precursors), individually addressed (if
there is only one precursor), or individually addressed iteratively to all precursors (see 14.10.7, item “PERR
element individually addressed”). The PERR element is processed as a single element when iteratively
individually addressed to several precursors. The PERR element contains the destinations that are
unreachable.
A PERR element is propagated by mesh STAs receiving a PERR element if certain conditions are met.
A mesh STA generating or receiving a PERR element may attempt to establish paths to unreachable
destinations using any of the available HWMP mechanisms.
2187
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.10.11.3 Conditions for generating and sending a PERR element
A mesh STA shall send out a PERR element in an HWMP Mesh Path Selection frame, as defined in
9.6.17.3, in the following cases:
Case A: Original transmission (next hop is unusable)
The mesh STA has not sent a PERR element less than dot11MeshHWMPperrMinInterval TUs ago, and the
following condition applies:
— The mesh STA determines that the link to the next hop of an active path in its forwarding
information is no longer usable.
NOTE—The detection might be triggered by the fact that a mesh STA is unable to forward an MSDU/MMPDU
to a next-hop mesh STA.
The HWMP SN in the forwarding information of all unreachable destinations announced in this PERR
element is incremented by 1. The forwarding information for each unreachable destination announced in
this PERR element is invalidated.
The contents of a PERR element in Case A shall be as shown in Table 14-21.
Table 14-21—Contents of a PERR element in Case A
Field Value
Element ID Value given in Table 9-77 for the PERR element
Length 2+N 13
Element TTL The maximum number of hops the element is propagated before
being discarded.
Number of Destinations Number of announced unreachable destinations in the PERR
element.
Flags #1 Bit 0–5: Reserved
Bit 6 (AE): 0
Bit 7: Reserved
Destination Address #1 MAC address of unreachable destination #1.
HWMP Sequence Number #1 HWMP SN for Destination Address #1 from the forwarding
information after above increment.
Reason Code #1 “MESH-PATH-ERROR-DESTINATION-UNREACHABLE”
(see 9.4.1.7).
... ...
2188
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case B: Original transmission (missing forwarding information)
The mesh STA has not sent a PERR element less than dot11MeshHWMPperrMinInterval TUs ago, and one
of the following conditions applies:
— The mesh STA receives an individually addressed frame with a destination address not matching its
own MAC address for which it has no forwarding information.
— The mesh STA receives an individually addressed frame with a destination address not matching its
own MAC address and dot11MeshForwarding is false.
The contents of a PERR element in Case B shall be as shown in Table 14-22.
Table 14-22—Contents of a PERR element in Case B
Field Value
Element ID Value given in Table 9-77 for the PERR element.
Length 2+N 13
Element TTL The maximum number of hops the element is propagated before
being discarded.
Number of Destinations Number of announced destinations with missing forwarding
information in the PERR element.
Flags #1 Bit 0–5: Reserved
Bit 6 (AE): 0
Bit 7: Reserved
Destination Address #1 MAC address of destination with missing forwarding information
#1. This is Address 3 of the received individually addressed frame.
HWMP Sequence Number #1 Reserved
Reason Code #1 “MESH-PATH-ERROR-NO-FORWARDING-INFORMATION”
(see 9.4.1.7).
... ...
2189
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case C: Original transmission (proxy information is unusable)
The mesh STA has not sent a PERR element less than dot11MeshHWMPperrMinInterval TUs ago, and the
following condition applies:
— The mesh STA is a proxy mesh gate and determines that an active proxy information where the
mesh STA is the proxy mesh gate is no longer usable.
The contents of a PERR element in Case C shall be as shown in Table 14-23.
Table 14-23—Contents of a PERR element in Case C
Field Value
Element ID Value given in Table 9-77 for the PERR element.
Length 2+N 19
Element TTL The maximum number of hops the element is propagated before
being discarded.
Number of Destinations Number of announced unreachable external destinations in the
PERR element.
Flags #1 Bit 0–5: Reserved
Bit 6 (AE): 1
Bit 7: Reserved
Destination Address #1 MAC address of proxy mesh gate #1 with unusable active proxy
information.
HWMP Sequence Number #1 Last used HWMP SN for Destination Address #1.
Destination External Address #1 External MAC address of the active proxy information that is not
longer usable and for which the mesh STA is the proxy mesh gate.
Reason Code #1 “MESH-PATH-ERROR-NO-PROXY-INFORMATION”
(see 9.4.1.7.
... ...
2190
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case D: PERR element propagation
The mesh STA has not sent a PERR element less than dot11MeshHWMPperrMinInterval TUs ago, and all
of the following conditions apply:
— The mesh STA received a PERR element from a neighbor peer mesh STA.
— A destination in the PERR element is the same as one of the destinations in the active forwarding
information of the mesh STA where the next hop is the transmitter of the received PERR element,
and the forwarding information or the proxy information has been invalidated according to
conditions in 14.10.11.4.3 case b), case c), or case d).
— dot11MeshForwarding is true.
— The Element TTL field in the received PERR element is greater than 1.
The contents of a PERR element in Case D shall be as shown in Table 14-24.
Table 14-24—Contents of a PERR element in Case D
Field Value
Element ID Value given in Table 9-77 for the PERR element
Length if AE subfield = 0: 2 + N 13
if AE subfield = 1: 2 + N 19
Element TTL Element TTL in received PERR element – 1
Number of Destinations 1 number of destinations in the PERR element received value
Received number of destinations less the number of received destinations
for which the transmitter of the PERR element is not the next hop
Flags #1 As received
Destination Address #1 MAC address of unreachable destination #1, as received
HWMP Sequence Number #1 If Reason Code #1 = “MESH-PATH-ERROR-NO-FORWARDING-
INFORMATION” and received value = 0, then HWMP SN for
Destination Address #1 from the forwarding information after the
increment of 14.10.10.4.3 step b).
Otherwise, as received.
Destination External Address #1 As received
This field is present if Bit 6 (AE subfield) of the Flags field #1 is 1; it is
not present otherwise.
Reason Code #1 As received
... ...
2191
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.10.11.4 PERR element processing
14.10.11.4.1 General
Received PERR elements are subject to certain acceptance criteria. Processing and actions taken depend on
the contents of the PERR element and the information available to the receiving mesh STA. See also
14.10.8.
14.10.11.4.2 Acceptance criteria
The PERR element shall be accepted (and shall be processed as described in 14.10.11.4.3) if the following
applies:
— The mesh STA that receives the PERR element has forwarding information stored where
— The destination is contained in the list of unreachable destinations of the PERR element and
— The next hop is the transmitter of the received PERR element
Otherwise, the PERR element shall be discarded.
14.10.11.4.3 Effect of receipt
The following applies only to a PERR element that was accepted according to the acceptance criteria in
14.10.11.4.2:
a) The mesh STA creates a list of unreachable destinations consisting of those destinations from the
received PERR element for which the next hop in the local active forwarding information is the
transmitter of the PERR element. Step b) through step e) are applied to the destinations in this list.
b) If the Reason Code is “MESH-PATH-ERROR-NO-FORWARDING-INFORMATION” and the
HWMP Sequence Number is 0, the receiving mesh STA increments the HWMP SN in the
forwarding information of the listed unreachable destination by 1 and invalidates the forwarding
information.
c) If the Reason Code is “MESH-PATH-ERROR-NO-FORWARDING-INFORMATION” and the
HWMP Sequence Number is not 0 or the Reason Code is “MESH-PATH-ERROR-
DESTINATION-UNREACHABLE” and the received HWMP SN for a listed unreachable
destination is higher than the current HWMP SN in the forwarding information for that destination,
the receiving mesh STA shall consider that destination unreachable and shall set the HWMP SN in
the forwarding information to the HWMP SN received in the PERR element and shall invalidate the
forwarding information associated with this unreachable destination.
d) If the Reason Code is “MESH-PATH-ERROR-NO-PROXY-INFORMATION,” the receiving mesh
STA shall consider the corresponding Destination External Address unreachable and shall invalidate
the proxy information associated with this unreachable external destination (proxy mesh gate is the
Destination Address of the PERR element, external MAC address is the Destination External
Address of the PERR element, proxy information sequence number is the HWMP Sequence
Number).
e) A PERR element is propagated according to the conditions defined in 14.10.11.3 Case D “PERR
element propagation.”
14.10.12 Root announcement (RANN) mechanism
14.10.12.1 General
Subclause 14.10.12 describes the function, generation, and processing of the RANN element.
2192
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.10.12.2 Function
The RANN element, described in 9.4.2.112, is used for announcing the presence of a mesh STA configured
as root mesh STA using the proactive RANN mechanism. RANN elements are sent out periodically by the
root mesh STA.
The RANN element propagates path metric information across the network so that each mesh STA can
select a best metric path to the announced root mesh STA. This mechanism allows bidirectional trees to be
built, using a robust procedure based on individually addressed frames initiated by the mesh STAs. This
procedure makes the root mesh STA aware of all mesh STAs.
A receiving mesh STA shall propagate the RANN element as described in 14.10.12.3 Case B.
14.10.12.3 Conditions for generating and sending a RANN element
A mesh STA sends out a RANN element in an HWMP Mesh Path Selection frame, as defined in 9.6.17.3, in
the following cases:
Case A: Original transmission
All of the following conditions apply:
— The mesh STA is configured as a root mesh STA using the proactive RANN mechanism
[dot11MeshHWMProotMode = rann (4)].
— The root mesh STA sent its previous RANN element dot11MeshHWMPrannInterval TUs ago.
The contents of a RANN element in Case A shall be as shown in Table 14-25.
Table 14-25—Contents of a RANN element in Case A
Field Value
Element ID Value given in Table 9-77 for the RANN element
Length 21
Flags Bit 0: set to 1 if dot11MeshGateAnnouncements is true, set to 0
otherwise.
Bit 1–7: Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for this element
Root Mesh STA Address MAC address of the root mesh STA
HWMP Sequence Number Last used HWMP SN of the root mesh STA + 1
Interval dot11MeshHWMPrannInterval
Metric Initial value of active path selection metric
2193
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Case B: Propagation
All of the following conditions apply:
— The mesh STA has valid forwarding information to a root mesh STA using the proactive RANN
mechanism [dot11MeshHWMProotMode = rann (4)].
— The mesh STA sent its previous RANN element dot11MeshHWMPrannInterval TUs ago.
— dot11MeshForwarding is true.
— The Element TTL field is greater than 1—see 14.10.8.2.
The contents of a RANN element in Case B shall be as shown in Table 14-26.
Table 14-26—Contents of a RANN element in Case B
Field Value
Element ID Value given in Table 9-77 for the RANN element
Length As received
Flags As received
Hop Count As received + 1
Element TTL As received – 1
Root Mesh STA Address As received
HWMP Sequence Number As received
Interval As received
Metric As received own link metric toward the transmitting mesh STA
14.10.12.4 RANN element reception
14.10.12.4.1 General
Received RANN elements are subject to certain acceptance criteria. Processing and actions taken depend on
the content of the RANN element and the forwarding information maintained by the receiving mesh STA.
See also 14.10.8.
14.10.12.4.2 Acceptance criteria
The RANN element shall not be accepted (and shall not be processed as described in 14.10.12.4.3) if any of
the following is true:
— The HWMP Sequence Number < previous HWMP SN from this originating root mesh STA
— (The HWMP Sequence Number = previous HWMP SN) AND (updated path metric is worse than
previous path metric)
Otherwise, the RANN element shall be accepted.
2194
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.10.12.4.3 Effect of receipt
The following applies only to a RANN element that was accepted according to the acceptance criteria in
14.10.12.4.2:
a) The receiving mesh STA shall set dot11MeshHWMPrannInterval to the value of the Interval field of
the received RANN element.
b) The receiving mesh STA may initiate a PREQ element / PREP element exchange with the root mesh
STA to set up or update a path to the root mesh STA. See 14.10.9.3 Case D.
c) The receiving mesh STA may record the Root Mesh STA Address, together with the HWMP
Sequence Number, Hop Count, and Metric in order to assist in executing 14.10.9.3 Case D.
The receiving mesh STA shall transmit a RANN element if the conditions defined in 14.10.12.3 Case B are
true.
14.10.13 Considerations for support of STAs without mesh functionality
The verification, by the mesh STA collocated with the AP, of disjunct MAC addresses between a non-AP
STA without mesh functionality and mesh STAs during authentication/association of the non-AP STA
without mesh functionality (see 11.3.6) may be done by issuing a PREQ element for the MAC address of the
non-AP STA without mesh functionality by the mesh STA collocated with the AP. The TO (Target Only)
subfield of the Per Target Flags field of the PREQ element shall be set to 1.
The MAC address of the non-AP STA already exists in the MBSS if the AP with mesh functionality receives
a PREP element for the MAC address of the non-AP STA and it can be derived from the PREP element that
the requested MAC address is originated from a mesh STA. (The AE subfield of the Flags field of the PREP
element is set to 0; see 9.4.2.114.)
14.11 Interworking with the DS
14.11.1 Overview of interworking between a mesh BSS and a DS
A mesh STA that has access to a DS is called a mesh gate. Mesh STAs in an MBSS access the DS via the
mesh gate. An MBSS functions like an IEEE 802 LAN segment that is compatible with IEEE Std 802.1D.
The MBSS appears as a single access domain.
An MBSS may contain two or more mesh gates. When multiple mesh gates in an MBSS have access to the
same DS, the MBSS has more than one “port” (in the sense of IEEE Std 802.1D-2004, for example) through
which it accesses the DS. Accordingly, broadcast loops may occur. Therefore, mesh gates should implement
a loop preventing protocol in the DS.
NOTE—In the DS a typical implementation uses the Rapid Spanning Tree Protocol (RSTP) as specified in
IEEE Std 802.1D-2004. With RSTP the resulting active DS topology forms a tree. Then, even if multiple mesh gates
connect with the same DS, the MBSS only accesses the DS through a single mesh gate.
When dot11MeshGateAnnouncements is true, the mesh gate announces its presence to other mesh STAs in
the MBSS. The mesh gate uses the gate announcement protocol (see 14.11.2) or alternatively one of the
HWMP proactive path selection methods with the Gate Announcement field equal to 1:
— The proactive PREQ mechanism (see 14.10.4.2), with the Gate Announcement field equal to 1 (see
14.10.9.3)
— The proactive RANN mechanism (see 14.10.4.3), with the Gate Announcement field equal to 1 (see
14.10.12.3)
2195
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the mesh gate uses one of the HWMP proactive path selection methods, the gate announcement
protocol is not used.
A mesh STA discovers the presence of a mesh gate with access to the external network by receiving GANN
elements (or PREQ element and RANN element with the Gate Announcement field equal to 1 if using such
mechanisms). Mesh STAs propagate these elements to neighbor mesh STAs in order to propagate the
information throughout the MBSS.
NOTE—The decision to set dot11MeshGateAnnouncements to true is beyond the scope of the standard. In general, the
mesh gate announces that it has access to a broader network beyond the MBSS, using gate announcement protocol or
HWMP proactive path selection methods with the Gate Announcement field equal to 1. One example of this
configuration is that the mesh gate has access to a portal through the DS.
When a mesh gate has access to IEEE 802 STAs outside the mesh BSS (a mesh STA collocated with an AP,
another mesh STA that belongs to another MBSS, etc.), the mesh gate acts as an intermediary for the IEEE
802 STAs outside the MBSS so that the forwarding information inside the MBSS only contains addresses
that belong to the MBSS. The mesh gate acting as an intermediary for external STAs is termed proxy mesh
gate. When the end station of an IEEE 802 communication is an external STA, mesh STAs handle addresses
of the end-to-end IEEE 802 communication as depicted in Figure 9-64. Proxy mesh gate operation is
described in 14.11.4.
14.11.2 Gate announcement (GANN)
14.11.2.1 General
Subclause 14.11.2 describes the function, generation, and processing of the GANN element.
14.11.2.2 Function
The GANN element, described in 9.4.2.111, is used to announce the presence of a mesh gate with
dot11MeshGateAnnouncements equal to true in the mesh BSS. Gate announcements allow mesh STAs to
discover such a mesh gate and, if necessary, to build a path toward it.
14.11.2.3 Conditions for generating and sending a GANN element
A mesh STA shall send a GANN element in a Gate Announcement frame, as defined in 9.6.17.4, in the
following cases:
Case A: Original transmission
The mesh STA is a mesh gate not sending PREQ element or RANN element with the Gate Announcement
field equal to 1 and dot11MeshGateAnnouncements is true. The mesh STA shall transmit the Gate
Announcement frame at every dot11MeshGateAnnouncementInterval.
The content of a GANN element in Case A shall be as shown in Table 14-27.
The mesh gate shall assign the GANN Sequence Number from a single modulo 232 counter, starting at 0 and
incrementing by 1 for each GANN element transmission.
2196
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-27—Contents of a GANN element in Case A
Field Value
Element ID Value given in Table 9-77 for the GANN element
Length 15
Flags Reserved
Hop Count 0
Element TTL Maximum number of hops allowed for the gate announcement
Mesh Gate Address Mesh STA MAC address
GANN Sequence Number Previous GANN sequence number + 1
Interval dot11MeshGateAnnouncementInterval
Case B: Propagation
All of the following conditions are met:
— The mesh STA has received and accepted a gate announcement.
— The decremented Element TTL of the gate announcement is greater than or equal to 1.
— dot11MeshForwarding is true.
The content of a GANN element in Case B shall be as shown in Table 14-28.
Table 14-28—Contents of a GANN element in Case B
Field Value
Element ID Value given in Table 9-77 for the GANN element
Length 15
Flags As received
Hop Count As received + 1
Element TTL As received – 1
Mesh Gate Address As received
GANN Sequence Number As received
Interval As received
2197
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.11.2.4 GANN element processing
14.11.2.4.1 General
A received gate announcement is subject to certain acceptance criteria. Processing depends on the contents
of the gate announcement and the information available at the receiving mesh STA.
14.11.2.4.2 Acceptance criteria
The GANN element shall not be accepted (and shall not be processed as described in 14.11.2.4.3) if the
GANN Sequence Number of the gate announcement is equal or lower than the GANN Sequence Number of
the most recently accepted gate announcement with the same Mesh Gate Address.
14.11.2.4.3 Effect of receipt
The following applies only to a GANN element that was accepted according to the acceptance criteria in
14.11.2.4.2. The receiving mesh STA shall transmit a gate announcement as described in 14.11.2.3, Case B.
The Mesh Gate Address field of the GANN contains the address of the mesh gate, and may be stored for the
purpose of determining paths to the mesh gates. Paths to mesh gates allow mesh STAs to forward MSDUs to
addresses for which no path could be determined (see 10.35.8).
14.11.3 Data forwarding at proxy mesh gates
14.11.3.1 General
Forwarding of MSDUs from the DS into the MBSS by a proxy mesh gate follows the procedures given in
10.35.2.
Forwarding of MSDUs from the MBSS into the DS by a proxy mesh gate follows the procedures that apply
for the specific collocated network.
A proxy mesh gate learns the addresses of the other proxy mesh gates in the MBSS and of external addresses
proxied by them through the receipt of path selection messages and messages carrying proxy information
(for example, see 9.4.2.116).
14.11.3.2 Forwarding of MSDUs from the MBSS to the DS
On receipt of an individually addressed mesh Data frame from the MBSS with Address Extension Mode
equal to “Address5&6” (see Table 9-20), a proxy mesh gate shall perform the following:
— If Address 5 is a known destination MAC address in the proxy information (external address) and
proxied by the proxy mesh gate, the proxy mesh gate forwards the MSDU to the external address
through the DS.
— If Address 5 is a known destination MAC address in the proxy information (external address) and
proxied by a different proxy mesh gate, the MSDU is forwarded through the MBSS to the proxy
mesh gate that proxies the external address. The MSDU is sent into the MBSS according to the
procedures in 10.35.3.1 as an individually addressed mesh Data frame with Address 3 set to the
MAC address of the proxy mesh gate of the proxy information proxying Address 5, Address 4 set to
the MAC address of this proxy mesh gate, and Address 5 and Address 6 kept unchanged.
— If Address 5 is unknown to the proxy mesh gate, the mesh gate forwards the MSDU to the DS. The
mesh gate may send an error notification to the mesh source of the MSDU. In HWMP, this is done
by sending a PERR element as described in 14.10.11.3 Case C.
On receipt of group addressed mesh Data frame from the MBSS with Address Extension Mode equal to
“Address4” (see Table 9-20), a proxy mesh gate shall forward the MSDU to the DS using a group addressed
frame.
2198
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.11.3.3 Forwarding of MSDUs from the DS to the MBSS
On receipt of an individually addressed MSDU from the DS, a proxy mesh gate shall perform the following
depending on the possible destination:
a) If the destination of the MSDU is a mesh STA address that the mesh gate knows to be inside the
MBSS, the mesh gate forwards the MSDU according to the procedures for frame addressing and
data forwarding at source mesh STAs in an MBSS (10.35.3.1). The MSDU shall be transmitted
using a frame with the four-address MAC header format (with the Address Extension Mode subfield
in the Mesh Control field set to “Address5&6” (see Table 9-20)), where the Mesh Address
Extension subfield in the Mesh Control field carries the addresses of the end stations, as specified in
row “Mesh Data (proxied, individually addressed)” of Table 9-42. The address fields are set as
follows:
— Address 1: The address of the next-hop mesh STA (toward the destination mesh STA
according to the forwarding information—see 10.35.2)
— Address 2: The address of the proxy mesh gate
— Address 3: The address of the destination mesh STA
— Address 4: The address of the proxy mesh gate
— Address 5: The address of the destination end mesh STA that is the same as Address 3
— Address 6: The address of the source end mesh STA that is the source address of the MSDU
received from the DS
b) If the destination of the MSDU is an external address that is proxied by another proxy mesh gate in
the MBSS, the mesh gate forwards the MSDU according to the procedures for frame addressing and
data forwarding at source mesh STAs in an MBSS (10.35.3.1). The MSDU shall be transmitted
using a frame with the four-address MAC header format [with the Address Extension Mode subfield
in the Mesh Control field set to “Address5&6” (see Table 9-20)], where the Mesh Address Exten-
sion subfield in the Mesh Control field carries the addresses of the end stations, as specified in row
“Mesh Data (proxied, individually addressed)” of Table 9-42. The address fields are set as follows:
— Address 1: The address of the next-hop mesh STA (toward the proxy mesh gate of the
destination of the MSDU as derived from the proxy information (see 14.11.4.2) and according
to the forwarding information—10.35.2)
— Address 2: The address of this proxy mesh gate
— Address 3: The address of the proxy mesh gate of the destination of the MSDU as derived from
the proxy information (see 14.11.4.2)
— Address 4: The address of this proxy mesh gate
— Address 5: The address of the destination end mesh STA that is the destination address of the
MSDU received from the DS
— Address 6: The address of the source end mesh STA that is the source address of the MSDU
received from the DS
c) If the MSDU has a destination address that is unknown to the mesh gate, the mesh gate forwards the
MSDU to other known mesh gates in the MBSS as an individually addressed frame according to the
procedures for frame addressing and data forwarding of individually addressed frames at source
mesh STAs in an MBSS (10.35.3.1). The MSDU shall be transmitted using a frame with the four-
address MAC header format [with the Address Extension Mode subfield in the Mesh Control field
set to “Address5&6” (see Table 9-20)], where the Mesh Address Extension subfield in the Mesh
Control field carries the addresses of the end stations, as specified in row “Mesh Data (proxied, indi-
vidually addressed)” of Table 9-42. The address fields are set as follows:
— Address 1: The address of the next-hop mesh STA (toward the other known mesh gate in the
MBSS according to the forwarding information—see 10.35.2)
— Address 2: The address of this proxy mesh gate
— Address 3: The address of the other known mesh gate in the MBSS
— Address 4: The address of this proxy mesh gate
2199
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Address 5: The address of the destination end mesh STA that is the unknown destination
address of the MSDU received from the DS
— Address 6: The address of the source end mesh STA that is the source address of the MSDU
received from the DS
Note that the procedure to determine that an address is unknown depends on the active path selection
protocol. It might require an attempt to establish a path to the destination (see 14.8).
On receipt of a group addressed MSDU from the DS, the mesh gate forwards the MSDU according to the
procedures for frame addressing and data forwarding of group addressed frames at source mesh STAs in an
MBSS (10.35.4.1). The MSDU shall be transmitted using a frame with the three-address MAC header
format [with the Address Extension Mode subfield in the Mesh Control field set to “Address4” (see Table 9-
20)], where the Mesh Address Extension subfield in the Mesh Control field carries the address of the source
end stations, as specified in row “Mesh Data (proxied, group addressed)” of Table 9-42. The address fields
are set as follows:
— Address 1: The group address
— Address 2: The address of the proxy mesh gate
— Address 3: The address of the proxy mesh gate
— Address 4: The address of the source external STA
14.11.4 Proxy information and proxy update
14.11.4.1 General
Forwarding information of mesh STAs only contains addresses of mesh STAs that belong to the MBSS.
However, the end station of the IEEE 802 communication may be an IEEE 802 station outside the MBSS,
and such station is called external STA. Examples of external STAs are as follows:
— STAs that are associated with an AP that is collocated with a mesh STA
— STAs that are behind a mesh gate
Mesh STAs forward MSDUs to external STAs by treating MAC addresses of the external STAs as external
addresses. The mesh STAs that are the destination mesh STAs of the messages destined to external STAs are
called proxy mesh gates, and their MAC addresses are called proxy addresses.
NOTE—External STAs are reached using mesh services solely, i.e., they are not part of an MBSS. The mechanism by
which the proxy mesh gate bridges the MBSS and the external STAs is beyond the scope of the standard. However, the
standard describes the method by which mesh STAs use the external addresses that are discovered and bridged by the
proxy mesh gate.
14.11.4.2 Proxy information
Proxy mesh gates and source mesh STAs of MSDUs destined to external STAs maintain proxy information.
Proxy information contains the external address, the corresponding proxy address, the sequence number of
the proxy information, and the corresponding proxy information lifetime.
Mesh STAs can learn the addresses of proxy mesh gates and of the external stations proxied by these proxy
mesh gates through the receipt of proxy update messages or path selection messages carrying proxy
information. Particularly, proxy information is updated in the following circumstances:
— A mesh STA receives and processes a proxy update (see 14.11.4.3)
— A mesh STA receives and processes an element of the active path selection protocol containing
proxy information. In HWMP, these are PREQ elements (see 14.10.9.4.3), PREP elements (see
14.10.10.4.3), and PERR elements (see 14.10.11.4.3)
Additionally, proxy mesh gates may also proactively maintain proxy information on external STAs.
2200
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the proxy information lifetime is specified, a mesh STA shall maintain the proxy information as valid
information until the lifetime expires. Details of the lifetime are described in 14.11.4.3.4.
The sequence number of the proxy information and the proxy mesh gate address define a chronological
order of the proxy information of an external STA at a specific proxy mesh gate.
When the proxy information is created at the proxy mesh gate, the proxy sequence number is initialized to
an arbitrary value. The proxy information sequence number in the proxy information at the proxy mesh gate
is incremented by 1 before the transmission of the proxy information to another mesh station. The proxy
information sequence number shall be incremented if the proxy information is invalidated.
If proxy information is transmitted in HWMP elements (PREQ, PREP, and PERR), the proxy information
sequence number is set to the HWMP SN of the HWMP element containing this proxy information.
Comparison of the proxy information sequence numbers is performed using a circular modulo 232
comparison.
Valid proxy information is used to determine and set Address 5 and Address 6 in individually addressed
mesh Data frames, or Address 4 in group addressed mesh Data frames.
14.11.4.3 Proxy update (PXU)
14.11.4.3.1 General
Subclause 14.11.4.3 describes the function, generation, and processing of the PXU element.
14.11.4.3.2 Function
A mesh STA generates a PXU element to inform a destination mesh STA about proxy information of
external addresses that are reachable through the proxy mesh gate specified in the PXU element.
NOTE—Typically, a proxy mesh gate generates and sends a PXU element to another proxy mesh gate in the MBSS or a
mesh STA that originates traffic to the external stations proxied by the proxy mesh gate. However, the standard also
allows other usage of the PXU element.
The PXU element is transmitted in a Proxy Update frame (an individually addressed frame). The Proxy
Update frame may contain multiple PXU elements when needed (for instance, the proxy mesh gate has a
large number of proxy information).
14.11.4.3.3 Conditions for generating and sending a PXU element
A proxy mesh gate may transmit a PXU when it adds, updates, or deletes an external address to (or from) its
proxy information. A proxy mesh gate may also transmit a PXU at periodic intervals.
A mesh STA that holds proxy information of a proxy mesh gate in the MBSS may also transmit a PXU.
A mesh STA may retransmit the same PXU element repeatedly until the mesh STA receives a PXUC
element from the destination mesh STA. See 14.11.4.4.
The content of a PXU element shall be as shown in Table 14-29.
The proxy mesh gate shall assign the PXU ID from a single modulo 256 counter, starting at 0 and
incrementing by 1 for each PXU element.
2201
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-29—Contents of a PXU element
Field Value/description
Element ID Value given in Table 9-77 for the PXU element
Length 8 + length of N Proxy Information fields
PXU ID Previous PXU ID + 1
PXU Originator MAC MAC address of the originator of the PXU
Address
Number of Proxy Information Number of proxy information reported to the destination mesh STA (N ≥ 1).
(N)
Per Proxy Flags Bit 0: 0: add proxy information; 1: delete proxy information
Information Bit 1: 0: Proxy MAC Address field present; 1: Proxy MAC Address = PXU
Originator MAC Address, Proxy MAC Address field not present
Bit 2: 0: Proxy Information Lifetime field not present; 1: Proxy Information
Lifetime field present. If Bit 0 is 1, Bit 1 shall be set to 0.
Bit 3–7: Reserved
External MAC address of the STA proxied by the proxy mesh gate.
MAC
Address
Proxy Proxy information sequence number of the proxy information after being
Information incremented. See 14.11.4.2.
Sequence
Number
Proxy MAC MAC address of the proxy mesh gate. This field is present if Bit 1 of the
Address Flags field is 0; it is not present otherwise.
Proxy The proxy information lifetime of this proxy information as taken from the
Information proxy information of the originator of the PXU.
Lifetime
14.11.4.3.4 Effect of receipt of a PXU element
A mesh STA that receives the PXU element shall update its proxy information with the list of proxy
information reported in the PXU under the following conditions:
— Proxy information for the external MAC address and the proxy mesh gate reported in the Proxy
Information field of the PXU does not exist at the mesh STA.
— Proxy information for the external MAC address and the proxy mesh gate reported in the Proxy
Information field of the PXU does exist at the mesh STA and the value of the Proxy Information
Sequence Number subfield in the received PXU is larger than the value of the proxy information
sequence number in the proxy information at the mesh STA.
When multiple PXU elements are contained in the received Proxy Update frame, the recipient mesh STA
shall process all of the PXU elements in the frame.
The MAC address of the proxy mesh gate is taken from the Proxy MAC Address subfield in the Proxy
Information field when bit 1 in the Flags subfield is equal to 0, and from the PXU Originator MAC Address
field in the PXU element when bit 1 in the Flags subfield is equal to 1.
The MAC address of the external STA is taken from the External MAC Address subfield of the
corresponding Proxy Information field in the received PXU element.
2202
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The sequence number of the proxy information is taken from the Proxy Information Sequence Number
subfield of the corresponding Proxy Information field in the received PXU element.
If the Proxy Information Lifetime subfield is present (the Lifetime subfield in the Flags subfield is 1) and
there is already proxy information stored for the proxy mesh gate and external address reported in the proxy
information of the PXU element, the mesh STA shall set the proxy lifetime to the larger one of the proxy
lifetime reported by the PXU and the stored proxy information.
If the Proxy Information Lifetime subfield is present (bit 2 of the Flags subfield is 1) and there is proxy
information stored for the proxy mesh gate and external address reported in the proxy information of the
PXU element, the mesh STA shall set the proxy information lifetime to the value in the Proxy Information
Lifetime subfield.
If the Proxy Information Lifetime subfield is not present, the lifetime of the proxy information is the same as
the lifetime of the path to the proxy address. Alternatively, the lifetime of the proxy information may be set
to a value representing infinity.
The destination mesh STA that received the PXU shall send a PXUC element to the originator mesh STA of
the PXU as described in 14.11.4.4.3.
14.11.4.4 Proxy update confirmation (PXUC)
14.11.4.4.1 General
Subclause 14.11.4.4 describes the function, generation, and processing of the PXUC element.
14.11.4.4.2 Function
A PXUC element is generated by the destination mesh STA of a PXU to inform the sender of the PXU that
the PXU has been properly received.
The PXUC element is transmitted in a Proxy Update Confirmation frame (an individually addressed frame).
The Proxy Update Confirmation frame may contain multiple PXUC elements in order to confirm the
reception of multiple PXU elements to the destination of the Proxy Update Confirmation frame.
14.11.4.4.3 Conditions for generating and sending a PXUC element
The destination mesh STA of a Proxy Update frame containing a PXU element shall send a PXUC element
to the originator mesh STA of the PXU element.
The content of a PXUC element shall be as shown in Table 14-30.
Table 14-30—Contents of a PXUC element
Field Value/description
Element ID Value given in Table 9-77 for the PXUC element
Length 7
PXU ID PXU ID of the PXU that is being confirmed
Destination mesh STA MAC address of the originator of the PXUC
Address
2203
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.11.4.4.4 Effect of receipt of PXUC element
If a mesh STA receives a PXUC element in a PXUC frame in response to a PXU element it originated, the
mesh STA shall no longer send any PXUs with the same PXU ID as given in the received PXUC element.
14.11.5 Mesh STA collocation
A mesh STA collocated with another STA shall use a MAC address that is different from the one used by the
collocated STA. This precludes ambiguities relating to the presence of the Mesh Control field in the Frame
Body (see 9.2.4.7), GTK use (see 12.6.1.1.10), and proxy information (see 14.11.4.2).
Path selection with collocated mesh STAs using HWMP is described in 14.10.5.
14.12 Intra-mesh congestion control
14.12.1 General
Intra-mesh congestion control is based on the following three main mechanisms:
a) Local congestion monitoring and congestion detection
b) Congestion control signaling
c) Local rate control
A mesh STA shall activate a congestion control protocol specified by
dot11MeshActiveCongestionControlMode. At any given time, there is only one congestion control protocol
active in a particular MBSS, signaled in the Congestion Control Mode Identifier field of the Mesh
Configuration element. This standard specifies the congestion control signaling protocol that shall be
available in any MBSS with an activated congestion control.
NOTE—This standard allows for inclusion of more advanced or alternative congestion control schemes through the
Congestion Control Mode Identifier in the Mesh Configuration element.
14.12.2 Congestion control signaling protocol
When dot11MeshActiveCongestionControlMode is congestionControlSignaling (1), the mesh STA activates
the congestion control signaling protocol. The congestion control signaling protocol specifies the signaling
messages used with intra-mesh congestion control. Specific algorithms for local congestion monitoring and
congestion detection are beyond the scope of the congestion control signaling protocol.
The congestion control signaling protocol is triggered after congestion is detected at a mesh STA. A mesh
STA that detects congestion, and the traffic destination causing this congestion, may transmit a Congestion
Control Notification frame to the mesh STAs of the traffic source and other neighboring mesh STAs. The
frame contains one or more Congestion Notification elements, each of which specifies the traffic destination
causing the congestion and the expected duration of the congestion per AC per mesh destination as
estimated by the congested mesh STA.
Upon receipt of a Congestion Notification frame a mesh STA may stop forwarding, or reduce the rate of
forwarding, traffic to the destinations listed in the Congestion Notification elements via the mesh STA
reporting congestion for the duration specified in the Congestion Notification element. It may also send its
own Congestion Control Notification frame to mesh STAs that are the source of the reported congestion, and
other neighboring mesh STAs. Any time difference between receipt of the original Congestion Control
Notification frame and the transmission of this new Congestion Control Notification frame should be
reflected in the duration indicated in the new congestion control notification in such a way that any timers
2204
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
set by mesh STAs in response to the first report of congestion for a given destination all expire at the same
time.
If the Destination MAC Address field in a received Congestion Notification element is the group address, it
should be interpreted to mean that communication with the transmitter of this frame should be stopped, or
reduced, for the duration specified in the Congestion Notification element. This event should not result in
the transmission of a Congestion Notification element with a Destination MAC Address field set to the
group address to any neighbor mesh STAs.
When the duration of a traffic congestion report has expired, a mesh STA should resume forwarding traffic
to the destinations that were listed in the traffic congestion report via the mesh STA that reported congestion.
NOTE 1—Local policies/mechanisms implemented in a mesh STA might be required to achieve timely transmission of
the congestion control signaling messages and to avoid transmission of stale messages that might reduce network
efficiency.
NOTE 2—A mesh STA that receives a Congestion Control Notification frame might choose to adjust its frame rate,
defined by the number of transmitted frames per a unit of time, to the sender of the Congestion Control Notification
frame in the identified congested AC(s) for the duration specified in the Congestion Notification element. The reduction
of the frame rate to a congested mesh STA avoids waste of the mesh resources for transmission of packets that with high
probability will not be handled/forwarded by the congested mesh STA.
14.13 Synchronization and beaconing in MBSSs
14.13.1 TSF for MBSSs
A mesh STA shall initialize and update its TSF timer according to the MBSS’s active synchronization
method. Each mesh STA shall maintain a TSF timer as described in 11.1.3.1, and comply with the TSF timer
accuracy as described in 11.1.3.9.
14.13.2 Extensible synchronization framework
14.13.2.1 General
This standard introduces an extensible framework to enable the implementation of multiple synchronization
methods for mesh STAs. Within the extensible synchronization framework, the neighbor offset
synchronization method is defined as the default mandatory synchronization method in order to enable
minimal synchronization capabilities and interoperability between mesh STAs that use MCCA, MBCA, or
operate in light or deep sleep mode. The framework allows the integration of other synchronization methods
into MBSSs. A vendor may implement any synchronization method using this framework to meet special
application needs. Although a mesh STA may include multiple implementations of synchronization
methods, only one synchronization method at a time shall be used by a mesh STA. All mesh STAs in an
MBSS use the same synchronization method; see 14.2.7 item a). The MBSS’s active synchronization
method is controlled by the SME and given to the MLME by dot11MeshActiveSynchronizationMethod.
A mesh STA shall announce the MBSS’s active synchronization method using the Synchronization Method
Identifier field in the Mesh Configuration element in their Beacon and Probe Response frames.
14.13.2.2 Neighbor offset synchronization method
14.13.2.2.1 General
When dot11MeshActiveSynchronizationMethod is neighborOffsetSynchronization (1), the mesh STA shall
use the neighbor offset synchronization method as its active synchronization method, and maintain the
timing offset value between its own TSF timer and the TSF timer of each neighbor STA with which it
2205
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
synchronizes. The mesh STA shall set the Synchronization Method Identifier field in the Mesh
Configuration element to 1.
The mesh STA shall maintain synchronization with all of its neighbor peer mesh STAs up to
dot11MeshNbrOffsetMaxNeighbor mesh STAs. The mesh STA should maintain synchronization with
additional neighbor mesh STAs that are in the same MBSS up to a total of
dot11MeshNbrOffsetMaxNeighbor mesh STAs and also, additional neighbor mesh STAs that are outside of
the MBSS up to a total of dot11MeshNbrOffsetMaxNeighbor mesh STAs.
Upon receipt of an MLME-MESHNEIGHBOROFFSETSYNCSTART.request primitive, the MLME shall
start synchronization using the neighbor offset synchronization method with the specified peer STA. Upon
receipt of an MLME-MESHNEIGHBOROFFSETSYNCSTOP.request primitive, the MLME shall stop
synchronization using the neighbor offset synchronization method with the specified peer STA.
A mesh STA that utilizes the neighbor offset synchronization method may start its TSF timer independently
of other mesh STAs. The mesh STA shall calculate the timing offset value with respect to the neighbor STA
with which it maintains synchronization, as described in 14.13.2.2.2. The mesh STA shall adjust its TSF
timer based on time stamps received in Beacon or Probe Response frames from neighbor STAs with which it
maintains synchronization, as described in 14.13.2.2.3.
When the mesh STA alternates awake state and doze state, it might not always listen to the Beacon frames of
a neighbor mesh STA with which it maintains synchronization. However, it shall comply with the clock drift
compensation procedures and TSF jitter allowance as described in 14.13.2.2.3. See S.3.6 for more
guidelines.
14.13.2.2.2 Timing offset calculation
When dot11MeshActiveSynchronizationMethod is neighborOffsetSynchronization (1), the mesh STA shall
calculate the timing offset value with respect to the neighbor STA with which it maintains synchronization.
The calculation of the timing offset value is based on time stamps from the received Beacon and Probe
Response frames as follows:
Toffset = Tt – Tr
where
Toffset is the timing offset value
Tt is the value in the Timestamp field in the received frame
Tr is the frame reception time measured in the TSF timer of the mesh STA
The offset value is represented as a signed integer. The unit of the offset value is µs. The mesh STA shall
keep the Toffset value calculated from the latest Beacon or Probe Response frame received from each
neighbor STA with which it maintains synchronization.
A mesh STA may translate the time measured in the TSF of the neighbor STA into the time base of its own
TSF as follows:
Tself = Tneighbor – Toffset
where
Tself is the translated time in its own TSF
Tneighbor is the time measured in the TSF timer of the neighbor STA
2206
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Upon receipt of an MLME-MESHNEIGHBOROFFSETCALCULATE.request primitive, the MLME shall
receive a Beacon or Probe Response frame from the specified neighbor STA, calculate the Toffset from the
received frame, and report the calculated Toffset to the SME by responding with an MLME-
MESHNEIGHBOROFFSETCALCULATE.confirm primitive. Toffset is used to provide the timing reference
of neighbor STAs.
14.13.2.2.3 Clock drift adjustment
When dot11MeshActiveSynchronizationMethod is neighborOffsetSynchronization (1), the mesh STA shall
examine the reception time of the Beacon frames from neighbor STAs with which it maintains
synchronization and adjust its TSF timer to compensate the relative timing error among neighbor mesh
STAs caused by the clock drift. The mesh STA adjusts its TSF so that its TSF counting is aligned to the most
delayed neighbor STA.
When the mesh STA receives a Beacon frame or a Probe Response frame from one of the neighbor STAs
with which it maintains synchronization, the mesh STA shall perform the following measurement procedure:
a) The mesh STA checks if the transmitter of the Beacon frame or Probe Response frame is in the
process of the TBTT adjustment (see 14.13.4.4.3). If the received frame contains the Mesh
Configuration element and the TBTT Adjusting subfield in the Mesh Configuration field is 1, the
mesh STA shall invalidate the Toffset value for this neighbor STA and shall not perform the
following steps.
b) The mesh STA checks if it has a valid Toffset value obtained from the previous Beacon or Probe
Response frame reception from the transmitter of the received frame. If it does not have the valid
Toffset value, it shall not perform the following steps.
c) The mesh STA calculates the clock drift amount TClockDrift by comparing the Toffset,p,the offset
value obtained previously for this neighbor STA, and the Toffset,c, the offset value obtained from the
current frame reception.
TClockDrift = Toffset, p – Toffset, c
where
TClockDrift is the clock drift amount in µs represented as a signed integer.
d) The mesh STA shall compare the TClockDrift value with the TMaxClockDrift, the largest TClockDrift
value obtained from other neighbor STA within this beacon period. If the TClockDrift value for this
neighbor STA is greater than the TMaxClockDrift value, the mesh STA replaces the TMaxClockDrift
value with the TClockDrift value, in order to determine the largest TClockDrift value among neighbor
STAs.
When the previous TClockDrift values have been stable for a neighbor mesh STA, the mesh STA may
substitute the previous TClockDrift value for the TClockDrift value in the measurement procedure and process
the step d), at the time of a TBTT of the neighbor STA, without receiving a Beacon frame.
Before the mesh STA transmits a Beacon frame, it shall perform the following adjustment procedure:
— The mesh STA checks if the current TMaxClockDrift value is greater than zero. If the TMaxClockDrift
value is greater than zero, it shall continue the following steps. Otherwise, it shall initialize the
TMaxClockDrift with zero and shall not perform the following step.
— If the TMaxClockDrift value is smaller than 0.04% of its beacon interval, the mesh STA shall adjust its
TSF timer so that the next TBTT will be delayed for the duration of the TMaxClockDrift and initialize
the TMaxClockDrift value with zero. Otherwise, it shall adjust its TSF timer so that the next TBTT will
be delayed for the duration of 0.04% of its beacon interval and subtract the value of 0.04% of its
beacon interval from the TMaxClockDrift.
The mesh STA may adjust its TSF timer only to slow the counting. The mesh STA may adjust its TSF timer
within the range of 0.04% in a beacon period.
2207
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the delay amount at each beacon period is not stable, the mesh STA should frequently listen to
neighbor STAs’ Beacon frames. An implementation might reduce TSF timer jitter caused by the adjustment
procedure by making additional adjustments to the TMaxClockDrift , as long as the mesh STA’s TSF count is
aligned to the most delayed neighbor mesh STA. The means of making these additional adjustments is
beyond the scope of this standard.
NOTE—This clock drift compensation procedure does not intend to maintain a strict synchronization. It aims to stop
TBTT drifting away among neighbor mesh STAs, allowing some jitter of TSF timer.
14.13.3 Beaconing
14.13.3.1 Beacon generation in MBSSs
A mesh STA transmits Beacon frames that are specific to an MBSS. Beacon frames for MBSS,
infrastructure BSS, or IBSS are differentiated by the Capability Information field in the Beacon frame as
specified in 9.4.1.4. A mesh STA that collocates with an AP generates Beacon frames for the MBSS
independently of the AP.
The mesh STA shall define a series of TBTTs exactly dot11BeaconPeriod TUs apart. Time zero is defined to
be a TBTT with the Beacon frame containing a DTIM. At each TBTT, the mesh STA shall schedule a
Beacon frame as the next frame for transmission according to the medium access rules specified in
Clause 10.
NOTE—To achieve this requirement, the mesh STA suspends any pending transmissions until the beacon has been
transmitted. In the case of a DTIM, the mesh STA also suspends any pending individually addressed transmissions until
any pending group addressed transmissions have been performed (see 14.14.5).
The beacon period is included in Beacon and Probe Response frames.
The mesh STA shall start beaconing upon the receipt of the MLME-START.request primitive.
14.13.3.2 Beacon reception for mesh STA
A mesh STA shall use information from the Timestamp field without regard to the BSSID or Mesh ID in
order to obtain information necessary for synchronization, if the mesh STA maintains synchronization with
the transmitter of the Beacon frame. A mesh STA may use information from the Beacon Interval field and
the Beacon Timing element without regard for the Mesh ID in order to obtain information necessary for
MBCA, if the mesh STA maintains synchronization with the transmitter of the Beacon frame and
dot11MBCAActivated is true. A mesh STA may use information from the MCCAOP Advertisement
Overview element and MCCAOP Advertisement element without regard for the Mesh ID in order to obtain
information necessary for MCCA, if the mesh STA maintains synchronization with the transmitter of the
Beacon frame and dot11MCCAActivated is true.
A mesh STA in a mesh BSS shall use information that is not in the CF Parameter Set element, the
Timestamp field, the Beacon Interval field, the Beacon Timing element, the MCCAOP Advertisement
Overview element, or the MCCAOP Advertisement element in received Beacon frames only if the mesh
STA maintains a mesh peering with the transmitter of the Beacon frame.
14.13.4 Mesh beacon collision avoidance (MBCA)
14.13.4.1 Overview
Mesh STAs use the mesh beacon collision avoidance (MBCA) protocol to detect and mitigate collisions
among Beacon frames transmitted by other STAs (including mesh STAs, IBSS APs, and IBSS STAs) on the
same channel within the range of 2 hops. MBCA mitigates hidden node problems with respect to Beacon
frames.
2208
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—Beacon frames are transmitted without acknowledgment and might collide with other frames. In a mesh BSS,
multiple STAs transmit Beacon frames periodically, and mesh STAs might be located out of range of each other. This
implies that Beacon frames might suffer from the so-called hidden node problem and might not be received by neighbor
STAs. Once Beacon frames from hidden STAs start to collide, Beacon frames keep on colliding if these hidden STAs
transmit Beacon frames at the same beacon interval that is a typical operation. MBCA provides a set of rules to mitigate
this problem.
When dot11MBCAActivated is true, the mesh STA shall set the MBCA Enabled subfield in the Mesh
Capability field of the Mesh Configuration element to 1.
MBCA is composed of beacon timing advertisements, TBTT selection, and TBTT adjustment. When
dot11MBCAActivated is true, the mesh STA advertises the TBTT and beacon interval of its neighbor STAs
through the Beacon Timing element as described in 14.13.4.2. Upon reception of the Beacon Timing
element, the mesh STA obtains the beacon timing information of its neighbor mesh STAs and uses this
information for its TBTT selection and TBTT adjustment as described in 14.13.4.3 and 14.13.4.4. The mesh
STA may also perform additional procedures described in 14.13.4.5 and 14.13.4.6.
When dot11MBCAActivated is true, the mesh STA that alternates awake state and doze state should listen to
Beacon frames from its neighbor STAs, with which it maintains synchronization, often, in order to advertise
and obtain the recent TBTT information.
14.13.4.2 Beacon timing advertisement
14.13.4.2.1 General
When dot11MBCAActivated is true, the mesh STA shall contain Beacon Timing element in Beacon and
Probe Response frames in order to advertise its beacon timing information. The mesh STA calculates the
TBTT of its neighbor STAs with which it maintains synchronization as described in 14.13.4.2.2, and
composes beacon timing information as described in 14.13.4.2.3. The mesh STA collects the beacon timing
information from each neighbor STA with which it maintains synchronization. The collection of the beacon
timing information is termed “beacon timing information set.” The mesh STA contains whole or part of the
beacon timing information set in the Beacon Timing element as described in 14.13.4.2.5. The mesh STA
also maintains the status number of the beacon timing information set and contains the status number in the
Beacon Timing element as described in 14.13.4.2.4. The receiver of the Beacon Timing element uses the
received beacon timing information as described in 14.13.4.2.6.
14.13.4.2.2 Calculation of neighbor STA’s TBTT
When a Beacon frame is received from one of its neighbor STAs with which the mesh STA maintains
synchronization, the mesh STA shall calculate the TBTT of the received Beacon frame as follows:
TTBTT = Tr – (Tt mod (TBeaconInterval 1024))
where
TTBTT is the calculated TBTT
Tr is the frame reception time measured in the TSF timer of the receiving mesh STA
Tt is the value in the Timestamp field in the received frame
TBeaconInterval is the value in the Beacon Interval field in the received frame
The TTBTT is used as described in 14.13.4.2.3.
Further, the mesh STA shall calculate the time difference between the TBTT of the received Beacon frame
and the time predicted from the past TBTT as follows:
2209
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TDelta = | TTBTT, c – (TTBTT, p + (TBeaconInterval NCount)) |
where
TDelta is the time difference
TTBTT, c is the TBTT calculated from the received Beacon frame
TTBTT, p is the TBTT calculated for the first time after the latest status number update (see
14.13.4.2.4)
TBeaconInterval is the value in the Beacon Interval field in the received Beacon frame
NCount is the number of TBTTs since TTBTT, p has been calculated
TDelta is used to maintain the status number described in 14.13.4.2.4.
14.13.4.2.3 Beacon timing information
The mesh STA shall keep the latest TTBTT together with the beacon interval contained in the received frame
and the identifier of the neighbor STA as the beacon timing information with respect to the neighbor STA.
When the elapsed time since the latest Beacon frame reception is smaller than 524 288 TU, the beacon
timing information is valid.
NOTE—The beacon timing information provides the time reference for a series of the TBTTs of the corresponding
STA. Using the beacon timing information, a mesh STA is able to predict future TBTTs by adding the reported beacon
interval to the reported TBTT.
The mesh STA shall collect the valid beacon timing information from each neighbor STA with which it
maintains synchronization and keep the collection as the beacon timing information set. The beacon timing
information set is advertised to its neighbor mesh STAs through the Beacon Timing element as described in
14.13.4.2.5.
When the amount of neighbors, for which valid beacon timing information is kept, is large, the beacon
timing information set may be divided into multiple tuples of beacon timing information. In such case, a
tuple of beacon timing information is included in the Beacon Timing element (see 14.13.4.2.5).
14.13.4.2.4 Maintenance of the status number
The mesh STA shall maintain the status number of the beacon timing information set. The status number is
set to a value from a single modulo 16 counter, starting at 0 and incrementing by 1 for each transmission of a
frame containing the Beacon Timing element after the mesh STA encountered any of the following events:
a) It starts or stops maintaining synchronization with a neighbor STA.
b) It receives a Beacon frame from a neighbor STA with which it maintains synchronization and the
calculated TDelta (see 14.13.4.2.2) is larger than 255 µs.
c) It completes the TBTT adjustment procedure described in 14.13.4.4.3.
The mesh STA shall set the Status Number subfield in the Report Control field in the Beacon Timing
element to the status number. The Status Number subfield in the Report Control field facilitates the detection
of the changes in the beacon timing information set.
14.13.4.2.5 Transmitter’s procedure
When dot11MBCAActivated is true, the mesh STA shall report the TBTT and beacon interval of its
neighbor STAs through the Beacon Timing element as described in this subclause.
The Beacon Timing element reports on timing information of the Beacon frames that are received from the
neighbor STAs with which the mesh STA maintains synchronization on the operating channel. The mesh
2210
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA shall include the Beacon Timing element in Probe Response frames and in TBTT Adjustment Request
frames. The mesh STA shall also include the Beacon Timing element in Beacon frames as specified by
dot11MeshBeaconTimingReportInterval and dot11MeshBeaconTimingReportMaxNum. The Beacon
Timing element is present in a Beacon frame when the DTIM Count value in the Beacon frame is zero or
equal to an integer multiple of dot11MeshBeaconTimingReportInterval.
The maximum number of Beacon Timing Information fields contained in a Beacon Timing element is
limited to dot11MeshBeaconTimingReportMaxNum for Beacon frames, or is limited by the maximum
element size for other frames. When the number of neighbors, for which valid beacon timing information is
kept, is equal or smaller than the limit, the mesh STA shall include all the beacon timing information in a
single Beacon Timing element, setting both Beacon Timing Element Number and More Beacon Timing
Elements subfield in the Report Control field to 0. When the number of neighbors, for which valid beacon
timing information is kept, exceeds the limit, the mesh STA shall divide the beacon timing information set
into multiple tuples and assign each tuple with an index number starting from 0. When the beacon timing
information set is divided, the mesh STA shall include the successive tuples of beacon timing information in
the Beacon Timing elements. In this case, the mesh STA shall set the Beacon Timing Element Number
subfield in the Report Control field to the index number of the tuple. The mesh STA shall set the More
Beacon Timing Elements subfield in the Report Control field to 1 when it has one or more beacon timing
information tuples with a larger index number. The mesh STA shall divide the beacon timing information set
into no more than Ninfo tuples, where
Ninfo = N v N max ,
Nv is the number of valid beacon timing information fields
Nmax is the maximum number of Beacon Timing Information fields in the Beacon Timing element
The mesh STA may update the combination of the tuples only when the status number described in
14.13.4.2.4 is updated. The mesh STA shall include newly updated beacon timing information (i.e., beacon
timing information that causes an update of the status number as described in 14.13.4.2.4) in the tuple with a
smaller index number. When the status number is updated, the mesh STA shall include the tuple of beacon
timing information indexed as 0 in the Beacon Timing element in the subsequent Beacon frame. Successive
tuples shall be transmitted in ascending order of the index number in the successive Beacon frames.
NOTE—The standard does not impose mesh STAs to advertise a fragmented beacon timing information set sequentially
in its Beacon frames at all times. This implies that the mesh STA might advertise tuples with a smaller index number
more frequently, which is useful to notify new beacon timing information efficiently.
When the mesh STA receives a Probe Request frame containing a Beacon Timing element ID in its Request
element, it shall respond with a Probe Response frame containing the Beacon Timing element. If all beacon
timing information cannot be contained in a Beacon Timing element, the mesh STA shall include multiple
Beacon Timing elements containing successive tuples of beacon timing information in the order of the
Request element (see Table 9-34) so that all tuples are transmitted.
14.13.4.2.6 Receiver’s procedure
A mesh STA with dot11MBCAActivated equal to true that receives a Beacon Timing element obtains the
beacon timing information of its neighbor mesh STA and uses it for its TBTT selection and TBTT
adjustment as described in 14.13.4.3 and 14.13.4.4.
When a mesh STA receives a Beacon frame with a Beacon Timing element that contains only a subset of the
beacon timing information set, the mesh STA may transmit a Probe Request frame containing a Beacon
Timing element ID in its Request element to the transmitter of the Beacon Timing element, in order to
request the rest of the beacon timing information.
NOTE 1—The Report Control field in the Beacon Timing element facilitates the detection of the missing beacon timing
information.
2211
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 2—Once the entire beacon timing information set with a particular Status Number is obtained, the mesh STA
does not need to retrieve beacon timing information as long as the Status Number remains the same.
A mesh STA that receives the Beacon Timing element shall record the reported TBTT and its successive
TBTTs as neighbor’s essential beacon reception timing if the MSB of the Neighbor STA ID field in the
corresponding Beacon Timing Information field is 0. The essential beacon reception timing is used to
control the transmission of frames as described in 14.13.4.5.
A mesh STA can also check if its neighbor mesh STAs received its Beacon frame successfully by checking
whether the Beacon Timing elements received from its neighbor mesh STAs contain beacon timing
information of the mesh STA. When the Beacon Timing element is received from one of the peer mesh
STAs, the mesh STA checks if the MSB of the Neighbor STA ID subfield is set to 0 and the rest of the field
matches with the 7 LSBs of the AID value assigned to the mesh STA through the mesh peering
establishment. When the Beacon Timing element is received from a nonpeer mesh STA, the mesh STA
checks if the MSB of the Neighbor STA ID subfield is set to 1 and the rest of the field matches with the 7
LSBs of its own MAC address (taking the I/G bit as the MSB). If the matching is verified, the corresponding
beacon timing information represents the correct beacon reception by the neighbor mesh STA.
If a Beacon frame is received from a neighbor peer mesh STA that is either in active mode or in light sleep
mode, the Beacon Timing element is present in the frame, and all beacon timing information is contained in
the Beacon Timing element, the mesh STA shall verify whether the neighbor peer mesh STA received its
Beacon frame. If the Beacon Timing element does not contain beacon timing information of the mesh STA
or the Neighbor TBTT subfield of the corresponding beacon timing information does not reflect the recent
TBTT of the mesh STA, the mesh STA considers the previous Beacon frame was not received by the
neighbor peer mesh STA.
14.13.4.3 TBTT selection
When dot11MBCAActivated is true, the mesh STA performs the TBTT selection described herein before it
starts beaconing (see 14.2.8). The mesh STA selects its TBTTs and its beacon interval so that its Beacon
frames do not collide with Beacon frames transmitted by other STAs in its 2 hop range.
Before the mesh STA starts beaconing, it performs scanning and discovered neighbor STAs are reported
through an MLME-SCAN.confirm primitive (see 14.2.6). Using TimeStamp, Local Time, and Beacon
Period in the BSSDescriptionSet parameter provided by the MLME-SCAN.confirm primitive, the mesh
STA shall obtain the TBTT and beacon interval of its neighbor STAs operating on the same channel as the
mesh STA starts to operate. The mesh STA shall also collect the beacon timing information contained in the
Beacon Timing elements received on the channel through Beacon Timing in the BSSDescriptionSet
parameter provided by the MLME-SCAN.confirm primitive, in order to obtain the TBTT and beacon
interval of STAs in 2 hop range. After obtaining this information, the mesh STA shall look for a timing of its
beacon transmissions so that its Beacon frames are likely not to collide with Beacon frames transmitted by
other STAs in its 2 hop range. The mesh STA shall update its TSF timer and select its beacon interval to set
its TBTTs to the appropriate timing, and then it shall start beaconing using the MLME-START.request
primitive.
14.13.4.4 TBTT adjustment
14.13.4.4.1 Self-determined TBTT adjustment
When dot11MBCAActivated is true, the mesh STA checks if it does not transmit Beacon frames during the
beacon transmissions of other STAs within its 2 hop range using the Beacon Timing element received from
its neighbor peer mesh STA.
2212
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When the mesh STA discovers that its Beacon frames repeatedly collide with the Beacon frames of a
neighbor or a neighbor’s neighbor and its TBTT comes later than the TBTT of the colliding STA at the time
of collision, it shall perform the TBTT scanning procedure described in 14.13.4.4.3. If the mesh STA finds
an alternative TBTT, it shall start the TBTT adjustment procedure as described in 14.13.4.4.3.
14.13.4.4.2 Requested TBTT adjustment
When a mesh STA discovers that Beacon frames from two or more neighbor STAs are colliding repeatedly
or a series of TBTTs are close enough to trigger frequent beacon collisions, the mesh STA may transmit a
TBTT Adjustment Request frame to the neighbor mesh STA of which the TBTT comes last at a particular
collision timing in order to request this neighbor mesh STA to adjust its TBTT. The TBTT Adjustment
Request frame may be transmitted only if the following conditions hold:
— The recipient of the TBTT Adjustment Request frame is a peer mesh STA and has set the MBCA
Enabled subfield in the Mesh Capability field of the Mesh Configuration element to 1.
— The other colliding STA does not include the Mesh Configuration element in its Beacon frames or
the TBTT Adjusting field in the Mesh Configuration element is 0.
When dot11MBCAActivated is true, the mesh STA that receives a TBTT Adjustment Request frame shall
perform the TBTT scanning procedure described in 14.13.4.4.3, and determine if it can find an appropriate
alternative timing for its TBTTs. After the completion of the TBTT scanning procedure, the mesh STA that
receives the TBTT Adjustment Request frame shall respond with a TBTT Adjustment Response frame
containing the result of the TBTT scanning in the Status Code field. If the mesh STA finds an alternative
TBTT, it shall agree with the request. If it agrees with the request, the Status Code field is set to SUCCESS
in the TBTT Adjustment Response frame, and it shall complete the TBTT adjustment procedure described
in 14.13.4.4.3. If it does not agree with the request, it shall indicate the reason in the Status Code field in the
TBTT Adjustment Response frame. A mesh STA may set the Status Code to either SUCCESS,
REFUSED_REASON_UNSPECIFIED, or CANNOT_FIND_ALTERNATIVE_TBTT in the TBTT
Adjustment Response frame.
14.13.4.4.3 TBTT scanning and adjustment procedures
When a mesh STA is in need of TBTT adjustment, it tries to find an alternative TBTT first. The mesh STA
shall perform the TBTT scanning procedure as follows:
— The mesh STA checks if its beacon timing information and collected neighbor’s beacon timing
information are sufficiently new. If the mesh STA did not receive a Beacon frame from a neighbor
STA with which it maintains synchronization at the latest TBTT, it shall receive a Beacon or Probe
Response frame from the neighbor STA and obtain the TBTT of the neighbor STA and the beacon
timing information contained in the Beacon Timing element.
NOTE—This is particularly important if the mesh STA is in deep sleep mode for a neighbor peer mesh STA.
— Using the latest TBTT of its neighbor STAs and the latest beacon timing information of neighbor
mesh STAs, the mesh STA shall look for an alternative TBTT that does not cause beacon collision
among the STAs in its 2 hop range.
If an alternative TBTT is not available, the mesh STA terminates the procedure. If an alternative TBTT is
available, the mesh STA shall start the TBTT adjustment procedure as follows:
— The mesh STA shall set the TBTT Adjusting field in the Mesh Configuration element to 1 in order
to announce that the TBTT adjustment procedure is ongoing.
— The mesh STA shall suspend its TSF timer for a period of time, no longer than half of the Group
Delivery Idle Time (defined in 14.14.5) within a single beacon period, to slow its TSF.
— The mesh STA shall adjust TBTT information of the neighbor STAs (see 14.13.4.2.3), that are to be
contained in the Beacon Timing element, accordingly by subtracting the delay amount.
2213
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— When dot11MCCAActivated is true, the mesh STA shall adjust the MCCAOP reservations
accordingly by modifying the MCCAOP Offset of each MCCAOP reservation. See 10.23.3.3.
— The mesh STA shall repeat suspending its TSF timer over multiple beacon periods until its TBTT is
set to the alternative TBTT.
— Upon completion of the TBTT adjustment, the mesh STA shall update the status number as
described in 14.13.4.2.4 and shall set the TBTT Adjusting field in the Mesh Configuration element
to 0.
NOTE—A mesh STA in deep sleep mode might interpret its neighbor mesh STA’s TBTT adjustment as a large
TSF jitter. When a mesh STA in deep sleep mode observes a large TSF jitter and the Status Number in the
Report Control field in the Beacon Timing element of the received Beacon frame (or Probe Response frame)
has been updated, the mesh STA in deep sleep mode should not take this jitter as clock drift and listen to the
next Beacon frame to verify if the clock drift is large.
14.13.4.5 Frame transmission across reported TBTT
When dot11MBCAActivated is true, the mesh STA should not extend its transmissions across TBTT of its
neighbor STAs with which it maintains synchronization. Further, the mesh STA should not extend its
transmissions, other than Beacon frames, across all essential beacon reception timing (see 14.13.4.2.6)
reported from its neighbor mesh STAs with which it maintains synchronization. This operation helps in
reducing the hidden STA interference with beacon reception at its neighbor mesh STAs. When both
dot11MBCAActivated and dot11MCCAActivated are true, the mesh STA shall not extend its transmissions
across TBTT of its neighbor STAs with which it maintains synchronization. Further, the mesh STA shall not
extend its transmissions, other than Beacon frames, across all beacon reception timing reported from its
neighbor mesh STAs with which it maintains synchronization.
After silencing for dot11MeshAverageBeaconFrameDuration µs from the reported neighbor’s TBTT, the
mesh STA may start transmitting frames again.
14.13.4.6 Delayed beacon transmissions
A mesh STA may occasionally delay its Beacon frame transmission from its TBTT for a pseudorandom
time. This attribute is specified by dot11MeshDelayedBeaconTxInterval,
dot11MeshDelayedBeaconTxMinDelay, and dot11MeshDelayedBeaconTxMaxDelay. When
dot11MeshDelayedBeaconTxInterval is set to nonzero value, the mesh STA shall delay its Beacon frame
transmission from TBTT, once every dot11MeshDelayedBeaconTxInterval. When the mesh STA transmits a
Beacon frame with delay from its TBTT, the delay time shall be randomly selected between
dot11MeshDelayedBeaconTxMinDelay and dot11MeshDelayedBeaconTxMaxDelay µs.
NOTE—Delayed beacon transmission allows mesh STAs to discover Beacon frames that are transmitted from multiple
mesh STAs with TBTTs close to each other. It is recommended to set dot11MeshDelayedBeaconTxMaxDelay to a time
longer than the typical duration of Beacon frames.
14.14 Power save in a mesh BSS
14.14.1 General
A mesh STA may use mesh power management modes to reduce its power consumption. A mesh STA
manages each of its mesh peerings with a peer-specific mesh power management mode as described in
14.14.2.2. A mesh STA may set the mesh power management mode for a mesh peering independently of the
mesh power management modes for its other mesh peerings. A mesh STA also manages a nonpeer mesh
power management mode as described in 14.14.2.3. When a mesh STA is in light sleep mode or in deep
sleep mode for a mesh peering, the mesh STA shall maintain its mesh awake window as described in
14.14.6.
2214
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A mesh STA shall have the capability to buffer frames and to perform mesh power management mode
tracking for the peer-specific mesh power management modes of its peer mesh STAs, as described in
14.14.7. A mesh STA shall use mesh peer service periods for individually addressed frame transmissions to
neighbor peer mesh STAs that are either in light sleep mode or in deep sleep mode toward this mesh STA, as
described in 14.14.9. A mesh STA transmits group addressed frames after the Beacon frame containing
DTIM when any of its peer mesh STAs is in light sleep mode or deep sleep mode for the mesh peering with
the mesh STA (see 14.14.4 and 14.14.5). These capabilities are referred to as support for power save.
14.14.2 Mesh power management modes
14.14.2.1 General
The manner in which a mesh STA transitions between power states is determined by its peer-specific mesh
power management modes and its nonpeer mesh power management mode. A mesh STA shall be in awake
state if any of the conditions specified in 14.14.8.6 is not fulfilled. A mesh STA maintains peer-specific
mesh power management modes for each of its mesh peerings as described in 14.14.2.2. A mesh STA may
have a different peer-specific mesh power management mode for each mesh peering. A mesh STA maintains
a nonpeer mesh power management mode for nonpeer mesh STAs that is described in 14.14.2.3. An
example illustration of the use of peer specific and nonpeer mesh power management modes is shown in
Figure 14-5.
Mesh STA A is in Mesh STA B is
active mode in light sleep
towards mesh mode towards
STA B mesh STA A mesh STA B
mesh STA A
Mesh STA B is in deep sleep
Mesh STA A is in active mode
mode towards nonpeer mesh
towards nonpeer mesh STAs
STAs
Mesh STA A is in Mesh STA B is in
active mode towards deep sleep mode
mesh STA C towards mesh STA C
Mesh STA C is in deep mesh STA C Mesh STA C is in deep
sleep mode towards sleep mode towards
Mesh STA C is in deep sleep
mesh STA A mesh STA B
mode towards nonpeer mesh
STAs
Figure 14-5—Example of mesh power management mode usage
14.14.2.2 Peer-specific mesh power management modes
The peer-specific mesh power management mode specifies the activity level of the mesh STA for the
corresponding mesh peering. Three mesh power management modes are defined: active mode, light sleep
mode, and deep sleep mode. The peer-specific mesh power management modes are defined as follows:
— Active mode: The mesh STA shall be in awake state all the time.
— Light sleep mode: The mesh STA alternates between awake state and doze state, as specified in
14.14.8.4. The mesh STA shall listen to all of the Beacon frames from the corresponding peer mesh
STA.
2215
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— Deep sleep mode: The mesh STA alternates between awake state and doze state, as specified in
14.14.8.5. The mesh STA may choose not to listen to the Beacon frames from the corresponding
peer mesh STA.
The combination of the Power Management subfield in the Frame Control field and the Mesh Power Save
Level subfield in the QoS Control field contained in mesh Data frames indicates the peer-specific mesh
power management mode as shown in the Table 14-31.
Table 14-31—Peer-specific mesh power management mode definition
Peer-specific mesh
Power Management Mesh Power Save Level
Activity level power management
subfield subfield
mode
Highest Active mode 0 Reserved
Light sleep mode 1 0
Deep sleep mode 1 1
Lowest
14.14.2.3 Nonpeer mesh power management modes
The nonpeer mesh power management mode indicates the mesh power management mode of the mesh STA
toward the nonpeer mesh STAs. Two nonpeer mesh power management modes are defined: active mode and
deep sleep mode. The nonpeer mesh power management mode is indicated by the Power Management
subfield in the Frame Control field in group addressed frames, Management frames transmitted to nonpeer
neighbor STAs, and in Probe Response frames. When the Power Management subfield in the Frame Control
field is set to 1, the nonpeer mesh power management mode is deep sleep mode. When the Power
Management subfield in the Frame Control field is set to 0, the nonpeer mesh power management mode is
active mode.
A mesh STA may send Probe Request and Mesh Peering Open Request frames to a nonpeer mesh STA that
sets its nonpeer mesh power management mode to deep sleep mode only during the mesh awake window of
the mesh STA.
14.14.3 Mesh power management mode indications and transitions
14.14.3.1 General
When a mesh STA is in active mode for a mesh peering, it shall set the Power Management subfield in the
Frame Control field to 0 in all individually addressed Mesh Data or QoS Null frames transmitted to the
corresponding peer mesh STA.
When a mesh STA is in light sleep mode for a mesh peering, it shall set the Power Management subfield in
the Frame Control field to 1 and the Mesh Power Save Level subfield in the QoS Control field to 0 in all
individually addressed Mesh Data or QoS Null frames transmitted to the corresponding peer mesh STA.
When a mesh STA is in deep sleep mode for a mesh peering, it shall set the Power Management subfield in
the Frame Control field to 1 and the Mesh Power Save Level subfield in the QoS Control field to 1 in all
individually addressed Mesh Data or QoS Null frames transmitted to the corresponding mesh STA.
2216
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When a mesh STA is in deep sleep mode for any of its mesh peerings, the Mesh Power Save Level subfield
in the QoS Control field in group addressed mesh Data frames and the Mesh Power Save Level subfield in
the Mesh Capability field in the Mesh Configuration element shall be set to 1. When a mesh STA is not in
deep sleep mode for any of its mesh peerings, these subfields shall be set to 0.
To change peer-specific mesh power management modes, a mesh STA shall inform its peer mesh STAs
through a successful frame exchange initiated by the mesh STA. The Power Management subfield in the
Frame Control field and the Mesh Power Save Level subfield in the QoS Control field of the frame sent by
the mesh STA in this exchange indicates the peer-specific mesh power management mode that the STA shall
adopt upon successful completion of the entire frame exchange.
The algorithm to trigger the change of a peer-specific mesh power management mode is beyond the scope of
this standard.
The nonpeer mesh power management mode is determined by the peer-specific mesh power management
modes of the mesh STA. When a mesh STA is in light sleep mode or deep sleep mode for at least one mesh
peering, it shall set the nonpeer mesh power management mode to deep sleep mode.
When a mesh STA is in active mode for nonpeer STAs, it shall set the Power Management subfield in the
Frame Control field to 0 in group addressed frames, in Management frames transmitted to nonpeer mesh
STAs, and in Probe Response frames.
When a mesh STA is in deep sleep mode for nonpeer STAs, it shall set the Power Management subfield in
the Frame Control field to 1 in group addressed frames, in Management frames transmitted to nonpeer mesh
STAs, and in Probe Response frames.
14.14.3.2 Transition to a higher activity level
A mesh STA may use group addressed or individually addressed Mesh Data or QoS Null frames to change
its mesh power management mode to a higher activity level, for example; from deep sleep to light sleep or to
active mode; or from light sleep to active mode.
Individually addressed frames may be used to temporarily raise the activity level of the mesh STA for a
mesh peering.
NOTE—This is useful in cases when a link temporarily requires efficient data transmission with the peer mesh STA and
the mesh STA is attempting to transit back to lower activity level without performing the mesh power management
mode transition signaling with all peer mesh STAs.
14.14.3.3 Transition to a lower activity level
A mesh STA shall use acknowledged individually addressed Mesh Data or QoS Null frames to change its
peer-specific mesh power management mode to a lower activity level, for example; from active mode to
light or deep sleep mode; or from light sleep to deep sleep mode.
14.14.4 TIM transmissions in an MBSS
The TIM element identifies the peer mesh STAs for which traffic is pending and buffered in the reporting
mesh STA. This information is coded in a partial virtual bitmap, as described in 9.4.2.6. In addition, the TIM
contains an indication whether group addressed traffic is pending. Every neighbor peer mesh STA is
assigned an AID by the reporting mesh STA as part of the mesh peering establishment process (see 14.3.1).
The mesh STA shall identify those peer mesh STAs for which it is prepared to deliver47 buffered MSDUs
and MMPDUs by setting bits in the TIM’s partial virtual bitmap that correspond to the appropriate AIDs.
47
How the AP or mesh STA determines the traffic is prepared to deliver is outside the scope of this standard.
2217
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
14.14.5 TIM types
There are two different TIM types: TIM and DTIM. A mesh STA shall transmit a TIM with every Beacon
frame. Every DTIMPeriod, a TIM of type DTIM is transmitted with a Beacon frame. After transmitting a
Beacon frame containing a DTIM, the mesh STA shall send the buffered group addressed MSDUs and
MMPDUs, before transmitting any individually addressed frames. The More Data subfield of each group
addressed frame shall be set to indicate the presence of further buffered group addressed MSDUs and
MMPDUs. The mesh STA sets the More Data subfield to 0 in the last transmitted group addressed frame
following the transmission of the DTIM Beacon frame.
While waiting to receive a group addressed frame that was previously indicated in a TIM element or More
Data subfield, a mesh STA that detects CCA is IDLE for the duration of the PHY specific Group Delivery
Idle Time may assume that no more frames destined to group addresses will be transmitted and may return
to doze state. The Group Delivery Idle Time is identical to the TXOP limit for AC_VI specified by the
default EDCA Parameter Set shown in Table 9-137.
14.14.6 Mesh awake window
A mesh STA shall be in awake state when its mesh awake window is active. A mesh awake window is active
after the Beacon and Probe Response frames containing the Mesh Awake Window element. A mesh STA
shall include the Mesh Awake Window element in its DTIM Beacon frames and may include the Mesh
Awake Window element in its TIM Beacon and Probe Response frames. A mesh STA that operates in light
sleep mode or deep sleep mode for any of its mesh peerings shall include the Mesh Awake Window element
in its Beacon frame if the Beacon frame indicates buffered traffic for at least one peer mesh STA. The start
of the mesh awake window is measured from the end of the Beacon or Probe Response frame transmission.
The duration of the mesh awake window period is specified by dot11MeshAwakeWindowDuration. A mesh
STA shall set the Mesh Awake Window field in the Mesh Awake Window element to
dot11MeshAwakeWindowDuration. If the Mesh Awake Window element is not contained in the Beacon
frame of a mesh STA, the duration of the mesh awake window period following this beacon is zero.
If the mesh STA that has its mesh awake window active transmits frames destined to group addresses, the
duration of the mesh awake window is extended by an additional PostAwakeDuration. The
PostAwakeDuration follows the group address frame, and the mesh STA that has its mesh awake window
active shall stay in awake state until it has transmitted all of its group addressed frames and the
PostAwakeDuration has expired. The PostAwakeDuration is equal to duration of the mesh awake window.
A mesh STA may send a frame to a peer mesh STA that is in light sleep mode or deep sleep mode for the
corresponding mesh peering during the mesh awake window of this peer mesh STA. When a peer trigger
frame is successfully transmitted it initiates a mesh peer service period as described in 14.14.9.
A mesh STA may send Class 1 or Class 2 frames, such as Probe Request or Mesh Peering Open frames, to a
nonpeer mesh STA that is in deep sleep mode for nonpeer mesh STAs during the mesh awake window of this
nonpeer mesh STA.
14.14.7 Power save support
As described in 14.14.2, a mesh STA indicates its peer-specific mesh power management modes and
performs mesh power management mode tracking of the peer-specific mesh power management modes of
its peer mesh STAs. A mesh STA shall not arbitrarily transmit frames to mesh STAs operating in a light or
deep sleep mode, but shall buffer frames and only transmit them at designated times.
A mesh STA may transmit frames to a mesh STA operating in a light or deep sleep mode if the recipient
mesh STA is in the awake state as defined in 14.14.8.4, 14.14.8.5, and 14.14.9; otherwise, the mesh STA
shall not transmit frames and shall buffer frames.
2218
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
As described in 14.14.4, a mesh STA indicates the presence of buffered traffic in TIM elements for all peer
mesh STAs that operate in light or deep sleep mode toward the mesh STA. The mesh STA sets the bit for
AID 0 (zero) in the Bitmap Control field of the TIM element to 1 when group addressed traffic is buffered,
according to 9.4.2.6. As described in 14.14.5, a mesh STA transmits its group addressed frames after its
DTIM beacon if any of its peer mesh STA is in light or deep sleep mode toward the mesh STA.
As described in 14.14.9, mesh peer service periods are used for frame transmissions toward a mesh STA that
operates in light or deep sleep mode. Mesh peer service periods are not used in frame exchanges toward
active mode mesh STAs.
A mesh STA may initiate a mesh peer service period with a peer mesh STA in deep or light sleep mode by
transmitting a peer trigger frame when the mesh awake window of the peer mesh STA is active.
14.14.8 Operation in peer-specific and nonpeer mesh power management modes
14.14.8.1 General
Detailed operations of mesh STA in each mesh power management mode are described in the following
subclauses. Figure 14-6 depicts example power state transitions of mesh STAs, when three mesh STAs are in
the mesh power management modes shown in the Figure 14-5.
DTIM interval of mesh STA A
Beacon interval
of mesh STA A
TIM (in Beacon) DTIM TIM TIM TIM DTIM TIM
mesh
STA A
Data
DTIM interval (= Beacon interval)
Trigger
of mesh STA B
Ack
DTIM (in Beacon) DTIM
Activity
mesh
STA B Mesh Mesh
awake awake
Data
window window
DTIM interval (= Beacon interval)
Ack
of mesh STA C
Activity DTIM DTIM
mesh
STA C Mesh Mesh
awake awake
window window
Figure 14-6—Mesh power management operation
14.14.8.2 Operation in active mode
When a mesh STA is in active mode for a mesh peering or for nonpeer mesh STAs, it shall be in awake state.
Mesh peer service periods are not used in frame exchanges toward mesh STAs that are in active mode.
An active mode mesh STA may receive peer trigger frames from a peer mesh STA in light or deep sleep
mode when there is no mesh peer service period ongoing between the peer mesh STAs.
14.14.8.3 Operation in deep sleep mode for nonpeer mesh STAs
If a mesh STA is in deep sleep mode for nonpeer mesh STAs, it shall enter the awake state prior to every
TBTT of its own and shall remain in awake state after the beacon transmission for the duration of the mesh
2219
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
awake window and the duration of its group addressed frame transmissions. The mesh STA may receive
frames during its mesh awake window as described in 14.14.6.
When receiving a frame initiating a mesh peering management procedure, an authentication procedure, or a
passive scanning procedure, a mesh STA in deep sleep mode for nonpeer mesh STAs shall operate in awake
state at least until the completion of the mesh peering management procedure (see 14.3 and 14.5), until the
completion of the authentication procedure (see 14.3.1 and 14.3.3), or the transmission of the Probe
Response frame.
If a mesh STA receives a peer trigger frame initiating a mesh peer service period from a peer mesh STA, the
mesh STA shall remain in awake state until the mesh peer service period is terminated as defined in
14.14.9.4.
A mesh STA may return to doze state after its mesh awake window if no frame initiating a response
transaction or a mesh peer service period is received during the mesh awake window.
14.14.8.4 Operation in light sleep mode for a mesh peering
If a mesh STA is in light sleep mode for a mesh peering, it shall enter the awake state prior to every TBTT of
the corresponding peer mesh STA to receive the Beacon frame from the peer mesh STA. The mesh STA may
return to the doze state after the beacon reception from this peer mesh STA, if the peer mesh STA did not
indicate buffered individually addressed or group addressed frames. If an indication of buffered individually
addressed frames is received, the light sleep mode mesh STA shall send a peer trigger frame with the RSPI
field set to 1 to initiate a mesh peer service period with the mesh STA that transmitted the Beacon frame (see
14.14.9.2). If an indication of buffered group addressed frames is received, the light sleep mode mesh STA
shall remain in awake state after the DTIM Beacon reception to receive group addressed frames The mesh
STA shall remain awake state until the More Data subfield of a received group addressed frame is set to 0 or
if no group addressed frame is received within the PHY specific Group Delivery Idle Time. (See 14.14.5.)
NOTE—When a mesh STA is in light sleep mode for a mesh peering, it sets its nonpeer mesh power management mode
to deep sleep mode. This implies that a mesh STA operating in light sleep mode a mesh peering is required to comply
with the rules described in 14.14.8.3.
14.14.8.5 Operation in deep sleep mode for a mesh peering
A mesh STA operating in deep sleep mode for a mesh peering might not receive Beacon frames from the
corresponding peer mesh STA. The logic of how the mesh STA in deep sleep mode maintains
synchronization among neighbors is beyond the scope of this standard. Guidance for the synchronization
maintenance by the mesh STA in deep sleep mode is given in S.3.6.
NOTE—When a mesh STA is in deep sleep mode for a mesh peering, it sets its nonpeer mesh power management mode
to deep sleep mode. This implies that a mesh STA operating in deep sleep mode for a mesh peering is required to comply
with the rules described in 14.14.8.3.
14.14.8.6 Conditions for doze state
A mesh STA may enter doze state if all of the following conditions are fulfilled:
— The mesh STA operates in light sleep mode or deep sleep mode for all of its mesh peerings, as
described in 14.14.8.4 or 14.14.8.5
— The mesh STA has no mesh peer service period ongoing, as described in 14.14.9
— The mesh STA has no pending transaction of mesh peering management, authentication, nor passive
scanning (see 14.14.8.3)
— The mesh awake window indicated by the mesh STA has expired, as described in 14.14.6
2220
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— The mesh STA has terminated its group addressed frames delivery sequence after its DTIM Beacon
frame, as described in 14.14.5
Guidance for using the power save in mesh BSS and default parameter values are given in S.3.
14.14.9 Mesh peer service periods
14.14.9.1 General
Mesh peer service periods are used for individually addressed frame exchanges between neighbor peer mesh
STAs in which at least one of the mesh STAs is in light or deep sleep mode for the corresponding mesh
peering. A mesh peer service period is a period of time during which one or more individually addressed
frames are transmitted between two peer mesh STAs. Within a mesh peer service period, a mesh STA may
obtain multiple TXOPs. A mesh peer service period is directional. One mesh STA is the owner of the mesh
peer service period. It obtains TXOPs in order to transmit Data frames or Management frames to the
recipient in the mesh peer service period. At the end of the frame transmissions, the owner of the mesh peer
service period terminates the mesh peer service period. The other mesh STA operates as the recipient of the
mesh peer service period and does not obtain TXOPs for transmitting Data frames or Management frames to
the owner of the mesh peer service period. A mesh STA may have multiple mesh peer service periods
concurrently toward multiple neighbor peer mesh STAs. At most, one mesh peer service period is set up in
each direction with each peer mesh STA.
A mesh peer service period is initiated by a peer trigger frame. A peer trigger frame may initiate two mesh
peer service periods. This enables both the transmitter and the receiver of the peer trigger frame to become
the owner of a mesh peer service period. An example mesh peer service period between two mesh STAs in
light or deep sleep mode is shown in Figure 14-7. The numbering on the left-hand-side describes the phase
of the operation: 1 indicates the Initiation phase, 2 indicates the data transmission phase, and 3 indicates the
termination phase of the mesh peer service period.
Mesh Data frame, RSPI=1, EOSP=0
1. Ack
Mesh Data frame, RSPI=0, EOSP=0
The mesh STA is the owner in
2. Ack the mesh peer service period
Mesh Data frame, RSPI=0, EOSP=1
The mesh STA is the recipient
3. Ack in the mesh peer service period
Mesh Data frame, RSPI=0, EOSP=1
Ack
mesh STA A mesh STA B
Figure 14-7—Mesh peer service period
14.14.9.2 Initiation of a mesh peer service period
A mesh Data frame or a QoS Null frame that requires acknowledgment are used as a peer trigger frame. The
RSPI and the EOSP subfields in the QoS Control field control the initiation of a mesh peer service period.
2221
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 14-32 lists how mesh peer service periods shall be initiated with different combinations of RSPI and
EOSP subfield values.
Table 14-32—Mesh peer service period triggering with RSPI and EOSP subfield combina-
tions in peer trigger frame
RSPI EOSP Mesh peer service period triggering
0 0 One mesh peer service period is initiated. The transmitter of the
trigger frame is the owner in the mesh peer service period.
0 1 No mesh peer service period is initiated.
1 0 Two mesh peer service periods are initiated. Both mesh STAs are
owners in a mesh peer service period.
1 1 One mesh peer service period is initiated. The receiver of the trigger
frame is the owner in the mesh peer service period.
Mesh peer service periods are not used in frame transmissions toward active mode mesh STAs.
The mesh peer service period may be initiated in the following cases:
— A mesh STA in light or deep sleep mode receives a peer trigger frame during its mesh awake
window as described in 14.14.6
— A mesh STA in active mode receives a peer trigger frame from the peer mesh STA in light or deep
sleep mode as described in 14.14.8.2
— A mesh STA receives a peer trigger frame from the peer mesh STA in light sleep mode as described
in 14.14.8.4
In addition, when a mesh STA uses MCCA with a neighbor peer mesh STA while in a light sleep mode for
the corresponding mesh peering, a scheduled service period begins at the each MCCAOP start time as
described in 14.14.10. A mesh STA in a light or deep sleep mode shall enter the awake state prior to the start
time of scheduled service period.
14.14.9.3 Operation during a mesh peer service period
During the mesh peer service period, the owner and the recipient of the mesh peer service period shall
operate in awake state. The mesh peer service period may contain one or more TXOPs.
Reverse direction grant (RDG) shall not be used when the receiver of the TXOP operates in light or deep
sleep mode for the link and there is no mesh peer service period ongoing toward the TXOP holder.
14.14.9.4 Termination of a mesh peer service period
The mesh peer service period is terminated after a successfully acknowledged QoS Null or mesh Data frame
with the EOSP subfield set to 1 from the owner of the mesh peer service period.
If the mesh STA does not receive an acknowledgment to a frame that requires an acknowledgment and that
is sent with the EOSP subfield set to 1, the mesh STA shall retransmit that frame at least once within the
same mesh peer service period, subject to applicable retry or lifetime limits. The maximum number of
retransmissions within the same mesh peer service period is the lesser of the Max Retry Limit and
dot11MeshSTAMissingAckRetryLimit.
2222
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—If an acknowledgment to the retransmission of this last frame in the same mesh peer service period is not
received, the mesh STA might use the next mesh peer service period to further retransmit that frame subject to the
applicable retry or lifetime limit.
14.14.10 MCCA use by power saving mesh STA
When dot11MCCAActivated is true and the mesh STA establishes MCCAOPs, the mesh STA shall be in
active mode or light sleep mode toward the neighbor peer mesh STAs with which it has established
MCCAOPs.
A scheduled mesh peer service period begins at the MCCAOP start time, if the MCCAOP responder
operates in light sleep mode for the MCCAOP owner. The MCCAOP owner is the owner of the scheduled
mesh peer service period. The MCCAOP responder is the recipient of the scheduled mesh peer service
period. Scheduled mesh peer service periods are not used if the MCCAOP responder is in active mode for
the MCCAOP owner.
The scheduled mesh peer service period continues until it is successfully terminated by the acknowledged
QoS Null or mesh Data frame with the EOSP subfield set to 1 from the owner of the mesh peer service
period to the recipient of the mesh peer service period as described in 14.14.9.
2223
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15. DSSS PHY specification for the 2.4 GHz band designated for ISM
applications
15.1 Overview
15.1.1 General
The PHY for the DSSS system is described in this clause. The RF LAN system is aimed for the 2.4 GHz
band designated for ISM applications.
The DSSS system provides a WLAN with both a 1 Mb/s and a 2 Mb/s data payload communication
capability. The DSSS system uses baseband modulations of differential binary phase shift keying (DBPSK)
and differential quadrature phase shift keying (DQPSK) to provide the 1 Mb/s and 2 Mb/s data rates,
respectively.
15.1.2 Scope
The PHY services provided to the IEEE 802.11 WLAN MAC by the 2.4 GHz DSSS system are described in
this clause. The DSSS PHY consists of the following protocol functions:
a) A function that defines a method of mapping the IEEE 802.11 MPDUs into a framing format
suitable for sending and receiving user data and management information between two or more
STAs.
b) A function that defines the characteristics of, and method of transmitting and receiving data through,
a WM between two or more STAs each using the DSSS system.
15.1.3 DSSS PHY functions
15.1.3.1 General
The 2.4 GHz DSSS PHY architecture is depicted in the reference model shown in Figure 4-19 (in 4.9). The
DSSS PHY contains two functional entities: the PHY function and the layer management function. Each of
these functions is described in detail in the following subclauses.
The DSSS PHY service shall be provided to the MAC through the PHY service primitives described in
Clause 8.
15.1.3.2 PLME
The PLME performs management of the local PHY functions in conjunction with the MLME.
15.1.4 Service specification method and notation
The models represented by figures and state diagrams are intended to be illustrations of functions provided.
It is important to distinguish between a model and a real implementation. The models are optimized for
simplicity and clarity of presentation, but do not necessarily reflect any particular implementation.
The service of a layer or sublayer is a set of capabilities that it offers to a user in the next-higher layer (or
sublayer). Abstract services are specified here by describing the service primitives and parameters that
characterize each service. This definition is independent of any particular implementation.
2224
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.2 DSSS PHY specific service parameter list
15.2.1 Introduction
The architecture of the IEEE 802.11 MAC is intended to be PHY independent. Some PHY implementations
require medium management state machines running in the MAC sublayer in order to meet certain PHY
requirements. These PHY-dependent MAC state machines reside in a sublayer defined as the MLME. In
certain PHY implementations, the MLME may need to interact with the PLME as part of the normal PHY
SAP primitives. These interactions are defined by the PLME parameter list currently defined in the PHY
service primitives as TXVECTOR and RXVECTOR. The list of these parameters, and the values they may
represent, are defined in the specific PHY specifications for each PHY. Subclause 15.2 addresses the
TXVECTOR and RXVECTOR for the DSSS PHY.
15.2.2 TXVECTOR parameters
15.2.2.1 General
The parameters in Table 15-1 are defined as part of the TXVECTOR parameter list in the PHY-
TXSTART.request primitive.
15.2.2.2 TXVECTOR LENGTH
The LENGTH parameter provided in the TXVECTOR is in octets and is converted to microseconds for
inclusion in the PHY LENGTH field.
15.2.2.3 TXVECTOR DATARATE
The DATARATE parameter describes the bit rate at which the PHY shall transmit the PSDU. Its value takes
any of the rates defined in Table 15-1.
Table 15-1—TXVECTOR parameters
Parameter Value
LENGTH 0 to 212 – 1
DATARATE 1, 2 Mb/s
SERVICE Null
TXPWR_LEVEL_IN- 1 to 8
DEX
TIME_OF_ false, true. When true, the MAC entity requests that the PHY entity measures and
DEPARTURE_ reports time of departure parameters corresponding to the time when the first frame
REQUESTED energy is sent by the transmitting port; when false, the MAC entity requests that the
PHY entity neither measures nor reports time of departure parameters.
TX_ANTENNA 1 to 256
15.2.2.4 TXVECTOR SERVICE
The SERVICE parameter shall be null.
2225
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.2.2.5 TXVECTOR TXPWR_LEVEL_INDEX
The allowed values for the TXPWR_LEVEL_INDEX parameter are in the range 1 to 8. This parameter is
used to indicate which of the available TxPowerLevel attributes defined in the MIB shall be used for the
current transmission.
15.2.2.6 TXVECTOR TIME_OF_DEPARTURE_REQUESTED
The allowed values are false or true. A parameter value of true indicates that the MAC sublayer is requesting
that the PHY entity provides measurement of when the first frame energy is sent by the transmitting port and
reporting within the PHY-TXSTART.confirm(TXSTATUS) primitive. A parameter value of false indicates
that the MAC sublayer is requesting that the PHY entity not provide time of departure measurement nor
reporting in the PHY-TXSTART.confirm(TXSTATUS) primitive.
15.2.2.7 TXVECTOR TX_ANTENNA
Selects the antenna used by the PHY for transmission (when diversity is disabled), in the range 1 to 256.
15.2.3 RXVECTOR parameters
15.2.3.1 General
The parameters listed in Table 15-2 are defined as part of the RXVECTOR parameter list in the PHY-
RXSTART.indication primitive.
Table 15-2—RXVECTOR parameters
Parameter Value
LENGTH 0 to 212 – 1
RSSI 0–255
SIGNAL 1, 2 Mb/s
SERVICE 1, 2 Mb/s
RCPI 0–255
(see NOTE)
SQ 0–255
RX_ANTENNA 1–256
RX_START_OF_FRAME_OFFSET 0 to 232– 1. An estimate of the offset (in 10 ns units) from the point in time
at which the start of the preamble corresponding to the incoming frame
arrived at the receive antenna connector to the point in time at which this
primitive is issued to the MAC.
NOTE—Parameter is present only when dot11RadioMeasurementActivated is true.
15.2.3.2 RXVECTOR LENGTH
The MPDU length in octets (calculated from the LENGTH field in microseconds).
2226
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.2.3.3 RXVECTOR RSSI
This parameter is a measure by the PHY of the energy observed at the antenna used to receive the current
PPDU. RSSI shall be measured during the reception of the PHY preamble. RSSI is intended to be used in a
relative manner, and it shall be a monotonically increasing function of the received power.
15.2.3.4 RXVECTOR SIGNAL
SIGNAL shall represent the data rate at which the current PPDU was received.
15.2.3.5 RXVECTOR SERVICE
The SERVICE parameter shall be null.
15.2.3.6 RXVECTOR RCPI
The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 9.4.2.38. This parameter
is a measure by the PHY of the received channel power. The performance requirements for the measurement
of RCPI are defined in 15.4.6.6.
15.2.3.7 RXVECTOR SQ
SQ provides to the MAC entity the signal quality of the DSSS PHY PN code correlation. The SQ shall be
sampled when the DSSS PHY achieves code lock and shall be held until the next code lock acquisition.
The SQ may be used in conjunction with RSSI as part of a CCA scheme.
15.2.3.8 RXVECTOR RX_ANTENNA
RX_ANTENNA reports the antenna used by the PHY for reception of the most recent packet.
15.2.4 TXSTATUS parameters
15.2.4.1 General
The parameters listed in Table 15-3 are defined as part of the TXSTATUS parameter list in the PHY-
TXSTART.confirm primitive.
15.2.4.2 TXSTATUS TIME_OF_DEPARTURE
The allowed values for the TIME_OF_DEPARTURE parameter are integers in the range 0 to 232- 1. This
parameter is used to indicate when the first frame energy is sent by the transmitting port in units equal to 1/
TIME_OF_DEPARTURE_ClockRate. TIME_OF_DEPARTURE may be included in the transmitted frame
in order for recipients on multiple channels to determine the time differences of air propagation times
between transmitter and recipients and hence to compute the location of the transmitter.
15.2.4.3 TXSTATUS TIME_OF_DEPARTURE_ClockRate
TIME_OF_DEPARTURE_ClockRate indicates the clock rate used for TIME_OF_DEPARTURE.
2227
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 15-3—TXSTATUS parameters
Parameter Value
TIME_OF_DEPARTURE 0 to 232– 1. The locally measured time when the first frame energy is
sent by the transmitting port, in units equal to
1/ TIME_OF_DEPARTURE_ClockRate. This parameter is present only
if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding
request.
TIME_OF_DEPARTURE_ClockRate 0 to 216– 1. The clock rate, in units of MHz, is used to generate the
TIME_OF_DEPARTURE value. This parameter is present only if
TIME_OF_DEPARTURE_REQUESTED is true in the corresponding
request.
TX_START_OF_FRAME_OFFSET 0 to 232– 1. An estimate of the offset (in 10 ns units) from the point in
time at which the start of the preamble corresponding to the frame was
transmitted at the transmit antenna connector to the point in time at
which this primitive is issued to the MAC.
15.3 DSSS PHY
15.3.1 Overview
Subclause 15.3 provides a convergence procedure in which MPDUs are converted to and from PPDUs.
During transmission, the MPDU shall be prepended with a PHY preamble and header to create the PPDU.
At the receiver, the PHY preamble and header are processed to aid in demodulation and delivery of the
MPDU.
15.3.2 PPDU format
Figure 15-1 shows the format for the PPDU including the DSSS PHY preamble, the DSSS PHY header, and
the MPDU. The PHY preamble contains the following fields: SYNC and SFD. The PHY header contains the
following fields: Signaling (SIGNAL), Service (SERVICE), length (LENGTH), and CRC-16 (CRC). Each
of these fields is described in detail in 15.3.3.
SYNC SFD SIGNAL SERVICE LENGTH CRC
128 bits 16 bits 8 bits 8 bits 16 bits 16 bits
PHY Preamble PHY Header
MPDU
144 bits 48 bits
PPDU
Figure 15-1—PPDU format
2228
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.3.3 PHY field definitions
15.3.3.1 General
The entire PHY preamble and header shall be transmitted using the 1 Mb/s DBPSK modulation described in
15.4.5. All transmitted bits shall be scrambled using the feedthrough scrambler described in 15.3.4.
15.3.3.2 PHY SYNC field
The SYNC field shall consist of 128 bits of scrambled 1s. This field shall be provided so that the receiver
can perform the necessary operations for synchronization.
15.3.3.3 PHY SFD
The SFD shall be provided to indicate the start of PHY-dependent parameters within the PHY preamble.
The SFD shall be a 16-bit field, X'F3A0' (MSB to LSB). The LSB shall be transmitted first in time.
15.3.3.4 PHY SIGNAL field
The 8-bit SIGNAL field indicates to the PHY the modulation that shall be used for transmission (and
reception) of the MPDU. The data rate shall be equal to the signal field value multiplied by 100 kb/s. The
DSSS PHY currently supports two mandatory modulation services given by the following 8-bit words,
where the LSB shall be transmitted first in time:
a) X'0A' (MSB to LSB) for 1 Mb/s DBPSK
b) X'14' (MSB to LSB) for 2 Mb/s DQPSK
The DSSS PHY rate change capability is described in 15.3.5. This field shall be protected by the CRC-16
FCS described in 15.3.3.7.
15.3.3.5 PHY SERVICE field
The 8-bit SERVICE field is reserved for future use; it shall be set to 0 on transmission and ignored on
reception. The LSB shall be transmitted first in time. This field shall be protected by the CRC-16 FCS
described in 15.3.3.7.
15.3.3.6 PHY LENGTH field
The PHY LENGTH field shall be an unsigned 16-bit integer that indicates the number of microseconds
required to transmit the MPDU. The transmitted value shall be determined from the LENGTH parameter in
the TXVECTOR issued with the PHY-TXSTART.request primitive described in 8.3.5.5. The LENGTH
field provided in the TXVECTOR is in octets and is converted to microseconds for inclusion in the PHY
LENGTH field. The LSB shall be transmitted first in time. This field shall be protected by the CRC-16 FCS
described in 15.3.3.7.
2229
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.3.3.7 PHY CRC field
The SIGNAL, SERVICE, and LENGTH fields shall be protected with a CRC-16 FCS. The CRC-16 FCS
shall be the 1s complement of the remainder generated by the modulo 2 division of the protected PHY fields
by the polynomial:
x16 + x12 + x5 + 1
The protected bits shall be processed in transmit order. All FCS calculations shall be made prior to data
scrambling.
As an example, the SIGNAL, SERVICE, and LENGTH fields for a DBPSK signal with a packet length of
192 µs (24 octets) would be given by the following:
0101 0000 0000 0000 0000 0011 0000 0000 (leftmost bit transmitted first in time)
The 1s complement FCS for these protected PHY preamble bits would be the following:
0101 1011 0101 0111 (leftmost bit transmitted first in time)
Figure 15-2 depicts this example.
1s
1s
1s
1s
Figure 15-2—CRC-16 implementation
2230
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An illustrative example of the CRC-16 FCS using the information from Figure 15-2 follows in Figure 15-3.
Data CRC registers
MSB LSB
1111111111111111 ; initialize preset to 1s
0 1110111111011111
1 1101111110111110
0 1010111101011101
1 0101111010111010
0 1011110101110100
0 0110101011001001
0 1101010110010010
0 1011101100000101
0 0110011000101011
0 1100110001010110
0 1000100010001101
0 0000000100111011
0 0000001001110110
0 0000010011101100
0 0000100111011000
0 0001001110110000
0 0010011101100000
0 0100111011000000
0 1001110110000000
0 0010101100100001
0 0101011001000010
0 1010110010000100
1 0101100100001000
1 1010001000110001
0 0101010001000011
0 1010100010000110
0 0100000100101101
0 1000001001011010
0 0001010010010101
0 0010100100101010
0 0101001001010100
0 1010010010101000
0101101101010111 ; 1s complement, result = CRC FCS parity
Figure 15-3—Example CRC calculation
15.3.4 PHY/DSSS PHY data scrambler and descrambler
The polynomial G(z) = z –7 + z –4 + 1 shall be used to scramble all bits transmitted by the DSSS PHY. The
feedthrough configuration of the scrambler and descrambler is self-synchronizing, which requires no prior
knowledge of the transmitter initialization of the scrambler for receive processing. Figure 15-4 and Figure 15-5
show typical implementations of the data scrambler and descrambler, but other implementations are possible.
The scrambler should be initialized to any state except all 1s when transmitting.
Figure 15-4—Data scrambler
2231
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 15-5—Data descrambler
15.3.5 PHY data modulation and modulation rate change
The PHY preamble shall be transmitted using the 1 Mb/s DBPSK modulation. The SIGNAL field shall
indicate the modulation that shall be used to transmit the MPDU. The transmitter and receiver shall initiate
the modulation indicated by the SIGNAL field starting with the first symbol (1 bit for DBPSK or 2 bits for
DQPSK) of the MPDU. The MPDU transmission rate shall be set by the DATARATE parameter in the
TXVECTOR issued with the PHY-TXSTART.request primitive described in 15.2.2.
15.3.6 Transmit PHY
The transmit PHY is shown in Figure 15-6.
PHY‐DATA. PHY‐TXEND.request
PHY‐TXSTART. PHY‐TXSTART.
request or length count met
MAC request confirm
(TXVECTOR) (TXSTATUS) (DATA) PHY‐TXEND.confirm
PHY SFD SFD Signal, Service, Length CRC MPDU
Scramble start CRC16 CRC16 Rate change start TX Power
TX Power RAMP start end RAMP Off
Figure 15-6—Transmit PHY
In order to transmit data, PHY-TXSTART.request primitive shall be issued so that the PHY entity shall be in
the transmit state. Further, the PHY shall be set to operate at the appropriate channel through STA
management via the PLME. Other transmit parameters such as DATARATE, TX antenna, and TX power
are set via the PHY SAP with the PHY-TXSTART.request(TXVECTOR) primitive as described in 15.2.2.
Based on the state of CCA indicated by the PHY-CCA.indication primitive, the MAC assesses that the
channel is clear. A clear channel shall be indicated by a PHY-CCA.indication(IDLE) primitive. If the channel
is clear, transmission of the PPDU shall be initiated by issuing the PHY-TXSTART.request(TXVECTOR)
primitive. The TXVECTOR elements for the PHY-TXSTART.request primitive are the PHY header
parameters SIGNAL (DATARATE), SERVICE, LENGTH, TX_ANTENNA, TXPWR_LEVEL_INDEX, and
TIME_OF_DEPARTURE_REQUESTED. The PHY header parameter LENGTH is calculated from the
TXVECTOR element by multiplying by 8 for 1 Mb/s and by 4 for 2 Mb/s.
The PHY is configured with the TXVECTOR elements TX_ANTENNA, DATARATE, and
TXPWR_LEVEL_INDEX. The PHY entity shall immediately initiate data scrambling and transmission of
2232
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the PHY preamble based on the parameters passed in the PHY-TXSTART.request primitive. The time
required for transmit power-on ramp described in 15.4.5.8 shall be included in the PHY SYNC field.
Once the PHY preamble transmission is complete, data shall be exchanged between the MAC and the PHY by
a series of PHY-DATA.request(DATA) primitives issued by the MAC and PHY-DATA.confirm primitives
issued by the PHY. The modulation rate change, if any, shall be initiated with the first data symbol of the
MPDU as described in 15.3.5. The PHY proceeds with MPDU transmission through a series of data octet
transfers from the MAC. Transmission can be prematurely terminated by the MAC through the PHY-
TXEND.request primitive. PHY-TXSTART shall be disabled by the issuance of the PHY-TXEND.request
primitive. Normal termination occurs after the transmission of the final bit of the last MPDU octet according to
the number supplied in the TXVECTOR LENGTH field. The packet transmission shall be completed and the
PHY entity shall enter the receive state (i.e., PHY-TXSTART shall be disabled). It is recommended that
chipping continue during power-down. Each PHY-TXEND.request primitive is acknowledged with a PHY-
TXEND.confirm primitive from the PHY.
A typical state machine implementation of the transmit PHY is provided in Figure 15-7.
PHY‐TXSTART.request(TXVECTOR)
Initialize
TX MPDU OCTET
PHY‐DATA.request
set Tx parameters (DATA)
get octet from MAC
set octet bit count
TX SYNC PATTERN TX SYMBOL
TX 128 scrambled 1s
PHY‐TXSTART.confirm
(TXSTATUS)
Decrement Bit
decrement bit count
TX HEADER by bits per symbol bit count 0
TX 16 bit SFD bit count = 0
TX 8 bit SIGNAL
Decrement Length
TX 8 bit SERVICE
TX 16 bit LENGTH decrement length length 0
TX 16 bit CRC count
length = 0
SETUP MPDU TX
Switch to RX STATE
set rate A
set length count
A At any stage in the above flow diagram, if a PHY‐TXEND.request primitive is received.
Figure 15-7—PHY transmit state machine
2233
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.3.7 Receive PHY
The receive PHY is shown in Figure 15-8.
PH Y‐RXEN D.indication
PH Y‐CCA .indication PH Y‐D ATA.indication(D ATA) (RXERRO R ,RXVECTO R )
(BU SY)
M AC PH Y‐RXSTART.indication(RXVECTO R) PH Y‐CCA .indication(ID LE)
PH Y SYN C SFD Signal, Service, Length CRC M PD U
D escram ble start CRC start CRC end Rate change start
Figure 15-8—Receive PHY
In order to receive data, PHY-TXSTART.request primitive shall be disabled so that the PHY entity is in the
receive state. Further, through STA management via the PLME, the PHY is set to the appropriate channel
and the CCA method is chosen. Other receive parameters such as RSSI, RCPI, signal quality (SQ), and
indicated DATARATE may be accessed via the PHY SAP.
Upon receiving the transmitted energy, according to the selected CCA mode, A PHY-
CCA.indication(BUSY) primitive shall be issued for energy detection (ED) and/or code lock prior to correct
reception of the PHY header. The PHY measures the RSSI and SQ and the parameters are reported to the
MAC in the RXVECTOR.
After a PHY-CCA.indication primitive is issued, the PHY entity shall begin searching for the SFD field.
Once the SFD field is detected, CRC-16 processing shall be initiated and the PHY SIGNAL, SERVICE and
LENGTH fields are received. The CRC-16 FCS shall be processed. If the CRC-16 FCS check fails, the PHY
receiver shall return to the RX IDLE state as depicted in Figure 15-9. Should the status of CCA return to the
IDLE state during reception prior to completion of the full PPDU processing, the PHY receiver shall return
to the RX IDLE state.
If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported),
a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued. If dot11TimingMsmtActivated is
true, the PHY shall do the following:
— Complete receiving the PHY header and verify the validity of the PHY Header.
— If the PHY header reception is successful (and the SIGNAL field is completely recognizable and
supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and
RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see
15.2.3).
NOTE—The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the
start of the preamble for the incoming frame was detected on the medium at the receive antenna connector.
The RXVECTOR associated with this primitive includes the SIGNAL field, the SERVICE field, the MPDU
length in octets (calculated from the LENGTH field in microseconds), the antenna used for receive
(RX_ANTENNA), RSSI, RCPI, and SQ.
The received MPDU bits are assembled into octets and presented to the MAC using a series of PHY-
DATA.indication(DATA) primitive exchanges. The rate change indicated in the SIGNAL field shall be
initiated with the first symbol of the MPDU as described in 15.3.5. The PHY proceeds with MPDU
2234
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
reception. After the reception of the final bit of the last MPDU octet, as indicated by the PHY preamble
LENGTH field, the receiver shall be returned to the RX IDLE state as shown in Figure 15-9. A PHY-
RXEND.indication(NoError) primitive shall be issued. A PHY-CCA.indication(IDLE) primitive shall be
issued following a change in PHY carrier sense (PHYCS) and/or PHY energy detection (PHYED) according
to the selected CCA method.
In the event that a change in PHYCS or PHYED would cause the status of CCA to return to the IDLE state
before the complete reception of the MPDU, as indicated by the PHY LENGTH field, the error condition
shall be reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive. The CCA of the
DSSS PHY shall indicate a busy medium for the intended duration of the transmitted packet.
If the PHY header is successful, but the indicated rate in the SIGNAL field is not receivable, a PHY-
RXSTART.indication primitive shall not be issued. The PHY shall indicate the error condition by issuing a
PHY-RXEND.indication(UnsupportedRate) primitive. If the PHY header is successful, but the SERVICE
field is out of IEEE 802.11 DSSS specification, a PHY-RXSTART.indication primitive shall not be issued.
The PHY shall indicate the error condition by issuing a PHY-RXEND.indication(FormatViolation)
primitive. Also, in both cases, the CCA of the DSSS PHY shall indicate a busy medium for the intended
duration of the transmitted frame as indicated by the LENGTH field. The intended duration is indicated by
the LENGTH field (length 1 µs).
Figure 15-9 shows the flow of a typical state machine implementation of the receive PHY.
15.4 DSSS PLME
15.4.1 PLME SAP sublayer management primitives
Table 15-4 lists the MIB attributes that may be accessed by the PHY entities and intralayer of higher level
LMEs. These attributes are accessed via the PLME-GET, PLME-SET, and PLME-RESET primitives
defined in Clause 6.
15.4.2 DSSS PHY MIB
All DSSS PHY MIB attributes are defined in Clause 8, with specific values defined in Table 15-4.
15.4.3 DSSS PHY
The static DSSS PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive,
are shown in Table 15-5. The definitions of these characteristics are in 6.5.4.
15.4.4 PHY operating specifications, general
15.4.4.1 General
Subclause 15.4.4 provides general specifications for the DSSS PHY sublayer. These specifications apply to
both the Receive and the Transmit functions and general operation of a DSSS PHY.
15.4.4.2 Operating frequency range
The DSSS PHY shall operate in the frequency range of 2.4 GHz to 2.4835 GHz as allocated by regulatory
bodies in the China, United States and Europe or in the 2.471 GHz to 2.497 GHz frequency band as
allocated by regulatory authority in Japan.
2235
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RX Idle State
perform CS/CCA
RX SYMBOL
PHY‐DATA.indication
Detect SFD pattern CCA(IDLE) CCA(BUSY)
Wait until SFD is Signal not valid Decrement length
PHY‐CCA. detected
indication PHY‐RXEND. decrement length
indication count by 1
length 0
(IDLE)
(carrier lost) microsecond
RX PHY Fields
Octet assimilation
PHY‐CCA. RX 8 bit SIGNAL
indication RX 8 bit SERVICE Increment bit count
(IDLE) set octet bit count
RX 16 bit LENGTH Wait for intended
end of MPDU PHY‐DATA.
indication (DATA)
PHY‐CCA.
indication
(IDLE) RX PHY CRC length = 0
or
CRC fail RX and Test CRC END OF MPDU RX
PHY‐CCA. PHY‐RXEND.
indication CRC correct
length = 0 indication
(IDLE) PHY‐CCA.
(No_Error)
VALIDATE PPDU indication (IDLE)
Decrement Length PHY‐CCA. indication
(IDLE)
decrement length Check PPDU
count PHY
Fields
out of
specification PPDU correct
SETUP MPDU RX
set Rate
set length count
set octet bit count
PHY‐
RXSTART.indication
(RXVECTOR)
Figure 15-9—PHY receive state machine
15.4.4.3 Channel Numbering of operating channels
When dot11OperatingClassesRequired is true, channel numbering shall be as specified in 17.3.8.4.2 and
channelization shall be as specified in 17.3.8.4.3. When dot11OperatingClassesDefined is false or not defined,
the channel center frequencies and CHNL_ID numbers shall be as shown in Table 15-6.
In a multiple cell network topology, overlapping and/or adjacent cells using different channels can operate
simultaneously without interference if the distance between the center frequencies is at least 30 MHz.
2236
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 15-4—MIB attribute default values/ranges
Operational
Managed object Default value/range
semantics
dot11PhyOperationComplianceGroup
dot11PHYType DSSS–2.4 (02) Static
dot11RegDomainsSupported Implementation dependent Static
dot11CurrentRegDomain Implementation dependent Static
dot11PhyRateGroup
dot11SupportedDataRatesTx X'02', X'04' Static
dot11SupportedDataRatesRx X'02', X'04' Static
dot11PhyAntennaComplianceGroup
dot11CurrentTxAntenna Implementation dependent Dynamic
dot11DiversitySupportImplemented Implementation dependent Static
dot11CurrentRxAntenna Implementation dependent Dynamic
dot11PhyTxPowerComplianceGroup
dot11NumberSupportedPowerLevelsImplemented Implementation dependent Static
dot11TxPowerLevel1 Implementation dependent Static
dot11TxPowerLevel2 Implementation dependent Static
dot11TxPowerLevel3 Implementation dependent Static
dot11TxPowerLevel4 Implementation dependent Static
dot11TxPowerLevel5 Implementation dependent Static
dot11TxPowerLevel6 Implementation dependent Static
dot11TxPowerLevel7 Implementation dependent Static
dot11TxPowerLevel8 Implementation dependent Static
dot11CurrentTxPowerLevel Implementation dependent Dynamic
dot11PhyDSSSComplianceGroup
dot11CurrentChannel Implementation dependent Dynamic
dot11CCAModeSupported Implementation dependent Static
dot11CurrentCCAMode Implementation dependent Dynamic
dot11EDThreshold Implementation dependent Dynamic
2237
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 15-4—MIB attribute default values/ranges (continued)
Operational
Managed object Default value/range
semantics
dot11AntennasListEntry
dot11TxAntennaImplemented Implementation dependent Static
dot11RxAntennaImplemented Implementation dependent Static
dot11DiversitySelectionRxImplemented Implementation dependent Dynamic
NOTE—The column titled “Operational semantics” contains two types: static and dynamic. Static MIB
attributes are fixed and cannot be modified for a given PHY implementation. MIB attributes defined as
dynamic can be modified by some management entities.
Table 15-5—DSSS PHY characteristics
Characteristic Value
aSlotTime If dot11OperatingClassesRequired is false, 20 µs
If dot11OperatingClassesRequired is true, 20 µs plus any coverage-class-depen-
dent aAirPropagationTime (see Table 9-79)
aSIFSTime 10 µs
aCCATime Implementation dependent, see 10.3.7.
aRxPHYStartDelay 192 µs
aRxTxTurnaroundTime Implementation dependent, see 10.3.7.
aTxPHYDelay Implementation dependent, see 10.3.7.
aRxPHYDelay Implementation dependent, see 10.3.7.
aRxTxSwitchTime Implementation dependent, see 10.3.7.
aTxRampOnTime Implementation dependent, see 10.3.7.
aAirPropagationTime As indicated by the coverage class (see 10.21.5).
aMACProcessingDelay Implementation dependent, see 10.3.7.
aPreambleLength 144 µs
aPHYHeaderLength 48 µs
aPSDUMaxLength 212 – 1 octets
aCWmin 31
aCWmax 1023
2238
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 15-6—DSSS PHY frequency channel plan
Frequency
CHNL_ID
(MHz)
1 2412
2 2417
3 2422
4 2427
5 2432
6 2437
7 2442
8 2447
9 2452
10 2457
11 2462
12 2467
13 2472
14 2484
15.4.4.4 Spreading sequence
The following 11-chip Barker sequence shall be used as the PN code sequence:
+1, –1, +1, +1, –1, +1, +1, +1, –1, –1, –1
The leftmost chip shall be output first in time. The first chip shall be aligned at the start of a transmitted
symbol. The symbol duration shall be exactly 11 chips long.
15.4.4.5 Modulation and channel data rates
Two modulation formats and data rates are specified for the DSSS PHY: a basic access rate and an
enhanced access rate. The basic access rate shall be based on 1 Mb/s DBPSK modulation. The DBPSK
encoder is specified in Table 15-7. The enhanced access rate shall be based on 2 Mb/s DQPSK. The DQPSK
encoder is specified in Table 15-8. (In the tables, +j shall be defined as counterclockwise rotation.)
Table 15-7—1 Mb/s DBPSK encoding table
Bit input Phase change (+j )
0 0
1
2239
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 15-8—2 Mb/s DQPSK encoding table
Dibit pattern (d0,d1)
Phase change (+j )
d0 is first in time
00 0
01 /2
11
10 3 /2 (– /2)
15.4.4.6 Transmit and receive in-band and out-of-band spurious emissions
The DSSS PHY shall comply with in-band and out-of-band spurious emissions as set by the appropriate
regulatory bodies.
15.4.4.7 TX-to-RX turnaround time
The TX-to-RX turnaround time shall be less than 10 µs, including the power-down ramp specified in
15.4.5.8.
The TX-to-RX turnaround time shall be measured on the WM from the trailing edge of the last transmitted
symbol to valid CCA detection of the incoming signal. The CCA should occur within 25 µs (10 µs for
turnaround time plus 15 µs for energy detect) or by the next slot boundary occurring after 25 µs has elapsed
(refer to 15.4.6.5). A receiver input signal 3 dB above the ED threshold described in 15.4.6.5 shall be present
at the receiver.
15.4.4.8 RX-to-TX turnaround time
The RX-to-TX turnaround time shall be measured at the MAC/PHY interface, using the PHY-
TXSTART.request primitive and shall be 5 µs. This includes the transmit power-on ramp described in
15.4.5.8.
15.4.4.9 Slot time
The value of the slot time is found in Table 15-5.
15.4.4.10 Transmit and receive antenna connector impedance
The impedance at the transmit and receive antenna connector(s) shall be 50 if the connector is exposed.
15.4.5 PHY transmit specifications
15.4.5.1 Introduction
The transmit functions and parameters associated with the PHY sublayer are described in 15.4.5.2 to
15.4.5.10.
15.4.5.2 Transmit power levels
The maximum allowable output power is measured in accordance with practices specified by the appropriate
regulatory bodies.
2240
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.4.5.3 Minimum transmitted power level
The minimum transmitted power shall be no less than 1 mW.
15.4.5.4 Transmit power level control
Power control shall be provided for transmitted power greater than 100 mW. A maximum of four power
levels may be provided. At a minimum, a radio capable of transmission greater than 100 mW shall be
capable of switching power back to 100 mW or less.
15.4.5.5 Transmit spectrum mask
The transmitted spectral products shall be less than –30 dBr (decibel relative to the SINx/x peak) for fc – 22
MHz < f < fc –11 MHz, fc +11 MHz < f < fc + 22 MHz, –50 dBr for f < fc –22 MHz, and f > fc + 22 MHz,
where fc is the channel center frequency. The transmit spectral mask is shown in Figure 15-10. The
measurements shall be made using 100 kHz resolution bandwidth and a 30 kHz video bandwidth.
Figure 15-10—Transmit spectrum mask
Channel 14 is unique. The Japanese standard ARIB RCR-STD 33 (5.0) [B7] states that B90/2 normalized
to the ‘transmission speed of modulation signal’ shall be > 10, where B90 is the 90% occupied channel
bandwidth. Therefore, for channel 14, B90/2 > 13.75 MHz for CCK spreading and >10.0 MHz for Barker
spreading.
15.4.5.6 Transmit center frequency tolerance
The transmitted center frequency tolerance shall be ±25 ppm maximum.
15.4.5.7 Chip clock frequency tolerance
The PN code chip clock frequency tolerance shall be ±25 ppm maximum.
15.4.5.8 Transmit power-on and power-down ramp
The transmit power-on ramp for 10% to 90% of maximum power shall be no greater than 2 µs. The transmit
power-on ramp is shown in Figure 15-11.
2241
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 15-11—Transmit power-on ramp
The transmit power-down ramp for 90% to 10% maximum power shall be no greater than 2 µs. The transmit
power-down ramp is shown in Figure 15-12.
Figure 15-12—Transmit power-down ramp
The transmit power ramps shall be constructed such that the DSSS PHY emissions comply with the spurious
frequency product specification defined in 15.4.4.6.
15.4.5.9 RF carrier suppression
The RF carrier suppression, measured at the channel center frequency, shall be at least 15 dB below the peak
sin(x)/x power spectrum. The RF carrier suppression shall be measured while transmitting a repetitive 01
data sequence with the scrambler disabled using DQPSK modulation. A 100 kHz resolution bandwidth shall
be used to perform this measurement.
2242
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.4.5.10 Transmit modulation accuracy
The transmit modulation accuracy requirement for the DSSS PHY shall be based on the difference between the
actual transmitted waveform and the ideal signal waveform. Modulation accuracy shall be determined by
measuring the peak vector error magnitude measured during each chip period. Worst-case vector error
magnitude shall not exceed 0.35 for the normalized sampled chip data. The ideal complex I and Q constellation
points associated with DQPSK modulation (0.707, 0.707), (0.707, –0.707), (–0.707, 0.707), (–0.707, –0.707)
shall be used as the reference. These measurements shall be from baseband I and Q sampled data after recovery
through a reference receiver system.
Figure 15-13 illustrates the ideal DQPSK constellation points and range of worst-case error specified for
modulation accuracy.
Figure 15-13—Modulation accuracy measurement example
Error vector measurement requires a reference receiver capable of carrier lock. All measurements shall be
made under carrier lock conditions. The distortion induced in the constellation by the reference receiver
shall be calibrated and measured. The test data error vectors described below shall be corrected to
compensate for the reference receiver distortion.
The IEEE 802.11 vendor compatible radio shall provide an exposed TX chip clock, which shall be used to
sample the I and Q outputs of the reference receiver.
The measurement shall be made under the conditions of continuous DQPSK transmission using scrambled
all 1s.
The eye pattern of the I channel shall be used to determine the I and Q sampling point. The chip clock
provided by the vendor radio shall be time delayed such that the samples fall at a 1/2 chip period offset from
the mean of the zero crossing positions of the eye (see Figure 15-14). This is the ideal center of the eye and
might not be the point of maximum eye opening.
2243
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 15-14—Chip clock alignment with baseband eye pattern
Using the aligned chip clock, 1000 samples of the I and Q baseband outputs from the reference receiver are
captured. The vector error magnitudes shall be calculated as follows:
Calculate the dc offsets for I and Q samples.
1000
I mean = I n 1000
n=1
1000
Q mean = Q n 1000
n=1
Calculate the dc corrected I and Q samples for all n =1000 sample pairs.
Idc(n) = I(n) – Imean
Qdc(n) = Q(n) – Qmean
Calculate the average magnitude of I and Q samples.
1000
I mag = I dc n 1000
n=1
1000
Q mag = Q dc n 1000
n=1
Calculate the normalized error vector magnitude for the Idc(n)/Qdc(n) pairs.
2 2 1 2
V err(n) = I dc(n) – I mag + Q dc(n) – Q mag
2244
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
the average power of the constellation is 1
NOTE—A correction factor might be needed to compensate for the error induced by a test reference receiver system.
For all n =1000 samples, the following condition shall be met:
Verr(n) < 0.35
15.4.5.11 Time of Departure accuracy
The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and
aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined
Annex P with the following test parameters:
— MULTICHANNEL_SAMPLING_RATE is 22 fH – fL sample/s
10 6 1 + -------------------
22 MHz
where
fH is the nominal center frequency in Hz of the highest channel in the channel set
fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel
set is the set of channels upon which frames providing measurements are transmitted, the
channel set comprises channels uniformly spaced across fH – fL 50 MHz
— FIRST_TRANSITION_FIELD is the SYNC field.
— SECOND_TRANSITION_FIELD is the SFD field.
— TRAINING_FIELD is the concatenation of the SYNC and SFD fields, using a chip pulse that
should approximate a rectangular pulse of duration 1/ 11 MHz convolved with a brick-wall low pass
filter of bandwidth 11 MHz.
— TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns.
NOTE—The indicated chip pulse applies to the time of departure accuracy test equipment, and not the transmitter or
receiver.
15.4.6 PHY receiver specifications
15.4.6.1 Introduction
The receive functions and parameters associated with the PHY sublayer are described in 15.4.6.2 to
15.4.6.5.
15.4.6.2 Receiver minimum input level sensitivity
The FER shall be less than 8 10–2 at an MPDU length of 1024 octets for an input level of –80 dBm
measured at the antenna connector. This FER shall be specified for 2 Mb/s DQPSK modulation. The test for
the minimum input level sensitivity shall be conducted with the ED threshold set –80 dBm.
15.4.6.3 Receiver maximum input level
The receiver shall provide a maximum FER of 8 10–2 at an MPDU length of 1024 octets for a maximum input
level of –4 dBm measured at the antenna. This FER shall be specified for 2 Mb/s DQPSK modulation.
2245
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
15.4.6.4 Receiver adjacent channel rejection
Adjacent channel rejection is defined between any two channels with 30 MHz separation in each channel
group defined in 15.4.4.3.
The adjacent channel rejection shall be 35 dB with an FER of 8 10–2 using 2 Mb/s DQPSK modulation
described in 15.4.4.5 and an MPDU length of 1024 octets.
The adjacent channel rejection shall be measured using the following method:
Input a 2 Mb/s DQPSK modulated signal at a level 6 dB greater than specified in 15.4.6.2. In an adjacent
channel ( 30 MHz separation as defined by the channel numbering), input a signal modulated in a similar
fashion that adheres to the transmit mask specified in 15.4.5.5 to a level 41 dB above the level specified in
15.4.6.2. The adjacent channel signal shall be derived from a separate signal source. It shall not be a
frequency shifted version of the reference channel. Under these conditions, the FER shall be less than or
equal to 8 10–2.
15.4.6.5 CCA
The DSSS PHY shall provide the capability to perform CCA according to both:
A — at least one of the following options:
— CCA Mode 1: Energy above threshold. CCA shall report a busy medium upon detection of any
energy above the ED threshold.
— CCA Mode 2: CS only. CCA shall report a busy medium only upon detection of a DSSS signal. This
signal may be above or below the ED threshold.
— CCA Mode 3: CS with energy above threshold. CCA shall report a busy medium upon detection of a
DSSS signal with energy above the ED threshold.
and
B — CCA Mode 6: CCA shall report a busy medium upon detection of any energy above –62 dBm.
A busy channel shall be indicated by issuing a PHY-CCA.indication(BUSY) primitive.
A clear channel shall be indicated by issuing a PHY-CCA.indication(IDLE) primitive.
The value of dot11CCAModeSupported shall indicate the appropriate operation modes. The PHY shall be
configured according to dot11CurrentCCAMode.
The CCA shall indicate a clear channel if there is no energy detect or CS. The CCA parameters are subject to
the following criteria:
a) The ED threshold shall be –80 dBm for TX power > 100 mW, –76 dBm for 50 mW < TX power
100 mW, and –70 dBm for TX power 50 mW.
b) With a valid signal (according to the CCA mode of operation) present at the receiver antenna within
5 µs of the start of a MAC slot boundary, the PHY-CCA.indication(BUSY) primitive shall be
generated before the end of the slot time. Refer to Figure 10-19 (in 10.3.7) and Figure 10-26 for a
definition of slot boundary.
c) In the event that a correct PHY header is received, the DSSS PHY shall not generate a PHY-
CCA.indication (IDLE) primitive until the end of the PPDU as determined by TXTIME in 16.4.7.
2246
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Compliance to DSSS PHY CCA shall be demonstrated by applying a DSSS signal, above the appropriate
ED threshold (item a), so that all conditions described in item b and item c are demonstrated.
15.4.6.6 Received Channel Power Indicator Measurement
The RCPI is a measure of the received RF power in the selected channel for a received frame. This
parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire
received frame or by other equivalent means that meet the specified accuracy.
The encoding of received power to RCPI is defined in 9.4.2.38.
RCPI shall equal the received RF power within an accuracy of ±5 dB (95% confidence interval) within the
specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel bandwidth multiplied by 1.1.
15.4.6.7 DSSS PHY TXTIME calculation
The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated
according to the following equations:
TXTIME = PreambleLength + PHYHeaderTime + LENGTH
--------------------------------8-
DATARATE
where
LENGTH and DATARATE are values from the TXVECTOR parameter of the corresponding
PLME-TXTIME.request primitive
LENGTH is in units of octets
DATARATE is in units of Mb/s
The value of PreambleLength is 144 s
The value of PHYHeaderTime is 48 s.
2247
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16. High rate direct sequence spread spectrum (HR/DSSS) PHY
specification
16.1 Overview
16.1.1 General
This clause specifies the high rate extension of the PHY for the DSSS system (see Clause 15), hereinafter
known as the HR/DSSS PHY for the 2.4 GHz band designated for ISM applications.
This extension of the DSSS system builds on the data rate capabilities, as described in Clause 15, to provide
5.5 Mb/s and 11 Mb/s payload data rates in addition to the 1 Mb/s and 2 Mb/s rates. To provide the higher
rates, 8-chip complementary code keying (CCK) is employed as the modulation scheme. The chipping rate
is 11 MHz, which is the same as the DSSS system described in Clause 15, thus providing the same occupied
channel bandwidth. The basic new capability described in this clause is called HR/DSSS. One mode of the
HR/DSSS PHY uses the same PHY preamble and header as the DSSS PHY, so both PHYs can co-exist in
the same BSS and can use the rate switching mechanism as provided.
In addition to providing higher speed extensions to the DSSS system, a number of optional features allow
the performance of the RF LAN system to be improved as technology allows the implementation of these
options to become cost effective.
Another optional mode is provided that allows data throughput at the higher rates (2, 5.5, and 11 Mb/s) to be
significantly increased by using a shorter PHY preamble. This mode is called HR/DSSS/short. This short
preamble mode can coexist with DSSS, HR/DSSS under limited circumstances, such as on different
channels or with appropriate CCA mechanisms.
16.1.2 Scope
This clause specifies the PHY entity for the HR/DSSS extension and explains how this standard
accommodates the HR/DSSS PHY.
The HR/DSSS PHY consists of the following two protocol functions:
a) A PHY function that defines a method for mapping the MPDUs into a framing format suitable for
sending and receiving user data and management information between two or more STAs. The PHY
exchanges PPDUs that contain PSDUs. The MAC uses the PHY service, so each MPDU
corresponds to a PSDU that is carried in a PPDU.
b) A function that defines the characteristics of, and method of transmitting and receiving data through,
a WM between two or more STAs, each using the HR/DSSS PHY system.
16.1.3 HR/DSSS PHY functions
16.1.3.1 General
The HR/DSSS PHY contains two functional entities: the PHY function and the layer management function.
Each of these functions is described in detail in 16.2 and 16.3.
The HR/DSSS PHY service shall be provided to the MAC through the PHY service primitives described in
Clause 8.
2248
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.1.3.2 PLME
The PLME performs management of the local PHY functions in conjunction with the MLME.
16.1.4 Service specification method and notation
The models represented by figures and state diagrams are intended to be illustrations of functions provided.
It is important to distinguish between a model and a real implementation. The models are optimized for
simplicity and clarity of presentation, but do not necessarily reflect any particular implementation.
The service of a layer or sublayer is a set of capabilities that it offers to a user in the next-higher layer (or
sublayer). Abstract services are specified here by describing the service primitives and parameters that
characterize each service. This definition is independent of any particular implementation.
16.2 HR/DSSS PHY
16.2.1 Overview
Subclause 16.2 provides a convergence procedure for the 2 Mb/s, 5.5 Mb/s, and 11 Mb/s specification, in
which PSDUs are converted to and from PPDUs. During transmission, the PSDU shall be appended to a
PHY preamble and header to create the PPDU. Two different preambles and headers are defined: the
mandatory supported long preamble and header, which interoperates with the current 1 Mb/s and 2 Mb/s
DSSS specification, and an optional short preamble and header. At the receiver, the PHY preamble and
header are processed to aid in demodulation and delivery of the PSDU.
The optional short preamble and header provides maximum throughput when interoperability with legacy
and nonshort-preamble-capable STAs is not a consideration. That is, it is expected to be used only in
networks of STAs that support the optional mode.
16.2.2 PPDU format
16.2.2.1 General
Two different preambles and headers are defined: the mandatory supported long preamble and header,
which is interoperable with the current 1 Mb/s and 2 Mb/s DSSS specification, and an optional short
preamble and header.
16.2.2.2 Long PPDU format
Figure 16-1 shows the format for the interoperable (long) PPDU, including the HR/DSSS PHY preamble,
the HR/DSSS PHY header, and the PSDU. The PHY preamble contains the following fields: SYNC and
SFD. The PHY header contains the following fields: signaling (SIGNAL), service (SERVICE), length
(LENGTH), and CRC-16. Each of these fields is described in detail in 16.2.3. The format for the PPDU,
including the long HR/DSSS PHY preamble, the long HR/DSSS PHY header, and the PSDU, does not differ
from the format for 1 Mb/s and 2 Mb/s. The only exceptions are:
a) The encoding of the rate in the SIGNAL field;
b) The use of a bit in the SERVICE field to resolve an ambiguity in PSDU length in octets, when the
length is expressed in whole microseconds;
c) The use of a bit in the SERVICE field to indicate that the transit frequency and bit clocks are locked.
2249
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Scrambled 1s
SYNC SFD SIGNAL SERVICE LENGTH CRC 1 Mb/s DBPSK
128 bits 16 bits 8 bits 8 bits 16 bits 16 bits
PHY Preamble PHY Header PSDU
144 bits 48 bits
192 s
1 DBPSK
PPDU 2 DQPSK
5.5 or 11 Mb/s
Figure 16-1—Long PPDU format
16.2.2.3 Short PPDU format
The short PHY preamble and header (HR/DSSS/short) is optional. The short preamble and header may be
used to minimize overhead and, thus, maximize the network data throughput. The format of the PPDU, with
HR/DSSS/short, is depicted in Figure 16-2. A Clause 18 STA shall support the short PPDU format.
Scrambled 0s Backward
SFD
shortSYNC shortSFD
56 bits 16 bits
DBPSK
SIGNAL SERVICE LENGTH CRC
8 bits 8 bits 16 bits 16 bits
2 Mb/s
Short PHY Preamble Short PHY Header PSDU
72 bits at 1 Mb/s 48 bits at 2 Mb/s Variable at 2, 5.5, or 11 Mb/s
96 s
PPDU
Figure 16-2—Short PPDU format
A transmitter using the short PPDU is interoperable with only another receiver that is also capable of
receiving this short PPDU. To interoperate with a receiver that is not capable of receiving a short preamble
and header, the transmitter shall use the long PHY preamble and header. The short PHY preamble uses the 1
Mb/s Barker code spreading with DBPSK modulation. The short PHY header uses the 2 Mb/s Barker code
spreading with DQPSK modulation, and the PSDU is transmitted at 2 Mb/s, 5.5 Mb/s, or 11 Mb/s.
2250
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.2.3 PPDU field definitions
16.2.3.1 General
In the PHY field definition subclauses (16.2.3.2 to 16.2.3.15), the definitions of the long (Clause 15) PHY
fields are given first, followed by the definitions of the short PHY fields. The names for the short PHY fields
are preceded by the term short.
16.2.3.2 Long PHY SYNC field
The SYNC field shall consist of 128 bits of scrambled 1 bits. This field is provided so the receiver can
perform the necessary synchronization operations. The initial state of the scrambler (seed) shall be
[1101100], where the leftmost bit specifies the value to put in the first delay element (Z1) in Figure 16-5 (in
16.2.4), and the rightmost bit specifies the value to put in the last delay element in the scrambler.
To support the reception of DSSS signals generated with implementations based on Clause 15, the receiver
shall also be capable of synchronization on a SYNC field derived from any nonzero scrambler initial state.
16.2.3.3 Long PHY SFD
The SFD shall be provided to indicate the start of PHY-dependent parameters within the PHY preamble.
The SFD shall be a 16-bit field, [1111 0011 1010 0000], where the rightmost bit shall be transmitted
first in time.
16.2.3.4 Long PHY SIGNAL field
The 8-bit SIGNAL field indicates to the PHY the modulation that shall be used for transmission (and
reception) of the PSDU. The data rate shall be equal to the SIGNAL field value multiplied by 100 kb/s. The
high rate PHY supports four mandatory rates given by the following 8-bit words, which represent the rate in
units of 100 kb/s, where the LSB shall be transmitted first in time:
a) X’0A’ (MSB to LSB) for 1 Mb/s;
b) X’14’ (MSB to LSB) for 2 Mb/s;
c) X’37’ (MSB to LSB) for 5.5 Mb/s;
d) X’6E’ (MSB to LSB) for 11 Mb/s.
The HR/DSSS PHY rate change capability is described in 16.2.3.15. This field shall be protected by the
CRC-16 FCS described in 16.2.3.7.
16.2.3.5 Long PHY SERVICE field
Two bits have been defined in the SERVICE field to support the high rate extension; see Table 16-1. The
rightmost bit (bit 7) shall be used to supplement the LENGTH field described in 16.2.3.6. Bit 2 shall be used
to indicate that the transmit frequency and symbol clocks are derived from the same oscillator. This locked
clocks bit shall be set by the PHY based on its implementation configuration. The SERVICE field shall be
transmitted B0 first in time, and shall be protected by the CRC-16 FCS described in 16.2.3.7. B0, B1, B3,
B4, B5, and B6 are reserved and shall be set to 0 on transmission and ignored on reception.
Table 16-1—SERVICE field definitions
B0 B1 B2 B3 B4 B5 B6 B7
Reserved Reserved Locked clocks bit Reserved Reserved Reserved Reserved Length
0 = not locked extension
1 = locked bit
2251
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.2.3.6 Long PHY LENGTH field
The PHY LENGTH field shall contain an unsigned 16-bit integer that indicates the number of microseconds
required to transmit the PSDU. The transmitted value shall be determined from the LENGTH and
DATARATE parameters in the TXVECTOR issued with the PHY-TXSTART.request primitive described
in 16.3.5.
The LENGTH field provided in the TXVECTOR is in octets and is converted to microseconds for inclusion
in the PHY LENGTH field. The LENGTH field is calculated as follows. Because there is an ambiguity in
the number of octets that is described by a length in integer microseconds for any data rate over 8 Mb/s, a
length extension bit is present in the SERVICE field to indicate when the smaller potential number of octets
is correct as follows:
8
— 5.5 Mb/s CCK LENGTH = number of octets ------- .
5.5
8-
— 11 Mb/s CCK LENGTH = -----
number of octets ; the length extension bit shall be set to 0
11
if (LENGTH – (number of octets 8/11)) < 8/11 and shall be set to 1 otherwise.
The length extension bit is reserved when the data rate is not 11 Mb/s.
At the receiver, the number of octets in the MPDU is calculated as follows:
5.5
— 5.5 Mb/s CCK number of octets = LENGTH ------- .
8
11
— 11 Mb/s CCK number of octets = LENGTH ------ , minus 1 if the length extension bit is a 1.
8
An example for an 11 Mb/s calculation described in pseudocode form is shown below. At the transmitter,
the values of the LENGTH field and length extension bit are calculated as follows:
LENGTH' = (number of octets 8) / R
LENGTH = LENGTH'
If
(R = 11) and ((LENGTH–LENGTH') 8/11)
then
length extension = 1
else
length extension = 0
where
R is the data rate (Mb/s)
2252
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
At the receiver, the number of octets in the MPDU is calculated as follows:
number of octets = LENGTH R – length extension
----------------------------------
8
where
R is the data rate (Mb/s)
Table 16-2 shows an example calculation for several packet lengths of CCK at 11 Mb/s.
Table 16-2—Example of LENGTH calculations for CCK
Octets 8 Length LENGTH 11 LENGTH 11
TX octets ------------------------- LENGTH extension -------------------------------------- -------------------------------------- RX octets
11 bit 8 8
1023 744 744 0 1023 1023 1023
1024 744.7273 745 0 1024.375 1024 1024
1025 745.4545 746 0 1025.75 1025 1025
1026 746.1818 747 1 1027.125 1027 1026
This example illustrates why normal rounding or truncation of the number does produce the right result. The
LENGTH field is defined in units of microseconds and corresponds to the actual length, and the number of
octets is exact.
The LSB shall be transmitted first in time. This field shall be protected by the CRC-16 FCS described in
16.2.3.7.
16.2.3.7 PHY CRC (CRC-16) field
The SIGNAL, SERVICE, and LENGTH fields shall be protected with a CRC-16 FCS. The CRC-16 FCS
shall be the 1s complement of the remainder generated by the modulo 2 division of the protected PHY fields
by the polynomial
16 12 5
x +x +x +1
The protected bits shall be processed in transmit order. All FCS calculations shall be made prior to data
scrambling. A schematic of the processing is shown in Figure 16-3.
As an example, the SIGNAL, SERVICE, and LENGTH fields for a DBPSK signal with a PPDU length of
192 s (24 octets) would be given by the following:
0101 0000 0000 0000 0000 0011 0000 0000 [leftmost bit (B0) transmitted first in time]
B0.................................................................B48
The 1s complement FCS for these protected PHY preamble bits would be the following:
0101 1011 0101 0111 [leftmost bit (B0) transmitted first in time]
B0.........................B16
2253
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 16-3 depicts this example.
TRANSMIT AND RECEIVE PHY HEADER
CRC-16 CALCULATOR
SERIAL DATA SERIAL DATA
INPUT CRC-16 OUTPUT
PRESET
TO 1S 1. Preset to all 1s
2. Shift signal, service length fields
through the shift register
3. Take 1s complement of the remainder
4. Transmit out serial X15 first
CRC-16 POLYNOMIAL: G(x) = X16 + X12 + X5 + 1
SERIAL DATA
INPUT
+ X15 X14 X13 X12
+ X11 X10 X9 X8 X7 X6 X5 + X4 X3 X2 X1 X0
SERIAL DATA OUTPUT
1S COMPLEMENT
(X15 FIRST)
Figure 16-3—CRC-16 implementation
2254
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An illustrative example of the CRC-16 FCS using the information from Figure 16-3 is shown in
Figure 16-4.
Data CRC Registers
MSB LSB
1111111111111111 ; Initialize preset to 1s
0 1110111111011111
1 1101111110111110
0 1010111101011101
1 0101111010111010
0 1011110101110100
0 0110101011001001
0 1101010110010010
0 1011101100000101
0 0110011000101011
0 1100110001010110
0 1000100010001101
0 0000000100111011
0 0000001001110110
0 0000010011101100
0 0000100111011000
0 0001001110110000
0 0010011101100000
0 0100111011000000
0 1001110110000000
0 0010101100100001
0 0101011001000010
0 1010110010000100
1 0101100100001000
1 1010001000110001
0 0101010001000011
0 1010100010000110
0 0100000100101101
0 1000001001011010
0 0001010010010101
0 0010100100101010
0 0101001001010100
0 1010010010101000
0101101101010111 ; 1s complement, result = CRC FCS parity
Figure 16-4—Example of CRC calculation
16.2.3.8 Long PHY data modulation and modulation rate change
The long PHY preamble and header shall be transmitted using the 1 Mb/s DBPSK modulation. The
SIGNAL field indicates the rate that is used to transmit the PSDU. The transmitter and receiver shall initiate
the rate indicated by the SIGNAL field, starting with the first octet of the PSDU. The PSDU transmission
rate shall be set by the DATARATE parameter in the TXVECTOR, issued with the PHY-
TXSTART.request primitive described in 16.3.5.
16.2.3.9 Short PHY synchronization (shortSYNC)
The shortSYNC field shall consist of 56 bits of scrambled 0 bits. This field is provided so the receiver can
perform the necessary synchronization operations. The initial state of the scrambler (seed) shall be
[001 1011], where the left end bit specifies the value to place in the first delay element (Z1) in Figure 16-5
(in 16.2.4), and the right end bit specifies the value to place in the last delay element (Z7).
16.2.3.10 Short PHY SFD field (shortSFD)
The shortSFD shall be a 16-bit field and be the time reverse of the field of the SFD in the long PHY
preamble (16.2.3.3). The field is the bit pattern 0000 0101 1100 1111. The right end bit shall be transmitted
first in time. A receiver not configured to use the short header option does not detect this SFD.
2255
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.2.3.11 Short PHY SIGNAL field (shortSIGNAL)
The 8-bit SIGNAL field of the short header indicates to the PHY the data rate that shall be used for
transmission (and reception) of the PSDU. A PHY operating with the HR/DSSS/short option supports three
mandatory rates given by the following 8-bit words, where the LSB shall be transmitted first in time and the
number represents the rate in units of 100 kb/s:
a) X’14’ (MSB to LSB) for 2 Mb/s;
b) X’37’(MSB to LSB) for 5.5 Mb/s;
c) X’6E’ (MSB to LSB) for 11 Mb/s.
16.2.3.12 Short PHY SERVICE field (shortSERVICE)
The SERVICE field in the short header shall be the same as the SERVICE field described in 16.2.3.5.
16.2.3.13 Short PHY LENGTH field (shortLENGTH)
The LENGTH field in the short header shall be the same as the LENGTH field described in 16.2.3.6.
16.2.3.14 Short CRC-16 field (shortCRC)
The CRC in the short header shall be the same as the CRC field defined in 16.2.3.7. The CRC-16 is
calculated over the shortSIGNAL, shortSERVICE, and shortLENGTH fields.
16.2.3.15 Short PHY data modulation and modulation rate change
The short PHY preamble shall be transmitted using the 1 Mb/s DBPSK modulation. The short PHY header
shall be transmitted using the 2 Mb/s modulation. The SIGNAL field indicates the rate that is used to
transmit the PSDU. The transmitter and receiver shall initiate the rate indicated by the SIGNAL field,
starting with the first octet of the PSDU. The PSDU transmission rate shall be set by the DATARATE
parameter in the TXVECTOR, issued with the PHY-TXSTART.request primitive described in 16.3.5.
16.2.4 PHY/HR/DSSS PHY data scrambler and descrambler
The polynomial G(z) = z –7 + z –4 + 1 shall be used to scramble all bits transmitted. The feedthrough
configuration of the scrambler and descrambler is self-synchronizing, which requires no prior knowledge of
the transmitter initialization of the scrambler for receive processing. Figure 16-5 and Figure 16-6 show
typical implementations of the data scrambler and descrambler, but other implementations are possible.
SCRAMBLER POLYNOMIAL: G(z) = Z-7 +Z-4 +1
SERIAL DATA
OUTPUT
SERIAL DATA
INPUT Z 1 Z2 Z 3 Z 4 Z 5 Z 6 Z7
Figure 16-5—Data scrambler
2256
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRAMBLER POLYNOMIAL: G(z) = Z-7 +Z-4 +1
SERIAL DATA INPUT Z 1 Z 2 Z 3 Z4 Z 5 Z6 Z 7
SERIAL DATA OUTPUT
Figure 16-6—Data descrambler
The scrambler shall be initialized as specified in 16.2.3.9 for the short PPDU format and 16.2.3.2 for the
long PPDU format. For a long preamble, this shall result in the scrambler registers Z1 to Z7 in Figure 16-5
having the data pattern [1101100] (i.e., Z1= 1... Z7= 0) when the scrambler is first started. The scrambler
shall be initialized with the reverse pattern [0011011] when transmitting the optional short preamble.
16.2.5 Transmit PHY
The transmit procedures for a HR/DSSS PHY using the long PPDU format are the same as the transmit
procedures described in 15.3.6 and 15.3.7 and do not change apart from the ability to transmit 5.5 Mb/s and
11 Mb/s.
The procedures for a transmitter employing HR/DSSS/short are the same except for length and rate changes.
The decision to use the long or short PPDU format is beyond the scope of this standard.
The transmit PHY is shown in Figure 16-7.
A PHY-TXSTART.request(TXVECTOR) primitive is issued by the MAC to start the transmission
of a PPDU. In addition to parameters DATARATE and LENGTH, other transmit parameters such as
PREAMBLE_TYPE are set via the PHY SAP with the PHY-TXSTART.request(TXVECTOR) primitive, as
described in 16.3.5. The SIGNAL, SERVICE, and LENGTH fields of the PHY header are calculated as
described in 16.2.3.
The PHY is configured with the TXVECTOR elements TX_ANTENNA, DATARATE, and
TXPWR_LEVEL_INDEX. The PHY entity shall immediately initiate data scrambling and transmission of
the PHY preamble based on the parameters passed in the PHY-TXSTART.request primitive. The time
required for transmit power-on ramp, described in 16.3.7.7, shall be included in the PHY SYNC field.
Once the PHY preamble transmission is complete, data shall be exchanged between the MAC and the PHY
by a series of PHY-DATA.request(DATA) primitives issued by the MAC and PHY-DATA.confirm
primitives issued by the PHY. The modulation and rate change, if any, shall be initiated with the first data
symbol of the PSDU, as described in 16.2.3.8 and 16.2.3.15. The PHY proceeds with PSDU transmission
through a series of data octet transfers from the MAC. Transmission can be prematurely terminated by the
MAC through the PHY-TXEND.request primitive. PHY-TXSTART shall be disabled by the issuance of the
PHY-TXEND.request primitive. Normal termination occurs after the transmission of the final bit of the last
PSDU octet, calculated from the number supplied in the PHY preamble LENGTH and SERVICE fields
using the equations specified in 16.2.3.6. The PPDU transmission shall be completed and the PHY entity
shall enter the receive state (i.e., PHY-TXSTART shall be disabled). It is recommended that modulation
2257
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
continue during power-down to prevent radiating a continuous wave carrier. Each PHY-TXEND.request
primitive is acknowledged with a PHY-TXEND.confirm primitive from the PHY.
MAC PHY
PHY-TXSTART.request
(TXVECTOR)
TX Power RAMP on
Scramble Start
SYNC
PHY-TXSTART.confirm
(TXSTATUS)
PHY-DATA.request
SFD
CRC-16 Start
SIGNAL, SERVICE
Time LENGTH
CRC-16 End
CRC
PHY-DATA.confirm
PSDU
.........
PHY-TXEND.request
TX Power RAMP Off
PHY-TXEND.confirm
Figure 16-7—Transmit PHY
16.2.6 Receive PHY
The receive procedures for receivers configured to receive the mandatory and optional PHYs, rates, and
modulations are described in this subclause. A receiver that supports this high rate extension of the
standard is capable of receiving 5.5 Mb/s and 11 Mb/s, in addition to 1 Mb/s and 2 Mb/s. If the PHY
implements the short preamble option, it shall detect both short and long preamble formats and indicate
which type of preamble was received in the RXVECTOR. The receiver shall implement the CCA procedure
as defined in 16.3.8.5. Upon receiving a PPDU, the receiver shall distinguish between a long and short
2258
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
header format by the value of the SFD, as specified in 16.2.2. The receiver shall demodulate a long PHY
header using BPSK at 1 Mb/s. The receiver shall demodulate a short PHY header using QPSK at 2 Mb/s.
The receiver shall use the SIGNAL and SERVICE fields of the PHY header to determine the data rate and
modulation of the PSDU.
The receive PHY is shown in Figure 16-8. In order to receive data, the PHY-TXSTART.request primitive
shall be disabled so that the PHY entity is in the receive state. Further, through station management via the
PLME, the PHY shall be set to the appropriate channel and the CCA method chosen. Other receive
parameters, such as RSSI, RCPI, SQ, and indicated DATARATE, may be accessed via the PHY SAP.
MAC PHY
PHY-CCA.indication(BUSY)
Descrambler Start
Time SYNC
SFD Rate Change Start
CRC Start
SIGNAL, SERVICE
LENGTH
CRC End
CRC
PHY-RXSTART.indication Modulation and Rate
(RXVECTOR) Change Start
PHY-DATA.indication(DATA)
PSDU
PHY-RXEND.indication
(RXERROR,RXVECTOR)/
PHY-CCA.indication(IDLE)
Figure 16-8—Receive PHY
Upon receiving the transmitted energy, according to the selected CCA mode a PHY-CCA.indication(BUSY)
primitive shall be issued for ED and/or code lock prior to correct reception of the PHY header. The PHY
measures the SQ, RSSI, and RCPI parameters and these are reported to the MAC in the RXVECTOR.
After a PHY-CCA.indication primitive is issued, the PHY entity shall begin searching for the SFD field.
Once the SFD field is detected, CRC-16 processing shall be initiated and the PHY SIGNAL, SERVICE, and
LENGTH fields shall be received. The CRC-16 FCS shall be processed. If the CRC-16 FCS check fails, the
2259
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PHY receiver shall return to the RX IDLE state, as depicted in Figure 16-9. Should the status of CCA return
to the IDLE state during reception prior to completion of the full PPDU processing, the PHY receiver shall
return to the RX IDLE state.
If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported),
a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued. The RXVECTOR associated with
this primitive includes:
a) The SIGNAL field
b) The SERVICE field
c) The PSDU length in octets (calculated from the LENGTH field in microseconds and the
DATARATE in Mb/s, in accordance with the formula in 16.2.3.6)
d) RXPREAMBLE_TYPE (which is an enumerated type taking on values SHORTPREAMBLE or
LONGPREAMBLE)
e) ANT_STATE (the antenna used for receive), RSSI, RCPI, and SQ
If dot11TimingMsmtActivated is true, the PHY shall do the following:
— Complete receiving the PHY header and verify the validity of the PHY Header.
— If the PHY header reception is successful (and the SIGNAL field is completely recognizable
and supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and
RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see
16.3.5).
NOTE—The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the
start of the preamble for the incoming frame was detected on the medium at the receive antenna connector.
The received PSDU bits are assembled into octets and presented to the MAC using a series of PHY-
DATA.indication(DATA) primitive exchanges. The rate and modulation change indicated in the SIGNAL
field shall be initiated with the first symbol of the PSDU, as described in 16.2.5. The PHY proceeds with
PSDU reception. After reception of the final bit of the last PSDU octet, as indicated by the PHY preamble
LENGTH field, the receiver shall be returned to the RX IDLE state shown in Figure 16-9.
A PHY-RXEND.indication(NoError) primitive shall be issued. A PHY-CCA.indication(IDLE) primitive
shall be issued following a change in PHYCS and/or PHYED according to the selected CCA method.
In the event that a change in PHYCS or PHYED would cause the status of CCA to return to the IDLE state
before the complete reception of the PSDU, as indicated by the PHY LENGTH field, the error condition
shall be reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive. The CCA of the HR/
DSSS PHY shall indicate a busy medium for the intended duration of the transmitted PPDU.
If the PHY header is successful, but the indicated rate or modulation in the SIGNAL and SERVICE fields is
not within the capabilities of the receiver, a PHY-RXSTART.indication primitive shall not be issued. The
PHY shall indicate the error condition by issuing a PHY-RXEND.indication(UnsupportedRate) primitive. If
the PHY header is invalid, a PHY-RXSTART.indication primitive shall not be issued, and the PHY shall
indicate the error condition using a PHY-RXEND.indication(FormatViolation) primitive. Also, in both
cases, the CCA of the HR/DSSS PHY shall indicate a busy medium for the intended duration of the
transmitted PSDU, as indicated by the LENGTH field. The intended duration is indicated by the LENGTH
field (LENGTH 1 s).
A typical state machine implementation of the receive PHY is shown in Figure 16-9.
2260
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RESET
RX IDLE state
perform CS/CCA
RX SYMBOL
PHY-DATA.indication
DETECT SYNC PATTERN CCA(IDLE) CCA(BUSY)
Wait Until SFD
is Detected SIGNAL NOT VALID DECREMENT LENGTH
PHY-CCA PHY-RXEND.indication Decrement count
.indication
(IDLE) (carrier lost) by 1 s
SET
RXPHY FIELDS
RX 8 bit SIGNAL
DECREMENT TIME OCTET ASSIMILATION
RX 8 bit SERVICE
PHY-CCA Wait for Intended Increment Bit Count
RX 16 bit LENGTH
.indication End of PSDU Set Octet Bit Count Length 0
(IDLE) PHY-DATA.indication
(DATA)
Time = 0
PHY-CCA Length = 0
.indication RX PHY CRC
(IDLE) or END OF WAIT END OF PSDU RX
RX and Test CRC
CRC FAIL PHY-RXEND.indication
PHY-CCA.indication
(IDLE) (No_Error)
PHY-CCA.indication PHY-CCA.indication
Length = 0 (IDLE) CRC Correct (IDLE)
DECREMENT LENGTH VALIDATE PPDU
Decrement Check PPDU
Length
Count
PPDU Correct
PHY field
Out of Spec SETUP PSDU RX
Set RATE
Set Length Count
Set Octet Bit Count
PHY-RXSTART.indication
(RXVECTOR)
Figure 16-9—PHY receive state machine
16.3 HR/DSSS PLME
16.3.1 PLME SAP sublayer management primitives
Table 16-3 lists the MIB attributes that may be accessed by the PHY entities and intralayer or higher level
LMEs. These attributes are accessed via the PLME-GET, PLME-SET, and PLME-RESET primitives
defined in Clause 6.
16.3.2 HR/DSSS PHY MIB
All HR/DSSS PHY MIB attributes are defined in Annex C, with specific values defined in Table 16-3.
2261
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 16-3—MIB attribute default values/ranges
Operational
Managed object Default value/range
semantics
dot11PhyOperationTable
dot11PHYType High rate–2.4 (X‘05’) Static
dot11CurrentRegDomain Implementation dependent Static
dot11PhyHRDSSSEntryTable
dot11ShortPreambleOptionImplemented Implementation dependent Static
dot11PhyAntennaTable
dot11CurrentTxAntenna Implementation dependent Dynamic
dot11DiversitySupportImplemented Implementation dependent Static
dot11CurrentRxAntenna Implementation dependent Dynamic
dot11PhyTxPowerTable
dot11NumberSupportedPowerLevelsImplemented Implementation dependent Static
dot11TxPowerLevel1 Implementation dependent Static
dot11TxPowerLevel2 Implementation dependent Static
dot11TxPowerLevel3 Implementation dependent Static
dot11TxPowerLevel4 Implementation dependent Static
dot11TxPowerLevel5 Implementation dependent Static
dot11TxPowerLevel6 Implementation dependent Static
dot11TxPowerLevel7 Implementation dependent Static
dot11TxPowerLevel8 Implementation dependent Static
dot11CurrentTxPowerLevel Implementation dependent Dynamic
dot11PhyDSSSTable
dot11CurrentChannel Implementation dependent Dynamic
dot11HRCCAModeSupported Implementation dependent Static
dot11CurrentCCAMode Implementation dependent Dynamic
dot11EDThreshold Implementation dependent Dynamic
dot11AntennasListTable
dot11SupportedTxAntenna Implementation dependent Static
dot11SupportedRxAntenna Implementation dependent Static
dot11DiversitySelectionRxImplemented Implementation dependent Dynamic
dot11RegDomainsSupportedTable
dot11RegDomainsImplementedValue Implementation dependent Static
dot11SupportedDataRatesTx Table Tx X’02’, X’04’, X’0B’, X’16’ Static
dot11SupportedDataRatesRx Table Rx X’02’, X’04’, 'X’0B’, X’16’ Static
NOTE—The column titled “Operational semantics” contains two types: static and dynamic. Static MIB
attributes are fixed and cannot be modified for a given PHY implementation. Dynamic MIB attributes can be
modified by some management entities.
2262
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.3.3 HR/DSSS PHY
The static HR/DSSS PHY characteristics, provided through the PLME-CHARACTERISTICS service
primitive, are shown in Table 16-4. The definitions of these characteristics are in 6.5.4.
Table 16-4—HR/DSSS PHY characteristics
Characteristic Value
aSlotTime If dot11OperatingClassesRequired is false, 20 µs
If dot11OperatingClassesRequired is true, 20 µs plus any coverage-class-
dependent aAirPropagationTime (see Table 9-79)
aSIFSTime 10 s
aCCATime Implementation dependent, see 10.3.7.
aRxPHYStartDelay 192 s for long preamble and 96 s for short preamble
aRxTxTurnaroundTime Implementation dependent, see 10.3.7.
aTxPHYDelay Implementation dependent, see 10.3.7.
aRxPHYDelay Implementation dependent, see 10.3.7.
aRxTxSwitchTime Implementation dependent, see 10.3.7.
aTxRampOnTime Implementation dependent, see 10.3.7.
aAirPropagationTime As indicated by the coverage class (see 10.21.5).
aMACProcessingDelay Implementation dependent, see 10.3.7.
aPreambleLength 72 s
aPHYHeaderLength 24 s
aPSDUMaxLength 212 – 1 octets
aCWmin 31
aCWmax 1023
16.3.4 HR/DSSS TXTIME calculation
The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated
according to the following equation:
TXTIME = PreambleLength + PHYHeaderTime + LENGTH 8
---------------------------------
DATARATE
where
LENGTH and DATARATE are values from the TXVECTOR parameter of the corresponding
PLME-TXTIME.request primitive
LENGTH is in units of octets
DATARATE is in units of Mb/s
The value of PreambleLength is 144 s if the TXPREAMBLE_TYPE value from the TXVECTOR
parameter indicates “LONGPREAMBLE,” or 72 s if the
TXPREAMBLE_TYPE value from the TXVECTOR parameter
indicates “SHORTPREAMBLE”
2263
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The value of PHYHeaderTime is 48 s if the TXPREAMBLE_TYPE value from the TXVECTOR
parameter indicates “LONGPREAMBLE,” or 24 s if the
TXPREAMBLE_TYPE value from the TXVECTOR parameter
indicates “SHORTPREAMBLE”
16.3.5 Vector descriptions
Several service primitives include a parameter vector. These vectors are a list of parameters as described in
Table 16-5. DATARATE and LENGTH are described in 8.3.4.4. The remaining parameters are considered
to be management parameters and are specific to this PHY.
Table 16-5—Parameter vectors
Parameter Associated vector Value
DATARATE RXVECTOR, The rate used to transmit the PSDU in Mb/s.
TXVECTOR
LENGTH RXVECTOR, The length of the PSDU in octets.
TXVECTOR
PREAMBLE_TYPE RXVECTOR, The preamble used for the transmission of this PPDU. This
TXVECTOR is an enumerated type that takes the value
SHORTPREAMBLE or LONGPREAMBLE.
ANT_STATE RXVECTOR 1–256
TX_ANTENNA TXVECTOR Selects which of the available antennas should be used for
transmit, in the range 1 to 256.
RSSI RXVECTOR 0–8 bits of RSSI
RCPI RXVECTOR 0–255
(see NOTE)
SQ RXVECTOR 0–8 bits of SQ
TIME_OF_DEPAR- TXVECTOR false, true. When true, the MAC entity requests that the
TURE_REQUESTED PHY entity measures and reports time of departure
parameters corresponding to the time when the first frame
energy is sent by the transmitting port; when false, the MAC
entity requests that the PHY entity neither measures nor
reports time of departure parameters.
TIME_OF_DEPARTURE TXSTATUS 0 to 232– 1. The time when the first frame energy is sent by
the transmitting port, measured by the local PHY entity, in
units equal to 1/TIME_OF_DEPARTURE_ClockRate. This
parameter is present only if
TIME_OF_DEPARTURE_REQUESTED is true in the
corresponding request.
TIME_OF_DEPARTURE_- TXSTATUS 0 to 216– 1. The clock rate, in units of MHz, is used to
ClockRate generate the TIME_OF_DEPARTURE value. This
parameter is present only if
TIME_OF_DEPARTURE_REQUESTED is true in the
corresponding request.
TX_START_OF_- TXSTATUS 0 to 232– 1. An estimate of the offset (in 10 ns units) from
FRAME_OFFSET the point in time at which the start of the preamble
corresponding to the frame was transmitted at the transmit
antenna connector to the point in time at which this
primitive is issued to the MAC.
2264
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 16-5—Parameter vectors (continued)
Parameter Associated vector Value
RX_START_OF_- RXVECTOR 0 to 232– 1. An estimate of the offset (in 10 ns units) from
FRAME_OFFSET the point in time at which the start of the preamble corre-
sponding to the incoming frame arrived at the receive
antenna connector to the point in time at which this primi-
tive is issued to the MAC.
NOTE—RCPI is present only when dot11RadioMeasurementActivated is true.
16.3.6 PHY operating specifications, general
16.3.6.1 General
General specifications for the HR/DSSS PHY sublayer are provided in 16.3.6.2 to 16.3.6.11. These
specifications apply to both the receive and transmit functions and general operation of a HR/DSSS PHY.
WLANs implemented in accordance with this standard are subject to equipment certification and operation
requirements established by regional and national regulatory administrations. The PHY specification
establishes minimum technical requirements for interoperability, based upon established regulations at the
time this standard was issued. These regulations are subject to revision, or may be superseded. Requirements
that are subject to local geographic regulations are annotated within the PHY specification. Regulatory
requirements that do not affect interoperability are not addressed in this standard. Implementers are referred
to the following regulatory sources for further information. Operation in countries within defined regulatory
domains may be subject to additional regulations.
16.3.6.2 Operating frequency range
The HR/DSSS PHY shall operate in the 2.4–2.4835 GHz frequency range, as allocated by regulatory bodies
in the China, United States, Europe, and Japan, or in the 2.471–2.497 GHz frequency range, as allocated by
regulatory authority in Japan.
16.3.6.3 Channel Numbering of operating channels
When dot11OperatingClassesRequired is true, channel numbering shall be as specified in 17.3.8.4.2 and
channelization shall be as specified in 17.3.8.4.3. When dot11OperatingClassesDefined is false or not
defined, the channel center frequencies and CHNL_ID numbers shall be as shown in Table 16-6.
Table 16-6—HR/DSSS PHY frequency channel plan
Frequency
CHNL_ID
(MHz)
1 2412
2 2417
3 2422
4 2427
5 2432
6 2437
7 2442
2265
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 16-6—HR/DSSS PHY frequency channel plan (continued)
Frequency
CHNL_ID
(MHz)
8 2447
9 2452
10 2457
11 2462
12 2467
13 2472
14 2484
In a multiple cell network topology, overlapping and/or adjacent cells using different channels can operate
simultaneously without interference if the distance between the center frequencies is at least 25 MHz.
Channel 14 shall be designated specifically for operation in Japan.
16.3.6.4 Modulation and channel data rates
Four modulation formats and data rates are specified for the HR/DSSS PHY. The basic access rate shall be
based on 1 Mb/s DBPSK modulation. The enhanced access rate shall be based on 2 Mb/s DQPSK. The
extended direct sequence specification defines two additional data rates. The HR/DSSS access rates shall be
based on the CCK modulation scheme for 5.5 Mb/s and 11 Mb/s.
16.3.6.5 Spreading sequence and modulation for 1 Mb/s and 2 Mb/s
The following 11-chip Barker sequence shall be used as the PN code sequence for the 1 Mb/s and 2 Mb/s
modulation:
+1, –1, +1, +1, –1, +1, +1, +1, –1, –1, –1
The leftmost chip shall be output first in time. The first chip shall be aligned at the start of a transmitted
symbol. The symbol duration shall be exactly 11 chips long.
The DBPSK encoder for the basic access rate is specified in Table 16-7. The DQPSK encoder is specified in
Table 16-8. (In these tables, +j shall be defined as counterclockwise rotation.)
Table 16-7—1 Mb/s DBPSK encoding table
Bit input Phase change (+j )
0 0
1
2266
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 16-8—2 Mb/s DQPSK encoding table
Dibit pattern (d0,d1)
Phase change (+j )
(d0 is first in time)
00 0
01 /2
11
10 3 /2 (– /2)
16.3.6.6 Spreading sequences and modulation for CCK modulation at 5.5 Mb/s and 11 Mb/s
16.3.6.6.1 General
For the CCK modulation modes, the spreading code length is 8 and is based on complementary codes. The
chipping rate is 11 Mchip/s. The symbol duration shall be exactly 8 complex chips long.
The following formula shall be used to derive the CCK codewords that shall be used for spreading both
5.5 Mb/s and 11 Mb/s
j 1 + 2 + 3 + 4 j 1 + 3 + 4 j 1 + 2 + 4
c = e ,e ,e ,
: j 1 + 4 j 1 + 2 + 3 j 1 + 3 j 1 + 2 j 1
(16-1)
–e ,e ,e , –e ,e
where C is the codeword
C = {c0 to c7}
The terms 1, 2, 3, and 4 are defined in 16.3.6.6.3 for 5.5 Mb/s and 16.3.6.6.4 for 11 Mb/s.
This formula creates 8 complex chips (c0 to c7), where c0 is transmitted first in time.
This is a form of the generalized Hadamard transform encoding, where 1 is added to all code chips, 2 is
added to all odd code chips, 3 is added to all odd pairs of code chips, and 4 is added to all odd groups of
four code chips.
The term 1 modifies the phase of all code chips of the sequence and shall be DQPSK encoded for
5.5 Mb/s and 11 Mb/s. This shall take the form of rotating the whole symbol by the appropriate amount
relative to the phase of the preceding symbol. Note that the chip c7 of the symbol defined above is the chip
that indicates the symbol’s phase and is transmitted last.
16.3.6.6.2 Cover code for CCK
The fourth and seventh chips are rotated 180 by a cover sequence to optimize the sequence correlation
properties and minimize dc offsets in the codes. This explains the minus sign on the fourth and seventh
terms in Equation (16-1).
16.3.6.6.3 CCK 5.5 Mb/s modulation
At 5.5 Mb/s, 4 bits (d0 to d3; d0 first in time) are transmitted per symbol.
The data bits d0 and d1 encode 1 based on DQPSK. The DQPSK encoder is specified in Table 16-8. (In the
table, +j shall be defined as counterclockwise rotation.) The phase change for 1 is relative to the phase 1
of the preceding symbol. For the header to PSDU transition, the phase change for 1 is relative to the phase
2267
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
of the preceding DQPSK (2 Mb/s) symbol. That is, the phase of the last symbol of the CRC-16 is the
reference phase for the first symbol generated from the PSDU octets. (See the definition in 16.3.6.5 for the
reference phase of this Barker coded symbol.) A “+1” chip in the Barker code shall represent the same
carrier phase as a “+1” chip in the CCK code.
All odd-numbered symbols generated from the PSDU octets shall be given an extra 180° ( ) rotation, in
addition to the standard DQPSK modulation as shown in Table 16-9. The symbols of the PSDU shall be
numbered starting with 0 for the first symbol, for the purposes of determining odd and even symbols. That
is, the PSDU transmission starts on an even-numbered symbol.
Table 16-9—DQPSK encoding table
Dibit pattern (d0, d1) Even symbols Odd symbols
(d0 is first in time) phase change (+j phase change (+j )
00 0
01 /2 3 /2 (– /2)
11 0
10 3 /2 (– /2) /2
The data dibits d2 and d3 CCK encode the basic symbol, as specified in Table 16-10. This table is derived
from the formula above by setting 2 = (d2 ) + /2, 3 = 0, and 4 = d3 . In this table, d2 and d3 are
in the order shown, and the complex chips are shown c0 to c7 (left to right), with c0 transmitted first in time.
Table 16-10—5.5 Mb/s CCK encoding table
d2, d3 c1 c2 c3 c4 c5 c6 c7 c8
00 1j 1 1j –1 1j 1 –1j 1
01 –1j –1 –1j 1 1j 1 –1j 1
10 –1j 1 –1j –1 –1j 1 1j 1
11 1j –1 1j 1 –1j 1 1j 1
16.3.6.6.4 CCK 11 Mb/s modulation
At 11 Mb/s, 8 bits (d0 to d7; d0 first in time) are transmitted per symbol.
The first dibit (d0, d1) encodes 1 based on DQPSK. The DQPSK encoder is specified in Table 16-8. The
phase change for 1 is relative to the phase 1 of the preceding symbol. In the case of header to PSDU
transition, the phase change for 1 is relative to the phase of the preceding DQPSK symbol. All odd-
numbered symbols of the PSDU are given an extra 180° ( ) rotation, in accordance with the DQPSK
modulation shown in Table 16-8. Symbol numbering starts with 0 for the first symbol of the PSDU.
The data dibits (d2, d3), (d4, d5), and (d6, d7) encode 2, 3, and 4, respectively, based on QPSK as
specified in Table 16-11. Note that this table is binary (not Gray) coded.
2268
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 16-11—QPSK encoding table
Dibit pattern [di, d(i+1)]
Phase
(di is first in time)
00 0
01 /2
10
11 3 /2 (– /2)
16.3.6.7 Transmit and receive in-band and out-of-band spurious emissions
The HR/DSSS PHY shall comply with in-band and out-of-band spurious emissions as set by the appropriate
regulatory bodies.
16.3.6.8 TX-to-RX turnaround time
The TX-to-RX turnaround time shall be less than 10 s, including the power-down ramp specified
in 16.3.7.7.
The TX-to-RX turnaround time shall be measured on the WM from the trailing edge of the last transmitted
symbol to the valid CCA detection of the incoming signal. The CCA should occur within 25 s (10 s for
turnaround time, plus 15 s for energy detect), or by the next slot boundary occurring after the 25 s has
elapsed (see 16.3.8.5). A receiver input signal 3 dB above the ED threshold described in 16.3.8.5 shall be
present at the receiver.
16.3.6.9 RX-to-TX turnaround time
The RX-to-TX turnaround time shall be measured at the MAC/PHY interface using the
PHY-TXSTART.request primitive, and shall be 5 s. This includes the transmit power-on ramp described in
16.3.7.7.
16.3.6.10 Slot time
The value of the slot time is found in Table 16-4.
16.3.6.11 Transmit and receive impedance at the antenna connector
The impedance at the transmit and receive antenna connector(s) shall be 50 if the connector is exposed.
16.3.7 PHY transmit specifications
16.3.7.1 Introduction
The transmit functions and parameters associated with the PHY sublayer are described in 16.3.7.2 to
16.3.7.9.
16.3.7.2 Transmit power levels
The maximum allowable output power is measured in accordance with practices specified by the appropriate
regulatory bodies.
2269
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.3.7.3 Transmit power level control
Power control shall be provided for transmitted power greater than 100 mW. A maximum of four power
levels may be provided. As a minimum, a radio capable of transmission greater than 100 mW shall be
capable of switching power back to 100 mW or less.
16.3.7.4 Transmit spectrum mask
The transmitted spectral products shall be less than –30 dBr (decibel relative to the SINx/x peak) for
fc – 22 MHz < f < fc –11 MHz and
fc + 11 MHz < f < fc + 22 MHz
and shall be less than –50 dBr for
f < fc – 22 MHz and
f > fc + 22 MHz
where
fc is the channel center frequency
The transmit spectral mask is shown in Figure 16-10. The measurements shall be made using a 100 kHz
resolution bandwidth and a 100 kHz video bandwidth.
Figure 16-10—Transmit spectrum mask
16.3.7.5 Transmit center frequency tolerance
The transmitted center frequency tolerance shall be ±25 ppm maximum.
16.3.7.6 Chip clock frequency tolerance
The PN code chip clock frequency tolerance shall be ±25 ppm maximum. It is highly recommended that the
chip clock and the transmit frequency be locked (coupled) for optimum demodulation performance. If these
clocks are locked, it is recommended that bit 2 of the SERVICE field be set to 1, as indicated in 16.2.3.5.
2270
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.3.7.7 Transmit power-on and power-down ramp
The transmit power-on ramp for 10% to 90% of maximum power shall be no greater than 2 s. The transmit
power-on ramp is shown in Figure 16-11.
Max Tx Power
Transmit
Power 90% MAX
Output
10% MAX
0 1 2 3 4 Time s
Figure 16-11—Transmit power-on ramp
The transmit power-down ramp for 90% to 10% maximum power shall be no greater than 2 s. The transmit
power-down ramp is shown in Figure 16-12.
Max Tx Power
Transmit
90% MAX
Power
Output
10% MAX
0 1 2 3 4 Time s
Figure 16-12—Transmit power-down ramp
The transmit power ramps shall be constructed such that the HR/DSSS PHY emissions comply with
spurious frequency product specification defined in 16.3.6.7.
16.3.7.8 RF carrier suppression
The RF carrier suppression, measured at the channel center frequency, shall be at least 15 dB below the peak
sin(x)/x power spectrum. The RF carrier suppression shall be measured while transmitting a repetitive 01
data sequence with the scrambler disabled using DQPSK modulation. A 100 kHz resolution bandwidth shall
be used to perform this measurement.
2271
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.3.7.9 Transmit modulation accuracy
The transmit modulation accuracy requirement for the HR/DSSS PHY shall be based on the difference
between the actual transmitted waveform and the ideal signal waveform. Modulation accuracy shall be
determined by measuring the peak vector error magnitude during each chip period. Worst-case vector error
magnitude shall not exceeded 0.35 for the normalized sampled chip data. The ideal complex I and Q
constellation points associated with DQPSK modulation, (0.707, 0.707), (0.707, –0.707), (–0.707, 0.707),
(–0.707, –0.707), shall be used as the reference. These measurements shall be from baseband I and Q
sampled data after recovery through a reference receiver system.
Figure 16-13 illustrates the ideal DQPSK constellation points and range of worst-case error specified for
modulation accuracy.
Figure 16-13—Modulation accuracy measurement example
Error vector measurement requires a reference receiver capable of carrier lock. All measurements shall be
made under carrier lock conditions. The distortion induced in the constellation by the reference receiver
shall be calibrated and measured. The test data error vectors described below shall be corrected to
compensate for the reference receiver distortion.
The IEEE Std 802.11-compatible radio shall provide an exposed TX chip clock, which shall be used to
sample the I and Q outputs of the reference receiver.
The measurement shall be made under the conditions of continuous DQPSK transmission using scrambled
all 1s.
The eye pattern of the I channel shall be used to determine the I and Q sampling point. The chip clock
provided by the vendor radio shall be time delayed, such that the samples fall at a 1/2 chip period offset from
the mean of the zero crossing positions of the eye (see Figure 16-14). This is the ideal center of the eye and
might not be the point of maximum eye opening.
2272
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
1 Chip Period
Amplitude
Geometric
Center
Ideal Sample Points (1/2 chip period)
Time
Vendor
Chip Clock
Figure 16-14—Chip clock alignment with baseband eye pattern
Using the aligned chip clock, 1000 samples of the I and Q baseband outputs from the reference receiver are
captured. The vector error magnitudes shall be calculated as follows:
Calculate the dc offsets for I and Q samples
999
I mean = I n 1000
n=0
999
Q mean = Q n 1000
n=0
Calculate the dc corrected I and Q samples for all n = 1000 sample pairs
Idc(n) = I(n) – Imean
Qdc(n) = Q(n) – Qmean
Calculate the average magnitude of I and Q samples
999
I mag = I dc n 1000
n=0
999
Q mag = Q dc n 1000
n=0
2273
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Calculate the normalized error vector magnitude for the Idc(n)/Qdc(n) pairs
--1-
2 2 2
V err n = I dc n – I mag + Q dc n – Q mag – V correction
where
the average power of the constellation is 1
Vcorrection is the error induced by the reference receiver system
For all n = 1000 samples, the following condition shall be met:
Verr(n) < 0.35
16.3.7.10 Time of Departure accuracy
The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and
aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in
Annex P with the following test parameters:
fH – fL
— MULTICHANNEL_SAMPLING_RATE is 22 10 6 1 + -------------------
- sample/s
22 MHz
where
fH is the nominal center frequency in Hz of the highest channel in the channel set
fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel
set is the set of channels upon which frames providing measurements are transmitted, the
channel set comprises channels uniformly spaced across fH – fL 50 MHz
— FIRST_TRANSITION_FIELD is the SYNC field.
— SECOND_TRANSITION_FIELD is the SFD field.
— TRAINING_FIELD is the concatenation of the appropriate short or long SYNC and SFD fields,
using a chip pulse which should approximate a rectangular pulse of duration 1/ 11 MHz convolved
with a brick-wall low pass filter of bandwidth 11 MHz.
— TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns.
NOTE—The indicated chip pulse applies to the time of departure accuracy test equipment, and not the transmitter or
receiver.
16.3.8 PHY receiver specifications
16.3.8.1 Introduction
The receive functions and parameters associated with the PHY sublayer are described in 16.3.8.2 to
16.3.8.5.
16.3.8.2 Receiver minimum input level sensitivity
The FER shall be less than 8 10–2 at a PSDU length of 1024 octets for an input level of –76 dBm measured
at the antenna connector. This FER shall be specified for 11 Mb/s CCK modulation. The test for the
minimum input level sensitivity shall be conducted with the ED threshold set less than or equal to –76 dBm.
2274
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
16.3.8.3 Receiver maximum input level
The receiver shall provide a maximum FER of 8 10–2 at a PSDU length of 1024 octets for a maximum
input level of –10 dBm measured at the antenna. This FER shall be specified for 11 Mb/s CCK modulation.
16.3.8.4 Receiver adjacent channel rejection
Adjacent channel rejection is defined between any two channels with 25 MHz separation in each channel
group, as defined in 16.3.6.3.
The adjacent channel rejection shall be greater than or equal to than 35 dB, with an FER of 8 10–2 using
11 Mb/s CCK modulation described in 16.3.6.4 and a PSDU length of 1024 octets.
The adjacent channel rejection shall be measured using the following method.
Input an 11 Mb/s CCK modulated signal at a level 6 dB greater than specified in 16.3.8.2. In an adjacent
channel ( 25 MHz separation as defined by the channel numbering), input a signal modulated in a similar
fashion, which adheres to the transmit mask specified in 16.3.7.4, to a level 41 dB above the level specified
in 16.3.8.2. The adjacent channel signal shall be derived from a separate signal source. It shall not be a
frequency shifted version of the reference channel. Under these conditions, the FER shall be less than or
equal to 8 10–2.
16.3.8.5 CCA
The HR/DSSS PHY shall provide the capability to perform CCA according to both:
A — At least one of the following options:
— CCA Mode 1: Energy above threshold. CCA shall report a busy medium upon detecting any energy
above the ED threshold.
— CCA Mode 4: CS with timer. CCA shall start a timer whose duration is 3.65 ms and report a busy
medium only upon the detection of a HR/DSSS PHY signal. CCA shall report an IDLE medium
after the timer expires and no HR/DSSS PHY signal is detected. The 3.65 ms timeout is the duration
of the longest possible 5.5 Mb/s PSDU.
— CCA Mode 5: A combination of CS and energy above threshold. CCA shall report busy at least
while a HR/DSSS PPDU is being received with energy above the ED threshold at the antenna.
and
B — CCA Mode 6: CCA shall report a busy medium upon detection of any energy above –62 dBm.
A busy channel shall be indicated by issuing a PHY-CCA.indication(BUSY) primitive. A clear channel shall
be indicated by issuing a PHY-CCA.indication(IDLE) primitive.
dot11HRCCAModeSupported shall indicate the appropriate operation modes. The PHY shall be configured
through dot11CurrentCCAMode.
The CCA shall indicate a clear channel if there is no energy detect or CS. The CCA parameters are subject to
the following criteria:
a) If a valid HR/DSSS signal is detected during its preamble within the CCA window, the ED threshold
shall be less than or equal to –76 dBm for TX power > 100 mW; –73 dBm for 50 mW < TX power
100 mW; and –70 dBm for TX power 50 mW.
2275
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) With a valid signal (according to the CCA mode of operation) present at the receiver antenna within
5 s of the start of a MAC slot boundary, the PHY-CCA.indication(BUSY) primitive shall be
generated before the end of the slot time. Refer to Figure 10-19 (in 10.3.7) and Figure 10-26 for a
definition of slot boundary.
c) In the event that a correct PHY header is received, the HR/DSSS PHY shall not generate a PHY-
CCA.indication (IDLE) primitive until the end of the PPDU as determined by TXTIME in 16.3.4.
Upon reception of a correct PHY header, the timer of CCA Mode 4 shall be overridden by this
requirement.
Compliance to the HR/DSSS PHY CCA shall be demonstrated by applying an equivalent HR/DSSS signal
above the appropriate ED threshold (item a) so that all conditions described in item b and item c are
demonstrated.
16.3.8.6 Received Channel Power Indicator Measurement
The RCPI indicator is a measure of the received RF power in the selected channel for a received frame. This
parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire
received frame or by other equivalent means that meet the specified accuracy.
The RCPI encoding is defined in 9.4.2.38.
RCPI shall equal the received RF power within an accuracy of ±5 dB (95% confidence interval) within the
specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel bandwidth multiplied by 1.1.
2276
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17. Orthogonal frequency division multiplexing (OFDM) PHY specification
17.1 Introduction
17.1.1 General
This clause specifies the PHY entity for an orthogonal frequency division multiplexing (OFDM) system.
The OFDM system provides a WLAN with data payload communication capabilities of 6, 9, 12, 18, 24, 36,
48, and 54 Mb/s. The support of transmitting and receiving at data rates of 6, 12, and 24 Mb/s is mandatory.
The system uses 52 subcarriers that are modulated using binary or quadrature phase shift keying (BPSK or
QPSK) or using 16- or 64-quadrature amplitude modulation (16-QAM or 64-QAM). Forward error
correction coding (convolutional coding) is used with a coding rate of 1/2, 2/3, or 3/4.
The OFDM system also provides a “half-clocked” operation using 10 MHz channel spacings with data
communications capabilities of 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s. The support of transmitting and
receiving at data rates of 3, 6, and 12 Mb/s is mandatory when using 10 MHz channel spacing. The half-
clocked operation doubles symbol times and clear channel assessment (CCA) times when using 10 MHz
channel spacing. The regulatory requirements and information regarding use of this OFDM PHY are in
Annex D and Annex E.
The OFDM system also provides a “quarter-clocked” operation using 5 MHz channel spacing with data
communication capabilities of 1.5, 2.25, 3, 4.5, 6, 9, 12, and 13.5 Mb/s. The support of transmitting and
receiving at data rates of 1.5, 3, and 6 Mb/s is mandatory when using 5 MHz channel spacing. The quarter-
clocked operation quadruples symbol times and CCA times when using 5 MHz channel spacing. The
regulatory requirements and information regarding use of this OFDM PHY are in Annex D and Annex E.
17.1.2 Scope
Subclause 17.1 describes the PHY services provided to the IEEE 802.11 WLAN MAC by the OFDM PHY.
The OFDM PHY consists of the following protocol functions:
a) A function that defines a method of mapping the IEEE 802.11 PSDUs into a framing format suitable
for sending and receiving user data and management information between two or more STAs.
b) A function that defines the characteristics and method of transmitting and receiving data through a
WM between two or more STAs, each using the OFDM system.
17.1.3 OFDM PHY functions
17.1.3.1 General
The OFDM PHY architecture is depicted in the reference model shown in Figure 4-19 (in 4.9). The OFDM
PHY contains two functional entities: the PHY function and the layer management function. Each of these
functions is described in detail in 17.3 and 17.4.
The OFDM PHY service is provided to the MAC through the PHY service primitives described in Clause 8.
17.1.3.2 PLME
The PLME performs management of the local PHY functions in conjunction with the MLME.
2277
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.1.3.3 Service specification method
The models represented by figures and state diagrams are intended to be illustrations of the functions
provided. It is important to distinguish between a model and a real implementation. The models are
optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular
implementation.
The service of a layer or sublayer is the set of capabilities that it offers to a user in the next higher layer (or
sublayer). Abstract services are specified here by describing the service primitives and parameters that
characterize each service. This definition is independent of any particular implementation.
17.2 OFDM PHY specific service parameter list
17.2.1 Introduction
The architecture of the IEEE 802.11 MAC is intended to be PHY independent. Some PHY implementations
require medium management state machines running in the MAC sublayer in order to meet certain PHY
requirements. These PHY-dependent MAC state machines reside in a sublayer defined as the MLME. In
certain PHY implementations, the MLME may need to interact with the PLME as part of the normal PHY
SAP primitives. These interactions are defined by the PLME parameter list currently defined in the PHY
service primitives as TXVECTOR and RXVECTOR. The list of these parameters, and the values they may
represent, are defined in the specific PHY specifications for each PHY. Subclause 17.2 addresses the
TXVECTOR and RXVECTOR for the OFDM PHY.
17.2.2 TXVECTOR parameters
17.2.2.1 General
The parameters in Table 17-1 are defined as part of the TXVECTOR parameter list in the
PHY-TXSTART.request primitive.
Table 17-1—TXVECTOR parameters
Parameter Associated primitive Value
LENGTH PHY-TXSTART.request 1–4095
(TXVECTOR)
DATATRATE PHY-TXSTART.request 6, 9, 12, 18, 24, 36, 48, and 54 Mb/s for 20 MHz channel
(TXVECTOR) spacing (Support of 6, 12, and 24 Mb/s data rates is
mandatory.)
3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s for 10 MHz channel
spacing (Support of 3, 6, and 12 Mb/s data rates is mandatory.)
1.5, 2.25, 3, 4.5, 6, 9, 12, and 13.5 Mb/s for 5 MHz channel
spacing (Support of 1.5, 3, and 6 Mb/s data rates is mandatory.)
SERVICE PHY-TXSTART.request Null
(TXVECTOR)
TXPWR_LEVEL_IN PHY-TXSTART.request 1–8
DEX (TXVECTOR)
2278
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 17-1—TXVECTOR parameters (continued)
Parameter Associated primitive Value
TIME_OF_ PHY-TXSTART.request false, true. When true, the MAC entity requests that the PHY
DEPARTURE_ (TXVECTOR) entity measures and reports time of departure parameters
REQUESTED corresponding to the time when the first frame energy is sent by
the transmitting port; when false, the MAC entity requests that
the PHY entity neither measures nor reports time of departure
parameters.
CH_BANDWIDTH_ PHY-TXSTART.request If present, CBW20, CBW40, CBW80, CBW160, or
IN_NON_HT (TXVECTOR) CBW80+80
DYN_BANDWIDTH PHY-TXSTART.request If present, Static or Dynamic
_IN_NON_HT (TXVECTOR)
17.2.2.2 TXVECTOR LENGTH
The allowed values for the LENGTH parameter are in the range 1 to 4095. This parameter is used to indicate
the number of octets in the MPDU which the MAC is currently requesting the PHY to transmit. This value is
used by the PHY to determine the number of octet transfers that will occur between the MAC and the PHY
after receiving a request to start the transmission.
17.2.2.3 TXVECTOR DATARATE
The DATARATE parameter describes the bit rate at which the PHY shall transmit the PSDU. Its value takes
any of the rates defined in Table 17-1. Data rates of 6, 12, and 24 Mb/s shall be supported for 20 MHz
channel spacing, data rates of 3, 6, and 12 Mb/s shall be supported for 10 MHz channel spacing, and data
rates of 1.5, 3, and 6 Mb/s shall be supported for 5 MHz channel spacing; other rates may also be supported.
17.2.2.4 TXVECTOR SERVICE
The SERVICE parameter shall be null.
17.2.2.5 TXVECTOR TXPWR_LEVEL_INDEX
The allowed values for the TXPWR_LEVEL_INDEX parameter are in the range 1 to 8. This parameter is
used to indicate which of the available TxPowerLevel attributes defined in the MIB shall be used for the
current transmission.
17.2.2.6 TXVECTOR TIME_OF_DEPARTURE_REQUESTED
The allowed values are false or true. A parameter value of true indicates that the MAC sublayer is requesting
that the PHY entity provides measurement of when the first frame energy is sent by the transmitting port and
reporting within the PHY-TXSTART.confirm(TXSTATUS) primitive. A parameter value of false indicates
that the MAC sublayer is requesting that the PHY entity not provide time of departure measurement nor
reporting in the PHY-TXSTART.confirm(TXSTATUS) primitive.
17.2.2.7 TXVECTOR CH_BANDWIDTH_IN_NON_HT
If present, the allowed values for CH_BANDWIDTH_IN_NON_HT are CBW20, CBW40, CBW80,
CBW160, and CBW80+80. If present, this parameter is used to modify the first 7 bits of the scrambling
sequence to indicate the bandwidth of the non-HT duplicate PPDU.
2279
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—The CH_BANDWIDTH_IN_NON_HT parameter is not present when the frame is transmitted by a non-VHT
STA. The CH_BANDWIDTH_IN_NON_HT parameter is not present when the frame is transmitted by a VHT STA to a
non-VHT STA. See 10.7.11.
17.2.2.8 TXVECTOR DYN_BANDWIDTH_IN_NON_HT
If present, the allowed values for DYN_BANDWIDTH_IN_NON_HT are Static and Dynamic. If present,
this parameter is used to modify the first 7 bits of the scrambling sequence to indicate if the transmitter is
capable of Static or Dynamic bandwidth operation. If DYN_BANDWIDTH_IN_NON_HT is present, then
CH_BANDWIDTH_IN_NON_HT is also present.
NOTE—The DYN_BANDWIDTH_IN_NON_HT parameter is not present when the frame is transmitted by a non-
VHT STA. The DYN_BANDWIDTH_IN_NON_HT parameter is not present when the frame is transmitted by a VHT
STA to a non-VHT STA. See 10.7.11.
17.2.3 RXVECTOR parameters
17.2.3.1 General
The parameters listed in Table 17-2 are defined as part of the RXVECTOR parameter list in the
PHY-RXSTART.indication primitive.
Table 17-2—RXVECTOR parameters
Parameter Associated primitive Value
LENGTH PHY- 1–4095
RXSTART.indication
RSSI PHY- 0–RSSI maximum
RXSTART.indication
(RXVECTOR)
DATARATE PHY-RXSTART.request 6, 9, 12, 18, 24, 36, 48, and 54 Mb/s for 20 MHz channel
(RXVECTOR) spacing (Support of 6, 12, and 24 Mb/s data rates is
mandatory.)
3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s for 10 MHz channel
spacing (Support of 3, 6, and 12 Mb/s data rates is
mandatory.)
1.5, 2.25, 3, 4.5, 6, 9, 12, and 13.5 Mb/s for 5 MHz
channel spacing (Support of 1.5, 3, and 6 Mb/s data rates
is mandatory.)
SERVICE PHY-RXSTART.request Null
(RXVECTOR)
RCPI PHY- 0–255
(see NOTE) RXSTART.indication
(RXVECTOR)
PHY-RXEND.indication
(RXVECTOR)
ANT_STATE PHY- 0–255
(see NOTE) RXSTART.indication
(RXVECTOR)
PHY-RXEND.indication
(RXVECTOR)
2280
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 17-2—RXVECTOR parameters (continued)
Parameter Associated primitive Value
RX_START_OF_FRAM PHY- 0 to 232– 1. An estimate of the offset (in 10 ns units)
E_OFFSET RXSTART.indication from the point in time at which the start of the preamble
(RXVECTOR) corresponding to the incoming frame arrived at the
receive antenna connector to the point in time at which
this primitive is issued to the MAC.
CH_BANDWIDTH PHY-RXSTART.request If present, CBW20, CBW40, CBW80, CBW160, or
_IN_NON_HT (RXVECTOR) CBW80+80
DYN_BANDWIDTH PHY-RXSTART.request If present, Static or Dynamic
_IN_NON_HT (RXVECTOR)
NOTE—Parameter is present only when dot11RadioMeasurementActivated is true.
17.2.3.2 RXVECTOR LENGTH
The allowed values for the LENGTH parameter are in the range 1–4095. This parameter is used to indicate
the value contained in the LENGTH field which the PHY has received in the PHY header. The MAC and
PHY use this value to determine the number of octet transfers that will occur between the two sublayers
during the transfer of the received PSDU.
17.2.3.3 RXVECTOR RSSI
The allowed values for the RSSI parameter are in the range 0 to RSSI maximum. This parameter is a
measure by the PHY of the energy observed at the antenna used to receive the current PPDU. RSSI shall be
measured during the reception of the PHY preamble. RSSI is intended to be used in a relative manner, and it
shall be a monotonically increasing function of the received power.
17.2.3.4 RXVECTOR DATARATE
DATARATE shall represent the data rate at which the current PPDU was received. The allowed values of
the DATARATE are 6, 9, 12, 18, 24, 36, 48, or 54 Mb/s for 20 MHz channel spacing; 3, 4.5, 6, 9, 12, 18, 24,
or 27 Mb/s for 10 MHz channel spacing; and 1.5, 2.25, 3, 4.5, 6, 9, 12, or 13.5 Mb/s for 5 MHz channel
spacing.
17.2.3.5 RXVECTOR SERVICE
The SERVICE parameter shall be null.
17.2.3.6 RXVECTOR RCPI
The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 17.3.10.7. This parameter
is a measure by the PHY of the received channel power. RCPI indications of 8 bits are supported. RCPI shall
be measured over the entire received frame or by other equivalent means that meet the specified accuracy.
17.2.3.7 RXVECTOR CH_BANDWIDTH_IN_NON_HT
If present, the allowed values for CH_BANDWIDTH_IN_NON_HT are CBW20, CBW40, CBW80,
CBW160, and CBW80+80. If present and valid, this parameter indicates the bandwidth of the non-HT
duplicate PPDU. This parameter is used by the MAC only when valid (see 10.3.2.7 and 10.7.6.6).
2281
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—The CH_BANDWIDTH_IN_NON_HT parameter is not present when the frame is received by a non-VHT
STA (see 10.7.11).
17.2.3.8 RXVECTOR DYN_BANDWIDTH_IN_NON_HT
If present, the allowed values for DYN_BANDWIDTH_IN_NON_HT are Static and Dynamic. If present
and valid, this parameter indicates whether the transmitter is capable of Static or Dynamic bandwidth
operation. This parameter is used by the MAC only when valid (see 10.3.2.7 and 10.7.6.6). If
DYN_BANDWIDTH_IN_NON_HT is present, then CH_BANDWIDTH_IN_NON_HT is also present.
NOTE—The DYN_BANDWIDTH_IN_NON_HT parameter is not present when the frame is received by a non-VHT
STA (see 10.7.11).
17.2.4 TXSTATUS parameters
17.2.4.1 General
The parameters listed in Table 17-3 are defined as part of the TXSTATUS parameter list in the PHY-
TXSTART.confirm primitive.
Table 17-3—TXSTATUS parameters
Parameter Associated primitive Value
TIME_OF_DEPARTURE PHY- 0 to 232– 1. The locally measured time when
TXSTART.confirm the first frame energy is sent by the
(TXSTATUS) transmitting port, in units equal to 1/
TIME_OF_DEPARTURE_ClockRate. This
parameter is present only if
TIME_OF_DEPARTURE_REQUESTED is
true in the corresponding request.
TIME_OF_DEPARTURE_ClockRate PHY- 0 to 216– 1. The clock rate, in units of MHz, is
TXSTART.confirm used to generate the TIME_OF_DEPARTURE
(TXSTATUS) value. This parameter is present only if
TIME_OF_DEPARTURE_REQUESTED is
true in the corresponding request.
TX_START_OF_FRAME_OFFSET PHY- 0 to 232– 1. An estimate of the offset (in 10 ns
TXSTART.confirm units) from the point in time at which the start
(TXSTATUS) of the preamble corresponding to the frame
was transmitted at the transmit antenna
connector to the point in time at which this
primitive is issued to the MAC.
17.2.4.2 TXSTATUS TIME_OF_DEPARTURE
The allowed values for the TIME_OF_DEPARTURE parameter are integers in the range 0 to 232– 1. This
parameter is used to indicate when the first frame energy is sent by the transmitting port in units equal to 1/
TIME_OF_DEPARTURE_ClockRate. TIME_OF_DEPARTURE may be included in the transmitted frame
in order for recipients on multiple channels to determine the time differences of air propagation times
between transmitter and recipients and hence to compute the location of the transmitter.
17.2.4.3 TXSTATUS TIME_OF_DEPARTURE_ClockRate
TIME_OF_DEPARTURE_ClockRate indicates the clock rate used for TIME_OF_DEPARTURE.
2282
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3 OFDM PHY
17.3.1 Introduction
Subclause 17.3 provides a convergence procedure in which PSDUs are converted to and from PPDUs.
During transmission, the PSDU shall be provided with a PHY preamble and header to create the PPDU. At
the receiver, the PHY preamble and header are processed to aid in demodulation and delivery of the PSDU.
17.3.2 PPDU format
17.3.2.1 General
Figure 17-1 shows the format for the PPDU including the OFDM PHY preamble, OFDM PHY header,
PSDU, tail bits, and pad bits. The PHY header contains the following fields: LENGTH, RATE, a reserved
bit, an even parity bit, and the SERVICE field. In terms of modulation, the LENGTH, RATE, reserved bit,
and parity bit (with 6 zero tail bits appended) constitute a separate single OFDM symbol, denoted SIGNAL,
which is transmitted with the most robust combination of BPSK modulation and a coding rate of R = 1/2.
The SERVICE field of the PHY header and the PSDU (with 6 zero tail bits and pad bits appended), denoted
as DATA, are transmitted at the data rate described in the RATE field and may constitute multiple OFDM
symbols. The tail bits in the SIGNAL symbol enable decoding of the RATE and LENGTH fields
immediately after the reception of the tail bits. The RATE and LENGTH fields are required for decoding the
DATA part of the packet. In addition, the CCA mechanism is augmented by predicting the duration of the
packet from the contents of the RATE and LENGTH fields, even if the data rate is not supported by the
STA. Each of these fields is described in detail in 17.3.3, 17.3.4, and 17.3.5.
PHY Header
RATE Reserved LENGTH Parity Tail SERVICE Tail Pad Bits
PSDU
4 bits 1 bit 12 bits 1 bit 6 bits 16 bits 6 bits
Coded/OFDM Coded/OFDM
(BPSK, r = 1/2) (RATE is indicated in SIGNAL)
PHY Preamble SIGNAL DATA
12 Symbols One OFDM Symbol Variable Number of OFDM Symbols
Figure 17-1—PPDU format
17.3.2.2 Overview of the PPDU encoding process
The encoding process is composed of many detailed steps, which are described fully in later subclauses, as
noted below. The following overview intends to facilitate understanding the details of the convergence
procedure:
a) Produce the PHY Preamble field, composed of 10 repetitions of a “short training sequence” (used
for AGC convergence, diversity selection, timing acquisition, and coarse frequency acquisition in
the receiver) and two repetitions of a “long training sequence” (used for channel estimation and fine
frequency acquisition in the receiver), preceded by a guard interval (GI). Refer to 17.3.3 for details.
b) Produce the PHY header field from the RATE, LENGTH, and SERVICE fields of the TXVECTOR
by filling the appropriate bit fields. The RATE and LENGTH fields of the PHY header are encoded
by a convolutional code at a rate of R = 1/2, and are subsequently mapped onto a single BPSK
2283
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
encoded OFDM symbol, denoted as the SIGNAL symbol. In order to facilitate a reliable and timely
detection of the RATE and LENGTH fields, 6 zero tail bits are inserted into the PHY header. The
encoding of the SIGNAL field into an OFDM symbol follows the same steps for convolutional
encoding, interleaving, BPSK modulation, pilot insertion, Fourier transform, and prepending a GI as
described subsequently for data transmission with BPSK-OFDM modulated at coding rate 1/2. The
contents of the SIGNAL field are not scrambled. Refer to 17.3.4 for details.
c) Calculate from RATE field of the TXVECTOR the number of data bits per OFDM symbol (NDBPS),
the coding rate (R), the number of bits in each OFDM subcarrier (NBPSC), and the number of coded
bits per OFDM symbol (NCBPS). Refer to 17.3.2.3 for details.
d) Append the PSDU to the SERVICE field of the TXVECTOR. Extend the resulting bit string with
zero bits (at least 6 bits) so that the resulting length is a multiple of NDBPS. The resulting bit string
constitutes the DATA part of the packet. Refer to 17.3.5.4 for details.
e) If the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is not present, initiate the
scrambler with a pseudorandom nonzero seed and generate a scrambling sequence. If the
TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is present, construct the first 7 bits of
the scrambling sequence from CH_BANDWIDTH_IN_NON_HT,
DYN_BANDWIDTH_IN_NON_HT (if present), and a pseudorandom integer constrained such that
the first 7 bits of the scrambling sequence are not all 0s; then set the scrambler state to these 7 bits
and generate the remainder of the scrambling sequence. XOR the scrambling sequence with the
extended string of data bits. Refer to 17.3.5.5 for details.
f) Replace the six scrambled zero bits following the data with six nonscrambled zero bits. (Those bits
return the convolutional encoder to the zero state and are denoted as tail bits.) Refer to 17.3.5.3 for
details.
g) Encode the extended, scrambled data string with a convolutional encoder (R = 1/2). Omit (puncture)
some of the encoder output string (chosen according to “puncturing pattern”) to reach the “coding
rate” corresponding to the TXVECTOR parameter RATE. Refer to 17.3.5.6 for details.
h) Divide the encoded bit string into groups of NCBPS bits. Within each group, perform an
“interleaving” (reordering) of the bits according to a rule corresponding to the TXVECTOR
parameter RATE. Refer to 17.3.5.7 for details.
i) Divide the resulting coded and interleaved data string into groups of NBPSC bits. For each of the bit
groups, convert the bit group into a complex number according to the modulation encoding tables.
Refer to 17.3.5.8 for details.
j) Divide the complex number string into groups of 48 complex numbers. Each such group is
associated with one OFDM symbol. In each group, the complex numbers are numbered 0 to 47 and
mapped hereafter into OFDM subcarriers numbered –26 to –22, –20 to –8, –6 to –1, 1 to 6, 8 to 20,
and 22 to 26. The subcarriers –21, –7, 7, and 21 are skipped and, subsequently, used for inserting
pilot subcarriers. The 0 subcarrier, associated with center frequency, is omitted and filled with the
value 0. Refer to 17.3.5.10 for details.
k) Four subcarriers are inserted as pilots into positions –21, –7, 7, and 21. The total number of the
subcarriers is 52 (48 + 4). Refer to 17.3.5.9 for details.
l) For each group of subcarriers –26 to 26, convert the subcarriers to time domain using inverse
Fourier transform. Prepend to the Fourier-transformed waveform a circular extension of itself thus
forming a GI, and truncate the resulting periodic waveform to a single OFDM symbol length by
applying time domain windowing. Refer to 17.3.5.10 for details.
m) Append the OFDM symbols one after another, starting after the SIGNAL symbol describing the
RATE and LENGTH fields. Refer to 17.3.5.10 for details.
n) Upconvert the resulting “complex baseband” waveform to an RF according to the center frequency
of the operating channel and transmit. Refer to 17.3.2.5 and 17.3.8.2 for details.
2284
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An illustration of the transmitted frame and its parts appears in Figure 17-4 (in 17.3.3).
17.3.2.3 Modulation-dependent parameters
The modulation parameters dependent on the data rate used shall be set according to Table 17-4.
Table 17-4—Modulation-dependent parameters
Coded Data bits Data rate Data rate Data rate
Coded bits
Coding bits per per (Mb/s) (Mb/s) (Mb/s)
per
Modulation rate OFDM OFDM (20 MHz (10 MHz (5 MHz
subcarrier
(R) symbol symbol channel channel channel
(NBPSC)
(NCBPS) (NDBPS) spacing) spacing) spacing)
BPSK 1/2 1 48 24 6 3 1.5
BPSK 3/4 1 48 36 9 4.5 2.25
QPSK 1/2 2 96 48 12 6 3
QPSK 3/4 2 96 72 18 9 4.5
16-QAM 1/2 4 192 96 24 12 6
16-QAM 3/4 4 192 144 36 18 9
64-QAM 2/3 6 288 192 48 24 12
64-QAM 3/4 6 288 216 54 27 13.5
17.3.2.4 Timing-related parameters
Table 17-5 is the list of timing parameters associated with the OFDM PHY.
Table 17-5—Timing-related parameters
Value Value Value
Parameter (20 MHz channel (10 MHz channel (5 MHz channel
spacing) spacing) spacing)
NSD: Number of data subcarriers 48 48 48
NSP: Number of pilot subcarriers 4 4 4
NST: Number of subcarriers, 52 (NSD + NSP) 52 (NSD + NSP) 52 (NSD + NSP)
total
F: Subcarrier frequency 0.3125 MHz 0.156 25 MHz 0.078 125 MHz
spacing (=20 MHz/64) (= 10 MHz/64) (= 5 MHz/64)
TFFT: Inverse Fast Fourier 3.2 s (1/ F) 6.4 µs (1/ F) 12.8 µs (1/ F)
Transform (IFFT) / Fast Fourier
Transform (FFT) period
TPREAMBLE: PHY preamble 16 s (TSHORT + TLONG) 32 µs (TSHORT + TLONG) 64 µs (TSHORT + TLONG)
duration
2285
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 17-5—Timing-related parameters (continued)
Value Value Value
Parameter (20 MHz channel (10 MHz channel (5 MHz channel
spacing) spacing) spacing)
TSIGNAL: Duration of the 4.0 s (TGI + TFFT) 8.0 µs (TGI + TFFT) 16.0 µs (TGI + TFFT)
SIGNAL BPSK-OFDM symbol
TGI: GI duration 0.8 s (TFFT/4) 1.6 µs (TFFT/4) 3.2 µs (TFFT/4)
TGI2: Training symbol GI 1.6 s (TFFT/2) 3.2 µs (TFFT/2) 6.4 µs (TFFT/2)
duration
TSYM: Symbol interval 4 s (TGI + TFFT) 8 µs (TGI + TFFT) 16 µs (TGI + TFFT)
TSHORT: Short training sequence 8 s (10 TFFT /4) 16 µs (10 × TFFT/4) 32 µs (10 × TFFT/4)
duration
TLONG: Long training sequence 8 s (TGI2 + 2 TFFT) 16 µs (TGI2 + 2 × TFFT) 32 µs (TGI2 + 2 × TFFT)
duration
17.3.2.5 Mathematical conventions in the signal descriptions
The transmitted signals are described in a complex baseband signal notation. The actual transmitted signal is
related to the complex baseband signal by the following relation:
r RF t = Re{r t exp j2 f c t } (17-1)
where
fc denotes the carrier center frequency
The transmitted baseband signal is composed of contributions from several OFDM symbols.
r PACKET t = r PREAMBLE t + r SIGNAL t – t SIGNAL + r DATA t – t DATA (17-2)
The subframes of which Equation (17-2) are composed are described in 17.3.3, 17.3.4, and 17.3.5.10. The
time offsets tSUBFRAME determine the starting time of the corresponding subframe; tSIGNAL is equal to 16 s
for 20 MHz channel spacing, 32 s for 10 MHz channel spacing, and 64 s for 5 MHz channel spacing, and
tDATA is equal to 20 s for 20 MHz channel spacing, 40 s for 10 MHz channel spacing, and 80 s for
5 MHz channel spacing.
All of the subframes of the signal are constructed as an inverse Fourier transform of a set of coefficients, Ck,
with Ck defined later as data, pilots, or training symbols in 17.3.3 to 17.3.5.
N ST 2
r SUBFRAME t = w TSUBFRAME t C k exp j2 k f t – T GUARD (17-3)
k = – N ST 2
The parameters F and NST are described in Table 17-5. The resulting waveform is periodic with a period of
TFFT = 1/ F. Shifting the time by TGUARD creates the “circular prefix” used in OFDM to avoid ISI from the
previous frame. Three kinds of TGUARD are defined: for the short training sequence (= 0 s), for the long
training sequence (= TGI2), and for data OFDM symbols (= TGI). (Refer to Table 17-5.) The boundaries of
2286
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the subframe are set by a multiplication by a time-windowing function, wTSUBFRAME(t), which is defined as
a rectangular pulse, wT(t), of duration T, accepting the value TSUBFRAME. The time-windowing function,
wT(t), depending on the value of the duration parameter, T, may extend over more than one period, TFFT. In
particular, window functions that extend over multiple periods of the FFT are utilized in the definition of the
preamble. Figure 17-2 illustrates the possibility of extending the windowing function over more than one
period, TFFT, and additionally shows smoothed transitions by application of a windowing function, as
exemplified in Equation (17-4). In particular, window functions that extend over multiple periods of the FFT
are utilized in the definition of the preamble.
2
sin --- 0.5 + t T –T 2 t T 2
2 TR TR TR
w
T
t = 1 T
TR
2 t T–T
TR
2 (17-4)
2
sin --- 0.5 – t – T T T–T 2 t T+T 2
2 TR TR TR
In the case of vanishing TTR, the windowing function degenerates into a rectangular pulse of duration T. This
standard describes transmitted waveforms using a rectangular pulse shape. In a typical implementation, a
higher TTR is used in order to smooth the transitions between consecutive subsections. This creates a small
overlap between them, of duration TTR, as shown in Figure 17-2. The transition time, TTR, is about 100 ns.
Smoothing the transition is required in order to reduce the spectral sidelobes of the transmitted waveform.
However, the binding requirements are the spectral mask and modulation accuracy requirements, as detailed
in 17.3.9.3 and 17.3.9.7. Time domain windowing, as described here, is just one way to achieve those
objectives. The implementer may use other methods to achieve the same goal, such as frequency domain
filtering. Therefore, the transition shape and duration of the transition are informative parameters.
T = TGI+TFFT
TGUARD
=TGI TFFT
(a)
TTR TTR
T = TGI2+2TFFT
TGUARD
=TGI2 TFFT TFFT
(b)
TTR TTR
Figure 17-2—Illustration of OFDM frame with cyclic extension and windowing for
(a) single reception or (b) two receptions of the FFT period
2287
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.2.6 Discrete time implementation considerations
The following descriptions of the discrete time implementation are informational.
In a typical implementation, the windowing function is represented in discrete time. As an example, when a
windowing function with parameters T = 4.0 s and a TTR = 100 ns is applied, and the signal is sampled at
20 Msample/s, it becomes
1 1 n 79
w T n = w T nT S = 0.5 0 80 (17-5)
0 otherwise
The common way to implement the inverse Fourier transform, as shown in Equation (17-3), is by an IFFT
algorithm. If, for example, a 64-point IFFT is used, the coefficients 1 to 26 are mapped to the same
numbered IFFT inputs, while the coefficients –26 to –1 are copied into IFFT inputs 38 to 63. The rest of the
inputs, 27 to 37 and the 0 (dc) input, are set to 0. This mapping is illustrated in Figure 17-3. After performing
an IFFT, the output is cyclically extended and the resulting waveform is windowed to the required OFDM
symbol length.
Null 0 0
#1 1 1
#2 2 2
. .
. .
#26 26 IFFT 26
Null 27 27
Null . Time Domain Outputs
Null 37 37
#-26 38 38
. .
. .
#-2 62 62
#-1 63 63
Figure 17-3—Inputs and outputs of inverse Fourier transform
17.3.3 PHY preamble (SYNC)
The PHY Preamble field is used for synchronization. It consists of 10 short symbols and two long symbols
that are shown in Figure 17-4 and described in this subclause. The timings described in this subclause and
shown in Figure 17-4 are for 20 MHz channel spacing. They are doubled for half-clocked (i.e., 10 MHz)
channel spacing and are quadrupled for quarter-clocked (i.e., 5 MHz) channel spacing.
Figure 17-4 shows the OFDM training structure (PHY preamble), where t1 to t10 denote short training
symbols and T1 and T2 denote long training symbols. The PHY preamble is followed by the SIGNAL field
and DATA. The total training length is 16 s. The dashed boundaries in the figure denote repetitions due to
the periodicity of the inverse Fourier transform.
2288
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8 + 8 = 16 s
10 0.8 = 8 s 2 0.8 + 2 3.2 = 8.0 s 0.8 +3.2 = 4.0 s 0.8 + 3.2 = 4.0 s 0.8 + 3.2 = 4.0 s
t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 GI2 T1 T2 GI SIGNAL GI Data 1 GI Data 2
Signal Detect, Coarse Freq. RATE
Channel and Fine Frequency SERVICE + DATA DATA
AGC, Diversity Offset Estimation Offset Estimation LENGTH
Selection timing synchronize
Figure 17-4—OFDM training structure
A short OFDM training symbol consists of 12 subcarriers, which are modulated by the elements of the
sequence S, given by
S–26, 26 = (13/6) {0, 0, 1+j, 0, 0, 0, –1–j, 0, 0, 0, 1+j, 0, 0, 0, –1–j, 0, 0, 0, –1–j, 0, 0, 0, 1+j, 0, 0, 0, 0,
0, 0, 0, –1–j, 0, 0, 0, –1–j, 0, 0, 0, 1+j, 0, 0, 0, 1+j, 0, 0, 0, 1+j, 0, 0, 0, 1+j, 0,0} (17-6)
The multiplication by a factor of (13/6) is in order to normalize the average power of the resulting OFDM
symbol, which utilizes 12 out of 52 subcarriers.
The signal shall be generated according to the following equation:
N ST 2
r SHORT t = w TSHORT t S k exp j2 k Ft (17-7)
k = – N ST 2
The fact that only spectral lines of S–26:26 with indices that are a multiple of 4 have nonzero amplitude
results in a periodicity of TFFT/4 = 0.8 s. The interval TSHORT is equal to ten 0.8 s periods (i.e., 8 s).
Generation of the short training sequence is illustrated in Table I-2.
A long OFDM training symbol consists of 53 subcarriers (including the value 0 at dc), which are modulated
by the elements of the sequence L, given by
L–26, 26 = {1, 1, –1, –1, 1, 1, –1, 1, –1, 1, 1, 1, 1, 1, 1, –1, –1, 1, 1, –1, 1, –1, 1, 1, 1, 1, 0,
1, –1, –1, 1, 1, –1, 1, –1, 1, –1, –1, –1, –1, –1, 1, 1, –1, –1, 1, –1, 1, –1, 1, 1, 1, 1} (17-8)
A long OFDM training symbol shall be generated according to the following equation:
N ST 2
r LONG t = w TLONG t L k exp (j2 k F t – T G 12 ) (17-9)
k = – N ST 2
where
TG 12 = 1.6 s
Two periods of the long sequence are transmitted for improved channel estimation accuracy, yielding
TLONG = 1.6 + 2 3.2 = 8 s.
2289
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An illustration of the long training sequence generation is given in Table I-5.
The sections of short repetitions and long repetitions shall be concatenated to form the preamble
r PREAMBLE t = r SHORT t + r LONG t – T SHORT (17-10)
17.3.4 SIGNAL field
17.3.4.1 General
The OFDM training symbols shall be followed by the SIGNAL field, which contains the RATE and the
LENGTH fields of the TXVECTOR. The RATE field conveys information about the type of modulation
and the coding rate as used in the rest of the packet. The encoding of the SIGNAL single OFDM symbol
shall be performed with BPSK modulation of the subcarriers and using convolutional coding at R = 1/2. The
encoding procedure, which includes convolutional encoding, interleaving, modulation mapping processes,
pilot insertion, and OFDM modulation, follows the steps described in 17.3.5.6, 17.3.5.7, and 17.3.5.9, as
used for transmission of data with BPSK-OFDM modulated at coding rate 1/2. The contents of the SIGNAL
field are not scrambled.
The SIGNAL field shall be composed of 24 bits, as illustrated in Figure 17-5. The four bits 0 to 3 shall
encode the RATE. Bit 4 shall be reserved for future use. Bits 5–16 shall encode the LENGTH field of the
TXVECTOR, with the LSB being transmitted first.
RATE LENGTH SIGNAL TAIL
(4 bits) (12 bits) (6 bits)
R1 R2 R3 R4 R LSB MSB P “0” “0” “0” “0” “0” “0”
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Transmit Order
Figure 17-5—SIGNAL field bit assignment
The process of generating the SIGNAL OFDM symbol is illustrated in I.1.4.
17.3.4.2 RATE field
The bits R1–R4 shall be set, dependent on RATE, according to the values in Table 17-6.
Table 17-6—Contents of the SIGNAL field
Rate (Mb/s) Rate (Mb/s) Rate (Mb/s)
R1–R4 (20 MHz channel (10 MHz channel (5 MHz channel
spacing) spacing) spacing)
1101 6 3 1.5
1111 9 4.5 2.25
0101 12 6 3
0111 18 9 4.5
1001 24 12 6
2290
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 17-6—Contents of the SIGNAL field (continued)
Rate (Mb/s) Rate (Mb/s) Rate (Mb/s)
R1–R4 (20 MHz channel (10 MHz channel (5 MHz channel
spacing) spacing) spacing)
1011 36 18 9
0001 48 24 12
0011 54 27 13.5
17.3.4.3 PHY LENGTH field
The PHY LENGTH field shall be an unsigned 12-bit integer that indicates the number of octets in the PSDU
that the MAC is currently requesting the PHY to transmit. This value is used by the PHY to determine the
number of octet transfers that will occur between the MAC and the PHY after receiving a request to start
transmission. The transmitted value shall be determined from the LENGTH parameter in the TXVECTOR
issued with the PHY-TXSTART.request primitive described in 8.3.5.5. The LSB shall be transmitted first in
time. This field shall be encoded by the convolutional encoder described in 17.3.5.6.
17.3.4.4 Parity (P), Reserved (R), and SIGNAL TAIL fields
Bit 4 is reserved. It shall be set to 0 on transmit and ignored on receive. Bit 17 shall be a positive parity (even
parity) bit for bits 0–16. The bits 18–23 constitute the SIGNAL TAIL field, and all 6 bits shall be set to 0.
17.3.5 DATA field
17.3.5.1 General
The DATA field contains the SERVICE field, the PSDU, the TAIL bits, and the PAD bits, if needed, as
described in 17.3.5.3 and 17.3.5.4. All bits in the DATA field are scrambled, as described in 17.3.5.5.
17.3.5.2 SERVICE field
The SERVICE field has 16 bits, which shall be denoted as bits 0–15. The bit 0 shall be transmitted first in
time. The bits from 0–6 of the SERVICE field, which are transmitted first, are set to 0s and are used to
synchronize the descrambler in the receiver. The remaining 9 bits (7–15) of the SERVICE field shall be
reserved for future use. All reserved bits shall be set to 0 on transmission and ignored on reception. Refer to
Figure 17-6.
Scrambler Initialization Reserved SERVICE Bits R: Reserved
“0” “0” “0” “0” “0” “0” “0” R R R R R R R R R
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Transmit Order
Figure 17-6—SERVICE field bit assignment
2291
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.5.3 PPDU TAIL field
The PPDU TAIL field shall be six bits of 0, which are required to return the convolutional encoder to the
zero state. This procedure improves the error probability of the convolutional decoder, which relies on future
bits when decoding and which may be not be available past the end of the message. The PPDU TAIL field
shall be produced by replacing six scrambled zero bits following the message end with six nonscrambled
zero bits.
17.3.5.4 Pad bits (PAD)
The number of bits in the DATA field shall be a multiple of NCBPS, the number of coded bits in an OFDM
symbol (48, 96, 192, or 288 bits). To achieve that, the length of the message is extended so that it becomes a
multiple of NDBPS, the number of data bits per OFDM symbol. At least 6 bits are appended to the message,
in order to accommodate the TAIL bits, as described in 17.3.5.3. The number of OFDM symbols, NSYM; the
number of bits in the DATA field, NDATA; and the number of pad bits, NPAD, are computed from the length
of the PSDU (LENGTH) as follows:
N SYM = 16 + 8 LENGTH + 6-
------------------------------------------------------ (17-11)
N DBPS
NDATA = NSYM NDBPS (17-12)
NPAD = NDATA – (16 + 8 LENGTH + 6) (17-13)
The appended bits (“pad bits”) are set to 0 and are subsequently scrambled with the rest of the bits in the
DATA field.
An example of a DATA field that contains the SERVICE field, DATA, tail, and pad bits is given in
I.1.5.1.
17.3.5.5 PHY DATA scrambler and descrambler
The DATA field, composed of SERVICE, PSDU, tail, and pad parts, shall be scrambled with a length-127
PPDU-synchronous scrambler. The octets of the PSDU are placed in the transmit serial bit stream, bit 0 first
and bit 7 last. The PPDU synchronous scrambler uses the generator polynomial S(x) as follows and is
illustrated in Figure 17-7:
7 4
S x = x +x +1 (17-14)
During bits 0-6 of Scrambling Sequence
when CH_BANDWIDTH_IN_NON_HT is
First 7 bits of Scrambling present
Sequence as defined in
Table 17-7
Data In
X7 X6 X5 X4 X3 X2 X 1
Scrambled
Data Out
Figure 17-7—Data scrambler
2292
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The 127-bit sequence generated repeatedly by the scrambler shall be (leftmost used first), 00001110
11110010 11001001 00000010 00100110 00101110 10110110 00001100 11010100 11100111 10110100
00101010 11111010 01010001 10111000 1111111, when the all 1s initial state is used. The same scrambler
is used to scramble transmit data and to descramble receive data. If the TXVECTOR parameter
CH_BANDWIDTH_IN_NON_HT is not present, when transmitting, the initial state of the scrambler shall
be set to a pseudorandom nonzero state. If the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is
present,
— The first 7 bits of the scrambling sequence shall be set as shown in Table 17-7 (with field values
defined in Table 17-8 and Table 17-10) and shall be also used to initialize the state of the scrambler
— The scrambler with this initialization shall generate the remainder (i.e., after the first 7 bits) of the
scrambling sequence as shown in Figure 17-7
— CH_BANDWIDTH_IN_NON_HT is transmitted LSB first. For example, if CBW80 has a value
of 2, which is ‘10’ in binary representation, then B5=0 and B6=1
Table 17-7—Contents of the first 7 bits of the scrambling sequence
First 7 bits of scrambling sequence
B0 B3 B4 B5 B6
Parameter Condition
Transmit order
TXVECTOR CH_BANDWIDTH_I 5-bit pseudorandom nonzero integer if CH_BANDWIDTH_
N_NON_HT is CH_BANDWIDTH_IN_NON_HT equals CBW20 IN_NON_HT
present and and a 5-bit pseudorandom integer otherwise
DYN_BANDWIDTH
_IN_NOT_HT is not
present in
TXVECTOR
TXVECTOR CH_BANDWIDTH_I 4-bit pseudorandom DYN_BANDWIDTH
N_NON_HT is nonzero integer if _IN_NON_HT
present and CH_BANDWIDTH_IN_
DYN_BANDWIDTH NON_HT equals CBW20
_IN_NOT_HT is and
present in DYN_BANDWIDTH_IN
TXVECTOR _NON_HT equals Static,
and a 4-bit pseudorandom
integer otherwise
RXVECTOR CH_BANDWIDTH_I — DYN_BANDWIDTH CbwInNonHtTemp is
N_NON_HT and _IN_NON_HT set to this subfield of
DYN_BANDWIDTH first 7 bits of
_IN_NOT_HT are scrambling sequence;
present in then
RXVECTOR CbwInNonHtTemp
is mapped according
to Table 17-9 to
CH_BANDWIDTH_
IN_NON_HT
2293
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 17-8—TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values
Enumerated value Value
CBW20 0
CBW40 1
CBW80 2
CBW160 or CBW80+80 3
During reception by a VHT STA, the CbwInNonHtTemp variable shall be set to selected bits in the
scrambling sequence as shown in Table 17-7 and then mapped as shown in Table 17-9 to the RXVECTOR
parameter CH_BANDWIDTH_IN_NON_HT. During reception by a VHT STA, the RXVECTOR
parameter DYN_BANDWIDTH_IN_NON_HT shall be set to selected bits in the scrambling sequence as
shown in Table 17-7. The fields shall be interpreted as being sent LSB-first.
Table 17-9—RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values
CbwInNonHtTemp dot11CurrentChannelCenter RXVECTOR parameter
(see Table 17-7) FrequencyIndex1 CH_BANDWIDTH_IN_NON_HT
0 0 CBW20
1 0 CBW40
2 0 CBW80
3 0 CBW160
3 1 to 200 CBW80+80
Table 17-10—DYN_BANDWIDTH_IN_NON_HT values
Enumerated value Value
Static 0
Dynamic 1
NOTE 1—The receiving PHY cannot determine whether the CH_BANDWIDTH_IN_NON_HT and
DYN_BANDWIDTH_IN_NON_HT parameters were present in the TXVECTOR of the transmitting PHY; therefore,
the receiving PHY in a VHT STA always includes values for the CH_BANDWIDTH_IN_NON_HT and
DYN_BANDWIDTH_IN_NON_HT parameters in the RXVECTOR if the detected PPDU is a non-HT PPDU. It is the
responsibility of the MAC to determine the validity of the RXVECTOR parameters CH_BANDWIDTH_IN_NON_HT
and DYN_BANDWIDTH_IN_NON_HT.
NOTE 2—The receiving PHY cannot determine whether the TXVECTOR parameter
CH_BANDWIDTH_IN_NON_HT was present, but it does not matter since descrambling the DATA field is the same
either way.
2294
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The seven LSBs of the SERVICE field shall be set to all 0s prior to scrambling to enable estimation of the
initial state of the scrambler in the receiver.
An example of the scrambler output is illustrated in I.1.5.2 with CH_BANDWIDTH_IN_NON_HT not
present.
17.3.5.6 Convolutional encoder
The DATA field, composed of SERVICE, PSDU, tail, and pad parts, shall be coded with a convolutional
encoder of coding rate R = 1/2, 2/3, or 3/4, corresponding to the TXVECTOR parameter RATE. The
convolutional encoder shall use the industry-standard generator polynomials, g0 = 1338 and g1 = 1718, of
rate R = 1/2, as shown in Figure 17-8. The bit denoted as “A” shall be output from the encoder before the bit
denoted as “B.” Higher rates are derived from it by employing “puncturing.” Puncturing is a procedure for
omitting some of the encoded bits in the transmitter (thus reducing the number of transmitted bits and
increasing the coding rate) and inserting a dummy “zero” metric into the convolutional decoder on the
receive side in place of the omitted bits. The puncturing patterns are illustrated in Figure 17-9. Decoding by
the Viterbi algorithm is recommended.
An example of encoding operation is shown in I.1.6.1.
Figure 17-8—Convolutional encoder (k = 7)
2295
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Punctured Coding (r = 3/4)
Source Data X0 X1 X2 X3 X4 X5 X6 X7 X8
A0 A1 A2 A3 A4 A5 A6 A7 A8
Encoded Data Stolen Bit
B0 B1 B2 B3 B4 B5 B6 B7 B8
Bit Stolen Data
(sent/received data) A0 B0 A1 B2 A3 B3 A4 B5 A6 B6 A7 B8
A0 A1 A2 A3 A4 A5 A6 A7 A8
Bit Inserted Data Inserted Dummy Bit
B0 B1 B2 B3 B4 B5 B6 B7 B8
Decoded Data y0 y1 y2 y3 y4 y5 y6 y7 y8
Punctured Coding (r = 2/3)
Source Data X0 X1 X2 X3 X4 X5
A0 A1 A2 A3 A4 A5
Encoded Data Stolen Bit
B0 B1 B2 B3 B4 B5
Bit Stolen Data
(sent/received data) A0 B0 A1 A2 B2 A3 A4 B4 A5
A0 A1 A2 A3 A4 A5
Bit Inserted Data Inserted Dummy Bit
B0 B1 B2 B3 B4 B5
Decoded Data y0 y1 y2 y3 y4 y5
Figure 17-9—Example of the bit-stealing and bit-insertion procedure (r = 3/4, 2/3)
2296
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.5.7 Data interleaving
All encoded data bits shall be interleaved by a block interleaver with a block size corresponding to the
number of bits in a single OFDM symbol, NCBPS. The interleaver is defined by a two-step permutation. The
first permutation causes adjacent coded bits to be mapped onto nonadjacent subcarriers. The second causes
adjacent coded bits to be mapped alternately onto less and more significant bits of the constellation and,
thereby, long runs of low reliability (LSB) bits are avoided.
The index of the coded bit before the first permutation shall be denoted by k; i shall be the index after the
first and before the second permutation; and j shall be the index after the second permutation, just prior to
modulation mapping.
The first permutation is defined by the rule
i = (NCBPS/16) (k mod 16) + k 16 k = 0,1,…,NCBPS – 1 (17-15)
The second permutation is defined by the rule
-i + i + N CBPS – ---------------
j= s 16 i mod s i = 0,1,… NCBPS – 1 (17-16)
s N CBPS
The value of s is determined by the number of coded bits per subcarrier, NBPSC, according to
s = max(NBPSC/2,1) (17-17)
The deinterleaver, which performs the inverse relation, is also defined by two permutations.
Here the index of the original received bit before the first permutation shall be denoted by j; i shall be the
index after the first and before the second permutation; and k shall be the index after the second permutation,
just prior to delivering the coded bits to the convolutional (Viterbi) decoder.
The first permutation is defined by the rule
i = s 16 j-
j s + j + -------------- mod s j = 0,1,… NCBPS – 1 (17-18)
N CBPS
where
s is defined in Equation (17-17).
This permutation is the inverse of the permutation described in Equation (17-16).
The second permutation is defined by the rule
k = 16 i – N CBPS – 1 16 i- , i = 0,1,… N
-------------- CBPS – 1 (17-19)
N CBPS
This permutation is the inverse of the permutation described in Equation (17-15).
An example of interleaving operation is illustrated in I.1.6.2.
2297
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.5.8 Subcarrier modulation mapping
The OFDM subcarriers shall be modulated by using BPSK, QPSK, 16-QAM, or 64-QAM, depending on the
RATE requested. The encoded and interleaved binary serial input data shall be divided into groups of NBPSC
(1, 2, 4, or 6) bits and converted into complex numbers representing BPSK, QPSK, 16-QAM, or 64-QAM
constellation points. The conversion shall be performed according to Gray-coded constellation mappings,
illustrated in Figure 17-10, with the input bit, B0, being the earliest in the stream. The output values, d, are
formed by multiplying the resulting (I+jQ) value by a normalization factor KMOD, as described in
Equation (17-20).
d = (I + jQ) KMOD (17-20)
The normalization factor, KMOD, depends on the base modulation mode, as prescribed in Table 17-11. Note
that the modulation type can be different from the start to the end of the transmission, as the signal changes
from SIGNAL to DATA, as shown in Figure 17-1. The purpose of the normalization factor is to achieve the
same average power for all mappings. In practical implementations, an approximate value of the
normalization factor may be used, as long as the device complies with the modulation accuracy requirements
described in 17.3.9.7.
Table 17-11—Modulation-dependent normalization factor KMOD
Modulation KMOD
BPSK 1
QPSK 1/ 2
16-QAM 1/ 10
64-QAM 1/ 2
2298
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
BPSK Q 16-QAM Q B0 B1 B2 B3
B0
+1
00 10 01 10 11 10 10 10
0 1 +3
–1 +1
I
–1 00 11 01 11 11 11 10 11
+1
–3 –1 +1 +3
I
QPSK 00 01 01 01 11 01 10 01
Q B0 B1 –1
01 11
+1
00 00 01 00 11 00 10 00
–3
–1 +1
00 10 I
–1
64-QAM Q B0B1B2 B3B4B5
000 100 001 100 011 100 010 100 110 100 111 100 101 100 100 100
+7
000 101 001 101 011 101 010 101 110 101 111 101 101 101 100 101
+5
000 111 001 111 011 111 010 111 110 111 111 111 101 111 100 111
+3
000 110 001 110 011 110 010 110 110 110 111 110 101 110 100 110
+1
–7 –5 –3 –1 +1 +3 +5 +7
000 010 001 010 011 010 010 010 110 010 111 010 101 010 100 010
I
–1
000 011 001 011 011 011 010 011 110 011 111 011 101 011 100 011
–3
000 001 001 001 011 001 010 001 110 001 111 001 101 001 100 001
–5
000 000 001 000 011 000 010 000 110 000 111 000 101 000 100 000
–7
Figure 17-10—BPSK, QPSK, 16-QAM, and 64-QAM constellation bit encoding
2299
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For BPSK, B0 determines the I value, as illustrated in Table 17-12. For QPSK, B0 determines the I value and
B1 determines the Q value, as illustrated in Table 17-13. For 16-QAM, B0B1 determines the I value and
B2B3 determines the Q value, as illustrated in Table 17-14. For 64-QAM, B0B1B2 determines the I value
and B3B4B5 determines the Q value, as illustrated in Table 17-15.
Table 17-12—BPSK encoding table
Input bit (B0) I-out Q-out
0 –1 0
1 1 0
Table 17-13—QPSK encoding table
Input bit (B0) I-out Input bit (B1) Q-out
0 –1 0 –1
1 1 1 1
Table 17-14—16-QAM encoding table
Input bits (B0 B1) I-out Input bits (B2 B3) Q-out
00 –3 00 –3
01 –1 01 –1
11 1 11 1
10 3 10 3
Table 17-15—64-QAM encoding table
Input bits (B0 B1 B2) I-out Input bits (B3 B4 B5) Q-out
000 –7 000 –7
001 –5 001 –5
011 –3 011 –3
010 –1 010 –1
110 1 110 1
111 3 111 3
101 5 101 5
100 7 100 7
2300
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.5.9 Pilot subcarriers
In each OFDM symbol, four of the subcarriers are dedicated to pilot signals in order to make the coherent
detection robust against frequency offsets and phase noise. These pilot signals shall be put in subcarriers
–21, –7, 7, and 21. The pilots shall be BPSK modulated by a pseudo-binary sequence to prevent the
generation of spectral lines. The contribution of the pilot subcarriers to each OFDM symbol is described in
17.3.5.10.
17.3.5.10 OFDM modulation
The stream of complex numbers is divided into groups of NSD = 48 complex numbers. This shall be denoted
by writing the complex number dk,n, which corresponds to subcarrier k of OFDM symbol n, as follows:
dk n d k + N SD n, k = 0, ... NSD – 1, n = 0, ... NSYM – 1 (17-21)
The number of OFDM symbols, NSYM, was introduced in 17.3.5.4.
An OFDM symbol, rDATA,n(t), is defined as
N SD – 1
r DATA n t = w TSYM t d k n exp (j2 M k F t – T GI (17-22)
k=0
N ST 2
+ pn + 1 P k exp j2 k F t – T GI
k = – N ST 2
where the function, M(k), defines a mapping from the logical subcarrier number 0 to 47 into frequency offset
index –26 to 26, while skipping the pilot subcarrier locations and the 0th (dc) subcarrier.
k – 26 0 k 4
k – 25 5 k 17
M k = k – 24 18 k 23 (17-23)
k – 23 24 k 29
k – 22 30 k 42
k – 21 43 k 47
The contribution of the pilot subcarriers for the nth OFDM symbol is produced by inverse Fourier transform
of sequence P, given by
P–26, 26 = {0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, –1, 0, 0, 0, 0, 0} (17-24)
2301
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The polarity of the pilot subcarriers is controlled by the sequence, pn, which is a cyclic extension of the
127 elements sequence and is given by
p0..126v = {1,1,1,1, –1,–1,–1,1, –1,–1,–1,–1, 1,1,–1,1, –1,–1,1,1, –1,1,1,–1, 1,1,1,1, 1,1,–1,1,
1,1,–1,1, 1,–1,–1,1, 1,1,–1,1, –1,–1,–1,1, –1,1,–1,–1, 1,–1,–1,1, 1,1,1,1, –1,–1,1,1,
–1,–1,1,–1, 1,–1,1,1, –1,–1,–1,1, 1,–1,–1,–1, –1,1,–1,–1, 1,–1,1,1, 1,1,–1,1, –1,1,–1,1,
–1,–1,–1,–1, –1,1,–1,1, 1,–1,1,–1, 1,1,1,–1, –1,1,–1,–1, –1,1,1,1, –1,–1,–1,–1, –1,–1,–1} (17-25)
The sequence pn is generated by the scrambler defined by Figure 17-7 when the all 1s initial state is used,
and by replacing all 1s with –1 and all 0s with 1. Each sequence element is used for one OFDM symbol. The
first element, p0, multiplies the pilot subcarriers of the SIGNAL symbol, while the elements from p1 on are
used for the DATA symbols.
The subcarrier frequency allocation is shown in Figure 17-11. To avoid difficulties in D/A and A/D
converter offsets and carrier feedthrough in the RF system, the subcarrier falling at DC (0th subcarrier) is not
used.
d0 d4 P–21 d5 d17P–7 d18 d23DC d24 d29 P7 d30 d42 P21 d43 d47
–26 –21 –7 0 7 21 26
Subcarrier Numbers
Figure 17-11—Subcarrier frequency allocation
The concatenation of NSYM OFDM symbols is written as
N SYM – 1
r DATA t = r DATA n t – nT SYM (17-26)
n=0
An example of mapping into symbols is shown in I.1.6.3, as well as the scrambling of the pilot signals (see
I.1.7). The final output of these operations is also shown in I.1.8.
17.3.6 CCA
The PHY shall provide the capability to perform CCA and report the result to the MAC. The CCA
mechanism shall detect a “medium busy” condition with requirements specified in 17.3.10.6 and 17.3.12.
The PHY issues the PHY-CCA.indication primitive to provide this medium status report to the MAC.
17.3.7 PHY data modulation and modulation rate change
The PHY preamble shall be transmitted using an OFDM modulated fixed waveform. The SIGNAL field,
BPSK-OFDM modulated with coding rate 1/2, shall indicate the modulation and coding rate that shall be
used to transmit the MPDU. The transmitter (receiver) shall initiate the modulation (demodulation)
constellation and the coding rate according to the RATE indicated in the SIGNAL field. The MPDU
transmission rate shall be set by the DATARATE parameter in the TXVECTOR, issued with the PHY-
TXSTART.request primitive described in 17.2.2.
2302
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.8 PHY operating specifications (general)
17.3.8.1 General
General specifications for the BPSK OFDM, QPSK OFDM, 16-QAM OFDM, and 64-QAM OFDM PHY
sublayers are provided in 17.3.8.2 to 17.3.8.7. These specifications apply to both the receive and transmit
functions and general operation of the OFDM PHY.
17.3.8.2 Outline description
The general block diagram of the transmitter and receiver for the OFDM PHY is shown in Figure 17-12.
Major specifications for the OFDM PHY are listed in Table 17-16.
Interleaving+ Symbol
FEC IFFT GI Wave I/Q
Coder Mapping Addition Mod.
Shaping
HPA
AGC Amp
I/Q Remove Demapping+ FEC
Det. FFT Deinterleaving
GI Decoder
LNA
Rx Lev. Det. AFC
Clock Recovery
Figure 17-12—Transmitter and receiver block diagram for the OFDM PHY
Table 17-16—Major parameters of the OFDM PHY
6, 9, 12, 18, 24, 36, 48, 3, 4.5, 6, 9, 12, 18, 24, 1.5, 2.25, 3, 4.5, 6, 9, 12,
and 54 Mb/s and 27 Mb/s and 13.5 Mb/s
(6, 12, and 24 Mb/s are (3, 6, and 12 Mb/s are (1.5, 3, and 6 Mb/s are
Information data rate
mandatory) mandatory) mandatory)
(20 MHz channel (10 MHz channel (5 MHz channel
spacing) spacing) spacing)
Modulation BPSK OFDM BPSK OFDM BPSK OFDM
QPSK OFDM QPSK OFDM QPSK OFDM
16-QAM OFDM 16-QAM OFDM 16-QAM OFDM
64-QAM OFDM 64-QAM OFDM 64-QAM OFDM
Error correcting code K = 7 (64 states) K = 7 (64 states) K = 7 (64 states)
convolutional code convolutional code convolutional code
Coding rate 1/2, 2/3, 3/4 1/2, 2/3, 3/4 1/2, 2/3, 3/4
Number of subcarriers 52 52 52
OFDM symbol duration 4.0 µs 8.0 µs 16.0 µs
GI 0.8 µsa (TGI) 1.6 µs (TGI) 3.2 µs (TGI)
Occupied bandwidth 16.6 MHz 8.3 MHz 4.15 MHz
aRefer
to 17.3.2.5.
2303
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.8.3 Regulatory requirements
WLANs implemented in accordance with this standard are subject to equipment certification and operating
requirements established by regional and national regulatory administrations. The PHY specification
establishes minimum technical requirements for interoperability, based upon established regulations at the
time this standard was issued. These regulations are subject to revision, or may be superseded. Requirements
that are subject to local geographic regulations are annotated within the PHY specification. Regulatory
requirements that do not affect interoperability are not addressed in this standard. Implementers are referred
to the regulatory sources in Annex D for further information. Operation in countries within defined
regulatory domains may be subject to additional or alternative national regulations.
17.3.8.4 Operating channel frequencies
17.3.8.4.1 Operating frequency range
The OFDM PHY shall not operate in frequency bands not allocated by a regulatory body in its operational
region. Regulatory requirements for a given frequency band are set by the regulatory authority responsible
for spectrum management in a given geographic region or domain. The particular channelization to be used
for this standard is dependent on such allocation, as well as the associated regulations for use of the
allocations. These regulations are subject to revision, or may be superseded.
In some regulatory domains, several frequency bands may be available for OFDM PHY-based WLANs.
These bands may be contiguous or not, and different regulatory limits may be applicable. An OFDM PHY
shall support at least one frequency band in at least one regulatory domain. The support of specific
regulatory domains, and bands within the domains, shall be indicated by PLME attributes
dot11RegDomainsImplementedValue and dot11FrequencyBandsImplemented.
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an OFDM PHY contains an
OPERATING_CHANNEL parameter, which identifies the operating channel. The PHY shall set
dot11CurrentFrequency to the value of this parameter.
17.3.8.4.2 Channel numbering
Channel center frequencies are defined at every integer multiple of 5 MHz above the channel starting
frequency. The relationship between center frequency and channel number is given by Equation (17-27):
Channel center frequency = Channel starting frequency + 5 nch (MHz) (17-27)
where
nch = 1,…200.
Channel starting frequency is defined as dot11ChannelStartingFactor × 500 kHz or
is defined as 5 GHz for systems where dot11OperatingClassesRequired is
false or not defined.
For example, dot11ChannelStartingFactor = 10000 indicates that Channel 0 center frequency is 5.000 GHz.
A channel center frequency of 5.000 GHz shall be indicated by dot11ChannelStartingFactor = 8000 and
nch = 200. An SME managing multiple channel sets can change the channel set being managed by changing
dot11ChannelStartingFactor.
This definition provides a unique numbering system for all channels with 5 MHz between center
frequencies, as well as the flexibility to define channelization sets for all current and future regulatory
domains.
2304
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.8.4.3 Channelization
The set of valid operating channel numbers by regulatory domain is defined in Annex E. As shown in
Figure 17-11, no subcarrier is allocated on the channel center frequency.
17.3.8.5 Transmit and receive in-band and out-of-band spurious emissions
The OFDM PHY shall comply with in-band and out-of-band spurious emissions as set by regulatory bodies.
17.3.8.6 Slot time
The value of the slot time is found in Table 17-21.
17.3.8.7 Transmit and receive impedance at the antenna connector
The impedance at the transmit and receive antenna connector(s) shall be 50 if the connector is exposed.
17.3.9 PHY transmit specifications
17.3.9.1 General
The transmit specifications associated with the PHY sublayer are described in 17.3.9.2 to 17.3.9.8.
17.3.9.2 Transmit power levels
The maximum allowable output power is measured in accordance with practices specified by the appropriate
regulatory bodies.
17.3.9.3 Transmit spectrum mask
The transmit spectrum mask by regulatory domain is defined in Annex D and Annex E.
NOTE 1—In the presence of additional regulatory restrictions, the device needs to meet both the regulatory
requirements and the mask defined here, i.e., its emissions need to be no higher at any frequency offset than the
minimum of the values specified in the regulatory and default masks.
NOTE 2—For rules regarding TX center frequency leakage levels by VHT STAs, see 21.3.17.4.2.
For operation using 20 MHz channel spacing, the transmitted spectrum shall have a 0 dBr (dB relative to the
maximum spectral density of the signal) bandwidth not exceeding 18 MHz, –20 dBr at 11 MHz frequency
offset, –28 dBr at 20 MHz frequency offset, and the maximum of –40 dBr and –53 dBm/MHz at 30 MHz
frequency offset and above. The transmitted spectral density of the transmitted signal shall fall within the
spectral mask, as shown in Figure 17-13. The measurements shall be made using a 100 kHz resolution
bandwidth and a 30 kHz video bandwidth.
For operation using 10 MHz channel spacing, the transmitted spectrum shall have a 0 dBr bandwidth not
exceeding 9 MHz, –20 dBr at 5.5 MHz frequency offset, –28 dBr at 10 MHz frequency offset, and the
maximum of –40 dBr and –50 dBm/MHz at 15 MHz frequency offset and above. The transmitted spectral
density of the transmitted signal shall fall within the spectral mask, as shown in Figure 17-14. The
measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth.
2305
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Power Spectral Density (dB)
Transmit Spectrum Mask
(not to scale)
–20 dBr
Typical Signal Spectrum
–28 dBr (an example)
–40 dBr
–30 –20 –11 –9 fc 9 11 20 30
Frequency (MHz)
Figure 17-13—Transmit spectrum mask for 20 MHz transmission
Power Spectral Density (dB)
Transmit Spectrum Mask
(not to scale)
–20 dBr
Typical Signal Spectrum
–28 dBr (an example)
–40 dBr
–15 –10 –5.5 -4.5 fc 4.5 5.5 10 15
Frequency (MHz)
Figure 17-14—Transmit spectrum mask for 10 MHz transmission
For operation using 5 MHz channel spacing, the transmitted spectrum shall have a 0 dBr bandwidth not
exceeding 4.5 MHz, –20 dBr at 2.75 MHz frequency offset, –28 dBr at 5 MHz frequency offset, and the
maximum of –40 dBr and –47 dBm/MHz at 7.5 MHz frequency offset and above. The transmitted spectral
density of the transmitted signal shall fall within the spectral mask, as shown in Figure 17-15. The
measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth.
2306
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Power Spectral Density (dB)
Transmit Spectrum Mask
(not to scale)
–20 dBr
Typical Signal Spectrum
–28 dBr (an example)
–40 dBr
–7.5 –5 –2.75 –2.25 fc 2.25 2.75 5 7.5
Frequency (MHz)
Figure 17-15—Transmit spectrum mask for 5 MHz transmission
17.3.9.4 Transmission spurious
Spurious transmissions shall comply with national regulations.
17.3.9.5 Transmit center frequency tolerance
The transmitted center frequency tolerance shall be ±20 ppm maximum for 20 MHz and 10 MHz channels
and shall be ±10 ppm maximum for 5 MHz channels. The transmit center frequency and the symbol clock
frequency shall be derived from the same reference oscillator.
17.3.9.6 Symbol clock frequency tolerance
The symbol clock frequency tolerance shall be ±20 ppm maximum for 20 MHz and 10 MHz channels, and
shall be ±10 ppm maximum for 5 MHz channels. The transmit center frequency and the symbol clock
frequency shall be derived from the same reference oscillator.
17.3.9.7 Modulation accuracy
17.3.9.7.1 Introduction
Transmit modulation accuracy specifications are described in 17.3.9.7. The test method is described in
17.3.9.8.
17.3.9.7.2 Transmitter center frequency leakage
For VHT STAs, the requirements on transmitter center frequency leakage are defined in 21.3.17.4.2;
otherwise, the requirements are defined in this subclause.
Certain transmitter implementations may cause leakage of the center frequency component. Such leakage
(which manifests itself in a receiver as energy in the center frequency component) shall not exceed –15 dB
relative to overall transmitted power or, equivalently, +2 dB relative to the average energy of the rest of the
subcarriers. The data for this test shall be derived from the channel estimation phase.
2307
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.9.7.3 Transmitter spectral flatness
The average energy of the constellations in each of the spectral lines –16.. –1 and +1.. +16 shall deviate no
more than ± 4 dB from their average energy. The average energy of the constellations in each of the spectral
lines –26.. –17 and +17.. +26 shall deviate no more than +4/–6 dB from the average energy of
spectral lines –16.. –1 and +1.. +16. The data for this test shall be derived from the channel estimation step.
17.3.9.7.4 Transmitter constellation error
The relative constellation RMS error, averaged over subcarriers and OFDM PPDUs, shall not exceed a data-
rate dependent value according to Table 17-17.
Table 17-17—Allowed relative constellation error versus data rate
Relative constellation error Coding rate
Modulation
(dB) (R)
–5 BPSK 1/2
–8 BPSK 3/4
–10 QPSK 1/2
–13 QPSK 3/4
–16 16-QAM 1/2
–19 16-QAM 3/4
–22 64-QAM 2/3
–25 64-QAM 3/4
17.3.9.8 Transmit modulation accuracy test
The transmit modulation accuracy test shall be performed by instrumentation capable of converting the
transmitted signal into a stream of complex samples at 20 Msample/s or more, with sufficient accuracy in
terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, etc. A possible embodiment of such a
setup is converting the signal to a low IF with a microwave synthesizer, sampling the signal with a digital
oscilloscope and decomposing it digitally into quadrature components.
The sampled signal shall be processed in a manner similar to an actual receiver, according to the following
steps, or an equivalent procedure:
a) Start of frame shall be detected.
b) Transition from short sequences to channel estimation sequences shall be detected, and fine timing
(with one sample resolution) shall be established.
c) Coarse and fine frequency offsets shall be estimated.
d) The packet shall be derotated according to estimated frequency offset.
e) The complex channel response coefficients shall be estimated for each of the subcarriers.
f) For each of the data OFDM symbols: transform the symbol into subcarrier received values, estimate
the phase from the pilot subcarriers, derotate the subcarrier values according to estimated phase, and
divide each subcarrier value with a complex estimated channel response coefficient.
2308
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
g) For each data-carrying subcarrier, find the closest constellation point and compute the Euclidean
distance from it.
h) Compute the RMS average of all errors in a packet. It is given by
LP 52
2 2
Nf I i j k – I0 i j k + Q i j k – Q0 i j k
=1 k=1
j----------------------------------------------------------------------------------------------------------------------------------------------------
-
52L P P 0
=1
Error RMS = i------------------------------------------------------------------------------------------------------------------------------------------------------------------
- (17-28)
Nf
where
LP is the length of the packet;
Nf is the number of frames for the measurement;
(I0(i,j,k), Q0(i,j,k))denotes the ideal symbol point of the ith frame, jth OFDM symbol of the frame, kth sub-
carrier of the OFDM symbol in the complex plane;
(I(i,j,k), Q(i,j,k))denotes the observed point of the ith frame, jth OFDM symbol of the frame, kth subcarrier
of the OFDM symbol in the complex plane (see Figure 17-16);
P0 is the average power of the constellation.
The vector error on a phase plane is shown in Figure 17-16.
The test shall be performed over at least 20 frames (Nf), and the RMS average shall be taken. The packets
under test shall be at least 16 OFDM symbols long. Random data shall be used for the symbols.
Q
Measurement Symbol (I(i, j, k), Q(i, j, k))
Error Vector Magnitude (EVM)
Ideal Symbol (I0(i, j, k), Q0(i, j, k))
Mean Power of Ideal Symbol (P0 = 1)
I
Figure 17-16—Constellation error
17.3.9.9 Time of Departure accuracy
The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and
aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined
Annex P with the following test parameters:
2309
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
fH – fL
— MULTICHANNEL_SAMPLING_RATE is 20 10 6 1 + ------------------- sample/s
20 MHz
where
fH is the nominal center frequency in Hz of the highest channel in the channel set
fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel
set is the set of channels upon which frames providing measurements are transmitted, the
channel set comprises channels uniformly spaced across fH – fL 50 MHz
— FIRST_TRANSITION_FIELD is the Short symbols.
— SECOND_TRANSITION_FIELD is the Long symbols.
— TRAINING_FIELD is the Long symbols windowed in a manner which should approximate the win-
dowing described in 17.3.2.5 with TTR = 100 ns for 20 MHz channel spacing, TTR = 200 ns for 10
MHz channel spacing and TTR = 400 ns for 5 MHz channel spacing.
— TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns.
NOTE—The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or
receiver.
17.3.10 PHY receiver specifications
17.3.10.1 Introduction
The receive specifications associated with the PHY sublayer are described in 17.3.10.2 to 17.3.10.6.
17.3.10.2 Receiver minimum input sensitivity
The packet error ratio (PER) shall be 10% or less when the PSDU length is 1000 octets and the rate-
dependent input level is as shown in Table 17-18. The minimum input levels are measured at the antenna
connector (noise factor of 10 dB and 5 dB implementation margins are assumed).
Table 17-18—Receiver performance requirements
Minimum Minimum Minimum
Alternate
Adjacent sensitivity sensitivity sensitivity
Coding adjacent
channel (dBm) (dBm) (dBm)
Modulation rate channel
rejection (20 MHz (10 MHz (5 MHz
(R) rejection
(dB) channel channel channel
(dB)
spacing) spacing) spacing)
BPSK 1/2 16 32 –82 –85 –88
BPSK 3/4 15 31 –81 –84 –87
QPSK 1/2 13 29 –79 –82 –85
QPSK 3/4 11 27 –77 –80 –83
16-QAM 1/2 8 24 –74 –77 –80
16-QAM 3/4 4 20 –70 –73 –76
64-QAM 2/3 0 16 –66 –69 –72
64-QAM 3/4 –1 15 –65 –68 –71
2310
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
17.3.10.3 Adjacent channel rejection
The adjacent channel rejection shall be measured by setting the desired signal’s strength 3 dB above the rate-
dependent sensitivity specified in Table 17-18 and raising the power of the interfering signal until 10% PER
is caused for a PSDU length of 1000 octets. The difference in power between the signals in the interfering
channel and the desired channel is the corresponding adjacent channel rejection. The interfering signal in
the adjacent channel shall be a signal compliant with the OFDM PHY, unsynchronized with the signal in the
channel under test. In an OFDM PHY the corresponding rejection shall be no less than specified in
Table 17-18.
An optional enhanced performance specification is provided for systems requiring improved immunity to
out-of-channel interfering emissions. If a STA has dot11ACRType equal to 2, the adjacent channel rejection
shall be no less than specified in Table 17-19. The interfering signal in the adjacent channel shall be a signal
compliant with the OFDM PHY, using transmit mask M (see D.2.4), unsynchronized with the signal in the
channel under test. The corresponding minimum receiver sensitivities for each modulation and coding rate
are the same as in Table 17-18.
NOTE—Transmit mask M is equivalent to class C (see D.2.2).
Table 17-19—Optional enhanced receiver performance requirements
Coding Adjacent channel Nonadjacent
Modulation rate rejection channel rejection
(R) (dB) (dB)
BPSK 1/2 28 42
BPSK 3/4 27 41
QPSK 1/2 25 39
QPSK 3/4 23 37
16-QAM 1/2 20 34
16-QAM 3/4 16 30
64-QAM 2/3 12 26
64-QAM 3/4 11 25
17.3.10.4 Nonadjacent channel rejection
The nonadjacent channel rejection shall be measured by setting the desired signal’s strength 3 dB above the
rate-dependent sensitivity specified in Table 17-18, and raising the power of the interfering signal until a
10% PER occurs for a PSDU length of 1000 octets. The difference in power between the signals in the
interfering channel and the desired channel is the corresponding nonadjacent channel rejection. The
interfering signal in the nonadjacent channel shall be a signal compliant with the OFDM PHY,
unsynchronized with the signal in the channel under test. In an OFDM PHY, the corresponding rejection
shall be no less than specified in Table 17-18.
2311
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
An optional enhanced performance specification is provided for systems requiring improved immunity to
out-of-channel interfering emissions. If a STA has dot11ACRType equal to 2, the nonadjacent channel
rejection shall be no less than specified in Table 17-19. The interfering signal in the nonadjacent channel
shall be a signal compliant with the OFDM PHY, using transmit mask M (see D.2.4), unsynchronized with
the signal in the channel under test. The corresponding minimum receiver sensitivities for each modulation
and coding rate are the same as in Table 17-18.
17.3.10.5 Receiver maximum input level
The receiver shall provide a maximum PER of 10% at a PSDU length of 1000 octets, for a maximum input
level of –30 dBm measured at the antenna for any baseband modulation.
17.3.10.6 CCA requirements
The PHY shall indicate a medium busy condition by issuing a PHY-CCA.indication primitive when the
carrier sense/clear channel assessment (CS/CCA) mechanism detects a channel busy condition.
For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall also indicate a medium
busy condition when CCA-ED detects a channel busy condition.
The start of a valid OFDM transmission at a receive level greater than or equal to the minimum modulation
and coding rate sensitivity (–82 dBm for 20 MHz channel spacing, –85 dBm for 10 MHz channel spacing,
and –88 dBm for 5 MHz channel spacing) shall cause CS/CCA to detect a channel busy condition with a
probability > 90% within 4 s for 20 MHz channel spacing, 8 s for 10 MHz channel spacing, and 16 s for
5 MHz channel spacing.
NOTE—CS/CCA detect time is based on finding the short sequences in the preamble, so when TSYM doubles, so does
CS/CCA detect time.
Additionally, the CS/CCA mechanism shall detect a medium busy condition within 4 s of any signal with a
received energy that is 20 dB above the minimum modulation and coding rate sensitivity (minimum
modulation and coding rate sensitivity + 20 dB resulting in –62 dBm for 20 MHz channel spacing, –65 dBm
for 10 MHz channel spacing, and –68 dBm for 5 MHz channel spacing).
For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED
is given in Table D-2. The operating classes requiring the corresponding CCA-ED behavior class are given
in E.1. The PHY of a STA that is operating within an operating class that requires CCA-ED shall operate
with CCA-ED.
CCA-ED shall detect a channel busy condition when the received signal strength exceeds the CCA-ED
threshold as given by dot11OFDMEDThreshold. The CCA-ED thresholds for the operating classes
requiring CCA-ED are subject to the criteria in D.2.5.
NOTE—The requirement to detect a channel busy condition for any signal 20 dB above the minimum modulation and
coding rate sensitivity (minimum modulation and coding rate sensitivity + 20 dB resulting in –62 dBm for 20 MHz
channel spacing, –65 dBm for 10 MHz channel spacing, and –68 dBm for 5 MHz channel spacing) is a mandatory
energy detect requirement on all Clause 17 receivers. Support for CCA-ED is an additional requirement that relates
specifically to the sensitivities described in D.2.5.
17.3.10.7 Received Channel Power Indicator Measurement
The RCPI indicator is a measure of the received RF power in the selected channel for a received frame. This
parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire
received frame or by other equivalent means that meet the specified accuracy.
2312
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The RCPI encoding is defined in 15.4.6.6.
RCPI shall equal the received RF power within an accuracy of ±5 dB (95% confidence interval) within the
specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel bandwidth multiplied by 1.1.
17.3.11 Transmit PHY
The transmit PHY is shown in Figure 17-17. In order to transmit data, the PHY-TXSTART.request
primitive shall be enabled so that the PHY entity shall be in the transmit state. Further, the PHY shall be set
to operate at the appropriate frequency through STA management via the PLME. Other transmit parameters,
such as DATARATE and TX power, are set via the PHY SAP with the PHY-
TXSTART.request(TXVECTOR) primitive, as described in 17.2.2.
PHY-TXSTART.confirm
PHY-TXEND.confirm
PHY-TXEND.request
PHY-TXSTART.request
PHY-DATA.request
PHY-DATAconfirm
PHY-DATA.request
PHY-DATAconfirm
(TXVECTER)
(TXSTATUS)
MAC
MPDU
Tail Bit
Bit Padding if Needed
Header PSDU
Scrambled + Encoded
Training Symbols Header C-PSDU
RATE Reserved LENGTH Parity Tail SERVICE Tail Pad bits
4 bits 1 bit 12 bits 1 bit 6 bits 16 bits PSDU
6 bits
PHY
PHY Preamble SIGNAL DATA
12 Symbols One OFDM Symbol Variable Number of OFDM Symbols
Coded/OFDM Coded/OFDM
(BPSK, r = 1/2) (RATE is indicated in SIGNAL)
Figure 17-17—Transmit PHY
2313
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PHY shall indicate a clear channel by issuing a PHY-CCA.indication(IDLE) primitive. The MAC
considers this indication before issuing the PHY-TXSTART.request primitive. Transmission of the PPDU
shall be initiated after receiving the PHY-TXSTART.request(TXVECTOR) primitive. The TXVECTOR
elements for the PHY-TXSTART.request primitive are the PHY header parameters DATARATE,
SERVICE, and LENGTH and the PHY parameters TXPWR_LEVEL_INDEX and
TIME_OF_DEPARTURE_REQUESTED.
The PHY is configured with the TXVECTOR elements DATARATE and TXPWR_LEVEL_INDEX.
Transmission of the PHY preamble and PHY header, based on the parameters passed in the PHY-
TXSTART.request primitive, shall be immediately initiated.
Once PHY preamble transmission is started, the PHY entity shall immediately initiate PHY header encoding
then data scrambling and data encoding, where the data shall be exchanged between the MAC and the PHY
through a series of PHY-DATA.request(DATA) primitives issued by the MAC, and PHY-DATA.confirm
primitives issued by the PHY. The modulation rate change, if any, shall be initiated from the SERVICE field
data of the PHY header, as described in 17.3.2.
The PHY proceeds with PSDU transmission through a series of data octet transfers from the MAC. The
PHY header parameter, SERVICE, and PSDU are encoded by the convolutional encoder with the bit-
stealing function described in 17.3.5.6. Transmission can be prematurely terminated by the MAC through
the PHY-TXEND.request primitive. PHY-TXSTART shall be disabled by the issuance of the PHY-
TXEND.request primitive. Normal termination occurs after the transmission of the final bit of the last PSDU
octet, according to the number supplied in the OFDM PHY preamble LENGTH field.
The packet transmission shall be completed and the PHY entity shall enter the receive state (i.e., PHY-
TXSTART shall be disabled). Each PHY-TXEND.request primitive is acknowledged with a
PHY-TXEND.confirm primitive from the PHY. If the coded PSDU (C-PSDU) length is not a multiple of the
OFDM symbol length NCBPS, the PSDU is padded prior to scrambling and coding (see 17.3.5.4).
In the PHY, the GI shall be inserted in every OFDM symbol as a countermeasure against severe delay
spread.
A typical state machine implementation of the transmit PHY is provided in Figure 17-18. Requests
(.request) and confirmations (.confirm) are issued once with designated states.
2314
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TX PSDU OCTET
PHY-TXSTART.request(TXVECTOR) PHY-DATA.request
Get octet from (DATA)
MAC and encoding
PHY-DATA.confirm
Initialize
length > 1
length = 1
set TX parameters
TAIL APPEND
Tail bits are appended
TX Preamble
TX training symbols BIT PADDING
followed by the SIGNAL Bit padding if needed
field, which consists of:
4 bits RATE,
1 bit Reserved,
12 bits LENGTH and TX SYMBOL
1 bit Parity
PHY-TXSTART.confirm Set symbol bit count
(TXSTATUS)
TX PHYDATA
Decrement Bit
Change coding rate and
modulation type, if Decrement bit count
necessary by bits per symbol bit count > 0
TX encoded PHY header bit count = 0
includes:
16 bits SERVICE Decrement Length
Decrement length count length > 0
SETUP MPDU TX
PHY-TXSTART.confirm PHY-DATA.request length = 0
Set length count (DATA) Switch RX STATE
A
A At any stage in the above flow diagram, if a PHY-TXEND.request primitive is received.
Figure 17-18—PHY transmit state machine
17.3.12 Receive PHY
The receive PHY is shown in Figure 17-19. In order to receive data, the PHY-TXSTART.request primitive
shall be disabled so that the PHY entity is in the receive state. Further, through STA management (via the
PLME) the PHY is set to the appropriate frequency. Other receive parameters, such as RSSI, RCPI, and
indicated DATARATE, may be accessed via the PHY SAP.
2315
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(RXERROR,RXVECTOR)
RX State
PHY-RXEND.indication
CS/CCA State
PHY-DATA.indication
PHY-DATA.indication
PHY-CCA.indication
PHY-CCA.indication
PHY-RXSTART.indication
(STATE=busy)
(RXVECTOR)
MAC
(IDLE)
MPDU
Tail Bit
Header
PSDU
Viterbi Decoding Delay
Bit Removing
Decoded+descrambled if Needed
Header
C-PSDU
Measure RSSI
RATE Reserved LENGTH Parity Tail SERVICE Tail Pad bits
4 bits 1 bit 12 bits 1 bit 6 bits 16 bits PSDU 6 bits
PHY
PHY Preamble SIGNAL DATA
12 Symbols One OFDM Symbol Variable Number of OFDM Symbols
Coded/OFDM Coded/OFDM
(BPSK, r = 1/2) (RATE is indicated in SIGNAL)
Figure 17-19—Receive PHY
Upon receiving the transmitted PHY preamble, the PHY measures the received signal strength level. This
indicates activity to the MAC via PHY-CCA.indication primitive. A PHY-CCA.indication(BUSY) primitive
shall be issued for reception of a signal prior to correct reception of the PPDU. The RSSI parameter reported
to the MAC in the RXVECTOR.
After a PHY-CCA.indication primitive is issued, the PHY entity shall begin receiving the training symbols
and searching for the SIGNAL in order to set the length of the data stream, the demodulation type, and the
decoding rate.
If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported),
a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued. If dot11TimingMsmtActivated is
true, the PHY shall do the following:
— Complete receiving the PHY header and verify the validity of the PHY Header.
— If the PHY header reception is successful (and the SIGNAL field is completely recognizable and
supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and
RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see
17.2.3).
A VHT STA shall include the CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT
parameters in the RXVECTOR within the PHY-RXSTART.indication(RXVECTOR) primitive.
2316
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE—The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the
start of the preamble for the incoming frame was detected on the medium at the receive antenna connector.
The RXVECTOR associated with this primitive includes the SIGNAL field, the SERVICE field, the PSDU
length in octets, and the RSSI. Also, in this case, the CCA of the OFDM PHY shall indicate a busy medium
for the intended duration of the transmitted frame, as indicated by the LENGTH field.
The received PSDU bits are assembled into octets, decoded, and presented to the MAC using a series of
PHY-DATA.indication(DATA) primitive exchanges. The rate change indicated in the SIGNAL field shall
be initiated from the SERVICE field data of the PHY header, as described in 17.3.2. The PHY shall proceed
with PSDU reception. After the reception of the final bit of the last PSDU octet indicated by the PHY
preamble LENGTH field, the receiver shall be returned to the RX IDLE state, as shown in Figure 17-19. A
PHY-RXEND.indication(NoError) primitive shall be issued.
In the event that a change in the RSSI causes the status of the CCA to return to the IDLE state before the
complete reception of the PSDU, as indicated by the PHY LENGTH field, the error condition shall be
reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive and the PHY receiver shall
return to the RX IDLE state. The CCA of the OFDM PHY shall indicate a busy medium for the intended
duration of the transmitted packet.
If the indicated rate in the SIGNAL field is not receivable, a PHY-RXSTART.indication primitive shall not
be issued. The PHY shall indicate the error condition by issuing a PHY-
RXEND.indication(UnsupportedRate) primitive and hold CCA busy for the calculated duration of the
PPDU. If the PHY header is receivable, but the parity check of the PHY header is not valid, a PHY-
RXSTART.indication primitive shall not be issued. The PHY shall indicate the error condition using a PHY-
RXEND.indication(FormatViolation) primitive.
Any data received after the indicated data length are considered pad bits (to fill out an OFDM symbol) and
should be discarded.
A typical state machine implementation of the receive PHY is given in Figure 17-20.
17.4 OFDM PLME
17.4.1 PLME SAP sublayer management primitives
Table 17-20 lists the MIB attributes that may be accessed by the PHY entities and the intralayer of higher
level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME-
CHARACTERISTICS primitives defined in 6.5.
17.4.2 OFDM PHY MIB
All OFDM PHY MIB attributes are defined in Annex C, with specific values defined in Table 17-20. The
column titled “Operational semantics” in Table 17-20 contains two types: static and dynamic. Static MIB
attributes are fixed and cannot be modified for a given PHY implementation. Dynamic MIB attributes can
be modified by some management entity.
2317
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RX IDLE state
CS/CCA
PHY-CCA.indication(BUSY)
Detect PHY Preamble RX SYMBOL
SIGNAL invalid Receive the SIGNAL
or PHY-CCA symbol
.indication (IDLE) SIGNAL Valid PHY-CCA.indication PHY-CCA.indication
RX SIGNAL Parity (IDLE) (BUSY)
Signal Not Valid Decode Symbol
Parity Fail RX and test parity
PHY-RXEND Descramble and
Parity Correct .indication decode symbol
(Carrier Lost)
RX PHY fields
Change demodulation type
and decoding rate
PHY-CCA
according to SIGNAL data Decrement Time Decrement Length
.indication
(IDLE) RX 12 bits LENGTH PHY-DATA.indication
RX 4 bits RATE Wait for intended (DATA)
end of PSDU (bit removing if needed) length 0
Decrement length count
Predicted duration expires
and PHY-CCA.indication(IDLE)
Time=0 length = 0
Wait until end of PHY field VALIDATE PPDU
PPDU Out of Spec.
End of Wait End of PSDU RX
If unsupported RATE, Check PPDU
predict duration Unsupported
RATE PHY-RXEND
PPDU Correct PHY-CCA.indication .indication (No Error)
(IDLE) PHY-CCA.indication(IDLE)
SETUP PSDU RX
Set length count
PHY-RXSTART
.indication
(RXVECTOR)
Figure 17-20—PHY receive state machine
Table 17-20—MIB attribute default values/ranges
Managed object Default value/range Operational semantics
dot11 PHY Operation Table
dot11PHYtype OFDM-5. (04) Static
dot11CurrentRegDomain Implementation dependent Dynamic
dot11 PHY Antenna Table
dot11CurrentTxAntenna Implementation dependent Dynamic
dot11DiversitySupportImplemented Implementation dependent Static
dot11CurrentRxAntenna Implementation dependent Dynamic
2318
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 17-20—MIB attribute default values/ranges (continued)
Managed object Default value/range Operational semantics
dot11 PHY Tx Power Table
dot11NumberSupportedPowerLevelsI Implementation dependent Static
mplemented
dot11TxPowerLevel1 Implementation dependent Static
dot11TxPowerLevel2 Implementation dependent Static
dot11TxPowerLevel3 Implementation dependent Static
dot11TxPowerLevel4 Implementation dependent Static
dot11TxPowerLevel5 Implementation dependent Static
dot11TxPowerLevel6 Implementation dependent Static
dot11TxPowerLevel7 Implementation dependent Static
dot11TxPowerLevel8 Implementation dependent Static
dot11CurrentTxPowerLevel Implementation dependent Dynamic
dot11 Reg Domains Supported Table
dot11RegDomainsImplementedValue Implementation dependent Static
dot11FrequencyBandsSupported Implementation dependent Static
dot11 PHY Antennas List Table
dot11SupportedTxAntenna Implementation dependent Static
dot11SupportedRxAntenna Implementation dependent Static
dot11DiversitySelectionRx Implementation dependent Dynamic
dot11 Supported Data Rates Tx Table
dot11ImplementedDataRatesTxValue 6, 9, 12, 18, 24, 36, 48, and Static
54 Mb/s for 20 MHz channel
spacing (Mandatory rates: 6,
12, and 24)
3, 4.5, 6, 9, 12, 18, 24, and
27 Mb/s for 10 MHz channel
spacing (Mandatory rates: 3, 6,
and 12)
1.5, 2.25, 3, 4.5, 6, 9, 12, and
13.5 Mb/s for 5 MHz channel
spacing (Mandatory rates: 1.5,
3, and 6)
2319
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 17-20—MIB attribute default values/ranges (continued)
Managed object Default value/range Operational semantics
dot11 Supported Data Rates Rx Table
dot11ImplementedDataRatesRxValue 6, 9, 12, 18, 24, 36, 48, and Static
54 Mb/s for 20 MHz channel
spacing (Mandatory rates: 6,
12, and 24)
3, 4.5, 6, 9, 12, 18, 24, and
27 Mb/s for 10 MHz channel
spacing (Mandatory rates: 3, 6,
and 12)
1.5, 2.25, 3, 4.5, 6, 9, 12, and
13.5 Mb/s for 5 MHz channel
spacing (Mandatory rates: 1.5,
3, and 6)
dot11 PHY OFDM Table
dot11CurrentFrequency Implementation dependent Dynamic
dot11TIThreshold Implementation dependent Dynamic
dot11ChannelStartingFactor Implementation dependent Dynamic
dot11OFDMEDThreshold Implementation dependent Dynamic
dot11ACRType Implementation dependent Dynamic
17.4.3 OFDM TXTIME calculation
The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated
according to the following equation:
TXTIME = TPREAMBLE + TSIGNAL + TSYM NSYM (17-29)
where
TPREAMBLE is defined in Table 17-5
TSIGNAL is defined in Table 17-5
TSYM is defined in Table 17-5
NSYM is given by Equation (17-11).
17.4.4 OFDM PHY characteristics
The static OFDM PHY characteristics, provided through the PLME-CHARACTERISTICS service
primitive, are shown in Table 17-21. The definitions for these characteristics are given in 6.5.
2320
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 17-21—OFDM PHY characteristics
Value Value Value
Characteristics (20 MHz channel (10 MHz channel (5 MHz channel
spacing) spacing) spacing)
aSlotTime If If If
dot11OperatingClassesReq dot11OperatingClassesReq dot11OperatingClassesReq
uired is false, 9 µs uired is false, 13 µs uired is false, 21 µs
If If If
dot11OperatingClassesReq dot11OperatingClassesReq dot11OperatingClassesReq
uired is true, 9 µs plus any uired is true, 13 µs plus any uired is true, 21 µs plus any
coverage-class-dependent coverage-class-dependent coverage-class-dependent
aAirPropagationTime (see aAirPropagationTime (see aAirPropagationTime (see
Table 9-79) Table 9-79) Table 9-79)
aSIFSTime 16 µs 32 µs 64 µs
aCCATime Implementation dependent, see 10.3.7.
aRxPHYStartDelay 20 µs 40 µs 80 µs
aRxTxTurnaroundTime Implementation dependent, see 10.3.7.
aTxPHYDelay Implementation dependent, see 10.3.7.
aRxPHYDelay Implementation dependent, see 10.3.7.
aRxTxSwitchTime Implementation dependent, see 10.3.7.
aTxRampOnTime Implementation dependent, see 10.3.7.
aAirPropagationTime As indicated by the coverage class (see 10.21.5).
aMACProcessingDelay Implementation dependent, see 10.3.7.
aPreambleLength 16 µs 32 µs 64 µs
aPHYHeaderLength 4 µs 8 µs 16 µs
aPSDUMaxLength 4095 octets 4095 octets 4095 octets
aCWmin 15 15 15
aCWmax 1023 1023 1023
2321
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
18. Extended Rate PHY (ERP) specification
18.1 Overview
18.1.1 General
This clause specifies further rate extension of the PHY for the DSSS system of Clause 15 and the extensions
of Clause 16. Hereinafter the PHY defined in this clause is known as the ERP. This PHY operates in the
2.4 GHz ISM band.
18.1.2 Introduction
The ERP builds on the payload data rates of 1 and 2 Mb/s, as described in Clause 15, that use DSSS
modulation and builds on the payload data rates of 1, 2, 5.5, and 11 Mb/s, as described in Clause 16, that use
DSSS and CCK. The ERP draws from Clause 17 to provide additional payload data rates of 6, 9, 12, 18, 24,
36, 48, and 54 Mb/s. Of these rates, transmission and reception capability for 1, 2, 5.5, 6, 11, 12, and 24 Mb/
s data rates is mandatory.
18.1.3 Operational modes
The radio portion of all Clause 18 systems implements all mandatory modes of Clause 17 and Clause 16,
except it uses the 2.4 GHz frequency band and channelization plan specified in 16.3.6. The ERP has the
capability to decode Clause 15, Clause 16 and ERP PPDUs. An ERP shall be capable of sending and
receiving the short preamble that is (and remains) optional for Clause 16 PHYs.
The ERP has the capability to detect ERP and Clause 16 preambles whenever a CCA is requested. Because
protection mechanisms are not required in all cases, the ERP CCA mechanisms for all preamble types shall
be active at all times.
An ERP BSS is capable of operating in any combination of available ERP modes (Clause 18 PHYs) and
NonERP modes (Clause 15 or Clause 16 PHYs). For example, a BSS could operate in an ERP-OFDM-only
mode, a mixed mode of ERP-OFDM and ERP-DSSS/CCK, or a mixed mode of ERP-DSSS/CCK and
NonERP. When options are enabled, combinations are also allowed.
The changes to other parts of this standard required to implement the ERP are summarized as follows:
a) ERP-DSSS/CCK
1) The PHY uses the capabilities of Clause 16 with the following exceptions:
i) Support of the short PPDU header format capability of 16.2.2.3 is mandatory.
ii) CCA (see 16.3.8.5) has a mechanism that detects all mandatory Clause 18 sync symbols.
iii) The maximum input signal level (see 16.3.8.3) is –20 dBm.
iv) Locking the transmit center frequency and the symbol clock frequency to the same
reference oscillator is mandatory.
b) ERP-OFDM
1) The PHY uses the capabilities of Clause 17 with the following exceptions:
i) The frequency plan is in accordance with 16.3.6.2 and 16.3.6.3 instead of 17.3.8.4.
ii) CCA has a mechanism that detects all mandatory Clause 18 sync symbols.
iii) The frequency accuracy (see 17.3.9.5 and 17.3.9.6) is ±25 ppm.
iv) The maximum input signal level (see 17.3.10.5) is –20 dBm.
2322
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
v) The value of the slot time is found in Table 18-5.
vi) SIFS is 10 µs in accordance with 16.3.3. See 18.3.2.4 for more detail.
The 2.4 GHz ISM band is a shared medium, and coexistence with other devices such as Clause 15 and
Clause 16 STAs is an important issue for maintaining high performance in Clause 18 (ERP) STAs. The ERP
modulation (ERP-OFDM) has been designed to coexist with existing Clause 15 and Clause 16 STAs. This
coexistence is achieved by several means, including virtual CS (RTS/CTS or CTS-to-self), CSMA/CA
protocols, and MSDU fragmentation.
18.1.4 Scope
This clause specifies the ERP entity and the deviations from earlier clauses to accommodate it. It is
organized by reference to the relevant earlier clauses to avoid excessive duplication.
The ERP consists of the following protocol functions:
a) A function that defines a method for mapping the MPDUs into a framing format suitable for sending
and receiving user data and management information between two or more STAs using the
associated PHY system. The PHY exchanges PPDUs that contain PSDUs. The MAC uses the PHY
service, so each MPDU corresponds to a PSDU that is carried in a PPDU.
b) A function that defines the characteristics and method of transmitting and receiving data through a
WM between two or more STAs; each using the ERP.
18.1.5 ERP functions
The ERP contains two functional entities: the PHY function and the layer management function.
The ERP service is provided to the MAC through the PHY service primitives described in Clause 8.
Interoperability is addressed by use of the CS mechanism specified in 10.3.2.1 and the protection
mechanism in 10.26. This mechanism allows NonERP STAs to know of ERP traffic that they cannot
demodulate so that they may defer the medium to that traffic.
18.2 PHY-specific service parameter list
The architecture of the IEEE 802.11 MAC is intended to be PHY independent. Some PHY implementations
require PHY-dependent MAC state machines running in the MAC sublayer in order to meet certain PHY
requirements. The PHY-dependent MAC state machine resides in a sublayer defined as the MLME. In
certain PHY implementations, the MLME may need to interact with the PLME as part of the normal PHY
SAP primitives. These interactions are defined by the PLME parameter list currently defined in the PHY
service primitives as TXVECTOR, TXSTATUS, and RXVECTOR. The list of these parameters and the
values they may represent are defined in the specific PHY specifications for each PHY. This subclause
addresses the TXVECTOR, TXSTATUS, and RXVECTOR for the ERP. The service parameters for
TXVECTOR, TXSTATUS, and RXVECTOR shall follow 17.2.2, 17.2.4, and 17.2.3, respectively.
Several service primitives include a parameter vector. DATARATE and LENGTH are described in 8.3.4.4.
The remaining parameters are considered to be management parameters and are specific to this PHY.
The parameters in Table 18-1 are defined as part of the TXVECTOR parameter list in the PHY-
TXSTART.request and PLME-TXTIME.request primitives.
2323
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 18-1—TXVECTOR parameters
Parameter Value
DATARATE The rate used to transmit the PSDU in Mb/s.
Allowed value depends on value of MODULATION parameter:
ERP-DSSS: 1 and 2
ERP-CCK: 5.5 and 11
ERP-OFDM: 6, 9, 12, 18, 24, 36, 48, and 54
LENGTH The length of the PSDU in octets.
Range: 1–4095
PREAMBLE_TYPE The preamble used for the transmission of the PPDU.
Enumerated type for which the allowed value depends on value of MODULATION
parameter:
ERP-OFDM: null
ERP-DSSS, ERP-CCK: SHORTPREAMBLE, LONGPREAMBLE
MODULATION The modulation used for the transmission of this PSDU.
Enumerated type: ERP-DSSS, ERP-CCK, ERP-OFDM
SERVICE The scrambler initialization vector.
Null.
TXPWR_LEVEL_INDE The transmit power level index. The definition of these levels is up to the
X implementer.
1–8
TIME_OF_DEPARTURE false, true. When true, the MAC entity requests that the PHY entity measures and
_REQUESTED reports time of departure parameters corresponding to the time when the first frame
energy is sent by the transmitting port; when false, the MAC entity requests that the
PHY entity neither measures nor reports time of departure parameters.
The parameters in Table 18-2 are defined as part of the TXSTATUS parameter list in the PHY-TXSTART.
confirm service primitive.
Table 18-2—TXSTATUS parameters
Parameter Value
TIME_OF_DEPARTURE 0 to 232– 1. The locally measured time when the first frame energy
is sent by the transmitting port, in units equal to 1/
TIME_OF_DEPARTURE_ClockRate. This parameter is present
only if TIME_OF_DEPARTURE_REQUESTED is true in the
corresponding request.
TIME_OF_DEPARTURE_ClockRate 0 to 216– 1. The clock rate, in units of MHz, is used to generate the
TIME_OF_DEPARTURE value. This parameter is present only if
TIME_OF_DEPARTURE_REQUESTED is true in the
corresponding request.
TX_START_OF_FRAME_OFFSET 0 to 232– 1. An estimate of the offset (in 10 ns units) from the point
in time at which the start of the preamble corresponding to the
frame was transmitted at the transmit antenna connector to the
point in time at which this primitive is issued to the MAC.
2324
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The parameters in Table 18-3 are defined as part of the RXVECTOR parameter list in the PHY-
RXSTART.indication primitive. When implementations require the use of these vectors, some or all of these
parameters may be used in the vectors.
Table 18-3—RXVECTOR parameters
Parameter Value
DATARATE The rate at which the PSDU was received in Mb/s.
Allowed value depends on value of MODULATION parameter:
ERP-DSSS: 1 and 2
ERP-CCK: 5.5 and 11
ERP-OFDM: 6, 9, 12, 18, 24, 36, 48, and 54
LENGTH The length of the PSDU in octets.
Range: 1–4095
PREAMBLE_TYPE The preamble type detected during reception of the PPDU.
Enumerated type for which the allowed value depends on value of MODULATION
parameter:
ERP-OFDM: null
ERP-DSSS, ERP-CCK: SHORTPREAMBLE, LONGPREAMBLE.
MODULATION The modulation used for the reception of this PSDU.
Enumerated types: ERP-DSSS, ERP-CCK, ERP-OFDM
SERVICE Null.
RSSI The RSSI is a measure of the RF energy received by the ERP. The 8-bit value is in the
range 0 to RSSI maximum as described in 17.2.3.3.
RCPI The RCPI is a measure of the received channel power and is included when
dot11RadioMeasurementActivated is true. The 8-bit RCPI value is described in
17.2.3.6 and 16.3.8.6.
RX_START_OF_FRAME 0 to 232– 1. An estimate of the offset (in 10 ns units) from the point in time at which
_OFFSET the start of the preamble corresponding to the incoming frame arrived at the receive
antenna connector to the point in time at which this primitive is issued to the MAC.
18.3 Extended Rate PHY sublayer
18.3.1 Introduction
Subclause 18.3 provides a PHY for the ERP. The convergence procedure specifies how PSDUs are
converted to and from PPDUs at the transmitter and receiver. The PPDU is formed during data transmission
by appending the PSDU to the Extended Rate PHY preamble and header. At the receiver, the PHY preamble
and header are processed to aid in the demodulation and delivery of the PSDU.
18.3.2 PPDU format
18.3.2.1 General
An ERP STA shall support three different preamble and header formats. The first is the long preamble and
header described in 18.3.2.2 (and based on 16.2.2.2 with redefinition of reserved bits defined therein). This
PPDU provides interoperability with Clause 16 STAs when using the 1, 2, 5.5, and 11 Mb/s data rates. The
second is the short preamble and header described in 18.3.2.3 (and based on 16.2.2.3 where it is optional).
2325
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The short preamble supports the rates 2, 5.5, and 11 Mb/s. The third is the ERP-OFDM preamble and header
specified in 18.3.2.4 (and based on 17.3.2).
18.3.2.2 Long preamble PPDU format
Figure 16-1 of 16.2.2.2 shows the basic format for the long preamble PPDU. This preamble is appropriate
for use with the 1, 2, 5.5, and 11 Mb/s (Clause 16) modes and is compatible with BSSs using these modes.
The SERVICE field is defined in 16.2.3.5. An ERP STA shall set the Locked clocks bit to 1, when
transmitting at a data rate described in Clause 16.
18.3.2.3 Short preamble PPDU format
Figure 16-2 of 16.2.2.3 shows the basic format for the short preamble PPDU. For the ERP, support for this
preamble is mandatory. The short preamble is appropriate for use with 2, 5.5, and 11 Mb/s modes. The bits
of the Short PHY SERVICE field and RATE field are the same as for the Long PHY SERVICE field and
RATE field and are defined in 18.3.2.2.
18.3.2.4 ERP-OFDM PPDU format
The format, preamble, and headers for the ERP-OFDM PPDU are described in 17.3.2 to 17.3.5. For the
ERP-OFDM modes, the DATA field that contains the SERVICE field, the PSDU, the TAIL bits, and the
PAD bits shall follow 17.3.5.
For ERP-OFDM modes, an ERP packet is followed by a period of no transmission with a duration of
aSignalExtension called the signal extension. The purpose of this extension is to make the TXTIME
calculation in 18.5.3 result in a transmission duration interval that includes an additional duration of
aSignalExtension. The SIFS for Clause 17 packets is 16 µs, and the SIFS for Clause 16 packets is 10 µs. The
longer SIFS in Clause 17 is to allow extra time for the convolutional decode process to finish. As Clause 18
packets use a SIFS of 10 µs, this extra aSignalExtension length extension causes the transmitter to compute
the Duration field in the MAC header incorporating the aSignalDuration of “idle time” following each ERP-
OFDM transmission, which causes the NAV value of Clause 16 STAs to be set correctly.
The “CS mechanism” described in 10.3.2.1 combines the NAV state and the STA’s transmitter status with
physical CS to determine the busy/idle state of the medium. The time interval between frames is called the
IFS. A STA shall determine that the medium is idle through the use of the CCA mechanism for the interval
specified. The starting reference of slot boundaries is the end of the last symbol of the previous frame on the
medium. For ERP-OFDM frames, this includes the length extension. For ERP-OFDM frames, a STA shall
generate the PHY-RXEND.indication aSignalDuration after the end of the last symbol of the previous frame
on the medium. This adjustment shall be performed by the STA based on local configuration information set
using the PLME SAP.
18.3.3 PHY data modulation and rate change
18.3.3.1 Long and short preamble formats
The long and short PHY preamble and the long PHY header shall be transmitted using the 1 Mb/s DBPSK
modulation. The short PHY header shall be transmitted using the 2 Mb/s modulation. The SIGNAL and
SERVICE fields combined shall indicate the modulation and rate that shall be used to transmit the PSDU.
The transmitter and receiver shall initiate the modulation and rate indicated by the SIGNAL and SERVICE
fields, starting with the first octet of the PSDU. The PSDU transmission rate shall be set by the DATARATE
parameter in the TXVECTOR, issued with the PHY-TXSTART.request primitive described in 16.3.5.
2326
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Four modulation formats are mandatory, 1 Mb/s and 2 Mb/s ERP-DSSS and 5.5 Mb/s and 11 Mb/s
ERP-CCK, and they are specified in 16.3.6.4.
18.3.3.2 ERP-OFDM format
PHY modulation and rate change for the ERP-OFDM frame format follows 17.3.7.
18.3.4 CCA
The PHY shall provide the capability to perform a CCA and report the results of the assessment to the MAC.
The CCA mechanism shall detect a “medium busy” condition for all supported preamble and header types.
That is, the CCA mechanism shall detect that the medium is busy for the PPDUs specified in 17.3.2 and
16.2.2. The CCA mechanism performance requirements are given in 18.4.6.
The ERP shall provide the capability to perform CCA according to the following method:
CCA Mode (ED and CS): A combination of CS and energy above threshold. CCA shall have a
mechanism for CS that detects all mandatory Clause 18 sync symbols. This CCA’s mode’s CS shall
include both Barker code sync detection and OFDM sync symbol detection. CCA shall report busy
at least while a PPDU is being received with energy above the ED threshold at the antenna.
The PHY shall indicate a busy channel by issuing a PHY-CCA.indication(BUSY) primitive and shall
indicate a clear channel by issuing a PHY-CCA.indication(IDLE) primitive.
18.3.5 PHY receive procedure
This subclause describes the procedure used by receivers of the ERP. An ERP receiver shall be capable of
receiving 1, 2, 5.5, and 11 Mb/s PPDUs using either the long or short preamble formats described in
Clause 16 and shall be capable of receiving 6, 12, and 24 Mb/s using the modulation and preamble described
in Clause 17. The PHY may also implement the ERP-OFDM modulations at rates of 9, 18, 36, 48, and 54
Mb/s. The receiver shall be capable of detecting the preamble type (ERP-OFDM, short preamble, or long
preamble) and the modulation type. These values shall be reported in the RXVECTOR (see 18.2).
Upon the receipt of a PPDU, the receiver shall first distinguish between the ERP-OFDM preamble and the
single carrier modulations (long or short preamble). In the case where the preamble is an ERP-OFDM
preamble, the PHY receive procedure shall follow the procedure described in 17.3.12. Otherwise, the
receiver shall then distinguish between the long preamble and short preamble as specified in 16.2.2. The
receiver shall then demodulate the SERVICE field to determine the modulation type as specified in 18.3.2.2
or 18.3.2.3. For short preamble and long preamble using ERP-DSSS or ERP-CCK, the receiver shall then
follow the receive procedure described in 16.2.6.
18.4 ERP operating specifications (general)
18.4.1 Introduction
Subclauses 18.4.2 to 18.4.7 provide general specifications for the ERP sublayers. These specifications are
based on 17.3.8 except where noted.
18.4.2 Regulatory requirements
All systems shall comply with the appropriate regulatory requirements for operation in the 2.4 GHz band.
2327
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
18.4.3 Operating channel frequencies
The ERP shall operate in the frequency ranges specified in 16.3.6.3, as allocated by regulatory bodies in the
United States, Europe, and Japan. The channel numbering and the number of operating channels shall follow
Table 16-6 of 16.3.6.3.
18.4.4 Transmit and receive in-band and out-of-band spurious emissions
The ERP shall comply with in-band and out-of-band spurious emissions as set by the appropriate regulatory
bodies for the 2.4 GHz band.
18.4.5 SIFS
The ERP shall use a SIFS of 10 µs.
18.4.6 CCA performance
The CCA shall indicate true if there is no CCA “medium busy” indication. The CCA parameters are subject
to the following criteria:
a) When the start of a valid ERP-OFDM signal or valid ERP-DSSS/CCK sync symbols at a receive
level greater than or equal to –82 dBm at the receiver antenna connector are present at the start of the
PHY slot, the receiver’s CCA indicator shall report the channel busy with probability
CCA_Detect_Probability within a aCCATime. CCA_Detect_Probabilty is the probability that the
CCA does respond correctly to a valid signal and shall be at least 99% for the long slot time and at
least 90% for the short slot time. The values for the other parameters are found in Table 18-5. Note
that the CCA Detect Probability and the power level are performance requirements.
b) In the event that a correct PHY header is received, the ERP shall hold the CCA signal inactive
(channel busy) for the full duration, as indicated by the PHY LENGTH field. Should a loss of CS
occur in the middle of reception, the CCA shall indicate a busy medium for the intended duration of
the transmitted PPDU.
c) CCA shall report a busy medium upon detection of any energy above –62 dBm.
18.4.7 PHY transmit specifications
18.4.7.1 General
The PHY transmit specifications shall follow 17.3.9 with the exception of the transmit power level
(17.3.9.2), the transmit center frequency tolerance (17.3.9.5), the symbol clock frequency tolerance
(17.3.9.6), and the time of departure accuracy (17.3.9.9). Regulatory requirements may have an effect on the
combination of maximum transmit power and spectral mask if the resulting signals violate restricted band
emission limits.
18.4.7.2 Transmit power levels
The maximum transmit power level shall meet the requirements of the local regulatory body.
18.4.7.3 Transmit spectral mask
The transmit spectral mask for the ERP-OFDM modes shall follow 17.3.9.3 and is shown in Figure 17-13
therein. The transmit spectral mask for the ERP-DSSS modes shall follow 16.3.7.4 and is shown in
Figure 16-10 therein.
2328
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
18.4.7.4 Transmit center frequency tolerance
The transmit center frequency tolerance shall be ± 25 ppm maximum. The transmit center frequency and
symbol clock frequency shall be derived from the same reference oscillator (locked).
18.4.7.5 Symbol clock frequency tolerance
The symbol clock frequency tolerance shall be ± 25 ppm maximum. The transmit center frequency and
symbol clock frequency shall be derived from the same reference oscillator (locked oscillators). This means
that the error in ppm for the carrier and the symbol timing shall be the same.
18.4.7.6 Time of Departure accuracy
The time of departure specifications shall follow 17.3.9.9 for PPDUs transmitted using ERP-OFDM format
and 16.3.7.10 for PPDUs transmitted using ERP-DSSS/CCK.
18.4.8 PHY receive specifications
18.4.8.1 General
Subclause 18.4.8 describes the receive specifications for the PHY sublayer. The receive specification for the
ERP-OFDM modes shall follow 17.3.10 with the exception of the receiver maximum input level (17.3.10.5)
and the adjacent channel rejection (17.3.10.3). The receive specifications for the ERP-DSSS modes shall
follow 16.3.8 with the exception of the receiver maximum input level (16.3.8.3).
18.4.8.2 Receiver minimum input level sensitivity
The PER of the ERP-OFDM modes shall be less than 10% at a PSDU length of 1000 octets for the input
levels of Table 17-18 of 17.3.10. Input levels are specific for each data rate and are measured at the antenna
connector. A noise figure of 10 dB and an implementation loss of 5 dB are assumed. The PER of the ERP-
DSSS modes shall be as specified in 16.3.8.2.
18.4.8.3 Adjacent channel rejection
Adjacent channels at 2.4 GHz are defined to be at ± 25 MHz spacing. The adjacent channel rejection shall be
measured by setting the desired signal’s strength 3 dB above the rate-dependent sensitivity specified in
Table 17-18 of 17.3.10 and raising the power of the interfering signal until 10% PER is caused for a PSDU
length of 1000 octets. The difference in power between the signals in the interfering channel and the desired
channel is the corresponding adjacent channel rejection. The interfering signal in the adjacent channel shall
be a signal compliant with the ERP, unsynchronized with the signal in the channel under test. In an ERP the
corresponding rejection shall be no less than specified in Table 17-18 of 17.3.10.
The alternative adjacent channel rejection of Table 17-18 shall not be required for the ERP.
The adjacent channel rejection of the ERP-DSSS modes shall follow 16.3.8.4.
18.4.8.4 Receive maximum input level capability
The PER shall be less than 10% at a PSDU length of 1000 octets for an input level of –20 dBm measured at
the antenna connector for any supported modulation signal or data rate (i.e., 1, 2, 5.5, 6, 9, 11, 12, 18, 22, 24,
33, 36, 48, 54 Mb/s).
2329
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
18.5 ERP PLME
18.5.1 PLME SAP
Table 18-4 lists the additional MIB attributes that may be accessed by the PHY entities and the intralayer of
higher LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME-
CHARACTERISTICS primitives defined in 6.5.
18.5.2 MIB
HR/DSSS PHY MIB attributes are defined in Annex C with additions from this supplement and with
specific values defined in Table 18-4.
Table 18-4—MIB attribute default values/ranges
Managed object Default value/range Operational semantics
dot11 PHY Operation Table
dot11PHYtype ERP (X'06') Static
dot11CurrentRegDomain Implementation dependent Static
dot11 PHY Antenna Table
dot11CurrentTxAntenna Implementation dependent Dynamic
dot11DiversitySupportImplemented Implementation dependent Static
dot11CurrentRxAntenna Implementation dependent Dynamic
dot11 PHY Tx Power Table
dot11NumberSupportedPowerLevelsImpleme Implementation dependent Static
nted
dot11TxPowerLevel1 Implementation dependent Static
dot11TxPowerLevel2 Implementation dependent Static
dot11TxPowerLevel3 Implementation dependent Static
dot11TxPowerLevel4 Implementation dependent Static
dot11TxPowerLevel5 Implementation dependent Static
dot11TxPowerLevel6 Implementation dependent Static
dot11TxPowerLevel7 Implementation dependent Static
dot11TxPowerLevel8 Implementation dependent Static
dot11CurrentTxPowerLevel Implementation dependent Dynamic
dot11 Phy DSSS Table
dot11CurrentChannel Implementation dependent Dynamic
dot11 Reg Domains Supported Table
dot11RegDomainsImplementedValue(s) Implementation dependent Static
dot11 PHY Antennas List Table
dot11TxAntennaImplemented Implementation dependent Static
dot11RxAntennaImplemented Implementation dependent Static
dot11DiversitySelectionRxImplemented Implementation dependent Dynamic
2330
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 18-4—MIB attribute default values/ranges (continued)
Managed object Default value/range Operational semantics
dot11 Supported Data Rates Tx Table
dot11SupportedDataratesTxValue X'02' = 1 Mb/s Static
X'04' = 2 Mb/s
X'0B' = 5.5 Mb/s
X'16' = 11 Mb/s
X'0C' = 6 Mb/s
X'12' = 9 Mb/s
X'18' = 12 Mb/s
X'24' = 18 Mb/s
X'30' = 24 Mb/s
X'48' = 36 Mb/s
X'60' = 48 Mb/s
X'6C' = 54 Mb/s
dot11 Supported Data Rates Rx Table
dot11ImplementedDataRatesRxValue X'02' = 1 Mb/s Static
X'04' = 2 Mb/s
X'0B' = 5.5 Mb/s
X'16' = 11 Mb/s
X'0C' = 6 Mb/s
X'12' = 9 Mb/s
X'18' = 12 Mb/s
X'24' = 18 Mb/s
X'30' = 24 Mb/s
X'48' = 36 Mb/s
X'60' = 48 Mb/s
X'6C' = 54 Mb/s
dot11 HRDSSS PHY Table
dot11ShortPreambleOptionImplemented true/Boolean Static
dot11 PHY ERP Table
dot11ShortSlotTimeOptionImplemented false/Boolean Static
dot11ShortSlotTimeOptionActivated false/Boolean Dynamic
18.5.3 TXTIME
18.5.3.1 General
The value of TXTIME is calculated for each modulation type based on parameters in the TXVECTOR. For
the 1, 2, 5.5, and 11 Mb/s modes with DSSS and CCK modulation formats, the value shall be calculated as
described in 16.3.4.
18.5.3.2 ERP-OFDM TXTIME calculations
The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated
using the ERP-OFDM TXTIME calculation as shown in Equation (18-1).
TXTIME = T PREAMBLE + T SIGNAL + T SYM 16 + 8 LENGTH + 6 + T (18-1)
------------------------------------------------------- SE
N DBPS
2331
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
TPREAMBLE, TSIGNAL, and TSYM are defined in Table 17-5 in 17.3.2.4
NDBPS is the number of data bits per symbol and is derived from the
DATARATE parameter in Table 17-4 in 17.3.2.3
TSE is aSignalExtension
18.5.4 ERP characteristics
The ERP characteristics in Table 18-5 shall be used for the ERP for the purposes of MAC timing
calculations.
Table 18-5—ERP characteristics
Characteristic Value
aSlotTime If dot11OperatingClassesRequired is false:
Long = 20 µs
Short = 9 µs
If dot11OperatingClassesRequired is true:
Long = 20 µs plus any coverage-class-dependent aAirPropagationTime (see
Table 9-79)
Short = 9 µs plus any coverage-class-dependent aAirPropagationTime (see
Table 9-79)
aSIFSTime 10 µs
aSignalExtension 6 µs
aCCATime Implementation dependent, see 10.3.7.
aRxPHYStartDelay 20 µs for ERP-OFDM,
192 µs for ERP-DSSS/CCK with long preamble, and
96 µs for ERP-DSSS/CCK with short preamble
aRxTxTurnaroundTime Implementation dependent, see 10.3.7.
aTxPHYDelay Implementation dependent, see 10.3.7.
aRxPHYDelay Implementation dependent, see 10.3.7.
aRxTxSwitchTime Implementation dependent, see 10.3.7.
aTxRampOnTime Implementation dependent, see 10.3.7.
aAirPropagationTime As indicated by the coverage class (see 10.21.5).
aMACProcessingDelay Implementation dependent, see 10.3.7.
aPreambleLength 16 µs for ERP-OFDM,
144 µs for ERP-DSSS/CCK with long preamble,
72 µs for ERP-DSSS/CCK with short preamble
aPHYHeaderLength 4 µs for ERP-OFDM,
48 µs for ERP-DSSS/CCK with long preamble,
24 µs for ERP-DSSS/CCK with short preamble
aPSDUMaxLength 4095 octets
aCWmin(0) 31
aCWmin(1) 15
ACWmin The set aCWmin()
aCWmax 1023
2332
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The long slot time indicated in Table 18-5 shall be used unless the BSS consists only of ERP STAs that
support the Short Slot Time option. STAs indicate support for a short slot time by setting the Short Slot
Time subfield to 1 when transmitting Association Request and Reassociation Request frames. If the BSS
consists of only ERP STAs that support the Short Slot Time option, an optional short slot time may be used.
APs indicate usage of the short slot time indicated in Table 18-5 by setting the Short Slot Time subfield to 1
in all Beacon, Probe Response, Association Response, and Reassociation Response frame transmissions as
described in 9.4.1.4. A STA shall use short slot if the BSS indicates short slot.
2333
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19. High-throughput (HT) PHY specification
19.1 Introduction
19.1.1 Introduction to the HT PHY
Clause 19 specifies the PHY entity for a high-throughput (HT) orthogonal frequency division multiplexing
(OFDM) system.
In addition to the requirements found in Clause 19, an HT STA shall be capable of transmitting and
receiving frames that are compliant with the mandatory PHY specifications defined as follows:
— In Clause 17 when the HT STA is operating in a 20 MHz channel width in the 5 GHz band
— In Clause 16 and Clause 18 when the HT STA is operating in a 20 MHz channel width in the
2.4 GHz band
The HT PHY is based on the OFDM PHY defined in Clause 17, with extensibility up to four spatial streams,
operating in 20 MHz bandwidth. Additionally, transmission using one to four spatial streams is defined for
operation in 40 MHz bandwidth. These features are capable of supporting data rates up to 600 Mb/s
(four spatial streams, 40 MHz bandwidth).
The HT PHY data subcarriers are modulated using binary phase shift keying (BPSK), quadrature phase shift
keying (QPSK), 16-quadrature amplitude modulation (16-QAM), or 64-QAM. Forward error correction
(FEC) coding (convolutional coding) is used with a coding rate of 1/2, 2/3, 3/4, or 5/6. LDPC codes are
added as an optional feature.
Other optional features at both transmit and receive sides are 400 ns (short) guard interval (GI), transmit
beamforming, HT-greenfield format, and STBC.
The maximum HT PSDU length is 65 535 octets.
19.1.2 Scope
The services provided to the MAC by the HT PHY consist of the following protocol functions:
a) A function that defines a method of mapping the PSDUs into a framing format (PPDU) suitable for
sending and receiving PSDUs between two or more STAs.
b) A function that defines the characteristics and method of transmitting and receiving data through a
wireless medium between two or more STAs. Depending on the PPDU format, these STAs support
a mixture of HT PHY and Clause 15, Clause 17, Clause 16, or Clause 18 PHYs.
19.1.3 HT PHY functions
19.1.3.1 General
The HT PHY contains two functional entities: the PHY and the layer management function (i.e., the PLME).
Both of these functions are described in detail in 19.3 and 19.4.
The HT PHY service is provided to the MAC through the PHY service primitives defined in Clause 8.
19.1.3.2 PHY management entity (PLME)
The PLME performs management of the local PHY functions in conjunction with the MLME.
2334
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.1.3.3 Service specification method
The models represented by figures and state diagrams are intended to be illustrations of the functions
provided. It is important to distinguish between a model and a real implementation. The models are
optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular
implementation. The service of a layer or sublayer is the set of capabilities that it offers to a user in the next
higher layer (or sublayer). Abstract services are specified here by describing the service primitives and
parameters that characterize each service. This definition is independent of any particular implementation.
19.1.4 PPDU formats
The structure of the PPDU transmitted by an HT STA is determined by the TXVECTOR FORMAT,
CH_BANDWIDTH, CH_OFFSET, and MCS parameters as defined in Table 19-1. The effect of the
CH_BANDWIDTH, CH_OFFSET, and MCS parameters on PPDU format is described in 19.2.4.
The FORMAT parameter determines the overall structure of the PPDU as follows:
— Non-HT format (NON_HT): Packets of this format are structured according to the Clause 17
(OFDM) or Clause 18 (ERP) specification. Support for non-HT format is mandatory.
— HT-mixed format (HT_MF): Packets of this format contain a preamble compatible with Clause 17
and Clause 18 receivers. The non-HT-STF (L-STF), the non-HT-LTF (L-LTF), and the non-HT
SIGNAL field (L-SIG) are defined so they can be decoded by non-HT Clause 17 and Clause 18
STAs. The rest of the packet cannot be decoded by Clause 17 or Clause 18 STAs. Support for HT-
mixed format is mandatory.
— HT-greenfield format (HT_GF): HT packets of this format do not contain a non-HT compatible
part. Support for HT-greenfield format is optional. An HT STA that does not support the reception
of an HT-greenfield format packet shall be able to detect that an HT-greenfield format packet is an
HT transmission (as opposed to a non-HT transmission). In this case, the receiver shall decode the
HT-SIG and determine whether the HT-SIG cyclic redundancy check (CRC) passes.
19.2 HT PHY service interface
19.2.1 Introduction
The PHY interfaces to the MAC through the TXVECTOR, TXSTATUS, RXVECTOR, and
PHYCONFIG_VECTOR. Using the TXVECTOR, the MAC supplies the PHY with per-PPDU transmit
parameters. Status of the transmission is reported from PHY to MAC by parameters within TXSTATUS.
Using the RXVECTOR, the PHY informs the MAC of the received packet parameters. Using the
PHYCONFIG_VECTOR, the MAC configures the PHY for operation, independent of frame transmission
or reception.
This interface is an extension of the generic PHY service interface defined in 8.3.4.
19.2.2 TXVECTOR and RXVECTOR parameters
The parameters in Table 19-1 are defined as part of the TXVECTOR parameter list in
the PHY-TXSTART.request primitive and/or as part of the RXVECTOR parameter list in the
PHY-RXSTART.indication primitive.
2335
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-1—TXVECTOR and RXVECTOR parameters
RXVECTOR
TXVECTOR
Parameter
Condition Value
See
NOTE 1
Determines the format of the PPDU. Y Y
Enumerated type:
NON_HT indicates Clause 15, Clause 17, Clause 16, or Clause 18
FORMAT
PPDU formats or non-HT duplicate PPDU format. In this case, the
modulation is determined by the NON_HT_MODULATION
parameter.
HT_MF indicates HT-mixed format.
HT_GF indicates HT-greenfield format.
FORMAT is Enumerated type: Y Y
NON_HT_ MODULATION
NON_HT ERP-DSSS
ERP-CCK
ERP-OFDM
OFDM
NON_HT_DUP_OFDM
Otherwise Not present
FORMAT is Indicates the length of the PSDU in octets in the range 1 to 4095. This Y Y
NON_HT value is used by the PHY to determine the number of octet transfers that
occur between the MAC and the PHY.
L_LENGTH
FORMAT is HT_MF Indicates the value in the Length field of the L-SIG in the range 1 to 4095. Y Y
This use is defined in 10.26.4. This parameter may be used for the
protection of more than one PPDU as described in 10.26.5.
FORMAT is HT_GF Not present N N
FORMAT is Indicates the rate used to transmit the PSDU in megabits per second. Y Y
NON_HT Allowed values depend on the value of the NON_HT_MODULATION
parameter as follows:
ERP-DSSS: 1 and 2
L_DATARATE
ERP-CCK: 5.5 and 11
ERP-OFDM, NON_HT_DUP_OFDM:
6, 9, 12, 18, 24, 36, 48, and 54
OFDM: 6, 9, 12, 18, 24, 36, 48, and 54
FORMAT is HT_MF Indicates the data rate value that is in the L-SIG. This use is defined in Y Y
10.26.4.
FORMAT is HT_GF Not present N N
FORMAT is HT_MF true if L-SIG Parity is valid N Y
LSIGVALID
false if L-SIG Parity is not valid
Otherwise Not present N N
2336
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
See
NOTE 1
FORMAT is Scrambler initialization, null Y N
NON_HT and
NON_HT_MODUL
ATION is one of
SERVICE
— ERP-OFDM
— OFDM
FORMAT is HT_MF Scrambler initialization, null Y N
or HT_GF
Otherwise Not present N N
The allowed values for the TXPWR_LEVEL_INDEX parameter are in the Y N
TXPWR_LEVEL_INDEX
range 1 to 8. This parameter is used to indicate which of the available
TxPowerLevel attributes defined in the MIB shall be used for the current
transmission.
The allowed values for the RSSI parameter are in the range 0 to RSSI N Y
maximum. This parameter is a measure by the PHY of the power observed
at the antennas used to receive the current PPDU. RSSI shall be measured
RSSI
during the reception of the PHY preamble. In HT-mixed format, the
reported RSSI shall be measured during the reception of the HT-LTFs.
RSSI is intended to be used in a relative manner, and it shall be a
monotonically increasing function of the received power.
FORMAT is Enumerated type: Y Y
PREAMBLE_TYPE
NON_HT and SHORTPREAMBLE
NON_HT_MODUL LONGPREAMBLE
ATION is one of
— ERP-DSSS
— ERP-CCK
Otherwise Not present N N
FORMAT is HT_MF Selects the modulation and coding scheme used in the transmission of the Y Y
or HT_GF packet. The value used in each MCS is the index defined in 19.5.
MCS
Integer: range 0 to 76. Values of 77 to 127 are reserved.
The interpretation of the MCS index is defined in 19.5.
Otherwise Not present N N
FORMAT is HT_MF Indicates the MCS that the STA’s receiver recommends. N O
REC_MCS
or HT_GF
Otherwise Not present N N
2337
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
See
NOTE 1
FORMAT is HT_MF Indicates whether the packet is transmitted using 40 MHz or 20 MHz Y Y
CH_BANDWIDTH
or HT_GF channel width.
Enumerated type:
HT_CBW20 for 20 MHz and 40 MHz upper and 40 MHz lower modes
HT_CBW40 for 40 MHz
FORMAT is Enumerated type: Y Y
NON_HT NON_HT_CBW40 for non-HT duplicate format
NON_HT_CBW20 for all other non-HT formats
Indicates which portion of the channel is used for transmission. Refer to Y N
Table 19-2 for valid combinations of CH_OFFSET and
CH_BANDWIDTH.
CH_OFFSET
Enumerated type:
CH_OFF_20 indicates the use of a 20 MHz channel (that is not part of a
40 MHz channel).
CH_OFF_40 indicates the entire 40 MHz channel.
CH_OFF_20U indicates the upper 20 MHz of the 40 MHz channel
CH_OFF_20L indicates the lower 20 MHz of the 40 MHz channel.
FORMAT is HT_MF Indicates the length of an HT PSDU in the range 0 to 65 535 octets. A Y Y
LENGTH
or HT_GF value of 0 indicates a NDP that contains no data symbols after the HT
preamble (see 19.3.9).
Otherwise Not present N N
FORMAT is HT_MF Indicates whether frequency domain smoothing is recommended as part of Y Y
or HT_GF channel estimation. (See NOTE 2.)
SMOOTHING
Enumerated type:
SMOOTHING_REC indicates that smoothing is recommended.
SMOOTHING_NOT_REC indicates that smoothing is not
recommended.
Otherwise Not present N N
FORMAT is HT_MF Indicates whether this packet is a sounding packet. Y Y
SOUNDING
or HT_GF Enumerated type:
SOUNDING indicates this is a sounding packet.
NOT_SOUNDING indicates this is not a sounding packet.
Otherwise Not present N N
FORMAT is HT_MF Indicates whether the PSDU contains an A-MPDU. Y Y
AGGREGATION
or HT_GF Enumerated type:
AGGREGATED indicates this PSDU has A-MPDU aggregation.
NOT_AGGREGATED indicates this PSDU does not have A-MPDU
aggregation.
Otherwise Not present N N
2338
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
See
NOTE 1
FORMAT is HT_MF Indicates the difference between the number of space-time streams ( N STS ) Y Y
or HT_GF
and the number of spatial streams ( N SS ) indicated by the MCS as follows:
0 indicates no STBC ( N STS = N SS ).
STBC
1 indicates N STS – N SS = 1 .
2 indicates N STS – N SS = 2 .
Value of 3 is reserved.
Otherwise Not present N N
FORMAT is HT_MF Indicates which FEC encoding is used. Y Y
FEC_CODING
or HT_GF Enumerated type:
BCC_CODING indicates binary convolutional code.
LDPC_CODING indicates low-density parity check code.
Otherwise Not present N N
FORMAT is HT_MF Indicates whether a short guard interval is used in the transmission of the Y Y
or HT_GF packet.
GI_TYPE
Enumerated type:
LONG_GI indicates short GI is not used in the packet.
SHORT_GI indicates short GI is used in the packet.
Otherwise Not present N N
FORMAT is HT_MF Indicates the number of extension spatial streams that are sounded during Y Y
NUM_EXTEN_SS
or HT_GF the extension part of the HT training in the range 0 to 3.
Otherwise Not present N N
FORMAT is HT_MF Indicates which antennas of the available antennas are used in the O N
ANTENNA_SET
or HT_GF transmission. The length of the field is 8 bits. A 1 in bit position n, relative
to the LSB, indicates that antenna n is used. At most 4 bits out of 8 may be
set to 1.
This field is present only if ASEL is applied.
Otherwise Not present N N
FORMAT is HT_MF The N_TX parameter indicates the number of transmit chains. Y N
N_TX
or HT_GF
Otherwise Not present N N
2339
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
See
NOTE 1
EXPANSION_MAT Contains a set of compressed beamforming feedback matrices as defined Y N
_TYPE is in 19.3.12.3.6. The number of elements depends on the number of spatial
COMPRESSED_SV streams and the number of transmit chains.
EXPANSION_MAT Contains a set of noncompressed beamforming feedback matrices as Y N
EXPANSION_MAT
_TYPE is defined in 19.3.12.3.5. The number of complex elements is N ST N r N c
NON_COMPRESSE
where N ST is the total number of subcarriers, N c is the number of
D_SV
columns, and N r is the number of rows in each matrix.
EXPANSION Contains a set of CSI matrices as defined in 19.3.12.3.2. The number of Y N
_MAT_TYPE is complex elements is N ST N r N c where N ST is the total number of
CSI_MATRICES
subcarriers, N c is the number of columns, and N r is the number of rows in
each matrix.
Otherwise Not present N N
EXPANSION_MAT Enumerated type: Y N
EXPANSION_MAT_TYPE
is present COMPRESSED_SV indicates that EXPANSION_MAT is a set of
compressed beamforming feedback matrices.
NON_COMPRESSED_SV indicates that EXPANSION_MAT is a set of
noncompressed beamforming feedback matrices.
CSI_MATRICES indicates that EXPANSION_MAT is a set of channel
state matrices.
Otherwise Not present N N
CHAN_MAT_TYPE Contains a set of compressed beamforming feedback matrices as defined N Y
is in 19.3.12.3.6 based on the channel measured during the training symbols
COMPRESSED_SV of the received PPDU. The number of elements depends on the number of
spatial streams and the number of transmit chains.
CHAN_MAT_TYPE Contains a set of noncompressed beamforming feedback matrices as N Y
is defined in 19.3.12.3.5 based on the channel measured during the training
NON_COMPRESSE symbols of the received PPDU. The number of complex elements is
CHAN_MAT
D_SV N ST N r N c where N ST is the total number of subcarriers, N c is the
number of columns, and N r is the number of rows in each matrix.
CHAN_MAT_TYPE Contains a set of CSI matrices as defined in 19.3.12.3.2 based on the N Y
is CSI_MATRICES channel measured during the training symbols of the received PPDU. The
number of complex elements is N ST N r N c where N ST is the total
number of subcarriers, N c is the number of columns, and N r is the number
of rows in each matrix.
Otherwise Not present N N
2340
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
See
NOTE 1
FORMAT is HT_MF Enumerated type: N Y
CHAN_MAT_TYPE
or HT_GF COMPRESSED_SV indicates that CHAN_MAT is a set of compressed
beamforming vector matrices.
NON_COMPRESSED_SV indicates that CHAN_MAT is a set of
noncompressed beamforming vector matrices.
CSI_MATRICES indicates that CHAN_MAT is a set of channel state
matrices.
Otherwise Not present N N
Is a measure of the received RF power averaged over all of the receive N Y
RCPI
chains in the data portion of a received frame.
Refer to 19.3.19.6 for the definition of RCPI.
CHAN_MAT_TYPE Is a measure of the received SNR per chain. SNR indications of 8 bits are N Y
is CSI_MATRICES supported. SNR shall be the decibel representation of linearly averaged
values over the tones represented in each receive chain as described in
9.4.1.28
SNR
CHAN_MAT_TYPE Is a measure of the received SNR per stream. SNR indications of 8 bits are N Y
is supported. SNR shall be the sum of the decibel values of SNR per tone
COMPRESSED_SV divided by the number of tones represented in each stream as described in
or 9.4.1.29 and 9.4.1.30
NON_COMPRESSE
D_SV
FORMAT is HT_MF Indicates whether signal extension needs to be applied at the end of Y N
or HT_GF transmission.
NO_SIG_EXTN
Or Boolean values:
true indicates no signal extension is present.
FORMAT is false indicates signal extension may be present depending on other
NON_HT and TXVECTOR parameters (see 19.2.2).
NON_HT_MODUL
ATION is NON_HT_
DUP_OFDM
Otherwise Not present N N
2341
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
See
NOTE 1
Enumerated type:
TIME_OF_DEPARTURE_REQUESTED
O N
true indicates that the MAC entity requests that the PHY entity measures
and reports time of departure parameters corresponding to the time when
the first frame energy is sent by the transmitting port. false indicates that
the MAC entity requests that the PHY entity neither measures nor reports
time of departure parameters.
0 to 232– 1. An estimate of the offset (in 10 ns units) from the point in time N O
RX_START_OF_FRAME_OFFSET
at which the start of the preamble corresponding to the incoming frame
arrived at the receive antenna connector to the point in time at which this
primitive is issued to the MAC.
NOTE 1—In the “TXVECTOR” and “RXVECTOR” columns, the following apply:
Y = Present; N = Not present; O = Optional.
NOTE 2—Setting the smoothing bit is defined in 19.3.11.11.2.
19.2.3 PHYCONFIG_VECTOR parameters
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an HT PHY contains an
OPERATING_CHANNEL parameter, which identifies the operating or primary channel. The PHY shall set
dot11CurrentPrimaryChannel to the value of this parameter.
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an HT PHY contains a
SECONDARY_CHANNEL_OFFSET parameter, which takes one of the following values:
— SECONDARY_CHANNEL_NONE if no secondary channel is present; in this case the PHY shall
set dot11CurrentSecondaryChannel to 0.
— SECONDARY_CHANNEL_ABOVE if the secondary channel is above the primary channel; in this
case the PHY shall set dot11CurrentSecondaryChannel to dot11CurrentPrimaryChannel + 4.
2342
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— SECONDARY_CHANNEL_BELOW if the secondary channel is below the primary channel; in this
case the PHY shall set dot11CurrentSecondaryChannel to dot11CurrentPrimaryChannel – 4.
19.2.4 Effect of CH_BANDWIDTH, CH_OFFSET, and MCS parameters on PPDU format
The structure of the PPDU transmitted by an HT STA is determined by the TXVECTOR FORMAT,
CH_BANDWIDTH, CH_OFFSET, and MCS parameters as defined in Table 19-1. The effect of the
FORMAT parameter is described in 19.1.4.
The operation of the PHY in the frequency domain is determined by the FORMAT, CH_BANDWIDTH, and
CH_OFFSET parameters. Table 19-2 shows the valid combinations of FORMAT, CH_BANDWIDTH,
and CH_OFFSET and the corresponding PPDU format. Other combinations are reserved.
Table 19-2—Interpretation of FORMAT, CH_BANDWIDTH, and
CH_OFFSET parameters
FORMAT CH_BANDWIDTH CH_OFFSET
HF_MF, HT_CBW20 CH_OFF_20: 20 MHz HT format—The STA has a 20 MHz operating
HF_GF channel width and transmits an HT-mixed or HT-greenfield format
PPDU of 20 MHz bandwidth.
CH_OFF_20U: 40 MHz HT upper format—The STA transmits an
HT-mixed or HT-greenfield format PPDU of 20 MHz bandwidth in
the upper 20 MHz of a 40 MHz channel.
CH_OFF_20L: 40 MHz HT lower format—The STA transmits an HT-
mixed or HT-greenfield format PPDU of 20 MHz bandwidth in the
lower 20 MHz of a 40 MHz channel.
HT_MF, HT_CBW40 CH_OFF_40: 40 MHz HT format—The STA transmits an HT-mixed
HT_GF or HT-greenfield format PPDU of 40 MHz bandwidth.
NON_HT NON_HT_CBW20 and CH_OFF_20: 20 MHz non-HT format—The STA has a 20 MHz
the operating channel width and transmits an ERP-DSSS, ERP-CCK,
SECONDARY_CHANN ERP-OFDM, or OFDM format PPDU.
EL_OFFSET parameter of
the
PHYCONFIG_VECTOR
is
SECONDARY_CHANN
EL_NONE
NON_HT NON_HT_CBW20 and CH_OFF_20U: 40 MHz non-HT upper format—The STA transmits an
the ERP-DSSS, ERP-CCK, ERP-OFDM, or OFDM format PPDU, in the
SECONDARY_CHANN upper 20 MHz of a 40 MHz channel.
EL_OFFSET parameter of
the
PHYCONFIG_VECTOR
is
SECONDARY_CHANN
EL_BELOW
2343
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-2—Interpretation of FORMAT, CH_BANDWIDTH, and
CH_OFFSET parameters (continued)
FORMAT CH_BANDWIDTH CH_OFFSET
NON_HT NON_HT_CBW20 and CH_OFF_20L: 40 MHz non-HT lower format—The STA transmits an
the ERP-DSSS, ERP-CCK, ERP-OFDM, or OFDM format PPDU, in the
SECONDARY_CHANN lower 20 MHz of a 40 MHz channel.
EL_OFFSET parameter of
the
PHYCONFIG_VECTOR
is
SECONDARY_CHANN
EL_ABOVE
NON_HT NON_HT_CBW40 CH_OFF_40: Non-HT duplicate format—The STA transmits an ERP-
OFDM or OFDM format PPDU in each of the 20 MHz channels of a
40 MHz channel. The upper channel (higher frequency) is rotated by
+90° relative to the lower channel. See 19.3.11.12.
NOTE—Support of 20 MHz non-HT format and 20 MHz HT format with one and two spatial streams is mandatory at
APs. Support of 20 MHz non-HT format and 20 MHz HT format with one spatial stream is mandatory at non-AP STAs.
19.2.5 Support for NON_HT formats
When the FORMAT parameter is equal to NON_HT, the behavior of the HT PHY is defined in other clauses
as shown in Table 19-3, dependent on the operational band. In this case, the PHY-TXSTART.request
primitive is handled by mapping the TXVECTOR parameters as defined in Table 19-3 and following the
operation as defined in the referenced clause. Likewise the PHY-RXSTART.indication primitive emitted
when a non-HT PPDU is received is defined in the referenced clauses, with mapping of RXVECTOR
parameters as defined in Table 19-3.
Table 19-3—Mapping of the HT PHY parameters for NON_HT operation
2.4 GHz operation 2.4 GHz operation 2.4 GHz operation 5.0 GHz operation
HT PHY
defined by defined by defined by defined by
parameter
Clause 15 Clause 16 Clause 18 Clause 17
L_LENGTH LENGTH LENGTH LENGTH LENGTH
L_DATARATE DATARATE DATARATE DATARATE DATARATE
LSIGVALID — — — —
TXPWR_LEVEL_I TXPWR_LEVEL_I TXPWR_LEVEL_I TXPWR_LEVEL_I TXPWR_LEVEL_I
NDEX NDEX NDEX NDEX NDEX
RSSI RSSI RSSI RSSI RSSI
FORMAT — — — —
PREAMBLE_TYP — — PREAMBLE_TYP —
E E
NON_HT_MODUL — — MODULATION —
ATION
SERVICE SERVICE SERVICE SERVICE SERVICE
MCS — — — —
2344
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-3—Mapping of the HT PHY parameters for NON_HT operation (continued)
2.4 GHz operation 2.4 GHz operation 2.4 GHz operation 5.0 GHz operation
HT PHY
defined by defined by defined by defined by
parameter
Clause 15 Clause 16 Clause 18 Clause 17
CH_BANDWIDTH — — — —
CH_OFFSET — — — —
LENGTH — — — —
SMOOTHING — — — —
SOUNDING — — — —
AGGREGATION — — — —
STBC — — — —
FEC_CODING — — — —
GI_TYPE — — — —
NUM_EXTEN_SS — — — —
ANTENNA_SET — — — —
EXPANSION_MAT — — — —
EXPANSION_MAT — — — —
_TYPE
CHAN_MAT — — — —
CHAN_MAT_TYP — — — —
E
N_TX — — — —
RCPI RCPI RCPI RCPI RCPI
REC_MCS — — — —
NO_SIG_EXTN — — — —
TIME_OF_DEPART TIME_OF_DEPART TIME_OF_DEPART TIME_OF_DEPART TIME_OF_DEPART
URE_REQUESTED URE_REQUESTED URE_REQUESTED URE_REQUESTED URE_REQUESTED
NOTE—A dash (—) in an entry above indicates that the related parameter is not present.
Non-HT format PPDUs structured according to Clause 15, Clause 17, Clause 16, or Clause 18 are
transmitted
— Within the limits of the transmit spectrum mask specified in the respective clauses, or
— As non-HT duplicate PPDUs within the limits of the 40 MHz transmit spectrum mask defined in
19.3.18.1, or
— As 20 MHz format non-HT PPDUs, within the limits of the 40 MHz transmit spectrum mask defined
in 19.3.18.1, in the upper (CH_BANDWIDTH of value NON_HT_CBW20 and CH_OFFSET of
value CH_OFF_20U) or lower (CH_BANDWIDTH of value NON_HT_CBW20 and CH_OFFSET
of value CH_OFF_20U) 20 MHz of the 40 MHz channel
Non-HT PPDUs transmitted using the 40 MHz transmit spectrum mask are referred to as 40 MHz mask non-
HT PPDUs. Refer to 11.16.9 for CCA sensing rules for transmission of 40 MHz mask non-HT PPDUs.
2345
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.2.6 TXSTATUS parameters
The parameters listed in Table 19-4 are defined as part of the TXSTATUS parameter list in the PHY-
TXSTART.confirm(TXSTATUS) service primitive.
Table 19-4—TXSTATUS parameter
Parameter Value
TIME_OF_DEPARTURE 0 to 232– 1. The locally measured time when the first frame energy is
sent by the transmitting port, in units equal to 1/
TIME_OF_DEPARTURE_ClockRate. This parameter is present only
if TIME_OF_DEPARTURE_REQUESTED is true in the
corresponding request.
TIME_OF_DEPARTURE_ClockRate 0 to 216– 1. The clock rate, in units of MHz, is used to generate the
TIME_OF_DEPARTURE value. This parameter is present only if
TIME_OF_DEPARTURE_REQUESTED is true in the corresponding
request.
TX_START_OF_FRAME_OFFSET 0 to 232– 1. An estimate of the offset (in 10 ns units) from the point in
time at which the start of the preamble corresponding to the frame was
transmitted at the transmit antenna connector to the point in time at
which this primitive is issued to the MAC.
19.3 HT PHY
19.3.1 Introduction
Subclause 19.3 provides a procedure in which PSDUs are converted to and from PPDUs. During
transmission, the PSDU is processed (i.e., scrambled and coded) and appended to the PHY preamble to
create the PPDU. At the receiver, the PHY preamble is processed to aid in demodulation and delivery of the
PSDU.
Two preamble formats are defined. For HT-mixed format operation, the preamble has a non-HT portion and
an HT portion. The non-HT portion of the HT-mixed format preamble enables detection of the PPDU and
acquisition of carrier frequency and timing by both HT STAs and STAs that are compliant with Clause 17
and/or Clause 18. The non-HT portion of the HT-mixed format preamble also consists of the SIGNAL field
defined in Clause 17 and is thus decodable by STAs compliant with Clause 17 and Clause 18 as well as HT
STAs.
The HT portion of the HT-mixed format preamble enables estimation of the MIMO channel to support
demodulation of the HT data by HT STAs. The HT portion of the HT-mixed format preamble also includes
the HT-SIG field, which supports HT operation. The SERVICE field is prepended to the PSDU.
For HT-greenfield operation, compatibility with Clause 17 and Clause 18 STAs is not required. Therefore,
the non-HT portions of the preamble are not included in the HT-greenfield format preamble.
19.3.2 PPDU format
Two formats are defined for the PPDU: HT-mixed format and HT-greenfield format. These two formats are
called HT formats. Figure 19-1 shows the non-HT format48 and the HT formats. There is also an MCS 32
format (specified in 19.3.11.11.5) used for MCS 32 that provides the lowest rate in a 40 MHz channel. In
48
The non-HT format is shown related to the terminology of this subclause. The non-HT PPDU format is defined in 17.3.3 and 17.3.2.
2346
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
addition to the HT formats, there is a non-HT duplicate format (specified in 19.3.11.12) that duplicates the
20 MHz non-HT packet in two 20 MHz halves of a 40 MHz channel.
Format of Data field SERVICE Scrambled 6·NES Pad
(non LDPC case only) 16 bits PSDU Tail bits bits
Non-HT PPDU
8 µs 8 µs 4 µs
L-
L-STF L-LTF Data
SIG
HT-mixed format PPDU
Data HT-LTFs Extension HT-LTFs
8 µs 8 µs 4 µs 8 µs 4 µs 4 µs per LTF 4 µs per LTF
L- HT- HT- HT- HT- HT-
L-STF L-LTF HT-SIG Data
SIG STF LTF LTF LTF LTF
HT-greenfield format PPDU
Data HT-LTFs Extension HT-LTFs
8 µs 8 µs 8 µs 4 µs per LTF 4 µs per LTF
HT- HT- HT- HT-
HT-GF-STF HT-LTF1 HT-SIG Data
LTF LTF LTF LTF
Figure 19-1—PPDU format
The elements of the PPDU are summarized in Table 19-5.
Table 19-5—Elements of the HT PPDU
Element Description
L-STF Non-HT Short Training field
L-LTF Non-HT Long Training field
L-SIG Non-HT SIGNAL field
HT-SIG HT SIGNAL field
HT-STF HT Short Training field
HT-GF-STF HT-Greenfield Short Training field
HT-LTF1 First HT Long Training field (Data)
HT-LTFs Additional HT Long Training fields (Data and Extension)
Data The Data field includes the PSDU
The HT-SIG, HT-STF, HT-GF-STF, HT-LTF1, and HT-LTFs exist only in HT packets. In non-HT packets
only the L-STF, L-LTF, L-SIG, and Data fields exist.
In both HT-mixed format and HT-greenfield format frames, there are two types of HT-LTFs: Data HT-LTFs
(HT-DLTFs) and Extension HT-LTFs (HT-ELTFs). HT-DLTFs are always included in HT PPDUs to provide
the necessary reference for the receiver to form a channel estimate that allows it to demodulate the data
2347
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
portion of the frame. The number of HT-DLTFs, N HT - DLTF , may be 1, 2, or 4 and is determined by the
number of space-time streams being transmitted in the frame (see Table 19-13). HT-ELTFs provide
additional reference in sounding PPDUs so that the receiver can form an estimate of additional dimensions
of the channel beyond those that are used by the data portion of the frame. The number of HT-ELTFs,
N HT - ELTF , may be 0, 1, 2, or 4 (see Table 19-14). PHY preambles in which HT-DLTFs are followed by
HT-ELTFs are referred to as staggered preambles. The HT-mixed format and HT-greenfield format frames
shown in Figure 19-1 both contain staggered preambles for illustrative purposes.
Transmissions of frames with TXVECTOR parameter NO_SIG_EXTN equal to false are followed by a
period of no transmission for a duration of aSignalExtension. See 10.3.8.
A Signal Extension shall be present in a transmitted PPDU, based on the parameters of the TXVECTOR,
when the NO_SIG_EXTN parameter is equal to false and either of the following is true:
— The FORMAT parameter is equal to HT_MF or HT_GF.
— The FORMAT parameter is equal to NON_HT, and the NON_HT_MODULATION parameter is
equal to ERP-OFDM, or NON_HT_DUP_OFDM.
A Signal Extension shall be assumed to be present (for the purpose of timing of PHY-RXEND.indication
and PHY-CCA.indication primitives, as described below and in 19.3.21) in a received PPDU when either of
the following is true, based on the determined parameter values of the RXVECTOR:
— The FORMAT parameter is equal to HT_MF or HT_GF.
— The FORMAT parameter is equal to NON_HT, and the NON_HT_MODULATION parameter is
equal to ERP-OFDM, or NON_HT_DUP_OFDM.
A PPDU containing a Signal Extension is called a signal extended PPDU. When transmitting a signal
extended PPDU, the PHY-TXEND.indication primitive shall be emitted a period of aSignalExtension after
the end of the last symbol of the PPDU. When receiving a signal extended PPDU, the PHY-
RXEND.indication primitive shall be emitted a period of aSignalExtension after the end of the last symbol
of the PPDU.
19.3.3 Transmitter block diagram
HT-mixed format and HT-greenfield format transmissions can be generated using a transmitter consisting of
the following blocks:
a) Scrambler scrambles the data to reduce the probability of long sequences of 0s or 1s; see 19.3.11.3.
b) Encoder parser, if BCC encoding is to be used, demultiplexes the scrambled bits among NES
(number of BCC encoders for the Data field) BCC encoders, in a round robin manner.
c) FEC encoders encode the data to enable error correction. An FEC encoder may include a binary
convolutional encoder followed by a puncturing device, or it may include an LDPC encoder.
d) Stream parser divides the outputs of the encoders into blocks that are sent to different interleaver
and mapping devices. The sequence of the bits sent to an interleaver is called a spatial stream.
e) Interleaver interleaves the bits of each spatial stream (changes order of bits) to prevent long
sequences of adjacent noisy bits from entering the BCC decoder. Interleaving is applied only when
BCC encoding is used.
f) Constellation mapper maps the sequence of bits in each spatial stream to constellation points
(complex numbers).
g) STBC encoder spreads constellation points from N SS spatial streams into N STS space-time streams
using a space-time block code. STBC is used only when N SS N STS ; see 19.3.11.9.2.
2348
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
h) Spatial mapper maps space-time streams to transmit chains. This may include one of the following:
1) Direct mapping: Constellation points from each space-time stream are mapped directly onto
the transmit chains (one-to-one mapping).
2) Spatial expansion: Vectors of constellation points from all of the space-time streams are
expanded via matrix multiplication to produce the input to all of the transmit chains.
3) Beamforming: Similar to spatial expansion, each vector of constellation points from all of the
space-time streams is multiplied by a matrix of steering vectors to produce the input to the
transmit chains.
i) Inverse discrete Fourier transform (IDFT) converts a block of constellation points to a time domain
block.
j) Cyclic shift (CSD) insertion is where the insertion of the cyclic shifts prevents unintentional
beamforming. CSD insertion may occur before or after the IDFT. There are three cyclic shift types
as follows:
1) A cyclic shift specified per transmitter chain with the values defined in Table 19-9 (a possible
implementation is shown in Figure 19-2).
2) A cyclic shift specified per space-time stream with the values defined in Table 19-10 (a
possible implementation is shown in Figure 19-3).
3) A cyclic shift M CSD k that may be applied as a part of the spatial mapper; see 19.3.11.11.2.
k) GI insertion prepends to the symbol a circular extension of itself.
l) Windowing optionally smooths the edges of each symbol to increase spectral decay.
Figure 19-2 and Figure 19-3 show example transmitter block diagrams. In particular, Figure 19-2 shows the
transmitter blocks used to generate the HT-SIG of the HT-mixed format PPDU. These transmitter blocks are
also used to generate the non-HT portion of the HT-mixed format PPDU, except that the BCC encoder and
interleaver are not used when generating the L-STF and L-LTFs. Figure 19-3 shows the transmitter blocks
used to generate the Data field of the HT-mixed format and HT-greenfield format PPDUs. A subset of these
transmitter blocks consisting of the constellation mapper and CSD blocks, as well as the blocks to the right
of, and including, the spatial mapping block, are also used to generate the HT-STF, HT-GF-STF, and
HT-LTFs. The HT-greenfield format SIGNAL field is generated using the transmitter blocks shown in
Figure 19-2, augmented by additional CSD and spatial mapping blocks.
19.3.4 Overview of the PPDU encoding process
The encoding process is composed of the steps described below. The following overview is intended to
facilitate an understanding of the details of the convergence procedure:
a) Determine the number of transmit chains, N TX , from the N_TX field of the TXVECTOR. Produce
the PHY preamble training fields for each of the N TX transmit chains based on the FORMAT,
NUM_EXTEN_SS, CH_BANDWIDTH, and MCS parameters of the TXVECTOR. The format and
relative placement of the PHY preamble training fields vary depending on the frame format being
used, as indicated by these parameters. Apply cyclic shifts. Determine spatial mapping to be used for
HT-STF and HT-LTFs in HT-mixed format frame and HT-GF-STF and HT-LTFs in HT-greenfield
format frame from the EXPANSION_MAT parameter of the TXVECTOR. Refer to 19.3.9 for
details.
b) Construct the PHY preamble SIGNAL fields from the appropriate fields of the TXVECTOR by
adding tail bits, applying convolutional coding, formatting into one or more OFDM symbols,
applying cyclic shifts, applying spatial processing, calculating an inverse Fourier transform for each
OFDM symbol and transmit chain, and prepending a cyclic prefix or GI to each OFDM symbol in
each transmit chain. The number and placement of the PHY preamble SIGNAL fields depend on the
frame format being used. Refer to 19.3.9.3.5, 19.3.9.4.3, and 19.3.9.5.4.
2349
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Insert
Analog
GI and
and RF
Window
Insert
Analog
BCC Encoder
Constellation
CSD GI and
and RF
Interleaver
Window
Mapper
IDFT
Insert
Analog
CSD GI and
and RF
Window
Insert
Analog
CSD GI and
and RF
Window
Single Spatial Stream NTX Transmit Chains
Figure 19-2—Transmitter block diagram 1
Insert
Constellation GI Analog
Interleaver IDFT
mapper and and RF
Window
FEC encoder
Insert
Constellation Analog
Interleaver CSD IDFT GI and
mapper and RF
Window
Stream Parser
Spatial Mapping
Encoder Parser
Scrambler
STBC
Insert
Constellation Analog
Interleaver CSD IDFT GI and
mapper and RF
Window
FEC encoder
Insert
Constellation Analog
Interleaver CSD IDFT GI and
mapper and RF
Window
NSS Spatial Streams NSTS Space‐time NTX Transmit Chains
NOTES Streams
—There might be 1 or 2 FEC encoders when BCC encoding is used.
—The stream parser might have 1, 2, 3 or 4 outputs.
—When LDPC encoding is used, the interleavers are not used
—When STBC is used, the STBC block has more outputs than inputs.
—When spatial mapping is used, there might be more transmit chains than space-time streams.
—The number of inputs to the spatial mapper might be 1, 2, 3, or 4.
Figure 19-3—Transmitter block diagram 2
2350
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) Concatenate the PHY preamble training and SIGNAL fields for each transmit chain one field after
another, in the appropriate order, as described in 19.3.2 and 19.3.7.
d) Use the MCS and CH_BANDWIDTH parameters of the TXVECTOR to determine the number of
data bits per OFDM symbol ( N DBPS ), the coding rate ( R ), the number of coded bits in each OFDM
subcarrier ( N BPSC ), and the number of coded bits per OFDM symbol ( N CBPS ). Determine the
number of encoding streams ( N ES ) from the MCS, CH_BANDWIDTH, and FEC_CODING
parameters of the TXVECTOR. Refer to 19.3.11.4 for details.
e) Append the PSDU to the SERVICE field (see 19.3.11.2). If BCC encoding is to be used, as indicated
by the FEC_CODING parameter of the TXVECTOR, tail bits are appended to the PSDU. If a single
BCC encoder is used (i.e., when the value of N ES is 1), the bit string is extended by 6 zero bits. If
two BCC encoders are used (i.e., when the value of N ES is 2), the bit string is extended by 12 zero
bits. The number of symbols, N SYM , is calculated according to Equation (19-32), and if necessary,
the bit string is further extended with zero bits so that the resulting length is a multiple of
N SYM N DBPS , as described in 19.3.11. If LDPC encoding is to be used, as indicated by the
FEC_CODING parameter of the TXVECTOR, the resulting bit string is padded, if needed, by
repeating coded bits rather than using zero bits, as given in the encoding procedure of 19.3.11.7.5.
The number of resulting symbols is given by Equation (19-41), and the number of repeated coded
bits used for padding is given by Equation (19-42). The resulting bit string constitutes the DATA
part of the packet.
f) Initiate the scrambler with a pseudorandom nonzero seed, generate a scrambling sequence, and
exclusive-OR (XOR) it with the string of data bits, as described in 17.3.5.5.
g) If BCC encoding is to be used, replace the scrambled zero bits that served as tail bits (6 bits if the
value of N ES is 1, or 12 bits if the value of N ES is 2) following the data with the same number of
nonscrambled zero bits, as described in 17.3.5.3. (These bits return the convolutional encoder to the
zero state.)
h) If BCC encoding is to be used and the value of N ES is 2, divide the scrambled data bits between two
BCC encoders by sending alternating bits to the two different encoders, as described in 19.3.11.5.
i) If BCC encoding is to be used, encode the extended, scrambled data string with a rate 1/2
convolutional encoder (see 17.3.5.6). Omit (puncture) some of the encoder output string (chosen
according to puncturing pattern) to reach the coding rate, R, corresponding to the TXVECTOR
parameters MCS or L_DATARATE. Refer to 19.3.11.6 for details. If LDPC encoding is to be used,
encode the scrambled data stream according to 19.3.11.7.5.
j) Parse the coded bit stream that results from the BCC encoding or LDPC encoding into N SS spatial
streams, where the value of N SS is determined from the MCS parameter of the TXVECTOR. See
19.3.11.8.2 for details.
k) Divide each of the N SS encoded and parsed spatial streams of bits into groups of N CBPSS i bits. If
BCC encoding is to be used, within each spatial stream and group, perform an interleaving
(reordering) of the bits according to a rule corresponding to N BPSCS i , where i is the index of the
spatial stream. Refer to 19.3.6 for details.
l) For each of the N SS encoded, parsed, and interleaved spatial streams, divide the resulting coded and
interleaved data string into groups of N BPSCS i bits, where i is the index of the spatial stream. For
each of the bit groups, convert the bit group into a complex number according to the modulation
encoding tables. Refer to 17.3.5.8 for details.
2351
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
m) Divide the complex number string for each of the resulting N SS spatial streams into groups of N SD
complex numbers, where the value of N SD is determined from the CH_OFFSET parameter of
TXVECTOR and the CH_BANDWIDTH parameter of TXVECTOR. Each such group is associated
with one OFDM symbol in one spatial stream. In each group, the complex numbers are indexed 0 to
N SD – 1 , and these indices have an associated one-to-one correspondence with subcarrier indices
r
via the mapping function M k as described in 19.3.11.11, 19.3.11.11.3, 19.3.11.11.4,
19.3.11.11.5, and 19.3.11.12.
n) If STBC is to be applied, as indicated by the STBC parameter in the TXVECTOR, operate on the
complex number associated with each data subcarrier in sequential pairs of OFDM symbols as
described in 19.3.11.9.2 to generate N STS OFDM symbols for every N SS OFDM symbols
associated with the N SS spatial streams. If STBC is not to be used, the number of space-time
streams is the same as the number of spatial streams, and the sequences of OFDM symbols in each
space-time stream are composed of the sequences of OFDM symbols in the corresponding spatial
stream. In each group of N SD resulting complex numbers in each space-time stream, the complex
numbers indexed 0 to N SD – 1 are mapped onto OFDM subcarriers via the mapping function
r
M k as described in 19.3.11.11, 19.3.11.11.3, 19.3.11.11.4, 19.3.11.11.5, and 19.3.11.12.
o) Determine whether 20 MHz or 40 MHz operation is to be used from the CH_BANDWIDTH
parameter of the TXVECTOR. Specifically, when CH_BANDWIDTH is HT_CBW20 or
NON_HT_CBW20, 20 MHz operation is to be used. When CH_BANDWIDTH is HT_CBW40 or
NON_HT_CBW40, 40 MHz operation is to be used. For 20 MHz operation (with the exception of
non-HT formats), insert four subcarriers as pilots into positions –21, –7, 7, and 21. The total number
of the subcarriers, N ST , is 56. For 40 MHz operation (with the exception of MCS 32 and non-HT
duplicate format), insert six subcarriers as pilots into positions –53, –25, –11, 11, 25, and 53,
resulting in a total of N ST = 114 subcarriers. See 19.3.11.11.5 for pilot locations when using
MCS 32 and 19.3.11.12 for pilot locations when using non-HT duplicate format. The pilots are
modulated using a pseudorandom cover sequence. Refer to 19.3.11.10 for details. For 40 MHz
operation, apply a +90° phase shift to the complex value in each OFDM subcarrier with an index
greater than 0, as described in 19.3.11.11.4, 19.3.11.11.5, and 19.3.11.12.
p) Map each of the complex numbers in each of the N ST subcarriers in each of the OFDM symbols in
each of the N STS space-time streams to the N TX transmit chain inputs. For direct-mapped operation,
N TX = N STS , and there is a one-to-one correspondence between space-time streams and transmit
chains. In this case, the OFDM symbols associated with each space-time stream are also associated
with the corresponding transmit chain. Otherwise, a spatial mapping matrix associated with each
OFDM subcarrier, as indicated by the EXPANSION_MAT parameter of the TXVECTOR, is used
to perform a linear transformation on the vector of N STS complex numbers associated with each
subcarrier in each OFDM symbol. This spatial mapping matrix maps the vector of N STS complex
numbers in each subcarrier into a vector of N TX complex numbers in each subcarrier. The sequence
of N ST complex numbers associated with each transmit chain (where each of the N ST complex
numbers is taken from the same position in the N TX vector of complex numbers across the N ST
subcarriers associated with an OFDM symbol) constitutes an OFDM symbol associated with the
corresponding transmit chain. For details, see 19.3.11.11. Spatial mapping matrices may include
cyclic shifts, as described in 19.3.11.11.2.
q) If the CH_BANDWIDTH and CH_OFFSET parameters of the TXVECTOR indicate that upper
or lower 20 MHz are to be used in 40 MHz, move the complex numbers associated with subcarriers
–28 to 28 in each transmit chain to carriers 4 to 60 in the upper channel or –60 to –4 in the lower
2352
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
channel. Note that this shifts the signal in frequency from the center of the 40 MHz channel to +10
MHz or –10 MHz offset from the center of the 40 MHz channel. The complex numbers in the other
subcarriers are set to 0.
r) For each group of N ST subcarriers and each of the N TX transmit chains, convert the subcarriers to
time domain using IDFT. Prepend to the Fourier-transformed waveform a circular extension of
itself, thus forming a GI, and truncate the resulting periodic waveform to a single OFDM symbol
length by applying time domain windowing. Determine the length of the GI according to the
GI_TYPE parameter of the TXVECTOR. Refer to 19.3.11.11 and 19.3.11.12 for details. When
beamforming is not used, it is sometimes possible to implement the cyclic shifts in the time domain.
s) Append the OFDM symbols associated with each transmit chain one after another, starting after the
final field of the PHY preamble. Refer to 19.3.2 and 19.3.7 for details.
t) Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF
signal according to the center frequency of the desired channel and transmit. Refer to 19.3.7 for
details. The transmit chains are connected to antenna elements according to ANTENNA_SET of the
TXVECTOR if ASEL is applied.
19.3.5 Modulation and coding scheme (MCS)
The MCS is a value that determines the modulation, coding, and number of spatial channels. It is a compact
representation that is carried in the HT-SIG. Rate-dependent parameters for the full set of MCSs are shown
in Table 19-27 through Table 19-41 (in 19.5). These tables give rate-dependent parameters for MCSs with
indices 0 to 76. MCSs with indices 0 to 7 and 32 have a single spatial stream; MCSs with indices 8 to 31
have multiple spatial streams using equal modulation (EQM) on all of the streams; MCSs with indices 33 to
76 have multiple spatial streams using unequal modulation (UEQM) on the spatial streams. MCS indices 77
to 127 are reserved.
Table 19-27 through Table 19-30 show rate-dependent parameters for EQM MCSs for one, two, three, and
four streams for 20 MHz operation. Table 19-31 through Table 19-34 show rate-dependent parameters for
EQM MCSs in one, two, three, and four streams for 40 MHz operation. The same EQM MCSs are used for
20 MHz and 40 MHz operation. Table 19-35 shows rate-dependent parameters for the 40 MHz, 6 Mb/s
MCS 32 format.
The remaining tables, Table 19-36 to Table 19-41, show rate-dependent parameters for the MCSs with
UEQM of the spatial streams for use with NSS > 1.
UEQM MCSs are detailed in the following tables:
— Table 19-36 through Table 19-38 are for 20 MHz operation.
— Table 19-39 through Table 19-41 are for 40 MHz operation.
An HT STA shall support all equal modulation (EQM) rates for one spatial stream (MCSs 0 to 7) using a 20
MHz channel width. An HT AP that is not a VHT AP shall support all EQM rates for two spatial streams
(MCSs 8 to 15) using a 20 MHz channel width. All other MCSs and modes are optional, specifically
including transmit and receive support of 400 ns GI, operation in 40 MHz, and support of MCSs with indices
16 to 76.
2353
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.6 Timing-related parameters
Table 19-6 defines the timing-related parameters.
Table 19-6—Timing-related constants
TXVECTOR CH_BANDWIDTH
HT_CBW40 or
Parameter NON_HT_CBW40
NON_HT_CBW20 HT_CBW_20
HT MCS 32 and
format non-HT duplicate
NSD: Number of complex 48 52 108 48
data numbers
NSP: Number of pilot 4 4 6 4
values
NST: Total number of 52 56 114 104
subcarriers
See NOTE 1
NSR: Highest data 26 28 58 58
subcarrier index
F : Subcarrier frequency 312.5 kHz 312.5 kHz 312.5 kHz
spacing (20 MHz/64) (40 MHz/128)
TDFT: IDFT/DFT period 3.2 µs 3.2 µs 3.2 µs
TGI: Guard interval 0.8 µs= TDFT/4 0.8 µs 0.8 µs
duration
TGI2: Double guard 1.6 µs 1.6 µs 1.6 µs
interval
TGIS: Short guard interval N/A 0.4 µs = TDFT/8 0.4 µs
duration See NOTE 2
TL-STF: Non-HT short 8 µs=10× TDFT/4 8 µs 8 µs
training sequence duration
THT-GF-STF: HT-greenfield N/A 8 µs=10× TDFT/4 8 µs
short training field duration See NOTE 2
TL-LTF: Non-HT long 8 µs=2× TDFT+TGI2 8 µs 8 µs
training field duration
TSYM: Symbol interval 4 µs= TDFT+TGI 4 µs 4 µs
TSYMS: Short GI symbol N/A 3.6 µs = TDFT+TGIS 3.6 µs
interval See NOTE 2
TL-SIG: Non-HT SIGNAL 4 µs= TSYM 4 µs 4 µs
field duration
THT-SIG: HT SIGNAL field N/A 8 µs= 2TSYM 8 µs
duration See NOTE 2
THT-STF: HT short training N/A 4 µs 4 µs
field duration See NOTE 2
2354
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-6—Timing-related constants (continued)
TXVECTOR CH_BANDWIDTH
HT_CBW40 or
Parameter NON_HT_CBW40
NON_HT_CBW20 HT_CBW_20
HT MCS 32 and
format non-HT duplicate
THT-LTF1: First HT long N/A 4 µs in HT-mixed 4 µs in HT-mixed format, 8 µs in
training field duration format, 8 µs in HT- HT-greenfield format
greenfield format See NOTE 2
THT-LTFs: Second, and N/A 4 µs 4 µs
subsequent, HT long See NOTE 2
training fields duration
NOTE 1—NST = NSD + NSP except in the cases of MCS 32 and non-HT duplicate, where the number of data
subcarriers differs from the number of complex data numbers, and the number of pilot subcarriers differs from
the number of pilot values. In those cases, data numbers and pilot values are replicated in upper and lower 20 MHz
portions of 40 MHz signal to make a total of 104 subcarriers.
NOTE 2—Not applicable in non-HT formats.
NOTE 3—N/A = Not applicable.
Table 19-7 defines parameters used frequently in Clause 19.
Table 19-7—Frequently used parameters
Symbol Explanation
N CBPS Number of coded bits per symbol
N CBPSS i Number of coded bits per symbol per the i-th spatial stream
N DBPS Number of data bits per symbol
N BPSC Number of coded bits per single carrier
N BPSCS i Number of coded bits per single carrier for spatial stream i
N RX Number of receive chains
N STS Number of space-time streams
N SS Number of spatial streams
N ESS Number of extension spatial streams
N TX Number of transmit chains
N ES Number of BCC encoders for the Data field
N HT-LTF Number of HT Long Training fields (see 19.3.9.4.6)
N HT-DLTF Number of Data HT Long Training fields
N HT-ELTF Number of Extension HT Long Training fields
R Coding rate
2355
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.7 Mathematical description of signals
For the description of the convention on mathematical description of signals, see 17.3.2.5.
In the case of either a 20 MHz non-HT format (TXVECTOR parameter FORMAT equal to NON_HT,
MODULATION parameter equal to one of {ERP-OFDM, OFDM}) transmission or a 20 MHz HT format
(TXVECTOR parameter FORMAT equal to HT_MF or HT_GF, CH_BANDWIDTH equal to
HT_CBW_20) transmission, the channel is divided into 64 subcarriers. In the 20 MHz non-HT format, the
signal is transmitted on subcarriers –26 to –1 and 1 to 26, with 0 being the center (dc) carrier. In the 20 MHz
HT format, the signal is transmitted on subcarriers –28 to –1 and 1 to 28.
In the case of the 40 MHz HT format, a 40 MHz channel is used. The channel is divided into
128 subcarriers. The signal is transmitted on subcarriers –58 to –2 and 2 to 58.
In the case of 40 MHz HT upper format or 40 MHz HT lower format, the upper or lower 20 MHz is divided
into 64 subcarriers. The signal is transmitted on subcarriers –60 to –4 in the case of a 40 MHz HT lower
format transmission and on subcarriers 4 to 60 in the case of a 40 MHz HT upper format transmission.
In the case of the MCS 32 and non-HT duplicate formats, the same data are transmitted over two adjacent
20 MHz channels. In this case, the 40 MHz channel is divided into 128 subcarriers, and the data are
transmitted on subcarriers –58 to –6 and 6 to 58.
The transmitted signal is described in complex baseband signal notation. The actual transmitted signal is
related to the complex baseband signal by the relation shown in Equation (19-1).
r RF t = Re r t exp j2 f c t (19-1)
where
fc is the center frequency of the carrier
The transmitted RF signal is derived by modulating the complex baseband signal, which consists of several
fields. The timing boundaries for the various fields are shown in Figure 19-4.
HT- HT- HT- HT-
HT-mixed Format L-STF L-LTF L-SIG HT-SIG STF LTF1 LTF2
... LTFn
Data Data
tL-LTF tL-SIG tHT-SIG tHT-STF tHT-LTF tHT-Data
HT-greenfield HT- HT-
Format
HT-GF-STF HT-LTF1 HT-SIG LTF2 ... LTFn
Data Data
tHT-LTF1 tHT-SiG tHT-LTFs tHT-Data
Figure 19-4—Timing boundaries for PPDU fields
The time offset, t Field , determines the starting time of the corresponding field.
In HT-mixed format, the signal transmitted on transmit chain i TX shall be as shown in Equation (19-2).
2356
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
iTX TX i
TX i
r PPDU t = r L-STF t + r L-LTF t – t L-LTF (19-2)
i TX i TX i TX
+ r L-SIG t – t L-SIG + r HT-SIG t – t HT-SIG + r HT-STF t – t HT-STF
N HTLTF
i i
TX LTF TX i
+ r HT-LTF t – t HT-LTF – i LTF – 1 T HT-LTFs + r HT-DATA t – t HT-DATA
i LTF = 1
where
t L-LTF = T L-STF
t L-SIG = t L-LTF + T L-LTF
t HT-SIG = t L-SIG + T L-SIG
t HT-STF = t HT-SIG + T HT-SIG
t HT-LTF = t HT-STF + T HT-STF
t HT-Data = t HT-LTF + N HT - LTF T HT-LTFs
In the case of HT-greenfield format, the transmitted signal on transmit chain iTX shall be as shown in
Equation (19-3).
iTX i i
r PPDU t = r HTTX– GF – STF t + r HTTX– LTF 1 t – t HT – LTF 1
i
+ r HTTX– SIG t – t HT – SIG
(19-3)
N HTLTF
i i
+ r HTTX– LTF
LTF
t – t HT – LTFs – i LTF – 2 T HT – LTFs
i LTF = 2
i
+ r HTTX– DATA t – t HT – DATA
where
t HT – LTF 1 = T HT – GF – STF
t HT-SIG = t HT-LTF1 + T HT-LTF1
t HT-LTFs = t HT-SIG + T HT-SIG
t HT-Data = t HT-LTFs + N HT - LTF – 1 T HT-LTFs
TX i
Each baseband waveform, r Field t , is defined via the discrete Fourier transform (DFT) per OFDM symbol
as shown in Equation (19-4).
i TX 1 i TX
r Field t = ------------------------------- w TField t k Xk exp j2 k Ft (19-4)
Tone
N Field N TX k
2357
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This general representation holds for all fields. A suggested definition of the windowing function, w TField t ,
i
is given in 17.3.2.5. The frequency domain symbols X k TX represent the output of any spatial processing in
subcarrier k for transmit chain i TX required for the field.
The function k is used to represent a rotation of the upper tones in a 40 MHz channel as shown in
Equation (19-5) and Equation (19-6).
= 1 k 0 in a 40 MHz channel (19-5)
k
j k 0 in a 40 MHz channel
k = 1 in a 20 MHz channel (19-6)
Tone
The 1 N Field N TX scale factor in Equation (19-4) causes the total power of the time domain signal as
summed over all transmit chains to be either 1 or lower than 1 when required. Table 19-8 summarizes the
Tone
various values of N Field .
Tone
Table 19-8—Value of tone scaling factor N Field
Tone
N Field , see NOTE 1
Field
20 MHz 40 MHz
L-STF 12 24
HT-GF-STF 12 24
L-LTF 52 104
L-SIG 52 104
HT-SIG 52/56, see NOTE 2 104/114, see NOTE 2
HT-STF 12 24
HT-LTF 56 114
HT-DATA 56 114
MCS 32 — 104
Non-HT Duplicate — 104
Tone
NOTE 1—The numbers in the table refer only to the value of N Field as it appears in Equation (19-4) and in
subsequent specification of various fields. This value might be different from the actual number of tones being
transmitted.
NOTE 2—The values 56 and 114 are for HT-greenfield format; the values 52 and 104 are for HT-mixed format.
19.3.8 Transmission in the upper/lower 20 MHz of a 40 MHz channel
When transmitting in the upper/lower 20 MHz portion of a 40 MHz channel, the mathematical definition of
transmission shall follow that of a 20 MHz channel with f c in Equation (19-1) replaced by f c 10 MHz .
2358
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This rule applies to 20 MHz HT transmission in the upper/lower 20 MHz of a 40 MHz channel
(TXVECTOR primitive CH_BANDWIDTH equal to HT_CBW20 and CH_OFFSET primitive equal to
CH_OFF_20U or CH_OFF_20L) and to 20 MHz non-HT transmission in the upper/lower 20 MHz of a
40 MHz channel (TXVECTOR primitive CH_BANDWIDTH equal to NON_HT_CBW20 and
CH_OFFSET primitive equal to CH_OFF_20U or CH_OFF_20L).
19.3.9 HT preamble
19.3.9.1 Introduction
The HT preambles are defined in HT-mixed format and in HT-greenfield format to carry the required
information to operate in a system with multiple transmit and multiple receive antennas.
In the HT-mixed format, to provide compatibility with non-HT STAs, specific non-HT fields are defined so
that they can be received by non-HT STAs compliant with Clause 17 or Clause 18 followed by the fields
specific to HT STAs.
In the HT-greenfield format, all of the non-HT fields are omitted. The specific HT fields used are as follows:
— One HT-GF-STF for automatic gain control convergence, timing acquisition, and coarse frequency
acquisition,
— One or several HT-LTFs, provided as a way for the receiver to estimate the channel between each
spatial mapper input and receive chain. The first HT-LTFs (HT-DLTFs) are necessary for
demodulation of the HT-Data portion of the PPDU and are followed, for sounding packets only, by
optional HT-LTFs (HT-ELTFs) to sound extra spatial dimensions of the MIMO channel,
— HT-SIG, which provides all the information required to interpret the HT packet format.
In the case of multiple transmit chains, the HT preambles use cyclic shift techniques to prevent unintentional
beamforming.
19.3.9.2 HT-mixed format preamble
In HT-mixed format frames, the preamble has fields that support compatibility with Clause 17 and Clause 18
STAs and fields that support HT operation. The non-HT portion of the HT-mixed format preamble enables
detection of the PPDU and acquisition of carrier frequency and timing by both HT STAs and STAs that are
compliant with Clause 17 or Clause 18. The non-HT portion of the HT-mixed format preamble contains the
SIGNAL field (L-SIG) defined in Clause 17 and is thus decodable by STAs compliant with Clause 17 and
Clause 18 as well as HT STAs.
The HT portion of the HT-mixed format preamble enables estimation of the MIMO channel to support
demodulation of the data portion of the frame by HT STAs. The HT portion of the HT-mixed format
preamble also contains the HT-SIG field that supports HT operation.
19.3.9.3 Non-HT portion of the HT-mixed format preamble
19.3.9.3.1 Introduction
The transmission of the non-HT training fields and the L-SIG as part of an HT-mixed format packet is
described in 19.3.9.3.2 through 19.3.9.3.5.
19.3.9.3.2 Cyclic shift definition
The cyclic shift values defined in this subclause apply to the non-HT fields in the HT-mixed format
preamble and the HT-SIG in the HT-mixed format preamble.
2359
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Cyclic shifts are used to prevent unintentional beamforming when the same signal or scalar multiples of one
signal are transmitted through different spatial streams or transmit chains. A cyclic shift of duration TCS on a
signal s t on interval 0 t T is defined as follows, where T is defined as T DFT as referenced in
Table 19-6.
With T CS 0 , replace s t with s t – T CS when 0 t T + T CS and with s t – T CS – T when
T + T CS t T . The cyclic-shifted signal is defined as shown in Equation (19-7).
s t – T CS 0 t T + T CS
s CS t ;T CS = (19-7)
T CS 0 s t – T CS – T T + T CS t T
The cyclic shift is applied to each OFDM symbol in the packet separately. Table 19-9 specifies the values for
the cyclic shifts that are applied in the L-STF (in an HT-mixed format packet), the L-LTF, and L-SIG. It also
applies to the HT-SIG in an HT-mixed format packet.
Table 19-9—Cyclic shift for non-HT portion of packet
i
T CSTX values for non-HT portion of packet
Cyclic shift for Cyclic shift for Cyclic shift for Cyclic shift for
Number of
transmit chain 1 transmit chain 2 transmit chain 3 transmit chain 4
transmit chains
(ns) (ns) (ns) (ns)
1 0 — — —
2 0 –200 — —
3 0 –100 –200 —
4 0 –50 –100 –150
With more than four transmit chains, each cyclic shift on the additional transmit chains shall be between
–200 ns and 0 ns inclusive.
19.3.9.3.3 L-STF definition
The L-STF is identical to the Clause 17 short training symbol. The non-HT short training OFDM symbol in
the 20 MHz channel width is shown in Equation (19-8).
S – 26,26 = 1 2
0 0 1 + j 0 0 0 – 1 – j 0 0 0 1 + j 0 0 0 –1 – j 0 0 0 – 1 – j 0 0 0 1 + j 0 0 0 (19-8)
0 0 0 0 –1–j 0 0 0 –1–j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0
The normalization factor 1 2 is the QPSK normalization.
The non-HT short training OFDM symbol in a 40 MHz channel width is given by Equation (19-9), after
rotating the tones in the upper subchannel (subcarriers 6–58) by +90° (see Equation (19-10)).
2360
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
S –58,58 = 1 2
0 0 1+j 0 0 0 – 1 – j 0 0 0 1 + j 0 0 0 –1 – j 0 0 0 – 1 – j 0 0 0 1 + j 0 0 0
0 0 0 0 –1–j 0 0 0 –1–j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 0 0 (19-9)
0 0 0 0 0 0 0 0 0 0 1+j 0 0 0 –1–j 0 0 0 1+j 0 0 0 –1–j 0 0 0 –1–j 0 0 0 1+j
0 0 0 0 0 0 0 –1–j 0 0 0 –1–j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0
In HT-mixed format, the L-STF on transmit chain i TX shall be as shown in Equation (19-10).
N SR
i TX 1 i TX
r L – STF t = ------------------------------------ w TL – STF t k S k exp j2 k F t – T CS (19-10)
Tone
N TX N L – STF k = – N SR
where
i
TX
T CS represents the cyclic shift for transmit chain i TX and takes values from Table 19-9
k is defined in Equation (19-5) and Equation (19-6)
The L-STF has a period of 0.8 µs. The entire STF includes ten such periods, with a total duration of T L-STF
= 8 µs.
19.3.9.3.4 L-LTF definition
The non-HT long training OFDM symbol is identical to the Clause 17 long training OFDM symbol. In the
20 MHz channel width, the long training OFDM symbol is given by Equation (19-11).
L –26,26 = 1 1 –1 –1 1 1 –1 1 –1 1 1 1 1 1 1 –1 –1 1 1 –1 1 –1 1 1 1 1 0 (19-11)
1 –1 –1 1 1 –1 1 –1 1 –1 –1 –1 –1 – 1 1 1 – 1 –1 1 – 1 1 – 1 1 1 1 1
The non-HT long training OFDM symbol in a 40 MHz channel width is given by Equation (19-12), after
rotating the tones in the upper subchannel (subcarriers 6–58) by +90° (see Equation (19-13)).
L – 58,58 = 1 1 –1 –1 1 1 –1 1 –1 1 1 1 1 1 1 –1 –1 1 1 –1 1 –1 1 1 1 1 0 (19-12)
1 –1 –1 1 1 –1 1 –1 1 –1 –1 –1 –1 –1 1 1 – 1 – 1 1 – 1 1 – 1 1 1 1 1 0 0 0 0 0
0 0 0 0 0 0 1 1 –1 –1 1 1 –1 1 –1 1 1 1 1 1 1 –1 –1 1 1 –1 1 –1 1 1 1 1 0
1 –1 –1 1 1 – 1 1 – 1 1 – 1 –1 –1 –1 –1 1 1 –1 –1 1 –1 1 –1 1 1 1 1
The subcarriers at ± 32 in 40 MHz, which are the dc subcarriers for the non-HT 20 MHz transmission, are
both nulled in the L-LTF. Such an arrangement allows proper synchronization of a 20 MHz non-HT STA.
The L-LTF waveform shall be as shown in Equation (19-13).
N SR
i 1 i
r L TX
– LTF t = ------------------------------------ w TL – LTF t k L k exp j2 k F
TX
t – T GI 2 – T CS (19-13)
Tone
N TX N L – LTF k = – N SR
where
T GI 2 is 1.6 s
i
TX
T CS represents the cyclic shift for transmit chain i TX and takes values specified in Table 19-9
2361
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
k is defined in Equation (19-5) and Equation (19-6)
The entire LTF includes two 3.2 µs IDFT/DFT periods and an additional 1.6 µs double GI. The entire LTF is
modulated with the L-LTF waveform.
19.3.9.3.5 L-SIG definition
The L-SIG is used to communicate rate and length information.The structure of the L-SIG is shown in
Figure 19-5.
Rate Length Tail
(4 bits) (12 bits) (6 bits)
R P
R1 R2 R3 R4 “0” “0” “0” “0” “0” “0”
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Figure 19-5—L-SIG structure
The value in the Rate field is obtained from the L_DATARATE field of the TXVECTOR. The value in the
Length field is obtained from the L_LENGTH field of the TXVECTOR. The Length field is transmitted
LSB first.
The reserved bit shall be set to 0.
The parity field has the even parity of bits 0–16.
The L-SIG shall be encoded, interleaved and mapped, and it shall have pilots inserted following the steps
described in 17.3.5.6, 17.3.5.7, and 17.3.5.9. The stream of 48 complex numbers generated by the steps
described in 17.3.5.7 is denoted by d k k = 0 47 . The time domain waveform of the L-SIG in 20 MHz
transmission shall be as given by Equation (19-14).
26
i 1 i
r L TX t = ------------------------------------ w TSYM t
TX
– SIG D k + p 0 P k exp j2 k F t – T GI – T CS (19-14)
Tone
N TX N L – SIG k = – 26
In a 40 MHz transmission the time domain waveform of the L-SIG shall be as given by Equation (19-15).
26
i 1
r L TX
– SIG t = ------------------------------------ w TSYM t Dk + p0 Pk
Tone
N TX N L – SIG k = – 26 (19-15)
TX i i
TX
exp j2 k – 32 F t – T GI – T CS + j exp j2 k + 32 F t – T GI – T CS
where
0 k = 0 7 21
Dk =
d Mr k otherwise
2362
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
k + 26 – 26 k – 22
k + 25 – 20 k – 8
r
M k = k + 24 –6 k –1
k + 23 1 k 6
k + 22 8 k 20
k + 21 22 k 26
Pk is defined in 17.3.5.10
p0 is the first pilot value in the sequence defined in 17.3.5.10
Tone
N L – SIG has the value given in Table 19-8
i TX
T CS represents the cyclic shift for transmit chain i TX and is defined by Table 19-9 for HT-mixed
format PPDUs
NOTE— D k exists for – N SR k N SR and takes the values from dk that exists for 0 k N SD – 1 . M r k is a “reverse”
function of the function M k defined in 17.3.5.10.
19.3.9.4 HT portion of HT-mixed format preamble
19.3.9.4.1 Introduction
When an HT-mixed format preamble is transmitted, the HT preamble consists of the HT-STF, the HT-LTFs,
and the HT-SIG.
19.3.9.4.2 Cyclic shift definition
The cyclic shift values defined in this subclause apply to the HT-STF and HT-LTFs of the HT-mixed format
preamble. The cyclic shift values defined in 19.3.9.3.2 apply to the HT-SIG in an HT-mixed format
preamble.
Throughout the HT portion of an HT-mixed format preamble, cyclic shift is applied to prevent beamforming
when similar signals are transmitted in different space-time streams. The same cyclic shift is applied to these
streams during the transmission of the data portion of the frame. The values of the cyclic shifts to be used
during the HT portion of the HT-mixed format preamble (with the exception of the HT_SIG) and the data
portion of the frame are specified in Table 19-10.
Table 19-10—Cyclic shift values of HT portion of packet
iSTS
T CS values for HT portion of packet
Number of Cyclic shift for Cyclic shift for Cyclic shift for Cyclic shift for
space-time space-time stream 1 space-time stream 2 space-time stream 3 space-time stream 4
streams (ns) (ns) (ns) (ns)
1 0 — — —
2 0 –400 — —
3 0 –400 –200 —
4 0 –400 –200 –600
2363
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.9.4.3 HT-SIG definition
The HT-SIG is used to carry information required to interpret the HT packet formats. The fields of the
HT-SIG are described in Table 19-11.
Table 19-11—HT-SIG fields
Number
Field Explanation and coding
of bits
Modulation and 7 Index into the MCS table.
Coding Scheme See NOTE 1.
CBW 20/40 1 Set to 0 for 20 MHz or 40 MHz upper/lower.
Set to 1 for 40 MHz.
HT Length 16 The number of octets of data in the PSDU in the range 0 to 65 535.
See NOTE 1 and NOTE 2.
Smoothing 1 Set to 1 indicates that channel estimate smoothing is recommended.
Set to 0 indicates that only per-carrier independent (unsmoothed) channel
estimate is recommended.
See 19.3.11.11.2.
Not Sounding 1 Set to 0 indicates that PPDU is a sounding PPDU.
Set to 1 indicates that the PPDU is not a sounding PPDU.
Reserved 1 Set to 1.
Aggregation 1 Set to 1 to indicate that the PPDU in the data portion of the packet contains an A-
MPDU; otherwise, set to 0.
STBC 2 Set to a nonzero number, to indicate the difference between the number of space-
time streams ( N STS ) and the number of spatial streams ( N SS ) indicated by the
MCS.
Set to 00 to indicate no STBC ( N STS = N SS ).
See NOTE 1.
FEC Coding 1 Set to 1 for LDPC.
Set to 0 for BCC.
Short GI 1 Set to 1 to indicate that the short GI is used after the HT training.
Set to 0 otherwise.
Number of 2 Indicates the number of extension spatial streams ( N ESS ).
Extension Spatial Set to 0 for no extension spatial stream.
Streams Set to 1 for 1 extension spatial stream.
Set to 2 for 2 extension spatial streams.
Set to 3 for 3 extension spatial streams.
See NOTE 1.
CRC 8 CRC of bits 0–23 in HT-SIG1 and bits 0–9 in HT-SIG2. See 19.3.9.4.4. The first
bit to be transmitted is bit C7 as explained in 19.3.9.4.4.
Tail Bits 6 Used to terminate the trellis of the convolution coder. Set to 0.
NOTE 1—Integer fields are transmitted in unsigned binary format, LSB first.
NOTE 2—A value of 0 in the HT Length field indicates a PPDU that does not include a data field, i.e., NDP. NDP transmissions are
used for sounding purposes only (see 10.34.2). The packet ends after the last HT-LTF or the HT-SIG.
2364
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The structure of the HT-SIG1 and HT-SIG2 fields is defined in Figure 19-6.
CBW 20/40
Modulation and Coding
HT Length
Scheme
LSB MSB LSB MSB
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
HT-SIG1
Number of Extension Spatial
Not Sounding
FEC Coding
Aggregation
Smoothing
Reserved
CRC Tail Bits
Streams
Short GI
STBC
C7 C0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
HT-SIG2
LSB LSB
Figure 19-6—Format of HT-SIG1 and HT-SIG2
The HT-SIG is composed of two parts, HT-SIG1 and HT-SIG2, each containing 24 bits, as shown in
Figure 19-6. All of the fields in the HT-SIG are transmitted LSB first, and HT-SIG1 is transmitted before
HT-SIG2.
The HT-SIG parts shall be encoded at R = 1/2, interleaved, and mapped to a BPSK constellation, and they
have pilots inserted following the steps described in 17.3.5.6, 17.3.5.7, 17.3.5.8, and 17.3.5.9, respectively.
The BPSK constellation is rotated by 90° relative to the L-SIG in order to accommodate detection of the
start of the HT-SIG. The stream of 96 complex numbers generated by these steps is divided into two groups
of 48 complex numbers: d k n 0 k 47 n = 0 1 . The time domain waveform for the HT-SIG in an HT-
mixed format packet in a 20 MHz transmission shall be as shown in Equation (19-16).
1
i TX 1
r HT – SIG t = --------------------------------------- w TSYM t – nT SYM
Tone
N TX N HT – SIG n=0
(19-16)
26
iTX
jD k n + p n + 1 P k exp j2 k F t – nT SYM – T GI – T CS
k = – 26
2365
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In a 40 MHz transmission the time domain waveform shall be as shown in Equation (19-17).
1
i TX 1
r HT – SIG t = --------------------------------------- w TSYM t – nT SYM
Tone
N TX N HT – SIG n=0
26
i TX (19-17)
jD k n + p n + 1 P k exp j2 k – 32 F t – nT SYM – T GI – T CS
k = – 26
i
TX
+ j exp j2 k + 32 F t – nT SYM – T GI – T CS
where
0 k = 0 7 21
Dk n =
d Mr k n otherwise
r
M k is defined in 19.3.9.3
P k and p n are defined in 17.3.5.10
Tone
N HT – SIG has the value given in Table 19-8
i
TX
T CS represents the cyclic shift for transmit chain i TX and is defined by Table 19-9 for HT-mixed
format PPDUs.
NOTE—This definition results in a quadrature binary phase shift keying (QBPSK) modulation in which the
constellation of the data tones is rotated by 90° relative to the L-SIG in HT-mixed format PPDUs and relative to the first
HT-LTF in HT-greenfield format PPDUs (see Figure 19-7). In HT-mixed format PPDUs, the HT-SIG is transmitted with
the same number of subcarriers and the same cyclic shifts as the preceding non-HT portion of the preamble. This is done
to accommodate the estimation of channel parameters needed to robustly demodulate and decode the information
contained in the HT-SIG.
Q Q
L-SIG HT-SIG
+1 +1 1
0 1 I I
–1 +1 –1 +1
–1 –1 0
Figure 19-7—Data tone constellations in an HT-mixed format PPDU
19.3.9.4.4 CRC calculation for HT-SIG
The CRC protects bits 0–33 of the HT-SIG (bits 0–23 of HT-SIG1 and bits 0–9 of HT-SIG2). The value of
the CRC field shall be the 1s complement of
2366
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8
crc D = M D I D D mod G D (19-18)
where
33 32
M D = m0 D + m1 D + + m 32 D + m 33 is the HT-SIG represented as a polynomial
where
m0 is bit 0 of HT-SIG1
m 33 is bit 9 of HT-SIG2
33
i
I D = D are initialization values that are added modulo 2 to the first 8 bits of HT-SIG1
i = 26
8 2
G D = D + D + D + 1 is the CRC generating polynomial
7 6
crc D = c 0 D + c 1 D + + c6 D + c7
The CRC field is transmitted with c7 first.
Figure 19-8 shows the operation of the CRC. First, the shift register is reset to all 1s. The bits are then passed
through the XOR operation at the input. When the last bit has entered, the output is generated by shifting the
bits out of the shift register, C7 first, through an inverter.
m33
to The feedback term is set to 0
during the shifting out of the result.
m0
0
Serial c c c c c c c c
Input 7 6 5 4 3 2 1 0
Serial Output
Figure 19-8—HT-SIG CRC calculation
As an example, if bits m 0 m 33 are given by {1 1 1 1 0 0 0 1 0 0 1 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0}, the
output bits B 7 B 0 , where B7 is output first, are {1 0 1 0 1 0 0 0}.
19.3.9.4.5 HT-STF definition
The purpose of the HT-STF is to improve automatic gain control estimation in a MIMO system. The
duration of the HT-STF is 4 µs. In a 20 MHz transmission, the frequency sequence used to construct the
HT-STF is identical to L-STF. In a 40 MHz transmission, the HT-STF is constructed from the 20 MHz
version by duplicating and frequency shifting and by rotating the upper subcarriers by 90°. The frequency
sequences are shown in Equation (19-19) and Equation (19-20).
2367
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For 20 MHz:
HTS –28,28 = 1 2 (19-19)
0 0 0 0 1 + j 0 0 0 – 1 – j 0 0 0 1 + j 0 0 0 –1 – j 0 0 0 – 1 – j 0 0 0 1 + j 0 0 0
0 0 0 0 –1–j 0 0 0 –1–j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 0
For 40 MHz:
HTS –58,58 = 1 2 (19-20)
0 0 1+j 0 0 0 – 1 – j 0 0 0 1 + j 0 0 0 –1 – j 0 0 0 – 1 – j 0 0 0 1 + j 0 0 0
0 0 0 0 –1–j 0 0 0 –1–j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1+j 0 0 0 –1–j 0 0 0 1+j 0 0 0 –1–j 0 0 0 –1–j 0 0 0 1+j
0 0 0 0 0 0 0 –1–j 0 0 0 –1–j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0
The time domain representation of the transmission in transmit chain i TX shall be as shown in
Equation (19-21).
i TX 1
r HT – STF t = ----------------------------------------- w T HT – STF t
Tone
N STS N HT – STF
(19-21)
N SR N STS
iSTS
Qk i TX i STS k HTS k exp j2 k F t – T CS
k = – N SR i STS = 1
where
i
STS
T CS represents the cyclic shift for the space-time stream i STS and takes the values given in
Table 19-10
Qk is defined in 19.3.11.11.2
k is defined in Equation (19-5) and Equation (19-6)
19.3.9.4.6 HT-LTF definition
The HT-LTF provides a means for the receiver to estimate the MIMO channel between the set of QAM
mapper outputs (or, if STBC is applied, the STBC encoder outputs) and the receive chains. If the transmitter
is providing training for exactly the space-time streams (spatial mapper inputs) used for the transmission of
the PSDU, the number of training symbols, N LTF , is equal to the number of space-time streams, N STS ,
except that for three space-time streams, four training symbols are required. If the transmitter is providing
training for more space-time streams (spatial mapper inputs) than the number used for the transmission of
the PSDU, the number of training symbols is greater than the number of space-time streams. This latter case
happens in a sounding PPDU.
The HT-LTF portion has one or two parts. The first part consists of one, two, or four HT-LTFs that are
necessary for demodulation of the HT-Data portion of the PPDU. These HT-LTFs are referred to as
HT-DLTFs. The optional second part consists of zero, one, two, or four HT-LTFs that may be used to sound
extra spatial dimensions of the MIMO channel that are not utilized by the HT-Data portion of the PPDU.
These HT-LTFs are referred to as HT-ELTFs. If a receiver has not advertised its ability to receive HT-ELTFs,
it shall either issue a PHY-RXEND.indication(UnsupportedRate) primitive upon reception of a frame that
includes HT-ELTFs or decode that frame. (When an HT packet includes one or more HT-ELTFs, it is
2368
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
optional for a receiver that has not advertised its capability to receive HT-ELTFs to decode the data portion
of the PPDU.)
The number of HT-DLTFs is denoted N HT - DLTF . The number of HT-ELTFs is denoted N HT - ELTF . The total
number of HT-LTFs is shown in Equation (19-22).
N HT - LTF = N HT - DLTF + N HT - ELTF (19-22)
N HT - LTF shall not exceed 5. Table 19-12 shows the determination of the number of space-time streams from
the MCS and STBC fields in the HT-SIG. Table 19-13 shows the number of HT-DLTFs as a function of the
number of space-time streams ( N STS ). Table 19-14 shows the number of HT-ELTFs as a function of the
number of extension spatial streams ( N ESS ). N STS plus N ESS is less than or equal to 4. In the case where
N STS equals 3, N ESS cannot exceed one; if N ESS equals one in this case then N LTF equals 5.
Table 19-12—Determining the number of space-time streams
Number of Spatial Number of
Streams (from MCS) STBC field space-time
N SS streams N STS
1 0 1
1 1 2
2 0 2
2 1 3
2 2 4
3 0 3
3 1 4
4 0 4
Table 19-13—Number of HT-DLTFs required for data space-time streams
N STS N HTDLTF
1 1
2 2
3 4
4 4
2369
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-14—Number of HT-ELTFs required for extension spatial streams
N ESS N HT-ELTF
0 0
1 1
2 2
3 4
The HT-LTF sequence shown in Equation (19-23) is transmitted in the case of 20 MHz operation.
HT-LTF -28,28 = 1 1 1 1 – 1 – 1 1 1 – 1 1 – 1 1 1 1 1 1 1 – 1 – 1 1 1 – 1 1 – 1 1 1 1 1 0
1 – 1 – 1 1 1 – 1 1 – 1 1 – 1 –1 –1 –1 –1 1 1 – 1 – 1 1 – 1 1 – 1 1 1 1 1 – 1 – 1 (19-23)
NOTE—This sequence is an extension of the L-LTF where the four extra subcarriers are filled with +1 for negative
frequencies and –1 for positive frequencies.
In 40 MHz transmissions, including MCS 32 format frames, the sequence to be transmitted is shown in
Equation (19-24).
HT-LTF -58,58 = 1 1 – 1 – 1 1 1 – 1 1 – 1 1 1 1 1 1 1 – 1 – 1 1 1 – 1 1 – 1 1 1 1 1 1
1 – 1 – 1 1 1 – 1 1 – 1 1 – 1 – 1 – 1 – 1 –1 1 1 – 1 – 1 1 – 1 1 – 1 1 1 1 1 –1 –1 –1 1 0
0 0 –1 1 1 –1 1 1 –1 –1 1 1 –1 1 –1 1 1 1 1 1 1 –1 –1 1 1 –1 1 –1 1 1 1 1 1
(19-24)
1 –1 –1 1 1 –1 1 –1 1 –1 –1 –1 –1 –1 1 1 –1 –1 1 –1 1 –1 1 1 1 1
NOTE—This sequence is also constructed by extending the L-LTF in the following way: first, the L-LTF is duplicated
and shifted as explained in 19.3.9.3.4 for the non-HT duplicate format; then the missing subcarriers [–32, –5, –4, –3, –2,
2, 3, 4, 5, 32] are filled with the values [1, –1, –1, –1, 1, –1, 1, 1, –1, 1], respectively.
This sequence, occupying 114 tones, is used even if the data portion is transmitted with MCS 32 format,
which uses 104 tones.
NOTE—This sequence uses 114 tones when MCS 32 format is used to retain consistency with other 40 MHz formats
and to facilitate channel estimation for beamforming and link adaptation.
In an HT-mixed format preamble, each HT-LTF consists of a single occurrence of the sequence plus a GI
insertion and has a duration of 4 µs. In case of multiple space-time streams, cyclic shift is invoked as
specified in Table 19-10.
The generation of HT-DLTFs is shown in Figure 19-9. The generation of HT-ELTFs is shown in
Figure 19-10. In these figures, and in the following text, the following notational conventions are used:
— X m n indicates the element in row m and column n of matrix X
— X N indicates a matrix consisting of the first N columns of matrix X
— X M:N indicates a matrix consisting of columns M to N of matrix X
where
M N
X is either Q k or P HT - LTF
2370
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
[PHT-LTF]1,n
HT-LTFk x
IFFT
CSD Qk N STS
IFFT
x
[PHT-LTF] NSTS , n
Figure 19-9—Generation of HT-DLTFs
[PHT-LTF]1, n-NHT-DLTF
HT-LTFk x
IFFT
Qk
CSD N STS 1:N STS N ESS
IFFT
x
[PHT-LTF] NESS, n-NHT-DLTF
Figure 19-10—Generation of HT-ELTFs
The mapping between space-time streams and transmit chains is defined by the columns of an antenna map
matrix Q k for subcarrier k. The first N STS columns define the space-time streams used for data
transmission, and the next N ESS columns (up to N TX – N STS columns) define the extension spatial streams.
Thus, for the purpose of defining HT-LTFs, Q k is an N TX N STS + N ESS dimension matrix. Columns
1 N STS of Q k are excited by the HT-DLTFs, and columns N STS + 1 N STS + N ESS are excited by the HT-
ELTFs, where N STS + N ESS N TX is the total number of spatial streams being probed by the HT-LTFs.
Possible forms of Q k and other limitations on Q k are specified in 19.3.11.11.2. P HT - LTF is defined in
Equation (19-27).
2371
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The time domain representation of the waveform transmitted on transmit chain i TX during HT-DLTF n,
where 1 n N HT - DLTF , shall be as shown in Equation (19-25).
n i TX 1
r HT – LTF t = ------------------------------------------ w THT – LTFs t (19-25)
Tone
N STS N HT – LTF
N SR N STS
i STS
Qk i TX i STS P HT - LTF i STS n k HT-LTF k exp j2 k F t – T GI – T CS
k = – N SR i STS = 1
For the HT-ELTFs N HT - DLTF n N HT - LTF , it shall be as shown in Equation (19-26).
n i 1
r HTTX– LTF t = ------------------------------------------ w THT – LTFs t (19-26)
Tone
N HT – LTF N ESS
N SR N ESS
Qk i TX N STS + i ESS P HT - LTF i ESS n – N HTDLTF k HT-LTF k
k = – N SR i ESS = 1
ESS i
exp j2 k F t – T GI – T CS
where
i
STS
T CS cyclic shift values are given in Table 19-10
i
ESS
T CS cyclic shift values are given in Table 19-10 with i ESS = i STS
Qk is defined in 19.3.11.11.2
k is defined in Equation (19-5) and Equation (19-6)
P HT - LTF the HT-LTF mapping matrix, is given by Equation (19-27)
1 –1 1 1
P HT - LTF = 1 1 –1 1 (19-27)
1 1 1 –1
–1 1 1 1
2372
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.9.5 HT-greenfield format preamble
19.3.9.5.1 General
For HT-greenfield operation, compatibility with Clause 17 and Clause 18 STAs is not required. Therefore,
the portions of the preamble that are compatible with Clause 17 and Clause 18 STAs are not included. The
result is a shorter and more efficient PHY frame format that includes a STF, LTF(s), and an HT-SIG.
19.3.9.5.2 Cyclic shift definition for HT-greenfield format preamble
Throughout the HT-greenfield format preamble, cyclic shift is applied to prevent beamforming when similar
signals are transmitted on different spatial streams. The same cyclic shift is applied to these streams during
the transmission of the data portion of the frame. The values of the cyclic shift to be used during the HT-
greenfield format preamble, as well as the data portion of the HT-greenfield format frame, are specified in
Table 19-10.
19.3.9.5.3 HT-GF-STF definition
The HT-GF-STF is placed at the beginning of an HT-greenfield format frame. The time domain waveform
for the HT-GF-STF on transmit chain i TX shall be as shown in Equation (19-28).
i 1
r HTTX– GF – STF t = ---------------------------------------------------- w THT – GF – STF t
Tone
N STS N HT – GF – STF (19-28)
N SR N STS
iSTS
Qk i TX i STS P HT - LTF i STS 1 k S k exp j2 k F t – T CS
k = – N SR i STS = 1
where
i
STS
T CS represents the cyclic shift for the space-time stream i STS and takes values from Table 19-10
Qk is defined in 19.3.11.11.2
P HT - LTF is defined in Equation (19-27)
Sk is defined in non-HT-STF (L-STF), Equation (19-8) for 20 MHz operation and Equation (19-
9) for 40 MHz operation
k is defined in Equation (19-5) and Equation (19-6)
The waveform defined by Equation (19-28) has a period of 0.8 µs, and the HT-GF-STF includes ten such
periods, with a total duration of T HT – GF – STF = 8 µs.
19.3.9.5.4 HT-greenfield format HT-SIG
The content and format of the HT-SIG of an HT-greenfield format frame is identical to the HT-SIG in an
HT-mixed format frame, as described in 19.3.9.4.3. The placement of the HT-SIG in an HT-greenfield
format frame is shown in Figure 19-1. In HT-greenfield format frames, the HT-SIG is transmitted with the
same cyclic shifts and the same spatial mapping as the preceding portions of the preamble. This use of the
same cyclic shifts and spatial mapping is done to accommodate the estimation of channel parameters needed
to robustly demodulate and decode the information contained in the HT-SIG.
2373
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The time domain waveform for the HT-SIG on transmit chain i TX with 20 MHz operation shall be as shown
in Equation (19-29).
1
i TX 1
r HT – SIG t = ----------------------------------------- w TSYM t – nT SYM
Tone
N STS N HT – SIG n=0
26 N STS
(19-29)
Qk i TX i STS P HT - LTF i STS 1 jD k n + p n P k
k = – 26 i STS = 1
i STS
exp j2 k F t – nT SYM – T GI – T CS
where
P k and p n are defined in 17.3.5.10
Dk n is defined in 19.3.9.4.3
i
STS
T CS represents the cyclic shift for space-time stream i STS and takes values from Table 19-10
Qk is defined in 19.3.11.11.2
P HT - LTF is defined in Equation (19-27)
The time domain waveform for the HT-SIG on transmit chain i TX with 40 MHz operation shall be as shown
in Equation (19-30).
1
i TX 1
r HT – SIG t = ----------------------------------------- w TSYM t – nT SYM
Tone
N STS N HT – SIG n=0
26 N STS
P HT - LTF i STS 1 jD k n + p n P k
k = – 26 i STS = 1 (19-30)
i
STS
Q k – 32 i TX i STS exp j2 k – 32 F t – nT SYM – T GI – T CS
STS i
+ j Q k + 32 i TX i STS exp j2 k + 32 F t – nT SYM – T GI – T CS
where
p n and P k are defined in 17.3.5.10
Dk n is defined in 19.3.9.4.3
i
STS
T CS represents the cyclic shift for space-time stream i STS and takes values from Table 19-10
Qk is defined in 19.3.11.11.2
P HT - LTF is defined in Equation (19-27)
2374
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.9.5.5 HT-greenfield format LTF
The format of the LTF portion of the preamble in an HT-greenfield format frame is similar to that of the
HT-LTF in an HT-mixed format frame, as described in 19.3.9.4.6, with the difference that the first HT-LTF
(HT-LTF1) is twice as long (8 s) as the other HT-LTFs. The time domain waveform for the long training
symbol on transmit chain iTX for the first HT-LTF in an HT-greenfield format frame shall be as shown in
Equation (19-31).
1 i 1
r HTTX– LTF t = ------------------------------------------ w THT – LTF1 t (19-31)
Tone
N STS N HT – LTF
N SR N STS
iSTS
Qk i TX i STS P HT - LTF i STS 1 k HT-LTF k exp j2 k F t – T GI 2 – T CS
k = – N SR i STS = 1
where
i STS
T CS represents the cyclic shift for space-time stream i STS and takes values from Table 19-10
Qk is defined in 19.3.11.11.2
P HT - LTF is defined in Equation (19-27)
The first HT-LTF (HT-LTF1) consists of two periods of the long training symbol, preceded by a double-
length (1.6 s) cyclic prefix. The placement of the first and subsequent HT-LTFs in an HT-greenfield format
frame is shown in Figure 19-1.
19.3.10 Transmission of NON_HT format PPDUs with more than one transmit chain
When an HT device transmits a NON_HT format PPDU with the MODULATION parameter equal to
OFDM or ERP-OFDM using more than one transmit chain, it shall apply the cyclic shifts defined in
Table 19-9 to the transmission in each chain.
19.3.11 Data field
19.3.11.1 General
When BCC encoding is used, the Data field consists of the 16-bit SERVICE field, the PSDU, either six or
twelve tail bits, depending on whether one or two encoding streams are represented, and pad bits. When
LDPC encoding is used, the Data field consists of the 16-bit SERVICE field and the PSDU, processed by the
procedure in 19.3.11.7.5.
The number of OFDM symbols in the data field when BCC encoding is used is computed as shown in
Equation (19-32).
8 length + 16 + 6 N ES
N SYM = m STBC ----------------------------------------------------------
- (19-32)
m STBC N DBPS
2375
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
m STBC is 2 if STBC is used and 1 otherwise (making sure that the number of symbols is even when
STBC is used)
length is the value of the HT Length field in the HT-SIG field defined in Table 19-11
N DBPS takes the values defined in Table 19-27 through Table 19-41
The number of “zero” pad bits is thus NSYM × NDBPS – 8 × length – 16 – 6 × NES. The number of symbols in
the data field when LDPC encoding is used is described in 19.3.11.7.
For LDPC encoding, the number of encoded data bits, N avbits , is given by Equation (19-39); the number of
OFDM symbols, N SYM , is given by Equation (19-41); and the number of repeated encoded bits for padding,
N rep , is given by Equation (19-42), in 19.3.11.7.5.
19.3.11.2 SERVICE field
The SERVICE field is used for scrambler initialization. The SERVICE field is composed of 16 bits, all set to
0 before scrambling. In non-HT PPDUs, the SERVICE field is the same as in 17.3.5.2. In HT PPDUs, the
SERVICE field is composed of 16 zero bits, scrambled by the scrambler, as defined in 19.3.11.3.
19.3.11.3 Scrambler
The data field shall be scrambled by the scrambler defined in 17.3.5.5. The Clause 17 TXVECTOR
parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT shall not be
present; therefore, the initial state of the scrambler shall be set to a pseudorandom nonzero seed.
19.3.11.4 Coding
The Data field shall be encoded using either the BCC defined in 17.3.5.6 or the LDPC code defined in
19.3.11.7. The encoder is selected by the FEC coding field in the HT-SIG, as described in 19.3.9.4.3. A
single FEC encoder is always used when LDPC coding is used. When the BCC FEC encoder is used, a
single encoder is used, except that two encoders are used when the selected MCS has a PHY rate greater
than 300 Mb/s (see 19.5). To determine whether to use one or two BCC FEC encoders, the rate is calculated
based on the use of an 800 ns GI. The operation of the BCC FEC is described in 19.3.11.6. The operation of
the LDPC coder is described in 19.3.11.7.
Support for the reception of BCC-encoded Data field frames is mandatory.
19.3.11.5 Encoder parsing operation for two BCC FEC encoders
If two BCC encoders are used, the scrambled data bits are divided between the encoders by sending
alternating bits to different encoders. Bit with index i sent to the encoder j, denoted xi(j), is shown in
Equation (19-33).
j
xi = b NES i+j ; 0 j N ES – 1 (19-33)
Following the parsing operation, 6 scrambled “zero” bits following the end of the message bits in each BCC
input sequence are replaced by unscrambled “zero” bits, as described in 17.3.5.3.
The replaced bits are shown in Equation (19-34).
2376
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
j length 8 + 16 length 8 + 16
xi : 0 j N ES – 1 ; ------------------------------------ i ------------------------------------ + 5 (19-34)
N ES N ES
19.3.11.6 Binary convolutional coding and puncturing
When BCC encoding is used, the encoder parser output sequences {xi0}, and {xi1} where applicable, are
each encoded by the rate 1/2 convolutional encoder defined in 17.3.5.6. After encoding, the encoded data
shall be punctured by the method defined in 17.3.5.7 to achieve the rate selected by the MCS.
If rate 5/6 coding is selected, the puncturing scheme is defined in Figure 19-11.
Source Data X0 X1 X2 X3 X4
Encoded data A0 A1 A2 A3 A4
B0 B1 B2 B3 B4
Bit Stolen data A0 B0 A1 B2 A3 B4
A0 A1 A2 A3 A4
Bit inserted data
B0 B1 B2 B3 B4
Decoded data Y0 Y1 Y2 Y3 Y4
Figure 19-11—Puncturing at rate 5/6
19.3.11.7 LDPC codes
19.3.11.7.1 Introduction
HT LDPC codes are described in 19.3.11.7.2 through 19.3.11.7.6. These codes are optionally used in the HT
system as a high-performance error correcting code instead of the convolutional code (19.3.11.6). The
LDPC encoder shall use the rate-dependent parameters in Table 19-27 through Table 19-41, with the
exception of the NES parameter.
Support for LDPC codes is optional.
2377
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.11.7.2 LDPC coding rates and codeword block lengths
The supported coding rates, information block lengths, and codeword block lengths are described in
Table 19-15.
Table 19-15—LDPC parameters
Coding rate LDPC information block length LDPC codeword block length
(R) (bits) (bits)
1/2 972 1944
1/2 648 1296
1/2 324 648
2/3 1296 1944
2/3 864 1296
2/3 432 648
3/4 1458 1944
3/4 972 1296
3/4 486 648
5/6 1620 1944
5/6 1080 1296
5/6 540 648
19.3.11.7.3 LDPC encoder
For each of the three available codeword block lengths, the LDPC encoder supports rate 1/2, rate 2/3,
rate 3/4, and rate 5/6 encoding. The LDPC encoder is systematic, i.e., it encodes an information block,
c=(i0,i1,..., i(k–1)), of size k, into a codeword, c, of size n, c=(i0,i1,... i(k–1), p0, p1,…, p(n–k–1)), by adding n–k
parity bits obtained so that H×cT = 0, where H is an (n–k)×n parity-check matrix. The selection of the
codeword block length (n) is achieved via the LDPC PPDU encoding process described in 19.3.11.7.5.
19.3.11.7.4 Parity-check matrices
Each of the parity-check matrices is partitioned into square subblocks (submatrices) of size Z × Z. These
submatrices are either cyclic-permutations of the identity matrix or null submatrices.
The cyclic-permutation matrix Pi is obtained from the Z × Z identity matrix by cyclically shifting the
columns to the right by i elements. The matrix P0 is the Z × Z identity matrix. Figure 19-12 illustrates
examples (for a subblock size of 8 × 8) of cyclic-permutation matrices Pi.
Table F-1 displays the “matrix prototypes” of parity-check matrices for all four coding rates at block length
n=648 bits. The integer i denotes the cyclic-permutation matrix Pi, as illustrated in Figure 19-12. Vacant
entries of the table denote null (zero) submatrices.
2378
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 00 0 0 1 0 0
0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 00 0 0 0 1 0
0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 00 0 0 0 0 1
P0 = 0 0 0 1 0 0 0 0 P = 0 0 0 0
1
1 0 0 0 P = 1 00 0
5
0 0 0 0
0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 10 0 0 0 0 0
0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 01 0 0 0 0 0
0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 00 1 0 0 0 0
0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 00 0 1 0 0 0
Figure 19-12—Examples of cyclic-permutation matrices with Z=8
Table F-2 displays the matrix prototypes of parity-check matrices for block length n=1296 bits, in the same
fashion.
Table F-3 displays the matrix prototypes of parity-check matrices for block length n=1944 bits, in the same
fashion.
19.3.11.7.5 LDPC PPDU encoding process
To encode an LDPC PPDU, step a) through step g) shall be performed in sequence:
a) Compute the number of available bits, N avbits , in the minimum number of OFDM symbols in which
the Data field of the packet may fit.
N pld = length 8 + 16 (19-35)
N pld
N avbits = N CBPS m STBC ---------------------------------------------- (19-36)
N CBPS R m STBC
where
mSTBC is 2 if STBC is used and 1 otherwise
length is the value of the HT Length field in the HT-SIG field defined in Table 19-11
N pld is the number of bits in the PSDU and SERVICE field
b) Compute the integer number of LDPC codewords to be transmitted, NCW, and the length of the
codewords to be used, LLDPC from Table 19-16.
Table 19-16—PPDU encoding parameters
Range of Navbits Number of LDPC codewords LDPC codeword length LLDPC
(bits) (NCW) (bits)
N avbits 648 1 1296, if N avbits N pld + 912 × (1-R)
648, otherwise
648 N avbits 1296 1 1944, if N avbits N pld + 1464 × (1-R)
1296, otherwise
1296 N avbits 1944 1 1944
2379
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-16—PPDU encoding parameters (continued)
Range of Navbits Number of LDPC codewords LDPC codeword length LLDPC
(bits) (NCW) (bits)
1944 N avbits 2592 2 1944, if N avbits N pld + 2916 × (1-R)
1296, otherwise
2592 < Navbits N pld 1944
-------------------
-
1944 R
c) Compute the number of shortening bits, N shrt , to be padded to the Npld data bits before encoding, as
shown in Equation (19-37).
N shrt = max 0 N CW L LDPC R – N pld (19-37)
When N shrt = 0 , shortening is not performed. (Note that N shrt is inherently restricted to be non-
negative due to the codeword length and count selection of 19-16). When N shrt 0 , shortening bits
shall be equally distributed over all N CW codewords with the first Nshrt mod NCW codewords
shortened 1 bit more than the remaining codewords. Define N spcw = N shrt N CW . Then, when
N shrt 0 , the shortening is performed by setting information bits i k – Nspcw – 1 i k – 1 to 0 in the first
Nshrt mod NCW codewords and setting information bits i k – N spcw i k – 1 to 0 in the remaining
codewords. For all values of N shrt , encode each of the N CW codewords using the LDPC encoding
technique described in 19.3.11.7.2 through 19.3.11.7.4. When N shrt 0 , the shortened bits shall be
discarded after encoding.
d) Compute the number of bits to be punctured, N punc , from the codewords after encoding, as shown
in Equation (19-38).
N punc = max 0 N CW L LDPC – N avbits – N shrt (19-38)
R
If N punc 0.1 N CW L LDPC 1–R AND N shrt 1.2 N punc ------------ is true OR if
1–R
N punc 0.3 N CW L LDPC 1–R is true, increment Navbits and recompute Npunc by the
following two equations once:
Navbits = Navbits + NCBPS × mSTBC (19-39)
N punc = max 0 N CW L LDPC – N avbits – N shrt (19-40)
The punctured bits shall be equally distributed over all NCW codewords with the first
Npunc mod NCW codewords punctured 1 bit more than the remaining codewords. Define
N ppcw = N punc N CW . When N ppcw 0 , the puncturing is performed by discarding parity bits
p n – k – N ppcw – 1 p n – k – 1 of the first Npunc mod NCW codewords and discarding parity bits
p n – k – Nppcw pn – k – 1 of the remaining codewords after encoding. The number of OFDM
symbols to be transmitted in the PPDU is computed as shown in Equation (19-41).
2380
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NSYM = Navbits / NCBPS (19-41)
e) Compute the number of coded bits to be repeated, N rep , as shown in Equation (19-42).
N rep = max 0 N avbits – N CW L LDPC 1 – R – N pld (19-42)
The number of coded bits to be repeated shall be equally distributed over all NCW codewords with
one more bit repeated for the first Nrep mod NCW codewords than for the remaining codewords.
NOTE—When puncturing occurs, the coded bits are not repeated, and vice versa.
The coded bits to be repeated for any codeword shall be copied only from that codeword itself,
starting from information bit i0 and continuing sequentially through the information bits and, when
necessary, into the parity bits, until the required number of repeated bits is obtained for that
codeword. Note that these repeated bits are copied from the codeword after the shortening bits have
been removed. If for a codeword the required number of repeated bits are not obtained in this
manner (i.e., repeating the codeword once), the procedure is repeated until the required number is
achieved. These repeated bits are then concatenated to the codeword after the parity bits in their
same order. This process is illustrated in Figure 19-13. In this figure, the outlined arrows indicate the
encoding procedure steps, while the solid arrows indicate the direction of puncturing and padding
with repeated bits.
LDPC Encoding
(concatenate parity)
(c)
Data Data Shortened Data Shortened Parity
Bits Bits Bits Bits Bits Bits
(Discard Shortened Bits) (Discard Punctured Bits)
(d) (e)
Data Parity Data Parity Data Parity Repeat
Bits Bits Bits Bits Bits Bits Bits
Copy Repeat Bits
Figure 19-13—LDPC PPDU encoding padding and puncturing of a single codeword
f) For each of the NCW codewords, process the data using the number of shortening bits per codeword
as computed in step c) for encoding, and puncture or repeat bits per codeword as computed per
step d) and step e), as illustrated in Figure 19-13.
g) Aggregate all codewords and parse as defined in 19.3.11.7.6.
19.3.11.7.6 LDPC parser
The succession of LDPC codewords that result from the encoding process of 19.3.11.7.5 shall be converted
into a bitstream in sequential fashion. Within each codeword, bit i0 is ordered first. The parsing of this
encoded data stream into spatial streams shall follow exactly the parsing rules defined for the BCC encoder,
as defined in 19.3.11.8.1. However, the frequency interleaver of 19.3.11.8.3 is bypassed.
2381
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.11.8 Data interleaver
19.3.11.8.1 Overview
After coding and puncturing, the data bit streams at the output of the FEC encoders are rearranged into
blocks of N CBPSS i SS bits, where i SS = 1 2 N SS is the spatial stream index. This operation is referred
to as stream parsing and is described in 19.3.11.8.2. If BCC encoding was used, each of these blocks is then
interleaved by an interleaver that is a modification of the Clause 17 interleaver.
19.3.11.8.2 Stream parser
The number of bits assigned to a single axis (real or imaginary) in a constellation point in spatial stream iSS
is denoted by Equation (19-43).
N BPSCS i SS
s i SS = max 1 ----------------------------- (19-43)
2
N SS
The sum of these over all streams is S = s i SS .
i SS = 1
NOTE—If equal MCS is used for all spatial streams, this sum becomes N SS s , where s is the number of bits for an axis
common to all streams.
Consecutive blocks of s i SS bits are assigned to different spatial streams in a round robin fashion.
If two encoders are present, the output of each encoder is used alternately for each round robin cycle, i.e., at
the beginning S bits from the output of first encoder are fed into all spatial streams, and then S bits from the
output of second encoder are used, and so on.
j
Input k to spatial stream i SS shall be y i , which is output bit i of the encoder j,
where
j = k
------------- mod N ES (19-44)
s i SS
i SS – 1
i = s i' + S k
--------------------------- + k mod s i SS (19-45)
N ES s i SS
i' = 1
1 i SS N SS
For i SS = 1 , the first term in Equation (19-45) has a value of 0.
19.3.11.8.3 Frequency interleaver
MCS 32 interleaving shall be as defined in 17.3.5.7. Interleaving for all other MCSs is defined in this
subclause.
2382
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The bits at the output of the stream parser are divided into blocks of N CBPSS i SS , i SS = 1 2 N SS bits;
and if BCC encoding was used, each block shall be interleaved by an interleaver based on the Clause 17
interleaver. This interleaver, which is based on entering the data in rows and reading them out in columns,
has a different number of columns and rows depending on whether a 20 MHz channel or a 40 MHz channel
is used. Table 19-17 defines the interleaver parameters. If LDPC encoding was used, no frequency
interleaving is performed; hence the parsed streams are immediately mapped to symbols as defined in
19.3.11.9.
Table 19-17—Number of rows and columns in the interleaver
Parameter 20 MHz 40 MHz
NCOL 13 18
NROW 4 N BPSCS i SS 6 N BPSCS i SS
NROT 11 29
If more than one spatial stream exists after the operations based on the Clause 17 interleaver have been
applied, a third operation called frequency rotation shall be applied to the additional spatial streams. The
parameter for the frequency rotation is NROT.
The interleaving is defined using three permutations. The first permutation is defined by the rule shown in
Equation (19-46).
i = N ROW k mod N COL + k N COL , k = 0 1 N CBPSS i SS – 1 (19-46)
The second permutation is defined by the rule shown in Equation (19-47).
j = s i SS i s i SS + i + N CBPSS i SS – N COL i N CBPSS i SS mod s i SS ; (19-47)
i = 0 1 N CBPSS i SS – 1
The value of s i SS is determined by the number of coded bits per subcarrier as shown in Equation (19-48).
s i SS = max N BPSCS i SS 2 1 (19-48)
If more than one spatial stream exists, a frequency rotation is applied to the output of the second permutation
as shown in Equation (19-49).
i SS – 1
r = j– i SS – 1 2 mod 3 + 3 --------------
- N ROT N BPSCS i SS mod N CBPSS i SS ; (19-49)
3
j = 0 1 N CBPSS i SS – 1
where
i SS = 1 2 N SS is the index of the spatial stream on which this interleaver is operating
The deinterleaver uses the following operations to perform the inverse rotation. The index of the bit in the
received block (per spatial stream) is denoted by r. The first permutation reverses the third (frequency
rotation) permutation of the interleaver as shown in Equation (19-50).
2383
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
i SS – 1
j = r+ i SS – 1 2 mod 3 + 3 --------------
- N ROT N BPSCS i SS mod N CBPSS i SS ; (19-50)
3
r = 0 1 N CBPSS i SS – 1
The second permutation reverses the second permutation in the interleaver as shown in Equation (19-51).
i = s i SS j s i SS + j + N COL j N CBPSS i SS mod s i SS ; (19-51)
j = 0 1 N CBPSS i SS – 1
where s i SS is defined in Equation (19-48).
The third permutation reverses the first permutation of the interleaver as shown in Equation (19-52).
k = N COL i – N CBPSS i SS – 1 i N ROW i = 0 1 N CBPSS i SS – 1 (19-52)
19.3.11.9 Constellation mapping
19.3.11.9.1 General
The mapping between bits at the output of the interleaver and complex constellation points for BPSK,
QPSK, 16-QAM, and 64-QAM follows the rules defined in 17.3.5.8.
The streams of complex numbers are denoted as shown in Equation (19-53).
dk l n 0 k N SD – 1 ;1 l N SS ;0 n N SYM – 1 (19-53)
19.3.11.9.2 Space-time block coding (STBC)
This subclause defines a set of optional robust transmission formats that are applicable only when N STS is
greater than N SS . In this case, N SS spatial streams are mapped to N STS space-time streams, which are
mapped to N TX transmit chains. These formats are based on STBC. When the use of STBC is indicated in
the STBC field of the HT-SIG, a symbol operation shall occur between the constellation mapper and the
spatial mapper (see Figure 19-3) as defined in this subclause.
If STBC is applied, the stream of complex numbers, d k i n ;k = 0 N SD – 1 ;i = 1 N SS ;n = 0 N SYM – 1 ,
generated by the constellation mapper, is the input of the STBC encoder, which produces as output the
stream of complex numbers d̃ k i n ;k = 0 N SD – 1 ;i = 1 N STS ;n = 0 N SYM – 1 . For given values of k
and i, STBC processing operates on the complex modulation symbols in sequential pairs of OFDM symbols
so that the value of d̃ k i 2m depends on d k i 2m and d k i 2m + 1 , and d̃ k i 2m + 1 also depends on d k i 2m and
dk i 2m + 1 , as defined in Table 19-18.
If STBC is not applied, d̃ k i n = dk i n and N SS = N STS .
NOTE 1—The specific STBC schemes for single spatial streams ( N SS = 1 ) with N TX 3 are not detailed in this
subclause since they are covered through the use of spatial expansion as detailed in 19.3.11.11.2.
NOTE 2—STBC is applied only for the HT-SIG MCS field values specified in Table 19-18 and is not used with
MCS 32.
2384
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-18—Constellation mapper output to spatial mapper input for STBC
HT-SIG
HT-SIG MCS
STBC field
NSTS field (bits 0–6 NSS iSTS d̃ k i 2m d̃ k i 2m + 1
(bits 4–5 in
in HT-SIG1)
HT-SIG2)
1 dk dk
1 2m 1 2m + 1
2 0–7 1 1
2 * *
–dk 1 2m + 1 dk 1 2m
1 dk dk
1 2m 1 2m + 1
2 * *
3 8–15, 33–38 2 1 –dk 1 2m + 1 dk 1 2m
3 dk dk
2 2m 2 2m + 1
1 dk dk
1 2m 1 2m + 1
2 * *
–dk 1 2m + 1 dk 1 2m
4 8–15 2 2
3 dk dk
2 2m 2 2m + 1
4 * *
–dk 2 2m + 1 dk 2 2m
1 dk dk
1 2m 1 2m + 1
2 * *
–dk 1 2m + 1 dk 1 2m
16–23, 39, 41,
4 3 1
43, 46, 48, 50
3 dk dk
2 2m 2 2m + 1
4 dk dk
3 2m 3 2m + 1
NOTE—The ‘*’ operator represents the complex conjugate.
19.3.11.10 Pilot subcarriers
In a 20 MHz transmission four pilot tones shall be inserted in the same subcarriers used in Clause 17, i.e., in
subcarriers –21, –7, 7, and 21. The pilot sequence for the nth symbols and iSTSth space-time stream shall be
as shown in Equation (19-54).
-28,28 N STS N STS
i STS n = 0 0 0 0 0 0 0 i STS n mod 4 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 1 mod 4 0 0 0 0 0 0 0
(19-54)
N STS N STS
0 0 0 0 0 0 i STS n + 2 mod 4 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 3 mod 4 0 0 0 0 0 0 0
In a 40 MHz transmission (excluding MCS 32; see 19.3.11.11.5), pilot signals shall be inserted in subcarriers
–53, –25, –11, 11, 25, and 53. The pilot sequence for symbol n and space-time stream iSTS shall be as shown
in Equation (19-55).
2385
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-58,58 N STS
P i STS n = 0 0 0 0 0 i STS n mod 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
N STS N STS
0 0 i STS n + 1 mod 6 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 2 mod 6 0 0 0 0 0 0 0 0 0
N STS N STS
(19-55)
0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 3 mod 6 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 4 mod 6
N STS
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 5 mod 6 0 0 0 0 0
N STS
where the patterns i STS n are defined in Table 19-19 and Table 19-20.
NOTE—For each space-time stream, there is a different pilot pattern, and the pilot patterns are cyclically rotated over
symbols.
The basic patterns are also different according to the total number of space-time streams for the packet.
Table 19-19—Pilot values for 20 MHz transmission
N STS N STS N STS N STS
NSTS iSTS i STS 0 i STS 1 i STS 2 i STS 3
1 1 1 1 1 –1
2 1 1 1 –1 –1
2 2 1 –1 –1 1
3 1 1 1 –1 –1
3 2 1 –1 1 –1
3 3 –1 1 1 –1
4 1 1 1 1 –1
4 2 1 1 –1 1
4 3 1 –1 1 1
4 4 –1 1 1 1
Table 19-20—Pilots values for 40 MHz transmission (excluding MCS 32)
N STS N STS N STS N STS N STS N STS
NSTS iSTS i STS 0 i STS 1 i STS 2 i STS 3 i STS 4 i STS 5
1 1 1 1 1 –1 –1 1
2 1 1 1 –1 –1 –1 –1
2 2 1 1 1 –1 1 1
3 1 1 1 –1 –1 –1 –1
3 2 1 1 1 –1 1 1
3 3 1 –1 1 –1 –1 1
2386
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-20—Pilots values for 40 MHz transmission (excluding MCS 32) (continued)
N STS N STS N STS N STS N STS N STS
NSTS iSTS i STS 0 i STS 1 i STS 2 i STS 3 i STS 4 i STS 5
4 1 1 1 –1 –1 –1 –1
4 2 1 1 1 –1 1 1
4 3 1 –1 1 –1 –1 1
4 4 –1 1 1 1 –1 1
19.3.11.11 OFDM modulation
19.3.11.11.1 General
The time domain signal is composed from the stream of complex numbers as shown in Equation (19-56)
d̃ k l n 0 k N SD – 1 ;1 l N STS ;0 n N SYM – 1 (19-56)
and from the pilot signals. In a 40 MHz transmission, the upper subcarriers are rotated 90° relative to the
lower subcarriers.
19.3.11.11.2 Spatial mapping
The transmitter may choose to rotate and/or scale the constellation mapper output vector (or the space-time
block coder output, if applicable). This rotation and/or scaling is useful in the following cases:
— When there are more transmit chains than space-time streams, N STS N TX
— As part of (an optional) sounding packet
— As part of (an optional) calibration procedure
— When the packet is transmitted using one of the (optional) beamforming techniques
i
If the data to be transmitted on subcarrier k on space-time stream i STS are X k STS , the transmitted data on the
transmit chain i TX shall be as shown in Equation (19-57).
N SR N STS
i TX 1 i STS i
r Field = ----------------------------------- w TField t Qk i TX i STS X k exp j2 k F
STS
t – T CS (19-57)
Tone
N STS N Field k = – N SR i STS = 1
where
Qk i TX i STS is the element in row i TX and column i STS in a matrix Q k with N TX rows and N STS columns;
Q k may be frequency dependent
Field is any field, as defined in 19.3.7, excluding L-STF, L-LTF, L-SIG, and HT-SIG in HT_MF
format PPDU
Below are examples of spatial mapping matrices that might be used. There exist many other alternatives;
implementation is not restricted to the spatial mapping matrices shown. The examples are:
2387
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a) Direct mapping: Q k is a diagonal matrix of unit magnitude complex values that takes one of two
forms:
1) Q k = I , the identity matrix
2) A CSD matrix in which the diagonal elements represent cyclic shifts in the time domain:
i i
Qk i i = exp – j2 k F CS , where CS i = 1 N TX represents the CSD applied.
b) Indirect mapping: Q k may be the product of a CSD matrix and a unitary matrix such as the
Hadamard matrix or the Fourier matrix.
c) Spatial expansion: Q k is the product of a CSD matrix and a square matrix formed of orthogonal
columns. As an illustration:
1) The spatial expansion may be performed by duplicating some of the N STS streams to form the
N TX streams, with each stream being scaled by the normalization factor N STS N TX . The
spatial expansion may be performed by using, for instance, one of the following matrices,
denoted D, left-multiplied by a CSD matrix, denoted M CSD k , and/or possibly multiplied by
any unitary matrix. The resulting spatial mapping matrix is then Q k = M CSD k D , where D
may take on one of the following values:
1 T
i) NTX=2, NSTS=1, D = ------- 1 1
2
1 T
ii) NTX=3, NSTS=1, D = ------- 1 1 1
3
1 T
iii) NTX=4, NSTS=1, D = --- 1 1 1 1
2
1 0
iv) NTX=3, NSTS=2, D = 2
--- 0 1
3
1 0
1 0
1 0 1
v) NTX=4, NSTS=2, D = -------
2 1 0
0 1
1 0 0
3
vi) NTX=4, NSTS=3, D = ------- 0 1 0
2 0 0 1
1 0 0
2) Different spatial expansion over subcarriers should be used in HT-mixed format only and with
the smoothing bit equal to 0:
T T
i) NTX=2, NSTS=1, Q k N STS = 1 0 or Qk N STS = 0 1
1 0 1 0 0 0
ii) NTX=3, NSTS=2, Q k N STS = 0 0 0 1 or 1 0
0 1 0 0 0 1
2388
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
1 0 1 0 0 0 0 0
iii) NTX=4, NSTS=2, Q k N STS = 0 0 0 0 1 0 or 1 0
0 0 0 1 0 0 0 1
0 1 0 0 0 1 0 0
1 0 0 1 0 0
iv) NTX=4, NSTS=3, Q k N STS = 0 1 0 or 0 0 0
0 0 0 0 1 0
0 0 1 0 0 1
d) Beamforming steering matrix: Q k is any matrix that improves the reception in the receiver based on
some knowledge of the channel between the transmitter and the receiver. With transmit
beamforming with explicit feedback, the steering matrix Q k is determined using either H eff for CSI
feedback or V k for noncompressed and compressed matrices feedback from the STA to which the
beamformed packet is addressed.
When there are fewer space-time streams than transmit chains, the first N STS columns of the matrices above
that are square might be used.
The same matrix Q k shall be applied to subcarrier k during all parts of the packet in HT-greenfield format
and all parts of the packet following and including the HT-STF field in an HT-mixed format packet. This
operation is transparent to the receiver.
If at least 95% of the sum of the energy from all impulse responses of the time domain channels between all
space-time streams and all transmit chain inputs, induced by the CSD added according to Table 19-10 and
the frequency-dependence in the matrix Q k , is contained within 800 ns, the smoothing bit should be set to 1.
Otherwise, it shall be set to 0.
The CSD of Table 19-10 shall be applied at the input of the spatial mapper.
For the identity matrix direct mapping, the smoothing bit should be set to 1.
If no spatial mapping is applied, the matrix Q k is equal to the identity matrix and N STS = N TX .
Sounding PPDUs using spatial expansion shall use an orthonormal column matrix Q k . When the number of
rows and columns is equal, the orthonormal column matrix becomes a unitary matrix.
19.3.11.11.3 Transmission in 20 MHz HT format
For 20 MHz HT transmissions, the signal from transmit chain i TX 1 i TX N TX shall be as shown in
Equation (19-58).
2389
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
N SYM – 1
i TX 1
r HT – DATA t = --------------------------------------------- w TSYM t – nT SYM
Tone
N STS N HT – DATA n=0
N SR N STS
k (19-58)
Qk i TX i STS D̃ k i STS n + pn + z P i STS n
k = – N SR i STS = 1
i STS
exp j2 k F t – nT SYM – T GI – T CS
where
z is 3 in an HT-mixed format packet and 2 in an HT-greenfield format packet
pn is defined in 17.3.5.10
0 k=0 7 21
D̃ k i STS n =
d̃ Mr k i STS n
otherwise
k + 28 – 28 k – 22
k + 27 – 20 k – 8
M k =
r k + 26 –6 k –1
k + 25 1 k 6
k + 24 8 k 20
k + 23 22 k 28
k
P i STS n is defined in Equation (19-54)
19.3.11.11.4 Transmission in 40 MHz HT format
For 40 MHz HT transmissions, the signal from transmit chain i TX shall be as shown in Equation (19-59).
N SYM – 1
i TX 1
r HT – DATA t = --------------------------------------------- w TSYM t – nT SYM
Tone
N STS N HT – DATA n=0
N SR N STS
k (19-59)
Qk i TX i STS D̃ k i STS n + pn + z P i STS n k
k = – N SR i STS = 1
i STS
exp j2 k F t – nT SYM – T GI – T CS
where
z is 3 in an HT-mixed format packet and 2 in an HT-greenfield format packet
pn is defined in 17.3.5.10
2390
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
0 k=0 1 11 25 53
D̃ k i STS n =
d̃ Mr k i STS n
otherwise
k + 58 – 58 k – 54
k + 57 – 52 k – 26
k + 56 – 24 k – 12
r
M k = k + 55 – 10 k – 2
k + 52 2 k 10
k + 51 12 k 24
k + 50 26 k 52
k + 49 54 k 58
k
P i STS n is defined in Equation (19-55)
NOTE—The 90° rotation that is applied to the upper part of the 40 MHz channel is applied in the same way to the
HT-STF, HT-LTF, and HT-SIG. The rotation applies to both pilots and the data in the upper part of the 40 MHz channel.
19.3.11.11.5 Transmission in MCS 32 format
MCS 32 format provides the lowest transmission rate in 40 MHz. It is used only for one spatial stream and
only with BPSK modulation and rate 1/2 coding.
In the MCS 32 format, the signal shall be as shown in Equation (19-60).
N SYM – 1
i TX 1
r HT – DATA t = ----------------------------------- w TSYM t – nT SYM (19-60)
Tone
N HT –D uplicate n=0
N SR
Dk n + pn + z Pk Q k – 32 i TX 1 exp j2 k – 32 F t – nT SYM – T GI
k = – N SR
+ j Q k + 32 i TX 1 exp j2 k + 32 F t – nT SYM – T GI
where
z is defined in 19.3.11.11.3
P k and p n are defined in 17.3.5.10
Dk n is defined in 19.3.9.4.3
N SR has the value defined for non-HT 20 MHz transmission
Qk i TX 1 is an element from a vector of length N TX , which may be frequency dependent
Tone
N HT – Duplicate is defined in Table 19-8
The rules of spatial expansion CSD limitation, as specified in 19.3.11.11.2, shall apply to Q k i TX 1 .
2391
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.11.11.6 Transmission with a short GI
Short GI is used in the data field of the packet when the Short GI field in the HT-SIG is equal to 1. When it
is used, the same formula for the formation of the signal shall be used as in 19.3.11.11.3, 19.3.11.11.4, and
19.3.11.11.5, with T GI replaced by T GIS and T SYM replaced by T SYMS .
NOTE—Short GI is not used in HT-greenfield format with one spatial stream, in which case the HT-SIG is immediately
followed by data. It is very difficult to parse the HT-SIG in time to demodulate these data with the correct GI length if
the GI length is not known in advance.
19.3.11.12 Non-HT duplicate transmission
Non-HT duplicate transmission is used to transmit to Clause 17 STAs, Clause 18 STAs, and Clause 19 STAs
that may be present in either the upper or lower halves of the 40 MHz channel. The L-STF, L-LTF, and
L-SIG shall be transmitted in the same way as in the HT 40 MHz transmission. The HT-SIG, HT-STF, and
HT-LTF are not transmitted. Data transmission shall be as defined in Equation (19-61).
N SYM – 1
i TX 1
r LEG – DUP t = --------------------------------------- w TSYM t – nT SYM (19-61)
Tone
N Non-HT Duplicate n=0
26
iTX
D k n + p n + 1 P k exp j2 k – 32 F t – nT SYM – T GI – T CS
k = – 26
iTX
+ j exp j2 k + 32 F t – nT SYM – T GI – T CS
where
P k and p n are defined in 17.3.5.10
Dk n is defined in 19.3.9.4.3
iTX
T CS represents the cyclic shift of the transmit chain i TX and is defined in Table 19-9
Tone
N Non-HT Duplicate is defined in Table 19-8
19.3.12 Beamforming
19.3.12.1 General
Beamforming is a technique in which the beamformer utilizes the knowledge of the MIMO channel to
generate a steering matrix Q k that improves reception in the beamformee.
The equivalent complex baseband MIMO channel model is one in which, when a vector
T T
xk = x1 x2 x NTX is transmitted in subcarrier k, the received vector y k = y 1 y 2 y NRX is modeled
as shown in Equation (19-62).
yk = Hk xk + n (19-62)
2392
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
Hk is channel matrix of dimensions N RX N TX
n is white (spatially and temporally) Gaussian noise as illustrated in Figure 19-14
HAB
STA A STA B
HBA
BTX , BRX
ATX , ARX
Figure 19-14—Beamforming MIMO channel model (3x2 example)
When beamforming is used, the beamformer replaces x k , which in this case has N STS N TX elements,
with Q k x k , where Q k has N TX rows and N STS columns, so that the received vector is as shown in
Equation (19-63).
yk = Hk Qk xk + n (19-63)
The beamforming steering matrix that is computed (or updated) from a new channel measurement replaces
the existing Q k for the next beamformed data transmission. There are several methods of beamforming,
differing in the way the beamformer acquires the knowledge of the channel matrices H k and on whether the
beamformer generates Q k or the beamformee provides feedback information for the beamformer to
generate Q k .
19.3.12.2 Implicit feedback beamforming
Implicit feedback beamforming is a technique that relies on reciprocity in the time division duplex channel
to estimate the channel over which a device is transmitting based on the MIMO reference that is received
from the device to which it plans to transmit. This technique allows the transmitting device to calculate a set
of transmit steering matrices, Q k , one for each subcarrier, which are intended to optimize the performance
of the link.
Referring to Figure 19-14, beamforming transmissions from STA A to STA B using implicit techniques are
enabled when STA B sends STA A a sounding PPDU, the reception of which allows STA A to form an
estimate of the MIMO channel from STA B to STA A, for all subcarriers. In a TDD channel in which the
forward and reverse channels are reciprocal, the channel from STA A to STA B in subcarrier k is the matrix
transpose of the channel from STA B to STA A in subcarrier k to within a complex scaling factor, i.e.,
T
H AB k = H BA k . Here H AB k is the MIMO channel matrix from STA A to STA B at subcarrier k , and
2393
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
H BA k is the channel matrix from STA B to STA A at subcarrier k . STA A uses this relationship to compute
transmit steering matrices that are suitable for transmitting to STA B over H AB k .
NOTE—In order for the recipient of the sounding to compute steering matrices when steered or unsteered sounding is
used, the steering matrices need to have the property H k Q k H k Q k H = H k H Hk , where X H indicates the conjugate
transpose of the matrix X .
While the over-the-air channel between the antenna(s) at one STA and the antenna(s) at a second STA is
reciprocal, the observed baseband-to-baseband channel used for communication might not be, as it includes
the transmit and receive chains of the STAs. Differences in the amplitude and phase characteristics of
the transmit and receive chains associated with individual antennas degrade the reciprocity of the over-the-
air channel and cause degradation of performance of implicit beamforming techniques. The over-the-air
calibration procedure described in 10.32.2.4 may be used to restore reciprocity. The procedure provides the
means for calculating a set of correction matrices that can be applied at the transmit side of a STA to correct
the amplitude and phase differences between the transmit and receive chains in the STA. If this correction is
done at least at the STA that serves as the beamformer, there is sufficient reciprocity for implicit feedback in
the baseband-to-baseband response of the forward link and reverse channel.
Figure 19-15 illustrates the observed baseband-to-baseband channel, including reciprocity correction.
Spatial mapping matrices Q A k and Q B k are assumed to be identity matrices here for simplicity of
illustration.
H AB
KA ATX HAB BRX
STA A STA B
ARX HBA BTX KB
H BA
Figure 19-15—Baseband-to-baseband channel
NOTE—Spatial mapping matrix for sounding PPDUs are specified in 19.3.13.3.
The amplitude and phase responses of the transmit and receive chains can be expressed as diagonal matrices
with complex valued diagonal entries, of the form A TX k and A RX k at STA A. The relationship between the
baseband-to-baseband channel, H̃ AB k , and the over-the-air channel, H AB k , is shown in Equation (19-64).
H̃ AB k = B RX k H AB k A TX k (19-64)
Similarly, the relationship between H̃ BA k and H BA k is shown in Equation (19-65).
2394
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
H̃ BA k = A RX k H BA k B TX k (19-65)
As an example, consider the case where calibration is performed at both STA A and STA B. The objective is
to compute correction matrices, K A k and K B k , that restore reciprocity so that Equation (19-66) is true.
T
H̃ AB k K A k = H̃ BA k K B k (19-66)
The correction matrices are diagonal matrices with complex valued diagonal entries. The reciprocity
condition in Equation (19-66) is enforced when Equation (19-67) and Equation (19-68) are true.
–1
KA k = A k A TX k A RX k (19-67)
and
–1
KB k = B k B TX k B RX k (19-68)
where A k and B k are complex valued scaling factors.
Using these expressions for the correction matrices, the calibrated baseband-to-baseband channel between
STA A and STA B is expressed as shown in Equation (19-69).
Ĥ AB k = H̃ AB k K A k = A k B RX k H AB k A RX k (19-69)
If both sides apply the correction matrices, the calibrated baseband-to-baseband channel between STA A and
STA B is expressed as shown in Equation (19-70).
B k T
Ĥ BA k = B k A RX k H BA k B RX k = ----------
- Ĥ AB k (19-70)
A k
Focusing on STA A, the procedure for estimating K A k is as follows:
a) STA A sends STA B a sounding PPDU, the reception of which allows STA B to estimate the
channel matrices H̃ AB k .
b) STA B sends STA A a sounding PPDU, the reception of which allows STA A to estimate the
channel matrices H̃ BA k .
c) STA B sends the quantized estimates of H̃ AB k to STA A.
d) STA A uses its local estimates of H̃ BA k and the quantized estimates of H̃ AB k received from STA B
to compute the correction matrices K A k .
NOTE—When a nonidentity matrix is used for Q A k , STA A is responsible for accounting for the spatial mapping in its
local channel estimate as well as in the quantized CSI fed back since the channel feedback received in step c) is actually
H̃ AB k Q A k and not H̃ AB k . Furthermore, since Q B k is defined in 19.3.13.3, additional steps might be taken in STA
A to remove the effect of Q B k when computing the correction matrix K A k .
Steps a) and b) occur over a short time interval to so the channel changes as little as possible between
measurements. A similar procedure is used to estimate K B k at STA B. The details of the computation of the
correction matrices is implementation specific and beyond the scope of this standard.
2395
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.12.3 Explicit feedback beamforming
19.3.12.3.1 General
In explicit beamforming, in order for STA A to transmit a beamformed packet to STA B, STA B measures
the channel matrices and sends STA A either the effective channel, H eff k , or the beamforming feedback
matrix, V k , for STA A to determine a steering matrix, Q steer, k = Q k V k , with V k found from H k Q k , where
Q k is the orthonormal spatial mapping matrix that was used to transmit the sounding packet that elicited the
V k feedback. The effective channel, H eff k = H k Q k , is the product of the spatial mapping matrix used on
transmit with the channel matrix. When new steering matrix Q steer k is found, Q steer k may replace Q k for
the next beamformed data transmission.
NOTE— Q steer k is a mathematical term to update a new steering matrix for Q k in the next beamformed data
transmission.
19.3.12.3.2 CSI matrices feedback
In CSI matrices feedback, the beamformer receives the quantized MIMO channel matrix, H eff , from the
beamformee. The beamformer then may use this matrix to compute a set of transmit steering matrices, Q k .
The CSI matrix, H eff , shall be determined from the transmitter spatial mapper input to the receiver FFT
outputs. The beamformee shall remove the CSD in Table 19-10 from the measured channel matrix.
The matrices H eff k , where k is the subcarrier index, are encoded so that applying the procedure in
19.3.12.3.3 optimally reconstructs the matrix.
19.3.12.3.3 CSI matrices feedback decoding procedure
q
The received, quantized matrix H eff k (of a specific subcarrier, k ) shall be decoded as follows:
q R q I
a) The real and imaginary parts of each element of the matrix, H eff m l k and H eff m l k , are
decoded as a pair of 2s complement numbers to create the complex element, where 1 m N r and
1 l Nc .
b) Each element in the matrix of subcarrier k is then scaled using the value in the carrier matrix
amplitude field (3 bits), M H k , interpreted as a positive integer, in decibels, as follows:
1) Calculate the linear value as defined in Equation (19-71).
2) Calculate decoded values of the real and imaginary parts of the matrix element as defined in
Equation (19-72) and Equation (19-73).
MH k 20
r k = 10 (19-71)
q R
H eff m l k
Re H̃ eff m l k = --------------------------
- (19-72)
r k
q I
H eff m l k
Im H̃ eff m l k = --------------------------
- (19-73)
r k
2396
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.12.3.4 Example of CSI matrices feedback encoding
The following is an example of an encoding process:
a) The maximums of the real and imaginary parts of each element of the matrix in each subcarrier are
found, as defined by Equation (19-74).
m = Nr l = Nc m = Nr l = Nc
m H k = max max Re H eff m l k m=1 l=1
max Im H eff m l k m=1 l=1
(19-74)
b) The scaling ratio is calculated and quantized to 3 bits as defined by Equation (19-75). A linear scaler
is given by Equation (19-76).
z = N SR
max m H z z = –N
M H k = min 7 20log 10 -----------------------------------------------
-
SR
(19-75)
mH k
where
z=N
lin
max m H z z = –NSR
MH k = -----------------------------------------------
-
SR
(19-76)
M H k 20
10
c) The real and imaginary parts of each element in the matrix H eff m l k are quantized to N b bits in
2s complement encoding as defined by Equation (19-77) and Equation (19-78).
q R Re H eff m l k N –1
H eff m l k = ----------------------------------------
lin
2 b – 1 + 0.5 (19-77)
MH k
q I Im H eff m l k N –1
H eff m l k = ----------------------------------------
lin
2 b – 1 + 0.5 (19-78)
MH k
Each matrix is encoded using 3 + 2 Nb Nr N c bits, where N r and N c are the number of rows and
columns, respectively, in the channel matrix estimate computed by the receiving station and where N b may
have the value of 4, 5, 6, or 8 bits.
19.3.12.3.5 Noncompressed beamforming feedback matrix
In noncompressed beamforming feedback matrix, the beamformee shall remove the space-time stream CSD
in Table 19-10 from the measured channel before computing a set of matrices for feedback to the
beamformer. The beamforming feedback matrices, V k , found by the beamformee are sent to the
beamformer in the order of real and imaginary components per tone as specified in 9.4.1.29. The
beamformer might use these matrices to determine the steering matrices, Q k .
The beamformee shall encode the matrices V k so a beamformer applying the procedure below optimally
reconstructs the matrix.
q
The received matrix V k (of a specific subcarrier k ) shall be decoded as follows:
2397
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
q R q I
a) The real and imaginary parts of each element of the matrix, V m l and V m l , shall be decoded as a
pair of 2s complement numbers to create the complex element, where 1 m N r and 1 l Nc .
b) The dimensions of the beamforming feedback matrices are N r N c , where N r and N c are the
number of rows and columns, respectively, in the beamforming feedback matrix computed by the
receiving station. Each matrix is encoded using 2 N b N r N c bits. N b may have the value of 2,
4, 6, or 8 bits.
c) Columns 1 N c of the beamforming feedback matrix correspond to spatial streams 1 Nc ,
respectively. The mapping of spatial stream to modulation is defined in the MCS tables in 19.5. A
transmitter shall not reorder the columns of the beamforming feedback matrices.
19.3.12.3.6 Compressed beamforming feedback matrix
In compressed beamforming feedback matrix, the beamformee shall remove the space-time stream CSD in
Table 19-10 from the measured channel before computing a set of matrices for feedback to the beamformer.
The beamforming feedback matrices, V k , found by the beamformee are compressed in the form of angles,
which are sent to the beamformer. The beamformer might use these angles to decompress the matrices and
determine the steering matrices Q k .
The matrix V per tone shall be compressed as follows: The N r N c beamforming feedback orthonormal
column matrix V found by the beamformee shall be represented as shown in Equation (19-79). When the
number of rows and columns is equal, the orthonormal column matrix becomes a unitary matrix.
min(N c N r – 1) Nr
j j N –1 i
i i r T
V = Di 1i – 1 e e 1 G li li Ĩ Nr Nc (19-79)
i=1 l = i+1
j j N –1 i
i i r
The matrix D i 1 i – 1 e e 1 is an N r N r diagonal matrix, where 1 i – 1 represents a sequence
of 1s with length of i–1, as shown in Equation (19-80).
Ii – 1 0 0
j i i
j 0 e 0 0
j i i Nr – 1 i
D 1i – 1 e e 1 = 0 0 0 (19-80)
j N –1 i
0 e r 0
0 0 0 0 1
The matrix G li is an N r N r Givens rotation matrix as shown in Equation (19-81).
Ii – 1 0 0 0 0
0 cos 0 sin 0
G li = 0 0 Il – i – 1 0 0 (19-81)
0 – sin 0 cos 0
0 0 0 0 I Nr – l
2398
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where each I m is an m m identity matrix, and cos and sin are located at row l and column i.
Ĩ Nr Nc is an identity matrix padded with 0s to fill the additional rows or columns when N r Nc .
For example, a 4×2 V matrix has the representation shown in Equation (19-82).
j T T T
e 11
0 0 0 cos 21 sin 21 0 0 cos 0 sin 0 cos 0 0 sin
31 31 41 41
0 e
j 21
0 0 – sin 21 cos 21 0 0 0 1 0 0 0 1 0 0
V =
j 31 0 0 1 0 – sin 31 0 cos 31 0 0 0 1 0
0 0 e 0
0 0 0 1 0 0 0 1 – sin 41 0 0 cos 41
0 0 0 1
(19-82)
T T
1 0 0 0 1 0 0 0 1 0 0 0 1 0
j
0 e 22
0 0 0 cos 32 sin 32 0 0 cos 42 0 sin 42 0 1
0 0 e 0
j 32 0 – sin 32 cos 32 0 0 0 1 0 0 0
0 0 0 1 0 0 0 1 0 – sin 42 0 cos 42 0 0
The procedure for finding a compressed V matrix is described as follows:
A Nr N c beamforming feedback orthonormal column matrix V is column-wise phase invariant because
the steering matrix needs a reference in phase per each column. When the number of rows and columns is
equal, the orthonormal column matrix becomes a unitary matrix. In other words, V is equivalent to ṼD̃ ,
j j j Nc
1 2
where D̃ is a column-wise phase shift matrix such as D̃ = diag e e e . When the beamformee
estimates the channel, it may find Ṽ for the beamforming feedback matrix for the beamformer, but it should
send ṼD̃ back to the beamformer, where V = ṼD̃ . The angle, i, in D̃ is found to make the last row of
ṼD̃ to be non-negative real numbers.
j j N –1 1 *
11 r
The angles 1 1 Nr – 1 1 in the diagonal matrix D 1 e e 1 shall satisfy the
*
constraint that all elements in the first column of D 1 V are non-negative real numbers. Now, the first
* T
column of G Nr 1 G 31 G 21 D 1 V can be 1 0 0 by the Givens rotations G l 1 such as shown in
Equation (19-83).
*
j
cos Nr 1 0 0 sin Nr 1 cos 31 0 sin 31 0 cos 21 sin 21 0 0 e 11
0 0 0 1 0 0 0
0 1 0 0 0 1 0 0 – sin cos 0 0 0 0 0 0
21 21 V = (19-83)
0 0 1 0 – sin 31 0 cos 31 0 0 0 1 0
j Nr – 1 1 0 V2
0 0 e 0
– sin Nr 1 0 0 cos N r 1 0 0 0 1 0 0 0 1 0
0 0 0 1
For a new N r – 1 N c – 1 submatrix V 2 , this process is applied in the same way. Then, the angles
j j N –1 2 *
22 r
2 2 Nr – 1 2 in the diagonal matrix D 2 1 e e 1 shall satisfy the constraint that all
2399
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
*
elements in the second column of D 2 diag(1,V 2 are non-negative real numbers. Now, the first two
* *
columns of G Nr 2 G 32 D 2 G Nr 1 G 31 G 21 D 1 V can be Ĩ Nr 2 by the Givens rotations G l 2 such as
shown in Equation (19-84).
*
1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0
j
0 cos Nr 2 0 sin N r 2 0 cos 32 sin 32 0 0 e 22 0 0 * 0 1 0 0
GN 1 G 31 G 21 D 1 V = (19-84)
0 0 1 0 0 – sin cos 0 j N –1 2 0 0
32 32 0 0 e
r
0 V3
0 – sin Nr 2 0 cos N r 2 0 0 0 1 0 0 0 0
0 1
This process continues until the first N c columns of the right side matrix become Ĩ Nr Nc . When N c Nr ,
this process does not need to continue because V Nc + 1 is nulled out by Ĩ Nr Nc . Then, by multiplying the
complex conjugate transpose of the products of the D i and G li matrices on the left, V can be expressed as
shown in Equation (19-85).
T T T T T T T T T
V = D 1 G 21 G 31 G Nr 1 D 2 G 32 G 42 G Nr 2 Dp Gp + 1 p Gp + 2 p G Nr p Ĩ Nr NC (19-85)
where p = min N c N r – 1 , which can be written in short form as in Equation (19-79).
The angles found from the decomposition process above, e.g., the values of i j and k l, are quantized as
described in 9.6.12.8.
Columns 1 N c of the beamforming feedback matrix correspond to spatial streams 1 N c , respectively.
The mapping of spatial stream to modulation is defined in the MCS tables in 19.5. A transmitter shall not
reorder the columns of the beamforming feedback matrices in determining steering matrices.
19.3.13 HT Preamble format for sounding PPDUs
19.3.13.1 General
The MIMO channel measurement takes place in every PPDU as a result of transmitting the HT-LTFs as part
of the PHY preamble. The number of HT-LTFs transmitted shall be determined by the number of space-time
streams transmitted unless additional dimensions are optionally sounded using HT-ELTFs and these are
transmitted using the same spatial transformation that is used for the Data field of the HT PPDU. The use of
the same spatial transformation enables the computation of the spatial equalization at the receiver.
When the number of space-time streams, N STS , is less than the number of transmit antennas, or less than
min N TX N RX , sending only N STS HT-LTFs does not allow the receiver to recover a full characterization
of the MIMO channel, even though the resulting MIMO channel measurement is sufficient for receiving the
Data field of the HT PPDU.
However, it is often desirable to obtain as full a characterization of the channel as possible. This involves the
transmission of a sufficient number of HT-LTFs to sound the full dimensionality of the channel, which is in
some cases N TX and in other cases min N TX N RX . These cases of MIMO channel measurement are
referred to as MIMO channel sounding. A sounding packet may be used to sound available channel
dimensions. A sounding PPDU is identified by setting the Not Sounding field in the HT-SIG to 0. A
sounding PPDU may have any allowed number of HT-LTFs satisfying N HT - LTF N STS . In general, if the
2400
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Not Sounding field in the HT-SIG is equal to 0 and N HT - LTF N STS , HT-ELTFs are used, except where
N SS = 3 and N HT - LTF = 4 or in an NDP.
19.3.13.2 Sounding with a NDP
A STA may sound the channel using a NDP (indicated by the HT Length field in the HT-SIG equal to 0)
with the Not Sounding field equal to 0. The number of LTFs is the number implied by the MCS, which shall
indicate two or more spatial streams. The last HT-LTF of an NDP shall not be followed by a Data field (see
Figure 19-16).
It is optional for a STA to process an NDP.
HT-
HT-GF-STF HT-LTF1 HT-SIG
LTF2
Figure 19-16—Example of an NDP used for sounding
19.3.13.3 Sounding PPDU for calibration
In the case of a bidirectional calibration exchange, two STAs exchange sounding PPDUs, the exchange of
which enables the receiving STA to compute an estimate of the MIMO channel matrix H k for each
subcarrier k. In general, in an exchange of calibration messages, the number of spatial streams is less than
the number of transmit antennas. In such cases, HT-ELTFs are used. In the case of sounding PPDUs for
calibration, the antenna mapping matrix shall be as shown in Equation (19-86).
Q k = C CSD k P CAL (19-86)
where
C CSD k is a diagonal cyclic shift matrix in which the diagonal elements carry frequency domain
representation of the cyclic shifts given in Table 19-9
P CAL is one of the following unitary matrices:
For N TX = 1 P CAL = 1
2
For N TX = 2 P CAL = ------- 1 – 1
2 1 1
1 1 1
3
For N TX = 3 P CAL = ------- 1 e – j 2 3
e
–j 4 3
3
–j 4 3 –j 2 3
1 e e
1 –1 1 1
1 1 1 –1 1
For N TX = 4 P CAL = ---
2 1 1 1 –1
–1 1 1 1
2401
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.13.4 Sounding PPDU for channel quality assessment
In response to the reception of an MRQ, sent by STA A to STA B, the responding STA B returns to the
requesting STA A an MCS selection that STA B determines to be a suitable MCS for STA A to use in
subsequent transmissions to STA B. In determining the MCS, STA B performs a channel quality assessment,
which entails using whatever information STA B has about the channel, such as an estimate of the MIMO
channel derived from the sounding PPDU that carries the MRQ. To enable this calculation, the MRQ is sent
in conjunction with a sounding PPDU.
The STA sending the MRQ (STA A) determines how many HT-LTFs to send, and whether to use HT-ELTFs
or an NDP, based on the Transmit Beamforming Capabilities field, number of space-time streams used in the
PPDU carrying the MRQ, the number of transmit chains it is using ( N TX ), whether the transmit and receive
STAs support STBC, and in some cases, the number of receive chains at the responding STA ( N RX ).
The maximum number of available space-time streams is set by the number of transmit and receive chains
and the STBC capabilities of the transmitter and receiver, as is shown in Table 19-21. While the number of
receive chains is not communicated in a capabilities indicator, the maximum number of space-time streams
supported may be inferred from the MCS capabilities and the STBC capabilities of the receiving STA. When
the number of receive chains is known at the transmitter, the number of HT-LTFs sent to obtain a full
channel quality assessment is determined according to the maximum number of space-time streams
indicated in Table 19-21. The number of HT-LTFs to use in conjunction with the indicated number of space-
time streams is determined according to 19.3.9.4.6.
Table 19-21—Maximum available space-time streams
N STS max N STS max
N TX N RX
without STBC with STBC
1 1 1 N/A
2 1 1 2
3 1 1 2
3 2 2 3
4 1 1 2
4 2 2 4
If the requesting STA A sends an MRQ in a PPDU that uses fewer space-time streams in the data portion
than the maximum number of space-time streams possible given the number of antennas at STA A and the
responding STA B, the channel quality assessment made by STA B may be based on the HT-DLTFs alone. In
this case, the MFB is limited to MCSs using the number of streams used in the Data field of the HT PPDU,
or fewer. To determine whether an MCS should be chosen that uses more spatial streams than the PPDU
containing the MRQ, it is necessary for the requesting STA A to either use HT-ELTFs (i.e., send the MRQ in
a staggered sounding PPDU) or use an NDP (i.e., send the MRQ in conjunction with an NDP).
The sounding PPDU may have nonidentity spatial mapping matrix Q k . For different receiving STAs, Q k
may vary.
2402
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.14 Regulatory requirements
Wireless LANs (WLANs) implemented in accordance with this standard are subject to equipment
certification and operating requirements established by regional and national regulatory administrations. The
PHY specification establishes minimum technical requirements for interoperability, based upon established
regulations at the time this standard was issued. These regulations are subject to revision or may be
superseded. Requirements that are subject to local geographic regulations are annotated within the PHY
specification. Regulatory requirements that do not affect interoperability are not addressed in this standard.
Implementers are referred to the regulatory sources in Annex D for further information. Operation in
countries within defined regulatory domains may be subject to additional or alternative national regulations.
19.3.15 Channel numbering and channelization
19.3.15.1 General
The STA may operate in the 5 GHz band and/or 2.4 GHz band. When using 20 MHz channels, it uses
channels defined in 17.3.8.4 (5 GHz band) or 16.3.6 (2.4 GHz band). When using 40 MHz channels, it can
operate in the channels defined in 19.3.15.2 and 19.3.15.3.
The set of valid operating channel numbers by regulatory domain is defined in Annex E.
19.3.15.2 Channel allocation in the 2.4 GHz Band
Channel center frequencies are defined at every integer multiple of 5 MHz in the 2.4 GHz band. The
relationship between center frequency and channel number is given by Equation (19-87).
Channel center frequency = 2407 + 5 n ch (MHz) (19-87)
where
n ch = 1 2 13
19.3.15.3 Channel allocation in the 5 GHz band
Channel center frequencies are defined at every integer multiple of 5 MHz above 5 GHz. The relationship
between center frequency and channel number is given in Equation (19-88).
Channel center frequency = Channel starting frequency + 5 n ch (MHz) (19-88)
where
n ch = 1 200
Channel starting frequency is defined as dot11ChannelStartingFactor × 500 kHz or is defined as 5.000 GHz
for systems where dot11OperatingClassesRequired is false or not defined. A channel center frequency of
5.000 GHz shall be indicated by dot11ChannelStartingFactor = 8000 and nch = 200.
19.3.15.4 40 MHz channelization
The set of valid operating channel numbers by regulatory domain is defined in Annex E.
2403
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The 40 MHz channels are specified by two fields: (Nprimary_ch, Secondary). The first field represents the
channel number of the primary channel, and the second field indicates whether the secondary channel is
above or below the primary channel (1 indicates above, – 1 indicates below). The secondary channel
number shall be Nprimary_ch + Secondary 4.
For example, a 40 MHz channel consisting of 40 MHz channel number 36 and Secondary 1 specifies the
primary channel is 36 and the secondary channel is 40.
19.3.16 Slot time
The slot time shall follow 17.3.8.6 for 5 GHz bands and 18.5.4 for 2.4 GHz bands.
The slot time for 40 MHz channel spacing shall be the same as that for 20 MHz channel spacing.
19.3.17 Transmit and receive impedance at the antenna connector
The impedance at the transmit and receive antenna connector(s) for each transmit and receive antenna shall
follow 17.3.8.7.
19.3.18 PHY transmit specification
19.3.18.1 Transmit spectrum mask
NOTE 1—In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements
and the mask defined in this subclause, i.e., its emissions can be no higher at any frequency offset than the minimum of
the values specified in the regulatory and default masks.
NOTE 2—The transmit spectral mask figures in this subclause are not drawn to scale.
NOTE 3—For rules regarding TX center frequency leakage levels by VHT STAs, see 21.3.17.4.2.
For the 2.4 GHz band, when transmitting in a 20 MHz channel, the transmitted spectrum shall have a 0 dBr
(dB relative to the maximum spectral density of the signal) bandwidth not exceeding 18 MHz, –20 dBr at 11
MHz frequency offset, –28 dBr at 20 MHz frequency offset, and the maximum of –45 dBr and –53 dBm/
MHz at 30 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall
fall within the spectral mask, as shown in Figure 19-17. The measurements shall be made using a 100 kHz
resolution bandwidth and a 30 kHz video bandwidth.
PSD
0dBr
–20dBr
–28dBr
–45dBr
Freq [MHz]
–30 –20 –11 –9 9 11 20 30
Figure 19-17—Transmit spectral mask for 20 MHz transmission in the 2.4 GHz band
2404
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For the 2.4 GHz band, when transmitting in a 40 MHz channel, the transmitted spectrum shall have a 0 dBr
bandwidth not exceeding 38 MHz, –20 dBr at 21 MHz frequency offset, –28 dBr at 40 MHz offset, and the
maximum of –45 dBr and –56 dBm/MHz at 60 MHz frequency offset and above. The transmitted spectral
density of the transmitted signal shall fall within the spectral mask, as shown in Figure 19-18.
PSD
0dBr
–20dBr
–28dBr
–45dBr
Freq [MHz]
–60 –40 –21 –19 0 19 21 40 60
Figure 19-18—Transmit spectral mask for a 40 MHz channel in the 2.4 GHz band
For the 5 GHz band, when transmitting in a 20 MHz channel, the transmitted spectrum shall have a 0 dBr
(dB relative to the maximum spectral density of the signal) bandwidth not exceeding 18 MHz, –20 dBr at 11
MHz frequency offset, –28 dBr at 20 MHz frequency offset, and the maximum of –40 dBr and –53 dBm/
MHz at 30 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall
fall within the spectral mask, as shown in Figure 19-19. The measurements shall be made using a 100 kHz
resolution bandwidth and a 30 kHz video bandwidth.
PSD
0dBr
–20dBr
–28dBr
–40dBr
Freq [MHz]
–30 –20 –11 –9 9 11 20 30
Figure 19-19—Transmit spectral mask for 20 MHz transmission in the 5 GHz band
For the 5 GHz band, when transmitting in a 40 MHz channel, the transmitted spectrum shall have a 0 dBr
bandwidth not exceeding 38 MHz, –20 dBr at 21 MHz frequency offset, –28 dBr at 40 MHz offset, and the
maximum of –40 dBr and –56 dBm/MHz at 60 MHz frequency offset and above. The transmitted spectral
density of the transmitted signal shall fall within the spectral mask, as shown in Figure 19-20.
2405
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PSD
0dBr
–20dBr
–28dBr
–40dBr
Freq [MHz]
–60 –40 –21 –19 0 19 21 40 60
Figure 19-20—Transmit spectral mask for a 40 MHz channel in the 5 GHz band
Transmission with CH_OFF_20U, CH_OFF_20L, or CH_OFF_40 shall comply with the same mask that is
used for the 40 MHz channel.
19.3.18.2 Spectral flatness
In a 20 MHz channel and in corresponding 20 MHz transmission in a 40 MHz channel, the average energy
of the constellations in each of the subcarriers with indices –16 to –1 and +1 to +16 shall deviate no more
than ± 4 dB from their average energy. The average energy of the constellations in each of the subcarriers
with indices –28 to –17 and +17 to +28 shall deviate no more than +4/–6 dB from the average energy of
subcarriers with indices –16 to –1 and +1 to +16.
In a 40 MHz transmission (excluding PPDUs in MCS 32 format and non-HT duplicate format), the average
energy of the constellations in each of the subcarriers with indices –42 to –2 and +2 to +42 shall deviate no
more than ± 4 dB from their average energy. The average energy of the constellations in each of the
subcarriers with indices –43 to –58 and +43 to +58 shall deviate no more than +4/–6 dB from the average
energy of subcarriers with indices –42 to –2 and +2 to +42.
In MCS 32 format and non-HT duplicate format, the average energy of the constellations in each of
the subcarriers with indices –42 to –33, –31 to –6, +6 to +31, and +33 to +42 shall deviate no more than
± 4 dB from their average energy. The average energy of the constellations in each of the subcarriers with
indices –43 to –58 and +43 to +58 shall deviate no more than +4/–6 dB from the average energy of
subcarriers with indices –42 to –33, –31 to –6, +6 to +31, and +33 to +42.
The tests for the spectral flatness requirements may be performed with spatial mapping Q k = I (see
19.3.11.11.2).
19.3.18.3 Transmit power
The maximum allowable output power is measured in accordance with practices specified by the appropriate
regulatory bodies.
2406
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.3.18.4 Transmit center frequency tolerance
The transmitter center frequency tolerance shall be ± 20 ppm maximum for the 5 GHz band and ± 25 ppm
maximum for the 2.4 GHz band. The different transmit chain center frequencies (LO) and each transmit
chain symbol clock frequency shall all be derived from the same reference oscillator.
19.3.18.5 Packet alignment
If no signal extension is required (see 19.3.2), the receiver shall emit a PHY-CCA.indication(IDLE)
primitive (see 8.3.5.12) at the 4 µs boundary following the reception of the last symbol of the packet. If a
signal extension is required, the receiver shall emit a PHY-CCA.indication(IDLE) primitive a duration of
aSignalExtension after the 4 µs boundary following the reception of the last symbol of the packet. This
situation is illustrated for an HT-greenfield format packet using short GI in Figure 19-21.
If no signal extension is required, the transmitter shall emit a PHY-TXEND.confirm primitive (see 8.3.5.8)
at the 4 µs boundary following the trailing boundary of the last symbol of the packet on the WM. If a signal
extension is required, the transmitter shall emit a PHY-TXEND.confirm primitive (see 8.3.5.8) a duration of
aSignalExtension after the 4 µs boundary following the trailing boundary of the last symbol of the packet on
the WM. This situation is illustrated in Figure 19-21.
8 µs 8 µs 8 µs 4 µs 3.6 µs 3.6 µs 3.6 µs 4 µs aSignalExtension µs
boundary
HT- Data Data Data
HT-GF-STF HT-LTF1 HT-SIG Signal Extension
LTF2 Sym 1 Sym 2 Sym 3
Note that Signal Extension field is only PHY-TXEND.confirm
present in some PPDU formats. See and
19.3.2. PHY-CCA.indication(IDLE)
Figure 19-21—Packet alignment example (HT-greenfield format packet with short GI)
19.3.18.6 Symbol clock frequency tolerance
The symbol clock frequency tolerance shall be ± 20 ppm maximum for 5 GHz bands and ± 25 ppm for
2.4 GHz bands. The transmit center frequency and the symbol clock frequency for all transmit antennas
shall be derived from the same reference oscillator.
19.3.18.7 Modulation accuracy
19.3.18.7.1 Introduction to modulation accuracy tests
Transmit modulation accuracy specifications are described in 19.3.18.7.2 and 19.3.18.7.3. The test method
is described in 19.3.18.7.4.
19.3.18.7.2 Transmit center frequency leakage
For VHT STAs the requirements on transmitter center frequency leakage are defined in 21.3.17.4.2;
otherwise, the requirements are defined in this subclause.
The transmitter center frequency leakage shall follow 17.3.9.7.2 for all transmissions in a 20 MHz channel
width. For transmissions in a 40 MHz channel width, the center frequency leakage shall not exceed –20 dB
relative to overall transmitted power, or, equivalently, 0 dB relative to the average energy of the rest of the
subcarriers. For upper or lower 20 MHz transmissions in a 40 MHz channel, the center frequency leakage
2407
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(center of a 40 MHz channel) shall not exceed –17 dB relative to overall transmitted power, or, equivalently,
0 dB relative to the average energy of the rest of the subcarriers. The transmit center frequency leakage is
specified per antenna.
19.3.18.7.3 Transmitter constellation error
The relative constellation frame-averaged RMS error, calculated first by averaging over subcarriers, OFDM
frames, and spatial streams, shall not exceed a data-rate-dependent value according to Table 19-22. The
number of spatial streams under test shall be equal to the number of utilized transmitting STA antenna
(output) ports and also equal to the number of utilized testing instrumentation input ports. In the test,
N SS = N STS with EQM MCSs shall be used. Each output port of the transmitting STA shall be connected
through a cable to one input port of the testing instrumentation. The same requirement applies both to
20 MHz channels and 40 MHz channels.
Table 19-22—Allowed relative constellation error versus constellation size
and coding rate
Relative constellation error
Modulation Coding rate
(dB)
BPSK 1/2 –5
QPSK 1/2 –10
QPSK 3/4 –13
16-QAM 1/2 –16
16-QAM 3/4 –19
64-QAM 2/3 –22
64-QAM 3/4 –25
64-QAM 5/6 –27
19.3.18.7.4 Transmitter modulation accuracy (EVM) test
The transmit modulation accuracy test shall be performed by instrumentation capable of converting the
transmitted signals into a streams of complex samples at 40 Msample/s or more, with sufficient accuracy in
terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, and analog-to-digital quantization
noise. Each transmit chain is connected directly through a cable to the setup input port. A possible
embodiment of such a setup is converting the signals to a low intermediate frequency with a microwave
synthesizer, sampling the signal with a digital oscilloscope, and decomposing it digitally into quadrature
components. The sampled signal shall be processed in a manner similar to an actual receiver, according to
the following steps, or an equivalent procedure:
a) Detect the start of frame.
b) Detect the transition from short sequences to channel estimation sequences, and establish fine timing
(with one sample resolution).
c) Estimate the coarse and fine frequency offsets.
d) Derotate the frame according to estimated frequency offset.
e) Estimate the complex channel response coefficients for each of the subcarriers and each of the
transmit chains.
2408
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
f) For each of the data OFDM symbols, transform the symbol into subcarrier received values, estimate
the phase from the pilot subcarriers in all spatial streams, derotate the subcarrier values according to
estimated phase, group the results from all of the receiver chains in each subcarrier to a vector,
multiply the vector by a zero-forcing equalization matrix generated from the channel estimated
during the channel estimation phase.
g) For each data-carrying subcarrier in each spatial stream, find the closest constellation point and
compute the Euclidean distance from it.
h) Compute the average of the RMS of all errors in a frame. It is given by Equation (19-89).
N SYM N SS N ST
2 2
I i f i s i ss i sc – I 0 i f i s i ss i sc + Q i f i s i ss i sc – Q 0 i f i s i ss i sc
Nf
i s = 1 i ss = 1 i sc = 1 (19-89)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
N SYM N SS N ST P 0
if = 1
Error RMS = --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Nf
where
Nf is the number of frames for the measurement
I 0 i f i s i ss i sc Q 0 i f i s i ss i sc denotes the ideal symbol point in the complex plane in subcarrier isc,
spatial stream iss, and OFDM symbol is of frame if
I i f i s i ss i sc Q i f i s i ss i sc denotes the observed symbol point in the complex plane in subcarrier isc,
spatial stream iss, and OFDM symbol is of frame if
P0 is the average power of the constellation
The vector error on a phase plane is shown in Figure 17-16.
The test shall be performed over at least 20 frames (Nf), and the average of the RMS shall be taken. The
frames under test shall be at least 16 OFDM symbols long. Random data shall be used for the symbols.
19.3.18.8 Time of Departure accuracy
The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and
aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in
Annex P with the following test parameters:
— MULTICHANNEL_SAMPLING_RATE is:
fH – fL
20 10 6 1 + -------------------
- sample/s, for a CH_BANDWIDTH parameter equal to HT_CBW20
20 MHz
fH – fL
40 10 6 1 + -------------------
- sample/s, for a CH_BANDWIDTH parameter equal to HT_CBW40
40 MHz
where
fH is the nominal center frequency in Hz of the highest channel in the channel set
fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel
set is the set of channels upon which frames providing measurements are transmitted, the
channel set comprises channels uniformly spaced across fH – fL 50 MHz
— FIRST_TRANSITION_FIELD is L-STF (for HT-mixed format) or HT-GF-STF (for HT-greenfield
format)
— SECOND_TRANSITION_FIELD is L-LTF (for HT-mixed format) or HT-GF-LTF1 (for HT-
greenfield format)
2409
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— TRAINING_FIELD is L-LTF (for HT-mixed format) or HT-LTF1 (for HT-greenfield
format) windowed in a manner which should approximate the windowing described in 17.3.2.5 with
TTR = 100 ns.
— TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns (for a CH_BANDWIDTH
parameter equal to HT_CBW20) or 80 ns (for a CH_BANDWIDTH parameter equal to
HT_CBW40).
NOTE—The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or
receiver.
19.3.19 HT PHY receiver specification
19.3.19.1 Receiver minimum input sensitivity
The packet error ratio (PER) shall be less than 10% for a PSDU length of 4096 octets with the rate-
dependent input levels listed in Table 19-23 or less. The minimum input levels are measured at the antenna
connectors and are referenced as the average power per receive antenna. The number of spatial streams
under test shall be equal to the number of utilized transmitting STA antenna (output) ports and also equal to
the number of utilized device under test input ports. Each output port of the transmitting STA shall be
connected through a cable to one input port of the device under test. The test in this subclause and the
minimum sensitivity levels specified in Table 19-23 apply only to non-STBC modes, MCSs 0–31, 800 ns
GI, and BCC.
Table 19-23—Receiver minimum input level sensitivity
Adjacent Nonadjacent Minimum sensitivity Minimum sensitivity
Rate channel channel (20 MHz (40 MHz
Modulation
(R) rejection rejection channel spacing) channel spacing)
(dB) (dB) (dBm) (dBm)
BPSK 1/2 16 32 –82 –79
QPSK 1/2 13 29 –79 –76
QPSK 3/4 11 27 –77 –74
16-QAM 1/2 8 24 –74 –71
16-QAM 3/4 4 20 –70 –67
64-QAM 2/3 0 16 –66 –63
64-QAM 3/4 –1 15 –65 –62
64-QAM 5/6 –2 14 –64 –61
19.3.19.2 Adjacent channel rejection
For all transmissions in a 20 MHz channel width, the adjacent channel rejection shall be measured by setting
the desired signal’s strength 3 dB above the rate-dependent sensitivity specified in Table 19-23 and raising
the power of an interfering signal of 20 MHz bandwidth until 10% PER is caused for a PSDU length of
4096 octets. The difference in power between the signals in the interfering channel and the desired channel
is the corresponding adjacent channel rejection. The adjacent channel center frequencies shall be separated
by 20 MHz when operating in the 5 GHz band, and the adjacent channel center frequencies shall be
separated by 25 MHz when operating in the 2.4 GHz band.
2410
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For all transmissions in a 40 MHz channel width, the adjacent channel rejection shall be measured by setting
the desired signal’s strength 3 dB above the rate-dependent sensitivity specified in Table 19-23 and raising
the power of an interfering signal of 40 MHz bandwidth until 10% PER is caused for a PSDU length of
4096 octets. The difference in power between the signals in the interfering channel and the desired channel
is the corresponding adjacent channel rejection. The adjacent channel center frequencies shall be separated
by 40 MHz.
The interfering signal in the adjacent channel shall be a signal compliant with the HT PHY, unsynchronized
with the signal in the channel under test. The corresponding rejection shall be no less than specified in
Table 19-23. The interference signal shall have a minimum duty cycle of 50%.
The test in this subclause and the adjacent channel rejection levels specified in Table 19-23 apply only to
non-STBC modes, MCSs 0–31, 800 ns GI, and BCC.
19.3.19.3 Nonadjacent channel rejection
For all transmissions in a 20 MHz channel width in the 5 GHz band, the nonadjacent channel rejection shall
be measured by setting the desired signal’s strength 3 dB above the rate-dependent sensitivity specified in
Table 19-23 and raising the power of an interfering signal of 20 MHz bandwidth until a 10% PER occurs for
a PSDU length of 4096 octets. The difference in power between the signals in the interfering channel and the
desired channel is the corresponding nonadjacent channel rejection. The nonadjacent channel center
frequencies shall be separated by 40 MHz or more.
For all transmissions in a 40 MHz channel width in the 5 GHz band, the nonadjacent channel rejection shall
be measured by setting the desired signal’s strength 3 dB above the rate-dependent sensitivity specified in
Table 19-23 and raising the power of an interfering signal of 40 MHz bandwidth until a 10% PER occurs for
a PSDU length of 4096 octets. The difference in power between the signals in the interfering channel and the
desired channel is the corresponding nonadjacent channel rejection. The nonadjacent channel center
frequencies shall be separated by 80 MHz or more.
The interfering signal in the nonadjacent channel shall be a signal compliant with the HT PHY,
unsynchronized with the signal in the channel under test. The corresponding rejection shall be no less than
specified in Table 19-23. The interference signal shall have a minimum duty cycle of 50%. The nonadjacent
channel rejection for transmissions in a 20 MHz or 40 MHz channel width is applicable only to 5 GHz band.
The test in this subclause and the nonadjacent channel rejection level specified in Table 19-23 apply only to
non-STBC modes, MCSs 0–31, 800 ns GI, and BCC.
19.3.19.4 Receiver maximum input level
The receiver shall provide a maximum PER of 10% at a PSDU length of 4096 octets, for a maximum input
level of –30 dBm in the 5 GHz band and –20 dBm in the 2.4 GHz band, measured at each antenna for any
baseband modulation.
19.3.19.5 CCA sensitivity
19.3.19.5.1 CCA-Energy Detect (CCA-ED)
For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall also indicate a medium
busy condition when CCA-ED detects a channel busy condition.
For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED
is given in Table D-2. The operating classes requiring the corresponding CCA-ED behavior class are given
2411
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
in E.1. The PHY of a STA that is operating within an operating class that requires CCA-ED shall operate
with CCA-ED.
CCA-ED shall detect a channel busy condition when the received signal strength exceeds the CCA-ED
threshold as given by dot11OFDMEDThreshold for the primary 20 MHz channel and
dot11OFDMEDThreshold for the secondary 20 MHz channel (if present). The CCA-ED thresholds for the
operating classes requiring CCA-ED are subject to the criteria in D.2.5.
NOTE—The requirement to detect a channel busy condition as stated in 19.3.19.5.2, 19.3.19.5.3, and 19.3.19.5.4 is a
mandatory energy detection requirement on all Clause 19 receivers. Support for CCA-ED is an additional requirement
that relates specifically to the sensitivities described in D.2.5.
19.3.19.5.2 CCA sensitivity for non-HT PPDUs
CCA sensitivity requirements for non-HT PPDUs in the primary channel are described in 17.3.10.6 and
18.4.6.
19.3.19.5.3 CCA sensitivity in 20 MHz
For an HT STA with the operating channel width equal to 20 MHz, the start of a valid 20 MHz HT signal at
a receive level greater than or equal to the minimum modulation and coding rate sensitivity of –82 dBm shall
cause the PHY to set PHY-CCA.indication(BUSY) with a probability > 90% within 4 s. The receiver shall
indicate a channel busy condition for any signal 20 dB or more above the minimum modulation and coding
rate sensitivity (–82 + 20 = –62 dBm) in the 20 MHz channel.
An HT STA that does not support the reception of HT_GF format PPDUs shall indicate a channel busy
condition (PHY-CCA.indication(BUSY)) for any valid HT_GF signal in the 20 MHz channel at a receive
level greater than or equal to –72 dBm.
19.3.19.5.4 CCA sensitivity in 40 MHz
This subclause describes the CCA sensitivity requirements for an HT STA with the operating channel width
equal to 40 MHz.
The receiver of a 20/40 MHz STA with the operating channel width equal to 40 MHz shall provide CCA on
both the primary and secondary channels.
When the secondary channel is idle, the start of a valid 20 MHz HT signal in the primary channel at a
receive level greater than or equal to the minimum modulation and coding rate sensitivity of –82 dBm shall
cause the PHY to generate a PHY-CCA.indication(BUSY, {primary}) primitive with a probability > 90%
within 4 s. The start of a valid 40 MHz HT signal that occupies both the primary and secondary channels at
a receive level greater than or equal to the minimum modulation and coding rate sensitivity of –79 dBm shall
cause the PHY to generate a PHY-CCA.indication(BUSY, {primary, secondary}) primitive for both the
primary and secondary channels with a probability per channel > 90% within 4 s.
An HT STA that does not support the reception of HT_GF format PPDUs shall indicate a {primary} channel
busy condition (PHY-CCA.indication(BUSY, {primary}) primitive) for any valid HT_GF signal in the
primary channel at a receive level greater than or equal to –72 dBm when the secondary channel is idle. An
HT STA that does not support the reception of HT_GF format PPDUs shall indicate a {primary, secondary}
channel busy condition (PHY-CCA.indication(BUSY, {primary, secondary}) primitive) for any valid
40 MHz HT_GF signal in both the primary and secondary channels at a receive level greater than or equal to
–69 dBm.
The receiver shall indicate a {primary} channel busy condition for any signal at or above –62 dBm in the
20 MHz primary channel. This level is 20 dB above the minimum modulation and coding rate sensitivity for
2412
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a 20 MHz PPDU. When the primary channel is idle, the receiver indicate a {secondary} channel busy
condition for any signal at or above –62 dBm in the 20 MHz secondary channel. The receiver shall indicate
a {primary, secondary} channel busy condition for any signal present in both the primary and secondary
channels that is at or above –62 dBm in the primary channel and at or above –62 dBm in the
secondary channel.
19.3.19.6 Received channel power indicator (RCPI) measurement
The RCPI is a measure of the received RF power in the selected channel. This parameter shall be a measure
by the PHY of the received RF power in the channel measured over the data portion of the received frame.
The received power shall be the average of the power in all active receive chains.
The RCPI encoding is defined in 15.4.6.6.
RCPI shall equal the received RF power within an accuracy of ± 5 dB (95% confidence interval) within the
specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel width multiplied by 1.1.
19.3.19.7 Reduced interframe space (RIFS)
The receiver shall be able to decode a packet that was transmitted with a RIFS separation from the previous
packet.
19.3.20 PHY transmit procedure
There are three options for the transmit PHY procedure. The first two options, for which typical transmit
procedures are shown in Figure 19-22 and Figure 19-23, are selected if the FORMAT field of the
PHY-TXSTART.request(TXVECTOR) primitive is equal to HT_MF or HT_GF, respectively. These
transmit procedures do not describe the operation of optional features, such as LDPC or STBC. The third
option is to follow the transmit procedure in Clause 17 or Clause 18 if the FORMAT field is equal to
NON_HT. Additionally, if the FORMAT field is equal to NON_HT, CH_BANDWIDTH indicates
NON_HT_CBW20, and NON_HT_MODULATION indicates OFDM, follow the transmit procedure in
Clause 17. If the FORMAT field is equal to NON_HT, CH_BANDWIDTH indicates NON_HT_CBW20,
and NON_HT_MODULATION indicates other than OFDM, follow the transmit procedure in Clause 18.
And furthermore, if the FORMAT field is equal to NON_HT and CH_BANDWIDTH indicates
NON_HT_CBW40, follow the transmit procedure in Clause 17, except that the signal in Clause 17 is
generated simultaneously on each of the upper and lower 20 MHz channels that constitute the 40 MHz
channel as defined in 19.3.8 and 19.3.11.12. In all these options, in order to transmit data, the PHY-
TXSTART.request primitive shall be enabled so that the PHY entity shall be in the transmit state. Further,
the PHY shall be set to operate at the appropriate frequency through station management via the PLME, as
specified in 19.4. Other transmit parameters, such as MCS coding types and transmit power, are set via the
PHY SAP with the PHY-TXSTART.request(TXVECTOR) primitive, as described in 19.2.2.
A clear channel shall be indicated by issuing a PHY-CCA.indication(IDLE) primitive. Note that under some
circumstances, the MAC uses the latest value of the PHY-CCA.indication primitive before issuing the PHY-
TXSTART.request primitive. Transmission of the PPDU shall be initiated after receiving the
PHY-TXSTART.request(TXVECTOR) primitive. The TXVECTOR elements for the PHY-
TXSTART.request primitive are specified in Table 19-1.
Transmission of the PHY preamble may start if TIME_OF_DEPARTURE_REQUESTED is false, and shall
start immediately if TIME_OF_DEPARTURE_REQUESTED is true, based on the parameters passed in the
PHY-TXSTART.request primitive.
2413
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PHY-TXEND.request
PHY-TXEND.confirm
PHY-TXSTART.confirm
PHY-DATA.request
PHY-DATA.confirm
PHY-TXSTART.request
PHY-DATA.request
PHY-DATA.confirm
(TXSTATUS)
(TXVECTOR)
…………..…………
MAC
MPDU
Tail Bits (if BCC)
L-SIG HT-SIG PSDU Bit Padding
IF needed
Scrambling +
encoding
PHY Non-HT
L-SIG HT-SIG HT-Training Data (Variable number of OFDM symbols)
Signal Extension (if
Preamble present)
Coded Coded
OFDM OFDM Coded OFDM, MCS indicated in HT-SIG
BPSK, QBPSK,
Rate 1/2 Rate 1/2
NOTE—This procedure does
not describe the operation of
optional features, such as LDPC
or STBC
Figure 19-22—PHY transmit procedure (HT-mixed format PPDU)
PHY-TXEND.request
PHY-TXEND.confirm
PHY-TXSTART.confirm
PHY-DATA.request
PHY-DATA.confirm
PHY-TXSTART.request
PHY-DATA.request
PHY-DATA.confirm
(TXSTATUS)
(TXVECTOR)
…………..…………
MAC
MPDU
Tail Bits (if BCC)
HT-SIG PSDU
Bit Padding
IF needed
Scrambling +
encoding
HT-Training Signal Extension
PHY Part I
HT-SIG HT-Training Data (Variable number of OFDM symbols)
(if present)
Coded
OFDM Coded OFDM, MCS indicated in HT-SIG
QBPSK,
Rate 1/2
NOTE—This procedure does
not describe the operation of
optional features, such as LDPC
or STBC.
Figure 19-23—PHY transmit procedure (HT-greenfield format PPDU)
The data shall then be exchanged between the MAC and the PHY through a series of PHY-
DATA.request(DATA) primitives issued by the MAC and PHY-DATA.confirm primitives issued by the
PHY. Once PHY preamble transmission is started, the PHY entity shall immediately initiate data scrambling
and data encoding. The encoding method shall be based on the FEC_CODING, CH_BANDWIDTH, and
2414
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MCS parameter of the TXVECTOR. A modulation rate change, if any, shall be initiated starting with the
SERVICE field data, as described in 19.3.2.
The PHY proceeds with PSDU transmission through a series of data octet transfers from the MAC. The
SERVICE field and PSDU are encoded by the encoder selected by the FEC_CODING, CH_BANDWIDTH,
and MCS parameters of the TXVECTOR as described in 19.3.3. Transmission can be prematurely
terminated by the MAC through the primitive PHY-TXEND.request primitive. PHY-TXSTART shall be
disabled by receiving a PHY-TXEND.request primitive. Normal termination occurs after the transmission of
the final bit of the last PSDU octet, according to the number supplied in the LENGTH field.
The packet transmission shall be completed, and the PHY entity shall enter the receive state (i.e., PHY-
TXSTART shall be disabled). Each PHY-TXEND.request primitive is acknowledged with a PHY-
TXEND.confirm primitive from the PHY. If the length of the coded PSDU is not an integer multiple of the
OFDM symbol length, bits shall be stuffed to make the coded PSDU length an integer multiple of the
OFDM symbol length.
The GI shall be inserted in every OFDM symbol as a countermeasure against delay spread.
In some PPDU formats (as defined in 19.3.2), a signal extension is present. When no signal extension is
present, the PHY-TXEND.confirm primitive is generated at the end of last symbol of the PPDU. When a
signal extension is present, the PHY-TXEND.confirm primitive is generated at the end of the signal
extension.
A typical state machine implementation of the transmit PHY is provided in Figure 19-24. Requests
(.request) and confirmations (.confirm) are issued once per state as shown. This state machine does not
describe the operation of optional features, such as LDPC or STBC.
19.3.21 PHY receive procedure
Typical PHY receive procedures are shown in Figure 19-25 and Figure 19-26. The receive procedures
correspond to HT-mixed format and HT-greenfield format, respectively. A typical state machine
implementation of the receive PHY is given in Figure 19-27. These receive procedures and state machine do
not describe the operation of optional features, such as LDPC or STBC. If the detected format indicates a
non-HT PPDU format, refer to the receive procedure and state machine in Clause 17 or Clause 18. Further,
through station management (via the PLME), the PHY is set to the appropriate frequency, as specified in
19.4. Other receive parameters, such as RSSI and indicated DATARATE, may be accessed via the PHY
SAP.
Upon receiving the transmitted PHY preamble, the PHY measures a receive signal strength. This indicates
activity to the MAC via the PHY-CCA.indication primitive. A PHY-CCA.indication(BUSY, channel-list)
primitive shall also be issued as an initial indication of reception of a signal. The channel-list parameter of
the PHY-CCA.indication primitive is determined as follows:
— It is absent when the operating channel width is 20 MHz.
— It is set to {primary} when the operating channel width is 40 MHz and the signal is present only in
the primary channel.
— It is set to {secondary} when the operating channel width is 40 MHz and the signal is present only in
the secondary channel.
— It is set to {primary, secondary} when the operating channel width is 40 MHz and the signal is
present in both the primary and secondary channels.
The RSSI parameter is reported to the MAC in the RXVECTOR.
2415
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PHY-TXSTART.request
(TXVECTOR) TX PSDU OCTET PHY-DATA.
request(DATA)
Get octet from MAC
and encoding
Initialize PHY-DATA.confirm
Length >1 Length =1
Set TX parameters
FORMAT=HT_MF OR TAIL APPEND
FORMAT=NON_HT
Tails bits are appended
BIT PADDING
FORMAT=HT_GF Tails bits are appended
TX GF HT-Preamble TX L-Preamble TX SYMBOL
Tx HT Training Part I
TX HT-SIG in TX Training Symbols Set symbol bit count
QBPSK rate 1/2 TX L-SIG in BPSK rate 1/2
TX HT Training
Bit Count > 0
PHY-TXSTART.confirm FORMAT=
(TXSTATUS) FORMAT=
HT_MF
NON_HT Decrement Bit
Refer to
Decrement bit count
TX HT-Preamble clause 17 or
18 by bits per symbol
Change Modulation to
QBPSK, Bit Count = 0
TX HT-SIG
TX HT Training
Symbols
Decrement Length
Decrement Length
count Length >0
Length = 0
TX Data Wait TX_END
Change coding rate
and modulation type
TX encoded 16 bit
service field signal extension
Add Signal Extension
no signal
extension Wait for duration of
SETUP MPDU TX signal extension
PHY-DATA.
request(DATA)
PHY-TXSTART.confirm
Set length count
Switch RX state
NOTE—This state machine A
At any stage in the
does not describe the operation above flow diagram, if
A
of optional features, such as a PHY-
TXEND.request is
LDPC or STBC. received.
Figure 19-24—PHY transmit state machine
2416
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
CS/CCA state RX state
PHY-RXSTART.indication
PHY-CCA.indication
PHY-RXEND.indication
(NoError, RXVECTOR)
PHY-DATA.indication
PHY-DATA.indication
PHY-CCA.indication
(STATE=busy)
(RXVECTOR)
(IDLE)
MAC
MPDU Tail Bits
(if BCC used)
Decoding Delay
L-SIG HT-SIG PSDU
Issued at
the same
Measure
Decoded and time
RSSI
Bit removing
descrambled
IF needed
PHY L-STF L-LTF L-SIG HT-SIG HT-Training Data (Variable number of OFDM symbols)
Signal Extension
(if present)
Coded Coded
OFDM OFDM Coded OFDM, MCS indicated in HT-SIG
BPSK, QBPSK,
Rate 1/2 Rate 1/2
NOTE—This procedure does
not describe the operation of
optional features, such as LDPC
or STBC.
Figure 19-25—PHY receive procedure for HT-mixed format PPDU format
CS/CCA state RX state
PHY-RXSTART.indication
PHY-CCA.indication
PHY-RXEND.indication
(NoError, RXVECTOR)
PHY-DATA.indication
PHY-DATA.indication
PHY-CCA.indication
(STATE=busy)
(RXVECTOR)
(IDLE)
MAC
Tail Bits
MPDU (if BCC used )
Measure
HT-SIG PSDU
RSSI
Issued at the
Decoded and same time
Bit removing
descrambled IF needed
PHY HT-Training
Part I
HT-SIG HT-Training Data (Variable number of OFDM symbols )
Signal Extension
(if present )
Coded
OFDM Coded OFDM , MCS indicated in HT -SIG
QBPSK ,
Rate 1/2
NOTE —This procedure does
not describe the operation of
optional features , such as LDPC
or STBC.
Figure 19-26—PHY receive procedure for HT-greenfield format PPDU
2417
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RX IDLE state
CS/CCA
Set PHY-CCA.indication(BUSY)
End of Wait Detect SIG A
RX Symbol
Set PHY-CCA. Determine type of HT_SIG (GF preamble)
indication(IDLE) SIG field
when receive
level drops below L-SIG (MF or non-HT
threshold (missed preamble)
preamble) Carrier lost Valid Signal
Detect L-SIG
Carrier Lost
Receive L-SIG
Set PHY-RXEND field Signal Not Valid Decode Symbol
.indication(CarrierLost)
Signal Valid Set RxEndStatus Decode and
= (CarrierLost, descramble
RX L-SIG Null) symbol
RX and test
Parity
Not HT-SIG:
Refer to 16.2.3 or Decrement Time Decrement Length
Detect HT-SIG 19.3.5 PHY-DATA
Carrier Lost Determine Wait for intended .indication(DATA)
Set PHY-RXEND whether HT-SIG end of PSDU (bit removing if needed) Length
Decrement length count
.indication follows L-SIG >0
(CarrierLost)
HT_SIG Time=0
Length=0
RX HT-SIG
CRC Fail: End of Wait End of PSDU RX
Set PHY-RXEND RX and test CRC
.indication Set RxEndStatus =
Check for Signal (NoError,RXVECTOR)
(FormatViolation)
Extension Check for Signal
CRC OK Extension
End of Wait Check Preamble
Unsupported Type no signal signal signal no signal
Set PHY-CCA Preamble: extension extension
Check for HT_GF extension extension
.indication(IDLE) Set PHY-
when receive RXSTART.indica or HT_MF
tion preamble type
level drops below Signal Extension
(RXVECTOR)
threshold then set PHY-
(minimum RXEND Supported Preamble CS/CCA
Wait for duration of
modulation and .indication(Form
atViolation) Evaluate HT-SIG A detected. Set
PHY-RXEND signal extension
coding rate .indication
sensitivity + 10 Check contents in (RxEndStatus)
dB) HT-SIG for
Unsupported mode: supported mode
Set PHY-RXSTART Supported
.indication End of Wait
mode
(RXVECTOR)
then set Set PHY-CCA
Setup PSDU RX
PHY-RXEND .indication(IDLE). Set
.indication(Unsuppor Set Length PHY-RXEND
tedRate) Set PHY-RXSTART .indication
.indication (RxEndStatus)
(RXVECTOR)
End of Wait
For Reserved HT-SIG
For unsupported Indication: set PHY-CCA
modes: set PHY-CCA .indication(IDLE) when
.indication(IDLE) receive level drops
when predicted below threshold
duration based on (minimum modulation
and coding rate
NOTE—This state machine does not describe the operation
TXTIME has elapsed
sensitivity + 20 dB) of optional features, such as LDPC or STBC.
Figure 19-27—PHY receive state machine
2418
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
After the PHY-CCA.indication(BUSY, channel-list) primitive is issued, the PHY entity shall begin receiving
the training symbols and searching for SIGNAL and HT-SIG in order to set the length of the data stream, the
demodulation type, code type, and the decoding rate. If signal loss occurs before validating L-SIG and/or
HT-SIG, the HT PHY shall not generate a PHY-CCA.indication(IDLE) primitive until the received level
drops below the CCA sensitivity level (for a missed preamble) specified in 19.3.19.5. If the check of the HT-
SIG CRC is not valid, a PHY-RXSTART.indication primitive is not issued. The PHY shall indicate the error
condition by issuing a PHY-RXEND.indication(FormatViolation) primitive. The HT PHY shall not generate
a PHY-CCA.indication(IDLE) primitive until the received level drops below the CCA sensitivity level (for a
missed preamble) specified in 19.3.19.5.
If the PHY preamble reception is successful and a valid HT-SIG CRC is indicated:
— Upon reception of an HT-mixed format preamble, the HT PHY shall not generate a PHY-
CCA.indication(IDLE) primitive for the predicted duration of the transmitted frame, as defined by
TXTIME in 19.4.3, for all supported and unsupported modes except Reserved HT-SIG Indication.
Reserved HT-SIG Indication is defined in the fourth list item below.
— Upon reception of a GF preamble by an HT STA that does not support GF, the HT PHY shall not
generate a PHY-CCA.indication(IDLE) primitive until either the predicted duration of the packet
from the contents of the HT-SIG field, as defined by TXTIME in 19.4.3, except Reserved HT-SIG
Indication, elapses or until the received level drops below the receiver minimum sensitivity level of
BPSK, R=1/2 in Table 19-23 + 10 dB (–72 dBm for 20 MHz, –69 dBm for 40 MHz). Reserved HT-
SIG Indication is defined in the fourth list item below.
— Upon reception of a GF preamble by an HT STA that supports GF, the HT PHY shall not generate a
PHY-CCA.indication(IDLE) primitive for the predicted duration of the transmitted frame, as
defined by TXTIME in 19.4.3, for all supported and unsupported modes except Reserved HT-SIG
Indication. Reserved HT-SIG Indication is defined in the fourth list item below.
— If the HT-SIG indicates a Reserved HT-SIG Indication, the HT PHY shall not generate a PHY-
CCA.indication(IDLE) primitive until the received level drops below the CCA sensitivity level
(minimum modulation and coding rate sensitivity + 20 dB) specified in 19.3.19.5. Reserved HT-SIG
Indication is defined as an HT-SIG with MCS field in the range 77–127 or Reserved field = 0 or
STBC field = 3 and any other HT-SIG field bit combinations that do not correspond to modes of
PHY operation defined in Clause 19.
Subsequent to an indication of a valid HT-SIG CRC, a PHY-RXSTART.indication(RXVECTOR) primitive
shall be issued. If dot11TimingMsmtActivated is true, the PHY shall do the following:
— Complete receiving the PHY header and verify the validity of the PHY Header.
— If the PHY header reception is successful (and the SIGNAL field is completely recognizable and
supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued
and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded
(see 19.2.2).
NOTE—The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the start
of the preamble for the incoming frame was detected on the medium at the receive antenna connector.
The RXVECTOR associated with this primitive includes the parameters specified in Table 19-1. Upon
reception of a GF preamble by an HT STA that does not support GF, the FORMAT field of RXVECTOR is
equal to HT_GF, the remaining fields may be empty, and the PHY shall indicate the error condition by
issuing a PHY-RXEND.indication(FormatViolation) primitive. If the HT-SIG indicates an unsupported
mode or Reserved HT-SIG Indication, the PHY shall indicate the error condition by issuing a PHY-
RXEND.indication(UnsupportedRate) primitive.
Following training and SIGNAL fields, the coded PSDU (which comprises the coded PHY SERVICE field
and scrambled and coded PSDU) shall be received. If signal loss occurs during reception prior to completion
of the PSDU reception, the error condition shall be reported to the MAC using a
2419
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PHY-RXEND.indication(CarrierLost) primitive. After waiting for the intended end of the PSDU, if no
signal extension is present (as defined in 19.3.2), the PHY shall generate a PHY-CCA.indication(IDLE)
primitive and return to RX IDLE state. Otherwise, the receiver waits for the duration of the signal extension
before returning to the RX IDLE state.
The received PSDU bits are assembled into octets, decoded, and presented to the MAC using a series of
PHY-DATA.indication(DATA) primitive exchanges. The number of PSDU octets is indicated in the HT
Length field of the HT-SIG. The PHY shall proceed with PSDU reception. After the reception of the final bit
of the last PSDU octet and possible tail and padding bits, the receiver shall be returned to the RX IDLE state
if no signal extension is present (as defined in 19.3.2), as shown in Figure 19-27. Otherwise, the receiver
waits for the duration of the signal extension before returning to the RX IDLE state. A PHY-
RXEND.indication(NoError) primitive shall be issued on entry to the RX IDLE state.
While in the Signal Extension state, if the receiver detects a CS/CCA event, it issues an RXEND.indication
primitive (with the RXERROR parameter set to NoError or CarrierLost, depending on whether a carrier lost
event occurred during the reception of the PPDU), leaves the Signal Extension state, and enters the Detect
SIG state. This sequence occurs when signal-extended PPDUs are transmitted while separated by a RIFS.
If the binary convolutional code is used, any data received after the indicated data length are considered pad
bits (to fill out an OFDM symbol) and should be discarded.
19.4 HT PLME
19.4.1 PLME SAP sublayer management primitives
Table 19-24 lists the MIB attributes that may be accessed by the PHY entities and the intralayer of higher
level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME-
CHARACTERISTICS primitives defined in 6.2 and 6.5.4.
19.4.2 PHY MIB
HT PHY MIB attributes are defined in Annex C with specific values defined in Table 19-24. The
“Operational semantics” column in Table 19-24 contains two types: static and dynamic.
— Static MIB attributes are fixed and cannot be modified for a given PHY implementation.
— Dynamic MIB attributes are interpreted according to the MAX-ACCESS field of the MIB attribute.
When MAX-ACCESS is equal to read-only, the MIB attribute value may be updated by the PLME
and read from the MIB attribute by management entities. When MAX-ACCESS is equal to read-
write, the MIB attribute may be read and written by management entities.
Table 19-24—HT PHY MIB attributes
Default Operational
Managed object
value/range semantics
dot11PHYOperationTable
dot11PHYType HT (X'07') Static
dot11CurrentRegDomain Implementation dependent Dynamic
2420
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-24—HT PHY MIB attributes (continued)
Default Operational
Managed object
value/range semantics
dot11PHYAntennaTable
dot11CurrentTxAntenna Implementation dependent Dynamic
dot11DiversitySupportImplemented Implementation dependent Static
dot11CurrentRxAntenna Implementation dependent Dynamic
dot11AntennaSelectionOptionImplemented false/Boolean Static
dot11TransmitExplicitCSIFeedbackASOptionImplemented false/Boolean Static
dot11TransmitIndicesFeedbackASOptionImplemented false/Boolean Static
dot11ExplicitCSIFeedbackASOptionImplemented false/Boolean Static
dot11TransmitIndicesComputationASOptionImplemented false/Boolean Static
dot11ReceiveAntennaSelectionOptionImplemented false/Boolean Static
dot11TransmitSoundingPPDUOptionImplemented false/Boolean Static
dot11PHYTxPowerTable
dot11NumberSupportedPowerLevelsImplemented Implementation dependent Static
dot11TxPowerLevel1 Implementation dependent Static
dot11TxPowerLevel2 Implementation dependent Static
dot11TxPowerLevel3 Implementation dependent Static
dot11TxPowerLevel4 Implementation dependent Static
dot11TxPowerLevel5 Implementation dependent Static
dot11TxPowerLevel6 Implementation dependent Static
dot11TxPowerLevel7 Implementation dependent Static
dot11TxPowerLevel8 Implementation dependent Static
dot11CurrentTxPowerLevel Implementation dependent Dynamic
dot11PhyDSSSTable
dot11CurrentChannel Implementation dependent Dynamic
dot11RegDomainsSupportedTable
dot11RegDomainsImplementedValue Implementation dependent Static
dot11FrequencyBandsSupported Implementation dependent Static
dot11PHYAntennasListTable
dot11SupportedTxAntenna Implementation dependent Dynamic
dot11SupportedRxAntenna Implementation dependent Static
dot11DiversitySelectionRx Implementation dependent Dynamic
2421
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-24—HT PHY MIB attributes (continued)
Default Operational
Managed object
value/range semantics
dot11SupportedDataRatesTxTable
dot11SupportedDataratesTxValue X'02' = 1 Mb/s (2.4) Static
X'04' = 2 Mb/s (2.4)
X'0B' = 5.5 Mb/s (2.4)
X'16' = 11 Mb/s (2.4)
X'0C' = 6 Mb/s
X'12' = 9 Mb/s
X'18' = 12 Mb/s
X'24' = 18 Mb/s
X'30' = 24 Mb/s
X'48' = 36 Mb/s
X'60' = 48 Mb/s
X'6C' = 54 Mb/s
dot11SupportedDataRatesRxTable
dot11SupportedDataRatesRxTable X'02' = 1 Mb/s (2.4) Static
X'04' = 2 Mb/s (2.4)
X'0B' = 5.5 Mb/s (2.4)
X'16' = 11 Mb/s (2.4)
X'0C' = 6 Mb/s
X'12' = 9 Mb/s
X'18' = 12 Mb/s
X'24' = 18 Mb/s
X'30' = 24 Mb/s
X'48' = 36 Mb/s
X'60' = 48 Mb/s
X'6C' = 54 Mb/s
dot11HRDSSSPHYTable
dot11ShortPreambleOptionImplemented true Static
dot11PHYOFDMTable
dot11CurrentFrequency Implementation dependent Dynamic
dot11TIThreshold Implementation dependent Dynamic
dot11ChannelStartingFactor Implementation dependent Dynamic
dot11PHYERPTable
dot11ShortSlotTimeOptionImplemented Implementation dependent Static
dot11ShortSlotTimeOptionActivated Implementation dependent Dynamic
2422
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-24—HT PHY MIB attributes (continued)
Default Operational
Managed object
value/range semantics
dot11PHYHTTable
dot11FortyMHzOperationImplemented false/Boolean Static
dot11FortyMHzOperationActivated false/Boolean Dynamic
dot11CurrentPrimaryChannel Implementation dependent Dynamic
dot11CurrentSecondaryChannel Implementation dependent Dynamic
dot11NumberOfSpatialStreamsImplemented Implementation dependent Static
dot11NumberOfSpatialStreamsActivated Implementation dependent Dynamic
dot11HTGreenfieldOptionImplemented false/Boolean Static
dot11HTGreenfieldOptionActivated false/Boolean Dynamic
dot11ShortGIOptionInTwentyImplemented false/Boolean Static
dot11ShortGIOptionInTwentyActivated false/Boolean Dynamic
dot11ShortGIOptionInFortyImplemented false/Boolean Static
dot11ShortGIOptionInFortyActivated false/Boolean Dynamic
dot11LDPCCodingOptionImplemented false/Boolean Static
dot11LDPCCodingOptionActivated false/Boolean Dynamic
dot11TxSTBCOptionImplemented false/Boolean Static
dot11TxSTBCOptionActivated false/Boolean Dynamic
dot11RxSTBCOptionImplemented false/Boolean Static
dot11RxSTBCOptionActivated false/Boolean Dynamic
dot11BeamFormingOptionImplemented false/Boolean Static
dot11BeamFormingOptionActivated false/Boolean Dynamic
dot11SupportedMCSTxTable
dot11SupportedMCSTxValue MCS 0–76 for 20 MHz; Static
MCS 0–76 for 40 MHz
(MCS 0–7 for 20 MHz
mandatory at non-AP STA;
MCS 0–15 for 20 MHz
mandatory at AP)
dot11SupportedMCSRxTable
dot11SupportedMCSRxValue MCS 0–76 for 20 MHz; Static
MCS 0–76 for 40 MHz
(MCS 0–7 for 20 MHz
mandatory at non-AP STA;
MCS 0–15 for 20 MHz
mandatory at AP)
2423
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-24—HT PHY MIB attributes (continued)
Default Operational
Managed object
value/range semantics
dot11TransmitBeamformingConfigTable
dot11ReceiveStaggerSoundingOptionImplemented false/Boolean Static
dot11TransmitStaggerSoundingOptionImplemented false/Boolean Static
dot11ReceiveNDPOptionImplemented false/Boolean Static
dot11TransmitNDPOptionImplemented false/Boolean Static
dot11ImplicitTransmitBeamformingOptionImplemented false/Boolean Static
dot11CalibrationOptionImplemented Implementation dependent Static
dot11ExplicitCSITransmitBeamformingOptionImplemented false/Boolean Static
dot11ExplicitNonCompressedBeamformingMatrixOption- false/Boolean Static
Implemented
dot11ExplicitTransmitBeamformingCSIFeedbackOption- Implementation dependent Static
Implemented
dot11ExplicitNoncompressedBeamformingFeedbackOption- Implementation dependent Static
Implemented
dot11ExplicitCompressedBeamformingFeedbackOption- Implementation dependent Static
Implemented
dot11NumberBeamFormingCSISupportAntenna Implementation dependent Static
dot11NumberNonCompressedBeamformingMatrixSupport- Implementation dependent Static
Antenna
dot11NumberCompressedBeamformingMatrixSupportAntenna Implementation dependent Static
dot11TxMCSSetDefined false/Boolean Static
dot11TxRxMCSSetNotEqual false/Boolean Static
dot11TxMaximumNumberSpatialStreamsSupported false/Boolean Static
dot11TxUnequalModulationSupported false/Boolean Static
19.4.3 TXTIME calculation
The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive or calculated for
the PHY receive procedure shall be calculated for HT-mixed format according to the Equation (19-90) and
Equation (19-91) for short and long GI, respectively, and for HT-greenfield format according to
Equation (19-92) and Equation (19-93) for short and long, respectively:
TXTIME = T LEG_PREAMBLE + T L_SIG + T HT_PREAMBLE + T HT_SIG (19-90)
T SYMS N SYM
+ T SYM -------------------------------- + SignalExtension
T SYM
2424
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TXTIME = T LEG_PREAMBLE + T L_SIG + T HT_PREAMBLE + T HT_SIG
(19-91)
+ T SYM N SYM + SignalExtension
TXTIME = T GF_HT_PREAMBLE + T HT_SIG + T SYMS N SYM + SignalExtension (19-92)
TXTIME = T GF_HT_PREAMBLE + T HT_SIG + T SYM N SYM + SignalExtension (19-93)
where
T LEG_PREAMBLE = T L-STF + T L-LTF is the duration of the non-HT preamble
THT_PREAMBLE is the duration of the HT preamble in HT-mixed format, given by
T HT – STF + T HT – LTF 1 + N HT - LTF – 1 T HT – LTFs
TGF_HT_PREAMBLE is the duration of the preamble in HT-greenfield format, given by
T HT – GF – STF + T HT – LTF 1 + N HT - LTF – 1 T HT – LTFs
TSYM, TSYMS, THT-SIG, TL-STF, THT-STF, THT-GF-STF, TL-LTF, THT-LTF1 and THT-LTFs
are defined in Table 19-6
SignalExtension is 0 µs when TXVECTOR parameter NO_SIG_EXTN is true and is aSignalExtension
as defined in Table 19-25 when TXVECTOR parameter NO_SIG_EXTN is false
NHT-LTF is defined in Equation (19-22)
NSYM is defined in Equation (19-32) for BCC and Equation (19-41) for LDPC
For non-HT modes of operation, refer to Clause 17 and Clause 18 for TXTIME calculations, except that
frames transmitted with a value of NON_HT_DUP_OFDM for the TXVECTOR parameter
NON_HT_MODULATION shall use Equation (18-1) for TXTIME calculation.
19.4.4 HT PHY
The static HT PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive,
shall be as shown in Table 19-25. The definitions for these characteristics are given in 6.5.4
Table 19-25—HT PHY characteristics
Characteristics Value
aRIFSTime 2 µs
aSlotTime When operating in the 2.4 GHz band:
If dot11OperatingClassesRequired is false, long = 20 µs
If dot11OperatingClassesRequired is true, long = 20 µs plus
any coverage-class-dependent aAirPropagationTime (see
Table 9-79)
If dot11OperatingClassesRequired is false, short = 9 µs
If dot11OperatingClassesRequired is true, short = 9 µs plus any
coverage-class-dependent aAirPropagationTime (see Table 9-
79)
When operating in the 5 GHz band:
If dot11OperatingClassesRequired is false, 9 µs
If dot11OperatingClassesRequired is true, 9 µs plus any
coverage-class-dependent aAirPropagationTime (see Table 9-
79)
2425
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-25—HT PHY characteristics (continued)
Characteristics Value
aSIFSTime 10 µs when operating in the 2.4 GHz band
16 µs when operating in the 5 GHz bands
aSignalExtension 0 µs when operating in the 5 GHz band
6 µs when operating in the 2.4 GHz band
aCCATime Implementation dependent, see 10.3.7.
aRxPHYStartDelay 28 µs for HT-mixed format,
24 µs for HT-greenfield format
aRxTxTurnaroundTime Implementation dependent, see 10.3.7.
aTxPHYDelay Implementation dependent, see 10.3.7.
aRxPHYDelay Implementation dependent, see 10.3.7.
aRxTxSwitchTime Implementation dependent, see 10.3.7.
aTxRampOnTime Implementation dependent, see 10.3.7.
aAirPropagationTime As indicated by the coverage class (see 10.21.5).
aMACProcessingDelay Implementation dependent, see 10.3.7.
aPreambleLength 16 µs
aSTFOneLength 8 µs
aSTFTwoLength 4 µs
aLTFOneLength 8 µs
aLTFTwoLength 4 µs
aPHYHeaderLength 4 µs for HT-mixed format,
N/A for HT-greenfield format
aPHYSigTwoLength 8 µs
aPHYServiceLength 16 bits
aPHYConvolutionalTailLen 6 bits
gth
aPSDUMaxLength 65 535 octets
aPPDUMaxTime 10 ms
aIUStime 8 µs
aDTT2UTTTime 32 µs
aCWmin 15
aCWmax 1023
aMaxCSIMatricesReportDel 250 ms
ay
For non-HT modes of operation, refer to Clause 17 and Clause 18 for PHY characteristics.
2426
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
19.5 Parameters for HT MCSs
Table 19-26 defines the symbols used in the rate-dependent parameter tables.
Table 19-26—Symbols used in MCS parameter tables
Symbol Explanation
NSS Number of spatial streams
R Coding rate
NBPSC Number of coded bits per single carrier (total across spatial streams)
NBPSCS(iSS) Number of coded bits per single carrier for each spatial stream, iSS = 1,...,NSS
NSD Number of complex data numbers per spatial stream per OFDM symbol
NSP Number of pilot values per OFDM symbol
NCBPS Number of coded bits per OFDM symbol
NDBPS Number of data bits per OFDM symbol
NES Number of BCC encoders for the DATA field
NTBPS Total bits per subcarrier
In the MCS parameter tables that follow, data rates for a 400 ns GI are rounded to 1 decimal place.
The rate-dependent parameters for mandatory 20 MHz, NSS = 1 MCSs with NES = 1 shall be as shown in
Table 19-27.
Table 19-27—MCS parameters for mandatory 20 MHz, NSS = 1, NES = 1
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS
Index 400 ns GI
800 ns GI
(see NOTE)
0 BPSK 1/2 1 52 4 52 26 6.5 7.2
1 QPSK 1/2 2 52 4 104 52 13.0 14.4
2 QPSK 3/4 2 52 4 104 78 19.5 21.7
3 16-QAM 1/2 4 52 4 208 104 26.0 28.9
4 16-QAM 3/4 4 52 4 208 156 39.0 43.3
5 64-QAM 2/3 6 52 4 312 208 52.0 57.8
6 64-QAM 3/4 6 52 4 312 234 58.5 65.0
7 64-QAM 5/6 6 52 4 312 260 65.0 72.2
NOTE—Support of 400 ns GI is optional on transmit and receive.
2427
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The rate-dependent parameters for optional 20 MHz, NSS = 2 MCSs with NES = 1 and EQM of the spatial
streams shall be as shown in Table 19-28.
Table 19-28—MCS parameters for optional 20 MHz, NSS = 2, NES = 1, EQM
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS
Index
800 ns GI 400 ns GI
8 BPSK 1/2 1 52 4 104 52 13.0 14.4
9 QPSK 1/2 2 52 4 208 104 26.0 28.9
10 QPSK 3/4 2 52 4 208 156 39.0 43.3
11 16-QAM 1/2 4 52 4 416 208 52.0 57.8
12 16-QAM 3/4 4 52 4 416 312 78.0 86.7
13 64-QAM 2/3 6 52 4 624 416 104.0 115.6
14 64-QAM 3/4 6 52 4 624 468 117.0 130.0
15 64-QAM 5/6 6 52 4 624 520 130.0 144.4
The rate-dependent parameters for optional 20 MHz, NSS = 3 MCSs with NES = 1 and EQM of the spatial
streams shall be as shown in Table 19-29.
Table 19-29—MCS parameters for optional 20 MHz, NSS = 3, NES = 1, EQM
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS
Index
800 ns GI 400 ns GI
16 BPSK 1/2 1 52 4 156 78 19.5 21.7
17 QPSK 1/2 2 52 4 312 156 39.0 43.3
18 QPSK 3/4 2 52 4 312 234 58.5 65.0
19 16-QAM 1/2 4 52 4 624 312 78.0 86.7
20 16-QAM 3/4 4 52 4 624 468 117.0 130.0
21 64-QAM 2/3 6 52 4 936 624 156.0 173.3
22 64-QAM 3/4 6 52 4 936 702 175.5 195.0
23 64-QAM 5/6 6 52 4 936 780 195.0 216.7
2428
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The rate-dependent parameters for optional 20 MHz, NSS = 4 MCSs with NES = 1 and EQM of the spatial
streams shall be as shown in Table 19-30.
Table 19-30—MCS parameters for optional 20 MHz, NSS = 4, NES = 1, EQM
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS
Index
800 ns GI 400 ns GI
24 BPSK 1/2 1 52 4 208 104 26.0 28.9
25 QPSK 1/2 2 52 4 416 208 52.0 57.8
26 QPSK 3/4 2 52 4 416 312 78.0 86.7
27 16-QAM 1/2 4 52 4 832 416 104.0 115.6
28 16-QAM 3/4 4 52 4 832 624 156.0 173.3
29 64-QAM 2/3 6 52 4 1248 832 208.0 231.1
30 64-QAM 3/4 6 52 4 1248 936 234.0 260.0
31 64-QAM 5/6 6 52 4 1248 1040 260.0 288.9
The rate-dependent parameters for optional 40 MHz, NSS = 1 MCSs with NES = 1 shall be as shown in
Table 19-31.
Table 19-31—MCS parameters for optional 40 MHz, NSS = 1, NES = 1
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS
Index
800 ns GI 400 ns GI
0 BPSK 1/2 1 108 6 108 54 13.5 15.0
1 QPSK 1/2 2 108 6 216 108 27.0 30.0
2 QPSK 3/4 2 108 6 216 162 40.5 45.0
3 16-QAM 1/2 4 108 6 432 216 54.0 60.0
4 16-QAM 3/4 4 108 6 432 324 81.0 90.0
5 64-QAM 2/3 6 108 6 648 432 108.0 120.0
6 64-QAM 3/4 6 108 6 648 486 121.5 135.0
7 64-QAM 5/6 6 108 6 648 540 135.0 150.0
2429
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The rate-dependent parameters for optional 40 MHz, NSS = 2 MCSs with NES = 1 and EQM of the spatial
streams shall be as shown in Table 19-32.
Table 19-32—MCS parameters for optional 40 MHz, NSS = 2, NES = 1, EQM
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS
Index
800 ns GI 400 ns GI
8 BPSK 1/2 1 108 6 216 108 27.0 30.0
9 QPSK 1/2 2 108 6 432 216 54.0 60.0
10 QPSK 3/4 2 108 6 432 324 81.0 90.0
11 16-QAM 1/2 4 108 6 864 432 108.0 120.0
12 16-QAM 3/4 4 108 6 864 648 162.0 180.0
13 64-QAM 2/3 6 108 6 1296 864 216.0 240.0
14 64-QAM 3/4 6 108 6 1296 972 243.0 270.0
15 64-QAM 5/6 6 108 6 1296 1080 270.0 300.0
The rate-dependent parameters for optional 40 MHz, NSS = 3 MCSs, with EQM of the spatial streams shall
be as shown in Table 19-33.
Table 19-33—MCS parameters for optional 40 MHz, NSS = 3, EQM
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS NES
Index
800 ns GI 400 ns GI
16 BPSK 1/2 1 108 6 324 162 1 40.5 45.0
17 QPSK 1/2 2 108 6 648 324 1 81.0 90.0
18 QPSK 3/4 2 108 6 648 486 1 121.5 135.0
19 16-QAM 1/2 4 108 6 1296 648 1 162.0 180.0
20 16-QAM 3/4 4 108 6 1296 972 1 243.0 270.0
21 64-QAM 2/3 6 108 6 1944 1296 2 324.0 360.0
22 64-QAM 3/4 6 108 6 1944 1458 2 364.5 405.0
23 64-QAM 5/6 6 108 6 1944 1620 2 405.0 450.0
2430
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The rate-dependent parameters for optional 40 MHz, NSS = 4 MCSs, with EQM of the spatial streams shall
be as shown in Table 19-34.
Table 19-34—MCS parameters for optional 40 MHz, NSS = 4, EQM
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS NES
Index
800 ns GI 400 ns GI
24 BPSK 1/2 1 108 6 432 216 1 54.0 60.0
25 QPSK 1/2 2 108 6 864 432 1 108.0 120.0
26 QPSK 3/4 2 108 6 864 648 1 162.0 180.0
27 16-QAM 1/2 4 108 6 1728 864 1 216.0 240.0
28 16-QAM 3/4 4 108 6 1728 1296 2 324.0 360.0
29 64-QAM 2/3 6 108 6 2592 1728 2 432.0 480.0
30 64-QAM 3/4 6 108 6 2592 1944 2 486.0 540.0
31 64-QAM 5/6 6 108 6 2592 2160 2 540.0 600.0
The rate-dependent parameters for optional 40 MHz MCS 32 format with NSS = 1 and NES = 1 shall be as
shown in Table 19-35.
Table 19-35—MCS parameters for optional 40 MHz MCS 32 format, NSS = 1, NES = 1
Data rate (Mb/s)
MCS
Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS
Index
800 ns GI 400 ns GI
32 BPSK 1/2 1 48 4 48 24 6.0 6.7
The rate-dependent parameters for optional 20 MHz, NSS = 2 MCSs with NES = 1 and UEQM of the spatial
streams shall be as shown in Table 19-36.
Table 19-36—MCS parameters for optional 20 MHz, NSS = 2, NES = 1, UEQM
Modulation Data rate (Mb/s)
MCS Index R NBPSC NSD NSP NCBPS NDBPS
Stream 1 Stream 2 800 ns GI 400 ns GI
33 16-QAM QPSK 1/2 6 52 4 312 156 39 43.3
34 64-QAM QPSK 1/2 8 52 4 416 208 52 57.8
35 64-QAM 16-QAM 1/2 10 52 4 520 260 65 72.2
36 16-QAM QPSK 3/4 6 52 4 312 234 58.5 65.0
37 64-QAM QPSK 3/4 8 52 4 416 312 78 86.7
38 64-QAM 16-QAM 3/4 10 52 4 520 390 97.5 108.3
2431
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The rate-dependent parameters for optional 20 MHz, NSS = 3 MCSs with NES = 1 and UEQM of the spatial
streams shall be as shown in Table 19-37.
Table 19-37—MCS parameters for optional 20 MHz, NSS = 3, NES = 1, UEQM
Modulation Data rate (Mb/s)
MCS
R NBPSC NSD NSP NCBPS NDBPS
Index 800 ns 400 ns
Stream 1 Stream 2 Stream 3
GI GI
39 16-QAM QPSK QPSK 1/2 8 52 4 416 208 52 57.8
40 16-QAM 16-QAM QPSK 1/2 10 52 4 520 260 65 72.2
41 64-QAM QPSK QPSK 1/2 10 52 4 520 260 65 72.2
42 64-QAM 16-QAM QPSK 1/2 12 52 4 624 312 78 86.7
43 64-QAM 16-QAM 16-QAM 1/2 14 52 4 728 364 91 101.1
44 64-QAM 64-QAM QPSK 1/2 14 52 4 728 364 91 101.1
45 64-QAM 64-QAM 16-QAM 1/2 16 52 4 832 416 104 115.6
46 16-QAM QPSK QPSK 3/4 8 52 4 416 312 78 86.7
47 16-QAM 16-QAM QPSK 3/4 10 52 4 520 390 97.5 108.3
48 64-QAM QPSK QPSK 3/4 10 52 4 520 390 97.5 108.3
49 64-QAM 16-QAM QPSK 3/4 12 52 4 624 468 117 130.0
50 64-QAM 16-QAM 16-QAM 3/4 14 52 4 728 546 136.5 151.7
51 64-QAM 64-QAM QPSK 3/4 14 52 4 728 546 136.5 151.7
52 64-QAM 64-QAM 16-QAM 3/4 16 52 4 832 624 156 173.3
The rate-dependent parameters for optional 20 MHz, NSS = 4 MCSs with NES = 1 and UEQM in the spatial
streams shall be as shown in Table 19-38.
Table 19-38—MCS parameters for optional 20 MHz, NSS = 4, NES = 1, UEQM
Data rate
Modulation
(Mb/s)
MCS
R NBPSC NSD NSP NCBPS NDBPS
Index
800 ns 400 ns
Stream 1 Stream 2 Stream 3 Stream 4
GI GI
53 16-QAM QPSK QPSK QPSK 1/2 10 52 4 520 260 65 72.2
54 16-QAM 16-QAM QPSK QPSK 1/2 12 52 4 624 312 78 86.7
55 16-QAM 16-QAM 16-QAM QPSK 1/2 14 52 4 728 364 91 101.1
56 64-QAM QPSK QPSK QPSK 1/2 12 52 4 624 312 78 86.7
57 64-QAM 16-QAM QPSK QPSK 1/2 14 52 4 728 364 91 101.1
58 64-QAM 16-QAM 16-QAM QPSK 1/2 16 52 4 832 416 104 115.6
59 64-QAM 16-QAM 16-QAM 16-QAM 1/2 18 52 4 936 468 117 130.0
2432
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-38—MCS parameters for optional 20 MHz, NSS = 4, NES = 1, UEQM (continued)
Data rate
Modulation
(Mb/s)
MCS
R NBPSC NSD NSP NCBPS NDBPS
Index
800 ns 400 ns
Stream 1 Stream 2 Stream 3 Stream 4
GI GI
60 64-QAM 64-QAM QPSK QPSK 1/2 16 52 4 832 416 104 115.6
61 64-QAM 64-QAM 16-QAM QPSK 1/2 18 52 4 936 468 117 130.0
62 64-QAM 64-QAM 16-QAM 16-QAM 1/2 20 52 4 1040 520 130 144.4
63 64-QAM 64-QAM 64-QAM QPSK 1/2 20 52 4 1040 520 130 144.4
64 64-QAM 64-QAM 64-QAM 16-QAM 1/2 22 52 4 1144 572 143 158.9
65 16-QAM QPSK QPSK QPSK 3/4 10 52 4 520 390 97.5 108.3
66 16-QAM 16-QAM QPSK QPSK 3/4 12 52 4 624 468 117 130.0
67 16-QAM 16-QAM 16-QAM QPSK 3/4 14 52 4 728 546 136.5 151.7
68 64-QAM QPSK QPSK QPSK 3/4 12 52 4 624 468 117 130.0
69 64-QAM 16-QAM QPSK QPSK 3/4 14 52 4 728 546 136.5 151.7
70 64-QAM 16-QAM 16-QAM QPSK 3/4 16 52 4 832 624 156 173.3
71 64-QAM 16-QAM 16-QAM 16-QAM 3/4 18 52 4 936 702 175.5 195.0
72 64-QAM 64-QAM QPSK QPSK 3/4 16 52 4 832 624 156 173.3
73 64-QAM 64-QAM 16-QAM QPSK 3/4 18 52 4 936 702 175.5 195.0
74 64-QAM 64-QAM 16-QAM 16-QAM 3/4 20 52 4 1040 780 195 216.7
75 64-QAM 64-QAM 64-QAM QPSK 3/4 20 52 4 1040 780 195 216.7
76 64-QAM 64-QAM 64-QAM 16-QAM 3/4 22 52 4 1144 858 214.5 238.3
The rate-dependent parameters for optional 40 MHz, NSS = 2 MCSs with NES = 1 and UEQM of the spatial
streams shall be as shown in Table 19-39.
Table 19-39—MCS parameters for optional 40 MHz, NSS = 2, NES = 1, UEQM
Modulation Data rate (Mb/s)
MCS Index R NBPSC NSD NSP NCBPS NDBPS
Stream 1 Stream 2 800 ns GI 400 ns GI
33 16-QAM QPSK 1/2 6 108 6 648 324 81 90
34 64-QAM QPSK 1/2 8 108 6 864 432 108 120
35 64-QAM 16-QAM 1/2 10 108 6 1080 540 135 150
36 16-QAM QPSK 3/4 6 108 6 648 486 121.5 135
37 64-QAM QPSK 3/4 8 108 6 864 648 162 180
38 64-QAM 16-QAM 3/4 10 108 6 1080 810 202.5 225
2433
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The rate-dependent parameters for optional 40 MHz, NSS = 3 MCSs, with UEQM of the spatial streams shall
be as shown in Table 19-40.
Table 19-40—MCS parameters for optional 40 MHz, NSS = 3, UEQM
Modulation Data rate (Mb/s)
MCS
R NBPSC NSD NSP NCBPS NDBPS NES
Index 800 ns 400 ns
Stream 1 Stream 2 Stream 3
GI GI
39 16-QAM QPSK QPSK 1/2 8 108 6 864 432 1 108 120
40 16-QAM 16-QAM QPSK 1/2 10 108 6 1080 540 1 135 150
41 64-QAM QPSK QPSK 1/2 10 108 6 1080 540 1 135 150
42 64-QAM 16-QAM QPSK 1/2 12 108 6 1296 648 1 162 180
43 64-QAM 16-QAM 16-QAM 1/2 14 108 6 1512 756 1 189 210
44 64-QAM 64-QAM QPSK 1/2 14 108 6 1512 756 1 189 210
45 64-QAM 64-QAM 16-QAM 1/2 16 108 6 1728 864 1 216 240
46 16-QAM QPSK QPSK 3/4 8 108 6 864 648 1 162 180
47 16-QAM 16-QAM QPSK 3/4 10 108 6 1080 810 1 202.5 225
48 64-QAM QPSK QPSK 3/4 10 108 6 1080 810 1 202.5 225
49 64-QAM 16-QAM QPSK 3/4 12 108 6 1296 972 1 243 270
50 64-QAM 16-QAM 16-QAM 3/4 14 108 6 1512 1134 1 283.5 315
51 64-QAM 64-QAM QPSK 3/4 14 108 6 1512 1134 1 283.5 315
52 64-QAM 64-QAM 16-QAM 3/4 16 108 6 1728 1296 2 324 360
The rate-dependent parameters for optional 40 MHz, NSS = 4 MCSs, with UEQM of the spatial streams shall
be as shown in Table 19-41.
Table 19-41—MCS parameters for optional 40 MHz, NSS = 4, UEQM
Data rate
Modulation
(Mb/s)
MCS
R NBPSC NSD NSP NCBPS NDBPS NES
Index
Stream Stream Stream Stream 800 ns 400 ns
1 2 3 4 GI GI
53 16- QPSK QPSK QPSK 1/2 10 108 6 1080 540 1 135 150
QAM
54 16- 16- QPSK QPSK 1/2 12 108 6 1296 648 1 162 180
QAM QAM
55 16- 16- 16- QPSK 1/2 14 108 6 1512 756 1 189 210
QAM QAM QAM
56 64- QPSK QPSK QPSK 1/2 12 108 6 1296 648 1 162 180
QAM
57 64- 16- QPSK QPSK 1/2 14 108 6 1512 756 1 189 210
QAM QAM
2434
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 19-41—MCS parameters for optional 40 MHz, NSS = 4, UEQM (continued)
Data rate
Modulation
(Mb/s)
MCS
R NBPSC NSD NSP NCBPS NDBPS NES
Index
Stream Stream Stream Stream 800 ns 400 ns
1 2 3 4 GI GI
58 64- 16- 16- QPSK 1/2 16 108 6 1728 864 1 216 240
QAM QAM QAM
59 64- 16- 16- 16- 1/2 18 108 6 1944 972 1 243 270
QAM QAM QAM QAM
60 64- 64- QPSK QPSK 1/2 16 108 6 1728 864 1 216 240
QAM QAM
61 64- 64- 16- QPSK 1/2 18 108 6 1944 972 1 243 270
QAM QAM QAM
62 64- 64- 16- 16- 1/2 20 108 6 2160 1080 1 270 300
QAM QAM QAM QAM
63 64- 64- 64- QPSK 1/2 20 108 6 2160 1080 1 270 300
QAM QAM QAM
64 64- 64- 64- 16- 1/2 22 108 6 2376 1188 1 297 330
QAM QAM QAM QAM
65 16- QPSK QPSK QPSK 3/4 10 108 6 1080 810 1 202.5 225
QAM
66 16- 16- QPSK QPSK 3/4 12 108 6 1296 972 1 243 270
QAM QAM
67 16- 16- 16- QPSK 3/4 14 108 6 1512 1134 1 283.5 315
QAM QAM QAM
68 64- QPSK QPSK QPSK 3/4 12 108 6 1296 972 1 243 270
QAM
69 64- 16- QPSK QPSK 3/4 14 108 6 1512 1134 1 283.5 315
QAM QAM
70 64- 16- 16- QPSK 3/4 16 108 6 1728 1296 2 324 360
QAM QAM QAM
71 64- 16- 16- 16- 3/4 18 108 6 1944 1458 2 364.5 405
QAM QAM QAM QAM
72 64- 64- QPSK QPSK 3/4 16 108 6 1728 1296 2 324 360
QAM QAM
73 64- 64- 16- QPSK 3/4 18 108 6 1944 1458 2 364.5 405
QAM QAM QAM
74 64- 64- 16- 16- 3/4 20 108 6 2160 1620 2 405 450
QAM QAM QAM QAM
75 64- 64- 64- QPSK 3/4 20 108 6 2160 1620 2 405 450
QAM QAM QAM
76 64- 64- 64- 16- 3/4 22 108 6 2376 1782 2 445.5 495
QAM QAM QAM QAM
2435
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20. Directional multi-gigabit (DMG) PHY specification
20.1 DMG PHY introduction
20.1.1 Scope
The DMG PHY supports three modulation methods:
— A control modulation using MCS 0 (the DMG control mode; see 20.4)
— A single carrier (SC) modulation using MCS 1 to MCS 12, MCS 9.1, 12.1, 12.2, 12.3, 12.4, 12.5 and
12.6 (the DMG SC mode; see 20.6) and MCS 25 to MCS 31 (the DMG low-power SC mode;
see 20.7)
— An OFDM modulation using MCS 13 to MCS 24 (the DMG OFDM mode; see 20.5)
All DMG modulation methods share a similar preamble (see 20.3.6).
The services provided to the MAC by the DMG PHY consist of the following protocol functions:
a) A function that defines a method of mapping the PHY service data units (PSDU) into a framing
format (PPDU) suitable for sending and receiving PSDUs between two or more STAs.
b) A function that defines the characteristics and method of transmitting and receiving data through a
wireless medium between two or more STAs. Depending on the DMG MCSs, these STAs support
a mixture of DMG SC mode, DMG OFDM mode, DMG low-power SC mode, and DMG control
mode.
20.1.2 DMG PHY functions
The DMG PHY contains two functional entities: the PHY and the layer management function (PLME).
Each of these functions is described in detail in 20.3 to 20.12. The DMG PHY service is provided to the
MAC through the PHY service primitives defined in Clause 8.
20.1.2.1 PHY management entity (PLME)
The PLME performs management of the local PHY functions in conjunction with the MLME.
20.1.2.2 Service specification method
The models represented by figures and state diagrams are intended to be illustrations of the functions
provided. It is important to distinguish between a model and a real implementation. The models are
optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular
implementation. The service of a layer or sublayer is the set of capabilities that it offers to a user in the next
higher layer (or sublayer). Abstract services are specified here by describing the service primitives and
parameters that characterize each service. This definition is independent of any particular implementation.
20.2 DMG PHY service interface
20.2.1 Introduction
The PHY interfaces to the MAC through the TXVECTOR, RXVECTOR, and the PHYCONFIG_VECTOR.
Using the TXVECTOR, the MAC supplies the PHY with per-PPDU transmit parameters. Using the
RXVECTOR, the PHY informs the MAC of the received packet parameters. Using the
PHYCONFIG_VECTOR, the MAC configures the PHY for operation, independent of frame transmission
or reception.
2436
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This interface is an extension of the generic PHY service interface defined in 8.3.4.
20.2.2 TXVECTOR and RXVECTOR parameters
The parameters in Table 20-1 are defined as part of the TXVECTOR parameter list in the PHY-
TXSTART.request primitive and/or as part of the RXVECTOR parameter list in the PHY-
RXSTART.indication primitive.
Table 20-1—TXVECTOR and RXVECTOR parameters
RXVECTOR
TXVECTOR
Parameter Value
MCS The MCS parameter is an enumerated type that indicates the modulation Y Y
and coding scheme used in the transmission of the packet. Values are
integers in the range 0 to 31 and the values 9.1, 12.1, 12.2, 12.3, 12.4,
12.5 and 12.6.
— An MCS value of 0 indicates the use of DMG control mode.
— MCS values of 1 to 12 and 9.1, 12.1, 12.2, 12.3, 12.4, 12.5, 12.6
indicate use of single carrier modulations. The value is an index to
Table 20-19.
— MCS values of 13 to 24 indicates use of OFDM modulations. The
value is an index to Table 20-14.
— MCS values of 25 to 31 indicate use of DMG low-power SC mode.
The value is an index to Table 20-23.
LENGTH Indicates the number of octets in the PSDU in the range 1 to 262 143. Y Y
ADD-PPDU Enumerated Type: Y Y
— ADD-PPDU indicates that this PPDU is immediately followed by
another PPDU with no IFS or preamble on the subsequent PPDU.
— NO-ADD-PPDU indicates no additional PPDU follows this PPDU.
PACKET-TYPE Enumerated Type: Y Y
— TRN-R-PACKET indicates either a packet whose data part is
followed by one or more TRN subfields, or a packet that is
requesting TRN subfields to be appended to a future response
packet.
— TRN-T-PACKET indicates a packet whose data part is followed by
one or more TRN subfields. The transmitter may change AWV
configuration at the beginning of each TRN subfield.
This parameter is reserved if TRN-LEN is 0.
TRN-LEN TRN-LEN indicates the length of the training field. Values are in the Y Y
range 0–16 (see 20.10.2.2.3).
AGGREGATION Indicates whether the PSDU contains an A-MPDU. Y Y
Enumerated Type:
— AGGREGATED indicates this is a PSDU with A-MPDU
aggregation.
— NOT_AGGREGATED indicates this is a PSDU without A-MPDU
aggregation.
2437
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter Value
RSSI The allowed values for the RSSI parameter are in the range 0 through N Y
RSSI maximum. This parameter is a measure by the PHY of the power
observed at the input of the antennas plus the antenna gain, or equivalent
antenna gain for a phased-array antenna, used to receive the current
PPDU. RSSI shall be measured during the reception of the PHY pream-
ble. RSSI is intended to be used in a relative manner, and it shall be a
monotonically increasing function of the received power.
SNR This parameter indicates the SNR measured during the reception of a N Y
DMG control mode packet. Values are –13 dB to 50.75 dB in 0.25 dB
steps.
RCPI Is a measure of the received RF power measured over the preamble of a N Y
received frame. Refer to 20.3.10 for the definition of RCPI.
ANT_CONFIG Indicates which antenna configuration(s) is to be used throughout the Y N
transmission of the packet, and when to switch between configurations.
Values are implementation dependent.
CHAN_MEASURE- Channel as measured during the reception of TRN subfields. Each mea- N Y
MENT surement includes 63 complex numbers.
TIME_OF_DEPAR- Enumerated type: O N
TURE_REQUESTED — true indicates that the MAC entity requests that the PHY PHY entity
measures and reports time of departure parameters corresponding to
the time when the first frame energy is sent by the transmitting port.
— false indicates that the MAC entity requests that the PHY PHY entity
neither measures nor reports time of departure parameters.
RX_START_OF_- 0 to 232–1. An estimate of the offset (in 10 nanosecond units) from the N See
FRAME_OFFSET point in time at which the start of the preamble corresponding to the NO
incoming frame arrived at the receive antenna connector to the point in TE
time at which this primitive is issued to the MAC.
DTP_TYPE Enumerated: Y Y
— STATIC indicating static tone paring (see 20.5.3.2.4.6.2).
— DYNAMIC indicating dynamic tone pairing (see 20.5.3.2.4.6.3).
DTP_INDICATOR An update to the DTP tone map is indicated by changing the value of this Y Y
parameter from 0 to 1 or from 1 to 0 (see 10.40)
BEAM_TRACK- This parameter indicates whether beam tracking is requested. Enumer- Y Y
ING_REQUEST ated type:
Beam tracking requested or Beam tracking not requested
2438
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter Value
LAST_RSSI In the TXVECTOR, LAST_RSSI indicates the received power level of Y Y
the last packet with a valid PHY header that was received a SIFS before
transmission of the current packet; otherwise, it is 0 (10.3.2.3.3).
In the RXVECTOR, LAST_RSSI indicates the value of the LAST_RSSI
field from the PCLP header of the received packet. Valid values are inte-
gers in the range 0 to 15:
— Values of 2 to 14 represent power levels (–71+value×2) dBm.
— A value of 15 represents power greater than or equal to –42 dBm.
— A value of 1 represents power less than or equal to –68 dBm.
— A value of 0 indicates that the previous packet was not received a
SIFS before the current transmission.
Turnaround Set to 1 or 0 as specified in 10.3.2.3.3. Y Y
NOTE— “Y” if dot11TimingMsmtActivated is true, otherwise “N”.
20.2.3 TXSTATUS parameters
The parameters listed in Table 20-2 are defined as part of the TXSTATUS parameter list in the
PHY-TXSTART.confirm(TXSTATUS) primitive.
Table 20-2—TXSTATUS parameters
Parameter Value
TIME_OF_DEPARTURE When the first frame energy is sent by the transmitting port, in
units equal to 1/TIME_OF_DEPARTURE_ClockRate.
This parameter is present only if TIME_OF_DEPARTURE_RE-
QUESTED is true in the corresponding request.
TIME_OF_DEPARTURE_ClockRate 0 to 216–1. The clock rate, in units of MHz, is used to generate the
TIME_OF_DEPARTURE value. This parameter is present only if
TIME_OF_DEPARTURE_REQUESTED is true in the corre-
sponding request.
TX_START_OF_FRAME_OFFSET 0 to 232–1. An estimate of the offset (in 10 nanosecond units) from
the point in time at which the start of the preamble corresponding
to the frame was transmitted at the transmit antenna connector to
the point in time at which this primitive is issued to the MAC.
20.3 Common parameters
20.3.1 Channelization
The DMG PHY operates in the channels defined in Annex E and shall support at least channel number 2.
2439
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The channel center frequency is defined as:
Channel center frequency = Channel starting frequency + Channel spacing × Channel number
where channel starting frequency, channel spacing and channel number are as defined in Annex E.
20.3.2 Transmit mask
The transmitted spectrum shall adhere to the transmit spectrum mask shown in the Figure 20-1. The transmit
spectrum shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth not
exceeding 1.88 GHz, –17 dBr at a 1.2 GHz offset, –22 dBr at a 2.7 GHz offset and –30 dBr at a 3.06 GHz
offset and above, inside the channels allowed for the regulatory domain in which the device is transmitting.
The measurement shall be made using a 1 MHz resolution bandwidth and a 300 kHz video bandwidth.
The transmit mask shall be measured on data packets longer than 10 µs without training fields.
-17dBr
-22dBr
-30dBr
-3.06 -2.7 -1.2 -0.94 0.94 1.2 2.7 3.06 (f-fc) GHz
Figure 20-1—Transmit mask
20.3.3 Common requirements
20.3.3.1 Introduction
This subclause describes the common requirement from all four DMG modes: control, SC, OFDM, and low-
power SC.
In all of the modes, all defined fields are transmitted bit 0 first in time.
20.3.3.2 Center frequency tolerance
20.3.3.2.1 General
The transmitter center frequency tolerance shall be ± 20 ppm maximum.
20.3.3.2.2 Center frequency convergence
The transmitter center frequency shall converge to within 1 ppm of its final value within 0.9 µs from the start
of the packet.
20.3.3.3 Symbol clock tolerance
The symbol clock frequency tolerance shall be ± 20 ppm maximum.
The transmit center frequency and the symbol clock frequency shall be derived from the same reference
oscillator.
2440
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.3.3.4 Transmit center frequency leakage
The transmitter center frequency leakage shall not exceed –23 dB relative to the overall transmitted power
or, equivalently, in OFDM (MCS 13-24), +2.5 dB relative to the average power of a subcarrier, measured
over a subcarrier spacing bandwidth.
20.3.3.5 Transmit rampup and rampdown
The transmit power-on ramp is defined as the time it takes for a transmitter to rise from less than 10% to
greater than 90% of the average power to be transmitted in the frame.
The transmit power-on ramp shall be less than 10 ns.
The transmit power-down ramp is defined as the time it takes the transmitter to fall from greater than 90% to
less than 10% of the maximum power to be transmitted in the frame.
The transmit power-down ramp shall be less than 10 ns.
20.3.3.6 Antenna setting
Antenna setting shall remain constant for the transmission of the entire packet except for the case of
transmission of BRP-TX packets (see 20.10.2.2). During the transmission of BRP-TX packets, it shall
remain constant for the transmission of the STF, CE field, and Data field.
20.3.3.7 Maximum input requirement
The receiver maximum input level is the maximum power level at the receive antenna(s) of the incoming
signal, in dBm, present at the input of the receiver antenna for which the error rate criterion (defined in
20.3.3.8) is met. A receiver shall have a receiver maximum input level at the receive antenna(s) of at least 10
microwatts/cm2 for each of the modulation formats that the receiver supports.
20.3.3.8 Receive sensitivity
For MCS 0, the PER shall be less than 5% for a PSDU length of 256 octets with the MCS dependent input
levels listed in Table 20-3 defined at the antenna connector(s). For the other MCSs, the PER shall be less
than 1% for a PSDU length of 4096 octets with the MCS dependent input levels listed in Table 20-3 defined
at the antenna connector(s).
NOTE—For RF power measurements performed over the air, the input level shall be corrected to compensate for the
antenna gain in the implementation. The gain of the antenna is the maximum estimated gain by the manufacturer. In the
case of the phased-array antenna, the gain of the phased-array antenna is the maximum sum of estimated element gain
minus 3 dB implementation loss.
Table 20-3 assumes 5 dB implementation loss and 10 dB noise factor (Noise Figure).
Table 20-3—Receiver sensitivity
Receive sensitivity
MCS
(dBm)
0 –78
1 –68
2 –66
3 –65
2441
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-3—Receiver sensitivity (continued)
Receive sensitivity
MCS
(dBm)
4 –64
5 –62
6 –63
7 –62
8 –61
9 –59
9.1 –57
10 –55
11 –54
12 –53
12.1 –51
12.2 –50
12.3 –48
12.4 –46
12.5 –44
12.6 –42
13 –66
14 –64
15 –63
16 –62
17 –60
18 –58
19 –56
20 –54
21 –53
22 –51
23 –49
24 –47
25 –64
26 –60
27 –57
28 –57
29 –57
30 –57
31 –57
2442
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.3.4 Timing-related parameters
Table 20-4 defines timing-related parameters.
Table 20-4—Timing-related parameters
Parameter Value
NSD: Number of data subcarriers 336
NSP: Number of pilot subcarriers 16
NDC: Number of DC subcarriers 3
NST: Total Number of subcarriers 355
NSR: Number of subcarriers occupying half of the overall BW 177
NGI 64
NSPB 448
F : subcarrier frequency spacing 5.156 25 MHz (2640 MHz / 512)
Fs: OFDM sample rate 2640 MHz
Fc: SC chip rate 1760 MHz = ⅔ Fs
Ts: OFDM Sample Time 0.38 ns=1 / Fs
Tc: SC Chip Time 0.57 ns=1 / Fc
TDFT: OFDM IDFT/DFT period 0.194 µs
TGI: guard interval duration 48.4 ns= TDFT/4
Tseq 72.7 ns=128 × Tc
TSTF: Detection sequence duration 1236 ns=17× Tseq
TCE: Channel Estimation sequence duration 655 ns=9 × Tseq
TSYM: Symbol Interval 0.242 µs= TDFT + TGI
THEADER: Header Duration 0.242 µs=TSYM (OFDM)
0.582 µs =2 × 512 × Tc (SC and low-power
SC)
FCCP: control mode chip rate 1760 MHz
TCCP: control mode chip time 0.57 ns = 1 / FCCP
TSTF-CP: control mode short training field duration 3.636 µs =50 × Tseq
TCE-CP: control mode channel estimation field duration 655 ns=9 × Tseq
TData NSYM × TSYM (OFDM)
(NBLKS × 512 + 64) × Tc (SC)
NOTE—NSYM is defined in 20.5.3.2.3.3 and
NBLKS is defined in 20.6.3.2.3.3.
Table 20-5 defines parameters used frequently in Clause 20.
2443
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-5—Frequently used parameters
Symbol Explanation
NCBPS Number of coded bits per symbol
N DBPS Number of data bits per symbol
N BPSC Number of coded bits per single carrier
R Code rate
20.3.5 Mathematical conventions in the signal description
20.3.5.1 General
The transmitted signal is described in complex base-band signal notation. The actual transmitted signal is
related to the complex baseband signal r t by the following relation:
r RF t = Re r t exp j2 f c t
where
fC is the center frequency of the carrier
The transmitted RF signal is generated by modulating the complex baseband signal, which consists of
several fields. The fields and the timing boundaries for the various fields are shown in Figure 20-2.
Short Training field CE Header Data AGC and TRN subfields
tCE t Header tData tTRN
Figure 20-2—Packet structure
The time offset, t Field , determines the starting time of the corresponding field.
r PPDU t = r STF t + r CE t – t CE + r Header t – t Header + r Data t – t Data + r TRN t – t TRN
where
t CE = T STF
t Header = t CE + T CE
t Data = t Header + T Header
t TRN = t Data + T Data
Each OFDM base band waveform r Field nT S , for the fields above, is defined via the discrete inverse
Fourier transform as:
r Field nT S = w TField nT S X k exp j2 k F nT S – T GI
k
2444
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
Xk is the complex constellation point to be transmitted on subcarrier k
n is the discrete time index
The window w TField nT S is user defined and is used to smooth the transition between fields.
The base band waveform for fields defined by time domain sequences or for single carrier transmission is
r Field nT C = x n
where
x n is the constellation point n
Conversion from the sampled digital domain to the continuous time domain is beyond the scope of this
document. Filtering for pulse shaping such as in GMSK is beyond the scope of this standard.
20.3.5.2 Windowing function
The windowing function w TField nT S is used to smooth the transition between adjacent fields in the PPDU
where OFDM modulation is employed. See Figure 20-3. No windowing is applied to preamble fields or to
SC modulated fields.
THeader TSYM
STF CE Header Symbol 1 Symbol 2
TR TR
Figure 20-3—Illustration of windowing function
An example of a windowing function is given by
–TR TR
sin --- 1--- + -----
t
2
- --------- t ------
2 2 TR 2 2
wT t = T T
1 -----R- t T – -----R-
2 2
2 1 t–T T T
sin --- --- – ----------- T – -----R- t T + -----R-
2 2 TR 2 2
The transition region creates an overlap (with length TR) between adjacent fields. The field wave form
r Field nT S is extended cyclically to fill the part of the transition region in which it is undefined. If the
transition region vanishes (i.e., TR=0), the windowing function degenerates to a rectangular window. The
choice of windowing function is implementation dependent, as long as transmit EVM and transmit mask
requirements are met.
2445
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.3.6 Common preamble
20.3.6.1 General
The preamble is the part of the PPDU that is used for packet detection, AGC, frequency offset estimation,
synchronization, indication of modulation (SC or OFDM) and channel estimation. The format of the
preamble is common to both OFDM packets and SC packets and consists of a Short Training field followed
by a Channel Estimation field. The content of the Short Training field is the same between SC and OFDM
packets (see 20.3.6.2), but the content of the Channel Estimation field is not the same between such packets
(see 20.3.6.3). Figure 20-4 illustrates the SC packet preamble, and Figure 20-5 illustrates the OFDM packet
preamble.
Ga128 Ga128 Ga128 Ga128 Ga128 Ga128 Ga128 -Ga128 Gu512 Gv512 Gv 128
Short Training field (STF) 2176 Tc Channel Estimation field (CEF) 1152 Tc
Figure 20-4—SC preamble
Ga 128 Ga128 Ga128 Ga128 Ga128 Ga128 Ga128 -Ga 128 Gv 512 Gu512 Gv 128
Short Training field (STF) 2176 Tc Channel Estimation field (CEF) 1152 Tc
Figure 20-5—OFDM preamble
20.3.6.2 Short Training field
The Short Training field is composed of 16 repetitions of sequences Ga128(n) of length 128 defined in 20.11,
followed by a single repetition of –Ga128(n).
The waveform for the Short Training field is
n
Ga 128 n mod 128 exp j --- n = 0 1 16 128 – 1
2
r STF nT c =
n
– Ga 128 n mod 128 exp j --- n = 16 128 17 128 – 1
2
where
mod is the modulus operation
2446
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.3.6.3 Channel Estimation field
The Channel Estimation field is used for channel estimation, as well as indication of which modulation is
going to be used for the packet. The Channel Estimation field is composed of a concatenation of two
sequences Gu512(n) and Gv512(n), where the last 128 samples of Gu512(n) and Gv512(n) are equal to the last
128 samples used in the Short Training field. They are followed by a 128 samples sequence Gv128(n) equal
to the first 128 samples of both Gv512(n) and Gu512(n).
The Gu512 and Gv512 sequences are defined as
G u512 = – Gb 128 – Ga Gb – Ga 128
128 128
G v512 = – Gb 128 Ga – Ga 128
128 – Gb 128
where
Ga128 and Gb128 are as defined in 20.11
When the data field of the packet is modulated using single carrier, the Gu512 and Gv512 fields are
concatenated in the order illustrated in Figure 20-6. When the data field of the packet is modulated using
OFDM, the Gu512 and Gv512 fields are concatenated in the order illustrated in Figure 20-7.
Gu 512 Gv 512 Gv128
... Ga 128 Ga 128 Ga 128 -Ga 128 -Gb 128 -Ga 128 Gb 128 -Ga 128 -Gb 128 Ga 128 -Gb 128 -Ga 128 -Gb 128
Short Training field Channel Estimation field
Figure 20-6—Channel Estimation field for SC packets
Gv512 Gu 512 Gv128
... Ga 128 Ga 128 Ga 128 -Ga 128 -Gb 128 Ga 128 -Gb 128 -Ga 128 -Gb 128 -Ga 128 Gb 128 -Ga 128 -Gb 128
Short Training field Channel Estimation field
Figure 20-7—Channel Estimation field for OFDM packets
The waveform for the channel estimation sequence is
n
r CESC nT c = Gu 512 n + Gv 512 n – 512 + Gv 128 n – 1024 exp j --- n = 0 1 1151
2
n
r CE OFDM nT c = Gv 512 n + Gu 512 n – 512 + Gv 128 n – 1024 exp j --- n = 0 1 1151
2
Note that sequences Gu512(n) and Gv512(n) are defined for 0 ≤ n ≤ 511. For other values of n, Gu512(n) and
Gv512(n) are set to 0.
2447
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.3.6.4 Transmission of the preamble and BRP fields in an OFDM packet
20.3.6.4.1 General
The preamble sequence defined in the above subclauses and the BRP fields defined in 20.10.2.2.5,
20.10.2.2.6, and 20.10.2.2.7 are specified at the SC chip rate (Tc). For transmission in the OFDM (nominal)
sample rate, the signal is resampled with a 3/2 rate change. The resampling is done by upsampling by a
factor of 3, filtering by the filter h Filt defined in 20.3.6.4.2, and downsampling by a factor of 2 (see equation
below). The resampling is performed using a specific filter h Filt since the OFDM receiver needs to know
this filter to correct for its response during channel estimation. To define the transmission of the preamble
when the packet is an OFDM packet, the preamble waveform is defined below.
Let r preamble nT c = r STF nT c + r CE nT c – t ce , where r CE is r CESC or r CEOFDM as appropriate.
Then:
T T
OFDM 2
r preamble n -----s = r preamble n -----c n = 0 3 6
2 3
0 otherwise
K–1
OFDM 2 Ts OFDM 2 T
r̃ preamble n ----- = r preamble n – k -----s h Filt k n = 0 1
2 2
K=0
r̃ preamble nT s = r OFDM 2 2n T Ts
OFDM
-----s – K
– 1- ----
preamble ------------ - n=0 1
2 2 2
where
K is the length of the filter defined in 20.3.6.4.2
OFDM 2
r̃ preamble n = 0 for n 0
20.3.6.4.2 hFilt definition
The filter h Filt is defined by the following coefficients (from h0 to h70):
[-1,0,1,1,-2,-3,0,5,5,-3,-9,-4,10,14,-1,-20,-16,14,33,9,-35,-42,11,64,40,-50,-96,-15,120,126,-62,-256,
-148,360,985,1267,985,360,-148,-256,-62,126,120,-15,-96,-50,40,64,11,-42,-35,9,33,14,-16,-20,-1,14,10,
3 h
-4,-9,-3,5,5,0,-3,-2,1,1,0,-1]. Normalized to have a norm of 3 so that h Filt k = -------------------k .
70
2
hl
l=0
2448
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.3.7 HCS calculation for headers of DMG control mode, DMG OFDM mode, and DMG SC
mode
The header check sequence (HCS) is a CRC of the header bits. The header is considered to be a stream of
bits B0,…,BM-1. The CRC is based on CRC 16-CCITT. The value of the CRC field is the 1s complement of
16
CRC D = M D I D D modG D
where
M–1 M–2
M D = B0 D + B1 D + + B M – 1 is the header bits represented as polynomial (over the binary
field) where B0 is bit 0 of the header and BM-1 is bit M-1 of the header
M–1
k
I D = D is an initialization polynomial added to the first 16 bits of the header (setting the shift
k = M – 16
register bits to 1)
16 12 5
G D = D + D + D + 1 is the CRC generating polynomial
15 14
CRC D = x 0 D + x 1 D + x 14 D + x 15
The CRC field is transmitted with x15 first.
For a block diagram and an example of how to calculate the CRC, see 15.3.3.7.
20.3.8 Common LDPC parity matrices
20.3.8.1 General
Four Low-Density Parity-Check (LDPC) codes are specified, each of a different rate but with a common
codeword size of 672 bits.
Each of the parity-check matrices H is partitioned into square submatrices of size Z x Z. The submatrices are
either cyclic-permutations of the identity matrix, or null submatrices with all zero entries.
A location with integer i denotes the cyclic-permutation submatrix Pi obtained from the Z x Z identity matrix
by cyclically shifting the columns to the right by i elements. The matrix Po is the Z x Z identity matrix. An
empty location denotes a null submatrix of size Z x Z.
Examples with Z = 4:
1 0 0 0 0 1 0 0 0 0 0 1
P0 = 0 1 0 0 P = 0 0
1
1 0 P = 1 0
3
0 0
0 0 1 0 0 0 0 1 0 1 0 0
0 0 0 1 1 0 0 0 0 0 1 0
2449
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.3.8.2 Rate 1/2 LDPC code matrix H = 336 rows x 672 columns, Z = 42
Table 20-6—Rate 1/2 LDPC code matrix
(Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z × Z;
blank entries represent the zero matrix of size Z × Z)
40 38 13 5 18
34 35 27 30 2 1
36 31 7 34 10 41
27 18 12 20 15 6
35 41 40 39 28 3 28
29 0 22 4 28 27 23
31 23 21 20 12 0 13
22 34 31 14 4 13 22 24
20.3.8.3 Rate 5/8 LDPC code matrix H = 252 rows x 672 columns, Z = 42
Table 20-7—Rate 5/8 LDPC code matrix
(Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z × Z;
blank entries represent the zero matrix of size Z × Z)
20 36 34 31 20 7 41 34 10 41
30 27 18 12 20 14 2 25 15 6
35 41 40 39 28 3 28
29 0 22 4 28 27 24 23
31 23 21 20 9 12 0 13
22 34 31 14 4 22 24
20.3.8.4 Rate 3/4 LDPC code matrix H = 168 rows x 672 columns, Z = 42
Table 20-8—Rate 3/4 LDPC code matrix
(Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z × Z;
blank entries represent the zero matrix of size Z × Z)
35 19 41 22 40 41 39 6 28 18 17 3 28
29 30 0 8 33 22 17 4 27 28 20 27 24 23
37 31 18 23 11 21 6 20 32 9 12 29 0 13
25 22 4 34 31 3 14 15 4 14 18 13 13 22 24
2450
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.3.8.5 Rate 13/16 LDPC code matrix H = 126 rows x 672 columns, Z = 42
Table 20-9—Rate 13/16 LDPC code matrix
(Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z × Z;
blank entries represent the zero matrix of size Z × Z)
29 30 0 8 33 22 17 4 27 28 20 27 24 23
37 31 18 23 11 21 6 20 32 9 12 29 10 0 13
25 22 4 34 31 3 14 15 4 2 14 18 13 13 22 24
20.3.9 Scrambler
The header and data fields following the scrambler initialization field (including data padding bits) shall be
scrambled by XORing each bit in turn with a length 127 periodic sequence generated by the polynomial
7 4
S x = x + x + 1 . The PHY header bits, with the exception of the first seven bits for SC and OFDM and
the first five bits for control mode, are placed one after the other, bit 7 first (bit 5 first for DMG control
mode). The octets of the PSDU and the pad bits shall be placed into a bit stream with bit 0 (LSB) of each
octet first and bit 7 of each octet (MSB) last. The generation of the sequence and the XOR operation are
defined in Figure 20-8.
Data In
x7 x6 x5 x4 x3 x2 x1
Scrambled Data Out
Figure 20-8—Data scrambler
For each PPDU, the transmitter shall select a nonzero seed value for the scrambler (bits x1 through x7). The
seed value should be selected in a pseudorandom fashion. The seed value is sent in the Scrambler
Initialization field of the PHY header. Each data bit in the data field of the PPDU is then XORed with the
scrambler output (x4 x7) and then the scrambler content is shifted once.
20.3.10 Received channel power indicator (RCPI) measurement
The RCPI is a measure of the received RF power in the selected channel as measured at the DMG Antenna
output. This parameter shall be measured by the PHY of the received RF power in the channel measured
over the preamble of the received frame.
The RCPI encoding is defined in 15.4.6.6.
RCPI shall equal the received RF power with an accuracy of ± 5 dB with 95% confidence interval within the
specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel width multiplied by 1.1. The relative error between RF
power measurements made within a 1 second interval should be less than ± 1 dB.
2451
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.4 DMG control mode
20.4.1 Introduction
Transmission and reception of control mode PPDUs is mandatory. DMG control mode uses the same chip
rate as the DMG SC mode. DMG control mode is transmitted when the TXVECTOR indicates MCS 0.
The modulation and coding scheme for the DMG control mode is shown in Table 20-10.
Table 20-10—DMG control mode modulation and coding scheme
MCS index Modulation Code rate Data rate
0 DBPSK 1/2a 27.5 Mb/sa
aCode
rate and data rate might be lower due to codeword shortening.
20.4.2 PPDU format
The DMG control mode PPDU is composed of the Preamble, Header, Data field, and possibly AGC and
TRN subfields. This is shown in Figure 20-9.
Preamble Header Block Data AGC subfields TRN subfields
Figure 20-9—DMG control mode PPDU format
20.4.3 Transmission
20.4.3.1 Preamble
20.4.3.1.1 General
The preamble is the part of the DMG control mode PPDU that is used for packet detection, AGC, frequency
offset estimation, synchronization, indication of frame type and channel estimation.
The preamble is composed of two parts as shown in Figure 20-10: the Short Training field and the Channel
Estimation field.
Gb128 Gb128 Gb128 Gb128 ... Gb 128 -Gb128 -Ga128 G U512 G V512 G V128
Short Training field (STF) 6400 T c Channel Estimation field (CEF) 1152 T c
Figure 20-10—DMG control mode preamble
2452
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.4.3.1.2 Short Training field
The Short Training field is composed of 48 repetitions of the sequence Gb128(n) of length 128, followed by
a single –Gb128(n) sequence (for synchronization) and then a single –Ga128(n) sequence. The sequences
Ga128(n) and Gb128(n) are defined in 20.11.
The waveform for the Short Training field is
n
Gb 128 n mod 128 exp j --- n=0 1 48 128 – 1
2
r STF nT c = n
– G b 128 n mod 128 exp j --- n = 48 128 49 128 – 1
2
n
– G a 128 n mod 128 exp j --- n = 49 128 50 128 – 1
2
where mod is the modulus operation. Note that sequences Ga128(n) and Gb128(n) are defined for 0≤n≤127.
For other n they are set to 0.
20.4.3.1.3 Channel Estimation field
The Channel Estimation field is the same as the Channel Estimation field of the DMG SC mode, as defined
in Figure 20-6 of 20.3.6.3.
20.4.3.2 Header
20.4.3.2.1 General
In the DMG control mode, the preamble is followed by the header block. The header consists of several
fields that define the details of the PPDU to be transmitted.
The header fields are described in Table 20-11.
Table 20-11—DMG control mode header fields
Number of
Field name Starting bit Description
bits
Differential encoder 1 0 Used to initialize the differential encoding.
initialization
Scrambler 4 1 Bits X1–X4 of the initial scrambler state.
Initialization
Length 10 5 Number of data octets in the PSDU.
Range 14–1023.
Packet Type 1 15 As defined in Table 20-17.
Training Length 5 16 Length of the training field. The use of this field is
defined in 20.10.2.2.3.
2453
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-11—DMG control mode header fields (continued)
Number of
Field name Starting bit Description
bits
Turnaround 1 21 As defined in Table 20-1.
Reserved bits 2 22
HCS 16 24 Header Check sequence. Calculation of the header
check sequence is defined in 20.3.7.
All of the numeric fields are encoded in unsigned binary, least significant bit first.
Reserved bits are set to 0 by the transmitter and shall be ignored by the receiver.
20.4.3.2.2 Generation of HCS bits
The header check sequence (HCS) is calculated over bits 0-23 and uses CRC 16-CCITT as described in
20.3.7.
20.4.3.2.3 Header encoding and modulation
The header bits followed by the HCS bits are prepended to the data field bits and passed into the data field
encoder per 20.4.3.3. The minimal payload length is 14 octets.
20.4.3.3 Data field
20.4.3.3.1 General
The Data field consists of the payload data of the PSDU. The PSDU is scrambled, encoded, modulated and
spread as described in the following subclauses.
20.4.3.3.2 Scrambler
The operation of the scrambler is defined in 20.3.9. Bits x1, x2, x3, x4 of the scrambler shift register are
initialized using the bits in the scrambler initialization bits from the header, bits x5, x6, x7 are set to 1. The
header is scrambled starting from bit 5. The scrambling of the data field continues the scrambling of the
header with no reset.
20.4.3.3.3 Encoder
The DMG control mode header and data is encoded using an effective LDPC code rate less than or equal to
1/2, generated from the data PHY rate 3/4 LDPC parity check matrix, with shortening. The following steps
are used for the encoding:
1) L CWD = 168 is the maximal number of data bits in each LDPC codeword. LHDR=5 is the length of
the header (including HCS) in octets. LFDCW=6 is the length of the additional data in the first LDPC
codeword in octets.
2) The total (header and additional data) number of bits in the first LDPC codeword is
L DPFCW = L HDR + L FDCW 8 = 88 .
2454
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
3) Length – 6 8
The number of LDPC codewords is N CW = 1 + ---------------------------------------- .
-
L CWD
4) The number of bits in the second and any subsequent LDPC codeword (if present), except the last, is
L DPCW = Length – 6 8 .
-----------------------------------------
N CW – 1
5) The number of bits in the last LDPC codeword is
L DPLCW = Length – 6 8 – N CW – 2 L DPCW .
128 – 6 8
NOTE—For example, if Length = 128 , then N CW = 1 + ------------------------------- = 7 , L DPCW = 163 , and
-
L CWD
L DPLCW = 161 . In the first LDPC block, the 88 bits of L DPFCW consist of 40 header+HCS bits along with 48 bits of
the data.
20.4.3.3.4 Modulation
The scrambled and coded bit stream is converted into a stream of complex constellation points using
differential binary phase shift keying (DBPSK) as follows.
The encoded bit stream [c 0 c 1 c 2 c 3 c 4, ] is converted to the nondifferential stream s k = 2c k – 1 . The
differential sequence is created by setting d k = s k d k – 1 . For the differential encoding purposes
d(–1) is defined to be 1. s 0 is the first bit of the encoded header bits.
20.4.3.3.5 Spreading
The constellation points are spread using the sequence Ga32(n), which is defined in 20.11.
The waveform for the modulated and spread data field is
n n
r DATA nT c = Ga 32 n mod 32 d ------ exp j --- n = 0 1 2
32 2
where d k is the modulated constellation point k.
20.4.4 Performance requirements
20.4.4.1 Transmit requirements
20.4.4.1.1 Introduction
Transmitter performance requirements of the DMG control mode are defined in 20.4.4.1.2.
20.4.4.1.2 Transmit EVM
The transmit EVM accuracy test shall be performed by instrumentation capable of converting the
transmitted signal into a stream of complex samples, with sufficient accuracy in terms of I/Q arm amplitude
and phase balance, dc offsets, phase noise, etc. The instrumentation shall perform carrier lock, symbol
timing recovery, and amplitude adjustment while making the measurements. The instrumentation shall
incorporate a rake receiver or equalizer to minimize error resulting from multipath. If used, the equalizer
2455
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
shall be trained using information in the preamble (STF and/or CEF). For the DMG control mode EVM, the
signal is first de-spread using Ga32. The EVM is then calculated on the resulting symbols according to the
formula below:
Ns
1 2 2
EVM = 20 log 10 ---------------- Ii – Ii + Qi – Qi
N s P avg
i=1
where
NS is the number of symbols to be measured
NS should be greater than 511
P avg is the average power of the constellation
(I i,Q i) is the complex coordinates of the measured symbol i
(I i ,Q i ) is the complex coordinates of the ideal constellation point for the measured symbol i
The test equipment should use a root-raised cosine filter with roll-off factor of 0.25 for the pulse shaping
filter when conducting EVM measurement.
The transmit pulse shaping used is left to the implementer.
The EVM shall not exceed a data-rate dependent value according to Table 20-12.
Table 20-12—DMG control mode EVM requirements
MCS index Description EVM value [dB]
0 DMG control mode –6
modulation
20.4.4.2 Receive requirements
20.4.4.2.1 Introduction
Subclause 20.4.4.2 describes the performance requirement from the DMG control mode receiver.
20.4.4.2.2 CCA
The start of a valid DMG control mode transmission at a receive level greater than -68dBm shall cause CCA
to indicate busy with a probability > 90% within 3 µs.
20.5 DMG OFDM mode
20.5.1 Introduction
Transmission and reception of DMG OFDM mode PPDUs is optional. The use of the DMG OFDM mode is
obsolete. Consequently, this option may be removed in a later revision of the standard.
2456
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.5.2 PPDU format
An OFDM frame is composed of the Short Training field (STF), the channel estimation field (CE), the
Header, OFDM symbols and optional training fields (see 20.10.2.2.2), as shown in Figure 20-11.
Short Training field CE Header Sym Sym Sym Sym AGC subfields TRN subfields
Figure 20-11—OFDM frame format
20.5.3 Transmission
20.5.3.1 Header
20.5.3.1.1 General
In the DMG OFDM mode, the preamble is followed by the PHY header. The PHY header consists of several
fields that define the details of the PPDU being transmitted. The encoding and modulation of the header is
described in 20.5.3.1.4.
The header fields are described in Table 20-13.
Table 20-13—DMG OFDM mode header fields
Number of
Field name Start bit Description
bits
Scrambler 7 0 Bits X1–X7 of the initial scrambler state.
Initialization
MCS 5 7 Index into the Modulation and Coding Scheme table.
Length 18 12 Number of data octets in the PSDU.
Range 1–262 143.
Additional PPDU 1 30 Contains a copy of the parameter ADD-PPDU from the
TXVECTOR. A value of 1 indicates that this PPDU is
immediately followed by another PPDU with no IFS or
preamble on the subsequent PPDU. A value of 0 indicates
that no additional PPDU follows this PPDU.
Packet Type 1 31 See the definition in Table 20-17.
Training Length 5 32 Corresponds to the TXVECTOR parameter TRN-LEN.
If the Beam Tracking Request field is 0, the Training
Length field indicates the length of the training field. The
use of this field is defined in 20.10.2.2.3. A value of 0 indi-
cates that no training field is present in this PPDU.
If the Beam Tracking Request field is 1 and the Packet
Type field is 1, the Training Length field indicates the
length of the training field appended to this PPDU. If the
Packet Type field is 0, the Training Length field indicates
the length of the training field requested for receive
training.
2457
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-13—DMG OFDM mode header fields (continued)
Number of
Field name Start bit Description
bits
Aggregation 1 37 Set to 1 to indicate that the PPDU in the data portion of the
packet contains an A-MPDU; otherwise, set to 0.
Beam Tracking 1 38 Corresponds to the TXVECTOR parameter
Request BEAM_TRACKING_REQUEST.
Set to 1 to indicate the need for beam tracking (10.38.7);
otherwise, set to 0.
The Beam Tracking Request field is reserved when the
Training Length field is 0.
Tone Pairing Type 1 39 Set to 0 to indicate Static Tone Pairing (20.5.3.2.4.6.2);
Set to 1 to indicate Dynamic Tone Pairing (20.5.3.2.4.6.3).
Only valid if MCS field value is in the range 13 to 17;
otherwise reserved.
DTP Indicator 1 40 Bit flip used to indicate DTP update.
Only valid when the Tone Pairing Type field is 1 and the
MCS field value is in the range 13 to 17; otherwise
reserved.
Last RSSI 4 41 Contains a copy of the parameter LAST_RSSI from the
TXVECTOR.
The value is an unsigned integer:
— Values of 2 to 14 represent power levels
(–71 + value × 2) dBm.
— A value of 15 represents a power greater than or equal
to –42 dBm.
— A value of 1 represents a power less than or equal to
–68 dBm.
Value of 0 indicates that the previous packet was not
received a SIFS before the current transmission.
Turnaround 1 45 As defined in Table 20-1.
Reserved 2 46
HCS 16 48 Header check sequence. Definition of this field calculation
is in 20.5.3.1.3.
All of the numeric fields are encoded in unsigned binary, least significant bit first.
Reserved bits are set to 0 by the transmitter and shall be ignored by the receiver.
If the Additional PPDU field is equal to 1, the Training Length field shall be set to 0.
20.5.3.1.2 Modulation and coding scheme
The modulation and coding scheme (MCS) field specifies the modulation and code rate used in the PPDU.
The modulation and coding schemes for OFDM modulations are defined in Table 20-14.
A device that supports OFDM shall support MCSs 13-17 for both transmit and receive.
2458
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-14—DMG OFDM mode modulation and coding schemes
Data rate
MCS index Modulation Code rate NBPSC NCBPS NDBPS
(Mb/s)
13 SQPSK 1/2 1 336 168 693.00
14 SQPSK 5/8 1 336 210 866.25
15 QPSK 1/2 2 672 336 1386.00
16 QPSK 5/8 2 672 420 1732.50
17 QPSK 3/4 2 672 504 2079.00
18 16-QAM 1/2 4 1344 672 2772.00
19 16-QAM 5/8 4 1344 840 3465.00
20 16-QAM 3/4 4 1344 1008 4158.00
21 16-QAM 13/16 4 1344 1092 4504.50
22 64-QAM 5/8 6 2016 1260 5197.50
23 64-QAM 3/4 6 2016 1512 6237.00
24 64-QAM 13/16 6 2016 1638 6756.75
20.5.3.1.3 Generation of the HCS bits
Calculation of the HCS for bits 0–47 of the header is defined in 20.3.7.
20.5.3.1.4 Header encoding and modulation
The header is encoded using a single OFDM symbol. The bits are scrambled and encoded as follows:
1) The 64 header bits (B1, B2, …, BLH), where LH = 64, are scrambled as described in 20.3.9, starting
from the eighth bit, to create q=(q1,q2,…,qLH).
2) The sequence q is padded with 440 zeros to obtain a total of 504 bits,
(q1,q2,…,qLH,0LH+1,0LH+2,…0504), which are then encoded using the rate 3/4 LDPC code as
described in 20.5.3.2.3.3. 168 parity bits, p1,p2,…,p168, are generated.
3) A sequence c1 is generated as (q1,q2,…,qLH,p9,p10,…p168).
4) A sequence c2 is generated as (q1,q2,…,qLH,p1,p2,…p84, p93,p94,…p168) XORed with a one-time
pad sequence generated using the scrambler defined in 20.3.9, with the shift register is initialized to
all 1s.
5) A sequence c3 is generated as (q1,q2,…,qLH,p1,p2,…p160) XORed with the continuation of the one-
time pad sequence generated in step 4).
6) The sequences c1,c2 and c3 are concatenated to form the 672-bit sequence
c=(c1,c2,c3,…,c672)=(c1,c2,c3).
2459
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
7) The 672-bit sequence, c, is then mapped as QPSK as described in 20.5.3.2.4.3, pilots are inserted as
described in 20.5.3.2.5 and the resulting sequence d0,d1,...,dSD-1 is modulated as an OFDM symbol
as follows:
N SR
1
r Header qT s = ------------------- w T SYM qT s D k + p 1 P k exp j2 k F qT s – T GI
N Tones k = – N SR
where p1 and Pk are defined in 20.5.3.2.5 and Dk is defined in 20.5.3.2.6.
20.5.3.2 Data field
20.5.3.2.1 General
The data field consists of the payload data of the PSDU and possible padding. The data are padded with
zeros, scrambled, encoded and modulated as described in the following subclauses. The amount of padding
is defined in 20.5.3.2.3.
20.5.3.2.2 Scrambler
The operation of the scrambler is defined in 20.3.9. The scrambling of the data field continues the
scrambling of the header with no reset.
20.5.3.2.3 Encoding
20.5.3.2.3.1 General
The data are encoded by a systematic LDPC encoder. LDPC is a block code. Each block of bits (B1,
B2,...,Bk) is concatenated with a block of parity bits (p1,p2,….,pn-k) to create a codeword c=(B1,
B2,...,Bk,p1,p2,….,pn-k) such that HcT=0. H is an (n-k)×n parity check matrix. The block size n is 672 bits.
The code rate, R, is equal to k/n. The set of code rates is defined in Table 20-15. The parity check matrices
are defined in 20.5.3.2.3.2. The encoding process is defined in 20.5.3.2.3.3.
Table 20-15—LDPC code rates
Code rate Codeword size Number of data bits
1/2 672 336
5/8 672 420
3/4 672 504
13/16 672 546
20.5.3.2.3.2 Parity check matrices
See 20.3.8.
2460
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.5.3.2.3.3 LDPC encoding process
The LDPC encoding process is composed of several steps including determining the number of padding bits,
padding with zeros and the coding of every word.
1) First the total number of padding bits NPAD is calculated, using the number of LDPC codeword NCW
and the number of OFDM symbols NSYM:
N CW = Length
--------------------------8-
L CW R
N CW L CW
N SYM = --------------------------
-
N CBPS
If BRP packet and N SYM aBRPminOFDMblocks ; N SYM = aBRPminOFDMblocks
N PAD = R N SYM N CBPS – Length 8
N CBPS
Recalculate N CW = N SYM ---------------
L CW
where LCW=672 is the LDPC codeword length, Length is the length of the PSDU defined in the
header field, R is the code rate and NCBPS is the number of code bits per symbol as defined in the
MCS table.
2) The PSDU is concatenated with NPAD zeros. They are scrambled using the continuation of the
scrambler sequence that scrambled the PSDU.
3) The output stream of the scrambler is broken into blocks of LCWD= R×LCW bits such as the m’th
m m m
data word is b 1 b2 b LCWD .
m m m
4) To each data word, n-k=LCW-R×LCW parity bits p 1 p2 p n –k are added to create the
T
m m m m m m m
codeword c = b1 b2 b L CWD p 1 p n – k such that Hc = 0.
5) The codewords are the concatenated one after the other to create the coded bits stream
c1 c2 c NSYM NCBPS .
20.5.3.2.4 Modulation mapping
20.5.3.2.4.1 General
The coded bits are mapped to complex constellation points for the modulation specified in the MCS as
described in the following subclauses.
20.5.3.2.4.2 SQPSK modulation
In SQPSK (Spread QPSK) modulation, the input stream is broken into groups of NCBPS bits –
c0
q q
c1
q
c NCBPS –1 . Each pair of bits q q N CBPS is converted into a
c2k c2k + 1 k = 0 1 --------------
-–1
2
q 1 q q
complex constellation point d k = ------- 2c 2 k – 1 + j 2c 2 k – 1 . This generates the constellation points
2
2461
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
for half the OFDM subcarriers. For the other subcarriers, d Pq k = conj d kq N CBPS
for k = 0 1 --------------- – 1
2
where the indices P(k), in the range NCBPS / 2 to NCBPS – 1, are as defined in 20.5.3.2.4.6.
20.5.3.2.4.3 QPSK modulation
q q q
a) The input stream is broken into groups of NCBPS bits – c 0 c1 c NCBPS –1 . Each group of four
q q q q
bits c4 k c4 k + 1 c4 k + 2 c4 k + 3 is converted into two complex constellation points
q 1 q q q 1 q q
x 2 k = ------- 2c 4 k – 1 + j 2c 4 k + 2 – 1 x 2 k + 1 = ------- 2c 4 k + 1 – 1 + j 2c 4 k + 3 – 1 . The block
2 2
q q q
x0 x1 x N CBPS is created.
--------------- – 1
2
b) Each pair of constellation points q q N SD is converted into
x2 k x2 k + 1 k = 0 1 --------- – 1
2
1
= Q x 2 k x 2 k + 1 where the matrix Q = ------- 1 2 and the indices P(k), in the range
q q q q
dk dP k
5 –2 1
NSD / 2 to NSD – 1, are as defined in 20.5.3.2.4.6.
c) The output is the stream of blocks q q q
d0 d1 d NSD – 1 q = 1 N SYM .
20.5.3.2.4.4 16-QAM modulation
q q q
The input stream is broken into groups of NCBPS bits c 0 c1 c NCBPS –1 . Each group of eight bits
q q q q q q q q N SD is
c 4 k c 4 k + 1 c 4 k + 2 c 4 k + 3 c 4 k + 2 NSD c 4 k + 1 + 2 NSD c 4 k + 2 + 2 NSD c 4 k + 3 + 2 NSD k = 0 1 2 --------
-–1
2
q q
converted into two complex constellation points x 2 k x 2 k + 1 such that
q 1 q q q
x 2 k = ---------- 4c 4 k – 2 – 2c 4 k – 1 2c 4 k + 1 – 1
10
q q q
+ j 4c 4 k + 2 – 2 – 2c 4 k + 2 – 1 2c 4 k + 3 – 1
and
q 1 q q q
x 2 k + 1 = ---------- 4c 4 k + 2 NSD – 2 – 2c 4 k + 2 NSD – 1 2c 4 k + 1 + 2 N SD – 1
10
q q q
+ j 4c 4 k + 2 + 2 NSD – 2 – 2c 4 k + 2 + 2 NSD – 1 2c 4 k + 3 + 2 NSD – 1
2462
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The output is the stream of blocks q q q
x0 x1 x NSD – 1 q = 0 1 N SYM – 1 .
20.5.3.2.4.5 64-QAM modulation
q q q
The input stream is broken into groups of NCBPS bits c 0 c1 c NCBPS –1 . The constellation point for the
k’th subcarrier in the q’th symbol is
q 1 q q q q q q
d k = ---------- 8c 6 m – 4 – 2c 6 m – 1 4c 6 m + 1 – 2 + 2c 6 m – 1 2c 6 m + 1 – 1 2c 6 m + 2 – 1
42
1 q q q q q q
+ j ---------- 8c 6 m + 3 – 4 – 2c 6 m + 3 – 1 4c 6 m + 4 – 2 + 2c 6 m + 3 – 1 2c 6 m + 4 – 1 2c 6 m + 5 – 1
42
m = 112 k mod 3 + --k- k=0 1 N SD – 1
3
NOTE—This mapping provides interleaving between three LDPC codewords on a subcarrier basis.
The mapping is shown in Figure 20-12.
Q c6kc6k+1c6k+2c6k+3c6k+4c6k+5
000 100 001 100 011 100 010 100 110 100 111 100 101 100 100 100
7
000 101 001 101 011 101 010 101 110 101 111 101 101 101 100 101
5
000 111 001 111 011 111 010 111 110 111 111 111 101 111 100 111
3
000 110 001 110 011 110 010 110 110 110 111 110 101 110 100 110
1
-7 -5 -3 -1 1 3 5 7
I
000 010 001 010 011 010 010 010 110 010 111 010 101 010 100 010
-1
000 011 001 011 011 011 010 011 110 011 111 011 101 011 100 011
-3
000 001 001 001 011 001 010 001 110 001 111 001 101 001 100 001
-5
000 000 001 000 011 000 010 000 110 000 111 000 101 000 100 000
-7
Figure 20-12—64-QAM modulation mapping
2463
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.5.3.2.4.6 Tone pairing for SQPSK and QPSK
20.5.3.2.4.6.1 General
When SQPSK or QPSK modulations are employed in OFDM, bit sequences are mapped to pairs of symbols
q q N SD N SD
d k d P k where k is in the range 0 k -------- - – 1 and P(k) is in the range --------
- P k N SD – 1 in order
2 2
to exploit frequency diversity. The indices k and P(k) determine which pair of OFDM subcarriers each pair
of symbols are carried on.
All DMG modes shall support Static Tone Pairing (STP) where a constant mapping between k and P(k) is
employed. The PHY header is always encoded using STP.
A STA may employ Dynamic Tone Pairing (DTP) where the mapping between k and P(k) are determined by
the receiving STA and fed back to the transmitting STA. A STA may use DTP when transmitting to a DTP-
capable STA, from which it has received DTP feedback.
20.5.3.2.4.6.2 Static tone pairing (STP)
When applied to the payload, STP is indicated by the value 0 in the Tone Pairing Type field in the PHY
header. STP is always applied to the PHY header.
When STP is applied, the QPSK or SQPSK symbol-pair indices k and P(k) are such that
N SD N SD
P k = k + --------
- for k = 0 1 2 --------
-–1
2 2
20.5.3.2.4.6.3 Dynamic tone pairing (DTP)
When applied, DTP is indicated by the value 1 in the Tone Pairing Type field in the PHY header. DTP can
be applied only to the payload of a PPDU employing MCS 13-17.
When DTP is applied, the SQPSK symbol-pair indices, k and P(k), are such that
k N SD
P k = ToneIndexOffset ------------ + mod k N TPG for k = 0 1 2 --------
-–1
N TPG 2
where
NTPG denotes the number of tones per group
N SD
ToneIndexOffset(l) denotes the starting index of the l-th group of tone pairs, for l = 0 1 2 -----------
-–1
N TPG
N SD
The values of NTPG and ToneIndexOffset(l) for l = 0 1 2 -----------
- – 1 are derived from the DTP Report
N TPG
element (9.4.2.146) included in the last received DTP Report frame (9.6.20.9).
2464
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The number of tone-pairs per group, NTPG, is derived as
N SD
N TPG = ---------
-
2N G
where
NG is the number of DTP groups, which is equal to 42
The tone index offsets, ToneIndexOffset(l), are derived as
N SD
ToneIndexOffset l = N TPG GroupPairIndex l + --------
-
2
where
GroupPairIndex(l) is the value of the GroupPairIndex(l) subfield of the DTP Report element
20.5.3.2.5 Pilot sequence
Pilot tones are inserted at tones –150, –130, –110, –90, –70, –50, –30, –10, 10, 30, 50, 70, 90, 110, 130,150.
The values of the pilots at these tones is [–1, 1, –1, 1, 1, –1, –1, –1, –1, –1, 1, 1, 1, –1, 1, 1], respectively. The
pilot sequence P is created by creating a sequence of zeros corresponding to tones –NSR to NSR. The pilots
are then inserted at the corresponding tones with the values specified above.
At OFDM symbol n the pilot sequence is multiplied by the value 2×pn–1, where pn is the value generated by
the shift register defined in 20.5.3.2.2 if x1,x2,…x7 are all set to 1 at the first OFDM symbol.
20.5.3.2.6 OFDM modulation
The stream of complex constellation points dk is broken into groups of NSD points dm,n where m=1,2,…,NSD
and n=1,2,…,NSYM. The baseband signal for the data phase is
1
r DATA qT s = -------------------
N Tones
N SYM N SR
w TSYM qT s – n – 1 T SYM D k n + p n + 1 P k exp j2 k F qT s – n – 1 T SYM – T GI
n=1 k = – N SR
where
pn, P are defined in 20.5.3.2.5
N Tones = N ST – N DC is the number of active subcarriers
2465
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
0 k=0 1 10 30 50 70 90 110 130 150
Dk n =
dM k n Otherwise
k + 178 – 177 k – 151
k + 177 – 149 k – 131
k + 176 – 129 k – 111
k + 175 – 109 k – 91
k + 174 – 89 k – 71
k + 173 – 69 k – 51
k + 172 – 49 k – 31
k + 171 – 29 k – 11
M k = k + 170 –9 k –2
k + 167 2 k 9
k + 166 11 k 29
k + 165 31 k 49
k + 164 51 k 69
k + 163 71 k 89
k + 162 91 k 109
k + 161 111 k 129
k + 160 131 k 149
k + 159 151 k 177
The header symbol uses p n with n = 1.
20.5.4 Performance requirements
20.5.4.1 Transmit requirements
20.5.4.1.1 Introduction
This subclause describes the performance requirement from the DMG OFDM mode transmitter.
20.5.4.1.2 Transmit EVM
The transmit EVM accuracy test shall be performed by instrumentation capable of converting the
transmitted signal into a stream of complex samples, with sufficient accuracy in terms of I/Q arm amplitude
and phase balance, dc offsets, phase noise, etc.
The sampled signal shall be processed in a manner similar to an actual receiver, according to the following
steps, or an equivalent procedure:
a) Start of frame shall be detected.
b) Transition from short sequences to channel estimation sequences shall be detected, and fine timing
(with one sample resolution) shall be established.
c) Frequency offsets shall be estimated and corrected.
d) The frame shall be de-rotated according to estimated frequency offset.
e) The complex channel response coefficients shall be estimated for each of the subcarriers using
information contained in the preamble (STF and/or CEF).
2466
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
f) For each of the OFDM symbols: transform the symbol into subcarrier received values, estimate the
phase from the pilot subcarriers, derotate the subcarrier values according to estimated phase, and
divide each subcarrier value with a complex estimated channel response coefficient.
g) For subcarrier, compute the Euclidean distance to the ideal location for the symbol, or pilot.
h) Compute the RMS average of all errors in a packet. It is given by
N SYM 2 2
Nf I i j k –I i j k + Q i j k –Q i j k
1-
----
j=1 k K
--------------------------------------------------------------------------------------------------------------------------------------------------
EVM = 20 log 10
Nf N ST – N DC N SYM P 0
i=1
where
Nf is the number of frames
i is the frame index
k is the carrier index
K is the set of pilot and data subcarriers {1,2, …, (NSR – 1), (NSR + NDC),
(NSR+NDC+1),…, NST}
j is the symbol index
N SYM is the number of symbols
N ST is the total number of subcarriers
I*,Q* is the ideal constellation point for I and Q, respectively
P0 is the average power of the constellation (I*,Q*) computed over the ith frame
The measurements shall occur only on the OFDM symbols, the measurement shall be performed on at least
10 frames with 16 symbols at least in each of them. Random data shall be used.
The EVM RMS error shall not exceed an MCS dependent value as found in Table 20-16.
Table 20-16—DMG OFDM mode EVM requirements
MCS index Modulation Coding rate EVM value [dB]
13 SQPSK 1/2 –7
14 SQPSK 5/8 –9
15 QPSK 1/2 –10
16 QPSK 5/8 –11
17 QPSK 3/4 –13
18 16-QAM 1/2 –15
19 16-QAM 5/8 –17
20 16-QAM 3/4 –19
21 16-QAM 13/16 –20
2467
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-16—DMG OFDM mode EVM requirements (continued)
MCS index Modulation Coding rate EVM value [dB]
22 64-QAM 5/8 –22
23 64-QAM 3/4 –24
24 64-QAM 13/16 –26
20.5.4.1.3 Tx flatness
When using the DMG OFDM mode and only while transmitting OFDM symbols, the average energy of the
OFDM Symbols constellations in each of the subcarriers with indices –146 to –2 and +2 to +145 shall
deviate no more than ± 2 dB from their average energy. The average energy of the constellations in each of
the subcarriers with indices –147 to –177 and +147 to +177 shall deviate no more than +2/–4 dB from the
average energy of subcarriers with indices –177 to –2 and +2 to +177.
20.5.4.1.4 Time of Departure accuracy
The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and
aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in
Annex P with the following test parameters:
6
— MULTICHANNEL_SAMPLING_RATE is 2640 10 sample/s
— FIRST_TRANSITION_FIELD is Short Training field
— SECOND_TRANSITION_FIELD is Channel Estimation field
— TRAINING_FIELD is Channel Estimation field
— TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns
NOTE—The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or
receiver.
20.5.4.2 Receive requirements
20.5.4.2.1 Introduction
Subclause 20.5.4.2 describes the performance requirement for an OFDM receiver.
20.5.4.2.2 CCA
The start of a valid DMG OFDM mode or DMG SC mode transmission at a receive level greater than the
minimum sensitivity for MCS 1 (–68 dBm) shall cause CCA to indicate busy with a probability >90%
within 1 µs.
20.6 DMG SC mode
20.6.1 Introduction
Transmission and reception of DMG SC mode PPDUs is mandatory for selected MCSs.
2468
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.6.2 PPDU format
A SC frame is composed of the Short Training field (STF), the channel estimation field (CE), the Header,
SC blocks and optional training fields, as shown in Figure 20-13.
Short Training field CE Header BLK BLK BLK BLK AGC subfields TRN subfields
Figure 20-13—SC frame format
20.6.3 Transmission
20.6.3.1 Header
20.6.3.1.1 General
In the DMG SC mode, the preamble is followed by the header. The header consists of several fields that
define the details of the PPDU to be transmitted. The encoding and modulation of the header is described in
20.6.3.1.4.
The header fields are described in Table 20-17.
Table 20-17—DMG SC mode header fields
Number
Field name Start bit Description
of bits
Scrambler 7 0 Bits X1–X7 of the initial scrambler state.
Initialization
Base MCS 5 7 Modulation and Coding Scheme (see Table 20-19)
Length 18 12 If the Extended SC MCS Indication field is 0, indicates the number
of data octets in the PSDU; range 1–262 143.
If the Extended SC MCS Indication field is 1, the Length field value
is set to Base_Length1 – Base_Length2 – N 4 , where N
is the number of data octets in the PSDU, and Base_Length1 and
Base_Length2 are computed according to Table 20-18. The number
of data octets in the PSDU shall not exceed 262 143.
Additional PPDU 1 30 Contains a copy of the parameter ADD-PPDU from the TXVEC-
TOR. A value of 1 indicates that this PPDU is immediately fol-
lowed by another PPDU with no IFS or preamble on the subsequent
PPDU. A value of 0 indicates that no additional PPDU follows this
PPDU.
Packet Type 1 31 Corresponds to the TXVECTOR parameter PACKET-TYPE.
— Packet Type = 0 (BRP-RX packet, see 20.10.2.2.3), indicates
either a PPDU whose data part is followed by one or more
TRN subfields (when the Beam Tracking Request field is 0 or
in DMG control mode), or a PPDU that contains a request for
TRN subfields to be appended to a future response PPDU
(when the Beam Tracking Request field is 1).
— Packet Type = 1 (BRP-TX packet, see 20.10.2.2.3), indicates a
PPDU whose data part is followed by one or more TRN sub-
fields. The transmitter may change AWV at the beginning of
each TRN subfield.
The field is reserved when the Training Length field is 0.
2469
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-17—DMG SC mode header fields (continued)
Number
Field name Start bit Description
of bits
Training Length 5 32 Corresponds to the TXVECTOR parameter TRN-LEN.
If the Beam Tracking Request field is 0, the Training Length field
indicates the length of the training field. The use of this field is
defined in 20.10.2.2.3. A value of 0 indicates that no training field
is present in this PPDU.
If the Beam Tracking Request field is 1 and the Packet Type field is
1, the Training Length field indicates the length of the training field
appended to this PPDU. If the Packet Type field is 0, the Training
Length field indicates the length of the training field requested for
receive training.
Aggregation 1 37 Set to 1 to indicate that the PPDU in the data portion of the packet
contains an A-MPDU; otherwise, set to 0.
Beam Tracking 1 38 Corresponds to the TXVECTOR parameter BEAM_TRACK-
Request ING_REQUEST.
Set to 1 to indicate the need for beam tracking (10.38.7); otherwise,
set to 0.
The Beam Tracking Request field is reserved when the Training
Length field is 0.
Last RSSI 4 39 Contains a copy of the parameter LAST_RSSI from the TXVEC-
TOR.
The value is an unsigned integer:
Values 2 to 14 represent power levels (–71+value×2) dBm.
A value of 15 represents a power greater than or equal to
–42 dBm.
A value of 1 represents a power less than or equal to –68 dBm.
A value of 0 indicates that the previous packet was not received a
SIFS before the current transmission.
Turnaround 1 43 As defined in Table 20-1.
Extended SC 1 44 The Extended SC MCS Indication field combined with the Base
MCS Indication MCS field indicates the MCS.
The Extended SC MCS Indication field indicates whether the
Length field shall be calculated according to Table 20-18.
Reserved 3 45
HCS 16 48 Header check sequence
All of the numeric fields are encoded in unsigned binary, least significant bit first.
Reserved bits are set to 0 by the transmitter and shall be ignored by the receiver.
If the Additional PPDU field is equal to 1, the Training Length field shall be set to 0.
When the MCS belongs to the set {9.1, 12.1, 12.2, 12.3, 12.4, 12.5, 12.6}, bits (X7, X6) of the initial
scrambler state are set to (Base_Length2 – N) mod 4, where N is the number of data octets in the PSDU, and
Base_Length2 is computed according to Table 20-18. Bits (X1–X5) are selected in a pseudorandom fashion
making sure that at least one bit in X1–X7 is nonzero.
2470
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
X1–X7 are sent in the Scrambler Initialization field, as defined in 20.6.3.1.4, and 20.6.3.2.2.
Table 20-18—Parameters for computing Length field value in SC header when
Extended SC MCS Indication field is set to 1
Base_Length1 Base_Length2
MCS
(See NOTEs 1 and 2) (See NOTEs 1 and 3)
9.1 N BLKS 4 N BLKS 56
------------------------ 42 --------------------------- 68.25
3 39
12.1 N BLKS 4 N BLKS 8
------------------------ 52.5 ------------------------ 68.25
3 3
12.2 N BLKS 4 N BLKS 112
------------------------ 63 ------------------------------ 68.25
3 39
12.3 N BLKS 4
------------------------ 68.25 N BLKS 210
3
12.4 N BLKS 8
------------------------ 42 N BLKS 252
3
12.5 N BLKS 8
------------------------ 52.5 N BLKS 273
3
12.6 N BLKS 8 N BLKS 56
------------------------ 63 --------------------------- 68.25
3 13
NOTE 1—NBLKS is the number of symbol blocks defined in 20.6.3.2.3.3.
NOTE 2—Base_Length1 is the maximum Length value such that the packet with the base
MCS specified in SC header has the given NBLKS.
NOTE 3—Base_Length2 is the maximum number of data octets in PSDU such that the packet
with the extended MCS has the given NBLKS.
20.6.3.1.2 Modulation and coding scheme
The modulation and coding scheme defines the modulation and code rate that is used in the PPDU. The
modulation and coding schemes for SC are defined in Table 20-19.
Table 20-19—DMG SC mode modulation and coding schemes
Extended
Base
SC MCS Code Data rate
MCS MCS Modulation NCBPS Repetition
Indication rate (Mb/s)
field
field
1 1 0 π/2-BPSK 1 2 1/2 385
2 2 0 π/2-BPSK 1 1 1/2 770
3 3 0 π/2-BPSK 1 1 5/8 962.5
2471
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-19—DMG SC mode modulation and coding schemes (continued)
Extended
Base
SC MCS Code Data rate
MCS MCS Modulation NCBPS Repetition
Indication rate (Mb/s)
field
field
4 4 0 π/2-BPSK 1 1 3/4 1155
5 5 0 π/2-BPSK 1 1 13/16 1251.25
6 6 0 π/2-QPSK 2 1 1/2 1540
7 7 0 π/2-QPSK 2 1 5/8 1925
8 8 0 π/2-QPSK 2 1 3/4 2310
9 9 0 π/2-QPSK 2 1 13/16 2502.5
9.1 6 1 π/2-QPSK 2 1 7/8 2695
10 10 0 π/2-16-QAM 4 1 1/2 3080
11 11 0 π/2-16-QAM 4 1 5/8 3850
12 12 0 π/2-16-QAM 4 1 3/4 4620
12.1 7 1 π/2-16-QAM 4 1 13/16 5005
12.2 8 1 π/2-16-QAM 4 1 7/8 5390
12.3 9 1 π/2-64-QAM 6 1 5/8 5775
12.4 10 1 π/2-64-QAM 6 1 3/4 6390
12.5 11 1 π/2-64-QAM 6 1 13/16 7507.5
12.6 12 1 π/2-64-QAM 6 1 7/8 8085
Transmit and receive support for MCS 4 and below is mandatory. Other MCSs are optional.
20.6.3.1.3 Generation of the HCS bits
Calculation of the HCS for bits 0–47 of the header is defined in 20.3.7.
20.6.3.1.4 Header encoding and modulation
The header is encoded using a two SC block of NSPB symbols with NGI guard symbols. The bits are
scrambled and encoded as follows:
1) The input header bits (B1, B2, …, BLH), where LH = 64, are scrambled as described in 20.3.9,
starting from the eighth bit. to create d1s=(q1,q2,…,qLH)
2) The LDPC codeword c = (q1,q2,…,qLH,01,02,…,0504-LH,p1,p2,…,p168) is created by concatenating
504-LH zeros to the LH bits of d1s and then generating the parity bits p1,p2,…,p168 such that HcT =
0, where H is the parity check matrix for the rate 3/4 LDPC code specified in 20.6.3.2.3.2.
3) Remove bits LH+1 to 504 and bits 665 to 672 of the codeword c to create the sequence
cs1=(q1,q2,…,qLH,p1,p2,…,p160).
4) Remove bits LH+1 to 504 and bits 657 to 664 of the codeword c to create the sequence cs2 =
(q1,q2,...,qLH,p1,p2,...,p152,p161,p162,...,p168) and then XOR with a PN sequence that is generated
2472
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
from the LFSR used for data scramblings defined in 20.3.9. The LFSR is initialized to the all 1s
vector.
5) cs1 and cs2 are concatenated to form the sequence (cs1, cs2). The resulting 448 bits are then mapped
as π/2-BPSK as described in 20.6.3.2.4.2. The NGI guard symbols are then prepended to the
resulting NCBPB symbols as described in 20.6.3.2.5.
The same resulting NCBPB symbols are multiplied by -1 and repeated, and then prepended with NGI guard
symbols as described in 20.6.3.2.5. The resulting sequence is then appended after the sequence created in
step 5).
20.6.3.2 Data field
20.6.3.2.1 General
The data field consists of the payload data of the PSDU and possible padding. The data are padded with
zeros, scrambled, encoded and modulated as described in the following subclauses. The amount of padding
is defined in 20.6.3.2.3.
20.6.3.2.2 Scrambler
The operation of the scrambler is defined in 20.3.9. The scrambling of the PSDU continues the scrambling
of the header with no reset of the scrambler.
20.6.3.2.3 Encoding
20.6.3.2.3.1 General
The data are encoded by a systematic LDPC encoder. The LDPC is a block code. Each block of information
bits (B1, B2,...,Bk) is concatenated with a block of parity bits (p1,p2,….,pn-k) to create a codeword c=(B1,
B2,...,Bk,p1,p2,….,pn-k) such that HcT=0, where H is the (n-k)×n parity check matrix. The block size n is
672 bits. The code rate, R, is equal to k/n. The set of code rates is defined in Table 20-20. The parity check
matrices are defined in 20.6.3.2.3.2. The encoding process is defined in 20.6.3.2.3.3.
Table 20-20—LDPC code rates
Code rate Codeword size Number of data bits
1/2 672 336
5/8 672 420
3/4 672 504
13/16 672 546
7/8 624 546
20.6.3.2.3.2 Parity check matrices
See 20.3.8.
2473
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.6.3.2.3.3 LDPC encoding process
The LDPC encoding process is composed of several steps that includes deciding the number of shortening/
repetition bits in every codeword, the shortening itself, the coding of each word and then any repetition of
bits.
a) First the total number of data pad bits NDATA_PAD is calculated, using the number of LDPC
codewords NCW:
Length 8
N CW = -------------------------
L CW
---------- R
if BRP packet and N CW N CWmin ; N CW = N CWmin
L CW
N DATA PAD = N CW ---------
- R – Length 8
where
LCW is the LDPC codeword length, which is 624 for code rate R=7/8, 672 for all other
code rates
Length is the length of the PSDU defined in the header field (in octets)
is the repetition factor (1 or 2)
R is the code rate
NCWmin is defined for BRP packets in Table 20-24.
The scrambled PSDU is concatenated with NDATA_PAD zeros. They are scrambled using the continu-
ation of the scrambler sequence that scrambled the PSDU input bits.
b) The procedure for converting the scrambled PSDU data to LDPC codewords depends on the
repetition factor.
1) If = 1 and the code rate is not 7/8,
i) The output stream of the scrambler is broken into blocks of LCWD = LCW ×R bits such that
m m m
the mth data word is b 1 b2 b LCWD m N CW .
m m m
ii) To each data word, n-k=LCW-R×LCW parity bits p 1 p2 p n – k are added to create
T
m m m m m m m
the codeword c = b1 b2 b L CWD p 1 p n – k such that Hc = 0
2) If = 1 and the code rate is 7/8, 48 bits are punctured from the parity bits of the rate 13/16
parity bits:
i) The output stream of the scrambler is broken into blocks of 546 bits such that the mth data
m m m
word is b 1 b2 b 546 m N CW .
m m m
ii) To each data word, 126 parity bits p 1 p2 p 126 are added to create the code word
T
m m m m m m m m
c̃ = b1 b2 b 546 p 1 p 126 such that Hc̃ = 0 . The code word c is
m
generated from c̃ by removing the first 48 parity bits so that
m m m m m m m
c = b1 b2 b 546 p 49 , p 50 p 126
2474
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
3) If ρ = 2,
i) The data bits in each codeword b 1 b 2 b LZ where L Z = L CW 2 are concatenated
with L CW 2 zeros to produce a sequence of length of 2LZ
b1 b2 b LZ 0 1 0 2 0 LZ .
ii) The LDPC codeword c = b 1 b 2 bLZ 0 1 0 2 0 LZ p 1 p 2 p 336 is created by
T
generating the parity bits p 1 p 2 p 336 such that Hc = 0 , where H is the parity
matrix for rate 1/2 LDPC coding specified in 20.3.8.
iii) Replace bits L Z + 1 to 336 of the codeword c with bits from the sequence b 1 b 2 bLZ
XORed by a PN sequence that is generated from the LFSR used for data scrambling as
defined in 20.3.9. The LFSR is initialized to the all 1s vector and reinitialized to the same
vector after every codeword.
c) The codewords are then concatenated one after the other to create the coded bits stream
c1 c2 c LCW NCW .
d) The number of symbol blocks, NBLKS, and the number of symbol block padding bits, NBLK_PAD, are
calculated:
N CW L CW
N BLKS = ------------------------
-
N CBPB
N BLK PAD = N BLKS N CBPB – N CW L CW
where NCBPB is the number of coded bits per symbol block, per Table 20-21 in 20.6.3.2.5.
e) The coded bit stream is concatenated with NBLK_PAD zeros. They are scrambled using the
continuation of the scrambler sequence that scrambled the PSDU input bits.
20.6.3.2.4 Modulation mapping
20.6.3.2.4.1 General
The coded and padded bit stream is converted into a stream of complex constellation points according to the
modulation specified in the MCS table.
20.6.3.2.4.2 π/2-BPSK modulation
In π/2-BPSK modulation, the input bit stream is mapped according to the following equation:
s̃ k = 2 c k – 1 , where ck is the kth input coded (or scrambled pad) bit. Each output symbol is then rotated
j k 2
according to the following equation: s k = s̃ k e . The constellation bit encoding for BPSK is depicted
in Figure 20-14.
NOTE—With appropriate choice of transmit filtering, π/2-BPSK is equivalent to a precoded pulse-shaped MSK (e.g.,
GMSK). The precoder is simply b out k = b in k b in k–1 k = 0 1 , where bin,k is the scrambled input stream,
bin,-1 is 0, bout,k is the input to the (G)MSK modulator.
2475
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
+i
0 1
-1 +1
-i
Figure 20-14—BPSK constellation bit encoding
20.6.3.2.4.3 π/2-QPSK modulation
In π/2-QPSK modulation, the input bit stream is grouped into sets of 2 bits and mapped according to the
1
following equation: s̃ k = ------- 2c 2 k – 1 + j 2c 2 k + 1 – 1 exp – j --- , where k is the output symbol index,
2 4
j k 2
k = 0, 1, …. Each output symbol is then rotated according to the following equation: s k = s̃ k e . The
constellation bit encoding for QPSK is depicted in Figure 20-15.
j
C(2k)=0,C(2k+1)=1
-1 1
C(2k)=0,C(2k+1)=0 C(2k)=1,C(2k+1)=1
-j
C(2k)=1,C(2k+1)=0
Figure 20-15—QPSK constellation bit encoding
20.6.3.2.4.4 π/2-16-QAM modulation
In π/2-16-QAM modulation, the input bit stream is grouped into sets of 4 bits and mapped according to the
following equation:
1
s̃ k = ---------- 4c 4 k – 2 – 2c 4 k – 1 2c 4 k + 1 – 1 + j 4c 4 k + 2 – 2 – j 2c 4 k + 2 – 1 2c 4 k + 3 – 1
10
2476
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where k is the output symbol index, k =0, 1, …. Each output symbol is then rotated according to the
j k 2
following equation: s k = s̃ k e . The constellation bit encoding for 16-QAM is depicted in
Figure 20-16.
Q c4kc4k+1c4k+2c4k+3
00 10 01 10 11 10 10 10
3
00 11 01 11 11 11 10 11
1
-3 -1 1 3
I
00 01 01 01 11 01 10 01
-1
00 00 01 00 11 00 10 00
-3
Figure 20-16—16-QAM constellation bit encoding
20.6.3.2.4.5 π/2-64-QAM modulation
In π/2-64-QAM modulation, the input bit stream is grouped in sets of 6 bits and mapped according to the
following equation:
s̃ k =
1
---------- 8c 6 k – 4 – 2c 6 k – 1 4c 6 k + 1 – 2 + 2c 6 k – 1 2c 6 k + 1 – 1 2c 6 k + 2 – 1 +
42
j-
--------- 8c 6 k + 3 – 4 – 2c 6 k + 3 – 1 4c 6 k + 4 – 2 + 2c 6 k + 3 – 1 2c 6 k + 4 – 1 2c 6 k + 5 – 1
42
where k is the output symbol index, k=0,1, …. Each output symbol is then rotated according to the following
j-------k-
2
equation s k = s̃ k e . The constellation bit encoding for 64-QAM is depicted in Figure 20-17.
2477
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Q c6kc6k+1c6k+2c6k+3c6k+4c6k+5
000 100 001 100 011 100 010 100 110 100 111 100 101 100 100 100
7
000 101 001 101 011 101 010 101 110 101 111 101 101 101 100 101
5
000 111 001 111 011 111 010 111 110 111 111 111 101 111 100 111
3
000 110 001 110 011 110 010 110 110 110 111 110 101 110 100 110
1
-7 -5 -3 -1 1 3 5 7
I
000 010 001 010 011 010 010 010 110 010 111 010 101 010 100 010
-1
000 011 001 011 011 011 010 011 110 011 111 011 101 011 100 011
-3
000 001 001 001 011 001 010 001 110 001 111 001 101 001 100 001
-5
000 000 001 000 011 000 010 000 110 000 111 000 101 000 100 000
-7
Figure 20-17—64-QAM constellation bit encoding
20.6.3.2.5 Symbol blocking and guard insertion
Each group of NCBPB bits is prepended by π/2-BPSK symbols generated by the 64 point Golay
sequence Ga64 defined in 20.11. NCBPB values are shown in Table 20-21. The starting index for the first
symbol for π/2 rotation is 0.
Table 20-21—Values of NCBPB
Symbol mapping NCBPB
π/2-BPSK 448
π/2-QPSK 896
π/2-16-QAM 1792
π/2-64-QAM 2688
If the Additional PPDU field within the PHY header is equal to 0, the final block transmitted is followed by
the same Golay sequence guard interval. See Figure 20-18. If the Additional PPDU field within the PHY
header is equal to 1, the final block transmitted of the last PPDU in an A-PPDU is followed by the same
Golay sequence guard interval.
2478
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
GI DATA GI DATA GI DATA GI
64 448 symbols 64 448 symbols 64 448 symbols 64
Figure 20-18—Block transmission
20.6.4 Performance requirements
20.6.4.1 Transmit requirements
20.6.4.1.1 Transmit EVM
The transmit EVM accuracy test shall be performed by instrumentation capable of converting the
transmitted signal into a stream of complex samples, with sufficient accuracy in terms of I/Q arm amplitude
and phase balance, dc offsets, phase noise, etc.
The instrumentation shall perform carrier lock, symbol timing recovery and amplitude adjustment and
equalization while making the measurements. The equalizer shall be trained using information in the SC
preamble (STF and/or CEF). For the DMG SC mode EVM, measuring Ns samples at the sample rate, the
measured symbols should not contain the first and the last hundred symbols of a given packet (ramp up/
down). The EVM is calculated according to the formula below:
Ns
1 2 2
EVM = 20 log 10 ---------------- Ii – Ii – I0 + Qi – Qi – Q0
N s P avg
i=1
where Ns is the number of samples to be measured and Ns shall be 1000, Pavg is the average power of the
constellation, I i Q i is the complex coordinates of the measured symbol i, I i Qi is the complex
coordinates of the ideal constellation point for the measured symbol i, and (Io, Qo) is the complex DC term
chosen to minimize EVM.
The test equipment should use a root-raised cosine filter with roll-off factor of 0.25 for the pulse shaping
filter when conducting EVM measurement.
The transmit pulse shaping used is left to the implementer.
The relative constellation error (EVM) shall not exceed an MCS dependent value according to Table 20-22.
Table 20-22—DMG SC mode EVM requirements
MCS Modulation Coding rate EVM value [dB]
1 π/2-BPSK 1/2 with repetition –6
2 π/2-BPSK 1/2 –7
3 π/2-BPSK 5/8 –9
4 π/2-BPSK 3/4 –10
5 π/2-BPSK 13/16 –12
2479
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-22—DMG SC mode EVM requirements (continued)
MCS Modulation Coding rate EVM value [dB]
6 π/2-QPSK 1/2 –11
7 π/2-QPSK 5/8 –12
8 π/2-QPSK 3/4 –13
9 π/2-QPSK 13/16 –15
9.1 π/2-QPSK 7/8 –16
10 π/2-16-QAM 1/2 –19
11 π/2-16-QAM 5/8 –20
12 π/2-16-QAM 3/4 –21
12.1 π/2-16-QAM 13/16 –22
12.2 π/2-16-QAM 7/8 –23
12.3 π/2-64-QAM 5/8 –26
12.4 π/2-64-QAM 3/4 –27
12.5 π/2-64-QAM 13/16 –29
12.6 π/2-64-QAM 7/8 –31
20.6.4.1.2 Time of Departure accuracy
The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and
aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in
Annex P with the following test parameters:
— MULTICHANNEL_SAMPLING_RATE is 1760x106 sample/s
— FIRST_TRANSITION_FIELD is Short Training field
— SECOND_TRANSITION_FIELD is Channel Estimation field
— TRAINING_FIELD is Channel Estimation field
— TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns
NOTE—The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or
receiver.
20.6.4.2 Receive requirements
20.6.4.2.1 Introduction
This subclause describes the receiver requirements of the DMG SC mode.
20.6.4.2.2 CCA
The start of a valid DMG SC mode transmission at a receive level greater than the minimum sensitivity for
MCS 1 (–68 dBm) shall cause CCA to indicate busy with a probability > 90% within 1 µs. The receiver shall
hold the carrier sense signal busy for any signal 20 dB above the minimum sensitivity for MCS 1.
2480
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.7 DMG low-power SC mode
20.7.1 Introduction
The DMG low-power SC mode is an optional SC mode that can provide lower processing power
requirements for DMG transceivers.
20.7.2 Transmission
20.7.2.1 Preamble
The DMG low-power SC mode uses the same preamble as the DMG SC mode.
20.7.2.2 Header
20.7.2.2.1 General
The DMG low-power SC mode header fields are the same fields as in the DMG SC mode (see Table 20-17
in 20.6.3.1).
The DMG low-power SC mode modulation and coding schemes are listed in Table 20-23.
Table 20-23—DMG low-power SC mode modulation and coding schemes
Effective Rate
MCS Modulation Coding scheme NCPB
code rate (Mb/s)
25 /2-BPSK 13/28 RS(224,208)+Block-Code(16,8) 392 626
26 /2-BPSK 13/21 RS(224,208)+Block-Code(12,8) 392 834
27 /2-BPSK 52/63 RS(224,208)+SPC(9,8) 392 1112
28 /2-QPSK 13/28 RS(224,208)+Block-Code(16,8) 392 1251
29 /2-QPSK 13/21 RS(224,208)+Block-Code(12,8) 392 1668
30 /2-QPSK 52/63 RS(224,208)+SPC(9,8) 392 2224
31 /2-QPSK 13/14 RS(224,208)+Block-Code(8,8) 392 2503
20.7.2.2.2 Header encoding and modulation
The DMG low-power SC mode header is encoded and modulated as defined in 20.6.3.1.4.
20.7.2.3 Data field
20.7.2.3.1 General
The data field consists of the payload data of the PSDU and possible padding. The data are padded with
zeros, scrambled, encoded and modulated as described in the following subclauses.
20.7.2.3.2 Scrambler
The operation of the scrambler is defined in 20.3.9. The scrambling of the PSDU continues the scrambling
of the header with no reset of the scrambler. The padding bits are also scrambled.
2481
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.7.2.3.3 Encoding
20.7.2.3.3.1 General
Data is encoded using an outer RS(224,208) block code and a short inner code. The inner code is a (16,8)
block code for MCSs 25 and 28, a (12,8) block code for MCSs 26 and 29, and a (9,8) single parity check
(SPC) block code for MCSs 27 and 30 and the identity block-code for MCS 31. The encoding is further
detailed in the following steps:
1) First, the number of block padding bits is calculated:
a) The total number of Reed Solomon codewords is N RS = Length 208 and the total
number of RS encoded symbols is given by Length + N RS 16 ;
b) After Reed Solomon encoding, the data is encoded with a short block code (N,8) where N
can take one of the following values 8, 9, 12, or 16 depending on the MCS as shown in
Table 20-23. Therefore:
i) The total number of encoded bits is N EB = N Length + N RS 16 ;
ii) The total number of 512 (in length) blocks (each containing 392 data symbols) is
N BLKS = N EB N CBPS 392 . If BRP packet and
N BLKS N BLKS_MIN ; N BLKS = N BLKS_MIN , where N BLKS MIN = 18 . The total number of
zero block padding bits is N BLK PAD = N BLKS N CBPS 392 – N EB .
2) The data is broken into blocks of length 208×8 bits (except for possibly the last block).
3) Each block is encoded using the RS(224,208) block code as described in 20.7.2.3.3.2, except
perhaps the last block, which is encoded by a shortened version of the code (i.e., if the last block
length is K, the shortened block code is RS(16+K,K).
4) The Reed Solomon encoded data stream is further encoded using the block code(N,8) as described
in 20.7.2.3.3.3.
5) The coded bit stream is concatenated with N BLK _ PAD zeros. They are scrambled with the
continuation of the scrambler sequence that scrambled the PSDU input bits.
6) Each set of 7 octets is interleaved using a uniform interleaver of 7 rows and 8 columns. The 7 octets
are written row wise and read column wise, i.e., the index i of a bit after interleaving is related to the
index k of a bit before interleaving by the following rule:
i = 8 k mod 7 + k 7 k = 0 1 55 .
7) The resulting bit stream is modulated and then blocked as described in 20.7.2.3.4 and 20.7.2.3.5.
20.7.2.3.3.2 RS encoding
The RS block code is based on the polynomial
16
k
g x = x+a
k=1
2 3 4 8
where a = 0x02 is a root of the primitive polynomial p x = 1 + x + x + x + x . We assume that an
octet b 0 b 1 b 2 b 3 b 4 b 5 b 6 b 7 (b0 is the LSB) represented by the polynomial
7 6 5 4 3 2
M = b7 x + b6 x + b5 x + b4 x + b3 x + b2 x + b1 x + b0 .
2482
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The RS is a systematic block code. Given a block of octets m = m M – 1 m M – 2 m0 , the additional
15
16 k
parity octets r = r 15 r 14 r 0 are calculated by setting r = x m x mod g x , where r x = rk x
k=0
M–1
k 8
and m x = mk x and where the calculation is performed over GF 2 . The parity octets r are
k=0
appended to the uncoded block m to generate the encoded RS block m M – 1 m M – 2 m 0 r 15 r 14 r0 .
20.7.2.3.3.3 (N,8) Block-coding
Every octet b 1 8 = b 0 b 1 b 2 b 3 b 4 b 5 b 6 b 7 is encoded into an N-bit codeword c 1 N = b1 8 p1 N–8
such that c 1 N = b1 8G8 N, where the generator matrix G 8 N is given by the following expressions for
N = 8, 9, 12, and 16, respectively:
G8x8 is the identity matrix.
1 0 0 0 0 0 0 0 1
0 1 0 0 0 0 0 0 1
0 0 1 0 0 0 0 0 1
G8 9 = 0 0 0 1 0 0 0 0 1
0 0 0 0 1 0 0 0 1
0 0 0 0 0 1 0 0 1
0 0 0 0 0 0 1 0 1
0 0 0 0 0 0 0 1 1
1 0 0 0 0 0 0 0 1 1 0 0
0 1 0 0 0 0 0 0 1 0 1 0
0 0 1 0 0 0 0 0 0 1 0 1
G8 12 = 0 0 0 1 0 0 0 0 0 0 1 1
0 0 0 0 1 0 0 0 1 0 1 1
0 0 0 0 0 1 0 0 1 1 0 1
0 0 0 0 0 0 1 0 1 1 1 0
0 0 0 0 0 0 0 1 0 1 1 1
1 0 0 0 0 0 0 0 0 1 1 0 1 0 1 0
0 1 0 0 0 0 0 0 0 0 1 1 0 1 0 1
0 0 1 0 0 0 0 0 1 0 0 1 1 0 1 0
G8 16 = 0 0 0 1 0 0 0 0 0 1 0 0 1 1 0 1
0 0 0 0 1 0 0 0 1 0 1 0 0 1 1 0
0 0 0 0 0 1 0 0 0 1 0 1 0 0 1 1
0 0 0 0 0 0 1 0 1 0 1 0 1 0 0 1
0 0 0 0 0 0 0 1 1 1 0 1 0 1 0 0
2483
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.7.2.3.4 Modulation
The same π/2-BPSK described in 20.6.3.2.4.2 and π/2-QPSK described in 20.6.3.2.4.2 are used in the DMG
low-power SC mode.
20.7.2.3.5 Blocking
The blocking for the low-power SC is illustrated in Figure 20-19. The data is partitioned into blocks of
length 512 wherein each 512-block is constructed from 8 subblocks. Each subblock is of length 64. The first
subblock is a G64, which is the π/2-BPSK symbols sequence generated by the 64 point Golay sequence Ga64
defined in 20.11. The starting index for the first symbol π/2 rotation is 0, and subblocks 2 to 8 are
constructed in the same way, i.e., a data portion of 56 symbols followed by a guard interval of 8 symbols.
Note that each 512-block carries 392 symbols of data and 120 symbols of guard.
Sub-block1 Sub-block2 Sub-block3 Sub-block8
Ga64 d56 G8 d56 G8 ... d56 G8
Block -1
512 chips
Block -2
512 chips
Block -3
512 chips
... Block -N
512 chips
Ga64
Figure 20-19—Blocking for DMG low-power SC mode
If the Additional PPDU field within the PHY header is equal to 0, the final block transmitted is followed by
Ga64. If the Additional PPDU field within the PHY header is equal to 1, the final block transmitted of the
last PPDU in an A-PPDU is followed by Ga64.
The G8 guard interval is a copy of the last 8 samples of Ga64.
NOTE—A STA might estimate the channel impulse response from the CEF, and decides whether to equalize using the
512-block or the short 64-subblock. For example, if the channel impulse response energy is almost concentrated in
8 taps, a 64-equalizer can be used; otherwise, a 512-equalizer is used.
20.8 PHY transmit procedure
The PHY transmit procedure is shown in Figure 20-20. In order to transmit data, a PHY-TXSTART.request
primitive shall be enabled so that the PHY entity shall be in the transmit state. Further, the PHY shall be set
to operate at the appropriate frequency through station management via the PLME, as specified in 20.12.
Other transmit parameters, such as MCS and transmit power, are set via the PHY SAP with the PHY-
TXSTART.request(TXVECTOR) primitive, as described in 20.2.2.
Transmission of the PHY preamble may start if TIME_OF_DEPARTURE_REQUESTED is false, and shall
start immediately if TIME_OF_DEPARTURE_REQUESTED is true, based on the parameters passed in the
PHY-TXSTART.request primitive.
2484
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PHY-TXSTART.confirm
PHY-TXHEADEREND
PHY-TXEND.request
PHY-TXSTART.request
PHY-DATA.request
PHY-DATA.request
PHY-TXEND.confirm
PHY-DATA.confirm
PHY-DATA.confirm
.indication
(TXVECTOR)
MPDU
Header PSDU
Scrambling + encoding
Bit Padding
IF needed
STF + CE Header C-PSDU AGC TRN
STF+CE Header Data (Variable length) AGC TRN
DMG control mode bits, SC blocks or OFDM symbols
Figure 20-20—PHY transmit procedure
The preamble format (control, SC, or OFDM mode) depend on the MCS in the PHY-TXSTART.request.
The PHY shall calculate the length of the packet according the MCS and the length specified in the
PHY-TXSTART.request primitive, adding padding bits if necessary.
The PHY continues with the encoding and transmission of the header according to the parameters of the
PHY-TXSTART.request(TXVECTOR) primitive. The PHY proceeds with PSDU transmission through a
series of data octet transfers from the MAC. The data are encoded as described in 20.4.3.2.3, 20.5.3.2.3, and
20.6.3.2.3. The encoded data are then modulated as described in 20.4, 20.5, 20.6, and 20.7, depending on the
MCS requested in the PHY-TXSTART.request primitive. Transmission can be prematurely terminated by
the MAC through the PHY-TXEND.request primitive. PHY-TXSTART shall be disabled by receiving a
PHY-TXEND.request primitive.
Transmission of the PSDU is completed with the transmission of the last bits of the (encoded) PSDU. If no
TRN-T/R fields are specified in the PHY-TXSTART.request primitive, the PHY shall issue a PHY-
TXEND.confirm primitive after the transmission of the last bits. If TRN units are requested in the PHY-
TXSTART.request primitive, the transmission continues with the transmission of AGC subfields and TRN
units. The PHY issues the PHY-TXEND.confirm primitive to the MAC after the transmission of the last
TRN unit. The packet transmission shall be completed, and the PHY entity shall enter the receive state (i.e.,
PHY-TXSTART shall be disabled). Each PHY-TXEND.request primitive is acknowledged with a PHY-
TXEND.confirm primitive from the PHY.
A typical transmit state machine is shown in Figure 20-21.
2485
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Initialize
MCS=0
Set TX parameters
MCS>0
Tx DMG SC/ Tx DMG control
OFDM mode STF mode STF
120 Length >0
Prepare OFDM
Prepare SC data Tx CP header
data
Get PSDU Octet Get PSDU Octet
Encode and
Decrement Octets Decrement Octets
Transmit CP
in CW in CW
header word.
Decrement Length Decrement Length
CW Zero Pad CW Zero Pad Prepare CP data
Pad with zeros to Pad with zeros to
Get PSDU Octet
Ncs>0 a full CW if Ncw>1 a full CW if
Ncw>0 Decrement Length
necessary necessary
TX OFDM Data TX SC Data TX CP data
Encode and TX Encode and TX Encode and
OFDM LDPC code SC LDPC code transmit CP LDPC
word, decrement Ncw>1 word, decrement code word.
NCW NCW Decrement Ncw
Ncw=0 Ncw=0
BLK Zero Pad
Pad with zeros to
a full SC blk if
necessary
Switch RX state
Figure 20-21—Typical Tx state machine (Training Length = 0 is assumed;
some optional features such as DMG SC low-power mode are not shown)
2486
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.9 PHY receive procedure
A typical PHY receive procedure is shown in Figure 20-22.
CS/CCA state RX state
PHY_RXSTART.indication
PHY_RXEND.indication
PHY_CCA.indication
PHY_DATA.indication
PHY_DATA.indication
PHY_CCA.indication
(STATE=busy)
(RXVECTOR)
(NoError)
(IDLE)
MPDU
Header PSDU
Decoded and descrambled
Issued at the
same time
Bit Padding
Header C‐PSDU
IF needed
Determine PHY type
Measure Channel
Measure RSSI
STF CE Header Data (Variable length) AGC TRN
DMG Control mode bits, SC blocks or OFDM symbols
Figure 20-22—PHY receive procedure
Upon receiving the STF, the PHY measures signal strength. This activity is indicated by the PHY to the
MAC by issuing a PHY-CCA.indication(BUSY) primitive.
After the PHY-CCA.indication(BUSY) primitive is issued, the PHY entity shall search for the CE field and
begin receiving the CE field. The PHY demodulates the header according to the PHY type determined the
reception of the CE field. If the CE field indicated a SC mode, the receiver is capable of receiving low-
power SC mode, and dot11LowPowerSCPHYActivated is true, then the PHY shall attempt to demodulate
both a SC header and an SC low-power header. The PHY shall decode the header and determine the MCS,
length and other parameters needed for the demodulation of the packet.
Subsequently, if dot11TimingMsmtActivated is true, a PHY-RXSTART.indication(RXVECTOR) primitive
shall be issued and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be
forwarded (see 20.2.2).
NOTE—The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the
start of the preamble for the incoming frame was detected on the medium at the receive antenna connector.
At the end of the data portion of a packet that has the Training Length field in the PHY header equal to 0, the
PHY shall issue a PHY-RXEND.indication(No_Error) primitive to the MAC. If the Training Length field in
the PHY header is greater than 0, the PHY shall continue to receive these training fields after the data
2487
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
portion of the packet and measure the channel. After the end of the training fields, the PHY shall generate a
PHY-CCA.indication(IDLE) primitive and the PHY-RXEND.indication(NoError) primitive.
In the case of signal loss before the decoding of the header or in the case of an invalid header, the PHY shall
not generate a PHY-CCA.indication(IDLE) primitive until the received level drops below a value that is
20 dB higher than the receive sensitivity of MCS 1. In the case of signal loss after decoding of a valid
header, the PHY shall not generate a PHY-CCA.indication(IDLE) primitive until the expected end of the
packet, including AGC and TRN fields.
A typical receive state machine is shown in Figure 20-23.
20.10 Beamforming
20.10.1 Beamforming concept
Beamforming enables a pair of STAs to train their transmit and receive antennas for subsequent
communication. A beamformed link is established following the successful completion of BF training,
which is described in 10.38.
DMG STAs use a quasi-omni antenna pattern. The antenna gain of the main beam of a quasi-omni antenna
pattern shall be at most 15 dB lower than the antenna gain in the main beam for a directional pattern.
20.10.2 Beamforming frame format
20.10.2.1 Sector-level sweep
PPDUs transmitted during transmit sector sweep are DMG control mode PPDUs. PPDUs transmitted during
receive sector sweep are DMG control mode or DMG SC mode PPDUs.
20.10.2.2 Beam refinement
20.10.2.2.1 General
Beam refinement is a process where a STA can improve its antenna configuration (or antenna weight
vectors) both for transmission and reception. If the SLS beamforming training did not include an RSS, as in
the case where both devices have more than one transmit sector per antenna, beam refinement can serve as
the first receive antenna configuration training. The procedure of beam refinement is described in 10.38.6.4.
In the beam refinement procedure, BRP packets are used to train the receiver and transmitter antenna. There
are two types of BRP packets: BRP-RX packets and BRP-TX packets:
— BRP-RX packets are packets that have TRN training subfields appended to them. These packets
enable receiver antenna weight vector training.
— BRP-TX packets are packets that have TRN training subfields appended to them. The transmitting
STA may change antenna configuration at the beginning of each subfield. The receiving STA per-
forms measurements on these subfields and sends feedback to the STA that transmits the BRP-TX
packet.
20.10.2.2.2 BRP packet structure
The TRN-LEN parameter in the TVXVECTOR or RXVECTOR of a BRP packet shall be greater than zero.
If the PACKET-TYPE parameter in the RXVECTOR or TXVECTOR is equal to TRN-R-PACKET, then
the BEAM_TRACKING_REQUEST parameter in the corresponding RXVECTOR or TXVECTOR shall be
set to Beam Tracking Not Requested.
2488
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Rx Idle DMG control mode STF
CCA/CS
DMG SC/OFDM mode STF
Bad CRC
SC/OFDM STF
CP CCA STF
Detect CE type
Process CEF
SC CEF
OFDM CEF
PHY-CCA.indication
(IDLE)
Rx OFDM Rx CP Header
Rx SC Header
Header BLK
Bad CRC Bad CRC
Check CRC Check CRC Check CRC
PHY-CCA.indication
(IDLE)
CRC OK CRC OK CRC OK
Rx OFDM End of Packet
Header Nbit=0 Rx SC Header Wait
Rx Bit
TRN Length>0
Wait until End of Decrement
Supported MCS Supported MCS
Packet Time Coded bit counter
Unsupported
MCS
Signal Lost
Nbits>0
Nbit=0
PHY-RXEND.indication TRN Length>0
Rx Symbol Rx BLK
(Carrier Lost)
Signal Lost
Signal Lost
Sym CNT>0
BLK CNT>0
Decode Symbol Decode BLK
Decode and Decode and
Descramble. Descramble.
Decrement Length Decrement Length
Sym CNT=0 BLK CNT=0
TRN Length>0 TRN Length>0
TRN
Process AGC and
TRN-R/T fields.
SYM CNT=0 BLK CNT=0
TRN Length=0 TRN Length=0 Nbit=0
End of PSDU TRN Length=0
PHY-RXEND.indica-
tion (No_error)
PHY-CCA.indication
(IDLE)
Figure 20-23—Typical Rx state machine
(some optional features such as DMG low-power SC mode are not shown)
2489
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Each BRP packet is composed of an STF, a CE field, and a data field followed by a training field containing
an AGC training field and a TRN field. This is shown in Figure 20-24.
STF
STF CE
CE Header
Header Data
Data AGC
AGC TRN
TRN field
field
TRN
TRN TRN
TRN TRN
TRN TRN
TRN TRN
TRN TRN
TRN TRN
TRN TRN
TRN
CE
CE CE
CE
subfield
subfield subfield
subfield subfield
subfield subfield
subfield subfield
subfield subfield
subfield subfield
subfield subfield
subfield
TRN-Unit
Figure 20-24—BRP packet structure
20.10.2.2.3 BRP packet header fields
The Packet Type and Training Length fields present within the SC mode header, control mode header, LP
SC mode header, and OFDM mode header are used to indicate that a packet is BRP packet and the length of
the training fields, respectively.
A value of 0 in the Packet Type field and a value of 0 in the Beam Tracking Request field indicate a BRP-
RX packet.
A value of 1 in the Packet Type field indicates a BRP-TX packet.
A value of N in the Training Length field indicates 4×N AGC subfields and that the TRN-R/T field has N
TRN-Units.
The value N in the Training Length field of a BRP-RX packet is equal to the value of the L-RX field
requested by the intended receiver of the BRP-RX packet at a previously received BRP Request field
(see 9.5.4).
20.10.2.2.4 BRP packet duration
The minimum duration of the data field of a BRP packet when sent in an SC mode is aBRPminSCblocks SC
blocks (see 20.6.3.2.5) and, if needed, the data field of the packet shall be extended by extra zero padding to
generate the required number of SC blocks. Table 20-24 contains the values of NCWmin for each MCS
necessary to compute the padding described in 20.6.3.2.3.3.
The minimum duration of the data field of a BRP packet when sent in an DMG OFDM mode is
aBRPminOFDMblocks OFDM blocks and, if needed, the data field of the packet shall be extended by extra
zero padding to generate the required number of OFDM symbols.
The minimum duration of the data field of a BRP packet when sent with the low-power SC mode is
NBLKS_MIN low-power SC blocks (see 20.7.2.3.3).
2490
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-24—Zero filling for DMG SC mode BRP packets
Data rate
MCS index Modulation NCBPS Repetition Code rate NCWmin
(Mb/s)
1 π/2-BPSK 1 2 1/2 385 12
2 π/2-BPSK 1 1 1/2 770 12
3 π/2-BPSK 1 1 5/8 962.5 12
4 π/2-BPSK 1 1 3/4 1155 12
5 π/2-BPSK 1 1 13/16 1251.25 12
6 π/2-QPSK 2 1 1/2 1540 23
7 π/2-QPSK 2 1 5/8 1925 23
8 π/2-QPSK 2 1 3/4 2310 23
9 π/2-QPSK 2 1 13/16 2502.5 23
9.1 π/2-QPSK 2 1 7/8 2695 25
10 π/2-16-QAM 4 1 1/2 3080 46
11 π/2-16-QAM 4 1 5/8 3850 46
12 π/2-16-QAM 4 1 3/4 4620 46
12.1 π/2-16-QAM 4 1 13/16 5005 46
12.2 π/2-16-QAM 4 1 7/8 5390 49
12.3 π/2-64-QAM 6 1 5/8 5775 69
12.4 π/2-64-QAM 6 1 3/4 6930 69
12.5 π/2-64-QAM 6 1 13/16 7507.5 69
12.6 π/2-64-QAM 6 1 7/8 8085 74
20.10.2.2.5 AGC field
The beam refinement AGC fields are composed of 4N repetitions of the sequence [Ga64 Ga64 Ga64 Ga64
Ga64] when the packet is transmitted using the OFDM or SC mode and [Gb64 Gb64 Gb64 Gb64 Gb64] when
the packet is transmitted using the control mode. The sequences Ga64 and Gb64 are defined in 20.11. The
sequences are transmitted using rotated π/2-BPSK modulation. Any transmit signal transients that occur due
to this TX AWV configuration change shall completely settle by the end of the first Ga64 or Gb64
subsequence.
In a BRP-TX packet, the transmitter may change the TX AWV configuration at the beginning of each AGC
subfield. The set of AWVs used for the AGC subfields should be the same as that used for the TRN-T
subfields. In a BRP-RX packet, the transmitter shall use the same TX AWV as in the preamble and data
fields of the packet.
20.10.2.2.6 TRN field
The TRN field enable transmitter and receiver AWV training. The TRN field has the form shown in
Figure 20-25.
2491
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
CE TRN1 TRN2 TRN3 TRN4 CE TRN5 TRN6 TRN7 TRN8 …
TRN-Unit TRN-Unit
Figure 20-25—TRN field definition
The TRN field is composed of N TRN-Units. Each TRN-Unit is composed of a CE subfield and 4 TRN
subfields. Each subfield CE matches the Channel Estimation field defined in 20.3.6.3. The 4N subfields
TRN1 through TRN4N each consist of the sequence [Ga128 –Gb128 Ga128 Gb128 Ga128]. The sequences
Ga128 and Gb128 are defined in Table 20-25 and Table 20-26, respectively, in 20.11. The sequences are
transmitted using rotated π/2-BPSK modulation.
In a BRP-RX packet, all of the TRN and CE subfields are transmitted using the same AWV as the preamble
and data field of the packet. In a BRP-TX packet, the CE subfield shall be transmitted using the same AWV
as the preamble and data field of the packet. In a BRP-TX packet, the transmitter may change AWV at the
beginning of each TRN subfield. Any transmit signal transients that occur due to TX AWV configuration
changes at the beginning of TRN subfields shall settle by the end of the first 64 samples of the subfield.
20.10.2.2.7 Channel measurement
The good autocorrelation properties of the Golay sequence enable reconstructing part of the impulse
response of the channel between the transmitter and the receiver. The receiver should find the tap with
largest amplitude in the channel during the CE field of the BRP-RX. It selects thereafter the set of taps that
is measured around the tap with the largest amplitude, according to dot11ChanMeasFBCKNtaps. It can
select a contiguous set of taps or select a noncontiguous set of taps, and include the tap delays subfield as
part of the subfield measurement. It then measures the phase and amplitude of the corresponding channel
taps in each of the TRN-T field repetition (except for those using the CE AWV configuration). The beam
refinement feedback subfield k-1 is the relative amplitude and phase of this tap in the k’th repetition
compared to this tap in the first TRN-T subfield.
20.10.2.2.8 BRP resampling in an OFDM packet
The BRP AGC, CE, and Tn/Rn fields are specified at the SC chip rate (Tc). When appended to an OFDM
packet, the signal is resampled as defined in 20.3.3.2.
20.11 Golay sequences
The following Golay sequences are used in the preamble, in the single carrier guard interval and in beam
refinement TRN-R/T and AGC fields: Ga128(n), Gb128(n), Ga64(n), Gb64(n), Ga32(n), Gb32(n). These are 3
pairs of complementary sequences. The subscript denotes the length of the sequences. These sequences are
generated using the following recursive procedure:
A0 n = n
B0 n = n
Ak n = Wk Ak – 1 n + Bk – 1 n – Dk
Bk n = Wk Ak – 1 n – Bk – 1 n – Dk
k
Note that A k n B k n are zero for n < 0 and for n 2 .
2492
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Ga128(n)=A7(128-n), Gb128(n)=B7(128-n) when the procedure uses Dk = [1 8 2 4 16 32 64] (k=1,2,…,7) and
Wk = [–1 –1 –1 –1 +1 –1 –1].
Ga64(n)=A6(64-n), Gb64(n)=B6(64-n) when the procedure uses Dk= [2 1 4 8 16 32] and Wk =[1 1 -1 -1 1 -1].
Ga32(n)=A5(32-n), Gb32(n)=B5(32-n) when the procedure uses Dk=[1 4 8 2 16] and Wk =[-1 1 -1 1 -1].
The sequences are defined in Table 20-25, Table 20-26, Table 20-27, Table 20-28, Table 20-29, and
Table 20-30. The sequences in the tables are normative, the description above is informative.
Table 20-25—The sequence Ga128(n)
The Sequence Ga128(n), to be transmitted from left to right, up to down
+1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 +1 +1 -1 -1 +1 +1 +1 +1 -1 +1 -1 +1 -1 +1 +1 -1
-1 -1 +1 +1 +1 +1 +1 +1 +1 -1 +1 -1 -1 +1 +1 -1 +1 +1 -1 -1 +1 +1 +1 +1 -1 +1 -1 +1 -1 +1 +1 -1
+1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 +1 +1 -1 -1 +1 +1 +1 +1 -1 +1 -1 +1 -1 +1 +1 -1
+1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 -1 -1 +1 +1 -1 -1 -1 -1 +1 -1 +1 -1 +1 -1 -1 +1
Table 20-26—The sequence Gb128(n)
The Sequence Gb128(n), to be transmitted from left to right, up to down
-1 -1 +1 +1 +1 +1 +1 +1 +1 -1 +1 -1 -1 +1 +1 -1 -1 -1 +1 +1 -1 -1 -1 -1 +1 -1 +1 -1 +1 -1 -1 +1
+1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 -1 -1 +1 +1 -1 -1 -1 -1 +1 -1 +1 -1 +1 -1 -1 +1
+1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 +1 +1 -1 -1 +1 +1 +1 +1 -1 +1 -1 +1 -1 +1 +1 -1
+1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 -1 -1 +1 +1 -1 -1 -1 -1 +1 -1 +1 -1 +1 -1 -1 +1
Table 20-27—The sequence Ga64(n)
The Sequence Ga64(n), to be transmitted from left to right, up to down
-1 -1 +1 -1 +1 -1 -1 -1 +1 +1 -1 +1 +1 -1 -1 -1 -1 -1 +1 -1 +1 -1 -1 -1 -1 -1 +1 -1 -1 +1 +1 +1
-1 -1 +1 -1 +1 -1 -1 -1 +1 +1 -1 +1 +1 -1 -1 -1 +1 +1 -1 +1 -1 +1 +1 +1 +1 +1 -1 +1 +1 -1 -1 -1
Table 20-28—The sequence Gb64(n)
The sequence Gb64(n), to be transmitted from left to right, up to down
+1 +1 -1 +1 -1 +1 +1 +1 -1 -1 +1 -1 -1 +1 +1 +1 +1 +1 -1 +1 -1 +1 +1 +1 +1 +1 -1 +1 +1 -1 -1 -1
-1 -1 +1 -1 +1 -1 -1 -1 +1 +1 -1 +1 +1 -1 -1 -1 +1 +1 -1 +1 -1 +1 +1 +1 +1 +1 -1 +1 +1 -1 -1 -1
Table 20-29—The sequence Ga32(n)
The Sequence Ga32(n), to be transmitted from left to right
+1 +1 +1 +1 +1 -1 +1 -1 -1 -1 +1 +1 +1 -1 -1 +1 +1 +1 -1 -1 +1 -1 -1 +1 -1 -1 -1 -1 +1 -1 +1 -1
Table 20-30—The sequence Gb32(n)
The Sequence Gb32(n), to be transmitted from left to right
-1 -1 -1 -1 -1 +1 -1 +1 +1 +1 -1 -1 -1 +1 +1 -1 +1 +1 -1 -1 +1 -1 -1 +1 -1 -1 -1 -1 +1 -1 +1 -1
2493
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
20.12 DMG PLME
20.12.1 PLME SAP sublayer management primitives
Table 20-31 lists the MIB attributes that may be accessed by the PHY entities and the intra-layer of higher
level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME-
CHARACTERISTICS primitives defined in 6.5.
20.12.2 DMG PHY MIB
All DMG PHY MIB attributes are defined in Annex C, with specific values defined in Table 20-31. The
column titled “Operational semantics” in Table 20-31 contains two types: static and dynamic. Static MIB
attributes are fixed and cannot be modified for a given PHY implementation. Dynamic MIB attributes can
be modified by some management entity.
Table 20-31—DMG PHY MIB attribute default values
Default Operational
Managed object
value/range semantics
dot11PHYOperationTable
dot11PHYtype DMG Static
dot11PHYDMGTable
dot11LowPowerSCPHYImplemented Boolean Static
dot11LowPowerSCPHYActivated Boolean Dynamic
20.12.3 TXTIME calculation
The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated
according to the following equations.
For the DMG OFDM mode and for the DMG SC mode (NTRN is Training Length field defined in the header
– see, for example, Table 20-13):
TXTIME
T STF + T CE + T header + T Data N TRN = 0
= T STF + T CE + T header + max T Data + T C + N TRN T TRN – Unit N TRN 0 and SC
T STF + T CE + T header + max T Data T SYM + N TRN T TRN – Unit N TRN 0 and OFDM
where
α = aBRPminSCblocks
β = aSCBlockSize
γ = aSCGILength
δ = aBRPminOFDMblocks
T TRN – Unit = aBRPTRNBlock T C
2494
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For the DMG control mode:
TXTIME
= T STF – CP + T CE – CP + 11 8 + Length – 6 8 + N CW 168 TC 32 + N TRN T TRN – Unit
where NCW calculation is defined in 20.4.3.3.3.
20.12.4 DMG PHY
The static DMG PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive,
shall be as shown in Table 20-32. The definitions for these characteristics are given in 6.5.4.
Table 20-32—DMG PHY characteristics
PHY parameter Value
aRIFSTime 1 µs
aSIFSTime 3 µs
aRxPHYDelay Implementation dependent, see 10.3.7.
aRxTxTurnaroundTime Implementation dependent, see 10.3.7.
aCCATime Implementation dependent, see 10.3.7.
aRxTxSwitchTime Implementation dependent, see 10.3.7.
aRxPHYStartDelay DMG control mode: 10 µs; DMG SC and SC low-
power modes: 3.6 µs; DMG OFDM mode: 3.3 µs
aMACProcessingDelay Implementation dependent, see 10.3.7.
aTxPHYDelay Implementation dependent, see 10.3.7.
aTxRampOnTime Implementation dependent, see 10.3.7.
aDataPreambleLength 1891 ns
aControlPHYPreambleLength 4291 ns
aSBIFSTime 1 µs
aSBIFSAccuracy 0.03 µs
aAirPropagationTime 100 ns
aDMGDetectionThres –48 dBm
aBRPIFS 40 µs
aSlotTime 5 µs
aCWmin 15
aCWmax 1023
aBRPminSCblocks 18
aBRPminOFDMblocks 20
aBRPTRNBlock 4992
2495
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 20-32—DMG PHY characteristics (continued)
PHY parameter Value
aSCGILength 64
aSCBlockSize 512
aPPDUMaxTime 2 ms
aPSDUMaxLength 262 143 octets
2496
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21. Very high throughput (VHT) PHY specification
21.1 Introduction
21.1.1 Introduction to the VHT PHY
Clause 21 specifies the PHY entity for a very high throughput (VHT) orthogonal frequency division
multiplexing (OFDM) system.
In addition to the requirements in Clause 21, a VHT STA shall be capable of transmitting and receiving
PPDUs that are compliant with the mandatory PHY specifications defined in Clause 19.
The VHT PHY is based on the HT PHY defined in Clause 19, which in turn is based on the OFDM PHY
defined in Clause 17. The VHT PHY extends the maximum number of space-time streams supported to
eight and provides support for downlink multi-user (MU) transmissions. A downlink MU transmission
supports up to four users with up to four space-time streams per user with the total number of space-time
streams not exceeding eight.
NOTE—MU transmission is different from VHT SU group addressed transmission.
The VHT PHY provides support for 20 MHz, 40 MHz, 80 MHz, and 160 MHz contiguous channel widths
and support for 80+80 MHz noncontiguous channel width.
The VHT PHY data subcarriers are modulated using binary phase shift keying (BPSK), quadrature phase
shift keying (QPSK), 16-quadrature amplitude modulation (16-QAM), 64-QAM, and 256-QAM. Forward
error correction (FEC) coding (convolutional or LDPC coding) is used with coding rates of 1/2, 2/3, 3/4,
and 5/6.
A VHT STA shall support the following features:
— Non-HT and non-HT duplicate formats (transmit and receive) for all channel widths supported by
the VHT STA
— HT-mixed format (transmit and receive)
— VHT format (transmit and receive)
— 20 MHz, 40 MHz, and 80 MHz channel widths
— Single spatial stream VHT-MCSs 0 to 7 (transmit and receive) in all supported channel widths
— Binary convolutional coding
A VHT STA may support the following features:
— HT-greenfield format (transmit and receive)
— 2 or more spatial streams (transmit and receive)
— 400 ns short guard interval (transmit and receive)
— Beamforming sounding (by sending a VHT NDP)
— Responding to transmit beamforming sounding (by providing compressed beamforming feedback)
— STBC (transmit and receive)
— LDPC (transmit and receive)
— VHT MU PPDUs (transmit and receive)
— Support for 160 MHz channel width
— Support for 80+80 MHz channel width
— VHT-MCSs 8 and 9 (transmit and receive)
2497
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.1.2 Scope
The services provided to the MAC by the VHT PHY consist of the following protocol functions:
a) A function that defines a method of mapping the PSDUs into a framing format (PPDU) suitable for
sending and receiving PSDUs between two or more STAs.
b) A function that defines the characteristics and method of transmitting and receiving data through a
wireless medium between two or more STAs. Depending on the PPDU format, these STAs support
a mixture of VHT, Clause 19 and Clause 17 PHYs.
21.1.3 VHT PHY functions
21.1.3.1 General
The VHT PHY contains two functional entities: the PHY function and the physical layer management
function (i.e., the PLME). Both of these functions are described in detail in 21.3 and 21.4.
The VHT PHY service is provided to the MAC through the PHY service primitives defined in Clause 8. The
VHT PHY service interface is described in 21.2.
21.1.3.2 PHY management entity (PLME)
The PLME performs management of the local PHY functions in conjunction with the MLME.
21.1.3.3 Service specification method
The models represented by figures and state diagrams are intended to be illustrations of the functions
provided. It is important to distinguish between a model and a real implementation. The models are
optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular
implementation.
The service of a layer is the set of capabilities that it offers to a user in the next higher layer. Abstract
services are specified here by describing the service primitives and parameters that characterize each
service. This definition is independent of any particular implementation.
21.1.4 PPDU formats
The structure of the PPDU transmitted by a VHT STA is determined by the TXVECTOR parameters as
defined in Table 21-1.
In a VHT STA the FORMAT parameter determines the overall structure of the PPDU and can take one of
the following values:
— Non-HT format (NON_HT), based on Clause 17 and including non-HT duplicate format.
— HT-mixed format (HT_MF) as specified in Clause 19.
— HT-greenfield format (HT_GF) as specified in Clause 19.
— VHT format (VHT). PPDUs of this format contain a preamble compatible with Clause 17 and
Clause 19 STAs. The non-VHT portion of the VHT format preamble (the parts of VHT preamble
preceding the VHT-SIG-A field) is defined so that it can be decoded by these STAs.
NOTE—Required support for these formats is defined in 11.40, 19.1.1, and 21.1.1.
A VHT PPDU can be further categorized as a VHT SU PPDU or a VHT MU PPDU. A VHT PPDU using a
group ID value of 0 or 63 is a VHT SU PPDU and either carries only one PSDU or no PSDU. A VHT PPDU
2498
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
using a group ID value in the range 1 to 62 is a VHT MU PPDU and carries one or more PSDUs to one or
more users.
21.2 VHT PHY service interface
21.2.1 Introduction
The PHY provides an interface to the MAC through an extension of the generic PHY service interface
defined in 8.3.4. The interface includes TXVECTOR, RXVECTOR, and PHYCONFIG_VECTOR.
Using the TXVECTOR, the MAC supplies the PHY with per-PPDU transmit parameters. Using the
RXVECTOR, the PHY informs the MAC of the received PPDU parameters. Using the
PHYCONFIG_VECTOR, the MAC configures the PHY for operation, independent of frame transmission
or reception.
21.2.2 TXVECTOR and RXVECTOR parameters
The parameters in Table 21-1 are defined as part of the TXVECTOR parameter list in the PHY-
TXSTART.request primitive and/or as part of the RXVECTOR parameter list in the PHY-
RXSTART.indication primitive.
Table 21-1—TXVECTOR and RXVECTOR parameters
RXVECTOR
TXVECTOR
Parameter
Condition Value
Determines the format of the PPDU. Y Y
Enumerated type:
NON_HT indicates Clause 17 (Orthogonal frequency division
FORMAT
multiplexing (OFDM) PHY specification) or non-HT
duplicate PPDU format. In this case, the modulation is
determined by the NON_HT_MODULATION parameter.
HT_MF indicates HT-mixed format.
HT_GF indicates HT-greenfield format.
VHT indicates VHT format.
FORMAT is NON_HT In TXVECTOR, indicates the format type of the transmitted non- Y Y
NON_HT_MODULATION
HT PPDU.
In RXVECTOR, indicates the estimated format type of the
received non-HT PPDU.
Enumerated type:
OFDM indicates Clause 17 (Orthogonal frequency division
multiplexing (OFDM) PHY specification) format
NON_HT_DUP_OFDM indicates non-HT duplicate format
Otherwise Not present N N
2499
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT Not present N N
NOTE—The Length field of the L-SIG in VHT PPDUs is
L_LENGTH
defined in Equation (21-24) using the TXTIME value defined by
Equation (21-109) and Equation (21-110), which in turn depend
on other parameters including the TXVECTOR parameter
APEP_LENGTH.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Not present N N
L_DATARATE
NOTE—The RATE field in the L-SIG field in a VHT PPDU is
set to the value representing 6 Mb/s in the 20 MHz channel
spacing column of Table 17-6.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Not present N N
LSIGVALID
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Not present N N
SERVICE
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Not present N N
SMOOTHING
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Not present N N
AGGREGATION
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Not present N N
NUM_EXTEN_SS
Otherwise See corresponding entry in Table 19-1
2500
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT Not present N N
ANTENNA_SET
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates the number of transmit chains. Y N
N_TX
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT and Set to COMPRESSED_SV Y N
EXPANSION_MAT_TYPE
EXPANSION_MAT
is present.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Contains a vector in the number of selected subcarriers M N
EXPANSION_MAT
containing feedback matrices as defined in 21.3.11.2 based on U
the channel measured during the training symbols of a previous
VHT NDP PPDU.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT and Set to COMPRESSED_SV N Y
CHAN_MAT_TYPE
PSDU_LENGTH equals 0
FORMAT is VHT and Not present N N
PSDU_LENGTH is
greater than 0
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT and Contains a set of compressed beamforming feedback matrices as N Y
PSDU_LENGTH equals 0 defined in 21.3.11.2 based on the channel measured during the
CHAN_MAT
training symbols of the received VHT NDP PPDU.
FORMAT is VHT and Not present N N
PSDU_LENGTH is
greater than 0
Otherwise See corresponding entry in Table 19-1
2501
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT Contains an array of delta SNR values as defined in 9.4.1.51 M Y
based on the channel measured during the training symbols of U
DELTA_SNR
the received VHT NDP PPDU.
NOTE—In the RXVECTOR this parameter is present only for
VHT NDP PPDUs for MU sounding.
Otherwise Not present N N
See corresponding entry in Table 19-1
RCPI
FORMAT is VHT Contains an array of received SNR measurements for each N Y
spatial stream. SNR indications of 8 bits are supported. SNR
shall be the sum of the decibel values of SNR per tone divided by
SNR
the number of tones represented in each stream as described in
9.4.1.49
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Not present N N
NO_SIG_EXTN
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates which FEC encoding is used. M Y
FEC_CODING
Enumerated type: U
BCC_CODING indicates binary convolutional code.
LDPC_CODING indicates low-density parity check code.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates whether STBC is used. Y Y
0 indicates no STBC (NSTS=NSS in the Data field).
STBC
1 indicates STBC is used (NSTS=2NSS in the Data field).
This parameter is 0 for a VHT MU PPDU.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates whether a short guard interval is used in the Y Y
transmission of the Data field of the PPDU.
Enumerated type:
GI_TYPE
LONG_GI indicates short GI is not used in the Data field of
the PPDU.
SHORT_GI indicates short GI is used in the Data field of the
PPDU.
Otherwise See corresponding entry in Table 19-1
2502
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT The allowed values for the TXPWR_LEVEL_INDEX parameter Y N
TXPWR_LEVEL_INDEX
are in the range 1 to
numberOfOctets(dot11TxPowerLevelExtended)/2. This
parameter is used to indicate which of the available transmit
output power levels defined in dot11TxPowerLevelExtended
shall be used for the current transmission.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT The allowed values for the RSSI parameter are in the range 0 to N Y
255. This parameter is a measure by the PHY of the power
observed at the antennas used to receive the current PPDU
RSSI
measured during the reception of the VHT-LTF field. RSSI is
intended to be used in a relative manner, and it is a
monotonically increasing function of the received power.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates the modulation and coding scheme used in the M Y
transmission of the PPDU. U
MCS
Integer: range 0 to 9
Otherwise See corresponding entry in Table 19-1
FORMAT is HT_MF, Indicates the MCS that the STA’s receiver recommends. N O
REC_MCS
HT_GF or VHT
Otherwise Not present N N
2503
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is HT_MF or See corresponding entry in Table 19-1
HT_GF
FORMAT is VHT Indicates the channel width of the transmitted PPDU: Y Y
Enumerated type:
CBW20 for 20 MHz
CBW40 for 40 MHz
CBW80 for 80 MHz
CBW160 for 160 MHz
CBW80+80 for 80+80 MHz
CH_BANDWIDTH
FORMAT is NON_HT In TXVECTOR, indicates the channel width of the transmitted Y Y
PPDU.
In RXVECTOR, indicates the estimated channel width of the
received PPDU.
Enumerated type:
CBW40, CBW80, CBW160, or CBW80+80 if
NON_HT_MODULATION equals
NON_HT_DUP_OFDM
CBW20 if NON_HT_MODULATION equals OFDM
NOTE—On reception, where valid, the CH_BAND-
WIDTH_IN_NON_HT parameter is likely to be a more reliable
indication of subformat and channel width than the NON_HT_-
MODULATION and CH_BANDWIDTH parameters, since for
non-HT or non-HT duplicate frames, CH_BANDWIDTH is a
receiver estimate of the bandwidth, whereas CH_BAND-
WIDTH_IN_NON_HT is the signaled bandwidth.
FORMAT is NON_HT In TXVECTOR, if present, indicates whether the transmitter is O Y
DYN_BANDWIDTH_IN_NON_HT
capable of Static or Dynamic bandwidth operation.
In RXVECTOR, if valid, indicates whether the transmitter is
capable of Static or Dynamic bandwidth operation.
Enumerated type:
Static if the transmitter is capable of Static bandwidth
operation
Dynamic if the transmitter is capable of Dynamic bandwidth
operation
NOTE—In the RXVECTOR, the validity of this parameter is
determined by the MAC based on the contents of the received
MPDU.
Otherwise Not present N N
2504
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is NON_HT In TXVECTOR, if present, indicates the channel width of the O Y
CH_BANDWIDTH_IN_NON_HT
transmitted PPDU, which is signaled via the scrambling
sequence.
In RXVECTOR, if valid, indicates the channel width of the
received PPDU, which is signaled via the scrambling sequence.
Enumerated type:
CBW20, CBW40, CBW80, CBW160, CBW80+80
NOTE—In the RXVECTOR, the validity of this parameter is
determined by the MAC based on the contents of the currently
received MPDU (e.g., RTS) or the previous MPDU in an
exchange (e.g., the RTS preceding a CTS).
Otherwise Not present N N
FORMAT is VHT Not present N N
LENGTH
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT If equal to 0, indicates a VHT NDP PPDU for both RXVECTOR M O
and TXVECTOR. U
APEP_LENGTH
If greater than 0 in the TXVECTOR, indicates the number of
octets in the range 1 to 1 048 575 in the A-MPDU pre-EOF
padding (see 10.13.2) carried in the PSDU.
If greater than 0 in the RXVECTOR, this parameter is the value
obtained from the VHT-SIG-B Length field multiplied by 4.
Otherwise Not present N N
FORMAT is VHT Indicates the number of octets in the VHT PSDU in the range 0 N Y
PSDU_LENGTH
to aPSDUMaxLength octets (see Table 21-29). A value of 0
indicates a VHT NDP PPDU.
Otherwise Not present N N
FORMAT is VHT and Index for user in MU transmission. Integer: range 0-3. M O
USER_POSITION
1 ≤ GROUP_ID ≤ 62 U
NOTE—The entries in the USER_POSITION array are in
ascending order.
Otherwise Not present N N
FORMAT is VHT Indicates the number of space-time streams. M Y
NUM_STS
Integer: range 1-8 for SU, 1-4 per user in the TXVECTOR and 0- U
4 in the RXVECTOR for MU.
NUM_STS summed over all users is in the range 1 to 8.
Otherwise Not present N N
2505
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT Indicates the group ID. Y Y
GROUP_ID
Integer: range 0-63 (see Table 21-12)
A value of 0 or 63 indicates a VHT SU PPDU. A value in the
range 1 to 62 indicates a VHT MU PPDU.
Otherwise Not present N N
FORMAT is VHT and Provides an abbreviated indication of the intended recipient(s) of Y Y
PARTIAL_AID
GROUP_ID is 0 or 63 the PSDU (see 10.20).
Integer: range 0-511.
Otherwise Not present N N
FORMAT is VHT Indicates the number of users with nonzero space-time streams. Y N
NUM_USERS
Integer: range 1 to 4.
Otherwise Not present N N
FORMAT is VHT and Set to 1 if a beamforming steering matrix is applied to the Y O
BEAMFORMED
GROUP_ID is 0 or 63 waveform in an SU transmission. Set to 0 otherwise.
NOTE—When BEAMFORMED is set to 1, frequency domain
smoothing as part of channel estimation is not recommended.
Otherwise Not present N N
FORMAT is VHT Indicates whether a VHT AP allows non-AP VHT STAs in Y Y
TXOP_PS_NOT_ALLOWED
TXOP power save mode to enter doze state during the TXOP.
0 indicates that the VHT AP allows non-AP VHT STAs to enter
doze state during a TXOP.
1 indicates that the VHT AP does not allow non-AP VHT STAs
to enter doze state during a TXOP.
Otherwise Not present N N
2506
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
See corresponding entry in Table 19-1
TIME_OF_DEPARTURE_REQUESTED
dot11TimingMsmtActivat 0 to 232– 1. An estimate of the offset (in 10 ns units) from the N Y
RX_START_OF_FRAME_OFFSET
ed is true point in time at which the start of the preamble corresponding to
the incoming frame arrived at the receive antenna connector to
the point in time at which this primitive is issued to the MAC.
Otherwise Not present N N
NOTE—In the “TXVECTOR” and “RXVECTOR” columns, the following apply:
Y = Present;
N = Not present;
O = Optional;
MU indicates that the parameter is present once for a VHT SU PPDU and present per user for a VHT MU PPDU.
Parameters specified to be present per user are conceptually supplied as an array of values indexed by u, where u
takes values 0 to NUM_USERS-1.
21.2.3 PHYCONFIG_VECTOR parameters
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains an
OPERATING_CHANNEL parameter, which identifies the operating or primary channel. The PHY shall set
dot11CurrentPrimaryChannel to the value of this parameter.
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains a
CHANNEL_WIDTH parameter, which identifies the operating channel width and takes one of the values
20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz. The PHY shall set dot11CurrentChannelWidth to
the value of this parameter.
2507
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains a
CENTER_FREQUENCY_SEGMENT_0 parameter, which identifies the center frequency of the channel
(or of segment 0 if the CHANNEL_WIDTH parameter indicates 80+80 MHz) and takes a value between 1
and 200. The PHY shall set dot11CurrentChannelCenterFrequencyIndex0 to the value of this parameter.
The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains a
CENTER_FREQUENCY_SEGMENT_1 parameter, which takes the value 0 if the CHANNEL_WIDTH
parameter does not indicate 80+80 MHz, and otherwise identifies the center frequency of segment 1 and
takes a value between 1 and 200. The PHY shall set dot11CurrentChannelCenterFrequencyIndex1 to the
value of this parameter.
21.2.4 Effects of CH_BANDWIDTH parameter on PPDU format
Table 21-2 shows the valid combinations of the FORMAT, NON_HT_MODULATION, and
CH_BANDWIDTH parameters and the corresponding PPDU format and value of CH_OFFSET (if
applicable). Other combinations are reserved.
Table 21-2—Interpretation of FORMAT, NON_HT_MODULATION, CH_BANDWIDTH, and
CH_OFFSET parameters
NON_HT_
FORMAT CH_BANDWIDTH CH_OFFSET PPDU format
MODULATION
VHT N/A CBW20 N/A The STA transmits a VHT PPDU
(when FORMAT is VHT) of 20
MHz bandwidth. If the BSS
bandwidth is wider than 20 MHz,
then the transmission shall use the
primary 20 MHz channel.
VHT N/A CBW40 N/A The STA transmits a VHT PPDU
(when FORMAT is VHT) of 40
MHz bandwidth. If the BSS
bandwidth is wider than 40 MHz,
then the transmission shall use the
primary 40 MHz channel.
HT_MF or N/A HT_CBW20 and CH_OFF_20U The STA transmits an HT-mixed
HT_GF CHANNEL_WIDTH PPDU (when FORMAT is
in HT_MF) or HT-greenfield PPDU
PHYCONFIG_VEC (when FORMAT is HT_GF) of 20
TOR > 20 MHz and MHz bandwidth. The transmission
f S20 idx < f P20 idx shall use the primary 20 MHz
channel.
HT_MF or N/A HT_CBW20 and CH_OFF_20L The STA transmits an HT-mixed
HT_GF CHANNEL_WIDTH PPDU (when FORMAT is
in HT_MF) or HT-greenfield PPDU
PHYCONFIG_VEC (when FORMAT is HT_GF) of 20
TOR > 20 MHz and MHz bandwidth. The transmission
f S20 idx > f P20 idx shall use the primary 20 MHz
channel.
HT_MF or N/A HT_CBW20 and CH_OFF_20 The STA transmits an HT-mixed
HT_GF CHANNEL_WIDTH PPDU (when FORMAT is
in HT_MF) or HT-greenfield PPDU
PHYCONFIG_VEC (when FORMAT is HT_GF) of 20
TOR = 20 MHz MHz bandwidth.
2508
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-2—Interpretation of FORMAT, NON_HT_MODULATION, CH_BANDWIDTH, and
CH_OFFSET parameters (continued)
NON_HT_
FORMAT CH_BANDWIDTH CH_OFFSET PPDU format
MODULATION
HT_MF or N/A HT_CBW40 CH_OFF_40 The STA transmits an HT-mixed
HT_GF PPDU (when FORMAT is
HT_MF) or HT-greenfield PPDU
(when FORMAT is HT_GF) of 40
MHz bandwidth. If the BSS
bandwidth is wider than 40 MHz,
then the transmission shall use the
primary 40 MHz channel.
VHT N/A CBW80 The STA transmits a VHT PPDU
of 80 MHz bandwidth. If the BSS
bandwidth is 160 MHz or
80+80 MHz, then the transmission
shall use the primary 80 MHz
channel.
VHT N/A CBW160 The STA transmits a VHT PPDU
of 160 MHz bandwidth.
VHT N/A CBW80+80 The STA transmits a VHT PPDU
of 80+80 MHz bandwidth.
NON_HT OFDM CBW20 The STA transmits a NON_HT
PPDU with
NON_HT_MODULATION set to
OFDM using the primary 20 MHz
channel as defined in Clause 17.
NON_HT NON_HT_DUP_ CBW40 The STA transmits a NON_HT
OFDM PPDU with
NON_HT_MODULATION set to
NON_HT_DUP_OFDM using two
adjacent 20 MHz channels as
defined in 21.3.10.12. If the BSS
bandwidth is wider than 40 MHz,
then the transmission shall use the
primary 40 MHz channel. The one
20 MHz channel higher in
frequency is rotated +90º relative to
the 20 MHz channel lowest in
frequency as defined in
Equation (21-15).
NON_HT NON_HT_DUP_ CBW80 The STA transmits a NON_HT
OFDM PPDU with
NON_HT_MODULATION set to
NON_HT_DUP_OFDM using four
adjacent 20 MHz channels as
defined in 21.3.10.12. If the BSS
BSS bandwidth is 160 MHz or
80+80 MHz, then the transmission
shall use the primary 80 MHz
channel. The three 20 MHz
channels higher in frequency are
rotated +180º relative to the 20
MHz channel lowest in frequency
as defined in Equation (21-16).
2509
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-2—Interpretation of FORMAT, NON_HT_MODULATION, CH_BANDWIDTH, and
CH_OFFSET parameters (continued)
NON_HT_
FORMAT CH_BANDWIDTH CH_OFFSET PPDU format
MODULATION
NON_HT NON_HT_DUP_ CBW160 The STA transmits a NON_HT
OFDM PPDU with
NON_HT_MODULATION set to
NON_HT_DUP_OFDM using
eight adjacent 20 MHz channels as
defined in 21.3.10.12. The second,
third, fourth, sixth, seventh, and
eighth 20 MHz channels in the
order of increasing frequency are
rotated +180º relative to the 20
MHz channel lowest in frequency
as defined in Equation (21-17).
NON_HT NON_HT_DUP_ CBW80+80 The STA transmits a NON_HT
OFDM PPDU with
NON_HT_MODULATION set to
NON_HT_DUP_OFDM using two
nonadjacent frequency segments,
with each frequency segment
consisting of four adjacent 20 MHz
channels as defined in 21.3.10.12.
In each frequency segment, the
three 20 MHz channels higher in
frequency are rotated +180º
relative to the 20 MHz channel
lowest in frequency as defined in
Equation (21-16).
2510
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.2.5 Support for NON_HT and HT formats
21.2.5.1 General
A VHT STA logically contains Clause 17, Clause 19, and Clause 21 PHYs. The MAC interfaces to the
PHYs via the Clause 21 PHY service interface, which in turn interacts with the Clause 17 and Clause 19
PHY service interfaces as shown in Figure 21-1, Figure 21-2, and Figure 21-3.
Clause 21 Clause 21 PHY-TXSTART.request(TXVECTOR)
PHY-TXSTART.confirm
FORMAT= FORMAT = NON_HT and FORMAT = NON_HT and FORMAT
PHY-DATA.request HT NON_HT_MODULATION NON_HT_MODULATION = = VHT
PHY-DATA.confirm = OFDM NON_HT_DUP_OFDM
PHY-TXEND.request
PHY-TXEND.confirm
Clause 21
Clause 17 Transmit
TXVECTOR
TXVECTOR
PHY-TXSTART.confirm Procedure
Clause 19 21.2.5.3 Clause 17 21.2.5.2 PHY-DATA.request
PHY-TXSTART.confirm PHY-TXSTART.confirm PHY-DATA.confirm
PHY-DATA.request Clause 19 PHY-DATA.request Clause 17 PHY-TXEND.request
PHY-DATA.confirm PHY- PHY-DATA.confirm PHY- PHY-TXEND.confirm
PHY-TXEND.request TXSTART PHY-TXEND.request TXSTART
PHY-TXEND.confirm .request PHY-TXEND.confirm .request
(TXVECTOR) (TXVECTOR)
Clause 19 Transmit Procedure; Clause 17 Transmit Procedure; Clause 17 21.3.10.12 and Clause 21
Clause 19 PPDU extended by 21.2.4 Clause 17 PPDU extended by 21.2.4 and Transmit 21.3.10 non-HT VHT PPDU
and 21.3.9.2, and with 21.3.9.1, and with Procedure duplicate PPDU
21.3.17.1 instead of 19.3.18.1 and 21.3.17.1 instead of 17.3.9.3 and
21.3.17.4.2 instead of 19.3.18.4 21.3.17.4.2 instead of 17.3.9.7.2
Figure 21-1— PHY interaction on transmit for various PPDU formats
Clause 21 PHY-RXSTART.indication(RXVECTOR)
Clause 21
PHY-DATA.indication
PHY-RXEND.indication
21.2.5.2 Clause 17 21.2.5.3 Clause 19
PHY-DATA.indication PHY-DATA.indication
Note: Not all PHY-RXEND.indication PHY-RXEND.indication
parameters
are shown
Clause 17 Clause 17 Clause 19 Clause 19 Clause 21
PHY-RXSTART Receive PHY-RXSTART Receive Receive
.indication Procedure .indication Procedure Procedure
(RXVECTOR) (RXVECTOR)
NON_HT + NON_HT + HT
OFDM NON_HT_DUP_OFDM VHT
Format Detection
Figure 21-2—PHY interaction on receive for various PPDU formats
2511
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Clause 21 PHY-CONFIG.request Clause 21 PHY-CONFIG.confirm
Clause 21 PHY-CCARESET.request
(PHYCONFIG_VECTOR)
PHY-CCARESET.confirm
PHY-CCA.indication
Configure all PHYs. Confirm configuration of all PHYs.
The PHY-CCA and PHY-CCARESET
primitives from Clause 17 and Clause 19
21.2.5.2 21.2.5.3 Clause 17 PHY- Clause 19 PHY- are unused (CCA requirements are
CONFIG.confirm CONFIG.confirm defined in Clause 21.3.18.5 instead).
Clause 17 PHY- Clause 19 PHY-
CONFIG.request CONFIG.request Clause 21 Clause 21
(PHYCONFIG_ (PHYCONFIG_
VECTOR) VECTOR)
Figure 21-3—PHY-CONFIG and CCA interaction with Clause 17, Clause 19, and Clause 21
PHYs
21.2.5.2 Support for NON_HT format when NON_HT_MODULATION is OFDM
When a PHY-TXSTART.request(TXVECTOR) primitive with the FORMAT parameter equal to NON_HT
and the NON_HT_MODULATION parameter equal to OFDM is issued, the behavior of the VHT PHY is
defined in Clause 17 with additional requirements described in the following subclauses:
— 21.3.9.1
— 21.3.17.1 instead of 17.3.9.3
— 21.3.17.4.2 instead of 17.3.9.7.2
where the Clause 21 TXVECTOR parameters in Table 21-1 are mapped to Clause 17 TXVECTOR
parameters in Table 17-1 according to Table 21-3.
NOTE—When the FORMAT parameter is set to NON_HT and the NON_HT_MODULATION parameter is set to
NON_HT_DUP_OFDM in a PHY-TXSTART.request(TXVECTOR) primitive, the behavior of the VHT PHY is
defined in Clause 21.
When the VHT PHY receives a Clause 21 PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive, the
VHT PHY shall, for the purposes of OFDM PPDU transmission and reception, behave as if it were a
Clause 17 PHY that had received a PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive but with the
CHANNEL_WIDTH, CENTER_FREQUENCY_SEGMENT_0, and
CENTER_FREQUENCY_SEGMENT_1 parameters discarded from PHYCONFIG_VECTOR.
As defined in 21.3.20, once a PPDU is received and detected as a NON_HT PPDU, the behavior of the VHT
PHY is defined in Clause 17. The RXVECTOR parameters from the Clause 17 PHY-RXSTART.indication
primitive are mapped to the Clause 21 RXVECTOR parameters as defined in Table 21-3. VHT PHY
parameters not listed in the table are not present.
Table 21-3—Mapping of VHT PHY parameters for NON_HT operation
5 GHz operation defined by
VHT PHY Parameter Parameter List
Clause 17
L_LENGTH LENGTH TXVECTOR/RXVECTOR
L_DATARATE DATARATE TXVECTOR/RXVECTOR
TXPWR_LEVEL_INDEX TXPWR_LEVEL_INDEX TXVECTOR
2512
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-3—Mapping of VHT PHY parameters for NON_HT operation (continued)
5 GHz operation defined by
VHT PHY Parameter Parameter List
Clause 17
RSSI RSSI RXVECTOR
SERVICE SERVICE TXVECTOR/RXVECTOR
RCPI RCPI RXVECTOR
CH_BANDWIDTH_IN_NON_HT CH_BANDWIDTH_IN_NON_HT TXVECTOR/RXVECTOR
DYN_BANDWIDTH_IN_NON_HT DYN_BANDWIDTH_IN_NON_HT TXVECTOR/RXVECTOR
OPERATING_CHANNEL OPERATING_CHANNEL PHYCONFIG_VECTOR
CHANNEL_WIDTH discarded PHYCONFIG_VECTOR
CENTER_FREQUENCY_SEGMENT_ discarded PHYCONFIG_VECTOR
0
CENTER_FREQUENCY_SEGMENT_ discarded PHYCONFIG_VECTOR
1
21.2.5.3 Support for HT formats
When a PHY-TXSTART.request(TXVECTOR) primitive is received with the TXVECTOR parameter
FORMAT equal to HT_MF or HT_GF, the behavior of the PHY is defined by Clause 19 with additional
requirements defined in the following subclauses:
— 21.3.9.2
— 21.3.17.1 instead of 19.3.18.1
— 21.3.17.4.2 instead of 19.3.18.4
The Clause 21 TXVECTOR parameters in Table 21-1 are mapped directly to Clause 19 TXVECTOR
parameters in Table 19-1 and the Clause 19 PHY-TXSTART.request(TXVECTOR) primitive is issued. The
PHY shall use a value of CH_OFFSET in the Clause 19 TXVECTOR that is consistent with Table 21-2.
When the VHT PHY receives a Clause 21 PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive, the
VHT PHY shall, for the purposes of HT PPDU transmission and reception, behave as if it were a Clause 19
PHY that had received PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive but with the
CHANNEL_WIDTH, CENTER_FREQUENCY_SEGMENT_0, and
CENTER_FREQUENCY_SEGMENT_1 parameters discarded from the PHYCONFIG_VECTOR and the
SECONDARY_CHANNEL_OFFSET parameter set to SECONDARY_CHANNEL_NONE if
dot11CurrentChannelWidth indicates 20 MHz, to SECONDARY_CHANNEL_ABOVE if
f P20 idx f S20 idx , or to SECONDARY_CHANNEL_BELOW otherwise.
As defined in 21.3.20, once a PPDU is received and detected as an HT PPDU, the behavior of the VHT PHY
is defined in Clause 19. The RXVECTOR parameters in Table 19-1 from the Clause 19 PHY-
RXSTART.indication primitive are mapped directly to the RXVECTOR parameters in Table 21-1 and a
Clause 21 PHY-RXSTART.indication primitive is issued.
21.2.6 TXSTATUS parameters
The parameters listed in Table 20-2 are defined as part of the TXSTATUS parameter list in the PHY-
TXSTART.confirm(TXSTATUS) primitive.
2513
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3 VHT PHY
21.3.1 Introduction
This subclause provides the procedure by which PSDUs are converted to and from transmissions on the
wireless medium.
During transmission, a PSDU (in the SU case) or one or more PSDUs (in the MU case) are processed (i.e.,
scrambled and coded) and appended to the PHY preamble to create the PPDU. At the receiver, the PHY
preamble is processed to aid in the detection, demodulation, and delivery of the PSDU.
Pre-VHT modulated fields refer to the L-STF, L-LTF, L-SIG, and VHT-SIG-A fields, while VHT
modulated fields refer to the VHT-STF, VHT-LTF, VHT-SIG-B, and Data fields (see Figure 21-17).
21.3.2 VHT PPDU format
A single PPDU format is defined for this PHY: the VHT PPDU format. Figure 21-4 shows the VHT PPDU
format.
8 μs 8 μs 4 μs 8 μs 4 μs 4 μs per VHT-LTF symbol 4 μs
L- VHT- VHT-
L-STF L-LTF VHT-SIG-A VHT-LTF Data
SIG STF SIG-B
Figure 21-4—VHT PPDU format
The fields of the VHT PPDU format are summarized in Table 21-4.
Table 21-4—Fields of the VHT PPDU
Field Description
L-STF Non-HT Short Training field
L-LTF Non-HT Long Training field
L-SIG Non-HT SIGNAL field
VHT-SIG-A VHT Signal A field
VHT-STF VHT Short Training field
VHT-LTF VHT Long Training field
VHT-SIG-B VHT Signal B field
Data The Data field carrying the PSDU(s)
The VHT-SIG-A, VHT-STF, VHT-LTF, and VHT-SIG-B fields exist only in VHT PPDUs. In a VHT NDP
the Data field is not present. The number of symbols in the VHT-LTF field, NVHTLTF, can be either 1, 2, 4, 6,
or 8 and is determined by the total number of space-time streams across all users being transmitted in the
VHT PPDU (see Table 21-13).
2514
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.3 Transmitter block diagram
The generation of each field in a VHT PPDU uses many of the following blocks:
a) PHY padding
b) Scrambler
c) BCC encoder parser
d) FEC (BCC or LDPC) encoders
e) Stream parser
f) Segment parser (for 160 MHz and 80+80 MHz transmissions)
g) BCC interleaver
h) Constellation mapper
i) Pilot insertion
j) Replicate over multiple 20 MHz (if BW > 20 MHz)
k) Multiply by 1st column of PVHTLTF
l) LDPC tone mapper
m) Segment deparser
n) Space time block code (STBC) encoder
o) Cyclic shift diversity (CSD) per STS insertion
p) Spatial mapper
q) Inverse discrete Fourier transform (IDFT)
r) Cyclic shift diversity (CSD) per chain insertion
s) Guard interval (GI) insertion
t) Windowing
Figure 21-5 to Figure 21-16 show example transmitter block diagrams. The actual structure of the
transmitter is implementation dependent. In particular, Figure 21-5 shows the transmit process for the L-SIG
and VHT-SIG-A fields of a VHT PPDU using one frequency segment. These transmit blocks are also used
to generate L-STF and L-LTF fields, except that the BCC encoder and interleaver are not used for these
fields.
Insert GI
Analog
and
and RF
Window
20 MHz if BW > 20 MHz
Insert GI
Replicate over multiple
Constellation Mapper
Analog
CSD and
BCC Interleaver
and RF
BCC Encoder
Window
IDFT
...
Insert GI
Analog
CSD and
and RF
Window
Single Spatial Stream
NTX Transmit Chains
Figure 21-5—Transmitter block diagram for the L-SIG and VHT-SIG-A fields
2515
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 21-6 and Figure 21-7 show the transmit process for generating the VHT-SIG-B field of a VHT SU
PPDU and VHT MU PPDU, respectively, in 20 MHz, 40 MHz, and 80 MHz channel widths. Figure 21-8
and Figure 21-9 show the transmit process for generating the VHT_SIG-B field of a 160 MHz and
80+80 MHz VHT SU PPDU, respectively.
Insert GI
Analog
IDFT and
and RF
Window
Multiply by 1st Column of PVHTLTF
VHT-SIG-B Bit Repetition
Constellation Mapper
CSD Insert GI
Analog
Spatial Mapping
if BW > 20 MHz
BCC Interleaver per IDFT and
BCC Encoder
and RF
STS Window
...
...
CSD Insert GI
Analog
per IDFT and
and RF
STS Window
Single Spatial Stream NSTS Space-Time NTX Transmit Chains
Streams
Figure 21-6—Transmitter block diagram for the VHT-SIG-B field of a 20 MHz, 40 MHz, and
80 MHz VHT SU PPDU
VHT-SIG-B Bit Repetition
Insert GI
Multiply by User Specific
Elements of 1st Column
Analog
Constellation Mapper
IDFT and
of PVHTLTF for User 0
and RF
BCC Interleaver
Window
if BW>20MHz
BCC Encoder
CSD
per STS
...
Insert GI
CSD Analog
IDFT and
per STS and RF
Window
NSTS, 0
Spatial Mapping
Single Spatial Stream
User 0 Space-time Streams
...
...
Elements of 1st Column of
VHT-SIG-B Bit Repetition
Multiply by User Specific
CSD
PVHTLTF for User Nuser-1
Constellation Mapper
per STS
BCC Interleaver
if BW>20MHz
BCC Encoder
...
CSD
per STS Insert GI
Analog
IDFT and
and RF
Window
Single Spatial Stream NSTS, Nuser-1
User Nuser-1 Space-time Streams
NSTS,total NTx Transmit Chains
Space-time Streams
Figure 21-7—Transmitter block diagram for the VHT-SIG-B field of a 20 MHz, 40 MHz, and
80 MHz VHT MU PPDU
2516
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Insert GI
Analog
IDFT and
and RF
Constellation
Window
Interleaver
CSD
mapper
VHT-SIG-B Bit Repetition
Multiply By 1st Column of PVHTLTF
BCC
per STS
Segment Deparser
if BW=160MHz
Insert GI
BCC Encoder
Segment Parser
Analog
IDFT and
Spatial Mapping
and RF
Window
Constellation
...
Interleaver
...
mapper
BCC Insert GI
Analog
IDFT and
CSD and RF
Window
per STS
Single Spatial Stream NSTS Space-Time NTX Transmit Chains
Streams
Figure 21-8—Transmitter block diagram for the VHT-SIG-B field of a 160 MHz VHT SU PPDU
Insert GI
Analog
IDFT and
and RF
Window
Multiply By 1 st Column of P VH TLTF
CSD
per STS
CSD
per STS
Interleaver Cons tellation mapper
Insert GI
Spatial Mapping
Analog
BCC Interleaver
IDFT and
V HT-SIG -B Bit Repetition
and RF
tellation mapper
Window
Multiply By 1 st Column of P VH TLTF
CSD
Interleav er
if BW=80+ 80MHz
CSD
...
......
per STS
BCC Enc oder
CSD
per STS
Segment
per STSCSD
Parser
mapper
CSD
Spatial Mapping
per STS
Interleav er
BCC
per STS
Constellation
Cons
mapper
Interleav er Cons tellation
CSD
......
BCCBCC
Insert GI
CSD CSD
...
BCC Constellation per STS
CSD Analog
IDFT and
Interleaver per STSper
mapper STS
per STS and RF
Window
Constellation
mapper
Insert GI
BCC
......
BCC Constellation
CSD CSD Analog
IDFT and
Interleaver mapper
per STS per STS and RF
Window
NSTS Space-Time NTX Transmit Chains for each of the
Single Spatial Stream Streams two segments
Figure 21-9—Transmitter block diagram for the VHT-SIG-B field of an 80+80 MHz VHT SU
PPDU
Figure 21-10 shows the transmitter blocks used to generate the Data field of a 20 MHz, 40 MHz, and
80 MHz VHT SU PPDU with BCC encoding. A subset of these transmitter blocks consisting of the
constellation mapper and CSD blocks, as well as the blocks to the right of, and including, the spatial
mapping block, are also used to generate the VHT-LTF fields. This is illustrated in Figure 21-21. A subset of
these transmitter blocks consisting of the constellation mapper and CSD blocks, as well as the blocks to the
right of, and including, the spatial mapping block, are also used to generate the VHT-STF field but without
k
the multiplication by A VHT - LTF (defined in Equation (21-40)).
2517
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Constellation
BCC Encoder
Interleaver
mapper
BCC
Insert GI
Analog
IDFT and
and RF
Window
BCC Encoder Parser
CSD per
Constellation
Interleaver
Spatial Mapping
STS Insert GI
mapper
Stream Parser
PHY Padding
Analog
BCC
Scrambler
IDFT and
...
and RF
STBC
Window
...
...
...
Constellation
BCC Encoder
Insert GI
Interleaver
CSD per Analog
mapper
Single Data Stream IDFT and
STS and RF
BCC
Window
NES Data Streams NSS Spatial Streams NSTS Space-Time NTX Transmit Chains
Streams
Figure 21-10—Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or
80 MHz VHT SU PPDU with BCC encoding
Figure 21-11 shows the transmitter blocks used to generate the Data field of a 20 MHz, 40 MHz, and
80 MHz VHT SU PPDU with LDPC encoding for a single frequency segment.
LDPC
Constellation
tone
mapper
mapper
LDPC
Constellation CSD per
Spatial Mapping
tone
Stream Parser
mapper
LDPC Encoder
STS
PHY Padding
mapper
Scrambler
STBC
...
...
...
LDPC CSD per
Constellation
tone STS
mapper
mapper
Insert GI
Analog
and IDFT
and RF
Window
...
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Figure 21-11—Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz
VHT SU PPDU with LDPC encoding
2518
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 21-12 shows the transmit process for generating the Data field of a 20 MHz, 40 MHz, or 80 MHz
VHT MU PPDU with BCC and LDPC encoding.
Constellation LDPC tone
mapper mapper
Stream Parser
PHY Padding
Scrambler Constellation LDPC tone CSD
Encoder
mapper mapper per STS
LDPC
...
...
Constellation LDPC tone CSD
Spatial Mapping
mapper mapper per STS
User 0 (Using LDPC)
...
...
BCC Encoder Parser
BCC Constellation CSD
Encoder
BCC
Interleaver mapper per STS
PHY Padding
Stream Parser
Scrambler
...
...
Encoder
BCC
BCC Constellation CSD
Interleaver mapper per STS
User Nuser-1 (Using BCC)
Insert GI
Analog
and IDFT
and RF
Window
...
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Figure 21-12—Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or
80 MHz VHT MU PPDU
2519
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 21-13 and Figure 21-14 show the transmit process for generating the Data field of a 160 MHz VHT
SU PPDU with BCC and LDPC encoding, respectively.
BCC Constellation
BCC Encoder
Segment
Interleaver mapper
Parser
Segment
Constellation Deparser
Interleaver
mapper
CSD
per STS
BCC Encoder Parser
BCC Encoder
Spatial Mapping
Stream Parser
PHY Padding
Scrambler
STBC
BCC Encoder
BCC Constellation
Segment
Interleaver mapper CSD
Parser
Segment
BCC Constellation Deparser per STS
Interleaver mapper
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Figure 21-13—Transmitter block diagram for the Data field of a 160 MHz VHT SU PPDU
with BCC encoding
Constellation LDPC tone
Segment
mapper mapper
Parser
Segment
Deparser
Constellation LDPC tone
mapper mapper
CSD
per STS
Spatial Mapping
LDPC Encoder
Stream Parser
PHY Padding
Scrambler
STBC
Constellation LDPC tone
Segment
mapper mapper CSD
Parser
Segment
Deparser per STS
Constellation LDPC tone
mapper mapper
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Figure 21-14—Transmitter block diagram for the Data field of a 160 MHz VHT SU PPDU with
LDPC encoding
2520
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 21-15 and Figure 21-16 show the transmit process for generating the Data field of an 80+80 MHz
VHT SU PPDU with BCC and LDPC encoding, respectively.
BCC Constellation
BCC Encoder
Segment
Parser
Interleaver mapper
Constellation
BCC
Interleaver Constellation LDPC tone
CSD
mapper
Interleaver mapper mapper
per STS
Spatial Mapping
BCC Encoder Parser
BCC Encoder
Stream Parser
PHY Padding
...
STBC
Scrambler
Spatial Mapping
...
...
STBC
...
BCC Encoder
BCC Constellation CSD
Segment
Interleaver mapper
Parser
per STS
BCC Constellation CSD
Interleaver mapper per STS
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
...
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Figure 21-15—Transmitter block diagram for the Data field of an 80+80 MHz VHT SU PPDU
with BCC encoding
2521
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Constellation LDPC tone
Segment
Parser
mapper mapper
Constellation LDPC tone CSD
mapper mapper per STS
Spatial Mapping
......
LDPC Encoder
Stream Parser
PHY Padding
STBC
......
Scrambler
Spatial Mapping
...
STBC
Constellation LDPC tone CSD
Segment
mapper mapper
Parser
per STS
Constellation LDPC tone CSD
mapper mapper per STS
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
...
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Figure 21-16—Transmitter block diagram for the Data field of an 80+80 MHz VHT SU PPDU
with LDPC encoding
21.3.4 Overview of the PPDU encoding process
21.3.4.1 General
This subclause provides an overview of the VHT PPDU encoding process.
21.3.4.2 Construction of L-STF
Construct the L-STF field as defined in 21.3.8.2.2 with the following highlights:
a) Determine the CH_BANDWIDTH from the TXVECTOR.
b) Sequence generation: Generate the L-STF sequence over the CH_BANDWIDTH as described in
21.3.8.2.2.
c) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
d) IDFT: Compute the inverse discrete Fourier transform.
e) CSD: Apply CSD for each transmit chain and frequency segment as described in 21.3.8.2.1.
f) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in
21.3.7.4.
2522
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.3 Construction of the L-LTF
Construct the L-LTF field as defined in 21.3.8.2.3 with the following highlights:
a) Determine the CH_BANDWIDTH from the TXVECTOR.
b) Sequence generation: Generate the L-LTF sequence over the CH_BANDWIDTH as described in
21.3.8.2.3.
c) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
d) IDFT: Compute the inverse discrete Fourier transform.
e) CSD: Apply CSD for each transmit chain and frequency segment as described in 21.3.8.2.1.
f) Insert GI and apply windowing: Prepend a GI ( 2 LONG_GI ) and apply windowing as described
in 21.3.7.4.
g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.4 Construction of L-SIG
Construct the L-SIG field as the SIGNAL field defined by 21.3.8.2.4 with the following highlights:
a) In a VHT PPDU set the RATE subfield in the SIGNAL field to 6 Mb/s. Set the Length, Parity, and
Tail bits in the SIGNAL field as described in 21.3.8.2.4.
b) BCC encoder: Encode the SIGNAL field by a convolutional encoder at the rate of R=1/2 as
described in 21.3.10.5.3.
c) BCC interleaver: Interleave as described in 21.3.10.8.
d) Constellation Mapper: BPSK modulate as described in 21.3.10.9.
e) Pilot insertion: Insert pilots as described in 21.3.10.11.
f) Duplication and phase rotation: Duplicate the L-SIG field over each 20 MHz of the
CH_BANDWIDTH. Apply appropriate phase rotation for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
g) IDFT: Compute the inverse discrete Fourier transform.
h) CSD: Apply CSD for each transmit chain and frequency segment as described in 21.3.8.2.1.
i) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in
21.3.7.4.
j) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.5 Construction of VHT-SIG-A
The VHT-SIG-A field consists of two symbols, VHT-SIG-A1 and VHT-SIG-A2, as defined in 21.3.8.3.3
and is constructed as follows:
a) Obtain the CH_BANDWIDTH, STBC, GROUP_ID, PARTIAL_AID (SU only), NUM_STS,
GI_TYPE, FEC_CODING, MCS (SU only), BEAMFORMED (SU only), NUM_USERS, and
TXOP_PS_NOT_ALLOWED from the TXVECTOR. Add the reserved bits, append the calculated
CRC, then append the N tail tail bits as shown in 21.3.8.3.3. This results in 48 uncoded bits.
2523
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
b) BCC encoder: Encode the data by a convolutional encoder at the rate of R=1/2 as described in
17.3.5.6
c) BCC interleaver: Interleave as described in 17.3.5.7.
d) Constellation mapper: BPSK modulate the first 48 interleaved bits as described in 17.3.5.8 to form
the first symbol of VHT-SIG-A. BPSK modulate the second 48 interleaved bits and rotate by 90°
counter-clockwise relative to the first symbol to form the second symbol of VHT-SIG-A.
e) Pilot insertion: Insert pilots as described in 117.3.5.9.
f) Duplication and phase rotation: Duplicate VHT-SIG-A1 and VHT-SIG-A2 over each 20 MHz of the
CH_BANDWIDTH. Apply the appropriate phase rotation for each 20 MHz subchannel as described
in 21.3.7.4 and 21.3.7.5.
g) IDFT: Compute the inverse discrete Fourier transform.
h) CSD: Apply CSD for each transmit chain and frequency segment as described in 21.3.8.2.1.
i) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in
21.3.7.4.
j) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.6 Construction of VHT-STF
The VHT-STF field is defined in 21.3.8.3.4 and is constructed as follows:
a) Sequence generation: Generate the VHT-STF in the frequency domain over the bandwidth indicated
by CH_BANDWIDTH as described in 21.3.8.3.4.
b) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
c) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2.
d) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1.
e) IDFT: Compute the inverse discrete Fourier transform.
f) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in
21.3.7.4.
g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.7 Construction of VHT-LTF
The VHT-LTF field is defined in 21.3.8.3.5 and constructed as follows:
a) Sequence generation: Generate the VHT-LTF sequence in the frequency domain over the bandwidth
indicated by CH_BANDWIDTH as described in 21.3.8.3.5.
b) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
c) AVHT-LTF matrix mapping: Apply the PVHT-LTF matrix to the data tones of the VHT-LTF sequence
and apply the RVHT-LTF matrix to the pilot tones as described in 21.3.8.3.5.
d) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2.
e) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1.
f) IDFT: Compute the inverse discrete Fourier transform.
g) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in
21.3.7.4.
2524
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
h) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.8 Construction of VHT-SIG-B
The VHT-SIG-B field is constructed per-user as follows:
a) Obtain the VHT-MCS (for MU only) and APEP_LENGTH from the TXVECTOR.
b) VHT-SIG-B bits: Set the VHT-MCS (for MU only) and VHT-SIG-B Length field as described in
21.3.8.3.6. Add the reserved bits (for SU only) and N tail bits of tail. In an NDP set VHT-SIG-B to
the fixed bit pattern for the bandwidth used as described in 21.3.8.3.6.
c) VHT-SIG-B Bit Repetition: Repeat the VHT-SIG-B bits as a function of CH_BANDWIDTH as
defined in 21.3.8.3.6.
d) BCC encoder: Encode the VHT-SIG-B field using BCC at rate R=1/2 as described in 17.3.5.6.
e) Segment parser (if needed): In a 160 MHz or 80+80 MHz transmission, divide the output bits of the
BCC encoder into two frequency subblocks as described in 21.3.10.7. This block is bypassed for
20 MHz, 40 MHz, and 80 MHz VHT PPDU transmissions.
f) BCC interleaver: Interleave as described in 21.3.10.8.
g) Constellation mapper: Map to a BPSK constellation as defined in 17.3.5.8.
h) Segment deparser (if needed): In a 160 MHz transmission, merge the two frequency subblocks into
one frequency segment as described in 21.3.10.9.3. This block is bypassed for 20 MHz, 40 MHz,
80 MHz, and 80+80 MHz VHT PPDU transmissions.
i) Pilot insertion: Insert pilots following the steps described in 21.3.10.10.
j) P VHT - LTF matrix mapping: Apply the mapping of the 1st column of the P VHT - LTF matrix to the data
subcarriers as described in 21.3.8.3.6. The total number of data and pilot subcarriers is the same as in
the Data field.
k) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2.
l) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1.
m) Phase rotation: Apply the appropriate phase rotations for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
n) IDFT: Compute the inverse discrete Fourier transform.
o) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in
21.3.7.4.
p) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.9 Construction of the Data field in a VHT SU PPDU
21.3.4.9.1 Using BCC
The construction of the Data field in a VHT SU PPDU with BCC encoding proceeds as follows:
a) Insert the CRC calculated for VHT-SIG-B in the SERVICE field as described in 21.3.10.2 and
append the PSDU to the SERVICE field.
b) PHY padding: Append the PHY pad bits and tail bits to the PSDU.
c) Scrambler: Scramble the PHY padded data.
d) BCC encoder: Divide the scrambled bits between the encoders by sending bits to different encoders
in a round robin manner. The number of encoders is determined by rate-dependent parameters
described in 21.5. BCC encode as described in 21.3.10.5.2 and 21.3.10.5.3.
2525
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
e) Stream parser: Rearrange the output of the BCC encoders into blocks as described in 21.3.10.6.
f) Segment parser (if needed): In a 160 MHz or 80+80 MHz transmission, divide the output bits of
each stream parser into two frequency subblocks as described in 21.3.10.7. This block is bypassed
for 20 MHz, 40 MHz, and 80 MHz VHT PPDU transmissions.
g) BCC interleaver: Interleave as described in 21.3.10.8.
h) Constellation mapper: Map to BPSK, QPSK, 16-QAM, 64-QAM, or 256-QAM constellation points
as described in 21.3.10.9.
i) Segment deparser (if needed): In a 160 MHz transmission, merge the two frequency subblocks into
one frequency segment as described in 21.3.10.9.3. This block is bypassed for 20 MHz, 40 MHz,
80 MHz, and 80+80 MHz VHT PPDU transmissions.
j) STBC: Apply STBC as described in 21.3.10.9.4.
k) Pilot insertion: Insert pilots following the steps described in 21.3.10.10.
l) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2.
m) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1.
n) Phase rotation: Apply the appropriate phase rotations for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
o) IDFT: In an 80+80 MHz transmission, map each frequency subblock to a separate IDFT. Compute
the inverse discrete Fourier transform.
p) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as
described in 21.3.7.4.
q) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.9.2 Using LDPC
The construction of the Data field in a VHT SU PPDU with LDPC encoding proceeds as follows:
a) Insert the CRC calculated for VHT-SIG-B in the SERVICE field as described in 21.3.10.2 and
append the PSDU to the SERVICE field.
b) PHY padding: Append the PHY pad bits to the PSDU. There are no tail bits.
c) Scrambler: Scramble the PHY padded data.
d) LDPC encoder: The scrambled bits are encoded using the LDPC code with the APEP_LENGTH in
the TXVECTOR as described in 21.3.10.5.4.
e) Stream parser: The output of the LDPC encoder is rearranged into blocks as described in 21.3.10.6.
f) Segment parser (if needed): In a 160 MHz or 80+80 MHz transmission, divide the output bits of
each stream parser into two frequency subblocks as described in 21.3.10.7. This block is bypassed
for 20 MHz, 40 MHz, and 80 MHz VHT PPDU transmissions.
g) Constellation mapper: Map to BPSK, QPSK, 16-QAM, 64-QAM or 256-QAM constellation points
as described in 21.3.10.9.
h) LDPC tone mapper: The LDPC tone mapping shall be performed on all LDPC encoded streams as
described in 21.3.10.9.2.
i) Segment deparser (if needed): In a 160 MHz transmission, merge the two frequency subblocks into
one frequency segment as described in 21.3.10.9.3. This block is bypassed for 20 MHz, 40 MHz,
80 MHz, and 80+80 MHz VHT PPDU transmissions.
j) STBC: Apply STBC as described in 21.3.10.9.4.
k) Pilot insertion: Insert pilots following the steps described in 21.3.10.10.
l) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2.
2526
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
m) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1.
n) Phase rotation: Apply the appropriate phase rotations for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
o) IDFT: In an 80+80 MHz transmission, map each frequency subblock to a separate IDFT. Compute
the inverse discrete Fourier transform.
p) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as
described in 21.3.7.4.
q) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.4.10 Construction of the Data field in a VHT MU PPDU
21.3.4.10.1 General
In an MU transmission, the PPDU encoding process is performed independently on a per-user basis up to the
input of the Spatial Mapping block, except that CSD is performed with a knowledge of the space time
stream starting index for that user. All user data is combined and mapped to the transmit chains in the Spatial
Mapping block.
21.3.4.10.2 Using BCC
A Data field with BCC encoding is constructed using steps a) to k) in 21.3.4.9.1, then applying CSD for a
VHT MU PPDU (as described in 21.3.8.3.2).
21.3.4.10.3 Using LDPC
A Data field with LDPC encoding is constructed using steps a) to k) in 21.3.4.9.2, then applying CSD as for
a VHT MU PPDU (as described in 22.3.8.3.2).
21.3.4.10.4 Combining to form a VHT MU PPDU
The per-user data is combined as follows:
a) Spatial Mapping: The Q matrix is applied as described in 21.3.10.11.1. The combining of all user
data is done in this block.
b) Phase rotation: Apply the appropriate phase rotations for each 20 MHz subchannel as described in
21.3.7.4 and 21.3.7.5.
c) IDFT: Compute the inverse discrete Fourier transform.
d) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as
described in 21.3.7.4.
e) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
21.3.7.4 and 21.3.8 for details.
21.3.5 VHT modulation and coding scheme (VHT-MCS)
The VHT-MCS is a value that determines the modulation and coding used in the Data field of the PPDU. It
is a compact representation that is carried in the VHT-SIG-A field for VHT SU PPDUs and in the VHT-
SIG-B field for VHT MU PPDUs. Rate-dependent parameters for the full set of VHT-MCSs are shown in
Table 21-30 to Table 21-61 (in 21.5). These tables give rate-dependent parameters for VHT-MCSs with
indices 0 to 9, with number of spatial streams from 1 to 8 and bandwidth options of 20 MHz, 40 MHz,
2527
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
80 MHz, and either 160 MHz or 80+80 MHz. Equal modulation (EQM) is applied to all streams for a
particular user.
21.3.6 Timing-related parameters
Refer to Table 19-6 for timing-related parameters for non-VHT formats.
Table 21-5 defines the timing-related parameters for VHT format.
Table 21-5—Timing-related constants
Parameter CBW20 CBW40 CBW80 CBW80+80 CBW160 Description
NSD 52 108 234 234 468 Number of complex
data numbers per
frequency segment
NSP 4 6 8 8 16 Number of pilot values
per frequency segment
NST 56 114 242 242 484 Total number of
subcarriers per
frequency segment.
See NOTE.
NSR 28 58 122 122 250 Highest data subcarrier
index per frequency
segment
NSeg 1 1 1 2 1 Number of frequency
segments
∆F 312.5 kHz Subcarrier frequency
spacing
TDFT 3.2 µs IDFT/DFT period
TGI 0.8 µs = TDFT /4 Guard interval
duration
TGI2 1.6 µs Double guard interval
TGIS 0.4 µs = TDFT /8 Short guard interval
duration
TSYML 4 µs = TDFT + TGI = 1.25 TDFT Long GI symbol
interval
TSYMS 3.6 µs = TDFT + TGIS = 1.125 TDFT Short GI symbol
interval
TSYM TSYML or TSYMS depending on the GI used (see Table 21-8) Symbol interval
TL-STF 8 µs = 10 x TDFT /4 Non-HT Short
Training field duration
TL-LTF 8 µs = 2 x TDFT + TGI2 Non-HT Long
Training field duration
TL-SIG 4 µs = TSYML Non-HT SIGNAL
field duration
TVHT-SIG-A 8 µs = 2TSYML VHT Signal A field
duration
2528
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-5—Timing-related constants (continued)
Parameter CBW20 CBW40 CBW80 CBW80+80 CBW160 Description
TVHT-STF 4 µs = TSYML VHT Short Training
field duration
TVHT-LTF 4 µs = TSYML Duration of each VHT-
LTF symbol
TVHT-SIG-B 4 µs = TSYML VHT Signal B field
duration
Nservice 16 Number of bits in the
SERVICE field
Ntail 6 Number of tail bits per
BCC encoder
NOTE—NST = NSD + NSP
Table 21-6 defines parameters used frequently in Clause 21.
Table 21-6—Frequently used parameters
Symbol Explanation
NCBPS, NCBPS,u Number of coded bits per symbol for user u, u = 0, ..., Nuser–1.
For a VHT SU PPDU, NCBPS = NCBPS,0
For a VHT MU PPDU, NCBPS is undefined
NCBPSS, NCBPSS,u Number of coded bits per symbol per spatial stream.
For the VHT-SIG-B field, NCBPSS is common for all users.
N SD for a 20 MHz, 40 MHz, 80 MHz, and 160 MHz PPDU
N CBPSS =
2N SD for an 80+80 MHz PPDU
for all users.
For the Data field, NCBPSS,u equals the number of coded bits per symbol per spatial
stream for user u, u = 0, ..., Nuser–1.
For the Data field of a VHT SU PPDU, NCBPSS = NCBPSS,0
For the Data field of a VHT MU PPDU, NCBPSS is undefined
NCBPSSI, NCBPSSI,u Number of coded bits per symbol per spatial stream per BCC interleaver block.
For a VHT SU PPDU,
N CBPSS for a 20 MHz, 40 MHz, or 80 MHz PPDU
N CBPSSI = N CBPSS
----------------- for a 160 MHz or 80+80 MHz PPDU
2
For a VHT MU PPDU for user u, u = 0, ..., Nuser–1
N CBPSS u for a 20 MHz, 40 MHz, or 80 MHz PPDU
N CBPSSI u = N CBPSS u
--------------------- for a 160 MHz or 80+80 MHz PPDU
2
For a VHT MU PPDU, NCBPSSI is undefined.
2529
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-6—Frequently used parameters (continued)
Symbol Explanation
NDBPS, NDBPS,u Number of data bits per symbol for user u, u = 0, ..., Nuser–1.
For a VHT SU PPDU, NDBPS = NDBPS,0
For a VHT MU PPDU, NDBPS is undefined
NBPSCS, NBPSCS,u Number of coded bits per subcarrier per spatial stream for user u, u = 0, ..., Nuser–1.
For a VHT SU PPDU, NBPSCS = NBPSCS,0
For a VHT MU PPDU, NBPSCS is undefined
NRX Number of receive chains
Nuser For pre-VHT modulated fields, Nuser = 1. For VHT modulated fields, Nuser
represents the number of users in the transmission (equal to the TXVECTOR
parameter NUM_USERS).
NSTS, NSTS,u For pre-VHT modulated fields, NSTS,u = 1 (see NOTE). For VHT modulated fields,
NSTS,u is the number of space-time streams for user u, u = 0,…, Nuser–1.
For a VHT SU PPDU, NSTS = NSTS,0.
For a VHT MU PPDU, NSTS is undefined.
NSTS,total For VHT modulated fields, NSTS,total is the total number of space-time streams in a
PPDU.
N user – 1
N STS total = N STS u
u=0
For pre-VHT modulated fields, NSTS,total is undefined.
Note that NSTS,total = NSTS for a VHT SU PPDU.
NSS, NSS,u Number of spatial streams.
For the VHT-SIG-B field, NSS = 1 for each user.
For the Data field, NSS,u is the number of spatial streams for user u, u = 0,…, Nuser–
1.
For the Data field of a VHT SU PPDU, NSS = NSS,0.
For the Data field of a VHT MU PPDU, NSS is undefined.
NTX Number of transmit chains
NES, NES,u The number of BCC encoders.
For the VHT-SIG-B field, NES = 1 for each user.
For a Data field encoded using BCC, NES,u is the number of BCC encoders for user
u, u = 0,…, Nuser–1.
For the Data field encoded using LDPC, NES = 1 for a VHT SU PPDU and
NES,u = 1 for a VHT MU PPDU for user u, u = 0, …Nuser–1.
For the Data field of a VHT SU PPDU, NES = NES,0.
For the Data field of a VHT MU PPDU, NES is undefined.
NVHT-LTF Number of VHT-LTF symbols (see 21.3.8.3.5)
2530
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-6—Frequently used parameters (continued)
Symbol Explanation
R, Ru Ru is the coding rate for user u, u = 0, ..., Nuser–1.
For a VHT SU PPDU, R = R0
For a VHT MU PPDU, R is undefined
Mu For pre-VHT modulated fields, Mu = 0. For VHT modulated fields, M 0 = 0 for
u–1
u = 0 and M u = N STS u' for u = 1, …Nuser–1.
u' = 0
NOTE—For pre-VHT modulated fields, u is 0 only since Nuser = 1.
21.3.7 Mathematical description of signals
21.3.7.1 Notation
For a description of the conventions used for the mathematical description of the signals, see 17.3.2.5. In
addition, the following notational conventions are used in Clause 21:
Q indicates the element in row m and column n of matrix Q , where 1 m Nrow and 1 n Ncol
m n
Nrow and Ncol are the number of rows and columns, respectively, of the matrix Q
Q indicates a matrix consisting of columns M to N of matrix Q
M:N
21.3.7.2 Subcarrier indices in use
For description on subcarrier indices over which the signal is transmitted for non-HT and HT PPDUs, see
19.3.7.
For a 20 MHz VHT PPDU transmission, the 20 MHz is divided into 64 subcarriers. The signal is transmitted
on subcarriers –28 to –1 and 1 to 28, with 0 being the center (DC) subcarrier.
For a 40 MHz VHT PPDU transmission, the 40 MHz is divided into 128 subcarriers. The signal is
transmitted on subcarriers –58 to –2 and 2 to 58.
For an 80 MHz VHT PPDU transmission, the 80 MHz is divided into 256 subcarriers. The signal is
transmitted on subcarriers –122 to –2 and 2 to 122.
For a 160 MHz VHT PPDU transmission, the 160 MHz is divided into 512 subcarriers. The signal is
transmitted on subcarriers –250 to –130, –126 to –6, 6 to 126, and 130 to 250.
For an 80+80 MHz VHT PPDU transmission, each 80 MHz frequency segment is divided into 256
subcarriers. In each frequency segment, the signal is transmitted on subcarriers –122 to –2 and 2 to 122.
2531
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.7.3 Channel frequencies
Let
fc idx0 = dot11CurrentChannelCenterFrequencyIndex0 (21-1)
fc idx1 = dot11CurrentChannelCenterFrequencyIndex1 (21-2)
f P20 idx = dot11CurrentPrimaryChannel (21-3)
f CH start = dot11ChannelStartingFactor 500 kHz (21-4)
where
dot11CurrentChannelCenterFrequencyIndex0, dot11CurrentChannelCenterFrequencyIndex1, and
dot11CurrentPrimaryChannel are defined in Table 21-22.
When dot11CurrentChannelWidth (see Table 21-22) is 20 MHz, f P20 idx = f c idx0 . For
dot11CurrentChannelWidth greater than 20 MHz, f P20 idx and f c idx0 shall have the relationship specified in
Equation (21-5).
N 20MHz
f P20 idx = fc idx0 –4 ----------------
- – n P20 + 2 (21-5)
2
where
2 if dot11CurrentChannelWidth indicates 40 MHz
N 20MHz = 4 if dot11CurrentChannelWidth indicates 80 MHz and 80+80 MHz
8 if dot11CurrentChannelWidth indicates 160 MHz
n P20 is an integer with possible range 0 n P20 N 20MHz – 1
When dot11CurrentChannelWidth is 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz,
— The primary 20 MHz channel is the channel with 20 MHz bandwidth centered at
f CH start + 5 f P20 idx MHz.
— The secondary 20 MHz channel is the channel with 20 MHz bandwidth centered at
f CH start + 5 f S 20 idx , where f S 20 idx is given in Equation (21-6).
f P20 idx +4 if n P20 is even
f S20 idx = (21-6)
f P20 idx –4 if n P20 is odd
When dot11CurrentChannelWidth is 80 MHz, 160 MHz, or 80+80 MHz,
— The primary 40 MHz channel is the channel with 40 MHz bandwidth centered at
f CH start + 5 f P40 idx MHz, where f P40 idx is given in Equation (21-7).
— The secondary 40 MHz channel is the channel with 40 MHz bandwidth centered at
f CH start + 5 f S 40 idx MHz, where f S 40 idx is given in Equation (21-8).
N 20MHz
f P40 idx = fc idx0 –8 ----------------
- – n P40 + 4 (21-7)
4
2532
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
f P40 idx +8 if n P40 is even
f S40 idx = (21-8)
f P40 idx –8 if n P40 is odd
where n P40 = n P20 2
When dot11CurrentChannelWidth is 160 MHz,
— The primary 80 MHz channel is the channel with 80 MHz bandwidth centered at
f CH start + 5 f P80 idx MHz, where f P80 idx is given in Equation (21-9).
— The secondary 80 MHz channel is the channel with 80 MHz bandwidth centered at
f CH start + 5 f S80 idx MHz where f S80 idx is given in Equation (21-10).
N 20MHz
f P80 idx = fc idx0 – 16 ----------------
- – n P80 + 8 (21-9)
8
f P80 idx + 16 if n P80 is even
f S80 idx = (21-10)
f P80 idx – 16 if n P80 is odd
where n P80 = n P20 4 .
When dot11CurrentChannelWidth is 80+80 MHz,
— The primary 80 MHz channel is the channel with 80 MHz bandwidth centered at
f CH start + 5 f P80 idx MHz, where f P80 idx = f c idx0 .
— The secondary 80 MHz channel is the channel with 80 MHz bandwidth centered at
f CH start + 5 f S80 idx MHz where f S80 idx = f c idx1 .
21.3.7.4 Transmitted signal
The transmitted signal is described in complex baseband signal notation. The actual transmitted signal is
related to the complex baseband signal by the relation shown in Equation (21-11).
i i TX 1 i Seg i TX i
r RFSeg (t) = Re --------------- r PPDU (t)exp(j2 f c Seg t) (21-11)
N Seg
i Seg = 0 N Seg – 1 ; i TX = 1 N TX
where
N Seg represents the number of frequency segments in the transmit signal, as defined in Table 21-5;
i Seg i TX
r PPDU (t) represents the complex baseband signal of frequency segment iSeg and transmit chain iTX;
i
f c Seg represents the center frequency of the portion of the PPDU transmitted in frequency segment
iSeg. Table 21-7 shows f ciSeg as a function of the channel starting frequency and
dot11CurrentChannelWidth (see Table 21-22) where f P20 idx , f P40 idx , and f P80 idx are given in
Equation (21-4), Equation (21-5), Equation (21-7), and Equation (21-9), respectively.
NOTE—Transmitted signals might have different impairments such as phase offset or phase noise between the two fre-
quency segments, which is not shown in Equation (21-11) for simplicity. See 21.3.17.3.
2533
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-7—Center frequency of the portion of the PPDU transmitted in
frequency segment iSeg
f ciSeg = f CH start +5 f i Seg
dot11CurrentChannel
CH_BANDWIDTH
Width
f 0 f 1
20 MHz CBW20 fc idx0 –
CBW20 f P20 idx –
40 MHz
CBW40 fc idx0 –
CBW20 f P20 idx –
80 MHz CBW40 f P40 idx –
CBW80 fc idx0 –
CBW20 f P20 idx –
CBW40 f P40 idx –
160 MHz
CBW80 f P80 idx –
CBW160 fc idx0 –
CBW20 f P20 idx –
CBW40 f P40 idx –
80+80 MHz
CBW80 f P80 idx –
CBW80+80 min f c idx0 fc idx1 max f c idx0 fc idx1
The transmitted RF signal is derived by upconverting the complex baseband signal, which consists of
several fields. The timing boundaries for the various fields are shown in Figure 21-17 where NVHTLTF is the
number of VHT-LTF symbols and is defined in Table 21-13.
Non-VHT portion VHT portion
Pre-VHT-modulated fields VHT modulated fields
VHT-LTF Data
VHT- VHT- VHT-
VHT- VHT- Data Data
L-STF L-LTF L-SIG VHT-SIG-A LTF LTF LTF
STF SIG-B symbol symbol
symbol symbol symbol
NVHTLTF
t=0 tL-LTF tL-SIG tVHT-SIG-A tVHT-STF tVHT-LTF tVHT-SIG-B tVHT-Data
Figure 21-17—Timing boundaries for VHT PPDU fields
2534
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The time offset, t Field , determines the starting time of the corresponding field relative to the start of L-STF
(t = 0).
The signal transmitted on frequency segment i Seg and transmit chain i TX shall be as shown in
Equation (21-12).
i Seg i TX i Seg i TX i Seg i TX
r PPDU (t) = r L-STF (t) + r L-LTF (t – t L-LTF) (21-12)
i Seg i TX i Seg i TX
+ r L-SIG (t – t L-SIG) + r VHT-SIG-A(t – t VHT-SIG-A)
i Seg i TX i Seg i TX
+ r VHT-STF(t – t VHT-STF) + r VHT-LTF (t – t VHT-LTF)
i Seg i TX i Seg i TX
+ r VHT-SIG-B(t – t VHT-SIG-B) + r VHT-Data(t – t VHT-Data)
where
0 i Seg N Seg – 1
1 i TX N TX
t L-LTF = T L-STF
t L-SIG = t L-LTF + T L-LTF
t VHT-SIG-A = t L-SIG + T L-SIG
t VHT-STF = t VHT-SIG-A + T VHT-SIG-A
t VHT-LTF = t VHT-STF + T VHT-STF
t VHT-SIG-B = t VHT-LTF + N VHT - LTF T VHT-LTF
t VHT-Data = t VHT-SIG-B + T VHT-SIG-B
Seg TX i i
Each field, r Field (t) , is defined as the summation of one or more subfields, where each subfield is defined
to be an inverse discrete Fourier transform as specified in Equation (21-13).
N SR N user – 1 N STS u
i Seg i TX 1 i Seg m
r Subfield (t) = ------------------------------- w TSubfield(t) i
Q k Seg k BW X k u (21-13)
Tone i TX M u + m
N Field N Norm k = – N SR u=0 m=1
exp(j2 k F t – T GI Field – T CS VHT Mu + m )
This general representation holds for all subfields. The total power of the time domain VHT modulated field
signals summed over all transmit chains should not exceed the total power of the time domain pre-VHT
modulated field signals summed over all transmit chains. For notational simplicity, the parameter BW is
omitted from some bandwidth dependent terms.
In Equation (21-13) the following notions are used:
Tone Tone
N Field Table 21-8 summarizes the various values of N Field as a function of bandwidth per frequency
segment.
2535
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-8—Tone scaling factor and guard interval duration values for PHY fields
Tone
N Field as a function of bandwidth per frequency
segment Guard interval
Field
duration
20 MHz 40 MHz 80 MHz 160 MHz
L-STF 12 24 48 96 -
L-LTF 52 104 208 416 TGI2
L-SIG 52 104 208 416 TGI
VHT-SIG-A 52 104 208 416 TGI
VHT-STF 12 24 48 96 -
VHT-LTF 56 114 242 484 TGI
VHT-SIG-B 56 114 242 484 TGI
VHT-Data 56 114 242 484 TGI or TGIS
(see NOTE 2)
NON_HT_DUP_OFDM-Data - 104 208 416 TGI
(see NOTE 1)
NOTE 1—For notational convenience, NON_HT_DUP_OFDM-Data is used as a label for the Data field of a
NON_HT PPDU with format type NON_HT_DUP_OFDM.
NOTE 2—TGI denotes guard interval duration when TXVECTOR parameter GI_TYPE equals LONG_GI,
TGIS denotes short guard interval duration when TXVECTOR parameter GI_TYPE equals SHORT_GI.
N Norm For pre-VHT modulated fields, N Norm = N TX . For VHT modulated fields,
N Norm = N STS total where N STS total is given in Table 21-6.
w TSubfield(t) is a windowing function. An example function, w TSubfield(t) , is given in 17.3.2.5. T Subfield is TL-
STF for L-STF, TL-LTF for L-LTF, TL-SIG for L-SIG, TSYML for VHT-SIG-A, TVHT-STF for
VHT-STF, TVHT-LTF for VHT-LTF and TVHT-SIG-B for VHT-SIG-B. T Subfield is TSYM for VHT-
Data, that is TSYML when not using the short guard interval (Short GI field of VHT-SIG-A is 0)
and TSYMS when using the short guard interval (Short GI field of VHT-SIG-A is 1).
Q kiSeg is the spatial mapping matrix for the subcarrier k in frequency segment i Seg . For pre-VHT
modulated fields, Q kiSeg is a column vector with N TX elements with element i TX being
i TX i TX
exp(– j2 k F T CS ) , where T CS represents the cyclic shift for transmitter chain i TX whose
values are given in Table 21-10. For VHT modulated fields, Q kiSeg is a matrix with N TX rows
and N STS total columns.
k BW is defined in 21.3.7.5
F is the subcarrier frequency spacing given in Table 21-5.
i m
X k Seg
u is the frequency domain symbol in subcarrier k of user u for frequency segment i Seg of space-
Seg i m
time stream m. Some of the X k u within – N SR k N SR have a value of 0. Examples of
such cases include the DC tones, guard tones on each side of the transmit spectrum, as well as
2536
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the unmodulated tones of L-STF and VHT-STF fields. Note that the multiplication matrices
Seg i m
k
A VHT - LTF and P VHT - LTF are included in the calculation of X k u for the VHT-LTF and VHT-
SIG-B fields, respectively.
T GI Field is the guard interval duration used for each OFDM symbol in the field. For L-STF and VHT-
STF, T GI Field = T GI but it can be omitted from Equation (21-13) due to the periodic property
of L-STF and VHT-STF over every 0.8 µs. For the L-SIG, VHT-SIG-A, VHT-LTF, and VHT-
SIG-B fields, T GI Field is defined in the “Guard interval duration” column of Table 21-8.
T CS VHT(l) For pre-VHT modulated fields, T CS VHT(l) = 0 . For VHT modulated fields, T CS VHT(l)
represents the cyclic shift per space-time stream, whose value is defined in Table 21-11.
Mu is defined in Table 21-6.
21.3.7.5 Definition of tone rotation
The function k BW is used to represent a rotation of the tones. BW in k BW is determined by the
TXVECTOR parameter CH_BANDWIDTH as defined in Table 21-9.
Table 21-9—CH_BANDWIDTH and k BW
CH_BANDWIDTH k BW
CBW20 k 20
CBW40 k 40
CBW80 k 80
CBW160 k 160
CBW80+80 k 80 per frequency segment
For a 20 MHz PPDU transmission,
k 20 = 1 (21-14)
For a 40 MHz PPDU transmission,
1 k 0
k 40 = (21-15)
j k 0
For an 80 MHz PPDU transmission,
1 k – 64
k 80 = (21-16)
–1 k – 64
For an 80+80 MHz PPDU transmission, each 80 MHz frequency segment shall use the phase rotation for
80 MHz PPDU transmissions as defined in Equation (21-16).
2537
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For a 160 MHz PPDU transmission,
1 k – 192
–1 – 192 k 0
k 160 = (21-17)
1 0 k 64
–1 64 k
21.3.8 VHT preamble
21.3.8.1 Introduction
A VHT preamble is defined to carry the required information to operate in either single user or multi-user
mode. To maintain compatibility with non-VHT STAs, specific non-VHT fields are defined that can be
received by non-VHT STAs compliant with Clause 17 or Clause 19. The non-VHT fields are followed by
VHT fields specific to VHT STAs.
21.3.8.2 Non-VHT portion of VHT format preamble
21.3.8.2.1 Cyclic shift for pre-VHT modulated fields
i TX
The cyclic shift value T CS for the L-STF, L-LTF, L-SIG, and VHT-SIG-A fields of the PPDU for transmit
chain iTX out of a total of NTX are defined in Table 21-10.
Table 21-10—Cyclic shift values for L-STF, L-LTF, L-SIG, and VHT-SIG-A fields of the PPDU
i TX
T CS values for L-STF, L-LTF, L-SIG, and VHT-SIG-A fields of the PPDU
Total Cyclic shift for transmit chain iTX (in units of ns)
number of
transmit
chains (NTX)
per 1 2 3 4 5 6 7 8 >8
frequency
segment
1 0 – – – – – – – –
2 0 –200 – – – – – – –
3 0 –100 –200 – – – – – –
4 0 –50 –100 –150 – – – – –
5 0 –175 –25 –50 –75 – – – –
6 0 –200 –25 –150 –175 –125 – – –
7 0 –200 –150 –25 –175 –75 –50 – –
8 0 –175 –150 –125 –25 –100 –50 –200 –
Between
>8 0 –175 –150 –125 –25 –100 –50 –200 –200 and 0
inclusive
2538
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.8.2.2 L-STF definition
The L-STF field for a 20 MHz or 40 MHz transmission is defined by Equation (19-8) and Equation (19-9),
respectively, in 19.3.9.3.3. For 80 MHz, the L-STF field is defined by Equation (21-18). Note that these
equations do not include the phase rotation per 20 MHz subchannel.
S –122 122 = S –58 58 0 0 0 0 0 0 0 0 0 0 0 S –58 58 (21-18)
where
S –58 58 is defined in Equation (19-9)
For 160 MHz, the L-STF is defined by Equation (21-19).
S –250 250 = S –122 122 0 0 0 0 0 0 0 0 0 0 0 S –122 122 (21-19)
where
S –122 122 is defined in Equation (21-18)
For an 80+80 MHz transmission, each 80 MHz frequency segment shall use the L-STF pattern for the
80 MHz ( S –122 122 ) defined in Equation (21-18).
The time domain representation of the signal on frequency segment i Seg and transmit chain i TX shall be as
specified in Equation (21-20).
N SR
i Seg i TX 1 i
(t) = ----------------------------- w TL-STF(t)
TX
r L-STF k BW S k exp j2 k F t – T CS (21-20)
Tone
N L-STF N TX k = – NSR
where
i
TX
T CS represents the cyclic shift for transmit chain i TX with a value given in Table 21-10
k BW is defined by Equation (21-14), Equation (21-15), Equation (21-16). and Equation (21-17)
Tone
N L-STF has the value given in Table 21-8
21.3.8.2.3 L-LTF definition
For a 20 MHz or 40 MHz transmission, the L-LTF pattern in the VHT preamble is defined by
Equation (19-11) and Equation (19-12) in 19.3.9.3.4, respectively. For an 80 MHz transmission, the L-LTF
pattern is defined by Equation (21-21). Note that these equations do not include the phase rotation per
20 MHz subchannel.
L –122 122 = L –58 58 0 0 0 0 0 0 0 0 0 0 0 L –58 58 (21-21)
where
L –58 58 is defined in Equation (19-12)
For a 160 MHz transmission, the L-LTF is defined by Equation (21-22). Note that this equation does not
include the phase rotations per 20 MHz subchannel.
2539
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
L –250 250 = L –122 122 0 0 0 0 0 0 0 0 0 0 0 L –122 122 (21-22)
where
L –122 122 is given by Equation (21-21)
For an 80+80 MHz transmission, each 80 MHz frequency segment shall use the L-LTF pattern for the
80 MHz L-LTF pattern ( L –122 122 ) defined in Equation (21-21).
The time domain representation of the signal on frequency segment i Seg and transmit chain i TX shall be as
defined in Equation (21-23).
N SR
i Seg i TX 1 i
r L-LTF (t) = ------------------------------ w TL-LTF(t) k BW L k exp j2 k F
TX
t – T GI2 – T CS (21-23)
Tone
N L-LTF N TX k = – N SR
where
i TX
T CS represents the cyclic shift for transmitter chain i TX with a value given in Table 21-10
k BW is defined by Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17)
Tone
N L-LTF has the value given in Table 21-8
21.3.8.2.4 L-SIG definition
The L-SIG field is used to communicate rate and length information. The structure of the L-SIG field is
defined in Figure 17-5.
In a VHT PPDU, the RATE field shall be set to the value representing 6 Mb/s in the 20 MHz channel
spacing column of Table 17-6. In a non-HT duplicate PPDU, the RATE field is defined in 17.3.4.2 using the
L_DATARATE parameter in the TXVECTOR.
The LENGTH field shall be set to the value given by Equation (21-24).
TXTIME – 20
Length = ---------------------------------- 3–3 (21-24)
4
where
TXTIME (in µs) is defined in 21.4.3
The LSB of the binary expression of the Length value shall be mapped to B5. In a non-HT duplicate PPDU,
the LENGTH field is defined in 17.3.4.3 using the L_LENGTH parameter in the TXVECTOR.
The Reserved (R) field shall be set to 0.
The Parity (P) field has the even parity of bits 0-16.
The SIGNAL TAIL field shall be set to 0.
The L-SIG field shall be encoded, interleaved, and mapped following the steps described in 17.3.5.6,
17.3.5.7, and 17.3.5.8. The stream of 48 complex numbers generated by these steps is denoted by
2540
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dk k = 0 47 . Pilots shall be inserted as described in 17.3.5.9. The time domain waveform of the L-SIG
field shall be as given by Equation (21-25).
i Seg i TX 1
r L-SIG (t) = ---------------------------- w TL-SIG(t) (21-25)
Tone
N L-SIG N TX
N 20MHz – 1 26
k – K Shift i BW BW Dk 20 + p0 Pk
i TX
i BW = 0 k = – 26
exp j2 k – K Shift i BW F t – T GI – T CS
where
N 20MHz is defined in 21.3.7.3
K Shift(i) = N 20MHz – 1 – 2i 32
0 k = 0 7 21
Dk 20 = (21-26)
d Mr k otherwise
20
k + 26 – 26 k – 22
k + 25 – 20 k – 8
r
M 20 k = k + 24 –6 k –1 (21-27)
k + 23 1 k 6
k + 22 8 k 20
k + 21 22 k 26
Pk is defined in 17.3.5.10
p0 is the first pilot value in the sequence defined in 17.3.5.10
Tone
N L-SIG has the value given in Table 21-8
k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17)
i
TX
T CS represents the cyclic shift for transmitter chain i TX with a value given in Table 21-10
NOTE— M 20
r (k) is a “reverse” function of the function M(k) defined in 17.3.5.10.
2541
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.8.3 VHT portion of VHT format preamble
21.3.8.3.1 Introduction
The VHT portion of the VHT format preamble consists of the VHT-SIG-A, VHT-STF, VHT-LTF, and
VHT-SIG-B fields.
21.3.8.3.2 Cyclic shift for VHT modulated fields
The cyclic shift values defined in this subclause apply to the VHT-STF, VHT-LTF, VHT-SIG-B, and Data
fields of the VHT PPDU. The cyclic shift values defined in 21.3.8.2.1 apply to VHT-SIG-A field in the VHT
format preamble.
Throughout the VHT modulated fields of the preamble, cyclic shifts are applied to prevent unintended
beamforming when correlated signals are transmitted in multiple space-time streams. The same cyclic shift
is also applied to these streams during the transmission of the Data field of the VHT PPDU. The cyclic shift
value T CS VHT n for the VHT modulated fields for space-time stream n out of NSTS,total total space-time
streams is shown in Table 21-11.
Table 21-11—Cyclic shift values for the VHT modulated fields of a PPDU
T CS VHT n values for the VHT modulated fields of a PPDU
Total number Cyclic shift for space-time stream n (ns)
of space-time
streams
(NSTS,total) 1 2 3 4 5 6 7 8
1 0 – – – – – – –
2 0 –400 – – – – – –
3 0 –400 –200 – – – – –
4 0 –400 –200 –600 – – – –
5 0 –400 –200 –600 –350 – – –
6 0 –400 –200 –600 –350 –650 – –
7 0 –400 –200 –600 –350 –650 –100 –
8 0 –400 –200 –600 –350 –650 –100 –750
In a VHT MU PPDU, the cyclic shifts are applied sequentially across the space-time streams as follows: the
cyclic shift of the space-time stream number m of user u is given by T CS VHT M u + m of the row
corresponding to NSTS,total in Table 21-11.
2542
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.8.3.3 VHT-SIG-A definition
The VHT-SIG-A field carries information required to interpret VHT PPDUs. The structure of the VHT-SIG-
A field for the first part (VHT-SIG-A1) is shown in Figure 21-18 and for the second part (VHT-SIG-A2) is
shown in Figure 21-19.
B0 B1 B2 B3 B4 B9 B10 B12 B13 B15 B16 B18 B19 B21 B22 B23
TXOP_PS_NOT
Composite Name: NSTS/Partial AID
_ALLOWED
Reserved
Reserved
Group ID
STBC
BW
SU Name: SU NSTS Partial AID
MU Name: MU[0] NSTS MU[1] NSTS MU[2] NSTS MU[3] NSTS
Bits: 2 1 1 6 3 3 3 3 1 1
Figure 21-18—VHT-SIG-A1 structure
B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B17 B18 B23
Composite Name: SU VHT-MCS/MU[1-3] Coding Beam-
SU/MU[0] Coding
formed
Short GI NSYM
Disambiguation
OFDM Symbol
LDPC Extra
Reserved
Short GI
CRC
Beam-
Tail
SU Name: SU VHT-MCS formed
MU Name: MU[1] MU[2] MU[3] Reserved Reserved
Coding Coding Coding
Bits: 1 1 1 1 1 1 1 1 1 1 8 6
Figure 21-19—VHT-SIG-A2 structure
NOTE—Integer fields are represented in unsigned binary format with the least significant bit in the lowest numbered bit
position.
The VHT-SIG-A field contains the fields listed in Table 21-12. The mapping of the fields is also described
in Table 21-12. Note that the mapping of the STBC field, the NSTS/Partial AID field, the SU/MU[0] Coding
field, the SU VHT-MCS/MU[1-3] Coding field, and the Beamformed field is different for VHT SU and MU
PPDUs.
The VHT-SIG-A field is composed of two parts, VHT-SIG-A1 and VHT-SIG-A2, each containing 24 data
bits, as shown in Table 21-12. VHT-SIG-A1 is transmitted before VHT-SIG-A2. The VHT-SIG-A symbols
shall be BCC encoded at rate, R = 1/2, be interleaved, be mapped to a BPSK constellation, and have pilots
inserted following the steps described in 17.3.5.6, 17.3.5.7, 17.3.5.8, and 17.3.5.9, respectively. The first and
second half of the stream of 96 complex numbers generated by these steps (before pilot insertion) is divided
into two groups of 48 complex numbers d k n k = 0 47 , where n = 0 1 , respectively. The first 48
complex numbers form the first symbol of VHT-SIG-A and the second 48 complex numbers form the
second symbol of VHT-SIG-A after rotating by 90° counter-clockwise relative to the first symbol. The first
symbol of VHT-SIG-A, which does not have the 90° rotation, is used to differentiate VHT PPDUs from HT
PPDUs, while the second symbol of VHT-SIG-A, which has the 90° rotation, is used to differentiate
VHT PPDUs from non-HT PPDUs.
2543
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-12—Fields in the VHT-SIG-A field
Two parts of Number
Bit Field Description
VHT-SIG-A of bits
B0-B1 BW 2 Set to 0 for 20 MHz, 1 for 40 MHz, 2 for 80 MHz, and 3 for
160 MHz and 80+80 MHz
B2 Reserved 1 Reserved. Set to 1.
B3 STBC 1 For a VHT SU PPDU:
Set to 1 if space time block coding (see 21.3.10.9.4) is
used and set to 0 otherwise.
For a VHT MU PPDU:
Set to 0.
B4-B9 Group ID 6 Set to the value of the TXVECTOR parameter GROUP_ID.
A value of 0 or 63 indicates a VHT SU PPDU; otherwise,
indicates a VHT MU PPDU.
B10-B21 NSTS/Partial 12 For a VHT MU PPDU: NSTS is divided into 4 user
AID positions of 3 bits each. User position p, where 0 p 3 ,
uses bits B( 10 + 3p ) to B( 12 + 3p ). The number of space-
time streams for user u are indicated at user position
p = USER_POSITION u where
u = 0 1 NUM_USERS – 1 and the notation A[b] denotes
the value of array A at index b. Zero space-time streams are
indicated at positions not listed in the USER_POSITION
array. Each user position is set as follows:
Set to 0 for 0 space-time streams
VHT-SIG-A1
Set to 1 for 1 space-time stream
Set to 2 for 2 space-time streams
Set to 3 for 3 space-time streams
Set to 4 for 4 space-time streams
Values 5-7 are reserved
For a VHT SU PPDU:
B10-B12
Set to 0 for 1 space-time stream
Set to 1 for 2 space-time streams
Set to 2 for 3 space-time streams
Set to 3 for 4 space-time streams
Set to 4 for 5 space-time streams
Set to 5 for 6 space-time streams
Set to 6 for 7 space-time streams
Set to 7 for 8 space-time streams
B13-B21
Partial AID: Set to the value of the TXVECTOR
parameter PARTIAL_AID. Partial AID provides an
abbreviated indication of the intended recipient(s) of the
PSDU (see 10.20).
B22 TXOP_PS_ 1 Set to 0 by VHT AP if it allows non-AP VHT STAs in
NOT_ALLO TXOP power save mode to enter doze state during a TXOP.
WED Set to 1 otherwise.
The bit is reserved and set to 1 in VHT PPDUs transmitted
by a non-AP VHT STA.
B23 Reserved 1 Set to 1
2544
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-12—Fields in the VHT-SIG-A field (continued)
Two parts of Number
Bit Field Description
VHT-SIG-A of bits
B0 Short GI 1 Set to 0 if short guard interval is not used in the Data field.
Set to 1 if short guard interval is used in the Data field.
B1 Short GI 1 Set to 1 if short guard interval is used and NSYM mod 10 = 9;
NSYM otherwise, set to 0. NSYM is defined in 21.4.3.
Disambiguati
on
B2 SU/MU[0] 1 For a VHT SU PPDU, B2 is set to 0 for BCC, 1 for LDPC
Coding For a VHT MU PPDU, if the MU[0] NSTS field is nonzero,
then B2 indicates the coding used for user u with
USER_POSITION[u] = 0; set to 0 for BCC and 1 for LDPC.
If the MU[0] NSTS field is 0, then this field is reserved and
set to 1.
B3 LDPC Extra 1 Set to 1 if the LDPC PPDU encoding process (if an SU
OFDM PPDU), or at least one LDPC user’s PPDU encoding process
Symbol (if a VHT MU PPDU), results in an extra OFDM symbol (or
symbols) as described in 21.3.10.5.4 and 21.3.10.5.5. Set to
0 otherwise.
B4-B7 SU VHT- 4 For a VHT SU PPDU:
MCS/MU[1- VHT-MCS index
3] Coding For a VHT MU PPDU:
If the MU[1] NSTS field is nonzero, then B4 indicates
VHT-SIG-A2
coding for user u with USER_POSITION[u] = 1: set to 0
for BCC, 1 for LDPC. If the MU[1] NSTS field is 0, then
B4 is reserved and set to 1.
If the MU[2] NSTS field is nonzero, then B5 indicates
coding for user u with USER_POSITION[u] = 2: set to 0
for BCC, 1 for LDPC. If the MU[2] NSTS field is 0, then
B5 is reserved and set to 1.
If the MU[3] NSTS field is nonzero, then B6 indicates
coding for user u with USER_POSITION[u] = 3: set to 0
for BCC, 1 for LDPC. If the MU[3] NSTS field is 0, then
B6 is reserved and set to 1.
B7 is reserved and set to 1
B8 Beamformed 1 For a VHT SU PPDU:
Set to 1 if a beamforming steering matrix is applied to the
waveform in an SU transmission, set to 0 otherwise.
For a VHT MU PPDU:
Reserved and set to 1
NOTE—If equal to 1 smoothing is not recommended.
B9 Reserved 1 Reserved and set to 1
B10-B17 CRC 8 CRC calculated as in 19.3.9.4.4 with c7 in B10. Bits 0-23 of
HT-SIG1 and bits 0-9 of HT-SIG2 are replaced by bits 0-23
of VHT-SIG-A1 and bits 0-9 of VHT-SIG-A2, respectively.
B18-B23 Tail 6 Used to terminate the trellis of the convolutional decoder.
Set to 0.
2545
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The time domain waveform for the VHT-SIG-A field in a VHT PPDU shall be as specified in
Equation (21-28).
1
i Seg i TX 1
r VHT-SIG-A(t) = --------------------------------------- w TSYML(t – nT SYML) (21-28)
Tone
N VHT-SIG-A N TX n=0
26
N 20MHz – 1
k – K Shift i BW BW j n Dk n BW + pn + 1 Pk
k = – 26
i BW = 0 i TX
exp j2 k – K Shift i BW F t – nT SYML – T GI – T CS
where
N 20MHz and K Shift(i) are defined in 21.3.8.2.4
0 k = 0 7 21
Dk n 20 =
d Mr k n otherwise
20
r ( k)
M 20 is defined in Equation (21-27)
P k and p n are defined in 17.3.5.10
Tone
N VHT-SIG-A has the value given in Table 21-8
k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17)
i
TX
T CS represents the cyclic shift for transmitter chain i TX with a value given in Table 21-10
NOTE—This definition results in a QBPSK modulation on the second symbol of VHT-SIG-A where the constellation of
the data tones is rotated by 90º counter-clockwise relative to the first symbol of VHT-SIG-A and relative to the non-HT
signal field in VHT PPDUs (Figure 21-20). In VHT PPDUs, the VHT-SIG-A is transmitted with the same number of
subcarriers and the same cyclic shifts as the preceding non-HT portion of the preamble.
For an 80+80 MHz transmission, each frequency segment shall use the time domain waveform for 80 MHz
transmissions.
Q Q Q
L-SIG VHT-SIG-A1 VHT-SIG-A2
+1 +1 +1 1
0 1 I
0 1 I I
-1 +1 -1 +1 -1 +1
-1 -1 -1 0
Figure 21-20—Data tone constellation in the VHT PPDU pre-VHT modulated fields
2546
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.8.3.4 VHT-STF definition
The main purpose of the VHT-STF field is to improve automatic gain control estimation in a MIMO
transmission. The duration of the VHT-STF field is TVHT-STF regardless of the Short GI field setting in
VHT-SIG-A. The frequency domain sequence used to construct the VHT-STF field in a 20 MHz
transmission is identical to the HT-STF field. In a 40 MHz and an 80 MHz transmission, the VHT-STF field
is constructed from the 20 MHz version by frequency shifting a duplicate of it to each 20 MHz subchannel
and applying appropriate phase rotations per 20 MHz subchannel.
For a 20 MHz transmission, the frequency domain sequence is given by Equation (21-29).
VHTS –28 28 = HTS –28 28 (21-29)
where
HTS –28 28 is defined in Equation (19-19)
For a 40 MHz transmission, the frequency domain sequence is given by Equation (21-30).
VHTS –58 58 = HTS –58 58 (21-30)
where
HTS –58 58 is defined in Equation (19-20)
For an 80 MHz transmission, the frequency domain sequence is given by Equation (21-31).
VHTS –122 122 = VHTS –58 58 0 0 0 0 0 0 0 0 0 0 0 VHTS –58 58 (21-31)
where
VHTS –58 58 is given by Equation (21-30)
For a 160 MHz transmission, the frequency domain sequence is given by Equation (21-32).
VHTS –250 250 = VHTS –122 122 0 0 0 0 0 0 0 0 0 0 0 VHTS –122 122 (21-32)
where
VHTS –122 122 is given by Equation (21-31)
NOTE—Equation (21-29), Equation (21-30), Equation (21-31), and Equation (21-32) do not show the phase rotation per
20 MHz subchannel.
For an 80+80 MHz transmission, each 80 MHz frequency segment shall use the VHT-STF pattern for the
80 MHz ( VHTS –122 122 ) defined in Equation (21-31).
The time domain representation of the signal on frequency segment i Seg and transmit chain i TX shall be as
specified in Equation (21-33).
2547
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
i Seg i TX 1
r VHT-STF(t) = ------------------------------------------------ w TVHT-STF(t) (21-33)
Tone
N VHT-STF N STS total
N SR N user – 1 N STS u
Q kiSeg i TX M u + m k BW VHTS k
k = – N SR u=0 m=1 exp j2 k F t – T CS,VHT(M u + m)
where
Tone
N VHT-STF has the value given in Table 21-8
T CS,VHT(n) is given in Table 21-11
Q kiSeg is defined in 21.3.10.11.1
k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17)
21.3.8.3.5 VHT-LTF definition
The VHT Long Training field (VHT-LTF) field provides a means for the receiver to estimate the MIMO
channel between the set of constellation mapper outputs (or, if STBC is applied, the STBC encoder outputs)
and the receive chains. The transmitter provides training for NSTS,total space-time streams (spatial mapper
inputs) used for the transmission of the PSDU(s). For each tone, the MIMO channel that can be estimated is
an NRX NSTS,total matrix. A VHT transmission has a preamble that contains VHT-LTF symbols, where the
data tones of each VHT-LTF symbol are multiplied by entries belonging to a matrix PVHT-LTF, to enable
channel estimation at the receiver. The pilot tones of each VHT-LTF symbol are multiplied by the entries of
a matrix RVHT-LTF defined in the following text. The multiplication of the pilot tones in the VHT-LTF
symbol by the RVHT-LTF matrix instead of the PVHT-LTF matrix allows receivers to track phase and frequency
offset during MIMO channel estimation using the VHT-LTF. The number of VHT-LTF symbols, NVHT-LTF,
is a function of the total number of space-time streams NSTS,total as shown in Table 21-13. As a result the
VHT-LTF field consists of one, two, four, six or eight symbols.
Table 21-13—Number of VHT-LTFs required for different numbers
of space-time streams
NSTS,total NVHTLTF
1 1
2 2
3 4
4 4
5 6
6 6
7 8
8 8
2548
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Let LTF left and LTF right be the sequences defined in Equation (21-34) and Equation (21-35), respectively.
LTF left = 1 1 –1 –1 1 1 –1 1 – 1 1 1 1 1 1 1 – 1 – 1 1 1 –1 1 –1 1 1 1 1 (21-34)
LTF right = 1 –1 –1 1 1 –1 1 –1 1 –1 –1 –1 –1 –1 1 1 –1 –1 1 –1 1 –1 1 1 1 1 (21-35)
NOTE— LTF left is identical to the leftmost 26 elements of Equation (17-8), and LTF right is identical to the rightmost
26 elements of Equation (17-8).
In a 20 MHz transmission, the VHT-LTF sequence transmitted is given by Equation (21-36).
VHT-LTF –28 28 = 1 1 LTF left 0 LTF right – 1 – 1 (21-36)
= HT-LTF –28 28
where
HT-LTF –28 28 is defined in Equation (19-23)
In a 40 MHz transmission, the VHT-LTF sequence transmitted is given by Equation (21-37).
VHT-LTF –58 58 = LTF left 1 LTF right – 1 – 1 – 1 1 0 0 0 – 1 1 1 – 1 LTF left 1 LTF right (21-37)
= HT-LTF –58 58
where
HT-LTF –58 58 is defined in Equation (19-24)
In an 80 MHz transmission, the VHT-LTF sequence transmitted is given by Equation (21-38).
VHT-LTF –122 122 = LTF left 1 LTF right – 1 – 1 – 1 1 1 – 1 1 – 1 1 1 – 1 LTF left 1 LTF right (21-38)
1 –1 1 –1 0 0 0 1 –1 –1 1
LTF left 1 LTF right – 1 – 1 – 1 1 1 – 1 1 – 1 1 1 – 1 LTF left 1 LTF right
In a 160 MHz transmission, the VHT-LTF sequence transmitted is given by Equation (21-39).
VHT-LTF –250 250 = VHT-LTF –122 122 0 0 0 0 0 0 0 0 0 0 0 VHT-LTF –122 122 (21-39)
where
VHT-LTF –122 122 is given in Equation (21-38)
NOTE—Equation (21-36), Equation (21-37), Equation (21-38), and Equation (21-39) do not show the phase rotation per
20 MHz subchannel.
For a 80+80 MHz transmission, each 80 MHz frequency segment shall use the 80 MHz VHT-LTF
sequence, VHT-LTF –122 122 , defined in Equation (21-38).
2549
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The generation of the time domain VHT-LTF symbols per frequency segment is shown in Figure 21-21
k
where A VHT - LTF is given in Equation (21-40).
k
AVHT-LTF 1,n
VHT-LTFk x
IDFT
...
...
CSD Qk
...
1:N STS,total
IDFT
x
k
AVHT-LTF N
STS,total ,n
Figure 21-21—Generation of VHT-LTF symbols per frequency segment
R VHT - LTF if k K Pilot
k
A VHT (21-40)
- LTF =
P VHT - LTF otherwise
where
K Pilot is the set of subcarrier indices for the pilot tones.
For a 20 MHz transmission, K Pilot = 7 21 .
For a 40 MHz transmission, K Pilot = 11 25 53 .
For an 80 MHz transmission, K Pilot = 11 39 75 103 .
For a 160 MHz transmission, K Pilot = 25 53 89 117 139 167 203 231 .
For an 80+80 MHz transmission, K Pilot for each 80 MHz frequency segment is identical to
K Pilot for an 80 MHz transmission.
R VHT - LTF is a N VHT - LTF N VHT - LTF matrix whose elements are defined in Equation (21-41).
R VHT - LTF = P VHT - LTF 1 m n N VHT - LTF (21-41)
m n 1 n
P VHT - LTF is defined in Equation (21-42)
The time domain representation of the waveform transmitted on frequency segment iSeg of transmit chain
iTX shall be as described by Equation (21-42).
2550
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
N VHT-LTF – 1
i Seg i TX 1
r VHT-LTF(t) = ------------------------------------------------ w TVHT-LTF(t – nT VHT-LTF) (21-42)
Tone
N VHT-LTF N STS total n=0
N SR N user – 1 N STS u
Q kiSeg k BW
k
A VHT - LTF
VHT-LTF k
i TX M u + m Mu + m n+1
k = – N SR u=0 m=1 exp j2 k F t – nT VHT-LTF – T GI – T CS,VHT(M u + m)
where
Tone
N VHT-LTF has the value given in Table 21-8
T CS,VHT(n) is given in Table 21-11
Q kiSeg is defined in 21.3.10.11.1
k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17)
k
A VHT - LTF is defined in Equation (21-40)
P4 4 N STS total 4
P VHT - LTF = P6 6 N STS total = 5 6 (21-43)
P8 8 N STS total = 7 8
where
P4 4 is defined in Equation (19-27)
The VHT-LTF mapping matrix for six VHT-LTF symbols, P 6 6, is defined in Equation (21-44).
1 –1 1 1 1 –1
1 2
1 –w w w3 w4 –w5
P6 = 1 –w 2 w4 w6 w8 – w 10 (21-44)
6
1 –w 3 w6 w9 w 12 – w 15
1 –w 4 w8 w 12 w 16 – w 20
1 –w 5 w 10 w 15 w 20 – w 25
where
w = exp – j2 6
The VHT-LTF mapping matrix for eight VHT-LTF symbols, P 8 8 , is defined in Equation (21-45).
P4 4 P4 4
P8 8 = (21-45)
P4 4 –P4 4
where
P4 4 is defined in Equation (19-27)
2551
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
As defined in Table 21-5, the duration of each VHT-LTF symbol is T VHT-LTF regardless of the Short GI
field setting in VHT-SIG-A.
21.3.8.3.6 VHT-SIG-B definition
The VHT-SIG-B field is one symbol and contains 26 bits in a 20 MHz PPDU, 27 bits in a 40 MHz PPDU,
and 29 bits in 80 MHz, 160 MHz, and 80+80 MHz PPDUs for each user. The fields in the VHT-SIG-B field
are listed in Table 21-14. For fields consisting of multiple bits, the LSB of the value occupies the lowest
numbered bit of the field. For example, for an MU transmission using VHT-MCS 5 (0101 in binary) in
20 MHz bandwidth, the VHT-SIG-B field bits are set as follows: B16=1, B17=0, B18=1, and B19=0.
Table 21-14—Fields in the VHT-SIG-B field
VHT MU PPDU Allocation (bits) VHT SU PPDU Allocation (bits)
Field 80 MHz, 80 MHz, Description
20 MHz 40 MHz 160 MHz, 20 MHz 40 MHz 160 MHz,
80+80 MHz 80+80 MHz
VHT-SIG-B B0-B15 B0-B16 B0-B18 B0-B16 B0-B18 B0-B20 Length of A-
Length (16) (17) (19) (17) (19) (21) MPDU pre-EOF
padding in units
of four octets
VHT-MCS B16-B19 B17-B20 B19-B22 N/A N/A N/A
(4) (4) (4)
Reserved N/A N/A N/A B17-B19 B19-B20 B21-B22 All 1s
(3) (2) (2)
Tail B20-B25 B21-B26 B23-B28 B20-B25 B21-B26 B23-B28 All 0s
(6) (6) (6) (6) (6) (6)
Total # bits 26 27 29 26 27 29
NOTE—Due to the limitations in the maximum A-MPDU length, B19-20 are always 0 for an 80 MHz, 160 MHz, and
80+80 MHz VHT SU PPDU.
The VHT-SIG-B Length field for user u shall be set using Equation (21-46).
APEP_LENGTH
VHT-SIG-B Length (for user u in units of 4 octets) = -------------------------------------------u- (21-46)
4
where
APEP_LENGTHu is the TXVECTOR parameter APEP_LENGTH for user u (in octets)
The VHT-SIG-B bits for an NDP transmission in various channel widths shall be set as defined in
Table 21-15.
2552
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-15—VHT-SIG-B bits (before Tail field) in NDP for various channel widths
Channel B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 B16 B17 B18 B19 B20 B21 B22
Width
20 MHz 0 0 0 0 0 1 1 1 0 1 0 0 0 1 0 0 0 0 1 0 – – –
40 MHz 1 0 1 0 0 1 0 1 1 0 1 0 0 0 1 0 0 0 0 1 1 - –
80 MHz,
160 MHz,
or 80+80 0 1 0 1 0 0 1 1 0 0 1 0 1 1 1 1 1 1 1 0 0 1 0
MHz
For a 40 MHz transmission, the VHT-SIG-B bits are repeated twice. For an 80 MHz transmission, the VHT-
SIG-B bits are repeated four times and a pad bit appended that is set to 0. For a 160 MHz and 80+80 MHz
transmission, the VHT-SIG-B bits are first repeated four times and a pad bit appended that is set to 0 as in
the 80 MHz transmission. Then, the resulting 117 bits are repeated again to fill the 234 available bits. The
repetition of the VHT-SIG-B bits for various channel width PPDUs is shown in Figure 21-22.
6 tail
20 MHz 20 bits
bits
6 tail 6 tail
40 MHz 21 bits 21 bits
bits bits
Repeated
6 tail 6 tail 6 tail 6 tail 1 Pad
80 MHz 23 bits 23 bits 23 bits 23 bits
bits bits bits bits bit
Repeated
160 MHz 6 tail 6 tail 6 tail 6 tail 1 Pad 6 tail 6 tail 6 tail 6 tail 1 Pad
23 bits 23 bits 23 bits 23 bits 23 bits 23 bits 23 bits 23 bits
80+80 MHz bits bits bits bits bit bits bits bits bits bit
Repeated
Repeated
Figure 21-22—VHT-SIG-B bits in 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz
transmissions
For each user u, the VHT-SIG-B field shall be BCC encoded at rate R = 1/2 as defined in 17.3.5.6, be
segment parsed as defined in 21.3.10.7, be interleaved as defined in 21.3.10.8, be mapped to a BPSK
constellation as defined in 17.3.5.8, be segment deparsed as defined in 21.3.10.9.3, and have pilots inserted
following the steps described in 21.3.10.10. The VHT-SIG-B field constellation points are mapped to NSTS,u
space-time streams by the user-specific elements of the first column of the PVHT-LTF matrix, which is
defined in clause 21.3.8.3.5. The total number of data subcarriers and pilot subcarriers are the same as in the
Data field. The space-time streams per each frequency segment are input into the CSD block, which is
defined in Table 21-11 and follow the same transmission flow as the Data field from there on. The duration
of the VHT-SIG-B field is TVHT-SIG-B, regardless of the value of the TXVECTOR parameter GI_TYPE. The
time domain waveform for the VHT-SIG-B field in a VHT PPDU is specified by Equation (21-47).
2553
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
i Seg i TX 1
r VHT-SIG-B(t) = ---------------------------------------------------- w TVHT-SIG-B(t) (21-47)
Tone
N VHT-SIG-B N STS total
N SR N user – 1 N STS u i u k
Q kiSeg k BW P VHT - LTF Mu + m 1
D k Seg
BW + p 3 P 0
i TX M u + m
k = – N SR u=0 m=1 exp j2 k F t – T GI – T CS,VHT(M u + m)
where
Tone
N VHT-SIG-B has the value given in Table 21-8
T CS,VHT(n) is given in Table 21-11
Q kiSeg is defined in 21.3.10.11.1
pn is defined in 17.3.5.10
P nk is defined in 21.3.10.10
k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17)
P VHT - LTF is given in Equation (21-43)
i Seg u
Let d k be the stream of complex numbers generated for VHT-SIG-B for user u at subcarrier k (logical
index, starting with 0) on frequency segment iSeg (prior to multiplication by PVHT-LTF). For a 20 MHz VHT
transmission,
i Seg u 0 k=0 7 21
Dk 20 = i Seg u (21-48)
d Mr k
otherwise
20
k + 28 – 28 k – 22
k + 27 – 20 k – 8
r
M 20 k = k + 26 –6 k –1 (21-49)
k + 25 1 k 6
k + 24 8 k 20
k + 23 22 k 28
For a 40 MHz VHT transmission,
i Seg u 0 k=0 1 11 25 53
Dk 40 = i Seg u (21-50)
d Mr k
otherwise
40
2554
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
k + 58 – 58 k – 54
k + 57 – 52 k – 26
k + 56 – 24 k – 12
r k + 55 – 10 k – 2
M 40 k = (21-51)
k + 52 2 k 10
k + 51 12 k 24
k + 50 26 k 52
k + 49 54 k 58
For an 80 MHz VHT transmission,
i Seg u 0 k=0 1 11 39 75 103
Dk 80 = i Seg u (21-52)
d Mr k
otherwise
80
k + 122 – 122 k – 104
k + 121 – 102 k – 76
k + 120 – 74 k – 40
k + 119 – 38 k – 12
r k + 118 – 10 k – 2
M 80 k = (21-53)
k + 115 2 k 10
k + 114 12 k 38
k + 113 40 k 74
k + 112 76 k 102
k + 111 104 k 122
For a 160 MHz VHT transmission,
i Seg u 0 k=0 1 2 3 4 5 25 53 89 117 127 128 129 139 167 203 231
Dk 160 = i Seg u
d Mr otherwise
160 k (21-54)
2555
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
k + 250 – 250 k – 232
k + 249 – 230 k – 204
k + 248 – 202 k – 168
k + 247 – 166 k – 140
k + 246 – 138 k – 130
k + 243 – 126 k – 118
k + 242 – 116 k – 90
k + 241 – 88 k – 54
k + 240 – 52 k – 26
r k + 239 – 24 k –6
M 160 k = (21-55)
k + 228 6 k 24
k + 227 26 k 52
k + 226 54 k 88
k + 225 90 k 116
k + 224 118 k 126
k + 221 130 k 138
k + 220 140 k 166
k + 219 168 k 202
k + 218 204 k 230
k + 217 232 k 250
For an 80+80 MHz VHT transmission, each frequency segment shall follow the 80 MHz VHT transmission
format as specified in Equation (21-52) and Equation (21-53).
21.3.9 Transmission of NON_HT and HT PPDUs with multiple transmit chains
21.3.9.1 Transmission of 20 MHz NON_HT PPDUs with more than one transmit chain
A VHT STA that transmits a NON_HT PPDU shall apply the cyclic shifts defined in Table 21-10 to the
preamble and Data field.
21.3.9.2 Transmission of HT PPDUs with more than four transmit chains
A VHT STA that transmits an HT PPDU with FORMAT equal to HT_MF shall apply the cyclic shifts
defined in Table 21-10 for the non-HT portion of the PPDU, including the HT-SIG field.
21.3.10 Data field
21.3.10.1 General
The number of OFDM symbols in the Data field is determined by the Length field in L-SIG (see
Equation (21-24)), the preamble duration and the setting of the Short GI field in VHT-SIG-A (see
21.3.8.3.3).
When BCC encoding is used, the Data field shall consist of the SERVICE field, the PSDU, the PHY pad
bits, and the tail bits ( N tail N ES bits for SU and N tail N ES u bits for each user u in MU). When LDPC
encoding is used, the Data field shall consist of the SERVICE field, the PSDU, and the PHY pad bits. No tail
bits are present when LDPC encoding is used.
2556
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The padding flow is as follows. The MAC delivers a PSDU that fills the available octets in the Data field of
the PPDU for each user u. The PHY determines the number of pad bits to add and appends them to the
PSDU. The number of pad bits added will always be 0 to 7 per user. When user u of a VHT MU PPDU uses
BCC encoding, the number of pad bits is calculated using Equation (21-56). In the case of SU ignore u in
Equation (21-56).
N PAD u = N SYM N DBPS u – 8 PSDU_LENGTH u – N service – N tail N ES u (21-56)
where
PSDU_LENGTH u is defined in 21.4.3
N SYM is the number of symbols in the Data field and is given by Equation (21-111) for a
VHT SU PPDU and by Equation (21-67) for a VHT MU PPDU
For an SU PPDU, if LDPC encoding is used then the PHY padding bits are calculated using Equation (21-
57).
N PAD = N SYM init N DBPS – 8 PSDU_LENGTH – N service (21-57)
where
PSDU_LENGTH is defined in 21.4.3
N SYM init is given by Equation (21-62)
For a VHT MU PPDU, if LDPC encoding is used for user u then the PHY padding bits are calculated using
Equation (21-58).
N PAD u = N SYM_max_init N DBPS u – 8 PSDU_LENGTH u – N service (21-58)
where
PSDU_LENGTH u is defined in 21.4.3
N SYM_max_init is given by Equation (21-65)
The Data field of the VHT PPDU contains data for one or more users. For a VHT MU PPDU, the data
processing, from scrambling to constellation mapping shall happen on a per-user basis. In the following
subclauses, this process is described from a single user’s point of view.
21.3.10.2 SERVICE field
The SERVICE field is as shown in Table 21-16.
Table 21-16—SERVICE field
Bits Field Description
B0-B6 Scrambler Initialization Set to 0
B7 Reserved Set to 0
B8-B15 CRC CRC calculated over VHT-SIG-B (excluding tail bits)
2557
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.10.3 CRC calculation for VHT-SIG-B
The CRC calculation and insertion is illustrated in Figure 21-23.
VHT-SIG-B SERVICE field
20 bits (20 MHz), 21 bits (40 MHz), Tail Scrambler Init Reserved CRC
23 bits (80 MHz, 160 MHz and 80+80 MHz) (6 bits) (7 bits) (1 bit) (8 bits)
Figure 21-23—VHT-SIG-B and SERVICE field relationship
The value of the CRC field shall be the 1s complement of Equation (21-59).
crc(D) = M(D) I(D) D 8 modG D (21-59)
where
M D = m0 DN – 1 + m1 DN – 2 + + mN – 2 D + mN – 1
N is the number of bits over which the CRC is generated; 20 for 20 MHz, 21 for 40 MHz, and 23
for 80 MHz/160 MHz/80+80 MHz
mi is bit i of VHT-SIG-B
N–1
I D = D i are initialized values that are added modulo 2 to the first 8 bits of VHT-SIG-B
i = N–8
G D = D 8 + D 2 + D + 1 is the CRC generating polynomial
crc D = c 0 D 7 + c 1 D 6 + + c6 D + c7
Figure 19-8 shows the operation of the CRC. First, the shift register is reset to all 1s. The bits are then passed
through the XOR operation at the input. When the last bit has entered, the output is generated by shifting the
bits out of the shift register, c7 first, through an inverter.
As an example, if bits {m0, … m22} are given by {1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1}, the CRC bits
{c7, … c0} are {0 0 0 1 1 1 0 0}.
The CRC field is transmitted with c7 first. Hence, c7 is mapped to B8 of the SERVICE field, c6 is mapped to
B9, …, and c0 is mapped to B15 of the SERVICE field.
21.3.10.4 Scrambler
The SERVICE, PSDU, and PHY pad parts of the Data field shall be scrambled by the scrambler defined in
17.3.5.5. The Clause 17 TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and
DYN_BANDWIDTH_IN_NON_HT are not present; therefore, the initial state of the scrambler is set to a
pseudorandom nonzero seed. Different users in a VHT MU PPDU may use different pseudorandom nonzero
seeds.
2558
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.10.5 Coding
21.3.10.5.1 General
The Data field shall be encoded using either the binary convolutional code (BCC) defined in 21.3.10.5.2 and
21.3.10.5.3 or the low density parity check (LDPC) code defined in 21.3.10.5.4. The encoder is selected by
the SU/MU[0] Coding, MU[1] Coding, MU[2] Coding, or MU[3] Coding fields in VHT-SIG-A, as defined
in 21.3.8.3.3. When BCC FEC encoding is used, the number of encoders is determined by rate-dependent
parameters as defined in 21.5. The operation of the BCC FEC is described in 21.3.10.5.2 and 21.3.10.5.3.
The operation of the LDPC coder is described in 21.3.10.5.4. Support for the reception of a BCC encoded
Data field is mandatory.
21.3.10.5.2 BCC encoder parsing operation
If multiple encoders are used, the scrambled SERVICE, PSDU, and PHY pad bits are divided between the
encoders by sending bits to different encoders in a round robin manner. Bit i to encoder j of user u, denoted
x i ju , is as specified in Equation (21-60).
N DBPS u
b NES u + j u ; 0 i N SYM ------------------
- – N tail 0 j N ES u – 1
N ES u
xi j
u = (21-60)
N DBPS u N DBPS u
0 ; N SYM ------------------
- – N tail i N SYM ------------------
- 0 j N ES u – 1
N ES u N ES u
where
bk,u is bit k of the scrambled SERVICE, PSDU, and pad bits of user u
NSYM is the number of symbols in the Data field and is given by Equation (21-111) for a VHT SU
PPDU and by Equation (21-67) for a VHT MU PPDU
NOTE—Tail bits with value 0 are being appended to each BCC encoder parser output sequence in Equation (21-60).
21.3.10.5.3 Binary convolutional coding and puncturing
The BCC encoder parser output sequences of user u x i ju 0 i N SYM N DBPS u N ES u 0 j N ES u – 1
each of which is separately encoded by a rate R = ½ convolutional encoder defined in 17.3.5.6. After
encoding, the encoded data is punctured by the method defined in 17.3.5.6 (except for rate 5/6), to achieve
the rate selected by the modulation and coding scheme. In the case that rate 5/6 coding is selected, the
puncturing scheme will be the same as described in 19.3.11.6.
21.3.10.5.4 LDPC coding
For a VHT SU PPDU using LDPC coding to encode the Data field, the LDPC code and encoding process
described in 19.3.11.7 shall be used with the following modifications. First, all bits in the Data field
including the scrambled SERVICE, PSDU, and pad bits are encoded. Thus, N pld for VHT PPDUs shall be
computed using Equation (21-61) instead of Equation (19-35).
N pld = N SYM init N DBPS (21-61)
where
N SYM init is given by Equation (21-62)
2559
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
8 APEP_LENGTH + N service
N SYM init = m STBC -------------------------------------------------------------------------- (21-62)
m STBC N DBPS
where
m STBC is equal to 2 when STBC is used, and 1 otherwise
APEP_LENGTH is the TXVECTOR parameter APEP_LENGTH
Following the calculation of N pld , N avbits shall be computed using Equation (21-63) instead of
Equation (19-36).
N avbits = N SYM init N CBPS (21-63)
In addition, if N SYM computed in Equation (19-41) in step d) of 19.3.11.7.5 is greater than N SYM init , then
the LDPC Extra OFDM Symbol field of VHT-SIG-A shall be set to 1. Otherwise, the LDPC Extra OFDM
Symbol field of VHT-SIG-A shall be set to 0.
LDPC codes used in VHT MU PPDUs shall also follow the definitions in 19.3.11.7. Refer to 21.3.10.5.5 for
a description of the LDPC encoding process for VHT MU PPDUs.
21.3.10.5.5 Encoding process for VHT MU PPDUs
For a VHT MU PPDU, first compute the initial number of OFDM symbols for each user using
Equation (21-64).
8 APEP_LENGTH u + N service + N tail N ES u
--------------------------------------------------------------------------------------------------------------- when user u uses BCC
N DBPS u
N SYM_init u = (21-64)
8 APEP_LENGTH u + N service
---------------------------------------------------------------------------- when user u uses LDPC
N DBPS u
where
APEP_LENGTH u is the TXVECTOR parameter APEP_LENGTH for user u
Based on the above equation, compute the largest initial number of symbols over all users using
Equation (21-65).
N user – 1
N SYM_max_init = max N SYM_init u u=0 (21-65)
Then, for each user u that uses LDPC in the VHT MU PPDU, the final number of symbols in the Data field
(NSYM,u) shall be computed as follows. First, perform step a) in 19.3.11.7.5 with the exception that Npld is
computed using Equation (21-66) instead of Equation (19-35).
N pld = N SYM_max_init N DBPS u (21-66)
Then, perform steps b) through d) in 19.3.11.7.5 with NCBPS and R replaced with NCBPS,u and Ru,
respectively. NSYM,u for user u shall then be equal to the value of NSYM obtained at the end of step d) using
Equation (19-41).
2560
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The purpose of going through steps a) to d) in 19.3.11.7.5 in the above paragraph is to compute NSYM,u.
Thus, at this stage NSYM,u for each user may be calculated without actually encoding the data using LDPC.
For BCC users, N SYM u = N SYM_init u .
Then, compute the number of symbols in the Data field using Equation (21-67).
N user – 1
N SYM = max N SYM u u=0 (21-67)
When constructing the Data field for user u encoded using LDPC code, the MAC follows the padding
procedure described in 10.13.6 and delivers a PSDU that contains PSDU_LENGTHu octets (see 21.4.3).
The PHY follows the padding procedure described in 21.3.10.1 to fill N SYM_max_init symbols, where
N SYM_max_init is defined in Equation (21-65). Then, for each user, all bits in the Data field including the
scrambled SERVICE, PSDU, and pad bits shall be encoded using the LDPC encoding process specified in
19.3.11.7.5 with the following modifications. First, N pld shall be computed using Equation (21-66) instead
of Equation (19-35). Also, replace NCBPS and R with NCBPS,u and Ru, respectively. Next, step d) in
19.3.11.7.5 is replaced with step d) below:
d) If NSYM computed in Equation (21-67) is equal to N SYM_max_init , then the number of bits to be
punctured, N punc , from the codewords after encoding is computed as shown in Equation (19-38).
If NSYM computed in Equation (21-67) is greater than N SYM_max_init , then the number of bits to be
punctured, N punc , from the codewords after encoding is computed using Equation (19-39) and
Equation (20-40). Note also that Navbits has now been updated in Equation (19-39) in this case.
The punctured bits shall be equally distributed over all NCW codewords with the first
rem(N punc N CW) codewords punctured 1 bit more than the remaining codewords. Define
N ppcw = N punc N CW . When N ppcw 0 , the puncturing is performed by discarding parity bits
p n – k – Nppcw – 1 p n – k – 1 of the first rem(N punc N CW) codewords and discarding parity bits
p n – k – N ppcw p n – k – 1 of the remaining codewords after encoding.
When constructing the Data field for users encoded using BCC, the MAC follows the padding procedure
described in 10.13.6 and delivers a PSDU that contains PSDU_LENGTHu octets. The PHY follows the
padding procedure described in 21.3.10.1 to fill up NSYM symbols computed in Equation (21-67). Then, for
each user, all bits in the Data field including the scrambled SERVICE, PSDU, and pad bits shall be encoded
using the BCC encoding process specified in 21.3.10.5.2 and 21.3.10.5.3. Note that this process results in
the BCC tail bits being placed at the very end of the PPDU.
In addition, if NSYM computed in Equation (21-67) is greater than N SYM_max_init computed in
Equation (21-65), then the LDPC Extra OFDM Symbol field of VHT-SIG-A2 shall be set to 1. Otherwise,
the LDPC Extra OFDM Symbol field of VHT-SIG-A2 shall be set to 0.
21.3.10.6 Stream parser
After coding and puncturing, the data bit streams at the output of the FEC encoders are processed in groups
of NCBPS bits. Each of these groups is rearranged into NSS blocks of NCBPSS bits (NSS,u blocks of NCBPSS,u
bits in the case of an MU transmission). This operation is referred to as stream parsing and is described in
this subclause.
The description is given in terms of an SU transmission. For MU transmissions, the rearrangements are
carried out in the same way per user.
2561
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The number of bits assigned to a single axis (real or imaginary) of a constellation point in a spatial stream is
denoted by Equation (21-68).
N BPSCS
s = max 1 ----------------
- (21-68)
2
The sum of these over all streams is S = N SS s
Consecutive blocks of s bits are assigned to different spatial streams in a round robin fashion.
Let
N CBPS
N Block = ---------------
- (21-69)
N ES S
and
N CBPS – N Block N ES S
M = -------------------------------------------------------
- (21-70)
s N ES
For the first N Block N ES S bits of each OFDM symbol, S bits from the output of first encoder are divided
among all spatial streams, s bits per stream. Then, S bits from the output of next encoder are used, and so on.
If N CBPS is greater than N Block N ES S , then for the last N CBPS – N Block N ES S bits of each OFDM
symbol, M s bits from the output of the first encoder are fed into spatial streams 1 through M (s bits per
spatial stream), and then M s bits from the output of the next encoder are used for spatial stream M + 1
through 2M – 1 mod N SS + 1 , and so on, where z mod t is the remainder resulting from the division of
integer z by integer t.
The following equations are an equivalent description to the above procedure. Bit i at the output of encoder j
is assigned to input bit k of spatial stream i SS where
k-- mod N k = 0 1 N Block N ES s – 1
ES
s
j = (21-71)
L k = N Block N ES s N CBPSS – 1
-----
M
and
i SS – 1 s + S k - + k mod s
--------------- k = 0 1 N Block N ES s – 1
i = N ES s (21-72)
L mod M s + N Block S + k mod s k = N Block N ES s N CBPSS – 1
where
i SS = 1 2 N SS
i = 0 1 N CBPS N ES – 1
j = 0 1 N ES – 1
k = 0 1 N CBPSS – 1
2562
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
L = k' N + i – 1
--- SS SS
s
k' = k – N Block N ES s
NOTE—NCBPS is greater than N Block N ES S in only the following cases:
— 160 MHz and 80+80 MHz, NSS = 5, VHT-MCS = 5
— 160 MHz and 80+80 MHz, NSS = 5, VHT-MCS = 6
— 160 MHz and 80+80 MHz, NSS = 7, VHT-MCS = 5
— 160 MHz and 80+80 MHz, NSS = 7, VHT-MCS = 6
21.3.10.7 Segment parser
The description in this subclause is given in terms of an SU transmission. For MU transmissions, the
rearrangements are carried out in the same way per user.
For a 160 MHz or an 80+80 MHz transmission, the output bits of each stream parser are first divided into
blocks of NCBPSS bits (NCBPSS,u bits in the case of an MU transmission). Then, each block is further divided
into two frequency subblocks of N CBPSS 2 bits as shown in Equation (21-73).
N CBPSS
yk l = x k - + l s N + k mod(s N ) k = 0 1 ----------------- – 1 (21-73)
2 s N ES ---------------
s N ES
ES ES 2
where
xm is the m th bit of a block of N CBPSS bits, m= 0 to N CBPSS – 1
l is the frequency subblock index, l = 0 1
yk l is bit k of the frequency subblock l
s is defined in Equation (21-68)
If NCBPSS is not divisible by 2s N ES , then apply the segment parsing method described in Equation (21-73)
for N CBPSS sets of 2s N ES segment parser input bits. At this point, each stream parser
2s N ES
N CBPSS mod(2s N ES)
output has 2s N res ( N res = ----------------------------------------------------
- N ES integer ) residue bits. Then, the residue bits are
2s
divided into subsets of s bits, with each subset being assigned to different subblock ( l = 0 1 ) in a round
robin fashion. The first s bits are assigned to the subblock with index l = 0 . Repeat Nres times (until all
bits are distributed to the two subblocks). That is, if N CBPSS is not divisible by 2s N ES , each block is
further divided into two subblocks of N CBPSS 2 bits as shown in Equation (21-74).
x k - + l s N + k mod(s N ) k = 0 1 N CBPSS 2s N ES s N ES – 1 (21-74)
2 s N ES --------------- ES ES
s N ES
yk l = N CBPSS
x k - + 2s k mod(s N ES) k = N CBPSS 2s N ES s N ES ----------------
-–1
2 s N ES --------------- - + l s + k mod s
---------------------------------- 2
s N ES s
2563
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Segment parser is bypassed for a 20 MHz, 40 MHz, or 80 MHz VHT PPDU transmission, i.e., as specified
in Equation (21-75).
yk l = xk k = 0 1 N CBPSS – 1 (21-75)
where
l is the frequency subblock index. l = 0 for a 20, 40 or 80 MHz VHT PPDU transmission.
yk l is bit k of the frequency subblock l
xm is bit m of a block of N CBPSS bits, m = 0 to N CBPSS – 1
21.3.10.8 BCC interleaver
For ease of explanation, the operation of the interleaver is described for the SU case. For user u of an MU
transmission, the interleaver operates in the same way on the output bits for the user from the stream parser
by replacing NSS, NCBPSS, NCBPSSI, and NBPSCS with NSS,u, NCBPSS,u, NCBPSSI,u, and NBPSCS,u, respectively.
That is, the operation of the interleaver is the same as if the transmission were an SU one, consisting of bits
from only that user.
This subclause describes the interleaver used in the case of BCC encoding. The interleaver described in this
subclause shall be bypassed in the case of LDPC encoding.
In a 20 MHz, 40 MHz, or 80 MHz VHT PPDU transmission, the bits at the output of the stream parser are
processed in groups of NCBPS bits. Each of these groups is divided into NSS blocks of NCBPSS bits, and each
block shall be interleaved by an interleaver based on the Clause 17 interleaver. In a 160 MHz or an
80+80 MHz VHT PPDU transmission, each frequency subblock of NCBPSS/2 output bits from the segment
parser is interleaved by the interleaver for 80 MHz defined in this subclause. This interleaver, which is based
on entering the data in rows, and reading it out in columns, has a different number of columns N COL and
rows N ROW for different bandwidths. The values of N COL and N ROW are given in Table 21-17.
Table 21-17—Number of rows and columns in the interleaver
Parameter 20 MHz 40 MHz 80 MHz
N COL 13 18 26
N ROW 4 N BPSCS 6 N BPSCS 9 N BPSCS
N ROT (NSS ≤ 4) 11 29 58
N ROT (NSS > 4) 6 13 28
After the operations based on the Clause 17 interleaver have been applied and if more than one spatial
stream exists, a third operation called frequency rotation is applied to the additional spatial streams. The
parameter for the frequency rotation is NROT. The values of NROT are given in Table 21-17.
An additional parameter is the spatial stream index i SS = 1 2 N SS . The output of the third operation is
a function of the spatial stream index.
2564
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The interleaving is defined using three permutations. The first permutation is given by the rule shown in
Equation (21-76).
k
i = N ROW k mod N COL + ------------ k = 0 1 N CBPSSI – 1 (21-76)
-
N COL
The second permutation is defined by the rule shown in Equation (21-77).
N COL i
j = s -i + i + N CBPSSI – ------------------
- mod s i = 0 1 N CBPSSI – 1 (21-77)
s N CBPSSI
where
s is defined in Equation (21-68)
If 2 N SS 4 , a frequency rotation is applied to the output of the second permutation as shown in
Equation (21-78).
i SS – 1
r = j– 2 i SS – 1 mod 3 + 3 --------------
- N ROT N BPSCS mod N CBPSSI (21-78)
3
j = 0 1 N CBPSSI – 1
where
i SS = 1 2 N SS is the spatial steam index on which this interleaver is operating
If N SS 4 , a frequency rotation is applied to the output of the second permutation as shown in Equation (21-
79).
r = j – J(i SS) N ROT N BPSCS mod N CBPSSI j = 0 1 N CBPSSI – 1 (21-79)
where
i SS = 1 2 N SS is the spatial steam index on which this interleaver is operating, and J iSS is an
integer as defined in Table 21-18.
Table 21-18— J(iSS) values
i SS J i SS
1 0
2 5
3 2
4 7
5 3
6 6
7 1
8 4
2565
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The deinterleaver uses the following three operations to perform the inverse permutations. Let r denote the
index of the bit in the received block (per spatial stream). The first operation reverses the third (frequency
rotation) permutation of the interleaver. When N SS = 1 , this reversal is performed by j = r
(r = 0 1 N CBPSSI – 1 ). When 2 N SS 4 , this reversal is performed by as shown in Equation (21-80).
i SS – 1
j = r+ 2 i SS – 1 mod 3 + 3 --------------
- N ROT N BPSCS mod N CBPSSI (21-80)
3
r = 0 1 N CBPSSI – 1
When N SS 4 , this reversal is performed by Equation (21-81).
j = r + J(i SS) N ROT N BPSCS mod N CBPSSI r = 0 1 N CBPSSI – 1 (21-81)
where
J(i SS) is defined in Table 21-18
The second operation defined by Equation (21-82) reverses the second permutation in the interleaver.
N COL j
i = s -j + j + ------------------
- mod s j = 0 1 N CBPSSI – 1 (21-82)
s N CBPSSI
where
s is defined in Equation (21-68)
The third operation defined in Equation (21-83) reverses the first permutation of the interleaver.
k = N COL i – N CBPSSI – 1 i
------------- i = 0 1 N CBPSSI – 1 (21-83)
N ROW
21.3.10.9 Constellation mapping
21.3.10.9.1 General
The mapping between bits at the output of the interleaver and complex constellation points for BPSK,
QPSK, 16-QAM, and 64-QAM follows the rules defined in 17.3.5.8. For 256-QAM, the mapping is shown
in Figure 21-24, Figure 21-25, Figure 21-26, and Figure 21-27.
The bit string convention in Figure 21-24, Figure 21-25, Figure 21-26, and Figure 21-27 follows the bit
string convention outlined in 17.3.5.8.
The streams of complex numbers in frequency subblock l for user u are denoted
2566
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 21-24—Constellation bit encoding for 256-QAM (1st quadrant)
2567
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 21-25—Constellation bit encoding for 256-QAM (2nd quadrant)
2568
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 21-26—Constellation bit encoding for 256-QAM (3rd quadrant)
2569
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure 21-27—Constellation bit encoding for 256-QAM (4th quadrant)
2570
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
d' k i n l u; k=0 1 N SD – 1 for 20 MHz, 40 MHz, 80 MHz, and 80+80 MHz; (21-84)
·
N SD ·
k = 0 1 --------- – 1 for 160 MHz;
2
i = 1 N SS u ;
n = 0 1 N SYM – 1 ;
l = 0 for 20 MHz, 40 MHz, and 80 MHz;
l = 0 1 for 160 MHz and 80+80 MHz;
u = 0 N user – 1
The normalization factor, KMOD, for 256-QAM is 1 170 .
21.3.10.9.2 LDPC tone mapping
The LDPC tone mapping shall be performed on all LDPC encoded streams as described in this subclause
and using an LDPC tone-mapping distance parameter D TM . D TM is constant for each bandwidth and its
value for different bandwidths is given in Table 21-19. LDPC tone mapping shall not be performed on
streams that are encoded using BCC.
Table 21-19—LDPC tone mapping distance for each bandwidth
160 MHz,
Parameter 20 MHz 40 MHz 80 MHz
80+80 MHz
D TM 4 6 9 9
For a VHT PPDU transmission, the LDPC tone mapping for LDPC-coded streams corresponding to user u is
done by permuting the stream of complex numbers generated by the constellation mappers (see
Equation (21-84)) to obtain
d'' t(k) i n l u = d' k i n l u; k=0 1 N SD – 1 for 20 MHz, 40 MHz, 80 MHz and 80+80 MHz; (21-85)
·
N SD ·
k = 0 1 --------- – 1 for 160 MHz;
2
i = 1 N SS u ;
n = 0 1 N SYM – 1 ;
l = 0 for 20 MHz, 40 MHz, and 80 MHz;
l = 0 1 for 160 MHz and 80+80 MHz;
u = 0 N user – 1
2571
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
N SD k D TM
D TM k mod ---------
- + ----------------- for 20 MHz, 40 MHz, 80 MHz, and 80+80 MHz
D TM N SD
t(k) = (21-86)
N SD 2 k D TM
D TM k mod ---------------
- + ----------------- for 160 MHz
D TM N SD 2
As a result of the LDPC tone mapping operation above, each two consecutively generated complex
constellation numbers d' k i n l u and d' k + 1 i n l u will be transmitted on two data tones that are separated by
at least D TM – 1 other data tones. Note that the operation above is equivalent to block-interleaving the
complex numbers d' 0 i n l u for each i, n, and u using a matrix with D TM rows and
d' NSD – 1 i n l u
N SD
N SD D TM (for 20 MHz, 40 MHz, 80 MHz, or 80+80 MHz) or ----------------- - (for 160 MHz) columns, where
2 D TM
d' 0 i n l u d' NSD – 1 i n l u are written row-wise into the matrix, and d'' 0 i n l u d'' NSD – 1 i n l u are read
column-wise from the matrix.
NOTE—LDPC tone mapping is performed separately for the upper and lower 80 MHz segments of a 160 MHz of
80+80 MHz transmission as indicated by the frequency subblock index l in Equation (21-85) and Equation (21-86).
Since LDPC tone mapping is not performed on BCC-coded streams, for BCC-coded streams, the following
applies:
d'' k i n l u = d' k i n l u; k=0 1 N SD – 1 for 20 MHz, 40 MHz, 80 MHz and 80+80 MHz; (21-87)
·
N SD ·
k = 0 1 --------- – 1 for 160 MHz;
2
i = 1 N SS u ;
n = 0 1 N SYM – 1 ;
l = 0 for 20 MHz, 40 MHz, and 80 MHz;
l = 0 1 for 160 MHz and 80+80 MHz;
u = 0 N user – 1
21.3.10.9.3 Segment deparser
In a 160 MHz VHT PPDU transmission, the two frequency subblocks at the output of the LDPC tone
mapper for LDPC or constellation mapper for BCC are combined into one frequency segment as shown in
Equation (21-88).
N SD
d'' k i n 0 u if 0 k --------- – 1
2
d kiSeg
i n u = i Seg = 0 (21-88)
N SD
d'' k – NSD 2 i n 1 u if --------
- k N SD – 1
2
2572
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In a 20 MHz, 40 MHz, or 80 MHz VHT PPDU transmission, the segment deparsing is not performed.
Hence,
d kiSeg
i n u = d'' k i n 0 u 0 k N SD – 1 i Seg = 0 (21-89)
In an 80+80 MHz VHT PPDU transmission, the segment deparsing is not performed. Hence,
d kiSeg
i n u = d '' k i n i Seg u 0 k N SD – 1 i Seg = 0 1 (21-90)
NOTE—As per Table 21-7, f c 0 (center frequency for frequency segment iSeg=0) is always less than f c 1 in case of
80+80 MHz VHT PPDU transmissions. Hence, d '' k i n 0 u (frequency subblock 0) is always transmitted in the frequency
segment lower in frequency, while d '' k i n 1 u (frequency subblock 1) is always transmitted in the frequency segment
higher in frequency.
21.3.10.9.4 Space-time block coding
This subclause defines a set of optional robust transmission techniques that are applicable only when using
STBC coding for VHT SU PPDUs. In this case, NSS,0 spatial streams are mapped to NSTS,0 space-time
streams. These techniques are based on STBC. When the VHT-SIG-A STBC field is 1, a symbol operation
shall occur between the constellation mapper and the spatial mapper as defined in this subclause. STBC
shall not be applied in a VHT MU PPDU. Hence, the user subscript u is 0 in this subclause.
If STBC is applied, the stream of complex numbers,
i
d k Seg
i n 0; k = 0 N SD – 1 ; i = 1 N SS 0 ; n = 0 N SYM – 1 , generated by the segment
deparser, is the input to the STBC encoder, which produces as output the stream of complex numbers
i
d̃ k Seg
i STS n 0; k = 0 N SD – 1 ; i STS = 1 N STS 0 ; n = 0 N SYM – 1 . For given values of k and i,
STBC processing operates on the complex modulation symbols in sequential pairs of OFDM symbols so
i Seg i Seg i Seg i Seg i Seg
that the value of d̃ k 2i – 1 2m 0 and d̃ k
2 i 2 m 0 depend on d k i 2m 0 and d k i 2m + 1 0 . Also, d̃ k 2i – 1 2m + 1 0
i Seg i Seg i Seg
and d̃ k 2i 2m + 1 0 depend on d k i 2 m 0 and d k i 2 m + 1 0 . This is defined in Table 21-20. Note that the segment
index i Seg is omitted in Table 21-20 for simplicity.
Table 21-20—Constellation mapper output to spatial mapper input for STBC
N STS N SS i STS d̃ k i STS 2m 0 d̃ k i STS 2m + 1 0
2 1 1 dk dk
1 2m 0 1 2m + 1 0
2 – d k* 1 d k* 1
2m + 1 0 2m 0
4 2 1 dk dk
1 2m 0 1 2m + 1 0
2 – d k* 1 d k* 1
2m + 1 0 2m 0
3 dk dk
2 2m 0 2 2m + 1 0
4 – d k* 2 d k* 2
2m + 1 0 2m 0
2573
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-20—Constellation mapper output to spatial mapper input for STBC (continued)
N STS N SS i STS d̃ k i STS 2m 0 d̃ k i STS 2m + 1 0
6 3 1 dk dk
1 2m 0 1 2m + 1 0
2 – d k* 1 d k* 1
2m + 1 0 2m 0
3 dk dk
2 2m 0 2 2m + 1 0
4 – d k* 2 d k* 2
2m + 1 0 2m 0
5 dk dk
3 2m 0 3 2m + 1 0
6 – d k* 3 d k* 3
2m + 1 0 2m 0
8 4 1 dk dk
1 2m 0 1 2m + 1 0
2 – d k* 1 d k* 1
2m + 1 0 2m 0
3 dk dk
2 2m 0 2 2m + 1 0
4 – d k* 2 d k* 2
2m + 1 0 2m 0
5 dk dk
3 2m 0 3 2m + 1 0
6 – d k* 3 d k* 3
2m + 1 0 2m 0
7 dk dk
4 2m 0 4 2m + 1 0
8 – d k* 4 d k* 4
2m + 1 0 2m 0
i i
If STBC is not applied, d̃ k Seg
i n 0 = d k Seg
i n 0 and N STS 0 = N SS 0 .
NOTE—When STBC is applied, an odd number of space-time streams is not allowed, and N STS 0 = 2N SS 0 .
21.3.10.10 Pilot subcarriers
In a 20 MHz transmission, four pilot tones shall be inserted in subcarriers k – 21 – 7 7 21 . The pilot
mapping P nk for subcarrier k for symbol n shall be as specified in Equation (21-91).
P n –21 – 7 7 21 = 1
1 n mod 4
1
1 n + 1 mod 4
1
1 n + 2 mod 4
1
1 n + 3 mod 4
(21-91)
P nk – 21 – 7 7 21 = 0
where
1 is given by the N STS = 1 row of Table 19-19
1 m
In a 40 MHz transmission, six pilot tones shall be inserted in subcarriers –53, –25, –11, 11, 25, and 53. The
pilot mapping P nk for subcarrier k for symbol n shall be as specified in Equation (21-92).
2574
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
P n –53 – 25 – 11 11 25 53 = 1
1 n mod 6
1
1 n + 1 mod 6
1
1 n + 5 mod 6
(21-92)
P nk – 53 – 25 – 11 11 25 53 = 0
where
1 is given by the NSTS = 1 row of Table 19-20
1 m
In an 80 MHz transmission, eight pilot tones shall be inserted in subcarriers –103, –75, –39, –11, 11, 39, 75,
and 103. The pilot mapping P nk for subcarrier k for symbol n shall be as specified in Equation (21-93).
P n –103 – 75 – 39 – 11 11 39 75 103 = n mod 8 n + 1 mod 8 n + 7 mod 8
(21-93)
P nk – 103 – 75 – 39 – 11 11 39 75 103 = 0
where
m is defined in Table 21-21
Table 21-21—Pilot values for 80 MHz transmission
0 1 2 3 4 5 6 7
1 1 1 –1 –1 1 1 1
In a 160 MHz transmission, the 80 MHz pilot mapping is replicated in the two 80 MHz subchannels
of the 160 MHz transmission. Specifically, 16 pilot tones shall be inserted in subcarriers –231, –203, –167,
–139, –117, –89, –53, –25, 25, 53, 89, 117, 139, 167, 203, and 231. The pilot mapping P nk for subcarrier k
for symbol n shall be as specified in Equation (21-94).
P n –231 – 203 – 167 – 139 – 117 – 89 – 53 – 25 25 53 89 117 139 167 203 231
(21-94)
= n mod 8 n + 1 mod 8 n + 2 mod 8 n + 3 mod 8 n + 4 mod 8 n + 5 mod 8 n + 6 mod 8 n + 7 mod 8
n mod 8 n + 1 mod 8 n + 2 mod 8 n + 3 mod 8 n + 4 mod 8 n + 5 mod 8 n + 6 mod 8 n + 7 mod 8
P nk – 231 – 203 – 167 – 139 – 117 – 89 – 53 – 25 25 53 89 117 139 167 203 231 = 0
where
m is given in Table 21-21
In an 80+80 MHz transmission, each frequency segment shall follow the 80 MHz pilot tone allocation and
values defined for 80 MHz transmission as specified in Equation (21-93) and Table 21-21.
The above pilot mapping shall be copied to all space-time streams before the space-time stream cyclic shifts
are applied.
21.3.10.11 OFDM modulation
21.3.10.11.1 Transmission in VHT format
The time domain waveform of the Data field of a VHT PPDU from frequency segment i Seg and transmit
chain iTX, 1 iTX NTX shall be as defined in Equation (21-95).
2575
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
N SYM – 1
i Seg i TX 1
r VHT-Data(t) = ------------------------------------------------- w TSYM(t – nT SYM) (21-95)
Tone
N VHT-Data N STS total n=0
N SR N user – 1 N STS u i u
Q kiSeg k BW D̃ k Seg
m n BW + p n + 4 P nk
i TX M u + m
k = – N SR u=0 m=1 exp j2 k F t – nT SYM – T GI Data – T CS,VHT(M u + m)
where
pn is defined in 17.3.5.10
P nk is defined in 21.3.10.10
k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17)
i u
D̃ k Seg
m n BW is the transmitted constellation for user u at subcarrier k, space-time stream m, and Data field
OFDM symbol n and is defined in Equation (21-96) through Equation (21-99)
Tone
N VHT-Data has the value given in Table 21-8
T CS,VHT(n) is given in Table 21-11
T GI Data is the guard interval duration. T GI Data = T GI when not using the short guard interval (Short
GI field of VHT-SIG-A2 is 0) and T GI Data = T GIS when using the short guard interval (Short
GI field of VHT-SIG-A2 is 1). T GI and T GIS are given in Table 21-5.
In a 20 MHz VHT transmission,
i u 0 k=0 7 21
D̃ k Seg
m n 20 = i (21-96)
d̃ MSeg
r otherwise
20 k m n u
where
r (k) is defined in Equation (21-49)
M 20
In a 40 MHz VHT transmission,
i u 0 k=0 1 11 25 53
D̃ k Seg
m n 40 = i (21-97)
d̃ MSeg
r otherwise
40 k m n u
where
r (k) is defined in Equation (21-51)
M 40
2576
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In an 80 MHz transmission,
i u 0 k=0 1 11 39 75 103
D̃ k Seg
m n 80 = i (21-98)
d̃ MSeg
r otherwise
80 k m n u
where
r (k) is defined in Equation (21-53)
M 80
In a 160 MHz transmission,
i u 0 k=0 1 2 3 4 5 25 53 89 117 127 128 129 139 167 203 231
D̃ k Seg
m n 160 = i
d̃ MSeg
r otherwise
160 k m n u (21-99)
where
r (k) is defined in Equation (21-55)
M 160
In an 80+80 MHz transmission, each frequency segment shall follow the 80 MHz VHT subcarrier mapping
as specified in Equation (21-98) and Equation (21-53).
Q kiSeg is a spatial mapping/steering matrix with NTX rows and NSTS,total columns for subcarrier k in
frequency segment i Seg . Q kiSeg may be frequency dependent. Refer to the examples of Q k listed in
19.3.11.11.2 for examples of Q kiSeg that could be used for VHT SU PPDUs. Note that implementations are
not restricted to the spatial mapping matrix examples listed in 19.3.11.11.2 and the number of transmit
chains NTX could be greater than 4. For VHT SU PPDUs to which beamforming is applied, Q kiSeg is a
beamforming steering matrix and is derived from the TXVECTOR parameter EXPANSION_MAT. For
VHT MU PPDUs, Q kiSeg is the DL-MU-MIMO steering matrix and is derived from the TXVECTOR
parameter EXPANSION_MAT. The beamforming steering matrices and DL-MU-MIMO steering matrices
are implementation specific.
21.3.10.12 Non-HT duplicate transmission
When the TXVECTOR parameter FORMAT is NON_HT and the TXVECTOR parameter
NON_HT_MODULATION is NON_HT_DUP_OFDM, the transmitted PPDU is a non-HT duplicate. Non-
HT duplicate transmission is used to transmit to non-HT OFDM STAs, HT STAs, or VHT STAs that may be
present in a part of a 40 MHz, 80 MHz, or 160 MHz channel (see Table 21-2). The VHT-SIG-A, VHT-STF,
VHT-LTF, and VHT-SIG-B fields are not transmitted. The L-STF, L-LTF, and L-SIG fields shall be
transmitted in the same way as in the VHT transmission, with the exceptions for the Rate and Length fields
which shall follow 17.3.4.
In a 40 MHz non-HT duplicate transmission, the Data field shall be as defined by Equation (19-61).
For 80 MHz and 160 MHz non-HT duplicate transmissions, the Data field shall be as defined by
Equation (21-100).
2577
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
N SYM – 1
i TX 1
r non-HT BW (t) = ----------------------------------------------------------- w TSYM(t – nT SYM) (21-100)
Tone
N NON_HT_DUP_OFDM-Data
n=0
26
N 20MHz – 1
k – K Shift(i BW) BW Dk n + pn + 1 Pk
k = – 26
i BW = 0 i
exp(j2 k – K Shift(i BW) F t – nT SYM – T GI – T CS
TX
)
where
N 20MHz and K Shift(i) are defined in 21.3.8.2.4
Pk and pn are defined in 17.3.5.10
Dk,n is defined in Equation (21-26)
k BW is defined in Equation (21-16) and Equation (21-17)
i
T CS
TX
represents the cyclic shift for transmitter chain i TX with a value given in Table 21-10
Tone
N NON_HT_DUP_OFDM-Data has the value given in Table 21-8
In an 80+80 MHz non-HT duplicate transmission, data transmission in each frequency segment shall be as
defined for an 80 MHz non-HT duplicate transmission in Equation (21-100).
21.3.11 SU-MIMO and DL-MU-MIMO Beamforming
21.3.11.1 General
SU-MIMO and DL-MU-MIMO beamforming are techniques used by a STA with multiple antennas (the
beamformer) to steer signals using knowledge of the channel to improve throughput. With SU-MIMO
beamforming all space-time streams in the transmitted signal are intended for reception at a single STA.
With DL-MU-MIMO beamforming, disjoint subsets of the space-time streams are intended for reception at
different STAs.
For SU-MIMO beamforming, the steering matrix Qk can be determined from the beamforming feedback
matrix Vk that is sent back to the beamformer by the beamformee using the compressed beamforming
feedback matrix format as defined in 19.3.12.3.6. The feedback report format is described in 9.4.1.49.
For DL-MU-MIMO beamforming, the receive signal vector in subcarrier k at beamformee u,
T T T T T
yk u = yk 0 yk 1 yk N RX – 1 , is shown in Equation (21-101), where x k = x k 0 xk 1 xk N user – 1
u
denotes the transmit signal vector in subcarrier k for all Nuser beamformees, with
T
xk u = xk 0 xk 1 xk N STS u – 1 being the transmit signal for beamformee u.
yk u = Hk u Qk 0 Qk 1 Qk N user – 1 xk + n (21-101)
where
Hk,u is the channel matrix from the beamformer to beamformee u in subcarrier k with dimensions
N RXu N TX
2578
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
N RXu is the number of receive antennas at beamformee u
Qk u is a steering matrix for beamformee u in subcarrier k with dimensions N TX N STSu
Nuser is the number of VHT MU PPDU recipients (see Table 21-6)
n is a vector of additive noise and may include interference
The DL-MU-MIMO steering matrix Q k = Q k 0 Qk 1 Qk N user – 1 can be determined by the
beamformer using the beamforming feedback matrices for subcarrier k from beamformee u, Vk,u, and SNR
information for subcarrier k from beamformee u, SNRk,u, where u = 0 1 N user – 1 . The steering matrix
that is computed (or updated) using new beamforming feedback matrices and new SNR information from
some or all of participating beamformees might replace the existing steering matrix Q k for the next DL-
MU-MIMO data transmission. The beamformee group for the MU transmission is signaled using the Group
ID field in VHT-SIG-A (see 21.3.8.3.3 and 21.3.11.4).
21.3.11.2 Beamforming Feedback Matrix V
Upon receipt of a VHT NDP sounding PPDU, the beamformee shall remove the space-time stream CSD in
Table 21-11 from the measured channel before computing a set of matrices for feedback to the beamformer.
The beamforming feedback matrix, Vk,u, found by the beamformee u for subcarrier k shall be compressed in
the form of angles using the method described in 19.3.12.3.6. The angles, k,u and k,u , are quantized
according to Table 9-68. The number of bits for quantization is chosen by the beamformee, based on the
indication from the beamformer as to whether the feedback is requested for SU-MIMO beamforming or DL-
MU-MIMO beamforming. The compressed beamforming feedback using 19.3.12.3.6 is the only Clause 21
beamforming feedback format defined.
The beamformee shall generate the beamforming feedback matrices with the number of rows (Nr) equal to
the NSTS of the NDP.
After receiving the angle information, k,u and k,u , the beamformer reconstructs Vk,u using
Equation (19-79). For SU-MIMO beamforming, the beamformer can use this Vk,0 matrix to determine the
steering matrix Qk. For DL-MU-MIMO beamforming, the beamformer may calculate a steering matrix
Qk = Qk 0 Qk 1 Qk N user – 1 using Vk,u and SNRk,u ( 0 u N user – 1 ) in order to suppress crosstalk
between participating beamformees. The method used by the beamformer to calculate the steering matrix Qk
is implementation specific.
The beamformee decides the tone grouping value to be used in the beamforming feedback matrix V. A
beamformer shall support all tone grouping values and Codebook Information values.
21.3.11.3 Maximum Number of Total Spatial Streams in VHT MU PPDUs
An MU beamformee capable STA shall support reception of VHT MU PPDUs with the total number of
space-time streams across the N_user users being less than or equal to the value indicated in the Maximum
NSTS,total subfield of the Supported VHT-MCS and NSS Set field of the VHT Capabilities element.
21.3.11.4 Group ID
A value in the Group ID field in VHT-SIG-A (see 21.3.8.3.3) in the range 1 to 62 indicates a VHT MU
PPDU. Prior to transmitting a VHT MU PPDU, group assignments have been established by the AP for DL-
MU-MIMO capable STAs using the Group ID Management frame as defined in 9.6.23.3.
2579
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
After the PHY is configured using the PHYCONFIG_VECTOR parameter GROUP_ID_MANAGEMENT,
the following lookup tables are populated:
a) Group ID to Membership Status, denoted by MembershipStatusInGroupID[g] for 1 g 62
b) Group ID to User Position, denoted by UserPositionInGroupID[g] for 1 g 62
When a STA receives a VHT MU PPDU where the Group ID field in VHT-SIG-A has the value k and where
MembershipStatusInGroupID[k] is equal to 1, then the number of space-time streams for that STA is
indicated in the MU[UserPositionInGroupID[k]] NSTS field in VHT-SIG-A. The space-time streams of
different users are ordered in accordance to user position values, i.e., the space-time streams for the user in
user position 0 come first, followed by the space-time streams for the user in position 1, followed by the
space-time streams for the user in position 2, and followed by the space-time streams for the user in
position 3.
A STA is also able to identify the space-time streams intended for other STAs that act as interference. VHT-
LTF symbols in the VHT MU PPDU are used to measure the channel for the space-time streams intended
for the STA and can also be used to measure the channel for the interfering space-time streams. To
successfully demodulate the space-time streams intended for the STA, the STA may use the channel state
information for all space-time streams to reduce the effect of interfering space-time streams.
If a STA finds that it is not a member of the group, or the STA is a member of the group but the
corresponding MU NSTS field in VHT-SIG-A indicates that there are zero space-time streams for the STA
in the PPDU, then the STA may elect to not process the remainder of the PPDU.
21.3.12 VHT preamble format for sounding PPDUs
NDP is the only VHT sounding format.
The format of a VHT NDP PPDU is shown in Figure 21-28.
8 μs 8 μs 4 μs 8 μs 4 μs 4 μs per VHT-LTF symbol 4 μs
L- VHT- VHT-
L-STF L-LTF VHT-SIG-A VHT-LTF
SIG STF SIG-B
Figure 21-28—VHT NDP format
NOTE—The number of VHT-LTF symbols in the NDP is determined by the SU NSTS field in VHT-SIG-A.
The VHT NDP PPDU has the following properties:
— Uses the VHT PPDU format but without the Data field.
— Is a VHT SU PPDU as indicated by the VHT-SIG-A field.
— Has the data bits of the VHT-SIG-B field set to a fixed bit pattern (see 21.3.8.3.6).
21.3.13 Regulatory requirements
Wireless LANs (WLANs) implemented in accordance with this standard are subject to equipment
certification and operating requirements established by regional and national regulatory administrations. The
PHY specification establishes minimum technical requirements for interoperability, based upon established
regulations at the time this standard was issued. These regulations are subject to revision or may be
superseded. Requirements that are subject to local geographic regulations are annotated within the PHY
specification. Regulatory requirements that do not affect interoperability are not addressed in this standard.
Implementers are referred to the regulatory sources in Annex D for further information. Operation in
2580
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
countries within defined regulatory domains might be subject to additional or alternative national
regulations.
21.3.14 Channelization
A VHT channel is specified by the four PLME MIB fields specified in Table 21-22.
Table 21-22—Fields to specify VHT channels
Field Meaning
dot11CurrentChannelWidth Channel width. Possible values represent 20 MHz, 40 MHz,
80 MHz, 160 MHz, and 80+80 MHz channels.
dot11CurrentChannelCenterFrequencyIndex0 For a 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel, denotes
the channel center frequency.
For an 80+80 MHz channel, denotes the center frequency of the
frequency segment 0, which is the frequency segment containing
the primary channel.
Valid range is 1 to 200.
See Equation (21-102).
dot11CurrentChannelCenterFrequencyIndex1 For an 80+80 MHz channel, denotes the center frequency of the
frequency segment 1, which is the frequency segment that does
not contain the primary channel.
Valid range is 1 to 200.
See Equation (21-102).
For a 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel, set to 0.
dot11CurrentPrimaryChannel Denotes the location of the primary 20 MHz channel.
Valid range is 1 to 200.
See Equation (21-103).
Given dot11CurrentChannelCenterFrequencyIndex0 and dot11CurrentChannelCenterFrequencyIndex1, the
respective center frequency is given by Equation (21-102).
Channel center frequency [MHz] (21-102)
= Channel starting frequency + 5 dot11CurrentChannelCenterFrequencyIndex
where
Channel starting frequency is given by the operating class (Annex E)
dot11CurrentChannelCenterFrequencyIndex is either dot11CurrentChannelCenterFrequencyIndex0 or
dot11CurrentChannelCenterFrequencyIndex1
The center frequency of the primary 20 MHz channel is given by Equation (21-103).
Primary 20 MHz channel center frequency [MHz] (21-103)
= Channel starting frequency + 5 dot11CurrentPrimaryChannel
The channel starting frequency is defined as dot11ChannelStartingFactor × 500 kHz. If a channel center
frequency is 5.000 GHz, it shall be indicated by dot11ChannelStartingFactor = 8000 and
dot11CurrentPrimaryChannel = 200.
For an 80+80 MHz channel, any two channels that would each be allowed as 80 MHz channels and whose
center frequencies are separated by greater than 80 MHz (difference between
dot11CurrentChannelCenterFrequencyIndex0 and dot11CurrentChannelCenterFrequencyIndex1
corresponds to a frequency difference greater than 80 MHz) may be used.
2581
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For example, a channel specified by
channel starting frequency = 5000 MHz
dot11CurrentChannelWidth = 80 MHz
dot11CurrentChannelCenterFrequencyIndex0 = 42
dot11CurrentPrimaryChannel = 36
is an 80 MHz channel with a center frequency of 5210 MHz and the primary 20 MHz channel centered at
5180 MHz.
A channel specified by
channel starting frequency = 5000 MHz
dot11CurrentChannelWidth = 160 MHz
dot11CurrentChannelCenterFrequencyIndex0 = 50
dot11CurrentPrimaryChannel = 56
is a 160 MHz channel with a center frequency of 5250 MHz and the primary 20 MHz channel centered at
5280 MHz.
A channel specified by
channel starting frequency = 5000 MHz
dot11CurrentChannelWidth = 80+80 MHz
dot11CurrentChannelCenterFrequencyIndex0 =155
dot11CurrentChannelCenterFrequencyIndex1 = 106
dot11CurrentPrimaryChannel = 161
is an 80+80 MHz channel in which frequency segment 0 has 80 MHz bandwidth and center frequency of
5775 MHz. Frequency segment 1 also has 80 MHz bandwidth and center frequency of 5530 MHz. The
primary 20 MHz channel is centered at 5805 MHz.
21.3.15 Slot time
The slot time for the VHT PHY shall be 9 s for 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz
channel spacing.
21.3.16 Transmit and receive port impedance
Transmit and receive antenna connector impedance for each transmit and receive antenna is defined in
17.3.8.7.
21.3.17 VHT transmit specification
21.3.17.1 Transmit spectrum mask
NOTE 1—In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements
and the mask defined in this subclause.
NOTE 2—Transmit spectral mask figures in this subclause are not drawn to scale.
NOTE 3—For rules regarding TX center frequency leakage levels, see 21.3.17.4.2. The spectral mask requirements in
this subclause do not apply to the RF LO.
For a 20 MHz mask PPDU of non-HT, HT or VHT format, the interim transmit spectral mask shall have a
0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of 18 MHz, –20 dBr at 11 MHz
frequency offset, –28 dBr at 20 MHz frequency offset, and –40 dBr at 30 MHz frequency offset and above.
The interim transmit spectral mask for frequency offsets in between 9 and 11 MHz, 11 and 20 MHz, and
20 and 30 MHz shall be linearly interpolated in dB domain from the requirements for 9 MHz, 11 MHz,
20 MHz, and 30 MHz frequency offsets. The transmit spectrum shall not exceed the maximum of the
2582
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
interim transmit spectral mask and –53 dBm/MHz at any frequency offset. Figure 21-29 shows an example
of the resulting overall spectral mask when the –40 dBr spectrum level is above –53 dBm/MHz.
PSD
0 dBr
-20 dBr
-28 dBr
-40 dBr
Freq [MHz]
-30 -20 -11 -9 9 11 20 30
Figure 21-29—Example transmit spectral mask for 20 MHz mask PPDU
For a 40 MHz mask PPDU of non-HT, non-HT duplicate, HT or VHT format, the interim transmit spectral
mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of 38 MHz,
–20 dBr at 21 MHz frequency offset, –28 dBr at 40 MHz frequency offset, and –40 dBr at 60 MHz
frequency offset and above. The interim transmit spectral mask for frequency offsets in between 19 and
21 MHz, 21 and 40 MHz, and 40 and 60 MHz shall be linearly interpolated in dB domain from the
requirements for 19 MHz, 21 MHz, 40 MHz, and 60 MHz frequency offsets. The transmit spectrum shall
not exceed the maximum of the interim transmit spectral mask and –56 dBm/MHz at any frequency
offset greater than 19 MHz. Figure 21-30 shows an example of the resulting overall spectral mask when the
–40 dBr spectrum level is above –56 dBm/MHz.
PSD
0 dBr
-20 dBr
-28 dBr
-40 dBr
Freq [MHz]
-60 -40 -21 -19 19 21 40 60
Figure 21-30—Example transmit spectral mask for 40 MHz mask PPDU
For an 80 MHz mask PPDU of non-HT, non-HT duplicate, HT or VHT format, the interim transmit
spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of
78 MHz, –20 dBr at 41 MHz frequency offset, –28 dBr at 80 MHz frequency offset, and –40 dBr at
2583
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
120 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between
39 and 41 MHz, 41 and 80 MHz, and 80 and 120 MHz shall be linearly interpolated in dB domain from the
requirements for 39 MHz, 41 MHz, 80 MHz, and 120 MHz frequency offsets. The transmit spectrum shall
not exceed the maximum of the interim transmit spectrum mask and –59 dBm/MHz at any frequency offset.
Figure 21-31 shows an example of the resulting overall spectral mask when the –40 dBr spectrum level is
above –59 dBm/MHz.
PSD
0 dBr
-20 dBr
-28 dBr
-40 dBr
Freq [MHz]
-120 -80 -41 -39 39 41 80 120
Figure 21-31—Example transmit spectral mask for 80 MHz mask PPDU
For a 160 MHz mask PPDU of non-HT, non-HT duplicate, HT or VHT format, the interim transmit spectral
mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of 158 MHz,
–20 dBr at 81 MHz frequency offset, –28 dBr at 160 MHz frequency offset, and –40 dBr at 240 MHz
frequency offset and above. The interim transmit spectral mask for frequency offsets in between 79 and
81 MHz, 81 and 160 MHz, and 160 and 240 MHz shall be linearly interpolated in dB domain from the
requirements for 79 MHz, 81 MHz, 160 MHz, and 240 MHz frequency offsets. The transmit spectrum shall
not exceed the maximum of the interim transmit spectrum mask and –59 dBm/MHz at any frequency offset.
Figure 21-32 shows an example of the resulting overall spectral mask when the –40 dBr spectrum level is
above –59 dBm/MHz.
PSD
0 dBr
-20 dBr
-28 dBr
-40 dBr
Freq [MHz]
-240 -160 -81 -79 79 81 160 240
Figure 21-32—Example transmit spectral mask for 160 MHz mask PPDU
2584
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For an 80+80 MHz mask PPDU of non-HT duplicate or VHT format, the overall transmit spectral mask is
constructed in the following manner. First, the 80 MHz interim spectral mask is placed on each of the two
80 MHz segments. Then, for each frequency at which both of the 80 MHz interim spectral masks have
values greater than –40 dBr and less than –20 dBr, the sum of the two interim mask values (summed in linear
domain) shall be taken as the overall spectral mask value. Next, for each frequency at which neither of the
two 80 MHz interim masks have values greater than or equal to –20 dBr and less than or equal to 0 dBr, the
higher value of the two interim masks shall be taken as the overall interim spectral value. Finally, for any
frequency region where the mask value has not been defined yet, linear interpolation (in dB domain)
between the nearest two frequency points with the interim spectral mask value defined shall be used to
define the interim spectral mask value. The transmit spectrum shall not exceed the maximum of the interim
transmit spectrum mask and –59 dBm/MHz at any frequency offset. Figure 21-33 shows an example of a
transmit spectral mask for a noncontiguous transmission using two 80 MHz channels where the
center frequency of the two 80 MHz channels are separated by 160 MHz and the –40 dBr spectrum level is
above –59 dBm/MHz.
PSD PSD
0 dBr 0 dBr
80 MHz Mask 1 80 MHz Mask 2
-20 dBr -20 dBr
-28 dBr -28 dBr
-40 dBr -40 dBr
-120 -80 -41 -39 0 39 41 80 120 f[MHz] -120 -80 -41 -39 0 39 41 80 120 f[MHz]
PSD
0 dBr
Overall transmit spectral mask
(bold line)
-20 dBr
both of the 80 MHz -25 dBr
-28 dBr neither of the two 80
spectral masks have
MHz masks have
values greater than
values greater than
-40 dBr and less
or equal to -20 dBr
than -20 dBr
and less than or
equal to 0 dBr
-40 dBr
f[MHz]
-200 -160 -121 -119 -80 -41 -39 39 41 80 119 121 160 200
higher Original lin. Original higher
value Mask 1 sum Mask 2 value
Figure 21-33—Example transmit spectral mask for 80+80 MHz mask PPDU
Different center frequency separation between the two 80 MHz frequency segments of the spectral mask as
well as different peak levels of each 80 MHz frequency segment of the spectral mask are possible, in which
case a similar procedure in determining the spectral mask as in Figure 21-33 is followed.
The transmit spectral mask for noncontiguous transmissions using two nonadjacent 80 MHz channels is
applicable only in regulatory domains that allow for such transmissions.
Measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth.
2585
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.17.2 Spectral flatness
Spectral flatness measurements shall be conducted using BPSK modulated PPDUs. Demodulate the PPDUs
according to the following (or equivalent) procedure:
a) Start of PPDU shall be detected.
b) Transition from L-STF to L-LTF shall be detected and fine timing shall be established.
c) Coarse and fine frequency offsets shall be estimated.
d) Symbols in a PPDU shall be derotated according to estimated frequency offset.
e) For each VHT-LTF symbol, transform the symbol into subcarrier received values, estimate the
phase from the pilot subcarriers, and derotate the subcarrier values according to the estimated phase.
f) For each of the data OFDM symbols: transform the symbol into subcarrier received values.
The spectral flatness test shall be performed over at least 20 PPDUs. The PPDUs under test shall be at least
16 data OFDM symbols long.
Evaluate spectral flatness using the subcarrier received values or the magnitude of the channel estimation.
Let E i avg denote the magnitude of the channel estimation on subcarrier i or the average constellation
energy of a BPSK modulated subcarrier i in a VHT data symbol.
In a contiguous non-HT duplicate or VHT transmission having a bandwidth listed in Table 21-23, E i avg of
each of the subcarriers with indices listed as tested subcarrier indices shall not deviate by more than the
specified maximum deviation in Table 21-23 from the average of E i avg over subcarrier indices listed as
averaging subcarrier indices. Averaging of E i avg is done in the linear domain.
Table 21-23—Maximum transmit spectral flatness deviations
Bandwidth of Maximum
Averaging subcarrier Tested subcarrier indices
Format transmission deviation
indices (inclusive) (inclusive)
(MHz) (dB)
–16 to –1 and +1 to +16 ±4
20 –16 to –1 and +1 to +16
–28 to –17 and +17 to +28 +4/–6
–42 to –2 and +2 to +42 ±4
40 –42 to –2 and +2 to +42
–58 to –43 and +43 to +58 +4/–6
VHT –84 to –2 and +2 to +84 ±4
80 –84 to –2 and +2 to +84
–122 to –85 and +85 to +122 +4/–6
–172 to –130, –126 to –44, +44 to
–172 to –130, –126 to –44, ±4
+126, and +130 to +172
160 +44 to +126, and +130 to
+172 –250 to –173, –43 to –6, +6 to
+4/–6
+43, and +173 to +250
2586
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-23—Maximum transmit spectral flatness deviations (continued)
Bandwidth of Maximum
Averaging subcarrier Tested subcarrier indices
Format transmission deviation
indices (inclusive) (inclusive)
(MHz) (dB)
–42 to –33, –31 to –6, +6 to +31,
–42 to –33, –31 to –6, ±4
40 and +33 to +42
+6 to +31, and +33 to +42
–43 to –58 and +43 to +58 +4/–6
–84 to –70,–58 to –33, –31 to –6,
–84 to –70, –58 to –33, ±4
+6 to +31, +33 to +58, +70 to +84
80 –31 to –6, +6 to +31,
+33 to +58, +70 to +84 –122 to –97, –95 to –85 and +85
+4/–6
to +95, +97 to +122
non-HT
duplicate –172 to –161, –159 to –134, –172 to –161, –159 to –134,
–122 to –97, –95 to –70, –122 to –97, –95 to –70,
–58 to –44, +44 to +58, –58 to –44, +44 to +58, ±4
+70 to +95, +97 to +122, +70 to +95, +97 to +122,
+134 to +159, +161 to +172 +134 to +159, +161 to +172
160
–250 to –225, –223 to –198,
–186 to –173, –43 to –33,
–31 to –6, +6 to +31, +33 to +43, +4/–6
+173 to +186, +198 to +223,
+225 to +250
In an 80+80 MHz transmission, each segment shall meet the spectral flatness requirement for an 80 MHz
transmission.
For the spectral flatness test, the transmitting STA shall be configured to use a spatial mapping matrix Qk
(see 21.3.10.11) with flat frequency response. Each output port under test of the transmitting STA shall be
connected through a cable to one input port of the testing instrumentation. The requirements apply to
20 MHz, 40 MHz, 80 MHz, and 160 MHz contiguous transmissions as well as 80+80 MHz transmissions.
21.3.17.3 Transmit center frequency and symbol clock frequency tolerance
The symbol clock frequency and transmit center frequency tolerance shall be ±20 ppm maximum. The
transmit center frequency and the symbol clock frequency for all transmit antennas and frequency segments
shall be derived from the same reference oscillator. Transmit signals with TXVECTOR parameter
CH_BANDWIDTH set to CBW160 or CBW80+80 may be generated using two separate RF LOs, one for
each of the lower and upper 80 MHz frequency portions.
NOTE—The signal phase of the two 80 MHz frequency portions might not be correlated.
21.3.17.4 Modulation accuracy
21.3.17.4.1 Introduction to modulation accuracy tests
Transmit modulation accuracy specifications are described in 21.3.17.4.2 and 21.3.17.4.3. The test method
is described in 21.3.17.4.4.
21.3.17.4.2 Transmit center frequency leakage
TX LO leakage shall meet the following requirements for all formats and bandwidths except 80+80 MHz
where the RF LO falls outside both frequency segments:
2587
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— When the RF LO is in the center of the transmitted PPDU BW, the power measured at the center of
transmission BW using resolution BW 312.5 kHz shall not exceed the average power per-subcarrier
of the transmitted PPDU, or equivalently, ( P – 10 log 10(N ST) ), where P is the transmit power per
antenna in dBm, and NST is defined in Table 21-5.
— When the RF LO is not at the center of the transmitted PPDU BW, the power measured at the
location of the RF LO using resolution BW 312.5 kHz shall not exceed the maximum of –32 dB
relative to the total transmit power and –20 dBm, or equivalently max(P – 32 – 20) , where P is the
transmit power per antenna in dBm, and NST is defined in Table 21-5.
For an 80+80 MHz transmission where the RF LO falls outside both frequency segments, the RF LO shall
follow the spectral mask requirements as defined in 21.3.17.1.
The transmit center frequency leakage is specified per antenna.
21.3.17.4.3 Transmitter constellation error
The relative constellation RMS error, calculated by first averaging over subcarriers, frequency segments,
VHT PPDUs, and spatial streams (see Equation (19-89)) shall not exceed a data-rate dependent value
according to Table 21-24. The number of spatial streams under test shall be equal to the number of utilized
transmitting STA antenna (output) ports and also equal to the number of utilized testing instrumentation
input ports. In the test, NSS = NSTS (no STBC) shall be used. Each output port of the transmitting STA shall
be connected through a cable to one input port of the testing instrumentation. The requirements apply to
20 MHz, 40 MHz, 80 MHz, and 160 MHz contiguous transmissions as well as 80+80 MHz noncontiguous
transmissions.
Table 21-24—Allowed relative constellation error versus constellation size
and coding rate
Relative constellation error
Modulation Coding rate
(dB)
BPSK 1/2 –5
QPSK 1/2 –10
QPSK 3/4 –13
16-QAM 1/2 –16
16-QAM 3/4 –19
64-QAM 2/3 –22
64-QAM 3/4 –25
64-QAM 5/6 –27
256-QAM 3/4 –30
256-QAM 5/6 –32
For non-HT duplicate transmissions, requirements defined in 17.3.9.7.4 apply to each 20 MHz subchannel.
2588
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.17.4.4 Transmitter modulation accuracy (EVM) test
The transmit modulation accuracy test shall be performed by instrumentation capable of converting the
transmitted signals into a stream of complex samples at sampling rate greater than or equal to the bandwidth
of the signal being transmitted; except that
— For non-HT duplicate transmissions, each 20 MHz subchannel may be tested independently while all
subchannels are being transmitted and
— For noncontiguous transmissions, each frequency segment may be tested independently while both
segments are being transmitted.
In this case, transmit modulation accuracy of each segment shall meet the required value in Table 21-24
using only the subcarriers within the corresponding segment.
The instrument shall have sufficient accuracy in terms of I/Q arm amplitude and phase balance, DC offsets,
phase noise, and analog to digital quantization noise. A possible embodiment of such a setup is converting
the signals to a low IF frequency with a microwave synthesizer, sampling the signal with a digital
oscilloscope and decomposing it digitally into quadrature components. The sampled signal shall be
processed in a manner similar to an actual receiver, according to the following steps, or equivalent
procedure:
a) Start of PPDU shall be detected.
b) Transition from L-STF to L-LTF shall be detected and fine timing shall be established.
c) Coarse and fine frequency offsets shall be estimated.
d) Symbols in a PPDU shall be derotated according to estimated frequency offset.
e) For each VHT-LTF symbol, transform the symbol into subcarrier received values, estimate the
phase from the pilot subcarriers, and derotate the subcarrier values according to the estimated phase.
f) Estimate the complex channel response coefficient for each of the subcarriers and each of the
transmit streams.
g) For each of the data OFDM symbols: transform the symbol into subcarrier received values, estimate
the phase from the pilot subcarriers, derotate the subcarrier values according to the estimated phase,
group the results from all of the receiver chains in each subcarrier to a vector, and multiply the
vector by a zero-forcing equalization matrix generated from the estimated channel.
h) For each data-carrying subcarrier in each spatial stream, find the closest constellation point and
compute the Euclidean distance from it.
i) Compute the average across PPDUs of the RMS of all errors per PPDU as given by Equation (19-
89).
NOTE—In the case the transmit modulation accuracy test is performed simultaneously for the two frequency segments
of the 80+80 MHz transmissions, NST in Equation (19-89) represents the total number of subcarriers of both 80 MHz fre-
quency segments.
The test shall be performed over at least 20 PPDUs ( N f as defined in Equation (19-89)). The PPDUs under
test shall be at least 16 data OFDM symbols long. Random data shall be used for the symbols.
2589
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.3.17.5 Time of Departure accuracy
The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and
aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in
Annex P with the following test parameters:
— MULTICHANNEL_SAMPLING_RATE is:
6 fH – fL
20 10 1 + -------------------
- sample/s, for a CH_BANDWIDTH parameter equal to CBW20
20 MHz
6 fH – fL
40 10 1 + -------------------
- sample/s, for a CH_BANDWIDTH parameter equal to CBW40
40 MHz
6 fH – fL
80 10 1 + -------------------
- sample/s, for a CH_BANDWIDTH parameter equal to CBW80
80 MHz
6 fH – fL
160 10 1 + ----------------------
- sample/s, for a CH_BANDWIDTH parameter equal to CBW160
160 MHz
or CBW80+80
where
fH is the nominal center frequency in Hz of the highest channel in the channel set
fL is the nominal center frequency in Hz of the lowest channel in the channel set, the
channel set is the set of channels upon which frames providing measurements are
transmitted, the channel set comprises channels uniformly spaced across
f H – f L 50 MHz
— FIRST_TRANSITION_FIELD is L-STF.
— SECOND_TRANSITION_FIELD is L-LTF.
— TRAINING_FIELD is L-LTF windowed in a manner which should approximate the windowing
described in 17.3.2.5 with TTR = 100 ns.
— TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns.
NOTE—The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or
receiver.
21.3.18 VHT receiver specification
For tests in this subclause, the input levels are measured at the antenna connectors and are referenced as the
average power per receive antenna. The number of spatial streams under test shall be equal to the number of
utilized transmitting STA antenna (output) ports and also equal to the number of utilized Device Under Test
input ports. Each output port of the transmitting STA shall be connected through a cable to one input port of
the Device Under Test.
21.3.18.1 Receiver minimum input sensitivity
The packet error ratio (PER) shall be less than 10% for a PSDU length of 4096 octets with the rate-
dependent input levels listed in Table 21-25. The test in this subclause and the minimum sensitivity levels
specified in Table 21-25 apply only to non-STBC modes, 800 ns GI, BCC, and VHT PPDUs.
2590
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-25—Receiver minimum input level sensitivity
Minimum
Minimum Minimum Minimum
sensitivity
sensitivity sensitivity sensitivity
Rate (160 MHz or
Modulation (20 MHz (40 MHz (80 MHz
(R) 80+80 MHz
PPDU) PPDU) PPDU)
PPDU)
(dBm) (dBm) (dBm)
(dBm)
BPSK 1/2 –82 –79 –76 –73
QPSK 1/2 –79 –76 –73 –70
QPSK 3/4 –77 –74 –71 –68
16-QAM 1/2 –74 –71 –68 –65
16-QAM 3/4 –70 –67 –64 –61
64-QAM 2/3 –66 –63 –60 –57
64-QAM 3/4 –65 –62 –59 –56
64-QAM 5/6 –64 –61 –58 –55
256-QAM 3/4 –59 –56 –53 –50
256-QAM 5/6 –57 –54 –51 –48
21.3.18.2 Adjacent channel rejection
Adjacent channel rejection for W MHz channels (where W is 20, 40, 80 or 160) shall be measured by setting
the desired signal’s strength 3 dB above the rate-dependent sensitivity specified in Table 21-25 and raising
the power of the interfering signal of W MHz bandwidth until 10% PER is caused for a PSDU length of
4096 octets. The difference in power between the signals in the interfering channel and the desired channel
is the corresponding adjacent channel rejection. The center frequency of the adjacent channel shall be placed
W MHz away from the center frequency of the desired signal.
Adjacent channel rejection for 80+80 MHz channels shall be measured by setting the desired signal’s
strength 3 dB above the rate-dependent sensitivity specified in Table 21-25. Then, an interfering signal of
80 MHz bandwidth is introduced, where the center frequency of the interfering signal is placed 80 MHz
away from the center frequency of the frequency segment lower in frequency of the desired signal. The
power of the interfering signal is raised until 10% PER is caused for a PSDU length of 4096 octets. Let P 1
be the power difference between the interfering and desired signal. Next, the interfering signal of 80 MHz
bandwidth is moved to a frequency where the center frequency of the interfering signal is 80 MHz away
from the center frequency of the frequency segment higher in frequency of the desired signal. The power of
the interfering signal is raised until 10% PER is caused for a PSDU length of 4096 octets. Let P 2 be the
power difference between the interfering and desired signal. The smaller value between P 1 and P 2 is the
corresponding adjacent channel rejection.
The interfering signal in the adjacent channel shall be a signal compliant with the VHT PHY,
unsynchronized with the signal in the channel under test, and shall have a minimum duty cycle of 50%. The
corresponding rejection shall be no less than specified in Table 21-26.
The test in this subclause and the adjacent sensitivity levels specified in Table 21-26 apply only to non-
STBC modes, 800 ns GI, BCC, and VHT PPDUs.
2591
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-26—Minimum required adjacent and nonadjacent channel rejection levels
Adjacent channel rejection Nonadjacent channel rejection
(dB) (dB)
Rate
Modulation
(R) 20/40/80/ 20/40/80/
80+80 MHz 80+80 MHz
160 MHz 160 MHz
Channel Channel
Channel Channel
BPSK 1/2 16 13 32 29
QPSK 1/2 13 10 29 26
QPSK 3/4 11 8 27 24
16-QAM 1/2 8 5 24 21
16-QAM 3/4 4 1 20 17
64-QAM 2/3 0 –3 16 13
64-QAM 3/4 –1 –4 15 12
64-QAM 5/6 –2 –5 14 11
256-QAM 3/4 –7 –10 9 6
256-QAM 5/6 –9 –12 7 4
The measurement of adjacent channel rejection for 160 MHz operation in a regulatory domain is required
only if such a frequency band plan is permitted in that regulatory domain.
21.3.18.3 Nonadjacent channel rejection
Nonadjacent channel rejection for W MHz channels (where W is 20, 40, 80, or 160) shall be measured by
setting the desired signal’s strength 3 dB above the rate-dependent sensitivity specified in Table 21-25, and
raising the power of the interfering signal of W MHz bandwidth until a 10% PER occurs for a PSDU length
of 4096 octets. The difference in power between the signals in the interfering channel and the desired
channel is the corresponding nonadjacent channel rejection. The nonadjacent channel rejection shall be met
with any nonadjacent channels located at least 2×W MHz away from the center frequency of the desired
signal.
Nonadjacent channel rejection for 80+80 MHz channels shall be measured by setting the desired signal’s
strength 3 dB above the rate-dependent sensitivity specified in Table 21-25. Then, an interfering signal of
80 MHz bandwidth is introduced, where the center frequency of the interfering signal is placed at least
160 MHz away from the center frequency of the frequency segment lower in frequency of the desired signal.
The center frequency of the interfering signal shall also be at least 160 MHz away from the center frequency
of the frequency segment higher in frequency of the desired signal. The power of the interfering signal is
raised until 10% PER is caused for a PSDU length of 4096 octets. Let P 1 be the power difference between
the interfering and desired signal. Next, the interfering signal of 80 MHz bandwidth is moved to a frequency
where the center frequency of the interfering signal is at least 160 MHz away from the center frequency of
the frequency segment higher in frequency of the desired signal. The center frequency of the interfering
signal shall also be at least 160 MHz away from the center frequency of the frequency segment lower in
frequency of the desired signal. The power of the interfering signal is raised until 10% PER is caused for a
PSDU length of 4096 octets. Let P 2 be the difference in power between the signals in the interfering
channel and the desired channel. The smaller value between P 1 and P 2 is the corresponding nonadjacent
channel rejection.
2592
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The interfering signal in the nonadjacent channel shall be a signal compliant with the VHT PHY,
unsynchronized with the signal in the channel under test, and shall have a minimum duty cycle of 50%. The
corresponding rejection shall be no less than specified in Table 21-26.
The test in this subclause and the nonadjacent sensitivity levels specified in Table 21-26 apply only to non-
STBC modes, 800 ns GI, BCC, and VHT PPDUs.
The measurement of nonadjacent channel rejection for 160 MHz operation in a regulatory domain is
required only if such a frequency band plan is permitted in that regulatory domain.
21.3.18.4 Receiver maximum input level
The receiver shall provide a maximum PER of 10% at a PSDU length of 4096 octets, for a maximum input
level of –30 dBm, measured at each antenna for any baseband VHT modulation.
21.3.18.5 CCA sensitivity
21.3.18.5.1 General
The thresholds in this subclause are compared with the signal level at each receiving antenna.
21.3.18.5.2 CCA sensitivity for operating classes requiring CCA-ED
For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall also indicate a medium
busy condition when CCA-ED detects a channel busy condition.
For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED
is given in Table D-2. The operating classes requiring the corresponding CCA-ED behavior class are given
in E.1. The PHY of a STA that is operating within an operating class that requires CCA-ED shall operate
with CCA-ED.
CCA-ED shall detect a channel busy condition when the received signal strength exceeds the CCA-ED
threshold as given by dot11OFDMEDThreshold for the primary 20 MHz channel,
dot11OFDMEDThreshold for the secondary 20 MHz channel (if present), dot11OFDMEDThreshold + 3 dB
for the secondary 40 MHz channel (if present), and dot11OFDMEDThreshold + 6 dB for the secondary
80 MHz channel (if present). The CCA-ED thresholds for the operating classes requiring CCA-ED are
subject to the criteria in D.2.5.
NOTE—The requirement to detect a channel busy condition as stated in 21.3.18.5.3 and 21.3.18.5.4 is a mandatory
energy detect requirement on all Clause 21 receivers. Support for CCA-ED is an additional requirement that relates spe-
cifically to the sensitivities described in D.2.5.
21.3.18.5.3 CCA sensitivity for signals occupying the primary 20 MHz channel
The PHY shall issue a PHY-CCA.indication(BUSY, {primary}) primitive if one of the conditions listed in
Table 21-27 is met in an otherwise idle 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz operating
channel width. With >90% probability, the PHY shall detect the start of a PPDU that occupies at least the
primary 20 MHz channel under the conditions listed in Table 21-27 within a period of aCCATime (see
21.4.4) and hold the CCA signal busy (PHY-CCA.indication(BUSY, channel-list) primitive) for the
duration of the PPDU.
2593
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-27—Conditions for CCA BUSY on the primary 20 MHz
Operating channel width Conditions
20 MHz, 40 MHz, 80 MHz, The start of a 20 MHz NON_HT PPDU in the primary 20 MHz channel as
160 MHz, or 80+80 MHz defined in 17.3.10.6.
The start of an HT PPDU under the conditions defined in 19.3.19.5.
The start of a 20 MHz VHT PPDU in the primary 20 MHz channel at or
above –82 dBm.
40 MHz, 80 MHz, 160 MHz, The start of a 40 MHz non-HT duplicate or VHT PPDU in the primary 40 MHz
or 80+80 MHz channel at or above –79 dBm.
The start of an HT PPDU under the conditions defined in 19.3.19.5.
80 MHz, 160 MHz, or The start of an 80 MHz non-HT duplicate or VHT PPDU in the primary 80 MHz
80+80 MHz channel at or above –76 dBm.
160 MHz or 80+80 MHz The start of a 160 MHz or 80+80 MHz non-HT duplicate or VHT PPDU at or
above –73 dBm.
The receiver shall issue a PHY-CCA.indication(BUSY, {primary}) primitive for any signal that exceeds a
threshold equal to 20 dB above the minimum modulation and coding rate sensitivity (–82 + 20 = –62 dBm)
in the primary 20 MHz channel within a period of aCCATime after the signal arrives at the receiver’s
antenna(s); then the receiver shall not issue a PHY-CCA.indication(BUSY,{secondary}), PHY-
CCA.indication(BUSY,{secondary40}), PHY-CCA.indication(BUSY,{secondary80}), or PHY-
CCA.indication(IDLE) primitive while the threshold continues to be exceeded.
21.3.18.5.4 CCA sensitivity for signals not occupying the primary 20 MHz channel
The PHY shall issue a PHY-CCA.indication(BUSY, {secondary}) primitive if the conditions for issuing
PHY-CCA.indication(BUSY, {primary}) primitive are not present and one of the following conditions are
present in an otherwise idle 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz operating channel width:
— Any signal within the secondary 20 MHz channel at or above a threshold of –62 dBm within a period
of aCCATime after the signal arrives at the receiver’s antenna(s); then the PHY shall not issue a
PHY-CCA.indication(BUSY,{secondary40}), PHY-CCA.indication(BUSY,{secondary80}), or
PHY-CCA.indication(IDLE) primitive while the threshold continues to be exceeded.
— A 20 MHz NON_HT, HT_MF, HT_GF or VHT PPDU detected in the secondary 20 MHz channel at
or above –72 dBm with >90% probability within a period aCCAMidTime (see 21.4.4).
The PHY shall issue a PHY-CCA.indication(BUSY, {secondary40}) primitive if the conditions for issuing a
PHY-CCA.indication(BUSY, {primary}) and PHY-CCA.indication(BUSY, {secondary}) primitive are not
present and one of the following conditions are present in an otherwise idle 80 MHz, 160 MHz, or
80+80 MHz operating channel width:
— Any signal within the secondary 40 MHz channel at or above a threshold of –59 dBm within a period
of aCCATime after the signal arrives at the receiver’s antenna(s); then the PHY shall not issue a
PHY-CCA.indication(BUSY, {secondary80}) primitive or PHY-CCA.indication(IDLE) primitive
while the threshold continues to be exceeded.
— A 40 MHz non-HT duplicate, HT_MF, HT_GF or VHT PPDU detected in the secondary 40 MHz
channel at or above –72 dBm with >90% probability within a period aCCAMidTime (see 21.4.4).
— A 20 MHz non-HT, HT_MF, HT_GF or VHT PPDU detected in any 20 MHz sub-channel of the
secondary 40 MHz channel at or above –72 dBm with >90% probability within a period
aCCAMidTime.
2594
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PHY shall issue a PHY-CCA.indication(BUSY, {secondary80}) primitive if the conditions for PHY-
CCA.indication(BUSY, {primary}), PHY-CCA.indication(BUSY, {secondary}), and PHY-
CCA.indication(BUSY, {secondary40}) primitive are not present and one of the following conditions are
present in an otherwise idle 160 MHz or 80+80 MHz operating channel width:
— Any signal within the secondary 80 MHz channel at or above –56 dBm.
— An 80 MHz non-HT duplicate or VHT PPDU detected in the secondary 80 MHz channel at or above
–69 dBm with >90% probability within a period aCCAMidTime (see 21.4.4).
— A 40 MHz non-HT duplicate, HT_MF, HT_GF or VHT PPDU detected in any 40 MHz sub-channel
of the secondary 80 MHz channel at or above –72 dBm with >90% probability within a period
aCCAMidTime.
— A 20 MHz NON_HT, HT_MF, HT_GF or VHT PPDU detected in any 20 MHz sub-channel of the
secondary 80 MHz channel at or above –72 dBm with >90% probability within a period
aCCAMidTime.
21.3.18.6 RSSI
The RSSI parameter returned in the RXVECTOR shall be calculated during the reception of the VHT-LTFs
and shall be a monotonically increasing function of the received power.
21.3.19 PHY transmit procedure
There are two paths for the transmit PHY procedure:
— The first path, for which typical transmit procedures are shown in Figure 21-34, is selected if the
FORMAT parameter of the PHY-TXSTART.request(TXVECTOR) primitive is VHT. These
transmit procedures do not describe the operation of optional features, such as LDPC, STBC or MU.
— The second path is to follow the transmit procedure in Clause 17 if the FORMAT parameter of the
PHY-TXSTART.request(TXVECTOR) primitive is NON_HT and the NON_HT_MODULATION
parameter is set to NON_HT_DUP_OFDM except that the signal referred to in Clause 17 is instead
generated simultaneously on each of the 20 MHz channels that are indicated by the
CH_BANDWIDTH parameter as defined in 21.3.8 and 21.3.10.12.
NOTE 1—For a VHT MU PPDU the A-MPDU is per user in the MAC sublayer and the VHT Training Symbols, VHT-
SIG-B, and Data are per user in the PHY in Figure 21-34, with the number VHT Training Symbols depending on the
total number of space-time streams across all users.
NOTE 2—The transmit procedure for NON_HT format where NON_HT_MODULATION is OFDM is specified in
21.2.5.2. The transmit procedure for HT_MF and HT_GF formats is specified in 21.2.5.3.
In both paths, in order to transmit data, the MAC generates a PHY-TXSTART.request primitive, which
causes the PHY entity to enter the transmit state. Further, the PHY is set to operate at the appropriate
frequency through station management via the PLME, as specified in 21.4. Other transmit parameters, such
as VHT-MCS Coding types and transmit power, are set via the PHY SAP using the PHY-
TXSTART.request(TXVECTOR) primitive, as described in 21.2.2. The remainder of the clause applies to
the first path.
The PHY indicates the state of the primary channel and other channels (if any) via the PHY-CCA.indication
primitive (see 21.3.18.5 and 8.3.5.12). Transmission of the PPDU shall be initiated by the PHY after
receiving the PHY-TXSTART.request(TXVECTOR) primitive. The TXVECTOR elements for the PHY-
TXSTART.request primitive are specified in Table 21-1.
Transmission of the PHY preamble may start if TIME_OF_DEPARTURE_REQUESTED is false, and shall
start immediately if TIME_OF_DEPARTURE_REQUESTED is true, based on the parameters passed in the
PHY-TXSTART.request primitive.
2595
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PHY-TXSTART.confirm
PHY-TXEND.request
PHY-DATA.request
PHY-DATA.confirm
PHY-DATA.request
PHY-DATA.confirm
PHY-TXSTART.request
PHY-TXEND.confirm
(TXVECTOR)
…………..…………
MAC
A-MPDU including
EOF padding
Bit Padding
VHT- VHT- if needed
L-SIG Service PSDU
SIG-A SIG-B Tail Bits
Scrambling
+ encoding
VHT- VHT- VHT
VHT-
L-STF L-LTF L-SIG SIG-A SIG-A Training Data (Variable number of OFDM symbols)
SIG-B
Sym 1 Sym 2 Symbols
PHY Coded Coded Coded
OFDM OFDM OFDM Coded OFDM, VHT-MCS indicated in
BPSK, QBPSK, BPSK, VHT-SIG-A
Rate ½ Rate ½ Rate ½
Coded
OFDM
BPSK,
Rate ½
NOTE—This procedure does not describe the operation of optional features, such as MU-MIMO, LDPC or STBC.
Figure 21-34—PHY transmit procedure for SU transmission
If all of the following conditions are met:
— If dot11TODImplemented and dot11TODActivated are true or if dot11TimingMsmtActivated is
true,
— The TXVECTOR parameter TIME_OF_DEPARTURE_REQUESTED is true,
then the PHY shall issue a PHY-TXSTART.confirm(TXSTATUS) primitive to the MAC, forwarding the
TIME_OF_DEPARTURE corresponding to the time when the first frame energy is sent by the transmitting
port and TIME_OF_DEPARTURE_ClockRate parameter within the TXSTATUS vector. If
dot11TimingMsmtActivated is true, then the PHY shall forward the value of
TX_START_OF_FRAME_OFFSET in TXSTATUS vector.
After the PHY preamble transmission is started, the PHY entity immediately initiates data scrambling and
data encoding. The encoding method for the Data field is based on the FEC_CODING, CH_BANDWIDTH,
NUM_STS, STBC, MCS, and NUM_USERS parameter of the TXVECTOR, as described in 21.3.2.
The SERVICE field and PSDU are encoded as described in 21.3.3. The data shall be exchanged between the
MAC and the PHY through a series of PHY-DATA.request(DATA) primitives issued by the MAC, and
PHY-DATA.confirm primitives issued by the PHY. Zero to seven PHY padding bits are appended to the
PSDU to make the number of bits in the coded PSDU an integer multiple of the number of coded bits per
OFDM symbol.
Transmission can be prematurely terminated by the MAC through the PHY-TXEND.request primitive.
PSDU transmission is terminated by receiving a PHY-TXEND.request primitive. Each PHY-
TXEND.request primitive is acknowledged with a PHY-TXEND.confirm primitive from the PHY. In an SU
transmission, normal termination occurs after the transmission of the final bit of the last PSDU octet,
according to the number of OFDM symbols indicated by NSYM (see 21.4.3).
2596
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In the PHY, the GI or short GI is inserted in every data OFDM symbol as a countermeasure against delay
spread.
When the PPDU transmission is completed the PHY entity enters the receive state.
A typical state machine implementation of the transmit PHY for an SU transmission is provided in
Figure 21-35. Request (.request) and confirmation (.confirm) primitives are issued once per state as shown.
This state machine does not describe the operation of optional features, such as multi-user, LDPC or STBC.
21.3.20 PHY receive procedure
A typical PHY receive procedure is shown in Figure 21-36 for VHT format. A typical state machine
implementation of the receive PHY is given in Figure 21-37. This receive procedure and state machine do
not describe the operation of optional features, such as LDPC or STBC. If the detected format indicates a
NON_HT PPDU, refer to the receive procedure and state machine in Clause 17. If the detected format
indicates an HT PPDU format, refer to the receive procedure and state machine in Clause 19. Further,
through station management (via the PLME) the PHY is set to the appropriate frequency, as specified in
21.4. The PHY has also been configured with group information (i.e., group membership and position in
group) so that it can receive data intended for the STA. Other receive parameters, such as RSSI and
indicated DATARATE, may be accessed via the PHY SAP.
Upon receiving the transmitted PHY preamble overlapping the primary 20 MHz channel, the PHY measures
a receive signal strength. The PHY indicates this activity to the MAC by issuing a PHY-CCA.indication
primitive. A PHY-CCA.indication(BUSY, channel-list) primitive is also issued as an initial indication of
reception of a signal as specified in 21.3.18.5. The channel-list parameter of the PHY-CCA.indication
primitive is absent when the operating channel width is 20 MHz. The channel-list parameter is present and
includes the element primary when the operating channel width is 40 MHz, 80 MHz, 160 MHz, or
80+80 MHz.
The PHY shall not issue a PHY-RXSTART.indication primitive in response to a PPDU that does not
overlap the primary 20 MHz channel.
The PHY includes the most recently measured RSSI value in the PHY-RXSTART.indication(RXVECTOR)
primitive issued to the MAC.
After the PHY-CCA.indication(BUSY, channel-list) primitive is issued, the PHY entity shall begin
receiving the training symbols and searching for L-SIG in order to set the maximum duration of the data
stream. If the check of the L-SIG parity bit is not valid, a PHY-RXSTART.indication primitive is not issued,
and instead the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation)
primitive. If a valid L-SIG parity bit is indicated, the VHT PHY shall maintain PHY-
CCA.indication(BUSY, channel-list) primitive for the predicted duration of the transmitted PPDU, as
defined by RXTIME in Equation (21-105), for all supported modes, unsupported modes, Reserved VHT-
SIG-A Indication, invalid VHT-SIG-A CRC and invalid L-SIG Length field value. The L-SIG Length field
value of a VHT PPDU is invalid if it is not divisible by 3. Reserved VHT-SIG-A Indication is defined as a
VHT-SIG-A with Reserved bits equal to 0 or MU[u] NSTS fields (u = 0, 1, 2, 3) set to 5-7 or Short GI field
set to 0 and Short GI NSYM Disambiguation field set to 1, or a combination of VHT-MCS and NSTS not
included in 21.5 or any other VHT-SIG-A field bit combinations that do not correspond to modes of PHY
operation defined in Clause 21. If the VHT-SIG-A indicates an unsupported mode, the PHY shall issue a
PHY-RXEND.indication(UnsupportedRate) primitive. If the VHT-SIG-A indicates an invalid CRC or
Reserved VHT-SIG-A Indication or if the L-SIG Length field is invalid, the PHY shall issue the error
condition PHY-RXEND.indication(FormatViolation) primitive.
2597
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
PHY-TXSTART.request
(TXVECTOR) TX PSDU OCTET PHY-DATA.
request(DATA)
Get octet from MAC,
FORMAT= scramble, encode and
Initialize NON_HT Refer buffer
to Clause 17
FORMAT= PHY-DATA.confirm
HT_MF or
HT_GF
Refer to Buffer contains a
Set TX parameters
Clause 19 symbol’s worth of
data or last octet otherwise &&
received from MAC PHY-DATA
request(DATA)
FORMAT=
VHT
Last Symbol?
TX L-Preamble Yes
No
TX L-STF
TX L-LTF
TX L-SIG in BPSK rate 1/2
PADDING & TAIL
Add 0 to 7 PHY
padding bits,
scramble, encode, and
TX VHT-Preamble buffer,
encode & buffer tail
bits (BCC only)
TX VHT-SIG-A1 (BPSK)
TX VHT-SIG-A2 (QBPSK) TX SYMBOL
TX VHT Training Symbols
TX VHT-SIG-B (BPSK)
TX Data
Use MCS and number of
space-time streams set by Decrement Symbol
TXVECTOR
Decrement symbol
16 bit service field prepended, count Symbol Count > 0
padding and tail bits appended
to PSDU Symbol Count = 0
Switch to RX state
SETUP MPDU TX
A
PHY-TXSTART.confirm PHY-DATA.request(DATA)
Set symbol count to NSYM
At any stage in the
A above flow diagram, if
a PHY-TXEND.request
is received
NOTE—This state machine does not describe the operation of optional features, such as MU-MIMO, LDPC or STBC.
Figure 21-35—PHY transmit state machine for SU transmission
2598
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
CS/CCA state RX state
PHY-RXSTART.indication
PHY-RXEND.indication
(NoError, RXVECTOR)
PHY-DATA.indication
PHY-DATA.indication
PHY-DATA.indication
PHY-CCA.indication
PHY-CCA.indication
(Busy,primary)
(RXVECTOR)
…………..…………
(IDLE)
MAC
A-MPDU
Decoding Delay VHT-
L-SIG PSDU
SIG-A
Decoded and Pad (if present)
descrambled and Tail bits
Measure RSSI
Measure RSSI
Measure RCPI
PHY
VHT- VHT- VHT-
VHT- Data (Variable number of OFDM
L-STF L-LTF L-SIG SIG-A SIG-A Training
SIG-B symbols)
Sym 1 Sym 2 Symbols
Coded Coded Coded
OFDM OFDM OFDM Coded OFDM, VHT-MCS indicated in
BPSK, QBPSK, BPSK, VHT-SIG-A
Rate ½ Rate ½ Rate ½
Coded
OFDM
BPSK,
Rate ½
NOTE—This procedure does not describe the operation of optional features, such as LDPC or STBC. This procedure describes the case where
VHT-SIG-A indicates a mode not requiring decoding of VHT-SIG-B.
Figure 21-36—PHY receive procedure for SU transmission
After receiving a valid L-SIG and VHT-SIG-A indicating a supported mode, the PHY entity shall begin
receiving the VHT training symbols and VHT-SIG-B. If the received group ID in VHT-SIG-A has a value
indicating a VHT SU PPDU (see 10.20), the PHY entity may choose not to decode VHT-SIG-B. If VHT-
SIG-B is not decoded, subsequent to an indication of a valid VHT-SIG-A CRC, a PHY-
RXSTART.indication(RXVECTOR) primitive shall be issued.
Subsequently, if dot11TimingMsmtActivated is true, a PHY-RXSTART.indication(RXVECTOR) primitive
shall be issued and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be
forwarded (see 20.2.2).
NOTE—The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the
start of the preamble for the incoming frame was detected on the medium at the receive antenna connector.
The RXVECTOR associated with this primitive includes the parameters specified in Table 21-1.
If the Group ID field in VHT-SIG-A has a value indicating a VHT MU PPDU (see 10.20), the PHY, in a
STA that is MU beamformee capable, shall decode VHT-SIG-B. If the VHT-SIG-B indicates an
unsupported mode, the PHY shall issue the error condition PHY-RXEND.indication(UnsupportedRate)
primitive.
If VHT-SIG-B was decoded the PHY may check the VHT-SIG-B CRC in the SERVICE field. If the VHT-
SIG-B CRC in the SERVICE field is not checked a PHY-RXSTART.indication(RXVECTOR) primitive
shall be issued. The RXVECTOR associated with this primitive includes the parameters specified in
Table 21-1.
2599
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
RX IDLE state
CS/CCA
Set PHY-CCA.indication(BUSY,primary)
End of Wait Detect SIG
HT_SIG (HT GF preamble): RX Symbol
Determine type of Refer to 19.3.23
Set PHY- SIG field
CCA.indication()
in accordance L-SIG
with 21.3.18.5
Carrier lost Valid Signal
Detect L-SIG
If SERVICE
field and Decode Symbol
Receive L-SIG
field Signal Not Valid VHT-SIG-B
Carrier Lost: Decode and
decoded
Set PHY-RXEND.indication descramble
Signal Valid and CRC
(CarrierLost) Set RxEndStatus = symbol
checked
(CarrierLost, Null)
RX L-SIG Otherwise
Parity Fail:
RX and test CRC
Set PHY-RXEND.indication
(FormatViolation) Parity
CRC CRC
N_symbol>0
fail pass
Detect HT-SIG
HT_SIG (HT MF preamble): A Decrement N_symbol
Determine Refer to 19.3.23
whether HT-SIG
follows L-SIG PHY-DATA.indication
Not HT-SIG (DATA)
Carrier Lost: (bit removing if
Set PHY-RXEND.indication Detect VHT-SIG-A Not VHT-SIG-A: needed)
(CarrierLost) Determine whether Refer to 17.3.12 Decrement Time Decrement symbol
VHT-SIG-A follows count
L-SIG
Wait for intended N_symbol=0
VHT-SIG-A end of PSDU based
CRC Fail:
Set PHY-RXEND.indication on RXTIME End of PSDU RX
RX VHT-SIG-A
(FormatViolation)
RX and test CRC Time = 0 Set RxEndStatus =
(NoError, RXVECTOR)
Unsupported mode:
Set PHY-RXSTART.indication CRC OK End of Wait
(RXVECTOR) Evaluate VHT-
then set PHY-RXEND.indication SIG-A Set PHY-
(UnsupportedRate) Check contents in CCA.indication(IDLE
Supported )
VHT-SIG-A for mode, no
supported mode VHT-SIG-B
Reserved VHT-SIG-A Indication decoding
and Invalid L-LENGTH: Supported mode,
Set PHY-RXEND.indication VHT-SIG-B
(FormatViolation) decoding
RX VHT-SIG-B
Unsupported mode: RX
Set
PHY-
RXSTART.indication(RXV
ECTOR)
then set Evaluate VHT-SIG-B
PHY-RXEND.indication
(UnsupportedRate) Check contents in
VHT-SIG-B for
supported mode
Filtered out: Supported
Set mode
PHY-RXSTART.indication(RXVECTOR)
then set Determine if PPDU is NOTE—This state machine does not
PHY-RXEND.indication filtered out or not
(Filtered) describe the operation of optional features,
Evaluate whether the
PPDU is filtered out or not such as LDPC, STBC or partial AID.
based on
PHYCONFIG_VECTOR
End of Wait
Not filtered out
For unsupported modes,
Reserved VHT-SIG-A
Indication, VHT-SIG-A CRC Setup PSDU RX
failure or filtered PPDU: set
PHY-CCA.indication(IDLE) A Set N_symbols = NSYM
when predicted duration Set PHY-RXSTART.indication
based on RXTIME has (RXVECTOR)
elapsed.
Figure 21-37—PHY receive state machine
2600
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The PHY optionally filters out the PPDU based on the GroupID, MU[0-3] NSTS and Partial AID fields of
VHT-SIG-A and the contents of the PHYCONFIG_VECTOR as follows:
— The PHY shall not filter out the PPDU if one of the following is true:
— (g = 0) and (l00 is true) and (partialaid is included in PARTIAL_AID_LIST_GID00)
— (g = 63) and (l63 is true) and (partialaid is included in PARTIAL_AID_LIST_GID63)
— (1 g 62) and (MembershipStatusInGroupID[g] = 1) and
(nSTS[UserPositionInGroupID[g]] > 0)
— where
— lNN is the one of the LISTEN_TO_GIDNN parameters of the PHYCONFIG_VECTOR
— MembershipStatusInGroupID[g] is the Membership Status Array field of the
GROUP_ID_MANAGEMENT parameter of the PHYCONFIG_VECTOR for group g
— g is the value of the GroupID field of VHT-SIG-A
— nSTS[u] is the value of the MU[u] NSTS field of VHT-SIG-A
— UserPositionInGroupID[g] is the User Position Array field of the GROUP_ID_MANAGE-
MENT parameter of the PHYCONFIG_VECTOR for group g
— partialaid is the value of the Partial AID field of VHT-SIG-A
— Otherwise, the PHY may filter out the PPDU.
If the PPDU is filtered out, the PHY shall issue a PHY-RXEND.indication(Filtered) primitive.
Following training and signal fields, the Data field shall be received. The number of symbols in the Data
field is determined by Equation (21-104).
N' SYM – 1 if Short GI = 1 and Short GI NSYM Disambiguation = 1
N SYM = (21-104)
N' SYM otherwise
where
T L-STF + T L-LTF + T L-SIG + T VHT-SIG-A +
RXTIME –
T VHT-STF + N VHT - LTF T VHT-LTF + T VHT-SIG-B
N' SYM = ---------------------------------------------------------------------------------------------------------------------------------------------------
T SYM
RXTIME( s = LENGTH + 3- 4 + 20 (21-105)
--------------------------------
3
where LENGTH is the LENGTH field in L-SIG.
The value of the PSDU_LENGTH parameter returned in the RXVECTOR using BCC encoding is
calculated using Equation (21-106).
N SYM N DBPS – N service – N tail N ES
PSDU_LENGTH = ----------------------------------------------------------------------------------- (21-106)
8
where
N SYM is given by Equation (21-104)
For a VHT SU PPDU, the SU/MU[0] Coding field of VHT-SIG-A2 indicates the type of coding. The PHY
entity shall use an LDPC decoder to decode the C-PSDU if this bit is 1; otherwise, BCC decoding shall be
used. For an MU transmission, the SU/MU[0] Coding, MU[1] Coding, MU[2] Coding and MU[3] Coding
2601
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
fields of VHT-SIG-A2 indicate the type of coding for user u with USER_POSITION[u] = 0, 1, 2, and 3,
respectively. The PHY entity shall use an LDPC decoder to decode the C-PSDU for the respective user if its
bit for its C-PSDU is 1. BCC decoding shall be used otherwise. When an LDPC decoder is to be used,
NSYM,init is obtained from Equation (21-107).
N SYM init if LDPC Extra OFDM Symbol = 0
N SYM init = N SYM init – 1 if LDPC Extra OFDM Symbol = 1 and STBC = 0 (21-107)
N SYM init – 2 if LDPC Extra OFDM Symbol = 1 and STBC = 1
where
LDPC Extra OFDM Symbol and STBC are fields in VHT-SIG-A (see Table 21-12)
The value of the PSDU_LENGTH parameter returned in the RXVECTOR using LDPC encoding is
calculated using Equation (21-108).
N SYM init N DBPS – N service
PSDU_LENGTH = ------------------------------------------------------------- (21-108)
8
where
N SYM init is given by Equation (21-107)
The value of the PSDU_LENGTH parameter returned in the RXVECTOR for an NDP is 0.
If VHT-SIG-B is decoded and the VHT-SIG-B CRC in the SERVICE field is checked and not valid,
the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation) primitive. If the
VHT-SIG-B field is decoded and the VHT-SIG-B CRC field is checked and valid, a PHY-
RXSTART.indication(RXVECTOR) primitive shall be issued. The RXVECTOR associated with this
primitive includes the parameters specified in Table 21-1.
If signal loss occurs during reception prior to completion of the PSDU reception, the error condition shall be
reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive. After waiting for the intended
end of the PSDU as determined by Equation (21-105), the PHY shall generate a PHY-
CCA.indication(IDLE) primitive and return to RX IDLE state.
The received PSDU bits are assembled into octets, decoded, and presented to the MAC using a series of
PHY-DATA.indication(DATA) primitive exchanges. Any final bits that cannot be assembled into a
complete octet are considered pad bits and discarded. After the reception of the final bit of the last PSDU
octet, and possible padding and tail bits, the receiver shall be returned to the RX IDLE state, as shown in
Figure 21-37. A PHY-RXEND.indication(NoError) primitive shall be issued on entry to the RX IDLE state.
21.4 VHT PLME
21.4.1 PLME SAP sublayer management primitives
Table 21-28 lists the MIB attributes that may be accessed by the PHY entities and the intralayer of higher
level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME-
CHARACTERISTICS primitives defined in 6.5.
2602
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-28—VHT PHY MIB attributes
Default value/ Operational
Managed object
range semantics
dot11PHYOperationTable
dot11PHYType vht(9) Static
dot11PHYTxPowerTable
dot11NumberSupportedPowerLevelsImplemented Implementation Static
dependent
dot11TxPowerLevel1 Implementation Static
dependent
dot11TxPowerLevel2 Implementation Static
dependent
dot11TxPowerLevel3 Implementation Static
dependent
dot11TxPowerLevel4 Implementation Static
dependent
dot11TxPowerLevel5 Implementation Static
dependent
dot11TxPowerLevel6 Implementation Static
dependent
dot11TxPowerLevel7 Implementation Static
dependent
dot11TxPowerLevel8 Implementation Static
dependent
dot11CurrentTxPowerLevel Implementation Static
dependent
dot11TxPowerLevelExtended Implementation Static
dependent
dot11CurrentTxPowerLevelExtended Implementation Static
dependent
dot11PHYHTTable
dot11CurrentPrimaryChannel Implementation Dynamic
dependent
dot11CurrentSecondaryChannel Implementation Dynamic
dependent
dot11FortyMHzOperationImplemented false/Boolean Static
dot11FortyMHzOperationActivated false/Boolean Dynamic
dot11NumberOfSpatialStreamsImplemented Implementation Static
dependent
dot11NumberOfSpatialStreamsActivated Implementation Dynamic
dependent
dot11HTGreenfieldOptionImplemented false/Boolean Static
dot11HTGreenfieldOptionActivated false/Boolean Dynamic
2603
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-28—VHT PHY MIB attributes (continued)
Default value/ Operational
Managed object
range semantics
dot11ShortGIOptionInTwentyImplemented false/Boolean Static
dot11ShortGIOptionInTwentyActivated false/Boolean Dynamic
dot11ShortGIOptionInFortyImplemented false/Boolean Static
dot11ShortGIOptionInFortyActivated false/Boolean Dynamic
dot11LDPCCodingOptionImplemented false/Boolean Static
dot11LDPCCodingOptionActivated false/Boolean Dynamic
dot11TxSTBCOptionImplemented false/Boolean Static
dot11TxSTBCOptionActivated false/Boolean Dynamic
dot11RxSTBCOptionImplemented false/Boolean Static
dot11RxSTBCOptionActivated false/Boolean Dynamic
dot11BeamFormingOptionImplemented false/Boolean Static
dot11BeamFormingOptionActivated false/Boolean Dynamic
dot11PHYVHTTable
dot11CurrentChannelWidth Implementation Dynamic
dependent
dot11CurrentChannelCenterFrequencyIndex0 Implementation Dynamic
dependent
dot11CurrentChannelCenterFrequencyIndex1 Implementation Dynamic
dependent
dot11VHTChannelWidthOptionImplemented Implementation Static
dependent
dot11VHTShortGIOptionIn80Implemented false/Boolean Static
dot11VHTShortGIOptionIn80Activated false/Boolean Dynamic
dot11VHTShortGIOptionIn160and80p80Implemented false/Boolean Static
dot11VHTShortGIOptionIn160and80p80Activated false/Boolean Dynamic
dot11VHTLDPCCodingOptionImplemented false/Boolean Static
dot11VHTLDPCCodingOptionActivated false/Boolean Dynamic
dot11VHTTxSTBCOptionImplemented false/Boolean Static
dot11VHTTxSTBCOptionActivated false/Boolean Dynamic
dot11VHTRxSTBCOptionImplemented false/Boolean Static
dot11VHTRxSTBCOptionActivated false/Boolean Dynamic
dot11VHTMaxNTxChainsImplemented Implementation Static
dependent
dot11VHTMaxNTxChainsActivated Implementation Dynamic
dependent
2604
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-28—VHT PHY MIB attributes (continued)
Default value/ Operational
Managed object
range semantics
dot11TransmitBeamformingConfigTable
dot11ReceiveStaggerSoundingOptionImplemented false/Boolean Static
dot11TransmitStaggerSoundingOptionImplemented false/Boolean Static
dot11ReceiveNDPOptionImplemented false/Boolean Static
dot11TransmitNDPOptionImplemented false/Boolean Static
dot11ImplicitTransmitBeamformingOptionImplemented false/Boolean Static
dot11CalibrationOptionImplemented Implementation Static
dependent
dot11ExplicitCSITransmitBeamformingOptionImplement false/Boolean Static
ed
dot11ExplicitNonCompressedBeamformingMatrixOptionI false/Boolean Static
mplemented
dot11ExplicitTransmitBeamformingCSIFeedbackOptionI Implementation Static
mplemented dependent
dot11ExplicitNoncompressedBeamformingFeedbackOptio Implementation Static
nImplemented dependent
dot11ExplicitCompressedBeamformingFeedbackOptionI Implementation Static
mplemented dependent
dot11NumberBeamFormingCSISupportAntenna Implementation Static
dependent
dot11NumberNonCompressedBeamformingMatrixSuppor Implementation Static
tAntenna dependent
dot11NumberCompressedBeamformingMatrixSupportAnt Implementation Static
enna dependent
dot11VHTTransmitBeamformingConfigTable
dot11VHTSUBeamformeeOptionImplemented false/Boolean Static
dot11VHTSUBeamformerOptionImplemented false/Boolean Static
dot11VHTMUBeamformeeOptionImplemented false/Boolean Static
dot11VHTMUBeamformerOptionImplemented false/Boolean Static
dot11VHTNumberSoundingDimensions Implementation Static
dependent
dot11VHTBeamformeeNTxSupport Implementation Static
dependent
21.4.2 PHY MIB
VHT PHY MIB attributes are defined in Annex C with specific values defined in Table 21-28. The
“Operational semantics” column in Table 21-28 contains two types: static and dynamic.
— Static MIB attributes are fixed and cannot be modified for a given PHY implementation.
— Dynamic MIB attributes are interpreted according to the MAX-ACCESS field of the MIB attribute.
2605
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When MAX-ACCESS is read-only, the MIB attribute value may be updated by the PLME and read from the
MIB attribute by management entities. When MAX-ACCESS is read-write, the MIB attribute may be read
and written by management entities but shall not be updated by the PLME.
21.4.3 TXTIME and PSDU_LENGTH calculation
The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated
for a VHT PPDU using Equation (21-109) for short GI and Equation (21-110) for long GI.
T SYMS N SYM
TXTIME = T LEG_PREAMBLE + T L-SIG + T VHT-SIG-A + T VHT_PREAMBLE + T VHT-SIG-B + T SYML ----------------------------------- (21-109)
T SYML
TXTIME = T LEG_PREAMBLE + T L-SIG + T VHT-SIG-A + T VHT_PREAMBLE + T VHT-SIG-B + T SYML N SYM (21-110)
where
T LEG_PREAMBLE = T L-STF + T L-LTF
T VHT_PREAMBLE = T VHT-STF + N VHT - LTF T VHT-LTF
T SYML , T SYMS , T VHT-SIG-A , T VHT-SIG-B , T L-STF , T VHT-STF , T L-LTF , and T VHT-LTF are defined in Table 21-
5
N VHT - LTF is defined in Table 21-13
For an NDP, there is no Data field and N SYM = 0 .
For a VHT SU PPDU using BCC encoding, the total number of data symbols in the Data field is given by
Equation (21-111).
8 APEP_LENGTH + N service + N tail N ES
N SYM = m STBC -------------------------------------------------------------------------------------------------------- (21-111)
m STBC N DBPS
where
m STBC is equal to 2 when STBC is used, and 1 otherwise
For a VHT SU PPDU using LDPC encoding, the total number of data symbols in the Data field, N SYM , is
given in 21.3.10.5.4 (computed using Equation (19-41) in step d) of 19.3.11.7.5).
For a VHT MU PPDU, the total number of data symbols in the Data field, N SYM , is given by
Equation (21-67).
The value of the PSDU_LENGTH parameter returned in the PLME-TXTIME.confirm primitive for a VHT
SU PPDU using BCC encoding is calculated using Equation (21-112).
N SYM N DBPS – N service – N tail N ES
PSDU_LENGTH = ----------------------------------------------------------------------------------- (21-112)
8
where
N SYM is given by Equation (21-111)
2606
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The value of the PSDU_LENGTH parameter returned in the PLME-TXTIME.confirm primitive for a VHT
SU PPDU using LDPC encoding is calculated using Equation (21-113).
N SYM init N DBPS – N service
PSDU_LENGTH = ------------------------------------------------------------- (21-113)
8
where
N SYM init is given by Equation (21-62)
The value of the PSDU_LENGTH parameter for user u returned in the PLME-TXTIME.confirm primitive
and in the RXVECTOR for a VHT MU PPDU is calculated using Equation (21-114).
N SYM N DBPS u – N service – N tail N ES u
------------------------------------------------------------------------------------------- when BCC is used for user u
8
PSDU_LENGTH u = (21-114)
N SYM_max_init N DBPS u – N service
-------------------------------------------------------------------------
- when LDPC is used for user u
8
where
N SYM is given by Equation (21-67),
N SYM_max_init is given by Equation (21-65),
The value of the PSDU_LENGTH parameter returned in the PLME-TXTIME.confirm primitive for an NDP
is 0.
21.4.4 VHT PHY
The static VHT PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive,
shall be as shown in Table 19-25 unless otherwise listed in Table 21-29. The definitions for these
characteristics are given in 6.5.
Table 21-29—VHT PHY characteristics
Characteristics Value
aCCAMidTime 25 µs
aPPDUMaxTime 5.484 ms
aPSDUMaxLength 4 692 480 octets (see NOTE 1)
aRxPHYStartDelay 36 + 4 × the maximum possible value for NVHT-LTF supported + 4 (see NOTE 2)
NOTE 1—This is the maximum length in octets for a VHT SU PPDU with a bandwidth of 160 MHz or 80+80 MHz,
VHT-MCS 9, and 8 spatial streams, and limited by 1504 possible Short GI data symbols in aPPDUMaxTime. This is
the maximum PSDU length a VHT PHY could support assuming no restrictions in MAC. See 10.3.2 and 9.2.4.7.1
for additional restrictions on the maximum number of octets the MAC could support.
NOTE 2—This value arises from the time to the end of VHT-SIG-B (see Figure 21-4) plus the need to decode the
first symbol of the Data field in order to extract the SERVICE field and check the CRC it contains.
2607
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
21.5 Parameters for VHT-MCSs
The rate-dependent parameters for 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz N SS = 1 8
are given in Table 21-30 through Table 21-61. Support for 400 ns GI is optional in all cases. Support for
VHT-MCS 8 and 9 (when valid) is optional in all cases. A VHT STA shall support single spatial stream
VHT-MCSs within the range VHT-MCS 0 to VHT-MCS 7 for all channel widths for which it has indicated
support regardless of the Tx or Rx Highest Supported Long GI Data Rate subfield values in the Supported
VHT-MCS and NSS Set field. When more than one spatial stream is supported, the Tx or Rx Highest
Supported Long GI Data Rate subfield values in the Supported VHT-MCS and NSS Set field may result in a
reduced VHT-MCS range (cut-off) for N SS = 2 8 . Support for 20 MHz, 40 MHz, and 80 MHz with
N SS = 1 is mandatory. Support for 20 MHz, 40 MHz, and 80 MHz with N SS = 2 8 is optional.
Support for 160 MHz and 80+80 MHz with N SS = 1 8 is optional. NES values were chosen to yield an
integer number of punctured blocks for each BCC encoder per OFDM symbol.
Table 21-30 to Table 21-33, Table 21-38 to Table 21-41, Table 21-46 to Table 21-49, and Table 21-54 to
Table 21-57 define VHT-MCSs not only for SU transmission but also for user u of MU transmission. In the
case of VHT-MCSs for MU transmission, the parameters, NSS, R, NBPSCS, NCBPS, NDBPS, and NES are
replaced with NSS,u, Ru, NBPSCS,u, NCBPS,u, NDBPS,u, and NES,u, respectively. Note that the 400 ns GI rate
values are rounded to 1 decimal place.
Table 21-30—VHT-MCSs for mandatory 20 MHz, NSS = 1
Data rate (Mb/s)
VHT-
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES 400 ns GI
Index 800 ns GI (See
NOTE)
0 BPSK 1/2 1 52 4 52 26 1 6.5 7.2
1 QPSK 1/2 2 52 4 104 52 1 13.0 14.4
2 QPSK 3/4 2 52 4 104 78 1 19.5 21.7
3 16-QAM 1/2 4 52 4 208 104 1 26.0 28.9
4 16-QAM 3/4 4 52 4 208 156 1 39.0 43.3
5 64-QAM 2/3 6 52 4 312 208 1 52.0 57.8
6 64-QAM 3/4 6 52 4 312 234 1 58.5 65.0
7 64-QAM 5/6 6 52 4 312 260 1 65.0 72.2
8 256-QAM 3/4 8 52 4 416 312 1 78.0 86.7
9 Not valid
NOTE—Support of 400 ns GI is optional on transmit and receive.
2608
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-31—VHT-MCSs for optional 20 MHz, NSS = 2
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 52 4 104 52 1 13.0 14.4
1 QPSK 1/2 2 52 4 208 104 1 26.0 28.9
2 QPSK 3/4 2 52 4 208 156 1 39.0 43.3
3 16-QAM 1/2 4 52 4 416 208 1 52.0 57.8
4 16-QAM 3/4 4 52 4 416 312 1 78.0 86.7
5 64-QAM 2/3 6 52 4 624 416 1 104.0 115.6
6 64-QAM 3/4 6 52 4 624 468 1 117.0 130.0
7 64-QAM 5/6 6 52 4 624 520 1 130.0 144.4
8 256-QAM 3/4 8 52 4 832 624 1 156.0 173.3
9 Not valid
Table 21-32—VHT-MCSs for optional 20 MHz, NSS = 3
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 52 4 156 78 1 19.5 21.7
1 QPSK 1/2 2 52 4 312 156 1 39.0 43.3
2 QPSK 3/4 2 52 4 312 234 1 58.5 65.0
3 16-QAM 1/2 4 52 4 624 312 1 78.0 86.7
4 16-QAM 3/4 4 52 4 624 468 1 117.0 130.0
5 64-QAM 2/3 6 52 4 936 624 1 156.0 173.3
6 64-QAM 3/4 6 52 4 936 702 1 175.5 195.0
7 64-QAM 5/6 6 52 4 936 780 1 195.0 216.7
8 256-QAM 3/4 8 52 4 1248 936 1 234.0 260.0
9 256-QAM 5/6 8 52 4 1248 1040 1 260.0 288.9
2609
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-33—VHT-MCSs for optional 20 MHz, NSS = 4
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 52 4 208 104 1 26.0 28.9
1 QPSK 1/2 2 52 4 416 208 1 52.0 57.8
2 QPSK 3/4 2 52 4 416 312 1 78.0 86.7
3 16-QAM 1/2 4 52 4 832 416 1 104.0 115.6
4 16-QAM 3/4 4 52 4 832 624 1 156.0 173.3
5 64-QAM 2/3 6 52 4 1248 832 1 208.0 231.1
6 64-QAM 3/4 6 52 4 1248 936 1 234.0 260.0
7 64-QAM 5/6 6 52 4 1248 1040 1 260.0 288.9
8 256-QAM 3/4 8 52 4 1664 1248 1 312.0 346.7
9 Not valid
Table 21-34—VHT-MCSs for optional 20 MHz, NSS = 5
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 52 4 260 130 1 32.5 36.1
1 QPSK 1/2 2 52 4 520 260 1 65.0 72.2
2 QPSK 3/4 2 52 4 520 390 1 97.5 108.3
3 16-QAM 1/2 4 52 4 1040 520 1 130.0 144.4
4 16-QAM 3/4 4 52 4 1040 780 1 195.0 216.7
5 64-QAM 2/3 6 52 4 1560 1040 1 260.0 288.9
6 64-QAM 3/4 6 52 4 1560 1170 1 292.5 325.0
7 64-QAM 5/6 6 52 4 1560 1300 1 325.0 361.1
8 256-QAM 3/4 8 52 4 2080 1560 1 390.0 433.3
9 Not valid
2610
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-35—VHT-MCSs for optional 20 MHz, NSS = 6
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 52 4 312 156 1 39.0 43.3
1 QPSK 1/2 2 52 4 624 312 1 78.0 86.7
2 QPSK 3/4 2 52 4 624 468 1 117.0 130.0
3 16-QAM 1/2 4 52 4 1248 624 1 156.0 173.3
4 16-QAM 3/4 4 52 4 1248 936 1 234.0 260.0
5 64-QAM 2/3 6 52 4 1872 1248 1 312.0 346.7
6 64-QAM 3/4 6 52 4 1872 1404 1 351.0 390.0
7 64-QAM 5/6 6 52 4 1872 1560 1 390.0 433.3
8 256-QAM 3/4 8 52 4 2496 1872 1 468.0 520.0
9 256-QAM 5/6 8 52 4 2496 2080 1 520.0 577.8
Table 21-36—VHT-MCSs for optional 20 MHz, NSS = 7
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 52 4 364 182 1 45.5 50.6
1 QPSK 1/2 2 52 4 728 364 1 91.0 101.1
2 QPSK 3/4 2 52 4 728 546 1 136.5 151.7
3 16-QAM 1/2 4 52 4 1456 728 1 182.0 202.2
4 16-QAM 3/4 4 52 4 1456 1092 1 273.0 303.3
5 64-QAM 2/3 6 52 4 2184 1456 1 364.0 404.4
6 64-QAM 3/4 6 52 4 2184 1638 1 409.5 455.0
7 64-QAM 5/6 6 52 4 2184 1820 1 455.0 505.6
8 256-QAM 3/4 8 52 4 2912 2184 2 546.0 606.7
9 Not valid
2611
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-37—VHT-MCSs for optional 20 MHz, NSS = 8
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 52 4 416 208 1 52.0 57.8
1 QPSK 1/2 2 52 4 832 416 1 104.0 115.6
2 QPSK 3/4 2 52 4 832 624 1 156.0 173.3
3 16-QAM 1/2 4 52 4 1664 832 1 208.0 231.1
4 16-QAM 3/4 4 52 4 1664 1248 1 312.0 346.7
5 64-QAM 2/3 6 52 4 2496 1664 1 416.0 462.2
6 64-QAM 3/4 6 52 4 2496 1872 1 468.0 520.0
7 64-QAM 5/6 6 52 4 2496 2080 1 520.0 577.8
8 256-QAM 3/4 8 52 4 3328 2496 2 624.0 693.3
9 Not valid
Table 21-38—VHT-MCSs for mandatory 40 MHz, NSS = 1
Data rate (Mb/s)
VHT-
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES 400 ns GI
Index 800 ns GI (See
NOTE)
0 BPSK 1/2 1 108 6 108 54 1 13.5 15.0
1 QPSK 1/2 2 108 6 216 108 1 27.0 30.0
2 QPSK 3/4 2 108 6 216 162 1 40.5 45.0
3 16-QAM 1/2 4 108 6 432 216 1 54.0 60.0
4 16-QAM 3/4 4 108 6 432 324 1 81.0 90.0
5 64-QAM 2/3 6 108 6 648 432 1 108.0 120.0
6 64-QAM 3/4 6 108 6 648 486 1 121.5 135.0
7 64-QAM 5/6 6 108 6 648 540 1 135.0 150.0
8 256-QAM 3/4 8 108 6 864 648 1 162.0 180.0
9 256-QAM 5/6 8 108 6 864 720 1 180.0 200.0
NOTE—Support of 400 ns GI is optional on transmit and receive.
2612
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-39—VHT-MCSs for optional 40 MHz, NSS = 2
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 108 6 216 108 1 27.0 30.0
1 QPSK 1/2 2 108 6 432 216 1 54.0 60.0
2 QPSK 3/4 2 108 6 432 324 1 81.0 90.0
3 16-QAM 1/2 4 108 6 864 432 1 108.0 120.0
4 16-QAM 3/4 4 108 6 864 648 1 162.0 180.0
5 64-QAM 2/3 6 108 6 1296 864 1 216.0 240.0
6 64-QAM 3/4 6 108 6 1296 972 1 243.0 270.0
7 64-QAM 5/6 6 108 6 1296 1080 1 270.0 300.0
8 256-QAM 3/4 8 108 6 1728 1296 1 324.0 360.0
9 256-QAM 5/6 8 108 6 1728 1440 1 360.0 400.0
Table 21-40—VHT-MCSs for optional 40 MHz, NSS = 3
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 108 6 324 162 1 40.5 45.0
1 QPSK 1/2 2 108 6 648 324 1 81.0 90.0
2 QPSK 3/4 2 108 6 648 486 1 121.5 135.0
3 16-QAM 1/2 4 108 6 1296 648 1 162.0 180.0
4 16-QAM 3/4 4 108 6 1296 972 1 243.0 270.0
5 64-QAM 2/3 6 108 6 1944 1296 1 324.0 360.0
6 64-QAM 3/4 6 108 6 1944 1458 1 364.5 405.0
7 64-QAM 5/6 6 108 6 1944 1620 1 405.0 450.0
8 256-QAM 3/4 8 108 6 2592 1944 1 486.0 540.0
9 256-QAM 5/6 8 108 6 2592 2160 1 540.0 600.0
2613
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-41—VHT-MCSs for optional 40 MHz, NSS = 4
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 108 6 432 216 1 54.0 60.0
1 QPSK 1/2 2 108 6 864 432 1 108.0 120.0
2 QPSK 3/4 2 108 6 864 648 1 162.0 180.0
3 16-QAM 1/2 4 108 6 1728 864 1 216.0 240.0
4 16-QAM 3/4 4 108 6 1728 1296 1 324.0 360.0
5 64-QAM 2/3 6 108 6 2592 1728 1 432.0 480.0
6 64-QAM 3/4 6 108 6 2592 1944 1 486.0 540.0
7 64-QAM 5/6 6 108 6 2592 2160 1 540.0 600.0
8 256-QAM 3/4 8 108 6 3456 2592 2 648.0 720.0
9 256-QAM 5/6 8 108 6 3456 2880 2 720.0 800.0
Table 21-42—VHT-MCSs for optional 40 MHz, NSS = 5
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 108 6 540 270 1 67.5 75.0
1 QPSK 1/2 2 108 6 1080 540 1 135.0 150.0
2 QPSK 3/4 2 108 6 1080 810 1 202.5 225.0
3 16-QAM 1/2 4 108 6 2160 1080 1 270.0 300.0
4 16-QAM 3/4 4 108 6 2160 1620 1 405.0 450.0
5 64-QAM 2/3 6 108 6 3240 2160 1 540.0 600.0
6 64-QAM 3/4 6 108 6 3240 2430 2 607.5 675.0
7 64-QAM 5/6 6 108 6 3240 2700 2 675.0 750.0
8 256-QAM 3/4 8 108 6 4320 3240 2 810.0 900.0
9 256-QAM 5/6 8 108 6 4320 3600 2 900.0 1000.0
2614
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-43—VHT-MCSs for optional 40 MHz, NSS = 6
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 108 6 648 324 1 81.0 90.0
1 QPSK 1/2 2 108 6 1296 648 1 162.0 180.0
2 QPSK 3/4 2 108 6 1296 972 1 243.0 270.0
3 16-QAM 1/2 4 108 6 2592 1296 1 324.0 360.0
4 16-QAM 3/4 4 108 6 2592 1944 1 486.0 540.0
5 64-QAM 2/3 6 108 6 3888 2592 2 648.0 720.0
6 64-QAM 3/4 6 108 6 3888 2916 2 729.0 810.0
7 64-QAM 5/6 6 108 6 3888 3240 2 810.0 900.0
8 256-QAM 3/4 8 108 6 5184 3888 2 972.0 1080.0
9 256-QAM 5/6 8 108 6 5184 4320 2 1080.0 1200.0
Table 21-44—VHT-MCSs for optional 40 MHz, NSS = 7
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 108 6 756 378 1 94.5 105.0
1 QPSK 1/2 2 108 6 1512 756 1 189.0 210.0
2 QPSK 3/4 2 108 6 1512 1134 1 283.5 315.0
3 16-QAM 1/2 4 108 6 3024 1512 1 378.0 420.0
4 16-QAM 3/4 4 108 6 3024 2268 2 567.0 630.0
5 64-QAM 2/3 6 108 6 4536 3024 2 756.0 840.0
6 64-QAM 3/4 6 108 6 4536 3402 2 850.5 945.0
7 64-QAM 5/6 6 108 6 4536 3780 2 945.0 1050.0
8 256-QAM 3/4 8 108 6 6048 4536 3 1134.0 1260.0
9 256-QAM 5/6 8 108 6 6048 5040 3 1260.0 1400.0
2615
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-45—VHT-MCSs for optional 40 MHz, NSS = 8
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 108 6 864 432 1 108.0 120.0
1 QPSK 1/2 2 108 6 1728 864 1 216.0 240.0
2 QPSK 3/4 2 108 6 1728 1296 1 324.0 360.0
3 16-QAM 1/2 4 108 6 3456 1728 1 432.0 480.0
4 16-QAM 3/4 4 108 6 3456 2592 2 648.0 720.0
5 64-QAM 2/3 6 108 6 5184 3456 2 864.0 960.0
6 64-QAM 3/4 6 108 6 5184 3888 2 972.0 1080.0
7 64-QAM 5/6 6 108 6 5184 4320 2 1080.0 1200.0
8 256-QAM 3/4 8 108 6 6912 5184 3 1296.0 1440.0
9 256-QAM 5/6 8 108 6 6912 5760 3 1440.0 1600.0
Table 21-46—VHT-MCSs for mandatory 80 MHz, NSS = 1
Data rate (Mb/s)
VHT-
NCBP
MCS Modulation R NBPSCS NSD NSP NDBPS NES 400 ns GI
Index S
800 ns GI (See
NOTE)
0 BPSK 1/2 1 234 8 234 117 1 29.3 32.5
1 QPSK 1/2 2 234 8 468 234 1 58.5 65.0
2 QPSK 3/4 2 234 8 468 351 1 87.8 97.5
3 16-QAM 1/2 4 234 8 936 468 1 117.0 130.0
4 16-QAM 3/4 4 234 8 936 702 1 175.5 195.0
5 64-QAM 2/3 6 234 8 1404 936 1 234.0 260.0
6 64-QAM 3/4 6 234 8 1404 1053 1 263.3 292.5
7 64-QAM 5/6 6 234 8 1404 1170 1 292.5 325.0
8 256-QAM 3/4 8 234 8 1872 1404 1 351.0 390.0
9 256-QAM 5/6 8 234 8 1872 1560 1 390.0 433.3
NOTE—Support of 400 ns GI is optional on transmit and receive.
2616
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-47—VHT-MCSs for optional 80 MHz, NSS = 2
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 234 8 468 234 1 58.5 65.0
1 QPSK 1/2 2 234 8 936 468 1 117.0 130.0
2 QPSK 3/4 2 234 8 936 702 1 175.5 195.0
3 16-QAM 1/2 4 234 8 1872 936 1 234.0 260.0
4 16-QAM 3/4 4 234 8 1872 1404 1 351.0 390.0
5 64-QAM 2/3 6 234 8 2808 1872 1 468.0 520.0
6 64-QAM 3/4 6 234 8 2808 2106 1 526.5 585.0
7 64-QAM 5/6 6 234 8 2808 2340 2 585.0 650.0
8 256-QAM 3/4 8 234 8 3744 2808 2 702.0 780.0
9 256-QAM 5/6 8 234 8 3744 3120 2 780.0 866.7
Table 21-48—VHT-MCSs for optional 80 MHz, NSS = 3
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 234 8 702 351 1 87.8 97.5
1 QPSK 1/2 2 234 8 1404 702 1 175.5 195.0
2 QPSK 3/4 2 234 8 1404 1053 1 263.3 292.5
3 16-QAM 1/2 4 234 8 2808 1404 1 351.0 390.0
4 16-QAM 3/4 4 234 8 2808 2106 1 526.5 585.0
5 64-QAM 2/3 6 234 8 4212 2808 2 702.0 780.0
6 Not valid
7 64-QAM 5/6 6 234 8 4212 3510 2 877.5 975.0
8 256-QAM 3/4 8 234 8 5616 4212 2 1053.0 1170.0
9 256-QAM 5/6 8 234 8 5616 4680 3 1170.0 1300.0
2617
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-49—VHT-MCSs for optional 80 MHz, NSS = 4
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 234 8 936 468 1 117.0 130.0
1 QPSK 1/2 2 234 8 1872 936 1 234.0 260.0
2 QPSK 3/4 2 234 8 1872 1404 1 351.0 390.0
3 16-QAM 1/2 4 234 8 3744 1872 1 468.0 520.0
4 16-QAM 3/4 4 234 8 3744 2808 2 702.0 780.0
5 64-QAM 2/3 6 234 8 5616 3744 2 936.0 1040.0
6 64-QAM 3/4 6 234 8 5616 4212 2 1053.0 1170.0
7 64-QAM 5/6 6 234 8 5616 4680 3 1170.0 1300.0
8 256-QAM 3/4 8 234 8 7488 5616 3 1404.0 1560.0
9 256-QAM 5/6 8 234 8 7488 6240 3 1560.0 1733.3
Table 21-50—VHT-MCSs for optional 80 MHz, NSS = 5
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 234 8 1170 585 1 146.3 162.5
1 QPSK 1/2 2 234 8 2340 1170 1 292.5 325.0
2 QPSK 3/4 2 234 8 2340 1755 1 438.8 487.5
3 16-QAM 1/2 4 234 8 4680 2340 2 585.0 650.0
4 16-QAM 3/4 4 234 8 4680 3510 2 877.5 975.0
5 64-QAM 2/3 6 234 8 7020 4680 3 1170.0 1300.0
6 64-QAM 3/4 6 234 8 7020 5265 3 1316.3 1462.5
7 64-QAM 5/6 6 234 8 7020 5850 3 1462.5 1625.0
8 256-QAM 3/4 8 234 8 9360 7020 4 1755.0 1950.0
9 256-QAM 5/6 8 234 8 9360 7800 4 1950.0 2166.7
2618
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-51—VHT-MCSs for optional 80 MHz, NSS = 6
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 234 8 1404 702 1 175.5 195.0
1 QPSK 1/2 2 234 8 2808 1404 1 351.0 390.0
2 QPSK 3/4 2 234 8 2808 2106 1 526.5 585.0
3 16-QAM 1/2 4 234 8 5616 2808 2 702.0 780.0
4 16-QAM 3/4 4 234 8 5616 4212 2 1053.0 1170.0
5 64-QAM 2/3 6 234 8 8424 5616 3 1404.0 1560.0
6 64-QAM 3/4 6 234 8 8424 6318 3 1579.5 1755.0
7 64-QAM 5/6 6 234 8 8424 7020 4 1755.0 1950.0
8 256-QAM 3/4 8 234 8 11 232 8424 4 2106.0 2340.0
9 Not valid
Table 21-52—VHT-MCSs for optional 80 MHz, NSS = 7
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 234 8 1638 819 1 204.8 227.5
1 QPSK 1/2 2 234 8 3276 1638 1 409.5 455.0
2 QPSK 3/4 2 234 8 3276 2457 3 614.3 682.5
3 16-QAM 1/2 4 234 8 6552 3276 2 819.0 910.0
4 16-QAM 3/4 4 234 8 6552 4914 3 1228.5 1365.0
5 64-QAM 2/3 6 234 8 9828 6552 4 1638.0 1820.0
6 Not valid
7 64-QAM 5/6 6 234 8 9828 8190 6 2047.5 2275.0
8 256-QAM 3/4 8 234 8 13 104 9828 6 2457.0 2730.0
9 256-QAM 5/6 8 234 8 13 104 10 920 6 2730.0 3033.3
2619
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-53—VHT-MCSs for optional 80 MHz, NSS = 8
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 234 8 1872 936 1 234.0 260.0
1 QPSK 1/2 2 234 8 3744 1872 1 468.0 520.0
2 QPSK 3/4 2 234 8 3744 2808 2 702.0 780.0
3 16-QAM 1/2 4 234 8 7488 3744 2 936.0 1040.0
4 16-QAM 3/4 4 234 8 7488 5616 3 1404.0 1560.0
5 64-QAM 2/3 6 234 8 11 232 7488 4 1872.0 2080.0
6 64-QAM 3/4 6 234 8 11 232 8424 4 2106.0 2340.0
7 64-QAM 5/6 6 234 8 11 232 9360 6 2340.0 2600.0
8 256-QAM 3/4 8 234 8 14 976 11 232 6 2808.0 3120.0
9 256-QAM 5/6 8 234 8 14 976 12 480 6 3120.0 3466.7
Table 21-54—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 1
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 468 16 468 234 1 58.5 65.0
1 QPSK 1/2 2 468 16 936 468 1 117.0 130.0
2 QPSK 3/4 2 468 16 936 702 1 175.5 195.0
3 16-QAM 1/2 4 468 16 1872 936 1 234.0 260.0
4 16-QAM 3/4 4 468 16 1872 1404 1 351.0 390.0
5 64-QAM 2/3 6 468 16 2808 1872 1 468.0 520.0
6 64-QAM 3/4 6 468 16 2808 2106 1 526.5 585.0
7 64-QAM 5/6 6 468 16 2808 2340 2 585.0 650.0
8 256-QAM 3/4 8 468 16 3744 2808 2 702.0 780.0
9 256-QAM 5/6 8 468 16 3744 3120 2 780.0 866.7
2620
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-55—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 2
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 468 16 936 468 1 117.0 130.0
1 QPSK 1/2 2 468 16 1872 936 1 234.0 260.0
2 QPSK 3/4 2 468 16 1872 1404 1 351.0 390.0
3 16-QAM 1/2 4 468 16 3744 1872 1 468.0 520.0
4 16-QAM 3/4 4 468 16 3744 2808 2 702.0 780.0
5 64-QAM 2/3 6 468 16 5616 3744 2 936.0 1040.0
6 64-QAM 3/4 6 468 16 5616 4212 2 1053.0 1170.0
7 64-QAM 5/6 6 468 16 5616 4680 3 1170.0 1300.0
8 256-QAM 3/4 8 468 16 7488 5616 3 1404.0 1560.0
9 256-QAM 5/6 8 468 16 7488 6240 3 1560.0 1733.3
Table 21-56—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 3
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 468 16 1404 702 1 175.5 195.0
1 QPSK 1/2 2 468 16 2808 1404 1 351.0 390.0
2 QPSK 3/4 2 468 16 2808 2106 1 526.5 585.0
3 16-QAM 1/2 4 468 16 5616 2808 2 702.0 780.0
4 16-QAM 3/4 4 468 16 5616 4212 2 1053.0 1170.0
5 64-QAM 2/3 6 468 16 8424 5616 3 1404.0 1560.0
6 64-QAM 3/4 6 468 16 8424 6318 3 1579.5 1755.0
7 64-QAM 5/6 6 468 16 8424 7020 4 1755.0 1950.0
8 256-QAM 3/4 8 468 16 11 232 8424 4 2106.0 2340.0
9 Not valid
2621
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-57—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 4
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 468 16 1872 936 1 234.0 260.0
1 QPSK 1/2 2 468 16 3744 1872 1 468.0 520.0
2 QPSK 3/4 2 468 16 3744 2808 2 702.0 780.0
3 16-QAM 1/2 4 468 16 7488 3744 2 936.0 1040.0
4 16-QAM 3/4 4 468 16 7488 5616 3 1404.0 1560.0
5 64-QAM 2/3 6 468 16 11 232 7488 4 1872.0 2080.0
6 64-QAM 3/4 6 468 16 11 232 8424 4 2106.0 2340.0
7 64-QAM 5/6 6 468 16 11 232 9360 6 2340.0 2600.0
8 256-QAM 3/4 8 468 16 14 976 11 232 6 2808.0 3120.0
9 256-QAM 5/6 8 468 16 14 976 12 480 6 3120.0 3466.7
Table 21-58—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 5
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 468 16 2340 1170 1 292.5 325.0
1 QPSK 1/2 2 468 16 4680 2340 2 585.0 650.0
2 QPSK 3/4 2 468 16 4680 3510 2 877.5 975.0
3 16-QAM 1/2 4 468 16 9360 4680 3 1170.0 1300.0
4 16-QAM 3/4 4 468 16 9360 7020 4 1755.0 1950.0
5 64-QAM 2/3 6 468 16 14 040 9360 5 2340.0 2600.0
6 64-QAM 3/4 6 468 16 14 040 10 530 5 2632.5 2925.0
7 64-QAM 5/6 6 468 16 14 040 11 700 6 2925.0 3250.0
8 256-QAM 3/4 8 468 16 18 720 14 040 8 3510.0 3900.0
9 256-QAM 5/6 8 468 16 18 720 15 600 8 3900.0 4333.3
2622
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-59—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 6
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 468 16 2808 1404 1 351.0 390.0
1 QPSK 1/2 2 468 16 5616 2808 2 702.0 780.0
2 QPSK 3/4 2 468 16 5616 4212 2 1053.0 1170.0
3 16-QAM 1/2 4 468 16 11 232 5616 3 1404.0 1560.0
4 16-QAM 3/4 4 468 16 11 232 8424 4 2106.0 2340.0
5 64-QAM 2/3 6 468 16 16 848 11 232 6 2808.0 3120.0
6 64-QAM 3/4 6 468 16 16 848 12 636 6 3159.0 3510.0
7 64-QAM 5/6 6 468 16 16 848 14 040 8 3510.0 3900.0
8 256-QAM 3/4 8 468 16 22 464 16 848 8 4212.0 4680.0
9 256-QAM 5/6 8 468 16 22 464 18 720 9 4680.0 5200.0
Table 21-60—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 7
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 468 16 3276 1638 1 409.5 455.0
1 QPSK 1/2 2 468 16 6552 3276 2 819.0 910.0
2 QPSK 3/4 2 468 16 6552 4914 3 1228.5 1365.0
3 16-QAM 1/2 4 468 16 13 104 6552 4 1638.0 1820.0
4 16-QAM 3/4 4 468 16 13 104 9828 6 2457.0 2730.0
5 64-QAM 2/3 6 468 16 19 656 13 104 7 3276.0 3640.0
6 64-QAM 3/4 6 468 16 19 656 14 742 7 3685.5 4095.0
7 64-QAM 5/6 6 468 16 19 656 16 380 9 4095.0 4550.0
8 256-QAM 3/4 8 468 16 26 208 19 656 12 4914.0 5460.0
9 256-QAM 5/6 8 468 16 26 208 21 840 12 5460.0 6066.7
2623
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 21-61—VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 8
VHT- Data rate (Mb/s)
MCS Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS NES
Index 800 ns GI 400 ns GI
0 BPSK 1/2 1 468 16 3744 1872 1 468.0 520.0
1 QPSK 1/2 2 468 16 7488 3744 2 936.0 1040.0
2 QPSK 3/4 2 468 16 7488 5616 3 1404.0 1560.0
3 16-QAM 1/2 4 468 16 14 976 7488 4 1872.0 2080.0
4 16-QAM 3/4 4 468 16 14 976 11 232 6 2808.0 3120.0
5 64-QAM 2/3 6 468 16 22 464 14 976 8 3744.0 4160.0
6 64-QAM 3/4 6 468 16 22 464 16 848 8 4212.0 4680.0
7 64-QAM 5/6 6 468 16 22 464 18 720 9 4680.0 5200.0
8 256-QAM 3/4 8 468 16 29 952 22 464 12 5616.0 6240.0
9 256-QAM 5/6 8 468 16 29 952 24 960 12 6240.0 6933.3
2624
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22. Television very high throughput (TVHT) PHY specification
22.1 Introduction
22.1.1 Introduction to the TVHT PHY
Clause 22 specifies the PHY entity for a television very high throughput (TVHT) orthogonal frequency
division multiplexing (OFDM) system.
Three basic channel units (BCUs) are defined as 6 MHz, 7 MHz, or 8 MHz, depending on the regulatory
domain, and denoted in the rest of this clause as a BCU or TVHT_W. Many of the terms used in this clause
refer to different bands, depending on the regulatory domain. These terms include
— TVHT_2W, which represents two contiguous BCUs (12 MHz, 14 MHz, or 16 MHz)
— TVHT_W+W, which represents two noncontiguous BCU (6+6 MHz, 7+7 MHz, or 8+8 MHz)
— TVHT_4W, which represents four contiguous BCUs (24 MHz, 28 MHz, or 32 MHz)
— TVHT_2W+2W, which represents two noncontiguous frequency segments, each of which is com-
posed of two BCUs (12+12 MHz, 14+14 MHz, or 16+16 MHz)
The TVHT PHY is based on the VHT PHY as defined in 21.3, 21.4, 21.5, and on Clause 17.
All TVHT transmissions in one BCU shall use the VHT PHY parameters for 40 MHz channel defined in
21.3, 21.4, and 21.5 with a sampling clock change to fit into each of the BCU bandwidths and with the
number of encoders (NES) always being 1 (for SU-MIMO and per user in MU-MIMO).
Table 22-8 describes the sampling clock for each of the BCUs and the basic PHY parameters for
transmission over one BCU.
For all VHT PPDUs and non-HT PPDUs in TVWS band, timing-related parameters shall be used as defined
in Table 22-5 and Table 22-8; frequently used parameters shall be used as defined in Table 22-6 and
Table 22-9; phase rotation parameter k BW shall be replaced by k M , which is defined in Table 22-12;
and cyclic shift parameters shall be used as defined in 22.3.8.3.2.
As shown in Table 22-8, the design is based on defining 144 OFDM tones in the 6 MHz and 8 MHz channel
units and using up to tone 58 on each side of the DC tone for data and pilots, exactly matching the VHT 40
MHz PHY parameters. The 7 MHz channel unit is split into 168 tones to maintain the same tone spacing and
PHY design as used for 6 MHz channels (note the ratio of 168 to 144 is identical to the ratio of 7 to 6). The
choice of 144 and not 128 was made to reduce the PHY channel BW from 6 MHz to 5 1/3 MHz in order to
allow sharper filtering to achieve 55 dB ACLR.
The TVHT PHY defines the following transmission modes that incorporate transmission on one, two, or
four BCUs:
a) Mandatory transmission mode - one BCU (TVHT_MODE_1)
b) Optional transmission modes - multi-BCUs
1) Two contiguous BCUs (TVHT_MODE_2C)
2) Two noncontiguous BCUs (TVHT_MODE_2N)
3) Four contiguous BCUs (TVHT_MODE_4C)
4) Two noncontiguous frequency segments, each of which comprises two contiguous BCUs
(TVHT_MODE_4N)
2625
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The tone spacing, DFT duration, and other timing parameters remain unchanged for all optional modes
compared with the definition in Table 22-8.
The number of occupied tones in each BCU of any optional mode is the same as the number defined in
Table 22-8.
The location of the occupied tones in each BCU of any optional mode is shown in Table 22-9.
The DATA encoding process for multi-BCUs transmission is similar to one BCU transmission and is defined
in 22.3.10.
A TVHT STA shall support the following features:
— TVHT_MODE_1 (one BCU)
— Single spatial stream MCSs 0 to 7 (transmit and receive)
— Binary convolutional coding
— Normal and short guard interval (transmit and receive)
A TVHT STA may support the following features:
— TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, or TVHT_MODE_4N (two or four
BCUs)
— Two or more spatial streams (transmit and receive)
— Beamforming sounding (by sending a VHT NDP frame)
— Respond to transmit beamforming sounding (provide compressed beamforming feedback)
— STBC (transmit and receive)
— LDPC (transmit and receive)
— VHT MU PPDUs (transmit and receive)
— MCSs 8 and 9 (transmit and receive)
22.1.2 Scope
The services provided to the MAC by the TVHT PHY consist of a protocol function that defines the
characteristics and method of transmitting and receiving data through a wireless medium between two or
more STAs. These STAs support a TVHT PHY.
22.1.3 TVHT PHY functions
22.1.3.1 General
See 21.1.3.1 with “TVHT” replacing “VHT”.
22.1.3.2 PHY management entity (PLME)
See 21.1.3.2.
22.1.3.3 Service specification method
See 21.1.3.3 with “TVHT” replacing “VHT”.
2626
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.1.4 PPDU formats
The structure of the PPDU transmitted by a TVHT STA is determined by the TXVECTOR parameters as
defined in 22.2.2.
The FORMAT parameter determines the overall structure of the PPDU and includes the following:
— Non-HT format (NON_HT), based on Clause 17. Support for non-HT format is mandatory.
— VHT format (VHT). Support for TVHT_W VHT format is mandatory.
22.2 TVHT PHY service interface
22.2.1 Introduction
See 21.2.1.
22.2.2 TXVECTOR and RXVECTOR parameters
The TXVECTOR and RXVECTOR parameters are defined in Table 22-1.
The TXVECTOR parameter FORMAT shall be set to NON_HT or VHT. When the TXVECTOR parameter
FORMAT equals NON_HT, then NON_HT_MODULATION shall be set to NON_HT_DUP_OFDM.
When the TXVECTOR parameter FORMAT equals NON_HT, the TXVECTOR parameter L_DATARATE
indicates the data rate used to transmit the PSDU in Mb/s. The allowed values are 6 Mb/s, 9 Mb/s, 12 Mb/s,
18 Mb/s, 24 Mb/s, 36 Mb/s, 48 Mb/s, and 54 Mb/s divided by 7.5 for 6 MHz and 7 MHz unit channels and
by 5.625 for 8 MHz channels.
When the TXVECTOR parameter FORMAT equals VHT, the TXVECTOR parameter CH_BANDWIDTH
indicates the channel width of the transmitted PPDU:
Enumerated type:
— TVHT_W for one BCU
— TVHT_2W for two contiguous BCUs
— TVHT_W+W for two noncontiguous BCUs
— TVHT_4W for four contiguous BCUs
— TVHT_2W+2W for two noncontiguous frequency segments, each of which comprises two
contiguous BCUs
Note that TVHT_W represents the broadcast channel bandwidth for the regulatory domain, e.g., TVHT_W
is 6 MHz, 7 MHz, or 8 MHz. TVHT_2W represents two contiguous BCUs with the same regulatory domain,
e.g., TVHT_2W is 12 MHz, 14 MHz, or 16 MHz.
When the TXVECTOR parameter FORMAT equals NON_HT, the TXVECTOR parameter
CH_BANDWIDTH indicates the channel width of the transmitted PPDU on transmission and the estimated
channel width of the received PPDU on reception:
Enumerated type:
— TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, TVHT_2W+2W
When the TXVECTOR parameter FORMAT equals VHT, the TXVECTOR parameter NUM_STS indicates
the number of space-time streams: range 1 to 4 for SU, 1 to 3 per user for MU. NUM_STS summed over all
2627
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
users shall be less than or equal to 4. The TXVECTOR parameter NUM_STS is not present when the
TXVECTOR parameter FORMAT equals to NON_HT.
Table 22-1—TXVECTOR and RXVECTOR parameters
RXVECTOR
TXVECTOR
Parameter
Condition Value
Determines the format of the PPDU. Y Y
Enumerated type:
FORMAT
NON_HT indicates non-HT duplicated PPDU format. In this case,
the modulation is determined by the NON_HT_MODULATION
parameter.
VHT indicates VHT format.
FORMAT is NON_HT In TXVECTOR, indicates the format type of the transmitted non- Y Y
NON_HT_MODULATION
HT PPDU.
In RXVECTOR, indicates the estimated format type of the received
non-HT PPDU.
Enumerated type:
NON_HT_DUP_OFDM indicates non-HT duplicate format.
Otherwise Not present N N
FORMAT is NON_HT Indicates the length of the PSDU in octets in the range 1 to 4095. Y Y
This value is used by the PHY to determine the number of octet
L_LENGTH
transfers that occur between the MAC and the PHY.
FORMAT is VHT Not present N N
NOTE—The Length field of the L-SIG in VHT PPDUs is defined
in Equation (22-9) using the scaling factor defined in 22.3.8.2.1.
FORMAT is NON_HT Indicates the data rate used to transmit the PSDU in Mb/s. The Y Y
allowed values are 6, 9, 12, 18, 24, 36, 48, and 54 divided by 7.5 for
L_DATARATE
6 MHz and 7 MHz unit channels and by 5.625 for 8 MHz channels.
FORMAT is VHT Not present N N
NOTE—The RATE field in the L-SIG field in a VHT PPDU is set
to the value representing 6/X Mb/s in TVWS band “Modulation
BPSK and Coding rate 1/2” row of Table 22-4.
FORMAT is VHT Indicates the number of transmit chains. Y N
N_TX
Otherwise Not present N N
FORMAT is VHT and Set to COMPRESSED_SV Y N
EXPANSION_MAT_TYPE
EXPANSION_MAT
is present.
Otherwise See corresponding entry in Table 19-1
2628
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT Contains a vector in the number of selected subcarriers containing M N
EXPANSION_MAT
feedback matrices as defined in 22.3.11.2 based on the channel U
measured during the training symbols of a previous VHT NDP
PPDU.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT and Set to COMPRESSED_SV N Y
CHAN_MAT_TYPE
PSDU_LENGTH NOTE—This parameter is present only for TVHT NDP PPDUs.
equals zero
FORMAT is VHT and Not present N N
PSDU_LENGTH is
greater than zero
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT and Contains a set of compressed beamforming feedback matrices as N Y
PSDU_LENGTH defined in 21.3.11.2 based on the channel measured during the
CHAN_MAT
equals zero training symbols of the received VHT NDP PPDU.
FORMAT is VHT and Not present N N
PSDU_LENGTH is
greater than zero
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Contains an array of delta SNR values as defined in 9.4.1.52 based M Y
on the channel measured during the training symbols of the U
DELTA_SNR
received VHT NDP PPDU.
NOTE—In the RXVECTOR this parameter is present only for VHT
NDP PPDUs for MU sounding.
Otherwise Not present N N
Is a measure of the received RF power averaged over all of the N Y
RCPI
receive chains in the Data field of a received PPDU. Refer to
19.3.19.6 for the definition of RCPI.
FORMAT is VHT Contains an array of measures of the received SNR for each spatial N Y
stream. SNR indications of 8 bits are supported. SNR shall be the
sum of the decibel values of SNR per tone divided by the number of
SNR
tones represented in each stream as described in 9.4.1.50.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Not present N N
NO_SIG_EXTN
Otherwise See corresponding entry in Table 19-1
2629
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is HT Indicates which FEC encoding is used. M Y
FEC_CODING
Enumerated type: U
BCC_CODING indicates binary convolutional code.
LDPC_CODING indicates low-density parity check code.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates whether STBC is used. Y Y
0 indicates no STBC (NSTS=NSS in the Data field).
STBC
1 indicates STBC is used (NSTS=2NSS in the Data field).
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates whether a short guard interval is used in the transmission Y Y
of the Data field of the PPDU.
Enumerated type:
GI_TYPE
LONG_GI indicates short GI is not used in the Data field of the
PPDU.
SHORT_GI indicates short GI is used in the Data field of the
PPDU.
Otherwise Not present N N
FORMAT is VHT The allowed values for the TXPWR_LEVEL_INDEX parameter Y N
TXPWR_LEVEL_INDEX
are in the range 1 to
numberOfOctets(dot11TxPowerLevelExtended)/2. This parameter
is used to indicate which of the available transmit output power
levels defined in dot11TxPowerLevelExtended shall be used for the
current transmission.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT The allowed values for the RSSI parameter are in the range 0 to N Y
255. This parameter is a measure by the PHY of the power observed
at the antennas used to receive the current PPDU measured during
RSSI
the reception of the TVHT-LTF field. RSSI is intended to be used in
a relative manner, and it is a monotonically increasing function of
the received power.
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates the modulation and coding scheme used in the M Y
transmission of the PPDU. U
MCS
Integer: range 0 to 9
Otherwise See corresponding entry in Table 19-1
FORMAT is VHT Indicates the MCS that the STA’s receiver recommends. N O
REC_MCS
Otherwise Not present N N
2630
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT Indicates the channel width of the transmitted PPDU: Y Y
Enumerated type:
TVHT_W for one BCU
TVHT_2W for two contiguous BCUs
TVHT_W+W for two noncontiguous BCUs
CH_BANDWIDTH
TVHT_4W for four contiguous BCUs
TVHT_2W+2W for two noncontiguous frequency segments, each
of which comprises two contiguous BCUs
FORMAT is NON_HT In TXVECTOR, indicates the channel width of the transmitted Y Y
PPDU.
In RXVECTOR, indicates the estimated channel width of the
received PPDU.
Enumerated type:
TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, TVHT_2W+2W
if NON_HT_MODULATION equals NON_HT_DUP_OFDM
FORMAT is NON_HT In TXVECTOR, if present, indicates whether the transmitter is O Y
DYN_BANDWIDTH_IN_NON_HT
capable of Static or Dynamic bandwidth operation.
In RXVECTOR, if valid, indicates whether the transmitter is
capable of Static or Dynamic bandwidth operation.
Enumerated type:
Static if the transmitter is capable of Static bandwidth operation
Dynamic if the transmitter is capable of Dynamic bandwidth
operation
NOTE—In the RXVECTOR, the validity of this parameter is
determined by the MAC based on the contents of the received
MPDU.
Otherwise Not present N N
FORMAT is NON_HT In TXVECTOR, if present, indicates the channel width of the O Y
CH_BANDWIDTH_IN_NON_HT
transmitted PPDU, which is signaled via the scrambling sequence.
In RXVECTOR, if valid, indicates the channel width of the
received PPDU, which is signaled via the scrambling sequence.
Enumerated type:
TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W,
TVHT_2W+2W.
NOTE—In the RXVECTOR, the validity of this parameter is
determined by the MAC based on the contents of the received
MPDU.
Otherwise Not present N N
FORMAT is VHT If equal to 0, indicates a TVHT NDP PPDU for both RXVECTOR M O
and TXVECTOR. U
APEP_LENGTH
If greater than zero, in the TXVECTOR, indicates the number of
octets in the range 1 to 1 048 575 in the A-MPDU pre-EOF padding
(see 10.13.2) carried in the PSDU.
If greater than zero, in the RXVECTOR, is the value obtained from
the VHT-SIG-B Length field multiplied by 4.
Otherwise Not present N N
2631
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT Indicates the number of octets in the VHT PSDU in the range 0 to N Y
PSDU_LENGTH
1 065 600 octets. A value of 0 indicates a VHT NDP PPDU.
Otherwise Not present N N
FORMAT is VHT and Index for user in MU transmission. Integer: range 0 to 3. M O
USER_POSITION
1 ≤ GROUP_ID ≤ 62 NOTE—The entries in the USER_POSITION array are in U
ascending order.
Otherwise Not present N N
FORMAT is VHT Indicates the number of space-time streams. M Y
NUM_STS
Integer: range 1 to 4 for SU, 1 to 3 per user in the TXVECTOR, and U
0 to 4 in the RXVECTOR for MU.
NUM_STS summed over all users is between 1 and 4.
Otherwise Not present N N
FORMAT is VHT Indicates the group ID. Y Y
GROUP_ID
Integer: range 0 to 63 (see Table 22-12)
A value of 0 or 63 indicates a VHT SU PPDU. A value in the range
1 to 62 indicates a VHT MU PPDU.
Otherwise Not present N N
FORMAT is VHT and Provides an abbreviated indication of the intended recipient(s) of Y Y
PARTIAL_AID
GROUP_ID is 0 or 63 the PSDU (see 9.1710.20).
Integer: range 0 to 511.
Otherwise Not present N N
FORMAT is VHT Indicates the number of users with nonzero space-time streams. Y N
NUM_USERS
Integer: range 1 to 4.
Otherwise Not present N N
FORMAT is VHT and Set to 1 if a beamforming steering matrix is applied to the Y O
BEAMFORMED
GROUP_ID is 0 or 63 waveform in an SU transmission. Set to 0 otherwise.
NOTE—When BEAMFORMED is set to 1, smoothing is not
recommended.
Otherwise Not present N N
2632
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-1—TXVECTOR and RXVECTOR parameters (continued)
RXVECTOR
TXVECTOR
Parameter
Condition Value
FORMAT is VHT Indicates whether a TVHT AP allows non-AP TVHT STAs in Y Y
TXOP_PS_NOT_ALLOWED
TXOP power save mode to enter doze state during the TXOP.
0 indicates that the TVHT AP allows non-AP TVHT STAs to enter
doze state during a TXOP.
1 indicates that the TVHT AP does not allow non-AP TVHT STAs
to enter doze state during a TXOP.
Otherwise Not present N N
Boolean value: O N
TIME_OF_DEPARTURE_REQUESTED
true indicates that the MAC entity requests that the PHY entity
measures and reports time of departure parameters corresponding to
the time when the first PPDU energy is sent by the transmitting
port.
false indicates that the MAC entity requests that the PHY entity
neither measures nor reports time of departure parameters.
dot11TimingMsmtActi 0 to 232– 1. An estimate of the offset (in 10 ns units) from the point N Y
RX_START_OF_FRAME_OFFSET
vated is true in time at which the start of the preamble corresponding to the
incoming frame arrived at the receive antenna connector to the
point in time at which this primitive is issued to the MAC.
Otherwise Not present N N
NOTE 1—In the “TXVECTOR” and “RXVECTOR” columns, the following apply:
Y = Present;
N = Not present;
O = Optional;
MU indicates that the parameter is present once for a VHT SU PPDU and present per user for a VHT MU
PPDU. Parameters specified to be present per user are conceptually supplied as an array of values indexed by u,
where u takes values 0 to NUM_USERS – 1.
NOTE 2—On reception, where valid, the CH_BANDWIDTH_IN_NON_HT parameter is likely to be a more reliable
indication of subformat and channel width than the NON_HT_MODULATION and CH_BANDWIDTH parameters,
since for non-HT or non-HT duplicate frames, CH_BANDWIDTH is a receiver estimate of the bandwidth, whereas
CH_BANDWIDTH_IN_NON_HT is the signaled bandwidth.
2633
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.2.3 Effects of CH_BANDWIDTH parameter on PPDU format
Table 22-2 shows the PPDU format as a function of the CH_BANDWIDTH and FORMAT parameters.
Table 22-2—PPDU format as a function of CH_BANDWIDTH parameter
FORMAT CH_BANDWIDTH PPDU format
VHT TVHT_W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is
VHT) with TVHT_MODE_1.
VHT TVHT_2W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is
VHT) with TVHT_MODE_2C.
VHT TVHT_4W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is
VHT) with TVHT_MODE_4C.
VHT TVHT_W+W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is
VHT) with TVHT_MODE_2N.
VHT TVHT_2W+2W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is
VHT) with TVHT_MODE_4N.
NON_HT TVHT_W The STA transmits a NON_HT PPDU with
NON_HT_MODULATION set to NON_HT_DUP_OFDM using one
TVHT_W channel as defined in 22.3.10.12. If the BSS bandwidth is
wider than TVHT_W, then the transmission shall use the primary
TVHT_W channel.
NON_HT TVHT_2W The STA transmits a NON_HT PPDU with
NON_HT_MODULATION set to NON_HT_DUP_OFDM using two
adjacent TVHT_W channels as defined in 22.3.10.12. If the BSS
bandwidth is wider than TVHT_2W, then the transmission shall use
the primary TVHT_2W channel.
NON_HT TVHT_4W The STA transmits a NON_HT PPDU with
NON_HT_MODULATION set to NON_HT_DUP_OFDM using
four adjacent TVHT_W channels as defined in 22.3.10.12.
NON_HT TVHT_W+W The STA transmits a NON_HT PPDU with
NON_HT_MODULATION set to NON_HT_DUP_OFDM using two
nonadjacent frequency segments, with each frequency segment
consisting of single TVHT_W channels as defined in 22.3.10.12.
NON_HT TVHT_2W+2W The STA transmits a NON_HT PPDU with
NON_HT_MODULATION set to NON_HT_DUP_OFDM using two
nonadjacent frequency segments, with each frequency segment
consisting of two adjacent TVHT_W channels as defined in
22.3.10.12.
22.2.4 Support for NON_HT and HT formats
Transmission of HT PPDUs is not supported in Clause 22. Except for Non-HT duplicate transmission
defined in 22.3.10.12, transmission of NON_HT is not supported in Clause 22.
Non-HT duplicate transmission is based on Clause 17, unless otherwise stated in Clause 22.
Non-HT PPDU format is same as in Figure 17-1. Overview of the PPDU encoding process is defined in
17.3.2.2 except for following modifications:
2634
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Modulation-dependent parameters for Non-HT duplicate mode in TVWS band is defined in Table 22-3.
Timing related parameters are defined in Table 22-5. tSIGNAL in Equation (17-2) is equal to 16 multiplied by
X µs, and tDATA in Equation (17-2) is equal to 20 multiplied by X µs where X is 7.5 for 6 MHz and 7 MHz
unit channels and X is 5.625 for 8 MHz channels.
Table 22-3—Modulation-dependent parameters for Non-HT duplicate mode in TVWS band
Coded Data
Coded Data rate
Coding bits per bits per
bits per (Mb/s)
Modulation rate OFDM OFDM
subcarrier (TVWS
(R) symbol symbol
(NBPSC) band)
(NCBPS) (NDBPS)
BPSK 1/2 1 48 24 6/X (see NOTE)
BPSK 3/4 1 48 36 9/X (see NOTE)
QPSK 1/2 2 96 48 12/X (see NOTE)
QPSK 3/4 2 96 72 18/X (see NOTE)
16-QAM 1/2 4 192 96 24/X (see NOTE)
16-QAM 3/4 4 192 144 36/X (see NOTE)
64-QAM 2/3 6 288 192 48/X (see NOTE)
64-QAM 3/4 6 288 216 54/X (see NOTE)
NOTE—In TVWS band, X depends on regulatory domain, i.e., 7.5 for 6 MHz and 7 MHz unit channels
and 5.625 for 8 MHz channels.
The timings for preamble are multiplied by X where X is 7.5 for 6 MHz and 7 MHz unit channels and X is
5.625 for 8 MHz channels.
Constructions of L-STF, L-LTF, and L-SIG are same as in 22.3.4.2, 22.3.4.3, and 22.3.4.4 except for the
value field parameters in L-SIG.
Interpretation of the bits R1-R4 in the SIGNAL field is modified as in Table 22-4.
Table 22-4—RATE field in L-SIG
R1-R4 Modulation Coding rate
1101 BPSK 1/2
1111 BPSK 3/4
0101 QPSK 1/2
0111 QPSK 3/4
1001 16-QAM 1/2
1011 16-QAM 3/4
0001 64-QAM 2/3
0011 64-QAM 3/4
2635
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-5 and Table 22-6 define the timing-related parameters for Non-HT format and location of occupied
tones.
Table 22-5—Timing-related constants in Non-HT PPDU
Parameter 6 MHz 7 MHz 8 MHz Description
NSD 96 96 96 Number of complex data
numbers per BCU
NSP 8 8 8 Number of pilot values per BCU
NST 104 104 104 Total number of subcarriers per
BCU
NSR 58 58 58 Highest data subcarrier index per
BCU
6 MHz 2 7 MHz 2 8 MHz 5
∆F ----------------- = 41 --- kHz ----------------- = 41 --- kHz ----------------- = 55 --- kHz Subcarrier frequency spacing
144 3 168 3 144 9
TDFT 24 µs 24 µs 18 µs IDFT/DFT period
TGI 6 µs = TDFT /4 6 µs = TDFT /4 4.5 µs = TDFT /4 Guard interval duration
TGIS 3 µs = TDFT /8 3 µs = TDFT /8 2.25 µs = TDFT /8 Short guard interval duration
Other timing parameters are derived as in Table 17-5 using the definition of TFFT in Table 22-5. Table 22-6
defines the number of occupied tones and their location in all transmission modes. Zero denotes the DC tone
of any contiguous segment.
Refer to Table 21-6 for parameters definition. The definitions in the table are applicable to Clause 22 with
the exception that in each transmission mode in Clause 22 NCBPSSI = NCBPSS for SU and MU PPDUs.
22.3 TVHT PHY sublayer
22.3.1 Introduction
See 21.3.1.
22.3.2 VHT PPDU format in TVWS bands
A single PPDU format is defined for this PHY: the VHT PPDU format in TVWS bands. Figure 22-1 shows
the VHT PPDU format in TVWS bands, with the timing parameters (8 µs and 4 µs) in Figure 21-4 replaced
by numbers from Table 22-8.
60 μs 60 μs 30 μs 60 μs 30 μs 30 μs pe r TVHT-LTF symbo l 30 μs for 6 and 7 MHz ch annels
45 μs 45 μs 22.5 μs 45 μs 22.5 μs 22.5 μs pe r TVHT-LTF symbo l 22.5 μs for 8 MHz ch annels
TVHT TVHT-
L-STF L-LTF L-SIG TVHT-SIG-A TVHT-LTF Data
-STF SIG-B
Figure 22-1—VHT PPDU format in TVWS bands
The fields of the VHT PPDU format in TVWS bands are summarized in Table 22-7.
2636
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-6—Tone location in Non-HT PPDU
TVHT_ TVHT_ TVHT_ TVHT_ TVHT_
Parameter Description
MODE_1 MODE_2C MODE_2N MODE_4C MODE_4N
NST 104 104 104 104 104 Total number of
occupied
subcarriers per
BCU
NTT 104 208 208 416 416 Total number of
occupied
subcarriers across
all BCUs
Subcarrier –58 to –33, –130 to –105, –58 to –33, –274 to –249, –130 to –105, Location of
index –31 to –6, –103 to –78, –31 to –6, –247 to –222, –103 to –78, occupied
+6 to +31, –66 to –41, +6 to +31, –210 to –185, –66 to –41, subcarriers for
and +33 to –39 to –14, and +33 to –183 to –158, –39 to –14, 6 MHz and 8 MHz
+58 +14 to +39, +58 for each –130 to –105, +14 to +39, channel units
+41 to +66, BCU –103 to –78, +41 to +66,
+78 to +103, –66 to –41, +78 to +103,
and +105 to –39 to –14, and +105 to
+130 +14 to +39, +130 for each
+41 to +66, BCU
+78 to +103,
+105 to +130,
+158 to +183,
+185 to +210,
+222 to +247,
and +249 to
+274
Subcarrier –58 to –33, –142 to –117, –58 to –33, –310 to –285, –142 to Location of
index –31 to –6, –115 to –90, –31 to –6, –283 to –258, –117, –115 to occupied
+6 to +31, –78 to –53, +6 to +31, –246 to –221, –90, –78 to subcarriers for
and +33 to –51 to –26, and +33 to –219 to –194, –53, –51 to 7 MHz
+58 +26 to +51, +58 for each –142 to –117, –26, +26 to
+53 to +78, BCU –115 to –90, +51, +53 to
+90 to +115, –78 to –53, +78, +90 to
and +117 to –51 to –26, +115, and
+142 +26 to +51, +117 to +142
+53 to +78, for each BCU
+90 to +115,
+117 to +142,
+194 to +219,
+221 to +246,
+258 to +283,
and +285 to
+310
The TVHT-SIG-A, TVHT-STF, TVHT-LTF, and TVHT-SIG-B fields exist only in VHT PPDU in TVWS
bands. In a TVHT NDP, the Data field is not present. The number of symbols in the TVHT-LTF field,
NTVHTLTF, can be 1, 2, or 4 and is determined by the total number of space-time streams across all users
being transmitted in the VHT PPDU in TVWS bands (see Table 21-13).
22.3.3 Transmitter block diagram
The transmit process for the L-SIG and TVHT-SIG-A fields of a VHT PPDU using one BCU is shown in
Figure 21-5, with “TVHT” replacing “VHT” and with bandwidth corrected according to TVHT bandwidth.
2637
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-7—Fields of the VHT PPDU in TVWS bands
Field Description
L-STF Non-HT Short Training field
L-LTF Non-HT Long Training field
L-SIG Non-HT SIGNAL field
TVHT-SIG-A TVHT Signal A field
TVHT-STF TVHT Short Training field
TVHT-LTF TVHT Long Training field
TVHT-SIG-B TVHT Signal B field
Data The Data field includes the PSDU
The transmit process for generating the TVHT-SIG-B field of a VHT SU PPDU and VHT MU PPDU using
one frequency segment is shown in Figure 21-5 and Figure 21-7, respectively, with “TVHT” replacing
“VHT” and with bandwidth corrected according to TVHT bandwidth.
The transmit process for generating the Data field of a SU PPDU in TVHT_MODE_1, TVHT_MODE_2C,
or TVHT_MODE_4C with BCC and LDPC encodings, using one BCU, is shown Figure 21-10 and
Figure 21-11, respectively, with “TVHT” replacing “VHT” and with bandwidth corrected according to
TVHT bandwidth. Single BCC encoder shall be assumed in Figure 21-10.
The transmit process for generating the Data field of a MU PPDU in TVHT_MODE_1, TVHT_MODE_2C,
or TVHT_MODE_4C with BCC and LDPC encoding is shown in Figure 21-12, with “TVHT” replacing
“VHT” and with bandwidth corrected according to TVHT bandwidth. In the case of BCC encoding, single
BCC encoder shall be assumed in Figure 21-12.
Figure 22-2 and Figure 22-3 show the transmit process for generating the Data field of a TVHT_MODE_2N
or TVHT_MODE_4N SU PPDU with BCC and LDPC encoding, respectively, where the subcarrier
allocation block allocates the subcarriers for the two IDFTs in each transmit path by the subcarrier mapper as
described in 22.3.10.11.
22.3.4 Overview of the PPDU encoding process
22.3.4.1 General
This subclause provides an overview of the VHT PPDU in TVWS bands encoding process.
22.3.4.2 Construction of L-STF
Construct the L-STF field as defined in 22.3.8.2.2 following the procedure in 21.3.4.2 reading “Clause 22”
for references to “Clause 21” except the following:
c) Duplication and phase rotation: Duplicate the L-STF over the BCUs of the CH_BANDWIDTH.
Apply appropriate phase rotation as defined in 22.3.7.
2638
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Subcarrier
Allocation
BCC Constellation
Interleaver mapper
Spatial Mapping
Stream Parser
PHY Padding
BCC Encoder
Scrambler
STBC
Subcarrier
Allocation
CSD
BCC Constellation
per STS
Interleaver mapper
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Figure 22-2—Transmitter block diagram for the Data field of a TVHT_MODE_2N or TVHT_-
MODE_4N SU PPDU with BCC encoding
22.3.4.3 Construction of the L-LTF
Construct the L-LTF field as defined in L-LTF definition following the procedure in 21.3.4.3 reading
“Clause 22” for references to “Clause 21” except the following:
c) Duplication and phase rotation: Duplicate the L-LTF over the BCUs of the CH_BANDWIDTH.
Apply appropriate phase rotation as defined in 22.3.7.
22.3.4.4 Construction of L-SIG
Construct the L-SIG field as the SIGNAL field defined by 22.3.8.2.4 following the procedure in 21.3.4.4
reading “Clause 22” for references to “Clause 21” except the following:
a) For a VHT PPDU in TVWS bands, set the RATE subfield in the SIGNAL field R1-R4 to 1101. Set
the Length, Parity, and Tail bits in the SIGNAL field as defined in 22.3.8.2.4. Add calculated one bit
parity and Ntail bits into the L-SIG symbol.
f) Duplication and phase rotation: Duplicate the L-SIG field over the BCUs of the
CH_BANDWIDTH. Apply appropriate phase rotation as defined in 22.3.7.
2639
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Subcarrier
Allocation
Constellation LDPC Tone
mapper Mapper
LDPC Encoder
PHY Padding
Spatial Mapping
Scrambler
Stream Parser
STBC
Subcarrier
Allocation
CSD
Constellation LDPC Tone per STS
mapper Mapper
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Insert GI
Analog
and IDFT
and RF
Window
Figure 22-3—Transmitter block diagram for the Data field of a TVHT_MODE_2N or
TVHT_MODE_4N SU PPDU with LDPC encoding
22.3.4.5 Construction of TVHT-SIG-A
The TVHT-SIG-A field consists of two symbols, TVHT-SIG-A1 and TVHT-SIG-A2, constructed as defined
in 22.3.8.3.3 following the procedure in 21.3.4.5 reading “Clause 22” for references to “Clause 21” except
the following:
e) Pilot insertion: Insert pilots following the steps defined in 22.3.10.10.
f) Duplication and phase rotation: Duplicate TVHT-SIG-A1 and TVHT-SIG-A2 over of the BCUs of
the CH_BANDWIDTH. Apply the appropriate phase rotation as defined in 22.3.7.
i) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as defined in
22.3.7.
22.3.4.6 Construction of TVHT-STF
Construct the TVHT-STF field for each BCU as defined in 22.3.8.3.4 with channel bandwidth being 40
MHz, following the procedure in 21.3.4.6 reading “Clause 22” for references to “Clause 21” except the
following:
b) Phase rotation: Apply appropriate phase rotation as defined in 22.3.7.
f) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as defined in
22.3.7.
2640
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In multiple BCU transmissions TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and
TVHT_MODE_4N, the TVHT-STF subcarriers of one BCU are repeated in each BCU with an appropriate
phase rotation factor being applied as described in 22.3.8.3.4.
22.3.4.7 Construction of TVHT-LTF
Construct the TVHT-LTF field for each BCU as defined in 22.3.8.3.5 with channel bandwidth being 40
MHz, following the procedure in 21.3.4.7 reading “Clause 22” for references to “Clause 21” except the
following:
b) Phase rotation: Apply appropriate phase rotation as defined in 22.3.7.
g) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as defined in
22.3.7.
In multiple BCU transmissions TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and
TVHT_MODE_4N, the TVHT-LTF subcarriers of one BCU are repeated in each BCU with an appropriate
phase rotation factor being applied as described in 22.3.8.3.5.
22.3.4.8 Construction of TVHT-SIG-B
The TVHT-SIG-B field is constructed per-user for each BCU as defined in 21.3.4.8 with channel bandwidth
being 40 MHz, reading “Clause 22” for references to “Clause 21” except the following:
i) Pilot insertion: Insert pilots following the steps defined in 22.3.10.10.
m) Phase rotation: Apply the appropriate phase rotations as defined in 22.3.7.
o) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as defined in
22.3.7.
In multiple BCU transmissions TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and
TVHT_MODE_4N, the TVHT-SIG-B subcarriers of one BCU are repeated in each BCU with an
appropriate phase rotation factor being applied as described in 22.3.8.3.6.
22.3.4.9 Construction of the Data field in an SU PPDU
22.3.4.9.1 Using BCC
The construction of the Data field in a VHT SU PPDU with BCC encoding proceeds as defined in 21.3.4.9.1
reading “Clause 22” for references to “Clause 21” except the following:
d) BCC encoder: Only one encoder is used.
f) Segment parser is omitted.
i) Segment deparser is omitted.
l) CSD: Apply CSD for each space-time stream and frequency segment as described in 22.3.8.3.2.
n) Phase rotation: Apply the appropriate phase rotations as defined in 22.3.7.
o) IDFT: When in TVHT_MODE_2N or VHT_MODE_4N, allocate the subcarriers for the two IDFTs
in each transmit path as described in 22.3.10.11.
p) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as
defined in 22.3.7.
2641
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.3.4.9.2 Using LDPC
The construction of the Data field in a VHT SU PPDU with LDPC encoding proceeds as defined in
21.3.4.9.2 reading “Clause 22” for references to “Clause 21” except the following:
f) Segment parser is omitted.
i) Segment deparser is omitted.
l) CSD: Apply CSD for each space-time stream and frequency segment as described in 22.3.8.3.2.
n) Phase rotation: Apply the appropriate phase rotations as defined in 22.3.7. When in TVHT_-
MODE_2N or VHT_MODE_4N, allocate the subcarriers for the two IDFTs in each transmit path as
described in 21.3.10.11.1.
o) IDFT: When in TVHT_MODE_2N or VHT_MODE_4N, allocate the subcarriers for the two IDFTs
in each transmit path as described in 22.3.10.11.
p) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as
defined in 22.3.7.
22.3.4.10 Construction of the Data field in an MU PPDU
22.3.4.10.1 General
See 21.3.4.10.1.
22.3.4.10.2 Using BCC
A Data field with BCC encoding is constructed using the process defined in 22.3.4.9.1 before the spatial
mapping block and repeated for each user that uses BCC encoding.
22.3.4.10.3 Using LDPC
A Data field with LDPC encoding is constructed using the process defined in 22.3.4.9.2 before the spatial
mapping block and repeated for each user that uses LDPC encoding.
22.3.4.10.4 Combining to form an MU PPDU
The per-user data is combined as defined in 21.3.4.10.4 except the following:
a) Spatial mapping: The Q matrix is applied as defined in 22.3.10.11. The combining of all user data is
done in this block.
b) Phase rotation: Apply the appropriate phase rotations as defined in 22.3.7.
d) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as
defined in 22.3.7.
e) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit
chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to
22.3.7 and 22.3.8 for details.
22.3.5 Modulation and coding scheme (MCS)
The MCS is a value that determines the modulation and coding used in the Data field of the PPDU. It is a
compact representation that is carried in the TVHT-SIG-A field for SU PPDUs and in the TVHT-SIG-B field
for MU PPDUs. Rate-dependent parameters for the full set of MCSs are shown in Table 22-26 to Table 22-
37 (in 22.5). These tables give rate-dependent parameters for MCSs with indices 0 to 9, with number of
spatial streams from 1 to 4 and bandwidth options of one, two, or four BCUs. Equal modulation (EQM) is
applied to all streams for a particular user.
2642
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-26 to Table 22-29 show rate-dependent parameters for MCSs for one to four streams for one BCU
operation. Table 22-30 to Table 22-33 show rate-dependent parameters for MCSs for one to four streams for
dual BCU operation. Table 22-34 to Table 22-37 show rate-dependent parameters for MCSs for one to four
streams for quad BCU operation.
22.3.6 Timing-related parameters
Table 22-8 and Table 22-9 define the timing-related parameters for VHT format and location of occupied
tones in TVWS bands.
Table 22-8—Timing-related parameters
Parameter 6 MHz 7 MHz 8 MHz Description
NSD 108 108 108 Number of complex data
numbers per BCU
NSP 6 6 6 Number of pilot values per BCU
NST 114 114 114 Total number of subcarriers per
BCU
NSR 58 58 58 Highest data subcarrier index per
BCU
6 MHz 2 7 MHz 2 8 MHz 5
∆F ----------------- = 41 --- kHz ----------------- = 41 --- kHz ----------------- = 55 --- kHz Subcarrier frequency spacing
144 3 168 3 144 9
TDFT 24 µs 24 µs 18 µs IDFT/DFT period
TGI 6 µs = TDFT /4 6 µs = TDFT /4 4.5 µs = TDFT /4 Guard interval duration
The rest of the timing parameters are derived as in Table 21-5 using the definition of TDFT in Table 22-8.
Table 22-9 defines the number of occupied tones and their location in all transmission modes. Zero denotes
the DC tone of any contiguous segment.
Table 22-9—Tone location
TVHT_ TVHT_ TVHT_ TVHT_ TVHT_
Parameter Description
MODE_1 MODE_2C MODE_2N MODE_4C MODE_4N
NST 114 114 114 114 114 Total number of
occupied
subcarriers per
BCU
NTT 114 228 228 456 456 Total number of
occupied
subcarriers across
all BCUs
2643
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-9—Tone location (continued)
TVHT_ TVHT_ TVHT_ TVHT_ TVHT_
Parameter Description
MODE_1 MODE_2C MODE_2N MODE_4C MODE_4N
Subcarrier –58 to –2 –130 to –74, –58 to –2 –274 to –218, –130 to –74, Location of
index and +2 to –70 to –14, and +2 to –214 to –158, –70 to –14, occupied
+58 +14 to +70, +58 for each –130 to –74, +14 to +70, subcarriers for
and +74 to BCU –70 to –14, and +74 to 6 MHz and 8 MHz
+130 +14 to +70, +130 for channel units
+74 to +130, each BCU
+158 to +214,
and +218 to
+274
Subcarrier –58 to –2 –142 to –86, –58 to –2 –310 to –254, –142 to –86, Location of
index and +2 to –82 to –26, and +2 to –250 to –194, –82 to –26, occupied
+58 +26 to +82, +58 for each –142 to –86, +26 to +82, subcarriers for
and +86 to BCU –82 to –26, and +86 to 7 MHz
+142 +26 to +82, +142 for
+86 to +142, each BCU
+194 to +250,
and +254 to
+310
Refer to Table 21-6 for the frequency parameters. The definitions in the table are applicable to Clause 22
with the exception that in each transmission mode in Clause 22 NCBPSSI = NCBPSS for SU and MU PPDUs.
22.3.7 Mathematical description of signals
For a description of the conventions used for the mathematical description of the signals, see 17.3.2.5.
For all VHT PPDU in TVWS bands transmission modes the signal is transmitted on subcarriers as defined in
Table 22-9.
Let
fc idx0 = dot11CurrentTVHTChannelCenterFrequencyIndex0 (see Table 22-17)
fc idx1 = dot11CurrentTVHTChannelCenterFrequencyIndex1 (see Table 22-17)
f PW idx = dot11CurrentPrimaryChannel (see Table 22-17), where TVHT_W refers to a BCU of
6 MHz, 7 MHz, or 8 MHz
f CH start = Channel starting frequency given in the operation class (E.1)
When dot11CurrentTVHTChannelWidth is TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, or
TVHT_2W+2W, fPW,idx and fc,idx1 shall have the relationship specified in Equation (22-1).
f PW idx = fc idx0 + n PW (22-1)
where
1 in TVHT_W and TVHT_W+W
N PW = 2 in TVHT_2W and TVHT_2W+2W
4 in TVHT_4W
n PW is an integer with possible range 0 n PW N PW – 1
2644
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When dot11CurrentTVHTChannelWidth is TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, or
TVHT_2W+2W,
— The primary TVHT_W channel is the channel with TVHT_W bandwidth centered at
f CH start + TVHT_W f PW idx , where f PW idx is given in Equation (22-1).
When dot11CurrentTVHTChannelWidth is TVHT_2W, TVHT_4W, or TVHT_2W+2W,
— The secondary TVHT_W channel is the channel with TVHT_W bandwidth centered at
f CH start + TVHT_W f S W idx , where f SW idx is given in Equation (22-2).
f PW idx +1 if n PW is even
f SW idx = (22-2)
f PW idx –1 if n PW is odd
When dot11CurrentTVHTChannelWidth is TVHT_W+W,
— The secondary TVHT_W channel is the channel with TVHT_W bandwidth centered at
f CH start + TVHT_W f S W idx , where f SW idx is given in Equation (22-3).
f SW idx = fc idx1 (22-3)
When dot11CurrentTVHTChannelWidth is TVHT_2W, TVHT_4W, or TVHT_2W+2W,
— The primary TVHT_2W channel is the channel with TVHT_2W bandwidth centered at
f CH start + TVHT_W f P2W idx + 0.5 TVHT_W MHz, where f P2W idx is given in Equation (22-4).
— The secondary TVHT_2W channel is the channel with TVHT_2W bandwidth centered at
f CH start + TVHT_W f S 2 W idx + 0.5 TVHT_W MHz, where f S 2 W idx is given in Equation (22-5).
1 in TVHT_2W and TVHT_2W+2W
f P2W idx = fc idx0 +2 n P2W 0 n P2W NP 2 W – 1 NP 2 W = (22-4)
2 in TVHT_4W
When dot11CurrentTVHTChannelWidth is TVHT_4W,
— The secondary TVHT_2W channel is the channel with TVHT_2W bandwidth centered at
f CH start + TVHT_W f S 2 W idx + 0.5 TVHT_W MHz, where f S 2 W idx is given in Equation (22-5).
f P2W idx +2 if n P2W is even
f S2W idx = (22-5)
f P2W idx –2 if n P2W is odd
When dot11CurrentTVHTChannelWidth is TVHT_2W+2W,
— The secondary TVHT_2W channel is the channel with TVHT_2W bandwidth centered at
f CH start + TVHT_W f S 2 W idx + 0.5 TVHT_W MHz, where f S 2 W idx is given in Equation (22-3).
The transmitted signal is defined in complex baseband signal notation. The actual transmitted signal is
related to the complex baseband signal by the relation shown in Equation (21-11) in Clause 21.
i
f c Seg represents the center frequency of the PPDU transmitted in frequency segment i Seg in each
transmission mode in Clause 22.
Note that in TVHT_MODE_2C and TVHT_MODE_4C, the gap between the center frequencies of the
adjacent segments is as shown in Table 22-9.
2645
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-10 shows f ciSeg as a function of dot11CurrentTVHTChannelWidth.
Table 22-10—Center frequency of a PPDU transmitted in
frequency segment iSeg
f ciSeg = f CH start + TVHT_W f i Seg + Correction
dot11CurrentTVHTCh
CH_BANDWIDTH
annelWidth
(f 0 ,Correction) (f 1 ,Correction)
TVHT_W TVHT_W (f c idx0,0) —
TVHT_2W TVHT_W (f PW idx,0) —
TVHT_2W (f c idx0,0.5 TVHT_W) —
TVHT_W+W TVHT_W (f PW idx,0)
TVHT_W+W (f c idx0,0) (f c idx1,0)
TVHT_4W TVHT_W (f PW idx,0) —
TVHT_2W (f P2W idx,0.5 TVHT_W) —
TVHT_4W (f c idx0,1.5 TVHT_W) —
TVHT_2W+2W TVHT_W (f c idx0,0)
TVHT_2W (f c idx0,0.5 TVHT_W)
TVHT_2W+2W (f c idx0,0.5 TVHT_W) (f c idx1,0.5 TVHT_W)
NOTE—Transmitted signals in TVHT_MODE_2N and TVHT_MODE_4N might have different impairments such as
phase offset or phase noise between the two frequency segments in TVHT_MODE_2N or TVHT_MODE_4N, which is
not shown in Equation (21-11) for simplicity. See 22.3.17.3.
The transmitted RF signal is derived by upconverting the complex baseband signal, which consists of
several fields. The signal transmitted on frequency segment i Seg of transmit chain i TX is described by
Equation (21-12) in 21.3.7. The timing boundaries for the various fields are shown in Figure 21-17.
Each field is defined as the summation of one or more subfields, where each subfield is defined to be an
inverse discrete Fourier transform as specified in Equation (21-13) and where references to Table 21-5,
Table 21-6, Table 21-8, Table 22-9, Table 21-10, and Table 21-11 are replaced by the corresponding
descriptions in Clause 22 including Table 22-8, Table 22-9, Table 22-11, and Table 22-12.
Tone
Table 22-11 summarizes the various values of N Field as a function of number of BCUs (TVHT_MODE_1
has one BCU, TVHT_MODE_2C and TVHT_MODE_2N have two BCUs, and TVHT_MODE_4C and
TVHT_MODE_4N have four BCUs).
2646
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-11—Tone scaling factor and guard interval duration values for PHY fields
Tone
N Field as a function of the number
of BCUs Guard interval
Field
duration
One Two Four
L-STF 24 48 96 —
L-LTF 104 208 416 TGI2
L-SIG 104 208 416 TGI
TVHT-SIG-A 104 208 416 TGI
TVHT-STF 24 48 96 -
TVHT-LTF 114 228 456 TGI
TVHT-SIG- 114 228 456 TGI
VHT-Data 114 228 484 TGI or TGIS
(see NOTE 2)
NON_HT_DUP_OFDM-Data (see NOTE 1) 104 208 416 TGI
NOTE 1—For notational convenience, NON_HT_DUP_OFDM-Data is used as a label for the Data field of a
NON_HT PPDU with format type NON_HT_DUP_OFDM.
NOTE 2—TGI denotes guard interval duration when TXVECTOR parameter GI_TYPE equals LONG_GI,
TGIS denotes short guard interval duration when TXVECTOR parameter GI_TYPE equals SHORT_GI.
In addition, the parameter k BW in Equation (21-13) is replaced by k M as defined in Table 22-12.
Table 22-12—Transmission mode and Gamma subk,M
Transmission mode k M
TVHT_MODE_1, k 1 per segment
TVHT_MODE_2N
TVHT_MODE_2C, k 2 per two contiguous segments
TVHT_MODE_4N
TVHT_MODE_4C k 4
For TVHT_MODE_1 and TVHT_MODE_2N PPDU transmission,
1 k 0
k 1 = (22-6)
j k 0
For TVHT_MODE_2C and TVHT_MODE_4N PPDU transmission,
1 k – 72 for 6 MHz and 8 MHz channels, k – 84 for 7 MHz channels
k 2 = (22-7)
–1 k – 72 for 6 MHz and 8 MHz channels, k – 84 for 7 MHz channels
2647
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For TVHT_MODE_4C PPDU transmission,
1 k – 216 for 6 MHz and 8 MHz channels, k – 252 for 7 MHz channels
–1 – 216 k 0 for 6 MHz and 8 MHz channels, – 252 k 0 for 7 MHz channels
k 4 = (22-8)
1 0 k 72 for 6 MHz and 8 MHz channels, 0 k 84 for 7 MHz channels
–1 k 72 for 6 MHz and 8 MHz channels, k 84 for 7 MHz channels
22.3.8 TVHT preamble
22.3.8.1 Introduction
A TVHT preamble is defined to carry the required information to operate in either single user or multi-user
mode.
22.3.8.2 Non-TVHT portion of TVHT format preamble
22.3.8.2.1 Cyclic shift definition for pre-TVHT modulated fields
i TX
The cyclic shift value T CS for the L-STF, L-LTF, L-SIG, and TVHT-SIG-A fields of the PPDU for transmit
chain i TX out of a total of N TX is defined in Table 21-10 with a scaling factor to account for the change in
sampling clock frequency. The CSD delay values shall be multiplied by the corresponding correction values
for the 6 MHz, 7 MHz, and 8 MHz channels, respectively.
The scaling factor for transmissions over 6 MHz and 7 MHz channels is 7.5.
The scaling factor for transmissions over 8 MHz channels is 5.625.
As an example, the CSD value for antenna-2 with 2-transmit antennas is –200 ns, and the corresponding
CSD value for 6 MHz channels is –1.5 µs.
22.3.8.2.2 L-STF definition
The L-STF field for each BCU in any transmission mode is defined by Equation (19-9) in 19.3.9.3.3.
The time domain representation of the signal on BCU i Seg in transmit chain i TX is specified in
Equation (21-20), where k BW is replaced by k M as defined in Table 22-12 and where N SR and ∆F are
defined in Table 22-8.
22.3.8.2.3 L-LTF definition
The L-LTF field for each BCU in any transmission mode is defined by Equation (19-12) in 19.3.9.3.4.
Note that these equations do not include the phase rotations as defined in Table 22-12.
The time domain representation of the signal in transmit chain i TX is specified in Equation (21-23), where
k BW is replaced by k M as defined in Table 22-12 and where N SR is defined in Table 22-8.
22.3.8.2.4 L-SIG definition
The L-SIG field is used to communicate data rate and length information. The structure of the L-SIG field is
defined in Figure 17-5.
2648
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In a VHT PPDU, the RATE field shall be set to the value corresponding to 6 Mb/s in the 20 MHz channel
spacing column of Table 17-6.
In a NON_HT_DUP PPDU, the RATE field is defined in 17.3.4.2 using the L_DATARATE parameter in
the TXVECTOR.
The LENGTH field shall be set to the value given by Equation (22-9).
LENGTH = TXTIME – 20 scaling factor 4 scaling factor 3–3 (22-9)
where the scaling factor is defined in 22.3.8.2.1 and TXTIME is defined in 22.4.3. In a non-HT duplicate
PPDU, the LENGTH field is defined in 17.3.4.3 using the L_LENGTH parameter in the TXVECTOR.
The time domain waveform of the L-SIG field in each BCU is specified in Equation (21-25)
using N 20MHz = 2, where k BW is replaced by k M as defined in Table 22-12 and where the rest of the
variables are specified in 22.3.7.
22.3.8.3 TVHT portion of TVHT format preamble
22.3.8.3.1 Introduction
The TVHT portion of the VHT format preamble consists of the TVHT-SIG-A, TVHT-STF, TVHT-LTF, and
TVHT-SIG-B fields.
Notational conventions are specified in 21.3.8.3.1.
22.3.8.3.2 Cyclic shift for TVHT modulated fields
The definition, application, and CSD values are defined in 21.3.8.3.2 with scaling factors as defined in
22.3.8.2.1.
22.3.8.3.3 TVHT-SIG-A definition
The TVHT-SIG-A field carries information required to interpret VHT PPDU in TVWS bands and is defined
in 21.3.8.3.3.
The time domain waveform of the TVHT-SIG-A field in each BCU is specified in Equation (21-28), where
N 20MHz = 2 and where the rest of the variables are specified in 22.3.7.
Fields in the TVHT-SIG-A fields are the same as in Table 21-12 except for the description B0-B1 (BW) and
B10-B21 in TVHT-SIG-A1. Description of B0-B1 is specified in Table 22-13
Table 22-13—B0-B1 (BW) in TVHT-SIG-A1
B0-B1 TVHT_MODE
00 Not used
10 TVHT_MODE_1
01 TVHT_MODE_2C and TVHT_MODE_2N
11 TVHT_MODE_4C and TVHT_MODE_4N
2649
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Description of B10-B21 (NSTS/Partial AID) is specified as follows:
For an MU PPDU:
NSTS is divided into 4 user positions of 3 bits each. User position p, where
0 p uses bits B(10+3p)-B(12+3p). The number of space-time streams for
user u is indicated at user position p = USER_POSITION[u] where u = 0, 1, ...,
NUM_USER – 1 and where the notation A[b] denotes the value of array A at
index b. Zero space-time streams are indicated at positions not listed in the
USER_POSITION array.
Set to 0 for 0 space time streams
Set to 1 for 1 space time stream
Set to 2 for 2 space time streams
Set to 3 for 3 space time streams
Values 4 to 7 are reserved
For an SU PPDU:
B10-B12
Set to 0 for 1 space time stream
Set to 1 for 2 space time streams
Set to 2 for 3 space time streams
Set to 3 for 4 space time streams
Values 4 to 7 are reserved
B13-B21
Partial AID: Set to the value of the TXVECTOR parameter PARTIAL_AID.
Partial AID provides an abbreviated indication of the intended recipient(s) of the
PSDU (see 10.20).
22.3.8.3.4 TVHT-STF definition
The TVHT-STF field for each BCU in any transmission mode is defined by Equation (21-30) in 21.3.8.3.4.
The time domain waveform of the TVHT-STF field in each BCU is specified in Equation (21-33), where
k BW is replaced by k M as defined in Table 22-12 and where N SR is defined in Table 22-8.
22.3.8.3.5 TVHT-LTF definition
The TVHT-LTF field is defined in 21.3.8.3.5.
The TVHT-LTF sequence transmitted for each BCU in any transmission mode is defined by
Equation (21-37).
The time domain waveform of the TVHT-LTF field in each BCU is specified in Equation (21-42), where
k BW is replaced by k M as defined in Table 22-12 and where N SR is defined in Table 22-8.
22.3.8.3.6 TVHT-SIG-B definition
The TVHT-SIG-B field for each BCU in any transmission mode is as defined in 21.3.8.3.6 for 40 MHz
bandwidth.
The 27 TVHT-SIG-B bits are first repeated twice, then BCC encoded, interleaved, and made into
constellations as described by Figure 21-22 and the corresponding text in 21.3.8.3.6. If the channel
bandwidth of the current PPDU is TVHT_W, then the IDFT is conducted as defined in 21.3.8.3.6.
2650
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The time domain waveform for the TVHT-SIG-B field in each BCU in a VHT PPDU is the same as
Equation (21-47) with channel bandwidth being 40 MHz. If the channel bandwidth of the current PPDU is
larger than TVHT_W, then the TVHT-SIG-B subcarriers as described above are repeated in each BCU, with
appropriate phase rotation factors k M being applied as shown in Table 22-12, before conducting IDFT.
22.3.9 Transmission of NON_HT and HT PPDUs with multiple antennas
A TVHT STA that transmits a NON_HT PPDU shall apply the cyclic shifts defined in 22.3.8.2.1 for L-STF,
L-LTF, and L-SIG fields of the PPDU.
22.3.10 Data field
22.3.10.1 General
See 21.3.10.1, with “TVHT” replacing “VHT”.
22.3.10.2 SERVICE field
See 21.3.10.2, with “TVHT” replacing “VHT”.
22.3.10.3 CRC calculation for TVHT-SIG-B
The CRC calculation and insertion is illustrated in Figure 21-23.
The value of the CRC field shall be the 1s complement of Equation (21-59) with the values of N set to 21 for
all Modes.
22.3.10.4 Scrambler
See 21.3.10.4 with “TVHT” replacing “VHT”.
22.3.10.5 Coding
See 21.3.10.5 with “TVHT” replacing “VHT”.
22.3.10.6 Stream parser
After coding and puncturing, the data bit streams at the output of the FEC encoders are processed in groups
of NCBPS bits. Each of these groups is rearranged into NSS blocks of NCBPSS bits (NSS,u blocks of NCBPSS,u
bits in the case of an MU transmission). This operation is referred to as stream parsing and is described in
21.3.10.6.
22.3.10.7 Segment parser
The segment parser as described in 21.3.10.7 is not used in Clause 22. All modes of operation use a common
interleaver in the case of BCC or use a common tone mapper in the case of LDPC.
22.3.10.8 BCC interleaver
The BCC interleaver and deinterleaver for one BCU (TVHT_MODE_1) is as defined in 21.3.10.8 for
40 MHz.
2651
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The BCC interleaver and deinterleaver for TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C,
and TVHT_MODE_4N reuse the same formulas as described in 21.3.10.8 for 40 MHz with new values for
N COL , N ROW , and N ROT as defined in Table 22-14.
Table 22-14—Number of rows and columns in the interleaver
TVHT_MODE_2C, TVHT_MODE_4C,
Parameter TVHT_MODE_1
TVHT_MODE_2N TVTH_MODE_4N
N COL 18 27 48
N ROW 6 N BPSCS 8 N BPSCS 9 N BPSCS
N ROT (NSS ≤ 4) 29 46 78
22.3.10.9 Constellation mapping
22.3.10.9.1 General
The mapping between bits at the output of the interleaver and complex constellation points is as described in
21.3.10.9.1.
The streams of complex numbers in frequency subblock l for user u are denoted
d' k i n l u ; k= 0 1 N SD – 1 ; i = 1 N SS u ; n = 0 1 N SYM – 1 ;
l = 0 for all transmission modes.
22.3.10.9.2 LDPC tone mapping
The LDPC tone mapping for one BCU (TVHT_MODE_1) is as defined in 21.3.10.9.2 for 40 MHz.
The LDPC tone mapping for TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and
TVHT_MODE_4N reuses the same formulas as described in 21.3.10.9.2 for 40 MHz with values for D TM
as defined in Table 22-15.
Table 22-15—LDPC Tone Mapping Distance for each transmission mode
TVHT_MODE_2C, TVHT_MODE_4C,
Parameter TVHT_MODE_1
TVHT_MODE_2N TVHT_MODE_4N
D TM 6 8 9
For all Clause 22 transmission Modes, the LDPC tone mapping for LDPC-coded streams corresponding to
user u is done by permuting the stream of complex numbers
d' k i n l u; k=0 1 N SD – 1 ; i = 1 N SS u ; n = 0 1 N SYM – 1 ;
l = 0 for all transmission modes.
generated by the constellation mappers, to obtain
d' t k i n l u; k=0 1 N SD – 1 ; i = 1 N SS u ; n = 0 1 N SYM – 1 ;
l = 0 for all transmission modes.
2652
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
N SD k D TM
t(k) = D TM k mod ---------
- + ----------------- for all transmission modes
D TM N SD
22.3.10.9.3 Segment deparser
The segment deparser is not used in Clause 22 as no segment parser is used in Clause 22.
22.3.10.9.4 Space-time block coding
See 21.3.10.9.4 with “TVHT” replacing “VHT”.
22.3.10.10 Pilot subcarriers
For TVHT_MODE_1 transmission, six pilot tones shall be inserted in subcarriers –53, –25, –11, 11, 25, and
53. The pilots are generated as described in 21.3.10.10 for 40 MHz transmission.
When multiple BCUs are used (TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and
TVHT_MODE_4N), each BCU shall use the same pilot tones, which are generated as described in
21.3.10.10 for 40 MHz transmission.
22.3.10.11 OFDM modulation transmission in VHT format
For TVHT transmissions, the signal from transmit chain iTX, 1 iTX NTX shall be as specified in
Equation (21-95), where k BW is replaced by k M as defined in Table 22-12 and where N SR and ∆F are
defined in Table 22-8.
For TVHT_MODE_1 transmission, parameters shall be selected to be the same with 40 MHz VHT
transmission as defined in 21.3.10.11.1.
For multi-segment transmissions TVHT_MODE_2C and TVHT_MODE_4C, each frequency segment shall
follow the waveform as described in Equation (21-95), and the data and pilot subcarriers are allocated to the
IDFT block according to the subcarrier mapping as specified in Table 22-9 in consecutive order from the
lowest subcarrier to the highest subcarrier.
For multi-segment transmissions TVHT_MODE_2N and TVHT_MODE_4N, each frequency segment shall
follow the waveform as described in Equation (21-95), and the data and pilot subcarriers are allocated by the
subcarrier allocation block, as shown in Figure 22-2, to the two IDFT blocks according to the subcarrier
mapping as specified in Equation (21-95) and Table 22-9 in consecutive order from the lowest subcarrier to
the highest subcarrier in each of the two frequency segments, the lower half of the subcarriers are mapped to
the IDFT corresponding to the lower frequency segment, and the upper half of the subcarriers are mapped to
the IDFT corresponding to the upper frequency segment.
22.3.10.12 Non-HT duplicate transmission
When the TXVECTOR parameter FORMAT is NON_HT and the TXVECTOR parameter
NON_HT_MODULATION is NON_HT_DUP_OFDM, the transmitted PPDU shall be a non-HT duplicate.
Multiple BCUs non-HT duplicate transmission is used to transmit to TVHT STAs that may be present in a
part of a channel.
For non-HT duplicate transmission, the Data field shall be as defined in 21.3.10.12, with “TVHT” replacing
“VHT” and with references to “Clause 22” replacing references to “Clause 21”, using the parameter values
2653
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
defined in Table 22-16. The Data field shall be as defined by Equation (21-100) with following
modifications. N 20MHz is defined in Table 22-16. KShift(i) in Equation (21-100) is replaced by
K Shift i = N – 1 – 2i 32 + 8 N 20MHz 4 + 8 N 20MHz 8 – 16 i 2 .
20MHz
i Tone
T CS
TX
represents the cyclic shift of the transmit chain i and is defined in 22.3.8.2.1. N NON_HT_DUP_OFDM-Data
TX
is defined in Table 22-16.
Table 22-16—Parameters for Non-HT duplicate transmissions
TVHT_ TVHT_ TVHT_ TVHT_ TVHT_
Parameter
MODE_1 MODE_2C MODE_2N MODE_4C MODE_4N
N 20MHz 2 4 2 8 4
Tone
N NON_HT_DUP_OFDM-Data 104 208 104 416 208
In addition, the parameter k BW is replaced by k M as defined in Table 22-12. For a noncontiguous
TVHT_W+W or TVHT_2W+2W non-HT duplicate transmission, data transmission in each frequency
segment shall be as defined for a TVHT_W or TVHT_2W non-HT duplicate transmission, respectively.
22.3.11 SU-MIMO and MU-MIMO Beamforming
22.3.11.1 General
SU-MIMO and DL-MU-MIMO beamforming in TVWS band is used as defined in 21.3.11.1 reading
“Clause 22” for references to “Clause 21” except for feedback report format described in 9.4.1.50.
22.3.11.2 Beamforming Feedback Matrix V
Beamforming Feedback Matrix V is constructed as defined in 21.3.11.2 reading “Clause 22” for reference to
“Clause 21” except for CSD values defined in 22.3.8.3.2.
22.3.11.3 Group ID
See 21.3.11.4 with “TVHT” replacing “VHT”.
22.3.12 TVHT preamble format for sounding PPDUs
The format of a VHT NDP PPDU in TVWS bands is constructed as defined Figure 22-1.
NOTE—The number of TVHT-LTF symbols in the NDP is determined by the SU NSTS field in TVHT-SIG-A.
The TVHT NDP PPDU has the following properties:
— Uses the TVHT PPDU format but without the Data field.
— Is a TVHT SU PPDU as indicated by the TVHT-SIG-A field.
— Has the data bits of the TVHT-SIG-B field set to a fixed bit pattern (see 22.3.8.3.6).
22.3.13 Regulatory requirements
See 21.3.13.
2654
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.3.14 Channelization
A TVHT channel is specified by the four PLME MIB fields specified in Table 22-17.
Table 22-17—Fields to specify TVHT channels
Field Meaning
dot11CurrentTVHTChannel Channel width. Possible values represent TVHT_W, TVHT_2W, TVHT_W+W,
Width TVHT_4W, TVHT_2W+2W.
dot11CurrentTVHTChannelC In TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C operation
enterFrequencyIndex0 denotes the center frequency of the lowest TV channel.
In TVHT_MODE_2N and TVHT_MODE_4N operation, denotes the center
frequency of the lowest TV channel in the frequency segment that contains the
primary channel.
Valid range is 1 to 200.
See Equation (22-10).
dot11CurrentTVHTChannelC In TVHT_MODE_2N and TVHT_MODE_4N operation, denotes the center
enterFrequencyIndex1 frequency of the lowest TV channel in the frequency segment that does not contain
the primary channel.
Valid range is 1 to 200.
See Equation (22-10).
Undefined for TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C
operation.
dot11CurrentPrimaryChannel Denotes the location of the primary TVHT_W channel.
Valid range is 1 to 200.
See Equation (22-11).
Given dot11CurrentTVHTChannelCenterFrequencyIndex0 and
dot11CurrentTVHTChannelCenterFrequencyIndex1, the respective center frequency is given by
Equation (22-10).
Channel center frequency [MHz] = Channel starting frequency (22-10)
+ TVHT_W dot11CurrentChannelCenterFrequencyIndex + ChannelCenterFrequencyCorrection
where
Channel starting frequency is given by the Operating Class (E.1) and
dot11CurrentTVHTChannelCenterFrequencyIndex is either dot11CurrentTVHTChannelCenterFrequen-
cyIndex0 or dot11CurrentTVHTChannelCenterFrequencyIndex1 and
ChannelCenterFrequencyCorrection is
0 for TVHT_MODE_1 and TVHT_MODE_2N,
0.5 TVHT_W for TVHT_MODE_2C and TVHT+MODE_4N ,
1.5 TVHT_W for TVHT_MODE_4C.
NOTE—Channel starting frequency is the frequency that results in the regulatory domain’s channel number being the
RLAN channel number, i.e., the center frequency of the channel for index 0. For example, the center frequency of
U.S. TV channel 2 is 57 MHz. The center frequency of U.S. TV channel 2 is obtained by Equation (22-10) as follows:
Channel center frequency [MHz] = Channel starting frequency + TVHT_W ×
dot11CurrentTVHTChannelCenterFrequencyIndex + ChannelCenterFrequencyCorrection = (0.045 × 1000) + 6 × 2 + 0 =
57 MHz.
The center frequency of the primary TVHT_W channel is given by Equation (22-11).
2655
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Primary channel center frequency [MHz]
(22-11)
= Channel starting frequency + TVHT_W dot11CurrentPrimaryChannel
The channel starting frequency is given by the Operating Class (see E.1).
For TVHT_MODE_2N operation, any two non-identical channels may be used.
For TVHT_MODE_4N operation, any two channels that would each be allowed as TVHT_2W channels and
whose center frequencies are separated by greater than TVHT_2W (difference between
dot11CurrentTVHTChannelCenterFrequencyIndex0 and
dot11CurrentTVHTChannelCenterFrequencyIndex1 corresponds to a frequency difference greater than 2)
may be used.
For example, in the United States, a channel specified by
dot11CurrentTVHTChannelWidth = TVHT_2W (12 MHz)
dot11CurrentTVHTChannelCenterFrequencyIndex0 = 15
dot11CurrentPrimaryChannel = 16
is a 12 MHz channel with a center frequency of 482 MHz and the primary 6 MHz channel centered at
485 MHz.
A channel specified by
dot11CurrentTVHTChannelWidth = TVHT_4W (24 MHz)
dot11CurrentTVHTChannelCenterFrequencyIndex0 = 14
dot11CurrentPrimaryChannel = 17
is a 24 MHz channel with a center frequency of 482 MHz and the primary 6 MHz channel centered at
491 MHz.
A channel specified by
dot11CurrentTVHTChannelWidth = TVHT_2W+2W (12+12 MHz)
dot11CurrentTVHTChannelCenterFrequencyIndex0 =15
dot11CurrentTVHTChannelCenterFrequencyIndex1 = 40
dot11CurrentPrimaryChannel = 16
is an 12+12 MHz channel in which frequency segment 0 has 12 MHz bandwidth and center frequency of
482 MHz. Frequency segment 1 also has 12 MHz bandwidth and center frequency of 632 MHz. The primary
6 MHz channel is centered at 485 MHz.
22.3.15 Slot time
The slot time for the TVHT PHY shall be 24 µs for 6 MHz and 7 MHz channel units and 20 µs for 8 MHz
channel units.
22.3.16 Transmit and receive port impedance
Transmit and receive antenna connector impedance for each transmit and receive antenna is defined in
17.3.8.7.
2656
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.3.17 TVHT transmit specification
22.3.17.1 Transmit spectrum mask
For transmission in TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C, the transmit spectral
mask shall be as described for 40 MHz mask PPDU in 21.3.17.1 with the frequency axis multiplied by the
frequency scaling factor as defined in Table 22-18.
Table 22-18—Spectral mask frequency scaling factor for contiguous transmission
Scaling for 6 MHz Scaling for 7 MHz Scaling for 8 MHz
Mode
channels channels channels
TVHT_MODE_1 6 / 40 7 / 40 8 / 40
TVHT_MODE_2C 12 / 40 14 / 40 16 / 40
TVHT_MODE_4C 24 / 40 28 / 40 32 / 40
For transmission in mode TVHT_MODE_4N, the transmit spectral mask shall be as described for
80+80 MHz mask PPDU in 21.3.17.1 with the frequency axis multiplied by the frequency scaling factor as
defined in Table 22-19.
Table 22-19—Spectral mask frequency scaling factor for TVHT_MODE_4N
Scaling for 6 MHz Scaling for 7 MHz Scaling for 8 MHz
Mode
channels channels channels
TVHT_MODE_4N 12 / 80 14 / 80 16 / 80
NOTE 1—In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements
(measured as defined in the relevant regulation) and the mask defined in this subclause.
NOTE 2—For rules regarding TX center frequency leakage levels, see 22.3.17.4.2.
For a TVHT_W+W mask PPDU of VHT or non-HT duplicate format, the overall transmit spectral mask is
constructed in the following manner. First, the 40 MHz interim transmit spectral mask shall have a 0 dBr (dB
relative to the maximum spectral density of the signal) bandwidth of 38 MHz, –20 dBr at 21 MHz frequency
offset, –28 dBr at 40 MHz frequency offset, and –40 dBr at 60 MHz frequency offset and above. The
40 MHz interim transmit spectral mask for frequency offsets in between 19 MHz and 21 MHz, 21 MHz and
40 MHz, and 40 MHz and 60 MHz shall be linearly interpolated in dB domain from the requirements for
19 MHz, 21 MHz, 40 MHz, and 60 MHz frequency offsets. Then the 40 MHz interim spectral mask
frequency points are scaled as defined in Table 22-20 to produce a TVHT_W interim spectral mask. Then,
the TVHT_W interim spectral mask is placed on each of the two segments to produce the TVHT_W+W
interim spectral mask. Then, for each frequency at which both of the TVHT_W interim spectral masks have
values greater than –40 dBr and less than –20 dBr, the sum of the two TVHT_W interim mask values
(summed in linear domain) shall be taken as the overall TVHT_W+W interim spectral mask value. Next,
for each frequency at which neither of the two TVHT_W interim masks has values greater than or equal to –
20 dBr and less than or equal to 0 dBr, the higher value of the two interim masks shall be taken as the overall
TVHT_W+W interim mask spectral value. Finally, for any frequency region where the TVHT_W+W
interim mask value has not been defined yet, linear interpolation (in dB domain) between the nearest two
frequency points with the TVHT_W+W interim spectral mask value defined shall be used to define the
2657
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TVHT_W+W interim spectral mask value. The transmit spectrum shall not exceed the maximum of the
TVHT_W+W interim transmit spectrum mask and –59 dBm/MHz at any frequency offset.
Table 22-20—Spectral mask frequency scaling factor for TVHT_MODE_2N
Scaling for 6 MHz Scaling for 7 MHz Scaling for 8 MHz
Mode
channels channels channels
TVHT_MODE_2N 6 / 40 7 / 40 8 / 40
Example transmit spectral mask for a TVHT_W+W mask PPDU for BCU of 6 MHz and spacing of 12 MHz
is shown in Figure 22-4.
P P
S S
0 D 0 D
dBr dBr
6 MHz 6 MHz
-20
Mask 1 -20
Mask 2
dBr dBr
-28 -28
dBr dBr
-40 -40
- - dBr - - dBr
2 3 2 3
3 2 3 2
. . f[MH . . f[MH
. . . .
-9 -6 0 9
0 9 0 6 9 z] -9 -6 0 9
0 9 0 6 9 z]
2 7 2 7
2 2 7 2
5 5 5 5
5 5 5 5
P
S
0 D
dBr
Overall transmit
spectral mask
(bold line)
both of the 6 -20 neither of the
dBr two 6 MHz
MHz sp ectral -25
-28 masks have
masks have dBr
dBr values
values
grea ter than grea ter than
-40 dBr and or equa l to -
less than -20 20 dBr and
dBr less than or
equ al to 0
-40
dBr dBr
- -
2 3
3 2
- - . . f[MH
. . 8.92 9.07
-15 -12 9.07 8.92 -6
0 9
9 0 6 5 5
12 15 z]
higher 5 5 Original lin. 2 7 Original higher
7 2
5 5
value Mask 1 5 5 sum Mask 2 value
Figure 22-4—Example transmit spectral mask for an 6+6 MHz mask PPDU
22.3.17.2 Spectral flatness
Spectral flatness measurements shall be conducted using BPSK modulated PPDUs. See 22.3.17.4.4 for the
demodulation procedure of the PPDUs as well as the number of PPDUs and OFDM symbols to be used for
testing.
2658
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Let E i avg denote the average constellation energy of a BPSK modulated subcarrier i in a TVHT data
symbol.
For TVHT_MODE_1 contiguous non-HT duplicate or TVHT transmission having a bandwidth listed in
Table 22-21, E i avg of each of the subcarriers with indices listed as tested subcarrier indices shall not
deviate by more than the specified maximum deviation in Table 22-21 from the average of E i avg over
subcarrier indices listed as averaging subcarrier indices. Averaging of E i avg is done in the linear domain.
Table 22-21—Maximum transmit spectral flatness deviations
Bandwidth of Maximum
Averaging subcarrier Tested subcarrier
Format transmission deviation
indices (inclusive) indices (inclusive)
(MHz) (dB)
VHT TVHT_W –42 to –2 and +2 to +42 –42 to –2 and +2 to +42 ±4
–58 to –43 and +43 to +58 +4/–6
non-HT duplicate TVHT_W –42 to –33, –31 to –6, +6 –42 to –33, –31 to –6, +6 ±4
to +31, and +33 to +42 to +31, and +33 to +42
–43 to –58 and +43 to +58 +4/–6
For transmissions consisting of multiple contiguous or noncontiguous BCUs, each BCU shall meet the
spectral flatness requirement for TVHT_MODE_1 transmission.
For the spectral flatness test, the transmitting STA shall be configured to use a spatial mapping matrix Qk
(see 22.3.10.11) with flat frequency response. Each output port under test of the transmitting STA shall be
connected through a cable to one input port of the testing instrumentation.
22.3.17.3 Transmit center frequency and symbol clock frequency tolerance
The transmitter center frequency maximum allowable deviation shall be ±25 ppm. Carrier (LO) and symbol
clock frequencies for the all transmit chains and BCUs shall be derived from the same reference oscillator.
NOTE—For multi-channel operation, the signal phase of each BCU might be uncorrelated.
The symbol clock frequency tolerance shall be maximum ±25 ppm. The transmit center frequency and the
symbol clock frequency for all transmit antennas and contiguous BCUs shall be derived from the same
reference oscillator.
22.3.17.4 Modulation accuracy
22.3.17.4.1 Introduction to modulation accuracy tests
Transmit modulation accuracy specifications are defined in 22.3.17.4.2 and 22.3.17.4.3. The test method is
described in 21.3.17.4.4.
2659
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.3.17.4.2 Transmit center frequency leakage
For transmissions using all formats except noncontiguous where the RF LO falls outside both BCUs, TX LO
leakage shall meet the following requirements:
— When the RF LO is in the center of the transmitted PPDU BW, the power measured at the center of
transmission BW using resolution BW (6/144 or 8/144) MHz shall not exceed the average power per
subcarrier of the transmitted PPDU, or equivalently ( P – 10 log 10(N ST) ), where P is the transmit
power per antenna in dBm and NST is defined in Table 22-8.
— When the RF LO is not at the center of the transmitted PPDU BW, the power measured at the
location of the RF LO using resolution BW (6/144 or 8/144) MHz shall not exceed the maximum of
–32 dB relative to the total transmit power and –20 dBm, or equivalently max(P – 32 – 20) , where
P is the transmit power per antenna in dBm and NST is defined in Table 22-8.
For transmissions using TVHT_MODE_2N and TVHT_MODE_4N, where the RF LO falls outside both
BCUs, the RF LO shall follow the spectral mask requirements as defined in 22.3.17.1.
22.3.17.4.3 Transmitter constellation error
For all modes defined in TVHT PHY, the requirements for transmit constellation RMS error are same as
defined in 21.3.17.4.3.
For non-HT duplicate transmissions, requirements defined in 17.3.9.7.4 apply to all parts of the channel
bandwidth. The channel bandwidth is determined by the TXVECTOR parameter CH_BANDWIDTH.
22.3.17.4.4 Transmitter modulation accuracy (EVM) test
For the transmit modulation accuracy test, the same methodology as that defined in 21.3.17.4.4 shall be
applied per BCU (termed frequency segment in Clause 21). The channel bandwidth is determined by the
TXVECTOR parameter CH_BANDWIDTH.
22.3.17.5 Time of Departure accuracy
For Time of Departure accuracy test, the test parameters defined in 21.3.17.5 shall be used for evaluation of
TOD except the channel bandwidth, TTR and TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH.
The channel bandwidth is determined by TXVECTOR parameter CH_BANDWIDTH in 22.2.2. TTR and
TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH shall be multiplied by the corresponding scaling
factor for the 6 MHz, 7 MHz, and 8 MHz channels, where the scaling factor is defined in 22.3.8.2.1.
22.3.18 TVHT receiver specification
22.3.18.1 General
See 21.3.18.
22.3.18.2 Receiver minimum input sensitivity
The packet error ratio (PER) shall be less than 10% for a PSDU length of 4096 octets with the rate-
dependent input levels listed in Table 22-22. The test in this subclause and the minimum sensitivity levels
specified in Table 22-22 apply only to non-STBC modes, long GI, BCC, and VHT PPDU in TVWS bands.
2660
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-22—Receiver minimum input level sensitivity
Minimum sensitivity (dBm)
12/14 MHz 24/28 MHz 32 MHz
16 MHz
Rate 6 or 7 (TVHT_ (TVHT_ (TVHT_
Modulation (TVHT_
(R) MHz MODE_2C) MODE_4C 8 MHz MODE_4C)
MODE_2C)
(TVHT_ or 6+6/7+7 or 12+12/ (TVHT_ or 16+16/
or 8+8 MHz
MODE_1) MHz 14+14 MHz MODE_1) 16+16 MHz
(TVHT_
(TVHT_ (TVHT_ (TVHT_
MODE_2N)
MODE_2N) MODE_4N) MODE_4N)
BPSK 1/2 –88 –85 –82 –87 –84 –81
QPSK 1/2 –85 –82 –79 –84 –81 –78
QPSK 3/4 –83 –80 –77 –82 –79 –76
16-QAM 1/2 –80 –77 –74 –79 –76 –73
16-QAM 3/4 –76 –73 –70 –75 –72 –69
64-QAM 2/3 –72 –69 –66 –71 –68 –65
64-QAM 3/4 –71 –68 –65 –70 –67 –64
64-QAM 5/6 –70 –67 –64 –69 –66 –63
256-QAM 3/4 –65 –62 –59 –64 –61 –58
256-QAM 5/6 –63 –60 –57 –62 –59 –56
22.3.18.3 Adjacent channel rejection
Adjacent channel rejection for TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C follow the
definition in the first paragraph of 21.3.18.2 and use the values in Table 22-23.
Adjacent channel rejection for TVHT_MODE_2N (TVHT_W+W) and TVHT_MODE_4N
(TVWT_2W+2W) follows the definition in the second paragraph of 21.3.18.2, where “80 MHz” is replaced
by “TVHT_W” for TVHT_MODE_2N and “TVHT_2W” for TVHT_MODE_4N, and uses the values in
Table 22-23.
The definitions in the rest of 21.3.18.2 apply to Clause 22 using the values in Table 22-23.
22.3.18.4 Nonadjacent channel rejection
Nonadjacent channel rejection for TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C channels
follows the definition in the first paragraph of 21.3.18.3 and use the values in Table 22-23.
Nonadjacent channel rejection for TVHT_MODE_2N (TVHT_W+W) and TVHT_MODE_4N
(TVWT_2W+2W) follows the definition in the second paragraph of 21.3.18.3, where “80 MHz” is replaced
by “TVHT_W” for TVHT_MODE_2N and “TVHT_2W” for TVHT_MODE_4N, and uses the values in
Table 22-23.
2661
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-23—Minimum required adjacent and nonadjacent channel rejection levels
Adjacent channel rejection (dB) Nonadjacent channel rejection (dB)
6+6 MHz
6 MHz, 7 MHz, (TVHT_MODE 6 MHz, 7 MHz,
6+6 MHz
8 MHz, 12 MHz _2N), 7+7 MHz 8 MHz, 12 MHz
(TVHT_MODE_
(TVHT_MODE_ (TVHT_MODE (TVHT_MODE_
2N), 7+_7 MHz
2C), 14 MHz _2N), 8+8 MHz 2C), 14 MHz
(TVHT_MODE_
(TVHT_MODE_ (TVHT_MODE (TVHT_MODE_
2N), 8+8 MHz
Modulation Rate (R) 2C), 16 MHz _2N), 12+12 2C), 16 MHz
(TVHT_MODE_
(TVHT_MODE_ MHz (MTVHT_MOD
2N), 12+12 MHz
2C), 24 MHz (TVHT_MODE E_2C), 24 MHz
(TVHT_MODE_
(TVHT_MODE_ _4N), 14+14 (TVHT_MODE_
4N), 14+14 MHz
4C), 28 MHz MHz 4C), 28 MHz
(TVHT_MODE_
(TVHT_MODE_ (TVHT_MODE (TVHT_MODE_
4N), 16+16 MHz
4C), 32 MHz _4N), 16+16 4C), 32 MHz
(TVHT_MODE_
(TVHT_MODE_ MHz (TVHT_MODE_
4N)
4C) (TVHT_MODE 4C)
_4N)
BPSK 1/2 16 13 32 29
QPSK 1/2 13 10 29 26
QPSK 3/4 11 8 27 24
16-QAM 1/2 8 5 24 21
16-QAM 3/4 4 1 20 17
64-QAM 2/3 0 –3 16 13
64-QAM 3/4 –1 –4 15 12
64-QAM 5/6 –2 –5 14 11
256-QAM 3/4 –7 –10 9 6
256-QAM 5/6 –9 –12 7 4
The definitions in the rest of 21.3.18.3 apply to Clause 22 using the values in Table 22-23.
22.3.18.5 Receiver maximum input level
The receiver shall provide a maximum PER of 10% at a PSDU length of 4096 octets, for a maximum input
level of –20 dBm, measured at each antenna for any baseband TVHT modulation.
22.3.18.6 CCA sensitivity
22.3.18.6.1 General
The thresholds in this subclause are compared with the signal level at each receiving antenna.
2662
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.3.18.6.2 CCA sensitivity for operating classes requiring CCA-ED
For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall also indicate a medium
busy condition when CCA-ED detects a channel busy condition.
For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED
is given in Table D-2. The operating classes requiring the corresponding CCA-ED behavior class are given
in E.1. The PHY of a STA that is operating within an operating class that requires CCA-ED shall operate
with CCA-ED.
CCA-ED shall detect a channel busy condition when the received signal strength exceeds the CCA-ED
threshold as given by dot11OFDMEDThreshold for the primary TVHT_W channel,
dot11OFDMEDThreshold for the secondary TVHT_W channel (if present) and dot11OFDMEDThreshold +
3 dB for the secondary TVHT_2W channel (if present). The CCA-ED thresholds for the operating classes
requiring CCA-ED are subject to the criteria in D.2.5.
NOTE—The requirement to detect a channel busy condition as stated in 22.3.18.6.3 and 22.3.18.6.4 is a mandatory
energy detect requirement on all Clause 22 receivers. Support for CCA-ED is an additional requirement that relates
specifically to the sensitivities described in D.2.5.
22.3.18.6.3 CCA sensitivity for signals occupying the primary channel
The PHY shall issue a PHY-CCA.indication(BUSY, {primary}) primitive if one of the conditions listed in
Table 22-24 is met in an otherwise idle TVHT_W (TVHT_MODE_1), TVHT_2W (TVHT_MODE_2C),
TVHT_4W (TVHT_MODE_4C), TVHT_W+W (TVHT_MODE_2N), and TVHT_2W+2W
(TVHT_MODE_4N) operating channel width. With >90% probability, the PHY shall detect the start of a
PPDU that occupies at least the primary TVHT_W channel under the conditions listed in Table 22-24 within
a period of aCCATime (see 22.4.4) and hold the CCA signal busy (PHY-CCA.indication(BUSY, channel-
list)) for the duration of the PPDU.
Table 22-24—Conditions for CCA BUSY on the primary channel
Frequency segment width Conditions
6 MHz The start of a 6 MHz non-HT duplicate or VHT PPDU in TVWS bands in the
primary 6 MHz channel at or above –88 dBm.
7 MHz The start of a 7 MHz non-HT duplicate or VHT PPDU in TVWS bands in the
primary 7 MHz channel at or above –88 dBm.
8 MHz The start of a 8 MHz non-HT duplicate or VHT PPDU in TVWS bands in the
primary 8 MHz channel at or above –87 dBm.
The receiver shall issue a PHY-CCA.indication(BUSY, {primary}) primitive for any signal that exceeds a
threshold equal to 20 dB above the minimum modulation and coding rate sensitivity (–88 + 20 = –68 dBm in
the case of 6 MHz channel) in the primary TVHT_W channel within a period of aCCATime after the signal
arrives at the receiver’s antenna(s); then the receiver shall not issue a PHY-
CCA.indication(BUSY,{secondary}), PHY-CCA.indication(BUSY,{secondaryTVHT_2W}), or PHY-
CCA.indication(IDLE) primitive while the threshold continues to be exceeded.
2663
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.3.18.6.4 CCA sensitivity for signals not occupying the primary channel
The PHY shall issue a PHY-CCA.indication(BUSY, {secondary}) primitive if the conditions for issuing a
PHY-CCA.indication(BUSY, {primary}) primitive are not present and one of the following conditions is
present in an otherwise idle TVHT_2W (TVHT_MODE_2C), TVHT_4W (TVHT_MODE_4C),
TVHT_W+W (TVHT_MODE_2N), and TVHT_2W+2W (TVHT_MODE_4N) operating channel width:
— Any signal within the secondary channel at or above a threshold (–68 dBm for 6 MHz, –68 dBm for
7 MHz, and –67 dBm for 8 MHz) within a period of aCCATime after the signal arrives at the
receiver’s antenna(s); then the PHY shall not issue a PHY-
CCA.indication(BUSY,{secondaryTVHT_2W}) or PHY-CCA.indication(IDLE) primitive while the
threshold continues to be exceeded.
— A TVHT_W non-HT duplicate or VHT PPDU in TVWS bands detected in the secondary channel at
or above a threshold (–81 dBm for 6 MHz, –81 dBm for 7 MHz, and –80 dBm for 8 MHz) with
>90% probability within a period aCCAMidTime (see 22.4.4).
The PHY shall issue a PHY-CCA.indication(BUSY, {secondaryTVHT_2W}) primitive if the conditions for
issuing a PHY-CCA.indication(BUSY, {primary}) primitive and a PHY-CCA.indication(BUSY,
{secondary}) primitive are not present and one of the following conditions is present in an otherwise idle
TVHT_4W (TVHT_MODE_4C) and TVHT_2W+2W (TVHT_MODE_4N) operating channel width:
— Any signal within the secondary TVHT_2W channel at or above a threshold (–65 dBm for 12 MHz,
–65 dBm for 14 MHz, and –64 dBm for 16 MHz) within a period of aCCATime after the signal
arrives at the receiver’s antenna(s); then the PHY shall not issue a PHY-CCA.indication(IDLE)
primitive while the threshold continues to be exceeded.
— A TVHT_2W non-HT duplicate or VHT PPDU in TVWS bands detected in the secondary
TVHT_2W channel at or above a threshold (–78 dBm for 6+6 MHz, –78 dBm for 7+7 MHz, and
–77 dBm for 8+8 MHz or 16 MHz) with >90% probability within a period aCCAMidTime (see
22.4.4).
— A TVHT_W non-HT duplicate or VHT PPDU in TVWS bands detected in any TVHT_W
subchannel of the secondary TVHT_2W channel at or above a threshold (–81 dBm for 6 MHz,
–81 dBm for 7 MHz, and –80 dBm for 8 MHz) with >90% probability within a period
aCCAMidTime.
22.3.18.7 RSSI
See 21.3.18.6 with “TVHT” replacing “VHT”.
22.3.19 PHY transmit procedure
See 21.3.19 with “TVHT” replacing “VHT”.
22.3.20 PHY receive procedure
See 21.3.20 with “TVHT” replacing “VHT”.
2664
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.4 TVHT PLME
22.4.1 PLME SAP sublayer management primitives
See 21.4.1 with “TVHT” replacing “VHT”.
22.4.2 PHY MIB
See 21.4.2 with “tvht(10)” replacing “vht(9)”, “TVHT” replacing “VHT”, and “In4W” replacing “In80” and
with the removal of “dot11VHTShortGIOptionIn160and80p80Implemented” and
“dot11VHTShortGIOptionIn160and80p80Activated”.
22.4.3 TXTIME and PSDU_LENGTH calculation
See 21.4.3 with “TVHT” replacing “VHT”.
22.4.4 TVHT PHY
The static TVHT PHY characteristics, provided through the PLME-CHARACTERISTICS service
primitive, shall be as shown in Table 19-25 except parameters listed in Table 22-25 and aPreambleLength,
aSTFOneLength, aSTFTwoLength, aLTFOneLength, aLTFTwoLength, aPHYHeaderLength, and
aPHYSigTwoLength, which are multiplied by 7.5 for 6 MHz and 7 MHz unit channels and by 5.625 for
8 MHz unit channels. The definitions for these characteristics are given in 6.5.
Table 22-25—TVHT PHY characteristics
Characteristics Value
aSlotTime 24 µs (BCUs: 6 MHz or 7 MHz) plus any coverage-class-dependent
aAirPropagationTime (see Table 9-79)
20 µs (BCUs: 8 MHz) plus any coverage-class-dependent aAirPropagationTime (see
Table 9-79)
aSIFSTime 120 µs (BCUs: 6 MHz or 7 MHz)
90 µs (BCUs: 8 MHz)
aSignalExtension 0 µs
aCCATime < 15 µs (6 MHz or 7 MHz)
< 11.25 µs (8 MHz)
aCCAMidTime < 94 µs (6 MHz or 7 MHz)
< 70 µs (8 MHz)
aAirPropagationTime As indicated by the coverage class (see 10.21.5)
aPPDUMaxTime 20 ms
aPSDUMaxLength 1 401 120 octets (see NOTE 1)
aRxPHYStartDelay (36 + 4 × the maximum possible value for NVHT-LTF supported + 4) × 7.5 (6 and 7
MHz channels) or 5.625 (8 MHz channels) (see NOTE 2)
NOTE 1—This is the maximum length in octets for SU PPDUs with a bandwidth of 32 MHz or 16+16 MHz, MCS9
and 4 spatial streams, limited by 973 possible Short GI data symbols in aPPDUMaxTime.
NOTE 2—This value arises from the time to the end of TVHT-SIG-B (see Figure 22-1) plus the need to decode the
first symbol of the Data field in order to extract the SERVICE field and check the CRC it contains.
2665
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
22.5 Parameters for TVHT MCSs
The rate-dependent parameters for one BCU mode (6 MHz, 7 MHz, and/or 8 MHz) and corresponding two
and four BCU modes with N SS = 1 4 are given in Table 22-26 through Table 22-37. Support for MCS
8 and 9 (when valid) is optional in all cases. A TVHT STA shall support single spatial stream MCSs within
the range MCS 0 to MCS 7 for all channel widths for which it has indicated support regardless of the Tx or
Rx Highest Supported Data Rate subfield values in the TVHT Supported MCS Set field. When more than
one spatial stream is supported, the Tx or Rx Highest Supported Data Rate subfield values in the TVHT
Supported MCS Set field may result in a reduced MCS range (cut-off) for N SS = 2 4 . Support for
6 MHz, 7 MHz, or 8 MHz with N SS = 1 is mandatory. Support for 6 MHz, 7 MHz, and 8 MHz with
N SS = 2 4 is optional. Support for two BCU modes with 12 MHz, 14 MHz, and 16 MHz or with
6+6 MHz, 7+7 MHz, and 8+8 MHz with N SS = 1 4 is optional. Support for four BCU modes with
24 MHz, 28 MHz, and 32 MHz or with 12+12 MHz, 14+14 MHz, and 16+16 MHz with N SS = 1 4 is
optional. NES values were chosen to yield an integer number of punctured blocks per OFDM symbol. Note
that N ES values are 1 for all Clause 22 modulations.
Table 22-26 through Table 22-37 define TVHT MCSs not only for SU transmission but also for user u of
MU transmission. In the case of TVHT MCSs for MU transmission, the parameters, NSS, R, NBPSCS, NCBPS,
and NDBPS are replaced with NSS,u, Ru, NBPSCS,u, NCBPS,u, and NDBPS,u, respectively.
In the MCS parameter tables that follow, data rates for a 400 ns GI are rounded to 1 decimal place.
Table 22-26—TVHT MCSs for TVHT_MODE_1, NSS = 1
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 108 6 108 54 1.8 2.0 2.4 2.7
1 QPSK 1/2 2 108 6 216 108 3.6 4.0 4.8 5.3
2 QPSK 3/4 2 108 6 216 162 5.4 6.0 7.2 8.0
3 16-QAM 1/2 4 108 6 432 216 7.2 8.0 9.6 10.7
4 16-QAM 3/4 4 108 6 432 324 10.8 12.0 14.4 16.0
5 64-QAM 2/3 6 108 6 648 432 14.4 16.0 19.2 21.3
6 64-QAM 3/4 6 108 6 648 486 16.2 18.0 21.6 24.0
7 64-QAM 5/6 6 108 6 648 540 18.0 20.0 24.0 26.7
8 256-QAM 3/4 8 108 6 864 648 21.6 24.0 28.8 32.0
9 256-QAM 5/6 8 108 6 864 720 24.0 26.7 32.0 35.6
2666
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-27—TVHT MCSs for TVHT_MODE_1, NSS = 2
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 108 6 216 108 3.6 4.0 4.8 5.3
1 QPSK 1/2 2 108 6 432 216 7.2 8.0 9.6 10.7
2 QPSK 3/4 2 108 6 432 324 10.8 12.0 14.4 16.0
3 16-QAM 1/2 4 108 6 864 432 14.4 16.0 19.2 21.3
4 16-QAM 3/4 4 108 6 864 648 21.6 24.0 28.8 32.0
5 64-QAM 2/3 6 108 6 1296 864 28.8 32.0 38.4 42.7
6 64-QAM 3/4 6 108 6 1296 972 32.4 36.0 43.2 48.0
7 64-QAM 5/6 6 108 6 1296 1080 36.0 40.0 48.0 53.3
8 256-QAM 3/4 8 108 6 1728 1296 43.2 48.0 57.6 64.0
9 256-QAM 5/6 8 108 6 1728 1440 48.0 53.3 64.0 71.1
Table 22-28—TVHT MCSs for TVHT_MODE_1, NSS = 3
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 108 6 324 162 5.4 6.0 7.2 8.0
1 QPSK 1/2 2 108 6 648 324 10.8 12.0 14.4 16.0
2 QPSK 3/4 2 108 6 648 486 16.2 18.0 21.6 24.0
3 16-QAM 1/2 4 108 6 1296 648 21.6 24.0 28.8 32.0
4 16-QAM 3/4 4 108 6 1296 972 32.4 36.0 43.2 48.0
5 64-QAM 2/3 6 108 6 1944 1296 43.2 48.0 57.6 64.0
6 64-QAM 3/4 6 108 6 1944 1458 48.6 54.0 64.8 72.0
7 64-QAM 5/6 6 108 6 1944 1620 54.0 60.0 72.0 80.0
8 256-QAM 3/4 8 108 6 2592 1944 64.8 72.0 86.4 96.0
9 256-QAM 5/6 8 108 6 2592 2160 72.0 80.0 96.0 106.7
2667
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-29—TVHT MCSs for TVHT_MODE_1, NSS = 4
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 108 6 432 216 7.2 8.0 9.6 10.7
1 QPSK 1/2 2 108 6 864 432 14.4 16.0 19.2 21.3
2 QPSK 3/4 2 108 6 864 648 21.6 24.0 28.8 32.0
3 16-QAM 1/2 4 108 6 1728 864 28.8 32.0 38.4 42.7
4 16-QAM 3/4 4 108 6 1728 1296 43.2 48.0 57.6 64.0
5 64-QAM 2/3 6 108 6 2592 1728 57.6 64.0 76.8 85.3
6 64-QAM 3/4 6 108 6 2592 1944 64.8 72.0 86.4 96.0
7 64-QAM 5/6 6 108 6 2592 2160 72.0 80.0 96.0 106.7
8 256-QAM 3/4 8 108 6 3456 2592 86.4 96.0 115.2 128.0
9 256-QAM 5/6 8 108 6 3456 2880 96.0 106.7 128.0 142.2
Table 22-30—TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 1
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD∙NSeg NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 216 12 216 108 3.6 4.0 4.8 5.3
1 QPSK 1/2 2 216 12 432 216 7.2 8.0 9.6 10.7
2 QPSK 3/4 2 216 12 432 324 10.8 12.0 14.4 16.0
3 16-QAM 1/2 4 216 12 864 432 14.4 16.0 19.2 21.3
4 16-QAM 3/4 4 216 12 864 648 21.6 24.0 28.8 32.0
5 64-QAM 2/3 6 216 12 1296 864 28.8 32.0 38.4 42.7
6 64-QAM 3/4 6 216 12 1296 972 32.4 36.0 43.2 48.0
7 64-QAM 5/6 6 216 12 1296 1080 36.0 40.0 48.0 53.3
8 256-QAM 3/4 8 216 12 1728 1296 43.2 48.0 57.6 64.0
9 256-QAM 5/6 8 216 12 1728 1440 48.0 53.3 64.0 71.1
2668
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-31—TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 2
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS NSD∙ 7 MHz
Modulation R NBPSCS NSP NCBPS NDBPS
Index NSeg
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 216 12 432 216 7.2 8.0 9.6 10.7
1 QPSK 1/2 2 216 12 864 432 14.4 16.0 19.2 21.3
2 QPSK 3/4 2 216 12 864 648 21.6 24.0 28.8 32.0
3 16-QAM 1/2 4 216 12 1728 864 28.8 32.0 38.4 42.7
4 16-QAM 3/4 4 216 12 1728 1296 43.2 48.0 57.6 64.0
5 64-QAM 2/3 6 216 12 2592 1728 57.6 64.0 76.8 85.3
6 64-QAM 3/4 6 216 12 2592 1944 64.8 72.0 86.4 96.0
7 64-QAM 5/6 6 216 12 2592 2160 72.0 80.0 96.0 106.7
8 256-QAM 3/4 8 216 12 3456 2592 86.4 96.0 115.2 128.0
9 256-QAM 5/6 8 216 12 3456 2880 96.0 106.7 128.0 142.2
Table 22-32—TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 3
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS NSD∙ 7 MHz
Modulation R NBPSCS NSP NCBPS NDBPS
Index NSeg
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 216 12 648 324 10.8 12.0 14.4 16.0
1 QPSK 1/2 2 216 12 1296 648 21.6 24.0 28.8 32.0
2 QPSK 3/4 2 216 12 1296 972 32.4 36.0 43.2 48.0
3 16-QAM 1/2 4 216 12 2592 1296 43.2 48.0 57.6 64.0
4 16-QAM 3/4 4 216 12 2592 1944 64.8 72.0 86.4 96.0
5 64-QAM 2/3 6 216 12 3888 2592 86.4 96.0 115.2 128.0
6 64-QAM 3/4 6 216 12 3888 2916 97.2 108.0 129.6 144.0
7 64-QAM 5/6 6 216 12 3888 3240 108. 120.0 144.0 160.0
8 256-QAM 3/4 8 216 12 5184 3888 129.6 144.0 172.8 192.0
9 256-QAM 5/6 8 216 12 5184 4320 144.0 160.0 192.0 213.3
2669
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-33—TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 4
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS NSD∙ 7 MHz
Modulation R NBPSCS NSP NCBPS NDBPS
Index NSeg
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 216 12 864 432 14.4 16.0 19.2 21.3
1 QPSK 1/2 2 216 12 1728 864 28.8 32.0 38.4 42.7
2 QPSK 3/4 2 216 12 1728 1296 43.2 48.0 57.6 64.0
3 16-QAM 1/2 4 216 12 3456 1728 57.6 64.0 76.8 85.3
4 16-QAM 3/4 4 216 12 3456 2592 86.4 96.0 115.2 128.0
5 64-QAM 2/3 6 216 12 5184 3456 115.2 128.0 153.6 170.7
6 64-QAM 3/4 6 216 12 5184 3888 129.6 144.0 172.8 192.0
7 64-QAM 5/6 6 216 12 5184 4320 144.0 160.0 192.0 213.3
8 256-QAM 3/4 8 216 12 6912 5184 172.8 192.0 230.4 256.0
9 256-QAM 5/6 8 216 12 6912 5760 192.0 213.3 256.0 284.4
Table 22-34—TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 1
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 432 24 432 216 7.2 8.0 9.6 10.7
1 QPSK 1/2 2 432 24 864 432 14.4 16.0 19.2 21.3
2 QPSK 3/4 2 432 24 864 648 21.6 24.0 28.8 32.0
3 16-QAM 1/2 4 432 24 1728 864 28.8 32.0 38.4 42.7
4 16-QAM 3/4 4 432 24 1728 1296 43.2 48.0 57.6 64.0
5 64-QAM 2/3 6 432 24 2592 1728 57.6 64.0 76.8 85.3
6 64-QAM 3/4 6 432 24 2592 1944 64.8 72.0 86.4 96.0
7 64-QAM 5/6 6 432 24 2592 2160 72.0 80.0 96.0 106.7
8 256-QAM 3/4 8 432 24 3456 2592 86.4 96.0 115.2 128.0
9 256-QAM 5/6 8 432 24 3456 2880 96.0 106.7 128.0 142.2
2670
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-35—TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 2
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 432 24 864 432 14.4 16.0 19.2 21.3
1 QPSK 1/2 2 432 24 1728 864 28.8 32.0 38.4 42.7
2 QPSK 3/4 2 432 24 1728 1296 43.2 48.0 57.6 64.0
3 16-QAM 1/2 4 432 24 3456 1728 57.6 64.0 76.8 85.3
4 16-QAM 3/4 4 432 24 3456 2592 86.4 96.0 115.2 128.0
5 64-QAM 2/3 6 432 24 5184 3456 115.2 128.0 153.6 170.7
6 64-QAM 3/4 6 432 24 5184 3888 129.6 144.0 172.8 192.0
7 64-QAM 5/6 6 432 24 5184 4320 144.0 160.0 192.0 213.3
8 256-QAM 3/4 8 432 24 6912 5184 172.8 192.0 230.4 256.0
9 256-QAM 5/6 8 432 24 6912 5760 192.0 213.3 256.0 284.4
Table 22-36—TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 3
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 432 24 1296 648 21.6 24.0 28.8 32.0
1 QPSK 1/2 2 432 24 2592 1296 43.2 48.0 57.6 64.0
2 QPSK 3/4 2 432 24 2592 1944 64.8 72.0 86.4 96.0
3 16-QAM 1/2 4 432 24 5184 2592 86.4 96.0 115.2 128.0
4 16-QAM 3/4 4 432 24 5184 3888 129.6 144.0 172.8 192.0
5 64-QAM 2/3 6 432 24 7776 5184 172.8 192.0 230.4 256.0
6 64-QAM 3/4 6 432 24 7776 5832 194.4 216.0 259.2 288.0
7 64-QAM 5/6 6 432 24 7776 6480 216.0 240.0 288.0 320.0
8 256-QAM 3/4 8 432 24 10 368 7776 259.2 288.0 345.6 384.0
9 256-QAM 5/6 8 432 24 10 368 8640 288.0 320.0 384.0 426.7
2671
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table 22-37—TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 4
Data rate
Data rate
(Mb/s) for
(Mb/s) for
6 MHz or
8 MHz
MCS 7 MHz
Modulation R NBPSCS NSD NSP NCBPS NDBPS
Index
6.0 3.0 4.5 2.25
µs µs µs µs
GI GI GI GI
0 BPSK 1/2 1 432 24 1728 864 28.8 32.0 38.4 42.7
1 QPSK 1/2 2 432 24 3456 1728 57.6 64.0 76.8 85.3
2 QPSK 3/4 2 432 24 3456 2592 86.4 96.0 115.2 128.0
3 16-QAM 1/2 4 432 24 6912 3456 115.2 128.0 153.6 170.7
4 16-QAM 3/4 4 432 24 6912 5184 172.8 192.0 230.4 256.0
5 64-QAM 2/3 6 432 24 10 368 6912 230.4 256.0 307.2 341.3
6 64-QAM 3/4 6 432 24 10 368 7776 259.2 288.0 345.6 384.0
7 64-QAM 5/6 6 432 24 10 368 8640 288.0 320.0 384.0 426.7
8 256-QAM 3/4 8 432 24 13 824 10 368 345.6 384.0 460.8 512.0
9 256-QAM 5/6 8 432 24 13 824 11 520 384.0 426.7 512.0 568.9
2672
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex A
(informative)
Bibliography
Bibliographical references are resources that provide additional or helpful material but do not need to be
understood or used to implement this standard. Reference to these resources is made for informational use
only.
[B1] 3GPP TS 23.167, IMS emergency sessions architecture: http://www.3gpp.org/ftp/Specs/html-info/
23167.htm.
[B2] 3GPP TR 21.905, Vocabulary for 3GPP Specifications.49
[B3] 3GPP TS 22.067: Enhanced Multi-Level Precedence and Pre-emption service (EMLPP); Stage 1.
[B4] 3GPP2 X.S0060-0 IMS emergency sessions architecture: http://www.3gpp2.org/Public_html/specs/
X.S0060-0_v1.0_080729.pdf.
[B5] ANSI Z136.1-1993, American National Standard for the Safe Use of Lasers.50
[B6] Arazi, E. G., A Commonsense Approach to the Theory of Error Correcting Codes, MIT Press, 1988.
[B7] ARIB RCR STD-33 (5.0), Low Power Data Communication/Wireless LAN System, ARIB,
Feb. 1999.51
[B8] ARIB STD-T71 (5.0), Broadband Mobile Access Communication System (CSMA), ARIB, Dec. 2007.
[B9] Code of Federal Regulations (CFR), Title 47, Telecommunication, Oct. 2001.52
[B10] Code of Federal Regulations, Title 47, Telecommunication, Part 90, Private Land Mobile Radio
Services, Section 90.210(m), Emission masks.
[B11] Engwer, D., and Zweig, J., “Algorithmically Derived Hop Sequences,” submission 99/195 to the
IEEE P802.11 Working Group, Sept. 1999.
[B12] “Ethernet, a local area network: Data link layer and physical layer specifications version 1.0.” Digital
Equipment Corporation, Intel Corporation, Xerox Corporation, Sept. 1980.
[B13] ETSI EN 300 328, Electromagnetic compatibility and Radio spectrum Matters (ERM); Wideband
transmission systems; Data transmission equipment operating in the 2,4 GHz ISM band and using wide band
modulation techniques; Harmonized EN covering essential requirements under article 3.2 of the R&TTE
Directive.53
493GPP documents are available from the 3rd Generation Partnership Project Web site (http://www.3gpp.org).
50
ANSI publications are available from the American National Standards Institute (http://www.ansi.org).
51
ARIB publications are available from the Association of Radio Industries and Businesses (www.arib.or.jp).
52The CFR is available from the U.S. Government Printing Office (www.gpo.gov).
53
ETSI publications are available from the European Telecommunications Standards Institute (www.etsi.org).
2673
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
[B14] ETSI EN 302 571 V1.1.1 (2008-09), Intelligent Transport Systems (ITS); Radiocommunications
equipment operating in the 5 855 MHz to 5 925 MHz frequency band; Harmonized EN covering the
essential requirements of article 3.2 of the R&TTE Directive.
[B15] ETSI ES 202 663 V1.1.0 (2010-01), Intelligent Transport Systems (ITS); European profile standard
for the physical and medium access control layer of Intelligent Transport Systems operating in the 5 GHz
frequency band.
[B16] GSMA, IR.34 v4.6, Inter-Service provider IP Backbone Guidelines, http://gsmworld.com/documents/
IR3446.pdf, Apr. 2009.
[B17] IANA Protocol Assignments for the Internet Key Exchange (IKE) Attributes, http://www.iana.org/
assignments/ipsec-registry.
[B18] IEC 60825-1:1993, Safety of laser products—Part 1: Equipment classification, requirements and
user’s guide.54
[B19] IEEE Standards Registration Authority—Frequently Asked Questions.55
[B20] IEEE Standards Registration Authority—Guidelines for Use Organizationally Unique Identifier
(OUI) and Company ID (CID).
[B21] IEEE Std 1609.0™-2013, IEEE Guide for Wireless Access in Vehicular Environments (WAVE)—
Architecture.56,57
[B22] IEEE Std 802.1AC™-2012, IEEE Standard for Local and metropolitan area networks—Media Access
Control (MAC) Service Definition.
[B23] IEEE Std 802.1D™-2004, IEEE Standard for Local and metropolitan area networks—Media Access
Control (MAC) Bridges.
[B24] IEEE Std 802.1H™-1995, IEEE Standards for Local and metropolitan area networks—
Recommended Practice for Media Access Control (MAC) Bridging of Ethernet V2.0 in IEEE 802 Local
Area Networks [now known as ISO/IEC Technical Report 11802-5:1997; see Clause 2].
[B25] IETF ECRIT, Extended ECRIT architecture supporting unauthenticated emergency services, http://
tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access.
[B26] IETF RFC 1157, Simple Network Management Protocol (SNMP), J. Case, M. Fedor, M. Schoffstall,
and J. Davin, May 1990.58
[B27] IETF RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis.
[B28] IETF RFC 2202, Test Cases for HMAC-MD5 and HMAC-SHA-1, P. Cheng and R. Glenn,
Sept. 1997 (status: informational).
54IEC publications are available from the International Electrotechnical Commission (http://www.iec.ch/). IEC publications are also
available in the United States from the American National Standards Institute (http://www.ansi.org).
55
This document is available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/regauth/faqs.html).
56
The IEEE standards or products referred to in this annex are trademarks owned by The Institute of Electrical and Electronics
Engineers, Inc.
57IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).
58
IETF documents (i.e., RFCs) are available for download at http://www.rfc-archive.org/.
2674
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
[B29] IETF RFC 2212, Specification of the Guaranteed Quality of Service.
[B30] IETF RFC 2215, General Characterization Parameters for Integrated Service Network Elements.
[B31] IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers.
[B32] IETF RFC 2548, Microsoft Vendor-specific RADIUS Attributes.
[B33] IETF RFC 2865, Remote Authentication Dial in User Service (RADIUS).
[B34] IETF RFC 2898, PKCS #5: Password-Based Cryptography Specification Version 2.0
[B35] IETF RFC 2903, Generic AAA architecture, C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, and
D. Spence, Aug. 2000 (status informational).
[B36] IETF RFC 3222, Terminology for Forwarding Information Base (FIB) based Router Performance.
[B37] IETF RFC 3290, An Informal Management Model for Diffserv Routers.
[B38] IETF RFC 3561, Ad hoc On-Demand Distance Vector (AODV) Routing, C. Perkins, E. Belding-
Royer, and S. Das, July 2003. (status: experimental).
[B39] IETF RFC 3580, IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage
Guidelines, P. Congdon, B. Aboba, A. Smith, G. Zorn, and J. Roese, Sept. 2003.
[B40] IETF RFC 3588, Diameter Base Protocol.
[B41] IETF RFC 3693, Geopriv Requirements, Feb. 2004.
[B42] IETF RFC 3748, Extensible Authentication Protocol (EAP).
[B43] IETF RFC 4493, The AES-CMAC Algorithm.
[B44] IETF RFC 4776, Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic
Addresses Configuration Information, H. Schulzrinne, Nov. 2006.
[B45] IETF RFC 4862, IPv6 Stateless Address Autoconfiguration, S. Thomson, T. Narten, T. Jinmei, Sept.
2007.
[B46] IETF RFC 5031, A Uniform Resource Name (URN) for Emergency and Other Well-Known Services,
H. Schulzrinne, Jan. 2008.
[B47] IETF RFC 5139, Revised Civic Location Format for Presence Information Data Format Location
Object (PIDF-LO), M. Thomson, Feb. 2008.
[B48] International Code Council, Inc., International Building Code 2006, Nov. 2006, ISBN-13: 978-1-
58001-251-5.
[B49] ISO/IEC 14977:1996, Information technology — Syntactic metalanguage — Extended BNF.59
59
ISO/IEC publications are available from the ISO Central Secretariat (http://www.iso.ch/). ISO/IEC publications are also available in
the United States from the American National Standards Institute (http://www.ansi.org/).
2675
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
[B50] ITU Radio Regulations, volumes 1–4.60
[B51] ITU-R Recommendation TF.460-6 (2002), Standard-Frequency and Time-Signal Emissions.
[B52] ITU-T Recommendation V.41 (11/88), Code-independent error-control system.
[B53] ITU-T Recommendation V.42, Error-correcting procedures for DCEs using asynchronous-to-
synchronous conversion.
[B54] ITU-T Recommendation X.210 (11/93), Information technology—Open systems interconnection—
Basic Reference Model: Conventions for the definition of OSI services (common text with ISO/IEC 10731).
[B55] Maric, S. V., and Titlebaum, E. L., “A Class of Frequency Hop Codes with Nearly Ideal
Characteristics for Use in Multiple-Access Spread-Spectrum Communications and Radar and Sonar
Systems,” IEEE Transactions on Communications, vol. 40, no. 9, pp. 1442–1447, Sept. 1992.
[B56] NENA 08-002, Functional and Interface Standards for Next Generation 9-1-1 (i3), ver. 1.0, http://
www.nena.org/standards/technical/voip/functional-interface-NG911-i3.
[B57] Rumbaugh, J., Jacobson, I., and Booch, G., The Unified Modeling Language (UML) Reference
Manual (Second Edition), Reading, MA: Addison-Wesley Longman, 2004.
60
ITU, ITU-R, and ITU-T publications are available from the International Telecommunications Union (http://www.itu.int/).
2676
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex B
(normative)
Protocol Implementation Conformance Statement (PICS)
proforma
B.1 Introduction
The supplier of a protocol implementation that is claimed to comply with IEEE Std 802.11-2016 shall
complete the following protocol implementation conformance statement (PICS) proforma.
A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of
which capabilities and options of the protocol have been implemented. This annex might not be compatible
with operation in any Regulatory Domain or describe combinations of usable features in any Regulatory
Domain. The PICS has a number of uses, including use:
a) By the protocol implementer, as a checklist to reduce the risk of failure to comply with the standard
through oversight;
b) By the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of
the capabilities of the implementation, stated relative to the common basis for understanding
provided by the standard PICS proforma;
c) By the user, or potential user, of the implementation, as a basis for initially checking the possibility
of interworking with another implementation (note that, while interworking is not guaranteed,
failure to interwork can often be predicted from incompatible PICS proformas);
d) By a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for
compliance of the implementation.
B.2 Abbreviations and special symbols
B.2.1 Symbols for Status column
M mandatory
O optional
O. optional — Support of at least one of the group of options labeled by the same numeral is
required. The scope of the group of options is limited to a single table (i.e., subclause) within the
PICS.
pred: predicate identification
B.2.2 General abbreviations for Item and Support columns
N/A not applicable
AD address function
AVT audio video transport
CF implementation under test (IUT) configuration
DMG-M directional multi-gigabit (DMG) medium access control (MAC) features
DMG-P directional multi-gigabit (DMG) physical layer (PHY) features
DS direct sequence
DSE dynamic station enablement
2677
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ERP extended rate physical layer (PHY)
FR frame reception
FS frame exchange sequence
FT frame transmission
HRDS high rate direct sequence
HTM high-throughput (HT) medium access control (MAC) features
HTP high-throughput (HT) physical layer (PHY) features
HWM hybrid wireless mesh protocol (HWMP) path selection protocol capability
IW interworking with external networks
MD multidomain
MP mesh protocol
OC operating classes
OF orthogonal frequency division multiplexing (OFDM)
PC protocol capability
RM radio management
QB quality-of-service (QoS) base functionality
QD quality-of-service (QoS) enhanced distributed channel access (EDCA)
QMF quality-of-service Management frame
QP quality-of-service (QoS) hybrid coordination function (HCF) controlled channel access
(HCCA)
SM spectrum management
TDLS tunneled direct-link setup
TVHTM television very high throughput medium access control (MAC) features
TVHTP television very high throughput physical layer (PHY) features
TVWS television white spaces
VHTM Very high throughput MAC
VHTP Very high throughput PHY
WNM wireless network management
WS white spaces
B.3 Instructions for completing the PICS proforma
B.3.1 General structure of the PICS proforma
The first parts of the PICS proforma, Implementation identification and Protocol summary, are to be
completed as indicated with the information necessary to identify fully both the supplier and the
implementation.
The main part of the PICS proforma is a fixed questionnaire, divided into subclauses, each containing a
number of individual items. Answers to the questionnaire items are to be provided in the rightmost column,
either by simply marking an answer to indicate a restricted choice (usually Yes or No) or by entering a value
or a set or a range of values. (Note that there are some items where two or more choices from a set of
possible answers may apply. All relevant choices are to be marked in these cases.)
Each item is identified by an item reference in the first column. The second column contains the question to
be answered. The third column contains the reference or references to the material that specifies the item in
the main body of this standard. The remaining columns record the status of each item, i.e., whether support
is mandatory, optional, or conditional, and provide the space for the answers (see also B.3.4). Marking an
item as supported is to be interpreted as a statement that all relevant requirements of the subclauses and
normative annexes, cited in the References column for the item, are met by the implementation.
2678
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A supplier may also provide, or be required to provide, further information, categorized as either Additional
Information or Exception Information. When present, each kind of further information is to be provided in a
further subclause of items labeled A or X, respectively, for cross-referencing purposes, where is
any unambiguous identification for the item (e.g., simply a numeral). There are no other restrictions on its
format or presentation.
A completed PICS proforma, including any Additional Information and Exception Information, is the PICS
for the implementation in question.
NOTE—Where an implementation is capable of being configured in more than one way, a single PICS might be able to
describe all such configurations. However, the supplier has the choice of providing more than one PICS, each covering
some subset of the implementation’s capabilities, if this makes for easier and clearer presentation of the information.
B.3.2 Additional information
Items of Additional Information allow a supplier to provide further information intended to assist in the
interpretation of the PICS. It is not intended or expected that a large quantity of information will be supplied,
and a PICS can be considered complete without any such information. Examples of such Additional
Information might be an outline of the ways in which an (single) implementation can be set up to operate in
a variety of environments and configurations, or information about aspects of the implementation that are
outside the scope of this standard but have a bearing upon the answers to some items.
References to items of Additional Information may be entered next to any answer in the questionnaire, and
may be included in items of Exception Information.
B.3.3 Exception information
It may happen occasionally that a supplier wishes to answer an item with mandatory status (after any
conditions have been applied) in a way that conflicts with the indicated requirement. No preprinted answer
is found in the Support column for this. Instead, the supplier shall write the missing answer into the Support
column, together with an X reference to an item of Exception Information, and shall provide the
appropriate rationale in the Exception Information item itself.
An implementation for which an Exception Information item is required in this way does not comply with
this standard.
NOTE—A possible reason for the situation described above is that a defect in this standard has been reported, a
correction for which is expected to change the requirement not met by the implementation.
B.3.4 Conditional status
The PICS proforma contains a number of conditional items. These are items for which both the applicability
of the item itself, and its status if it does apply, mandatory or optional, are dependent upon whether certain
other items are supported.
Where a group of items is subject to the same condition for applicability, a separate preliminary question
about the condition appears at the head of the group, with an instruction to skip to a later point in the
questionnaire if the N/A answer is selected. Otherwise, individual conditional items are indicated by a
conditional symbol in the Status column.
A conditional symbol is of the form “:” or “O” (or “O.”), where “” is a predicate as
described below, and “” is one of the status symbols “M” or “O” (or “O.”).
2679
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the value of a predicate is true, the conditional symbol is applicable, and yields the status given by S. If
any applicable conditional symbol yields mandatory status, the conditional item has mandatory status.
Otherwise, if any applicable conditional symbol (including one of the form “O” (or “O.”)) yields
optional status, the conditional item has optional status. In either case, the support column is to be completed
in the usual way. If no conditional symbol is applicable, the conditional item is not relevant and the N/A
answer is to be marked.
A predicate is one of the following:
a) An item-reference for an item in the PICS proforma: the value of the predicate is true if the item is
marked as supported and is false otherwise.
b) An expression constructed by combining item-references using the boolean operators (in decreasing
order of precedence) “NOT”, “AND”, and “OR”, with or without the use of parenthetical groupings:
the value of the predicate is true if the expression evaluates to true and is false otherwise.
NOTE—If optional feature F1 requires features F2 and F3, this can be represented in the PICS in one of two ways:
— The status for conditional items F2 and F3 is “F1:M” and the status for conditional item F1 is “O”, or
— The status for conditional item F1 is “F2 AND F3:O”.
If feature F1 is required if feature F2 or F3 is supported, and is optional otherwise, this can be represented in the PICS in
one way:
— The status for conditional item F1 is “F2 OR F3:M” and “O”.
If feature F1 is required if feature F2 or F3 is supported, and is not relevant otherwise, this can be represented in the
PICS in one way:
— The status for conditional item F1 is “F2 OR F3:M”.
If feature F1 is required if feature F2 is supported, is optional if feature F3 is supported, and is not relevant otherwise,
this can be represented in the PICS in one way:
— The status for conditional item F1 is “F2:M” and “F3:O”.
Conditional symbols can be given in any order.
Each item referenced in a predicate, or in a preliminary question for grouped conditional items, is indicated
by an asterisk in the Item column.
2680
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4 PICS proforma—IEEE Std 802.11-201661
B.4.1 Implementation identification
Supplier
Contact point for queries about the PICS
Implementation Name(s) and Version(s)
Other information necessary for full identification, e.g.,
name(s) and version(s) of the machines and/or operating
system(s), system names
NOTE 1—Only the first three items are required for all implementations. Other information might be completed as
appropriate in meeting the requirement for full identification.
NOTE 2—The terms Name and Version need to be interpreted appropriately to correspond with a supplier’s
terminology (e.g., Type, Series, Model).
B.4.2 Protocol summary
Identification of protocol standard IEEE Std 802.11-2016
Identification of amendments and corrigenda to this Amd. : Corr. :
PICS proforma that have been completed as part of this
PICS Amd. : Corr. :
Have any exception items been required? Yes No
(See B.3.3; the answer Yes means that the
implementation does not comply with IEEE Std 802.11-
2016.)
Date of statement (yyyy-mm-dd)
61
Copyright release for PICS proforma: Users of this standard may freely reproduce the PICS proforma in this annex so that it can be
used for its intended purpose and may further publish the completed PICS.
2681
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.3 IUT configuration
Item IUT configuration References Status Support
What is the configuration of the IUT?
* CFAP Access point (AP) 4.3 O.1 Yes No
* Independent station (neither an AP, nor a 4.3 O.1 Yes No
CFIndepSTA mesh STA, nor a STA operating outside
the context of a BSS)
*CFSTAofA Operation in an infrastructure BSS 4.3 CFIndepSTA: Yes No N/A
P M
*CFIBSS Operation in an independent BSS (IBSS) 4.3 CFIndepSTA: Yes No N/A
O
*CF2.3 Reserved
*CFPBSS Operation in a PBSS 4.3.3 CFIndepSTA
AND
CFDMG:M
CFDMG:O.7
*CFPCP Operation as a PCP 4.3.3 CFPBSS:M Yes No
*CFPBSSnot Operation not as a PCP 4.3.3 CFPBSS:M Yes No
PCP
NOTE—See CFMBSS for mesh STA and CFOCB for OCB operation.
CF3 Reserved
* CFDSSS Direct sequence spread spectrum (DSSS) — O.2 Yes No
PHY for the 2.4 GHz band CFHRDSSS:
M
CF5 Reserved
* CFOFDM Orthogonal frequency division — O.2 Yes No
multiplexing (OFDM) PHY CFHT5G:M
CFTVHT:M
* High rate direct sequence spread — O.2 Yes No
CFHRDSSS spectrum (HR/DSSS) PHY CFERP:M
* CFMD Multidomain operation capability 10.21 O Yes No
implemented
* CFERP Extended Rate PHY (ERP) 18 O.2 Yes No
CF2G4:M
* CFSM Spectrum management 9.4.1.4, O Yes No
11.8, 11.9
*CFOC Operating classes capability 9.4.2.10, O Yes No N/A
implemented 17.3.8.4.2,
17.3.8.6,
17.4.2
Annex D,
Annex E
2682
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.3 IUT configuration (continued)
Item IUT configuration References Status Support
* CFQoS Quality of service (QoS) 10.22, O Yes No N/A
10.24,
4.3.13, CFHT OR
4.3.20.3 CFMBSS OR
CFQMF OR
CFAVT:M
CFDMG:M
CFTVHT:M
* CFRM Radio Measurement 9.4.1.4, (CFMD AND Yes No N/A
11.11 CFOC):O
*CFInfraST Infrastructure mode 4.3.4 CFAP OR Yes No N/A
A CFSTAofAP:
M
CFDMG:O.7
*CF3G6 3.65–3.70 GHz band in the United States 9.4.2.52, CFOFDM Yes No N/A
11.12, AND CFMD
17.3.6, AND CFSM
17.3.10.6, AND CFOC:O
Annex D,
Annex E
*CFHT High-throughput (HT) PHY 9.4.2.56 O.2 Yes No
CFVHT:M
* CFHT2G4 HT operation in 2.4 GHz band 19 CFHT:O.6 Yes No N/A
* CFHT5G HT operation in 5 GHz band 19 CFHT:O.6 Yes No N/A
CFVHT:M
*CF5G9 5.9 GHz band Annex E CFOFDM:O Yes No N/A
*CFTDLS Tunneled direct-link setup supported 11.23 O Yes No N/A
*CFWNM Wireless network management (WNM) ((CFMD AND Yes No N/A
CFOC AND
CFRM):O
*CFIW Interworking with external networks 9.4.2.27 O Yes No
service
*CFMBSS Operation in a mesh BSS (MBSS) 4.3.20 (NOT Yes No N/A
CFDMG):O.1
*CFQMF QoS management frame (QMF) policy 11.26 O Yes No N/A
*CFAVT Robust audio/video transport (AVT) 4.3.23 O Yes No
CF24 Reserved
*CFDMG Directional multi-gigabit (DMG) PHY 9.4.2.128 O.2 Yes No
CFDMG:M
*CFMBO Multi-band operation 9.6.21, At least two of Yes No N/A
11.32 CFDSSS,
CFOFDM,
CF3G6,
CF5G9,
CFDMG:O
*CFVHT Very High Throughput (VHT) features 9.4.2.158 O.2 Yes No
*CFTVHT TVWS Operation Annex D, O Yes No
Annex E
2683
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.3 IUT configuration (continued)
Item IUT configuration References Status Support
*CFOCB Operation outside the context of a BSS 11.21 O.1 Yes No
(OCB) CF5G9:M
*CFESM Extended spectrum management 10.21.3 O Yes No
CFVHT OR
CFTVHT:M
B.4.4 MAC protocol
B.4.4.1 MAC protocol capabilities
Item Protocol capability References Status Support
Are the following MAC protocol
capabilities supported?
PC1 Authentication service 4.5.4.2, 4.5.4.3, CFInfraSTA Yes No N/A
11.21, 12.2 AND not
CFDMG:M
CFIBSS OR
CFDMG:M
PC1.1 Authentication state 11.3 PC1:M Yes No
PC1.2 Open System authentication 12.2.2 PC1 AND not Yes No
CFDMG:M
PC1.3 Shared Key authentication 12.2.3, 12.5 PC2:M Yes No N/A
* PC2 Wired equivalent privacy (WEP) 4.5.4.4, 12.3.2 O Yes No
algorithm This capability is
deprecated (applicable only to
systems that are backward
compatible).
PC2.1 WEP encryption procedure 12.3.2 PC2:M Yes No N/A
PC2.2 WEP decryption procedure 12.3.2 PC2:M Yes No N/A
PC3 Distributed coordination function 10.2, 10.3 M Yes No
(DCF)
PC3.1 Network allocation vector 10.3.2.1, 10.3.4, M Yes No
(NAV) function 10.4.3.3
PC3.2 Interframe space usage and 10.3.2.3, 10.3.4, M Yes No
timing 10.3.7
PC3.3 Random Backoff function 10.3.3 M Yes No
PC3.4 DCF Access procedure 10.3.4.2, 10.3.4.5 M Yes No
PC3.5 Random Backoff procedure 10.3.4.3 M Yes No
PC3.6 Recovery procedures and 10.3.4.4 M Yes No
retransmit limits
PC3.7 Request to send (RTS)/clear 10.3.2.4, M Yes No
to send (CTS) procedure 10.3.2.5, 10.3.2.7
PC3.8 Individually addressed MAC 10.3.5 M Yes No
protocol data unit (MPDU)
transfer
2684
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.1 MAC protocol capabilities (continued)
Item Protocol capability References Status Support
PC3.9 Group addressed MPDU 10.3.6 M Yes No
transfer
PC3.10 MAC-level acknowledgment 10.3.2.2, 10.3.2.9 M Yes No
PC3.11 Duplicate detection and 10.3.2.11 M Yes No
recovery
PC3.12 Dynamic EIFS 10.3.7 O Yes No
* PC4 Point coordinator 10.2, 10.4 not CFDMG Yes No N/A
The PCF mechanism is obsolete. AND
Consequently, this option may be CFAP:O
removed in a later revision of the
standard.
PC4.1 Maintenance of contention 10.4.2, 10.4.3 PC4:M Yes No N/A
free period (CFP) structure
and timing
PC4.2 Point coordination function 10.4.4 PC4:M Yes No N/A
(PCF) MPDU transfer from
point coordinator
* PC4.3 PCF MPDU transfer to point 10.4.4 PC4:O Yes No N/A
coordinator
PC4.4 Overlapping point coordinator 10.4.4.3 PC4:M Yes No N/A
provisions
PC4.5 Polling list maintenance 10.4.5 PC4.3:M Yes No N/A
* PC5 Contention free (CF)-Pollable 10.2, 10.4 not CFDMG Yes No N/A
The PCF mechanism is obsolete. AND
Consequently, this option may be CFSTAofAP:
removed in a later revision of the O
standard.
PC5.1 Interpretation of CFP 10.4.2, 10.4.3 PC5:M Yes No N/A
structure and timing
PC5.2 PCF MPDU transfer to/from 10.4.4 PC5:M Yes No N/A
and CF-Pollable station (STA)
PC5.3 Polling list update 10.4.5 PC5:M Yes No N/A
PC6 Fragmentation 10.3, 10.5 M Yes No
PC7 Defragmentation 10.3, 10.6 M Yes No
PC8 MAC data service 10.2.8, 10.8 M Yes No
PC8.1 ReorderableGroupAddressed 10.8 M Yes No
service class
PC8.2 StrictlyOrdered service class 10.8 O Yes No
Note that the use of the
StrictlyOrdered service class is
obsolete and the StrictlyOrdered
service class might be removed in
a future revision of the standard.
PC9 Multirate support 10.7 M Yes No
PC9.1 Rate selection using Rx Supported 10.7.12.1, CFVHT:M Yes No N/A
VHT-MCS and NSS Set / Tx 10.7.12.2 CFTVHT:M
Supported VHT-MCS and NSS Set
2685
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.1 MAC protocol capabilities (continued)
Item Protocol capability References Status Support
PC9.2 Rate selection constraints for VHT 10.7.12.3 CFVHT:O Yes No N/A
PPDUs CFTVHT:O
* PC10 Multiple outstanding MAC 10.8 O Yes No
service data unit (MSDU)
support
PC10.1 Multiple outstanding MSDU 10.8 PC10:M Yes No N/A
transmission restrictions
PC11 Timing synchronization function 11.1 CFAP OR Yes No
(TSF) CFIndepSTA:
M
PC11.1 Timing in an infrastructure 11.1.2.1, 11.1.5 CFInfraSTA: Yes No N/A
network M
PC11.2 Timing in an independent 11.1.2.2, 11.1.5 CFIBSS:M Yes No N/A
basic service set (IBSS)
PC11.3 Beacon generation function 11.1.3 CFAP OR Yes No
CFIBSS OR
CFPCP:M
PC11.4 TSF synchronization and 11.1.2, 11.1.3 CFAP OR Yes No N/A
accuracy CFIndepSTA:
M
PC11.5 Infrastructure basic service set 11.1.4 CFAP:M Yes No N/A
(BSS) initialization
PC11.6 IBSS initialization 11.1.4 CFIBSS:M Yes No N/A
PC11.7 Passive scanning 11.1.4 (CFSTAofAP Yes No N/A
OR CFIBSS
OR
CFPBSSnotP
CP):O.1
PC11.8 Active scanning 11.1.4 (CFSTAofAP Yes No N/A
OR CFIBSS
OR
CFPBSSnotP
CP):O.1
PC11.9 Probe response 11.1.4 (NOT Yes No N/A
CFOCB):M
PC11.10 Reserved
PC12 Infrastructure power management 11.2.3 CFInfraSTA Yes No N/A
AND not
CFDMG:M
PC12.1 STA power management 11.2.3.2, 11.2.3.9 (CFSTAofAP Yes No N/A
modes or
CFIBSS):M
PC12.2 Traffic indication map (TIM) 11.2.3.3, 11.2.3.4 CFAP:M Yes No N/A
transmission
PC12.3 AP function during contention 11.2.3.6 CFAP:M Yes No N/A
period (CP)
PC12.4 AP function during CFP 11.2.3.7 PC4:M Yes No N/A
PC12.5 Non-AP STA receive function 11.2.3.8 CFSTAofAP: Yes No N/A
during CP M
2686
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.1 MAC protocol capabilities (continued)
Item Protocol capability References Status Support
PC12.6 Non-AP STA receive function 11.2.3.9 PC5:M Yes No N/A
during CFP
PC12.7 Aging function 11.2.3.12 CFAP:M Yes No N/A
PC13 IBSS power management 11.2.4 CFIBSS:M Yes No N/A
PC13.1 Initialization of power 11.2.4.3 CFIBSS:M Yes No N/A
management
PC13.2 STA power state transitions 11.2.4.4 CFIBSS:M Yes No N/A
PC13.3 Announcement traffic f CFIBSS:M Yes No N/A
indication message (ATIM)
and frame transmission
*PC14 (Re)Association 4.5, 11.3, 11.3.5, CFInfraSTA Yes No N/A
OR
CFPCP:M
CFPBSSnotP
CP:O
PC14.1 Association state 11.3.5 PC14:M Yes No N/A
PC14.2 STA association procedure 11.3.5.2 CFSTAofAP: Yes No N/A
M
CFPBSSnotP
CP:O
PC14.3 AP association procedure 11.3.5.3 CFAP OR Yes No N/A
CFPCP:M
PC14.4 STA reassociation procedure 11.3.5.4 CFSTAofAP: Yes No N/A
M
CFPBSSnotP
CP:O
PC14.5 AP reassociation procedure 11.3.5.5 CFAP OR Yes No N/A
CFPCP:M
PC15 Management information base Annex C M Yes No
(MIB)
PC15.1 dot11SMTbase, Annex C M Yes No
dot11SmtAuthenticationAlgor
ithms
* PC15.2 dot11SMTprivacy Annex C PC2:M Yes No N/A
PC15.3 dot11MACbase, Annex C M Yes No
dot11CountersGroup,
dot11GroupAddressesTable
* PC15.4 dot11MACStatistics Annex C O Yes No
PC15.5 dot11ResourceTypeID Annex C M Yes No
PC16 Set 9.4.1.4 CFERP:M Yes No N/A
dot11ShortPreambleOptionImple
mented to 1
PC17 Reserved
PC18 Reserved
PC19 Reserved
PC20 Set Short Slot Time subfield as 9.4.1.4 CFERP:M Yes No N/A
described in reference
2687
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.1 MAC protocol capabilities (continued)
Item Protocol capability References Status Support
PC21 Monitor each received short time 9.4.1.4 CFERP:M Yes No N/A
slot subfield and take action as
described in reference.
PC22 Transmit the ERP element in each 9.4.1.4 CFERP:M Yes No N/A
transmitted Beacon or Probe
Response frame in the format and
with content as described in
reference
PC23 Receive the ERP element and 9.4.1.4 CFERP:M Yes No N/A
employ a protection mechanism
when required prior to transmitting
information using ERP-OFDM
modulation
PC24 Determine the value of aCWmin 10.3.9 CFERP:M Yes No N/A
based on the characteristic rate set
as described in the reference
PC25 Transmit control response frames 10.7 CFERP:M Yes No N/A
at the largest basic rates less than
equal to the rate received and with
the same PHY options or use the
highest mandatory rate if no basic
rate meets the above criterion
PC26 Transmit group addressed frames 10.7 CFERP:M Yes No N/A
at a rate contained in the
BSSBasicRateSet parameter
PC27 Transmit individually addressed 10.7 CFERP:M Yes No N/A
frames at any supported rate
selected by a rate switching
mechanism as long as it is
supported by the destination STA
PC28 Reserved
PC29 Use ERP element to control use of 10.26 CFERP:M Yes No N/A
protection mechanism as described
in the reference
PC30 Updated NAV is long enough to 10.26 CFERP:M Yes No N/A
cover frame and any response
PC31 Support transmission of CTS-to- 10.3.2.12 CFERP:O Yes No N/A
self sequence as described in the CFTVHT:O
references
PC32 Support reception of CTS-to-self 10.3.2.12 CFERP:M Yes No N/A
sequence as described in the CFTVHT:M
references
PC33 Update NAV 10.26 CFERP:M Yes No N/A
* PC34 Robust security network 9.3.2.1, 9.4.1.4, O Yes No
association (RSNA) 4.5.4.4,
11.3.4, 11.3.5,
12.9.2, 12.9.2.2,
12.9.2.4,
12.9.2.6,
12.9.2.8, 12.5.3
PC34.1 RSNE 9.4.2.25 PC34:M Yes No N/A
2688
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.1 MAC protocol capabilities (continued)
Item Protocol capability References Status Support
PC34.1.1 Group cipher suite 9.4.2.25 PC34.1:M Yes No N/A
PC34.1.2 Pairwise cipher suite list 9.4.2.25 PC34.1:M Yes No N/A
PC34.1.2.1 Counter mode with cipher-block 12.5.3 PC34:M Yes No N/A
chaining message authentication
code protocol (CCMP) data
confidentiality protocol using
CCMP-128
PC34.1.2.1.1 CCMP cryptographic 12.5.3.3 PC34.1.2.1:M Yes No N/A
encapsulation procedure using
CCMP-128
PC34.1.2.1.2 CCMP decapsulation procedure 12.5.3.4 PC34.1.2.1:M Yes No N/A
using CCMP-128
PC34.1.2.2 Temporal key integrity protocol 12.5.2 PC34:O Yes No N/A
(TKIP) data confidentiality
protocol
PC34.1.2.2.1 TKIP cryptographic 12.5.2.1.2 PC34.1.2.2:M Yes No N/A
encapsulation procedure
PC34.1.2.2.2 TKIP decapsulation procedure 12.5.2.1.3 PC34.1.2.2:M Yes No N/A
PC34.1.2.2.3 TKIP countermeasures 12.5.2.4 PC34.1.2.2:M Yes No N/A
PC34.1.2.2.4 TKIP security services 12.5.2.3 PC34.1.2.2:M Yes No N/A
management
PC34.1.2.3 Galois/counter mode protocol 12.5.5 (CFDMG and Yes No N/A
(GCMP) PC34):M
*PC34.1.3 Authentication key management 9.4.2.25, 12.5.1 PC34.1:M Yes No N/A
(AKM) suite list
PC34.1.3.1 IEEE 802.1X-defined/RSNA key 9.4.2.25 PC34.1:M Yes No N/A
management
PC34.1.3.2 Preshared key (PSK)/ 9.4.2.25 PC34.1:M Yes No N/A
RSNA key management
PC34.1.3.3 RSNA key management 12.7 PC34.1:M Yes No N/A
PC34.1.3.3.1 Key hierarchy 12.7, 12.8 PC34.1:M Yes No N/A
PC34.1.3.3.1.1 Pairwise key hierarchy 12.7.1.3 PC34.1:M Yes No N/A
PC34.1.3.3.1.2 Group key hierarchy 12.7.1.4 PC34.1:M Yes No N/A
PC34.1.3.3.2 4-way handshake 12.7.6 PC34.1:M Yes No N/A
PC34.1.3.3.3 Group key handshake 12.7.7 PC34.1:M Yes No N/A
PC34.1.4 RSN capabilities 9.4.2.25, 12.2.3 PC34.1:M Yes No N/A
PC34.1.5 RSNA preauthentication 12.6.10.2 PC34.1:O Yes No N/A
PC34.1.6 RSNA security association 12.6 PC34.1:M Yes No N/A
management
2689
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.1 MAC protocol capabilities (continued)
Item Protocol capability References Status Support
PC34.1.7 RSNA pairwise master key 12.6.1, 12.6.10.3 PC34.1:M Yes No N/A
security association (PMKSA)
caching
PC34.1.8 RSNA extended service set (ESS) 12.6.10, 12.6.14 (PC34.1 and Yes No N/A
CFAP):M
PC34.1.8.1 RSNA PeerKey handshake 12.7.8 PC34.1.8:O Yes No N/A
PC34.1.9 RSNA IBSS 12.6.5, 12.6.11, (PC34.1 and Yes No N/A
12.6.15 CFIBSS):O
*PC 34.1.10 Management frame protection 9.2.4.1.10, PC34:O Yes No N/A
9.4.1.11,
9.4.2.25.4, 9.6.3,
12.3.3.3.5,
12.5.2.1.2,
12.5.2.1.3,
12.5.2.2,
12.5.3.3.3,
12.5.3.3.6,
12.5.3.4.2,
12.5.3.4.4,
12.6.3, 12.9.2.3,
12.9.2.5,
12.9.2.7, 12.9.2.9
*PC 34.1.10.1 BIP 11, 12.5.4 PC34.1.10:M Yes No N/A
PC 34.1.10.1.1 Management MIC element 9.4.2.55 PC34.1.10.1: Yes No N/A
M
PC 34.1.11 AKM: IEEE 802.1X 9.4.2.25, 12.7 PC34:O Yes No N/A
authentication with SHA-256 PRF
PC 34.1.12 AKM: PSK with SHA-256 PRF 9.4.2.25, 12.7 PC34:O Yes No N/A
PC34.1.13 RSNA rekeying 12.6.21 PC34:O Yes No N/A
PC34.1.14 Multi-band RSNA 12.6.22 CFMBO Yes No N/A
AND
PC34:M
*PC35 Fast basic service set (BSS) 13 CFInfraSTA: Yes No N/A
transition (FT) O
PC35.1 Mobility Domain element (MDE) 9.4.2.47 PC35:M Yes No N/A
PC35.2 Fast basic service set (BSS) 9.4.2.48 PC35 AND Yes No N/A
Transition element (FTE) PC34:M
PC35.3 Timeout Interval element (TIE) 9.4.2.49 PC35:M Yes No N/A
PC35.4 Fast basic service set (BSS) 9.4.1.1 PC35:M Yes No N/A
Transition (FT) authentication
algorithm
PC35.5 Fast basic service set (BSS) 9.6.9 PC35:M Yes No N/A
Transition (FT) Action frames
PC35.6 Fast basic service set (BSS) 9.4.2.25, 12.7.1.7 PC35 AND Yes No N/A
Transition (FT) key management PC34:M
based on IEEE Std 802.1X
2690
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.1 MAC protocol capabilities (continued)
Item Protocol capability References Status Support
PC35.7 Fast basic service set (BSS) 9.4.2.25, 12.7.1.7 PC35 AND Yes No N/A
Transition (FT) key management PC34:M
based on preshared keys (PSKs)
PC35.8 Fast basic service set (BSS) 12.7.1.7 PC35 AND Yes No N/A
Transition (FT) key hierarchy PC34:M
PC35.9 FT initial mobility domain 13.4 PC35 AND Yes No N/A
association PC34:M
PC35.10 Fast Basic Service Set (BSS) 13.5 PC35:M Yes No N/A
Transition (FT) Protocol
PC35.10.1 Fast Basic Service Set (BSS) 13.5.2, 13.5.3, PC35 AND Yes No N/A
Transition (FT) Protocol in robust 13.7.1 PC34:M
security network (RSN)
PC35.10.2 Fast Basic Service Set (BSS) 13.5.4, 13.5.5, PC35:M Yes No N/A
Transition (FT) Protocol in 13.7.2
nonrobust security network (non-
RSN)
*PC35.11 Fast Basic Service Set (BSS) 13.6 PC35:O Yes No N/A
transition (FT) resource request
protocol
PC35.11.1 Resource Request protocol over 13.6.2 PC35.11:M Yes No N/A
the air
PC35.11.2 Resource Request protocol over 13.6.3, 13.10 PC35.11:M Yes No N/A
the distribution system (DS)
PC35.12 QoS procedures for fast basic 13.11 (CFQoS AND Yes No N/A
service set (BSS) transition PC35 or
CFDMG
AND
PC35):M
*PC35.13 Resource Information Container 9.4.2.50, 13.11 PC35:M Yes No N/A
(RIC) Data element (RDE)
PC35.13.1 Resource Request Procedures at 13.11.3.1 PC35.13:M Yes No N/A
the fast basic service set (BSS)
transition originator (FTO)
PC35.13.2 Resource Request Procedures at 13.11.3.2 PC35.13:M Yes No N/A
the target access point (AP)
*PC35.14 Remote Request Procedures at the 13.10 PC35:M Yes No N/A
current access point (AP)
PC35.14.1 Remote Request/Response frame 13.10.3 PC35.14:O Yes No N/A
support
PC35.14.2 Vendor-specific remote request 13.10.3 PC35.14:O Yes No N/A
broker (RRB) mechanism
PC36 SA Query Procedure 9.6.10, 11.14 PC34.1.10:M Yes No N/A
*PC37 Power save multi-poll (PSMP) 9.6.12.4, 10.29 not Yes No
CFDMG:O
*PC37.1 Scheduled PSMP 9.4.2.30, 11.4.6 PC37:M Yes No N/A
PC37.1.1 PSMP additions to TSPEC 9.4.2.30 PC37.1:M Yes No N/A
PC37.1.2 AP role in scheduled PSMP 10.29.2.2, (PC37.1 AND Yes No N/A
sequence 10.29.2.3 CFAP):M
2691
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.1 MAC protocol capabilities (continued)
Item Protocol capability References Status Support
PC37.1.3 STA role in scheduled PSMP 10.29.2.2, (PC37.1 AND Yes No N/A
sequence 10.29.2.3 CFIndepSTA)
:M
*PC37.2 Unscheduled PSMP 10.29.4 PC37:M Yes No N/A
PC37.2.1 PSMP additions to TSPEC 9.4.2.30 (CFAP AND Yes No N/A
PC37.2):M
(CFIndepSTA
AND
PC37.2):O
PC37.3 Creation, scheduling, and 9.6.12.4, (PC37 AND Yes No N/A
transmission of PSMP frame 10.29.2.1 CFAP):M
PC37.4 Reception and interpretation of 9.6.12.4 (PC37 AND Yes No N/A
PSMP frame CFIndepSTA)
:M
PC37.5 Multi-TID block ack rules in 9.3.1.8.5, PC37:M Yes No N/A
PSMP sequence 9.3.1.9.4,
10.29.2.7,
11.17.2
PC37.6 Multi-phase PSMP 10.29.2.5 PC37:M Yes No N/A
PC38 dot11OCBActivated is false when 11.21 (CFSTAofAP Yes No N/A
STA is a BSS member OR
CFIBSS):M
PC39 Simultaneous authentication of 12.4 CFMBSS:M Yes No N/A
equals (SAE)
*PC40 Multi-band Operation 11.33 CFMBO:O Yes No N/A
*PC40.1 FST Setup 9.4.2.138, PC40:M Yes No N/A
9.4.2.151,
9.4.2.152,
9.6.21.2,
9.6.21.3,
9.6.21.5,
9.6.21.6,
11.33.2.1,
11.33.2.2
PC40.2 FST TS switching 9.4.2.30, PC40.1:M Yes No N/A
9.4.2.141,
9.6.3.2.2,
9.6.3.3.2, 9.6.3.4,
9.6.5.2, 9.6.5.3,
9.6.5.4, 11.33.2.3
PC40.3 FST Teardown
PC40.3.1 Transmission of FST Teardown 9.6.21.4, 11.33.3 PC40.1:O Yes No N/A
PC40.3.2 Reception of FST Teardown 9.6.21.4, 11.33.3 PC40.1:M Yes No N/A
PC41 MMSL cluster operation 11.34 O Yes No N/A
PC42 Quieting adjacent BSS operation 11.37 O Yes No N/A
PC43 Beacon RSSI 11.45 O Yes No N/A
PC44 Estimated throughput 11.46 O Yes No N/A
2692
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.2 MAC frames
Item MAC frame References Status Support
Is transmission of the following 9
MAC frames supported?
FT1 Association Request 9 CFSTAofAP:M Yes No N/A
CFPBSSnotPC
P:O
FT2 Association Response 9 (CFAP OR Yes No N/A
CFPCP):M
FT3 Reassociation Request 9 CFSTAofAP:M Yes No N/A
CFPBSSnotPC
P:O
FT4 Reassociation Response 9 (CFAP OR Yes No N/A
CFPCP):M
FT5 Probe Request 9 (CFSTAofAP Yes No N/A
or CFIBSS OR
CFPBSSnotPC
P OR
CFMBSS):M
FT6 Probe Response 9 (CFAP OR Yes No N/A
CFIBSS OR
CFPCP OR
CFMBSS):M
FT7 Beacon 9 (CFAP OR Yes No N/A
CFIBSS OR
CFMBSS)
AND not
CFDMG:M
FT8 ATIM 9 CFIBSS:M Yes No N/A
FT9 Disassociation 9 CFInfraSTA:M Yes No N/A
CFPBSS:O
FT10 Authentication 9 CFInfraSTA:M Yes No N/A
CFIBSS OR
CFPBSS:O
FT11 Deauthentication 9 (NOT Yes No N/A
CFOCB):M
not CFDMG:M
FT12 Power save (PS)-Poll 9 not CFDMG Yes No N/A
AND
CFSTAofAP:M
FT13 RTS 9 M Yes No
FT14 CTS 9 not CFDMG:M Yes No
FT15 Acknowledgment (Ack) 9 M Yes No
FT16 CF-End 9 not CFDMG Yes No N/A
AND PC4:M
O
FT17 CF-End +CF-Ack 9 not CFDMG Yes No N/A
AND PC4:M
FT18 Data 9 not CFDMG:M Yes No
FT19 Data +CF-Ack 9 not CFDMG Yes No N/A
AND (PC4 OR
PC5):M
2693
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.2 MAC frames (continued)
Item MAC frame References Status Support
FT20 Data +CF-Poll 9 not CFDMG Yes No N/A
AND PC4.3:M
FT21 Data +CF-Ack +CF-Poll 9 not CFDMG Yes No N/A
AND PC4.3:M
FT22 Null 9 not CFDMG:M Yes No
FT23 CF-Ack (no data) 9 not CFDMG Yes No N/A
AND (PC4 OR
PC5):M
FT24 CF-Poll (no data) 9 not CFDMG Yes No N/A
AND PC4.3:M
FT25 CF-Ack +CF-Poll (no data) 9 not CFDMG Yes No N/A
AND PC4.3:M
FT26 Timing Advertisement frame 9 O Yes No
FT27 QoS Data 9 CFQoS:M Yes No N/A
FT28 QoS Null (no data) 9 CFQoS:M Yes No N/A
FT29 BlockAckReq 9 CFDMG:M Yes No N/A
CFQoS:O
FT30 BlockAck 9 CFDMG:M Yes No N/A
CFQoS:O
CFHT:M
FT31 Poll 9 CFDMG:M Yes No N/A
FT32 SPR 9 CFDMG:M Yes No N/A
FT33 Grant 9 CFDMG:M Yes No N/A
FT34 DMG CTS 9 CFDMG:M Yes No N/A
FT35 DMG DTS 9 CFDMG:M Yes No N/A
FT36 SSW 9 CFDMG:M Yes No N/A
FT37 SSW-Feedback 9 CFDMG:M Yes No N/A
FT38 SSW-Ack 9 CFDMG:M Yes No N/A
FT39 DMG Beacon 9 CFDMG:M Yes No N/A
FT40 VHT NDP Announcement 9 VHTM4.1:M Yes No N/A
TVHTM4.1:M
FT41 Beamforming Report Poll 9 VHTM4.1:O Yes No N/A
VHTM4.3:M
TVHTM4.1:O
TVHTM4.3:M
FT42 Transmission of Operating Mode 9.6.23.4, O Yes No N/A
Notification frame and Operating 9.4.2.166,
Mode Notification element 11.42
Is reception of the following MAC 9
frames supported?
*FR1 Association Request 9 (CFAP OR Yes No N/A
CFPCP):M
*FR2 Association Response 9 (CFSTAofAP1 Yes No N/A
OR
CFPBSSnotPC
P):M
2694
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.2 MAC frames (continued)
Item MAC frame References Status Support
FR3 Reassociation Request 9 (CFAP OR Yes No N/A
CFPCP):M
FR4 Reassociation Response 9 (CFSTAofAP Yes No N/A
OR
CFPBSSnotPC
P):M
FR5 Probe Request 9 (CFAP OR Yes No N/A
CFIBSS OR
CFPCP OR
CFMBSS):M
FR6 Probe Response 9 (CFSTAofAP Yes No N/A
OR CFIBSS
OR
CFPBSSnotPC
P OR
CFMBSS):M
FR7 Beacon 9 (NOT Yes No N/A
CFOCB):M
not CFDMG:M
FR8 ATIM 9 (CFSTAofAP Yes No N/A
OR CFIBSS
OR CFMBSS)
AND not
CFDMG:M
FR9 Disassociation 9 FR1 OR FR2:M Yes No N/A
FR10 Authentication 9 CFAP AND not Yes No N/A
CFDMG:M
CFIBSS OR
CFPBSS OR
(CFAP AND
CFDMG):O
FR11 Deauthentication 9 FR10:M Yes No N/A
FR12 PS-Poll 9 CFAP:M Yes No N/A
FR13 RTS 9 M Yes No
FR14 CTS 9 not CFDMG:M Yes No
FR15 Ack 9 M Yes No
FR16 CF-End 9 (NOT Yes No N/A
CFOCB):M
FR17 CF-End +CF-Ack 9 not CFDMG Yes No N/A
AND (PC4 OR
PC5):M
FR18 Data 9 not CFDMG:M Yes No
FR19 Data +CF-Ack 9 (NOT Yes No N/A
CFOCB):M
not CFDMG:M
FR20 Data +CF-Poll 9 not CFDMG Yes No N/A
AND PC5:M
FR21 Data +CF-Ack +CF-Poll 9 not CFDMG Yes No N/A
AND PC5:M
FR22 Null 9 not CFDMG:M Yes No
2695
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.2 MAC frames (continued)
Item MAC frame References Status Support
FR23 CF-Ack (no data) 9 not CFDMG Yes No N/A
AND (PC4 OR
PC5):M
FR24 CF-Poll (no data) 9 not CFDMG Yes No N/A
AND PC5:M
FR25 CF-Ack +CF-Poll (no data) 9 not CFDMG Yes No N/A
AND PC5:M
FR26 Timing Advertisement frame 9 O Yes No
FR27 QoS Data 9 CFQoS:M Yes No N/A
FR28 QoS Null (no data) 9 CFQoS:M Yes No N/A
FR29 BlockAckReq 9 CFQoS:O Yes No N/A
HTM3.1:M
FR30 BlockAck 9 CFQoS:O Yes No N/A
HTM3.5:M
FR31 Poll 9 CFDMG:M Yes No N/A
FR32 SPR 9 CFDMG:M Yes No N/A
FR33 Grant 9 CFDMG:M Yes No N/A
FR34 DMG CTS 9 CFDMG:M Yes No N/A
FR35 DMG DTS 9 CFDMG:M Yes No N/A
FR36 Reserved
FR37 SSW 9 CFDMG:M Yes No N/A
FR38 SSW-Feedback 9 CFDMG:M Yes No N/A
FR39 SSW-Ack 9 CFDMG:M Yes No N/A
FR40 DMG Beacon 9 (CFSTAofAP Yes No N/A
OR CFIBSS
OR CFPBSS)
AND
CFDMG:M
FR41 VHT NDP Announcement 9 VHTM4.2:M Yes No N/A
TVHTM4.2:M
FR42 Beamforming Report Poll 9 VHTM4.2:O Yes No N/A
VHTM4.4:M
TVHTM4.2:O
TVHTM4.4:M
FR43 Reception of Operating Mode 9.6.23.4, CFVHT:M Yes No N/A
Notification frame and Operating 9.4.2.166, CFTVHT:M
Mode Notification element 11.42
2696
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.4.3 Frame exchange sequences
Frame exchange
Item References Status Support
sequence
Are the following frame
exchange sequences
supported?
FS1 Basic frame exchange 10.3.2.5, 10.3.2.7, M Yes No
sequences 10.3.2.9, 10.3.5, 10.3.6,
10.4.3
FS2 CF-frame exchange 10.4.3, 10.4.4 (PC4 OR PC5):M Yes No N/A
sequences
B.4.4.4 MAC addressing functions
Item MAC Address function References Status Support
Are the following MAC Addressing
functions supported?
AD1 STA universal individual IEEE 802 9.2.4.3 M Yes No
address
AD2 BSS identification (BSSID) 9.2.4.3, 11.1.4 M Yes No
generation
AD3 Receive address matching 9.2.4.3, 9.3.2.1 M Yes No
AD4 Wildcard BSSID 9.2.4.3.4, 9.3.2 CFOCB:M Yes No N/A
AD5 MAC and PHY operation resumes with 11.21 CFOCB:M Yes No N/A
appropriate MIB attributes in less than
2 TU
AD6 Group addressed mesh Data frame 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A
addressing (3 address frame) 9.2.4.3, 9.3.5
AD7 Individually addressed mesh Data frame 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A
addressing (4 address frame) 9.2.4.3, 9.3.5
AD8 Proxied group addressed mesh Data 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A
frame addressing (4 address frame) 9.2.4.3,
9.2.4.7.3, 9.3.5
AD9 Proxied individually addressed mesh 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A
Data frame addressing (6 address frame) 9.2.4.3,
9.2.4.7.3, 9.3.5
AD10 Multihop Action frame addressing (4 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A
address frame) 9.2.4.3,
9.2.4.7.3,
9.6.18, 9.3.5
AD11 TA filtering for mesh STA 9.2.4.3, 9.3.2.1, CFMBSS:M Yes No N/A
9.3.5
2697
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.5 Direct sequence PHY functions
Item PHY feature References Status Support
PHY sublayer procedures 15.3
DS1 Preamble prepend on transmit (TX) 15.3.1 M Yes No
DS1.1 PHY frame format 15.3.2, 15.3.3 M Yes No
DS1.2 PHY integrity check generation 15.3.3, 15.3.3.7 M Yes No
DS1.3 TX rate change capability 15.2.3.4, 15.3.5 M Yes No
DS1.4 Supported data rates 15.1, 15.2.3.4 M Yes No
DS1.5 Data whitener scrambler 15.3.4 M Yes No
DS1.6 Scrambler initialization 15.3.4 M Yes No
DS2 Preamble process on receive (RX) 15.3.1
DS2.1 PHY frame format 15.3.2, 15.3.3 M Yes No
DS2.2 PHY integrity check verify 15.3.3, 15.3.3.7 M Yes No
DS2.3 RX Rate change capability 15.2.3.4, 15.3.5 M Yes No
DS2.4 Data whitener descrambler 15.3.4 M Yes No
DS3 Pseudonoise (PN) code sequence 15.4.4.4 M Yes No
DS4 Chipping continue on power-down 15.3.6 O Yes No
*DS5 Operating channel capability 15.3.6, 15.4.4.3
* DS5.1 North America (FCC) 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A
DS5.1.1 Channel 1 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.2 Channel 2 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.3 Channel 3 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.4 Channel 4 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.5 Channel 5 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.6 Channel 6 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.7 Channel 7 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.8 Channel 8 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.9 Channel 9 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.10 Channel 10 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
DS5.1.11 Channel 11 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A
* DS5.2 Canada (IC) 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A
DS5.2.1 Channel 1 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.2 Channel 2 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.3 Channel 3 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.4 Channel 4 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.5 Channel 5 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.6 Channel 6 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.7 Channel 7 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.8 Channel 8 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.9 Channel 9 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
DS5.2.10 Channel 10 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
2698
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.5 Direct sequence PHY functions (continued)
Item PHY feature References Status Support
DS5.2.11 Channel 11 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A
* DS5.3 Europe (ETSI) 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A
DS5.3.1 Channel 1 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.2 Channel 2 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.3 Channel 3 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.4 Channel 4 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.5 Channel 5 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.6 Channel 6 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.7 Channel 7 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.8 Channel 8 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.9 Channel 9 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.10 Channel 10 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.11 Channel 11 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.12 Channel 12 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
DS5.3.13 Channel 13 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A
* DS5.4 France 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A
DS5.4.1 Channel 10 15.3.6, 15.4.4.3 DS5.4:M Yes No N/A
DS5.4.2 Channel 11 15.3.6, 15.4.4.3 DS5.4:M Yes No N/A
DS5.4.3 Channel 12 15.3.6, 15.4.4.3 DS5.4:M Yes No N/A
DS5.4.4 Channel 13 15.3.6, 15.4.4.3 DS5.4:M Yes No N/A
* DS5.5 Spain 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A
DS5.5.1 Channel 10 15.3.6, 15.4.4.3 DS5.5:M Yes No N/A
DS5.5.2 Channel 11 15.3.6, 15.4.4.3 DS5.5:M Yes No N/A
* DS5.6 Japan 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A
* DS5.7 China 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A
DS5.7.1 Channel 1 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.2 Channel 2 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.3 Channel 3 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.4 Channel 4 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.5 Channel 5 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.6 Channel 6 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.7 Channel 7 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.8 Channel 8 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.9 Channel 9 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.10 Channel 10 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.11 Channel 11 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.12 Channel 12 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS5.7.13 Channel 13 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A
DS6 Bits to symbol mapping 15.4.4.5
DS6.1 1 Mb/s 15.4.4.5 M Yes No
2699
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.5 Direct sequence PHY functions (continued)
Item PHY feature References Status Support
DS6.2 2 Mb/s 15.4.4.5 M Yes No
*DS7 CCA functionality 15.4.6.5
DS7.1 Energy Only (RSSI above threshold) 15.4.6.5 DS7:O.2 Yes No N/A
DS7.2 IEEE 802.11 DSSS correlation 15.4.6.5 DS7:O.2 Yes No N/A
DS7.3 Both methods 15.4.6.5 DS7:O.2 Yes No N/A
DS7.4 Hold CCA busy for packet duration of 15.3.7 M Yes No
a correctly received PPDU but carrier
lost during reception of MPDU
DS7.5 Hold CCA busy for packet duration of 15.3.7 M Yes No
a correctly received but out of
specification PPDU
DS8 Transmit antenna selection O Yes No
DS9 Receive antenna diversity 15.2.3.8 O Yes No
*DS10 Antenna connector(s) availability 15.4.4.10 O Yes No
DS10.1 50 impedance 15.4.4.10 DS10:M Yes No N/A
*DS11 Transmit power level support 15.4.5.4 O Yes No
DS11.1 If greater than 100 mW capability 15.4.5.4 DS11:M Yes No N/A
DS12 Spurious emissions compliance 15.4.4.6 M Yes No
DS13 TX-to-RX turnaround time 15.4.4.7 M Yes No
DS14 RX-to-TX turnaround time 15.4.4.8 M Yes No
DS15 Slot time 15.4.4.9 M Yes No
DS16 Energy detection (ED) reporting time 15.4.4.9, M Yes No
15.4.6.5
DS17 Minimum transmit power level 15.4.5.3 M Yes No
DS18 Transmit spectral mask compliance 15.4.5.5 M Yes No
DS19 Transmitted center frequency 15.4.5.6 M Yes No
tolerance
DS20 Chip clock frequency tolerance 15.4.5.7 M Yes No
DS21 Transmit power-on ramp 15.4.5.8 M Yes No
DS22 Transmit power-down ramp 15.4.5.8 M Yes No
DS23 Radio frequency (RF) carrier 15.4.5.9 M Yes No
suppression
DS24 Transmit modulation accuracy 15.4.5.10 M Yes No
DS25 Receiver minimum input level 15.4.6.2 M Yes No
sensitivity
DS26 Receiver maximum input level 15.4.6.3 M Yes No
DS27 Receiver adjacent channel rejection 15.4.6.4 M Yes No
DS28 MIB 15.4.2, Annex C M Yes No
DS28.1 dot11PhyDSSSComplianceGroup, 15.4.2 M Yes No
dot11PhyRegDomainsSupportGroup,
and
dot11PhyOperationComplianceGroup
2700
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions
Item Feature References Status Support
OF1: OFDM PHY Specific Service Parameters
OF1.1 TXVECTOR parameter: LENGTH 17.2.2.2 M Yes No
OF1.2 TXVECTOR parameter: DATARATE 17.2.2.3 M Yes No
OF1.2.1 DATARATE = 6.0 Mb/s 17.2.2.3 M Yes No
*OF1.2.2 DATARATE = 9.0 Mb/s 17.2.2.3 O Yes No
OF1.2.3 DATARATE = 12.0 Mb/s 17.2.2.3 M Yes No
*OF1.2.4 DATARATE = 18.0 Mb/s 17.2.2.3 O Yes No
*OF1.2.5 DATARATE = 24.0 Mb/s 17.2.2.3, (NOT Yes No
Annex E CF3G6):M
CF3G6:O
*OF1.2.6 DATARATE = 36.0 Mb/s 17.2.2.3 O Yes No
*OF1.2.7 DATARATE = 48.0 Mb/s 17.2.2.3 O Yes No
*OF1.2.8 DATARATE = 54.0 Mb/s 17.2.2.3 O Yes No
OF1.3 TXVECTOR parameter: SERVICE 17.2.2.4 M Yes No
OF1.4 TXVECTOR parameter: 17.2.2.5 M Yes No
TXPWR_LEVEL_INDEX
OF1.5 RXVECTOR parameter: LENGTH 17.2.3.2 M Yes No
OF1.6 RXVECTOR parameter: RSSI 17.2.3.3 M Yes No
*OF1.7 10 MHz Channel spacing 17.2.2, CFOC:O Yes No N/A
17.2.3, CF3G6
17.2.3.4, AND
Annex E DSE2:M
*OF1.7.1 DATARATE = 3 Mb/s 17.2.2, CFOC Yes No N/A
(10 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.7:M
*OF1.7.2 DATARATE = 4.5 Mb/s 17.2.2, CFOC Yes No N/A
(10 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.7:O
*OF1.7.3 DATARATE = 6 Mb/s 17.2.2, CFOC Yes No N/A
(10 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.7:M
*OF1.7.4 DATARATE = 9 Mb/s 17.2.2, CFOC Yes No N/A
(10 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.7:O
*OF1.7.5 DATARATE = 12 Mb/s 17.2.2, CFOC Yes No N/A
(10 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.7:M
*OF1.7.6 DATARATE = 18 Mb/s 17.2.2, CFOC Yes No N/A
(10 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.7:O
*OF1.7.7 DATARATE = 24 Mb/s 17.2.2, CFOC Yes No N/A
(10 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.7:O
*OF1.7.8 DATARATE = 27 Mb/s 17.2.2, CFOC Yes No N/A
(10 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.7:O
2701
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
*OF1.8 5 MHz Channel spacing 17.2.2, CFOC:O Yes No N/A
17.2.3, CF3G6
17.2.3.4, AND
Annex E DSE2:M
CF3G6
AND
DSE3:M
*OF1.8.1 DATARATE = 1.5 Mb/s 17.2.2, CFOC Yes No N/A
(5 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.8:M
*OF1.8.2 DATARATE = 2.25 Mb/s 17.2.2, CFOC Yes No N/A
(5 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.8:O
*OF1.8.3 DATARATE = 3 Mb/s 17.2.2, CFOC Yes No N/A
(5 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.8:M
*OF1.8.4 DATARATE = 4.5 Mb/s 17.2.2, CFOC Yes No N/A
(5 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.8:O
*OF1.8.5 DATARATE = 6 Mb/s 17.2.2, CFOC Yes No N/A
(5 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.8:M
*OF1.8.6 DATARATE = 9 Mb/s 17.2.2, CFOC Yes No N/A
(5 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.8:O
*OF1.8.7 DATARATE = 12 Mb/s 17.2.2, CFOC Yes No N/A
(5 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.8:O
*OF1.8.8 DATARATE = 13.5 Mb/s 17.2.2, CFOC Yes No N/A
(5 MHz channel spacing) 17.2.3, AND
17.2.3.4 OF1.8:O
OF2: OFDM PHY Sublayer
OF2.1 RATE-dependent parameters 17.3.2.3 M Yes No
OF2.2 Timing related parameters 17.3.2.4 M Yes No
OF2.3 PHY preamble: SYNC 17.3.3 M Yes No
OF2.4 PHY header: SIGNAL 17.3.4 M Yes No
OF2.5 PHY header: LENGTH 17.3.4.2 M Yes No
OF2.6 PHY header: RATE 17.3.4.3 M Yes No
OF2.7 PHY header: parity, reserve 17.3.4.4 M Yes No
OF2.8 PHY header: SIGNAL TAIL 17.3.4.4 M Yes No
OF2.9 PHY header: SERVICE 17.3.5.2 M Yes No
OF2.10 PHY protocol data unit (PPDU): TAIL 17.3.5.3 M Yes No
OF2.11 PPDU: PAD 17.3.5.4 M Yes No
OF2.12 PHY/OFDM PHY data scrambler 17.3.5.5 M Yes No
and descrambler
OF2.13 Convolutional encoder 17.3.5.6 M Yes No
OF2.13.1 Rate R = 1/2 17.3.5.6 M Yes No
2702
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF2.13.2 Punctured coding R = 2/3 17.3.5.6 OF1.2.7:M Yes No N/A
OF2.13.3 Punctured coding R = 3/4 17.3.5.6 OF1.2.2 Yes No N/A
OR
OF1.2.4
OR
OF1.2.6
OR
OF1.2.8:M
OF2.14 Data interleaving 17.3.5.7 M Yes No
OF2.15 Subcarrier modulation mapping 17.3.5.8 M Yes No
OF2.15.1 Binary phase shift keying (BPSK) 17.3.5.8 M Yes No
OF2.15.2 Quadrature phase shift keying (QPSK) 17.3.5.8 M Yes No
OF2.15.3 16-quadrature amplitude modulation 17.3.5.8 M Yes No
(QAM)
OF2.15.4 64-QAM 17.3.5.8 OF1.2.7 Yes No N/A
OR
OF1.2.8:M
OF2.16 Pilot subcarriers 17.3.5.9 M Yes No
OF2.17 OFDM modulation 17.3.5.6 M Yes No
OF2.18 Packet duration calculation M Yes No
OF2.19 CCA
OF2.19.1 CCA: RSSI 17.3.6 M Yes No
OF2.19.2 CCA: indication to MAC sublayer 17.3.6 M Yes No
*OF2.19.3 CCA-ED functionality 17.3.10.6 CF3G6:M Yes No N/A
OF2.19.3.1 CCA-ED energy only (RPI above 17.3.10.6 OF2.19.3: Yes No N/A
threshold) M
OF2.19.3.2 Hold CCA busy for packet duration of a 17.3.10.6 OF2.19.3: Yes No N/A
correctly received PPDU, but carrier lost M
during reception of MPDU
OF2.20 PHY data modulation and modulation rate 17.3.7 M Yes No
change
OF2.21 Modulation-dependent parameters 17.3.2.3 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7:M
OF2.22 Timing-related parameters 17.3.2.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7:M
OF2.23 PHY header: RATE 17.3.4.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7:M
OF2.24 Modulation-dependent parameters 17.3.2.3 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8:M
OF2.25 Timing-related parameters 17.3.2.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8:M
2703
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF2.26 PHY header: RATE 17.3.4.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8:M
OF3: PDM Operating Specification General
OF3.1 Occupied channel bandwidth
OF3.1.1 20 MHz channel spacing 17.3.8.2 M Yes No
OF3.1.2 10 MHz channel spacing 17.3.8.2 CFOC Yes No N/A
AND
OF1.7:M
OF3.1.3 5 MHz channel spacing 17.3.8.2 CFOC Yes No N/A
AND
OF1.8:M
OF3.2 Operating frequency range 17.3.8.4.1
*OF3.2.1 4.9 GHz band Annex E CFOC:O Yes No N/A
*OF3.2.2 5.0 GHz band Annex E CFOC:M Yes No N/A
OF3.2.3 5.15–5.25 GHz band 17.3.8.4 O.1 Yes No
OF3.2.4 5.25–5.35 GHz band 17.3.8.4 O.1 Yes No
*OF3.2.5 5.47–5.725 GHz band Annex E CFSM:M Yes No N/A
OF3.2.6 5.725–5.85 GHz band 17.3.8.4 O.1 Yes No
*OF3.2.7 3.65–3.70 GHz band Annex D, CF3G6:M Yes No N/A
Annex E
OF3.2.8 5.9 GHz band Annex E CF5G9:M Yes No N/A
OF3.3 Channelization
OF3.3.1 5.15–5.25 GHz (20 MHz channel Annex E O.1 Yes No
spacing)
OF3.3.2 5.25–5.35 GHz (20 MHz channel spacing) Annex E O.1 Yes No
OF3.3.3 5.725–5.825 GHz (20 MHz channel Annex E O.1 Yes No
spacing)
OF3.3.4 5.15–5.25 GHz band in Japan (20 MHz Annex E CFOC:M Yes No N/A
channel spacing)
OF3.3.5 5.47–5.725 GHz (20 MHz channel Annex E CFSM Yes No N/A
spacing) AND
OF3.2.5:M
OF3.3.6 5.725–5.85 GHz (20 MHz channel Annex E O.1 Yes No
spacing)
OF3.3.7 4.9 GHz band (20 MHz channel spacing) Annex E CFOC Yes No N/A
AND
OF3.2.1:M
OF3.3.8 5.0 GHz band (20 MHz channel spacing) Annex E CFOC Yes No N/A
AND
OF3.2.2:M
OF3.3.9 4.9 GHz band (10 MHz channel spacing) Annex E CFOC Yes No N/A
AND
OF3.2.1
AND
OF1.7:M
2704
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF3.3.10 5.0 GHz band (10 MHz channel spacing) Annex E CFOC Yes No N/A
AND
OF3.2.2
AND
OF1.7:M
OF3.3.11 4.9 GHz band (5 MHz channel spacing) Annex E CFOC Yes No N/A
AND
OF3.2.1
AND
OF1.8:M
OF3.3.12 5.0 GHz band (5 MHz channel spacing) Annex E CFOC Yes No N/A
AND
OF3.2.2
AND
OF1.8:M
OF3.3.13 3.65–3.70 GHz (20 MHz channel spacing) Annex E CF3G6 Yes No N/A
AND
OF3.2.7:M
OF3.3.14 3.65–3.70 GHz (10 MHz channel spacing) Annex E CF3G6 Yes No N/A
AND
OF3.2.7
AND
OF1.7:M
OF3.3.15 3.65–3.70 GHz (5 MHz channel spacing) Annex E CF3G6 Yes No N/A
AND
OF3.2.7
AND
OF1.8:M
OF3.3.16 5.9 GHz band (10 MHz channel spacing) Annex E CF5G9:O Yes No N/A
OF3.3.17 5.9 GHz band (20 MHz channel spacing) Annex E CF5G9:O Yes No N/A
OF3.3.18 5.9 GHz band (5 MHz channel spacing) Annex E CF5G9:O Yes No N/A
OF3.4 Number of operating channels Annex E M Yes No
OF3.5 Operating channel frequencies Annex E M Yes No
OF3.6 Transmit and receive in band and out of Annex E M Yes No
band spurious emission
OF3.6.1 Interference-limited areas, 4.9 GHz band Annex E CFOC Yes No N/A
(20 MHz channel spacing) AND
OF3.2.1:M
OF3.6.2 Interference-limited areas, 5.0 GHz band Annex E CFOC Yes No N/A
(20 MHz channel spacing) AND
OF3.2.2:M
OF3.6.3 Interference-limited areas, 4.9 GHz band Annex E CFOC Yes No N/A
(10 MHz channel spacing) AND
OF3.2.1
AND
OF1.7:O
2705
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF3.6.4 Interference-limited areas, 5.0 GHz band Annex E CFOC Yes No N/A
(10 MHz channel spacing) AND
OF3.2.2
AND
OF1.7:O
OF3.6.5 Interference-limited areas, 4.9 GHz band Annex E CFOC Yes No N/A
(5 MHz channel spacing) AND
OF3.2.1
AND
OF1.8:O
OF3.6.6 Interference-limited areas, 5.0 GHz band Annex E CFOC Yes No N/A
(5 MHz channel spacing) AND
OF3.2.2
AND
OF1.8:O
OF3.7 Reserved
OF3.8 Slot time 17.3.8.6 M Yes No
OF3.8.1 Slot time (20 MHz channel spacing) 17.3.8.6 CFOC Yes No N/A
AND
OC2:M
OF3.8.2 Slot time (10 MHz channel spacing) 17.3.8.6 CFOC Yes No N/A
AND
OC3 AND
OF1.7:M
OF3.8.3 Slot time (5 MHz channel spacing) 17.3.8.6 CFOC Yes No N/A
AND
OC4 AND
OF1.8:M
OF3.9 Transmit and receive antenna connector 17.3.8.7 M Yes No
impedance
OF4: PHY Transmit Specification
OF4.1 Transmit power levels M Yes No
OF4.1.1 Power level (5.15–5.25 GHz) 17.3.9.2 OF3.3.1:M Yes No N/A
OF4.1.2 Power level (5.25–5.35 GHz) 17.3.9.2 OF3.3.2:M Yes No N/A
OF4.1.3 Power level (5.725–5.825 GHz) 17.3.9.2 OF3.3.3:M Yes No N/A
*OF4.1.4 Power Level (5.850–5.925 GHz), Class A D.2.2 CF5G9:M Yes No N/A
*OF4.1.5 Power Level (5.850–5.925 GHz), Class B D.2.2 CF5G9:O Yes No N/A
*OF4.1.6 Power Level (5.850–5.925 GHz), Class C D.2.2 CF5G9:O Yes No N/A
*OF4.1.7 Power Level (5.850–5.925 GHz), Class D D.2.2 CF5G9:O Yes No N/A
OF4.2 Spectrum mask 17.3.9.3 M Yes No
OF4.3 Spurious 17.3.9.4 M Yes No
OF4.4 Center frequency tolerance 17.3.9.5 M Yes No
OF4.5 Clock frequency tolerance 17.3.9.6 M Yes No
OF4.6 Modulation accuracy Yes No
OF4.6.1 Center frequency leakage 17.3.9.7.2 M Yes No
2706
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF4.6.2 Spectral flatness 17.3.9.7.3 M Yes No
OF4.6.3 Transmitter constellation error < –5 dB 17.3.9.7.4 M Yes No
OF4.6.4 Transmitter constellation error < –8 dB 17.3.9.7.4 OF1.2.2:M Yes No N/A
OF4.6.5 Transmitter constellation error < –10 dB 17.3.9.7.4 M Yes No
OF4.6.6 Transmitter constellation error < –13 dB 17.3.9.7.4 OF1.2.4:M Yes No N/A
OF4.6.7 Transmitter constellation error < –16 dB 17.3.9.7.4 M Yes No
OF4.6.8 Transmitter constellation error < –19 dB 17.3.9.7.4 OF1.2.6:M Yes No N/A
OF4.6.9 Transmitter constellation error < –22 db 17.3.9.7.4 OF1.2.7:M Yes No N/A
OF4.6.10 Transmitter constellation error < –25 dB 17.3.9.7.4 OF1.2.8:M Yes No N/A
OF4.7 Power level, 4.9 GHz band 17.3.9.2 CFOC Yes No N/A
(20 MHz channel spacing) AND
OF3.12.1:
M
OF4.8 Power level, 5.0 GHz band 17.3.9.2 CFOC Yes No N/A
(20 MHz channel spacing) AND
OF3.12.2:
M
OF4.9 Power level, 5.47–5.725 GHz band 17.3.9.2 CFOC Yes No N/A
AND
OF3.12.3:
M
OF4.10 Power level, 4.9 GHz band 17.3.9.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF3.12.1
AND
OF1.7:M
OF4.11 Power level, 5.0 GHz band 17.3.9.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF3.12.2
AND
OF1.7:M
OF4.12 Power level, 4.9 GHz band 17.3.9.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF3.12.1
AND
OF1.8:M
OF4.13 Power level, 5.0 GHz band 17.3.9.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF3.12.2
AND
OF1.8:M
OF4.13a Power level, 3.65–3.70 GHz (20 MHz Annex E CF3G6 Yes No N/A
channel spacing) AND
OF3.2.7:M
OF4.13b Power level, 3.65–3.70 GHz (10 MHz Annex E CF3G6 Yes No N/A
channel spacing) AND
OF3.2.7
AND
OF1.7:M
2707
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF4.13c Power level, 3.65–3.70 GHz (5 MHz Annex E CF3G6 Yes No N/A
channel spacing) AND
OF3.2.7
AND
OF1.8:M
OF4.14 Spectrum mask 17.3.9.3 CFOC:M Yes No N/A
(20 MHz channel spacing)
OF4.15 Spectrum mask 17.3.9.3 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7:M
OF4.15.1 Spectrum mask, Class A D.2.3 OF4.1.4:M Yes No N/A
(10 MHz channel spacing)
OF4.15.2 Spectrum mask, Class B D.2.3 OF4.1.5:M Yes No N/A
(10 MHz channel spacing)
OF4.15.3 Spectrum mask, Class C D.2.3 OF4.1.6:M Yes No N/A
(10 MHz channel spacing)
OF4.15.4 Spectrum mask, Class D D.2.3 OF4.1.7:M Yes No N/A
(10 MHz channel spacing)
OF4.16 Spectrum mask 17.3.9.3 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8:M
OF4.17 Transmitter constellation error
(10 MHz channel spacing)
OF4.17.1 Transmitter constellation error < –5 dB 17.3.9.7.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.1:M
OF4.17.2 Transmitter constellation error < –8 dB 17.3.9.7.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.2:M
OF4.17.3 Transmitter constellation error < –10 dB 17.3.9.7.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.3:M
OF4.17.4 Transmitter constellation error < –13 dB 17.3.9.7.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.4:M
OF4.17.5 Transmitter constellation error < –16 dB 17.3.9.7.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.5:M
OF4.17.6 Transmitter constellation error < –19 dB 17.3.9.7.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.6:M
OF4.17.7 Transmitter constellation error < –22 dB 17.3.9.7.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.7:M
OF4.17.8 Transmitter constellation error < –25 dB 17.3.9.7.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.8:M
OF4.18 Transmitter constellation error
(5 MHz channel spacing)
2708
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF4.18.1 Transmitter constellation error < –5 dB 17.3.9.7.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.1:M
OF4.18.2 Transmitter constellation error < –8 dB 17.3.9.7.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.2:M
OF4.18.3 Transmitter constellation error < –10 dB 17.3.9.7.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.3:M
OF4.18.4 Transmitter constellation error < –13 dB 17.3.9.7.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.4:M
OF4.18.5 Transmitter constellation error < –16 dB 17.3.9.7.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.5:M
OF4.18.6 Transmitter constellation error < –19 dB 17.3.9.7.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.6:M
OF4.18.7 Transmitter constellation error < –22 dB 17.3.9.7.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.7:M
OF4.18.8 Transmitter constellation error < –25 dB 17.3.9.7.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.8:M
OF5: PHY Receiver Specifications
OF5.1 Minimum input level sensitivity at packet
error ratio (PER) = 10% with 1000 octet
frames
OF5.1.1 –82 dBm for 6 Mb/s 17.3.10.2 M Yes No
OF5.1.2 –81 dBm for 9 Mb/s 17.3.10.2 OF1.2.2:M Yes No N/A
OF5.1.3 –79 dBm for 12 Mb/s 17.3.10.2 M Yes No
OF5.1.4 –77 dBm for 18 Mb/s 17.3.10.2 OF1.2.4:M Yes No N/A
OF5.1.5 –74 dBm for 24 Mb/s 17.3.10.2 M Yes No
OF5.1.6 –70 dBm for 36 Mb/s 17.3.10.2 OF1.2.6:M Yes No N/A
OF5.1.7 –66 dBm for 48 Mb/s 17.3.10.2 OF1.2.7:M Yes No N/A
OF5.1.8 –65 dBm for 54 Mb/s 17.3.10.2 OF1.2.8:M Yes No N/A
OF5.2 Adjacent channel rejection 17.3.10.3 M Yes No
OF5.2.1 Optional adjacent channel rejection 17.3.10.3 O Yes No
OF5.3 Nonadjacent channel rejection 17.3.10.4 M Yes No
OF5.3.1 Optional nonadjacent channel rejection 17.3.10.4 O Yes No
OF5.4 Maximum input level 17.3.10.5 M Yes No
OF5.5 CCA sensitivity 17.3.10.6 M Yes No
OF5.6 Maximum input level sensitivity at packet
error ratio (PER) = 10% with 1000 octet
frames (10 MHz channel spacing)
2709
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF5.6.1 –85 dBm for 3 Mb/s 17.3.10.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.1:M
OF5.6.2 –84 dBm for 4.5 Mb/s 17.3.10.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.2:M
OF5.6.3 –82 dBm for 6 Mb/s 17.3.10.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.3:M
OF5.6.4 –80 dBm for 9 Mb/s 17.3.10.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.4:M
OF5.6.5 –77 dBm for 12 Mb/s 17.3.10.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.5:M
OF5.6.6 –73 dBm for 18 Mb/s 17.3.10.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.6:M
OF5.6.7 –69 dBm for 24 Mb/s 17.3.10.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.7:M
OF5.6.8 –68 dBm for 27 Mb/s 17.3.10.2 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7.8:M
OF5.7 Adjacent channel rejection 17.3.10.3 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7:M
OF5.8 Nonadjacent channel rejection 17.3.10.4 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7:M
OF5.9 Maximum input level 17.3.10.5 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7:M
OF5.10 CCA sensitivity 17.3.10.6 CFOC Yes No N/A
(10 MHz channel spacing) AND
OF1.7:M
OF5.11 Maximum input level sensitivity at packet
error ratio (PER) = 10% with 1000 octet
frames (5 MHz channel spacing)
OF5.11.1 –85 dBm for 3 Mb/s 17.3.10.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.1:M
OF5.11.2 –84 dBm for 4.5 Mb/s 17.3.10.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.2:M
OF5.11.3 –82 dBm for 6 Mb/s 17.3.10.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.3:M
OF5.11.4 –80 dBm for 9 Mb/s 17.3.10.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.4:M
2710
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF5.11.5 –77 dBm for 12 Mb/s 17.3.10.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.5:M
OF5.11.6 –73 dBm for 18 Mb/s 17.3.10.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.6:M
OF5.11.7 –69 dBm for 24 Mb/s 17.3.10.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF.1.8.7:M
OF5.11.8 –68 dBm for 27 Mb/s 17.3.10.2 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8.8:M
OF5.12 Adjacent channel rejection 17.3.10.3 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8:M
OF5.13 Nonadjacent channel rejection 17.3.10.4 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8:M
OF5.14 Maximum input level 17.3.10.5 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8:M
OF5.15 CCA sensitivity 17.3.10.6 CFOC Yes No N/A
(5 MHz channel spacing) AND
OF1.8:M
OF6: Transmit PHY
OF6.1 Transmit: transmit on MAC request 17.3.11 M Yes No
OF6.2 Transmit: format and data encoding 17.3.11 M Yes No
OF6.3 Transmit: timing 17.3.11 M Yes No
OF7: Receive PHY
OF7.1 Receive: receive and data decoding 17.3.12 M Yes No
OF8: PLME
OF8.1 PLME: support PLME SAP 17.4.1 M Yes No
management primitives
OF8.2 PLME: support PHY MIB 17.4.2 M Yes No
OF8.3 PLME: support PHY characteristics 17.4.3 M Yes No
OF8.4 PLME:support PHY characteristics 17.4.2 CFOC:M Yes No N/A
(dot11ChannelStartingFactor)
OF9 Reserved
2711
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.6 OFDM PHY functions (continued)
Item Feature References Status Support
OF10: Geographic Area Specific Requirements
*OF10.1 Geographic areas 17.3.8.3, M Yes No
17.3.8.4,
17.3.8.5,17.
3.9.4
OF10.2 Regulatory domain extensions 17.3.8.4.3, CFOC:M Yes No N/A
17.3.8.5,
17.3.9.2,
17.3.9.3,
Annex E
B.4.7 High rate, direct sequence PHY functions
Item PHY feature References Status Support
Are the following PHY features
supported?
HRDS1 Long preamble and header procedures 16.2 M Yes No
HRDS1.1 Long direct sequence preamble 16.2.1 M Yes No
prepended on TX
HRDS1.2 Long PHY integrity check generation 16.2.3 M Yes No
HRDS1.3 TX rate change capability 16.2.3.4 M Yes No
HRDS1.4 Supported data rates 16.1, 16.2.3.4 M Yes No
HRDS1.5 Data scrambler 16.2.4 M Yes No
HRDS1.6 Scrambler initialization 16.2.4 M Yes No
HRDS2 Reserved
*HRDS3 Short preamble and header procedures 16.2 O Yes No
HRDS3.1 Short preamble prepended on TX 16.2.2 HRDS3:M Yes No N/A
HRDS3.2 Short header transmission 16.2.3.9, 16.2.3.10, HRDS3:M Yes No N/A
16.2.3.11,
16.2.3.12,
16.2.3.13,
16.2.3.14,
16.2.3.15
HRDS4 Long preamble process on RX 16.2.6 M Yes No
HRDS4.1 PHY format 16.2.6 M Yes No
HRDS4.2 PHY integrity check verify 16.2.6 M Yes No
HRDS4.3 RX Rate change capability 16.2.6 M Yes No
HRDS4.4 Data whitener descrambler 16.2.6 M Yes No
*HRDS5 Short preamble process on RX 16.2.6 HRDS3:M Yes No N/A
HRDS5.1 PHY format 16.2.6 HRDS5:M Yes No N/A
HRDS5.2 PHY integrity check verify 16.2.6 HRDS5:M Yes No N/A
HRDS5.3 RX rate change capability 16.2.6 HRDS5:M Yes No N/A
HRDS5.4 Data whitener descrambler 16.2.6 HRDS5:M Yes No N/A
2712
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.7 High rate, direct sequence PHY functions (continued)
Item PHY feature References Status Support
*HRDS6 Operating channel capability — — —
*HRDS6.1 North America (FCC) 16.3.6.3 HRDS6:O.3 Yes No N/A
HRDS6.1.1 Channel 1 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.2 Channel 2 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.3 Channel 3 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.4 Channel 4 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.5 Channel 5 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.6 Channel 6 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.7 Channel 7 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.8 Channel 8 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.9 Channel 9 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.10 Channel 10 16.3.6.3 HRDS6.1:M Yes No N/A
HRDS6.1.11 Channel 11 16.3.6.3 HRDS6.1:M Yes No N/A
*HRDS6.2 Canada (IC) 16.3.6.3 HRDS6:O.3 Yes No N/A
HRDS6.2.1 Channel 1 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.2 Channel 2 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.3 Channel 3 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.4 Channel 4 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.5 Channel 5 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.6 Channel 6 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.7 Channel 7 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.8 Channel 8 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.9 Channel 9 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.10 Channel 10 16.3.6.3 HRDS6.2:M Yes No N/A
HRDS6.2.11 Channel 11 16.3.6.3 HRDS6.2:M Yes No N/A
*HRDS6.3 Europe (ETSI) 16.3.6.3 HRDS6:O.3 Yes No N/A
HRDS6.3.1 Channel 1 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.2 Channel 2 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.3 Channel 3 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.4 Channel 4 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.5 Channel 5 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.6 Channel 6 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.7 Channel 7 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.8 Channel 8 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.9 Channel 9 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.10 Channel 10 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.11 Channel 11 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.12 Channel 12 16.3.6.3 HRDS6.3:M Yes No N/A
HRDS6.3.13 Channel 13 16.3.6.3 HRDS6.3:M Yes No N/A
*HRDS6.4 France 16.3.6.3 HRDS6:O.3 Yes No N/A
2713
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.7 High rate, direct sequence PHY functions (continued)
Item PHY feature References Status Support
HRDS6.4.1 Channel 10 16.3.6.3 HRDS6.4:M Yes No N/A
HRDS6.4.2 Channel 11 16.3.6.3 HRDS6.4:M Yes No N/A
HRDS6.4.3 Channel 12 16.3.6.3 HRDS6.4:M Yes No N/A
HRDS6.4.4 Channel 13 16.3.6.3 HRDS6.4:M Yes No N/A
*HRDS6.5 Spain 16.3.6.3 HRDS6:O.3 Yes No N/A
HRDS6.5.1 Channel 10 16.3.6.3 HRDS6.5:M Yes No N/A
HRDS6.5.2 Channel 11 16.3.6.3 HRDS6.5:M Yes No N/A
*HRDS6.6 Japan 16.3.6.3 HRDS6:O.3 Yes No N/A
HRDS6.6.1 Channel 1 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.2 Channel 2 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.3 Channel 3 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.4 Channel 4 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.5 Channel 5 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.6 Channel 6 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.7 Channel 7 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.8 Channel 8 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.9 Channel 9 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.10 Channel 10 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.11 Channel 11 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.12 Channel 12 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.13 Channel 13 16.3.6.3 HRDS6.6:M Yes No N/A
HRDS6.6.14 Channel 14 16.3.6.3 HRDS6.6:M Yes No N/A
*HRDS6.7 China (Radio Administration The Radio 16.3.6.3 HRDS6:O.3 Yes No N/A
Administration of P.R.China)
HRDS6.7.1 Channel 1 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.2 Channel 2 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.3 Channel 3 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.4 Channel 4 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.5 Channel 5 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.6 Channel 6 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.7 Channel 7 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.8 Channel 8 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.9 Channel 9 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.10 Channel 10 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.11 Channel 11 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.12 Channel 12 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS6.7.13 Channel 13 16.3.6.3 HRDS6.7:M Yes No N/A
HRDS7 Reserved
HRDS8 Complementary code keying (CCK) bits
to symbol mapping
2714
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.7 High rate, direct sequence PHY functions (continued)
Item PHY feature References Status Support
HRDS8.1 5.5 Mb/s 16.3.6.6 M Yes No
HRDS8.2 11 Mb/s 16.3.6.6 M Yes No
HRDS9 Reserved
*HRDS10 CCA functionality 16.3.8.5
HRDS10.1 CCA Mode 1, energy only (RSSI above 16.3.8.5 HRDS10:O.4 Yes No N/A
threshold)
HRDS10.2 CCA Mode 4, CS with timer 16.3.8.5 HRDS10:O.4 Yes No N/A
HRDS10.3 CCA Mode 5, energy detect with high 16.3.8.5 HRDS10:O.4 Yes No N/A
rate CS
HRDS10.4 Hold CCA busy for packet duration of a 16.2.6 M Yes No
correctly received PPDU, but carrier lost
during reception of MPDU.
HRDS10.5 Hold CCA busy for packet duration of a 16.2.6 M Yes No
correctly received, but out of spec,
PPDU.
HRDS11 Transmit antenna selection 16.3.5 O Yes No
HRDS12 Receive antenna diversity 16.3.5 O Yes No
*HRDS13 Antenna connector(s) availability 16.3.6.7 O Yes No
HRDS13.1 If available (50 impedance) 16.3.6.7 HRDS13:M Yes No N/A
*HRDS14 Transmit power level support 16.3.7.3 O Yes No
HRDS14.1 If greater than 100 mW capability 16.3.7.3 HRDS14:M Yes No N/A
HRDS15 Spurious emissions compliance 16.3.6.7 M Yes No
HRDS16 TX-to-RX turnaround time 16.3.6.8 M Yes No
HRDS17 RX-to-TX turnaround time 16.3.6.9 M Yes No
HRDS18 Slot time 16.3.6.10 M Yes No
HRDS19 ED reporting time 16.3.6.9, 16.3.8.5 M Yes No
HRDS20 Minimum transmit power level 16.3.7.3 M Yes No
HRDS21 Transmit spectral mask compliance 16.3.7.4 M Yes No
HRDS22 Transmitted center frequency tolerance 16.3.7.5 M Yes No
HRDS23 Chip clock frequency tolerance 16.3.7.6 M Yes No
HRDS24 Transmit power-on ramp 16.3.7.7 M Yes No
HRDS25 Transmit power-down ramp 16.3.7.7 M Yes No
HRDS26 RF carrier suppression 16.3.7.8 M Yes No
HRDS27 Transmit modulation accuracy 16.3.7.9 M Yes No
HRDS28 Receiver minimum input level 16.3.8.2 M Yes No
sensitivity
HRDS29 Receiver maximum input level 16.3.8.3 M Yes No
HRDS30 Receiver adjacent channel rejection 16.3.8.4 M Yes No
HRDS31 MIB 16.3.2 M Yes No
HRDS31.1 PHY object class 16.3.3 M Yes No
2715
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.8 Regulatory domain extensions
Item Protocol capability References Status Support
MD1 Country element 9.3.3.3, CFMD:M Yes No N/A
9.3.3.11,
Length 9.4.2.9
Country String
First Channel Number
Maximum Transmit Power Level
Number of Channels
MD2 Inclusion of the Request information 9.3.3.10 CFMD:O Yes No N/A
in the Probe Request frame
MD3 Reserved
MD4 Reserved
MD5 Request mechanism
MD5.1 Request element 9.4.2.10 CFMD:M Yes No N/A
Format
Element ID
Order of the Requested Elemented
IDs
MD5.2 Extended Request element 9.4.2.11 CFMD:M Yes No N/A
MD6 Entering a Regulatory Domain 10.21.2 CFMD:M Yes No N/A
Lost Connectivity with its
extended service set (ESS)
Passive Scanning to learn
Beacon information
Transmit Probe Request
MD7 Reserved
MD8 Roaming requires Beacon frame with 11.1.4.4 CFMD:M Yes No N/A
country element
MD9 Actions to be taken upon the receipt 11.1.4.5 CFMD:M Yes No N/A
of the Beacon frame
MD10 Reserved
MD11 Reserved
MD12 Operating and Coverage classes 9.4.2.9 OC1:M Yes No N/A
MD13 Reserved First Channel Number 10.21.3 CF3G6:M Yes No N/A
MD14 Reserved Operating Class 10.21.3 CF3G6:M Yes No N/A
*MD15 Operation with operating classes 10.21.3 CF3G6:M Yes No N/A
MD15.1 Multiple classes in Country element 10.21.3 MD15:M Yes No N/A
MD15.2 Multiple classes in (Re)Association 10.21.3 MD15:M Yes No N/A
frames
2716
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.9 ERP functions
Item PHY features References Status Support
*ERP1 Transmit and Receive 18.3.2 CFERP:M Yes No N/A
ERP-DSSS data rates 1
and 2 Mb/s and ERP-
CCK data rates 5.5 and
11 Mb/s
ERP1.1 Transmit and receive 18.3.2 CFERP:M Yes No N/A
ERP-OFDM data rates
of 6, 12, and 24 Mb/s
ERP1.2 Transmit and receive 18.3.2 ERP1:O Yes No N/A
ERP-OFDM data rate of
9 Mb/s
ERP1.3 Transmit and receive 18.3.2 ERP1:O Yes No N/A
ERP-OFDM data rate of
18 Mb/s
ERP1.4 Transmit and receive 18.3.2 ERP1:O Yes No N/A
ERP-OFDM data rate of
36 Mb/s
ERP1.5 Transmit and receive 18.3.2 ERP1:O Yes No N/A
ERP-OFDM data rate of
48 Mb/s
ERP1.6 Transmit and receive 18.3.2 ERP1:O Yes No N/A
ERP-OFDM data rate of
54 Mb/s
ERP2 Reserved
ERP3 Reserved
ERP4 Support of ERP3 18.3.2 CFERP:O Yes No N/A
required PPDU formats
as described in
reference
ERP5 Able to transmit and 18.3.2 CFERP:M Yes No N/A
receive long and short
DSSS as well as OFDM
preambles
ERP6 Set SERVICE field bits 18.3.2.2 CFERP:M Yes No N/A
for locked clocks, and
length extension
ERP7 Set B1 and B4 of long 18.3.2.2 CFERP:M Yes No N/A
and short preamble
PPDU SERVICE field
to 0
ERP8 Set B2 to 1 in all long 18.3.2.2 CFERP:M Yes No N/A
and short preamble
PPDU SERVICE fields
ERP9 Set B7 of the long and 18.3.2.2, CFERP:M Yes No N/A
short preamble PPDU 18.3.2.3
SERVICE fields as
described in the
reference
2717
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.9 ERP functions (continued)
Item PHY features References Status Support
ERP10 Use Clause 16 (DSSS 10.26 CFERP:M Yes No N/A
PHY specification for
the 2.4 GHz band
designated for ISM
applications) or
Clause 17 (High rate
direct sequence spread
spectrum (HR/DSSS)
PHY specification) rates
when using protection
mechanisms
ERP11 Reserved
ERP12 Reserved
ERP13 Reserved
ERP14 Reserved
ERP15 Reserved
ERP16 Add signal extension of 18.3.2.4 CFERP:M Yes No N/A
6 µs
ERP17 Simultaneous CCA on 18.3.4 CFERP:M Yes No N/A
long preamble Barker,
short preamble Barker,
and OFDM
ERP18 CCA with energy detect 18.3.4 CFERP:M Yes No N/A
above threshold and CS
ERP19 Reserved
ERP20 Able to automatically 18.3.5 CFERP:M Yes No N/A
detect format of long
preamble Barker, short
preamble Barker, and
OFDM and receive
appropriately
ERP21 Comply with local 18.4.2 CFERP:M Yes No N/A
regulatory frequency
allocation requirements
ERP22 Use frequency plan for 18.4.3 CFERP:M Yes No N/A
2.4 GHz
ERP23 Comply with regulatory 18.4.4 CFERP:M Yes No N/A
spurious emissions
regulations
ERP24 Slot time requirements 18.5.4 CFERP:M Yes No N/A
ERP25 Implement Short Slot 18.5.4 CFERP:O Yes No N/A
Time option
ERP26 Use 10 µs short 18.4.6 CFERP:M Yes No N/A
interframe space (SIFS)
time
ERP27 Comply with regulatory 18.4.7.2 CFERP:M Yes No N/A
transmit power
requirements
ERP28 ± 25 ppm frequency 18.4.7.4 CFERP:M Yes No N/A
tolerance
2718
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.9 ERP functions (continued)
Item PHY features References Status Support
ERP29 Use locked clocks 18.4.7.4, CFERP:M Yes No N/A
18.4.7.5
ERP30 Tolerate input level of 18.4.8.4 CFERP:M Yes No N/A
–20 dBm
ERP31 Use specified transmit 18.5 CFERP:M Yes No N/A
mask
ERP32 Meet sensitivity for all 18.4.8.2 CFERP:M Yes No N/A
supported data rates
ERP33 Reject adjacent 18.4.8.3 CFERP:M Yes No N/A
channels as in Table 18-
18 (Receiver
performance
requirements) in
18.3.10.2 (Receiver
minimum input
sensitivity) or in
17.3.8.4 (Receiver
adjacent channel
rejection) as appropriate
ERP34 Reserved
ERP35 Reserved
ERP36 Reserved
ERP37 Reserved
ERP38 Reserved
ERP39 Calculate ERP-OFDM 18.5.3.2 CFERP:M Yes No N/A
TXTIME
ERP40 Reserved
ERP41 Reserved
ERP42 Revert to long slot time 9.4.1.4 CFERP:M Yes No N/A
when establishing
association with a long
slot time STA
ERP43 Support TXVECTOR 10.3 CFERP:M Yes No N/A
and RXVECTOR as
described in reference
ERP44 Reserved
B.4.10 Spectrum management extensions
Item IUT configuration References Status Support
SM1 Country, Power Constraint, and 9.3.3.3, CFSM:M Yes No N/A
transmit power control (TPC) 9.3.3.11,
Report elements included in 9.4.2.9,
Beacon and Probe Response frames 9.4.2.12,
9.4.2.15
SM1.1 Transmit Envelope element(s) in 9.4.2.162 CFSM AND Yes No N/A
Beacon and Probe Response frames CFESM:M
2719
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.10 Spectrum management extensions (continued)
Item IUT configuration References Status Support
SM2 Spectrum Management Capability 9.4.1.4 CFSM:M Yes No N/A
bit
SM3 Power Capability and Supported 9.3.3.6, 9.3.3.7, CFSM:M Yes No N/A
Channels elements in 11.6.1
(Re)Association frames
SM4 Action frame protocol for spectrum 9.4.1.11, 9.6 CFSM:M Yes No N/A
management actions
SM4.1 Measurement Request frame 9.6.2.2 CFSM:M Yes No N/A
SM4.2 Measurement Report frame 9.6.2.3 CFSM:M Yes No N/A
SM4.3 TPC Request frame 9.6.2.4 CFSM:M Yes No N/A
SM4.4 TPC Report frame 9.6.2.5 CFSM:M Yes No N/A
SM4.5 Channel Switch Announcement 9.6.2.6 CFSM:M Yes No N/A
frame
SM5 Measurement requests
SM5.1 Basic request 9.4.2.21.2 CFSM:M Yes No N/A
SM5.2 CCA request 9.4.2.21.3 CFSM:O Yes No N/A
SM5.3 Receive power indication (RPI) 9.4.2.21.4 CFSM:O Yes No N/A
histogram
SM5.4 Enabling/disabling requests and 9.4.2.21 CFSM:M Yes No N/A
reports
SM6 Measurement reports
SM6.1 Basic report 9.4.2.22.2 CFSM:M Yes No N/A
SM6.2 CCA report 9.4.2.22.3 CFSM:O Yes No N/A
SM6.3 RPI histogram report 9.4.2.22.4 CFSM:O Yes No N/A
SM6.4 Refusal to measure 9.4.2.22 CFSM:M Yes No N/A
SM7 Quiet interval EMPTY
SM7.1 AP-defined Quiet interval 9.3.3.3, (CFAP and Yes No N/A
9.3.3.11, CFSM):M
9.4.2.23, 11.6.2
SM7.2 STA-defined Quiet interval 9.3.3.3, (CFSTAofAP and Yes No N/A
9.3.3.11, CFSM):M
9.4.2.23, 11.6.2
SM7.3 STA support for Quiet interval 9.3.3.3, CFSM:M Yes No N/A
9.3.3.11,
9.4.2.23, 11.6.2
SM8 Association control based on 11.8, 11.9 (CFAP and Yes No N/A
spectrum management capability CFSM):M
SM9 Association control based on 11.8.2 (CFAP and Yes No N/A
transmit power capability CFSM):M
SM10 Maximum transmit power levels
SM10.1 AP determination and 11.8.5 (CFAP AND Yes No N/A
communication of local CFSM):M
maximum transmit power level
2720
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.10 Spectrum management extensions (continued)
Item IUT configuration References Status Support
SM10.2 STA determination and 11.8.5 ((CFSTAofAP OR Yes No N/A
communication of local CFIBSS) AND
maximum transmit power level CFSM):M
SM11 Selection of transmit power 11.8.6 CFSM:M Yes No N/A
SM12 Adaptation of transmit power
SM12.1 TPC report in Beacon and Probe 11.8.7 CFSM:M Yes No N/A
Response frames
SM13.1 Dynamic transmit power 11.8.7 CFSM:O Yes No N/A
adaptation
SM13 Testing channels for radar 11.9.4 CFSM:M Yes No N/A
SM14 Detecting and discontinuing 11.9.5 CFSM:M Yes No N/A
operations after detection of radar
SM15 Requesting and reporting of 11.9.7 CFSM:M Yes No N/A
measurements
SM16 Autonomous reporting of radar 11.9.7 CFSM:M Yes No N/A
SM17 IBSS dynamic frequency selection 9.4.2.24 (CFIBSS AND Yes No N/A
(DFS) element including channel CFSM):M
map
SM18 DFS owner function 11.9.8 (CFIBSS AND Yes No N/A
CFSM):M
SM19 DFS owner recovery procedure 11.9.8 (CFIBSS AND Yes No N/A
CFSM):M
SM20 Channel switching procedure
SM20.1 Transmission of channel switch 11.9.8 (CFAP AND Yes No N/A
announcement and channel CFSM):M
switching procedure by an AP
SM20.2 Transmission of channel switch 11.9.8 (CFSTAofAP Yes No N/A
announcement and channel AND CFSM):M
switching procedure by a STA
SM20.3 Reception of channel switch 11.9.8 CFSM:M Yes No N/A
announcement and channel
switching procedure by a STA
SM20.4 Transmission of Wide 11.40.4 (CFAP AND Yes No N/A
Bandwidth Channel Switch CFSM AND
element in Channel CFESM):M
Announcement frame and
transmission of Wide Bandwidth
Channel Switch subelement in
Channel Switch Wrapper
element in Beacon/Probe
Response frames, and associated
channel switching procedure by
an AP
2721
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.10 Spectrum management extensions (continued)
Item IUT configuration References Status Support
SM20.5 Transmission of Wide 11.40.4 (CFIBSS AND Yes No N/A
Bandwidth Channel Switch CFSM AND
element in Channel CFESM):M
Announcement frame and
transmission of Wide Bandwidth
Channel Switch subelement in
Channel Switch Wrapper
element in Beacon/Probe
Response frames, and associated
channel switching procedure by a
STA.
SM20.6 Reception of Wide Bandwidth 11.40.4 (CFSM AND Yes No N/A
Channel Switch element in CFESM):M
Channel Announcement frame
and reception of Wide
Bandwidth Channel Switch
subelement in Channel Switch
Wrapper element in Beacon/
Probe Response frames, and
associated channel switching
procedure by a STA.
SM20.7 Transmission of New Transmit 11.40.4 (CFAP AND Yes No N/A
Power Envelope element in CFSM AND
Channel Announcement frame CFESM):M
and transmission of New
Transmit Power Envelope
subelement in Channel Switch
Wrapper element in Beacon/
Probe Response frames, and
associated channel switching
procedure by an AP.
SM20.8 Transmission of New Transmit 11.40.4 (CFIBSS AND Yes No N/A
Power Envelope element in CFSM AND
Channel Announcement frame CFESM):M
and transmission of New
Transmit Power Envelope
subelement in Channel Switch
Wrapper element in Beacon/
Probe Response frames, and
associated channel switching
procedure by a STA.
SM20.9 Reception of New Transmit 11.40.4 (CFSM AND Yes No N/A
Power Envelope element in CFESM):M
Channel Announcement frame
and reception of New Transmit
Power Envelope subelement in
Channel Switch Wrapper
element in Beacon/Probe
Response frames, and associated
channel switching procedure by a
STA.
SM20.1 Transmission of Future Channel 11.9.10 CFSM:O Yes No N/A
0 Guidance element by a STA.
SM20.11 Reception of Future Channel 11.9.10 CFSM:O Yes No N/A
Guidance element procedure by a
STA.
2722
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.11 Operating classes extensions
Item Protocol capability References Status Support
OC1 Operating and coverage classes 9.4.2.9 CFMD AND Yes No N/A
CFOC:M
OC2 Operating and coverage classes 9.4.2.9, CFMD AND Yes No N/A
(20 MHz channel spacing) 17.3.8.6 CFOC:M
OC3 Operating and coverage classes 9.4.2.9, CFMD AND Yes No N/A
(10 MHz channel spacing) 17.3.8.6 CFOC AND
OF1.7:M
OC4 Operating and coverage classes (5 9.4.2.9, CFMD AND Yes No N/A
MHz channel spacing) 17.3.8.6 CFOC AND
OF1.8:M
OC5 Coverage classes 0–31 10.21.5 CF3G6:M Yes No N/A
Coverage class operation when 10.21.5 CF3G6:M Yes No N/A
not associated
OC6 Power level, equivalent maximum 10.21.5 CF3G6:M Yes No N/A
transmit power level and
operating class
Power level operation when not 10.21.5 CF3G6:M Yes No N/A
associated
OC7 Power level, different maximum 10.21.5 CF3G6:M Yes No N/A
transmit power level and
operating class
Power level operation when not 10.21.5 CF3G6:M Yes No N/A
associated
OC 8 Operation with multiple country — OC1:O Yes No N/A
elements
B.4.12 QoS base functionality
Item Protocol capability References Status Support
QB1 QoS frame format
QB1.1 QoS frame format 9.3.1.2–9.3.1.4, not CFDMG AND Yes No N/A
9.3.2.1, 9.3.3.3, CFQoS:M
9.3.3.6–9.3.3.9,
9.3.3.11, 9.3.3.14
QB1.2 QoS frame format 9.3.1.2, 9.3.1.4, CFDMG:M Yes No N/A
9.3.1.8, 9.3.1.9,
9.3.1.11–9.3.1.19,
9.3.2.1, 9.3.4.2,
9.3.3.6–9.3.3.9,
9.3.3.11, 9.3.3.14
QB2 Per traffic identifier (TID) 9.2.4.4, 9.2.4.5, CFQoS OR Yes No N/A
duplicate detection 10.3.2.11 CFDMG:M
QB3 Decode of no-acknowledgment 9.2.4.5.4, CFQoS OR Yes No N/A
policy in QoS Data frames 10.22.2.7, CFDMG:M
10.22.2.11,
10.22.4.2,
10.22.4.3
2723
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.12 QoS base functionality (continued)
Item Protocol capability References Status Support
QB4 Block acknowledgments
(block ack)
QB4.1 Immediate block ack 9.3.1.8.1, CFQoS:O Yes No N/A
9.3.1.8.2, CFHT OR CFDMG
Non-HT block ack is obsolete. 9.3.1.9.1, OR CFTVHT:M
Support for this mechanism 9.3.1.9.2, 9.6.5,
might be removed in a later 10.24 (except
revision of the standard. 10.24.7 and
10.24.8), 11.5
*QB4.2 Delayed block ack 9.3.1.8.1, CFQoS:O Yes No N/A
9.3.1.8.2,
Non-HT block ack is obsolete. 9.3.1.9.1,
Support for this mechanism 9.3.1.9.2, 9.6.5,
might be removed in a later 10.24 (except
revision of the standard. 10.24.7 and
10.24.8), 11.5
QB4.3 Compressed Block Ack
QB4.3.1 Compressed Block Ack 9.3.1.8.3 CFQoS:O Yes No N/A
CFHT OR CFDMG
OR CFTVHT:M
QB4.3.2 Extended Compressed Block 9.3.1.8.4 CFDMG:O Yes No N/A
Ack
QB4.4 Multi-TID Block Ack 9.3.1.9.4 CFQoS:O Yes No N/A
CFHT OR
CFTVHT:M
QB5 Automatic power save delivery 9.6.3, 11.2.3 (CFAP and Yes No N/A
(APSD) CFQoS):O
(CFIndepSTA and
CFQoS):O
QB6 Direct-link setup (DLS) 6.3.14, 9.4.2.19, (CFAP AND Yes No N/A
9.6.4, 11.7 CFQoS):M
(CFSTAofAP AND
CFQoS):O
B.4.13 QoS enhanced distributed channel access (EDCA)
Item Protocol capability References Status Support
QD1 Support for four transmit queues 10.2.4.2, 10.22.2.1 not CFDMG AND Yes No N/A
with a separate channel access CFQoS:M
entity associated with each
QD2 Per-channel access function 10.22.2.2, not CFDMG AND Yes No N/A
differentiated channel access 10.22.2.4, CFQoS:M
10.22.2.11
QD3 Multiple frame transmission 10.22.2.7 CFQoS OR Yes No N/A
support CFDMG:O
QD4 Maintenance of within-queue 10.22.2.11 CFQoS OR Yes No N/A
ordering, exhaustive CFDMG:M
retransmission when sending
non-QoS Data frames
2724
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.13 QoS enhanced distributed channel access (EDCA) (continued)
Item Protocol capability References Status Support
QD5 Interpretation of admission 9.4.2.13, 10.22.4.2 (CFSTAofAP AND Yes No N/A
control mandatory (ACM) bit in (CFQoS OR
EDCA Parameter Set element CFDMG)):M
(CFPBSSnotPCP
AND CFDMG):
QD6 Contention based admission 9.4.2.14, 9.4.2.15, (CFAP AND Yes No N/A
control 9.6.3.2–9.6.3.4, (CFQoS OR
10.22.4.2, 11.4 CFDMG)):O
(CFSTAofAP AND
(CFQoS OR
CFDMG)):O
(CFPCP AND
CFDMG):O
(CFPBSSnotPCP
AND CFDMG):O
QD7 Power management in an 11.2 (CFAP AND Yes No N/A
infrastructure BSS or in an IBSS CFQoS):O
(CFIndepSTA AND
CFQoS):O
QD8 Default EDCA parameters for 9.4.2.29, 10.22.2.2 CFOCB:M Yes No N/A
communications outside context
of BSS
QD9 Duration/ID rules for QoS STA 9.2.5 CFQoS Yes No N/A
B.4.14 QoS hybrid coordination function (HCF) controlled channel access
(HCCA)
Item Protocol Capability References Status Support
QP1 Traffic specification (TSPEC) and 9.6.3 (CFAP AND Yes No N/A
associated frame formats CFQoS):M
(CFIndepSTA AND
CFQoS):M
QP2 HCCA rules 10.2.4.3, 10.22.3, (CFAP AND Yes No N/A
10.22.3.2– CFQoS):M
10.22.3.5 (CFIndepSTA AND
CFQoS):M
QP3 HCCA schedule generation and 10.22.4 (CFAP AND Yes No N/A
management CFQoS):M
QP4 HCF frame exchange sequences 10.4.3, 10.22.2 (CFAP AND Yes No N/A
CFQoS):M
(CFIndepSTA AND
CFQoS):M
QP5 Traffic stream (TS) management 11.4 (CFAP AND Yes No N/A
CFQoS):M
(CFIndepSTA AND
CFQoS):M
2725
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.14 QoS hybrid coordination function (HCF) controlled channel access
(HCCA) (continued)
Item Protocol Capability References Status Support
QP6 Minimum TSPEC parameter set 10.22.4 (CFAP AND Yes No N/A
CFQoS):M
(CFIndepSTA AND
CFQoS):M
QP7 Power management in an 11.2.3.5, 11.2.3.6, (CFAP AND Yes No N/A
infrastructure BSS 11.2.3.7, 11.2.3.8, CFQoS):M
11.2.3.9, (CFIndepSTA AND
11.2.3.10, CFQoS):M
11.2.3.11
B.4.15 Radio management extensions
Item Protocol Capability References Status Support
Are the following Radio
Measurement capabilities
supported?
RM1 Radio Measurement 9.4.1.4 CFRM:M Yes No N/A
Capability
RM2 Action frame protocol for 9.6 CFRM:M Yes No N/A
measurements
RM2.1 Radio Measurement 9.6.7.2 CFRM:M Yes No N/A
Request frame
RM2.2 Radio Measurement 9.6.7.3 CFRM:M Yes No N/A
Report frame
RM2.3 Link Measurement 9.6.7.4 CFRM:M Yes No N/A
Request frame
RM2.4 Link Measurement 9.6.7.5 CFRM:M Yes No N/A
Report frame
RM2.4.1 Link Measurement 9.6.7.5 not CF DMG Yes No N/A
Report frame AND
CFRM:M
RM2.4.2 Link Measurement 9.6.7.5, 9.4.2.149, CFDMG Yes No N/A
Report frame 9.4.2.150, 10.39 AND
CFRM:M
RM2.5 Neighbor Report Request
RM2.5.1 Generate and transmit 9.6.7.6 (CFRM Yes No N/A
Neighbor Report Request AND
CFSTAofAP
):M
RM2.5.2 Receive and process 9.6.7.6 (CFRM Yes No N/A
Neighbor Report Request AND
CFAP):M
RM2.6 Neighbor Report
Response
2726
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.15 Radio management extensions (continued)
Item Protocol Capability References Status Support
RM2.6.1 Generate and transmit 9.4.2.37, 9.6.7.7 (CFRM Yes No N/A
Neighbor Report AND
Response CFAP):M
RM2.6.2 Receive and process 9.4.2.37, 9.6.7.7 (CFRM Yes No N/A
Neighbor Report AND
Response CFSTAofAP
):M
RM3 General protocol for 9.4.2.21, 9.4.2.22, CFRM:M Yes No N/A
requesting and reporting 11.11, 11.11.6
of measurements
RM3.1 Parallel Measurements 9.4.2.21, 9.4.2.22, CFRM:M Yes No N/A
11.11.6
RM3.2 Use of Enable, Request 9.4.2.21, 11.11.6, CFRM:M Yes No N/A
and Report bits to enable/ 11.11.8
disable measurement
requests and triggered
autonomous reports
Measurement Requests
RM3.3 Enable Autonomous 9.4.2.21, 11.11.8 CFRM:M Yes No N/A
Report
RM3.4 Duration Mandatory 9.4.2.21, 11.11.4 CFRM:M Yes No N/A
RM3.5 Incapable Indication 9.4.2.22 CFRM:M Yes No N/A
RM3.6 Refused Indication 9.4.2.22, 11.11.5 CFRM:M Yes No N/A
RM3.7 Repeated Measurement 9.6.7.2, 11.11.7 CFRM:M Yes No N/A
RM3.8 Measurement Pause 9.4.2.21.12, CFRM:M Yes No N/A
11.11.9.7
RM4 Beacon Measurement 11.11, 11.11.9.1 CFRM:M Yes No N/A
Type
RM4.1 Beacon request 9.4.2.21.7 CFRM:M Yes No N/A
RM4.2 Passive Measurement 9.4.2.21.7, 11.11.9.1 CFRM:M Yes No N/A
mode
RM4.3 Active Measurement 9.4.2.21.7, 11.11.9.1 CFRM:M Yes No N/A
mode
RM4.4 Beacon table mode 9.4.2.21.7, 11.11.9.1 CFRM:M Yes No N/A
RM4.5 Reporting Conditions 9.4.2.21.7 CFRM:O Yes No N/A
RM4.6 Beacon report 9.4.2.21.7 CFRM:M Yes No N/A
RM4.7 Reporting Detail 9.4.2.21.7, CFRM:O Yes No N/A
9.4.2.22.7, 9.4.2.36
* RM5 Frame Measurement 11.11, 11.11.9.2 CFRM:O Yes No N/A
Type
RM5.1 Frame request 9.4.2.21.8 (CFRM Yes No N/A
AND
RM5):M
2727
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.15 Radio management extensions (continued)
Item Protocol Capability References Status Support
RM5.2 Frame report 9.4.2.22.8 (CFRM Yes No N/A
AND
RM5):M
RM6 Channel Load 11.11, 11.11.9.3 CFRM:M Yes No N/A
Measurement Type
RM6.1 Channel Load request 9.4.2.21.5 CFRM:M Yes No N/A
RM6.2 Channel Load report 9.4.2.22.5 CFRM:M Yes No N/A
RM7 Noise Histogram 11.11, 11.11.9.4 CFRM:M Yes No N/A
Measurement Type
RM7.1 Noise Histogram request 9.4.2.21.6 CFRM:M Yes No N/A
RM7.2 Noise Histogram report 9.4.2.22.6 CFRM:M Yes No N/A
RM8 STA Statistics 11.11, 11.11.9.5 CFRM:M Yes No N/A
Measurement Type
RM8.1 STA Statistics request 9.4.2.21.9 CFRM:M Yes No N/A
RM8.2 STA Statistics report 9.4.2.22.9 CFRM:M Yes No N/A
RM9 LCI Measurement Type 11.11, 11.11.9.6 CFRM:M Yes No N/A
RM9.1 LCI request 9.4.2.21.10 CFRM:M Yes No N/A
RM9.1.1 Location Subject 9.4.2.21.10 CFRM:M Yes No N/A
RM9.1.1.1 Location Subject third 9.4.2.21.10 CFRM:O Yes □ No □ N/A □
party
RM9.2 LCI report 9.4.2.22.10 CFRM:M Yes No N/A
RM9.3 Azimuth 11.11, 11.11.9.6 CFRM:O Yes No N/A
RM9.3.1 Azimuth Request 9.4.2.21.10 CFRM:O Yes No N/A
RM9.3.2 Azimuth Response 9.4.2.22.10 CFRM:O Yes No N/A
*RM10 Transmit Stream/ 11.11, 11.11.9.8 (CFRM Yes No N/A
Category Measurement AND
Type (CFQoS OR
CFDMG)):O
RM10.1 Transmit Stream/ 9.4.2.21.11 RM10:M Yes No N/A
Category Measurement
request
RM10.2 Transmit Stream/ 9.4.2.22.11 RM10:M Yes No N/A
Category Measurement
report
RM10.3 Triggered Transmit 9.4.2.22.11, RM10:O Yes No N/A
Stream/Category 11.11.9.8
Measurement report
RM11 AP Channel report 9.4.2.9, 9.4.2.36 (CFRM Yes No N/A
AND
CFAP):M
2728
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.15 Radio management extensions (continued)
Item Protocol Capability References Status Support
RM11.1 Generate and transmit 9.3.3.3, 9.3.3.11, (CFRM Yes No N/A
AP Channel report 9.4.2.36 AND
CFAP):M
RM11.2 Receive and process AP 9.3.3.3, 9.3.3.11, (CFRM Yes No N/A
Channel report 9.4.2.36 AND
CFSTAofAP
):M
RM12 Neighbor report 11.11, 11.11.10 CFRM:M Yes No N/A
procedure
RM12.1 Neighbor report 11.11.10.2, CFRM:M Yes No N/A
procedure 11.11.10.3
RM12.2 TSF Offset in Neighbor 9.4.2.37, 11.11.10.3 CFRM:O Yes No N/A
report
RM13 RCPI Measurement
RM13.1 RCPI Measurement for 15.4.6.6 (CFRM Yes No N/A
DSSS PHY at 2.4 GHz AND
CFDSSS):M
RM13.2 RCPI Measurement for 17.2.3.6, 17.3.10.7 (CFRM Yes No N/A
OFDM PHY at 5 GHz AND
CFOFDM):
M
RM13.3 RCPI Measurement for 16.3.8.6 (CFRM Yes No N/A
HR DSSS PHY at 2.4 AND
GHz CFHRDSSS
):M
RM13.4 RCPI Measurement for 18.2 (CFRM Yes No N/A
Extended Rate PHY at AND
2.4 GHz CFERP):M
RM14 RCPI Measurement
during Active Scanning
RM14.1 Respond with RCPI 11.1.4.3.2 (CFRM Yes No N/A
element when requested AND
(CFQoS OR
CFDMG)
AND
CFAP):M
RM14.2 Measurement of RCPI on 11.1.4.3.2 (CFRM Yes No N/A
Probe Request frames AND
(CFQoS OR
CFDMG)
AND
CFAP):O
RM15 RSNI Measurement 9.4.2.41 (CFRM Yes No N/A
AND
RM13):M
RM16 TPC Information in
Beacon and Probe
Response frames
2729
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.15 Radio management extensions (continued)
Item Protocol Capability References Status Support
RM16.1 Country and TPC Report 9.3.3.3, 9.3.3.11, CFRM:M Yes No N/A
elements included in 9.4.2.9, 9.4.2.17,
Beacon and Probe 11.8
Response frames
RM16.2 Power Constraint 9.3.3.3, 9.3.3.11, CFRM:O Yes No N/A
element included in 9.4.2.14
Beacon and Probe
Response frames
RM17 Power Capability 9.3.3.6, 9.3.3.7, CFRM:M Yes No N/A
elements in 11.9.2
(Re)Association frames
RM18 Management Information
Base
RM18.1 dot11RadioMeasurement Annex C (CFRM Yes No N/A
AND
CFAP):M
RM18.2 dot11SMTRMRequest Annex C (CFRM Yes No N/A
AND
CFAP):O
RM18.3 dot11SMTRMReport Annex C (CFRM Yes No N/A
AND
CFAP):O
RM18.4 dot11SMTRMConfig Annex C (CFRM Yes No N/A
AND
CFAP):O
RM19 Measurement Pilot frame 6.3.3.2, 9.4.1.18, CFRM:O Yes No N/A
9.4.2.46, 11.8,
11.11.14, 11.11.5
RM20 BSS Average Access 9.3.3.3, 9.3.3.11, (CFAP AND Yes No N/A
Delay elements included 9.4.2.39 CFRM):M
in Beacon and Probe
Response frames
RM21 Antenna elements 9.3.3.3, 9.3.3.11, CFRM:M Yes No N/A
included in Beacon and 9.4.2.40
Probe Response frames
RM22 Measurement Pilot 9.3.3.11, 9.4.2.42, CFRM:O Yes No N/A
Transmission element 9.4.2.46
and Multiple BSSID
element, if required,
included in Probe
Response frame
RM23 Quiet interval
RM23.1 AP-defined Quiet 9.3.3.3, 9.3.3.11, (CFAP AND Yes No N/A
Interval 9.4.2.23, 11.9.3 CFRM):M
RM23.2 STA-defined Quiet 9.3.3.3, 9.3.3.11, (CFSTAofA Yes No N/A
Interval 9.4.2.23, 11.9.3 P AND
CFRM):M
RM23.3 STA support for Quiet 9.3.3.3, 9.3.3.11, CFRM:M Yes No N/A
Interval 9.4.2.23, 11.9.3
2730
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.15 Radio management extensions (continued)
Item Protocol Capability References Status Support
RM24 BSS Available 9.4.2.43 (CFAP AND Yes No N/A
Admission Capacity (CFQoS OR
CFDMG)
AND
CFRM):M
RM25 BSS AC Access Delay 9.3.3.3, 9.3.3.11, not CFDMG Yes No N/A
9.4.2.44 AND (CFAP
AND
CFQoS
AND
CFRM):M
RM26 BSS AC Access Delay 9.3.3.3, 9.3.3.11, CFDMG Yes No N/A
9.4.2.44 AND CFAP
AND
CFRM:M
RM27 Directional channel 11.11, 11.32
quality measurement
RM27.1 Directional Channel 8.4.2.23.16, 11.32 (CFRM Yes No N/A
Quality request AND DMG-
M19):O
RM27.2 Directional Channel 8.4.2.24.15, 11.32 (CFRM Yes No N/A
Quality report AND DMG-
M19):M
RM28 Directional measurement 11.11
type
RM28.1 Directional Measurement 9.4.2.21.17 (CFRM Yes No N/A
request AND
CFDMG):O
RM28.2 Directional Measurement 9.4.2.22.16 (CFRM Yes No N/A
report AND
CFDMG):O
RM29 Directional statistics 11.11
measurement type
RM29.1 Directional Statistics 9.4.2.21.18 (CFRM Yes No N/A
Measurement Type AND
CFDMG):O
RM29.2 Directional Statistics 9.4.2.22.17 (CFRM Yes No N/A
Measurement Type AND
CFDMG):O
2731
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.16 DSE functions
Item Protocol capability References Status Support
*DSE1 Fixed STA operation with RegLoc 11.12.3 CF3G6:O.1 Yes No N/A
*DSE2 Enabling STA operation with RegLoc 11.12.3 CF3G6:O.1 Yes No N/A
DSE2.1 Enabling STA creation of DSE service 11.12.4 DSE2:M Yes No N/A
area
DSE2.2 Enabling STA operation with DSE 11.12.3 DSE2:M Yes No N/A
*DSE3 Dependent STA operation with DSE 11.12.5 CF3G6:O.1 Yes No N/A
DSE3.1 Dependent STA enablement 11.12.5 DSE3:M Yes No N/A
DSE3.2 Dependent STA DSE time to 11.12.5 DSE3:M Yes No N/A
enablement
DSE3.3 Dependent STA DSE time to not 11.12.5 DSE3:M Yes No N/A
transmit
DSE3.4 Dependent STA DSE Registered 11.12.5 DSE3:M Yes No N/A
Location Announcement frame
DSE3.5 Dependent STA MLME- 6.3.7.5 DSE3:M Yes No N/A
ASSOCIATE.response primitive DSE
DSE3.6 Dependent STA MLME- 6.3.8.5 DSE3:M Yes No N/A
REASSOCIATE.response primitive
DSE
DSE4 DSE request report procedure 11.12.5 (CF3G6 AND Yes No N/A
Transmission of DSE measurement CFAP):M
request by an AP 11.12.5 Yes No N/A
Transmission of DSE measurement (CF3G6 AND
report by a STA CFSTAofAP):M
DSE5 STA association procedure 10.21.3, (CF3G6 AND Yes No N/A
Transmission of Association Request 11.3.5.2, CFSTAofAP):M
frame with Supported Operating 11.3.5.3
Classes element by a STA
Transmission of Association Response (CF3G6 AND Yes No N/A
frame with Supported Operating CFAP):M
Classes element by an AP
DSE6 STA reassociation procedure 11.3.5.4, (CF3G6 AND Yes No N/A
Transmission of Reassociation Request 11.3.5.5 CFSTAofAP):M
frame with Supported Operating
Classes element by a STA
Transmission of Reassociation (CF3G6 AND Yes No N/A
Response frame with Supported CFAP):M
Operating Classes element by an AP
DSE7 Probe request procedure 11.10.1 CF3G6 AND Yes No N/A
Transmission of Probe Request frame CFSTAofAP:M
with Supported Operating Classes
element by a STA
DSE8 Probe response procedure 11.10.1 CF3G6 AND Yes No N/A
Transmission of Probe Response frame CFAP:M
with Supported Operating Classes
element by an AP
DSE9 Extended channel switching procedure 11.10.1
2732
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.16 DSE functions (continued)
Item Protocol capability References Status Support
DSE9.1 Transmission of extended channel 11.10.3 (CF3G6 AND Yes No N/A
switch announcement frame/element CFAP):M
and extended channel switching (CFAP AND
procedure by an AP. CFVHT):M
(CFAP AND
CFTVHT):M
DSE9.2 Transmission of extended channel 11.10.3 (CF3G6 AND Yes No N/A
switch announcement frame/element CFIBSS):M
and extended channel switching (CFIBSS AND
procedure by a STA. CFVHT):M
(CFIBSS AND
CFTVHT):M
DSE9.3 Reception of extended channel switch 11.10.3 CF3G6:M Yes No N/A
announcement frame/element and CFVHT:M
extended channel switching procedure CFTVHT:M
by a STA.
DSE9.4 Transmission of Wide Bandwidth 11.40.4 (CFAP AND Yes No N/A
Channel Switch element in Extended CFESM):M
Channel Announcement frame and
transmission of Wide Bandwidth
Channel Switch subelement in Channel
Switch Wrapper element in Beacon/
Probe Response frames, and associated
extended channel switching procedure
by an AP.
DSE9.5 Transmission of Wide Bandwidth 11.40.4 (CFIBSS AND Yes No N/A
Channel Switch element in Extended CFESM):M
Channel Announcement frame and
transmission of Wide Bandwidth
Channel Switch subelement in Channel
Switch Wrapper element in Beacon/
Probe Response frames, and associated
extended channel switching procedure
by a STA.
DSE9.6 Reception of Wide Bandwidth Channel 11.40.4 CFESM:M Yes No N/A
Switch element in Extended Channel
Announcement frame and reception of
Wide Bandwidth Channel Switch
subelement in Channel Switch
Wrapper element in Beacon/Probe
Response frames, and associated
extended channel switching procedure
by a STA.
DSE9.7 Transmission of New Transmit Power 11.40.4 (CFAP AND Yes No N/A
Envelope element in Extended CFESM):M
Channel Announcement frame and
transmission of New Transmit Power
Envelope subelement in Channel
Switch Wrapper element in Beacon/
Probe Response frames, and associated
extended channel switching procedure
by an AP.
2733
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.16 DSE functions (continued)
Item Protocol capability References Status Support
DSE9.8 Transmission of New Transmit Power 11.40.4 (CFIBSS AND Yes No N/A
Envelope element in Extended CFESM):M
Channel Announcement frame and
transmission of NewTransmit Power
Envelope subelement in Channel
Switch Wrapper element in Beacon/
Probe Response frames, and associated
extended channel switching procedure
by a STA.
DSE9.9 Reception of New Transmit Power 11.40.4 CFESM:M Yes No N/A
Envelope element in Extended
Channel Announcement frame and
reception of New Transmit Power
Envelope subelement in Channel
Switch Wrapper element in Beacon/
Probe Response frames, and associated
extended channel switching procedure
by a STA.
DSE9.10 Transmission of New Country element 11.40.4 (CFAP AND Yes No N/A
in Extended Channel Announcement CFESM):M
frame and transmission of New
Country subelement in Channel Switch
Wrapper element in Beacon/Probe
Response frames, and associated
extended channel switching procedure
by an AP.
DSE9.11 Transmission of New Country element 11.40.4 (CFIBSS AND Yes No N/A
in Extended Channel Announcement CFESM):M
frame and transmission of New
Country subelement in Channel Switch
Wrapper element in Beacon/Probe
Response frames, and associated
extended channel switching procedure
by a STA.
DSE9.12 Reception of New Country element in 11.40.4 CFESM:M Yes No N/A
Extended Channel Announcement
frame and reception of New Country
subelement in Channel Switch
Wrapper element in Beacon/Probe
Response frames, and associated
extended channel switching procedure
by a STA.
DSE10 DSE power constraint procedure 11.12.5 (CF3G6 AND Yes No N/A
Transmission of DSE power constraint CFAP):M
announcement by an enabling STA 11.12.5
Reception of DSE power constraint Yes No N/A
announcement by a dependent STA CF3G6:M
2734
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.17 High-throughput (HT) features
B.4.17.1 HT MAC features
Item Protocol capability References Status Support
Are the following MAC protocol
features supported?
HTM1 HT capabilities signaling
HTM1.1 HT Capabilities element 9.4.2.56.1 CFHT:M Yes No N/A
CFTVHT:M
HTM1.2 Signaling of STA capabilities in 9.3.3.6, 9.3.3.8, (CFHT AND Yes No N/A
Probe Request, (Re)Association 9.3.3.10, CFIndepSTA):
Request frames 9.4.2.56 M
(CFTVHT
AND
CFIndepSTA):
M
HTM1.3 Signaling of STA and BSS 9.3.3.3, 9.3.3.7, (CFHT AND Yes No N/A
capabilities in Beacon, Probe 9.3.3.9, CFAP):M
Response, (Re)Association 9.3.3.11, (CFTVHT
Response frames 9.4.2.56 AND CFAP):M
HTM2 Signaling of HT operation 9.4.2.57 (CFHT AND Yes No N/A
CFAP):M
(CFTVHT
AND CFAP):M
HTM3 MPDU aggregation
HTM3.1 Reception of A-MPDU 9.4.2.56.3, CFHT:M Yes No N/A
10.13.2, 12.5
HTM3.2 A-MPDU format 9.7.1 CFHT:M Yes No N/A
HTM3.3 A-MPDU contents 9.7.3 CFHT:M Yes No N/A
HTM3.4 A-MPDU frame exchange 10.22.2.7 CFHT:M Yes No N/A
sequences
HTM3.5 Transmission of A-MPDU 9.4.2.56.3, 12.5 CFHT:O Yes No N/A
CFVHT:M
HTM4 MSDU aggregation
HTM4.1 Reception of A-MSDUs 9.2.4.5, 9.3.2.2 CFHT:M Yes No N/A
HTM4.2 A-MSDU format 9.3.2.2 CFHT:M Yes No N/A
HTM4.3 A-MSDU content 9.3.2.2 CFHT:M Yes No N/A
HTM4.4 Transmission of A-MSDUs 9.2.4.5, 9.3.2.2 CFHT:O Yes No N/A
HTM5 Block Ack
HTM5.1 Block ack mechanism 9.3.1.8, 9.3.1.9, CFHT:M Yes No N/A
9.4.1.14, 10.24, CFTVHT:M
11.16
HTM5.2 Use of compressed bitmap between 9.3.1.9.3, CFHT:M Yes No N/A
HT STAs 10.24.6 CFTVHT:M
HTM5.3 HT-immediate block ack extensions 10.24.7 CFHT:M Yes No N/A
CFTVHT:M
2735
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.17.1 HT MAC features (continued)
Item Protocol capability References Status Support
HTM5.4 HT-delayed block ack extensions 10.24.8 CFHT AND Yes No N/A
QB4.2:O
HT-delayed block ack is obsolete.
Support for this mechanism might CFTVHT AND
be removed in a later revision of the QB4.2:O
standard.
HTM5.5 Multiple TID Block Ack 9.3.1.8.5, PC37:M Yes No N/A
9.3.1.9.4,
10.29.2.7
HTM6 Protection mechanisms for different
HT PHY options
HTM6.1 Protection of RIFS PPDUs in the 10.26.3.3 CFHT:M Yes No N/A
presence of non-HT STAs
HTM6.2 Protection of RIFS PPDUs in an 10.26.3.3 CFHT:M Yes No N/A
IBSS
HTM6.3 Protection of HT-greenfield PPDUs 10.26.3.1 HTP1.3:M Yes No N/A
in the presence of non-HT STAs
HTM6.4 Protection of HT-greenfield PPDUs 10.26.3.1 CFHT:M Yes No N/A
in an IBSS
*HTM7 L-SIG TXOP protection mechanism 10.26.5 CFHT:O Yes No N/A
The L-SIG TXOP protection
mechanism is obsolete.
Consequently, the L-SIG TXOP
protection mechanism might be
removed in a later revision of this
standard.
HTM7.1 Update NAV according to L-SIG 10.26.5.4 HTM7:M Yes No N/A
HTM8 Duration/ID rules for A-MPDU 9.7.3 CFHT:M Yes No N/A
HTM9 Truncation of TXOP as TXOP holder 10.22.2.9 CFHT:O Yes No N/A
CFTVHT:O
HTM10 Reception of +HTC frames 9.2.4.1.10, CFHT:O Yes No N/A
9.4.2.56.5, 10.9 CFTVHT:O
*HTM11 Reverse direction (RD) aggregation 10.28 CFHT:O Yes No N/A
exchanges CFTVHT:O
HTM11.1 Constraints regarding responses 10.28.4 HTM11:M Yes No N/A
HTM12 Link adaptation
HTM12.1 Use of the HT Control field for link 9.2.4.6, CFHT:O Yes No N/A
adaptation in immediate response 9.3.3.15, CFTVHT:O
exchange 10.31.2
HTM12.2 Link adaptation using explicit 9.3.3.15, CFHT:O Yes No N/A
feedback mechanism 10.32.3 CFTVHT:O
HTM13 Transmit beamforming
*HTM13.1 Transmission of beamformed 10.32 CFHT:O Yes No N/A
PPDUs
*HTM13.2 Reception of beamformed PPDUs 10.32 CFHT:O Yes No N/A
*HTM13.3 Initiate transmit beamforming frame 10.32.2 HTM13.1:O Yes No N/A
exchange with implicit feedback
HTM13.3.1 Reception of sounding PPDUs 10.32.2 HTM13.3:M Yes No N/A
2736
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.17.1 HT MAC features (continued)
Item Protocol capability References Status Support
*HTM13.4 Response to transmit beamforming 10.32.2 HTM13.2:O Yes No N/A
frame exchange with implicit
feedback
HTM13.4.1 Transmission of sounding PPDUs 10.32.2 HTM13.4:M Yes No N/A
*HTM13.5 Initiate transmit beamforming frame 9.6.12.6, HTM13.1:O Yes No N/A
exchange with explicit feedback 10.32.3
HTM13.5.1 Transmission of sounding PPDUs 10.32.3 HTM13.5:M Yes No N/A
*HTM13.6 Respond to transmit beamforming 10.32.3 HTM13.2:O Yes No N/A
frame exchange with explicit
feedback
HTM13.6.1 Transmission of Action No Ack 9.6.12.6, HTM13.6:O.1 Yes No N/A
+HTC frame including Action 10.32.3
payload of type CSI
HTM13.6.2 Transmission of Action No Ack 9.6.12.7, HTM13.6:O.1 Yes No N/A
+HTC frame including Action 10.32.3
payload of type “Noncompressed
beamforming”
HTM13.6.3 Transmission of Action No Ack 9.6.12.8, HTM13.6:O.1 Yes No N/A
+HTC frame including Action 10.32.3
payload of type “Compressed
beamforming”
*HTM13.7 Calibration procedure 9.3.3.15, HTM13:O Yes No N/A
10.32.2.4
HTM14 Antenna selection (ASEL) 9.2.4.6, CFHT:O Yes No N/A
9.4.2.56.7,
9.6.12.9, 10.33
*HTM15 Null data packet (NDP) 10.34 CFHT:O Yes No N/A
HTM16 Space-time block coding (STBC)
support
HTM16.1 STBC beacon transmission 11.1.3.2 HTP2.11:O Yes No N/A
The use of the STBC beacon
transmission mechanism is
deprecated.
HTM16.2 Dual CTS protection 10.3.2.8 HTP2.11:O Yes No N/A
The use of the dual CTS mechanism
is deprecated.
HTM17 SM power save support
*HTM17.1 AP support for non-AP STA 11.2.6 (CFHT AND Yes No N/A
dynamic and static SM power save CFAP):M
mode (CFTVHT
AND CFAP):M
*HTM17.2 STA support for local dynamic and 11.2.6 (CFHT AND Yes No N/A
static SM power save mode CFIndepSTA):
O
(CFTVHT
AND
CFIndepSTA):
O
2737
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.17.1 HT MAC features (continued)
Item Protocol capability References Status Support
HTM17.3 Transmit SM power save state 9.6.12.3, 11.2.6 HTM17.2:M Yes No N/A
information using HT Capabilities
element, or SM Power Save frame
HTM17.4 Receive SM power save state 11.2.6 HTM17.1:M Yes No N/A
information and support frame
exchanges with STAs in SM power
save mode
HTM18 Mechanisms for coexistence of 11.16 CFHT:M Yes No N/A
20 MHz and 40 MHz channels
HTM19 Channel selection methods for 11.16.3 (HTP2.3.4 Yes No N/A
20/40 MHz operation AND CFAP):M
HTM20 20/40 MHz operation 11.16 HTP2.3.4:M Yes No N/A
HTM21 Phased coexistence operation (PCO)
The PCO mechanism is obsolete.
Consequently, the PCO mechanism
might be removed in a later revision
of this standard.
*HTM21.1 PCO capability at AP 11.17 (CFHT AND Yes No N/A
CFAP):O
HTM21.1.1 Rules for operation at a PCO 9.6.12.5, HTM21.1:M Yes No N/A
active AP 11.17.2
*HTM21.2 STA support for PCO mode 11.17 (CFHT AND Yes No N/A
CFIndepSTA):
O
HTM21.2.1 Rules for operation at PCO active 9.6.12.5, HTM21.2:M Yes No N/A
STA 11.17.3
HTM22 Management information base (MIB)
HTM22.1 dot11PhyHTComplianceGroup Annex C CFHT:M Yes No N/A
HTM22.2 dot11PhyMCSGroup Annex C CFHT:M Yes No N/A
B.4.17.2 HT PHY features
Item Protocol capability References Status Support
Are the following PHY protocol
features supported?
HTP1 PHY operating modes
HTP1.1 Operation according to 18 19.1.4 CFHT:M Yes No N/A
(Orthogonal frequency division
multiplexing (OFDM) PHY
specification) and/or Clause 19
(Extended Rate PHY (ERP)
specification)
HTP1.2 HT-mixed format 19.1.4 CFHT:M Yes No N/A
*HTP1.3 HT-greenfield format 19.1.4 CFHT:O Yes No N/A
HTP2 PHY frame format
2738
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.17.2 HT PHY features (continued)
Item Protocol capability References Status Support
HTP2.1 HT-mixed format PPDU format 19.3.2 CFHT:M Yes No N/A
HTP2.2 HT-greenfield PPDU format 19.3.2 HTP1.3:M Yes No N/A
HTP2.3 Modulation and coding schemes
(MCS)
HTP2.3.1 MCS 0 to MCS 7 in 20 MHz with
800 ns guard interval (GI)
HTP2.3.1.1 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A
GI MCS index 0
HTP2.3.1.2 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A
GI MCS index 1
HTP2.3.1.3 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A
GI MCS index 2
HTP2.3.1.4 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A
GI MCS index 3
HTP2.3.1.5 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A
GI MCS index 4
HTP2.3.1.6 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A
GI MCS index 5
HTP2.3.1.7 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A
GI MCS index 6
HTP2.3.1.8 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A
GI MCS index 7
HTP2.3.2 MCS 8 to MCS 15 in 20 MHz
with 800 ns GI
HTP2.3.2.1 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A
GI MCS index 8 CFAP):M
HTP2.3.2.2 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A
GI MCS index 9 CFAP):M
HTP2.3.2.3 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A
GI MCS index 10 CFAP):M
HTP2.3.2.4 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A
GI MCS index 11 CFAP):M
HTP2.3.2.5 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A
GI MCS index 12 CFAP):M
HTP2.3.2.6 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A
GI MCS index 13 CFAP):M
HTP2.3.2.7 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A
GI MCS index 14 CFAP):M
HTP2.3.2.8 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A
GI MCS index 15 CFAP):M
HTP2.3.3 Transmit and receive support for 19.3.5, 19.5 CFHT:O Yes No N/A
400 ns GI
*HTP2.3.4 Operation at 40 MHz 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5 Support for MCS with indices 16
to 76
HTP2.3.5.1 Support for MCS with index 16 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.2 Support for MCS with index 17 19.3.5, 19.5 CFHT:O Yes No N/A
2739
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.17.2 HT PHY features (continued)
Item Protocol capability References Status Support
HTP2.3.5.3 Support for MCS with index 18 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.4 Support for MCS with index 19 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.5 Support for MCS with index 20 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.6 Support for MCS with index 21 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.7 Support for MCS with index 22 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.8 Support for MCS with index 23 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.9 Support for MCS with index 24 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.10 Support for MCS with index 25 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.11 Support for MCS with index 26 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.12 Support for MCS with index 27 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.13 Support for MCS with index 28 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.14 Support for MCS with index 29 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.15 Support for MCS with index 30 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.16 Support for MCS with index 31 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.17 Support for MCS with index 32 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.18 Support for MCS with index 33 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.19 Support for MCS with index 34 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.20 Support for MCS with index 35 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.21 Support for MCS with index 36 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.22 Support for MCS with index 37 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.23 Support for MCS with index 38 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.24 Support for MCS with index 39 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.25 Support for MCS with index 40 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.26 Support for MCS with index 41 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.27 Support for MCS with index 42 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.28 Support for MCS with index 43 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.29 Support for MCS with index 44 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.30 Support for MCS with index 45 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.31 Support for MCS with index 46 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.32 Support for MCS with index 47 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.33 Support for MCS with index 48 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.34 Support for MCS with index 49 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.35 Support for MCS with index 50 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.36 Support for MCS with index 51 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.37 Support for MCS with index 52 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.38 Support for MCS with index 53 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.39 Support for MCS with index 54 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.40 Support for MCS with index 55 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.41 Support for MCS with index 56 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.42 Support for MCS with index 57 19.3.5, 19.5 CFHT:O Yes No N/A
2740
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.17.2 HT PHY features (continued)
Item Protocol capability References Status Support
HTP2.3.5.43 Support for MCS with index 58 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.44 Support for MCS with index 59 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.45 Support for MCS with index 60 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.46 Support for MCS with index 61 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.47 Support for MCS with index 62 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.48 Support for MCS with index 63 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.49 Support for MCS with index 64 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.50 Support for MCS with index 65 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.51 Support for MCS with index 66 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.52 Support for MCS with index 67 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.53 Support for MCS with index 68 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.54 Support for MCS with index 69 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.55 Support for MCS with index 70 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.56 Support for MCS with index 71 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.57 Support for MCS with index 72 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.58 Support for MCS with index 73 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.59 Support for MCS with index 74 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.60 Support for MCS with index 75 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.3.5.61 Support for MCS with index 76 19.3.5, 19.5 CFHT:O Yes No N/A
HTP2.4 PHY timing parameters
HTP2.4.1 Values in non-HT 20 MHz channel 19.3.6 CFHT:M Yes No N/A
HTP2.4.2 Values in 20 MHz HT channel 19.3.6 CFHT:M Yes No N/A
HTP2.4.3 Values in 40 MHz channel 19.3.6 HTP2.3.4:M Yes No N/A
HTP2.5 HT Preamble field definition and
coding
HTP2.5.1 HT-mixed format preamble 19.3.9.2 CFHT:M Yes No N/A
HTP2.5.2 HT-greenfield preamble 19.3.9.5 HTP1.3:M Yes No N/A
HTP2.5.3 Extension HT Long Training 19.3.9.4.6 CFHT:O Yes No N/A
fields (HT-ELTFs)
HTP2.6 HT Data field definition and 19.3.11 CFHT:M Yes No N/A
coding
HTP2.6.1 Use of LDPC codes 19.3.11.7 CFHT:O Yes No N/A
HTP2.7 Beamforming 19.3.12 CFHT:O Yes No N/A
HTP2.8 Sounding PPDUs
HTP2.8.1 HT preamble format for sounding 19.3.13 CFHT:O Yes No N/A
PPDUs
HTP2.8.2 Sounding with an NDP 19.3.13.2 HTM15:O Yes No N/A
HTP2.8.3 Sounding PPDU for calibration 19.3.13.3 HTM14.7:M Yes No N/A
HTP2.9 Channel numbering and
channelization
HTP2.9.1 Channel allocation for 20 MHz 17.3.8.4 CFHT:M Yes No N/A
channels at 5 GHz
2741
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.17.2 HT PHY features (continued)
Item Protocol capability References Status Support
HTP2.9.2 Channel allocation for 20 MHz 18.4.3 CFHT:M Yes No N/A
channels at 2.4 GHz
HTP2.9.3 Channel allocation for 40 MHz 19.3.15.3 HTP2.3.4:M Yes No N/A
channels at 5 GHz
HTP2.9.4 Channel allocation for 40 MHz 19.3.15.2 HTP2.3.4:M Yes No N/A
channels at 2.4 GHz
HTP2.10 PHY transmit specification
HTP2.10.1 PHY transmit specification for 19.3.18 CFHT:M Yes No N/A
20 MHz channel
HTP2.10.2 PHY transmit specification for 19.3.18 HTP2.3.4:M Yes No N/A
40 MHz channel
*HTP2.11 Space-time block coding (STBC) 19.3.11.9.2 CFHT:O Yes No N/A
HTP2.12 PHY receive specification EMPTY
HTP2.12.1 PHY receive specification for 19.3.19 CFHT:M Yes No N/A
20 MHz channel
HTP2.12.2 PHY receive specification for 19.3.19 HTP2.3.4:M Yes No N/A
40 MHz channel
HTP2.13 PPDU reception with RIFS 19.3.19.7 CFHT:M Yes No N/A
B.4.18 Tunneled direct-link setup extensions
Item Protocol capability References Status Support
TDLS1 Tunneled direct-link setup 9.6.13, 11.23 CFIndepSTA Yes No N/A
AND
CFTDLS:M
TDLS1.1 TDLS setup 9.4.2.62, CFIndepSTA Yes No N/A
9.6.13.2, AND
9.6.13.3, CFTDLS:M
9.6.13.4,
11.23.4
TDLS1.2 TDLS teardown 9.4.2.62, CFIndepSTA Yes No N/A
9.6.13.5, AND
11.23.5 CFTDLS:M
TDLS1.3 TPK handshake 12.7.9 CFIndepSTA Yes No N/A
AND
CFTDLS:M
TDLS1.4 TDLS peer PSM 9.4.2.62, CFIndepSTA Yes No N/A
9.4.2.63, AND
9.6.13.9, CFTDLS:O
9.6.13.10,
11.2.3.14
TDLS 1.5 TPU 9.4.2.62, CFIndepSTA Yes No N/A
9.4.2.65, AND
9.4.2.66, CFTDLS:O
9.6.13.6,
9.6.13.11,
11.2.3.15
2742
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.18 Tunneled direct-link setup extensions (continued)
Item Protocol capability References Status Support
TDLS 1.6 TDLS Channel Switching 9.4.2.62, CFIndepSTA Yes No N/A
9.4.2.64, AND CFMD
9.6.13.7, AND
9.6.13.8, CFOC AND
11.23.6 CFTDLS:O
TDLS1.7 TDLS Discovery 9.4.2.62, CFIndepSTA Yes No N/A
9.6.8.16, AND CFMD
9.6.13.12, AND
11.23.3 CFOC AND
CFTDLS:O
B.4.19 WNM extensions
Item Protocol capability References Status Support
WNM1 Extended Capabilities element 9.4.2.27 CFWNM:M Yes □ No □ N/A □
WNM2 STA Statistics (Triggered) and 11.11.8 CFWNM:M Yes □ No □ N/A □
Multicast Diagnostics
WNM2.1 Protocol for Triggered 11.11.8 CFWNM:M Yes □ No □ N/A □
Measurements
WNM2.2 Triggered STA Statistics 9.4.2.21.9, CFWNM:O Yes □ No □ N/A □
9.4.2.22.9,
9.6.7.2,
9.6.7.3,
11.11.9.5
WNM2.3 Multicast Diagnostics 9.4.2.21.13, CFWNM:M Yes □ No □ N/A □
9.4.2.22.12,
9.6.7.2,
9.6.7.3,
11.11.19
WNM3 Event 11.24.2 CFWNM:M Yes □ No □ N/A □
WNM3.1 Event Request frame 9.4.2.67, (CFWNM Yes □ No □ N/A □
9.6.14.2 AND
CFAP):M
WNM3.2 Event Report frame 9.4.2.68, (CFWNM Yes □ No □ N/A □
9.6.14.3 AND
CFIndepSTA)
:M
WNM4 Diagnostic 11.24.3 CFWNM:M Yes □ No □ N/A □
WNM4.1 Diagnostic Request frame 9.4.2.69, (CFWNM Yes □ No □ N/A □
9.6.14.4 AND
CFAP):M
WNM4.2 Diagnostic Report frame 9.4.2.70, (CFWNM Yes □ No □ N/A □
9.6.14.5 AND
CFIndepSTA)
:M
WNM4.3 Configuration Profile Diagnostic 9.4.2.70.3, CFWNM:M Yes □ No □ N/A □
Type 11.24.3.2
2743
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.19 WNM extensions (continued)
Item Protocol capability References Status Support
WNM4.4 Manufacturer Information STA 9.4.2.70.2, CFWNM:M Yes □ No □ N/A □
Report Diagnostic Type 11.24.3.3
WNM4.5 Association Diagnostic Type 9.4.2.69.2, CFWNM:M Yes □ No □ N/A □
9.4.2.70.4,
11.24.3.4
WNM4.6 IEEE 802.1X Authentication 9.4.2.69.3, (CFWNM Yes □ No □ N/A □
Diagnostic Type 9.4.2.70.5, AND
11.24.3.5 PC34):M
WNM5 Location 9.4.2.71, CFWNM:M Yes □ No □ N/A □
11.24.4
WNM5.1 Location Civic request/report 11.11.9.9 CFWNM:M Yes □ No □ N/A □
WNM5.2 Location Identifier request/report 11.11.9.10 CFWNM:M Yes □ No □ N/A □
WNM5.3 Location Track Notification 9.6.8.17, CFWNM:O Yes □ No □ N/A □
11.24.4
WNM5.3.1 Time of Departure Notifications 9.4.2.71, CFWNM:O Yes □ No □ N/A □
11.24.4
WNM5.3.2 Motion Detection Notifications 9.4.2.71, CFWNM:O Yes □ No □ N/A □
11.24.4
WNM5.4 Location Configuration Request 9.4.2.71, CFWNM:M Yes □ No □ N/A □
frame 9.6.14.6
WNM5.4.1 Normal Indication 9.4.2.71, CFWNM:O Yes □ No □ N/A □
9.6.14.6
WNM5.4.2 Motion Indication 9.4.2.71, CFWNM:O Yes □ No □ N/A □
9.6.14.6
WNM5.5 Location Configuration Response 9.4.2.71, CFWNM:M Yes □ No □ N/A □
frame 9.6.14.7
*WNM6 Multiple BSSID Support 11.1.3.8, CFWNM:O Yes □ No □ N/A □
11.1.4,
11.11.14
WNM6.1 Multiple BSSID element 9.4.2.46 WNM6:M Yes □ No □ N/A □
WNM6.2 Multiple BSSID-index element 9.4.2.74 WNM6:M Yes □ No □ N/A □
WNM7 BSS transition management 11.24.7 CFWNM:O Yes □ No □ N/A □
WNM7.1 Neighbor Report element 9.4.2.37 (CFWNM Yes □ No □ N/A □
AND
CFAP):M
WNM7.2 BSS Transition Management 9.6.14.8 (CFWNM Yes □ No □ N/A □
Query frame AND
CFAP):M
WNM7.3 BSS Transition Management 9.6.14.9 (CFWNM Yes □ No □ N/A □
Request frame AND
CFIndepSTA)
:M
WNM7.4 BSS Transition Management 9.6.14.10 (CFWNM Yes □ No □ N/A □
Response frame AND
CFIndepSTA)
:M
2744
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.19 WNM extensions (continued)
Item Protocol capability References Status Support
*WNM8 FMS 11.2.3.16 CFWNM:O Yes □ No □ N/A □
WNM8.1 FMS Request frame 9.6.14.11 (CFIndepSTA Yes □ No □ N/A □
AND
WNM8):M
WNM8.2 FMS Response frame 9.6.14.12 (CFAP AND Yes □ No □ N/A □
WNM8):M
WNM9 Proxy ARP 11.24.14 CFWNM:O Yes □ No □ N/A □
*WNM10 Collocated Interference Reporting 11.24.10 CFWNM:O Yes □ No □ N/A □
WNM10.1 Collocated Interference Request 9.6.14.13 WNM10:M Yes □ No □ N/A □
frame
WNM10.2 Collocated Interference Report 9.6.14.14 WNM10:M Yes □ No □ N/A □
frame
*WNM11 BSS max idle period 11.24.13 CFWNM:M Yes □ No □ N/A □
WNM11.1 BSS Max Idle Period element 9.4.2.79 WNM11:M Yes □ No □ N/A □
*WNM12 TFS 11.24.12 CFWNM:O Yes □ No □ N/A □
WNM12.1 TFS Request frame 9.4.2.80, WNM12:M Yes □ No □ N/A □
9.6.14.15
WNM12.2 TFS Response frame 9.4.2.81, WNM12:M Yes □ No □ N/A □
9.6.14.16
WNM12.3 TFS Notify frame 9.6.14.17 (CFAP AND Yes □ No □ N/A □
WNM12):M
(CFIndepSTA
AND
WNM12):O
*WNM13 WNM sleep mode 11.2.3.18 WNM12:O Yes □ No □ N/A □
WNM13.1 WNM Sleep Mode Request frame 9.4.2.82, WNM13:M Yes □ No □ N/A □
9.6.14.19
WNM13.2 WNM Sleep Mode Response 9.4.2.82, WNM13:M Yes □ No □ N/A □
frame 9.6.14.20
*WNM14 TIM Broadcast 11.2.3.17 CFWNM:O Yes □ No □ N/A □
WNM14.1 TIM Broadcast Request frame 9.4.2.83, WNM14:M Yes □ No □ N/A □
9.6.14.21
WNM14.2 TIM Broadcast Response frame 9.4.2.84, WNM14:M Yes □ No □ N/A □
9.6.14.22
WNM14.3 TIM Broadcast frame 9.6.15.2 WNM14:M Yes □ No □ N/A □
*WNM15 QoS Traffic Capability 11.24.10 (CFWNM Yes □ No □ N/A □
AND
CFIndepSTA)
:O
WNM15.1 QoS Traffic Capability element 9.4.2.78 WNM15:M Yes □ No □ N/A □
WNM15.2 QoS Traffic Capability Update 9.6.14.23 WNM15:M Yes □ No □ N/A □
frame
WNM16 AC Station Count 11.24.11 (CFWNM Yes □ No □ N/A □
AND
CFIndepSTA)
:O
2745
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.19 WNM extensions (continued)
Item Protocol capability References Status Support
WNM17 Timing Measurement 11.24.5 CFWNM:O Yes □ No □ N/A □
WNM17.1 Timing Measurement Request 9.6.14.28 WNM17:M Yes □ No □ N/A □
WNM17.2 Timing Measurement 9.6.15.3 WNM17:M Yes □ No □ N/A □
*WNM18 Channel Usage 11.24.15 CFWNM:O Yes □ No □ N/A □
WNM18.1 Channel Usage Request frame 9.4.2.86, WNM18:M Yes □ No □ N/A □
9.6.14.24
WNM18.2 Channel Usage Response frame 9.4.2.86, WNM18:M Yes □ No □ N/A □
9.6.14.25
*WNM19 DMS 11.24.16 (CFWNM Yes □ No □ N/A □
AND
CFHT):O
(CFWNM
AND
CFTVHT):O
WNM19.1 DMS Request frame 9.4.2.88, WNM19:M Yes □ No □ N/A □
9.6.14.26
WNM19.2 DMS Response frame 9.4.2.89, WNM19:M Yes □ No □ N/A □
9.6.14.27
WNM20 UTC TSF Offset 9.4.2.61, CFWNM:O Yes □ No □ N/A □
9.4.2.87,
11.22.3
WNM21 U-APSD coexistence 9.4.2.91, CFWNM:O Yes □ No □ N/A □
11.2.3.5.2
WNM22 WNM notification 11.24.17 (CFWNM Yes □ No □ N/A □
AND
CFHT):O
(CFWNM
AND
CFTVHT):O
WNM22.1 WNM Notification Request 9.6.14.29 WNM21:M Yes □ No □ N/A □
frame
WNM22.2 WNM Notification Response 9.6.14.30 WNM21:M Yes □ No □ N/A □
frame
WNM23 Fine timing measurement 11.24.6 CFWNM:O Yes □ No □ N/A □
WNM23.1 Fine timing measurement request 9.6.8.32 WNM23:M Yes □ No □ N/A □
(including LCI and/or location
civic request)
WNM23.2 Fine timing measurement 9.6.8.33 WNM23:M Yes □ No □ N/A □
(including LCI and/or location
civic report)
WNM23.3 Request neighbor LCI and/or civic 11.11.10.2 (CFIndepSTA Yes □ No □ N/A □
locations within neighbor report OR CFMBSS)
request AND
WNM23:M
WNM23.4 Report neighbor LCI and/or civic 11.11.10.2 CFAP AND Yes □ No □ N/A □
locations within neighbor report WNM23:M
response
2746
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.19 WNM extensions (continued)
Item Protocol capability References Status Support
WNM23.5 Transmitter of Fine Timing 11.11.9.11 WNM23:M Yes □ No □ N/A □
Measurement Range request and
receiver of Fine Timing
Measurement Range report
WNM23.6 Receiver of Fine Timing 11.11.9.11 (CFIndepSTA Yes □ No □ N/A □
Measurement Range request and OR CFMBSS)
transmitter of Fine Timing AND
Measurement Range report WNM23:M
B.4.20 Interworking (IW) with external networks extensions
Item Protocol capability References Status Support
Are the following Interworking
with External Networks
capabilities supported?
IW1 Interworking capabilities and 9.4.2.92, CFIW:M Yes No N/A
Information 11.25.2
IW1.1 Interworking element 9.4.2.92 IW1:M Yes No N/A
IW1.2 Access network type 9.4.2.92 IW1:M Yes No N/A
IW1.3 Venue type 9.4.2.92 IW1:M Yes No N/A
IW1.4 HESSID 9.4.2.92 IW1:M Yes No N/A
IW2 Generic Advertisement Service 11.25.3 CFIW:M Yes No N/A
IW2.1 Advertisement Protocol element 9.4.2.93 IW2:M Yes No N/A
*IW2.2 GAS Protocol 11.25.3.2 IW2:M Yes No N/A
*IW2.2.1 GAS frames 9.6.8 IW2:M Yes No N/A
IW2.2.2 Access network query protocol 9.4.5 IW2.2:M Yes No N/A
IW2.2.3 Query List 9.4.5.2 IW2.2.1:M Yes No N/A
IW2.2.4 Capability List 9.4.5.3 IW2.2.1:M Yes No N/A
IW2.2.5 Venue Name 9.4.5.4 IW2.2.1:O Yes No N/A
IW2.2.6 Emergency Call Number 9.4.5.5 IW2.2.1:O Yes No N/A
IW2.2.7 Network Authentication Type 9.4.5.6 IW2.2.1:O Yes No N/A
IW2.2.8 Roaming Consortium 9.4.5.7 IW2.2.1:O Yes No N/A
IW2.2.9 IP Address Type Availability 9.4.5.9 IW2.2.1:O Yes No N/A
IW2.2.10 NAI Realm 9.4.5.10 IW2.2.1:O Yes No N/A
IW2.2.11 3GPP Cellular Network 9.4.5.11 IW2.2.1:O Yes No N/A
IW2.2.12 AP Geospatial Location 9.4.5.12 IW2.2.1:O Yes No N/A
IW2.2.13 AP Civic Location 9.4.5.13 IW2.2.1:O Yes No N/A
IW2.2.14 AP Location Public Identifier URI/ 9.4.5.14 IW2.2.1:O Yes No N/A
FQDN
IW2.2.15 Domain Name 9.4.5.15 IW2.2.1:O Yes No N/A
IW2.2.16 Emergency Alert URI 9.4.5.16 IW2.2.1:O Yes No N/A
2747
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.20 Interworking (IW) with external networks extensions (continued)
Item Protocol capability References Status Support
IW2.2.17 Emergency NAI 9.4.5.17 IW2.2.1:O Yes No N/A
IW2.2.18 Vendor Specific 9.4.5.8 IW2.2.1:O Yes No N/A
IW2.2.19 MIH IS 9.4.2.93, IW2:O Yes No N/A
11.25.4
IW2.2.20 MIH Event and Command Services 9.4.2.93, IW2.2:O Yes No N/A
Discovery 11.25.4
IW2.2.21 Emergency Alert System (EAS) 9.4.2.93, IW2.2:O Yes No N/A
9.4.2.97
IW2.2.22 Advertisement Protocol ID, Vendor 9.4.2.93 IW2.2:O Yes No N/A
Specific
IW2.2.23 TDLS Capability 9.4.5.18 IW2.21:O Yes No N/A
IW2.2.24 Neighbor Report 9.4.5.19 IW2.21:O Yes No N/A
IW2.3 GAS Initial Request frame 9.6.8.12 IW2:M Yes No N/A
IW2.4 GAS Initial Response frame 9.6.8.13 IW2:M Yes No N/A
IW2.5 GAS Comeback Request frame 9.6.8.14 IW2:M Yes No N/A
IW2.6 GAS Comeback Response frame 9.6.8.15 IW2:M Yes No N/A
IW3 QoS Mapping from External 10.22.4.2, CFIW:O Yes No N/A
Networks 10.22.4.3,
11.25.9
IW3.1 QoS Map element 9.4.2.95 IW3:M Yes No N/A
IW3.2 Transport of QoS Map 11.25.9 IW3:M Yes No N/A
IW3.3 QoS Map Configure 9.6.3.6 IW3:M Yes No N/A
IW4 MIH Support 6.4, 11.25.4 CFIW:O Yes No N/A
IW4.1 MAC state generic convergence 6.4 IW4:M Yes No N/A
function support
IW4.2 Informational events 6.4.5 IW4:M Yes No N/A
IW4.3 ESS status reporting 6.4.7 IW4:M Yes No N/A
IW4.4 Network configuration 6.4.8 IW4:M Yes No N/A
IW4.5 Network events 6.4.9 IW4:M Yes No N/A
IW4.6 Network command interface 6.4.10 IW4:M Yes No N/A
IW4.7 Mobility management 6.4.11 IW4:M Yes No N/A
IW4.8 Network configuration 6.4.8 IW4:M Yes No N/A
IW5 Extended channel switching 9.4.2.58, 11.1.4 (CF3G6 AND Yes No N/A
enabled DSE9):M
IW6 Expedited Bandwidth Request 9.4.2.94 CFIW:O Yes No N/A
IW7 SSPN Interface 11.25.5 CFIW:O Yes No N/A
2748
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.21 Mesh protocol capabilities
B.4.21.1 General mesh support
Item Protocol capability Reference Status Support
*MP1 Support of mesh capability 4.3.20, 14.1 CFMBSS: Yes No N/A
M
MP1.1 Mesh BSS scanning 14.2.2, 14.2.6 MP1:M Yes No N/A
MP1.2 Candidate peer mesh STA 14.2.7 MP1:M Yes No N/A
determination
MP1.3 Active mesh profile 14.2.3, 14.2.4 MP1:M Yes No N/A
determination
MP1.4 Establishing a mesh BSS 14.2.8 MP1:M Yes No N/A
MP1.5 Becoming a member of a mesh 14.2.8 MP1:M Yes No N/A
BSS
MP1.6 Announcement of mesh 14.2.3, 14.2.5 MP1:M Yes No N/A
profile and supplemental
information for the mesh
discovery
*MP2 Mesh peering management 14.3 CFMBSS: Yes No N/A
(MPM) framework M
*MP2.1 Mesh peering management 14.3 MP2:M Yes No N/A
(MPM) protocol
MP2.1.1 Processing of Mesh Peering 14.3.6 MP2.1:M Yes No N/A
Open frame
MP2.1.2 Processing of Mesh Peering 14.3.7 MP2.1:M Yes No N/A
Confirm frame
MP2.1.3 Processing of Mesh Peering 14.3.8 MP2.1:M Yes No N/A
Close frame
MP2.1.4 MPM finite state machine 14.4 MP2.1:M Yes No N/A
*MP2.2 Authenticated mesh peering 14.5 MP2:O Yes No N/A
exchange (AMPE)
MP2.2.1 Mesh authentication using SAE 12.4, 14.3.3 MP2.2:M Yes No N/A
MP2.2.2 Mesh authentication using IEEE 4.10, 14.3.3 MP2.2:O Yes No N/A
Std 802.1X
MP2.2.3 Protected mesh peering 14.5.3, 14.5.3 MP2.2:M Yes No N/A
Management frame processing
MP2.2.4 Mesh pairwise master key 12.6.12 MP2.2:M Yes No N/A
security association (PMKSA)
caching
MP2.2.5 AMPE finite state machine 14.5.6 MP2.2:M Yes No N/A
MP2.2.6 MGTK distribution 14.5.4 MP2.2:M Yes No N/A
MP2.2.7 MGTK update 14.6 MP2.2:O Yes No N/A
MP3 Mesh STA beaconing 14.13.3 CFMBSS: Yes No N/A
M
*MP4 Mesh STA synchronization 14.13.2 CFMBSS: Yes No N/A
M
*MP4.1 Neighbor offset synchronization 14.13.2 MP4:M Yes No N/A
method
MP4.1.1 Calculation of TSF offset 14.13.2.2.2 MP4.1:M Yes No N/A
2749
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.21.1 General mesh support (continued)
Item Protocol capability Reference Status Support
MP4.1.2 Clock drift adjustment 14.13.2.2.3 MP4.1:M Yes No N/A
*MP4.2 Mesh beacon collision 14.13.4 MP4:O Yes No N/A
avoidance (MBCA)
MP4.2.1 Beacon timing advertisement 14.13.4.2 MP4.2:M Yes No N/A
MP4.2.2 TBTT selection 14.13.4.3 MP4.2:M Yes No N/A
MP4.2.3 TBTT adjustment 14.13.4.4 MP4.2:M Yes No N/A
MP4.2.4 Frame transmission across 14.13.4.5 MP4.2:O Yes No N/A
reported TBTT
MP4.2.5 Delayed beacon transmission 14.13.4.6 MP4.2:O Yes No N/A
*MP5 MCCA 10.23.3 CFMBSS: Yes No N/A
O
MP5.1 MCCAOP Advertisement 10.23.3.7 MP5:M Yes No N/A
MP5.2 Neighbor MCCAOP 10.23.3.4, 10.23.3.5 MP5:M Yes No N/A
Recognition
MP5.3 MCCAOP Setup 10.23.3.6 MP5:M Yes No N/A
MP5.4 Access during MCCAOPs 10.23.3.9 MP5:M Yes No N/A
MP5.5 MCCAOP teardown 10.23.3.8 MP5:M Yes No N/A
*MP6 Intra mesh congestion control 14.12 CFMBSS: Yes No N/A
O
MP6.1 Local congestion monitoring and 14.12 MP6:M Yes No N/A
detection
MP6.2 Congestion control signaling 14.12 MP6:M Yes No N/A
MP6.3 Local rate control 14.12 MP6:M Yes No N/A
*MP7 MBSS channel switching 11.9.8, 11.10.3 CFMBSS: Yes No N/A
procedure M
MP7.1 Transmission of channel switch 11.9.8, 11.10.3 MP7:M Yes No N/A
advertisement
MP7.2 Propagation of channel switch 11.9.8, 11.10.3 MP7:M Yes No N/A
advertisement
*MP8 Mesh power save operation 14.14 CFMBSS: Yes No N/A
(operation in light or deep sleep O
mode)
MP8.1 Link-specific mesh power 14.14.2.2, 14.14.8 MP8:M Yes No N/A
management mode setting
MP8.2 Nonpeer mesh power 14.14.2.3 MP8:M Yes No N/A
management mode setting
MP8.3 Light sleep mode operation 14.14.8.4 MP8:M Yes No N/A
MP8.4 Deep sleep mode operation 14.14.8.5 MP8:M Yes No N/A
MP8.5 STA power state transitions 14.14.3 MP8:M Yes No N/A
MP8.6 Mesh awake window 14.14.6 MP8:M Yes No N/A
operation
*MP9 Mesh power save support 14.14 CFMBSS: Yes No N/A
M
MP9.1 TIM transmission 14.14.4 MP9:M Yes No N/A
2750
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.21.1 General mesh support (continued)
Item Protocol capability Reference Status Support
MP9.2 Link-specific mesh power 14.14.2 MP9:M Yes No N/A
management modes
determination
MP9.3 Group addressed frame 14.14.7 MP9:M Yes No N/A
transmission
MP9.4 Frame transmission to a mesh 14.14.7, 14.14.9 MP9:M Yes No N/A
STA in light sleep mode
MP9.5 Frame transmission to a mesh 14.14.7, 14.14.9 MP9:M Yes No N/A
STA in deep sleep mode
MP10 Airtime link metric 14.9 CFMBSS: Yes No N/A
computation M
*MP11 Link metric reporting 14.8.3 CFMBSS: Yes No N/A
M
MP11.1 Autonomous link metric 14.8.3 MP11:O Yes No N/A
reporting
MP11.2 Link metric reporting upon 14.8.3 MP11:M Yes No N/A
request
*MP12 Proxy operation 14.11.4 CFMBSS: Yes No N/A
O
MP12.1 Data forwarding at proxy mesh 14.11.3 MP12:M Yes No N/A
gate
MP12.2 Maintenance of proxy 14.11.4.2 CFMBSS: Yes No N/A
information M
MP12.3 Proxy update using Proxy Update 14.11.4 CFMBSS: Yes No N/A
and Proxy Update Confirmation M
frames
MP12.4 Proxy update using HWMP Mesh 14.10.9, 14.10.10, HWM1:M Yes No N/A
Path Selection frames 14.10.11
*MP13 Gate announcement 14.11.2 CFMBSS: Yes No N/A
O
MP13.1 GANN transmission 14.11.2 MP13:O Yes No N/A
MP13.2 GANN reception and 14.11.2 CFMBSS: Yes No N/A
propagation M
*MP14 Mesh Control field handling 9.2.4.7.3 CFMBSS: Yes No N/A
M
MP14.1 Address Extension 9.2.4.7.3, 9.3.5 MP14:M Yes No N/A
recognition
MP14.2 Mesh TTL handling 9.2.4.7.3, 10.35.3, MP14:M Yes No N/A
10.35.4, 10.35.5
MP14.3 Mesh Sequence Number 9.2.4.7.3, 10.35.3, MP14:M Yes No N/A
handling 10.35.4, 10.35.5,
10.35.6
*MP15 MSDU/MMPDU forwarding 10.35 CFMBSS: Yes No N/A
O
MP15.1 Individually addressed MSDU 10.35.3 MP15:M Yes No N/A
forwarding
MP15.2 Group addressed MSDU 10.35.4 MP15:M Yes No N/A
forwarding
2751
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.21.1 General mesh support (continued)
Item Protocol capability Reference Status Support
MP15.3 MMPDU forwarding 10.35.5 MP15:M Yes No N/A
MP15.4 Detection of duplicate MSDUs/ 10.35.6 CFMBSS: Yes No N/A
MMPDUs M
MP15.5 Treatment of unknown 10.35.8 CFMBSS: Yes No N/A
destination M
B.4.21.2 HWMP path selection protocol capabilities
Item Protocol capability Reference Status Support
*HWM1 Hybrid wireless mesh 14.10 CFMBSS:M Yes No N/A
protocol (HWMP)
*HWM1.1 On-demand path selection 14.10.3 HWM1:M Yes No N/A
HWM1.1.1 PREQ processing for on-demand 14.10.9 HWM1.1:M Yes No N/A
path selection
HWM1.1.2 PREP processing for on-demand 14.10.10 HWM1.1:M Yes No N/A
path selection
HWM1.1.3 PERR processing for on-demand 14.10.11 HWM1.1:M Yes No N/A
path selection
*HWM1.2 Proactive tree building 14.10.4 HWM1:M Yes No N/A
HWM1.2.1 PREQ processing for 14.10.9 HWM1.2:M Yes No N/A
proactive tree building
HWM1.2.2 PREP processing for 14.10.10 HWM1.2:M Yes No N/A
proactive tree building
HWM1.2.3 PERR processing for 14.10.11 HWM1.2:M Yes No N/A
proactive tree building
HWM1.2.4 RANN processing 14.10.12 HWM1.2:M Yes No N/A
HWM2 Maintenance of forwarding 10.35.2, 14.10.8.4 MP15:M Yes No N/A
information
B.4.22 QMF extensions
Item Protocol capability References Status Support
QMF1 Extended Capabilities element 9.4.2.27 CFQMF:M Yes No N/A
QMF2 Channel access procedures for 10.2.4.2 CFQMF:M Yes No N/A
QMFs
QMF3 Duplicate detection and recovery 10.3.2.11 CFQMF:M Yes No N/A
for QMFs
QMF4 QMF policy Configuration 11.26.2 CFQMF:M Yes No N/A
QMF5 Interpreting QMF priority 11.26.3 CFQMF:M Yes No N/A
QMF6 CCMP cryptographic encapsulation 12.5.3.3 (CFQMF AND Yes No N/A
for QMFs PC34.1.10):M
2752
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.23 RobustAVT extensions
Item Protocol capability References Status Support
AVT1 Extended Capabilities element 9.4.2.27 CFAVT:M Yes No N/A
AVT2 Groupcast with Retries (GCR) 11.24.16.3.2, (CFHT AND Yes No N/A
11.24.16.3.3, CFAVT AND
11.24.16.3.4, WNM19):M
11.24.16.3.5, (CFTVHT
11.24.16.3.6 AND CFAVT
AND
WNM19):M
(CFAP AND Yes No N/A
CFAVT AND
WNM19 AND
HTM4.4):M
AVT2.1 Advanced GCR 9.4.2.27, (CFAVT AND Yes No N/A
10.24.10, QB5):O
11.24.16.3.7,
11.24.16.3.8
AVT3 Alternate EDCA transmit queues 10.2.4.2 CFAVT AND Yes No N/A
CFHT:O
AVT4 Stream Classification Service 11.27.2 CFAVT:O Yes No N/A
(SCS)
AVT4.1 SCS Request frame 9.6.19.2 AVT4:M Yes No N/A
AVT4.2 SCS Response frame 9.6.19.3 AVT4:M Yes No N/A
AVT4.3 Drop eligibility indicator (DEI) 11.27.2 (CFHT AND Yes No N/A
AVT4):M
(CFTVHT
AND AVT4):M
ATV5 Overlapping Basic Service Set 9.4.2.27, 11.28 (CFAP AND Yes No N/A
(OBSS) Management (QP2 OR QD6)
AND
CFAVT):M
ATV5.1 AP PeerKey 12.11 AVT5:O Yes No N/A
ATV5.2 QLoad Report 11.28.2 AVT5:M Yes No N/A
AVT5.2.1 QLoad Report element 9.4.2.123 AVT5.2:M Yes No N/A
AVT5.2.2 QLoad Request frame 9.6.8.20 AVT5.2:M Yes No N/A
AVT5.2.3 QLoad Report frame 9.6.8.21 AVT5.2:M Yes No N/A
AVT5.2.4 Protected QLoad Report 9.6.8.21 (AVT5.2 AND Yes No N/A
AVT5.1):O
AVT5.3 HCCA TXOP Update Count 9.4.2.124 (AVT5 AND Yes No N/A
element QP2):O
AVT5.3.1 HCCA TXOP Negotiation 11.28.3 AVT5.3:O Yes No N/A
AVT5.3.2 Protected HCCA TXOP 11.28.3 (AVT5.3 AND Yes No N/A
Negotiation ATV5.1):O
2753
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.23 RobustAVT extensions (continued)
Item Protocol capability References Status Support
AVT6 GCR for Mesh 9.4.2.27, (WNM19 AND Yes No N/A
10.24.10, HTM4.4 AND
11.24.16.3.6, CFHT AND
11.24.16.3.7 CFAVT AND
CFMBSS):O
(WNM19 AND
HTM4.4 AND
CFTVHT AND
CFAVT and
CFMBSS):O
B.4.24 DMG features
B.4.24.1 DMG MAC features
Item Protocol capability References Status Support
Are the following MAC protocol features
supported?
DMG-M1 DMG capabilities signaling
DMG-M1.1 DMG Capabilities element 9.4.2.128 CFDMG:M Yes No
N/A
DMG-M1.2 Signaling of STA capabilities in Probe 9.3.3.6, (CFDMG AND Yes No
Request, (Re)Association Request frames 9.3.3.8, (CFSTAofAP N/A
9.3.3.10, OR CFIBSS
9.4.2.128 OR
CFPBSSnotPC
P)):M
DMG-M1.3 Signaling of STA and BSS capabilities in 9.3.3.7, (CFDMG AND Yes No
DMG Beacon, Probe Response, 9.3.3.9, (CFAP OR N/A
(Re)Association Response frames 9.3.3.11, CFPCP)):M
9.3.4.2,
9.4.2.128
DMG-M2 Signaling of DMG operation 9.4.2.129 (CFDMG AND Yes No
(CFAP OR N/A
CFPCP)):M
DMG-M3 MSDU aggregation
DMG-M3.1 Reception of Basic A-MSDUs 9.2.4.5, CFDMG:M Yes No
9.3.2.2.2 N/A
DMG-M3.2 Basic A-MSDU format 9.3.2.2.2 CFDMG:M Yes No
N/A
DMG-M3.3 Basic A-MSDU content 9.3.2.2.2 CFDMG:M Yes No
N/A
DMG-M3.4 Transmission of Basic A-MSDUs 9.2.4.5, CFDMG:O Yes No
9.3.2.2.2 N/A
*DMG-M3.5 Reception of Short A-MSDU 9.2.4.5, CFDMG:O Yes No
9.3.2.2.2 N/A
2754
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.24.1 DMG MAC features (continued)
Item Protocol capability References Status Support
DMG-M3.6 Short A-MSDU format 9.3.2.2.3 (DMG-M3.5 Yes No
OR DMG- N/A
M3.8):M
DMG-M3.7 Short A-MSDU content 9.3.2.2.3 (DMG-M3.5 Yes No
OR DMG- N/A
M3.8):M
*DMG-M3.8 Transmission of Short A-MSDU 9.2.4.5, CFDMG:O Yes No
9.3.2.2.3 N/A
DMG-M3.9 Negotiation of Short A-MSDU usage 9.4.2.30 CFDMG:M Yes No
N/A
DMG-M4 MPDU aggregation
DMG-M4.1 Reception of A-MPDU 9.4.2.128.2, CFDMG:M Yes No
10.13.2, 11.3 N/A
DMG-M4.2 A-MPDU format 9.7.1 CFDMG:M Yes No
N/A
DMG-M4.3 A-MPDU content 9.7.3 CFDMG:M Yes No
N/A
DMG-M4.4 Transmission of A-MPDU 9.4.2.128.2, CFDMG:O Yes No
10.13.2 N/A
DMG-M5 A-PPDU aggregation 10.13-10.15
*DMG-M5.1 Reception of A-PPDU 9.4.2.128.2 CFDMG:O Yes No
N/A
DMG-M5.2 A-PPDU format 20.5.2, (DMG-M5.1 Yes No
20.6.2 OR DMG- N/A
M5.3):M
*DMG-M5.3 Transmission of A-PPDU 9.4.2.128.2 CFDMG:O Yes No
N/A
*DMG-M6 Reverse direction aggregation exchanges 9.4.2.128.2, CFDMG:O Yes No
10.28 N/A
DMG-M6.1 Constraints regarding responses 10.28.3 DMG-M6:M Yes No
N/A
DMG-M7 DMG channel access
DMG-M7.1 ATI transmission
DMG- Transmission of Request 10.36.3 CFDMG AND Yes No
M7.1.1 (CFAP OR N/A
CFPCP):O
DMG- Reception of Request 10.36.3 CFDMG AND Yes No
M7.1.2 (CFSTAofAP N/A
OR
CFPBSSnotPC
P):M
2755
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.24.1 DMG MAC features (continued)
Item Protocol capability References Status Support
DMG- Transmission of Response 10.36.3 CFDMG AND Yes No
M7.1.3 (CFSTAofAP N/A
OR
CFPBSSnotPC
P):M
DMG- Reception of Response 10.36.3 CFDMG AND Yes No
M7.1.4 (CFAP OR N/A
CFPCP):M
DMG-M7.2 DTI transmission 10.36.4 CFDMG:M Yes No
N/A
DMG-M7.3 Time allocation
*DMG- Service period (SP) allocation 9.4.2.132, CFDMG AND Yes No
M7.3.1 9.4.2.134, (CFAP OR N/A
9.4.2.137, CFPCP):O
10.36.6.2
*DMG- CBAP allocation 9.4.2.132, CFDMG AND Yes No
M7.3.2 9.4.2.137, (CFAP OR N/A
10.36.6.2 CFPCP):O
DMG- Interpretation of allocation 9.4.2.132, CFDMG AND Yes No
M7.3.3 9.4.2.137, (CFInfraSTA N/A
10.36.5, OR CFIBSS
10.36.6.2 OR CFPCP OR
CFPBSSnotPC
P):M
*DMG-M7.4 Contention based access period 10.36.5, CFDMG:M Yes No
10.36.6.2 N/A
DMG- Distributed coordination function (DCF)
M7.4.1
DMG- Network allocation vector (NAV) function 10.3.2.2, DMG-M7.4:M Yes No
M7.4.1.1 10.3.4, N/A
10.36.10
DMG- Interframe space usage and timing 10.3.2.4, DMG-M7.4:M Yes No
M7.4.1.2 10.3.4, N/A
10.3.7
DMG- Random Backoff function 10.3.3 DMG-M7.4:M Yes No
M7.4.1.3 N/A
DMG- DCF Access procedure 10.3, DMG-M7.4:M Yes No
M7.4.1.4 10.3.4.2, N/A
10.3.4.5
DMG- Random Backoff procedure 10.3, DMG-M7.4:M Yes No
M7.4.1.5 10.3.4.3 N/A
DMG- Recovery procedures and retransmit limits 10.3.4.4 DMG-M7.4:M Yes No
M7.4.1.6 N/A
DMG- Request to send (RTS)/DMG clear to send 10.3.2.5, DMG-M7.4:M Yes No
M7.4.1.7 (DMG CTS) procedure 10.3.2.7, N/A
10.3.2.8,
10.36.10
2756
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.24.1 DMG MAC features (continued)
Item Protocol capability References Status Support
DMG- Individually addressed MAC protocol data 10.3.5 DMG-M7.4:M Yes No
M7.4.1.8 unit (MPDU) transfer N/A
DMG- Group addressed MPDU transfer 10.3.6 DMG-M7.4:M Yes No
M7.4.1.9 N/A
DMG- MAC-level acknowledgment 10.3.2.3, DMG-M7.4:M Yes No
M7.4.1.10 10.3.2.9 N/A
DMG- Duplicate detection and recovery 10.3.2.11 DMG-M7.4:M Yes No
M7.4.1.11 N/A
DMG- Enhanced DCF (EDCA)
M7.4.2
*DMG- Support for one transmit queue with AC_BE 10.2.4.2, DMG-M7.4:M Yes No
M7.4.2.1 access category 10.22.2.1 N/A
DMG- Support for four transmit queues with a 10.2.4.2, DMG- Yes No
M7.4.2.2 separate channel access entity associated with 10.22.2.1 M7.4.2.1:O N/A
each
DMG- AC_BE access category and differentiated 10.22.2.2, DMG- Yes No
M7.4.2.3 channel access 10.22.2.4, M7.4.2.1:M N/A
10.22.2.11
DMG-M7.5 Pseudo-static allocation
DMG- Scheduling of pseudo-static allocation 9.4.2.113, DMG- Yes No
M7.5.1 9.4.2.141, M7.3.1:O N/A
10.36.6.2,
10.36.6.5,
11.4.13.2
DMG- Operation within pseudo-static allocation 9.4.2.139, CFDMG AND Yes No
M7.5.2 9.4.2.141, (CFAP OR N/A
10.36.6.2, CFSTAofAP
10.36.6.4 OR CFPCP OR
CFPBSSnotPC
P):M
DMG-M7.6 Guard time 10.36.6.5 DMG- Yes No
M7.3.1:M N/A
DMG-M7.7 DMG protected period
*DMG- Establishment of DMG protected period with 10.36.6.6 DMG- Yes No
M7.7.1 RTS at source DMG STA M7.3.1:O N/A
*DMG- Establishment of DMG protected period using 10.36.6.6 DMG- Yes No
M7.7.2 a DMG CTS frame at destination DMG STA M7.3.1:M N/A
DMG- Transmission of DMG DTS frame at 10.36.6.6 DMG- Yes No
M7.7.3 destination DMG STA M7.7.2:O N/A
DMG- Reception of DMG DTS frame at source DMG 10.36.6.6 DMG- Yes No
M7.7.4 STA M7.7.1:M N/A
DMG-M7.8 Service period recovery 10.36.6.7 DMG-M7.3.1 Yes No
AND (CFAP N/A
OR CFPCP):O
2757
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.24.1 DMG MAC features (continued)
Item Protocol capability References Status Support
DMG-M7.9 Dynamic allocation of service period 10.36.7
DMG- Polling period (PP) 9.4.2.143,
M7.9.1 10.36.7.2
DMG- Transmission of Poll 9.3.1.11 CFDMG AND Yes No
M7.9.1.1 (CFAP OR N/A
CFPCP):O
DMG- Reception of Poll 9.3.1.11 CFDMG AND Yes No
M7.9.1.2 (CFSTAofAP N/A
OR
CFPBSSnotPC
P):M
DMG- Transmission of SPR 9.3.1.12 CFDMG AND Yes No
M7.9.1.3 (CFSTAofAP N/A
OR
CFPBSSnotPC
P):M
DMG- Reception of SPR 9.3.1.12 CFDMG AND Yes No
M7.9.1.4 (CFAP OR N/A
CFPCP):M
DMG- Grant period (GP) 10.36.7.3
M7.9.2
DMG- Transmission of Grant 9.3.1.13 CFDMG AND Yes No
M7.9.2.1 (CFAP OR N/A
CFPCP):O
DMG- Reception of Grant 9.3.1.13 CFDMG AND Yes No
M7.9.2.2 (CFSTAofAP N/A
OR
CFPBSSnotPC
P):M
DMG-M7.10 Dynamic truncation of service period 10.36.8
DMG- Transmission of CF-End 9.3.1.16 CFDMG:O Yes No
M7.10.1 N/A
DMG- Reception of CF-End 9.3.1.16 CFDMG:M Yes No
M7.10.2 N/A
DMG-M7.11 Dynamic extension of service period 10.36.9
DMG- Transmission of SPR 9.3.1.12 CFDMG AND Yes No
M7.11.1 (CFSTAofAP N/A
OR
CFPBSSnotPC
P):O
DMG- Reception of SPR 9.3.1.12 CFDMG AND Yes No
M7.11.2 (CFAP OR N/A
CFPCP):M
DMG- Transmission of Grant 9.3.1.13 CFDMG AND Yes No
M7.11.3 (CFAP OR N/A
CFPCP):O
2758
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.24.1 DMG MAC features (continued)
Item Protocol capability References Status Support
DMG- Reception of Grant 9.3.1.13 CFDMG AND Yes No
M7.11.4 (CFSTAofAP N/A
OR
CFPBSSnotPC
P):M
DMG-M7.12 Isochronous and Asynchronous TS support
DMG- Isochronous operation 9.4.2.132, DMG-M7.3.1 Yes No
M7.12.1 9.4.2.134, AND N/A
9.4.2.137, (CFInfraSTA
11.4.13.2 OR CFPCP OR
CFPBSSnotPC
P):M
DMG- Asynchronous operation 9.3.1.12, DMG-M7.3.1 Yes No
M7.12.2 9.4.2.132, AND N/A
9.4.2.134, (CFInfraSTA
9.4.2.137, OR CFPCP OR
11.4.13.2 CFPBSSnotPC
P):M
DMG-M8 AP or PCP clustering
DMG-M8.1 S-AP in centralized AP or PCP cluster 10.37 CFDMG:O Yes No
N/A
DMG-M8.2 Except when centralized AP or PCP clusters 10.37.2.2 CFDMG AND Yes No
on all channels supported by the AP or PCP in (CFAP OR N/A
the operating class, join a centralized AP or CFPCP) AND
PCP cluster or cease activity on channel NOT DMG-
M8.1:M
DMG-M8.3 Other AP or PCP clustering 10.37 CFDMG:O Yes No
N/A
DMG-M9 DMG beamforming
DMG-M9.1 Sector-level sweep 10.38.2, CFDMG:M Yes No
10.38.6.2 N/A
DMG-M9.2 Beamforming in BTI 10.38.4 CFDMG:M Yes No
N/A
DMG-M9.3 Beamforming in A-BFT 10.38.5 CFDMG:M Yes No
N/A
DMG-M9.4 BRP setup 10.38.3.2 CFDMG:M Yes No
N/A
DMG-M9.5 MID 10.38.6.3.3 CFDMG:O Yes No
N/A
DMG-M9.6 BC 10.38.6.3.4 CFDMG:O Yes No
N/A
DMG-M9.7 BRP
*DMG- BRP with BS-FBCK 10.38.3, CFDMG:M Yes No
M9.7.1 10.38.6.4 N/A
DMG- BRP with channel measurement 10.38.3, DMG- Yes No
M9.7.2 10.38.6.4 M9.7.1:O N/A
2759
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.24.1 DMG MAC features (continued)
Item Protocol capability References Status Support
DMG-M9.8 Beam tracking 10.38.7 CFDMG:M Yes No
N/A
DMG-M10 DMG block ack with flow control 9.4.2.128.2, CFDMG:O Yes No
10.39 N/A
DMG-M11 DMG link adaptation 10.39 CFDMG:O Yes No
N/A
DMG-M12 DMG dynamic tone pairing (DTP) 9.4.2.128.2, CFDMG:O Yes No
10.40 N/A
DMG-M13 Timing synchronization function (TSF) in a
PBSS
DMG-M13.1 Timing in a PBSS 11.1.2.1, CFPCP AND Yes No
11.1.5 CFDMG:M N/A
DMG-M13.2 PBSS initialization 11.1.4 CFPCP AND Yes No
CFDMG:M N/A
DMG-M14 Power management
DMG-M14.1 STA power management without wakeup 11.2.7.2.2, CFDMG:M Yes No
schedule 11.2.7.2.4 N/A
DMG-M14.2 STA power management with wakeup 9.4.2.138, CFDMG:O Yes No
schedule 11.2.7.2.3, N/A
11.2.7.2.4
DMG-M14.3 PCP power management 9.4.2.138, CFDMG:O Yes No
11.2.7.2.3 N/A
DMG-M15 Authentication and association
DMG-M15.1 Association state 11.3.1 M Yes No
DMG-M15.2 STA association procedure 11.3.5.2 CFSTAofAP Yes No
AND N/A
CFDMG:M
CFPBSSnotPC
P AND
CFDMG:O
DMG-M15.3 AP or PCP association procedure 11.3.5.3 CFAP AND Yes No
CFDMG:M N/A
CFPCP AND
CFDMG:O
DMG-M15.4 Communicating PBSS information 11.3.7 (CFPCP OR Yes No
CFPBSSnotPC N/A
P) AND
CFDMG:M
DMG-M16 DMG beamformed link and BSS maintenance
DMG-M16.1 Beamformed link maintenance
*DMG- Negotiation of 9.5.6 CFDMG:M Yes No
M16.1.1 dot11BeamLinkMaintenanceTime timer N/A
DMG- Beamformed link maintenance procedure 11.29.1 DMG- Yes No
M16.1.2 M16.1.1:O N/A
2760
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.24.1 DMG MAC features (continued)
Item Protocol capability References Status Support
DMG-M16.2 PCP handover 11.29.2 CFDMG:O Yes No
N/A
DMG-M17 DMG BSS Peer and Service Discovery 11.30 CFDMG:M Yes No
N/A
DMG-M18 Changing DMG BSS parameters 11.31 CFDMG:O Yes No
N/A
*DMG-M19 Spatial sharing and interference mitigation 11.32 CFDMG:O Yes No
N/A
DMG-M20 DMG Coexistence with other DMG systems 11.35 CFDMG:O Yes No
N/A
DMG-M21 Traffic specification (TSPEC and DMG 9.6.3 CFDMG:M Yes No
TSPEC) and associated frame formats N/A
DMG-M22 DMG frame formats
DMG-M22.1 DMG Action field 9.6.20.1 CFDMG:M Yes No
N/A
DMG-M22.2 Announce frame 9.6.22.2 CFDMG:M Yes No
N/A
DMG-M22.3 Power Save Configuration 9.6.20.2, CFDMG:M Yes No
9.6.20.3 N/A
DMG-M22.4 Information Request/Response 9.6.20.4, CFDMG:M Yes No
9.6.20.5 N/A
DMG-M22.5 BRP 9.6.22.3 CFDMG:M Yes No
N/A
DMG-M22.6 Handover 9.6.20.6, DMG- Yes No
9.6.20.7 M16.2:M N/A
DMG-M22.7 DTP 9.6.20.8, DMG-M12:M Yes No
9.6.20.9 N/A
DMG-M22.8 DMG relay 9.6.20.10– DMG-M23:M Yes No
9.6.20.24 N/A
DMG-M23 DMG relay 10.40, 11.36 CFDMG:O Yes No
N/A
B.4.24.2 DMG PHY features
Item Protocol capability References Status Support
Are the following PHY protocol features
supported?
DMG-P1 PHY operating modes
DMG-P1.1 Operation according to Clause 20 20 CFDMG:M Yes No
N/A
DMG-P2 PHY frame format
2761
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.24.2 DMG PHY features (continued)
Item Protocol capability References Status Support
*DMG-P2.1 DMG control mode format 20.4 CFDMG:M Yes No
N/A
*DMG-P2.2 DMG SC mode format 20.6 CFDMG:M Yes No
N/A
*DMG-P2.3 DMG OFDM mode format 20.5 CFDMG:O Yes No
N/A
*DMG-P2.4 DMG low-power SC mode format 20.7 CFDMG:O Yes No
N/A
DMG-P2.5 Modulation and coding schemes (MCS)
DMG-P2.5.1 MCS 0 of DMG control mode DMG-P2.1:M Yes No
N/A
DMG-P2.5.2 MCS 1-12 of DMG SC mode
DMG- MCS 1-4 DMG-P2.2:M Yes No
P2.5.2.1 N/A
DMG- MCS 5-12 DMG-P2.2:O Yes No
P2.5.2.2 N/A
DMG-P2.5.3 MCS 13-24 of DMG OFDM mode
DMG- MCS 13-17 DMG-P2.3:M Yes No
P2.5.3.1 N/A
DMG- MCS 18-24 DMG-P2.3:O Yes No
P2.5.3.2 N/A
DMG-P2.5.4 MCS 25-31 of DMG low-power SC mode DMG-P2.4:M Yes No
N/A
DMG-P2.6 Common preamble format 20.3.6 CFDMG:M Yes No
N/A
DMG-P2.7 Use of LDPC codes 20.3.8 CFDMG:M Yes No
N/A
B.4.25 Very high throughput (VHT) features
B.4.25.1 VHT MAC features
Item Protocol capability References Status Support
Are the following MAC protocol
features supported?
VHTM1 VHT capabilities signaling
VHTM1.1 VHT Capabilities element 9.4.2.158.1 CFVHT:M Yes No N/A
VHTM1.2 Signaling of STA capabilities in 9.3.3.6, 9.3.3.8, (CFVHT AND Yes No N/A
Probe Request, (Re)Association 9.3.3.10, CFIndepSTA):
Request frames 9.4.2.158.1 M
(CFVHT AND
CFMBSS):M
2762
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.25.1 VHT MAC features (continued)
Item Protocol capability References Status Support
VHTM1.3 Signaling of STA and BSS 9.3.3.3, 9.3.3.7, (CFVHT AND Yes No N/A
capabilities in Beacon, Probe 9.3.3.9, CFAP):M
Response, (Re)Association 9.3.3.11, (CFVHT AND
Response frames 9.4.2.158 CFMBSS):M
VHTM2 Signaling of VHT operation 9.4.2.159 (CFVHT AND Yes No N/A
CFAP):M
(CFVHT AND
CFMBSS):M
(CFVHT AND
CFIBSS):M
VHTM3 Link adaptation
VHTM3.1 Use of the VHT variant HT Control 9.2.4.6, CFVHT:O Yes No N/A
field for link adaptation in 9.3.3.15,
immediate response exchange. 10.31.3
VHTM4 Transmit beamforming
*VHTM4.1 SU Beamformer Capable 9.4.2.158 CFVHT:O Yes No N/A
*VHTM4.2 SU Beamformee Capable 9.4.2.158 CFVHT:O Yes No N/A
*VHTM4.3 MU Beamformer Capable 9.4.2.158 CFAP AND Yes No N/A
VHTM4.1:O
*VHTM4.4 MU Beamformee Capable 9.4.2.158 CFIndepSTA Yes No N/A
AND
VHTM4.2:O
VHTM4.5 Transmission of null data packet 10.34 VHTM4.1:M Yes No N/A
VHTM4.6 Reception of null data packet 10.34 VHTM4.2:M
VHTM5 VHT Sounding Protocol
VHTM5.1 VHT sounding protocol as SU 10.34.5 VHTM4.1:M Yes No N/A
beamformer
VHTM5.2 VHT sounding protocol as SU 10.34.5 VHTM4.2:M Yes No N/A
beamformee
VHTM5.3 VHT sounding protocol as MU 10.34.5 VHTM4.3:M Yes No N/A
beamformer
VHTM5.4 VHT sounding protocol as MU 10.34.5 VHTM4.4:M Yes No N/A
beamformee
VHTM6 TXOP Sharing
VHTM6.1 Sharing of EDCA TXOP 10.22.2.6 CFVHT:O Yes No N/A
VHTM6.2 Use of Primary and Secondary AC 10.22.2.6 VHTM6.1:M Yes No N/A
VHTM7 VHT TXOP power saving 11.2.3.19 CFVHT:O Yes No N/A
VHTM8 BSS Operation
VHTM8.1 Use of primary 20 MHz, secondary 10.3.2.6, CFVHT:M Yes No N/A
20 MHz, and secondary 40 MHz 10.3.2.7
channels
VHTM8.2 Use of secondary 80 MHz channels 11.40.1 (VHTP3.4 OR Yes No N/A
for 160 MHz and 80+80 MHz VHTP3.5):M
VHTM8.3 CCA on primary 20 MHz, secondary 11.40.5 CFVHT:M Yes No N/A
20 MHz, and secondary 40 MHz
channels
2763
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.25.1 VHT MAC features (continued)
Item Protocol capability References Status Support
VHTM8.4 CCA on secondary 80 MHz channels 11.40.5 (VHTP3.4 OR Yes No N/A
for 160 MHz and 80+80 MHz VHTP3.5):M
VHTM9 Group ID
VHTM9.1 Transmission of Group ID 9.6.23.3 VHTM4.3:M Yes No N/A
Management frame
VHTM9.2 Reception of Group ID Management 9.6.23.3 VHTM4.4:M
frame
VHTM10 Bandwidth signaling
VHTM10.1 Support for non-HT bandwidth 10.3.2.6 CFVHT:M Yes No N/A
signaling and static operation
VHTM10.2 Support for non-HT bandwidth 10.3.2.6 CFVHT:O Yes No N/A
signaling and dynamic operation
VHTM11 VHT single MPDU format 10.13.7 CFVHT:M Yes No N/A
VHTM12 Partial AID in VHT PPDU 10.20 CFVHT:M Yes No N/A
VHTM13 Extended BSS Load element 9.4.2.160 CFVHT:O Yes No N/A
VHTM13.1 Transmission of the Extended BSS 9.4.2.160 CFAP AND Yes No N/A
Load element CFVHT:O
VHTM14 Quiet Channel element
VHTM14.1 Transmission of Quiet Channel 9.3.3.3, (CFAP OR Yes No N/A
element by an AP or mesh station in 9.3.3.11, CFMBSS)
Beacon and Probe Response frames 9.4.2.165, AND CFSM
11.9.3 AND CFVHT
AND
VHTP3.4:O
VHTM14.2 Transmission of Quiet Channel 9.3.3.3, (CFIndepSTA Yes No N/A
element by an independent station or 9.3.3.11, OR CFMBSS)
mesh station in Beacon and Probe 9.4.2.165, AND CFSM
Response frames 11.9.3 AND CFVHT
AND
VHTP3.4:O
VHTM14.3 Reception of Quiet Channel element 9.3.3.3, (CFIndepSTA Yes No N/A
by an independent station or mesh 9.3.3.11, OR CFMBSS)
station in Beacon and Probe 9.4.2.165, AND CFSM
Response frames 11.9.3 AND
CFVHT:M
VHTM15 Space-time block coding (STBC)
VHTM15.1 STBC operation 9.4.2.158, VHTP9:M Yes No N/A
10.17
VHTM15.2 Transmission of at least 2x1 STBC 9.4.2.158.2 VHTP9:O.1 Yes No N/A
VHTM15.3 Reception of 1 STBC spatial stream 9.4.2.158.2 VHTP9:O.1 Yes No N/A
VHTM15.4 Reception of 2 STBC spatial streams 9.4.2.158.2 VHTM15.3:O Yes No N/A
VHTM15.5 Reception of 3 STBC spatial streams 9.4.2.158.2 VHTM15.4:O Yes No N/A
VHTM15.6 Reception of 4 STBC spatial streams 9.4.2.158.2 VHTM15.5:O Yes No N/A
VHTM16 Highest Supported Long GI Data
Rate
2764
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.25.1 VHT MAC features (continued)
Item Protocol capability References Status Support
VHTM16.1 Tx Highest Supported Long GI Data 9.4.2.158.3 CFVHT:M Yes No N/A
Rate
VHTM16.2 Rx Highest Supported Long GI Data 9.4.2.158.3 CFVHT:M Yes No N/A
Rate
NOTE—Required support for MCS might be limited by the declaration of Tx and Rx Highest Supported Long GI
Data Rates.
B.4.25.2 VHT PHY features
Item Protocol capability References Status Support
Are the following PHY protocol
features supported?
VHTP1 PHY operating modes
VHTP1.1 Operation according to Clause 17 21.1.4 CFVHT:M Yes No N/A
(Orthogonal frequency division
multiplexing (OFDM) PHY
specification) and/or Clause 19
(high throughput)
VHTP2 VHT format 21.3.2 CFVHT:M Yes No N/A
VHTP3 BSS bandwidth
VHTP3.1 20 MHz operation 11.40.1 CFVHT:M Yes No N/A
VHTP3.2 40 MHz operation 11.40.1 CFVHT:M Yes No N/A
VHTP3.3 80 MHz operation 11.40.1 CFVHT:M Yes No N/A
VHTP3.4 160 MHz operation 11.40.1 CFVHT:O Yes No N/A
VHTP3.5:M
VHTP3.5 80+80 MHz operation 11.40.1 CFVHT:O Yes No N/A
VHTP4 Bandwidth indication 17.3.5.5 CFVHT:M Yes No N/A
VHTP5 PHY timing parameters
VHTP5.1 Values in 20 MHz channel 21.3.6 CFVHT:M Yes No N/A
VHTP5.2 Values in 40 MHz channel 21.3.6 CFVHT:M Yes No N/A
VHTP5.3 Values in 80 MHz channel 21.3.6 CFVHT:M Yes No N/A
VHTP5.4 Values in 160 MHz channel 21.3.6 VHTP3.4:M Yes No N/A
VHTP5.5 Values in 80+80 MHz channel 21.3.6 VHTP3.5:M Yes No N/A
VHTP6 VHT preamble 21.3.8 CFVHT:M Yes No N/A
VHTP7 Use of LDPC Code 21.3.10.5.4 CFVHT:O Yes No N/A
VHTP8 Modulation and coding schemes
(MCS)
VHTP8.1 CBW20, CBW40, and CBW80 21.5
VHTP8.1.1 VHT-MCS with Index 0-7 and 21.5 CFVHT:M Yes No N/A
NSS = 1
VHTP8.1.2 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.1:O Yes No N/A
NSS = 1
2765
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.25.2 VHT PHY features (continued)
Item Protocol capability References Status Support
VHTP8.1.3 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.2:O Yes No N/A
NSS = 1
VHTP8.1.4 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 2
VHTP8.1.5 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.4:O Yes No N/A
NSS = 2
VHTP8.1.6 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.5:O Yes No N/A
NSS = 2
VHTP8.1.7 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 3
VHTP8.1.8 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.7:O Yes No N/A
NSS = 3
VHTP8.1.9 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.7:O Yes No N/A
NSS = 3
VHTP8.1.10 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 4
VHTP8.1.11 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.10:O Yes No N/A
NSS = 4
VHTP8.1.12 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.11:O Yes No N/A
NSS = 4
VHTP8.1.13 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 5
VHTP8.1.14 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.13:O Yes No N/A
NSS = 5
VHTP8.1.15 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.14:O Yes No N/A
NSS = 5
VHTP8.1.16 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 6
VHTP8.1.17 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.16:O Yes No N/A
NSS = 6
VHTP8.1.18 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.17:O Yes No N/A
NSS = 6
VHTP8.1.19 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 7
VHTP8.1.20 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.19:O Yes No N/A
NSS = 7
VHTP8.1.21 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.20:O Yes No N/A
NSS = 7
VHTP8.1.22 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 8
VHTP8.1.23 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.22:O Yes No N/A
NSS = 8
VHTP8.1.24 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.23:O Yes No N/A
NSS = 8
VHTP8.2 CBW160 21.5
VHTP8.2.1 VHT-MCS with Index 0-7 and 21.5 VHTP3.4:M Yes No N/A
NSS = 1
2766
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.25.2 VHT PHY features (continued)
Item Protocol capability References Status Support
VHTP8.2.2 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.1:O Yes No N/A
NSS = 1
VHTP8.2.3 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.2:O Yes No N/A
NSS = 1
VHTP8.2.4 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 2
VHTP8.2.5 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.4:O Yes No N/A
NSS = 2
VHTP8.2.6 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.5:O Yes No N/A
NSS = 2
VHTP8.2.7 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 3
VHTP8.2.8 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.7:O Yes No N/A
NSS = 3
VHTP8.2.9 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.8:O Yes No N/A
NSS = 3
VHTP8.2.10 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 4
VHTP8.2.11 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.10:O Yes No N/A
NSS = 4
VHTP8.2.12 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.11:O Yes No N/A
NSS = 4
VHTP8.2.13 VHT-MCS with Index 0-7 and 21.5 CFVHT9:O Yes No N/A
NSS = 5
VHTP8.2.14 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.13:O Yes No N/A
NSS = 5
VHTP8.2.15 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.14:O Yes No N/A
NSS = 5
VHTP8.2.16 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 6
VHTP8.2.17 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.16:O Yes No N/A
NSS = 6
VHTP8.2.18 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.17:O Yes No N/A
NSS = 6
VHTP8.2.19 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 7
VHTP8.2.20 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.19:O Yes No N/A
NSS = 7
VHTP8.2.21 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.20:O Yes No N/A
NSS = 7
VHTP8.2.22 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 8
VHTP8.2.23 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.22:O Yes No N/A
NSS = 8
VHTP8.2.24 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.23:O Yes No N/A
NSS = 8
VHTP8.3 CBW80+80 21.5
2767
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.25.2 VHT PHY features (continued)
Item Protocol capability References Status Support
VHTP8.3.1 VHT-MCS with Index 0-7 and 21.5 VHTP3.5:M Yes No N/A
NSS = 1
VHTP8.3.2 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.1:O Yes No N/A
NSS = 1
VHTP8.3.3 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.2:O Yes No N/A
NSS = 1
VHTP8.3.4 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 2
VHTP8.3.5 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.4:O Yes No N/A
NSS = 2
VHTP8.3.6 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.5:O Yes No N/A
NSS = 2
VHTP8.3.7 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 3
VHTP8.3.8 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.7:O Yes No N/A
NSS = 3
VHTP8.3.9 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.8:O Yes No N/A
NSS = 3
VHTP8.3.10 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 4
VHTP8.3.11 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.10:O Yes No N/A
NSS = 4
VHTP8.3.12 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.11:O Yes No N/A
NSS = 4
VHTP8.3.13 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 5
VHTP8.3.14 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.13:O Yes No N/A
NSS = 5
VHTP8.3.15 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.14:O Yes No N/A
NSS = 5
VHTP8.3.16 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 6
VHTP8.3.17 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.16:O Yes No N/A
NSS = 6
VHTP8.3.18 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.17:O Yes No N/A
NSS = 6
VHTP8.3.19 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 7
VHTP8.3.20 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.19:O Yes No N/A
NSS = 7
VHTP8.3.21 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.20:O Yes No N/A
NSS = 7
VHTP8.3.22 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A
NSS = 8
VHTP8.3.23 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.22:O Yes No N/A
NSS = 8
VHTP8.3.24 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.23:O Yes No N/A
NSS = 8
2768
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.25.2 VHT PHY features (continued)
Item Protocol capability References Status Support
VHTP8.4 Transmit and receive support for 21.5 CFVHT:O Yes No N/A
400 ns GI
VHTP9 Space-time block coding (STBC) 21.3.10.9.4 CFVHT:O Yes No N/A
VHTP10 Non-HT duplicate format 21.3.10.12 CFVHT:M Yes No N/A
B.4.26 TVWS functions
Item Protocol capability References Status Support
WS1 Fixed STA TVWS operation 11.44, Annex D, E.2.5 CFTVHT:O Yes No N/A
WS2 Master STA TVWS 11.44, 11.44.2, CFTVHT:O Yes No N/A
operation Annex D, E.2.5
*WS3 Client STA TVWS operation 11.44.3, Annex D, CFTVHT:O Yes No N/A
E.2.5
WS3.1 GDD dependent STA TVWS 11.44.3, Annex D, WS3:M Yes No N/A
behavior E.2.5
WS4 Channel Availability Query 9.4.5.2, 9.6.8.25, CFTVHT:M Yes No N/A
11.44.4
WS5 Channel Schedule 9.4.5.3, 9.6.8.26, CFTVHT:M Yes No N/A
Management 11.44.5
WS6 Contact Verification Signal 9.6.8.27, 11.44.6 CFTVHT:M Yes No N/A
*WS7 Network Channel Control 6.3.101, 9.4.5.4, CFTVHT:M
9.6.8.30, 11.44.7
WS7.1 NCC Requesting STA 11.44.7.2 CFTVHT:M Yes No N/A
WS7.2 NCC Responding STA 11.44.7.3 CFTVHT:O Yes No N/A
WS8 White Space Map 9.4.2.170, 9.6.8.31, CFTVHT:M Yes No N/A
Announcement 11.44.9
B.4.26.1 TVHT MAC features
Item Protocol capability References Status Support
Are the following MAC protocol
features supported?
TVHTM1 TVHT Capabilities element
TVHTM1.1 VHT Capabilities element 9.4.2.158.1 CFTVHT:O Yes No N/A
2769
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.26.1 TVHT MAC features (continued)
Item Protocol capability References Status Support
TVHTM1.2 Signaling of STA capabilities in 9.3.3.6, 9.3.3.8, (CFTVHT Yes No N/A
Probe Request, (Re)Association 9.3.3.10, AND
Request frames 9.4.2.158.1 CFIndepSTA):
O
(CFTVHT
AND
CFMBSS):O
TVHTM1.3 Signaling of STA and BSS 9.3.3.3, 9.3.3.7, (CFTVHT Yes No N/A
capabilities in Beacon, Probe 9.3.3.9, AND CFAP):O
Response, (Re)Association 9.3.3.11, (CFTVHT
Response frames 9.4.2.158 AND
CFMBSS):O
TVHTM2 Signaling of VHT operation 9.4.2.159 (CFTVHT Yes No N/A
AND CFAP):O
(CFTVHT
AND
CFMBSS):O
(CFTVHT
AND
CFIBSS):O
TVHTM3 Link adaptation
TVHTM3.1 Use of the VHT variant HT Control 9.2.4.6, CFTVHT:O Yes No N/A
field for link adaptation in 9.3.3.15,
immediate response exchange 10.28.3
TVHTM4 Transmit beamforming
*TVHTM4.1 SU Beamformer Capable 9.4.2.158 CFTVHT:O Yes No N/A
*TVHTM4.2 SU Beamformee Capable 9.4.2.158 CFTVHT:O Yes No N/A
*TVHTM4.3 MU Beamformer Capable 9.4.2.158 CFAP AND Yes No N/A
TVHTM4.1:O
*TVHTM4.4 MU Beamformee Capable 9.4.2.158 CFIndepSTA Yes No N/A
AND
TVHTM4.2:O
TVHTM4.5 Transmission of null data packet 10.31 TVHTM4.1:M Yes No N/A
TVHTM4.6 Reception of null data packet 10.31 TVHTM4.2:M Yes No N/A
TVHTM5 VHT sounding protocol
TVHTM5.1 VHT sounding protocol as SU 10.34.5 TVHTM4.1:M Yes No N/A
beamformer
TVHTM5.2 VHT sounding protocol as SU 10.34.5 TVHTM4.2:M Yes No N/A
beamformee
TVHTM5.3 VHT sounding protocol as MU 10.34.5 TVHTM4.3:M Yes No N/A
beamformer
TVHTM5.4 VHT sounding protocol as MU 10.34.5 TVHTM4.4:M Yes No N/A
beamformee
TVHTM6 TXOP Sharing
2770
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.26.1 TVHT MAC features (continued)
Item Protocol capability References Status Support
TVHTM6.1 Sharing of EDCA TXOP 9.19.2.3a CFTVHT:O Yes No N/A
TVHTM6.2 Use of Primary and Secondary AC 9.19.2.3a TVHTM6.1:M Yes No N/A
TVHTM7 VHT TXOP power saving 10.2.1.4a CFTVHT:O Yes No N/A
TVHTM8 BSS Operation
TVHTM8.1 Use of primary TVHT_W, secondary 11.43 CFTVHT:O Yes No N/A
TVHT_W, and secondary
TVHT_2W channels
TVHTM8.2 CCA on primary TVHT_W, 11.43 CFTVHT:O Yes No N/A
secondary TVHT_W, and secondary
TVHT_2W channels
TVHTM9 Group ID
TVHTM9.1 Transmission of Group ID 9.6.23.3 TVHTM4.3:M Yes No N/A
Management frame
TVHTM9.2 Reception of Group ID Management 9.6.23.3 TVHTM4.4:M Yes No N/A
frame
TVHTM10 Bandwidth signaling
TVHTM10.1 Support for non-HT bandwidth 9.3.2.5a CFTVHT:M Yes No N/A
signaling and static operation
TVHTM10.2 Support for non-HT bandwidth 9.3.2.5a CFTVHT:O Yes No N/A
signaling and dynamic operation
TVHTM11 VHT single MPDU format 10.13.8 CFTVHT:M Yes No N/A
TVHTM12 Partial AID in VHT PPDU 10.20 CFTVHT:M Yes No N/A
TVHTM13 Extended BSS Load element 9.4.2.160 CFTVHT:O Yes No N/A
TVHTM13.1 Transmission of the Extended BSS 9.4.2.160 CFAP AND Yes No N/A
Load element CFTVHT:O
TVHTM14 Quiet Channel element
TVHTM14.1 Transmission of Quiet Channel 9.3.3.3, (CFAP OR Yes No N/A
element by an AP or mesh STA in 9.3.3.11, CFMBSS)
Beacon and Probe Response frames 9.4.2.165, AND CFSM
11.9.3 AND CFTVHT
AND
TVHTP3.4:O
TVHTM14.2 Transmission of Quiet Channel 9.3.3.3, (CFIndepSTA Yes No N/A
element by an independent STA or 9.3.3.11, OR CFMBSS)
mesh STA in Beacon and Probe 9.4.2.165, AND CFSM
Response frames 11.9.3 AND CFTVHT
AND
TVHTP3.4:O
TVHTM14.3 Reception of Quiet Channel element 9.3.3.3, (CFIndepSTA Yes No N/A
by an independent STA or mesh STA 9.3.3.11, OR CFMBSS)
in Beacon and Probe Response 9.4.2.165, AND CFSM
frames 11.9.3 AND
CFTVHT:O
2771
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.26.1 TVHT MAC features (continued)
Item Protocol capability References Status Support
TVHTM15 Space-time block coding (STBC)
TVHTM15.1 STBC operation 9.4.2.158, TVHTP9:M Yes No N/A
10.15
TVHTM15.2 Transmission of at least 2x1 STBC 9.4.2.158 TVHTP9:O.1 Yes No N/A
TVHTM15.3 Reception of 1 STBC spatial stream 9.4.2.158 TVHTP9:O.1 Yes No N/A
TVHTM15.4 Reception of 2 STBC spatial stream 9.4.2.158 TVHTM15.3:O Yes No N/A
TVHTM15.5 Reception of 3 STBC spatial stream 9.4.2.158 TVHTM15.4:O Yes No N/A
TVHTM15.6 Reception of 4 STBC spatial stream 9.4.2.158 TVHTM15.5:O Yes No N/A
TVHTM16 Highest Supported Long GI Data
Rate
TVHTM16.1 Tx Highest Supported Long GI Data 9.4.2.158.3 CFTVHT:O Yes No N/A
Rate
TVHTM16.2 Rx Highest Supported Long GI Data 9.4.2.158.3 CFTVHT:O Yes No N/A
Rate
NOTE—Required support for MCS might be limited by the declaration of Tx and Rx Highest Supported Long GI Data Rates.
B.4.26.2 TVHT PHY features
Item Protocol capability References Status Support
Are the following PHY protocol
features supported?
TVHTP1 PHY operating modes Yes No N/A
TVHTP2 VHT format 21.3.2 CFTVHT:M Yes No N/A
TVHTP3 BSS bandwidth
TVHTP3.1 TVHT_W operation 11.43 CFTVHT:M Yes No N/A
TVHTP3.2 TVHT_2W operation 11.43 CFTVHT:O Yes No N/A
TVHTP3.3 TVHT_W+W operation 11.43 CFTVHT:O Yes No N/A
TVHTP3.4 TVHT_4W operation 11.43 CFTVHT:O Yes No N/A
TVHTP3.5 TVHT_2W+2W operation 11.43 CFTVHT:O Yes No N/A
TVHTP4 Bandwidth indication 17.3.5.5 CFVHT:M Yes No N/A
TVHTP5 PHY timing parameters
TVHTP5.1 Values in 6 MHz channel 22.3.6 CFTVHT:M Yes No N/A
TVHTP5.2 Values in 7 MHz channel 22.3.6 CFTVHT:M Yes No N/A
TVHTP5.3 Values in 8 MHz channel 22.3.6 CFTVHT:M Yes No N/A
2772
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.26.2 TVHT PHY features (continued)
Item Protocol capability References Status Support
TVHTP5.4 Values in non-HT 6 MHz, 7 MHz, and 22.2.4 CFTVHT:M Yes No N/A
8 MHz channels
TVHTP6 TVHT preamble 22.3.8 CFTVHT:M Yes No N/A
TVHTP7 Use of LDPC Code 11.5.4, 21.3 CFTVHT:O Yes No N/A
TVHTP8 Modulation and coding schemes
(MCS)
TVHTP8.1 TVHT_MODE_1 22.5
TVHTP8.1.1 TVHT-MCS with Index 0-7 and 22.5 CFTVHT:M Yes No N/A
NSS = 1
TVHTP8.1.2 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.1.1:O Yes No N/A
NSS = 1
TVHTP8.1.3 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.1.2:O Yes No N/A
NSS = 1
TVHTP8.1.4 TVHT-MCS with Index 0-7 and 22.5 CFTVHT:O Yes No N/A
NSS = 2
TVHTP8.1.5 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.1.4:O Yes No N/A
NSS = 2
TVHTP8.1.6 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.1.5:O Yes No N/A
NSS = 2
TVHTP8.1.7 TVHT-MCS with Index 0-7 and 22.5 CFTVHT:O Yes No N/A
NSS = 3
TVHTP8.1.8 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.1.7:O Yes No N/A
NSS = 3
TVHTP8.1.9 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.1.7:O Yes No N/A
NSS = 3
TVHTP8.1.10 TVHT-MCS with Index 0-7 and 22.5 CFTVHT:O Yes No N/A
NSS = 4
TVHTP8.1.11 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.1.10: Yes No N/A
NSS = 4 O
TVHTP8.1.12 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.1.11: Yes No N/A
NSS = 4 O
TVHTP8.2 TVHT_MODE_2C and 22.5
TVHT_MODE_2N
TVHTP8.2.1 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.2 Yes No N/A
NSS = 1 AND
TVHTP3.3):M
TVHTP8.2.2 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.2.1:O Yes No N/A
NSS = 1
TVHTP8.2.3 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.2.2:O Yes No N/A
NSS = 1
2773
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.26.2 TVHT PHY features (continued)
Item Protocol capability References Status Support
TVHTP8.2.4 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.2 Yes No N/A
NSS = 2 AND
TVHTP3.3):O
TVHTP8.2.5 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.2.4:O Yes No N/A
NSS = 2
TVHTP8.2.6 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.2.5:O Yes No N/A
NSS = 2
TVHTP8.2.7 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.2 Yes No N/A
NSS = 3 AND
TVHTP3.3):O
TVHTP8.2.8 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.2.7:O Yes No N/A
NSS = 3
TVHTP8.2.9 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.2.8:O Yes No N/A
NSS = 3
TVHTP8.2.10 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.2 Yes No N/A
NSS = 4 AND
TVHTP3.3):O
TVHTP8.2.11 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.2.10: Yes No N/A
NSS = 4 O
TVHTP8.2.12 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.2.11: Yes No N/A
NSS = 4 O
TVHTP8.3 TVHT_MODE_4C and 22.5
TVHT_MODE_4N
TVHTP8.3.1 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.4 Yes No N/A
NSS = 1 AND
TVHTP3.5):M
TVHTP8.3.2 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.3.1:O Yes No N/A
NSS = 1
TVHTP8.3.3 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.3.2:O Yes No N/A
NSS = 1
TVHTP8.3.4 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.4 Yes No N/A
NSS = 2 AND
TVHTP3.5):O
TVHTP8.3.5 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.3.4:O Yes No N/A
NSS = 2
TVHTP8.3.6 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.3.5:O Yes No N/A
NSS = 2
TVHTP8.3.7 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.4 Yes No N/A
NSS = 3 AND
TVHTP3.5):O
TVHTP8.3.8 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.3.7:O Yes No N/A
NSS = 3
TVHTP8.3.9 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.3.8:O Yes No N/A
NSS = 3
2774
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B.4.26.2 TVHT PHY features (continued)
Item Protocol capability References Status Support
TVHTP8.3.10 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.4 Yes No N/A
NSS = 4 AND
TVHTP3.5):O
TVHTP8.3.11 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.3.10: Yes No N/A
NSS = 4 O
TVHTP8.3.12 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.3.11: Yes No N/A
NSS = 4 O
TVHTP9 Space-time block coding (STBC) 22.3.10.9.4 CFTVHT:O Yes No N/A
2775
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex C
(normative)
ASN.1 encoding of the MAC and PHY MIB
C.1 General
The MIB for the current revision of IEEE Std 802.11 is available online at the following URL: http://
www.ieee802.org/11/802.11mib.txt. The MAC and PHY MIBs are described in Abstract Syntax Notation
One (ASN.1), defined in ISO/IEC 8824-1:1995, ISO/IEC 8824-2:1995, ISO/IEC 8824-3:1995 and ISO/IEC
8824-4:1995.
C.2 Guidelines for IEEE 802.11 MIB authors/editors
The MIB may be compiled using the "smitools" package from the Institute of Operating Systems and
Computer Networks at the Technical University of Braunschweig, Germany. These tools may be accessed
online using the following URL: http://www.ibr.cs.tu-bs.de/bin/smitools.cgi.
Using this tool, the MIB should compile without generating warnings of severity 3 or lower.
Specific points that authors and editors should pay attention to:
— The MIB should compile as specified above prior to submission to IEEE-SA RevCom.
— Use only the 7-bit US-ASCII character-set. In particular, use only straight single and double quotes.
— Do not use symbols such as in units, instead spell out the units fully, i.e.,
"microseconds."
— Follow the guidelines for writing MIB modules in http://www.rfc-editor.org/rfc/rfc4181.txt
(including any updates thereto).
— Pay attention to IETF recommendations on object types.
— When adding a lot of new objects, consider adding a new module.
— Consider seeking advice from an IETF MIB Doctor when creating significant new material. The
IEEE has an arrangement with the IETF whereby the IEEE may ask for a MIB Advisor from the
IETF MIB Doctors.
— When an object is deprecated, add a line to the Description indicating why (IETF convention).
C.3 MIB detail
-- **********************************************************************
-- * IEEE 802.11 MIB
-- **********************************************************************
IEEE802dot11-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, Counter32, Counter64, Unsigned32, TimeTicks, Gauge32
FROM SNMPv2-SMI
DisplayString , MacAddress, RowStatus, TruthValue,
2776
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TEXTUAL-CONVENTION FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF
ifIndex, InterfaceIndex FROM IF-MIB;
-- **********************************************************************
-- * MODULE IDENTITY
-- **********************************************************************
ieee802dot11 MODULE-IDENTITY
LAST-UPDATED "201612140000Z"
ORGANIZATION "IEEE Std 802.11"
CONTACT-INFO
"Chair: Adrian P Stephens
Postal: 64 Lambs Lane
Cottenham, Cambridge, CB24 8TA, United Kingdom
Tel: +44 1793 404825
E-mail: adrian.p.stephens@ieee.org
Editor: Adrian P Stephens
E-mail: adrian.p.stephens@ieee.org"
DESCRIPTION
"The MIB module for IEEE 802.11 entities.
iso(1).member-body(2).us(840).ieee802dot11(10036)"
REVISION "201612140000Z"
DESCRIPTION "IEEE Std 802.11-2016
Note that not all objects within this MIB are referenced by a group, and
not all groups are referenced by a MODULE-COMPLIANCE statement. Some
existing groups and the dot11Compliance MODULE-COMPLIANCE have been
modified since the previous revision of this standard."
REVISION "201203300000Z"
DESCRIPTION "IEEE Std 802.11-2012.
Note that not all objects within this MIB are referenced by a group, and
not all groups are referenced by a MODULE-COMPLIANCE statement. Some
existing groups and the dot11Compliance MODULE-COMPLIANCE have been
modified since the previous revision of this standard.
Implementations should not claim compliance to dot11Compliance."
::= { us 10036 }
-- **********************************************************************
-- * Tree Definition
-- **********************************************************************
member-body OBJECT IDENTIFIER ::= { iso 2 }
us OBJECT IDENTIFIER ::= { member-body 840 }
-- **********************************************************************
-- * Major sections
-- **********************************************************************
-- Station ManagemenT (SMT) Attributes
-- DEFINED AS "The SMT object class provides the necessary support
-- at the station to manage the processes in the station such that
-- the station may work cooperatively as a part of an IEEE 802.11
-- network."
2777
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11smt OBJECT IDENTIFIER ::= { ieee802dot11 1 }
-- dot11smt GROUPS
-- dot11StationConfigTable ::= { dot11smt 1 }
-- dot11AuthenticationAlgorithmsTable ::= { dot11smt 2 }
-- dot11WEPDefaultKeysTable ::= { dot11smt 3 }
-- dot11WEPKeyMappingsTable ::= { dot11smt 4 }
-- dot11PrivacyTable ::= { dot11smt 5 }
-- dot11SMTnotification ::= { dot11smt 6 }
-- dot11MultiDomainCapabilityTable ::= { dot11smt 7 }
-- dot11SpectrumManagementTable ::= { dot11smt 8 }
-- dot11RSNAConfigTable ::= { dot11smt 9 }
-- dot11RSNAConfigPairwiseCiphersTable ::= { dot11smt 10 }
-- dot11RSNAConfigAuthenticationSuitesTable ::= { dot11smt 11 }
-- dot11RSNAStatsTable ::= { dot11smt 12 }
-- dot11OperatingClassesTable ::= { dot11smt 13 }
-- dot11RadioMeasurement ::= { dot11smt 14 }
-- dot11FastBSSTransitionConfigTable ::= { dot11smt 15 }
-- dot11LCIDSETable ::= { dot11smt 16 }
-- dot11HTStationConfigTable ::= { dot11smt 17 }
-- dot11WirelessMgmtOptionsTable ::= { dot11smt 18}
-- dot11LocationServicesNextIndex ::= { dot11smt 19}
-- dot11LocationServicesTable ::= { dot11smt 20}
-- dot11WirelessMGTEventTable ::= { dot11smt 21}
-- dot11WirelessNetworkManagement ::= { dot11smt 22}
-- dot11MeshSTAConfigTable ::= { dot11smt 23 }
-- dot11MeshHWMPConfigTable ::= { dot11smt 24 }
-- dot11RSNAConfigPasswordValueTable ::= { dot11smt 25 }
-- dot11RSNAConfigDLCGroupTable ::= { dot11smt 26 }
-- dot11DMGSTAConfigTable ::= { dot11smt 27 }
-- dot11AVOptionsTable ::= { dot11smt 28 }
-- dot11AVConfigTable ::= { dot11smt 29 }
-- dot11APCTable ::= { dot11smt 30 }
-- dot11VHTStationConfigTable ::= { dot11smt 31 }
-- dot11TVHTStationConfigTable ::= { dot11smt 32 }
-- dot11STALCITable ::= { dot11smt 33 }
-- dot11STALCIConfigTable ::= { dot11smt 36 }
-- dot11STACivicLocationConfigTable ::= { dot11smt 37 }
-- MAC Attributes
-- DEFINED AS "The MAC object class provides the necessary support
-- for the access control, generation, and verification of frame
-- check sequences (FCSs), and proper delivery of valid data to
-- upper layers."
dot11mac OBJECT IDENTIFIER ::= { ieee802dot11 2 }
-- MAC GROUPS
-- dot11OperationTable ::= { dot11mac 1 }
-- dot11CountersTable ::= { dot11mac 2 }
-- dot11GroupAddressesTable ::= { dot11mac 3 }
-- dot11EDCATable ::= { dot11mac 4 }
-- dot11QAPEDCATable ::= { dot11mac 5 }
-- dot11QosCountersTable ::= { dot11mac 6 }
-- dot11ResourceInfoTable ::= { dot11mac 7 }
-- dot11DMGOperationTable ::= { dot11mac 8 }
-- dot11DMGCountersTable ::= { dot11mac 9 }
-- dot11BSSStatisticsTable ::= { dot11mac 10 }
-- Resource Type ID
dot11res OBJECT IDENTIFIER ::= { ieee802dot11 3 }
dot11resAttribute OBJECT IDENTIFIER ::= { dot11res 1 }
-- PHY Attributes
-- DEFINED AS "The PHY object class provides the necessary support
2778
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- for required PHY operational information that may vary from PHY
-- to PHY and from STA to STA to be communicated to upper layers."
dot11phy OBJECT IDENTIFIER ::= { ieee802dot11 4 }
-- PHY GROUPS
-- dot11PhyOperationTable ::= { dot11phy 1 }
-- dot11PhyAntennaTable ::= { dot11phy 2 }
-- dot11PhyTxPowerTable ::= { dot11phy 3 }
-- dot11PhyDSSSTable ::= { dot11phy 5 }
-- dot11RegDomainsSupportedTable ::= { dot11phy 7 }
-- dot11AntennasListTable ::= { dot11phy 8 }
-- dot11SupportedDataRatesTxTable ::= { dot11phy 9 }
-- dot11SupportedDataRatesRxTable ::= { dot11phy 10 }
-- dot11PhyOFDMTable ::= { dot11phy 11 }
-- dot11PhyHRDSSSTable ::= { dot11phy 12 }
-- dot11HoppingPatternTable ::= { dot11phy 13 }
-- dot11PhyERPTable ::= { dot11phy 14 }
-- dot11PhyHTTable ::= { dot11phy 15 }
-- dot11SupportedMCSTxTable ::= { dot11phy 16 }
-- dot11SupportedMCSRxTable ::= { dot11phy 17 }
-- dot11TransmitBeamformingConfigTable ::= { dot11phy 18 }
-- dot11PHYDMGTable ::= { dot11phy 19 }
-- dot11DMGBeamformingConfigTable ::= { dot11phy 22 }
-- **********************************************************************
-- * Textual conventions for 802 definitions
-- **********************************************************************
WEPKeytype ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "Represents the type of WEP key."
SYNTAX OCTET STRING (SIZE (5))
TSFType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "Represents the type of TSF."
SYNTAX OCTET STRING (SIZE (8))
-- **********************************************************************
-- * MIB attribute OBJECT-TYPE definitions follow
-- **********************************************************************
-- **********************************************************************
-- * dot11StationConfig TABLE
-- **********************************************************************
dot11StationConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11StationConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Station Configuration attributes. In tabular form to allow for multiple
instances on an agent."
::= { dot11smt 1 }
dot11StationConfigEntry OBJECT-TYPE
SYNTAX Dot11StationConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11StationConfigTable. It is possible for there to be
multiple IEEE 802.11 interfaces on one agent, each with its unique MAC
address. The relationship between an IEEE 802.11 interface and an
2779
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
interface in the context of the Internet-standard MIB is one-to-one. As
such, the value of an ifIndex object instance can be directly used to
identify corresponding instances of the objects defined herein.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11StationConfigTable 1 }
Dot11StationConfigEntry ::= SEQUENCE
{
dot11StationID MacAddress,
dot11MediumOccupancyLimit Unsigned32,
dot11CFPollable TruthValue,
dot11CFPPeriod Unsigned32,
dot11CFPMaxDuration Unsigned32,
dot11AuthenticationResponseTimeout Unsigned32,
dot11PrivacyOptionImplemented TruthValue,
dot11PowerManagementMode INTEGER,
dot11DesiredSSID OCTET STRING,
dot11DesiredBSSType INTEGER,
dot11OperationalRateSet OCTET STRING,
dot11BeaconPeriod Unsigned32,
dot11DTIMPeriod Unsigned32,
dot11AssociationResponseTimeout Unsigned32,
dot11DisassociateReason Unsigned32,
dot11DisassociateStation MacAddress,
dot11DeauthenticateReason Unsigned32,
dot11DeauthenticateStation MacAddress,
dot11AuthenticateFailStatus Unsigned32,
dot11AuthenticateFailStation MacAddress,
dot11MultiDomainCapabilityImplemented TruthValue,
dot11MultiDomainCapabilityActivated TruthValue,
dot11CountryString OCTET STRING,
dot11SpectrumManagementImplemented TruthValue,
dot11SpectrumManagementRequired TruthValue,
dot11RSNAOptionImplemented TruthValue,
dot11RSNAPreauthenticationImplemented TruthValue,
dot11OperatingClassesImplemented TruthValue,
dot11OperatingClassesRequired TruthValue,
dot11QosOptionImplemented TruthValue,
dot11ImmediateBlockAckOptionImplemented TruthValue,
dot11DelayedBlockAckOptionImplemented TruthValue,
dot11DirectOptionImplemented TruthValue,
dot11APSDOptionImplemented TruthValue,
dot11QAckOptionImplemented TruthValue,
dot11QBSSLoadImplemented TruthValue,
dot11QueueRequestOptionImplemented TruthValue,
dot11TXOPRequestOptionImplemented TruthValue,
dot11MoreDataAckOptionImplemented TruthValue,
dot11AssociateInNQBSS TruthValue,
dot11DLSAllowedInQBSS TruthValue,
dot11DLSAllowed TruthValue,
dot11AssociateStation MacAddress,
dot11AssociateID Unsigned32,
dot11AssociateFailStation MacAddress,
dot11AssociateFailStatus Unsigned32,
dot11ReassociateStation MacAddress,
dot11ReassociateID Unsigned32,
dot11ReassociateFailStation MacAddress,
dot11ReassociateFailStatus Unsigned32,
dot11RadioMeasurementImplemented TruthValue,
dot11RadioMeasurementActivated TruthValue,
dot11RMMeasurementNavSync Unsigned32,
2780
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMMeasurementPilotPeriod Unsigned32,
dot11RMLinkMeasurementActivated TruthValue,
dot11RMNeighborReportActivated TruthValue,
dot11RMParallelMeasurementsActivated TruthValue,
dot11RMRepeatedMeasurementsActivated TruthValue,
dot11RMBeaconPassiveMeasurementActivated TruthValue,
dot11RMBeaconActiveMeasurementActivated TruthValue,
dot11RMBeaconTableMeasurementActivated TruthValue,
dot11RMBeaconMeasurementReportingConditionsActivated TruthValue,
dot11RMFrameMeasurementActivated TruthValue,
dot11RMChannelLoadMeasurementActivated TruthValue,
dot11RMNoiseHistogramMeasurementActivated TruthValue,
dot11RMStatisticsMeasurementActivated TruthValue,
dot11RMLCIMeasurementActivated TruthValue,
dot11RMLCIAzimuthActivated TruthValue,
dot11RMTransmitStreamCategoryMeasurementActivated TruthValue,
dot11RMTriggeredTransmitStreamCategoryMeasurementActivated
TruthValue,
dot11RMAPChannelReportActivated TruthValue,
dot11RMMIBActivated TruthValue,
dot11RMMaxMeasurementDuration Unsigned32,
dot11RMNonOperatingChannelMaxMeasurementDuration Unsigned32,
dot11RMMeasurementPilotTransmissionInformationActivated
TruthValue,
dot11RMMeasurementPilotActivated Unsigned32,
dot11RMNeighborReportTSFOffsetActivated TruthValue,
dot11RMRCPIMeasurementActivated TruthValue,
dot11RMRSNIMeasurementActivated TruthValue,
dot11RMBSSAverageAccessDelayActivated TruthValue,
dot11RMBSSAvailableAdmissionCapacityActivated TruthValue,
dot11RMAntennaInformationActivated TruthValue,
dot11FastBSSTransitionImplemented TruthValue,
dot11LCIDSEImplemented TruthValue,
dot11LCIDSERequired TruthValue,
dot11DSERequired TruthValue,
dot11ExtendedChannelSwitchActivated TruthValue,
dot11RSNAProtectedManagementFramesActivated TruthValue,
dot11RSNAUnprotectedManagementFramesAllowed TruthValue,
dot11AssociationSAQueryMaximumTimeout Unsigned32,
dot11AssociationSAQueryRetryTimeout Unsigned32,
dot11HighThroughputOptionImplemented TruthValue,
dot11RSNAPBACRequired TruthValue,
dot11PSMPOptionImplemented TruthValue,
dot11TunneledDirectLinkSetupImplemented TruthValue,
dot11TDLSPeerUAPSDBufferSTAActivated TruthValue,
dot11TDLSPeerPSMActivated TruthValue,
dot11TDLSPeerUAPSDIndicationWindow Unsigned32,
dot11TDLSChannelSwitchingActivated TruthValue,
dot11TDLSPeerSTAMissingAckRetryLimit Unsigned32,
dot11TDLSResponseTimeout Unsigned32,
dot11OCBActivated TruthValue,
dot11TDLSNavSync Unsigned32,
dot11TDLSDiscoveryRequestWindow Unsigned32,
dot11TDLSACDeterminationInterval Unsigned32,
dot11WirelessManagementImplemented TruthValue,
dot11BssMaxIdlePeriod Unsigned32,
dot11BssMaxIdlePeriodOptions OCTET STRING,
dot11TIMBroadcastInterval Unsigned32,
dot11TIMBroadcastOffset Integer32,
dot11TIMBroadcastHighRateTIMRate Unsigned32,
dot11TIMBroadcastLowRateTIMRate Unsigned32,
dot11StatsMinTriggerTimeout Unsigned32,
dot11RMCivicMeasurementActivated TruthValue,
dot11RMIdentifierMeasurementActivated TruthValue,
2781
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TimeAdvertisementDTIMInterval Unsigned32,
dot11TimeAdvertisementTimeError OCTET STRING,
dot11TimeAdvertisementTimeValue OCTET STRING,
dot11RM3rdPartyMeasurementActivated TruthValue,
dot11InterworkingServiceImplemented TruthValue,
dot11InterworkingServiceActivated TruthValue,
dot11QosMapImplemented TruthValue,
dot11QosMapActivated TruthValue,
dot11EBRImplemented TruthValue,
dot11EBRActivated TruthValue,
dot11ESNetwork TruthValue,
dot11SSPNInterfaceImplemented TruthValue,
dot11SSPNInterfaceActivated TruthValue,
dot11HESSID MacAddress,
dot11EASImplemented TruthValue,
dot11EASActivated TruthValue,
dot11MSGCFImplemented TruthValue,
dot11MSGCFActivated TruthValue,
dot11MeshActivated TruthValue,
dot11RejectUnadmittedTraffic TruthValue,
dot11BSSBroadcastNullCount Unsigned32,
dot11QMFActivated TruthValue,
dot11QMFReconfigurationActivated TruthValue,
dot11QMFPolicyChangeTimeout Unsigned32,
dot11RobustAVStreamingImplemented TruthValue,
dot11MultibandImplemented TruthValue,
dot11DynamicEIFSActivated TruthValue,
dot11VHTOptionImplemented TruthValue,
dot11OperatingModeNotificationImplemented TruthValue,
dot11TVHTOptionImplemented TruthValue,
dot11ChannelScheduleManagementActivated TruthValue,
dot11ContactVerificationSignalActivated TruthValue,
dot11ContactVerificationSignalInterval Unsigned32,
dot11NetworkChannelControlActivated TruthValue,
dot11RLSSActivated TruthValue,
dot11WhiteSpaceMapActivated TruthValue,
dot11WSSTAType INTEGER,
dot11GeolocationCapabilityActivated TruthValue,
dot11GDDActivated TruthValue,
dot11GDDEnablementTimeLimit Unsigned32,
dot11GDDEnablementFailHoldTime Unsigned32,
dot11GDDEnablementValidityTimer Unsigned32,
dot11MaxMSDULength INTEGER,
dot11ExtendedSpectrumManagementImplemented TruthValue,
dot11EstimatedServiceParametersOptionImplemented TruthValue,
dot11VHTExtendedNSSBWCapable TruthValue,
dot11FutureChannelGuidanceActivated TruthValue
}
dot11StationID OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
The purpose of dot11StationID is to allow a manager to identify a station
for its own purposes. This attribute provides for that eventuality while
keeping the true MAC address independent. Its syntax is MAC address, and
the default value is the station's assigned, unique MAC address."
::= { dot11StationConfigEntry 1 }
2782
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11MediumOccupancyLimit OBJECT-TYPE
SYNTAX Unsigned32 (0..1000)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum amount of time that a point
coordinator (PC) may control the usage of the wireless medium (WM) without
relinquishing control for long enough to allow at least one instance of
DCF access to the medium. The maximum value of this variable is 1000."
DEFVAL { 100 }
::= { dot11StationConfigEntry 2 }
dot11CFPollable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
When this attribute is true, it indicates that the STA is able to respond
to a CF-Poll with a Data frame within a SIFS. This attribute is false if
the STA is not able to respond to a CF-Poll with a Data frame within a
SIFS."
::= { dot11StationConfigEntry 3 }
dot11CFPPeriod OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
In an AP, it is written by the MAC when it receives an MLME-START.request
primitive.
In a non-AP STA, it is written by the MAC when it receives an updated CF
Parameter Set in a Beacon frame.
The attribute describes the number of DTIM intervals between the start of
CFPs. It is modified by MLME-START.request primitive."
::= { dot11StationConfigEntry 4 }
dot11CFPMaxDuration OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
In an AP, it is written by the MAC when it receives an MLME-START.request
primitive.
In a non-AP STA, it is written by the MAC when it receives an updated CF
Parameter Set in a Beacon frame.
The attribute describes the maximum duration of the CFP that may be
generated by the PCF. It is modified by MLME-START.request primitive."
::= { dot11StationConfigEntry 5 }
dot11AuthenticationResponseTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
2783
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-write
STATUS Deprecated
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next Authentication frame.
This attribute specifies the number of time units (TUs) that a responding
STA should wait for the next frame in the authentication sequence."
::= { dot11StationConfigEntry 6 }
dot11PrivacyOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the IEEE 802.11 WEP option is
implemented."
DEFVAL { false }
::= { dot11StationConfigEntry 7 }
dot11PowerManagementMode OBJECT-TYPE
SYNTAX INTEGER { active(1), powersave(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an MLME-POWERMGT.request primitive is
received.
This attribute specifies the power management mode of the STA. When equal
to active, it indicates that the station is not in power save (PS) mode.
When equal to powersave, it indicates that the station is in power save
mode. The power management mode is transmitted in all frames according to
the rules in 9.2.4.1.8."
::= { dot11StationConfigEntry 8 }
dot11DesiredSSID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-SCAN.request primitive.
This attribute reflects the Service Set ID (SSID) used in the SSID
parameter of the most recent MLME-SCAN.request primitive. This value may
be modified by an external management entity and used by the local SME to
make decisions about the Scanning process."
::= { dot11StationConfigEntry 9 }
dot11DesiredBSSType OBJECT-TYPE
SYNTAX INTEGER { infrastructure(1), independent(2), any(3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-SCAN.request primitive.
2784
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute specifies the type of BSS the station uses when scanning
for a BSS with which to synchronize. This value is used to filter Probe
Response frames and Beacon frames. When equal to infrastructure, the
station synchronizes only with a BSS in which the Capability Information
field has the ESS subfield equal to 1. When equal to independent, the
station synchronizes only with a BSS whose Capability Information field
has the IBSS subfield equal to 1. When equal to any, the station may
synchronize to either type of BSS."
::= { dot11StationConfigEntry 10 }
dot11OperationalRateSet OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..126))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when joining or establishing a BSS.
This attribute specifies the set of non-HT data rates at which the station
is able to receive data. Each octet contains a value representing a rate.
Each rate is within the range 2 to 127, corresponding to data rates in
increments of 500 kb/s from 1 Mb/s to 63.5 Mb/s, and is supported (as
indicated in the supported rates table) for receiving data. This value is
reported in transmitted Beacon, Probe Request, Probe Response, Association
Request, Association Response, Reassociation Request, and Reassociation
Response frames, and is used to determine whether a BSS with which the
station might synchronize is suitable. It is also used when starting a
BSS, as specified in 6.3.4."
::= { dot11StationConfigEntry 11 }
dot11BeaconPeriod OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
For non-DMG STAs, this attribute specifies the number of TUs that a
station uses for scheduling Beacon transmissions. For DMG STAs, this
attribute specifies the number of TUs that a station uses for scheduling
BTI and/or ATI in the beacon interval. This value is transmitted in Beacon
and Probe Response frames."
::= { dot11StationConfigEntry 12 }
dot11DTIMPeriod OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute specifies the number of beacon intervals that elapse
between transmission of Beacon frames containing a TIM element whose DTIM
Count field is 0. This value is transmitted in the DTIM Period field of
Beacon frames."
::= { dot11StationConfigEntry 13 }
dot11AssociationResponseTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-write
2785
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of TU that a requesting STA should
wait for a response to a transmitted (Re)Association Request frame."
::= { dot11StationConfigEntry 14 }
dot11DisassociateReason OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA disassociates.
This attribute holds the most recently transmitted Reason Code in a
Disassociation frame. If no Disassociation frame has been transmitted, the
value of this attribute is 0."
REFERENCE "IEEE Std 802.11-2016, 9.4.1.7"
::= { dot11StationConfigEntry 15 }
dot11DisassociateStation OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA disassociates.
This attribute holds the MAC address from the Address 1 field of the most
recently transmitted Disassociation frame. If no Disassociation frame has
been transmitted, the value of this attribute is 0."
::= { dot11StationConfigEntry 16 }
dot11DeauthenticateReason OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA deauthenticates.
This attribute holds the most recently transmitted Reason Code in a
Deauthentication frame. If no Deauthentication frame has been transmitted,
the value of this attribute is 0."
REFERENCE "IEEE Std 802.11-2016, 9.4.1.7"
::= { dot11StationConfigEntry 17 }
dot11DeauthenticateStation OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA deauthenticates.
This attribute holds the MAC address from the Address 1 field of the most
recently transmitted Deauthentication frame. If no Deauthentication frame
has been transmitted, the value of this attribute is 0."
::= { dot11StationConfigEntry 18 }
2786
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11AuthenticateFailStatus OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA fails to authenticate.
This attribute holds the most recently transmitted Status Code in a failed
Authentication frame. If no failed Authentication frame has been
transmitted, the value of this attribute is 0."
REFERENCE "IEEE Std 802.11-2016, 9.4.1.9"
::= { dot11StationConfigEntry 19 }
dot11AuthenticateFailStation OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA fails to authenticate.
This attribute holds the MAC address from the Address 1 field of the most
recently transmitted failed Authentication frame. If no failed
Authentication frame has been transmitted, the value of this attribute is
0."
::= { dot11StationConfigEntry 20 }
dot11MultiDomainCapabilityImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting multiple regulatory domains. The capability is
disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 21 }
dot11MultiDomainCapabilityActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute, when true, indicates that the capability of the station to
operate in multiple regulatory domains is enabled."
DEFVAL { false }
::= { dot11StationConfigEntry 22 }
dot11CountryString OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(3))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME.
Changes take effect for the next MLME-START.request primitive.
2787
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute identifies the country or noncountry entity in which the
station is operating. If it is a country, the first two octets of this
string is the two character country code as described in document ISO
3166-1. The third octet is one of the following:
1. an ASCII space character, if the regulations under which the station is
operating encompass all environments for the current frequency band in the
country,
2. an ASCII 'O' character, if the regulations under which the station is
operating are for an outdoor environment only, or
3. an ASCII 'I' character, if the regulations under which the station is
operating are for an indoor environment only.
4. an ASCII 'X' character, if the station is operating under a noncountry
entity. The first two octets of the noncountry entity is two ASCII 'XX'
characters.
5. the hexadecimal representation of the Operating Class table number
currently in use, from the set of tables defined in Annex E, e.g., Table E-
1 is represented as x'01'."
::= { dot11StationConfigEntry 23 }
dot11SpectrumManagementImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting spectrum management. The capability is disabled
otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 24 }
dot11SpectrumManagementRequired OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
A STA uses the defined TPC and DFS procedures if this attribute is true;
otherwise it does not use the defined TPC and DFS procedures."
DEFVAL { false }
::= { dot11StationConfigEntry 25 }
dot11RSNAOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This variable indicates whether the entity is RSNA-capable."
::= { dot11StationConfigEntry 26 }
2788
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RSNAPreauthenticationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This variable indicates whether the entity supports RSNA
preauthentication. This cannot be true unless dot11RSNAOptionImplemented
is true."
::= { dot11StationConfigEntry 27 }
dot11OperatingClassesImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting operating classes. The capability is disabled
otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 28 }
dot11OperatingClassesRequired OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
A STA uses the defined operating classes procedures if this attribute is
true."
DEFVAL { false }
::= { dot11StationConfigEntry 29 }
dot11QosOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting QoS. The capability is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 30}
dot11ImmediateBlockAckOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
2789
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
capable of supporting immediate block ack. The capability is disabled,
otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 31}
dot11DelayedBlockAckOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting delayed block ack. The capability is disabled,
otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 32 }
dot11DirectOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of sending and receiving frames from a non-AP STA in the BSS. The
capability is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 33 }
dot11APSDOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute is available only at an AP. When true, this attribute
indicates that the AP implementation is capable of delivering data and
polls to stations using APSD."
::= { dot11StationConfigEntry 34 }
dot11QAckOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of interpreting the CF-Ack bit in a received frame with the Type
subfield equal to Data even if the frame is not directed to the QoS
station. The capability is disabled, otherwise. A STA is capable of
interpreting the CF-Ack bit in a received Data frame if that station is
the recipient of the Data frame, regardless of the value of this MIB
variable."
DEFVAL { false }
::= { dot11StationConfigEntry 35 }
2790
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11QBSSLoadImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute is available only at an AP. This attribute, when true,
indicates that the AP implementation is capable of generating and
transmitting the BSS load element in the Beacon and Probe Response frames.
The capability is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 36 }
dot11QueueRequestOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute is available only at an AP. This attribute, when true,
indicates that the AP is capable of processing the Queue Size field in QoS
Control field of QoS Data type frames. The capability is disabled,
otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 37 }
dot11TXOPRequestOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute is available only at an AP. This attribute, when true,
indicates that the AP is capable of processing the TXOP Duration requested
field in QoS Control field of QoS Data type frames. The capability is
disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 38 }
dot11MoreDataAckOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of interpreting the More Data bit in the Ack frames. The
capability is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 39 }
dot11AssociateInNQBSS OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
2791
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the station may associate in a
non-QoS BSS. When false, this attribute indicates that the station does
not associate in a non-QoS BSS."
DEFVAL { true }
::= { dot11StationConfigEntry 40 }
dot11DLSAllowedInQBSS OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute available at the AP, when true, indicates that STAs may set
up DLS and communicate using DLS with other STAs in the BSS. When false,
this attribute indicates that the stations do not set up DLS nor
communicate with other STAs using DLS in the BSS."
DEFVAL { true }
::= { dot11StationConfigEntry 41 }
dot11DLSAllowed OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute available at non-AP STAs, when true, indicates that the STA
may set up DLS or accept DLS Requests, and communicate with other STAs in
the BSS using DLS. When false, this attribute indicates that the STA does
not set up DLS nor accept DLS, nor communicate with other STAs in the BSS
using DLS."
DEFVAL { true }
::= { dot11StationConfigEntry 42}
dot11AssociateStation OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA associates.
This attribute indicates the MAC address from the Address 1 field of the
most recently transmitted Association Response frame. If no Association
Response frame has been transmitted, the value of this attribute is 0."
::= { dot11StationConfigEntry 43 }
dot11AssociateID OBJECT-TYPE
SYNTAX Unsigned32(0..2007)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA associates.
2792
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the Association ID from the most recently
transmitted Association Response frame. If no Association Response frame
has been transmitted, the value of this attribute is 0."
::= { dot11StationConfigEntry 44 }
dot11AssociateFailStation OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA fails to associate.
This attribute indicates the MAC address from the Address 1 field of the
most recently transmitted failed Association Response frame. If no failed
Association Response frame has been transmitted, the value of this
attribute is 0."
::= { dot11StationConfigEntry 45 }
dot11AssociateFailStatus OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA fails to associate.
This attribute indicates the most recently transmitted Status Code in a
failed Association Response frame. If no failed Association Response frame
has been transmitted, the value of this attribute is 0."
::= { dot11StationConfigEntry 46 }
dot11ReassociateStation OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA reassociates.
This attribute indicates the MAC address from the Address 1 field of the
most recently transmitted Reassociation Response frame. If no
Reassociation Response frame has been transmitted, the value of this
attribute is 0."
::= { dot11StationConfigEntry 47 }
dot11ReassociateID OBJECT-TYPE
SYNTAX Unsigned32(0..2007)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA reassociates.
This attribute indicates the Association ID from the most recently
transmitted Reassociation Response frame. If no Reassociation Response
frame has been transmitted, the value of this attribute is 0."
::= { dot11StationConfigEntry 48 }
dot11ReassociateFailStation OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
2793
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the MAC when a STA fails to reassociate.
This attribute indicates the MAC address from the Address 1 field of the
most recently transmitted failed Reassociation Response frame. If no
failed Reassociation Response frame has been transmitted, the value of
this attribute is 0."
::= { dot11StationConfigEntry 49 }
dot11ReassociateFailStatus OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA fails to reassociate.
This attribute indicates the most recently transmitted Status Code in a
failed Reassociation Response frame. If no failed Reassociation Response
frame has been transmitted, the value of this attribute is 0."
::= { dot11StationConfigEntry 50 }
dot11RadioMeasurementImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting Radio Measurement. Otherwise it is not capable of
performing Radio Measurement."
DEFVAL { false }
::= { dot11StationConfigEntry 51 }
dot11RadioMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when any of the MIB
variables listed in 9.4.2.45 is equal to true.
Changes take effect with the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that one or more of the Radio
Measurement Activated Capabilities MIB attributes, listed in 9.4.2.45, are
equal to true. A STA may use the defined Radio Measurement procedures if
this attribute is true."
DEFVAL { false }
::= { dot11StationConfigEntry 52 }
dot11RMMeasurementNavSync OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The value of ProbeDelay to be used when making a beacon type measurement
2794
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
with measurement mode active."
::= { dot11StationConfigEntry 53 }
dot11RMMeasurementPilotPeriod OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of TUs that a station uses for
scheduling Measurement Pilot frame transmissions. This value is
transmitted in Measurement Pilot frames. The default period is 25% of
dot11BeaconPeriod."
::= { dot11StationConfigEntry 54 }
dot11RMLinkMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Link Measurement is enabled. A
value of false indicates the station has no Link Measurement capability or
that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 55 }
dot11RMNeighborReportActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for neighbor report is enabled.
false indicates the station has no neighbor report capability or that the
capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 56 }
dot11RMParallelMeasurementsActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Parallel Measurements is
enabled. false indicates the station has no Parallel Measurements
2795
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 57 }
dot11RMRepeatedMeasurementsActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Repeated Measurements is
enabled. false indicates the station has no Repeated Measurements
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 58 }
dot11RMBeaconPassiveMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Beacon Passive Measurement is
enabled. false indicates the station has no Beacon Passive Measurement
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 59 }
dot11RMBeaconActiveMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Beacon Active Measurement is
enabled. false indicates the station has no Beacon Active Measurement
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 60 }
dot11RMBeaconTableMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
2796
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Beacon Table Measurement is
enabled. false indicates the station has no Beacon Table Measurement
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 61 }
dot11RMBeaconMeasurementReportingConditionsActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Beacon Measurement Reporting
Conditions is enabled. false indicates the station has no Beacon
Measurement Reporting Conditions capability or that the capability is
present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 62 }
dot11RMFrameMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Frame Measurement is enabled.
false indicates the station has no Frame Measurement capability or that
the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 63 }
dot11RMChannelLoadMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Channel Load Measurement is
enabled. false indicates the station has no Channel Load Measurement
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 64 }
dot11RMNoiseHistogramMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
2797
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Noise Histogram Measurement is
enabled. false indicates the station has no Noise Histogram Measurement
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 65 }
dot11RMStatisticsMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Statistics Measurement is
enabled. false indicates the station has no Statistics Measurement
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 66 }
dot11RMLCIMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for LCI Measurement is enabled.
false indicates the station has no LCI Measurement capability or that the
capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 67 }
dot11RMLCIAzimuthActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for LCI Azimuth Measurement is
enabled. false indicates the station has no LCI Azimuth Measurement
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 68 }
dot11RMTransmitStreamCategoryMeasurementActivated OBJECT-TYPE
2798
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Transmit Stream/Category
Measurement is enabled. false indicates the station has no Transmit
Stream/Category Measurement capability or that the capability is present
but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 69 }
dot11RMTriggeredTransmitStreamCategoryMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Triggered Transmit Stream/
Category Measurement is enabled. false indicates the station has no
Triggered Transmit Stream/Category Measurement capability or that the
capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 70 }
dot11RMAPChannelReportActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for AP Channel Report is enabled.
false indicates the station has no AP Channel Report capability or that
the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 71 }
dot11RMMIBActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for RM MIB is enabled. false
indicates the station has no RM MIB capability or that the capability is
present but is disabled. See RM MIB details."
DEFVAL { false }
2799
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11StationConfigEntry 72 }
dot11RMMaxMeasurementDuration OBJECT-TYPE
SYNTAX Unsigned32(0 .. 7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum measurement duration for operating
channel measurements, where
Max Measurement Duration in TUs =
(2 ** (dot11RMMaxMeasurementDuration - 4)) * BeaconInterval
Further details are provided in 11.11.4"
::= { dot11StationConfigEntry 73 }
dot11RMNonOperatingChannelMaxMeasurementDuration OBJECT-TYPE
SYNTAX Unsigned32(0 .. 7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute indicates the maximum measurement duration for nonoperating
channel measurements, where
Non-OpMax Measurement Duration in TUs =
(2 ** (dot11RMNonOperatingChannelMaxMeasurementDuration - 4))
* BeaconInterval
Further details are provided in 11.11.4"
::= { dot11StationConfigEntry 74 }
dot11RMMeasurementPilotTransmissionInformationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Measurement Pilot Transmission
information is enabled. false indicates the station has no Measurement
Pilot Transmission information capability or that the capability is
present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 75 }
dot11RMMeasurementPilotActivated OBJECT-TYPE
SYNTAX Unsigned32(0 .. 7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
2800
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the station capability for Measurement Pilot. The
value 0 indicates the station has no Measurement Pilot capability or that
the capability is present but is disabled. Activated values 1-7 are
defined in Table 11-10."
DEFVAL { 0 }
::= { dot11StationConfigEntry 76 }
dot11RMNeighborReportTSFOffsetActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Neighbor Report TSF Offset is
enabled. false indicates the station has no Neighbor Report TSF Offset
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 77 }
dot11RMRCPIMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for RCPI Measurement is enabled.
false indicates the station has no RCPI Measurement capability or that the
capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 78 }
dot11RMRSNIMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for RSNI Measurement is enabled.
false indicates the station has no RSNI Measurement capability or that the
capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 79 }
dot11RMBSSAverageAccessDelayActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
2801
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for BSS Average Access Delay is
enabled. false indicates the station has no BSS Average Access Delay
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 80 }
dot11RMBSSAvailableAdmissionCapacityActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for BSS Available Admission
Capacity is enabled. false indicates the station has no BSS Available
Admission Capacity capability or that the capability is present but is
disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 81 }
dot11RMAntennaInformationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Antenna information is
enabled. false indicates the station has no Antenna information capability
or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 82 }
dot11FastBSSTransitionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This object indicates if the entity is fast BSS transition capable."
::= { dot11StationConfigEntry 83 }
dot11LCIDSEImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
2802
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute, when true, indicates that the station implementation is
capable of supporting LCI DSE. The capability is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 84 }
dot11LCIDSERequired OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME.
A STA uses the Dependent Station Enablement procedures if this attribute
is true."
DEFVAL { false }
::= { dot11StationConfigEntry 85 }
dot11DSERequired OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME.
This attribute, when true, indicates that the station operation is
dependent on enablement from enabling STAs. This attribute, when false,
indicates that the station operation does not depend on enablement from
STAs."
DEFVAL { false }
::= { dot11StationConfigEntry 86 }
dot11ExtendedChannelSwitchActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized for operation in a
band defined by an Operating Class.
This attribute, when true, indicates that the station implementation is
capable of supporting Extended Channel Switch Announcement. The capability
is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 87 }
--**********************************************************
--* Management frame protection MIBs
--**********************************************************
dot11RSNAProtectedManagementFramesActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This variable indicates whether this STA enables management frame
protection."
DEFVAL { false }
::= { dot11StationConfigEntry 88}
2803
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RSNAUnprotectedManagementFramesAllowed OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This variable indicates whether this STA supports RSNA STAs which do not
provide robust management frames protection."
DEFVAL { true }
::= { dot11StationConfigEntry 89}
--**********************************************************
--* SA Query Procedure MIBs
--**********************************************************
dot11AssociationSAQueryMaximumTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of TUs that an AP can wait, from the
scheduling of the first SA Query Request to allow association process to
be started without starting additional SA Query procedure if a successful
SA Query Response is not received."
DEFVAL { 1000 }
::= { dot11StationConfigEntry 90}
dot11AssociationSAQueryRetryTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of TUs that an AP waits between
issuing two subsequent MLME-SA-QUERY.request primitive primitives."
DEFVAL { 201 }
::= { dot11StationConfigEntry 91}
dot11HighThroughputOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates whether the entity is HT Capable."
::= { dot11StationConfigEntry 92}
dot11RSNAPBACRequired OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
2804
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This variable indicates whether this STA requires the Protection of block
ack agreements."
DEFVAL { false }
::= { dot11StationConfigEntry 93}
dot11PSMPOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting PSMP."
DEFVAL { false }
::= { dot11StationConfigEntry 94 }
dot11TunneledDirectLinkSetupImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute, when true, indicates that the STA implementation is
capable of supporting Tunneled DirectLink Setup."
DEFVAL { false }
::= { dot11StationConfigEntry 95 }
dot11TDLSPeerUAPSDBufferSTAActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute, when true, indicates that the STA implementation is
capable of supporting TPU."
DEFVAL { false }
::= { dot11StationConfigEntry 96 }
dot11TDLSPeerPSMActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute, when true, indicates that the STA implementation is
capable of supporting TDLS peer PSM."
DEFVAL { false }
::= { dot11StationConfigEntry 97 }
dot11TDLSPeerUAPSDIndicationWindow OBJECT-TYPE
SYNTAX Unsigned32 (1..256)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This attribute indicates the minimum interval in Beacon Intervals between
successive Peer Traffic Indication frames."
DEFVAL { 1 }
::= { dot11StationConfigEntry 98 }
dot11TDLSChannelSwitchingActivated OBJECT-TYPE
SYNTAX TruthValue
2805
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute, when true, indicates that the STA implementation is
capable of supporting TDLS Channel Switching."
DEFVAL { false }
::= { dot11StationConfigEntry 99 }
dot11TDLSPeerSTAMissingAckRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This attribute indicates the number of times the TDLS STA may retry a
frame for which it does not receive an Ack frame from TDLS peer STA in
power save mode after the TDLS peer STA does not receive an Ack frame to
an individually addressed MPDU sent with the EOSP subfield equal to 1 or
to an individually addressed MPDU that initiated a channel switch."
DEFVAL { 3 }
::= { dot11StationConfigEntry 100 }
dot11TDLSResponseTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This attribute indicates the amount of time the STA waits before timing
out a TDLS setup request."
DEFVAL { 5 }
::= { dot11StationConfigEntry 101 }
dot11OCBActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A STA uses the defined outside the context of a BSS procedures if and
only if this attribute is true. The default value of this attribute is
false."
DEFVAL { false }
::= { dot11StationConfigEntry 102 }
dot11TDLSNavSync OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This attribute indicates the amount of time the STA waits before
transmitting on a new channel, in the absence of traffic on the channel
that causes a CCA state to be created."
DEFVAL { 1000 }
::= { dot11StationConfigEntry 103 }
dot11TDLSDiscoveryRequestWindow OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This attribute indicates the minimum number of DTIM intervals between
successive TDLS Discovery Request frames."
DEFVAL { 2 }
::= { dot11StationConfigEntry 104 }
2806
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TDLSACDeterminationInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This attribute indicates the number of seconds during which the lowest AC
of transmitted traffic is determined."
DEFVAL { 1 }
::= { dot11StationConfigEntry 105 }
dot11WirelessManagementImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting one or more wireless network management services."
::= { dot11StationConfigEntry 106}
dot11BssMaxIdlePeriod OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates that the number of 1000 TUs that pass before an
AP disassociates an inactive non-AP STA. This value is transmitted in the
Association Response and Reassociation Response frames."
::= { dot11StationConfigEntry 107}
dot11BssMaxIdlePeriodOptions OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the options associated with the BSS max idle
capability. This value is transmitted in the Association Response and
Reassociation Response frames."
::= { dot11StationConfigEntry 108}
dot11TIMBroadcastInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the number of beacon periods between TIM frame
transmissions. A value of 0 disables TIM Broadcast for the requesting sta-
tion."
DEFVAL { 0 }
2807
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11StationConfigEntry 109}
dot11TIMBroadcastOffset OBJECT-TYPE
SYNTAX Integer32 (-214748364..214748363)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the offset with a tolerance of +/- 4 microseconds
relative to the TBTT for which a TIM frame is scheduled for transmission."
DEFVAL { 0 }
::= { dot11StationConfigEntry 110}
dot11TIMBroadcastHighRateTIMRate OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "0.5 Mb/s"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the rate used to transmit the high data rate
TIM frame. A value of 0 indicates that the high rate TIM frame is not
transmitted."
DEFVAL { 0 }
::= { dot11StationConfigEntry 111}
dot11TIMBroadcastLowRateTIMRate OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "0.5 Mb/s"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the rate used to transmit the low data rate
TIM frame. A value of 0 indicates that the low rate TIM frame is not
transmitted."
DEFVAL { 0 }
::= { dot11StationConfigEntry 112}
dot11StatsMinTriggerTimeout OBJECT-TYPE
SYNTAX Unsigned32 (10..7200)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum allowable value for Triggered
Timeout. A Triggered STA Statistics report is generated by the STA after
the timeout if none of the trigger conditions are satisfied."
DEFVAL { 10 }
::= { dot11StationConfigEntry 113 }
2808
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMCivicMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Location Civic Measurement is
enabled. false indicates the station has no Location Civic Measurement
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 114 }
dot11RMIdentifierMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for location identifier
measurement is enabled. false indicates the station has no Location
Identifier Measurement capability or that the capability is present but is
disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 115 }
dot11TimeAdvertisementDTIMInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "dtims"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the interval in number of DTIMS when the Time
Advertisement element is included in Beacon frames."
DEFVAL { 1 }
::= { dot11StationConfigEntry 116 }
dot11InterworkingServiceImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute when true, indicates the STA is capable of interworking
with external networks. A STA setting this to true implements Interworking
Service. When this is false, the STA does not implement Interworking
Service."
DEFVAL {false}
::= { dot11StationConfigEntry 117 }
2809
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11InterworkingServiceActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes take
effect as soon as practical in the implementation.
This attribute when true, indicates the capability of the STA to interwork
with external networks is enabled. The capability is disabled otherwise."
DEFVAL {false}
::= { dot11StationConfigEntry 118 }
dot11QosMapImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute available at STAs, when true, indicates the STA is capable
of supporting the QoS Map procedures. When this is false, the STA does not
implement QoS Map procedures."
DEFVAL {false}
::= { dot11StationConfigEntry 119 }
dot11QosMapActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes take
effect as soon as practical in the implementation.
This attribute, when true, indicates the capability of the STA to support
QoS Map procedures is enabled. The capability is disabled otherwise."
DEFVAL {false}
::= { dot11StationConfigEntry 120 }
dot11EBRImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute available at STAs, when true, indicates the STA is capable
of supporting Expedited Bandwidth Request procedures. When this is false,
the STA does not implement Expedited Bandwidth Request procedures."
DEFVAL {false}
::= { dot11StationConfigEntry 121 }
dot11EBRActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
2810
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes take
effect as soon as practical in the implementation.
This attribute, when true, indicates the capability of the STA to support
Expedited Bandwidth Request procedures is enabled. The capability is
disabled otherwise."
DEFVAL {false}
::= { dot11StationConfigEntry 122 }
dot11ESNetwork OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes take
effect as soon as practical in the implementation.
The emergency services access network type equal to true indicates that
the BSS is used exclusively for the purposes of accessing emergency
services. This object is not used by non-AP STAs."
::= { dot11StationConfigEntry 123 }
dot11SSPNInterfaceImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute when true, indicates the AP is capable of SSPN Interface
service. When this is false, the STA does not implement SSPN Interface
Service. This object is not used by non-AP STAs. The default value of this
attribute is false."
DEFVAL {false}
::= { dot11StationConfigEntry 124 }
dot11SSPNInterfaceActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes take
effect as soon as practical in the implementation.
This attribute, when true, indicates the capability of the AP to provide
SSPN Interface service is enabled. The capability is disabled, otherwise.
The default value of this attribute is false."
DEFVAL {false}
::= { dot11StationConfigEntry 125 }
dot11HESSID OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-write
STATUS current
2811
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes take
effect for the next MLME-START.request primitive.
This attribute is used by an AP and is the 6-octet homogeneous ESS
identifier field, whose value is set to one of the BSSIDs in the ESS. It
is required that the same value of HESSID be used for all BSSs in the
homogeneous ESS."
::= { dot11StationConfigEntry 126 }
dot11EASImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute when true, indicates the STA is capable of emergency alert
system notification with external networks. A STA setting this to true
implements emergency alert system notification. When this is false, the
STA does not implement emergency alert system notification."
DEFVAL {false}
::= { dot11StationConfigEntry 127 }
dot11EASActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes take
effect as soon as practical in the implementation.
This attribute when true, indicates the STA is capable of supporting
emergency alert system. The capability is disabled otherwise."
DEFVAL {false}
::= { dot11StationConfigEntry 128 }
dot11MSGCFImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute when true, indicates the non-AP STA is capable of
supporting the MSGCF procedures defined in 6.4. When false, the non-AP STA
does not implement MSGCF procedures. This object is not used by APs. The
default value of this attribute is false."
DEFVAL {false}
::= { dot11StationConfigEntry 129 }
dot11MSGCFActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
2812
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity or the SME. Changes take
effect as soon as practical in the implementation.
This attribute, when true, indicates the capability of the non-AP STA to
provide the MSGCF is enabled. The capability is disabled, otherwise. The
default value of this attribute is false."
DEFVAL {false}
::= { dot11StationConfigEntry 130 }
dot11TimeAdvertisementTimeError OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(5))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the Time Error value as defined in the Time
Advertisement element Time Error field when the Time Capabilities field is
set to 2. This field is included in the Time Advertisement element in
Beacon and Probe Response frames."
DEFVAL { ''H }
::= { dot11StationConfigEntry 131 }
dot11TimeAdvertisementTimeValue OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(10))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the TimeAdvertisement Time Value as defined in
the Time Advertisement element Time Value field when the Time Capabilities
field is set to 2. The format is defined in Table 9-170 and is included in
the Time Advertisement element in Beacon and Probe Response frames."
::= { dot11StationConfigEntry 132 }
dot11RM3rdPartyMeasurementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that dot11RadioMeasurementActivated
is true and that the station capability for Third Party Location
Measurement is enabled. false indicates the station has no Third Party
Location Measurement capability or that the capability is present but is
disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 133 }
dot11RejectUnadmittedTraffic OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
2813
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity.
Changes take effect at the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute when true indicates the STA's MA-UNITDATA primitive rejects
frames whose requested priority corresponds to an AC for which admission
control is mandatory and for which there is not an admitted TSPEC."
DEFVAL { false }
::= {dot11StationConfigEntry 134}
dot11BSSBroadcastNullCount OBJECT-TYPE
SYNTAX Unsigned32 (1..64)
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"Deprecated because this variable is not referenced in the standard.
This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of group addressed (QoS) Null frames
an IBSS STA transmits before it changes power management modes."
DEFVAL { 3 }
::= {dot11StationConfigEntry 135}
dot11MeshActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
When this object is true, this indicates that the STA is a mesh STA.
Configuration variables for mesh operation are found in the
dot11MeshSTAConfigTable."
::= { dot11StationConfigEntry 136 }
dot11QMFActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
In an AP changes take effect for the next MLME-START.request primitive. In
a non-AP STA that is not associated and is not a member of an IBSS,
changes take effect as soon as practical in the implementation. In a non-
AP STA that is associated, changes take effect at the end of the lifetime
of the association. For a STA that is a member of an IBSS, changes take
effect for the next MLME-START.request primitive or MLME-JOIN.request
primitive.
This attribute indicates whether the entity is QMF enabled or disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 137 }
dot11QMFReconfigurationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
2814
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
The purpose of dot11QMFReconfigurationActivated is to allow an SME to
accept a QMF Policy Change request from another STA and respond with a QMF
Policy frame."
DEFVAL { false }
::= { dot11StationConfigEntry 138 }
dot11QMFPolicyChangeTimeout OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum number of TUs that a STA waits to
receive a response to a QMF Policy Change request before declaring that
the request has failed and also the number of TUs that a STA waits after
it has received a rejection to a QMF Policy Change request before issuing
a repeat QMF Policy Change request to the same destination STA."
DEFVAL { 5000 }
::= { dot11StationConfigEntry 139 }
dot11RobustAVStreamingImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation
supports robust AV streaming."
DEFVAL { false }
::= { dot11StationConfigEntry 140 }
dot11VHTOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates whether the entity is VHT Capable."
::= { dot11StationConfigEntry 141}
dot11OperatingModeNotificationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates whether the entity is Operating Mode Notification
Capable."
::= { dot11StationConfigEntry 142}
dot11TVHTOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
2815
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates whether the entity is TVHT Capable."
::= { dot11StationConfigEntry 143}
dot11MultibandImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Multiband Support Activated
This attribute, when true, indicates that the STA is capable of operating
in multiple bands. Otherwise, it is false. The default value of this
attribute is false."
DEFVAL { false }
::= { dot11StationConfigEntry 144 }
dot11ChannelScheduleManagementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when the device is initialized for
operation in a band defined by an Operating Class.
This attribute, when true, indicates that the STA implementation is
capable of supporting Channel Schedule Management Announcement. The
capability is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 145 }
dot11ContactVerificationSignalActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive
primitive.
This attribute, when true, indicates that the system capability for
contact verification signal is activated. false indicates that the STA has
contact verification signal capability, but it is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 146 }
dot11ContactVerificationSignalInterval OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
dot11ContactVerificationSignalInterval indicates the maximum number of
seconds that a GDD dependent STA may receive the Contact Verification
Signal frame. Unless another value is mandated by regulatory authorities,
2816
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the value is 60 seconds."
DEFVAL { 60 }
::= { dot11StationConfigEntry 147 }
dot11NetworkChannelControlActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when the device is initialized for
operation in a band defined by an Operating Class.
This attribute, when true, indicates that the STA implementation is
capable of supporting network channel control. The capability is disabled,
otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 148 }
dot11RLSSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as possible in the device.
This attribute, when true, indicates that the RLQP capability is
activated. The capability is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 149 }
dot11WhiteSpaceMapActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request
primitive or MLME-JOIN.request primitive.
This attribute, when true, indicates that the STA capability for white
space map is activated. false indicates the STA has no white space map
capability or that the capability is present but is disabled."
DEFVAL { false }
::= { dot11StationConfigEntry 150 }
dot11WSSTAType OBJECT-TYPE
SYNTAX INTEGER {gddap(1), gddnonapsta(2), gddfixedsta(3), reserved(4)}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when the device is initialized for operation in a
band that requires Geolocation Database Control.
This attribute specifies the type of STA mode for the purpose of channel
availability query requirements. This value is used to set the desired
channel availability query request parameters in using GAS frames carrying
Channel Availability Query element of RLQP. When set to gddap, the STA
indicates that it operates as a personal/portable AP STA after channel
availability query.
2817
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When set to gddnonapsta, the STA indicates that it operates as a personal/
portable non-AP STA after channel availability query. When set to
gddfixedsta, the STA indicates that it operates as a fixed STA after
channel availability query. When set to any other values, its use is
reserved, and remains unspecified."
::= { dot11StationConfigEntry 151}
dot11GeolocationCapabilityActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the has obtained its device
location information in geospatial coordinates for its position using its
geolocation capability, as required for its device class, otherwise this
is false."
DEFVAL { false }
::= { dot11StationConfigEntry 152 }
dot11GDDActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when the device is initialized for operation in a
band that requires Geolocation Database Dependent behavior.
This attribute, when true, indicates that the STA capability for operation
with Geolocation Database Dependent behavior is activated. The capability
is disabled, otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 153 }
dot11GDDEnablementTimeLimit OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when the device is initialized.
Changes take effect as soon as practical in the implementation.
dot11GDDEnablementTimeLimit indicates the maximum number of seconds that a
GDD dependent STA may transmit in a frequency band under the control of a
geolocation database while attaining GDD enablement with a GDD enabling
STA. Unless another value is mandated by regulatory authorities, the value
is 32 seconds."
DEFVAL { 32 }
::= { dot11StationConfigEntry 155 }
dot11GDDEnablementFailHoldTime OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when the device is initialized.
Changes take effect as soon as practical in the implementation.
2818
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11GDDEnablementFailHoldTime indicates the number of seconds that a GDD
dependent STA shall not transmit in a frequency band under control of a
geolocation database when it fails to attain GDD enablement with an GDD
enabling STA within dot11GDDEnablementTimeLimit seconds. Unless another
value is mandated by regulatory authorities, the value is 512 seconds."
DEFVAL { 512 }
::= { dot11StationConfigEntry 156 }
dot11GDDEnablementValidityTimer OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when the device is initialized.
Changes take effect as soon as practical in the implementation.
dot11GDDEnablementValidityTimer indicates the number of seconds that a GDD
dependent STA remains in GDDEnabled state. Unless another value is
mandated by regulatory authorities, the value is 60 seconds."
DEFVAL { 60 }
::= { dot11StationConfigEntry 157 }
dot11MaxMSDULength OBJECT-TYPE
SYNTAX INTEGER { normal(2304), long(7920) }
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum supported MSDU size.
This is 7920 octets for a DMG STA and 2304 octets for a non-DMG STA."
::= { dot11StationConfigEntry 162 }
dot11DynamicEIFSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute indicates whether the entity uses a dynamic value for EIFS
based on properties of the PPDU that causes the EIFS, or a fixed value."
::= { dot11StationConfigEntry 158 }
dot11ExtendedSpectrumManagementImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the non-VHT station
implementation is capable of supporting extended spectrum management. The
capability is disabled at the non-VHT station otherwise."
DEFVAL { false }
::= { dot11StationConfigEntry 161 }
2819
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11EstimatedServiceParametersOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the IEEE 802.11 Estimated
Service Parameters option is implemented."
DEFVAL { false }
::= { dot11StationConfigEntry 163 }
dot11VHTExtendedNSSBWCapable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the VHT extended NSS BW support
option is implemented. dot11VHTExtendedNSSBWCapable might be false when
dot11VHTOptionImplemented is false."
DEFVAL { false }
::= { dot11StationConfigEntry 165 }
dot11FutureChannelGuidanceActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes
take effect as soon as practical in the implementation.
This attribute, when true, indicates the capability of the STA to support
Future channel guidance procedures is enabled. The capability is disabled
otherwise."
DEFVAL {false}
::= { dot11StationConfigEntry 166 }
-- **********************************************************************
-- * End of dot11StationConfig TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11AuthenticationAlgorithms TABLE
-- **********************************************************************
dot11AuthenticationAlgorithmsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11AuthenticationAlgorithmsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This (conceptual) table of attributes is a set of all of the
authentication algorithms and whether they are activated."
REFERENCE
"IEEE Std 802.11-2016, 9.4.1.1"
::= { dot11smt 2 }
dot11AuthenticationAlgorithmsEntry OBJECT-TYPE
SYNTAX Dot11AuthenticationAlgorithmsEntry
MAX-ACCESS not-accessible
STATUS current
2820
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"An Entry (conceptual row) in the Authentication Algorithms Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex,
dot11AuthenticationAlgorithmIndex}
::= { dot11AuthenticationAlgorithmsTable 1 }
Dot11AuthenticationAlgorithmsEntry ::=
SEQUENCE {
dot11AuthenticationAlgorithmIndex Unsigned32,
dot11AuthenticationAlgorithm INTEGER,
dot11AuthenticationAlgorithmActivated TruthValue }
dot11AuthenticationAlgorithmIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the Authentication Algorithms Table."
::= { dot11AuthenticationAlgorithmsEntry 1 }
dot11AuthenticationAlgorithm OBJECT-TYPE
SYNTAX INTEGER {
openSystem(1),
sharedKey(2),
fastBSSTransition(3),
simultaneousAuthEquals(4) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute is the authentication algorithm described by this entry in
the table. The following values can be used here
Value = 1: Open system
Value = 2: Shared key
Value = 3: Fast BSS transition (FT)
Value = 4: Simultaneous authentication of equals (SAE)
A given value shall not be used more than once."
::= { dot11AuthenticationAlgorithmsEntry 2 }
dot11AuthenticationAlgorithmActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, enables the acceptance of the authentication
algorithm described in the corresponding table entry in authentication
frames received that have odd authentication transactions sequence
numbers. The default value of this attribute is true when the value of
dot11AuthenticationAlgorithm is openSystem and false otherwise."
::= { dot11AuthenticationAlgorithmsEntry 3 }
-- **********************************************************************
-- * End of dot11AuthenticationAlgorithms TABLE
2821
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- **********************************************************************
-- **********************************************************************
-- * dot11WEPDefaultKeys TABLE
-- **********************************************************************
dot11WEPDefaultKeysTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WEPDefaultKeysEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Conceptual table for WEP default keys. This table contains the four WEP
default secret key values corresponding to the four possible Key ID
values. The WEP default secret keys are logically WRITE-ONLY. Attempts to
read the entries in this table return unsuccessful status and values of
null or 0. The default value of each WEP default key is null."
REFERENCE "IEEE Std 802.11-2016, 12.3.2"
::= { dot11smt 3 }
dot11WEPDefaultKeysEntry OBJECT-TYPE
SYNTAX Dot11WEPDefaultKeysEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the WEP Default Keys Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11WEPDefaultKeyIndex }
::= { dot11WEPDefaultKeysTable 1 }
Dot11WEPDefaultKeysEntry ::=
SEQUENCE {
dot11WEPDefaultKeyIndex Unsigned32,
dot11WEPDefaultKeyValue WEPKeytype }
dot11WEPDefaultKeyIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the WEP Default Keys Table. The value of this variable is equal to the
WEPDefaultKeyID + 1"
::= { dot11WEPDefaultKeysEntry 1 }
dot11WEPDefaultKeyValue OBJECT-TYPE
SYNTAX WEPKeytype
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
A WEP default secret key value."
::= { dot11WEPDefaultKeysEntry 2 }
-- **********************************************************************
-- * End of dot11WEPDefaultKeys TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11WEPKeyMappings TABLE
2822
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- **********************************************************************
dot11WEPKeyMappingsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WEPKeyMappingsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Conceptual table for WEP Key Mappings. The MIB supports the ability to
share a separate WEP key for each RA/TA pair. The Key Mappings Table
contains zero or one entry for each MAC address and contains two fields
for each entry: WEPOn and the corresponding WEP key. The WEP key mappings
are logically WRITE-ONLY. Attempts to read the entries in this table
return unsuccessful status and values of null or 0. The default value for
all WEPOn fields is false."
REFERENCE "IEEE Std 802.11-2016, 12.3.2"
::= { dot11smt 4 }
dot11WEPKeyMappingsEntry OBJECT-TYPE
SYNTAX Dot11WEPKeyMappingsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the WEP Key Mappings Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11WEPKeyMappingIndex }
::= { dot11WEPKeyMappingsTable 1 }
Dot11WEPKeyMappingsEntry ::=
SEQUENCE {
dot11WEPKeyMappingIndex Unsigned32,
dot11WEPKeyMappingAddress MacAddress,
dot11WEPKeyMappingWEPOn TruthValue,
dot11WEPKeyMappingValue WEPKeytype,
dot11WEPKeyMappingStatus RowStatus }
dot11WEPKeyMappingIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the WEP Key Mappings Table."
::= { dot11WEPKeyMappingsEntry 1 }
dot11WEPKeyMappingAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The MAC address of the STA for which the values from this key mapping
entry are to be used."
::= { dot11WEPKeyMappingsEntry 2 }
dot11WEPKeyMappingWEPOn OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Boolean as to whether WEP is to be used when communicating with the
dot11WEPKeyMappingAddress STA."
::= { dot11WEPKeyMappingsEntry 3 }
2823
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WEPKeyMappingValue OBJECT-TYPE
SYNTAX WEPKeytype
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A WEP secret key value."
::= { dot11WEPKeyMappingsEntry 4 }
dot11WEPKeyMappingStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status column used for creating, modifying, and deleting instances of
the columnar objects in the WEP key mapping Table."
DEFVAL { active }
::= { dot11WEPKeyMappingsEntry 5 }
-- **********************************************************************
-- * End of dot11WEPKeyMappings TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11Privacy TABLE
-- **********************************************************************
dot11PrivacyTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PrivacyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group containing attributes concerned with IEEE 802.11 Privacy. Created
as a table to allow multiple instantiations on an agent."
::= { dot11smt 5 }
dot11PrivacyEntry OBJECT-TYPE
SYNTAX Dot11PrivacyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PrivacyTable Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11PrivacyTable 1 }
Dot11PrivacyEntry ::=
SEQUENCE {
dot11PrivacyInvoked TruthValue,
dot11WEPDefaultKeyID Unsigned32,
dot11WEPKeyMappingLengthImplemented Unsigned32,
dot11ExcludeUnencrypted TruthValue,
dot11WEPICVErrorCount Counter32,
dot11WEPExcludedCount Counter32,
dot11RSNAActivated TruthValue,
dot11RSNAPreauthenticationActivated TruthValue }
dot11PrivacyInvoked OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
2824
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
When this attribute is true, it indicates that some level of security is
invoked for transmitting Data frames. For WEP-only clients, the security
mechanism used is WEP.
For RSNA-capable clients, an additional variable dot11RSNAActivated
indicates whether RSNA is enabled. If dot11RSNAActivated is false or the
MIB variable does not exist, the security mechanism invoked is WEP; if
dot11RSNAActivated is true, RSNA security mechanisms invoked are
configured in the dot11RSNAConfigTable."
DEFVAL { false }
::= { dot11PrivacyEntry 1 }
dot11WEPDefaultKeyID OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the use of the first, second, third, or fourth
element of the WEPDefaultKeys array when equal to values of zero, one,
two, or three."
REFERENCE "IEEE Std 802.11-2016, 12.3.2"
DEFVAL { 0 }
::= { dot11PrivacyEntry 2 }
dot11WEPKeyMappingLengthImplemented OBJECT-TYPE
SYNTAX Unsigned32 (10..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The maximum number of tuples that dot11WEPKeyMappings can hold."
REFERENCE "IEEE Std 802.11-2016, 12.3.2"
::= { dot11PrivacyEntry 3 }
dot11ExcludeUnencrypted OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
When this attribute is true, the STA does not indicate at the MAC service
interface received MSDUs that have the Protected Frame subfield of the
Frame Control field equal to 0. When this attribute is false, the STA may
accept MSDUs that have the Protected Frame subfield of the Frame Control
field equal to 0."
DEFVAL { false }
::= { dot11PrivacyEntry 4 }
dot11WEPICVErrorCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
2825
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a status variable.
It is written by the MAC when an ICV error is detected.
This counter increments when a frame is received with the Protected Frame
subfield of the Frame Control field equal to 1 and the value of the ICV as
received in the frame does not match the ICV value that is calculated for
the contents of the received frame. ICV errors for TKIP are not counted in
this variable but in dot11RSNAStatsTKIPICVErrors."
::= { dot11PrivacyEntry 5 }
dot11WEPExcludedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a bad frame is received.
This counter increments when a frame is received with the Protected Frame
subfield of the Frame Control field equal to 0 and the value of
dot11ExcludeUnencrypted causes that frame to be discarded."
::= { dot11PrivacyEntry 6 }
dot11RSNAActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
When this object is true, this indicates that RSNA is enabled on this
entity. Configuration variables for RSNA operation are found in the
dot11RSNAConfigTable.
This object requires that dot11PrivacyInvoked also be equal to true."
::= { dot11PrivacyEntry 7 }
dot11RSNAPreauthenticationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
When this object is true, this indicates that RSNA preauthentication is
enabled on this entity.
This object requires that dot11RSNAActivated also be equal to true."
::= { dot11PrivacyEntry 8 }
-- **********************************************************************
-- * End of dot11Privacy TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11SMTnotification Objects
-- **********************************************************************
2826
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11SMTnotification OBJECT IDENTIFIER ::= { dot11smt 6 }
dot11Disassociate NOTIFICATION-TYPE
OBJECTS { ifIndex, dot11DisassociateReason, dot11DisassociateStation }
STATUS current
DESCRIPTION
"The disassociate notification is sent when the STA sends a Disassociation
frame. The value of the notification includes the MAC address of the MAC
to which the Disassociation frame was sent and the reason for the
disassociation.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
::= { dot11SMTnotification 0 1 }
dot11Deauthenticate NOTIFICATION-TYPE
OBJECTS { ifIndex, dot11DeauthenticateReason, dot11DeauthenticateStation }
STATUS current
DESCRIPTION
"The deauthenticate notification is sent when the STA sends a
Deauthentication frame. The value of the notification includes the MAC
address of the MAC to which the Deauthentication frame was sent and the
reason for the deauthentication.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
::= { dot11SMTnotification 0 2 }
dot11AuthenticateFail NOTIFICATION-TYPE
OBJECTS {
ifIndex, dot11AuthenticateFailStatus, dot11AuthenticateFailStation }
STATUS current
DESCRIPTION
"The authenticate failure notification is sent when the STA sends an
Authentication frame with a status code other than SUCCESS. The value of
the notification includes the MAC address of the MAC to which the
Authentication frame was sent and the reason for the authentication
failure.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Inter-
face tables in this MIB module are indexed by ifIndex."
::= { dot11SMTnotification 0 3 }
dot11Associate NOTIFICATION-TYPE
OBJECTS { ifIndex, dot11AssociateStation, dot11AssociateID}
STATUS current
DESCRIPTION
"The associate notification is sent when the STA sends an Association
Response frame with a status code equal to SUCCESS. The value of the
notification includes the MAC address of the MAC to which the Association
Response frame was sent and the Association ID. ifIndex - Each IEEE 802.11
interface is represented by an ifEntry. Interface tables in this MIB
module are indexed by ifIndex."
::= { dot11SMTnotification 0 4 }
dot11AssociateFailed NOTIFICATION-TYPE
OBJECTS { ifIndex, dot11AssociateFailStatus, dot11AssociateFailStation }
STATUS current
DESCRIPTION
"The associate failed notification is sent when the STA sends an
Association Response frame with a status code other than SUCCESS. The
value of the notification includes the MAC address of the MAC to which the
Association Response frame was sent and the reason for the association
failure. ifIndex - Each IEEE 802.11 interface is represented by an
2827
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ifEntry. Interface tables in this MIB module are indexed by ifIndex."
::= { dot11SMTnotification 0 5 }
dot11Reassociate NOTIFICATION-TYPE
OBJECTS { ifIndex, dot11ReassociateStation, dot11ReassociateID}
STATUS current
DESCRIPTION
"The reassociate notification is sent when the STA sends a Reassociation
Response frame with a status code equal to SUCCESS. The value of the
notification includes the MAC address of the MAC to which the
Reassociation Response frame was sent and the Reassociation ID. ifIndex -
Each IEEE 802.11 interface is represented by an ifEntry. Interface tables
in this MIB module are indexed by ifIndex."
::= { dot11SMTnotification 0 6 }
dot11ReassociateFailed NOTIFICATION-TYPE
OBJECTS { ifIndex, dot11ReassociateFailStatus, dot11ReassociateStation }
STATUS current
DESCRIPTION
"The reassociate failed notification is sent when the STA sends a
Reassociation Response frame with a status code other than SUCCESS. The
value of the notification includes the MAC address of the MAC to which the
Reassociation Response frame was sent and the reason for the reassociation
failure. ifIndex - Each IEEE 802.11 interface is represented by an
ifEntry. Interface tables in this MIB module are indexed by ifIndex."
::= { dot11SMTnotification 0 7 }
-- **********************************************************************
-- * End of dot11SMTnotification Objects
-- **********************************************************************
-- **********************************************************************
-- * dot11MultiDomainCapability TABLE
-- **********************************************************************
dot11MultiDomainCapabilityTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11MultiDomainCapabilityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This (conceptual) table of attributes for cross-domain mobility."
::= { dot11smt 7 }
dot11MultiDomainCapabilityEntry OBJECT-TYPE
SYNTAX Dot11MultiDomainCapabilityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the Multiple Domain Capability Table.
IfIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB are indexed by ifIndex."
INDEX { ifIndex, dot11MultiDomainCapabilityIndex }
::= { dot11MultiDomainCapabilityTable 1 }
Dot11MultiDomainCapabilityEntry ::=
SEQUENCE {
dot11MultiDomainCapabilityIndex Unsigned32,
dot11FirstChannelNumber Unsigned32,
dot11NumberofChannels Unsigned32,
dot11MaximumTransmitPowerLevel Integer32 }
dot11MultiDomainCapabilityIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
2828
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the multidomain Capability Table."
::= { dot11MultiDomainCapabilityEntry 1 }
dot11FirstChannelNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the value of the lowest channel number in the
subband for the associated domain country string."
DEFVAL { 0 }
::= { dot11MultiDomainCapabilityEntry 2 }
dot11NumberofChannels OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the value of the total number of channels allowed
in the subband for the associated domain country string."
DEFVAL { 0 }
::= { dot11MultiDomainCapabilityEntry 3 }
dot11MaximumTransmitPowerLevel OBJECT-TYPE
SYNTAX Integer32
UNITS "dBm"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum transmit power allowed in the subband
for the associated domain country string."
DEFVAL { 0 }
::= { dot11MultiDomainCapabilityEntry 4 }
-- ********************************************************************
-- * End of dot11MultiDomainCapability TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11SpectrumManagement TABLE
-- ********************************************************************
dot11SpectrumManagementTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11SpectrumManagementEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"(Conceptual) table of attributes for spectrum management"
::= {dot11smt 8}
dot11SpectrumManagementEntry OBJECT-TYPE
2829
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Dot11SpectrumManagementEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the Spectrum Management Table.
IfIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB are indexed by ifIndex."
INDEX {ifIndex, dot11SpectrumManagementIndex}
::= { dot11SpectrumManagementTable 1 }
Dot11SpectrumManagementEntry ::=
SEQUENCE {
dot11SpectrumManagementIndex Unsigned32,
dot11ChannelSwitchTime Unsigned32,
dot11PowerCapabilityMaxImplemented Integer32,
dot11PowerCapabilityMinImplemented Integer32 }
dot11SpectrumManagementIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the Spectrum Management Table."
::= { dot11SpectrumManagementEntry 1 }
-- value 2 is reserved
dot11ChannelSwitchTime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates assumed channel switch time. The minimum value of
this attribute is 1 TU."
DEFVAL { 2 }
::= { dot11SpectrumManagementEntry 3 }
dot11PowerCapabilityMaxImplemented OBJECT-TYPE
SYNTAX Integer32
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum transmit Power Capability of this
station."
DEFVAL { 0 }
::= { dot11SpectrumManagementEntry 4 }
dot11PowerCapabilityMinImplemented OBJECT-TYPE
SYNTAX Integer32
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
2830
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the minimum transmit Power Capability of this
station."
DEFVAL { -100 }
::= { dot11SpectrumManagementEntry 5 }
-- ******************************************************************
-- * End of dot11SpectrumManagement TABLE
-- ******************************************************************
-- ********************************************************************
-- * dot11RSNAConfig TABLE (RSNA and TSN)
-- ********************************************************************
dot11RSNAConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RSNAConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table containing RSNA configuration objects."
::= { dot11smt 9 }
dot11RSNAConfigEntry OBJECT-TYPE
SYNTAX Dot11RSNAConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11RSNAConfigTable."
INDEX { ifIndex }
::= { dot11RSNAConfigTable 1 }
Dot11RSNAConfigEntry ::=
SEQUENCE {
dot11RSNAConfigVersion Unsigned32,
dot11RSNAConfigPairwiseKeysImplemented Unsigned32,
dot11RSNAConfigGroupCipher OCTET STRING,
dot11RSNAConfigGroupRekeyMethod INTEGER,
dot11RSNAConfigGroupRekeyTime Unsigned32,
dot11RSNAConfigGroupRekeyPackets Unsigned32,
dot11RSNAConfigGroupRekeyStrict TruthValue,
dot11RSNAConfigPSKValue OCTET STRING,
dot11RSNAConfigPSKPassPhrase DisplayString,
dot11RSNAConfigGroupUpdateCount Unsigned32,
dot11RSNAConfigPairwiseUpdateCount Unsigned32,
dot11RSNAConfigGroupCipherSize Unsigned32,
dot11RSNAConfigPMKLifetime Unsigned32,
dot11RSNAConfigPMKReauthThreshold Unsigned32,
dot11RSNAConfigNumberOfPTKSAReplayCounters Unsigned32,
dot11RSNAConfigSATimeout Unsigned32,
dot11RSNAAuthenticationSuiteSelected OCTET STRING,
dot11RSNAPairwiseCipherSelected OCTET STRING,
dot11RSNAGroupCipherSelected OCTET STRING,
dot11RSNAPMKIDUsed OCTET STRING,
dot11RSNAAuthenticationSuiteRequested OCTET STRING,
dot11RSNAPairwiseCipherRequested OCTET STRING,
dot11RSNAGroupCipherRequested OCTET STRING,
dot11RSNATKIPCounterMeasuresInvoked Unsigned32,
dot11RSNA4WayHandshakeFailures Unsigned32,
dot11RSNAConfigNumberOfGTKSAReplayCounters Unsigned32,
dot11RSNAConfigSTKKeysImplemented Unsigned32,
dot11RSNAConfigSTKCipher OCTET STRING,
dot11RSNAConfigSTKRekeyTime Unsigned32,
2831
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RSNAConfigSMKUpdateCount Unsigned32,
dot11RSNAConfigSTKCipherSize Unsigned32,
dot11RSNAConfigSMKLifetime Unsigned32,
dot11RSNAConfigSMKReauthThreshold Unsigned32,
dot11RSNAConfigNumberOfSTKSAReplayCounters Unsigned32,
dot11RSNAPairwiseSTKSelected OCTET STRING,
dot11RSNASMKHandshakeFailures Unsigned32,
dot11RSNASAERetransPeriod Unsigned32,
dot11RSNASAEAntiCloggingThreshold Unsigned32,
dot11RSNASAESync Unsigned32 }
-- dot11RSNAConfigEntry 1 has been deprecated.
dot11RSNAConfigVersion OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The highest RSNA version this entity supports. See 9.4.2.9."
::= { dot11RSNAConfigEntry 2 }
dot11RSNAConfigPairwiseKeysImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This object indicates how many pairwise keys the entity supports for
RSNA."
::= { dot11RSNAConfigEntry 3 }
dot11RSNAConfigGroupCipher OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object indicates the group cipher suite selector the entity uses. The
group cipher suite in the RSNE takes its value from this variable. It
consists of an OUI or CID (the first 3 octets) and a cipher suite
identifier (the last octet)."
::= { dot11RSNAConfigEntry 4 }
dot11RSNAConfigGroupRekeyMethod OBJECT-TYPE
SYNTAX INTEGER { disabled(1), timeBased(2), packetBased(3),
timepacketBased(4) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object selects a mechanism for rekeying the RSNA GTK. The default is
time-based, once per day. Rekeying the GTK is applicable only to an entity
acting in the Authenticator role."
2832
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { timeBased }
::= { dot11RSNAConfigEntry 5 }
dot11RSNAConfigGroupRekeyTime OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The time after which the RSNA GTK is refreshed. The timer starts at the
moment the GTK was set using the MLME-SETKEYS.request primitive."
DEFVAL { 86400 } -- once per day
::= { dot11RSNAConfigEntry 6 }
dot11RSNAConfigGroupRekeyPackets OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "1000 packets"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
A packet count after which the RSNA GTK is refreshed. The packet counter
starts at the moment the GTK was set using the MLME-SETKEYS.request
primitive and it counts all packets encrypted using the current GTK."
::= { dot11RSNAConfigEntry 7 }
dot11RSNAConfigGroupRekeyStrict OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object signals that the GTK be refreshed whenever a STA leaves the
BSS that possesses the GTK."
::= { dot11RSNAConfigEntry 8 }
dot11RSNAConfigPSKValue OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(32))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The PSK for when RSNA in PSK mode is the selected AKM suite. In that case,
the PMK obtains its value from this object.
This object is logically write-only. Reading this variable returns
unsuccessful status or null or 0."
::= { dot11RSNAConfigEntry 9 }
dot11RSNAConfigPSKPassPhrase OBJECT-TYPE
SYNTAX DisplayString
2833
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The PSK, for when RSNA in PSK mode is the selected AKM suite, is
configured by dot11RSNAConfigPSKValue.
An alternative manner of setting the PSK uses the password-to-key
algorithm defined in J.4. This variable provides a means to enter a pass-
phrase. When this object is written, the RSNA entity uses the password-to-
key algorithm specified in J.4 to derive a preshared and populate
dot11RSNAConfigPSKValue with this key.
This object is logically write-only. Reading this variable returns
unsuccessful status or null or 0."
::= { dot11RSNAConfigEntry 10 }
-- dot11RSNAConfigEntry 11 and dot11RSNAConfigEntry 12 have been
-- deprecated.
dot11RSNAConfigGroupUpdateCount OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The number of times message 1 in the RSNA group key handshake is retried
per GTK handshake attempt."
DEFVAL { 3 }
::= { dot11RSNAConfigEntry 13 }
dot11RSNAConfigPairwiseUpdateCount OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The number of times message 1 and message 3 in the RSNA 4-way handshake
are retried per 4-way handshake attempt."
DEFVAL { 3 }
::= { dot11RSNAConfigEntry 14 }
dot11RSNAConfigGroupCipherSize OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
UNITS "bits"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object indicates the length of the group cipher key."
::= { dot11RSNAConfigEntry 15 }
dot11RSNAConfigPMKLifetime OBJECT-TYPE
2834
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Unsigned32 (1..4294967295)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The maximum lifetime of a PMK in the PMKSA cache."
DEFVAL { 43200 }
::= { dot11RSNAConfigEntry 16 }
dot11RSNAConfigPMKReauthThreshold OBJECT-TYPE
SYNTAX Unsigned32 (1..100)
UNITS "percentage"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The percentage of the PMK lifetime that should expire before an IEEE
802.1X reauthentication occurs."
DEFVAL { 70 }
::= { dot11RSNAConfigEntry 17 }
dot11RSNAConfigNumberOfPTKSAReplayCounters OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Specifies the number of PTKSA replay counters per association:
0 -> 1 replay counter,
1 -> 2 replay counters,
2 -> 4 replay counters,
3 -> 16 replay counters"
DEFVAL { 3 }
::= { dot11RSNAConfigEntry 18 }
dot11RSNAConfigSATimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The maximum time a security association takes to set up."
DEFVAL { 60 }
::= { dot11RSNAConfigEntry 19 }
dot11RSNAAuthenticationSuiteSelected OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
2835
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the RSNA Key Management in the SME when a security
association is established.
The selector of the last AKM suite negotiated."
::= { dot11RSNAConfigEntry 20 }
dot11RSNAPairwiseCipherSelected OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when a security
association is established.
The selector of the last pairwise cipher negotiated."
::= { dot11RSNAConfigEntry 21 }
dot11RSNAGroupCipherSelected OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when a security
association is established.
The selector of the last group cipher negotiated."
::= { dot11RSNAConfigEntry 22 }
dot11RSNAPMKIDUsed OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when a security
association is established.
The selector of the last PMKID used in the last 4-way handshake."
::= { dot11RSNAConfigEntry 23 }
dot11RSNAAuthenticationSuiteRequested OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when a security
association is established.
The selector of the last AKM suite requested."
::= { dot11RSNAConfigEntry 24 }
dot11RSNAPairwiseCipherRequested OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when a security
association is established.
The selector of the last pairwise cipher requested."
2836
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11RSNAConfigEntry 25 }
dot11RSNAGroupCipherRequested OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when a security
association is established.
The selector of the last group cipher requested."
::= { dot11RSNAConfigEntry 26 }
dot11RSNATKIPCounterMeasuresInvoked OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
Counts the number of times that a TKIP MIC failure occurred two times
within 60 s and TKIP countermeasures were invoked. This attribute counts
both local and remote MIC failure events reported to this STA. It
increments every time TKIP countermeasures are invoked"
::= { dot11RSNAConfigEntry 27 }
dot11RSNA4WayHandshakeFailures OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when the condition
described below occurs.
Counts the number of 4-way handshake failures."
::= { dot11RSNAConfigEntry 28 }
dot11RSNAConfigNumberOfGTKSAReplayCounters OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Specifies the number of GTKSA replay counters per association:
0 -> 1 replay counter,
1 -> 2 replay counters,
2 -> 4 replay counters,
3 -> 16 replay counters"
DEFVAL { 3 }
::= { dot11RSNAConfigEntry 29 }
dot11RSNAConfigSTKKeysImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
2837
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This object indicates how many STKs the entity supports for RSNA."
::= { dot11RSNAConfigEntry 30 }
dot11RSNAConfigSTKCipher OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object specifies the ciphersuite used by the STK for a DLS link."
::= { dot11RSNAConfigEntry 31}
dot11RSNAConfigSTKRekeyTime OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The time after which an RSNA STK is refreshed. The timer starts at the
moment the STK was set using the MLME-SETKEYS.request primitive."
DEFVAL { 86400 } -- once per day
::= { dot11RSNAConfigEntry 32 }
dot11RSNAConfigSMKUpdateCount OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The number of times message 1 in the RSNA SMK handshake is retried per SMK
handshake attempt."
DEFVAL { 3 }
::= { dot11RSNAConfigEntry 33 }
dot11RSNAConfigSTKCipherSize OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
UNITS "bits"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object indicates the length of the STK cipher key."
::= { dot11RSNAConfigEntry 34 }
dot11RSNAConfigSMKLifetime OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "seconds"
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"Deprecated because mechanisms for use of cached SMKSAs are not defined.
2838
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The maximum lifetime of an SMK in the SMKSA cache."
DEFVAL { 43200 }
::= { dot11RSNAConfigEntry 35 }
dot11RSNAConfigSMKReauthThreshold OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"Deprecated because mechanisms for use of cached SMKSAs are not defined.
This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the number of seconds for which an SMK
authentication is valid. If a new SMK authentication is not completed
successfully before the number of seconds indicated by this attribute
elapse, from the prior authentication, the STA deletes the SMKSA."
::= { dot11RSNAConfigEntry 36 }
dot11RSNAConfigNumberOfSTKSAReplayCounters OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Specifies the number of STKSA replay counters per association:
0 -> 1 replay counter,
1 -> 2 replay counters,
2 -> 4 replay counters,
3 -> 16 replay counters"
DEFVAL { 3 }
::= { dot11RSNAConfigEntry 37 }
dot11RSNAPairwiseSTKSelected OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when a security
association is established.
The selector of the last STK cipher negotiated."
::= { dot11RSNAConfigEntry 38 }
dot11RSNASMKHandshakeFailures OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME when the condition
described below occurs.
Counts the number of SMK handshake failures."
::= { dot11RSNAConfigEntry 39 }
2839
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RSNASAERetransPeriod OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when establishing or becoming a member of a BSS.
Changes take effect for the next MLME-START.request primitive.
This object specifies the initial retry timeout, in millisecond units,
used by the SAE authentication and key establishment protocol."
DEFVAL { 40 }
::= { dot11RSNAConfigEntry 40 }
dot11RSNASAEAntiCloggingThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This object specifies the maximum number of SAE protocol instances allowed
to simultaneously be in either Commit or Confirmed state."
DEFVAL { 5 }
::= { dot11RSNAConfigEntry 41 }
dot11RSNASAESync OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This object specifies the maximum number of synchronization errors that
are allowed to happen prior to disassociation of the offending SAE peer."
DEFVAL { 5 }
::= { dot11RSNAConfigEntry 42 }
-- ********************************************************************
-- * End of dot11RSNAConfig TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11RSNAConfigPairwiseCiphers TABLE
-- ********************************************************************
dot11RSNAConfigPairwiseCiphersTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RSNAConfigPairwiseCiphersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the pairwise ciphers supported by this entity. It allows
enabling and disabling of each pairwise cipher by network management. The
pairwise cipher suite list in the RSNE is formed using the information in
this table."
::= { dot11smt 10 }
dot11RSNAConfigPairwiseCiphersEntry OBJECT-TYPE
SYNTAX Dot11RSNAConfigPairwiseCiphersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
2840
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"The table entry, indexed by the interface index (or all interfaces) and
the pairwise cipher."
INDEX { ifIndex, dot11RSNAConfigPairwiseCipherIndex }
::= { dot11RSNAConfigPairwiseCiphersTable 1 }
Dot11RSNAConfigPairwiseCiphersEntry ::=
SEQUENCE {
dot11RSNAConfigPairwiseCipherIndex Unsigned32,
dot11RSNAConfigPairwiseCipherImplemented OCTET STRING,
dot11RSNAConfigPairwiseCipherActivated TruthValue,
dot11RSNAConfigPairwiseCipherSizeImplemented Unsigned32 }
dot11RSNAConfigPairwiseCipherIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary index into the dot11RSNAConfigPairwiseCiphersTable."
::= { dot11RSNAConfigPairwiseCiphersEntry 1 }
dot11RSNAConfigPairwiseCipherImplemented OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The selector of a supported pairwise cipher. It consists of an OUI or CID
(the first 3 octets) and a cipher suite identifier (the last octet)."
::= { dot11RSNAConfigPairwiseCiphersEntry 2 }
dot11RSNAConfigPairwiseCipherActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object enables or disables the pairwise cipher."
::= { dot11RSNAConfigPairwiseCiphersEntry 3 }
dot11RSNAConfigPairwiseCipherSizeImplemented OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
UNITS "bits"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This object indicates the length of the pairwise cipher key. This should
be 256 for TKIP and 128 or 256 for CCMP and 128 or 256 for GCMP."
::= { dot11RSNAConfigPairwiseCiphersEntry 4 }
-- ********************************************************************
-- * End of dot11RSNAConfigPairwiseCiphers TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11RSNAConfigAuthenticationSuites TABLE
-- ********************************************************************
2841
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RSNAConfigAuthenticationSuitesTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RSNAConfigAuthenticationSuitesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the AKM suites supported by this entity. Each AKM suite
can be individually enabled and disabled. The AKM suite list in the RSNE
is formed using the information in this table."
::= { dot11smt 11 }
dot11RSNAConfigAuthenticationSuitesEntry OBJECT-TYPE
SYNTAX Dot11RSNAConfigAuthenticationSuitesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (row) in the dot11RSNAConfigAuthenticationSuitesTable."
INDEX { dot11RSNAConfigAuthenticationSuiteIndex }
::= { dot11RSNAConfigAuthenticationSuitesTable 1 }
Dot11RSNAConfigAuthenticationSuitesEntry ::=
SEQUENCE {
dot11RSNAConfigAuthenticationSuiteIndex Unsigned32,
dot11RSNAConfigAuthenticationSuiteImplemented OCTET STRING,
dot11RSNAConfigAuthenticationSuiteActivated TruthValue }
dot11RSNAConfigAuthenticationSuiteIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used as an index into the dot11RSNAConfigAuthenti-
cationSuitesTable."
::= { dot11RSNAConfigAuthenticationSuitesEntry 1 }
dot11RSNAConfigAuthenticationSuiteImplemented OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The selector of an AKM suite. It consists of an OUI or CID (the first 3
octets) and a cipher suite identifier (the last octet)."
::= { dot11RSNAConfigAuthenticationSuitesEntry 2 }
dot11RSNAConfigAuthenticationSuiteActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This variable indicates whether the corresponding AKM suite is enabled/
disabled."
::= { dot11RSNAConfigAuthenticationSuitesEntry 3 }
-- ********************************************************************
-- * End of dot11RSNAConfigAuthenticationSuites TABLE
-- ********************************************************************
-- ********************************************************************
2842
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- * dot11RSNAStats TABLE
-- ********************************************************************
dot11RSNAStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RSNAStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table maintains per-STA statistics in an RSN. The entry with
dot11RSNAStatsSTAAddress equal to FF-FF-FF-FF-FF-FF contains statistics
for group addressed traffic."
::= { dot11smt 12 }
dot11RSNAStatsEntry OBJECT-TYPE
SYNTAX Dot11RSNAStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11RSNAStatsTable."
INDEX { ifIndex, dot11RSNAStatsIndex }
::= { dot11RSNAStatsTable 1 }
Dot11RSNAStatsEntry ::=
SEQUENCE {
dot11RSNAStatsIndex Unsigned32,
dot11RSNAStatsSTAAddress MacAddress,
dot11RSNAStatsVersion Unsigned32,
dot11RSNAStatsSelectedPairwiseCipher OCTET STRING,
dot11RSNAStatsTKIPICVErrors Counter32,
dot11RSNAStatsTKIPLocalMICFailures Counter32,
dot11RSNAStatsTKIPRemoteMICFailures Counter32,
dot11RSNAStatsCCMPReplays Counter32,
dot11RSNAStatsCCMPDecryptErrors Counter32,
dot11RSNAStatsTKIPReplays Counter32,
dot11RSNAStatsCMACReplays Counter32,
dot11RSNAStatsRobustMgmtCCMPReplays Counter32,
dot11RSNAStatsBIPMICErrors Counter32 }
dot11RSNAStatsIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An auxiliary index into the dot11RSNAStatsTable."
::= { dot11RSNAStatsEntry 1 }
dot11RSNAStatsSTAAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME.
The MAC address of the STA to which the statistics in this conceptual row
belong."
::= { dot11RSNAStatsEntry 2 }
dot11RSNAStatsVersion OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
2843
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the RSNA Key Management in the SME.
The RSNA version with which the STA associated."
::= { dot11RSNAStatsEntry 3 }
dot11RSNAStatsSelectedPairwiseCipher OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the RSNA Key Management in the SME.
The pairwise cipher suite Selector (as defined in 9.4.2.25.2) used during
association, in transmission order."
::= { dot11RSNAStatsEntry 4 }
dot11RSNAStatsTKIPICVErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
Counts the number of TKIP ICV errors encountered when decrypting packets
for the STA."
::= { dot11RSNAStatsEntry 5 }
dot11RSNAStatsTKIPLocalMICFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
Counts the number of MIC failures encountered when checking the integrity
of packets received from the STA at this entity."
::= { dot11RSNAStatsEntry 6 }
dot11RSNAStatsTKIPRemoteMICFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
Counts the number of MIC failures encountered by the STA identified by
dot11StatsSTAAddress and reported back to this entity."
::= { dot11RSNAStatsEntry 7 }
dot11RSNAStatsCCMPReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
The number of received CCMP MPDUs discarded by the replay mechanism."
::= { dot11RSNAStatsEntry 8 }
2844
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RSNAStatsCCMPDecryptErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
The number of received MPDUs discarded by the CCMP decryption algorithm."
::= { dot11RSNAStatsEntry 9 }
dot11RSNAStatsTKIPReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
Counts the number of TKIP replay errors detected."
::= { dot11RSNAStatsEntry 10 }
dot11RSNAStatsCMACReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
The number of received MPDUs discarded by the CMAC replay errors."
::= { dot11RSNAStatsEntry 12 }
dot11RSNAStatsRobustMgmtCCMPReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
The number of received robust Management frames discarded due to CCMP
replay errors"
::= {dot11RSNAStatsEntry 13}
dot11RSNAStatsBIPMICErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
The number of received MMPDUs discarded due to BIP MIC errors"
::= {dot11RSNAStatsEntry 14}
-- ********************************************************************
-- * End of dot11RSNAStats TABLE
-- ********************************************************************
-- **********************************************************************
-- * dot11OperatingClasses TABLE
-- **********************************************************************
dot11OperatingClassesTable OBJECT-TYPE
2845
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX SEQUENCE OF Dot11OperatingClassesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"(Conceptual) table of attributes for operating classes"
::= {dot11smt 13}
dot11OperatingClassesEntry OBJECT-TYPE
SYNTAX Dot11OperatingClassesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the Operating Classes Table.
IfIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB are indexed by ifIndex."
INDEX {ifIndex, dot11OperatingClassesIndex}
::= { dot11OperatingClassesTable 1 }
Dot11OperatingClassesEntry ::=
SEQUENCE {
dot11OperatingClassesIndex Unsigned32,
dot11OperatingClass Unsigned32,
dot11CoverageClass Unsigned32 }
dot11OperatingClassesIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the Operating Classes Table."
::= { dot11OperatingClassesEntry 1 }
dot11OperatingClass OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity when the device is
initialized.
This attribute indicates the operating class to be used."
DEFVAL { 0 }
::= { dot11OperatingClassesEntry 2 }
dot11CoverageClass OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity when the device is
initialized.
This attribute indicates the coverage class to be used."
DEFVAL { 0 }
::= { dot11OperatingClassesEntry 3 }
-- ********************************************************************
-- * End of dot11OperatingClasses TABLE
-- ********************************************************************
-- **********************************************************************
2846
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- * dot11BeaconRssi TABLE
-- **********************************************************************
dot11BeaconRssiTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11BeaconRssiEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"(Conceptual) table of attributes for received Beacon RSSI."
::= {dot11smt 38}
dot11BeaconRssiEntry OBJECT-TYPE
SYNTAX Dot11BeaconRssiEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the received Beacon RSSI table."
INDEX { dot11BeaconRssiIndex }
::= { dot11BeaconRssiTable 1 }
Dot11BeaconRssiEntry ::=
SEQUENCE {
dot11BeaconRssiIndex Unsigned32,
dot11BeaconMACAddress MacAddress,
dot11BeaconRssi Unsigned32}
dot11BeaconRssiIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the received Beacon Rssi table."
::= { dot11BeaconRssiEntry 1 }
dot11BeaconMACAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by MAC upon receiving a Beacon frame.
This attribute indicates the MAC address of the AP from which the beacon
used for Beacon RSSI measurement was transmitted."
::= { dot11BeaconRssiEntry 2 }
dot11BeaconRssi OBJECT-TYPE
SYNTAX Integer32
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by MAC upon receiving a Beacon frame.
This attribute indicates the received signal strength of Beacon frames
received on the channel, averaged (in linear domain) over all active
receive chains. This may be time-averaged over recent history by a
vendor-specific smoothing function."
::= { dot11BeaconRssiEntry 3 }
-- ********************************************************************
-- * End of dot11BeaconRssi TABLE
-- ********************************************************************
2847
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
-- * dot11FastBSSTransitionConfig TABLE
-- ********************************************************************
dot11FastBSSTransitionConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11FastBSSTransitionConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table containing fast BSS transition configuration objects."
::= { dot11smt 15 }
dot11FastBSSTransitionConfigEntry OBJECT-TYPE
SYNTAX Dot11FastBSSTransitionConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11FastBSSTransitionConfigTable."
INDEX { ifIndex }
::= { dot11FastBSSTransitionConfigTable 1 }
Dot11FastBSSTransitionConfigEntry ::=
SEQUENCE {
dot11FastBSSTransitionActivated TruthValue,
dot11FTMobilityDomainID OCTET STRING,
dot11FTOverDSActivated TruthValue,
dot11FTResourceRequestSupported TruthValue,
dot11FTR0KeyHolderID OCTET STRING,
dot11FTR0KeyLifetime Unsigned32,
dot11FTR1KeyHolderID OCTET STRING,
dot11FTReassociationDeadline Unsigned32 }
dot11FastBSSTransitionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
When this object is true, this indicates that fast BSS transition (FT) is
enabled on this entity. The entity advertises the FT-related elements in
its Beacon and Probe Response frames. This object requires that dot11-
FastBSSTransitionImplemented also be equal to true."
::= { dot11FastBSSTransitionConfigEntry 1 }
dot11FTMobilityDomainID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the Mobility Domain identifier (MDID) of this
entity.
The MDID is used to indicate a group of APs, within an ESS, between which
a STA can use fast BSS transition services. Fast BSS transitions are
allowed only between APs that have the same MDID and are within the same
ESS. They are not allowed between APs with different MDIDs or in different
ESSs.
2848
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Since fast BSS transition services are defined only within the scope of an
ESS, there is no requirement that MDIDs be unique across ESSs."
::= { dot11FastBSSTransitionConfigEntry 2 }
dot11FTOverDSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
When this object is true, this indicates that fast BSS transition via the
over-the-DS protocol as described in Clause 13 is enabled on this AP
entity."
::= { dot11FastBSSTransitionConfigEntry 3 }
dot11FTResourceRequestSupported OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
When this object is true, this indicates that the fast BSS transition (FT)
resource request procedures of 13.10 are supported on this AP entity."
::= { dot11FastBSSTransitionConfigEntry 4 }
dot11FTR0KeyHolderID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..48))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the PMK-R0 key holder identifier (R0KH-ID) of the
Authenticator of this AP.
NOTE: Backend protocol might allow longer NAS Client identifiers (e.g.,
RADIUS allows up to 253-octet NAS-Identifier), but when used with fast BSS
transition, the maximum length is limited to 48 octets. Subclause 13.2.2
requires that the same value is used for the NAS Client identifier and
dot11FTR0KeyHolderID."
::= { dot11FastBSSTransitionConfigEntry 5 }
dot11FTR0KeyLifetime OBJECT-TYPE
SYNTAX Unsigned32 (60..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the default lifetime of the PMK-R0, in seconds,
when a Session-Timeout attribute is not provided during the EAP authenti-
cation. This attribute also applies when the PMK-R0 is derived from a
PSK."
DEFVAL { 1209600 }
2849
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11FastBSSTransitionConfigEntry 6 }
dot11FTR1KeyHolderID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(6))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the PMK-R1 key holder identifier (R1KH-ID) of the
Authenticator of this AP. It is equal to a MAC address of the entity hold-
ing the PMK-R1 in the Authenticator."
::= { dot11FastBSSTransitionConfigEntry 7 }
dot11FTReassociationDeadline OBJECT-TYPE
SYNTAX Unsigned32 (1000..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of TUs that this target AP entity
caches a PTKSA and reserves any specified resources for a STA while wait-
ing for a reassociation from that STA. It is assumed that this value is
administered consistently across the mobility domain."
DEFVAL { 1000 }
::= { dot11FastBSSTransitionConfigEntry 8 }
-- *********************************************************************
-- * End of dot11FastBSSTransitionConfig TABLE
-- *********************************************************************
-- ********************************************************************
-- * dot11LCIDSE TABLE
-- ********************************************************************
dot11LCIDSETable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11LCIDSEEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains conceptual table of attributes for Dependent Station
Enablement."
::= { dot11smt 16 }
dot11LCIDSEEntry OBJECT-TYPE
SYNTAX Dot11LCIDSEEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11LCIDSETable Indexed by dot11LCIDSEIndex."
INDEX { dot11LCIDSEIndex }
::= { dot11LCIDSETable 1 }
Dot11LCIDSEEntry ::=
SEQUENCE {
dot11LCIDSEIndex Unsigned32,
dot11LCIDSEIfIndex InterfaceIndex,
dot11LCIDSECurrentOperatingClass Unsigned32,
dot11LCIDSELatitudeUncertainty Unsigned32,
2850
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11LCIDSELatitudeInteger Integer32,
dot11LCIDSELatitudeFraction Integer32,
dot11LCIDSELongitudeUncertainty Unsigned32,
dot11LCIDSELongitudeInteger Integer32,
dot11LCIDSELongitudeFraction Integer32,
dot11LCIDSEAltitudeType INTEGER,
dot11LCIDSEAltitudeUncertainty Unsigned32,
dot11LCIDSEAltitude Integer32,
dot11LCIDSEDatum Unsigned32,
dot11RegLocAgreement TruthValue,
dot11RegLocDSE TruthValue,
dot11DependentSTA TruthValue,
dot11DependentEnablementIdentifier Unsigned32,
dot11DSEEnablementTimeLimit Unsigned32,
dot11DSEEnablementFailHoldTime Unsigned32,
dot11DSERenewalTime Unsigned32,
dot11DSETransmitDivisor Unsigned32 }
dot11LCIDSEIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for LCI DSE elements in dot11LCIDSETable, greater than 0."
::= { dot11LCIDSEEntry 1 }
dot11LCIDSEIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Each IEEE 802.11 interface is represented by an ifEntry. Interface Tables
in this MIB are indexed by ifIndex."
::= { dot11LCIDSEEntry 2 }
dot11LCIDSECurrentOperatingClass OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Current Operating Class is 8 bits indicating the particular Operating
Class in use by the radio."
::= { dot11LCIDSEEntry 3 }
dot11LCIDSELatitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Latitude uncertainty is defined in IETF RFC 6225."
::= { dot11LCIDSEEntry 4 }
dot11LCIDSELatitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-359..359)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
2851
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME when the device is initialized.
Latitude is represented as a 2s complement 34-bit fixed point value
consisting of 9 bits of integer and 25 bits of fraction. This field
contains the 9 bits of integer portion of the latitude."
::= { dot11LCIDSEEntry 5 }
dot11LCIDSELatitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Latitude is represented a 2s complement 34-bit fixed point value
consisting of 9 bits of integer and 25 bits of fraction. This field
contains the 25 bits of fraction portion of the latitude."
::= { dot11LCIDSEEntry 6 }
dot11LCIDSELongitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Longitude uncertainty is defined in IETF RFC 6225."
::= { dot11LCIDSEEntry 7 }
dot11LCIDSELongitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-359..359)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Longitude is represented a 2s complement 34-bit fixed point value
consisting of 9 bits of integer and 25 bits of fraction. This field
contains the 9 bits of integer portion of the longitude."
::= { dot11LCIDSEEntry 8 }
dot11LCIDSELongitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Longitude is represented a 2s complement 34-bit fixed point value
consisting of 9 bits of integer and 25 bits of fraction. This field
contains the 25 bits of fraction portion of the longitude."
::= { dot11LCIDSEEntry 9 }
dot11LCIDSEAltitudeType OBJECT-TYPE
SYNTAX INTEGER { meters(1), floors(2), hagm(3) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Altitude Type is 4 bits encoding the type of altitude.
Codes defined are:
2852
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
meters : in 2s complement fixed-point 22-bit integer part with 8-bit
fraction
floors : in 2s complement fixed-point 22-bit integer part with 8-bit
fraction
hagm : Height Above Ground in meters, in 2s complement fixed-point 22-bit
integer part with 8-bit fraction. "
DEFVAL { 3 }
::= { dot11LCIDSEEntry 10 }
dot11LCIDSEAltitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Altitude resolution is 6 bits indicating the number of valid bits in the
altitude."
::= { dot11LCIDSEEntry 11 }
dot11LCIDSEAltitude OBJECT-TYPE
SYNTAX Integer32 (-536870912..536870911)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Altitude is a 30-bit value defined by the Altitude type field. The field
is encoded as a 2s complement fixed-point 22-bit integer part with 8-bit
fraction."
::= { dot11LCIDSEEntry 12 }
-- reserved: 13. was dot11LCIDSEAltitudeFraction
dot11LCIDSEDatum OBJECT-TYPE
SYNTAX Unsigned32 (1..3)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
Datum is a 3-bit value encoding the horizontal and vertical references
used for the coordinates given in this LCI. IETF RFC 6225 defines the
values of Datum. Type 1 is WGS-84, the coordinate system used by GPS. Type
2 is NAD83 with NAVD88 vertical reference. Type 3 is NAD83 with Mean Lower
Low Water vertical datum. All other types are reserved."
DEFVAL { 1 }
::= { dot11LCIDSEEntry 14 }
dot11RegLocAgreement OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a DSE Enablement frame is received.
RegLocAgreement reports the Enabling STA's Agreement status. false
indicates it is operating away from national borders and outside national
policy zones. true indicates it is operating by agreement near national
borders or inside national policy zones."
2853
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { false }
::= { dot11LCIDSEEntry 15 }
dot11RegLocDSE OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a DSE Enablement frame is received.
RegLocDSE reports the Enabling STA's DSE status. false indicates Dependent
STAs are not enabled. true indicates Dependent STA operation is enabled."
DEFVAL { false }
::= { dot11LCIDSEEntry 16 }
dot11DependentSTA OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a DSE Enablement frame is received.
This attribute reports the Dependent STA status of the STA that sent the
Beacon or Probe Response frame(s) with this information. false indicates
that STA is not operating as a Dependent STA. true indicates that STA is
operating as a Dependent STA."
DEFVAL { true }
::= { dot11LCIDSEEntry 17 }
dot11DependentEnablementIdentifier OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a DSE Enablement frame is received.
This attribute reports the Dependent STA identifier assigned by the
enabling STA to the dependent station."
DEFVAL { 0 }
::= { dot11LCIDSEEntry 18 }
dot11DSEEnablementTimeLimit OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
dot11DSEEnablementTimeLimit indicates the maximum number of seconds that a
dependent STA may transmit in a DSE frequency band while attaining
enablement with an enabling STA. Unless another value is mandated by
regulatory authorities, the value is 32 seconds."
DEFVAL { 32 }
::= { dot11LCIDSEEntry 19 }
dot11DSEEnablementFailHoldTime OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
2854
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by the SME when the device is initialized.
dot11DSEEnablementFailHoldTime indicates the number of seconds that a
dependent STA must not transmit in a DSE frequency band when it fails to
attain enablement with an enabling STA within dot11DSEEnablementTimeLimit
seconds. Unless another value is mandated by regulatory authorities, the
value is 512 seconds."
DEFVAL { 512 }
::= { dot11LCIDSEEntry 20}
dot11DSERenewalTime OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
dot11DSERenewalTime indicates the maximum number of seconds that a
dependent STA may operate in a DSE frequency band without receiving and
decoding an enabling signal from its enabling STA. Unless another value is
mandated by regulatory authorities, the value is 60 seconds."
DEFVAL { 60 }
::= { dot11LCIDSEEntry 21}
dot11DSETransmitDivisor OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
dot11DSETransmitDivisor indicates the value used by a dependent STA when
operating in a DSE frequency band and transmitting. The dependent STA
sends an Action frame when the sum of dot11TransmittedFragmentCount,
dot11GroupTransmittedFrameCount and dot11ReceivedFragmentCount modulo
dot11DSETransmitDivisor equals 0. Unless another value is mandated by
regulatory authorities, the default value is 256."
DEFVAL { 256 }
::= { dot11LCIDSEEntry 22}
-- ********************************************************************
-- * End of dot11LCIDSE TABLE
-- ********************************************************************
-- **********************************************************************
-- * dot11HTStationConfig TABLE
-- **********************************************************************
dot11HTStationConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11HTStationConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Station Configuration attributes. In tabular form to allow for multiple
instances on an agent."
::= { dot11smt 17 }
dot11HTStationConfigEntry OBJECT-TYPE
SYNTAX Dot11HTStationConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
2855
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"An entry (conceptual row) in the dot11HTStationConfig Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11HTStationConfigTable 1 }
Dot11HTStationConfigEntry ::=
SEQUENCE {
dot11HTOperationalMCSSet OCTET STRING,
dot11MIMOPowerSave INTEGER,
dot11NDelayedBlockAckOptionImplemented TruthValue,
dot11MaxAMSDULength INTEGER,
dot11STBCControlFrameOptionImplemented TruthValue,
dot11LsigTxopProtectionOptionImplemented TruthValue,
dot11MaxRxAMPDUFactor Unsigned32,
dot11MinimumMPDUStartSpacing Unsigned32,
dot11PCOOptionImplemented TruthValue,
dot11TransitionTime Unsigned32,
dot11MCSFeedbackOptionImplemented INTEGER,
dot11HTControlFieldSupported TruthValue,
dot11RDResponderOptionImplemented TruthValue,
dot11SPPAMSDUCapable TruthValue,
dot11SPPAMSDURequired TruthValue,
dot11FortyMHzOptionImplemented TruthValue }
dot11HTOperationalMCSSet OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..127))
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"Deprecated as no longer used by IEEE Std 802.11-2016
This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute shall specify the set of MCS at which the station may
transmit data. Each octet contains a value representing a rate. Each MCS
shall be within the range 1 to 127, and shall be supported for receiving
data. This value is reported in transmitted Beacon, Probe Request, Probe
Response, Association Request, Association Response, Reassociation
Request, and Reassociation Response frames, and is used to determine
whether a BSS with which the station might synchronize is suitable. It is
also used when starting a BSS, as specified in 11.3."
::= { dot11HTStationConfigEntry 1 }
dot11MIMOPowerSave OBJECT-TYPE
SYNTAX INTEGER { static(1), dynamic(2), mimo(3) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY when the power save condition changes.
This is an 8-bit integer value that identifies the configured power save
state of MIMO."
::= { dot11HTStationConfigEntry 2 }
dot11NDelayedBlockAckOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
2856
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting the No Acknowledgment option of the delayed block
ack."
DEFVAL { false }
::= { dot11HTStationConfigEntry 3 }
dot11MaxAMSDULength OBJECT-TYPE
SYNTAX INTEGER { short(3839), long(7935) }
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum supported size of an A-MSDU."
::= { dot11HTStationConfigEntry 4 }
dot11STBCControlFrameOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of processing the received Control frames that are STBC frames."
DEFVAL { false }
::= { dot11HTStationConfigEntry 5 }
dot11LsigTxopProtectionOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting L-SIG TXOP protection option."
DEFVAL { false }
::= { dot11HTStationConfigEntry 6 }
dot11MaxRxAMPDUFactor OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum length of A-MPDU that the STA can
receive. The Maximum Rx A-MPDU defined by this field is equal to 2 **
(13+dot11MaxRxAMPDUFactor) -1 octets."
DEFVAL { 0 }
::= { dot11HTStationConfigEntry 7 }
dot11MinimumMPDUStartSpacing OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS read-only
2857
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the minimum time between the start of adjacent
MPDUs within an A-MPDU. This time is measured at the PHY SAP; the number
of octets between the start of two consecutive MPDUs in A-MPDU shall be
equal or greater than (dot11MinimumMPDUStartSpacing*PHY-bit-rate)/8. The
encoding of the minimum time to this attribute is:
0 - no restriction
1 - 1/4 microsecond
2 - 1/2 microsecond
3 - 1 microsecond
4 - 2 microseconds
5 - 4 microseconds
6 - 8 microseconds
7 - 16 microseconds"
DEFVAL { 0 }
::= { dot11HTStationConfigEntry 8 }
dot11PCOOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting PCO."
DEFVAL { false }
::= { dot11HTStationConfigEntry 9 }
dot11TransitionTime OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates that the maximum transition time within which the
STA can switch between 20 MHz channel width and 40 MHz channel width with
a high probability. The encoding of the transition time to this attribute
is:
0 - no transition
1 - 400 microseconds
2 - 1500 microseconds
3 - 5000 microseconds"
DEFVAL { 2 }
::= { dot11HTStationConfigEntry 10 }
dot11MCSFeedbackOptionImplemented OBJECT-TYPE
SYNTAX INTEGER { none(0), unsolicited (2), both (3) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the MCS feed back capability supported by the
station implementation."
DEFVAL { 0 }
2858
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11HTStationConfigEntry 11 }
dot11HTControlFieldSupported OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of receiving HT Control field."
DEFVAL { false }
::= { dot11HTStationConfigEntry 12 }
dot11RDResponderOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable operating as an RD responder."
DEFVAL { false }
::= { dot11HTStationConfigEntry 13 }
dot11SPPAMSDUCapable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA implementation is
capable of protecting the A-MSDU bit (Bit 7) in the QoS Control field when
dot11RSNAActivated is true."
DEFVAL { false }
::= { dot11HTStationConfigEntry 14 }
dot11SPPAMSDURequired OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the STA is configured to
disallow (i.e., not to send or receive) PP A-MSDUs when dot11RSNAActivated
is true."
DEFVAL { false }
::= { dot11HTStationConfigEntry 15 }
dot11FortyMHzOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
2859
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute, when true, indicates that the STA is capable of
transmitting and receiving on a 40 MHz channel using a 40 MHz mask."
DEFVAL { false }
::= { dot11HTStationConfigEntry 16 }
-- **********************************************************************
-- * End of dot11HTStationConfig TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11WirelessMgmtOptions TABLE
-- **********************************************************************
dot11WirelessMgmtOptionsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WirelessMgmtOptionsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Wireless Management attributes. In tabular form to allow for multiple
instances on an agent. This table only applies to the interface if
dot11WirelessManagementImplemented is equal to true in the
dot11StationConfigTable."
::= { dot11smt 18 }
dot11WirelessMgmtOptionsEntry OBJECT-TYPE
SYNTAX Dot11WirelessMgmtOptionsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WirelessMgmtOptionsTable. For all Wireless
Management features, an Activated MIB variable is used to activate/enable
or deactivate/disable the corresponding feature. An Implemented MIB
variable is used for an optional feature to indicate whether the feature
is implemented. A mandatory feature does not have a corresponding
Implemented MIB variable. It is possible for there to be multiple IEEE
802.11 interfaces on one agent, each with its unique MAC address. The
relationship between an IEEE 802.11 interface and an interface in the
context of the Internet-standard MIB is one-to-one. As such, the value of
an ifIndex object instance can be directly used to identify corresponding
instances of the objects defined herein. ifIndex - Each IEEE 802.11
interface is represented by an ifEntry. Interface tables in this MIB
module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11WirelessMgmtOptionsTable 1 }
Dot11WirelessMgmtOptionsEntry ::=
SEQUENCE {
dot11LocationActivated TruthValue,
dot11FMSImplemented TruthValue,
dot11FMSActivated TruthValue,
dot11EventsActivated TruthValue,
dot11DiagnosticsActivated TruthValue,
dot11MultiBSSIDImplemented TruthValue,
dot11MultiBSSIDActivated TruthValue,
dot11TFSImplemented TruthValue,
dot11TFSActivated TruthValue,
dot11WNMSleepModeImplemented TruthValue,
dot11WNMSleepModeActivated TruthValue,
dot11TIMBroadcastImplemented TruthValue,
dot11TIMBroadcastActivated TruthValue,
dot11ProxyARPImplemented TruthValue,
dot11ProxyARPActivated TruthValue,
dot11BSSTransitionImplemented TruthValue,
dot11BSSTransitionActivated TruthValue,
2860
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11QoSTrafficCapabilityImplemented TruthValue,
dot11QoSTrafficCapabilityActivated TruthValue,
dot11ACStationCountImplemented TruthValue,
dot11ACStationCountActivated TruthValue,
dot11CoLocIntfReportingImplemented TruthValue,
dot11CoLocIntfReportingActivated TruthValue,
dot11MotionDetectionImplemented TruthValue,
dot11MotionDetectionActivated TruthValue,
dot11TODImplemented TruthValue,
dot11TODActivated TruthValue,
dot11TimingMsmtImplemented TruthValue,
dot11TimingMsmtActivated TruthValue,
dot11ChannelUsageImplemented TruthValue,
dot11ChannelUsageActivated TruthValue,
dot11TriggerSTAStatisticsActivated TruthValue,
dot11SSIDListImplemented TruthValue,
dot11SSIDListActivated TruthValue,
dot11MulticastDiagnosticsActivated TruthValue,
dot11LocationTrackingImplemented TruthValue,
dot11LocationTrackingActivated TruthValue,
dot11DMSImplemented TruthValue,
dot11DMSActivated TruthValue,
dot11UAPSDCoexistenceImplemented TruthValue,
dot11UAPSDCoexistenceActivated TruthValue,
dot11WNMNotificationImplemented TruthValue,
dot11WNMNotificationActivated TruthValue,
dot11UTCTSFOffsetImplemented TruthValue,
dot11UTCTSFOffsetActivated TruthValue,
dot11FineTimingMsmtRespActivated TruthValue,
dot11FineTimingMsmtInitActivated TruthValue,
dot11LciCivicInNeighborReport TruthValue,
dot11RMFineTimingMsmtRangeRepImplemented TruthValue,
dot11RMFineTimingMsmtRangeRepActivated TruthValue,
dot11RMLCIConfigured TruthValue,
dot11RMCivicConfigured TruthValue
}
dot11LocationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide location is enabled. The capability is disabled, otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 1 }
dot11FMSImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting FMS when the dot11WirelessManagementImplemented is
equal to true."
2861
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11WirelessMgmtOptionsEntry 2 }
dot11FMSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide FMS is enabled. The capability is disabled, otherwise"
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 3 }
dot11EventsActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide Event Reporting is enabled. The capability is disabled, otherwise"
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 4 }
dot11DiagnosticsActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide Diagnostic Reporting is enabled. The capability is disabled,
otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 5 }
dot11MultiBSSIDImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting Multiple BSSID when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 6 }
dot11MultiBSSIDActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
2862
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide Multi BSSID is enabled. The capability is disabled, otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 7 }
dot11TFSImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting TFS when the dot11WirelessManagementImplemented is
equal to true."
::= { dot11WirelessMgmtOptionsEntry 8 }
dot11TFSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that TFS is enabled. TFS is disabled
otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 9 }
dot11WNMSleepModeImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting WNM sleep mode when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 10 }
dot11WNMSleepModeActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that WNM sleep mode is enabled. WNM
sleep mode is disabled otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 11 }
dot11TIMBroadcastImplemented OBJECT-TYPE
SYNTAX TruthValue
2863
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting TIM Broadcast when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 12}
dot11TIMBroadcastActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that TIM broadcast is enabled. TIM
broadcast is disabled otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 13}
dot11ProxyARPImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting the proxy ARP service, when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 14 }
dot11ProxyARPActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the AP to
provide the proxy ARP service is enabled. The capability is disabled,
otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 15 }
dot11BSSTransitionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This is a capability variable. Its value is determined by device
capabilities. This attribute, when true, indicates that the station
implementation is capable of supporting BSS transition management, when
2864
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 16 }
dot11BSSTransitionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide BSS transition is enabled. The capability is disabled, otherwise.
"
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 17 }
dot11QoSTrafficCapabilityImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting QoS traffic capability when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 18 }
dot11QoSTrafficCapabilityActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide QoS traffic capability is enabled. QoS traffic capability is
disabled otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 19 }
dot11ACStationCountImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting AC Station Count when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 20 }
dot11ACStationCountActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
2865
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide AC Station Count is enabled. AC Station Count is disabled
otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 21 }
dot11CoLocIntfReportingImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting Colocated Interference Reporting. The capability is
disabled, otherwise."
::= { dot11WirelessMgmtOptionsEntry 22 }
dot11CoLocIntfReportingActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
support Colocated Interference Reporting is enabled. The capability is
disabled, otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 23 }
dot11MotionDetectionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting motion detection when the
dot11WirelessManagementImplemented is equal to true. "
::= { dot11WirelessMgmtOptionsEntry 24 }
dot11MotionDetectionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability to support motion
detection is enabled."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 25 }
2866
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TODImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting Time Of Departure for Clause 15 transmitted frames,
Clause 17 transmitted frames, Clause 16 transmitted frames, Clause 18
transmitted frames and Clause 19 transmitted frames when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 26 }
dot11TODActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability to support Time
Of Departure frames for transmitted Clause 15, Clause 17, Clause 16,
Clause 18 and Clause 19 frames is enabled."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 27 }
dot11TimingMsmtImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting Timing Measurement capability when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 28 }
dot11TimingMsmtActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect at the next occurrence of an MLME-START.request or
MLME-JOIN.request primitive.
This attribute, when true, indicates that the station capability for
Timing Measurement is enabled. false indicates the station has no Timing
Measurement capability or that the capability is present but is disabled."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 29 }
dot11ChannelUsageImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
2867
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting Channel Usage when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 30 }
dot11ChannelUsageActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that Channel Usage is enabled.
Channel Usage is disabled otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 31 }
dot11TriggerSTAStatisticsActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide triggered STA statistics is enabled. The capability is disabled
otherwise"
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 32 }
dot11SSIDListImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting the SSID List capability when the
dot11WirelessManagementImplemented is true."
::= { dot11WirelessMgmtOptionsEntry 33 }
dot11SSIDListActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
support the SSID List capability is enabled. The capability is disabled,
otherwise"
DEFVAL { false}
2868
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11WirelessMgmtOptionsEntry 34 }
dot11MulticastDiagnosticsActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide multicast diagnostic reporting is enabled. The capability is
disabled, otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 35 }
dot11LocationTrackingImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting Location Track when the
dot11WirelessManagementImplemented is true."
::= { dot11WirelessMgmtOptionsEntry 36 }
dot11LocationTrackingActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide Location Track is enabled. The capability is disabled otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 37 }
dot11DMSImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting DMS when the dot11WirelessManagementImplemented is
true."
::= { dot11WirelessMgmtOptionsEntry 38 }
dot11DMSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
2869
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that DMS is enabled. DMS is disabled
otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 39 }
dot11UAPSDCoexistenceImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the Station implementation is
capable of supporting U-APSD coexistence when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 40}
dot11UAPSDCoexistenceActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that U-APSD coexistence is enabled.
U-APSD coexistence is disabled, otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 41}
dot11WNMNotificationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting WNM notification when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 42}
dot11WNMNotificationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the capability of the station to
provide WNM notification is enabled. The capability is disabled,
otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 43}
dot11UTCTSFOffsetImplemented OBJECT-TYPE
SYNTAX TruthValue
2870
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the Station implementation is
capable of supporting UTC TSF Offset advertisement when the
dot11WirelessManagementImplemented is equal to true."
::= { dot11WirelessMgmtOptionsEntry 44}
dot11UTCTSFOffsetActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that UTC TSF Offset advertisement is
enabled at the station. The capability is disabled, otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 45}
dot11FineTimingMsmtRespActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect at the next occurrence of an MLME-START.request or
MLME-JOIN.request primitive.
This attribute, when true, indicates that the station capability for Fine
Timing Measurement as a responder is enabled. false indicates the station
has no Fine Timing Measurement capability as a responder or that the
capability is present but is disabled."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 47 }
dot11LciCivicInNeighborReport OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the station includes LCI and
civic location subelements in the Neighbor Report without regard to either
dot11FineTimingMsmtRespActivated or dot11FineTimingMsmtInitActivated."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 48 }
dot11RMFineTimingMsmtRangeRepImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
2871
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting fine timing measurement range reporting."
::= { dot11WirelessMgmtOptionsEntry 49}
dot11RMFineTimingMsmtRangeRepActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that fine timing measurement range
reporting is enabled at the station. The capability is disabled,
otherwise."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 50}
dot11FineTimingMsmtInitActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect at the next occurrence of an MLME-START.request or
MLME-JOIN.request primitive.
This attribute, when true, indicates that the station capability for Fine
Timing Measurement as an initiator is enabled. false indicates the station
has no Fine Timing Measurement capability as an initiator or that the
capability is present but is disabled."
DEFVAL { false}
::= { dot11WirelessMgmtOptionsEntry 51 }
dot11RMLCIConfigured OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity which sets the Value to
true after it configures dot11STALCIEntry.
It is written by the STA when an external management entity configures
dot11STALCIEntry.
Changes take effect as soon as practical in the implementation. This
attribute, when true, indicates that that the station is configured with
an LCI location (LCI is not Unknown). false indicates the station is not
configured with an LCI location or the configured LCI Location is set to
Unknown (as defined in 9.4.2.22.10)."
DEFVAL { false }
::= { dot11WirelessMgmtOptionsEntry 52 }
dot11RMCivicConfigured OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity which sets the Value to
true when it configures dot11STACivicLocationEntry.
2872
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the STA when an external management entity configures
dot11STALCIEntry.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that that the station is configured
with a civic location (civic location is not Unknown). false indicates the
station is not configured with an civic location or the configured civic
Location is set to Unknown (as defined in 9.4.2.22.13)."
DEFVAL { false }
::= { dot11WirelessMgmtOptionsEntry 53 }
-- ********************************************************************
-- * dot11LocationServices TABLE
-- ********************************************************************
dot11LocationServicesNextIndex OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Identifies a hint for the next value of dot11LocationServicesIndex to be
used in a row creation attempt for dot11LocationServicesTable. If no new
rows can be created for some reason, such as memory, processing
requirements, etc, the SME shall set this attribute to 0. It shall update
this attribute to a proper value other than 0 as soon as it is capable of
receiving new measurement requests. The nextIndex is not necessarily
sequential nor monotonically increasing."
::= { dot11smt 19 }
dot11LocationServicesTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11LocationServicesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains conceptual table of attributes for
WNM LocationServices."
::= { dot11smt 20 }
dot11LocationServicesEntry OBJECT-TYPE
SYNTAX Dot11LocationServicesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11LocationServicesTable
Indexed by dot11LocationServicesIndex."
INDEX { dot11LocationServicesIndex }
::= { dot11LocationServicesTable 1 }
Dot11LocationServicesEntry ::=
SEQUENCE {
dot11LocationServicesIndex Unsigned32,
dot11LocationServicesMACAddress MacAddress,
dot11LocationServicesLIPIndicationMulticastAddress MacAddress,
dot11LocationServicesLIPReportIntervalUnits INTEGER,
dot11LocationServicesLIPNormalReportInterval Unsigned32,
dot11LocationServicesLIPNormalFramesperChannel Unsigned32,
dot11LocationServicesLIPInMotionReportInterval Unsigned32,
dot11LocationServicesLIPInMotionFramesperChannel Unsigned32,
dot11LocationServicesLIPBurstInterframeInterval Unsigned32,
dot11LocationServicesLIPTrackingDuration Unsigned32,
dot11LocationServicesLIPEssDetectionInterval Unsigned32,
dot11LocationServicesLocationIndicationChannelList OCTET STRING,
dot11LocationServicesLocationIndicationBroadcastDataRate
2873
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Unsigned32,
dot11LocationServicesLocationIndicationOptionsUsed OCTET STRING,
dot11LocationServicesLocationIndicationIndicationParameters
OCTET STRING,
dot11LocationServicesLocationStatus Unsigned32
}
dot11LocationServicesIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute contains an auxiliary index into the
dot11LocationServicesTable."
::= { dot11LocationServicesEntry 1 }
dot11LocationServicesMACAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute is the MAC address of the STA reporting location
information."
::= { dot11LocationServicesEntry 2 }
dot11LocationServicesLIPIndicationMulticastAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute is the destination address to which the Location Track
Notification frames are sent in a BSS that is not an IBSS; see 9.4.2.71.2
and 11.24.4.1."
::= { dot11LocationServicesEntry 3 }
dot11LocationServicesLIPReportIntervalUnits OBJECT-TYPE
SYNTAX INTEGER {
hours(0),
minutes(1),
seconds(2),
milliseconds(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute contains the Location Indication Parameters Report
Interval Units value."
::= { dot11LocationServicesEntry 4 }
dot11LocationServicesLIPNormalReportInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute contains the time interval, expressed in the units
indicated in the Report Interval Units field, at which the reporting STA
is expected to transmit one or more Location Track Notification frames if
either dot11MotionDetectionActivated is false or the STA is stationary.
The STA does not transmit Location Track Notification frames when the
Normal Report Interval is 0."
::= { dot11LocationServicesEntry 5 }
dot11LocationServicesLIPNormalFramesperChannel OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
2874
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute contains the number of Location Track Notification frames
per channel sent or expected to be sent by the STA at each Normal Report
Interval."
::= { dot11LocationServicesEntry 6 }
dot11LocationServicesLIPInMotionReportInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute contains the time interval, expressed in the units
indicated in the Report Interval Units field, at which the STA reports its
location by sending a Location Track Notification frame when the reporting
STA is in motion. If dot11MotionDetectionActivated is false, this field is
set to 0."
::= { dot11LocationServicesEntry 7}
dot11LocationServicesLIPInMotionFramesperChannel OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute contains the number of Location Track Notification frames
per channel sent or expected to be sent by the STA at each In-Motion
Report Interval. If dot11MotionDetectionActivated is false, this field is
set to 0."
::= { dot11LocationServicesEntry 8 }
dot11LocationServicesLIPBurstInterframeInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute contains the target time interval between the
transmissions of each of the Normal or In-Motion frames on the same
channel. The Burst Inter-frame interval value is set to 0 to indicate that
frames will be transmitted with no target inter-frame delay."
::= { dot11LocationServicesEntry 9 }
dot11LocationServicesLIPTrackingDuration OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "minutes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute contains the amount of time that a STA sends the Location
Track Notification frames. The duration starts as soon as the STA sends a
Location Configuration Response frame with a Location Status value of
Success. If the Tracking Duration value is a nonzero value the STA will
send Location Track Notification frames, based on the Normal and In-Motion
Report Interval field values, until the duration ends. If the Tracking
Duration is 0 the STA will continuously send Location Track Notification
frames as defined by Normal and In-Motion Report Interval field values
until transmission is terminated based on 11.24.4.2 procedures."
::= { dot11LocationServicesEntry 10}
dot11LocationServicesLIPEssDetectionInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "minutes"
MAX-ACCESS read-create
2875
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This attribute contains the interval that a STA checks for beacons
transmitted by one or more APs belonging to the same ESS that configured
the STA. If no beacons from the ESS are received for this period, the STA
terminates transmission of Location Track Notification frames as described
in 11.24.4.2 procedures. The ESS Detection Interval field is not used when
the ESS Detection Interval field value is set to 0."
::= { dot11LocationServicesEntry 11}
dot11LocationServicesLocationIndicationChannelList OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (2..254))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute contains one or more Operating Class and Channel octet
pairs."
::= { dot11LocationServicesEntry 12}
dot11LocationServicesLocationIndicationBroadcastDataRate OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute specifies the target data rate at which the STA transmits
Location Track Notification frames. The Broadcast Target Data Rate field
format is specified by the Rate Identification field defined in 9.4.1.33.
A value of 0 indicates the STA transmits Location Track Notification
frames at a rate chosen by the STA transmitting the Location Track
Notification frames."
DEFVAL { 0 }
::= { dot11LocationServicesEntry 13}
dot11LocationServicesLocationIndicationOptionsUsed OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the location configuration options used for
transmitting Location Track Notification frames."
::= { dot11LocationServicesEntry 14}
dot11LocationServicesLocationIndicationIndicationParameters OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the location Indication Parameters used for
transmitting Location Track Notification frames."
::= { dot11LocationServicesEntry 15}
dot11LocationServicesLocationStatus OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the Location Status value as indicated in
Table 9-175, Event Report Status."
::= { dot11LocationServicesEntry 16 }
-- ********************************************************************
-- * End of dot11LocationServices TABLE
-- ********************************************************************
2876
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
-- * dot11WirelessMGTEvent TABLE
-- ********************************************************************
dot11WirelessMGTEventTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WirelessMGTEventEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of WIRELESS Management reports that have
been received by the MLME. The report tables shall be maintained as FIFO
to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor.
New rows shall have different RprtIndex values than those deleted within
the range limitation of the index. One easy way is to increment the
EventIndex for new reports being written in the table."
::= { dot11smt 21 }
dot11WirelessMGTEventEntry OBJECT-TYPE
SYNTAX Dot11WirelessMGTEventEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WirelessMGTEventTable
Indexed by dot11WirelessMGTEventIndex."
INDEX { dot11WirelessMGTEventIndex }
::= { dot11WirelessMGTEventTable 1 }
Dot11WirelessMGTEventEntry ::=
SEQUENCE {
dot11WirelessMGTEventIndex Unsigned32,
dot11WirelessMGTEventMACAddress MacAddress,
dot11WirelessMGTEventType INTEGER,
dot11WirelessMGTEventStatus INTEGER,
dot11WirelessMGTEventTSF TSFType,
dot11WirelessMGTEventUTCOffset OCTET STRING,
dot11WirelessMGTEventTimeError OCTET STRING,
dot11WirelessMGTEventTransitionSourceBSSID MacAddress,
dot11WirelessMGTEventTransitionTargetBSSID MacAddress,
dot11WirelessMGTEventTransitionTime Unsigned32,
dot11WirelessMGTEventTransitionReason INTEGER,
dot11WirelessMGTEventTransitionResult Unsigned32,
dot11WirelessMGTEventTransitionSourceRCPI Unsigned32,
dot11WirelessMGTEventTransitionSourceRSNI Unsigned32,
dot11WirelessMGTEventTransitionTargetRCPI Unsigned32,
dot11WirelessMGTEventTransitionTargetRSNI Unsigned32,
dot11WirelessMGTEventRSNATargetBSSID MacAddress,
dot11WirelessMGTEventRSNAAuthenticationType OCTET STRING,
dot11WirelessMGTEventRSNAEAPMethod OCTET STRING,
dot11WirelessMGTEventRSNAResult Unsigned32,
dot11WirelessMGTEventRSNARSNElement OCTET STRING,
dot11WirelessMGTEventPeerSTAAddress MacAddress,
dot11WirelessMGTEventPeerOperatingClass Unsigned32,
dot11WirelessMGTEventPeerChannelNumber Unsigned32,
dot11WirelessMGTEventPeerSTATxPower Integer32,
dot11WirelessMGTEventPeerConnectionTime Unsigned32,
dot11WirelessMGTEventPeerPeerStatus Unsigned32,
dot11WirelessMGTEventWNMLog OCTET STRING
}
dot11WirelessMGTEventIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-only
STATUS current
2877
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This attribute contains an auxiliary index into the
dot11WirelessMGTEventTable."
::= { dot11WirelessMGTEventEntry 1 }
dot11WirelessMGTEventMACAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute is the MAC address of the STA providing the Event report."
::= { dot11WirelessMGTEventEntry 2 }
dot11WirelessMGTEventType OBJECT-TYPE
SYNTAX INTEGER {
transition(0),
rsna(1),
peerToPeer(2),
wnmLog(3),
vendorSpecific(221)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the request type of this WNM Event request."
::= { dot11WirelessMGTEventEntry 3 }
dot11WirelessMGTEventStatus OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the status value included in the Event report."
::= { dot11WirelessMGTEventEntry 4 }
dot11WirelessMGTEventTSF OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the value of the Event timestamp field."
::= { dot11WirelessMGTEventEntry 5 }
dot11WirelessMGTEventUTCOffset OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(10))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the UTC Offset Time Value optionally included in
the Event report."
::= { dot11WirelessMGTEventEntry 6}
dot11WirelessMGTEventTimeError OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(5))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the value of the Event Time Error field
2878
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
optionally included in the Event report."
::= { dot11WirelessMGTEventEntry 7}
dot11WirelessMGTEventTransitionSourceBSSID OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the value of the Source BSSID field in a
Transition event report."
::= { dot11WirelessMGTEventEntry 8}
dot11WirelessMGTEventTransitionTargetBSSID OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the value of the Target BSSID field in a
Transition event report."
::= { dot11WirelessMGTEventEntry 9}
dot11WirelessMGTEventTransitionTime OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the transition time for the reported transition
event in TUs. The Transition time is defined as the time difference
between the starting time and the ending time of a transition between APs,
even if the transition results in remaining on the same AP. Start and end
times for a transition event are defined in 11.24.2.2"
::= { dot11WirelessMGTEventEntry 10}
dot11WirelessMGTEventTransitionReason OBJECT-TYPE
SYNTAX INTEGER {
unspecified(0),
excessiveFrameLossRatesPoorConditions(1),
excessiveDelayForCurrentTrafficStreams(2),
insufficientQosCapacityForCurrentTrafficStreams(3),
firstAssociationToEss(4),
loadBalancing(5),
betterApFound(6),
deauthenticatedDisassociatedFromPreviousAp(7),
certificateToken(8),
apFailedIeee8021XEapAuthentication(9),
apFailed4wayHandshake(10),
excessiveDataMICFailures(11),
exceededFrameTransmissionRetryLimit(12),
ecessiveBroadcastDisassociations(13),
excessiveBroadcastDeauthentications(14),
previousTransitionFailed(15)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the reason for the reported BSS transition
event. The format for this list of reasons is further detailed in
9.4.2.68.2."
::= { dot11WirelessMGTEventEntry 11}
dot11WirelessMGTEventTransitionResult OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
2879
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This attribute indicates the result of the attempted transition and is
set to one of the status codes specified in Table 9-46."
::= { dot11WirelessMGTEventEntry 12 }
dot11WirelessMGTEventTransitionSourceRCPI OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the received channel power of the most recently
measured frame from the Source BSSID before the STA reassociates to the
Target BSSID. The Source RCPI is a logarithmic function of the received
signal power, as defined in 9.4.2.38."
::= { dot11WirelessMGTEventEntry 13 }
dot11WirelessMGTEventTransitionSourceRSNI OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the received signal-to-noise indication of the
most recently measured frame from the Source BSSID before the STA
reassociates to the Target BSSID. The Source RSNI is a logarithmic
function of the signal-to-noise ratio, as defined in 9.4.2.41."
::= { dot11WirelessMGTEventEntry 14 }
dot11WirelessMGTEventTransitionTargetRCPI OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the received channel power of the first measured
frame just after STA reassociates to the Target BSSID. If association with
target BSSID failed, the Target RCPI field indicates the received channel
power of the most recently measured frame from the Target BSSID. The
Target RCPI is a logarithmic function of the received signal power, as
defined 9.4.2.38."
::= { dot11WirelessMGTEventEntry 15 }
dot11WirelessMGTEventTransitionTargetRSNI OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the received signal-to-noise indication of the
first measured frame just after STA reassociates to the Target BSSID. If
association with target BSSID failed, the Target RCPI field indicates the
received signal-to-noise indication of the most recently measured frame
from the Target BSSID. The Target RSNI is a logarithmic function of the
signal-to-noise ratio, as defined in 9.4.2.41."
::= { dot11WirelessMGTEventEntry 16 }
dot11WirelessMGTEventRSNATargetBSSID OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the value of the Target BSSID field in an RSNA
event report."
::= { dot11WirelessMGTEventEntry 17 }
dot11WirelessMGTEventRSNAAuthenticationType OBJECT-TYPE
2880
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX OCTET STRING (SIZE (4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the AKM suite, as defined in Table 9-133. The
first three octets indicate the OUI or CID. The last octet indicates the
suite type."
::= { dot11WirelessMGTEventEntry 18 }
dot11WirelessMGTEventRSNAEAPMethod OBJECT-TYPE
SYNTAX OCTET STRING(SIZE (1..8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates a value that identifies the EAP Method. When the
Authentication Type field is set to the value of either 00-0F-AC:1
(Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as
defined in 12.6.10.3) or 00-0F-AC:3 (AKM suite selector for fast BSS
transition as defined in 12.7.1.7), the EAP Method field contains the IANA
assigned EAP type defined at http://www.iana.org/assignments/eap-numbers.
The EAP type contains either the legacy type (1 octet) or the expanded
type (1 octet type = 254, 3-octet Vendor ID, 4-octet Vendor-Type). The EAP
Method field is set to 0 otherwise."
::= { dot11WirelessMGTEventEntry 19 }
dot11WirelessMGTEventRSNAResult OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the result of the RSNA event and is set to one
of the status codes specified in Table 9-46."
::= { dot11WirelessMGTEventEntry 20}
dot11WirelessMGTEventRSNARSNElement OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..257))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the entire contents of the negotiated RSNE at the
time of the authentication attempt. The format of the RSNE is defined in
9.4.2.25."
::= { dot11WirelessMGTEventEntry 21}
dot11WirelessMGTEventPeerSTAAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the MAC address of the peer STA or IBSS BSSID is
equal to the indicated MAC address. If this event is for a peer-to-peer
link in an infrastructure BSS, this field contains the MAC address of the
peer STA. If this event is for a peer-to-peer link in an IBSS, this field
contains the BSSID of the IBSS."
::= { dot11WirelessMGTEventEntry 22 }
dot11WirelessMGTEventPeerOperatingClass OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the channel set for this peer-to-peer event
report. Country, Operating Class, and Channel Number together specify the
channel frequency and spacing for this measurement request. Valid values
2881
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
of Operating Class are shown in Annex E."
::= { dot11WirelessMGTEventEntry 23 }
dot11WirelessMGTEventPeerChannelNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the current operating channel for this peer-to-
peer event report. The Channel Number is defined only within the indicated
Operating Class as shown in Annex E."
::= { dot11WirelessMGTEventEntry 24 }
dot11WirelessMGTEventPeerSTATxPower OBJECT-TYPE
SYNTAX Integer32 (-128..127)
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the STA transmit power used for the peer-to-peer
link. The STA Tx Power field indicates the target transmit power at the
antenna with a tolerance of +/-5 dB for the lowest basic rate of the
reporting STA. A value of -128 indicates that the value is unknown."
::= { dot11WirelessMGTEventEntry 25 }
dot11WirelessMGTEventPeerConnectionTime OBJECT-TYPE
SYNTAX Unsigned32 (0..16777215)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates a value representing the connection time for the
reported peer-to-peer event. If the Peer Status is 0, this field indicates
the duration of the Direct Link. If the Peer Status is 1, this field
indicates the time difference from the time the Direct Link was
established to the time at which the reporting STA generated the event
report. If the Peer Status is 2, this field indicates the duration of the
IBSS membership. If the Peer Status is 3, this field indicates the time
difference from the time the STA joined the IBSS to the time at which the
reporting STA generated the event report. See 11.24.2.4."
::= { dot11WirelessMGTEventEntry 26 }
dot11WirelessMGTEventPeerPeerStatus OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute indicates the Peer link connection status as indicated in
Table 9-177. See 9.4.2.68.4."
::= { dot11WirelessMGTEventEntry 27 }
dot11WirelessMGTEventWNMLog OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..2284))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute contains the entire syslog message, consisting of the PRI,
HEADER, and MSG portion of a WNM log message as described in IETF RFC
5424. The TAG field of the MSG portion of the message is a 17 octet string
containing the ASCII representation of the STA MAC address using
hexadecimal notation with colons between octets. The octet containing the
Individual/Group bit occurs last, and that bit is in the least significant
position within that octet. See 11.24.2.5."
::= { dot11WirelessMGTEventEntry 28 }
2882
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
-- * End of dot11WirelessMGTEvent TABLE
-- ********************************************************************
2883
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- **********************************************************************
-- * IEEE 802.11 RM and WNM Interface MIB
-- **********************************************************************
-- * The primary interface to the radio measurements and Wireless
-- * Network Management functions is meant to be real-time information
-- * obtained through the request/response mechanisms of RM and WNM.
-- * A secondary interface to the measurements and management functions
-- * is through retention of information in this MIB. Non-SNMP requests
-- * for information are obtained via object IDs (OIDs) through the NDIS
-- * or wireless interfaces in the operating systems. SNMP requests for
-- * information are obtained via SNMP SETs and GETs (see [B26]).
-- * dot11RMRequest and dot11RMReport Usage
-- *
-- * The dot11RMRequest and dot11RMReport portions of the RM MIB
-- * provide access to the Radio Measurement service. By performing
-- * SET operations on the various dot11RMRequest MIB objects,
-- * radio measurements may be initiated directly on the local STA or
-- * on any peer station within the same BSS. Subsequently, by
-- * performing GET operations on the various dot11RMReport MIB
-- * objects the results of the requested measurements may be
-- * retrieved.
-- *
-- * In the diagram below, a radio measurement could be initiated
-- * for STA x by performing a MIB.set operation on the RM MIB of
-- * STA x and specifying the MAC address of STA x in
-- * dot11RMRqstTargetAdd. Additionally, it is possible to have STA x
-- * request a measurement from STA y by performing a MIB.set operation
-- * on the SME MIB of STA x and specifying the MAC address of STA y in
-- * dot11RMRqstTargetAdd. In both cases the result of the measurements
-- * can be retrieved by performing a MIB.get operation on the RM MIB
-- * of STA x upon completion of the measurement.
-- *
-- *
-- * MIB.Set MIB.Set
-- * or or
-- * MIB.Get MIB.Get
-- * +========|=========+ +========|=========+
-- * | SME | | | SME | |
-- * | \ / | | \ / |
-- * | +=========+ | | +=========+ |
-- * | | RM and | | | | RM and | |
-- * | | WNM MIB | | | | WNM MIB | |
-- * | | | | | | | |
-- * | | | | | | | |
-- * | +=========+ | | +=========+ |
-- * | | | |
-- * | / \ | | / \ |
-- * | | MREQUEST | | | MREQUEST |
-- * +====+=============+ +====+=============+
-- * | | MREPORT | | | MREPORT |
-- * | \ / MEASURE | Action frames | \ / MEASURE |
-- * | | <==Measurement Request==> | |
-- * | | <==Measurement Report===> | |
-- * | MLME | | MLME |
-- * +==================+ +==================+
-- * STA x STA y
-- *
-- * Each STA maintains a single dot11RMRequestTable in the SME MIB
-- * used to initiate RM Measurement Requests. Each dot11RMRequestEntry
-- * in the table represents an individual Measurement Request that
-- * makes up a complete Measurement Request frame.
-- * Multiple Measurement Requests may be concatenated into a single
2884
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- * Measurement Request frame by setting the same
-- * dot11RMRqstToken value into multiple dot11RMRequestEntrys.
-- *
-- * Each row, dot11RMRequestEntry, of the dot11RMRequestTable
-- * provides read-create access for the initiation of a measurement
-- * request. The dot11RMRequestNextIndex object can be used to
-- * determine which is the next available row. Each row corresponding to
-- * one measurement in the sequence is created with a dot11RMRqstRowStatus
-- * equal to notInService. Once the dot11RMRequestEntry(s) have been
-- * created for a desired measurement sequence the corresponding
-- * dot11RMRqstRowStatus(s) objects are set to active to indicate that
-- * the SME can trigger the appropriate MLME primitives. Upon processing
-- * the request, the SME returns the corresponding dot11RMRqstRowStatus(s)
-- * object to notInService and are now available for additional
-- * measurement requests.
-- *
-- * After a radio measurement is complete the RM populates the RMReport
-- * objects with the results of the measurement. Each STA maintains a set
-- * of RMReport tables, one corresponding to each measurement type. The
-- * results of the entire measurement sequence are spread across the tables
-- * based on the type of measurements requested. Each xxxReportEntry
-- * within a xxxReportTable contains a xxxRprtRqstToken that corresponds
-- * to the original dot11RMRqstToken in the measurement request. So the
-- * results of the measurement can be collected by searching the appropriate
-- * xxxReportTables and retrieve any reports with the matching request
-- * token.
-- *
-- * Similar structures and mechanisms are used for WNM
-- * Request and Reports. The WNM MIB definitions follow the RM MIB definitions
-- * in this Annex.
-- **********************************************************************
-- ********************************************************************
-- * Radio Measurement Interface MIB
-- ********************************************************************
dot11RadioMeasurement OBJECT IDENTIFIER ::= { dot11smt 14 }
-- ********************************************************************
-- * Radio Measurement Requests
-- ********************************************************************
dot11RMRequest OBJECT IDENTIFIER ::= { dot11RadioMeasurement 1 }
-- ********************************************************************
-- * dot11RMRequest TABLE
-- ********************************************************************
dot11RMRequestNextIndex OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when able to accept a new request.
Identifies a hint for the next value of dot11RMRqstIndex to be used in a
row creation attempt for dot11RMRequestTable. If no new rows can be
created for some reason, such as memory, processing requirements, etc.,
the SME sets this attribute to 0. It updates this attribute to a proper
value other than 0 as soon as it is capable of receiving new measurement
requests. The nextIndex is not necessarily sequential nor monotonically
increasing."
::= { dot11RMRequest 1 }
dot11RMRequestTable OBJECT-TYPE
2885
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX SEQUENCE OF Dot11RMRequestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This group contains the current list of requests for RM reports to be
issued and have been issued until removed. A network manager adds an RM
request by creating a row with createAndWait row status and then filling
in the request parameters/attributes. The request becomes active to be
issued when the row status is set to Active. The columnar objects or
attributes other than the rowStatus are not written if the rowStatus is
Active. The request rows can be deleted, if commanded by a network manager
via changing the value of dot11RMRqstRowStatus to Destroy. This may leave
orphaned rows if a manager crashes and forgets which rows are being used
by it. One recommended way to manage orphaned or finished rows is to
delete rows if their dot11RMRqstRowStatus remains other than Active for
longer than a period (recommend at least 5 minutes, IETF RFC 2579). Or
another recommended way is to delete older rows as needed based on their
dot11RMRqstTimeStamp values. This can be done by the agent as well as the
manager. "
::= { dot11RMRequest 2 }
dot11RMRequestEntry OBJECT-TYPE
SYNTAX Dot11RMRequestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11RMRequestTable Indexed by dot11RMRqstIndex."
INDEX { dot11RMRqstIndex }
::= { dot11RMRequestTable 1 }
Dot11RMRequestEntry ::=
SEQUENCE {
dot11RMRqstIndex Unsigned32,
dot11RMRqstRowStatus RowStatus,
dot11RMRqstToken OCTET STRING,
dot11RMRqstRepetitions Unsigned32,
dot11RMRqstIfIndex InterfaceIndex,
dot11RMRqstType INTEGER,
dot11RMRqstTargetAdd MacAddress,
dot11RMRqstTimeStamp TimeTicks,
dot11RMRqstChanNumber Unsigned32,
dot11RMRqstOperatingClass Unsigned32,
dot11RMRqstRndInterval Unsigned32,
dot11RMRqstDuration Unsigned32,
dot11RMRqstParallel TruthValue,
dot11RMRqstEnable TruthValue,
dot11RMRqstRequest TruthValue,
dot11RMRqstReport TruthValue,
dot11RMRqstDurationMandatory TruthValue,
dot11RMRqstBeaconRqstMode INTEGER,
dot11RMRqstBeaconRqstDetail INTEGER,
dot11RMRqstFrameRqstType INTEGER,
dot11RMRqstBssid MacAddress,
dot11RMRqstSSID OCTET STRING,
dot11RMRqstBeaconReportingCondition INTEGER,
dot11RMRqstBeaconThresholdOffset Integer32,
dot11RMRqstSTAStatRqstGroupID INTEGER,
dot11RMRqstLCIRqstSubject INTEGER,
dot11RMRqstLCIAzimuthType INTEGER,
dot11RMRqstLCIAzimuthResolution Unsigned32,
dot11RMRqstPauseTime Unsigned32,
dot11RMRqstTransmitStreamPeerQSTAAddress MacAddress,
dot11RMRqstTransmitStreamTrafficIdentifier Unsigned32,
dot11RMRqstTransmitStreamBin0Range Unsigned32,
2886
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMRqstTrigdQoSAverageCondition TruthValue,
dot11RMRqstTrigdQoSConsecutiveCondition TruthValue,
dot11RMRqstTrigdQoSDelayCondition TruthValue,
dot11RMRqstTrigdQoSAverageThreshold Unsigned32,
dot11RMRqstTrigdQoSConsecutiveThreshold Unsigned32,
dot11RMRqstTrigdQoSDelayThresholdRange Unsigned32,
dot11RMRqstTrigdQoSDelayThreshold Unsigned32,
dot11RMRqstTrigdQoSMeasurementCount Unsigned32,
dot11RMRqstTrigdQoSTimeout Unsigned32,
dot11RMRqstChannelLoadReportingCondition INTEGER,
dot11RMRqstChannelLoadReference Unsigned32,
dot11RMRqstNoiseHistogramReportingCondition INTEGER,
dot11RMRqstAnpiReference Unsigned32,
dot11RMRqstAPChannelReport OCTET STRING,
dot11RMRqstSTAStatPeerSTAAddress MacAddress,
dot11RMRqstFrameTransmitterAddress MacAddress,
dot11RMRqstVendorSpecific OCTET STRING,
dot11RMRqstSTAStatTrigMeasCount Unsigned32,
dot11RMRqstSTAStatTrigTimeout Unsigned32,
dot11RMRqstSTAStatTrigCondition OCTET STRING,
dot11RMRqstSTAStatTrigSTAFailedCntThresh Unsigned32,
dot11RMRqstSTAStatTrigSTAFCSErrCntThresh Unsigned32,
dot11RMRqstSTAStatTrigSTAMultRetryCntThresh Unsigned32,
dot11RMRqstSTAStatTrigSTAFrameDupeCntThresh Unsigned32,
dot11RMRqstSTAStatTrigSTARTSFailCntThresh Unsigned32,
dot11RMRqstSTAStatTrigSTAAckFailCntThresh Unsigned32,
dot11RMRqstSTAStatTrigSTARetryCntThresh Unsigned32,
dot11RMRqstSTAStatTrigQoSTrigCondition OCTET STRING,
dot11RMRqstSTAStatTrigQoSFailedCntThresh Unsigned32,
dot11RMRqstSTAStatTrigQoSRetryCntThresh Unsigned32,
dot11RMRqstSTAStatTrigQoSMultRetryCntThresh Unsigned32,
dot11RMRqstSTAStatTrigQoSFrameDupeCntThresh Unsigned32,
dot11RMRqstSTAStatTrigQoSRTSFailCntThresh Unsigned32,
dot11RMRqstSTAStatTrigQoSAckFailCntThresh Unsigned32,
dot11RMRqstSTAStatTrigQoSDiscardCntThresh Unsigned32,
dot11RMRqstSTAStatTrigRsnaTrigCondition OCTET STRING,
dot11RMRqstSTAStatTrigRsnaCMACICVErrCntThresh Unsigned32,
dot11RMRqstSTAStatTrigRsnaCMACReplayCntThresh Unsigned32,
dot11RMRqstSTAStatTrigRsnaRobustCCMPReplayCntThresh
Unsigned32,
dot11RMRqstSTAStatTrigRsnaTKIPICVErrCntThresh Unsigned32,
dot11RMRqstSTAStatTrigRsnaTKIPReplayCntThresh Unsigned32,
dot11RMRqstSTAStatTrigRsnaCCMPDecryptErrCntThreshUnsigned32,
dot11RMRqstSTAStatTrigRsnaCCMPReplayCntThresh Unsigned32
}
dot11RMRqstIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for RM Request elements in dot11RMRequestTable, greater than 0."
::= { dot11RMRequestEntry 1 }
dot11RMRqstRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement, and by the SME when accepting a measurement request.
The Row Status column of the current row, used for tracking status of an
2887
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
individual request. When this attribute is set to Active, AND a
measurement request can be unambiguously created based on the parameters
in the row, then the MLME may proceed to issue the request to its intended
targets when appropriate. If not, this attribute may be set to Not-ready
immediately to indicate parametric errors. However, it is the network
managers
responsibility to correct the error. If the request is successfully issued
to the target STA, then the rowStatus is set to notInService."
REFERENCE "9.4.2.21"
::= { dot11RMRequestEntry 2 }
dot11RMRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when the table entry is
created, i.e., when requesting a measurement..
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates a unique string to identify a group of rows to be
issued as parallel or sequential measurements. To guarantee the uniqueness
of this token across multiple network managers, it is recommended that
this token be prefixed with the IP address of the network manager creating
this row. This token is not necessarily equivalent to the measurement
tokens in RM request frames. If this attribute is an empty string, then
this row of request is independent from other requests."
DEFVAL { "" }
::= { dot11RMRequestEntry 3 }
dot11RMRqstRepetitions OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the requested number of repetitions for all of
the Measurement Request elements in this frame. A value of 0 in the Number
of Repetitions field indicates Measurement Request elements are executed
once without repetition."
::= { dot11RMRequestEntry 4 }
dot11RMRqstIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
The ifIndex on which this row of the RM Request is to be issued."
::= { dot11RMRequestEntry 5 }
dot11RMRqstType OBJECT-TYPE
SYNTAX INTEGER {
channelLoad(3),
noiseHistogram(4),
2888
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
beacon(5),
frame(6),
staStatistics(7),
lci(8),
transmitStream(9),
pause(255) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the measurement type of this RM request row."
::= { dot11RMRequestEntry 6 }
dot11RMRqstTargetAdd OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
The MAC address of STA for this row of RM Request is to be issued to. If
this attribute matches the MAC address of the dot11RMRqstIfIndex, then
measurement request is for this STA itself to carry out."
::= { dot11RMRequestEntry 7 }
dot11RMRqstTimeStamp OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when dot11RMRqstRowStatus is set to Active.
This attribute indicates the sysUpTime Value the last time when the
dot11RMRqstRowStatus is set to active or when this row is created the
first time."
::= { dot11RMRequestEntry 8 }
dot11RMRqstChanNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
The target STA channel number on which to perform the measurements
indicated in this request. The Channel Number is defined only within the
indicated Operating Class for this measurement request. This attribute is
ignored if dot11RMRqstType = STA Statistics, LCI, Transmit Stream/Category
Measurement, or Measurement Pause. However, even in that case, the manager
should set this attribute to the current channel for this interface, so
that the row can be set to active when ready with all attributes
indicated."
::= { dot11RMRequestEntry 9 }
2889
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMRqstOperatingClass OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the channel set for this measurement request.
Country, Operating Class and Channel Number together specify the channel
frequency and spacing for this measurement request. Valid values of
Operating Class are shown in Annex E."
REFERENCE "Annex E"
::= { dot11RMRequestEntry 10 }
dot11RMRqstRndInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the upper bound of the random delay to be used
prior to making the measurement. See 11.11.3. This attribute is ignored if
dot11RMRqstType = STA Statistics, LCI, Transmit Stream/Category
Measurement or Measurement Pause."
DEFVAL { 0 }
::= { dot11RMRequestEntry 11 }
dot11RMRqstDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the preferred or mandatory measurement duration
for this Measurement Request. This attribute is ignored if dot11RMRqstType
= LCI or Measurement Pause."
DEFVAL { 0 }
::= { dot11RMRequestEntry 12 }
dot11RMRqstParallel OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the parallel bit for this Measurement Request
2890
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
element. This attribute, when false, indicates that the measurement is
performed in sequence. This attribute, when true, indicates that this
measurement should start at the same time as the measurement described by
the next Measurement Request element in the next row if the next row
indicates the same value for dot11RMRqstToken."
DEFVAL { false }
::= { dot11RMRequestEntry 13 }
dot11RMRqstEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the enable bit for this Measurement Request
element."
DEFVAL { false }
::= { dot11RMRequestEntry 14 }
dot11RMRqstRequest OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the request bit for this Measurement Request
element. This attribute, when true, indicates that this STA accepts
measurement requests from the target STA."
DEFVAL { false }
::= { dot11RMRequestEntry 15 }
dot11RMRqstReport OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the report bit for this Measurement Request
element. This attribute, when true, indicates that the target STA may
enable autonomous measurement reports to the requesting STA."
DEFVAL { false }
::= { dot11RMRequestEntry 16 }
dot11RMRqstDurationMandatory OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
2891
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the duration mandatory bit for this Measurement
Request element. This attribute, when true, indicates that the indicated
Measurement Duration is a mandatory duration for this measurement. This
attribute, when false, indicates that the indicated Measurement Duration
is a maximum duration for this measurement."
DEFVAL { false }
::= { dot11RMRequestEntry 17 }
dot11RMRqstBeaconRqstMode OBJECT-TYPE
SYNTAX INTEGER {
passive(0),
active(1),
beaconTable(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the Measurement Mode for this Beacon request.
This attribute is valid only if the dot11RMRqstType is 5, indicating a
Beacon request, and is ignored otherwise."
DEFVAL { 0 }
::= { dot11RMRequestEntry 18 }
dot11RMRqstBeaconRqstDetail OBJECT-TYPE
SYNTAX INTEGER {
noBody(0),
fixedFieldsAndRequestedElements(1),
allBody(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
dot11RMRqstBeaconRqstDetail indicates the Reporting Detail for Beacon
request. This attribute is valid only if the dot11RMRqstType is 5,
indicating a Beacon request, and is ignored otherwise."
DEFVAL { 2 }
::= { dot11RMRequestEntry 19 }
dot11RMRqstFrameRqstType OBJECT-TYPE
SYNTAX INTEGER { frameCountRep(1) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
dot11RMRqstFrameRqstType indicates the Frame Request Type for the Frame
request. This attribute is valid only if the dot11RMRqstType is 6,
indicating a Frame request, and is ignored otherwise."
DEFVAL { 1 }
::= { dot11RMRequestEntry 20 }
dot11RMRqstBssid OBJECT-TYPE
2892
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
BSSID indicates the BSSID of the particular AP for which this measurement
is requested. The BSSID is set to the wildcard BSSID when the measurement
is to be performed on any AP(s) on the indicated channel. This attribute
is valid only if the dot11RMRqstType is 5, indicating a Beacon request,
and is ignored otherwise."
DEFVAL { 'FFFFFFFFFFFF'H }
::= { dot11RMRequestEntry 21 }
dot11RMRqstSSID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the SSID for the measurement. Zero-length MIB
element for SSID indicates the wildcard SSID. The SSID is set to the
wildcard SSID when the measurement is to be performed on all ESSs/IBSSs on
the indicated channel. This attribute is valid only if the dot11RMRqstType
is 5, indicating a Beacon request, and is ignored otherwise."
DEFVAL { ''H }
::= { dot11RMRequestEntry 22 }
dot11RMRqstBeaconReportingCondition OBJECT-TYPE
SYNTAX INTEGER {
afterEveryMeasurement(0),
rcpiAboveAbsoluteThreshold(1),
rcpiBelowAbsoluteThreshold(2),
rsniAboveAbsoluteThreshold(3),
rsniBelowAbsoluteThreshold(4),
rcpiAboveOffsetThreshold(5),
rcpiBelowOffsetThreshold(6),
rsniAboveOffsetThreshold(7),
rsniBelowOffsetThreshold(8),
rcpiInBound(9),
rsniInBound(10) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates when the Beacon Measurement results are to be
reported to the requesting STA. This attribute is valid only if the
dot11RMRqstType is 5, indicating a Beacon request, and is ignored
otherwise."
REFERENCE
"IEEE Std 802.11, Table 9-89-Reporting Condition values for Beacon request"
DEFVAL {0}
::= { dot11RMRequestEntry 23 }
2893
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMRqstBeaconThresholdOffset OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
Threshold/Offset provides either the threshold value or the offset value
to be used for conditional reporting. For indicated reporting conditions
1-4, the integer range is (0..255). For indicated reporting conditions 5-
10, the integer range is (-127..+127). This attribute is valid only if
the dot11RMRqstType is 5, indicating a Beacon request, and is ignored
otherwise."
DEFVAL { 0 }
::= { dot11RMRequestEntry 24 }
dot11RMRqstSTAStatRqstGroupID OBJECT-TYPE
SYNTAX INTEGER {
dot11CountersTable(0),
dot11MacStatistics(1),
dot11QosCountersTableforUP0(2),
dot11QosCountersTableforUP1(3),
dot11QosCountersTableforUP2(4),
dot11QosCountersTableforUP3(5),
dot11QosCountersTableforUP4(6),
dot11QosCountersTableforUP5(7),
dot11QosCountersTableforUP6(8),
dot11QosCountersTableforUP7(9),
bSSAverageAccessDelays(10),
dot11CountersGroup3Tablefor31(11),
dot11CountersGroup3Tablefor32(12),
dot11CountersGroup3Tablefor33(13),
dot11CountersGroup3Tablefor34(14),
dot11CountersGroup3Tablefor35(15),
dot11RSNAStatsTable(16)}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
The attribute indicates the group identity for this Measurement Request
element. This attribute is valid only if the dot11RMRqstType is 7,
indicating a STA statistics request, and is ignored otherwise."
DEFVAL { 0 }
::= { dot11RMRequestEntry 25 }
dot11RMRqstLCIRqstSubject OBJECT-TYPE
SYNTAX INTEGER { local(0), remote(1) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
The attribute indicates the subject of the LCI request. This attribute is
2894
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
valid only if the dot11RMRqstType is 8, indicating an LCI request, and is
ignored otherwise."
DEFVAL { 0 }
::= { dot11RMRequestEntry 26 }
-- 27 to 29 are reserved
dot11RMRqstLCIAzimuthType OBJECT-TYPE
SYNTAX INTEGER { frontSurfaceofSta(0), radioBeam(1) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the azimuth reference for the LCI Azimuth
measurement request. This attribute is valid only if the dot11RMRqstType
is 8, indicating an LCI request, and is ignored otherwise."
DEFVAL{ 0 }
::= { dot11RMRequestEntry 30 }
dot11RMRqstLCIAzimuthResolution OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute is 4 bits indicating the number of valid
bits in the fixed-point value of Azimuth of the LCI Azimuth
measurement request. This attribute is valid only if the dot11RMRqstType
is 8, indicating an LCI request, and is ignored otherwise."
::= { dot11RMRequestEntry 31 }
dot11RMRqstPauseTime OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "10 TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the time period for which measurements are
suspended or paused. Measurement Pause requests are used to
provide time delays between the execution times of measurement
request elements in a Measurement Request frame. This attribute is valid
only if the dot11RMRqstType is 255, indicating an pause request, and is
ignored otherwise."
DEFVAL { 0 }
::= { dot11RMRequestEntry 32 }
dot11RMRqstTransmitStreamPeerQSTAAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
2895
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the peer STA address to be measured for a
Transmit Stream/Category Measurement measurement. This attribute is valid
only if the dot11RMRqstType is 9, indicating a transmit stream/category
request, and is ignored otherwise."
::= { dot11RMRequestEntry 33 }
dot11RMRqstTransmitStreamTrafficIdentifier OBJECT-TYPE
SYNTAX Unsigned32(0..16)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the TC, or TS to be measured for a Transmit
Stream/Category Measurement measurement. This attribute is valid only if
the dot11RMRqstType is 9, indicating a transmit stream/category request,
and is ignored otherwise."
::= { dot11RMRequestEntry 34 }
dot11RMRqstTransmitStreamBin0Range OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the delay range for bin 0 of the transmit delay
histogram. This attribute is valid only if the dot11RMRqstType is 9,
indicating a transmit stream/category request, and is ignored otherwise."
::= { dot11RMRequestEntry 35 }
dot11RMRqstTrigdQoSAverageCondition OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute, when true, indicates a request for triggered reporting
with trigger based on the number of discarded MSDUs reaching the
dot11RMRqstTrigdQoSAverageThreshold when averaged over
dot11RMRqstTrigdQoSMeasurementCount consecutive MSDUs. This attribute is
valid only if the dot11RMRqstType is 9, indicating a transmit stream/
category request, and is ignored otherwise."
DEFVAL { false }
::= { dot11RMRequestEntry 36 }
dot11RMRqstTrigdQoSConsecutiveCondition OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
2896
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute, when true, indicates a request for triggered reporting
with trigger based on the consecutive number of MSDUs discarded reaching
dot11RMRqstTrigdQoSConsecutiveThreshold. This attribute is valid only if
the dot11RMRqstType is 9, indicating a transmit stream/category request,
and is ignored otherwise."
DEFVAL { false }
::= { dot11RMRequestEntry 37 }
dot11RMRqstTrigdQoSDelayCondition OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute, when true, indicates a request for triggered reporting
with trigger based on the consecutive number of MSDUs that experience a
transmit delay greater than dot11RMRqstTrigdQoSDelayThresholdRange
reaching dot11RMRqstTrigdQoSDelayThreshold. This attribute is valid only
if the dot11RMRqstType is 9, indicating a transmit stream/category
request, and is ignored otherwise."
DEFVAL { false }
::= { dot11RMRequestEntry 38 }
dot11RMRqstTrigdQoSAverageThreshold OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the trigger threshold for triggered Transmit
Stream/Category Measurement based on average MSDUs discarded. Trigger
occurs if the number of MSDUs discarded over the moving average number of
transmitted MSDUs in dot11RMRqstTrigdQoSMeasurementCount reaches this
threshold. This attribute is valid only if the dot11RMRqstType is 9,
indicating a transmit stream/category request, and is ignored otherwise."
DEFVAL { 10 }
::= { dot11RMRequestEntry 39 }
dot11RMRqstTrigdQoSConsecutiveThreshold OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the trigger threshold for triggered Transmit
2897
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Stream/Category Measurement based on consecutive MSDUs discarded. Trigger
occurs if the consecutive number of MSDUs discarded reaches this
threshold. This attribute is valid only if the dot11RMRqstType is 9,
indicating a transmit stream/category request, and is ignored otherwise."
DEFVAL { 5 }
::= { dot11RMRequestEntry 40 }
dot11RMRqstTrigdQoSDelayThresholdRange OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the minimum transmit delay for delayed MSDU
counts. Trigger occurs if the a consecutive number of MSDUs experience a
transmit delay greater than or equal to the lower bound of the bin of the
Transmit Delay Histogram given by the value of this attribute + 2, e.g.,if
this attribute is 1 the lower bound of bin 3. This attribute is valid only
if the dot11RMRqstType is 9, indicating a transmit stream/category
request, and is ignored otherwise."
DEFVAL { 1 }
::= { dot11RMRequestEntry 41 }
dot11RMRqstTrigdQoSDelayThreshold OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the number of consecutive delayed MSDUs needed
for trigger. Trigger occurs if the consecutive number of MSDUs that
experience a transmit delay greater than
dot11RMRqstTrigdQoSDelayThresholdRange reaches this value. This attribute
is valid only if the dot11RMRqstType is 9, indicating a transmit stream/
category request, and is ignored otherwise."
DEFVAL { 20 }
::= { dot11RMRequestEntry 42 }
dot11RMRqstTrigdQoSMeasurementCount OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the number of MSDUs to be used as a moving
average count in the average error threshold and in determining the scope
of the reported Transmit Stream/Category measurement in a triggered
measurement report. This attribute is valid only if the dot11RMRqstType is
9, indicating a transmit stream/category request, and is ignored
otherwise."
DEFVAL { 100 }
::= { dot11RMRequestEntry 43 }
2898
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMRqstTrigdQoSTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "100 TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the timeout interval during which a measuring STA
does not generate further triggered Transmit Stream/Category measurement
reports after a trigger condition has been met and a report generated.
This attribute is valid only if the dot11RMRqstType is 9, indicating a
transmit stream/category request, and is ignored otherwise."
DEFVAL { 20 }
::= { dot11RMRequestEntry 44 }
dot11RMRqstChannelLoadReportingCondition OBJECT-TYPE
SYNTAX INTEGER {
afterEveryMeasurement(0),
chanLoadAboveReference(1),
chanLoadBelowReference(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates when the Channel Load Measurement results are to
be reported to the requesting STA. This attribute is valid only if the
dot11RMRqstType is 3, indicating a Channel Load request, and is ignored
otherwise."
REFERENCE
"IEEE Std 802.11, Table 9-84"
DEFVAL {0}
::= { dot11RMRequestEntry 45 }
dot11RMRqstChannelLoadReference OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "1/255"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the channel load reporting condition reference
value. The measured Channel Load is compared to this reference value and a
report is issued if the reporting condition is satisfied. The reference
value is in the same units as Channel Load and represents the fractional
time of the measurement duration during which the STA determined the
channel to be busy. This attribute is valid only if the dot11RMRqstType is
3, indicating a Channel Load request, and is ignored otherwise."
DEFVAL { 5 }
::= { dot11RMRequestEntry 46 }
dot11RMRqstNoiseHistogramReportingCondition OBJECT-TYPE
2899
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX INTEGER {
afterEveryMeasurement(0),
aNPIAboveReference(1),
aNPIBelowReference(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates when the Noise Histogram Measurement results are
to be reported to the requesting STA. This attribute is valid only if the
dot11RMRqstType is 4, indicating a Noise Histogram request, and is ignored
otherwise."
REFERENCE
"IEEE Std 802.11, Table 9-86-Reporting Condition for Noise Histogram report"
DEFVAL {0}
::= { dot11RMRequestEntry 47 }
dot11RMRqstAnpiReference OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the noise histogram reporting condition ANPI
reference value. The measured ANPI is compared to this reference value and
a report is issued if the indicated reporting condition is satisfied.
ANPIval = Floor((ANPIpower in dBm + 110)*2), for ANPI in the range -110
dBm to 0 dBm. ANPIval = 220 for ANPI > 0 dBm. ANPIval = 255 when ANPI is
not available. This attribute is valid only if the dot11RMRqstType is 4,
indicating a Noise Histogram request, and is ignored otherwise."
DEFVAL { 5 }
::= { dot11RMRequestEntry 48 }
dot11RMRqstAPChannelReport OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the specific channels to be used for the
requested beacon measurements. The default value is null. Each octet
indicates a different channel within the indicated Operating Class. This
list of channels is the Channel List in the AP Channel Report element
described in 9.4.2.36. This attribute is valid only if the dot11RMRqstType
is 5, indicating a Beacon request, and is ignored otherwise."
DEFVAL { ''H }
::= { dot11RMRequestEntry 49 }
dot11RMRqstSTAStatPeerSTAAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
2900
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the peer STA address to be measured for a STA
statistics request. This attribute is valid only if the dot11RMRqstType is
7, indicating a statistics request, and is ignored otherwise."
::= { dot11RMRequestEntry 50 }
dot11RMRqstFrameTransmitterAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute indicates the Transmitter Address (TA) of the frames to be
counted in this Frame request. This attribute is valid only if the
dot11RMRqstType is 6, indicating a Frame request, and is ignored
otherwise."
::= { dot11RMRequestEntry 51 }
dot11RMRqstVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when requesting a
measurement.
Changes take effect when dot11RMRqstRowStatus is set to Active.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a Measurement Request element. The
default value is null. This attribute is valid for all requests."
DEFVAL { ''H }
::= { dot11RMRequestEntry 52 }
dot11RMRqstSTAStatTrigMeasCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the number of MSDUs or MPDUs over which the
trigger criterion is applied. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics) and if the value of the attribute is
not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 53 }
dot11RMRqstSTAStatTrigTimeout OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
UNITS "100 TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the interval during which a measuring STA does
not generate further triggered STA Statistics reports after a trigger
condition has been met. This attribute is valid only if dot11RMRqstType is
2901
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
7 (STA Statistics)."
DEFVAL { 0 }
::= { dot11RMRequestEntry 54 }
dot11RMRqstSTAStatTrigCondition OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the trigger values used when requesting
triggered STA Statistics
reporting. The format of the STA Counter Trigger Condition field is shown
in Figure 9-161."
::= { dot11RMRequestEntry 55 }
dot11RMRqstSTAStatTrigSTAFailedCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11FailedCount value has increased more than the
threshold value indicated here. The counter increase is measured over the
last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 56 }
dot11RMRqstSTAStatTrigSTAFCSErrCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11FCSErrorCount value has increased more than the
threshold value indicated here. The counter increase is measured over the
last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 57 }
dot11RMRqstSTAStatTrigSTAMultRetryCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11MultipleRetryCount value has increased more than
the threshold value indicated here. The counter increase is measured over
the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 58 }
dot11RMRqstSTAStatTrigSTAFrameDupeCntThresh OBJECT-TYPE
2902
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11FrameDuplicateCount value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 59 }
dot11RMRqstSTAStatTrigSTARTSFailCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RTSFailureCount value has increased more than
the threshold value indicated here. The counter increase is measured over
the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 60 }
dot11RMRqstSTAStatTrigSTAAckFailCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11AckFailureCount value has increased more than
the threshold value indicated here. The counter increase is measured over
the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 61 }
dot11RMRqstSTAStatTrigSTARetryCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RetryCount value has increased more than the
threshold value indicated here. The counter increase is measured over the
last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 62 }
dot11RMRqstSTAStatTrigQoSTrigCondition OBJECT-TYPE
2903
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX OCTET STRING (SIZE(2))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the trigger values used when requesting
triggered QoS STA Statistics
reporting. The format of the STA Counter Trigger Condition field is shown
in Figure 9-163."
::= { dot11RMRequestEntry 63 }
dot11RMRqstSTAStatTrigQoSFailedCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11QosFailedCount value has increased more than the
threshold value indicated here. The counter increase is measured over the
last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the
value of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 64 }
dot11RMRqstSTAStatTrigQoSRetryCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11QosRetryCount value has increased more than the
threshold value indicated here. The counter increase is measured over the
last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the
value of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 65 }
dot11RMRqstSTAStatTrigQoSMultRetryCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11QosMultipleRetryCount value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the
value of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 66 }
dot11RMRqstSTAStatTrigQoSFrameDupeCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
2904
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(triggered) when the dot11QosFrameDuplicateCount value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the
value of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 67 }
dot11RMRqstSTAStatTrigQoSRTSFailCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11QosRTSFailureCount value has increased more than
the threshold value indicated here. The counter increase is measured over
the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the
value of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 68 }
dot11RMRqstSTAStatTrigQoSAckFailCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11QosAckFailureCount value has increased more than
the threshold value indicated here. The counter increase is measured over
the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the
value of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 69 }
dot11RMRqstSTAStatTrigQoSDiscardCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11QosDiscardedFrameCount value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the
value of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 70 }
dot11RMRqstSTAStatTrigRsnaTrigCondition OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the trigger values used when requesting
2905
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
triggered RSNA STA Statistics
reporting. The format of the STA Counter Trigger Condition field is shown
in Figure 9-165."
::= { dot11RMRequestEntry 71 }
dot11RMRqstSTAStatTrigRsnaCMACICVErrCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RSNAStatsBIPMICErrors value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 72 }
dot11RMRqstSTAStatTrigRsnaCMACReplayCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RSNAStatsCMACReplays value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 73 }
dot11RMRqstSTAStatTrigRsnaRobustCCMPReplayCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RSNAStatsRobustMgmtCCMPReplays value has
increased more than the threshold value indicated here. The counter
increase is measured over the last n MSDUs or MPDUs, where n is the value
of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 74 }
dot11RMRqstSTAStatTrigRsnaTKIPICVErrCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RSNAStatsTKIPICVErrors value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
2906
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 75 }
dot11RMRqstSTAStatTrigRsnaTKIPReplayCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RSNAStatsTKIPReplays value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 76 }
dot11RMRqstSTAStatTrigRsnaCCMPDecryptErrCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RSNAStatsCCMPDecryptErrors value has increased
more than the threshold value indicated here. The counter increase is
measured over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 77 }
dot11RMRqstSTAStatTrigRsnaCCMPReplayCntThresh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates that a STA Statistics report should be generated
(triggered) when the dot11RSNAStatsCCMPReplays value has increased more
than the threshold value indicated here. The counter increase is measured
over the last n MSDUs or MPDUs, where n is the value of
dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if
dot11RMRqstType is 7 (STA Statistics), and if
dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value
of the attribute is not equal to 0."
DEFVAL { 0 }
::= { dot11RMRequestEntry 78 }
-- **********************************************************************
-- * End of dot11RMRequest TABLE
-- **********************************************************************
-- ********************************************************************
-- * Radio Measurement Reports
-- * Report tables contain measurement reports received by this STA or
-- * results of measurements performed by this STA.
-- ********************************************************************
dot11RMReport OBJECT IDENTIFIER ::= { dot11RadioMeasurement 2 }
2907
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
-- * dot11ChannelLoadReport TABLE
-- ********************************************************************
dot11ChannelLoadReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11ChannelLoadReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the current list of Channel Load reports that have been
received by the MLME. The report tables are maintained as a FIFO to
preserve freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows have different RprtIndex values than those deleted within the
range limitation of the index. One easy way is to increment RprtIndex for
new reports being written in the table."
::= { dot11RMReport 1 }
dot11ChannelLoadReportEntry OBJECT-TYPE
SYNTAX Dot11ChannelLoadReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11ChannelLoadReportTable Indexed by
dot11ChannelLoadRprtIndex."
INDEX { dot11ChannelLoadRprtIndex }
::= { dot11ChannelLoadReportTable 1 }
Dot11ChannelLoadReportEntry ::=
SEQUENCE {
dot11ChannelLoadRprtIndex Unsigned32,
dot11ChannelLoadRprtRqstToken OCTET STRING,
dot11ChannelLoadRprtIfIndex InterfaceIndex,
dot11ChannelLoadMeasuringSTAAddr MacAddress,
dot11ChannelLoadRprtChanNumber Unsigned32,
dot11ChannelLoadRprtOperatingClass Unsigned32,
dot11ChannelLoadRprtActualStartTime TSFType,
dot11ChannelLoadRprtMeasurementDuration Unsigned32,
dot11ChannelLoadRprtChannelLoad Unsigned32,
dot11ChannelLoadRprtVendorSpecific OCTET STRING,
dot11ChannelLoadRprtMeasurementMode INTEGER }
dot11ChannelLoadRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Channel Load report elements in dot11ChannelLoadReportTable,
greater than 0."
::= { dot11ChannelLoadReportEntry 1 }
dot11ChannelLoadRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the request token that was indicated in the
Measurement request that generated this measurement report. This should be
an exact match to the original dot11RMRqstToken attribute. Note that there
may be multiple entries in the table that match this value since a single
request may generate multiple measurement reports."
::= { dot11ChannelLoadReportEntry 2 }
2908
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11ChannelLoadRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The ifIndex of the interface over which this ChannelLoad Report was
received."
::= { dot11ChannelLoadReportEntry 3 }
dot11ChannelLoadMeasuringSTAAddr OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The MAC address of the measuring STA for this row of the Channel Load
report."
::= { dot11ChannelLoadReportEntry 4 }
dot11ChannelLoadRprtChanNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel number used for this Channel Load
report. The Channel Number is defined only within the indicated Operating
Class for this measurement report."
::= { dot11ChannelLoadReportEntry 5 }
dot11ChannelLoadRprtOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel set for this measurement report.
Country, Operating Class and Channel Number together specify the channel
frequency and spacing for this measurement report. Valid values of
Operating Class are shown in Annex E."
REFERENCE "Annex E"
::= { dot11ChannelLoadReportEntry 6 }
dot11ChannelLoadRprtActualStartTime OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the TSF value at the time when the
measurement started."
::= { dot11ChannelLoadReportEntry 7 }
2909
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11ChannelLoadRprtMeasurementDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the duration over which the ChannelLoad Report
was measured."
::= { dot11ChannelLoadReportEntry 8 }
dot11ChannelLoadRprtChannelLoad OBJECT-TYPE
SYNTAX Unsigned32(0..255)
UNITS "1/255"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
Channel Load contains the fractional duration over which the measuring STA
determined the channel to be busy during the measurement duration."
REFERENCE "9.4.2.22.5"
::= { dot11ChannelLoadReportEntry 9 }
dot11ChannelLoadRprtVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a measurement report element. The
default value is null."
DEFVAL { ''H }
::= { dot11ChannelLoadReportEntry 10 }
dot11ChannelLoadRprtMeasurementMode OBJECT-TYPE
SYNTAX INTEGER {
success(0),
incapableBit(1),
refusedBit(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the outcome status for the measurement request
which generated this measurement report; status is indicated using the
following reason codes: 1 indicates this STA is incapable of generating
the report, 2 indicates this STA is refusing to generate the report, 0
indicates the STA successfully carried out the measurement request."
DEFVAL { 0 }
::= { dot11ChannelLoadReportEntry 11 }
-- ********************************************************************
-- * End of dot11ChannelLoadReport TABLE
2910
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
-- ********************************************************************
-- * dot11NoiseHistogramReport TABLE
-- ********************************************************************
dot11NoiseHistogramReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11NoiseHistogramReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the current list of Noise Histogram reports that have
been received by the MLME. The report tables are maintained as a FIFO to
preserve freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows have different RprtIndex values than those deleted within the
range limitation of the index. One easy way is to increment RprtIndex for
new reports being written in the table."
::= { dot11RMReport 2 }
dot11NoiseHistogramReportEntry OBJECT-TYPE
SYNTAX Dot11NoiseHistogramReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11NoiseHistogramReportTable Indexed by
dot11NoiseHistogramRprtIndex."
INDEX { dot11NoiseHistogramRprtIndex }
::= { dot11NoiseHistogramReportTable 1 }
Dot11NoiseHistogramReportEntry ::=
SEQUENCE {
dot11NoiseHistogramRprtIndex Unsigned32,
dot11NoiseHistogramRprtRqstToken OCTET STRING,
dot11NoiseHistogramRprtIfIndex InterfaceIndex,
dot11NoiseHistogramMeasuringSTAAddr MacAddress,
dot11NoiseHistogramRprtChanNumber Unsigned32,
dot11NoiseHistogramRprtOperatingClass Unsigned32,
dot11NoiseHistogramRprtActualStartTime TSFType,
dot11NoiseHistogramRprtMeasurementDuration Unsigned32,
dot11NoiseHistogramRprtAntennaID Unsigned32,
dot11NoiseHistogramRprtANPI Unsigned32,
dot11NoiseHistogramRprtIPIDensity0 Unsigned32,
dot11NoiseHistogramRprtIPIDensity1 Unsigned32,
dot11NoiseHistogramRprtIPIDensity2 Unsigned32,
dot11NoiseHistogramRprtIPIDensity3 Unsigned32,
dot11NoiseHistogramRprtIPIDensity4 Unsigned32,
dot11NoiseHistogramRprtIPIDensity5 Unsigned32,
dot11NoiseHistogramRprtIPIDensity6 Unsigned32,
dot11NoiseHistogramRprtIPIDensity7 Unsigned32,
dot11NoiseHistogramRprtIPIDensity8 Unsigned32,
dot11NoiseHistogramRprtIPIDensity9 Unsigned32,
dot11NoiseHistogramRprtIPIDensity10 Unsigned32,
dot11NoiseHistogramRprtVendorSpecific OCTET STRING,
dot11NoiseHistogramRprtMeasurementMode INTEGER}
dot11NoiseHistogramRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Noise Histogram elements in dot11NoiseHistogramReportTable,
greater than 0."
::= { dot11NoiseHistogramReportEntry 1 }
2911
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11NoiseHistogramRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the request token that was indicated in the
measurement request that generated this measurement report. This should be
an exact match to the original dot11RMRqstToken attribute. Note that there
may be multiple entries in the table that match this value since a single
request may generate multiple measurement reports."
::= { dot11NoiseHistogramReportEntry 2 }
dot11NoiseHistogramRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The ifIndex of the interface over which this Noise Histogram report was
received. "
::= { dot11NoiseHistogramReportEntry 3 }
dot11NoiseHistogramMeasuringSTAAddr OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The MAC address of the measuring STA for this row of Noise Histogram
report."
::= { dot11NoiseHistogramReportEntry 4 }
dot11NoiseHistogramRprtChanNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel number used for this Noise Histogram
report. The Channel Number is defined only within the indicated Operating
Class for this measurement report."
::= { dot11NoiseHistogramReportEntry 5 }
dot11NoiseHistogramRprtOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel set for this measurement report.
Country, Operating Class and Channel Number together specify the channel
frequency and spacing for this measurement report. Valid values of
Operating Class are shown in Annex E."
2912
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
REFERENCE "Annex E"
::= { dot11NoiseHistogramReportEntry 6 }
dot11NoiseHistogramRprtActualStartTime OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the TSF value at the time when the
measurement started."
::= { dot11NoiseHistogramReportEntry 7 }
dot11NoiseHistogramRprtMeasurementDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the duration over which the Noise Histogram
report was measured."
::= { dot11NoiseHistogramReportEntry 8 }
dot11NoiseHistogramRprtAntennaID OBJECT-TYPE
SYNTAX Unsigned32(0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the identifying number for the antenna used for
this measurement. The value 0 indicates that the antenna identifier is
unknown. The value 255 indicates that the measurement was made with
multiple antennas or that the antenna ID is unknown. The value 1 is used
for a STA with only one antenna. STAs with more than one antenna assign
Antenna IDs to each antenna as consecutive, ascending numbers. Each
Antenna ID number represents a unique antenna characterized by a fixed
relative position, a fixed relative direction, and a peak gain for that
position and direction."
::= { dot11NoiseHistogramReportEntry 9 }
dot11NoiseHistogramRprtANPI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the Average Noise Power Indicator (ANPI) for this
Noise Histogram measurement. The ANPI value represents the average noise
plus interference power on the measured channel at the antenna connector
during the measurement duration. To calculate ANPI, the STA measures and
uses IPI in the indicated channel when NAV is equal to 0 (when virtual CS
mechanism indicates idle channel) except during frame transmission or
reception."
::= { dot11NoiseHistogramReportEntry 10 }
2913
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11NoiseHistogramRprtIPIDensity0 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition: Power <= -92 dBm."
::= { dot11NoiseHistogramReportEntry 11 }
dot11NoiseHistogramRprtIPIDensity1 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition: -92 dBm < Power <= -
9 dBm."
::= { dot11NoiseHistogramReportEntry 12 }
dot11NoiseHistogramRprtIPIDensity2 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition: -89 dBm < Power <= -
86 dBm."
::= { dot11NoiseHistogramReportEntry 13 }
dot11NoiseHistogramRprtIPIDensity3 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition: -86 dBm < Power <= -
83 dBm."
::= { dot11NoiseHistogramReportEntry 14 }
dot11NoiseHistogramRprtIPIDensity4 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition: -83 dBm < Power <= -
80 dBm."
::= { dot11NoiseHistogramReportEntry 15 }
2914
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11NoiseHistogramRprtIPIDensity5 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition: -80 dBm < Power <= -
75 dBm."
::= { dot11NoiseHistogramReportEntry 16 }
dot11NoiseHistogramRprtIPIDensity6 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition:
-75 dBm < Power <= -70 dBm."
::= { dot11NoiseHistogramReportEntry 17 }
dot11NoiseHistogramRprtIPIDensity7 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition:
-70 dBm < Power <= -65 dBm."
::= { dot11NoiseHistogramReportEntry 18 }
dot11NoiseHistogramRprtIPIDensity8 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition:
-65 dBm < Power <= -60 dBm."
::= { dot11NoiseHistogramReportEntry 19 }
dot11NoiseHistogramRprtIPIDensity9 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition:
-60 dBm < Power <= -55 dBm."
::= { dot11NoiseHistogramReportEntry 20 }
2915
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11NoiseHistogramRprtIPIDensity10 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the measured IPI density for non-IEEE-802.11
signals with measured power satisfying the condition:
-55 dBm < Power."
::= { dot11NoiseHistogramReportEntry 21 }
dot11NoiseHistogramRprtVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a measurement report element. The
default value is null."
DEFVAL { ''H }
::= { dot11NoiseHistogramReportEntry 22 }
dot11NoiseHistogramRprtMeasurementMode OBJECT-TYPE
SYNTAX INTEGER {
success(0),
incapableBit(1),
refusedBit(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the outcome status for the measurement request
which generated this measurement report; status is indicated using the
following reason codes: 1 indicates this STA is incapable of generating
the report, 2 indicates this STA is refusing to generate the report, 0
indicates the STA successfully carried out the measurement request."
DEFVAL { 0 }
::= { dot11NoiseHistogramReportEntry 23 }
-- ********************************************************************
-- * End of dot11NoiseHistogramReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11BeaconReport TABLE
-- ********************************************************************
dot11BeaconReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11BeaconReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the current list of Beacon reports that have been
received by the MLME. The report tables are maintained as FIFO to preserve
freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows have different RprtIndex values than those deleted within the
2916
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
range limitation of the index. One easy way is to increment RprtIndex for
new reports being written in the table."
::= { dot11RMReport 3 }
dot11BeaconReportEntry OBJECT-TYPE
SYNTAX Dot11BeaconReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11BeaconReportTable Indexed by dot11BeaconRprtIndex."
INDEX { dot11BeaconRprtIndex }
::= { dot11BeaconReportTable 1 }
Dot11BeaconReportEntry ::=
SEQUENCE {
dot11BeaconRprtIndex Unsigned32,
dot11BeaconRprtRqstToken OCTET STRING,
dot11BeaconRprtIfIndex InterfaceIndex,
dot11BeaconMeasuringSTAAddr MacAddress,
dot11BeaconRprtChanNumber Unsigned32,
dot11BeaconRprtOperatingClass Unsigned32,
dot11BeaconRprtActualStartTime TSFType,
dot11BeaconRprtMeasurementDuration Unsigned32,
dot11BeaconRprtPhyType INTEGER,
dot11BeaconRprtReportedFrameType INTEGER,
dot11BeaconRprtRCPI Unsigned32,
dot11BeaconRprtRSNI Unsigned32,
dot11BeaconRprtBSSID MacAddress,
dot11BeaconRprtAntennaID Unsigned32,
dot11BeaconRprtParentTSF TSFType,
dot11BeaconRprtReportedFrameBody OCTET STRING,
dot11BeaconRprtVendorSpecific OCTET STRING,
dot11BeaconRprtMeasurementMode INTEGER}
dot11BeaconRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Beacon reports in dot11BeaconReportTable, greater than 0."
::= { dot11BeaconReportEntry 1 }
dot11BeaconRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the request token that was indicated in the
measurement request that generated this measurement report. This should be
an exact match to the original dot11RMRqstToken attribute. Note that there
may be multiple entries in the table that match this value since a single
request may generate multiple measurement reports."
::= { dot11BeaconReportEntry 2 }
dot11BeaconRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
2917
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The ifIndex of the interface over which this Beacon report was received."
::= { dot11BeaconReportEntry 3 }
dot11BeaconMeasuringSTAAddr OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The MAC address of the measuring STA for this row of Beacon report."
::= { dot11BeaconReportEntry 4 }
dot11BeaconRprtChanNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel number used for this Beacon report.
The Channel Number is defined only within the indicated Operating Class
for this measurement report."
::= { dot11BeaconReportEntry 5 }
dot11BeaconRprtOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel set for this measurement report.
Country, Operating Class and Channel Number together specify the channel
frequency and spacing for this measurement report. Valid values of
Operating Class are shown in Annex E."
REFERENCE "Annex E"
::= { dot11BeaconReportEntry 6 }
dot11BeaconRprtActualStartTime OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the TSF value at the time when the measurement
started."
::= { dot11BeaconReportEntry 7 }
dot11BeaconRprtMeasurementDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
2918
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the duration over which the Beacon report was
measured."
::= { dot11BeaconReportEntry 8 }
dot11BeaconRprtPhyType OBJECT-TYPE
SYNTAX INTEGER {
dsss(2),
ofdm(4),
hrdsss(5),
erp(6),
ht(7),
dmg(8),
vht(9),
tvht(10)}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the PHY Type for this row of Beacon report."
::= { dot11BeaconReportEntry 9 }
dot11BeaconRprtReportedFrameType OBJECT-TYPE
SYNTAX INTEGER { beaconOrProbeResponse(0), measurementPilot(1) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the frame type reported in
dot11BeaconRprtReportedFrameBody"
::= { dot11BeaconReportEntry 10 }
dot11BeaconRprtRCPI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the received channel power of the beacon or Probe
Response frame as defined 9.4.2.38.
RCPIval = Floor((RCPIpower in dBm + 110)*2), for RCPI in the range -110
dBm to 0 dBm. RCPIval = 220 for RCPI > 0 dBm. RCPIval = 255 when RCPI is
not available."
::= { dot11BeaconReportEntry 11 }
dot11BeaconRprtRSNI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the received signal-to-noise ratio of the beacon
or Probe Response frame. RSNI is the received signal-to-noise plus
interference ratio derived from the measured RCPI for the received frame
and from the measured ANPI for the channel used to receive the frame. RSNI
2919
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
is calculated by the ratio of the received signal power (RCPI - ANPI) over
the noise plus interference power (ANPI) where
RSNI = [(ratio(dB) + 10) * 2], for ratios in the range -10 dB to +118 dB."
::= { dot11BeaconReportEntry 12 }
dot11BeaconRprtBSSID OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the BSSID of the beacon for this row of Beacon
report."
::= { dot11BeaconReportEntry 13 }
dot11BeaconRprtAntennaID OBJECT-TYPE
SYNTAX Unsigned32(0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the identifying number for the antenna used for
this measurement. The value 0 indicates that the antenna identifier is
unknown. The value 255 indicates that this measurement was made with
multiple antennas. The value 1 is used for a STA with only one antenna.
STAs with more than one antenna assign Antenna IDs to each antenna as
consecutive, ascending numbers. Each Antenna ID number represents a unique
antenna characterized by a fixed relative position, a fixed relative
direction, and a peak gain for that position and direction."
::= { dot11BeaconReportEntry 14 }
dot11BeaconRprtParentTSF OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the TSF value of the serving measuring STA's TSF
value at the time the measuring STA received the Beacon or Probe Response
frame."
::= { dot11BeaconReportEntry 15 }
dot11BeaconRprtReportedFrameBody OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..100))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the fixed fields and elements from the frame body
of the Beacon, Measurement Pilot or Probe Response frame being received.
All reported TIM elements are truncated to 4 octets."
::= { dot11BeaconReportEntry 16 }
dot11BeaconRprtVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
2920
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a measurement report element. The
default value is null."
DEFVAL { ''H }
::= { dot11BeaconReportEntry 17 }
dot11BeaconRprtMeasurementMode OBJECT-TYPE
SYNTAX INTEGER {
success(0),
incapableBit(1),
refusedBit(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the outcome status for the measurement request
which generated this measurement report; status is indicated using the
following reason codes: 1 indicates this STA is incapable of generating
the report, 2 indicates this STA is refusing to generate the report, 0
indicates the STA successfully carried out the measurement request."
DEFVAL { 0 }
::= { dot11BeaconReportEntry 18 }
-- ********************************************************************
-- * End of dot11BeaconReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11FrameReport TABLE
-- ********************************************************************
dot11FrameReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11FrameReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the current list of Frame reports that have been
received by the MLME. The report tables are maintained as a FIFO to
preserve freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows have different RprtIndex values than those deleted within the
range limitation of the index. One easy way is to increment RprtIndex for
new reports being written in the table."
::= { dot11RMReport 4 }
dot11FrameReportEntry OBJECT-TYPE
SYNTAX Dot11FrameReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11FrameReportTable Indexed by dot11FrameRprtIndex."
INDEX { dot11FrameRprtIndex }
::= { dot11FrameReportTable 1 }
Dot11FrameReportEntry ::=
SEQUENCE {
dot11FrameRprtIndex Unsigned32,
dot11FrameRprtIfIndex InterfaceIndex,
2921
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11FrameRprtRqstToken Unsigned32,
dot11FrameRprtChanNumber Unsigned32,
dot11FrameRprtOperatingClass Unsigned32,
dot11FrameRprtActualStartTime TSFType,
dot11FrameRprtMeasurementDuration Unsigned32,
dot11FrameRprtTransmitSTAAddress MacAddress,
dot11FrameRprtBSSID MacAddress,
dot11FrameRprtPhyType INTEGER,
dot11FrameRprtAvgRCPI Unsigned32,
dot11FrameRprtLastRSNI Unsigned32,
dot11FrameRprtLastRCPI Unsigned32,
dot11FrameRprtAntennaID Unsigned32,
dot11FrameRprtNumberFrames Unsigned32,
dot11FrameRprtVendorSpecific OCTET STRING,
dot11FrameRptMeasurementMode INTEGER}
dot11FrameRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Frame reports in dot11FrameReportTable, greater than 0."
::= { dot11FrameReportEntry 1 }
dot11FrameRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The ifIndex of the interface over which this Frame report was received."
::= { dot11FrameReportEntry 2 }
dot11FrameRprtRqstToken OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
INDEX for Frame requests in dot11FrameRequestTable that corresponds to
this row of frame report. Since a single Frame request can generate
multiple rows in the frame report table, one per BSSID, this
dot11FrameRprtRqstToken indicates which request this particular row
indicates. If this row of report is received without a particular request,
this attribute should be 0"
::= { dot11FrameReportEntry 3 }
dot11FrameRprtChanNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel number used for this Frame report.
The Channel Number is defined only within the indicated Operating Class
for this measurement report."
::= { dot11FrameReportEntry 4 }
2922
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11FrameRprtOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel set for this measurement report.
Country, Operating Class and Channel Number together specify the channel
frequency and spacing for this measurement report. Valid values of
Operating Class are shown in Annex E."
REFERENCE "Annex E"
::= { dot11FrameReportEntry 5 }
dot11FrameRprtActualStartTime OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the TSF value at the time when measurement
started."
::= { dot11FrameReportEntry 6 }
dot11FrameRprtMeasurementDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the duration over which the Frame report was
measured"
::= { dot11FrameReportEntry 7 }
dot11FrameRprtTransmitSTAAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The MAC address of STA for this row of Frame report that it has been
received from."
::= { dot11FrameReportEntry 8 }
dot11FrameRprtBSSID OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the BSSID of the STA that transmitted this
frame."
::= { dot11FrameReportEntry 9 }
2923
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11FrameRprtPhyType OBJECT-TYPE
SYNTAX INTEGER {
dsss(2),
ofdm(4),
hrdsss(5),
erp(6),
ht(7),
dmg(8),
vht(9),
tvht(10) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the PHY used for frame reception in this row of
the frame report."
::= { dot11FrameReportEntry 10 }
dot11FrameRprtAvgRCPI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the average value for the received channel power
of all of the frames received and counted in this frame report entry as
defined 9.4.2.38.
RCPIval = Floor((RCPIpower in dBm + 110)*2), for RCPI in the range -110
dBm to 0 dBm. RCPIval = 220 for RCPI > 0 dBm. RCPIval = 255 when RCPI is
not available."
::= { dot11FrameReportEntry 11 }
dot11FrameRprtLastRSNI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the received signal-to-noise ratio of the
received frame. RSNI is the received signal-to-noise plus interference
ratio derived from the RCPI for the received frame and from the most
recent ANPI value measured on the channel used to receive the frame. RSNI
may be calculated by the ratio of the received signal power (RCPI - ANPI)
over the noise plus interference power (ANPI) where RSNI = [(ratio(dB) +
10) * 2], for ratios in the range -10 dB to +118 dB. Other measurement
techniques are allowed."
::= { dot11FrameReportEntry 12 }
dot11FrameRprtLastRCPI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
2924
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the received channel power of the most recently
measured frame in this frame report entry as defined 9.4.2.38.
RCPIval = Floor((RCPIpower in dBm + 110)*2), for RCPI in the range -110
dBm to 0 dBm. RCPIval = 220 for RCPI > 0 dBm. RCPIval = 255 when RCPI is
not available."
::= { dot11FrameReportEntry 13 }
dot11FrameRprtAntennaID OBJECT-TYPE
SYNTAX Unsigned32(0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the identifying number for the antenna used for
this measurement. The value 0 indicates that the antenna identifier is
unknown. The value 255 indicates that this measurement was made with
multiple antennas. The value 1 is used for a STA with only one antenna.
STAs with more than one antenna assign Antenna IDs to each antenna as
consecutive, ascending numbers. Each Antenna ID number represents a
unique antenna characterized by a fixed relative position, a fixed
relative direction, and a peak gain for that position and direction."
::= { dot11FrameReportEntry 14 }
dot11FrameRprtNumberFrames OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the number of received frames in the Measurement
Report frame for this row of the Frame report."
::= { dot11FrameReportEntry 15 }
dot11FrameRprtVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a measurement report element. The
default value is null."
DEFVAL { ''H }
::= { dot11FrameReportEntry 16 }
dot11FrameRptMeasurementMode OBJECT-TYPE
SYNTAX INTEGER {
success(0),
incapableBit(1),
refusedBit(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the outcome status for the measurement request
2925
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
which generated this measurement report; status is indicated using the
following reason codes: 1 indicates this STA is incapable of generating
the report, 2 indicates this STA is refusing to generate the report, 0
indicates the STA successfully carried out the measurement request."
DEFVAL { 0 }
::= { dot11FrameReportEntry 17 }
-- ********************************************************************
-- * End of dot11FrameReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11STAStatisticsReport TABLE
-- ********************************************************************
dot11STAStatisticsReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11STAStatisticsReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the current list of STA Statistics reports that have
been received by the MLME. The report tables are maintained as a FIFO to
preserve freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows have different RprtIndex values than those deleted within the
range limitation of the index. One easy way is to increment RprtIndex for
new reports being written in the table."
::= { dot11RMReport 5 }
dot11STAStatisticsReportEntry OBJECT-TYPE
SYNTAX Dot11STAStatisticsReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11STAStatisticsReportTable Indexed by
dot11STAStatisticsReportIndex."
INDEX { dot11STAStatisticsReportIndex }
::= { dot11STAStatisticsReportTable 1 }
Dot11STAStatisticsReportEntry ::=
SEQUENCE {
dot11STAStatisticsReportIndex Unsigned32,
dot11STAStatisticsReportToken OCTET STRING,
dot11STAStatisticsIfIndex InterfaceIndex,
dot11STAStatisticsSTAAddress MacAddress,
dot11STAStatisticsMeasurementDuration Unsigned32,
dot11STAStatisticsGroupID INTEGER,
dot11STAStatisticsTransmittedFragmentCount Counter32,
dot11STAStatisticsGroupTransmittedFrameCount Counter32,
dot11STAStatisticsFailedCount Counter32,
dot11STAStatisticsRetryCount Counter32,
dot11STAStatisticsMultipleRetryCount Counter32,
dot11STAStatisticsFrameDuplicateCount Counter32,
dot11STAStatisticsRTSSuccessCount Counter32,
dot11STAStatisticsRTSFailureCount Counter32,
dot11STAStatisticsAckFailureCount Counter32,
dot11STAStatisticsQosTransmittedFragmentCount Counter32,
dot11STAStatisticsQosFailedCount Counter32,
dot11STAStatisticsQosRetryCount Counter32,
dot11STAStatisticsQosMultipleRetryCount Counter32,
dot11STAStatisticsQosFrameDuplicateCount Counter32,
dot11STAStatisticsQosRTSSuccessCount Counter32,
dot11STAStatisticsQosRTSFailureCount Counter32,
dot11STAStatisticsQosAckFailureCount Counter32,
dot11STAStatisticsQosReceivedFragmentCount Counter32,
2926
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11STAStatisticsQosTransmittedFrameCount Counter32,
dot11STAStatisticsQosDiscardedFrameCount Counter32,
dot11STAStatisticsQosMPDUsReceivedCount Counter32,
dot11STAStatisticsQosRetriesReceivedCount Counter32,
dot11STAStatisticsReceivedFragmentCount Counter32,
dot11STAStatisticsGroupReceivedFrameCount Counter32,
dot11STAStatisticsFCSErrorCount Counter32,
dot11STAStatisticsTransmittedFrameCount Counter32,
dot11STAStatisticsAPAverageAccessDelay Unsigned32,
dot11STAStatisticsAverageAccessDelayBestEffort Unsigned32,
dot11STAStatisticsAverageAccessDelayBackground Unsigned32,
dot11STAStatisticsAverageAccessDelayVideo Unsigned32,
dot11STAStatisticsAverageAccessDelayVoice Unsigned32,
dot11STAStatisticsStationCount Unsigned32,
dot11STAStatisticsChannelUtilization Unsigned32,
dot11STAStatisticsVendorSpecific OCTET STRING,
dot11STAStatisticsRprtMeasurementMode INTEGER,
dot11STAStatisticsRSNAStatsBIPMICErrors Counter32,
dot11STAStatisticsRSNAStatsCMACReplays Counter32,
dot11STAStatisticsRSNAStatsRobustMgmtCCMPReplays Counter32,
dot11STAStatisticsRSNAStatsTKIPICVErrors Counter32,
dot11STAStatisticsRSNAStatsTKIPReplays Counter32,
dot11STAStatisticsRSNAStatsCCMPDecryptErrors Counter32,
dot11STAStatisticsRSNAStatsCCMPReplays Counter32,
dot11STAStatisticsReportingReasonSTACounters OCTET STRING,
dot11STAStatisticsReportingReasonQosCounters OCTET STRING,
dot11STAStatisticsReportingReasonRsnaCounters OCTET STRING,
dot11STAStatisticsTransmittedAMSDUCount Counter32,
dot11STAStatisticsFailedAMSDUCount Counter32,
dot11STAStatisticsRetryAMSDUCount Counter32,
dot11STAStatisticsMultipleRetryAMSDUCount Counter32,
dot11STAStatisticsTransmittedOctetsInAMSDUCount Counter64,
dot11STAStatisticsAMSDUAckFailureCount Counter32,
dot11STAStatisticsReceivedAMSDUCount Counter32,
dot11STAStatisticsReceivedOctetsInAMSDUCount Counter64,
dot11STAStatisticsTransmittedAMPDUCount Counter32,
dot11STAStatisticsTransmittedMPDUsInAMPDUCount Counter32,
dot11STAStatisticsTransmittedOctetsInAMPDUCount Counter64,
dot11STAStatisticsAMPDUReceivedCount Counter32,
dot11STAStatisticsMPDUInReceivedAMPDUCount Counter32,
dot11STAStatisticsReceivedOctetsInAMPDUCount Counter64,
dot11STAStatisticsAMPDUDelimiterCRCErrorCount Counter32,
dot11STAStatisticsImplicitBARFailureCount Counter32,
dot11STAStatisticsExplicitBARFailureCount Counter32,
dot11STAStatisticsChannelWidthSwitchCount Counter32,
dot11STAStatisticsTwentyMHzFrameTransmittedCount Counter32,
dot11STAStatisticsFortyMHzFrameTransmittedCount Counter32,
dot11STAStatisticsTwentyMHzFrameReceivedCount Counter32,
dot11STAStatisticsFortyMHzFrameReceivedCount Counter32,
dot11STAStatisticsPSMPUTTGrantDuration Counter32,
dot11STAStatisticsPSMPUTTUsedDuration Counter32,
dot11STAStatisticsGrantedRDGUsedCount Counter32,
dot11STAStatisticsGrantedRDGUnusedCount Counter32,
dot11STAStatisticsTransmittedFramesInGrantedRDGCount Counter32,
dot11STAStatisticsTransmittedOctetsInGrantedRDGCount Counter64,
dot11STAStatisticsDualCTSSuccessCount Counter32,
dot11STAStatisticsDualCTSFailureCount Counter32,
dot11STAStatisticsRTSLSIGSuccessCount Counter32,
dot11STAStatisticsRTSLSIGFailureCount Counter32,
dot11STAStatisticsBeamformingFrameCount Counter32,
dot11STAStatisticsSTBCCTSSuccessCount Counter32,
dot11STAStatisticsSTBCCTSFailureCount Counter32,
dot11STAStatisticsnonSTBCCTSSuccessCount Counter32,
dot11STAStatisticsnonSTBCCTSFailureCount Counter32,
2927
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11STAStatisticsAverageMSDUSizeVideo Unsigned32,
dot11STAStatisticsAverageMSDUSizeVoice Unsigned32,
dot11STAStatisticsAverageBitrateVideo Unsigned32,
dot11STAStatisticsAverageBitrateVoice Unsigned32
}
dot11STAStatisticsReportIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for STA Statistics reports in dot11STAStatisticsReportTable,
greater than 0."
::= { dot11STAStatisticsReportEntry 1 }
dot11STAStatisticsReportToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the token that was indicated in the measurement
request that generated this measurement report. This should be an exact
match to the original dot11RMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple measurement reports."
::= { dot11STAStatisticsReportEntry 2 }
dot11STAStatisticsIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
Identifies the Interface that this row of STA Statistics report has been
received on"
::= { dot11STAStatisticsReportEntry 3 }
dot11STAStatisticsSTAAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The MAC address of the STA that returned this STA Statistics report."
::= { dot11STAStatisticsReportEntry 4 }
dot11STAStatisticsMeasurementDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the duration over which the STA Statistics was
measured. The value 0 for this attribute indicates that the reported
2928
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
statistics are a current snapshot of the statistics variables. A nonzero
value for this attribute indicates that the reported statistics contain
the difference in the corresponding statistics variables over the
indicated duration."
::= { dot11STAStatisticsReportEntry 5 }
dot11STAStatisticsGroupID OBJECT-TYPE
SYNTAX INTEGER {
dot11CountersTable(0),
dot11MacStatistics(1),
dot11QosCountersTableforUP0(2),
dot11QosCountersTableforUP1(3),
dot11QosCountersTableforUP2(4),
dot11QosCountersTableforUP3(5),
dot11QosCountersTableforUP4(6),
dot11QosCountersTableforUP5(7),
dot11QosCountersTableforUP6(8),
dot11QosCountersTableforUP7(9),
bSSAverageAccessDelays(10),
dot11CountersGroup3Tablefor31(11),
dot11CountersGroup3Tablefor32(12),
dot11CountersGroup3Tablefor33(13),
dot11CountersGroup3Tablefor34(14),
dot11CountersGroup3Tablefor35(15),
dot11RSNAStatsTable(16) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the value of dot11RMRqstSTAStatRqstGroupID
returned from the STA in this STA Statistics report."
DEFVAL { 0 }
::= { dot11STAStatisticsReportEntry 6 }
dot11STAStatisticsTransmittedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11TransmittedFragmentCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 0 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 7 }
dot11STAStatisticsGroupTransmittedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11GroupTransmittedFrameCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
2929
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 0 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 8 }
dot11STAStatisticsFailedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11FailedCount returned from the STA in this STA Statistics
report. If dot11STAStatisticsMeasurementDuration indicates a nonzero
value, this attribute indicates the difference in the referenced dot11
variable over the indicated duration. This attribute is valid only if the
dot11STAStatisticsGroupID is 0 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 9 }
dot11STAStatisticsRetryCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RetryCount returned from the STA in this STA Statistics
report. If dot11STAStatisticsMeasurementDuration indicates a nonzero
value, this attribute indicates the difference in the referenced dot11
variable over the indicated duration. This attribute is valid only if the
dot11STAStatisticsGroupID is 1 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 10 }
dot11STAStatisticsMultipleRetryCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11MultipleRetryCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 1 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 11 }
dot11STAStatisticsFrameDuplicateCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11FrameDuplicateCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
2930
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 1 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 12 }
dot11STAStatisticsRTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RTSSuccessCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 1 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 13 }
dot11STAStatisticsRTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RTSFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 1 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 14 }
dot11STAStatisticsAckFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11AckFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 1 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 15 }
dot11STAStatisticsQosTransmittedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosTransmittedFragmentCount returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
2931
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 16 }
dot11STAStatisticsQosFailedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosFailedCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 17 }
dot11STAStatisticsQosRetryCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosRetryCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 18 }
dot11STAStatisticsQosMultipleRetryCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosMultipleRetryCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 19 }
dot11STAStatisticsQosFrameDuplicateCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosFrameDuplicateCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
2932
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 20 }
dot11STAStatisticsQosRTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosRTSSuccessCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 21 }
dot11STAStatisticsQosRTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosRTSFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 22 }
dot11STAStatisticsQosAckFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosAckFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 23 }
dot11STAStatisticsQosReceivedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosReceivedFragmentCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
2933
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 24 }
dot11STAStatisticsQosTransmittedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosTransmittedFrameCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 25 }
dot11STAStatisticsQosDiscardedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosDiscardedFrameCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 26 }
dot11STAStatisticsQosMPDUsReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosMPDUsReceivedCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 27 }
dot11STAStatisticsQosRetriesReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11QosRetriesReceivedCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
2934
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 28 }
dot11STAStatisticsReceivedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11ReceivedFragmentCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 0 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 29 }
dot11STAStatisticsGroupReceivedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11GroupReceivedFrameCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 0 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 30 }
dot11STAStatisticsFCSErrorCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11FCSErrorCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 0 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 31 }
dot11STAStatisticsTransmittedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11TransmittedFrameCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
2935
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 0 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 32 }
dot11STAStatisticsAPAverageAccessDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of the AP Average Access Delay (AAD) returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced access delay value over the indicated duration. This attribute
is valid only if the dot11STAStatisticsGroupID is 10 and is ignored
otherwise."
REFERENCE
"IEEE Std 802.11 9.4.2.39"
::= { dot11STAStatisticsReportEntry 33 }
dot11STAStatisticsAverageAccessDelayBestEffort OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of the Average Access Delay (AAD) for the Best Effort Access
Category returned from the STA in this STA Statistics report. If
dot11STAStatisticsMeasurementDuration indicates a nonzero value, this
attribute indicates the difference in the referenced access delay value
over the indicated duration. This attribute is valid only if the
dot11STAStatisticsGroupID is 10 and is ignored otherwise."
REFERENCE
"IEEE Std 802.11 9.4.2.44"
::= { dot11STAStatisticsReportEntry 34 }
dot11STAStatisticsAverageAccessDelayBackground OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of the Average Access Delay (AAD) for the Background Access
Category returned from the STA in this STA Statistics report. If
dot11STAStatisticsMeasurementDuration indicates a nonzero value, this
attribute indicates the difference in the referenced access delay value
over the indicated duration. This attribute is valid only if the
dot11STAStatisticsGroupID is 10 and is ignored otherwise."
REFERENCE
"IEEE Std 802.11 9.4.2.44"
::= { dot11STAStatisticsReportEntry 35 }
dot11STAStatisticsAverageAccessDelayVideo OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
2936
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of the Average Access Delay (AAD) for the Video Access Category
returned from the STA in this STA Statistics report. If
dot11STAStatisticsMeasurementDuration indicates a nonzero value, this
attribute indicates the difference in the referenced access delay value
over the indicated duration. This attribute is valid only if the
dot11STAStatisticsGroupID is 10 and is ignored otherwise."
REFERENCE
"IEEE Std 802.11 9.4.2.44"
::= { dot11STAStatisticsReportEntry 36 }
dot11STAStatisticsAverageAccessDelayVoice OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of the Average Access Delay (AAD) for the Voice Access Category
returned from the STA in this STA Statistics report. If
dot11STAStatisticsMeasurementDuration indicates a nonzero value, this
attribute indicates the difference in the referenced access delay value
over the indicated duration. This attribute is valid only if the
dot11STAStatisticsGroupID is 10 and is ignored otherwise."
REFERENCE
"IEEE Std 802.11 9.4.2.44"
::= { dot11STAStatisticsReportEntry 37 }
dot11STAStatisticsStationCount OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11AssociatedStationCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 10 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 38 }
dot11STAStatisticsChannelUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "1/255"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of the Channel Utilization returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
2937
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
nonzero value, this attribute indicates the difference in the Channel
Utilization value over the indicated duration. The Channel Utilization is
the time fraction during which the AP sensed the channel busy. This
attribute is valid only if the dot11STAStatisticsGroupID is 10 and is
ignored otherwise."
REFERENCE
"IEEE Std 802.11 9.4.2.28"
::= { dot11STAStatisticsReportEntry 39 }
dot11STAStatisticsVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a measurement report element. The
default value is null."
DEFVAL { ''H }
::= { dot11STAStatisticsReportEntry 40 }
dot11STAStatisticsRprtMeasurementMode OBJECT-TYPE
SYNTAX INTEGER {
success(0),
incapableBit(1),
refusedBit(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the outcome status for the measurement request
which generated this measurement report; status is indicated using the
following reason codes: 1 indicates this STA is incapable of generating
the report, 2 indicates this STA is refusing to generate the report, 0
indicates the STA successfully carried out the measurement request."
DEFVAL { 0 }
::= { dot11STAStatisticsReportEntry 41 }
dot11STAStatisticsRSNAStatsBIPMICErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RSNAStatsBIPMICErrors returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 16 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 42 }
dot11STAStatisticsRSNAStatsCMACReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
2938
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RSNAStatsCMACReplays returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 16 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 43 }
dot11STAStatisticsRSNAStatsRobustMgmtCCMPReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RSNAStatsRobustMgmtCCMPReplays returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 16 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 44 }
dot11STAStatisticsRSNAStatsTKIPICVErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RSNAStatsTKIPICVErrors returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 16 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 45 }
dot11STAStatisticsRSNAStatsTKIPReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RSNAStatsTKIPReplays returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 16 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 46 }
dot11STAStatisticsRSNAStatsCCMPDecryptErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
2939
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RSNAStatsCCMPDecryptErrors returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 16 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 47 }
dot11STAStatisticsRSNAStatsCCMPReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates
the value of dot11RSNAStatsCCMPReplays returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 16 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 48 }
dot11STAStatisticsReportingReasonSTACounters OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the trigger reason(s) for this Statistics report.
Each bit indicates a different trigger condition. When the bit is set to
1, it indicates that the listed trigger threshold has been exceeded:
B0 (least significant bit): dot11Failed,
B1: dot11FCSError,
B2: dot11MultipleRetry,
B3: dot11FrameDuplicate,
B4: dot11RTSFailure,
B5: dot11AckFailureCount,
B6: dot11Retry,
B7: Reserved.
This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is
ignored otherwise."
::= { dot11STAStatisticsReportEntry 49 }
dot11STAStatisticsReportingReasonQosCounters OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the trigger reason(s) for this Statistics report.
Each bit indicates a different trigger condition. When the bit is set to
1, it indicates that the listed trigger threshold has been exceeded:
B0 (least significant bit): dot11QoSFailed,
B1: dot11QoSRetry,
2940
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
B2: dot11QoSMultipleRetry,
B3: dot11QoSFrameDuplicate,
B4: dot11QoSRTSFailure,
B5: dot11QoSAckFailure,
B6: dot11QoSDiscarded,
B7: Reserved.
This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and
is ignored otherwise."
::= { dot11STAStatisticsReportEntry 50 }
dot11STAStatisticsReportingReasonRsnaCounters OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the trigger reason(s) for this Statistics report.
Each bit indicates a different trigger condition. When the bit is set to
1, it indicates that the listed trigger threshold has been exceeded:
B0 (least significant bit): dot11RSNAStatsBIPMICErrors,
B1: dot11RSNAStatsCMACReplays,
B2: dot11RSNAStatsRobustMgmtCCMPReplays,
B3: dot11RSNAStatsTKIPICVErrors,
B4: dot11RSNAStatsCCMPReplays,
B5: dot11RSNAStatsCCMPDecryptErrors,
B6: dot11RSNAStatsCCMPReplays,
B7: Reserved.
This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is
ignored otherwise."
::= { dot11STAStatisticsReportEntry 51 }
dot11STAStatisticsTransmittedAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TransmittedAMSDUCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 11 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 52 }
dot11STAStatisticsFailedAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11FailedAMSDUCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 11 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 53 }
2941
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11STAStatisticsRetryAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11RetryAMSDUCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 11 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 54 }
dot11STAStatisticsMultipleRetryAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11MultipleRetryAMSDUCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 11 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 55 }
dot11STAStatisticsTransmittedOctetsInAMSDUCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TransmittedOctetsInAMSDUCount returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 11 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 56 }
dot11STAStatisticsAMSDUAckFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11AMSDUAckFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 11 and is ignored otherwise."
2942
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11STAStatisticsReportEntry 57 }
dot11STAStatisticsReceivedAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11ReceivedAMSDUCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 11 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 58 }
dot11STAStatisticsReceivedOctetsInAMSDUCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11ReceivedOctetsInAMSDUCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 11 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 59 }
dot11STAStatisticsTransmittedAMPDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TransmittedAMPDUCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 12 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 60 }
dot11STAStatisticsTransmittedMPDUsInAMPDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TransmittedMPDUsInAMPDUCount returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 12 and is ignored
2943
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
otherwise."
::= { dot11STAStatisticsReportEntry 61 }
dot11STAStatisticsTransmittedOctetsInAMPDUCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TransmittedOctetsInAMPDUCount returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 12 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 62 }
dot11STAStatisticsAMPDUReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11AMPDUReceivedCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 12 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 63 }
dot11STAStatisticsMPDUInReceivedAMPDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11MPDUInReceivedAMPDUCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 12 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 64 }
dot11STAStatisticsReceivedOctetsInAMPDUCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11ReceivedOctetsInAMPDUCount returned from the STA in this
2944
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 12 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 65 }
dot11STAStatisticsAMPDUDelimiterCRCErrorCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11AMPDUDelimiterCRCErrorCount returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 12 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 66 }
dot11STAStatisticsImplicitBARFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11ImplicitBARFailureCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 13 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 67 }
dot11STAStatisticsExplicitBARFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11ExplicitBARFailureCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 13 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 68 }
dot11STAStatisticsChannelWidthSwitchCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
2945
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11ChannelWidthSwitchCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 13 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 69 }
dot11STAStatisticsTwentyMHzFrameTransmittedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TwentyMHzFrameTransmittedCount returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 13 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 70 }
dot11STAStatisticsFortyMHzFrameTransmittedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11FortyMHzFrameTransmittedCount returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 13 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 71 }
dot11STAStatisticsTwentyMHzFrameReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TwentyMHzFrameReceivedCount returned from the STA in
this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 13 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 72 }
dot11STAStatisticsFortyMHzFrameReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
2946
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11FortyMHzFrameReceivedCount returned from the STA in this
STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates
a nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 13 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 73 }
dot11STAStatisticsPSMPUTTGrantDuration OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11PSMPUTTGrantDuration returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 13 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 74 }
dot11STAStatisticsPSMPUTTUsedDuration OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11PSMPUTTUsedDuration returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 13 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 75 }
dot11STAStatisticsGrantedRDGUsedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11GrantedRDGUsedCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 14 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 76 }
dot11STAStatisticsGrantedRDGUnusedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
2947
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11GrantedRDGUnusedCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 14 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 77 }
dot11STAStatisticsTransmittedFramesInGrantedRDGCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TransmittedFramesInGrantedRDGCount returned from the STA
in this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 14 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 78 }
dot11STAStatisticsTransmittedOctetsInGrantedRDGCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11TransmittedOctetsInGrantedRDGCount returned from the STA
in this STA Statistics report. If dot11STAStatisticsMeasurementDuration
indicates a nonzero value, this attribute indicates the difference in the
referenced dot11 variable over the indicated duration. This attribute is
valid only if the dot11STAStatisticsGroupID is 14 and is ignored
otherwise."
::= { dot11STAStatisticsReportEntry 79 }
dot11STAStatisticsDualCTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11DualCTSSuccessCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 14 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 80 }
dot11STAStatisticsDualCTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
2948
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11DualCTSFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 14 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 81 }
dot11STAStatisticsRTSLSIGSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11RTSLSIGSuccessCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 14 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 82 }
dot11STAStatisticsRTSLSIGFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11RTSLSIGFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 14 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 83 }
dot11STAStatisticsBeamformingFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11BeamformingFrameCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 15 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 84 }
dot11STAStatisticsSTBCCTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
2949
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11STBCCTSSuccessCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 15 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 85 }
dot11STAStatisticsSTBCCTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11STBCCTSFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 15 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 86 }
dot11STAStatisticsnonSTBCCTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11nonSTBCCTSSuccessCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 15 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 87 }
dot11STAStatisticsnonSTBCCTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of dot11nonSTBCCTSFailureCount returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
dot11 variable over the indicated duration. This attribute is valid only
if the dot11STAStatisticsGroupID is 15 and is ignored otherwise."
::= { dot11STAStatisticsReportEntry 88 }
dot11STAStatisticsAverageMSDUSizeVideo OBJECT-TYPE
SYNTAX Unsigned32 (0..7935)
MAX-ACCESS read-write
2950
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed or
by an external management entity.
Changes from an external management entity take effect as soon as
practical in the implementation.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of the Average MSDU size for the Video Access Category returned
from the STA in this STA Statistics report. If
dot11STAStatisticsMeasurementDuration indicates a nonzero value, this
attribute indicates the difference in the referenced size over the
indicated duration. Changes by an external management entity are ignored
when dot11STAStatisticsMeasurementDuration is nonzero."
DEFVAL { 1401 }
::= { dot11STAStatisticsReportEntry 89 }
dot11STAStatisticsAverageMSDUSizeVoice OBJECT-TYPE
SYNTAX Unsigned32 (0.. 7935)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed or by an
external management entity. Changes from an external management entity
take effect as soon as practical in the implementation.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of the Average MSDU size for the Voice Access Category returned
from the STA in this STA Statistics report. If
dot11STAStatisticsMeasurementDuration indicates a nonzero value, this
attribute indicates the difference in the referenced size over the
indicated duration. Changes by an external management entity are ignored
when dot11STAStatisticsMeasurementDuration is nonzero."
DEFVAL { 365 }
::= { dot11STAStatisticsReportEntry 90 }
dot11STAStatisticsAverageBitrateVideo OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed or by an
external management entity.
Changes from an external management entity take effect as soon as
practical in the implementation.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of the Average PHY bit rate of MPDUs transmitted and received
using the Video Access Category returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
size over the indicated duration. Changes by an external management entity
are ignored when dot11STAStatisticsMeasurementDuration is nonzero."
::= { dot11STAStatisticsReportEntry 91 }
dot11STAStatisticsAverageBitrateVoice OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a status variable.
2951
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME when a measurement report is completed or by an
external management entity.
Changes from an external management entity take effect as soon as
practical in the implementation.
If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates
the value of the Average PHY bit rate of MPDUs transmitted and received
using the Voice Access Category returned from the STA in this STA
Statistics report. If dot11STAStatisticsMeasurementDuration indicates a
nonzero value, this attribute indicates the difference in the referenced
size over the indicated duration. Changes by an external management entity
are ignored when dot11STAStatisticsMeasurementDuration is nonzero."
::= { dot11STAStatisticsReportEntry 92 }
-- ********************************************************************
-- * End of dot11STAStatisticsReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11LCIReport TABLE
-- ********************************************************************
dot11LCIReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11LCIReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the current list of LCI reports that have been received
by the MLME. The report tables are maintained as a FIFO to preserve
freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows have different RprtIndex values than those deleted within the
range limitation of the index. One easy way is to increment RprtIndex for
new reports being written in the table."
::= { dot11RMReport 6 }
dot11LCIReportEntry OBJECT-TYPE
SYNTAX Dot11LCIReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11LCIReportTable Indexed by dot11LCIReportIndex."
INDEX { dot11LCIReportIndex }
::= { dot11LCIReportTable 1 }
Dot11LCIReportEntry ::=
SEQUENCE {
dot11LCIReportIndex Unsigned32,
dot11LCIReportToken OCTET STRING,
dot11LCIIfIndex InterfaceIndex,
dot11LCISTAAddress MacAddress,
dot11LCILatitudeUncertainty Unsigned32,
dot11LCILatitudeInteger Integer32,
dot11LCILatitudeFraction Integer32,
dot11LCILongitudeUncertainty Unsigned32,
dot11LCILongitudeInteger Integer32,
dot11LCILongitudeFraction Integer32,
dot11LCIAltitudeType INTEGER,
dot11LCIAltitudeUncertainty Unsigned32,
dot11LCIAltitude Integer32,
dot11LCIDatum Unsigned32,
dot11LCIAzimuthType INTEGER,
dot11LCIAzimuthResolution Unsigned32,
dot11LCIAzimuth Integer32,
dot11LCIVendorSpecific OCTET STRING,
2952
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11LCIRprtMeasurementMode INTEGER}
dot11LCIReportIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for LCI reports in dot11LCIReportTable, greater than 0."
::= { dot11LCIReportEntry 1 }
dot11LCIReportToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the token that was indicated in the measurement
request that generated this measurement report. This should be an exact
match to the original dot11RMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple measurement reports."
::= { dot11LCIReportEntry 2 }
dot11LCIIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
Identifies the Interface that this row of LCI report has been received on"
::= { dot11LCIReportEntry 3 }
dot11LCISTAAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The MAC address of the STA that returned this LCI report."
::= { dot11LCIReportEntry 4 }
dot11LCILatitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the latitude uncertainty as 6 bits."
::= { dot11LCIReportEntry 5 }
dot11LCILatitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-359..359)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
2953
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME when a measurement report is completed.
This attribute indicates the latitude as a 34 bit fixed point value
consisting of 9 bits of integer and 25 bits of fraction. This field
contains the 9 bits of integer portion of Latitude."
::= { dot11LCIReportEntry 6 }
dot11LCILatitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the latitude as a 34 bit fixed point value
consisting of 9 bits of integer and 25 bits of fraction. This field
contains the 25 bits of fraction portion of Latitude."
::= { dot11LCIReportEntry 7 }
dot11LCILongitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the longitude uncertainty as 6 bits."
::= { dot11LCIReportEntry 8 }
dot11LCILongitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-359..359)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the longitude as a 34 bit fixed point value
consisting of 9 bits of integer and 25 bits of fraction. This field
contains the 9 bits of integer portion of Longitude."
::= { dot11LCIReportEntry 9 }
dot11LCILongitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the longitude as a 34 bit fixed point value
consisting of 9 bits of integer and 25 bits of fraction. This field
contains the 25 bits of fraction portion of Longitude."
::= { dot11LCIReportEntry 10 }
dot11LCIAltitudeType OBJECT-TYPE
SYNTAX INTEGER { meters(1), floors(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
2954
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the altitude Type. Codes defined are:
meters : in 2s complement fixed-point 22-bit integer part with 8-bit
fraction
floors : in 2s complement fixed-point 22-bit integer part with 8-bit
fraction. "
::= { dot11LCIReportEntry 11 }
dot11LCIAltitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the altitude resolution as 6 bits indicating the
number of valid bits in the altitude."
::= { dot11LCIReportEntry 12 }
dot11LCIAltitude OBJECT-TYPE
SYNTAX Integer32 (-536870912..536870911)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the altitude as a 30 bit value defined by the
Altitude type field. The field is encoded as a 2s complement fixed-point
22-bit integer part with 8-bit fraction."
::= { dot11LCIReportEntry 13 }
-- reserved: 14. Was dot11LCIAltitudeFraction.
dot11LCIDatum OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the datum as an eight-bit value encoding the
horizontal and vertical references used for the coordinates given in this
LCI."
::= { dot11LCIReportEntry 15 }
dot11LCIAzimuthType OBJECT-TYPE
SYNTAX INTEGER { frontSurfaceOfSTA(0), radioBeam(1) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the azimuth Type as a one bit attribute encoding
the type of Azimuth. Codes defined are: front surface of STA : in 2s
complement fixed-point 9-bit integer; and radio beam : in 2s complement
fixed-point 9-bit integer"
::= { dot11LCIReportEntry 16 }
dot11LCIAzimuthResolution OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
2955
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the azimuth Resolution as 4 bits indicating the
number of valid bits in the azimuth."
::= { dot11LCIReportEntry 17 }
dot11LCIAzimuth OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the azimuth as a 9 bit value defined by the
Azimuth Type field.The field is encoded as a 2s complement fixed-point 9-
bit integer horizontal angle in degrees from true north."
::= { dot11LCIReportEntry 18 }
dot11LCIVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a measurement report element. The
default value is null."
DEFVAL { ''H }
::= { dot11LCIReportEntry 19 }
dot11LCIRprtMeasurementMode OBJECT-TYPE
SYNTAX INTEGER {
success(0),
incapableBit(1),
refusedBit(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the outcome status for the measurement request
which generated this measurement report; status is indicated using the
following reason codes: 1 indicates this STA is incapable of generating
the report, 2 indicates this STA is refusing to generate the report, 0
indicates the STA successfully carried out the measurement request."
DEFVAL { 0 }
::= { dot11LCIReportEntry 20 }
-- ********************************************************************
-- * End of dot11LCIReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11TransmitStreamReport TABLE
-- ********************************************************************
2956
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TransmitStreamReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11TransmitStreamReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the current list of Transmit Delay Metrics reports
that have been received by the MLME. The report tables are maintained as a
FIFO to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows have different RprtIndex values than those deleted within
the range limitation of the index. One easy way is to increment RprtIndex
for new reports being written in the table."
::= { dot11RMReport 7 }
dot11TransmitStreamReportEntry OBJECT-TYPE
SYNTAX Dot11TransmitStreamReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11TransmitStreamReportTable Indexed by
dot11TransmitStreamRprtIndex."
INDEX { dot11TransmitStreamRprtIndex }
::= { dot11TransmitStreamReportTable 1 }
Dot11TransmitStreamReportEntry ::=
SEQUENCE {
dot11TransmitStreamRprtIndex Unsigned32,
dot11TransmitStreamRprtRqstToken OCTET STRING,
dot11TransmitStreamRprtIfIndex InterfaceIndex,
dot11TransmitStreamMeasuringSTAAddr MacAddress,
dot11TransmitStreamRprtActualStartTime TSFType,
dot11TransmitStreamRprtMeasurementDuration Unsigned32,
dot11TransmitStreamRprtPeerSTAAddress MacAddress,
dot11TransmitStreamRprtTID Unsigned32,
dot11TransmitStreamRprtAverageQueueDelay Unsigned32,
dot11TransmitStreamRprtAverageTransmitDelay Unsigned32,
dot11TransmitStreamRprtTransmittedMSDUCount Unsigned32,
dot11TransmitStreamRprtMSDUDiscardedCount Unsigned32,
dot11TransmitStreamRprtMSDUFailedCount Unsigned32,
dot11TransmitStreamRprtMultipleRetryCount Unsigned32,
dot11TransmitStreamRprtCFPollsLostCount Unsigned32,
dot11TransmitStreamRprtBin0Range Unsigned32,
dot11TransmitStreamRprtDelayHistogram OCTET STRING,
dot11TransmitStreamRprtReason INTEGER,
dot11TransmitStreamRprtVendorSpecific OCTET STRING,
dot11TransmitStreamRprtMeasurementMode INTEGER}
dot11TransmitStreamRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Transmit Delay Metrics Report elements in
dot11TransmitStreamReportTable, greater than 0."
::= { dot11TransmitStreamReportEntry 1 }
dot11TransmitStreamRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
2957
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the request token that was indicated in the
measurement request that generated this measurement report. This should be
an exact match to the original dot11RMRqstToken attribute. Note that there
may be multiple entries in the table that match this value since a single
request may generate multiple measurement reports."
::= { dot11TransmitStreamReportEntry 2 }
dot11TransmitStreamRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The ifIndex of the interface on which this TransmitStream Report was
received."
::= { dot11TransmitStreamReportEntry 3 }
dot11TransmitStreamMeasuringSTAAddr OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The MAC address of the measuring STA for this row of Transmit Delay
Metrics report."
::= { dot11TransmitStreamReportEntry 4 }
dot11TransmitStreamRprtActualStartTime OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the TSF value at the time when the measurement
started or for a triggered Transmit Stream/Category Measurement report the
TSF value at the reporting QoS STA when the trigger condition was met."
::= { dot11TransmitStreamReportEntry 5 }
dot11TransmitStreamRprtMeasurementDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the duration over which the Transmit Delay
Metrics Report was measured. In a triggered Transmit Stream/Category
Measurement report, metrics are reported over a number of transmitted
MSDUs rather than a duration, hence Measurement Duration is equal to 0."
::= { dot11TransmitStreamReportEntry 6 }
dot11TransmitStreamRprtPeerSTAAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
2958
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a measurement report is completed.
The MAC address present in the Address 1 field of the measured Data
frames for this row of Transmit Stream/Category Measurement report."
::= { dot11TransmitStreamReportEntry 7 }
dot11TransmitStreamRprtTID OBJECT-TYPE
SYNTAX Unsigned32(0..16)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the TC or TS for which traffic is to be measured.
Values 0 to 15 are defined. Values 16-255 are reserved."
::= { dot11TransmitStreamReportEntry 8 }
dot11TransmitStreamRprtAverageQueueDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the average delay of the frames (MSDUs) that are
passed to the MAC during the measurement duration for the indicated
destination and the indicated Traffic Identifier. Queue Delay is measured
from the time the MSDU is passed to the MAC until the transmission
starts."
::= { dot11TransmitStreamReportEntry 9 }
dot11TransmitStreamRprtAverageTransmitDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the average delay of the frames (MSDUs) that are
successfully transmitted during the measurement duration for the indicated
destination and the indicated Traffic Identifier. Delay is measured from
the time the MSDU is passed to the MAC until the Ack frame is received
from the intermediate destination."
::= { dot11TransmitStreamReportEntry 10}
dot11TransmitStreamRprtTransmittedMSDUCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the number of MSDUs to the peer STA for the TC,
or TS given by the Traffic Identifier successfully transmitted in the
measurement duration."
::= {dot11TransmitStreamReportEntry 11}
2959
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TransmitStreamRprtMSDUDiscardedCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the number of MSDUs to the peer STA for the TC,
or TS given by the Traffic Identifier discarded due either to the number
of transmit attempts exceeding dot11ShortRetryLimit or dot11LongRetryLimit
as appropriate, or due to the MSDU lifetime having been reached."
::= {dot11TransmitStreamReportEntry 12}
dot11TransmitStreamRprtMSDUFailedCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the number of MSDUs to the peer STA for the TC,
or TS given by the Traffic Identifier discarded during the measurement
duration due to the number of transmit attempts exceeding
dot11ShortRetryLimit or dot11LongRetryLimit as appropriate."
::= {dot11TransmitStreamReportEntry 13}
dot11TransmitStreamRprtMultipleRetryCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the number of MSDUs for the TC, or TS given by
the Traffic Identifier that are successfully transmitted after more than
one retransmission attempt."
::= {dot11TransmitStreamReportEntry 14}
dot11TransmitStreamRprtCFPollsLostCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the number of QoS (+)CF-Poll frames transmitted
to the peer STA where there was no response from the QoS STA."
::= {dot11TransmitStreamReportEntry 15}
dot11TransmitStreamRprtBin0Range OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the delay range for Bin 0 of the delay
histogram."
2960
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11TransmitStreamReportEntry 16 }
dot11TransmitStreamRprtDelayHistogram OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (6))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the histogram of delay of the frames (MSDUs) that
are successfully transmitted during the measurement duration for the
indicated Traffic Identifier and the indicated destination. Delay is
measured from the time the MSDU is passed to the MAC until the Ack frame
is received from the intermediate destination, in units of TUs."
::= { dot11TransmitStreamReportEntry 17 }
dot11TransmitStreamRprtReason OBJECT-TYPE
SYNTAX INTEGER {
averageTrigger(0),
consecutiveTrigger(1),
delayTrigger(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the Reason field indicating the reason that the
measuring QoS STA sent the Transmit Stream/Category measurement report."
DEFVAL { 0 }
::= { dot11TransmitStreamReportEntry 18 }
dot11TransmitStreamRprtVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a measurement report element. The
default value is null."
DEFVAL { ''H }
::= { dot11TransmitStreamReportEntry 19 }
dot11TransmitStreamRprtMeasurementMode OBJECT-TYPE
SYNTAX INTEGER {
success(0),
incapableBit(1),
refusedBit(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the outcome status for the measurement request
which generated this measurement report; status is indicated using the
following reason codes: 1 indicates this STA is incapable of generating
the report, 2 indicates this STA is refusing to generate the report, 0
indicates the STA successfully carried out the measurement request."
DEFVAL { 0 }
2961
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11TransmitStreamReportEntry 20 }
-- ********************************************************************
-- * End of dot11TransmitStreamReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * Radio Measurement Configuration Information
-- ********************************************************************
dot11RMConfig OBJECT IDENTIFIER ::= { dot11RadioMeasurement 3 }
-- ********************************************************************
-- * dot11APChannelReport TABLE
-- ********************************************************************
dot11APChannelReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11APChannelReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"AP Channel Report information, in tabular form."
::= { dot11RMConfig 1 }
dot11APChannelReportEntry OBJECT-TYPE
SYNTAX Dot11APChannelReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11APChannelReportTable. Each entry in the table is
indexed by dot11APChannelReportIndex."
INDEX { dot11APChannelReportIndex }
::= { dot11APChannelReportTable 1 }
Dot11APChannelReportEntry ::=
SEQUENCE {
dot11APChannelReportIndex Unsigned32,
dot11APChannelReportIfIndex InterfaceIndex,
dot11APChannelReportOperatingClass Unsigned32,
dot11APChannelReportChannelList OCTET STRING}
dot11APChannelReportIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for AP channel report entry in dot11APChannelReportTable, greater
than 0."
::= { dot11APChannelReportEntry 1 }
dot11APChannelReportIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The ifIndex for this row of the AP channel report."
::= { dot11APChannelReportEntry 2 }
dot11APChannelReportOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
2962
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel set for this AP Channel report.
Country, Operating Class and Channel Number together specify the channel
frequency and spacing for this measurement report. Valid values of
Operating Class are shown in Annex E."
REFERENCE "Annex E"
::= { dot11APChannelReportEntry 3 }
dot11APChannelReportChannelList OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute lists the specific channels in this AP Channel report. The
default value is null. Each octet indicates a different channel within the
indicated Operating Class. This list of channels is the Channel List in
the AP Channel Report element described in 9.4.2.36. "
DEFVAL { ''H }
::= { dot11APChannelReportEntry 4 }
-- ********************************************************************
-- * End of dot11APChannelReportTable TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11RMNeighborReport TABLE
-- ********************************************************************
dot11RMNeighborReportNextIndex OBJECT-TYPE
SYNTAX Unsigned32(0..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Identifies the next available index for managing the neighbor report
table. If this attribute is 0, it indicates that the neighbor report
feature is not configurable via SNMP, or the table is full and new rows
cannot be accepted."
::= { dot11RMConfig 2 }
dot11RMNeighborReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RMNeighborReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains pertinent information on a collection of BSSIDs that are
candidates to which STAs can roam. The rows are created using
createAndWait method and fill in the attributes. When the rowStatus is set
to active, the row can be included in Neighbor Report elements. If there
is an error, the rowStatus is set to notReady by SME. Since this table
contains all Neighbor Report element entries for all interfaces enabled
with the neighbor report feature, it is possible to have too many entries
for one interface, while still remaining under the MaxTableSize. In that
situation, SME includes neighbor report entries only with lower
dot11RMNeighborReportIFIndex up to the maximum possible number of entries
for a particular interface identified by ifIndex. SME sets the rowStatus
to notInService for those rows that cannot be included in the Neighbor
Report element for that interface."
::= { dot11RMConfig 3 }
dot11RMNeighborReportEntry OBJECT-TYPE
2963
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Dot11RMNeighborReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11RMNeighborReportTable"
INDEX { dot11RMNeighborReportIndex }
::= { dot11RMNeighborReportTable 1 }
Dot11RMNeighborReportEntry ::=
SEQUENCE {
dot11RMNeighborReportIndex Unsigned32,
dot11RMNeighborReportIfIndex InterfaceIndex,
dot11RMNeighborReportBSSID MacAddress,
dot11RMNeighborReportAPReachability INTEGER,
dot11RMNeighborReportSecurity TruthValue,
dot11RMNeighborReportCapSpectrumMgmt TruthValue,
dot11RMNeighborReportCapQoS TruthValue,
dot11RMNeighborReportCapAPSD TruthValue,
dot11RMNeighborReportCapRM TruthValue,
dot11RMNeighborReportCapDelayBlockAck TruthValue,
dot11RMNeighborReportCapImmediateBlockAck TruthValue,
dot11RMNeighborReportKeyScope TruthValue,
dot11RMNeighborReportOperatingClass Unsigned32,
dot11RMNeighborReportChannelNumber Unsigned32,
dot11RMNeighborReportPhyType INTEGER,
dot11RMNeighborReportNeighborTSFInfo OCTET STRING,
dot11RMNeighborReportPilotInterval Unsigned32,
dot11RMNeighborReportPilotMultipleBSSID OCTET STRING,
dot11RMNeighborReportRMEnabledCapabilities OCTET STRING,
dot11RMNeighborReportVendorSpecific OCTET STRING,
dot11RMNeighborReportRowStatus RowStatus,
dot11RMNeighborReportMobilityDomain TruthValue,
dot11RMNeighborReportCapHT TruthValue,
dot11RMNeighborReportHTLDPCCodingCap TruthValue,
dot11RMNeighborReportHTSupportedChannelWidthSet
TruthValue,
dot11RMNeighborReportHTSMPowerSave Unsigned32,
dot11RMNeighborReportHTGreenfield TruthValue,
dot11RMNeighborReportHTShortGIfor20MHz TruthValue,
dot11RMNeighborReportHTShortGIfor40MHz TruthValue,
dot11RMNeighborReportHTTxSTBC TruthValue,
dot11RMNeighborReportHTRxSTBC Unsigned32,
dot11RMNeighborReportHTDelayedBlockAck TruthValue,
dot11RMNeighborReportHTMaxAMSDULength TruthValue,
dot11RMNeighborReportHTDSSCCKModein40MHz TruthValue,
dot11RMNeighborReportHTFortyMHzIntolerant TruthValue,
dot11RMNeighborReportHTLSIGTXOPProtectionSupport TruthValue,
dot11RMNeighborReportHTMaxAMPDULengthExponent Unsigned32,
dot11RMNeighborReportHTMinMPDUStartSpacing Unsigned32,
dot11RMNeighborReportHTRxMCSBitMask OCTET STRING,
dot11RMNeighborReportHTRxHighestSupportedDataRate Unsigned32,
dot11RMNeighborReportHTTxMCSSetDefined TruthValue,
dot11RMNeighborReportHTTxRxMCSSetNotEqual TruthValue,
dot11RMNeighborReportHTTxMaxNumberSpatialStreamsSupported
Unsigned32,
dot11RMNeighborReportHTTxUnequalModulationSupported
TruthValue,
dot11RMNeighborReportHTPCO TruthValue,
dot11RMNeighborReportHTPCOTransitionTime Unsigned32,
dot11RMNeighborReportHTMCSFeedback Unsigned32,
dot11RMNeighborReportHTCSupport TruthValue,
dot11RMNeighborReportHTRDResponder TruthValue,
dot11RMNeighborReportHTImplictTransmitBeamformingReceivingCap
TruthValue,
2964
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMNeighborReportHTReceiveStaggeredSoundingCap
TruthValue,
dot11RMNeighborReportHTTransmitStaggeredSoundingCap
TruthValue,
dot11RMNeighborReportHTReceiveNDPCap TruthValue,
dot11RMNeighborReportHTTransmitNDPCap TruthValue,
dot11RMNeighborReportHTImplicitTransmitBeamformingCap
TruthValue,
dot11RMNeighborReportHTTransmitBeamformingCalibration
Unsigned32,
dot11RMNeighborReportHTExplicitCSITransmitBeamformingCap
TruthValue,
dot11RMNeighborReportHTExplicitNonCompressedSteeringCap
TruthValue,
dot11RMNeighborReportHTExplicitCompressedSteeringCap
TruthValue,
dot11RMNeighborReportHTExplicitTransmitBeamformingFeedback
Unsigned32,
dot11RMNbRprtHTExplicitNonCompressedBeamformingFeedbackCap
Unsigned32,
dot11RMNeighborReportHTExplicitCompressedBeamformingFeedbackCap
Unsigned32,
dot11RMNeighborReportHTTransmitBeamformingMinimalGrouping
Unsigned32,
dot11RMNbRprtHTCSINumberofTxBeamformingAntennasSuppt
Unsigned32,
dot11RMNbRprtHTNonCompressedSteeringNumofTxBmfmingAntennasSuppt
Unsigned32,
dot11RMNbRprtHTCompressedSteeringNumberofTxBmfmingAntennasSuppt
Unsigned32,
dot11RMNbRprtHTCSIMaxNumberofRowsTxBeamformingSuppt
Unsigned32,
dot11RMNeighborReportHTTransmitBeamformingChannelEstimationCap
Unsigned32,
dot11RMNeighborReportHTAntSelectionCap TruthValue,
dot11RMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap
TruthValue,
dot11RMNeighborReportHTAntIndicesFeedbackBasedTxASELCap
TruthValue,
dot11RMNeighborReportHTExplicitCSIFeedbackBasedCap
TruthValue,
dot11RMNeighborReportHTAntIndicesFeedbackCap TruthValue,
dot11RMNeighborReportHTRxASELCap TruthValue,
dot11RMNeighborReportHTTxSoundingPPDUsCap TruthValue,
dot11RMNeighborReportHTInfoPrimaryChannel Unsigned32,
dot11RMNeighborReportHTInfoSecChannelOffset Unsigned32,
dot11RMNeighborReportHTInfoSTAChannelWidth TruthValue,
dot11RMNeighborReportHTInfoRIFSMode TruthValue,
dot11RMNeighborReportHTInfoProtection Unsigned32,
dot11RMNeighborReportHTInfoNonGreenfieldHTSTAsPresent
TruthValue,
dot11RMNeighborReportHTInfoOBSSNonHTSTAsPresent
TruthValue,
dot11RMNeighborReportHTInfoDualBeacon TruthValue,
dot11RMNeighborReportHTInfoDualCTSProtection TruthValue,
dot11RMNeighborReportHTInfoSTBCBeacon TruthValue,
dot11RMNeighborReportHTInfoLSIGTXOPProtectionSup
TruthValue,
dot11RMNeighborReportHTInfoPCOActive TruthValue,
dot11RMNeighborReportHTInfoPCOPhase TruthValue,
dot11RMNeighborReportHTInfoBasicMCSSet OCTET STRING,
dot11RMNeighborReportHTSecChannelOffset Unsigned32,
dot11RMNeighborReportExtCapPSMPSupport TruthValue,
dot11RMNeighborReportExtCapSPSMPSup TruthValue,
2965
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMNeighborReportExtCapServiceIntervalGranularity
Unsigned32,
dot11RMNeighborReportBSSTransitCandPreference Unsigned32,
dot11RMNeighborReportBSSTerminationTSF TSFType,
dot11RMNeighborReportBSSTerminationDuration Unsigned32
}
dot11RMNeighborReportIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for neighbor report configuration table in
dot11RMNeighborReportTable, greater than 0."
::= { dot11RMNeighborReportEntry 1 }
dot11RMNeighborReportIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The ifIndex for this row of the neighbor report."
::= { dot11RMNeighborReportEntry 2 }
dot11RMNeighborReportBSSID OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the BSSID of the AP described by this row of
neighbor report."
::= { dot11RMNeighborReportEntry 3 }
dot11RMNeighborReportAPReachability OBJECT-TYPE
SYNTAX INTEGER { notReachable(1), unknown(2), reachable(3) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the reachability of the AP represented by the
dot11RMNeighborReportBSSID."
::= { dot11RMNeighborReportEntry 4 }
dot11RMNeighborReportSecurity OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute, when true, indicates that the neighbor AP identified by
this BSSID supports the same security provisioning as used by the AP which
provided this neighbor report. This attribute, when false, indicates
either that the neighbor AP identified by this BSSID does not support the
same security provisioning or that the security information for this
2966
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
neighbor AP is not available at this time."
::= { dot11RMNeighborReportEntry 5 }
dot11RMNeighborReportCapSpectrumMgmt OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the spectrum management capability of the AP
represented by dot11RMNeighborReportBSSID."
::= { dot11RMNeighborReportEntry 6 }
dot11RMNeighborReportCapQoS OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the QoS capability of the AP represented by
dot11RMNeighborReportBSSID."
::= { dot11RMNeighborReportEntry 7 }
dot11RMNeighborReportCapAPSD OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the APSD capability of the AP represented by
dot11RMNeighborReportBSSID."
::= { dot11RMNeighborReportEntry 8 }
dot11RMNeighborReportCapRM OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute is equal to true when the AP, represented by
dot11RMNeighborReportBSSID, transmits a RM Enabled Capabilities element;
and is false otherwise."
::= { dot11RMNeighborReportEntry 9 }
dot11RMNeighborReportCapDelayBlockAck OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the delayed block ack capability of the AP
represented by dot11RMNeighborReportBSSID."
::= { dot11RMNeighborReportEntry 10 }
2967
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMNeighborReportCapImmediateBlockAck OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the immediate block ack capability of the AP
represented by dot11RMNeighborReportBSSID."
::= { dot11RMNeighborReportEntry 11 }
dot11RMNeighborReportKeyScope OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute, when true, indicates the neighbor AP identified by this
BSSID has the same authenticator as the AP which provided this neighbor
report. This attribute, when false, indicates that the neighbor AP
identified by this BSSID has a different authenticator or that
authenticator information is not available."
::= { dot11RMNeighborReportEntry 12 }
dot11RMNeighborReportOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the channel set for this neighbor report entry.
Country, Operating Class and Channel Number together specify the channel
frequency and spacing for this measurement report. Valid values of
Operating Class are shown in Annex E."
REFERENCE
"Annex E"
::= { dot11RMNeighborReportEntry 13 }
dot11RMNeighborReportChannelNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the current operating channel of the AP
represented by the dot11RMNeighborReportBSSID. The Channel Number is
defined only within the indicated Operating Class for this neighbor report
entry."
::= { dot11RMNeighborReportEntry 14 }
dot11RMNeighborReportPhyType OBJECT-TYPE
SYNTAX INTEGER {
dsss(2),
ofdm(4),
hrdsss(5),
erp(6),
ht(7),
2968
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dmg(8),
vht(9),
tvht(10) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the PHY Type of the neighbor AP identified by
this BSSID."
::= { dot11RMNeighborReportEntry 15 }
dot11RMNeighborReportNeighborTSFInfo OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (6))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates TSF timing information for the neighbor AP
identified by this BSSID. The TSF timing information includes the TSF
Offset and the Beacon Interval, as defined in 9.4.2.37."
::= { dot11RMNeighborReportEntry 16 }
dot11RMNeighborReportPilotInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the Measurement Pilot Interval for the neighbor
AP identified by this BSSID, as defined in 9.4.1.18."
::= { dot11RMNeighborReportEntry 17 }
dot11RMNeighborReportPilotMultipleBSSID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
UNITS "BSSID LSBs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates n, where 2**n is the maximum number of BSSIDs in
the multiple BSSID set, as described in 11.11.14."
::= { dot11RMNeighborReportEntry 18 }
dot11RMNeighborReportRMEnabledCapabilities OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(7))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute indicates the detailed enabled capabilities of the AP
represented by the dot11RMNeighborReportBSSID, as defined in 9.4.2.45."
REFERENCE
"IEEE Std 802.11 - 9.4.2.45"
2969
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11RMNeighborReportEntry 19 }
dot11RMNeighborReportVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This attribute provides an envelope for any optional vendor specific
subelements which may be included in a measurement report element. The
default value is null."
DEFVAL { ''H }
::= { dot11RMNeighborReportEntry 20 }
dot11RMNeighborReportRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
Contains the row status of the neighbor report, essentially used for
indicating whether the row has all valid attributes filled in. Then set to
active to be used in Neighbor Report elements. If any parameter is
invalid, the SME sets this attribute back to notReady. It is the
responsibility of the manager to correct the parameters."
::= { dot11RMNeighborReportEntry 21 }
dot11RMNeighborReportMobilityDomain OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
Indicates a common mobility domain identifier (MDID) and an identical
value of the FT Capability and Policy value."
::= { dot11RMNeighborReportEntry 22 }
dot11RMNeighborReportCapHT OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The High Throughput Bit when equal to 1 indicates that the AP represented
by this BSSID is an HT AP including the HT Capabilities element in its
Beacons and that the contents of that HT Capabilities element are
identical to the HT Capabilities element advertised by the AP sending the
report. See 9.4.2.37"
::= { dot11RMNeighborReportEntry 23 }
dot11RMNeighborReportHTLDPCCodingCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
2970
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME when a measurement report is completed.
This variable indicates support for receiving LDPC coded packets, equal to
false if not supported, equal to true if supported. See 9.4.2.56.2"
::= { dot11RMNeighborReportEntry 24 }
dot11RMNeighborReportHTSupportedChannelWidthSet OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates which channel widths the STA supports, equal to
false if only 20 MHz operation is supported, equal to true if both 20 MHz
and 40 MHz operation is supported. See 9.4.2.56.2"
::= { dot11RMNeighborReportEntry 25 }
dot11RMNeighborReportHTSMPowerSave OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the SM power save mode, equal to 0 for static SM
power save mode, equal to 1 for dynamic SM power save mode, equal to 3 for
SM power save disabled or not supported, the value 2 is reserved; see
9.4.2.56.2"
::= { dot11RMNeighborReportEntry 26 }
dot11RMNeighborReportHTGreenfield OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for the reception of PPDUs with HT-
greenfield format, equal to false if not supported, equal to true if
supported. See 9.4.2.56.2"
::= { dot11RMNeighborReportEntry 27 }
dot11RMNeighborReportHTShortGIfor20MHz OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates short GI support for the reception of 20 MHz
packets, equal to false if not supported, equal to true if supported See
9.4.2.56.2"
::= { dot11RMNeighborReportEntry 28 }
dot11RMNeighborReportHTShortGIfor40MHz OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
2971
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates short GI support for the reception of 40 MHz
packets, equal to false if not supported, equal to true if supported. See
9.4.2.56.2"
::= { dot11RMNeighborReportEntry 29}
dot11RMNeighborReportHTTxSTBC OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for the transmission of PPDUs using STBC,
equal to false if not supported, equal to true if supported. See
9.4.2.56.2"
::= { dot11RMNeighborReportEntry 30}
dot11RMNeighborReportHTRxSTBC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for the reception of PPDUs using STBC,
equal to 0 for no support, equal to 1 for support of one spatial stream,
equal to 2 for support of one and two spatial streams, equal to 3 for
support of one, two, and three spatial streams. See 9.4.2.56.2"
::= { dot11RMNeighborReportEntry 31}
dot11RMNeighborReportHTDelayedBlockAck OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for HT-delayed block ack operation, equal
to false if not supported, equal to true if supported. Support indicates
that the STA is able to accept an ADDBA request for HT-delayed block ack.
See 9.4.2.56.2"
::= { dot11RMNeighborReportEntry 32 }
dot11RMNeighborReportHTMaxAMSDULength OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates maximum A-MSDU length, equal to false for 3839
octets, equal to true for 7935 octets. See 9.4.2.56.2"
::= { dot11RMNeighborReportEntry 33 }
dot11RMNeighborReportHTDSSCCKModein40MHz OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
2972
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates use of DSSS/CCK mode in a 40 MHz capable BSS
operating in 20/40 MHz mode, equal to false if DSSS/CCK in 40 MHz is not
allowed, equal to true if the DSSS/CCK in 40 MHz is allowed. See
9.4.2.56.2"
::= { dot11RMNeighborReportEntry 34 }
dot11RMNeighborReportHTFortyMHzIntolerant OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether other BSSs receiving this information are
required to prohibit 40 MHz transmissions, equal to true to prohibit 20/40
MHz BSS operation, otherwise equal to false. See 9.4.2.56.2"
::= { dot11RMNeighborReportEntry 35 }
dot11RMNeighborReportHTLSIGTXOPProtectionSupport OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for the LSIG TXOP protection mechanism,
equal to false if not supported, equal to true if supported. See
9.4.2.56.2"
::= { dot11RMNeighborReportEntry 36 }
dot11RMNeighborReportHTMaxAMPDULengthExponent OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the maximum length of A-MPDU that the STA can
receive. This field is an integer in the range 0 to 3. The length defined
by this field is equal to 2 ** (13 + Maximum A-MPDU Length) - 1 octets. See
9.4.2.56.3"
::= { dot11RMNeighborReportEntry 37 }
dot11RMNeighborReportHTMinMPDUStartSpacing OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable determines the minimum time between the start of adjacent
MPDUs within an AMPDU, measured at the PHY SAP, equal to 0 for no
restriction, equal to 1 for 1/4 microsecond, equal to 2 for 1/2
microsecond, equal to 3 for 1 microsecond, equal to 4 for 2 microseconds,
equal to 5 for 4 microseconds, equal to 6 for 8 microseconds, equal to 7
2973
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
for 16 microseconds. See 9.4.2.56.3"
::= { dot11RMNeighborReportEntry 38 }
dot11RMNeighborReportHTRxMCSBitMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(10))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable is a 77 bit bitmap that defines a set of MCS values, where
bit B0 (i.e., the lsb of the first octet) corresponds to MCS 0 and bit B76
corresponds to MCS 76, equal to 0 when the MCS is not supported, equal to
1 when the MCS is supported. See 9.4.2.56.4"
::= { dot11RMNeighborReportEntry 39}
dot11RMNeighborReportHTRxHighestSupportedDataRate OBJECT-TYPE
SYNTAX Unsigned32 (1..1023)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable defines the highest HT PPDU data rate that the STA is able
to receive, in units of 1 Mb/s. See 9.4.2.56.4"
::= { dot11RMNeighborReportEntry 40 }
dot11RMNeighborReportHTTxMCSSetDefined OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates if the Tx MCS set is defined, equal to false if no
Tx MCS set is defined, equal to true if Tx MCS set is defined. See
9.4.2.56.4"
::= { dot11RMNeighborReportEntry 41 }
dot11RMNeighborReportHTTxRxMCSSetNotEqual OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates if the Tx MCS set is defined to be equal to the Rx
MCS set, equal to false where no Tx MCS set is defined or where the Tx MCS
Set is defined to be equal to the RX MCS Set, equal to true where the TX
MCS set may differ from the Rx MCS set. See 9.4.2.56.4"
::= { dot11RMNeighborReportEntry 42 }
dot11RMNeighborReportHTTxMaxNumberSpatialStreamsSupported OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
2974
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This variable indicates maximum number of spatial streams supported when
the Tx MCS Set may differ from the Rx MCS set, equal to 0 where no TX MCS
set is defined or where the Tx MCS set is defined to be equal to the RX MCS
set or where the maximum number of spatial streams supported when
transmitting is 1 spatial stream and the Tx MCS set may differ from the Rx
MCS set, equal to 1 where the maximum number of spatial streams supported
when transmitting is 2 spatial streams and the Tx MCS set may differ from
the Rx MCS set, equal to 2 where the maximum number of spatial streams
supported when transmitting is 3 spatial streams and the Tx MCS set may
differ from the Rx MCS set, equal to 3 where the maximum number of spatial
streams supported when transmitting is 4 spatial streams and the Tx MCS
set may differ from the Rx MCS set. See 9.4.2.56.4"
::= { dot11RMNeighborReportEntry 43 }
dot11RMNeighborReportHTTxUnequalModulationSupported OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether transmit UEQM is supported when the Tx MCS
set may differ from the Rx MCS set, equal to false where no TX MCS set is
defined or where the Tx MCS set is defined to be equal to the RX MCS set
or when UEQM is not supported and the Tx MCS set may differ from the Rx MCS
set, equal to true when UEQM is supported and the Tx MCS set may differ
from the Rx MCS set. See 9.4.2.56.4"
::= { dot11RMNeighborReportEntry 44 }
dot11RMNeighborReportHTPCO OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for PCO, equal to false if not supported,
equal to true if supported. See 9.4.2.56.5"
::= { dot11RMNeighborReportEntry 45 }
dot11RMNeighborReportHTPCOTransitionTime OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates that the STA can switch between 20 MHz channel
width and 40 MHz channel width within the indicated time, equal to 0 for
no transition, equal to 1 for 400 microseconds, equal to 2 for 1.5 ms,
equal to 3 for 5 ms. For the no transition case (equal to 0) the PCO active
STA does not change its operation channel width and is able to receive 40
MHz PPDUs during the 20 MHz phase. See 9.4.2.56.5"
::= { dot11RMNeighborReportEntry 46 }
dot11RMNeighborReportHTMCSFeedback OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
2975
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME when a measurement report is completed.
This variable indicates the capability of the STA to provide MFB, equal to
0 if the STA does not provide MFB, equal to 2 if the STA provide only
unsolicited MFB, equal to 3 if the STA can provide MFB in response to MRQ
as well as unsolicited MFB. Note the value 1 is reserved. See 9.4.2.56.5"
::= { dot11RMNeighborReportEntry 47 }
dot11RMNeighborReportHTCSupport OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support of the HT Control field, equal to false if
not supported, equal to true if supported. See 9.4.2.56.5"
::= { dot11RMNeighborReportEntry 48 }
dot11RMNeighborReportHTRDResponder OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for acting as a revere direction
responder, equal to false if not supported, equal to true if supported.
See 9.4.2.56.5"
::= { dot11RMNeighborReportEntry 49}
dot11RMNeighborReportHTImplictTransmitBeamformingReceivingCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA can receive Transmit Beamforming
steered frames using implicit feedback, equal to false if not supported,
equal to true if supported. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 50 }
dot11RMNeighborReportHTReceiveStaggeredSoundingCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA can receive staggered sounding
frames, equal to false if not supported, equal to true if supported. See
9.4.2.56.6"
::= { dot11RMNeighborReportEntry 51 }
dot11RMNeighborReportHTTransmitStaggeredSoundingCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
2976
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA can transmit staggered sounding
frames, equal to false if not supported, equal to true if supported. See
9.4.2.56.6"
::= { dot11RMNeighborReportEntry 52 }
dot11RMNeighborReportHTReceiveNDPCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this receiver can interpret NDPs as
sounding frames, equal to false if not supported, equal to true if
supported. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 53 }
dot11RMNeighborReportHTTransmitNDPCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA can transmit NDPs as sounding
frames, equal to false if not supported, equal to true if supported. See
9.4.2.56.6"
::= { dot11RMNeighborReportEntry 54 }
dot11RMNeighborReportHTImplicitTransmitBeamformingCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA can apply implicit transmit
beamforming, equal to false if not supported, equal to true if supported.
See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 55 }
dot11RMNeighborReportHTTransmitBeamformingCalibration OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates that the STA can participate in a calibration
procedure initiated by another STA that is capable of generating an
immediate response Sounding PPDU and can provide a CSI report in response
to the receipt of a Sounding PPDU, equal to 0 if not supported, equal to 1
is the STA can respond to a calibration request using the CSI report but
cannot initiate calibration, equal to 3 if the STA can both initiate and
respond to a calibration request. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 56 }
2977
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMNeighborReportHTExplicitCSITransmitBeamformingCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA can apply transmit beamforming
using SCI explicit feedback in its transmission, equal to false if not
supported, equal to true if supported. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 57 }
dot11RMNeighborReportHTExplicitNonCompressedSteeringCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
The variable indicates whether this STA can apply transmit beamforming
using noncompressed beamforming feedback matrix explicit feedback in its
transmission, equal to false if not supported, equal to true if supported.
See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 58 }
dot11RMNeighborReportHTExplicitCompressedSteeringCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA can apply transmit beamforming
using compressed beamforming feedback matrix explicit feedback in its
transmission, equal to false if not supported, equal to true if supported.
See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 59}
dot11RMNeighborReportHTExplicitTransmitBeamformingFeedback OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this receiver can return CSI explicit
feedback, equal to 0 if not supported, equal to 1 for delayed feedback,
equal to 2 for immediate feedback, equal to 3 for delayed and immediate
feedback. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 60 }
dot11RMNbRprtHTExplicitNonCompressedBeamformingFeedbackCap OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this receiver can return noncompressed
2978
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
beamforming feedback matrix explicit feedback, equal to 0 if not
supported, equal to 1 for delayed feedback, equal to 2 for immediate
feedback, equal to 3 for delayed and immediate feedback. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 61 }
dot11RMNeighborReportHTExplicitCompressedBeamformingFeedbackCap OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this receiver can return compressed
beamforming feedback matrix explicit feedback, equal to 0 if not
supported, equal to 1 for delayed feedback, equal to 2 for immediate
feedback, equal to 3 for delayed and immediate feedback. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 62 }
dot11RMNeighborReportHTTransmitBeamformingMinimalGrouping OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the minimal grouping used for explicit feedback
reports, equal to 0 if the STA supports groups of 1 (no grouping), equal
to 1 to indicate groups of 1, 2, equal to 2 to indicate groups of 1, 4,
equal to 3 to indicate groups of 1, 2, 4. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 63 }
dot11RMNbRprtHTCSINumberofTxBeamformingAntennasSuppt OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the maximum number of beamformer antennas the
beamformee can support when CSI feedback is required, equal to 0 for
single Tx antenna sounding, equal to 1 for 2 Tx antenna sounding, equal to
2 for 3 Tx antenna sounding, equal to 3 for 4 Tx antenna sounding. See
9.4.2.56.6"
::= { dot11RMNeighborReportEntry 64 }
dot11RMNbRprtHTNonCompressedSteeringNumofTxBmfmingAntennasSuppt OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the maximum number of beamformer antennas the
beamformee can support when noncompressed beamforming feedback matrix is
required, equal to 0 for single Tx antenna sounding, equal to 1 for 2 Tx
antenna sounding, equal to 2 for 3 Tx antenna sounding, equal to 3 for 4
Tx antenna sounding. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 65 }
dot11RMNbRprtHTCompressedSteeringNumberofTxBmfmingAntennasSuppt OBJECT-TYPE
2979
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the maximum number of beamformer antennas the
beamformee can support when compressed beamforming feedback matrix is
required, equal to 0 for single Tx antenna sounding, equal to 1 for 2 Tx
antenna sounding, equal to 2 for 3 Tx antenna sounding, equal to 3 for 4
Tx antenna sounding. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 66 }
dot11RMNbRprtHTCSIMaxNumberofRowsTxBeamformingSuppt OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the maximum number of rows of CSI explicit
feedback from the beamformee or calibration responder or transmit ASEL
responder that a beamformer or calibration initiator or transmit ASEL
initiator can support when SCI feedback is required, equal to 0 for a
single row of CSI, equal to 1 for 2 rows of CSI, equal to 2 for 3 rows of
CSI, equal to 3 for 4 rows of CSI. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 67 }
dot11RMNeighborReportHTTransmitBeamformingChannelEstimationCap OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the maximum number of space-time streams for which
channel dimensions can be simultaneously estimated when receiving an NDP
sounding PPDU or the extension portion of the HT-LTFs in a staggered
sounding PPDU. Equal to 0 for 1 space-time stream, equal to 1 for 2 space-
time streams, equal to 2 for 3 space-time streams, equal to 3 for 4 space-
time streams. See 9.4.2.56.6"
::= { dot11RMNeighborReportEntry 68 }
dot11RMNeighborReportHTAntSelectionCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA supports ASEL, equal to false if
not supported, equal to true if supported. See 9.4.2.56.7"
::= { dot11RMNeighborReportEntry 69}
dot11RMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
2980
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA has transmit ASEL capability
based on explicit CSI feedback, equal to false if not supported, equal to
true if supported. See 9.4.2.56.7"
::= { dot11RMNeighborReportEntry 70 }
dot11RMNeighborReportHTAntIndicesFeedbackBasedTxASELCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA has transmit ASEL capability
based on antenna indices feedback, equal to false if not supported, equal
to true if supported. See 9.4.2.56.7"
::= { dot11RMNeighborReportEntry 71 }
dot11RMNeighborReportHTExplicitCSIFeedbackBasedCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA can compute CSI and feedback in
support of ASEL, equal to false if not supported, equal to true is
supported. See 9.4.2.56.7"
::= { dot11RMNeighborReportEntry 72 }
dot11RMNeighborReportHTAntIndicesFeedbackCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA has Rx ASEL capability, equal to
false if not supported, equal to true if supported. See 9.4.2.56.7"
::= { dot11RMNeighborReportEntry 73 }
dot11RMNeighborReportHTRxASELCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether this STA has Rx ASEL capability, equal to
false if not supported, equal to true if supported. See 9.4.2.56.7"
::= { dot11RMNeighborReportEntry 74 }
dot11RMNeighborReportHTTxSoundingPPDUsCap OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
2981
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This variable indicates whether this STA can transmit sounding PPDUs for
ASEL training per request, equal to false if not supported, equal to true
if supported. See 9.4.2.56.7"
::= { dot11RMNeighborReportEntry 75 }
dot11RMNeighborReportHTInfoPrimaryChannel OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the channel number of the primary channel,
encoding: channel number of the primary channel. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 76 }
dot11RMNeighborReportHTInfoSecChannelOffset OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the offset of the secondary channel relative to
the primary channel, equal to 1 if the secondary channel is above the
primary channel, equal to 3 if the secondary channel is below the primary
channel, equal to 0 if no secondary channel is present. The value 2 is
reserved. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 77 }
dot11RMNeighborReportHTInfoSTAChannelWidth OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable defines the channel widths that may be used to transmit to
the STA, equal to false for a 20 MHz channel width, equal to true allows
use of any channel width in the supported channel width set. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 78 }
dot11RMNeighborReportHTInfoRIFSMode OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether use of RIFS is permitted within the BSS,
equal to false if use of RIFS is prohibited, equal to true if use of RIFS
is permitted. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 79}
dot11RMNeighborReportHTInfoProtection OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
2982
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates protection requirements of HT transmissions. Equal
to 0 if all STAs detected in the primary or the secondary channel or that
are a member of this BSS are HT STAs and either all STAs that are known by
the transmitting STA to be a member of this BSS are 20/40 MHz HT in a 20/
40 MHz BSS or this BSS is a 20 MHz BSS. Equal to 1 (nonmember protection
mode) if there is at least one non-HT STA detected in either the primary
or the secondary channel or in both the primary and secondary channels and
that is not known by the transmitting STA to be a member of this BSS and
all STAs that are known by the transmitting STA to be a member of this BSS
are HT STAs. Equal to 2 if all STAs detected in the primary or the
secondary channel or that are known by the transmitting STA to be a member
of this BSS are HT STAs and this BSS is a 20/40 MHz BSS and there is at
least one 20 MHz HT STA associated with this BSS. Equal to 3 (non-HT mixed
mode) otherwise. See 9.4.2.56.2"
::= { dot11RMNeighborReportEntry 80 }
dot11RMNeighborReportHTInfoNonGreenfieldHTSTAsPresent OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates if any HT STAs that are not HT-greenfield capable
have associated. Determines when a non-AP STA should use HT-greenfield
protection. Present in Beacon and Probe Response frames transmitted by an
AP. Equal to false if all HT STAs that are associated are HT-greenfield
capable, equal to true if one or more HT STAs that are not HT-greenfield
capable are associated. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 81 }
dot11RMNeighborReportHTInfoOBSSNonHTSTAsPresent OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates if the use of protection for non-HT STAs by OBSSs
is determined to be desirable. Present in Beacon and Probe Response frames
transmitted by an AP, equal to true if the use of protection for non-HT
STAs by OBSSs is determined to be desirable, equal to false otherwise. See
9.4.2.57"
::= { dot11RMNeighborReportEntry 82 }
dot11RMNeighborReportHTInfoDualBeacon OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether the AP transmits an STBC beacon, equal to
false if no STBC beacon is transmitted, equal to true if an STBC beacon is
transmitted. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 83 }
dot11RMNeighborReportHTInfoDualCTSProtection OBJECT-TYPE
2983
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable is used by the AP to set a NAV at STAs that do not support
STBC and at STAs that can associate solely through the secondary beacon,
equal to false if dual CTS protection is not required, equal to true if
dual CTS protection is required. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 84 }
dot11RMNeighborReportHTInfoSTBCBeacon OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether the beacon containing this element is a
primary or a STBC beacon, equal to false in a primary beacon, equal to
true in a STBC beacon. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 85 }
dot11RMNeighborReportHTInfoLSIGTXOPProtectionSup OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether all HT STA in the BSS support L-SIG TXOP
protection, equal to false if one or more HT STA in the BSS do not support
L-SIG TXOP protection, equal to true if all HT STA in the BSS support L-
SIG TXOP protection. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 86 }
dot11RMNeighborReportHTInfoPCOActive OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates whether PCO is active in the BSS, equal to false
if PCO is not active in the BSS, equal to true if PCO is active in the BSS.
See 9.4.2.57"
::= { dot11RMNeighborReportEntry 87}
dot11RMNeighborReportHTInfoPCOPhase OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the PCO phase of operation, equal to false
indicates a switch to or continued 20 MHz phase, equal to true indicates a
switch to or continuation of 40 MHz phase. See 9.4.2.57"
2984
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11RMNeighborReportEntry 88 }
dot11RMNeighborReportHTInfoBasicMCSSet OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates values that are supported by all HT STAs in the
BSS. The Basic HT-MCS Set is a bitmap of size 128 bits. Bit 0 corresponds
to MCS 0. A bit is equal to 1 to indicate support for that MCS, equal to 0
otherwise. See 9.4.2.57"
::= { dot11RMNeighborReportEntry 89 }
dot11RMNeighborReportHTSecChannelOffset OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates the position of the secondary channel relative to
the primary channel, equal to 1 to indicate that the secondary channel is
above the primary channel, equal to 3 to indicate the secondary channel is
below the primary channel, equal to 0 to indicate that no secondary
channel is present. The value 2 is reserved. See 9.4.2.20"
::= { dot11RMNeighborReportEntry 90 }
dot11RMNeighborReportExtCapPSMPSupport OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for PSMP operation, equal to false if PSMP
is not supported, equal to true if PSMP operation is supported. See
9.4.2.27"
::= { dot11RMNeighborReportEntry 91 }
dot11RMNeighborReportExtCapSPSMPSup OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a measurement report is completed.
This variable indicates support for scheduled PSMP, equal to false when
PSMP is supported is equal to false and when the PSMP Capability field is
equal to 1 if the STA does not support S-PSMP, equal to true when the PSMP
Capability field is equal to 1 if the STA supports S-PSMP. See 9.4.2.27."
::= { dot11RMNeighborReportEntry 92 }
dot11RMNeighborReportExtCapServiceIntervalGranularity OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
2985
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME when a measurement report is completed.
This variable indicates the duration of the shortest SI, equal to 0 for 5
ms, equal to 1 for 10 ms, equal to 2 for 15 ms, equal to 3 for 20 ms, equal
to 4 for 25 ms, equal to 5 for 30 ms, equal to 6 for 35 ms, equal to 7 for
40 ms. See 9.4.2.27."
::= { dot11RMNeighborReportEntry 93 }
dot11RMNeighborReportBSSTransitCandPreference OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the network preference for BSS transition to the
BSS listed in this BSS Transition Candidate List Entries field in the BSS
Transition Management Request frame, BSS Transition Management Query frame
and BSS Transition Management Response frame. The Preference field value
is a number ranging from 0 to 255 indicating an ordering of preferences
for the BSS transition candidates for this STA. The value 0 indicates an
excluded BSS. The values 1-255 the preferred relative ordering of BSSs,
with 255 indicating the most preferred candidate and 1 indicating the
least preferred candidate. Additional details describing use of the
Preference field are provided in 11.24.7.3."
::= { dot11RMNeighborReportEntry 94 }
dot11RMNeighborReportBSSTerminationTSF OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the value of the TSF timer when the BSS
termination will occur in the future. A BSS Termination TSF field value of
0 indicates that termination of the BSS will occur imminently. Prior to
termination of the BSS, all associated STAs are disassociated by the AP."
::= { dot11RMNeighborReportEntry 95 }
dot11RMNeighborReportBSSTerminationDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "minutes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This attribute indicates the number of minutes for which the BSS is not
present. The Duration field value of 0 is reserved. The Duration field
value is set to 65 535 when the BSS is terminated for a period longer than
or equal to 65 535 minutes."
::= { dot11RMNeighborReportEntry 96 }
-- ********************************************************************
-- * End of dot11RMNeighborReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * END of Radio Measurement Interface MIB
-- ********************************************************************
-- ********************************************************************
-- * Wireless Network Management Interface MIB
-- ********************************************************************
dot11WirelessNetworkManagement OBJECT IDENTIFIER ::= { dot11smt 22 }
-- ********************************************************************
-- * Wireless network management requests
2986
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
dot11WNMRequest OBJECT IDENTIFIER ::= { dot11WirelessNetworkManagement 1 }
-- ********************************************************************
-- * dot11WNMRequest TABLE
-- ********************************************************************
dot11WNMRequestNextIndex OBJECT-TYPE
SYNTAX Unsigned32(0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when able to accept a new request.
Identifies a hint for the next value of dot11WNMRqstIndex to be used in a
row creation attempt for dot11WNMRequestTable. If no new rows can be
created for some reason, such as memory, processing requirements, etc, the
SME shall set this attribute to 0. It shall update this attribute to a
proper value other than 0 as soon as it is capable of receiving new
measurement requests. The nextIndex is not necessarily sequential nor
monotonically increasing."
::= { dot11WNMRequest 1 }
dot11WNMRequestTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMRequestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This group contains the current list of requests for WNM reports to be
issued and have been issued until removed. A network manager adds a WNM
request by creating a row with createAndWait row status and then filling
in the request parameters/attributes. The request becomes active to be
issued when the row status is set to Active. The columnar objects or
attributes other than the rowStatus shall not be written if the rowStatus
is Active. The request rows can be deleted, if commanded by a network
manager via changing the value of dot11WNMRqstRowStatus to Destroy. This
may leave orphaned rows if a manager crashes and forgets which rows are
being used by it. One recommended way to manage orphaned or finished rows
is to delete rows if their dot11WNMRqstRowStatus remains other than Active
for longer than a period (recommend at least 5 minutes, IETF RFC 2579). Or
another recommended way is to delete older rows as needed based on their
dot11WNMRqstTimeStamp values. This can be done by the agent as well as the
manager."
::= { dot11WNMRequest 2 }
dot11WNMRequestEntry OBJECT-TYPE
SYNTAX Dot11WNMRequestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMRequestTable Indexed by dot11WNMRqstIndex."
INDEX { dot11WNMRqstIndex }
::= { dot11WNMRequestTable 1 }
Dot11WNMRequestEntry ::=
SEQUENCE {
dot11WNMRqstIndex Unsigned32,
dot11WNMRqstRowStatus RowStatus,
dot11WNMRqstToken OCTET STRING,
dot11WNMRqstIfIndex InterfaceIndex,
dot11WNMRqstType INTEGER,
dot11WNMRqstTargetAdd MacAddress,
dot11WNMRqstTimeStamp TimeTicks,
2987
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMRqstRndInterval Unsigned32,
dot11WNMRqstDuration Unsigned32,
dot11WNMRqstMcstGroup MacAddress,
dot11WNMRqstMcstTrigCon OCTET STRING,
dot11WNMRqstMcstTrigInactivityTimeout Unsigned32,
dot11WNMRqstMcstTrigReactDelay Unsigned32,
dot11WNMRqstLCRRqstSubject INTEGER,
dot11WNMRqstLCRIntervalUnits INTEGER,
dot11WNMRqstLCRServiceInterval Unsigned32,
dot11WNMRqstLIRRqstSubject INTEGER,
dot11WNMRqstLIRIntervalUnits INTEGER,
dot11WNMRqstLIRServiceInterval Unsigned32,
dot11WNMRqstEventToken Unsigned32,
dot11WNMRqstEventType INTEGER,
dot11WNMRqstEventResponseLimit Unsigned32,
dot11WNMRqstEventTargetBssid MacAddress,
dot11WNMRqstEventSourceBssid MacAddress,
dot11WNMRqstEventTransitTimeThresh Unsigned32,
dot11WNMRqstEventTransitMatchValue OCTET STRING,
dot11WNMRqstEventFreqTransitCountThresh Unsigned32,
dot11WNMRqstEventFreqTransitInterval Unsigned32,
dot11WNMRqstEventRsnaAuthType OCTET STRING,
dot11WNMRqstEapType Unsigned32,
dot11WNMRqstEapVendorId OCTET STRING,
dot11WNMRqstEapVendorType OCTET STRING,
dot11WNMRqstEventRsnaMatchValue OCTET STRING,
dot11WNMRqstEventPeerMacAddress MacAddress,
dot11WNMRqstOperatingClass Unsigned32,
dot11WNMRqstChanNumber Unsigned32,
dot11WNMRqstDiagToken Unsigned32,
dot11WNMRqstDiagType INTEGER,
dot11WNMRqstDiagTimeout Unsigned32,
dot11WNMRqstDiagBssid MacAddress,
dot11WNMRqstDiagProfileId Unsigned32,
dot11WNMRqstDiagCredentials INTEGER,
dot11WNMRqstLocConfigLocIndParams OCTET STRING,
dot11WNMRqstLocConfigChanList OCTET STRING,
dot11WNMRqstLocConfigBcastRate Unsigned32,
dot11WNMRqstLocConfigOptions OCTET STRING,
dot11WNMRqstBssTransitQueryReason INTEGER,
dot11WNMRqstBssTransitReqMode OCTET STRING,
dot11WNMRqstBssTransitDisocTimer Unsigned32,
dot11WNMRqstBssTransitSessInfoURL OCTET STRING,
dot11WNMRqstBssTransitCandidateList OCTET STRING,
dot11WNMRqstColocInterfAutoEnable TruthValue,
dot11WNMRqstColocInterfRptTimeout Unsigned32,
dot11WNMRqstVendorSpecific OCTET STRING,
dot11WNMRqstDestinationURI OCTET STRING
}
dot11WNMRqstIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for WNM Request elements in dot11WNMRequestTable, greater than 0."
::= { dot11WNMRequestEntry 1 }
dot11WNMRqstRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
2988
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity when requesting a
measurement, and by the SME when accepting a management request.
The Row Status column of the current row, used for tracking status of an
individual request. When this attribute is set to Active, AND a
measurement request can be unambiguously created based on the parameters
in the row, then the MLME may proceed to issue the request to its intended
targets when appropriate. If not, this attribute may be set to Not-ready
immediately to indicate parametric errors. However, it is the network
managers
responsibility to correct the error. If the request is successfully issued
to the target STA, then the rowStatus is set to notInService."
::= { dot11WNMRequestEntry 2 }
dot11WNMRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when the table entry is
created, i.e., when requesting a measurement. Changes take effect when
dot11RMRqstRowStatus is set to Active.
This attribute indicates a unique string to identify this request. To
guarantee the uniqueness of this token across multiple network managers,
it is recommended that this token be prefixed with the IP address of the
network manager creating this row. This token is not necessarily
equivalent to the measurement tokens in WNM request frames."
::= { dot11WNMRequestEntry 3 }
dot11WNMRqstIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The ifIndex for this row of WNM Request to be issued on."
::= { dot11WNMRequestEntry 4 }
dot11WNMRqstType OBJECT-TYPE
SYNTAX INTEGER {
mcastDiagnostics(0),
locationCivic(1),
locationIdentifier(2),
event(3),
dignostic(4),
locationConfiguration(5),
bssTransitionQuery(6),
bssTransitionRqst(7),
fms(8),
colocInterference(9)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the request type of this WNM request row."
::= { dot11WNMRequestEntry 5 }
dot11WNMRqstTargetAdd OBJECT-TYPE
SYNTAX MacAddress
2989
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
The MAC address of STA for this row of WNM Request is to be issued to. If
this attribute matches the MAC address of the dot11WNMRqstIfIndex, then
measurement request is for this STA itself to carry out."
::= { dot11WNMRequestEntry 6 }
dot11WNMRqstTimeStamp OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the SysUpTime Value the last time when the
dot11WNMRqstRowStatus is set to active or when this row is created the
first time. This attribute shall be set by this STA or AP automatically,
not by an SNMP manager."
::= { dot11WNMRequestEntry 7 }
dot11WNMRqstRndInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the upper bound of the random delay to be used
prior to making the measurement. See 11.11.3."
DEFVAL { 0 }
::= { dot11WNMRequestEntry 8 }
dot11WNMRqstDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the preferred or mandatory measurement duration
for this Measurement Request."
DEFVAL { 0 }
::= { dot11WNMRequestEntry 9 }
dot11WNMRqstMcstGroup OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
2990
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
Multicast Group address indicates the MAC address of the multicast group
for which diagnostics are requested. The BSSID shall be set to the
wildcard BSSID when the measurement is to be performed on any multicast
group on the operating channel. This attribute is valid only if the
dot11WNMRqstType is 10, indicating a multicast diagnostic request, and is
ignored otherwise."
DEFVAL { 'FFFFFFFFFFFF'H }
::= { dot11WNMRequestEntry 10 }
dot11WNMRqstMcstTrigCon OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the trigger condition for the Multicast
Diagnostic request."
::= { dot11WNMRequestEntry 11 }
dot11WNMRqstMcstTrigInactivityTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "100 TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the time interval value to be use as the
threshold value for Trigger Inactivity Timeout trigger condition."
::= { dot11WNMRequestEntry 12 }
dot11WNMRqstMcstTrigReactDelay OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "100 TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the time interval value during which a measuring
STA does not generate further multicast triggered reports after a trigger
condition has been met."
::= { dot11WNMRequestEntry 13 }
dot11WNMRqstLCRRqstSubject OBJECT-TYPE
SYNTAX INTEGER {
local(0),
remote(1)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
2991
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The attribute indicates the subject of the Location Civic request."
DEFVAL { 0 }
::= { dot11WNMRequestEntry 14 }
dot11WNMRqstLCRIntervalUnits OBJECT-TYPE
SYNTAX INTEGER {
seconds(0),
minutes(1),
hours(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the units used in the Location Civic Request
Service Interval."
::= { dot11WNMRequestEntry 15 }
dot11WNMRqstLCRServiceInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the time interval, expressed in the units
indicated in the Location Civic Request Service Interval Units field, at
which the STA requests to receive Location Civic reports. A Location
Civic Request Service Interval of 0 indicates that only a single Location
Civic report is requested."
::= { dot11WNMRequestEntry 16 }
dot11WNMRqstLIRRqstSubject OBJECT-TYPE
SYNTAX INTEGER {
local(0),
remote(1)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
The attribute indicates the subject of the Location Identifier request."
DEFVAL { 0 }
::= { dot11WNMRequestEntry 17 }
dot11WNMRqstLIRIntervalUnits OBJECT-TYPE
SYNTAX INTEGER {
seconds(0),
minutes(1),
hours(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
2992
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the units used in the Location Identifier request
Service Interval."
::= { dot11WNMRequestEntry 18 }
dot11WNMRqstLIRServiceInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the time interval, expressed in the units
indicated in the Location Identifier Request Interval Units field, at
which the STA requests to receive Location Identifier reports. A Location
Identifier Request Service Interval of 0 indicates that only a single
Location Identifier report is requested."
::= { dot11WNMRequestEntry 19 }
dot11WNMRqstEventToken OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates a unique string to identify this request."
::= { dot11WNMRequestEntry 20 }
dot11WNMRqstEventType OBJECT-TYPE
SYNTAX INTEGER {
transition(0),
rsna(1),
peerToPeer(2),
wnmLog(3),
vendorSpecific(221)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the request type of this WNM Event request."
::= { dot11WNMRequestEntry 21 }
dot11WNMRqstEventResponseLimit OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the maximum number of requested Event Reports to
be included in the Event Report element. A value of 0 indicates that no
2993
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
limit is set on the number of Event Reports to be included in the Event
Report element."
::= { dot11WNMRequestEntry 22 }
dot11WNMRqstEventTargetBssid OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute is used to request that a Transition or RSNA Event Report
includes the event entry when the target BSSID is equal to the indicated
BSSID. A transition event is a STA movement or attempted movement from one
BSS (the source BSS) in one ESS to another BSS (the target BSS) within the
same ESS. The BSSID shall be set to the wildcard BSSID when the
transitions to any BSSID is requested."
DEFVAL { 'FFFFFFFFFFFF'H }
::= { dot11WNMRequestEntry 23 }
dot11WNMRqstEventSourceBssid OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute is used to request that a Transition Event Report includes
the transition event entry when the source BSSID is equal to the indicated
BSSID. A transition event is a STA movement or attempted movement from one
BSS (the source BSS) in one ESS to another BSS (the target BSS) within the
same ESS. The BSSID shall be set to the wildcard BSSID when the
transitions from any BSSID is requested."
DEFVAL { 'FFFFFFFFFFFF'H }
::= { dot11WNMRequestEntry 24 }
dot11WNMRqstEventTransitTimeThresh OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates a value representing the transition time to be
used as the threshold value for the Transition Time condition in TUs. The
Transition Time is defined in 11.24.2.2"
::= { dot11WNMRequestEntry 25 }
dot11WNMRqstEventTransitMatchValue OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
2994
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates a request for the specified transition results
that match the bit descriptions of this field. B0 indicates match when
transition is successful. B1 indicates match when transition fails."
::= { dot11WNMRequestEntry 26 }
dot11WNMRqstEventFreqTransitCountThresh OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the minimum number of matching transitions
detected in the measurement duration to generate a Transition Event
report."
::= { dot11WNMRequestEntry 27 }
dot11WNMRqstEventFreqTransitInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the sliding window time interval during which the
STA detects matching transitions to determine if the Frequent Transition
Count Threshold is exceeded in order to generate a Transition Event
report."
::= { dot11WNMRequestEntry 28 }
dot11WNMRqstEventRsnaAuthType OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute is used to request that an RSNA Event Report include the
event entry when its RSNA Authentication Type matches the indicated RSNA
authentication type value."
::= { dot11WNMRequestEntry 29 }
dot11WNMRqstEapType OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute is used to request that an RSNA Event Report include the
event entry when its EAP Type matches the indicated EAP type value. Valid
EAP Type numbers are assigned by IANA and are defined at http://
www.iana.org/assignments/eap-numbers."
::= { dot11WNMRequestEntry 30 }
2995
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMRqstEapVendorId OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..3))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute is used to request that an RSNA Event Report include the
event entry when its EAP Vendor ID matches the indicated vendor ID value.
The EAP Vendor ID field is included when the EAP Type field is set to 254
and is excluded otherwise."
::= { dot11WNMRequestEntry 31 }
dot11WNMRqstEapVendorType OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..4))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute is used to request that an RSNA Event Report include the
event entry when its EAP Vendor Type matches the indicated EAP vendor type
value. The EAP Vendor ID field is included when the EAP Type field is set
to 254 and is excluded otherwise."
::= { dot11WNMRequestEntry 32 }
dot11WNMRqstEventRsnaMatchValue OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates a request for the specified transition results
that match the bit descriptions of this field. B0 (least significant bit)
indicates match when RSNA is successful. B1 indicates match when RSNA
fails."
::= { dot11WNMRequestEntry 33 }
dot11WNMRqstEventPeerMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute is used to request that a peer-to-peer event report
includes the transition event entry when the MAC address of the peer STA
or IBSS BSSID is equal to the indicated MAC address. The MAC address shall
be set to the wildcard BSSID when the transitions from any peer STA or
IBSS BSSID is requested."
DEFVAL { 'FFFFFFFFFFFF'H }
::= { dot11WNMRequestEntry 34 }
dot11WNMRqstOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
2996
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the channel set for this WNM request. Country,
Operating Class and Channel Number together specify the channel frequency
and spacing for this measurement request. Valid values of Operating Class
are shown in Annex E."
::= { dot11WNMRequestEntry 35 }
dot11WNMRqstChanNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the current operating channel for this WNM
request. The Channel Number is defined only within the indicated Operating
Class as shown in Annex E."
::= { dot11WNMRequestEntry 36 }
dot11WNMRqstDiagToken OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates a unique string to identify this request."
::= { dot11WNMRequestEntry 37 }
dot11WNMRqstDiagType OBJECT-TYPE
SYNTAX INTEGER {
cancelRequest(0),
manufacturerInfoStaRep(1),
configurationProfile(2),
associationDiag(3),
ieee8021xAuthDiag(4),
vendorSpecific(221)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the request type of this WNM Diagnostic request."
::= { dot11WNMRequestEntry 38 }
dot11WNMRqstDiagTimeout OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
2997
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates a value representing the time interval after a
Diagnostic Report is generated during which no additional Diagnostic
Reports shall be sent."
::= { dot11WNMRequestEntry 39 }
dot11WNMRqstDiagBssid OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates a request for a Diagnostic Report from the
indicated BSSID. The BSSID shall be set to the wildcard BSSID when
diagnostics from any BSSID is requested."
DEFVAL { 'FFFFFFFFFFFF'H }
::= { dot11WNMRequestEntry 40 }
dot11WNMRqstDiagProfileId OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates a unique identifier for referencing a
configuration profile available on a device. The value of the identifier
can be any arbitrary value, as long as it is uniquely associated to a
single configuration profile on the device sending the identifier."
::= { dot11WNMRequestEntry 41 }
dot11WNMRqstDiagCredentials OBJECT-TYPE
SYNTAX INTEGER {
none(0),
preSharedKey(1),
usernamePassword(2),
x509Certificate(3),
otherCertificate(4),
oneTimePassword(5),
token(6)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the type of credential used for the IEEE 802.1X
authentication."
::= { dot11WNMRequestEntry 42 }
dot11WNMRqstLocConfigLocIndParams OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(16))
MAX-ACCESS read-create
STATUS current
2998
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates STA Location reporting characteristics. The
format of these Location Indication Parameters are detailed in
9.4.2.71.2."
::= { dot11WNMRequestEntry 43 }
dot11WNMRqstLocConfigChanList OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..252))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute lists location reporting channel information for this
location configuration request. The default value is null. Each pair of
octets indicates a different operating class and channel number for this
request. The detailed format for this list of channels is described in
9.4.2.71.3."
DEFVAL { ''H }
::= { dot11WNMRequestEntry 44 }
dot11WNMRqstLocConfigBcastRate OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "0.5 Mb/s"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the target data rate at which the STA transmits
Location Track Notification frames. A value of 0 indicates the STA
transmits Location Track Notification frames at a rate chosen by the STA
transmitting the Location Track Notification frames."
::= { dot11WNMRequestEntry 45 }
dot11WNMRqstLocConfigOptions OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the location track indication options used; see
9.4.2.71.9."
DEFVAL { ''H }
::= { dot11WNMRequestEntry 46 }
dot11WNMRqstBssTransitQueryReason OBJECT-TYPE
SYNTAX INTEGER {
unspecified(0),
excessiveFrameLossRatesPoorConditions(1),
excessiveDelayForCurrentTrafficStreams(2),
insufficientQosCapacityForCurrentTrafficStreams(3),
firstAssociationToEss(4),
2999
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
loadBalancing(5),
betterApFound(6),
deauthenticatedDisassociatedFromPreviousAp(7),
apFailedIeee8021XEapAuthentication(8),
apFailed4wayHandshake(9),
receivedTooManyReplayCounterFailures(10),
receivedTooManyDataMICFailures(11),
exceededMaxNumberOfRetransmissions(12),
receivedTooManyBroadcastDisassociations(13),
receivedTooManyBroadcastDeauthentications(14),
previousTransitionFailed(15),
lowRSSI(16)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the reason for the BSS Transition Query. The
format for this list of reasons is further detailed in 9.4.2.68.2."
::= { dot11WNMRequestEntry 47 }
dot11WNMRqstBssTransitReqMode OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the type of BSS request transition. B0 (least
significant bit) indicates the Preferred Candidate list is included in
this frame. B1 indicates an abridged format for all BSSIDs not listed in
this frame. B2 indicates that the STA will be disassociated for the
current AP. B3 indicates the BSS is shutting down and that the STA will be
disassociated. B4 indicates that the will be disassociated from the ESS.
The format for this field is detailed in 9.6.14.9."
::= { dot11WNMRequestEntry 48 }
dot11WNMRqstBssTransitDisocTimer OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the number of TBTTs until the serving AP sends a
Disassociation frame to this STA. The value 0 indicates unknown. If the
Disassociation Imminent bit of the Request Mode field is set to 0, this
field is ignored."
::= { dot11WNMRequestEntry 49 }
dot11WNMRqstBssTransitSessInfoURL OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
3000
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute contains a variable-length field formatted in accordance
with IETF RFC 3986-2005."
::= { dot11WNMRequestEntry 50 }
dot11WNMRqstBssTransitCandidateList OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..11426))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute lists one or more Neighbor Report elements described in
9.4.2.37. If the STA has no Transition Candidate information in response
to the BSS Transition Management Query frame, the candidate list is null.
"
::= { dot11WNMRequestEntry 51 }
dot11WNMRqstColocInterfAutoEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute, when true, indicates that the requesting STA requests the
receiving STA to send the Collocated Interference Response frames
periodically with the Report Period interval, as defined in 9.6.14.13, or
when the STA detects a change in the collocated interference."
::= { dot11WNMRequestEntry 52 }
dot11WNMRqstColocInterfRptTimeout OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
UNITS "100 TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute indicates the minimum duration between two consecutive
Collocated Interference Response frames from the reporting STA."
::= { dot11WNMRequestEntry 53 }
dot11WNMRqstVendorSpecific OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute provides an envelope for any optional vendor specific
subelements that may be included in a WNM request element. The default
value is null."
DEFVAL { ''H }
::= { dot11WNMRequestEntry 54}
3001
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMRqstDestinationURI OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..253))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity when making a management
request. Changes take effect when dot11WNMRqstRowStatus is set to Active.
This attribute provides the Destination URI which defines an alternate
destination for the WNM request. The alternate destination may be an
internet address on an Ethernet adapter, for example, to be used when the
wireless link to the requesting entity is unavailable or unreliable. The
default value is null."
DEFVAL { ''H }
::= { dot11WNMRequestEntry 55}
-- **********************************************************************
-- * End of dot11WNMRequest TABLE
-- **********************************************************************
-- ********************************************************************
-- * Wireless network management reports:
-- * Report tables contain WNM reports received by this STA or
-- * results of WNM requests performed by this STA.
-- ********************************************************************
dot11WNMReport OBJECT IDENTIFIER ::= { dot11WirelessNetworkManagement 2 }
-- ********************************************************************
-- * dot11WNMVendorSpecificReport TABLE
-- ********************************************************************
dot11WNMVendorSpecificReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMVendorSpecificReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Vendor Specific reports that have been
received by the MLME. The report tables shall be maintained as FIFO to
preserve freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows shall have different RprtIndex values than those deleted within
the range limitation of the index. One easy way is to increment RprtIndex
for new reports being written in the table."
::= { dot11WNMReport 1 }
dot11WNMVendorSpecificReportEntry OBJECT-TYPE
SYNTAX Dot11WNMVendorSpecificReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMVendorSpecificReportTable Indexed by
dot11WNMVendorSpecificRprtIndex."
INDEX { dot11WNMVendorSpecificRprtIndex }
::= { dot11WNMVendorSpecificReportTable 1 }
Dot11WNMVendorSpecificReportEntry ::=
SEQUENCE {
dot11WNMVendorSpecificRprtIndex Unsigned32,
dot11WNMVendorSpecificRprtRqstToken OCTET STRING,
dot11WNMVendorSpecificRprtIfIndex InterfaceIndex,
dot11WNMVendorSpecificRprtContent OCTET STRING }
3002
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMVendorSpecificRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Vendor Specific Report elements in
dot11WNMVendorSpecificReportTable, greater than 0."
::= { dot11WNMVendorSpecificReportEntry 1 }
dot11WNMVendorSpecificRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMVendorSpecificReportEntry 2 }
dot11WNMVendorSpecificRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMVendorSpecific report has been received
on."
::= { dot11WNMVendorSpecificReportEntry 3 }
dot11WNMVendorSpecificRprtContent OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute provides an envelope for all of the vendor specific
subelements that may be included in a WNM Vendor Specific request element.
The default value is null."
DEFVAL { ''H }
::= { dot11WNMVendorSpecificReportEntry 4 }
-- ********************************************************************
-- * End of dot11WNMVendorSpecificReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMMulticastDiagnosticReport TABLE
-- ********************************************************************
dot11WNMMulticastDiagnosticReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMMulticastDiagnosticReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Multicast Diagnostic reports that have
been received by the MLME. The report tables shall be maintained as FIFO
to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
3003
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 2 }
dot11WNMMulticastDiagnosticReportEntry OBJECT-TYPE
SYNTAX Dot11WNMMulticastDiagnosticReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMMulticastDiagnosticReportTable Indexed by
dot11WNMMulticastDiagnosticRprtIndex."
INDEX { dot11WNMMulticastDiagnosticRprtIndex }
::= { dot11WNMMulticastDiagnosticReportTable 1 }
Dot11WNMMulticastDiagnosticReportEntry ::=
SEQUENCE {
dot11WNMMulticastDiagnosticRprtIndex Unsigned32,
dot11WNMMulticastDiagnosticRprtRqstToken OCTET STRING,
dot11WNMMulticastDiagnosticRprtIfIndex InterfaceIndex,
dot11WNMMulticastDiagnosticRprtMeasurementTime TSFType,
dot11WNMMulticastDiagnosticRprtDuration Unsigned32,
dot11WNMMulticastDiagnosticRprtMcstGroup MacAddress,
dot11WNMMulticastDiagnosticRprtReason OCTET STRING,
dot11WNMMulticastDiagnosticRprtRcvdMsduCount Unsigned32,
dot11WNMMulticastDiagnosticRprtFirstSeqNumber Unsigned32,
dot11WNMMulticastDiagnosticRprtLastSeqNumber Unsigned32,
dot11WNMMulticastDiagnosticRprtMcstRate Unsigned32 }
dot11WNMMulticastDiagnosticRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Multicast Diagnostics reports in
dot11WNMMulticastDiagnosticReportTable, greater than 0."
::= { dot11WNMMulticastDiagnosticReportEntry 1 }
dot11WNMMulticastDiagnosticRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMMulticastDiagnosticReportEntry 2 }
dot11WNMMulticastDiagnosticRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMMulticastDiagnostic report been received
on."
::= { dot11WNMMulticastDiagnosticReportEntry 3 }
dot11WNMMulticastDiagnosticRprtMeasurementTime OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
3004
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the value of the STA TSF timer at the time the
measurement started. In a triggered Multicast Diagnostics report, this is
the TSF value at the reporting STA when the trigger condition was met.
When the reason for sending the report is Performance Measurement and the
Multicast Received MSDU Count is nonzero, the Measurement Time field is
set to the value of the STA TSF timer at the time of the first multicast
MSDU received during the measurement interval."
::= { dot11WNMMulticastDiagnosticReportEntry 4 }
dot11WNMMulticastDiagnosticRprtDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the period over which the Multicast Diagnostics
report was generated."
::= { dot11WNMMulticastDiagnosticReportEntry 5 }
dot11WNMMulticastDiagnosticRprtMcstGroup OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
Multicast Group address indicates the MAC address of the multicast group
for this report element."
::= { dot11WNMMulticastDiagnosticReportEntry 6 }
dot11WNMMulticastDiagnosticRprtReason OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the reason why the measuring STA sent the
Multicast Diagnostics report. B0 (least significant bit) indicates
Inactivity Timeout Trigger. B1 indicates the measurement result from the
completed measurement. These are defined further in 9.4.2.22.12."
::= { dot11WNMMulticastDiagnosticReportEntry 7 }
dot11WNMMulticastDiagnosticRprtRcvdMsduCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the total number of multicast MSDUs with the
indicated Multicast MAC Address that were received during the Measurement
Duration. In a triggered multicast diagnostics measurement this is the
3005
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
total number of MSDUs received between the acceptance of the multicast
diagnostics measurement request and the occurrence of the trigger
condition for MSDUs with the indicated Multicast MAC Address."
::= { dot11WNMMulticastDiagnosticReportEntry 8 }
dot11WNMMulticastDiagnosticRprtFirstSeqNumber OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the twelve least significant bits of the First
Sequence Number field. When the LSB of the first octet of the Multicast
MAC address field in the multicast diagnostic request is set to 1, the
twelve LSBs of the First Sequence Number field contain the sequence number
of the first frame received with destination address equal to the value in
the Multicast MAC address field during the measurement period. When the
LSB of the first octet of the Multicast MAC address field in the multicast
diagnostic request is set to 0, the twelve LSBs of the First Sequence
Number field contain the sequence number of the first group addressed
frame, that does not have the broadcast MAC address as its destination,
received during the measurement period. The four most significant bits of
the First Sequence Number field are set to 0. This field is set to 0 if the
Multicast Received MSDU Count is 0."
::= { dot11WNMMulticastDiagnosticReportEntry 9 }
dot11WNMMulticastDiagnosticRprtLastSeqNumber OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the twelve least significant bits of the Last
Sequence Number field. When the LSB of the first octet of the Multicast
MAC address field in the multicast diagnostic request is set to 1, the
twelve LSBs of the Last Sequence Number field contain the sequence number
of the last frame received with destination address equal to the value in
the Multicast MAC address field during the measurement period. When the
LSB of the first octet of the Multicast MAC address field in the multicast
diagnostic request is 0, the twelve LSBs of the Last Sequence Number field
contain the sequence number of the last group addressed frame, that does
not have the broadcast MAC address as its destination, received during the
measurement period. The four most significant bits of the Last Sequence
Number field are set to 0. This field is set to 0 if the Multicast
Received MSDU Count is 0."
::= { dot11WNMMulticastDiagnosticReportEntry 10 }
dot11WNMMulticastDiagnosticRprtMcstRate OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "0.5 Mb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the highest data rate at which the STA has
received a group addressed frame during the measurement period. The
Multicast Rate field is encoded with the MSB set to 1 to indicate that the
data rate is in the basic rate set, and set to 0 to indicate that the data
3006
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
rate is not in the basic rate set. The remaining 15 bit value is
multiplied by 0.5 Mb/s to indicate the data rate. The Multicast Rate field
is set to 0 by the STA to indicate that it has not received a group
addressed frame during the measurement period."
::= { dot11WNMMulticastDiagnosticReportEntry 11 }
-- ********************************************************************
-- * End of dot11WNMMulticastDiagnosticReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMLocationCivicReport TABLE
-- ********************************************************************
dot11WNMLocationCivicReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMLocationCivicReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Location Civic reports that have been
received by the MLME. The report tables shall be maintained as FIFO to
preserve freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows shall have different RprtIndex values than those deleted within
the range limitation of the index. One easy way is to increment RprtIndex
for new reports being written in the table."
::= { dot11WNMReport 3 }
dot11WNMLocationCivicReportEntry OBJECT-TYPE
SYNTAX Dot11WNMLocationCivicReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMLocationCivicReportTable Indexed by
dot11WNMLocationCivicRprtIndex."
INDEX { dot11WNMLocationCivicRprtIndex }
::= { dot11WNMLocationCivicReportTable 1 }
Dot11WNMLocationCivicReportEntry ::=
SEQUENCE {
dot11WNMLocationCivicRprtIndex Unsigned32,
dot11WNMLocationCivicRprtRqstToken OCTET STRING,
dot11WNMLocationCivicRprtIfIndex InterfaceIndex,
dot11WNMLocationCivicRprtCivicLocation OCTET STRING }
dot11WNMLocationCivicRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Location Civic reports in dot11WNMLocationCivicReportTable,
greater than 0."
::= { dot11WNMLocationCivicReportEntry 1 }
dot11WNMLocationCivicRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
3007
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMLocationCivicReportEntry 2 }
dot11WNMLocationCivicRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMLocationCivic report been received on."
::= { dot11WNMLocationCivicReportEntry 3 }
dot11WNMLocationCivicRprtCivicLocation OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates a variable octet field and contains a list of
civic address elements in TLV format as defined in IETF RFC 4776."
::= { dot11WNMLocationCivicReportEntry 4}
-- ********************************************************************
-- * End of dot11WNMLocationCivicReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMLocationIdentifierReport TABLE
-- ********************************************************************
dot11WNMLocationIdentifierReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMLocationIdentifierReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Location Identifier reports that have
been received by the MLME. The report tables shall be maintained as FIFO
to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 4 }
dot11WNMLocationIdentifierReportEntry OBJECT-TYPE
SYNTAX Dot11WNMLocationIdentifierReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMLocationIdentifierReportTable Indexed by
dot11WNMLocationIdentifierRprtIndex."
INDEX { dot11WNMLocationIdentifierRprtIndex }
::= { dot11WNMLocationIdentifierReportTable 1 }
Dot11WNMLocationIdentifierReportEntry ::=
SEQUENCE {
dot11WNMLocationIdentifierRprtIndex Unsigned32,
dot11WNMLocationIdentifierRprtRqstToken OCTET STRING,
dot11WNMLocationIdentifierRprtIfIndex InterfaceIndex,
dot11WNMLocationIdentifierRprtExpirationTSF TSFType,
dot11WNMLocationIdentifierRprtPublicIdUri OCTET STRING }
dot11WNMLocationIdentifierRprtIndex OBJECT-TYPE
3008
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Location Identifier reports in
dot11WNMLocationIdentifierReportTable, greater than 0."
::= { dot11WNMLocationIdentifierReportEntry 1 }
dot11WNMLocationIdentifierRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMLocationIdentifierReportEntry 2 }
dot11WNMLocationIdentifierRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMLocationIdentifier report been received
on."
::= { dot11WNMLocationIdentifierReportEntry 3 }
dot11WNMLocationIdentifierRprtExpirationTSF OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the value of the STA TSF timer when the Public
Identifier URI/FQDN field value is no longer valid. The Expiration TSF
field set to 0 indicates the Public Identifier URI/FQDN does not expire."
::= { dot11WNMLocationIdentifierReportEntry 4 }
dot11WNMLocationIdentifierRprtPublicIdUri OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains concatenated Public Identifier URI/FQDN
subelements, one per Public Identifier URI or FQDN. The format for a
Public Identifier URI/FQDN subelement is further detailed in 9.4.2.22.14."
::= { dot11WNMLocationIdentifierReportEntry 5}
-- ********************************************************************
-- * End of dot11WNMLocationIdentifierReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMEventTransitReport TABLE
3009
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
dot11WNMEventTransitReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMEventTransitReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Transition Event reports that have
been received by the MLME. The report tables shall be maintained as FIFO
to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 5 }
dot11WNMEventTransitReportEntry OBJECT-TYPE
SYNTAX Dot11WNMEventTransitReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMEventTransitReportTable Indexed by
dot11WNMEventTransitRprtIndex."
INDEX { dot11WNMEventTransitRprtIndex }
::= { dot11WNMEventTransitReportTable 1 }
Dot11WNMEventTransitReportEntry ::=
SEQUENCE {
dot11WNMEventTransitRprtIndex Unsigned32,
dot11WNMEventTransitRprtRqstToken OCTET STRING,
dot11WNMEventTransitRprtIfIndex InterfaceIndex,
dot11WNMEventTransitRprtEventStatus INTEGER,
dot11WNMEventTransitRprtEventTSF TSFType,
dot11WNMEventTransitRprtUTCOffset OCTET STRING,
dot11WNMEventTransitRprtTimeError OCTET STRING,
dot11WNMEventTransitRprtSourceBssid MacAddress,
dot11WNMEventTransitRprtTargetBssid MacAddress,
dot11WNMEventTransitRprtTransitTime Unsigned32,
dot11WNMEventTransitRprtTransitReason INTEGER,
dot11WNMEventTransitRprtTransitResult Unsigned32,
dot11WNMEventTransitRprtSourceRCPI Unsigned32,
dot11WNMEventTransitRprtSourceRSNI Unsigned32,
dot11WNMEventTransitRprtTargetRCPI Unsigned32,
dot11WNMEventTransitRprtTargetRSNI Unsigned32 }
dot11WNMEventTransitRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Transition Event Report elements in
dot11WNMEventTransitReportTable, greater than 0."
::= { dot11WNMEventTransitReportEntry 1 }
dot11WNMEventTransitRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
3010
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMEventTransitReportEntry 2 }
dot11WNMEventTransitRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMEventTransit report been received on."
::= { dot11WNMEventTransitReportEntry 3 }
dot11WNMEventTransitRprtEventStatus OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the status value included in the Event report."
::= { dot11WNMEventTransitReportEntry 4 }
dot11WNMEventTransitRprtEventTSF OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the value of the Event timestamp field."
::= { dot11WNMEventTransitReportEntry 5 }
dot11WNMEventTransitRprtUTCOffset OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(10))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the UTC Offset Time Value optionally included in
the Event report."
::= { dot11WNMEventTransitReportEntry 6 }
dot11WNMEventTransitRprtTimeError OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(5))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the value of the Event Time Error field optionally
included in the Event report."
::= { dot11WNMEventTransitReportEntry 7 }
3011
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMEventTransitRprtSourceBssid OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the source BSSID for the reported transition
event."
::= { dot11WNMEventTransitReportEntry 8 }
dot11WNMEventTransitRprtTargetBssid OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the target BSSID for the reported transition
event."
::= { dot11WNMEventTransitReportEntry 9 }
dot11WNMEventTransitRprtTransitTime OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "TUs"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the transition time for the reported transition
event in TUs. The Transition time is defined as the time difference
between the starting time and the ending time of a transition between APs,
even if the transition results in remaining on the same AP. Start and end
times for a transition event are defined in 11.24.2.2"
::= { dot11WNMEventTransitReportEntry 10 }
dot11WNMEventTransitRprtTransitReason OBJECT-TYPE
SYNTAX INTEGER {
unspecified(0),
excessiveFrameLossRatesPoorConditions(1),
excessiveDelayForCurrentTrafficStreams(2),
insufficientQosCapacityForCurrentTrafficStreams(3),
firstAssociationToEss(4),
loadBalancing(5),
betterApFound(6),
deauthenticatedDisassociatedFromPreviousAp(7),
apFailedIeee8021XEapAuthentication(8),
apFailed4wayHandshake(9),
receivedTooManyReplayCounterFailures(10),
receivedTooManyDataMICFailures(11),
exceededMaxNumberOfRetransmissions(12),
receivedTooManyBroadcastDisassociations(13),
receivedTooManyBroadcastDeauthentications(14),
previousTransitionFailed(15),
lowRSSI(16)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
3012
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME when a management report is completed.
This attribute indicates the reason for the reported BSS Transition event.
The format for this list of reasons is further detailed in 9.4.2.68.2."
::= { dot11WNMEventTransitReportEntry 11 }
dot11WNMEventTransitRprtTransitResult OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the result of the attempted transition and is set
to one of the status codes specified in Table 9-46 in 9.4.1.9."
::= { dot11WNMEventTransitReportEntry 12 }
dot11WNMEventTransitRprtSourceRCPI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the received channel power of the most recently
measured frame from the Source BSSID before the STA reassociates to the
Target BSSID. The Source RCPI is a logarithmic function of the received
signal power, as defined 9.4.2.38."
::= { dot11WNMEventTransitReportEntry 13 }
dot11WNMEventTransitRprtSourceRSNI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the received signal-to-noise indication of the
most recently measured frame from the Source BSSID before the STA
reassociates to the Target BSSID. The Source RSNI is a logarithmic
function of the signal-to-noise ratio, as defined in 9.4.2.41."
::= { dot11WNMEventTransitReportEntry 14 }
dot11WNMEventTransitRprtTargetRCPI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the received channel power of the first measured
frame just after STA reassociates to the Target BSSID. If association with
target BSSID failed, the Target RCPI field indicates the received channel
power of the most recently measured frame from the Target BSSID. The
Target RCPI is a logarithmic function of the received signal power, as
defined 9.4.2.38."
::= { dot11WNMEventTransitReportEntry 15 }
dot11WNMEventTransitRprtTargetRSNI OBJECT-TYPE
SYNTAX Unsigned32(0..255)
3013
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the received signal-to-noise indication of the
first measured frame just after STA reassociates to the Target BSSID. If
association with target BSSID failed, the Target RCPI field indicates the
received signal-to-noise indication of the most recently measured frame
from the Target BSSID. The Target RSNI is a logarithmic function of the
signal-to-noise ratio, as defined in 9.4.2.41."
::= { dot11WNMEventTransitReportEntry 16 }
-- ********************************************************************
-- * End of dot11WNMEventTransitReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMEventRsnaReport TABLE
-- ********************************************************************
dot11WNMEventRsnaReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMEventRsnaReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of RSNA Event reports that have been
received by the MLME. The report tables shall be maintained as FIFO to
preserve freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows shall have different RprtIndex values than those deleted within
the range limitation of the index. One easy way is to increment RprtIndex
for new reports being written in the table."
::= { dot11WNMReport 6 }
dot11WNMEventRsnaReportEntry OBJECT-TYPE
SYNTAX Dot11WNMEventRsnaReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMEventRsnaReportTable Indexed by
dot11WNMEventRsnaRprtIndex."
INDEX { dot11WNMEventRsnaRprtIndex }
::= { dot11WNMEventRsnaReportTable 1 }
Dot11WNMEventRsnaReportEntry ::=
SEQUENCE {
dot11WNMEventRsnaRprtIndex Unsigned32,
dot11WNMEventRsnaRprtRqstToken OCTET STRING,
dot11WNMEventRsnaRprtIfIndex InterfaceIndex,
dot11WNMEventRsnaRprtEventStatus INTEGER,
dot11WNMEventRsnaRprtEventTSF TSFType,
dot11WNMEventRsnaRprtUTCOffset OCTET STRING,
dot11WNMEventRsnaRprtTimeError OCTET STRING,
dot11WNMEventRsnaRprtTargetBssid MacAddress,
dot11WNMEventRsnaRprtAuthType OCTET STRING,
dot11WNMEventRsnaRprtEapMethod OCTET STRING,
dot11WNMEventRsnaRprtResult Unsigned32,
dot11WNMEventRsnaRprtRsnElement OCTET STRING }
dot11WNMEventRsnaRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
3014
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"Index for RSNA Event Report elements in dot11WNMEventRsnaReportTable,
greater than 0."
::= { dot11WNMEventRsnaReportEntry 1 }
dot11WNMEventRsnaRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMEventRsnaReportEntry 2 }
dot11WNMEventRsnaRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMEventRsna report been received on."
::= { dot11WNMEventRsnaReportEntry 3 }
dot11WNMEventRsnaRprtEventStatus OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the status value included in the Event report."
::= { dot11WNMEventRsnaReportEntry 4 }
dot11WNMEventRsnaRprtEventTSF OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the value of the Event timestamp field."
::= { dot11WNMEventRsnaReportEntry 5 }
dot11WNMEventRsnaRprtUTCOffset OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(10))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
3015
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the UTC Offset Time Value optionally included in
the Event report."
::= { dot11WNMEventRsnaReportEntry 6 }
dot11WNMEventRsnaRprtTimeError OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(5))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the value of the Event Time Error field optionally
included in the Event report."
::= { dot11WNMEventRsnaReportEntry 7 }
dot11WNMEventRsnaRprtTargetBssid OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the BSSID of the AP accepting the authorization
attempt."
::= { dot11WNMEventRsnaReportEntry 8 }
dot11WNMEventRsnaRprtAuthType OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the AKM suite, as defined in Table 9-133 in
9.4.2.25.3. The first three octets indicate the OUI or CID. The last octet
indicates the suite type."
::= { dot11WNMEventRsnaReportEntry 9 }
dot11WNMEventRsnaRprtEapMethod OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates a value that identifies the EAP Method. When the
Authentication Type field is set to the value of either 00-0F-AC:1
(Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as
defined in 12.6.10.3) or 00-0F-AC:3 (AKM suite selector for fast BSS
transition as defined in 12.7.1.7), the EAP Method field contains the IANA
assigned EAP type defined at http://www.iana.org/assignments/eap-numbers.
The EAP type contains either the legacy type (1 octet) or the expanded
type (1 octet type = 254, 3-octet Vendor ID, 4-octet Vendor-Type). The EAP
Method field is set to 0 otherwise."
::= { dot11WNMEventRsnaReportEntry 10 }
dot11WNMEventRsnaRprtResult OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
3016
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the result of the RSNA event and is set to one of
the status codes specified in Table 9-46 in 9.4.1.9."
::= { dot11WNMEventRsnaReportEntry 11 }
dot11WNMEventRsnaRprtRsnElement OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the entire contents of the negotiated RSNE at the
time of the authentication attempt. The maximum length of the RSNE field
is less than the maximum length of an RSNE, as defined in 9.4.2.25. If the
length of the RSNE included here exceeds the maximum length of the RSNE
field, the RSNE shall be truncated to the maximum length allowed for the
RSNE field."
::= { dot11WNMEventRsnaReportEntry 12 }
-- ********************************************************************
-- * End of dot11WNMEventRsnaReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMEventPeerReport TABLE
-- ********************************************************************
dot11WNMEventPeerReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMEventPeerReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of peer-to-peer event reports that have
been received by the MLME. The report tables shall be maintained as FIFO
to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 7 }
dot11WNMEventPeerReportEntry OBJECT-TYPE
SYNTAX Dot11WNMEventPeerReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMEventPeerReportTable Indexed by
dot11WNMEventPeerRprtIndex."
INDEX { dot11WNMEventPeerRprtIndex }
::= { dot11WNMEventPeerReportTable 1 }
Dot11WNMEventPeerReportEntry ::=
SEQUENCE {
dot11WNMEventPeerRprtIndex Unsigned32,
dot11WNMEventPeerRprtRqstToken OCTET STRING,
dot11WNMEventPeerRprtIfIndex InterfaceIndex,
dot11WNMEventPeerRprtEventStatus INTEGER,
dot11WNMEventPeerRprtEventTSF TSFType,
dot11WNMEventPeerRprtUTCOffset OCTET STRING,
dot11WNMEventPeerRprtTimeError OCTET STRING,
3017
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMEventPeerRprtPeerMacAddress MacAddress,
dot11WNMEventPeerRprtOperatingClass Unsigned32,
dot11WNMEventPeerRprtChanNumber Unsigned32,
dot11WNMEventPeerRprtStaTxPower Integer32,
dot11WNMEventPeerRprtConnTime Unsigned32,
dot11WNMEventPeerRprtPeerStatus INTEGER }
dot11WNMEventPeerRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Peer-to-Peer Event Report elements in
dot11WNMEventPeerReportTable, greater than 0."
::= { dot11WNMEventPeerReportEntry 1 }
dot11WNMEventPeerRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMEventPeerReportEntry 2 }
dot11WNMEventPeerRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMEventPeer report been received on."
::= { dot11WNMEventPeerReportEntry 3 }
dot11WNMEventPeerRprtEventStatus OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the status value included in the Event report."
::= { dot11WNMEventPeerReportEntry 4 }
dot11WNMEventPeerRprtEventTSF OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
3018
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute contains the value of the Event timestamp field."
::= { dot11WNMEventPeerReportEntry 5 }
dot11WNMEventPeerRprtUTCOffset OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(10))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the UTC Offset Time Value optionally included in
the Event report."
::= { dot11WNMEventPeerReportEntry 6 }
dot11WNMEventPeerRprtTimeError OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(5))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the value of the Event Time Error field optionally
included in the Event report."
::= { dot11WNMEventPeerReportEntry 7 }
dot11WNMEventPeerRprtPeerMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the MAC address of the peer STA or IBSS BSSID. If
this event is for a peer-to-peer link in an infrastructure BSS, this field
contains the MAC address of the peer STA. If this event is for a peer-to-
peer link in an IBSS, this field contains the BSSID of the IBSS."
::= { dot11WNMEventPeerReportEntry 8 }
dot11WNMEventPeerRprtOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the channel set for this peer-to-peer event
report. Country, Operating Class and Channel Number together specify the
channel frequency and spacing for this measurement request. Valid values
of Operating Class as shown in Annex E."
::= { dot11WNMEventPeerReportEntry 9 }
dot11WNMEventPeerRprtChanNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the current operating channel for this peer-to-
3019
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
peer event report. The Channel Number is defined only within the indicated
Operating Class as shown in Annex E."
::= { dot11WNMEventPeerReportEntry 10 }
dot11WNMEventPeerRprtStaTxPower OBJECT-TYPE
SYNTAX Integer32 (-128..127)
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the STA transmit power used for the peer-to-peer
link. The STA Tx Power field indicates the target transmit power at the
antenna with a tolerance of +/-5 dB for the lowest basic rate of the
reporting STA."
::= { dot11WNMEventPeerReportEntry 11 }
dot11WNMEventPeerRprtConnTime OBJECT-TYPE
SYNTAX Unsigned32 (0..16777215)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates a value representing the connection time for the
reported peer-to-peer event. If the Peer Status is 0, this field indicates
the duration of the Direct Link. If the Peer Status is 1, this field
indicates the time difference from the time the Direct Link was
established to the time at which the reporting STA generated the event
report. If the Peer Status is 2, this field indicates the duration of the
IBSS membership. If the Peer Status is 3, this field indicates the time
difference from the time the STA joined the IBSS to the time at which the
reporting STA generated the event report. See 11.24.2.4."
::= { dot11WNMEventPeerReportEntry 12 }
dot11WNMEventPeerRprtPeerStatus OBJECT-TYPE
SYNTAX INTEGER {
directLinkTerminated(0),
directLinkActive(1),
ibssMembershipTerminated(2),
ibssMembershipActive(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the peer link connection status."
::= { dot11WNMEventPeerReportEntry 13 }
-- ********************************************************************
-- * End of dot11WNMEventPeerReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMEventWNMLogReport TABLE
-- ********************************************************************
dot11WNMEventWNMLogReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMEventWNMLogReportEntry
3020
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of WNMLog Event reports that have been
received by the MLME. The report tables shall be maintained as FIFO to
preserve freshness, thus the rows in this table can be deleted for memory
constraints or other implementation constraints determined by the vendor.
New rows shall have different RprtIndex values than those deleted within
the range limitation of the index. One easy way is to increment RprtIndex
for new reports being written in the table."
::= { dot11WNMReport 8 }
dot11WNMEventWNMLogReportEntry OBJECT-TYPE
SYNTAX Dot11WNMEventWNMLogReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMEventWNMLogReportTable Indexed by
dot11WNMEventWNMLogRprtIndex."
INDEX { dot11WNMEventWNMLogRprtIndex }
::= { dot11WNMEventWNMLogReportTable 1 }
Dot11WNMEventWNMLogReportEntry ::=
SEQUENCE {
dot11WNMEventWNMLogRprtIndex Unsigned32,
dot11WNMEventWNMLogRprtRqstToken OCTET STRING,
dot11WNMEventWNMLogRprtIfIndex InterfaceIndex,
dot11WNMEventWNMLogRprtEventStatus INTEGER,
dot11WNMEventWNMLogRprtEventTSF TSFType,
dot11WNMEventWNMLogRprtUTCOffset OCTET STRING,
dot11WNMEventWNMLogRprtTimeError OCTET STRING,
dot11WNMEventWNMLogRprtContent OCTET STRING }
dot11WNMEventWNMLogRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for WNMLog Event Report elements in dot11WNMEventWNMLogReportTable,
greater than 0."
::= { dot11WNMEventWNMLogReportEntry 1 }
dot11WNMEventWNMLogRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMEventWNMLogReportEntry 2 }
dot11WNMEventWNMLogRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMEventWNMLog report been received on."
::= { dot11WNMEventWNMLogReportEntry 3 }
3021
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMEventWNMLogRprtEventStatus OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the status value included in the Event report."
::= { dot11WNMEventWNMLogReportEntry 4 }
dot11WNMEventWNMLogRprtEventTSF OBJECT-TYPE
SYNTAX TSFType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the value of the Event timestamp field."
::= { dot11WNMEventWNMLogReportEntry 5 }
dot11WNMEventWNMLogRprtUTCOffset OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(10))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the UTC Offset Time Value optionally included in
the Event report."
::= { dot11WNMEventWNMLogReportEntry 6 }
dot11WNMEventWNMLogRprtTimeError OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(5))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the value of the Event Time Error field optionally
included in the Event report."
::= { dot11WNMEventWNMLogReportEntry 7 }
dot11WNMEventWNMLogRprtContent OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..2284))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the entire syslog message, consisting of the PRI,
HEADER, and MSG portion of a WNM log message as described in IETF RFC
5424. The TAG field of the MSG portion of the message is a 17 octet string
3022
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
containing the ASCII representation of the STA MAC address using
hexadecimal notation with colons between octets. The octet containing the
Individual/Group bit occurs last, and that bit is in the least significant
position within that octet. See 11.24.2.5."
::= { dot11WNMEventWNMLogReportEntry 8 }
-- ********************************************************************
-- * End of dot11WNMEventWNMLogReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMDiagMfrInfoReport TABLE
-- ********************************************************************
dot11WNMDiagMfrInfoReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMDiagMfrInfoReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Manufacturer Information STA reports
that have been received by the MLME. The report tables shall be maintained
as FIFO to preserve freshness, thus the rows in this table can be deleted
for memory constraints or other implementation constraints determined by
the vendor. New rows shall have different RprtIndex values than those
deleted within the range limitation of the index. One easy way is to
increment RprtIndex for new reports being written in the table."
::= { dot11WNMReport 9 }
dot11WNMDiagMfrInfoReportEntry OBJECT-TYPE
SYNTAX Dot11WNMDiagMfrInfoReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMDiagMfrInfoReportTable Indexed by
dot11WNMDiagMfrInfoRprtIndex."
INDEX { dot11WNMDiagMfrInfoRprtIndex }
::= { dot11WNMDiagMfrInfoReportTable 1 }
Dot11WNMDiagMfrInfoReportEntry ::=
SEQUENCE {
dot11WNMDiagMfrInfoRprtIndex Unsigned32,
dot11WNMDiagMfrInfoRprtRqstToken OCTET STRING,
dot11WNMDiagMfrInfoRprtIfIndex InterfaceIndex,
dot11WNMDiagMfrInfoRprtEventStatus INTEGER,
dot11WNMDiagMfrInfoRprtMfrOi OCTET STRING,
dot11WNMDiagMfrInfoRprtMfrIdString OCTET STRING,
dot11WNMDiagMfrInfoRprtMfrModelString OCTET STRING,
dot11WNMDiagMfrInfoRprtMfrSerialNumberString OCTET STRING,
dot11WNMDiagMfrInfoRprtMfrFirmwareVersion OCTET STRING,
dot11WNMDiagMfrInfoRprtMfrAntennaType OCTET STRING,
dot11WNMDiagMfrInfoRprtCollocRadioType INTEGER,
dot11WNMDiagMfrInfoRprtDeviceType INTEGER,
dot11WNMDiagMfrInfoRprtCertificateID OCTET STRING}
dot11WNMDiagMfrInfoRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Manufacturer Information STA Report elements in
dot11WNMDiagMfrInfoReportTable, greater than 0."
::= { dot11WNMDiagMfrInfoReportEntry 1 }
dot11WNMDiagMfrInfoRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
3023
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMDiagMfrInfoReportEntry 2 }
dot11WNMDiagMfrInfoRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMDiagMfrInfo report been received on."
::= { dot11WNMDiagMfrInfoReportEntry 3 }
dot11WNMDiagMfrInfoRprtEventStatus OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the status value included in the Event report."
::= { dot11WNMDiagMfrInfoReportEntry 4}
dot11WNMDiagMfrInfoRprtMfrOi OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..5))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the Manufacturer OI for the reported Manufacturer
Information STA Diagnostic."
::= { dot11WNMDiagMfrInfoReportEntry 5 }
dot11WNMDiagMfrInfoRprtMfrIdString OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the Manufacturer ID string for the reported
Manufacturer Information STA Diagnostic. The ID attribute contains an
ASCII string indicating the manufacturer identifier of the wireless
network adaptor. This string is not null terminated."
::= { dot11WNMDiagMfrInfoReportEntry 6 }
3024
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMDiagMfrInfoRprtMfrModelString OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the Manufacturer model string for the reported
Manufacturer Information STA Diagnostic. The model attribute contains an
ASCII string indicating the model of the wireless network adaptor. This
string is not null terminated."
::= { dot11WNMDiagMfrInfoReportEntry 7 }
dot11WNMDiagMfrInfoRprtMfrSerialNumberString OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the Manufacturer serial number string for the
reported Manufacturer Information STA Diagnostic. The serial number
attribute contains an ASCII string indicating the serial number of the
wireless network adaptor. This string is not null terminated."
::= { dot11WNMDiagMfrInfoReportEntry 8 }
dot11WNMDiagMfrInfoRprtMfrFirmwareVersion OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the Manufacturer firmware version string for the
reported Manufacturer Information STA Diagnostic. The firmware version
attribute contains an ASCII string identifying the version of firmware
currently installed on the wireless network adaptor. This string is not
null terminated."
::= { dot11WNMDiagMfrInfoReportEntry 9 }
dot11WNMDiagMfrInfoRprtMfrAntennaType OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the Manufacturer antenna type string for the
reported Manufacturer Information STA Diagnostic. The first octet of this
string indicates the antenna count, and the second octet indicates the
antenna gain. The antenna gain indicates the peak gain in dBi of the
antenna connected to the wireless network adaptor. The remaining octets
contain an ASCII string indicating the type of antenna connected to the
wireless network adaptor."
::= { dot11WNMDiagMfrInfoReportEntry 10 }
dot11WNMDiagMfrInfoRprtCollocRadioType OBJECT-TYPE
SYNTAX INTEGER {
reserved(0),
cellular(1),
3025
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
cordless(2),
gps(3),
ieee80211(4),
ieee80215(5),
ieee80216(6),
ieee80220(7),
ieee80222(8),
digitalAudioBroadcasting(9),
digitalVideoBroadcasting(10)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the type of the collocated radio."
::= { dot11WNMDiagMfrInfoReportEntry 11 }
dot11WNMDiagMfrInfoRprtDeviceType OBJECT-TYPE
SYNTAX INTEGER {
reserved(0),
referenceDesign(1),
accessPointWirelessRouterSoho(2),
enterpriseAccessPoint(3),
broadbandGateway(4),
digitalStillCamera(5),
portableVideoCamera(6),
networkedWebCamera(7),
digitalAudioStationary(8),
digitalAudioPortable(9),
setTopBoxMediaServer(10),
tvMonitorDigitalPictureFrame(11),
gameConsoleGameAdaptor(12),
gamingDevice(13),
mediaServerMediaAdaptor(14),
networkStorageDevice(15),
externalCard(16),
internalCard(17),
ultraMobilPc(18),
notebookComputer(19),
personalDigitalAssistant(20),
printerPrintServer(21),
phoneDualMode(22),
phoneSingleMode(23),
smartphoneDualMode(24),
smartphoneSingleMode(25),
otherDevices(221)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the type of device in which the IEEE 802.11 STA
resides."
::= { dot11WNMDiagMfrInfoReportEntry 12 }
dot11WNMDiagMfrInfoRprtCertificateID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..251))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
3026
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the Certificate ID for the
reported Manufacturer Information STA Diagnostic."
::= { dot11WNMDiagMfrInfoReportEntry 13 }
-- ********************************************************************
-- * End of dot11WNMDiagMfrInfoReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMDiagConfigProfReport TABLE
-- ********************************************************************
dot11WNMDiagConfigProfReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMDiagConfigProfReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Configuration Profile reports that
have been received by the MLME. The report tables shall be maintained as
FIFO to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 10 }
dot11WNMDiagConfigProfReportEntry OBJECT-TYPE
SYNTAX Dot11WNMDiagConfigProfReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMDiagConfigProfReportTable Indexed by
dot11WNMDiagConfigProfRprtIndex."
INDEX { dot11WNMDiagConfigProfRprtIndex }
::= { dot11WNMDiagConfigProfReportTable 1 }
Dot11WNMDiagConfigProfReportEntry ::=
SEQUENCE {
dot11WNMDiagConfigProfRprtIndex Unsigned32,
dot11WNMDiagConfigProfRprtRqstToken OCTET STRING,
dot11WNMDiagConfigProfRprtIfIndex InterfaceIndex,
dot11WNMDiagConfigProfRprtEventStatus INTEGER,
dot11WNMDiagConfigProfRprtProfileId Unsigned32,
dot11WNMDiagConfigProfRprtSupportedOperatingClasses OCTET STRING,
dot11WNMDiagConfigProfRprtTxPowerMode INTEGER,
dot11WNMDiagConfigProfRprtTxPowerLevels OCTET STRING,
dot11WNMDiagConfigProfRprtCipherSuite OCTET STRING,
dot11WNMDiagConfigProfRprtAkmSuite OCTET STRING,
dot11WNMDiagConfigProfRprtEapType Unsigned32,
dot11WNMDiagConfigProfRprtEapVendorID OCTET STRING,
dot11WNMDiagConfigProfRprtEapVendorType OCTET STRING,
dot11WNMDiagConfigProfRprtCredentialType INTEGER,
dot11WNMDiagConfigProfRprtSSID OCTET STRING,
dot11WNMDiagConfigProfRprtPowerSaveMode INTEGER }
dot11WNMDiagConfigProfRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Configuration Profile Report elements in
dot11WNMDiagConfigProfReportTable, greater than 0."
3027
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11WNMDiagConfigProfReportEntry 1 }
dot11WNMDiagConfigProfRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMDiagConfigProfReportEntry 2 }
dot11WNMDiagConfigProfRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMDiagConfigProf report been received on."
::= { dot11WNMDiagConfigProfReportEntry 3 }
dot11WNMDiagConfigProfRprtEventStatus OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the status value included in the Event report."
::= { dot11WNMDiagConfigProfReportEntry 4}
dot11WNMDiagConfigProfRprtProfileId OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates a unique identifier for referencing a
configuration profile available on a device. The value of the identifier
can be any arbitrary value, as long as it is uniquely associated to a
single configuration profile on the device sending the identifier."
::= { dot11WNMDiagConfigProfReportEntry 5 }
dot11WNMDiagConfigProfRprtSupportedOperatingClasses OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
3028
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the current Operating Class followed by a list of
each Supported Operating Class, as defined in 9.4.2.54. Each octet
contains an integer representing an operating class. Operating Classes are
defined in Annex E. The default value is null."
DEFVAL { ''H }
::= { dot11WNMDiagConfigProfReportEntry 6 }
dot11WNMDiagConfigProfRprtTxPowerMode OBJECT-TYPE
SYNTAX INTEGER {
fixedPowerMode(0),
automaticPowerMode(1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the power mode of the STA."
::= { dot11WNMDiagConfigProfReportEntry 7 }
dot11WNMDiagConfigProfRprtTxPowerLevels OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute lists the power levels for the STA. Each octet contains an
integer representing a power level encoded as a 2s complement value in
dBm, rounded to the nearest integer. If the Power Mode is automatic, the
list contains only the minimum and the maximum power levels for the STA.
If the Power Mode is fixed, the list contains one or more fixed power
level settings available at this STA, arranged in increasing numerical
order."
::= { dot11WNMDiagConfigProfReportEntry 8 }
dot11WNMDiagConfigProfRprtCipherSuite OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the cipher suite, as defined in Table 9-131. The
first three octets indicate the OUI or CID. The last octet indicates the
suite type."
::= { dot11WNMDiagConfigProfReportEntry 9 }
dot11WNMDiagConfigProfRprtAkmSuite OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the AKM suite, as defined in Table 9-133 in
9.4.2.25.3. The first three octets indicate the OUI or CID. The last octet
indicates the suite type."
::= { dot11WNMDiagConfigProfReportEntry 10 }
3029
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMDiagConfigProfRprtEapType OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the single EAP method used by the STA. Valid EAP
Type numbers are assigned by IANA and are defined at http://www.iana.org/
assignments/eap-numbers."
::= { dot11WNMDiagConfigProfReportEntry 11 }
dot11WNMDiagConfigProfRprtEapVendorID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..3))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the EAP Vendor ID number for the EAP method used
by the STA. The EAP Vendor ID field is included when the EAP Type field is
set to 254 and is excluded otherwise."
::= { dot11WNMDiagConfigProfReportEntry 12 }
dot11WNMDiagConfigProfRprtEapVendorType OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the EAP Vendor Type number for the EAP method
used by the STA. The EAP Vendor Type field is included when the EAP Type
field is set to 254 and is excluded otherwise."
::= { dot11WNMDiagConfigProfReportEntry 13 }
dot11WNMDiagConfigProfRprtCredentialType OBJECT-TYPE
SYNTAX INTEGER {
none(0),
preSharedKey(1),
userNamePassword(2),
x509Certificate(3),
otherCertificate(4),
oneTimePassword(5),
token(6)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the type of IEEE 802.1X credentials used by the
STA for this authentication diagnostic."
::= { dot11WNMDiagConfigProfReportEntry 14 }
dot11WNMDiagConfigProfRprtSSID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
3030
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the SSID for the diagnostic report, as defined in
9.4.2.2."
::= { dot11WNMDiagConfigProfReportEntry 15 }
dot11WNMDiagConfigProfRprtPowerSaveMode OBJECT-TYPE
SYNTAX INTEGER {
unknownMode(0),
none(1),
psDtims1Mode(2),
psDtims0Mode(3),
uapsdMode(4),
sapsdMode(5),
upsmpMode(6),
spsmpMode(7),
smpsMode(8),
wnmSleepMode(9),
fmsMode(10),
timBroadcastMode(11),
tfsMode(12),
tdlsPeerUapsdMode(13),
tdlsPeerPsmMode(14)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the power save mode in use by the STA, as defined
in Table 9-185."
::= { dot11WNMDiagConfigProfReportEntry 16 }
-- ********************************************************************
-- * End of dot11WNMDiagConfigProfReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMDiagAssocReport TABLE
-- ********************************************************************
dot11WNMDiagAssocReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMDiagAssocReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Association Diagnostic reports that
have been received by the MLME. The report tables shall be maintained as
FIFO to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 11 }
dot11WNMDiagAssocReportEntry OBJECT-TYPE
SYNTAX Dot11WNMDiagAssocReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMDiagAssocReportTable Indexed by
dot11WNMDiagAssocRprtIndex."
INDEX { dot11WNMDiagAssocRprtIndex }
3031
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11WNMDiagAssocReportTable 1 }
Dot11WNMDiagAssocReportEntry ::=
SEQUENCE {
dot11WNMDiagAssocRprtIndex Unsigned32,
dot11WNMDiagAssocRprtRqstToken OCTET STRING,
dot11WNMDiagAssocRprtIfIndex InterfaceIndex,
dot11WNMDiagAssocRprtEventStatus INTEGER,
dot11WNMDiagAssocRprtBssid MacAddress,
dot11WNMDiagAssocRprtOperatingClass Unsigned32,
dot11WNMDiagAssocRprtChannelNumber Unsigned32,
dot11WNMDiagAssocRprtStatusCode Unsigned32 }
dot11WNMDiagAssocRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Association Diagnostic Report elements in
dot11WNMDiagAssocReportTable, greater than 0."
::= { dot11WNMDiagAssocReportEntry 1 }
dot11WNMDiagAssocRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMDiagAssocReportEntry 2 }
dot11WNMDiagAssocRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMDiagAssoc report been received on."
::= { dot11WNMDiagAssocReportEntry 3 }
dot11WNMDiagAssocRprtEventStatus OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the status value included in the Event report."
::= { dot11WNMDiagAssocReportEntry 4 }
dot11WNMDiagAssocRprtBssid OBJECT-TYPE
SYNTAX MacAddress
3032
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the BSSID for the target AP for this Association
Diagnostic report."
::= { dot11WNMDiagAssocReportEntry 5 }
dot11WNMDiagAssocRprtOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the channel set for the target AP for this
Association Diagnostic report. Country, Operating Class and Channel Number
together specify the channel frequency and spacing for this measurement
request. Valid values of Operating Class as shown in Annex E."
::= { dot11WNMDiagAssocReportEntry 6 }
dot11WNMDiagAssocRprtChannelNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the operating channel of the target AP for this
Association Diagnostic report. The Channel Number is defined only within
the indicated Operating Class as sown in Annex E."
::= { dot11WNMDiagAssocReportEntry 7 }
dot11WNMDiagAssocRprtStatusCode OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the result of the association diagnostic and is
set to one of the status codes specified in Table 9-46 in 9.4.1.9."
::= { dot11WNMDiagAssocReportEntry 8 }
-- ********************************************************************
-- * End of dot11WNMDiagAssocReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMDiag8021xAuthReport TABLE
-- ********************************************************************
dot11WNMDiag8021xAuthReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMDiag8021xAuthReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of IEEE 802.1X Authentication Diagnostic
reports that have been received by the MLME. The report tables shall be
maintained as FIFO to preserve freshness, thus the rows in this table can
3033
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
be deleted for memory constraints or other implementation constraints
determined by the vendor. New rows shall have different RprtIndex values
than those deleted within the range limitation of the index. One easy way
is to increment RprtIndex for new reports being written in the table."
::= { dot11WNMReport 12 }
dot11WNMDiag8021xAuthReportEntry OBJECT-TYPE
SYNTAX Dot11WNMDiag8021xAuthReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMDiag8021xAuthReportTable Indexed by
dot11WNMDiag8021xAuthRprtIndex."
INDEX { dot11WNMDiag8021xAuthRprtIndex }
::= { dot11WNMDiag8021xAuthReportTable 1 }
Dot11WNMDiag8021xAuthReportEntry ::=
SEQUENCE {
dot11WNMDiag8021xAuthRprtIndex Unsigned32,
dot11WNMDiag8021xAuthRprtRqstToken OCTET STRING,
dot11WNMDiag8021xAuthRprtIfIndex InterfaceIndex,
dot11WNMDiag8021xAuthRprtEventStatus INTEGER,
dot11WNMDiag8021xAuthRprtBssid MacAddress,
dot11WNMDiag8021xAuthRprtOperatingClass Unsigned32,
dot11WNMDiag8021xAuthRprtChannelNumber Unsigned32,
dot11WNMDiag8021xAuthRprtEapType Unsigned32,
dot11WNMDiag8021xAuthRprtEapVendorID OCTET STRING,
dot11WNMDiag8021xAuthRprtEapVendorType OCTET STRING,
dot11WNMDiag8021xAuthRprtCredentialType INTEGER,
dot11WNMDiag8021xAuthRprtStatusCode Unsigned32 }
dot11WNMDiag8021xAuthRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for IEEE 802.1X Authentication Diagnostic Report elements in
dot11WNMDiag8021xAuthReportTable, greater than 0."
::= { dot11WNMDiag8021xAuthReportEntry 1 }
dot11WNMDiag8021xAuthRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMDiag8021xAuthReportEntry 2 }
dot11WNMDiag8021xAuthRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMDiag8021xAuth report been received on."
::= { dot11WNMDiag8021xAuthReportEntry 3 }
dot11WNMDiag8021xAuthRprtEventStatus OBJECT-TYPE
3034
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the status value included in the Event report."
::= { dot11WNMDiag8021xAuthReportEntry 4 }
dot11WNMDiag8021xAuthRprtBssid OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the BSSID for the target AP for this
Authentication Diagnostic report."
::= { dot11WNMDiag8021xAuthReportEntry 5 }
dot11WNMDiag8021xAuthRprtOperatingClass OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the channel set for the target AP for this
Authentication Diagnostic report. Country, Operating Class and Channel
Number together specify the channel frequency and spacing for this
measurement request. Valid values of Operating Class as shown in Annex E."
::= { dot11WNMDiag8021xAuthReportEntry 6 }
dot11WNMDiag8021xAuthRprtChannelNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the operating channel of the target AP for this
Authentication Diagnostic report. The Channel Number is defined only
within the indicated Operating Class as shown in Annex E."
::= { dot11WNMDiag8021xAuthReportEntry 7 }
dot11WNMDiag8021xAuthRprtEapType OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the single EAP method used by the STA. Valid EAP
3035
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Type numbers are assigned by IANA and are defined at http://www.iana.org/
assignments/eap-numbers."
::= { dot11WNMDiag8021xAuthReportEntry 8 }
dot11WNMDiag8021xAuthRprtEapVendorID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..3))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the EAP Vendor ID number for the EAP method used
by the STA. The EAP Vendor ID field is included when the EAP Type field is
set to 254 and is excluded otherwise."
::= { dot11WNMDiag8021xAuthReportEntry 9 }
dot11WNMDiag8021xAuthRprtEapVendorType OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the EAP Vendor Type number for the EAP method
used by the STA. The EAP Vendor Type field is included when the EAP Type
field is set to 254 and is excluded otherwise."
::= { dot11WNMDiag8021xAuthReportEntry 10 }
dot11WNMDiag8021xAuthRprtCredentialType OBJECT-TYPE
SYNTAX INTEGER {
none(0),
preSharedKey(1),
userNamePassword(2),
x509Certificate(3),
otherCertificate(4),
oneTimePassword(5),
token(6)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the type of IEEE 802.1X credentials used by the
STA for this authentication diagnostic."
::= { dot11WNMDiag8021xAuthReportEntry 11 }
dot11WNMDiag8021xAuthRprtStatusCode OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the result of the authentication diagnostic and
is set to one of the status codes specified in Table 9-46."
::= { dot11WNMDiag8021xAuthReportEntry 12 }
-- ********************************************************************
-- * End of dot11WNMDiag8021xAuthReport TABLE
3036
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMLocConfigReport TABLE
-- ********************************************************************
dot11WNMLocConfigReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMLocConfigReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of location configuration reports that
have been received by the MLME. The report tables shall be maintained as
FIFO to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 13 }
dot11WNMLocConfigReportEntry OBJECT-TYPE
SYNTAX Dot11WNMLocConfigReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMLocConfigReportTable Indexed by
dot11WNMLocConfigRprtIndex."
INDEX { dot11WNMLocConfigRprtIndex }
::= { dot11WNMLocConfigReportTable 1 }
Dot11WNMLocConfigReportEntry ::=
SEQUENCE {
dot11WNMLocConfigRprtIndex Unsigned32,
dot11WNMLocConfigRprtRqstToken OCTET STRING,
dot11WNMLocConfigRprtIfIndex InterfaceIndex,
dot11WNMLocConfigRprtLocIndParams OCTET STRING,
dot11WNMLocConfigRprtLocIndChanList OCTET STRING,
dot11WNMLocConfigRprtLocIndBcastRate Unsigned32,
dot11WNMLocConfigRprtLocIndOptions OCTET STRING,
dot11WNMLocConfigRprtStatusConfigSubelemId INTEGER,
dot11WNMLocConfigRprtStatusResult INTEGER,
dot11WNMLocConfigRprtVendorSpecificRprtContent OCTET STRING }
dot11WNMLocConfigRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Location Configuration Report elements in
dot11WNMLocConfigReportTable, greater than 0."
::= { dot11WNMLocConfigReportEntry 1 }
dot11WNMLocConfigRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
3037
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11WNMLocConfigReportEntry 2 }
dot11WNMLocConfigRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMLocConfig report been received on."
::= { dot11WNMLocConfigReportEntry 3 }
dot11WNMLocConfigRprtLocIndParams OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates STA Location reporting characteristics. The
format of these Location Indication Parameters are detailed in
9.4.2.71.2."
::= { dot11WNMLocConfigReportEntry 4 }
dot11WNMLocConfigRprtLocIndChanList OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..254))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute lists location indication reporting channel information for
this location configuration report. The default value is null. Each pair
of octets indicates a different Operating Class and channel number for
this request. The detailed format for this list of channels as described
in 9.4.2.71.3."
DEFVAL { ''H }
::= { dot11WNMLocConfigReportEntry 5 }
dot11WNMLocConfigRprtLocIndBcastRate OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "0.5 Mb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the data rate at which the STA broadcasts its
Location Track Notification frames."
::= { dot11WNMLocConfigReportEntry 6 }
dot11WNMLocConfigRprtLocIndOptions OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the location track indication options used; see
9.4.2.71.9."
::= { dot11WNMLocConfigReportEntry 7}
3038
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMLocConfigRprtStatusConfigSubelemId OBJECT-TYPE
SYNTAX INTEGER {
multipleSubelemIds(0),
locationIndicationParams(1),
locationIndicationChannels(2),
locationStatus(3),
radioInformation(4),
motion(5),
locationIndicationBcastDataRate(6),
timeOfDeparture(7),
vendorSpecific(8)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute is set to a specific Location Parameters subelement ID
transmitted in a Location Configuration Request frame. If the following
StatusResult attribute field value applies to more than one subelement
then the Config subelement ID is set to 0. If the Status field value
applies to one subelement, then a Location Status subelement may be
included in the Location Configuration Response for each configuration
subelement that has a non-Success Status value."
::= { dot11WNMLocConfigReportEntry 8 }
dot11WNMLocConfigRprtStatusResult OBJECT-TYPE
SYNTAX INTEGER {
successful(0),
requestFailed(1),
requestRefused(2),
requestIncapable(3),
detectedFrequentTransition(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the resulting status of the Location Configuration
Request frame for the indicated Location Parameter subelement ID, as
listed in Table 9-175, Event Report Status."
::= { dot11WNMLocConfigReportEntry 9 }
dot11WNMLocConfigRprtVendorSpecificRprtContent OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute provides an envelope for all of the vendor specific
subelements that may be included in Location Configuration Report element.
The default value is null."
DEFVAL { ''H }
::= { dot11WNMLocConfigReportEntry 10 }
-- ********************************************************************
-- * End of dot11WNMLocConfigReport TABLE
-- ********************************************************************
3039
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
-- * dot11WNMBssTransitReport TABLE
-- ********************************************************************
dot11WNMBssTransitReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMBssTransitReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of BSS Transition Management reports that
have been received by the MLME. The report tables shall be maintained as
FIFO to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 14 }
dot11WNMBssTransitReportEntry OBJECT-TYPE
SYNTAX Dot11WNMBssTransitReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMBssTransitReportTable Indexed by
dot11WNMBssTransitRprtIndex."
INDEX { dot11WNMBssTransitRprtIndex }
::= { dot11WNMBssTransitReportTable 1 }
Dot11WNMBssTransitReportEntry ::=
SEQUENCE {
dot11WNMBssTransitRprtIndex Unsigned32,
dot11WNMBssTransitRprtRqstToken OCTET STRING,
dot11WNMBssTransitRprtIfIndex InterfaceIndex,
dot11WNMBssTransitRprtStatusCode INTEGER,
dot11WNMBssTransitRprtBSSTerminationDelay Unsigned32,
dot11WNMBssTransitRprtTargetBssid MacAddress,
dot11WNMBssTransitRprtCandidateList OCTET STRING }
dot11WNMBssTransitRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for BSS Transition Management Report elements in
dot11WNMBssTransitReportTable, greater than 0."
::= { dot11WNMBssTransitReportEntry 1 }
dot11WNMBssTransitRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMBssTransitReportEntry 2 }
dot11WNMBssTransitRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
3040
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex for this row of WNMBssTransit report been received on."
::= { dot11WNMBssTransitReportEntry 3 }
dot11WNMBssTransitRprtStatusCode OBJECT-TYPE
SYNTAX INTEGER {
accept(0),
rejectUnspecified(1),
rejectInsufficientBeacons(2),
rejectInsufficientCapacity(3),
rejectBssTerminationUndesired(4),
rejectBssTerminationDelayRequest(5),
rejectBssTransitionCandidateListprovided(6),
rejectNoSuitableBssTransitionCandidates(7),
rejectLeavingEss(8)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the status of this BSS Transition report."
::= { dot11WNMBssTransitReportEntry 4 }
dot11WNMBssTransitRprtBSSTerminationDelay OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "minutes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the time that the responding STA requests the BSS
to delay termination. This attribute is included only if the Status Code
field value is set to 5."
::= { dot11WNMBssTransitReportEntry 5 }
dot11WNMBssTransitRprtTargetBssid OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the target BSSID for this BSS Transition report."
::= { dot11WNMBssTransitReportEntry 6 }
dot11WNMBssTransitRprtCandidateList OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..11426))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute lists one or more Neighbor Report elements which are BSS
transition candidates for this request. The Neighbor Report elements are
described in 9.4.2.37."
::= { dot11WNMBssTransitReportEntry 7 }
3041
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- ********************************************************************
-- * End of dot11WNMBssTransitReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11WNMColocInterfReport TABLE
-- ********************************************************************
dot11WNMColocInterfReportTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11WNMColocInterfReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains the current list of Collocated Interference reports that
have been received by the MLME. The report tables shall be maintained as
FIFO to preserve freshness, thus the rows in this table can be deleted for
memory constraints or other implementation constraints determined by the
vendor. New rows shall have different RprtIndex values than those deleted
within the range limitation of the index. One easy way is to increment
RprtIndex for new reports being written in the table."
::= { dot11WNMReport 16 }
dot11WNMColocInterfReportEntry OBJECT-TYPE
SYNTAX Dot11WNMColocInterfReportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11WNMColocInterfReportTable Indexed by
dot11WNMColocInterfRprtIndex."
INDEX { dot11WNMColocInterfRprtIndex }
::= { dot11WNMColocInterfReportTable 1 }
Dot11WNMColocInterfReportEntry ::=
SEQUENCE {
dot11WNMColocInterfRprtIndex Unsigned32,
dot11WNMColocInterfRprtRqstToken OCTET STRING,
dot11WNMColocInterfRprtIfIndex InterfaceIndex,
dot11WNMColocInterfRprtPeriod Unsigned32,
dot11WNMColocInterfRprtInterfLevel Integer32,
dot11WNMColocInterfRprtInterfAccuracy Unsigned32,
dot11WNMColocInterfRprtInterfIndex Unsigned32,
dot11WNMColocInterfRprtInterfInterval Integer32,
dot11WNMColocInterfRprtInterfBurstLength Integer32,
dot11WNMColocInterfRprtInterfStartTime Integer32,
dot11WNMColocInterfRprtInterfCenterFreq Integer32,
dot11WNMColocInterfRprtInterfBandwidth Unsigned32 }
dot11WNMColocInterfRprtIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for Collocated Interference Report elements in
dot11WNMColocInterfReportTable, greater than 0."
::= { dot11WNMColocInterfReportEntry 1 }
dot11WNMColocInterfRprtRqstToken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
3042
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the request token that was indicated in the WNM
request that generated this measurement report. This should be an exact
match to the original dot11WNMRqstToken attribute. Note that there may be
multiple entries in the table that match this value since a single request
may generate multiple WNM reports."
::= { dot11WNMColocInterfReportEntry 2 }
dot11WNMColocInterfRprtIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
The ifIndex for this row of WNMColocInterf report been received on."
::= { dot11WNMColocInterfReportEntry 3 }
dot11WNMColocInterfRprtPeriod OBJECT-TYPE
SYNTAX Unsigned32(0..255)
UNITS "100 TU"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates how often the STA periodically reports the
collocated interference. If the Report Period field is set to 0, then the
reporting is not periodic, and a report is generated when the STA detects
a change in the collocated interference. See 11.24.9 for further details."
::= { dot11WNMColocInterfReportEntry 4 }
dot11WNMColocInterfRprtInterfLevel OBJECT-TYPE
SYNTAX Integer32(-128..127)
UNITS "dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the maximum level of the collocated interference
power in units of dBm over all receive chains averaged over a 4 s period
during an interference period and across interference bandwidth. When the
interference level is unknown, the field is set to +127 dBm. When the
interference level is equal or greater than 126 dBm, the field is set to
+126 dBm. If no collocated interference is present the field is set to -
128 dBm. When the interference level is equal or lower than -127 dBm, the
field is set to -127 dBm. The interference level is referenced to the
antenna connector (see definition in Clause 3) used for reception, like
RCPI."
::= { dot11WNMColocInterfReportEntry 5 }
dot11WNMColocInterfRprtInterfAccuracy OBJECT-TYPE
SYNTAX Unsigned32(0..15)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
3043
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the expected accuracy of the estimate of
interference in dB with 95% confidence interval. If the Interference Level
field is X (dBm) and the expected accuracy field is Y (dB), the actual
interference level is in the range X - Y to X +Y with the probability of
95%. If the accuracy is unknown then the Expected Accuracy field is set to
15."
::= { dot11WNMColocInterfReportEntry 6 }
dot11WNMColocInterfRprtInterfIndex OBJECT-TYPE
SYNTAX Unsigned32(0..15)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the interference index that is unique for each
type of interference source. The field set to 0 indicates that no
collocated interference is present. See 11.24.9 for further details."
::= { dot11WNMColocInterfReportEntry 7 }
dot11WNMColocInterfRprtInterfInterval OBJECT-TYPE
SYNTAX Integer32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the interval between two successive periods of
interference. When the interval between two successive periods of
interference is variable the field is set to 2**32-1. When the interval
between two successive periods of interference is equal or greater than
2**32-2 the field is set to 2**32-2. If no collocated interference is
present the field is set to 0."
::= { dot11WNMColocInterfReportEntry 8 }
dot11WNMColocInterfRprtInterfBurstLength OBJECT-TYPE
SYNTAX Integer32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the duration of each period of interference. When
the duration of each period of interference is variable the field is set
to 2**32-1). When the duration of each period of interference is equal or
greater than 2**32-2, the field is set to 2**32-2. If no collocated
interference is present the field is set to 0."
::= { dot11WNMColocInterfReportEntry 9 }
dot11WNMColocInterfRprtInterfStartTime OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute contains the least significant 4 octets (i.e., B0-B31) of
the TSF timer at the start of the interference burst. When either the
3044
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Interference Interval or the Interference Burst Length fields are set to
2**32-1, this field indicates the average duty cycle. The average duty
cycle value is defined as Floor((2**32-2) * [average interference burst
length (microsecond)]/[average interference interval (microsecond)] +
0.5). When the interference is nonperiodic the Interference Start Time
field is set to 0. If no collocated interference is present the field is
set to 0."
::= { dot11WNMColocInterfReportEntry 10 }
dot11WNMColocInterfRprtInterfCenterFreq OBJECT-TYPE
SYNTAX Integer32
UNITS "5 kHz"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates center frequency of interference. When center
frequency is unknown, the center frequency of the STA's operating channel
is reported. If no collocated interference is present the field is set to
0."
::= { dot11WNMColocInterfReportEntry 11 }
dot11WNMColocInterfRprtInterfBandwidth OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "5 kHz"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when a management report is completed.
This attribute indicates the bandwidth at the -3 dB roll-off point of the
interference signal. When bandwidth of the interference signal is unknown,
the field is set to 65 535. When bandwidth of the interference signal is
equal or greater than 65 534 the field is set to 65 534. If no collocated
interference is present the field is set to 0."
::= { dot11WNMColocInterfReportEntry 12 }
-- ********************************************************************
-- * End of dot11WNMColocInterfReport TABLE
-- ********************************************************************
-- ********************************************************************
-- * END of Wireless Network Management Interface MIB
-- ********************************************************************
-- **********************************************************************
-- * END of IEEE 802.11 RM and WNM Interface MIB
-- **********************************************************************
3045
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- **********************************************************************
-- * dot11MeshSTAConfig TABLE
-- **********************************************************************
dot11MeshSTAConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11MeshSTAConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Mesh Station Configuration attributes. In tabular form to allow for
multiple instances on an agent."
::= { dot11smt 23 }
dot11MeshSTAConfigEntry OBJECT-TYPE
SYNTAX Dot11MeshSTAConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11MeshStationConfigTable. It is possible for there to
be multiple IEEE 802.11 interfaces on one agent, each with its unique MAC
address. The relationship between an IEEE 802.11 interface and an
interface in the context of the Internet-standard MIB is one-to-one. As
such, the value of an ifIndex object instance can be directly used to
identify corresponding instances of the objects defined herein.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Inter-
face tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11MeshSTAConfigTable 1 }
Dot11MeshSTAConfigEntry ::=
SEQUENCE {
dot11MeshID OCTET STRING,
dot11MeshNumberOfPeerings Unsigned32,
dot11MeshAcceptingAdditionalPeerings TruthValue,
dot11MeshConnectedToMeshGate TruthValue,
dot11MeshSecurityActivated TruthValue,
dot11MeshActiveAuthenticationProtocol INTEGER,
dot11MeshMaxRetries Unsigned32,
dot11MeshRetryTimeout Unsigned32,
dot11MeshConfirmTimeout Unsigned32,
dot11MeshHoldingTimeout Unsigned32,
dot11MeshConfigGroupUpdateCount Unsigned32,
dot11MeshActivePathSelectionProtocol INTEGER,
dot11MeshActivePathSelectionMetric INTEGER,
dot11MeshForwarding TruthValue,
dot11MeshTTL Unsigned32,
dot11MeshGateAnnouncements TruthValue,
dot11MeshGateAnnouncementInterval Unsigned32,
dot11MeshActiveCongestionControlMode INTEGER,
dot11MeshActiveSynchronizationMethod INTEGER,
dot11MeshNbrOffsetMaxNeighbor Unsigned32,
dot11MBCAActivated TruthValue,
dot11MeshBeaconTimingReportInterval Unsigned32,
dot11MeshBeaconTimingReportMaxNum Unsigned32,
dot11MeshDelayedBeaconTxInterval Unsigned32,
dot11MeshDelayedBeaconTxMaxDelay Unsigned32,
dot11MeshDelayedBeaconTxMinDelay Unsigned32,
dot11MeshAverageBeaconFrameDuration Unsigned32,
dot11MeshSTAMissingAckRetryLimit Unsigned32,
dot11MeshAwakeWindowDuration Unsigned32,
dot11MCCAImplemented TruthValue,
dot11MCCAActivated TruthValue,
dot11MAFlimit Unsigned32,
dot11MCCAScanDuration Unsigned32,
3046
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11MCCAAdvertPeriodMax Unsigned32,
dot11MCCAMinTrackStates Unsigned32,
dot11MCCAMaxTrackStates Unsigned32,
dot11MCCAOPtimeout Unsigned32,
dot11MCCACWmin Unsigned32,
dot11MCCACWmax Unsigned32,
dot11MCCAAIFSN Unsigned32
}
dot11MeshID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute reflects the Mesh ID configured in this entity."
::= { dot11MeshSTAConfigEntry 1 }
dot11MeshNumberOfPeerings OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the number of mesh peering currently maintained
by the STA. This value is reflected in the Number of Peerings subfield in
the Mesh Formation Info field in the Mesh Configuration element."
::= { dot11MeshSTAConfigEntry 2 }
dot11MeshAcceptingAdditionalPeerings OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates whether the station is willing to accept
additional peerings. This value is reflected in the Accepting Additional
Mesh Peerings subfield in the Mesh Capability field in the Mesh
Configuration element."
::= { dot11MeshSTAConfigEntry 3 }
dot11MeshConnectedToMeshGate OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates whether the station has a mesh path to a mesh
gate. This value is reflected in the Connected to Mesh Gate subfield in
the Mesh Formation Info field in the Mesh Configuration element."
::= { dot11MeshSTAConfigEntry 4 }
3047
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11MeshSecurityActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute specifies whether the station is security enabled."
::= { dot11MeshSTAConfigEntry 5 }
dot11MeshActiveAuthenticationProtocol OBJECT-TYPE
SYNTAX INTEGER {
null (0),
sae (1),
ieee8021x (2),
vendorSpecific (255) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute specifies the active authentication protocol."
DEFVAL { null }
::= { dot11MeshSTAConfigEntry 6 }
dot11MeshMaxRetries OBJECT-TYPE
SYNTAX Unsigned32 (0..16)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum number of Mesh Peering Open retries
that can be sent to establish a new mesh peering instance in a mesh BSS."
DEFVAL { 2 }
::= { dot11MeshSTAConfigEntry 7 }
dot11MeshRetryTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the initial retry timeout used by the Mesh
Peering Open message."
DEFVAL { 40 }
::= { dot11MeshSTAConfigEntry 8 }
dot11MeshConfirmTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "milliseconds"
MAX-ACCESS read-write
STATUS current
3048
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the initial retry timeout used by the Mesh
Peering Open message."
DEFVAL { 40 }
::= { dot11MeshSTAConfigEntry 9 }
dot11MeshHoldingTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the confirm timeout used by the mesh peering
management to close a mesh peering."
DEFVAL { 40 }
::= { dot11MeshSTAConfigEntry 10 }
dot11MeshConfigGroupUpdateCount OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies how many times the Mesh Group Key Inform frame
will be retried per mesh group key handshake attempt."
DEFVAL { 3 }
::= { dot11MeshSTAConfigEntry 11 }
dot11MeshActivePathSelectionProtocol OBJECT-TYPE
SYNTAX INTEGER { hwmp (1), vendorSpecific (255) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute specifies the active path selection protocol."
DEFVAL { hwmp }
::= { dot11MeshSTAConfigEntry 12 }
dot11MeshActivePathSelectionMetric OBJECT-TYPE
SYNTAX INTEGER { airtimeLinkMetric (1), vendorSpecific (255) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute specifies the active path selection metric."
DEFVAL { airtimeLinkMetric }
::= { dot11MeshSTAConfigEntry 13 }
3049
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11MeshForwarding OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the ability of a mesh STA to forward MSDUs."
DEFVAL { true }
::= { dot11MeshSTAConfigEntry 14 }
dot11MeshTTL OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of Mesh TTL subfield set at a source
mesh STA."
DEFVAL { 31 }
::= { dot11MeshSTAConfigEntry 15 }
dot11MeshGateAnnouncements OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies whether the mesh STA activates mesh gate
announcements."
DEFVAL { false }
::= { dot11MeshSTAConfigEntry 16 }
dot11MeshGateAnnouncementInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the gate announcement interval. The gate
announcement interval is the number of seconds between the transmission of
two gate announcements."
DEFVAL { 10 }
::= { dot11MeshSTAConfigEntry 17 }
dot11MeshActiveCongestionControlMode OBJECT-TYPE
SYNTAX INTEGER {
null (0),
congestionControlSignaling (1),
vendorSpecific (255) }
MAX-ACCESS read-write
STATUS current
3050
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute specifies the active congestion control protocol."
DEFVAL { null }
::= { dot11MeshSTAConfigEntry 18 }
dot11MeshActiveSynchronizationMethod OBJECT-TYPE
SYNTAX INTEGER {
neighborOffsetSynchronization (1),
vendorSpecific (255) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute specifies the MBSS's active synchronization method."
DEFVAL { neighborOffsetSynchronization }
::= { dot11MeshSTAConfigEntry 19 }
dot11MeshNbrOffsetMaxNeighbor OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute specifies the maximum number of neighbor STAs with which
the mesh STA maintains synchronization using the neighbor offset
synchronization method."
DEFVAL { 50 }
::= { dot11MeshSTAConfigEntry 20 }
dot11MBCAActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies whether the station activates mesh beacon
collision avoidance mechanisms."
DEFVAL { false }
::= { dot11MeshSTAConfigEntry 21 }
dot11MeshBeaconTimingReportInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
This attribute specifies when the Beacon Timing element is present in
Beacon frames. The Beacon Timing element is present when the DTIM Count
value in the Beacon frame is zero or equal to an integer multiple of the
set value."
3051
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { 4 }
::= { dot11MeshSTAConfigEntry 22 }
dot11MeshBeaconTimingReportMaxNum OBJECT-TYPE
SYNTAX Unsigned32 (0..50)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum number of the Beacon Timing
Information field contained in a Beacon Timing element in the transmitting
Beacon frames."
DEFVAL { 16 }
::= { dot11MeshSTAConfigEntry 23 }
dot11MeshDelayedBeaconTxInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the interval of the delayed beacon transmission
for the purpose of MBCA. The value is expressed in units of Beacon
Interval. The value 0 indicates that the delayed beacon transmission is
disabled."
DEFVAL { 0 }
::= { dot11MeshSTAConfigEntry 24 }
dot11MeshDelayedBeaconTxMaxDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum delay time from a TBTT of delayed
beacon transmissions for the purpose of MBCA."
DEFVAL { 2048 }
::= { dot11MeshSTAConfigEntry 25 }
dot11MeshDelayedBeaconTxMinDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..4023)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum delay time from a TBTT of delayed
beacon transmissions for the purpose of MBCA."
DEFVAL { 0 }
::= { dot11MeshSTAConfigEntry 26 }
3052
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11MeshAverageBeaconFrameDuration OBJECT-TYPE
SYNTAX Unsigned32 (0..16383)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the average duration of the last 16 Beacon frames
of other mesh STAs received by this mesh STA."
::= { dot11MeshSTAConfigEntry 27 }
dot11MeshSTAMissingAckRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of times the mesh STA may retry a
frame for which it does not receive an Ack frame for a STA in power save
mode after the mesh STA does not receive an Ack frame to an individually
addressed MPDU sent with the EOSP subfield set to 1."
::= { dot11MeshSTAConfigEntry 28 }
dot11MeshAwakeWindowDuration OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the duration of the mesh Awake Window in TUs.
This value is reflected in the value of the Mesh Awake Window element."
::= { dot11MeshSTAConfigEntry 29 }
dot11MCCAImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute specifies whether the MCCA is implemented in this station."
::= { dot11MeshSTAConfigEntry 30 }
dot11MCCAActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies whether the station is MCCA enabled."
DEFVAL { false }
3053
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11MeshSTAConfigEntry 31 }
dot11MAFlimit OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "1/255"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum MCCA access fraction allowed at the
mesh STA."
DEFVAL { 128 }
::= { dot11MeshSTAConfigEntry 32 }
dot11MCCAScanDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the duration after the activation of MCCA that
the mesh STA shall not initiate or accept MCCAOP Setup Requests."
DEFVAL { 3200 } -- (2 ** 5) * 100
::= { dot11MeshSTAConfigEntry 33 }
dot11MCCAAdvertPeriodMax OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "DTIM intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum interval that a mesh STA with
dot11MCCAActivated equal to true waits for an MCCAOP advertisement."
DEFVAL { 1 }
::= { dot11MeshSTAConfigEntry 34 }
dot11MCCAMinTrackStates OBJECT-TYPE
SYNTAX Unsigned32 (83..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a capability variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the smallest number of MCCAOP reservations that
the MAC entity is able to track."
DEFVAL { 83 }
::= { dot11MeshSTAConfigEntry 35 }
dot11MCCAMaxTrackStates OBJECT-TYPE
3054
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Unsigned32 (83..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The lower bound is given by the current value of dot11MCCAMinTrackStates.
This attribute specifies the maximum number of MCCAOP reservations that
the MAC entity is able to track."
DEFVAL { 83 }
::= { dot11MeshSTAConfigEntry 36 }
dot11MCCAOPtimeout OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the timeout value for an MCCAOP teardown."
DEFVAL { 10000 }
::= { dot11MeshSTAConfigEntry 37 }
dot11MCCACWmin OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of the minimum size of the window that
shall be used by the mesh STA during the MCCAOP for which it is the MCCAOP
owner for generating a random number for the backoff."
DEFVAL { 0 }
::= { dot11MeshSTAConfigEntry 38 }
dot11MCCACWmax OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of the maximum size of the window that
shall be used by the mesh STA during the MCCAOP for which it is the MCCAOP
owner for generating a random number for the backoff. The value of this
attribute shall be such that it could always be expressed in the form of
2**X - 1, where X is an integer."
DEFVAL { 31 }
::= { dot11MeshSTAConfigEntry 39 }
dot11MCCAAIFSN OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS read-write
STATUS current
3055
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of slots, after a SIFS, that the mesh
STA shall sense the medium idle either before transmitting or executing a
backoff during an MCCAOP for which it is the MCCAOP owner."
DEFVAL { 1 }
::= { dot11MeshSTAConfigEntry 40 }
-- **********************************************************************
-- * End of dot11MeshSTAConfig TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11MeshHWMPConfig TABLE
-- **********************************************************************
dot11MeshHWMPConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11MeshHWMPConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Mesh Station HWMP Configuration attributes. In tabular form to allow for
multiple instances on an agent."
::= { dot11smt 24 }
dot11MeshHWMPConfigEntry OBJECT-TYPE
SYNTAX Dot11MeshHWMPConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11MeshHWMPConfigTable. It is possible for there to be
multiple IEEE 802.11 interfaces on one agent, each with its unique MAC
address. The relationship between an IEEE 802.11 interface and an
interface in the context of the Internet-standard MIB is one-to-one. As
such, the value of an ifIndex object instance can be directly used to
identify corresponding instances of the objects defined herein.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11MeshHWMPConfigTable 1 }
Dot11MeshHWMPConfigEntry ::=
SEQUENCE {
dot11MeshHWMPmaxPREQretries Unsigned32,
dot11MeshHWMPnetDiameter Unsigned32,
dot11MeshHWMPnetDiameterTraversalTime Unsigned32,
dot11MeshHWMPpreqMinInterval Unsigned32,
dot11MeshHWMPperrMinInterval Unsigned32,
dot11MeshHWMPactivePathToRootTimeout Unsigned32,
dot11MeshHWMPactivePathTimeout Unsigned32,
dot11MeshHWMProotMode INTEGER,
dot11MeshHWMProotInterval Unsigned32,
dot11MeshHWMPrannInterval Unsigned32,
dot11MeshHWMPtargetOnly INTEGER,
dot11MeshHWMPmaintenanceInterval Unsigned32,
dot11MeshHWMPconfirmationInterval Unsigned32
}
dot11MeshHWMPmaxPREQretries OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-write
3056
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of Action frames containing a PREQ
element that an originator mesh STA can send to a particular path target
for a specific path discovery."
DEFVAL { 3 }
::= { dot11MeshHWMPConfigEntry 1}
dot11MeshHWMPnetDiameter OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the estimate of the maximum number of hops that
it takes for an HWMP element to propagate across the mesh BSS."
DEFVAL { 31 }
::= { dot11MeshHWMPConfigEntry 2}
dot11MeshHWMPnetDiameterTraversalTime OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the estimate of the interval of time that it
takes for an HWMP element to propagate across the mesh BSS."
DEFVAL { 500 }
::= { dot11MeshHWMPConfigEntry 3}
dot11MeshHWMPpreqMinInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum interval of time during which a mesh
STA can send only one Action frame containing a PREQ element."
DEFVAL { 100 }
::= { dot11MeshHWMPConfigEntry 4}
dot11MeshHWMPperrMinInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
3057
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum interval of time during which a mesh
STA can send only one Action frame containing a PERR element."
DEFVAL { 100 }
::= { dot11MeshHWMPConfigEntry 5}
dot11MeshHWMPactivePathToRootTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object shall specify the time for which mesh STAs receiving a
proactive PREQ element shall consider the forwarding information to the
root mesh STA to be valid; it needs to be greater than
dot11MeshHWMProotInterval."
DEFVAL { 5000 }
::= { dot11MeshHWMPConfigEntry 6}
dot11MeshHWMPactivePathTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the time for which mesh STAs receiving a PREQ
element to individual target(s) shall consider the forwarding information
to be valid."
DEFVAL { 5000 }
::= { dot11MeshHWMPConfigEntry 7}
dot11MeshHWMProotMode OBJECT-TYPE
SYNTAX INTEGER {
noRoot(0),
proactivePREQnoPREP(2),
proactivePREQwithPREP(3),
rann(4) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute controls the configuration of a mesh STA as root mesh STA.
A mesh STA is configured as a root mesh STA if dot11MeshHWMProotMode is
set to 2, 3 or 4. Different values correspond to different modes of the
root mesh STA. The mesh STA is not a root mesh STA when the attribute is
set to 0."
DEFVAL { noRoot }
::= { dot11MeshHWMPConfigEntry 8}
dot11MeshHWMProotInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
3058
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum interval of time during which a root
mesh STA can send only one Action frame containing a proactive PREQ
element."
DEFVAL { 2000 }
::= { dot11MeshHWMPConfigEntry 9}
dot11MeshHWMPrannInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum interval of time during which a mesh
STA can send only one Action frame containing a RANN element."
DEFVAL { 2000 }
::= { dot11MeshHWMPConfigEntry 10}
dot11MeshHWMPtargetOnly OBJECT-TYPE
SYNTAX INTEGER { intermediateMSTA(0), targetOnly(1) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when set to intermediateMSTA (0), allows intermediate mesh
STAs to respond with a PREP element to a PREQ element if they have valid
forwarding information to the requested target. When set to targetOnly
(1), only the target mesh STA is allowed to respond with a PREP element to
a PREQ element."
DEFVAL { targetOnly }
::= { dot11MeshHWMPConfigEntry 11}
dot11MeshHWMPmaintenanceInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum interval of time during which a mesh
STA can send only one Action frame containing a PREQ element for path
maintenance."
DEFVAL { 2000 }
::= { dot11MeshHWMPConfigEntry 12}
dot11MeshHWMPconfirmationInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "TUs"
3059
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum interval of time during which a mesh
STA can send only one Action frame containing a PREQ element for root path
confirmation."
DEFVAL { 2000 }
::= { dot11MeshHWMPConfigEntry 13}
-- ********************************************************************
-- * End of dot11MeshHWMPConfig TABLE
-- ********************************************************************
-- *******************************************************************
-- * dot11RSNAConfigPasswordValue TABLE
-- *******************************************************************
dot11RSNAConfigPasswordValueTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RSNAConfigPasswordValueEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"When SAE authentication is the selected AKM suite,
this table is used to locate the binary representation
of a shared, secret, and potentially low-entropy word,
phrase, code, or key that will be used as the
authentication credential between a TA/RA pair.
This table is logically write-only. Reading this table
returns unsuccessful status or null or zero."
::= { dot11smt 25 }
dot11RSNAConfigPasswordValueEntry OBJECT-TYPE
SYNTAX Dot11RSNAConfigPasswordValueEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the Password Value Table"
INDEX { dot11RSNAConfigPasswordValueIndex }
::= { dot11RSNAConfigPasswordValueTable 1 }
Dot11RSNAConfigPasswordValueEntry ::=
SEQUENCE {
dot11RSNAConfigPasswordValueIndex Unsigned32,
dot11RSNAConfigPasswordCredential OCTET STRING,
dot11RSNAConfigPasswordPeerMac MacAddress }
dot11RSNAConfigPasswordValueIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar
objects in the Password Value table."
::= { dot11RSNAConfigPasswordValueEntry 1 }
dot11RSNAConfigPasswordCredential OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-write
STATUS current
3060
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This variable is a binary representation of a shared,
secret, and potentially low-entropy word, phrase, code
or key used as an authentication credential.
Any character-based word or phrase shall be converted
into a canonical binary representation according to
12.4.3 before populating the Password Credential."
::= { dot11RSNAConfigPasswordValueEntry 2 }
dot11RSNAConfigPasswordPeerMac OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This variable represents the MAC address of the peer
that is to be authenticated. A wildcard BSSID is
permitted when passwords are shared among peers."
::= { dot11RSNAConfigPasswordValueEntry 3 }
-- *******************************************************************
-- * End of dot11RSNAConfigPasswordValue TABLE
-- *******************************************************************
-- *******************************************************************
-- * dot11RSNAConfigDLCGroup TABLE
-- *******************************************************************
dot11RSNAConfigDLCGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RSNAConfigDLCGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table gives a prioritized list of domain parameter set
Identifiers for discrete logarithm cryptography (DLC) groups."
::= { dot11smt 26 }
dot11RSNAConfigDLCGroupEntry OBJECT-TYPE
SYNTAX Dot11RSNAConfigDLCGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the DLC Group Table."
INDEX { dot11RSNAConfigDLCGroupIndex }
::= { dot11RSNAConfigDLCGroupTable 1 }
Dot11RSNAConfigDLCGroupEntry ::=
SEQUENCE {
dot11RSNAConfigDLCGroupIndex Unsigned32,
dot11RSNAConfigDLCGroupIdentifier Unsigned32 }
dot11RSNAConfigDLCGroupIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
3061
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"The variable used to identify instances of the columnar
objects in the DLC Group Table. Entries are sorted
based on the Group Index according to the priority
of the Group Identifier relative to other objects.
More preferred Group Identifiers will have a lower
index in the Group Entry."
::= { dot11RSNAConfigDLCGroupEntry 1 }
dot11RSNAConfigDLCGroupIdentifier OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This variable uniquely identifies a domain parameter
set for a group in the IANA registry `Group Description'
attributes for IETF RFC 2409 (IKE)."
::= { dot11RSNAConfigDLCGroupEntry 2 }
-- *********************************************************************
-- * End of dot11RSNAConfigDLCGroup TABLE
-- *********************************************************************
-- *******************************************************************
-- * dot11DMGSTAConfigTable TABLE
-- *******************************************************************
dot11DMGSTAConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11DMGSTAConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a table management object.
The dot11DMGSTAConfig Table"
::= { dot11smt 27 }
dot11DMGSTAConfigEntry OBJECT-TYPE
SYNTAX Dot11DMGSTAConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an entry in the dot11DMGSTAConfig Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11DMGSTAConfigTable 1 }
Dot11DMGSTAConfigEntry ::=
SEQUENCE {
dot11DMGOptionImplemented TruthValue,
dot11RelayActivated TruthValue,
dot11REDSActivated TruthValue,
dot11RDSActivated TruthValue,
dot11MultipleMACActivated TruthValue,
dot11ClusteringActivated TruthValue
}
dot11DMGOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
3062
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
DMG Capable Object
This attribute, when true, indicates the STA is DMG
capable. This attribute, when false, indicates the STA is not DMG capable.
The default value of this attribute is false."
DEFVAL { false }
::= { dot11DMGSTAConfigEntry 1 }
dot11RelayActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates the DMG STA is Relay
capable. This attribute, when false, indicates the STA is not Relay capa-
ble. The default value of this attribute is false."
DEFVAL { false }
::= { dot11DMGSTAConfigEntry 2 }
dot11REDSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates the DMG STA is capable of operating
as a REDS. This attribute, when false, indicates the STA is not capable of
operating as a REDS."
DEFVAL { false }
::= { dot11DMGSTAConfigEntry 3 }
dot11RDSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates the DMG STA is capable of operating
as a RDS. This attribute, when false, indicates the STA is not capable of
operating as a RDS."
DEFVAL { false }
::= { dot11DMGSTAConfigEntry 4 }
dot11MultipleMACActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
If dot11MultipleMACActivated is true, the STA is capable of managing more
than one MAC address."
3063
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { false }
::= { dot11DMGSTAConfigEntry 5 }
dot11ClusteringActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
If dot11ClusteringActivated is true, the STA is capable of supporting AP
or PCP Clustering."
DEFVAL { false }
::= { dot11DMGSTAConfigEntry 6 }
-- *******************************************************************
-- * End of dot11DMGSTAConfigTable TABLE
-- *******************************************************************
-- **********************************************************************
-- * dot11AVOptions TABLE
-- **********************************************************************
dot11AVOptionsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11AVOptionsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"AV streaming attributes. In tabular form to allow for multiple instances
on an agent. This table applies to the interface only if
dot11RobustAVStreamingImplemented is true in the dot11StationConfigTable.
Otherwise this table should be ignored."
::= { dot11smt 28 }
dot11AVOptionsEntry OBJECT-TYPE
SYNTAX Dot11AVOptionsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11AVOptionsTable. For all AV Streaming features, an
Activated MIB variable is used to activate/enable or deactivate/disable
the corresponding feature. An Implemented MIB variable is used for an
optional feature to indicate whether the feature is implemented. A
mandatory feature does not have a corresponding Implemented MIB variable.
It is possible for there to be multiple IEEE 802.11 interfaces on one
agent, each with its unique MAC address. The relationship between an IEEE
802.11 interface and an interface in the context of the Internet-standard
MIB is one-to-one. As such, the value of an ifIndex object instance can be
directly used to identify corresponding instances of the objects defined
herein.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11AVOptionsTable 1 }
Dot11AVOptionsEntry ::=
SEQUENCE {
dot11GCRActivated TruthValue,
dot11AdvancedGCRImplemented TruthValue,
dot11AdvancedGCRActivated TruthValue,
dot11SCSImplemented TruthValue,
3064
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11SCSActivated TruthValue,
dot11QLoadReportActivated TruthValue,
dot11AlternateEDCAActivated TruthValue,
dot11GCRGroupMembershipAnnouncementActivated TruthValue,
dot11PublicHCCATXOPNegotiationImplemented TruthValue,
dot11PublicHCCATXOPNegotiationActivated TruthValue,
dot11ProtectedHCCATXOPNegotiationImplemented TruthValue,
dot11ProtectedHCCATXOPNegotiationActivated TruthValue,
dot11ProtectedQLoadReportImplemented TruthValue,
dot11ProtectedQLoadReportActivated TruthValue,
dot11MeshGCRImplemented TruthValue,
dot11MeshGCRActivated TruthValue }
dot11GCRActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive
or MLME-JOIN.request primitive.
This attribute, when true, indicates that the station
implementation supports the GCR procedures as defined in 11.24.16.3 and
that this has been activated."
DEFVAL { false }
::= { dot11AVOptionsEntry 1 }
dot11AdvancedGCRImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation
supports the Advanced GCR features."
DEFVAL { false }
::= { dot11AVOptionsEntry 2 }
dot11AdvancedGCRActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive
or MLME-JOIN.request primitive.
This attribute, when true, indicates that the station implementation
supports the GCR procedures as defined in 11.24.16.3 and that this has
been activated."
DEFVAL { false }
::= { dot11AVOptionsEntry 3 }
dot11SCSImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
3065
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation
supports the stream classification service."
DEFVAL { false }
::= { dot11AVOptionsEntry 4 }
dot11SCSActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive
or MLME-JOIN.request primitive.
This attribute, when true, indicates that the station implementation
supports the stream classification service and that this has been
activated."
DEFVAL { false }
::= { dot11AVOptionsEntry 5 }
dot11QLoadReportActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute, when true, indicates that the AP performs the QLoad report
procedures described in 11.28.2."
DEFVAL { false }
::= { dot11AVOptionsEntry 6 }
dot11AlternateEDCAActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute, when true, indicates that the station can additionally use
the Alternate EDCA transmit queues."
DEFVAL { false }
::= { dot11AVOptionsEntry 7 }
dot11GCRGroupMembershipAnnouncementActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the STA sends unsolicited Group
Membership Response frames when its dot11GroupAddressesTable changes."
DEFVAL { false }
3066
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11AVOptionsEntry 8 }
dot11PublicHCCATXOPNegotiationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation
supports the negotiation of HCCA TXOPs using Public Action frames."
DEFVAL { true }
::= { dot11AVOptionsEntry 9 }
dot11PublicHCCATXOPNegotiationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute, when true, indicates that the AP can negotiate HCCA TXOPs
using Public Action frames."
DEFVAL { true }
::= { dot11AVOptionsEntry 10 }
dot11ProtectedHCCATXOPNegotiationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation
supports the negotiation of HCCA TXOPs using protected dual of Public
Action frames."
DEFVAL { true }
::= { dot11AVOptionsEntry 11 }
dot11ProtectedHCCATXOPNegotiationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute, when true, indicates that the AP can negotiate HCCA TXOPs
using protected dual of Public Action frames."
DEFVAL { true }
::= { dot11AVOptionsEntry 12 }
dot11ProtectedQLoadReportImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3067
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute, when true, indicates that the station implementation
supports the reporting of QLoad using protected dual of Public Action
frames."
DEFVAL { true }
::= { dot11AVOptionsEntry 13 }
dot11ProtectedQLoadReportActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute, when true, indicates that the AP can report QLoad using
protected dual of Public Action frames."
DEFVAL { true }
::= { dot11AVOptionsEntry 14 }
dot11MeshGCRImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the mesh station implementation
supports the Advanced GCR features."
DEFVAL { false }
::= { dot11AVOptionsEntry 15 }
dot11MeshGCRActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive or MLME-
JOIN.request primitive.
This attribute, when true, indicates that the mesh station implementation
supports the GCR procedures as defined in 11.24.16.3 and that this has
been activated."
DEFVAL { false }
::= { dot11AVOptionsEntry 16 }
-- **********************************************************************
-- * End of dot11AVOptions TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11AVConfig TABLE
-- **********************************************************************
dot11AVConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11AVConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"AV streaming attributes. In tabular form to allow for multiple instances
3068
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
on an agent. This table only applies to the interface if
dot11RobustAVStreamingImplemented is true in the dot11StationConfigTable.
Otherwise this table should be ignored."
::= { dot11smt 29 }
dot11AVConfigEntry OBJECT-TYPE
SYNTAX Dot11AVConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11AVConfigTable. It is possible for there to be
multiple IEEE 802.11 interfaces on one agent, each with its unique MAC
address. The relationship between an IEEE 802.11 interface and an
interface in the context of the Internet-standard MIB is one-to-one. As
such, the value of an ifIndex object instance can be directly used to
identify corresponding instances of the objects defined herein.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11AVConfigTable 1 }
Dot11AVConfigEntry ::=
SEQUENCE {
dot11GCRPolicyChangeTimeout Unsigned32,
dot11QLoadReportIntervalDTIM Unsigned32,
dot11HCCATXOPBeaconTimeout Unsigned32,
dot11GCRConcealmentAddress MacAddress,
dot11QLoadReportDelay Unsigned32,
dot11ShortDEIRetryLimit Unsigned32,
dot11LongDEIRetryLimit Unsigned32,
dot11UnsolicitedRetryLimit Unsigned32,
dot11DefaultSurplusBandwidthAllowance Unsigned32 }
dot11GCRPolicyChangeTimeout OBJECT-TYPE
SYNTAX Unsigned32(5..18000)
UNITS "100 TUs"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
Changes take effect for the next MLME-START.request primitive or
MLME-JOIN.request primitive.
This attribute indicates the interval after which a STA updates its
GCR delivery mode or retransmission policy state using the procedures
defined in 11.24.16.3.4."
DEFVAL { 100 }
::= { dot11AVConfigEntry 1 }
dot11QLoadReportIntervalDTIM OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect at the next MLMESTART.request primitive.
This attribute describes the number of DTIM intervals between
transmissions of Beacon frames containing a Qload Report element."
::= { dot11AVConfigEntry 2 }
3069
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11HCCATXOPBeaconTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the MAC or external management entity.
Changes take effect for the next MLME-START.request primitive.
This attribute specifies the number of beacon periods an AP defers
scheduling new potentially conflicting HCCA TXOPs while performing the
HCCA TXOP procedures defined in 11.28.3."
DEFVAL { 3 }
::= { dot11AVConfigEntry 3 }
dot11GCRConcealmentAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or external management entity.
In a non-AP STA or mesh STA receiving GCR service, it is written by the
MAC when it receives a DMS Response frame that contains a DMS Status field
with a GCR Response subelement and a Response Type subfield set to Accept.
In an AP or mesh STA providing GCR service, changes take effect for the
next MLME-START.request primitive.
In a non-AP STA or mesh STA receiving GCR service, changes take effect as
soon as practical in the implementation.
The purpose of dot11GCRConcealmentAddress is to define the group address
that is used by the GCR procedures (as defined in 11.24.16.3.5) to conceal
group addressed frames from STAs that do not support GCR."
DEFVAL {'010FAC474352'H}
::= { dot11AVConfigEntry 4 }
dot11QLoadReportDelay OBJECT-TYPE
SYNTAX Unsigned32 (1..60)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect at the next MLMESTART.request primitive.
This attribute describes the maximum number of seconds an AP delays
sending an unsolicited QLoad Report action frame."
DEFVAL { 10 }
::= { dot11AVConfigEntry 5 }
dot11ShortDEIRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
For frames where the DEI subfield has the value of one and length less
than or equal to dot11RTSThreshold, this attribute indicates the maximum
number of transmission attempts that are made before a failure condition
is indicated. The default value of this attribute is 5."
DEFVAL { 5 }
3070
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11AVConfigEntry 6 }
dot11LongDEIRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
For frames where the DEI subfield has the value of one and length greater
than dot11RTSThreshold, this attribute indicates the maximum number of
transmission attempts that are made before a failure condition is
indicated. The default value of this attribute is 3."
DEFVAL { 3 }
::= { dot11AVConfigEntry 7 }
dot11UnsolicitedRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum number of transmission attempts of a
frame delivered using the GCR unsolicited retry retransmission policy."
DEFVAL { 7 }
::= { dot11AVConfigEntry 8 }
dot11DefaultSurplusBandwidthAllowance OBJECT-TYPE
SYNTAX Unsigned32 (100..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This object specifies the default percentage surplus bandwidth allowance
when calculating medium time.
"
DEFVAL { 110 }
::= { dot11AVConfigEntry 9 }
-- ********************************************************************
-- * End of dot11AVConfig TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11APC TABLE
-- ********************************************************************
dot11APCTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11APCEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains conceptual table of attributes for MIB-based HCCA TXOP
negotiation."
::= { dot11smt 30 }
3071
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11APCTableEntry OBJECT-TYPE
SYNTAX Dot11APCEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11APCTable, Indexed by dot11APCIndex."
INDEX { dot11APCIndex }
::= { dot11APCTable 1 }
Dot11APCEntry ::=
SEQUENCE {
dot11APCIndex Unsigned32,
dot11APCEntryAvoidanceDuration Unsigned32,
dot11APCEntryAvoidanceServiceInterval Unsigned32,
dot11APCEntryAvoidanceOffset Unsigned32,
dot11APCEntryMACAddress MacAddress }
dot11APCIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the HCCA TXOP Table."
::= { dot11APCTableEntry 1 }
dot11APCEntryAvoidanceDuration OBJECT-TYPE
SYNTAX Unsigned32 (0..131071)
UNITS "32 microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the duration of a TXOP reservation that the AP
attempts to avoid when scheduling new HCCA TXOPs."
::= { dot11APCTableEntry 2 }
dot11APCEntryAvoidanceServiceInterval OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "ms"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the duration of the period between successive HCCA
TXOPs. When zero, no period has been reserved."
::= { dot11APCTableEntry 3 }
dot11APCEntryAvoidanceOffset OBJECT-TYPE
SYNTAX Unsigned32 (0..131071)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
3072
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute contains the offset from the scheduled start of the Beacon
transmission until the start of the time period for a TXOP reservation
that the AP attempts to avoid when scheduling new HCCA TXOPs."
::= { dot11APCTableEntry 4 }
dot11APCEntryMACAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the MAC address of the peer AP that has scheduled
an HCCA TXOP in the time period defined by dot11APCEntryAvoidanceDuration,
dot11APCEntryAvoidanceServiceInterval, and dot11APCEntryAvoidanceOffset."
::= { dot11APCTableEntry 5 }
-- ********************************************************************
-- * End of dot11APC TABLE
-- ********************************************************************
-- *********************************************************************
-- * dot11VHTStationConfig TABLE
-- **********************************************************************
dot11VHTStationConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11VHTStationConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Station Configuration attributes. In tabular form to allow for multiple
instances on an agent."
::= { dot11smt 31 }
dot11VHTStationConfigEntry OBJECT-TYPE
SYNTAX Dot11VHTStationConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the dot11VHTStationConfig Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11VHTStationConfigTable 1 }
Dot11VHTStationConfigEntry ::=
SEQUENCE {
dot11MaxMPDULength INTEGER,
dot11VHTMaxRxAMPDUFactor Unsigned32,
dot11VHTControlFieldOptionImplemented TruthValue,
dot11VHTTXOPPowerSaveOptionImplemented TruthValue,
dot11VHTRxVHTMCSMap OCTET STRING,
dot11VHTRxHighestDataRateSupported Unsigned32,
dot11VHTTxVHTMCSMap OCTET STRING,
dot11VHTTxHighestDataRateSupported Unsigned32,
dot11VHTOBSSScanCount Unsigned32
}
dot11MaxMPDULength OBJECT-TYPE
SYNTAX INTEGER { short(3895), medium(7991), long(11454) }
UNITS "octets"
MAX-ACCESS read-only
3073
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum supported size of an MPDU received in
a VHT PPDU."
::= { dot11VHTStationConfigEntry 1 }
dot11VHTMaxRxAMPDUFactor OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum length of A-MPDU that the STA can
receive. The Maximum Rx A-MPDU defined by this field is equal to
2^(13+dot11VHTMaxRxAMPDUFactor) -1 octets."
DEFVAL { 0 }
::= { dot11VHTStationConfigEntry 2 }
dot11VHTControlFieldOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of receiving the VHT variant HT Control field."
DEFVAL { false }
::= { dot11VHTStationConfigEntry 3 }
dot11VHTTXOPPowerSaveOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of VHT TXOP power save operation."
DEFVAL { false }
::= { dot11VHTStationConfigEntry 4 }
dot11VHTRxVHTMCSMap OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Each octet represents the highest VHT-MCS supported (for Rx) on the number
of streams represented by the octet position (first octet represents 1
stream, second octet represents 2 streams, etc.) A value 0 indicates that
VHT-MCSs 0-7 are supported. A value 1 indicates that VHT-MCSs 0-8 are
supported. A value 2 indicates that VHT-MCSs 0-9 are supported. A value 3
indicates no support for that number of spatial streams."
::= { dot11VHTStationConfigEntry 5 }
3074
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11VHTRxHighestDataRateSupported OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Mb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Represents the highest data rate that the STA is capable of receiving."
::= { dot11VHTStationConfigEntry 6 }
dot11VHTTxVHTMCSMap OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Each octet represents the highest VHT-MCS supported (for Tx) on the number
of streams represented by the octet position (first octet represents 1
stream, second octet represents 2 streams, etc.). A value 0 indicates that
VHT-MCSs 0-7 are supported. A value 1 indicates that VHT-MCSs 0-8 are
supported. A value 2 indicates that VHT-MCSs 0-9 are supported. A value 3
indicates no support for that number of spatial streams."
::= { dot11VHTStationConfigEntry 7 }
dot11VHTTxHighestDataRateSupported OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Mb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Represents the highest data rate that the STA is capable of transmitting."
DEFVAL { 0 }
::= { dot11VHTStationConfigEntry 8 }
dot11VHTOBSSScanCount OBJECT-TYPE
SYNTAX Unsigned32 (3..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum number of scan operations performed
on a channel to detect another OBSS."
DEFVAL { 3 }
::= { dot11VHTStationConfigEntry 9 }
-- ********************************************************************
-- * End of dot11VHTStationConfigTable TABLE
-- ********************************************************************
-- *********************************************************************
-- * dot11TVHTStationConfig TABLE
-- **********************************************************************
dot11TVHTStationConfigTable OBJECT-TYPE
3075
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX SEQUENCE OF Dot11TVHTStationConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Station Configuration attributes. In tabular form to allow for multiple
instances on an agent."
::= { dot11smt 32 }
dot11TVHTStationConfigEntry OBJECT-TYPE
SYNTAX Dot11TVHTStationConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the dot11HTStationConfig Table. ifIndex -
Each IEEE 802.11 interface is represented by an ifEntry. Interface tables
in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11TVHTStationConfigTable 1 }
Dot11TVHTStationConfigEntry ::=
SEQUENCE {
dot11TVHTMaxMPDULength INTEGER,
dot11TVHTMaxRxAMPDUFactor Unsigned32,
dot11TVHTControlFieldOptionImplemented TruthValue,
dot11TVHTTXOPPowerSaveOptionImplemented TruthValue,
dot11TVHTRxVHTMCSMap OCTET STRING,
dot11TVHTRxHighestDataRateSupported Unsigned32,
dot11TVHTTxVHTMCSMap OCTET STRING,
dot11TVHTTxHighestDataRateSupported Unsigned32,
dot11TVHTOBSSScanCount Unsigned32
}
dot11TVHTMaxMPDULength OBJECT-TYPE
SYNTAX INTEGER { short(3895), medium(7991), long(11454) }
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum supported size of an MPDU received in
a TVHT PPDU."
::= { dot11TVHTStationConfigEntry 1 }
dot11TVHTMaxRxAMPDUFactor OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum length of A-MPDU that the STA can
receive. The Maximum Rx A-MPDU defined by this field is equal to
2^(13+dot11TVHTMaxRxAMPDUFactor)-1 octets."
DEFVAL { 0 }
::= { dot11TVHTStationConfigEntry 2 }
dot11TVHTControlFieldOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3076
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute, when true, indicates that the STA implementation is
capable of receiving the VHT variant HT Control field."
DEFVAL { false }
::= { dot11TVHTStationConfigEntry 3 }
dot11TVHTTXOPPowerSaveOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA
implementation is capable of VHT TXOP power save operation."
DEFVAL { false }
::= { dot11TVHTStationConfigEntry 4 }
dot11TVHTRxVHTMCSMap OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Each octet represents the highest VHT-MCS supported (for Rx) on the number
of streams represented by the octet position (first octet represents
1stream, second octet represents 2 streams, etc.). A value 0 indicates
that VHT-MCSs 0-7 are supported. A value 1 indicates that VHT-MCSs 0-8 are
supported. A value 2 indicates that VHT-MCSs 0-9 are supported. A value
3 indicates no support for that number of spatial streams."
::= { dot11TVHTStationConfigEntry 5 }
dot11TVHTRxHighestDataRateSupported OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Mb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Represents the highest data rate that the STA is capable of receiving."
::= { dot11TVHTStationConfigEntry 6 }
dot11TVHTTxVHTMCSMap OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Each octet represents the highest VHT-MCS supported (for Tx) on the number
of streams represented by the octet position (first octet represents 1
stream, second octet represents 2 streams, etc.).
A value 0 indicates that VHT-MCSs 0-7 are supported. A value 1 indicates
that VHT-MCSs 0-8 are supported. A value 2 indicates that VHT-MCSs 0-9 are
supported. A value 3 indicates no support for that number of spatial
streams."
::= { dot11TVHTStationConfigEntry 7 }
dot11TVHTTxHighestDataRateSupported OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Mb/s"
MAX-ACCESS read-only
STATUS current
3077
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Represents the highest data rate that the STA is capable of transmitting."
DEFVAL { 0 }
::= { dot11TVHTStationConfigEntry 8 }
dot11TVHTOBSSScanCount OBJECT-TYPE
SYNTAX Unsigned32 (3..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum number of scan operations performed
on a channel to detect another OBSS."
DEFVAL { 3 }
::= { dot11TVHTStationConfigEntry 9 }
-- ********************************************************************
-- * End of dot11TVHTStationConfigTable TABLE
-- ********************************************************************
-- ********************************************************************
-- * dot11STALCI TABLE
-- ********************************************************************
dot11STALCITable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11STALCIEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table represents the geolocation of the STA as specified in
11.44.1."
::= { dot11smt 33 }
dot11STALCIEntry OBJECT-TYPE
SYNTAX Dot11STALCIEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"STA's location information in geospatial coordinates"
INDEX {dot11STALCIIndex }
::= { dot11STALCITable 1 }
Dot11STALCIEntry ::=
SEQUENCE {
dot11STALCIIndex Unsigned32,
dot11STALCILatitudeUncertainty Unsigned32,
dot11STALCILatitudeInteger Integer32,
dot11STALCILatitudeFraction Integer32,
dot11STALCILongitudeUncertainty Unsigned32,
dot11STALCILongitudeInteger Integer32,
dot11STALCILongitudeFraction Integer32,
dot11STALCIAltitudeType INTEGER,
dot11STALCIAltitudeUncertainty Unsigned32,
dot11STALCIAltitude Integer32,
dot11STALCIDatum INTEGER }
dot11STALCIIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
3078
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"Index for STA LCI elements in dot11STALCITable, greater than 0."
::= { dot11STALCIEntry 1 }
dot11STALCILatitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the
implementation.
Latitude uncertainty is 6 bits indicating the amount of uncertainty in
latitude value. A value of 0 is reserved to indicate that the uncertainty
is unknown; values greater than 34 are reserved. This field is derived
from IETF RFC 6225."
::= { dot11STALCIEntry 2 }
dot11STALCILatitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-359..359)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Latitude is a 2s complement 34 bit fixed point value consisting of 9 bits
of integer and 25 bits of fraction. This field contains the 9 bits of
integer portion of Latitude. This field is derived from IETF RFC 6225."
::= { dot11STALCIEntry 3 }
dot11STALCILatitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Latitude is a 2s complement 34 bit fixed point value consisting of 9 bits
of integer and 25 bits of fraction. This field contains the 25 bits of
fraction portion of Latitude. This field is derived from IETF RFC 6225."
::= { dot11STALCIEntry 4 }
dot11STALCILongitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude uncertainty is 6 bits indicating the amount of uncertainty in
longitude value. A value of 0 is reserved to indicate that the uncertainty
is unknown; values greater than 34 are reserved. This field is derived
from IETF RFC 6225."
::= { dot11STALCIEntry 5 }
dot11STALCILongitudeInteger OBJECT-TYPE
3079
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Integer32 (-359..359)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude is a 2s complement 34 bit fixed point value consisting of 9 bits
of integer and 25 bits of fraction. This field contains the 9 bits of
integer portion of Longitude. This field is derived from IETF RFC 6225."
::= { dot11STALCIEntry 6 }
dot11STALCILongitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude is a 2s complement 34 bit fixed point value consisting of 9 bits
of integer and 25 bits of fraction. This field contains the 25 bits of
fraction portion of Longitude. This field is derived from IETF RFC 6225."
::= { dot11STALCIEntry 7 }
dot11STALCIAltitudeType OBJECT-TYPE
SYNTAX INTEGER {
meters(1),
floors(2),
hagm (3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Altitude Type is four bits encoding the type of altitude.
Codes defined are:
meters in 2s complement fixed-point 22-bit integer part with 8-bit
fraction
floors: in 2s complement fixed-point 22-bit integer part with 8-bit
fraction
hagm: Height Above Ground in meters, in 2s complement fixed-point 22-bit
integer part with 8-bit fraction
This field is derived from IETF RFC 6225."
::= { dot11STALCIEntry 8 }
dot11STALCIAltitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the
implementation.
Altitude uncertainty is 6 bits indicating the amount of uncertainty in the
altitude value. A value of 0 is reserved to indicate that altitude
uncertainty is not known; values above 30 are also reserved. Altitude
uncertainty applies only to Altitude Type 1. This field is derived from
3080
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
IETF RFC 6225."
::= { dot11STALCIEntry 9 }
dot11STALCIAltitude OBJECT-TYPE
SYNTAX Integer32 (-536870912..536870911)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Altitude is a 30 bit value defined by the Altitude type field. The field
is encoded as a 2s complement fixed-point 22-bit integer part with 8-bit
fraction. This field is derived from IETF RFC 6225."
::= { dot11STALCIEntry 10 }
-- Reserved: 11. Was dot11STALCIAltitudeFraction.
dot11STALCIDatum OBJECT-TYPE
SYNTAX INTEGER { wgs84 (1), nad83navd88 (2), nad93mllwvd (3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Datum is an 8-bit value encoding the horizontal and vertical references
used for the coordinates given in this LCI. IETF RFC 6225 defines the
values of Datum. Type 1 is WGS-84, the coordinate system used by GPS. Type
2 is NAD83 with NAVD88 vertical reference. Type 3 is NAD83 with Mean Lower
Low Water vertical datum. All other types are reserved. This field is
derived from IETF RFC 6225."
::= { dot11STALCIEntry 12 }
-- **********************************************************************
-- * End of dot11STALCI TABLE
-- **********************************************************************
-- ********************************************************************
-- * dot11STALCIConfig Table
-- ********************************************************************
dot11STALCIConfig OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11STALCIConfiguration
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object represents the sequence of STA’s geospatial coordinates."
::= { dot11smt 36 }
dot11STALCIConfiguration OBJECT-TYPE
SYNTAX Dot11STALCIConfiguration
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object represents the geospatial coordinates
of the STA."
INDEX { ifIndex }
::= { dot11STALCIConfigTable 1 }
Dot11STALCIConfiguration ::=
3081
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SEQUENCE {
dot11STALCIConfigLatitudeUncertainty Unsigned32,
dot11STALCIConfigLatitudeInteger Integer32,
dot11STALCIConfigLatitudeFraction Integer32,
dot11STALCIConfigLongitudeUncertainty Unsigned32,
dot11STALCIConfigLongitudeInteger Integer32,
dot11STALCIConfigLongitudeFraction Integer32,
dot11STALCIConfigAltitudeType INTEGER,
dot11STALCIConfigAltitudeUncertainty Unsigned32,
dot11STALCIConfigAltitude Integer32,
dot11STALCIConfigDatum INTEGER }
dot11STALCIConfigLatitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Latitude uncertainty is 6 bits indicating the amount of
uncertainty in latitude value. A value of 0 is reserved to
indicate that the uncertainty is unknown; values greater than
34 are reserved. This field is derived from IETF RFC 6225."
::= { dot11STALCIConfiguration 1 }
dot11STALCIConfigLatitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-359..359)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Latitude is a 2s complement 34 bit fixed point value consisting
of 9 bits of integer and 25 bits of fraction. This field contains
the 9 bits of integer portion of Latitude. This field is derived
from IETFRFC 6225."
::= { dot11STALCIConfiguration 2 }
dot11STALCIConfigLatitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Latitude is a 2s complement 34 bit fixed point value consisting
of 9 bits of integer and 25 bits of fraction. This field contains
the 25 bits of fraction portion of Latitude. This field is
derived from IETFRFC 6225."
::= { dot11STALCIConfiguration 3 }
dot11STALCIConfigLongitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude uncertainty is 6 bits indicating the amount of
uncertainty in longitude value. A value of 0 is reserved to
3082
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
indicate that the uncertainty is unknown; values greater than 34
are reserved. This field is derived from IETFRFC 6225."
::= { dot11STALCIConfiguration 4 }
dot11STALCIConfigLongitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-359..359)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude is a 2s complement 34 bit fixed point value consisting
of 9 bits of integer and 25 bits of fraction. This field contains
the 9 bits of integer portion of Longitude. This field is derived
from IETFRFC 6225."
::= { dot11STALCIConfiguration 5 }
dot11STALCIConfigLongitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude is a 2s complement 34 bit fixed point value consisting
of 9 bits of integer and 25 bits of fraction. This field contains
the 25 bits of fraction portion of Longitude. This field is
derived from IETF RFC 6225."
::= { dot11STALCIConfiguration 6 }
dot11STALCIConfigAltitudeType OBJECT-TYPE
SYNTAX INTEGER {
meters(1),
floors(2),
hagm (3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Altitude Type is four bits encoding the type of altitude.
Codes defined are:
meters in 2s complement fixed-point 22-bit integer part with
8-bit fraction
floors: in 2s complement fixed-point 22-bit integer part with
8-bit fraction
hagm: Height Above Ground in meters, in 2s complement
fixed-point 22-bit integer part with 8-bit fraction
This field is derived from IETF RFC 6225."
::= { dot11STALCIConfiguration 7 }
dot11STALCIConfigAltitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Altitude uncertainty is 6 bits indicating the amount of
uncertainty in the altitude value. A value of 0 is reserved to
3083
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
indicate that altitude uncertainty is not known; values above 30
are also reserved. Altitude uncertainty applies only to Altitude
Type 1. This field is derived from IETF RFC 6225."
::= { dot11STALCIConfiguration 8 }
dot11STALCIConfigAltitude OBJECT-TYPE
SYNTAX Integer32 (-536870912..536870911)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Altitude is a 30 bit value defined by the Altitude type field.
The field is encoded as a 2s complement fixed-point 22-bit
integer part with 8-bit fraction. This field is derived from IETF
RFC 6225."
::= { dot11STALCIConfiguration 9 }
dot11STALCIConfigDatum OBJECT-TYPE
SYNTAX INTEGER { wgs84 (1), nad83navd88 (2), nad93mllwvd (3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Datum is an 8-bit value encoding the horizontal and vertical
References used for the coordinates given in this LCI.
IETF RFC 6225 defines the values of Datum.
Type 1 is WGS-84, the coordinate system used by GPS.
Type 2 is NAD83 with NAVD88 vertical reference.
Type 3 is NAD83 with Mean Lower Low Water vertical datum.
All other types are reserved.
This field is derived from IETF RFC 6225."
::= { dot11STALCIConfiguration 10 }
-- ********************************************************************
-- * End of dot11STALCIConfig
-- ********************************************************************
-- ********************************************************************
-- * dot11STACivicLocationConfig Table
-- ********************************************************************
dot11STACivicLocationConfig OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11STACivicLocationConfiguration
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object represents the sequence of STA’s civic location."
::= { dot11smt 37 }
dot11STACivicLocationConfiguration OBJECT-TYPE
SYNTAX Dot11STACivicLocationConfiguration
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object represents the civic location of the STA."
INDEX { ifIndex }
::= { dot11STACivicLocationConfigTable 1 }
Dot11STACivicLocationConfiguration ::=
SEQUENCE {
dot11STACivicLocationType INTEGER,
3084
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11STACivicLocation OCTET STRING
}
dot11STACivicLocationType OBJECT-TYPE
SYNTAX INTEGER (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Civic Location type is defined in 9.4.2.21.14."
::= { dot11STACivicLocationConfiguration 1 }
dot11STACivicLocation OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Civic Location is defined in 9.4.2.22.13."
::= { dot11STACivicLocationConfiguration 2 }
-- ********************************************************************
-- * End of dot11STACivicLocationConfig
-- ********************************************************************
-- **********************************************************************
-- * MAC Attribute Templates
-- **********************************************************************
-- **********************************************************************
-- * dot11Operation TABLE
-- **********************************************************************
dot11OperationTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11OperationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group contains MAC attributes pertaining to the operation of the MAC.
This has been implemented as a table in order to allow for multiple
instantiations on an agent."
::= { dot11mac 1 }
dot11OperationEntry OBJECT-TYPE
SYNTAX Dot11OperationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11OperationEntry Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11OperationTable 1 }
Dot11OperationEntry ::=
SEQUENCE {
dot11MACAddress MacAddress,
dot11RTSThreshold Unsigned32,
dot11ShortRetryLimit Unsigned32,
3085
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11LongRetryLimit Unsigned32,
dot11FragmentationThreshold Unsigned32,
dot11MaxTransmitMSDULifetime Unsigned32,
dot11MaxReceiveLifetime Unsigned32,
dot11ManufacturerID DisplayString,
dot11ProductID DisplayString,
dot11CAPLimit Unsigned32,
dot11HCCWmin Unsigned32,
dot11HCCWmax Unsigned32,
dot11HCCAIFSN Unsigned32,
dot11ADDBAResponseTimeout Unsigned32,
dot11ADDTSResponseTimeout Unsigned32,
dot11ChannelUtilizationBeaconIntervals Unsigned32,
dot11ScheduleTimeout Unsigned32,
dot11DLSResponseTimeout Unsigned32,
dot11QAPMissingAckRetryLimit Unsigned32,
dot11EDCAAveragingPeriod Unsigned32,
dot11HTProtection INTEGER,
dot11RIFSMode TruthValue,
dot11PSMPControlledAccess TruthValue,
dot11ServiceIntervalGranularity Unsigned32,
dot11DualCTSProtection TruthValue,
dot11LSIGTXOPFullProtectionActivated TruthValue,
dot11NonGFEntitiesPresent TruthValue,
dot11PCOActivated TruthValue,
dot11PCOFortyMaxDuration Unsigned32,
dot11PCOTwentyMaxDuration Unsigned32,
dot11PCOFortyMinDuration Unsigned32,
dot11PCOTwentyMinDuration Unsigned32,
dot11FortyMHzIntolerant TruthValue,
dot11BSSWidthTriggerScanInterval Unsigned32,
dot11BSSWidthChannelTransitionDelayFactor Unsigned32,
dot11OBSSScanPassiveDwell Unsigned32,
dot11OBSSScanActiveDwell Unsigned32,
dot11OBSSScanPassiveTotalPerChannel Unsigned32,
dot11OBSSScanActiveTotalPerChannel Unsigned32,
dot112040BSSCoexistenceManagementSupport TruthValue,
dot11OBSSScanActivityThreshold Unsigned32 }
dot11MACAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Unique MAC Address assigned to the STA."
::= { dot11OperationEntry 1 }
dot11RTSThreshold OBJECT-TYPE
SYNTAX Unsigned32 (0..65536)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the number of octets in a PSDU, below which an
RTS/CTS handshake is not performed, except as RTS/CTS is used as a cross
modulation protection mechanism as defined in 10.26. An RTS/CTS handshake
is performed at the beginning of any frame exchange sequence where the
PSDU is with the Type subfield equal to Data or Management, the PSDU has
3086
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
an individual address in the Address 1 field, and the length of the PSDU
is greater than this threshold. Setting this attribute to be larger than
the maximum PSDU size has the effect of turning off the RTS/CTS handshake
for frames of Data or Management type transmitted by this STA. Setting
this attribute to 0 has the effect of turning on the RTS/CTS handshake for
all frames of Data or Management type transmitted by this STA."
DEFVAL { 65536 }
::= { dot11OperationEntry 2 }
dot11ShortRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum number of transmission attempts of a
frame, in a PSDU of length that is less than or equal to
dot11RTSThreshold, that are made before a failure condition is indicated."
DEFVAL { 7 }
::= { dot11OperationEntry 3 }
dot11LongRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum number of transmission attempts of a
frame, in a PSDU of length that is greater than dot11RTSThreshold, that is
made before a failure condition is indicated."
DEFVAL { 4 }
::= { dot11OperationEntry 4 }
dot11FragmentationThreshold OBJECT-TYPE
SYNTAX Unsigned32 (256..65535)
UNITS "octets"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum size of an individually addressed
MPDU beyond which the corresponding MSDU or MMPDU is fragmented, except
when an MSDU is transmitted under an HT-immediate or HT-delayed block ack
agreement, or when an MSDU is carried in an A-MSDU, or when an MSDU or
MMPDU is carried in an A-MPDU that does not contain a VHT single MPDU.
Fields added to the MPDU by security encapsulation are not counted against
the limit specified by this attribute. An MSDU or MMPDU might be
fragmented even if it is smaller."
DEFVAL { 65535 }
::= { dot11OperationEntry 5 }
dot11MaxTransmitMSDULifetime OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "TUs"
MAX-ACCESS read-write
3087
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The MaxTransmitMSDULifetime is the elapsed time, after the initial
transmission of an MSDU, after which further attempts to transmit the MSDU
are terminated."
DEFVAL { 512 }
::= { dot11OperationEntry 6 }
dot11MaxReceiveLifetime OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The MaxReceiveLifetime is the elapsed time, after the initial reception of
a fragmented MMPDU or MSDU, after which further attempts to reassemble the
MMPDU or MSDU are terminated."
DEFVAL { 512 }
::= { dot11OperationEntry 7 }
dot11ManufacturerID OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..128))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The ManufacturerID includes, at a minimum, the name of the manufacturer.
It may include additional information at the manufacturer's discretion.
The default value of this attribute is null."
::= { dot11OperationEntry 8 }
dot11ProductID OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..128))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The ProductID includes, at a minimum, an identifier that is unique to the
manufacturer. It may include additional information at the manufacturer's
discretion. The default value of this attribute is null."
::= { dot11OperationEntry 9 }
dot11CAPLimit OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum number of TUs a Controlled access
3088
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
phase(CAP) can last."
::= { dot11OperationEntry 10 }
dot11HCCWmin OBJECT-TYPE
SYNTAX Unsigned32 -- (0..aCWmin)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of the minimum size of the window that
is used by the HC for generating a random number for the backoff. The
value of this attribute is such that it could always be expressed in the
form of 2**X - 1, where X is an integer."
DEFVAL { 0 }
::= { dot11OperationEntry 11 }
dot11HCCWmax OBJECT-TYPE
SYNTAX Unsigned32 -- (0..aCWmax)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of the maximum size of the window that
is used by the HC for generating a random number for the backoff. The
value of this attribute is such that it could always be expressed in the
form of 2**X - 1, where X is an integer."
DEFVAL { 0 }
::= { dot11OperationEntry 12 }
dot11HCCAIFSN OBJECT-TYPE
SYNTAX Unsigned32 (1..15)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of slots, after a SIFS, that the HC
senses the medium idle either before transmitting or executing a backoff."
DEFVAL { 1 }
::= { dot11OperationEntry 13 }
dot11ADDBAResponseTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "seconds"
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"Deprecated as no longer used by IEEE Std 802.11-2016
This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the timeout for an ADDBA Response frame that is a
response to an ADDBA Request frame."
DEFVAL { 1 }
::= { dot11OperationEntry 14 }
3089
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11ADDTSResponseTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"Deprecated as no longer used by IEEE Std 802.11-2016
This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum number of seconds an ADDTS request is
to be responded."
DEFVAL { 1 }
::= { dot11OperationEntry 15 }
dot11ChannelUtilizationBeaconIntervals OBJECT-TYPE
SYNTAX Unsigned32 (1..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the number of beacon intervals over which the
channel busy time should be averaged."
DEFVAL { 50 }
::= { dot11OperationEntry 16 }
dot11ScheduleTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..100)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the duration after which a STA could go into
power save mode."
DEFVAL { 10 }
::= { dot11OperationEntry 17 }
dot11DLSResponseTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum number of seconds a direct link
request is to be responded."
DEFVAL { 10 }
::= { dot11OperationEntry 18 }
dot11QAPMissingAckRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
3090
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the number of times the AP may retry a frame for
which it does not receive an Ack frame for a STA in power save mode after
receiving a PS-Poll frame and sending an individually addressed response
or after the AP does not receive an Ack frame to an individually addressed
MPDU sent with the EOSP subfield equal to 1."
::= { dot11OperationEntry 19 }
dot11EDCAAveragingPeriod OBJECT-TYPE
SYNTAX Unsigned32 (1..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the number of seconds over which the admitted_-
time and used_time are computed."
DEFVAL { 5 }
::= { dot11OperationEntry 20 }
dot11HTProtection OBJECT-TYPE
SYNTAX INTEGER {
htNoProtection (0),
htNonmemberProtection(1),
ht20MHzProtection(2),
htNonHTmixed(3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the level of protection that needs to be provided
to the transmissions in an IEEE 802.11 network with HT STAs."
DEFVAL { htNoProtection }
::= { dot11OperationEntry 21 }
dot11RIFSMode OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that use of RIFS is allowed in the
BSS."
DEFVAL { false }
::= { dot11OperationEntry 22 }
dot11PSMPControlledAccess OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
3091
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Changes take effect as soon as practical in the implementation.
This attribute, when true indicates that the AP accepts associations only
from STAs for which dot11PSMPOptionImplemented is true."
DEFVAL { false }
::= { dot11OperationEntry 23 }
dot11ServiceIntervalGranularity OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the SI granularity to be used for scheduled PSMP.
The value of the granularity is given by
(dot11ServiceIntervalGranularity+1)*5 ms."
DEFVAL { 0 }
::= { dot11OperationEntry 24 }
dot11DualCTSProtection OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true indicates that the AP uses dual CTS protection
to protect the non-STBC frame and STBC frame transmissions."
DEFVAL { false }
::= { dot11OperationEntry 25 }
dot11LSIGTXOPFullProtectionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the LSIG TXOP protection may be
used by STAs that have the attribute
dot11LsigTxopProtectionOptionImplemented equal to true."
DEFVAL { false }
::= { dot11OperationEntry 26 }
dot11NonGFEntitiesPresent OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME when it determines that the presence of
greenfield stations in the BSS has changed.
This attribute, when true, indicates that STA that are not HT-greenfield
Capable are present in the BSS."
DEFVAL { false }
::= { dot11OperationEntry 27 }
3092
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11PCOActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the PCO is activated."
DEFVAL { false }
::= { dot11OperationEntry 28 }
dot11PCOFortyMaxDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..200)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The attribute indicates the maximum duration of 40 MHz phase in TU under
PCO operation. The value of this attribute shall be equal to or larger
than dot11PCOFortyMinDuration."
DEFVAL { 30 }
::= { dot11OperationEntry 29 }
dot11PCOTwentyMaxDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..200)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The attribute indicates the maximum duration of 20 MHz phase in TU under
PCO operation. The value of this attribute shall be equal to or larger
than dot11PCOTwentyMinDuration."
DEFVAL { 30 }
::= { dot11OperationEntry 30 }
dot11PCOFortyMinDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..200)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The attribute indicates the minimum duration of 40 MHz phase in TU under
PCO operation."
DEFVAL { 20 }
::= { dot11OperationEntry 31 }
dot11PCOTwentyMinDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..200)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
3093
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The attribute indicates the minimum duration of 20 MHz phase in TU under
PCO operation."
DEFVAL { 20 }
::= { dot11OperationEntry 32 }
dot11FortyMHzIntolerant OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the STA requests that 40 MHz
mask PPDUs are not transmitted within range of the STA."
DEFVAL { false }
::= { dot11OperationEntry 33 }
dot11BSSWidthTriggerScanInterval OBJECT-TYPE
SYNTAX Unsigned32 (10..900)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum interval between scan operations to
be performed to detect BSS channel width trigger events."
DEFVAL { 300 }
::= { dot11OperationEntry 34 }
dot11BSSWidthChannelTransitionDelayFactor OBJECT-TYPE
SYNTAX Unsigned32 (5..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum ratio between the delay time in
performing a switch from 20 MHz BSS operation to 20/40 MHz BSS operation
and the maximum interval between OBSS scan operations."
DEFVAL { 5 }
::= { dot11OperationEntry 35 }
dot11OBSSScanPassiveDwell OBJECT-TYPE
SYNTAX Unsigned32 (5..1000)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum amount of time that the STA
continuously scans each channel when performing a passive OBSS scan
3094
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
operation."
DEFVAL { 20 }
::= { dot11OperationEntry 36 }
dot11OBSSScanActiveDwell OBJECT-TYPE
SYNTAX Unsigned32 (10..1000)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum amount of time that the STA
continuously scans each channel when performing an active OBSS scan
operation."
DEFVAL { 10 }
::= { dot11OperationEntry 37 }
dot11OBSSScanPassiveTotalPerChannel OBJECT-TYPE
SYNTAX Unsigned32 (200..10000)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum total amount of time that the STA
scans each channel when performing a passive OBSS scan operation."
DEFVAL { 200 }
::= { dot11OperationEntry 38 }
dot11OBSSScanActiveTotalPerChannel OBJECT-TYPE
SYNTAX Unsigned32 (20..10000)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the minimum total amount of time that the STA
scans each channel when performing an active OBSS scan operation."
DEFVAL { 20 }
::= { dot11OperationEntry 39 }
dot112040BSSCoexistenceManagementSupport OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the
transmission and reception of the 20/40 BSS Coexistence Management frame."
DEFVAL { false }
::= { dot11OperationEntry 40 }
dot11OBSSScanActivityThreshold OBJECT-TYPE
3095
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Unsigned32 (0..100)
UNITS "0.01%"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum total time that a STA may be active
on the medium during a period of dot11BSSWidthChannelTransitionDelayFactor
* dot11BSSWidthTriggerScanInterval seconds without being obligated to
perform OBSS Scan operations. The default value of this attribute is 25,
which equates to 0.25%."
DEFVAL { 25 }
::= { dot11OperationEntry 41}
-- **********************************************************************
-- * End of dot11Operation TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11Counters TABLE
-- **********************************************************************
dot11CountersTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11CountersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group containing attributes that are MAC counters. Implemented as a table
to allow for multiple instantiations on an agent."
::= { dot11mac 2 }
dot11CountersEntry OBJECT-TYPE
SYNTAX Dot11CountersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11CountersEntry Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11CountersTable 1 }
Dot11CountersEntry ::=
SEQUENCE {
dot11TransmittedFragmentCount Counter32,
dot11GroupTransmittedFrameCount Counter32,
dot11FailedCount Counter32,
dot11RetryCount Counter32,
dot11MultipleRetryCount Counter32,
dot11FrameDuplicateCount Counter32,
dot11RTSSuccessCount Counter32,
dot11RTSFailureCount Counter32,
dot11AckFailureCount Counter32,
dot11ReceivedFragmentCount Counter32,
dot11GroupReceivedFrameCount Counter32,
dot11FCSErrorCount Counter32,
dot11TransmittedFrameCount Counter32,
dot11WEPUndecryptableCount Counter32,
dot11QosDiscardedFragmentCount Counter32,
dot11AssociatedStationCount Counter32,
3096
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11QosCFPollsReceivedCount Counter32,
dot11QosCFPollsUnusedCount Counter32,
dot11QosCFPollsUnusableCount Counter32,
dot11QosCFPollsLostCount Counter32,
dot11TransmittedAMSDUCount Counter32,
dot11FailedAMSDUCount Counter32,
dot11RetryAMSDUCount Counter32,
dot11MultipleRetryAMSDUCount Counter32,
dot11TransmittedOctetsInAMSDUCount Counter64,
dot11AMSDUAckFailureCount Counter32,
dot11ReceivedAMSDUCount Counter32,
dot11ReceivedOctetsInAMSDUCount Counter64,
dot11TransmittedAMPDUCount Counter32,
dot11TransmittedMPDUsInAMPDUCount Counter32,
dot11TransmittedOctetsInAMPDUCount Counter64,
dot11AMPDUReceivedCount Counter32,
dot11MPDUInReceivedAMPDUCount Counter32,
dot11ReceivedOctetsInAMPDUCount Counter64,
dot11AMPDUDelimiterCRCErrorCount Counter32,
dot11ImplicitBARFailureCount Counter32,
dot11ExplicitBARFailureCount Counter32,
dot11ChannelWidthSwitchCount Counter32,
dot11TwentyMHzFrameTransmittedCount Counter32,
dot11FortyMHzFrameTransmittedCount Counter32,
dot11TwentyMHzFrameReceivedCount Counter32,
dot11FortyMHzFrameReceivedCount Counter32,
dot11PSMPUTTGrantDuration Counter32,
dot11PSMPUTTUsedDuration Counter32,
dot11GrantedRDGUsedCount Counter32,
dot11GrantedRDGUnusedCount Counter32,
dot11TransmittedFramesInGrantedRDGCount Counter32,
dot11TransmittedOctetsInGrantedRDGCount Counter64,
dot11BeamformingFrameCount Counter32,
dot11DualCTSSuccessCount Counter32,
dot11DualCTSFailureCount Counter32,
dot11STBCCTSSuccessCount Counter32,
dot11STBCCTSFailureCount Counter32,
dot11nonSTBCCTSSuccessCount Counter32,
dot11nonSTBCCTSFailureCount Counter32,
dot11RTSLSIGSuccessCount Counter32,
dot11RTSLSIGFailureCount Counter32,
dot11PBACErrors Counter32,
dot11DeniedAssociationCounterDueToBSSLoad Counter32,
dot11TransmittedMSDUOctetsCount Counter64,
dot11ReceivedMSDUOctetsCount Counter64
}
dot11TransmittedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a fragment is successfully transmitted.
This counter is incremented for an acknowledged MPDU with an individual
address in the Address 1 field or an MPDU with a group address in the
Address 1 field with the Type subfield equal to Data or Management."
::= { dot11CountersEntry 1 }
dot11GroupTransmittedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
3097
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a status variable.
It is written by the MAC when a group addressed frame is transmitted.
This counter is incremented only when the group bit is set in the
destination MAC address of a successfully transmitted MSDU. When operating
as a STA in an infrastructure BSS, where these frames are directed to the
AP, this implies having received an acknowledgment to all associated
MPDUs."
::= { dot11CountersEntry 2 }
dot11FailedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when an MSDU is not transmitted successfully due
to the number of transmit attempts exceeding either the
dot11ShortRetryLimit or dot11LongRetryLimit."
::= { dot11CountersEntry 3 }
dot11RetryCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when an MSDU is successfully transmitted after one
or more retransmissions."
::= { dot11CountersEntry 4 }
dot11MultipleRetryCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when an MSDU is successfully transmitted after
more than one retransmission."
::= { dot11CountersEntry 5 }
dot11FrameDuplicateCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when a frame is received that the Sequence Control
field indicates is a duplicate."
::= { dot11CountersEntry 6 }
dot11RTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
3098
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a status variable.
It is written by the MAC when a CTS frame is received in response to an
RTS.
This counter increments when a CTS frame is received in response to an
RTS."
::= { dot11CountersEntry 7 }
dot11RTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when a CTS frame is not received in response to an
RTS."
::= { dot11CountersEntry 8 }
dot11AckFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when an Ack frame is not received when expected."
::= { dot11CountersEntry 9 }
dot11ReceivedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a fragment is successfully received.
This counter is incremented for each successfully received MPDU with the
Type subfield equal to Data or Management."
::= { dot11CountersEntry 10 }
dot11GroupReceivedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a group addressed frame is received.
This counter increments when an MSDU is received with the group bit set in
the destination MAC address."
::= { dot11CountersEntry 11 }
dot11FCSErrorCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
3099
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This counter increments when an FCS error is detected in a received MPDU."
::= { dot11CountersEntry 12 }
dot11TransmittedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a frame is successfully transmitted.
This counter increments for each successfully transmitted MSDU."
::= { dot11CountersEntry 13 }
dot11WEPUndecryptableCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when a frame is received with the Protected Frame
subfield of the Frame Control field equal to 1 and the WEPOn value for the
key mapped to the transmitter's MAC address indicates that the frame
should not have been encrypted or that frame is discarded due to the
receiving STA not implementing the privacy option."
::= { dot11CountersEntry 14 }
dot11QosDiscardedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments for each QoS Data frame that has been discarded."
::= { dot11CountersEntry 15 }
dot11AssociatedStationCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a STA associates or disassociates.
This counter, only available at AP, increments when a station associates
or reassociates. This counter decrements when a station disassociates."
::= { dot11CountersEntry 16 }
dot11QosCFPollsReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a CF-Poll is received.
This counter increments for each QoS (+)CF-Poll that has been received."
::= { dot11CountersEntry 17 }
dot11QosCFPollsUnusedCount OBJECT-TYPE
3100
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a CF-Poll is unused.
This counter increments for each QoS (+)CF-Poll that has been received but
not used."
::= { dot11CountersEntry 18 }
dot11QosCFPollsUnusableCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments for each QoS (+)CF-Poll that has been received but
could not be used due to the TXOP size being smaller than the time that is
required for one frame exchange sequence."
::= { dot11CountersEntry 19 }
dot11QosCFPollsLostCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments for each QoS (+)CF-Poll that has been issued where
there was no response from the QoS STA."
::= { dot11CountersEntry 20 }
dot11TransmittedAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a transmitted A-MSDU is acknowledged.
This counter shall be incremented for an acknowledged A-MSDU frame with an
individual address in the Address 1 field or an A-MSDU frame with a group
address in the Address 1 field."
::= { dot11CountersEntry 21 }
dot11FailedAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter shall be incremented when an A-MSDU is not transmitted
successfully due to the number of transmit attempts exceeding either the
dot11ShortRetryLimit or dot11LongRetryLimit."
::= { dot11CountersEntry 22 }
dot11RetryAMSDUCount OBJECT-TYPE
SYNTAX Counter32
3101
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a transmitted A-MSDU is acknowledged only
after one or more retransmissions.
This counter shall be incremented when an A-MSDU is successfully
transmitted after one or more retransmissions."
::= { dot11CountersEntry 23 }
dot11MultipleRetryAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a transmitted A-MSDU is acknowledged only
after more than one retransmission.
This counter shall be incremented when an A-MSDU is successfully
transmitted after more than one retransmission."
::= { dot11CountersEntry 24 }
dot11TransmittedOctetsInAMSDUCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MSDU is transmitted.
This counter shall be incremented by the number of octets in the frame
body of an A-MSDU frame when an A-MSDU frame is successfully transmitted."
::= { dot11CountersEntry 25 }
dot11AMSDUAckFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter shall be incremented when an acknowledgment to an A-MSDU is
not received when expected. This acknowledgment can be in an Ack or Block-
Ack frame."
::= { dot11CountersEntry 26 }
dot11ReceivedAMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MSDU is received.
This counter shall be incremented for a received A-MSDU frame with the
station's MAC address in the Address 1 field or an A-MSDU frame with a
group address in the Address 1 field."
::= { dot11CountersEntry 27 }
dot11ReceivedOctetsInAMSDUCount OBJECT-TYPE
SYNTAX Counter64
3102
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MSDU is received.
This counter shall be incremented by the number of octets in the frame
body of an A-MSDU frame when an A-MSDU frame is received."
::= { dot11CountersEntry 28 }
dot11TransmittedAMPDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MPDU is transmitted.
This counter shall be incremented when an A-MPDU is transmitted."
::= { dot11CountersEntry 29 }
dot11TransmittedMPDUsInAMPDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MPDU is transmitted.
This counter shall increment by the number of MPDUs in the A-MPDU when an
A-MPDU is transmitted."
::= { dot11CountersEntry 30 }
dot11TransmittedOctetsInAMPDUCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MPDU is transmitted.
This counter shall be incremented by the number of octets in the A-MPDU
frame when an A-MPDU frame is transmitted."
::= { dot11CountersEntry 31 }
dot11AMPDUReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MPDU is received.
This counter shall be incremented when the MAC receives an A-MPDU from the
PHY."
::= { dot11CountersEntry 32 }
dot11MPDUInReceivedAMPDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MPDU is received.
3103
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This counter shall be incremented by the number of MPDUs received in the
A-MPDU when an A-MPDU is received."
::= { dot11CountersEntry 33 }
dot11ReceivedOctetsInAMPDUCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an A-MPDU is received.
This counter shall be incremented by the number of octets in the A-MPDU
frame when an A-MPDU frame is received."
::= { dot11CountersEntry 34 }
dot11AMPDUDelimiterCRCErrorCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter shall be incremented when an MPDU delimiter has a CRC error
when this is the first CRC error in the received A-MPDU or when the
previous delimiter has been decoded correctly."
::= { dot11CountersEntry 35 }
dot11ImplicitBARFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter shall be incremented when the expected BlockAck frame is not
received in response to an Implicit BlockAckReq frame."
::= { dot11CountersEntry 36 }
dot11ExplicitBARFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter shall be incremented when the expected BlockAck frame is not
received in response to an Explicit BlockAckReq frame."
::= { dot11CountersEntry 37 }
dot11ChannelWidthSwitchCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the bandwidth is switched.
This counter shall be increment when the bandwidth used is switched from
20 to 40 or vice-versa."
3104
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11CountersEntry 38 }
dot11TwentyMHzFrameTransmittedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a frame is transmitted only on the primary
channel.
This counter shall be incremented when a frame is transmitted only on the
primary channel."
::= { dot11CountersEntry 39 }
dot11FortyMHzFrameTransmittedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a frame is transmitted on both control and
secondary channels.
This counter shall be incremented when a frame is transmitted on both
control and secondary channels."
::= { dot11CountersEntry 40 }
dot11TwentyMHzFrameReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a frame is received only on the primary
channel.
This counter shall be incremented when a frame is received only on the
primary channel."
::= { dot11CountersEntry 41 }
dot11FortyMHzFrameReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a frame is received on both the control and
secondary channels.
This counter shall be incremented when a frame is received on both the
control and secondary channels."
::= { dot11CountersEntry 42 }
dot11PSMPUTTGrantDuration OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a PSMP-UTT is granted.
This counter contains the cumulative duration of PSMP-UTT granted to the
STA, in units of 4 microseconds."
3105
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11CountersEntry 43 }
dot11PSMPUTTUsedDuration OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a PSMP-UTT is used.
This counter contains the cumulative duration of transmission by the STA
during its allocated PSMP-UTT, in units of 4 microseconds"
::= { dot11CountersEntry 44 }
dot11GrantedRDGUsedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an RDG is used.
This counter at the RD initiator shall be incremented when an allocated
RDG is used by the station, apart from transmitting a response frame such
as Ack or BlockAck frames."
::= { dot11CountersEntry 45 }
dot11GrantedRDGUnusedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an RDG is not used.
This counter at the initiator shall be incremented when an allocated RDG
is not used by the station, apart from transmitting a response frame such
as Ack or BlockAck frames."
::= { dot11CountersEntry 46 }
dot11TransmittedFramesInGrantedRDGCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an RDG is used.
This counter at the initiator shall be incremented for every frame, other
than response frames such as Ack or BlockAck frames, transmitted by the
station during a granted RDG."
::= { dot11CountersEntry 47 }
dot11TransmittedOctetsInGrantedRDGCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an RDG is used.
This counter at the initiator shall be incremented by the number of octets
in the frame body of a frame, other than response frames such as Ack or
BlockAck frames, transmitted by the station during a granted RDG."
3106
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11CountersEntry 48 }
dot11BeamformingFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a frame with beamforming parameters is sent.
This counter shall be incremented when the transmitter sends a frame with
new/updated beamforming parameters."
::= { dot11CountersEntry 49 }
dot11DualCTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a dual CTS is sent.
This counter shall be incremented when AP sends a dual CTS in response to
a STA initiating TXOP in extended range."
::= { dot11CountersEntry 50 }
dot11DualCTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a dual CTS is not sent.
This counter shall be incremented when AP fails to send a dual CTS in
response to a STA initiating TXOP in extended range."
::= { dot11CountersEntry 51 }
dot11STBCCTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when no collision is detected.
This counter shall be incremented when AP does not detect a collision PIFS
after sending a CTS to self STBC frame in extended range."
::= { dot11CountersEntry 52 }
dot11STBCCTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a collision is detected.
This counter shall be incremented when AP detects a collision PIFS after
sending a CTS to self STBC frame in extended range."
::= { dot11CountersEntry 53 }
dot11nonSTBCCTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
3107
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when no collision is detected.
This counter shall be incremented when AP does not detect a collision PIFS
after sending a CTS to self that is an non-STBC frame in extended range."
::= { dot11CountersEntry 54 }
dot11nonSTBCCTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a collision is detected.
This counter shall be incremented when AP detects a collision PIFS after
sending a CTS to self that is an non-STBC frame in extended range."
::= { dot11CountersEntry 55 }
dot11RTSLSIGSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter shall be incremented when the duration/ID field is set
according to the rules of L-SIG TXOP protection in the received CTS
following a transmission of RTS in L-SIG TXOP protection mode."
::= { dot11CountersEntry 56 }
dot11RTSLSIGFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter shall be incremented when the duration/ID field is not set
according to the rules of L-SIG TXOP protection in the received CTS
following a transmission of RTS in L-SIG TXOP protection mode."
::= { dot11CountersEntry 57 }
dot11PBACErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This variable indicates the number of errors encountered in the PBAC
procedures."
::= { dot11CountersEntry 58}
dot11DeniedAssociationCounterDueToBSSLoad OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
3108
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a status variable.
It is written by the SME when the condition described below occurs.
This counter, available at a WNM AP, shall increment when an
(re)association request is denied because the AP has insufficient
bandwidth to handle the additional STA."
::= { dot11CountersEntry 59}
dot11TransmittedMSDUOctetsCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an MSDU is successfully transmitted.
This counter is incremented by the number of octets in the MSDU when an
MSDU is successfully transmitted."
::= { dot11CountersEntry 60 }
dot11ReceivedMSDUOctetsCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when an MSDU is received that is addressed to the
STA (either individually or globally).
This counter is incremented by the number of octets in the MSDU."
::= { dot11CountersEntry 61 }
-- **********************************************************************
-- * End of dot11Counters TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11GroupAddresses TABLE
-- **********************************************************************
dot11GroupAddressesTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11GroupAddressesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual table containing a set of MAC addresses identifying the
multicast-group addresses for which this STA receives frames. The default
value of this attribute is null."
::= { dot11mac 3 }
dot11GroupAddressesEntry OBJECT-TYPE
SYNTAX Dot11GroupAddressesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the Group Addresses Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11GroupAddressesIndex }
::= { dot11GroupAddressesTable 1 }
3109
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Dot11GroupAddressesEntry ::=
SEQUENCE {
dot11GroupAddressesIndex InterfaceIndex,
dot11GroupAddress MacAddress,
dot11GroupAddressesStatus RowStatus }
dot11GroupAddressesIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the Group Addresses Table."
::= { dot11GroupAddressesEntry 1 }
dot11GroupAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
MAC address identifying multicast-group addresses from which this STA
receives frames."
::= { dot11GroupAddressesEntry 2 }
dot11GroupAddressesStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status column used for creating, modifying, and deleting instances of
the columnar objects in the Group Addresses Table."
DEFVAL { active }
::= { dot11GroupAddressesEntry 3 }
-- **********************************************************************
-- * End of dot11GroupAddresses TABLE
-- **********************************************************************
-- **********************************************************************
-- * SMT EDCA Config TABLE
-- **********************************************************************
dot11EDCATable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11EDCAEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Conceptual table for EDCA default parameter values at a non-AP STA. This
table contains the four entries of the EDCA parameters corresponding to
four possible ACs. Index 1 corresponds to AC_BK, index 2 to AC_BE, index 3
to AC_VI, and index 4 to AC_VO."
REFERENCE
"IEEE Std 802.11-2012, 10.2.4.2"
::= { dot11mac 4 }
dot11EDCAEntry OBJECT-TYPE
SYNTAX Dot11EDCAEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
3110
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"An Entry (conceptual row) in the EDCA Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11EDCATableIndex }
::= { dot11EDCATable 1 }
Dot11EDCAEntry ::=
SEQUENCE {
dot11EDCATableIndex Unsigned32,
dot11EDCATableCWmin Unsigned32,
dot11EDCATableCWmax Unsigned32,
dot11EDCATableAIFSN Unsigned32,
dot11EDCATableTXOPLimit Unsigned32,
dot11EDCATableMSDULifetime Unsigned32,
dot11EDCATableMandatory TruthValue }
dot11EDCATableIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the EDCA Table. The value of this variable is
1, if the value of the AC is AC_BK.
2, if the value of the AC is AC_BE.
3, if the value of the AC is AC_VI.
4, if the value of the AC is AC_VO."
::= { dot11EDCAEntry 1 }
dot11EDCATableCWmin OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the MAC upon receiving an EDCA Parameter Set.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of the minimum size of the window that
is used by a STA for a particular AC for generating a random number for
the backoff. The value of this attribute is such that it could always be
expressed in the form of 2**X - 1, where X is an integer. See Table 9-137
and Table 9-138."
::= { dot11EDCAEntry 2 }
dot11EDCATableCWmax OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the MAC upon receiving an EDCA Parameter Set.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of the maximum size of the window that
is used by a STA for a particular AC for generating a random number for
the backoff. The value of this attribute is such that it could always be
expressed in the form of 2**X - 1, where X is an integer. See Table 9-137
and Table 9-138."
::= { dot11EDCAEntry 3 }
dot11EDCATableAIFSN OBJECT-TYPE
SYNTAX Unsigned32 (2..15)
3111
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the MAC upon receiving an EDCA Parameter Set element.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of slots, after a SIFS, that the STA,
for a particular AC, senses the medium idle either before transmitting or
executing a backoff. See Table 9-137 and Table 9-138."
::= { dot11EDCAEntry 4 }
dot11EDCATableTXOPLimit OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "32 microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MLME upon receiving an EDCA Parameter Set element.
This attribute specifies the maximum duration of an EDCA TXOP for a given
AC, for a non-AP non-OCB STA. The default value for this attribute is
given (in different units) in Table 9-137.
REFERENCE IEEE Std 802.11-2016, 9.4.2.29"
::= { dot11EDCAEntry 5 }
dot11EDCATableMSDULifetime OBJECT-TYPE
SYNTAX Unsigned32 (0..500)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the MAC upon receiving an EDCA Parameter Set in a Beacon
frame.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum duration an MSDU, for a given AC,
would be retained by the MAC before it is discarded."
DEFVAL { 500 }
::= { dot11EDCAEntry 6 }
dot11EDCATableMandatory OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the MAC upon receiving an EDCA Parameter Set in a Beacon
frame.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that admission control is mandatory
for the given AC. When false, this attribute indicates that admission
control is not mandatory for the given AC."
DEFVAL { false }
::= { dot11EDCAEntry 7 }
-- **********************************************************************
-- * End of SMT EDCA Config TABLE
-- **********************************************************************
-- **********************************************************************
3112
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- * SMT AP EDCA Config TABLE
-- **********************************************************************
dot11QAPEDCATable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11QAPEDCAEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Conceptual table for EDCA default parameter values at the AP. This table
contains the four entries of the EDCA parameters corresponding to four
possible ACs. Index 1 corresponds to AC_BK, index 2 to AC_BE, index 3 to
AC_VI, and index 4 to AC_VO."
REFERENCE
"IEEE Std 802.11-2012, 10.22.2"
::= { dot11mac 5 }
dot11QAPEDCAEntry OBJECT-TYPE
SYNTAX Dot11QAPEDCAEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the EDCA Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Inter-
face tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11QAPEDCATableIndex }
::= { dot11QAPEDCATable 1 }
Dot11QAPEDCAEntry ::=
SEQUENCE {
dot11QAPEDCATableIndex Unsigned32,
dot11QAPEDCATableCWmin Unsigned32,
dot11QAPEDCATableCWmax Unsigned32,
dot11QAPEDCATableAIFSN Unsigned32,
dot11QAPEDCATableTXOPLimit Unsigned32,
dot11QAPEDCATableMSDULifetime Unsigned32,
dot11QAPEDCATableMandatory TruthValue }
dot11QAPEDCATableIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the EDCA Table. The value of this variable is
1, if the value of the AC is AC_BK.
2, if the value of the AC is AC_BE.
3, if the value of the AC is AC_VI.
4, if the value of the AC is AC_VO."
::= { dot11QAPEDCAEntry 1 }
dot11QAPEDCATableCWmin OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of the minimum size of the window that
is used by an AP for a particular AC for generating a random number for
the backoff. The value of this attribute is such that it could always be
expressed in the form of 2**X - 1, where X is an integer. The default
3113
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
value for this attribute is
aCWmin, if dot11QAPEDCATableIndex is 1 or 2.
(aCWmin+1)/2 - 1, if dot11QAPEDCATableIndex is 3.
(aCWmin+1)/4 - 1, if dot11QAPEDCATableIndex is 4."
::= { dot11QAPEDCAEntry 2 }
dot11QAPEDCATableCWmax OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the value of the maximum size of the window that
is used by an AP for a particular AC for generating a random number for
the backoff. The value of this attribute is such that it could always be
expressed in the form of 2**X - 1, where X is an integer. The default
value for this attribute is
aCWmax, if dot11QAPEDCATableIndex is 1.
4*(aCWmin+1) - 1, if dot11QAPEDCATableIndex is 2.
aCWmin, if dot11QAPEDCATableIndex is 3.
(aCWmin+1)/2 - 1, if dot11QAPEDCATableIndex is 4."
::= { dot11QAPEDCAEntry 3 }
dot11QAPEDCATableAIFSN OBJECT-TYPE
SYNTAX Unsigned32 (1..15)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the number of slots, after a SIFS, that the AP,
for a particular AC, senses the medium idle either before transmitting or
executing a backoff. The default value for this attribute is
7, if dot11QAPEDCATableIndex is 1,
3, if dot11QAPEDCATableIndex is 2
1, otherwise."
::= { dot11QAPEDCAEntry 4 }
dot11QAPEDCATableTXOPLimit OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "32 microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum duration of an EDCA TXOP for a given
AC, for an AP. The default value for this attribute is given (in different
units) in Table 9-137.
REFERENCE IEEE Std 802.11-2016, 9.4.2.29"
::= { dot11QAPEDCAEntry 5 }
dot11QAPEDCATableMSDULifetime OBJECT-TYPE
SYNTAX Unsigned32 (0..500)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
3114
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum duration an MSDU, for a given AC,
would be retained by the MAC at the AP before it is discarded."
DEFVAL { 500 }
::= { dot11QAPEDCAEntry 6 }
dot11QAPEDCATableMandatory OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that admission control is mandatory
for the given AC. When false, this attribute indicates that admission
control is not mandatory for the given AC. The default value for this
parameter is false."
::= { dot11QAPEDCAEntry 7 }
-- **********************************************************************
-- * End of SMT AP EDCA Config TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11QosCounters TABLE
-- **********************************************************************
dot11QosCountersTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11QosCountersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group containing attributes that are MAC counters implemented as a table
to allow for multiple instantiations on an agent."
::= { dot11mac 6 }
dot11QosCountersEntry OBJECT-TYPE
SYNTAX Dot11QosCountersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the EDCA Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11QosCountersIndex }
::= { dot11QosCountersTable 1 }
Dot11QosCountersEntry ::=
SEQUENCE {
dot11QosCountersIndex Unsigned32,
dot11QosTransmittedFragmentCount Counter32,
dot11QosFailedCount Counter32,
dot11QosRetryCount Counter32,
dot11QosMultipleRetryCount Counter32,
dot11QosFrameDuplicateCount Counter32,
dot11QosRTSSuccessCount Counter32,
dot11QosRTSFailureCount Counter32,
3115
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11QosAckFailureCount Counter32,
dot11QosReceivedFragmentCount Counter32,
dot11QosTransmittedFrameCount Counter32,
dot11QosDiscardedFrameCount Counter32,
dot11QosMPDUsReceivedCount Counter32,
dot11QosRetriesReceivedCount Counter32 }
dot11QosCountersIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..16)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the QoSCounter Table. The value of this variable is equal to TID + 1."
::= { dot11QosCountersEntry 1 }
dot11QosTransmittedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a QoS fragment is transmitted.
This counter is incremented for an acknowledged MPDU, for a particular UP,
with an individual address in the Address 1 field or an MPDU with a group
address in the Address 1 field, either belonging to a particular TID. This
counter has relevance only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 2 }
dot11QosFailedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when an MSDU, for a particular UP, is not
transmitted successfully due to the number of transmit attempts exceeding
either the dot11ShortRetryLimit or dot11LongRetryLimit. This counter has
relevance only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 3 }
dot11QosRetryCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when an MSDU, of a particular UP, is successfully
transmitted after one or more retransmissions. This counter has relevance
only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 4 }
dot11QosMultipleRetryCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
3116
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This counter increments when an MSDU, of a particular UP, is successfully
transmitted after more than one retransmissions. This counter has
relevance only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 5 }
dot11QosFrameDuplicateCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when a frame, of a particular UP, is received that
the Sequence Control field indicates is a duplicate. This counter has
relevance only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 6 }
dot11QosRTSSuccessCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a CTS frame is received in response to an
RTS.
This counter increments when a CTS frame is received in response to an RTS
that has been sent for the transmission of an MPDU of a particular UP.
This counter has relevance only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 7 }
dot11QosRTSFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when a CTS frame is not received in response to an
RTS that has been sent for the transmission of an MPDU of a particular UP.
This counter has relevance only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 8 }
dot11QosAckFailureCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments when an Ack frame is not received in response to
an MPDU of a particular UP. This counter has relevance only for TIDs
between 0 and 7."
::= { dot11QosCountersEntry 9 }
dot11QosReceivedFragmentCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
3117
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the MAC when a QoS fragment is received.
This counter is incremented for each successfully received MPDU with the
Type subfield equal to Data of a particular UP. This counter has relevance
only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 10 }
dot11QosTransmittedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a QoS frame is transmitted.
This counter increments for each successfully transmitted MSDU of a
particular UP. This counter has relevance only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 11 }
dot11QosDiscardedFrameCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments for each Discarded MSDU of a particular UP. This
counter has relevance only for TIDs between 0 and 7."
::= { dot11QosCountersEntry 12 }
dot11QosMPDUsReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when a QoS MPDU is received.
This counter increments for each received MPDU of a particular TID."
::= { dot11QosCountersEntry 13 }
dot11QosRetriesReceivedCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MAC when the condition described below occurs.
This counter increments for each received MPDU of a particular TID with
the Retry subfield equal to 1."
::= { dot11QosCountersEntry 14 }
-- **********************************************************************
-- * End of dot11QosCounters TABLE
-- **********************************************************************
-- **********************************************************************
-- * Resource Type Attribute Templates
-- **********************************************************************
dot11ResourceTypeIDName OBJECT-TYPE
3118
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX DisplayString (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Contains the name of the Resource Type ID managed object. The attribute
is read-only and always contains the value RTID. This attribute value is
not used as a naming attribute for any other managed object class."
REFERENCE "IEEE Std 802.1F-1993, A.7"
DEFVAL { "RTID" }
::= { dot11resAttribute 1 }
-- **********************************************************************
-- * dot11ResourceInfo TABLE
-- **********************************************************************
dot11ResourceInfoTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11ResourceInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"provides a means of indicating, in data readable from a managed object,
information that identifies the source of the implementation."
REFERENCE "IEEE Std 802.1F-1993, A.7. Note that this standard has been
withdrawn."
::= { dot11resAttribute 2 }
dot11ResourceInfoEntry OBJECT-TYPE
SYNTAX Dot11ResourceInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11ResourceInfo Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11ResourceInfoTable 1 }
Dot11ResourceInfoEntry ::=
SEQUENCE {
dot11manufacturerOUI OCTET STRING,
dot11manufacturerName DisplayString,
dot11manufacturerProductName DisplayString,
dot11manufacturerProductVersion DisplayString }
dot11manufacturerOUI OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(3))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Takes the value of an IEEE assigned unique identifier (OUI or CID)."
::= { dot11ResourceInfoEntry 1 }
dot11manufacturerName OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..128))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3119
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
A printable string used to identify the manufacturer of the resource.
Maximum string length is 128 octets."
::= { dot11ResourceInfoEntry 2 }
dot11manufacturerProductName OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..128))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
A printable string used to identify the manufacturer's product name of the
resource. Maximum string length is 128 octets."
::= { dot11ResourceInfoEntry 3 }
dot11manufacturerProductVersion OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..128))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
Printable string used to identify the manufacturer's product version of
the resource. Maximum string length is 128 octets."
::= { dot11ResourceInfoEntry 4 }
-- **********************************************************************
-- * End of dot11ResourceInfo TABLE
-- **********************************************************************
-- *******************************************************************
-- * dot11DMGOperation TABLE
-- *******************************************************************
dot11DMGOperationTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11DMGOperationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a Table management object.
The dot11DMGOperation Table"
::= { dot11mac 8 }
dot11DMGOperationEntry OBJECT-TYPE
SYNTAX Dot11DMGOperationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an entry in the dot11DMGOperation Table.
ifIndex - Each IEEE 802.11 interface is represented by an
ifEntry. Interface tables in this MIB module are indexed
by ifIndex."
INDEX { ifIndex }
::= { dot11DMGOperationTable 1 }
Dot11DMGOperationEntry ::=
SEQUENCE {
dot11MaxLostBeacons Unsigned32,
dot11MinBHIDuration Unsigned32,
dot11PSRequestSuspensionInterval Unsigned32,
dot11BroadcastSTAInfoDuration Unsigned32,
dot11NbrOfChangeBeacons Unsigned32,
3120
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11ImplicitHandoverLostBeacons Unsigned32,
dot11MinPPDuration Unsigned32,
dot11SPIdleTimeout Unsigned32,
dot11QABTimeout Unsigned32,
dot11ClusterEnableTime Unsigned32,
dot11PNWarningThresholdLow Unsigned32,
dot11PNWarningThresholdHigh Unsigned32,
dot11BeaconSPDuration Unsigned32,
dot11PNExhaustionThresholdLow Unsigned32,
dot11PNExhaustionThresholdHigh Unsigned32,
dot11MaxNumberOfClusteringMonitoringPeriods Unsigned32,
dot11DMGEcssPolicyDetailUpdateDurationMax Unsigned32,
dot11DMGEcssClusterReportDurationMin Unsigned32,
dot11DMGNavSync Unsigned32
}
dot11MaxLostBeacons OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Maximum Number of Lost Beacons"
DEFVAL { 4 }
::= { dot11DMGOperationEntry 1 }
dot11MinBHIDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..100000)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Minimum Beacon Header Interval duration."
DEFVAL { 5000 }
::= { dot11DMGOperationEntry 2 }
dot11PSRequestSuspensionInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..64)
UNITS "beacon intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
PS Request Suspension Interval"
DEFVAL { 8 }
::= { dot11DMGOperationEntry 3 }
dot11BroadcastSTAInfoDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..512)
UNITS "beacon intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
3121
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Broadcast STA Information Duration."
DEFVAL { 32 }
::= { dot11DMGOperationEntry 5 }
dot11NbrOfChangeBeacons OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
UNITS "beacon intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Number of Change Beacons."
DEFVAL { 4 }
::= { dot11DMGOperationEntry 6 }
dot11ImplicitHandoverLostBeacons OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
UNITS "beacon intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Implicit handover lost beacons."
DEFVAL { 8 }
::= { dot11DMGOperationEntry 7 }
dot11MinPPDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..100000)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
The MinPPDuration subfield indicates the minimum duration of the
PP and GP as part of the dynamic allocation of service period
mechanism."
DEFVAL { 200 }
::= { dot11DMGOperationEntry 8 }
dot11SPIdleTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..100000)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
The SPIdleTimeout subfield indicates time during which a STA
expects to receive a frame from its partner STA."
3122
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { 200 }
::= { dot11DMGOperationEntry 9 }
dot11QABTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..64000)
UNITS "milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Quiet Adjacent BSS Operation Timeout."
DEFVAL { 1000 }
::= { dot11DMGOperationEntry 10 }
dot11ClusterEnableTime OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
UNITS "beacon intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Frequency with which a non-AP and non-PCP is allowed to retransmit a
cluster request element to its AP or PCP."
DEFVAL { 8 }
::= { dot11DMGOperationEntry 11 }
dot11PNWarningThresholdLow OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
UNITS "packet number"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Threshold used for generating a warning to the MLME about a potential PN
exhaustion.
Threshold is a 48 bit integer. This field contains the least significant
32 bits of the threshold."
DEFVAL { 4294967295 }
::= { dot11DMGOperationEntry 12 }
dot11PNWarningThresholdHigh OBJECT-TYPE
SYNTAX INTEGER (0..65535)
UNITS "packet number"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Threshold used for generating a warning to the MLME about a potential PN
exhaustion.
Threshold is a 48 bit integer. This field contains the most significant 16
bits of the threshold."
DEFVAL { 65535 }
3123
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11DMGOperationEntry 13 }
dot11BeaconSPDuration OBJECT-TYPE
SYNTAX Unsigned32 (1..100000)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
The size of a Beacon SP used for AP or PCP clustering."
DEFVAL { 600 }
::= { dot11DMGOperationEntry 14 }
dot11PNExhaustionThresholdLow OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
UNITS "packet number"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Threshold used for indicating an imminent PN exhaustion.
Threshold is a 48 bit integer. This field contains the least significant
32 bits of the threshold."
DEFVAL { 4294967295 }
::= { dot11DMGOperationEntry 15 }
dot11PNExhaustionThresholdHigh OBJECT-TYPE
SYNTAX INTEGER (0..65535)
UNITS "packet number"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Threshold used for indicating an imminent PN exhaustion.
Threshold is a 48 bit integer. This field contains the most significant 16
bits of the threshold."
DEFVAL { 65535 }
::= { dot11DMGOperationEntry 16 }
dot11MaxNumberOfClusteringMonitoringPeriods OBJECT-TYPE
SYNTAX Unsigned32 (1..16)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Number of clustering monitoring periods until determination of the loss of
an S-AP or S-PCP."
DEFVAL { 3 }
::= { dot11DMGOperationEntry 17 }
3124
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11DMGEcssPolicyDetailUpdateDurationMax OBJECT-TYPE
SYNTAX Unsigned32 (10..30000)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Maximum duration between attempts by a member AP or member PCP in a
centralized AP or PCP cluster to receive a DMG Beacon frame from the S-AP
of the centralized AP or PCP cluster"
DEFVAL { 1000 }
::= { dot11DMGOperationEntry 18 }
dot11DMGEcssClusterReportDurationMin OBJECT-TYPE
SYNTAX Unsigned32 (100..36000000)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Minimum duration between the transmission of interference reports by a
member AP or member PCP in a centralized AP or PCP cluster to the S-AP of
the centralized AP or PCP cluster"
DEFVAL { 1000 }
::= { dot11DMGOperationEntry 19 }
dot11DMGNavSync OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Delay to be used by a DMG STA prior to transmitting a Probe Request
frame."
DEFVAL { 0 }
::= { dot11DMGOperationEntry 20 }
-- *******************************************************************
-- * End of dot11DMGOperation TABLE
-- *******************************************************************
-- *******************************************************************
-- * dot11DMGCounters TABLE
-- *******************************************************************
dot11DMGCountersTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11DMGCountersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a Table management object.
The dot11DMGCountersTable Table"
::= { dot11mac 9 }
3125
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11DMGCountersEntry OBJECT-TYPE
SYNTAX Dot11DMGCountersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an entry in the dot11DMGCountersTable Table.
ifIndex - Each IEEE 802.11 interface is represented by an
ifEntry. Interface tables in this MIB module are indexed
by ifIndex."
INDEX { ifIndex }
::= { dot11DMGCountersTable 1 }
Dot11DMGCountersEntry ::=
SEQUENCE {
dot11RSNAStatsGCMPReplays Unsigned32,
dot11RSNAStatsRobustMgmtGCMPReplays Unsigned32
}
dot11RSNAStatsGCMPReplays OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME or an external management entity.
Counter for the number of times an MPDU with the Type subfield equal to
Data is discarded due to PN violation."
DEFVAL { 0 }
::= { dot11DMGCountersEntry 1 }
dot11RSNAStatsRobustMgmtGCMPReplays OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME or an external management entity.
Counter for the number of times a Management frame is
discarded due to PN violation."
DEFVAL { 0 }
::= { dot11DMGCountersEntry 2 }
-- *******************************************************************
-- * End of dot11DMGCounters TABLE
-- *******************************************************************
-- *******************************************************************
-- * dot11BSSStatisticsTable TABLE
-- *******************************************************************
dot11BSSStatisticsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11BSSStatisticsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a Table management object.
The dot11BSSStatisticsTable Table contains objects related to BSS
Statistics. It is present only in an AP."
::= { dot11mac 10 }
dot11BSSStatisticsEntry OBJECT-TYPE
SYNTAX Dot11BSSStatisticsEntry
3126
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an entry in the dot11BSSStatisticsTable Table.
ifIndex - Each IEEE 802.11 interface is represented by an
ifEntry. Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11BSSStatisticsTable 1 }
Dot11BSSStatisticsEntry ::=
SEQUENCE {
dot11BSSLoadChannelUtilization Unsigned32,
dot11BSSLoadAvailableAdmissionCapacity Unsigned32,
dot11BSSLoadAssocAttemptCount Unsigned32,
dot11BSSLoadAssocFailCount Unsigned32,
dot11BSSLoadReassocAttemptCount Unsigned32,
dot11BSSLoadReassocFailCount Unsigned32
}
dot11BSSLoadChannelUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MLME.
This object indicates the percentage of time, linearly scaled with 255
representing 100%, that the AP sensed the medium was busy, as indicated by
either the physical or virtual carrier sense (CS) mechanism."
REFERENCE "IEEE Std 802.11-2016, 9.4.2.28"
DEFVAL { 0 }
::= { dot11BSSStatisticsEntry 1 }
dot11BSSLoadAvailableAdmissionCapacity OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "32 microseconds/second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MLME.
This object indicates the remaining amount of medium time available via
explicit admission control."
REFERENCE "IEEE Std 802.11-2016, 9.4.2.28"
DEFVAL { 0 }
::= { dot11BSSStatisticsEntry 2 }
dot11BSSLoadAssocAttemptCount OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MLME.
This object contains the count of the number of association procedures
started at the AP. It reports the count of such events since the AP
started the operation of its BSS (i.e., since the last MLME-START.request
primitive)."
DEFVAL { 0 }
::= { dot11BSSStatisticsEntry 3 }
dot11BSSLoadAssocFailCount OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
3127
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MLME.
This object contains the count of the number of unsuccessful association
procedures at the AP (i.e., it is the number of association procedures
started less those that completed successfully). It reports the count of
such events since the AP started the operation of its BSS (i.e., since the
last MLME-START.request primitive)."
DEFVAL { 0 }
::= { dot11BSSStatisticsEntry 4 }
dot11BSSLoadReassocAttemptCount OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MLME.
This object contains the count of the number of reassociation procedures
started at the AP. It reports the count of such events since the AP
started the operation of its BSS (i.e., since the last MLME-START.request
primitive)."
DEFVAL { 0 }
::= { dot11BSSStatisticsEntry 5 }
dot11BSSLoadReassocFailCount OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MLME.
This object contains the count of the number of unsuccessful reassociation
procedures at the AP (i.e., it is the number of reassociation procedures
started less those that completed successfully). It reports the count of
such events since the AP started the operation of its BSS (i.e., since the
last MLME-START.request primitive)."
DEFVAL { 0 }
::= { dot11BSSStatisticsEntry 6 }
-- **********************************************************************
-- * PHY Attribute Templates
-- **********************************************************************
-- **********************************************************************
-- * dot11PhyOperation TABLE
-- **********************************************************************
dot11PhyOperationTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyOperationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"PHY level attributes concerned with operation. Implemented as a table
indexed on ifIndex to allow for multiple instantiations on an Agent."
::= { dot11phy 1 }
dot11PhyOperationEntry OBJECT-TYPE
SYNTAX Dot11PhyOperationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyOperation Table.
3128
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11PhyOperationTable 1 }
Dot11PhyOperationEntry ::=
SEQUENCE {
dot11PHYType INTEGER,
dot11CurrentRegDomain Unsigned32,
dot11TempType INTEGER }
dot11PHYType OBJECT-TYPE
SYNTAX INTEGER {
dsss(2),
ofdm(4),
hrdsss(5),
erp(6),
ht(7),
dmg(8),
vht(9),
tvht(10) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY.
This is an 8-bit integer value that identifies the supported PHY type.
Currently defined values and their corresponding PHY types are:
DSSS 2.4 GHz = 2, OFDM = 4, HRDSSS = 5, ERP = 6, HT = 7, DMG = 8, VHT = 9,
TVHT = 10"
::= { dot11PhyOperationEntry 1 }
dot11CurrentRegDomain OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized.
The current regulatory domain this instance of the PHY is supporting. This
object corresponds to one of the RegDomains listed in
dot11RegDomainsSupported."
::= { dot11PhyOperationEntry 2 }
dot11TempType OBJECT-TYPE
SYNTAX INTEGER { tempType1(1), tempType2(2) }
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The use of dot11TempType is deprecated because no associated behavior is
described in IEEE Std 802.11-2016, and this entity may be removed in a
later revision of the standard.
This is a status variable.
It is written by the PHY.
There are different operating temperature requirements dependent on the
anticipated environmental conditions. This attribute describes the current
PHY's operating temperature range capability. Currently defined values and
their corresponding temperature ranges are:
3129
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Type 1 = X'01'-Commercial range of 0 to 40 degrees C,
Type 2 = X'02'-Industrial range of -30 to 70 degrees C."
::= { dot11PhyOperationEntry 3 }
-- **********************************************************************
-- * End of dot11PhyOperation TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11PhyAntenna TABLE
-- **********************************************************************
dot11PhyAntennaTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyAntennaEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group of attributes for PhyAntenna. Implemented as a table indexed on
ifIndex to allow for multiple instances on an agent."
::= { dot11phy 2}
dot11PhyAntennaEntry OBJECT-TYPE
SYNTAX Dot11PhyAntennaEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyAntenna Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11PhyAntennaTable 1 }
Dot11PhyAntennaEntry ::=
SEQUENCE {
dot11CurrentTxAntenna Unsigned32,
dot11DiversitySupportImplemented INTEGER,
dot11CurrentRxAntenna Unsigned32,
dot11AntennaSelectionOptionImplemented TruthValue,
dot11TransmitExplicitCSIFeedbackASOptionImplemented TruthValue,
dot11TransmitIndicesFeedbackASOptionImplemented TruthValue,
dot11ExplicitCSIFeedbackASOptionImplemented TruthValue,
dot11TransmitIndicesComputationASOptionImplemented TruthValue,
dot11ReceiveAntennaSelectionOptionImplemented TruthValue,
dot11TransmitSoundingPPDUOptionImplemented TruthValue,
dot11NumberOfActiveRxAntennas Unsigned32 }
dot11CurrentTxAntenna OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The current antenna being used to transmit. This value is one of the
values appearing in dot11TxAntennaImplemented. This may be used by a
management agent to control which antenna is used for transmission."
::= { dot11PhyAntennaEntry 1 }
dot11DiversitySupportImplemented OBJECT-TYPE
SYNTAX INTEGER { fixedlist(1), notsupported(2), dynamic(3) }
3130
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This implementation's support for diversity, encoded as:
X'01'-diversity is available and is performed over the fixed list of
antennas defined in dot11DiversitySelectionRxImplemented.
X'02'-diversity is not supported.
X'03'-diversity is supported and control of diversity is also available,
in which case the attribute dot11DiversitySelectionRxImplemented can be
dynamically modified by the LME."
::= { dot11PhyAntennaEntry 2 }
dot11CurrentRxAntenna OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY.
The current antenna being used to receive, if the dot11 DiversitySupport
indicates that diversity is not supported. The selected antenna is one of
the antennae marked for receive in the dot11AntennasListTable."
::= { dot11PhyAntennaEntry 3 }
dot11AntennaSelectionOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that ASEL is supported by the station
implementation."
DEFVAL { false }
::= { dot11PhyAntennaEntry 4 }
dot11TransmitExplicitCSIFeedbackASOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the transmit ASEL based on
explicit CSI feedback is supported by the station implementation."
DEFVAL { false }
::= { dot11PhyAntennaEntry 5 }
dot11TransmitIndicesFeedbackASOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3131
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute, when true, indicates that the transmit ASEL based on
antenna indices feedback is supported by the station implementation."
DEFVAL { false }
::= { dot11PhyAntennaEntry 6 }
dot11ExplicitCSIFeedbackASOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the computation of CSI and
feedback the results to support the peer to do ASEL is supported by the
station implementation."
DEFVAL { false }
::= { dot11PhyAntennaEntry 7 }
dot11TransmitIndicesComputationASOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the transmit ASEL based on
antenna indices selection computation and feedback the results to support
the peer to do ASEL is supported by the station implementation."
DEFVAL { false }
::= { dot11PhyAntennaEntry 8 }
dot11ReceiveAntennaSelectionOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the receive ASEL is supported by
the station implementation."
DEFVAL { false }
::= { dot11PhyAntennaEntry 9 }
dot11TransmitSoundingPPDUOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the transmission of sounding
PPDUs is supported by the station implementation."
DEFVAL { false }
::= { dot11PhyAntennaEntry 10 }
dot11NumberOfActiveRxAntennas OBJECT-TYPE
SYNTAX Unsigned32 (1..4)
MAX-ACCESS read-only
STATUS current
3132
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a status variable.
It is written by the PHY.
This attribute indicates the number of current active antennas being used
to receive."
::= { dot11PhyAntennaEntry 11 }
-- **********************************************************************
-- * End of dot11PhyAntenna TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11PhyTxPower TABLE
-- **********************************************************************
dot11PhyTxPowerTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyTxPowerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group of attributes for dot11PhyTxPowerTable. Implemented as a table
indexed on STA ID to allow for multiple instances on an Agent."
::= { dot11phy 3}
dot11PhyTxPowerEntry OBJECT-TYPE
SYNTAX Dot11PhyTxPowerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyTxPower Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11PhyTxPowerTable 1 }
Dot11PhyTxPowerEntry ::=
SEQUENCE {
dot11NumberSupportedPowerLevelsImplemented Unsigned32,
dot11TxPowerLevel1 Unsigned32,
dot11TxPowerLevel2 Unsigned32,
dot11TxPowerLevel3 Unsigned32,
dot11TxPowerLevel4 Unsigned32,
dot11TxPowerLevel5 Unsigned32,
dot11TxPowerLevel6 Unsigned32,
dot11TxPowerLevel7 Unsigned32,
dot11TxPowerLevel8 Unsigned32,
dot11CurrentTxPowerLevel Unsigned32,
dot11TxPowerLevelExtended OCTET STRING,
dot11CurrentTxPowerLevelExtended Unsigned32 }
dot11NumberSupportedPowerLevelsImplemented OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The number of power levels supported by the PHY. This attribute can have a
value of 1 to 8."
::= { dot11PhyTxPowerEntry 1 }
3133
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TxPowerLevel1 OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "mW"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The transmit output power for LEVEL1. This is also the default power
level."
::= { dot11PhyTxPowerEntry 2 }
dot11TxPowerLevel2 OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "mW"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The transmit output power for LEVEL2."
::= { dot11PhyTxPowerEntry 3 }
dot11TxPowerLevel3 OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "mW"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The transmit output power for LEVEL3."
::= { dot11PhyTxPowerEntry 4 }
dot11TxPowerLevel4 OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "mW"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The transmit output power for LEVEL4."
::= { dot11PhyTxPowerEntry 5 }
dot11TxPowerLevel5 OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "mW"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The transmit output power for LEVEL5."
::= { dot11PhyTxPowerEntry 6 }
dot11TxPowerLevel6 OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "mW"
3134
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The transmit output power for LEVEL6."
::= { dot11PhyTxPowerEntry 7 }
dot11TxPowerLevel7 OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "mW"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The transmit output power for LEVEL7."
::= { dot11PhyTxPowerEntry 8 }
dot11TxPowerLevel8 OBJECT-TYPE
SYNTAX Unsigned32 (0..10000)
UNITS "mW"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The transmit output power for LEVEL8."
::= { dot11PhyTxPowerEntry 9 }
dot11CurrentTxPowerLevel OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY.
Set to min(N,8) where N is an index into dot11TxPowerLevel or
dot11TxPowerLevelExtended and identifies the transmit power level
currently being used to transmit data. Some PHYs also use this value to
determine the receiver sensitivity requirements for CCA."
::= { dot11PhyTxPowerEntry 10 }
dot11TxPowerLevelExtended OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2..256))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
It has an even number of octets. It is organized as a variable length list
of octet pairs, where each octet pair defines a big-endian 16-bit integer.
The N-th integer represents the N-th EIRP, in units of 250 microWatts. The
values dot11TxPowerLevel1 to dot11TxPowerLevel inclusive, in order,
correspond to the first to min(8,
dot11NumberSupportedPowerLevelsImplemented)-th integers in this variable.
Where dot11TxPowerLevel1 to dot11TxPowerLevel inclusive contain EIRP
3135
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
values then, when converted from units of milliWatts to 250 microWatts,
they shall appear in order in positions 1 to min(8,
dot11NumberSupportedPowerLevelsImplemented) in this variable."
::= { dot11PhyTxPowerEntry 11 }
dot11CurrentTxPowerLevelExtended OBJECT-TYPE
SYNTAX Unsigned32 (1..128)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY.
Contains an index into the integer array in dot11TxPowerLevelExtended
(where the value 1 indicates the first value in dot11TxPowerLevelExtended,
and so on) that identifies the transmit output power currently being used
to transmit data."
::= { dot11PhyTxPowerEntry 12 }
-- **********************************************************************
-- * End of dot11PhyTxPower TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11PhyDSSSEntry TABLE
-- **********************************************************************
dot11PhyDSSSTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyDSSSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11PhyDSSSEntry. Implemented as a table indexed
on ifIndex to allow for multiple instances on an Agent."
::= { dot11phy 5 }
dot11PhyDSSSEntry OBJECT-TYPE
SYNTAX Dot11PhyDSSSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyDSSSEntry Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11PhyDSSSTable 1 }
Dot11PhyDSSSEntry ::=
SEQUENCE {
dot11CurrentChannel Unsigned32,
dot11CCAModeSupported Unsigned32,
dot11CurrentCCAMode INTEGER,
dot11EDThreshold Integer32 }
dot11CurrentChannel OBJECT-TYPE
SYNTAX Unsigned32 (1..14)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY.
The current operating frequency channel of the DSSS PHY. Valid channel
3136
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
numbers are as defined in 15.4.4.3"
::= { dot11PhyDSSSEntry 1 }
dot11CCAModeSupported OBJECT-TYPE
SYNTAX Unsigned32 (1..7)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
dot11CCAModeSupported is a bit-significant value, representing all of the
CCA modes supported by the DSSS PHY in addition to detection of energy
above -62 dBm (which is always supported). Valid values are:
energy detect only (edonly) = 01,
carrier sense only (csonly) = 02,
carrier sense and energy detect (csanded)= 04
or the logical sum of any of these values."
::= { dot11PhyDSSSEntry 2 }
dot11CurrentCCAMode OBJECT-TYPE
SYNTAX INTEGER {
edonly(1),
csonly(2),
csanded(4), cswithtimer(8),
hrcsanded(16) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The current CCA method in operation for a DSSS or HR/DSSS PHY, in addition
to detection of energy above -62 dBm (which is always supported). Valid
values are:
energy detect only (edonly) = 01,
carrier sense only (csonly) = 02,
carrier sense and energy detect (csanded)= 04
carrier sense with timer (cswithtimer)= 08
high rate carrier sense and energy detect (hrcsanded)=16,
subject to the support indicated in dot11CCAModeSupported (for the DSSS
PHY) or dot11HRCCAModeImplemented (for the HR/DSSS PHY)."
::= { dot11PhyDSSSEntry 3 }
dot11EDThreshold OBJECT-TYPE
SYNTAX Integer32(-100..-70)
UNITS "dBm"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The current energy detect threshold being used by the DSSS PHY or HR/DSSS
PHY."
::= { dot11PhyDSSSEntry 4 }
-- **********************************************************************
-- * End of dot11PhyDSSSEntry TABLE
-- **********************************************************************
-- **********************************************************************
3137
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- * dot11RegDomainsSupported TABLE
-- **********************************************************************
dot11RegDomainsSupportedTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RegDomainsSupportedEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"Superceded by dot11OperatingClassesTable.
There are different operational requirements dependent on the regulatory
domain. This attribute list describes the regulatory domains the PHY
supportS in this implementation. Currently defined values and their
corresponding Regulatory Domains are:
FCC (USA) = X'10', DOC (Canada) = X'20', ETSI (most of Europe) = X'30',
Spain = X'31', France = X'32', Japan = X'40', China = X'50', Other = X'00'
"
::= { dot11phy 7}
dot11RegDomainsSupportedEntry OBJECT-TYPE
SYNTAX Dot11RegDomainsSupportedEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"Superceded by dot11OperatingClassesTable.
An entry in the dot11RegDomainsSupportedTable.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11RegDomainsSupportedIndex }
::= { dot11RegDomainsSupportedTable 1 }
Dot11RegDomainsSupportedEntry ::=
SEQUENCE {
dot11RegDomainsSupportedIndex Unsigned32,
dot11RegDomainsImplementedValue INTEGER }
dot11RegDomainsSupportedIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The auxiliary variable used to identify instances of the columnar objects
in the RegDomainsSupport Table."
::= { dot11RegDomainsSupportedEntry 1 }
dot11RegDomainsImplementedValue OBJECT-TYPE
SYNTAX INTEGER {
other (0),
fcc(16),
doc(32),
etsi(48),
spain (49),
france(50),
japan (64)}
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
There are different operational requirements dependent on the regulatory
domain. This attribute list describes the regulatory domains the PHY
3138
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
supports in this implementation. Currently defined values and their
corresponding Regulatory Domains are:
FCC (USA) = X'10', DOC (Canada) = X'20', ETSI (most of Europe) = X'30',
Spain = X'31', France = X'32', Japan = X'40', China = X'50' "
::= { dot11RegDomainsSupportedEntry 2 }
-- **********************************************************************
-- * End of dot11RegDomainsSupported TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11AntennasList TABLE
-- **********************************************************************
dot11AntennasListTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11AntennasListEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table represents the list of antennae. An antenna can be marked to
be capable of transmitting, receiving, and/or for participation in receive
diversity. Each entry in this table represents a single antenna with its
properties. The maximum number of antennae that can be contained in this
table is 255."
::= { dot11phy 8 }
dot11AntennasListEntry OBJECT-TYPE
SYNTAX Dot11AntennasListEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11AntennasListTable, representing the properties of a
single antenna.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11AntennaListIndex }
::= { dot11AntennasListTable 1 }
Dot11AntennasListEntry ::=
SEQUENCE {
dot11AntennaListIndex Unsigned32,
dot11TxAntennaImplemented TruthValue,
dot11RxAntennaImplemented TruthValue,
dot11DiversitySelectionRxImplemented TruthValue }
dot11AntennaListIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index of an antenna which is used to identify the columnar
objects in the dot11AntennasList Table."
::= { dot11AntennasListEntry 1 }
dot11TxAntennaImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3139
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
When true, this object indicates that the antenna represented by
dot11AntennaIndex can be used as a transmit antenna."
::= { dot11AntennasListEntry 2 }
dot11RxAntennaImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
When true, this object indicates that the antenna represented by the
dot11AntennaIndex can be used as a receive antenna."
::= { dot11AntennasListEntry 3 }
dot11DiversitySelectionRxImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
When true, this object indicates that the antenna represented by
dot11AntennaIndex can be used for receive diversity. This object is true
only if the antenna can be used as a receive antenna, as indicated by
dot11RxAntennaImplemented."
::= { dot11AntennasListEntry 4 }
-- **********************************************************************
-- * End of dot11AntennasList TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11SupportedDataRatesTx TABLE
-- **********************************************************************
dot11SupportedDataRatesTxTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11SupportedDataRatesTxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Transmit bit rates supported by the PHY, represented by a count from
X'02-X'7f, corresponding to data rates in increments of 500 kb/s from 1
Mb/s to 63.5 Mb/s subject to limitations of each individual PHY."
::= { dot11phy 9 }
dot11SupportedDataRatesTxEntry OBJECT-TYPE
SYNTAX Dot11SupportedDataRatesTxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the dot11SupportedDataRatesTx Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11SupportedDataRatesTxIndex }
::= { dot11SupportedDataRatesTxTable 1 }
Dot11SupportedDataRatesTxEntry ::=
SEQUENCE {
dot11SupportedDataRatesTxIndex Unsigned32,
dot11ImplementedDataRatesTxValue Unsigned32 }
3140
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11SupportedDataRatesTxIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index object that identifies which data rate to access. Range is 1..255."
::= { dot11SupportedDataRatesTxEntry 1 }
dot11ImplementedDataRatesTxValue OBJECT-TYPE
SYNTAX Unsigned32 (2..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The Transmit bit rates supported by the PHY, represented by a count from
X'02-X'7f, corresponding to data rates in increments of 500 kb/s from 1
Mb/s to 63.5 Mb/s subject to limitations of each individual PHY."
::= { dot11SupportedDataRatesTxEntry 2 }
-- **********************************************************************
-- * End of dot11SupportedDataRatesTx TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11SupportedDataRatesRx TABLE
-- **********************************************************************
dot11SupportedDataRatesRxTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11SupportedDataRatesRxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The receive bit rates supported by the PHY, represented by a count from
X'002-X'7f, corresponding to data rates in increments of 500 kb/s from 1
Mb/s to 63.5 Mb/s."
::= { dot11phy 10 }
dot11SupportedDataRatesRxEntry OBJECT-TYPE
SYNTAX Dot11SupportedDataRatesRxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the dot11SupportedDataRatesRx Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11SupportedDataRatesRxIndex }
::= { dot11SupportedDataRatesRxTable 1 }
Dot11SupportedDataRatesRxEntry ::=
SEQUENCE {
dot11SupportedDataRatesRxIndex Unsigned32,
dot11ImplementedDataRatesRxValue Unsigned32 }
dot11SupportedDataRatesRxIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index object that identifies which data rate to access. Range is 1..255."
::= { dot11SupportedDataRatesRxEntry 1 }
3141
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11ImplementedDataRatesRxValue OBJECT-TYPE
SYNTAX Unsigned32 (2..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The receive bit rates supported by the PHY, represented by a count from
X'02-X'7f, corresponding to data rates in increments of 500 kb/s from 1
Mb/s to 63.5 Mb/s."
::= { dot11SupportedDataRatesRxEntry 2 }
-- **********************************************************************
-- * End of dot11SupportedDataRatesRx TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11PhyOFDM TABLE
-- **********************************************************************
dot11PhyOFDMTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyOFDMEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Group of attributes for dot11PhyOFDMTable. Implemented as a table indexed
on ifindex to allow for multiple instances on an Agent."
::= { dot11phy 11 }
dot11PhyOFDMEntry OBJECT-TYPE
SYNTAX Dot11PhyOFDMEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyOFDM Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11PhyOFDMTable 1 }
Dot11PhyOFDMEntry ::=
SEQUENCE {
dot11CurrentFrequency Unsigned32,
dot11TIThreshold Integer32,
dot11FrequencyBandsImplemented Unsigned32,
dot11ChannelStartingFactor Unsigned32,
dot11FiveMHzOperationImplemented TruthValue,
dot11TenMHzOperationImplemented TruthValue,
dot11TwentyMHzOperationImplemented TruthValue,
dot11PhyOFDMChannelWidth INTEGER,
dot11OFDMCCAEDImplemented TruthValue,
dot11OFDMCCAEDRequired TruthValue,
dot11OFDMEDThreshold Unsigned32,
dot11STATransmitPowerClass INTEGER,
dot11ACRType INTEGER }
dot11CurrentFrequency OBJECT-TYPE
SYNTAX Unsigned32 (0..200)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
3142
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a status variable.
It is written by the PHY.
The number of the current operating frequency channel of the OFDM PHY."
::= { dot11PhyOFDMEntry 1 }
dot11TIThreshold OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"Superseded by PHY-specific or regulatory CCA energy detect limits.
The Threshold being used to detect a busy medium (frequency). CCA reports
a busy medium upon detecting the RSSI above this threshold."
::= { dot11PhyOFDMEntry 2 }
dot11FrequencyBandsImplemented OBJECT-TYPE
SYNTAX Unsigned32 (1..127)
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"Superseded by subband-specific supported operating classes.
This is a capability variable.
Its value is determined by device capabilities.
The capability of the OFDM PHY implementation to operate in the 4.9 GHz
and 5 GHz bands. Coded as an integer value with bit 0 LSB as follows:
bit 0 .. capable of operating in the 5.15-5.25 GHz band
bit 1 .. capable of operating in the 5.25-5.35 GHz band
bit 2 .. capable of operating in the 5.725-5.825 GHz band
bit 3 .. capable of operating in the 5.47-5.725 GHz band
bit 4 .. capable of operating in the lower Japanese (5.15-5.25 GHz) band
bit 5 .. capable of operating in the 5.03-5.091 GHz band
bit 6 .. capable of operating in the 4.94-4.99 GHz band
For example, for an implementation capable of operating in the 5.15-5.35
GHz bands this attribute would take the value 3."
::= { dot11PhyOFDMEntry 3 }
dot11ChannelStartingFactor OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
The base factor from which channel center frequencies are calculated. This
number is multiplied by 500 kHz to form the base frequency to be added to
the channel number x 5 MHz."
DEFVAL { 10000 }
::= { dot11PhyOFDMEntry 4 }
dot11FiveMHzOperationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the 5 MHz Operation is
implemented."
3143
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { false }
::= { dot11PhyOFDMEntry 5 }
dot11TenMHzOperationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the 10 MHz Operation is
implemented."
DEFVAL { false }
::= { dot11PhyOFDMEntry 6 }
dot11TwentyMHzOperationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the 20 MHz Operation is
implemented."
DEFVAL { true }
::= { dot11PhyOFDMEntry 7 }
dot11PhyOFDMChannelWidth OBJECT-TYPE
SYNTAX INTEGER { width5MHz(1), width10MHz(2), width20MHz(3)}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME.
Changes take effect as soon as practical in the implementation.
This is an 8-bit integer value that identifies the OFDM PHY channel width.
Currently defined values and their corresponding Channel widths are:
5 MHz = 01, 10 MHz = 02, 20 MHz = 03"
::= { dot11PhyOFDMEntry 8 }
dot11OFDMCCAEDImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates that the OFDM PHY is capable of CCA-Energy
Detect."
::= { dot11PhyOFDMEntry 9 }
dot11OFDMCCAEDRequired OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME when the device is initialized for operation in a
band defined by an Operating Class.
3144
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates that the PHY CCA-Energy Detect functionality is
enabled."
::= { dot11PhyOFDMEntry 10 }
dot11OFDMEDThreshold OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written the SME when the device is initialized for operation in a
band defined by an Operating Class, or written by an external management
entity.
Changes take effect as soon as practical in the implementation.
The current Energy Detect Threshold being used by the OFDM PHY."
::= { dot11PhyOFDMEntry 11 }
dot11STATransmitPowerClass OBJECT-TYPE
SYNTAX INTEGER { classA(1), classB(2), classC(3), classD(4) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The station transmit power class: Class A=1, Class B=2, Class C=3, Class
D=4 (as defined in D.2.2)."
DEFVAL { 1 }
::= { dot11PhyOFDMEntry 12 }
dot11ACRType OBJECT-TYPE
SYNTAX INTEGER { standard(1), enhanced(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME.
The Adjacent and Nonadjacent Channel Rejection performance:
when this attribute = 1 the levels in Table 17-18 apply; when this
attribute = 2 the levels in Table 17-19 apply."
DEFVAL { 1 }
::= { dot11PhyOFDMEntry 13 }
-- **********************************************************************
-- * End of dot11PhyOFDM TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11PhyHRDSSSEntry TABLE
-- **********************************************************************
dot11PhyHRDSSSTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyHRDSSSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11PhyHRDSSSEntry. Implemented as a table
indexed on ifIndex to allow for multiple instances on an Agent."
::= { dot11phy 12 }
dot11PhyHRDSSSEntry OBJECT-TYPE
SYNTAX Dot11PhyHRDSSSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
3145
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"An entry in the dot11PhyHRDSSSEntry Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11PhyHRDSSSTable 1 }
Dot11PhyHRDSSSEntry ::=
SEQUENCE {
dot11ShortPreambleOptionImplemented TruthValue,
dot11HRCCAModeImplemented Unsigned32 }
dot11ShortPreambleOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the short preamble option as
defined in 16.2.2.3 is implemented."
DEFVAL { false }
::= { dot11PhyHRDSSSEntry 1 }
dot11HRCCAModeImplemented OBJECT-TYPE
SYNTAX Unsigned32 (1..31)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
dot11HRCCAModeImplemented is a bit-significant value, representing all of
the CCA modes supported by the HR/DSSS PHY, in addition to detection of
energy above -62 dBm (which is always supported). Valid values are:
energy detect only (edonly) = 01,
carrier sense with timer (cswithtimer)= 08,
high rate carrier sense and energy detect (hrcsanded)= 16
or the logical sum of any of these values."
::= { dot11PhyHRDSSSEntry 5 }
-- **********************************************************************
-- * End of dot11PhyHRDSSSEntry TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11HoppingPattern TABLE
-- **********************************************************************
dot11HoppingPatternTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11HoppingPatternEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"This attribute is deprecated because the frequency hopping PHY is no
longer present in IEEE Std 802.11-2016.
The (conceptual) table of attributes necessary for a frequency hopping
implementation to be able to create the hopping sequences necessary to
operate in the subband for the associated domain country string."
::= { dot11phy 13 }
3146
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11HoppingPatternEntry OBJECT-TYPE
SYNTAX Dot11HoppingPatternEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"This attribute is deprecated because the frequency hopping PHY is no
longer present in IEEE Std 802.11-2016.
An entry (conceptual row) in the Hopping Pattern Table that indicates the
random hopping sequence to be followed.
IfIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB are indexed by ifIndex."
INDEX { ifIndex, dot11HoppingPatternIndex }
::= { dot11HoppingPatternTable 1 }
Dot11HoppingPatternEntry ::=
SEQUENCE {
dot11HoppingPatternIndex Unsigned32,
dot11RandomTableFieldNumber Unsigned32 }
dot11HoppingPatternIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"This attribute is deprecated because the frequency hopping PHY is no
longer present in IEEE Std 802.11-2016.
The auxiliary variable used to identify instances of the columnar objects
in the Hopping Pattern Table."
::= { dot11HoppingPatternEntry 1 }
dot11RandomTableFieldNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"This attribute is deprecated because the frequency hopping PHY is no
longer present in IEEE Std 802.11-2016.
This is a control variable.
It is written by the SME when the device is initialized.
This attribute indicates the value of the starting channel number in the
hopping sequence of the subband for the associated domain country string."
DEFVAL { 0 }
::= { dot11HoppingPatternEntry 2 }
-- **********************************************************************
-- * End of dot11HoppingPattern TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11PhyERP TABLE
-- **********************************************************************
dot11PhyERPTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyERPEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11PhyERPEntry. Implemented as a table indexed
on ifIndex to allow for multiple instances on an Agent."
3147
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11phy 14 }
dot11PhyERPEntry OBJECT-TYPE
SYNTAX Dot11PhyERPEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyERPEntry Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX {ifIndex}
::= { dot11PhyERPTable 1 }
Dot11PhyERPEntry ::=
SEQUENCE {
dot11ShortSlotTimeOptionImplemented TruthValue,
dot11ShortSlotTimeOptionActivated TruthValue }
dot11ShortSlotTimeOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the Short Slot Time option as
defined in 9.4.1.4 is implemented."
DEFVAL { false }
::= { dot11PhyERPEntry 5}
dot11ShortSlotTimeOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the Short Slot Time option as
defined in 9.4.1.4 is enabled."
DEFVAL { false }
::= { dot11PhyERPEntry 6 }
-- **********************************************************************
-- * End of dot11PhyERP TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11 Phy HT TABLE
-- **********************************************************************
dot11PhyHTTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyHTEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11PhyHTTable. Implemented as a table indexed
on ifIndex to allow for multiple instances on an Agent."
::= { dot11phy 15 }
dot11PhyHTEntry OBJECT-TYPE
SYNTAX Dot11PhyHTEntry
3148
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyHTEntry Table. ifIndex - Each IEEE 802.11
interface is represented by an ifEntry. Interface tables in this MIB
module are indexed by ifIndex."
INDEX {ifIndex}
::= { dot11PhyHTTable 1 }
Dot11PhyHTEntry ::=
SEQUENCE {
dot11FortyMHzOperationImplemented TruthValue,
dot11FortyMHzOperationActivated TruthValue,
dot11CurrentPrimaryChannel Unsigned32,
dot11CurrentSecondaryChannel Unsigned32,
dot11NumberOfSpatialStreamsImplemented Unsigned32,
dot11NumberOfSpatialStreamsActivated Unsigned32,
dot11HTGreenfieldOptionImplemented TruthValue,
dot11HTGreenfieldOptionActivated TruthValue,
dot11ShortGIOptionInTwentyImplemented TruthValue,
dot11ShortGIOptionInTwentyActivated TruthValue,
dot11ShortGIOptionInFortyImplemented TruthValue,
dot11ShortGIOptionInFortyActivated TruthValue,
dot11LDPCCodingOptionImplemented TruthValue,
dot11LDPCCodingOptionActivated TruthValue,
dot11TxSTBCOptionImplemented TruthValue,
dot11TxSTBCOptionActivated TruthValue,
dot11RxSTBCOptionImplemented TruthValue,
dot11RxSTBCOptionActivated TruthValue,
dot11BeamFormingOptionImplemented TruthValue,
dot11BeamFormingOptionActivated TruthValue,
dot11HighestSupportedDataRate Unsigned32,
dot11TxMCSSetDefined TruthValue,
dot11TxRxMCSSetNotEqual TruthValue,
dot11TxMaximumNumberSpatialStreamsSupported Unsigned32,
dot11TxUnequalModulationSupported TruthValue }
dot11FortyMHzOperationImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the 40 MHz Operation is
implemented."
DEFVAL { false }
::= { dot11PhyHTEntry 1 }
dot11FortyMHzOperationActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the 40 MHz Operation is
enabled."
DEFVAL { false }
::= { dot11PhyHTEntry 2 }
3149
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11CurrentPrimaryChannel OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY.
This attribute indicates the operating channel. If 20/40 MHz BSS is
currently in use then this attribute indicates the primary channel."
::= { dot11PhyHTEntry 3 }
dot11CurrentSecondaryChannel OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY.
This attribute indicates the channel number of the secondary channel. If
20/40 MHz BSS is not currently in use, this attribute value shall be 0."
::= { dot11PhyHTEntry 4 }
dot11NumberOfSpatialStreamsImplemented OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of spatial streams imple-
mented."
DEFVAL { 2 }
::= { dot11PhyHTEntry 5 }
dot11NumberOfSpatialStreamsActivated OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum number of spatial streams enabled."
DEFVAL { 2 }
::= { dot11PhyHTEntry 6 }
dot11HTGreenfieldOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the HT-greenfield option is
implemented."
DEFVAL { false }
::= { dot11PhyHTEntry 7 }
dot11HTGreenfieldOptionActivated OBJECT-TYPE
3150
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the HT-greenfield option is
enabled."
DEFVAL { false }
::= { dot11PhyHTEntry 8 }
dot11ShortGIOptionInTwentyImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the Short Guard option is
implemented for 20 MHz operation."
DEFVAL { false }
::= { dot11PhyHTEntry 9 }
dot11ShortGIOptionInTwentyActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the Short Guard option is
enabled for 20 MHz operation."
DEFVAL { false }
::= { dot11PhyHTEntry 10 }
dot11ShortGIOptionInFortyImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the Short Guard option is
implemented for 40 MHz operation."
DEFVAL { false }
::= { dot11PhyHTEntry 11 }
dot11ShortGIOptionInFortyActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the Short Guard option is
enabled for 40 MHz operation."
3151
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { false }
::= { dot11PhyHTEntry 12 }
dot11LDPCCodingOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the LDPC coding option is
implemented."
DEFVAL { false }
::= { dot11PhyHTEntry 13 }
dot11LDPCCodingOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the LDPC coding option is
enabled."
DEFVAL { false }
::= { dot11PhyHTEntry 14 }
dot11TxSTBCOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the entity is capable of
transmitting frames using STBC option."
DEFVAL { false }
::= { dot11PhyHTEntry 15 }
dot11TxSTBCOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the entity's capability of
transmitting frames using STBC option is enabled."
DEFVAL { false }
::= { dot11PhyHTEntry 16 }
dot11RxSTBCOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3152
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute, when true, indicates that the entity is capable of
receiving frames that are sent using the STBC."
DEFVAL { false }
::= { dot11PhyHTEntry 17 }
dot11RxSTBCOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the entity's capability of
receiving frames that are sent using the STBC is enabled."
DEFVAL { false }
::= { dot11PhyHTEntry 18 }
dot11BeamFormingOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the beamforming option is
implemented."
DEFVAL { false }
::= { dot11PhyHTEntry 19 }
dot11BeamFormingOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the beamforming option is
enabled."
DEFVAL { false }
::= { dot11PhyHTEntry 20 }
dot11HighestSupportedDataRate OBJECT-TYPE
SYNTAX Unsigned32 (0..600)
UNITS "Mb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute shall specify the Highest Data Rate at which the station
may receive data."
DEFVAL { 0 }
::= { dot11PhyHTEntry 21 }
dot11TxMCSSetDefined OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
3153
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the Tx MCS set is defined."
DEFVAL { false }
::= { dot11PhyHTEntry 22 }
dot11TxRxMCSSetNotEqual OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the PHY.
This attribute, when true, indicates that the supported Tx and Rx MCS sets
are not equal."
DEFVAL { false }
::= { dot11PhyHTEntry 23 }
dot11TxMaximumNumberSpatialStreamsSupported OBJECT-TYPE
SYNTAX Unsigned32 (0..3)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the Tx maximum number of spatial streams sup-
ported."
DEFVAL { 0 }
::= { dot11PhyHTEntry 24 }
dot11TxUnequalModulationSupported OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that Tx UEQM is supported."
DEFVAL { false }
::= { dot11PhyHTEntry 25 }
-- **********************************************************************
-- * End of dot11 PHY HT TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11 Supported MCS Tx TABLE
-- **********************************************************************
dot11SupportedMCSTxTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11SupportedMCSTxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"he Transmit MCS supported by the PHY, represented by a count from 1 to
127, subject to limitations of each individual PHY."
::= { dot11phy 16 }
3154
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11SupportedMCSTxEntry OBJECT-TYPE
SYNTAX Dot11SupportedMCSTxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the dot11SupportedMCSTx Table.
ifIndex - Each IEEE 802.11 interface is represented by an
ifEntry. Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11SupportedMCSTxIndex }
::= { dot11SupportedMCSTxTable 1 }
Dot11SupportedMCSTxEntry ::=
SEQUENCE {
dot11SupportedMCSTxIndex Unsigned32,
dot11SupportedMCSTxValue Unsigned32 }
dot11SupportedMCSTxIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index object that identifies which MCS to access. Range is 1..255."
::= { dot11SupportedMCSTxEntry 1 }
dot11SupportedMCSTxValue OBJECT-TYPE
SYNTAX Unsigned32 (1..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The Transmit MCS supported by the PHY, represented by a count from 1 to
127, subject to limitations of each individual PHY."
::= { dot11SupportedMCSTxEntry 2 }
-- **********************************************************************
-- * End of dot11 Supported MCS Tx TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11 Supported MCS Rx TABLE
-- **********************************************************************
dot11SupportedMCSRxTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11SupportedMCSRxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The receive MCS supported by the PHY, represented by a count from 1 to
127, subject to limitations of each individual PHY."
::= { dot11phy 17 }
dot11SupportedMCSRxEntry OBJECT-TYPE
SYNTAX Dot11SupportedMCSRxEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An Entry (conceptual row) in the dot11SupportedMCSRx Table. ifIndex -
Each IEEE 802.11 interface is represented by an ifEntry. Interface tables
in this MIB module are indexed by ifIndex."
INDEX { ifIndex, dot11SupportedMCSRxIndex }
::= { dot11SupportedMCSRxTable 1 }
3155
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Dot11SupportedMCSRxEntry ::=
SEQUENCE {
dot11SupportedMCSRxIndex Unsigned32,
dot11SupportedMCSRxValue Unsigned32 }
dot11SupportedMCSRxIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index object that identifies which MCS to access. Range is 1..255."
::= { dot11SupportedMCSRxEntry 1 }
dot11SupportedMCSRxValue OBJECT-TYPE
SYNTAX Unsigned32 (1..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
The receive MCS supported by the PHY, represented by a count from 1 to
127, subject to limitations of each individual PHY."
::= { dot11SupportedMCSRxEntry 2 }
-- **********************************************************************
-- * End of dot11 Supported MCS Rx TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11 Transmit Beamforming Config TABLE
-- **********************************************************************
dot11TransmitBeamformingConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11TransmitBeamformingConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11TransmitBeamformingConfigTable. Implemented
as a table indexed on ifIndex to allow for multiple instances on an
Agent."
::= { dot11phy 18 }
dot11TransmitBeamformingConfigEntry OBJECT-TYPE
SYNTAX Dot11TransmitBeamformingConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11TransmitBeamformingConfig Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX {ifIndex}
::= { dot11TransmitBeamformingConfigTable 1 }
Dot11TransmitBeamformingConfigEntry ::=
SEQUENCE {
dot11ReceiveStaggerSoundingOptionImplemented TruthValue,
dot11TransmitStaggerSoundingOptionImplemented TruthValue,
dot11ReceiveNDPOptionImplemented TruthValue,
dot11TransmitNDPOptionImplemented TruthValue,
dot11ImplicitTransmitBeamformingOptionImplemented TruthValue,
dot11CalibrationOptionImplemented INTEGER,
dot11ExplicitCSITransmitBeamformingOptionImplemented TruthValue,
dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented
3156
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TruthValue,
dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented
INTEGER,
dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented
INTEGER,
dot11ExplicitCompressedBeamformingFeedbackOptionImplemented
INTEGER,
dot11NumberBeamFormingCSISupportAntenna Unsigned32,
dot11NumberNonCompressedBeamformingMatrixSupportAntenna
Unsigned32,
dot11NumberCompressedBeamformingMatrixSupportAntenna Unsigned32 }
dot11ReceiveStaggerSoundingOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA implementation supports
the receiving of staggered sounding frames."
DEFVAL { false }
::= { dot11TransmitBeamformingConfigEntry 1 }
dot11TransmitStaggerSoundingOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA implementation supports
the transmission of staggered sounding frames."
DEFVAL { false }
::= { dot11TransmitBeamformingConfigEntry 2 }
dot11ReceiveNDPOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA implementation is
capable of receiving NDP as sounding frames."
DEFVAL { false }
::= { dot11TransmitBeamformingConfigEntry 3 }
dot11TransmitNDPOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA implementation is
capable of transmitting NDP as sounding frames."
DEFVAL { false }
::= { dot11TransmitBeamformingConfigEntry 4 }
3157
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11ImplicitTransmitBeamformingOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that STA implementation is capable of
applying implicit transmit beamforming."
DEFVAL { false }
::= { dot11TransmitBeamformingConfigEntry 5 }
dot11CalibrationOptionImplemented OBJECT-TYPE
SYNTAX INTEGER {
inCapable (0),
unableToInitiate (1),
ableToInitiate (2),
fullyCapable (3) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the level of calibration supported by the STA
implementation."
DEFVAL { inCapable }
::= { dot11TransmitBeamformingConfigEntry 6 }
dot11ExplicitCSITransmitBeamformingOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that STA implementation is capable of
applying transmit beamforming using CSI explicit feedback in its
transmission."
DEFVAL { false }
::= { dot11TransmitBeamformingConfigEntry 7 }
dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that STA implementation is capable of
applying transmit beamforming using noncompressed beamforming feedback
matrix explicit feedback in its transmission."
DEFVAL { false }
::= { dot11TransmitBeamformingConfigEntry 8 }
dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented OBJECT-TYPE
SYNTAX INTEGER {
inCapable (0),
delayed (1),
immediate (2),
unsolicitedImmediate (3),
3158
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
aggregated (4),
delayedAggregated (5),
immediateAggregated(6),
unsolicitedImmediateAggregated (7) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the level of CSI explicit feedback returned by
the STA implementation."
DEFVAL { inCapable }
::= { dot11TransmitBeamformingConfigEntry 9 }
dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented OBJECT-TYPE
SYNTAX INTEGER {
inCapable (0),
delayed (1),
immediate (2),
unsolicitedImmediate (3),
aggregated (4),
delayedAggregated (5),
immediateAggregated(6),
unsolicitedImmediateAggregated (7) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the level of noncompressed beamforming feedback
matrix explicit feedback returned by the STA implementation."
DEFVAL { inCapable }
::= { dot11TransmitBeamformingConfigEntry 10 }
dot11ExplicitCompressedBeamformingFeedbackOptionImplemented OBJECT-TYPE
SYNTAX INTEGER {
inCapable (0),
delayed (1),
immediate (2),
unsolicitedImmediate (3),
aggregated (4),
delayedAggregated (5),
immediateAggregated(6),
unsolicitedImmediateAggregated (7) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the level of noncompressed beamforming feedback
matrix explicit feedback returned by the STA implementation."
DEFVAL { inCapable }
::= { dot11TransmitBeamformingConfigEntry 11 }
dot11NumberBeamFormingCSISupportAntenna OBJECT-TYPE
SYNTAX Unsigned32 (1..4)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3159
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the maximum number of beamforming antennas the
beamformee can support when CSI feedback is required."
::= { dot11TransmitBeamformingConfigEntry 12 }
dot11NumberNonCompressedBeamformingMatrixSupportAntenna OBJECT-TYPE
SYNTAX Unsigned32 (1..4)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of beamforming antennas the
beamformee can support when noncompressed beamforming feedback matrix
feedback is required."
::= { dot11TransmitBeamformingConfigEntry 13 }
dot11NumberCompressedBeamformingMatrixSupportAntenna OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of beamforming antennas the
beamformee can support when compressed beamforming feedback matrix
feedback is required."
::= { dot11TransmitBeamformingConfigEntry 14 }
-- **********************************************************************
-- * End of dot11 Transmit Beamforming Config TABLE
-- **********************************************************************
-- *******************************************************************
-- * dot11 Phy DMG TABLE
-- *******************************************************************
dot11PHYDMGTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PHYDMGEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11PhyDMGTable. Implemented as a table indexed
on ifIndex to allow for multiple instances on an Agent."
::= { dot11phy 19 }
dot11PHYDMGEntry OBJECT-TYPE
SYNTAX Dot11PHYDMGEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in dot11PHYDMGTable. ifIndex - Each IEEE 802.11 interface is
represented by an ifEntry. Interface tables in this MIB module are indexed
by ifIndex."
INDEX {ifIndex}
::= { dot11PHYDMGTable 1 }
Dot11PHYDMGEntry ::=
SEQUENCE {
dot11LowPowerSCPHYImplemented TruthValue,
dot11LowPowerSCPHYActivated TruthValue }
3160
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11LowPowerSCPHYImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the low power SC mode is imple-
mented."
DEFVAL { false }
::= { dot11PHYDMGEntry 1 }
dot11LowPowerSCPHYActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute, when true, indicates that the low power SC mode is
activated."
DEFVAL { false }
::= { dot11PHYDMGEntry 2 }
-- *******************************************************************
-- * End of dot11 PHY DMG TABLE
-- *******************************************************************
-- *******************************************************************
-- * dot11DMGBeamformingConfig TABLE
-- *******************************************************************
dot11DMGBeamformingConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11DMGBeamformingConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a Table management object.
The dot11DMGBeamformingConfig Table"
::= { dot11phy 22 }
dot11DMGBeamformingConfigEntry OBJECT-TYPE
SYNTAX Dot11DMGBeamformingConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an entry in the dot11DMGBeamformingConfigTable Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX { ifIndex }
::= { dot11DMGBeamformingConfigTable 1 }
Dot11DMGBeamformingConfigEntry ::=
SEQUENCE {
dot11MaxBFTime Unsigned32,
dot11BFTXSSTime Unsigned32,
dot11MaximalSectorScan Unsigned32,
dot11ABFTRTXSSSwitch Unsigned32,
dot11RSSRetryLimit Unsigned32,
dot11RSSBackoff Unsigned32,
dot11BFRetryLimit Unsigned32,
3161
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11BeamLinkMaintenanceTime Unsigned32,
dot11AntennaSwitchingTime Unsigned32,
dot11ChanMeasFBCKNtaps Unsigned32,
dot11BeamTrackingTimeLimit Unsigned32
}
dot11MaxBFTime OBJECT-TYPE
SYNTAX Unsigned32 (1..16)
UNITS "beacon intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Maximum Beamforming Time."
DEFVAL { 4 }
::= { dot11DMGBeamformingConfigEntry 1 }
dot11BFTXSSTime OBJECT-TYPE
SYNTAX Unsigned32 (1..256)
UNITS "milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Timeout until the initiator restarts ISS."
DEFVAL { 100 }
::= { dot11DMGBeamformingConfigEntry 2 }
dot11MaximalSectorScan OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
UNITS "beacon intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Maximal Sector Scan."
DEFVAL { 8 }
::= { dot11DMGBeamformingConfigEntry 3 }
dot11ABFTRTXSSSwitch OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
UNITS "beacon intervals"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
A-BFT Transmit Sector Sweep Switch."
DEFVAL { 4 }
::= { dot11DMGBeamformingConfigEntry 4 }
dot11RSSRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
3162
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Responder Sector Sweep Retry Limit"
DEFVAL { 8 }
::= { dot11DMGBeamformingConfigEntry 5 }
dot11RSSBackoff OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Responder Sector Sweep Backoff"
DEFVAL { 8 }
::= { dot11DMGBeamformingConfigEntry 6 }
dot11BFRetryLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME or an external management entity.
Changes take effect as soon as practical in the implementation.
Beamforming Retry Limit"
DEFVAL { 8 }
::= { dot11DMGBeamformingConfigEntry 7 }
dot11BeamLinkMaintenanceTime OBJECT-TYPE
SYNTAX Unsigned32 (0..64000000)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the MAC or SME.
Changes take effect as soon as practical in the implementation.
Beam Link Maintenance Time
dot11BeamLinkMaintenanceTime = BeamLink_Maintenance_Unit *
BeamLink_Maintenance_Value. Otherwise, the dot11BeamLinkMaintenanceTime
is left undefined. An
undefined value of the dot11BeamLinkMaintenanceTime indicates
that the STA does not participate in beamformed link maintenance."
DEFVAL { 0 }
::= { dot11DMGBeamformingConfigEntry 8 }
dot11AntennaSwitchingTime OBJECT-TYPE
SYNTAX Unsigned32 (0..64000000)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable. It is written by the MAC or SME.
Changes take effect as soon as practical in the implementation."
3163
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { 0 }
::= { dot11DMGBeamformingConfigEntry 9 }
dot11ChanMeasFBCKNtaps OBJECT-TYPE
SYNTAX Unsigned32 (0..64000000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable. It is written by the MAC or SME.
Changes take effect as soon as practical in the implementation.
Number of channel measurement taps."
DEFVAL { 0 }
::= { dot11DMGBeamformingConfigEntry 10 }
dot11BeamTrackingTimeLimit OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "microseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the MAC or SME.
Changes take effect as soon as practical in the implementation.
BRP tracking initiator time limit."
DEFVAL { 10000 }
::= { dot11DMGBeamformingConfigEntry 11 }
-- *******************************************************************
-- * End of dot11DMGBeamformingConfig TABLE
-- *******************************************************************
-- **********************************************************************
-- * dot11 Phy VHT TABLE
-- **********************************************************************
dot11PhyVHTTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyVHTEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11PhyVHTTable. Implemented as a table indexed
on ifIndex to allow for multiple instances on an Agent."
::= { dot11phy 23 }
dot11PhyVHTEntry OBJECT-TYPE
SYNTAX Dot11PhyVHTEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyHTEntry Table. ifIndex - Each IEEE 802.11
interface is represented by an ifEntry. Interface tables in this MIB
module are indexed by ifIndex."
INDEX {ifIndex}
::= { dot11PhyVHTTable 1 }
Dot11PhyVHTEntry ::=
SEQUENCE {
dot11VHTChannelWidthOptionImplemented INTEGER,
dot11CurrentChannelWidth INTEGER,
dot11CurrentChannelCenterFrequencyIndex0 Unsigned32,
dot11CurrentChannelCenterFrequencyIndex1 Unsigned32,
dot11VHTShortGIOptionIn80Implemented TruthValue,
dot11VHTShortGIOptionIn80Activated TruthValue,
3164
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11VHTShortGIOptionIn160and80p80Implemented TruthValue,
dot11VHTShortGIOptionIn160and80p80Activated TruthValue,
dot11VHTLDPCCodingOptionImplemented TruthValue,
dot11VHTLDPCCodingOptionActivated TruthValue,
dot11VHTTxSTBCOptionImplemented TruthValue,
dot11VHTTxSTBCOptionActivated TruthValue,
dot11VHTRxSTBCOptionImplemented TruthValue,
dot11VHTRxSTBCOptionActivated TruthValue,
dot11VHTMUMaxUsersImplemented Unsigned32,
dot11VHTMUMaxNSTSPerUserImplemented Unsigned32,
dot11VHTMUMaxNSTSTotalImplemented Unsigned32,
dot11VHTMaxNTxChainsImplemented Unsigned32,
dot11VHTMaxNTxChainsActivated Unsigned32
}
dot11VHTChannelWidthOptionImplemented OBJECT-TYPE
SYNTAX INTEGER { contiguous80(0), contiguous160(1), noncontiguous80plus80(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the channel widths supported: 20/40/80 MHz, 20/
40/80/160 MHz or 20/40/80/160/80+80 MHz."
DEFVAL { contiguous80 }
::= { dot11PhyVHTEntry 1 }
dot11CurrentChannelWidth OBJECT-TYPE
SYNTAX INTEGER { cbw20(0), cbw40(1), cbw80(2), cbw160(3), cbw80p80(4) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
This attribute indicates the operating channel width."
DEFVAL { cbw20 }
::= { dot11PhyVHTEntry 2 }
dot11CurrentChannelCenterFrequencyIndex0 OBJECT-TYPE
SYNTAX Unsigned32 (0..200)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
For a 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel, denotes the channel
center frequency.
For an 80+80 MHz channel, denotes the center frequency of frequency
segment 0. See 21.3.14."
DEFVAL { 0 }
::= { dot11PhyVHTEntry 3 }
dot11CurrentChannelCenterFrequencyIndex1 OBJECT-TYPE
SYNTAX Unsigned32 (0..200)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
For an 80+80 MHz channel, denotes the center frequency of frequency
segment 1.
Set to 0 for a 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel. See 21.3.14."
3165
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL { 0 }
::= { dot11PhyVHTEntry 4 }
dot11VHTShortGIOptionIn80Implemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the device is capable of
receiving 80 MHz short guard interval packets."
DEFVAL { false }
::= { dot11PhyVHTEntry 5 }
dot11VHTShortGIOptionIn80Activated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the reception of 80 MHz short
guard interval packets is enabled."
DEFVAL { false }
::= { dot11PhyVHTEntry 6 }
dot11VHTShortGIOptionIn160and80p80Implemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the device is capable of
receiving 160 MHz and 80+80 MHz short guard interval packets."
DEFVAL { false }
::= { dot11PhyVHTEntry 7 }
dot11VHTShortGIOptionIn160and80p80Activated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the reception of 160 MHz and
80+80 MHz short guard interval packets is enabled."
DEFVAL { false }
::= { dot11PhyVHTEntry 8 }
dot11VHTLDPCCodingOptionImplemented OBJECT-TYPE
3166
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the LDPC coding option for VHT
packets is implemented."
DEFVAL { false }
::= { dot11PhyVHTEntry 9 }
dot11VHTLDPCCodingOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the LDPC coding option for VHT
packets is enabled."
DEFVAL { false }
::= { dot11PhyVHTEntry 10 }
dot11VHTTxSTBCOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the device is capable of
transmitting VHT PPDUs using STBC."
DEFVAL { false }
::= { dot11PhyVHTEntry 11 }
dot11VHTTxSTBCOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the entity's capability for
transmitting VHT PPDUs using STBC is enabled."
DEFVAL { false }
::= { dot11PhyVHTEntry 12 }
dot11VHTRxSTBCOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
3167
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the device is capable of
receiving VHT PPDUs using STBC."
DEFVAL { false }
::= { dot11PhyVHTEntry 13 }
dot11VHTRxSTBCOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the entity's capability for
receiving VHT PPDUs using STBC is enabled."
DEFVAL { false }
::= { dot11PhyVHTEntry 14 }
dot11VHTMUMaxUsersImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of users to which this device
is capable of transmitting within a VHT MU PPDU."
DEFVAL { 1 }
::= { dot11PhyVHTEntry 15 }
dot11VHTMUMaxNSTSPerUserImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of space-time streams per user
that this device is capable of transmitting within a VHT MU PPDU."
DEFVAL { 1 }
::= { dot11PhyVHTEntry 16 }
dot11VHTMUMaxNSTSTotalImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of space-time streams for all
users that this device is capable of transmitting within a VHT MU PPDU."
DEFVAL { 1 }
::= { dot11PhyVHTEntry 17 }
3168
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11VHTMaxNTxChainsImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of transmit chains within this
device."
DEFVAL { 1 }
::= { dot11PhyVHTEntry 18 }
dot11VHTMaxNTxChainsActivated OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum number of transmit chains that are
activated within this device, unless this attribute exceeds
dot11VHTMaxNTxChainsImplemented, in which case the maximum number of
transmit chains that are activated within this device is equal to
dot11VHTMaxNTxChainsImplemented."
DEFVAL { 2147483647}
::= { dot11PhyVHTEntry 19 }
-- **********************************************************************
-- * End of dot11PhyVHT TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11 VHT Transmit Beamforming Config TABLE
-- **********************************************************************
dot11VHTTransmitBeamformingConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11VHTTransmitBeamformingConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11VHTTransmitBeamformingConfigTable.
Implemented as a table indexed on ifIndex to allow for multiple instances
on an Agent."
::= { dot11phy 24 }
dot11VHTTransmitBeamformingConfigEntry OBJECT-TYPE
SYNTAX Dot11VHTTransmitBeamformingConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11VHTTransmitBeamformingConfig Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX {ifIndex}
::= { dot11VHTTransmitBeamformingConfigTable 1 }
Dot11VHTTransmitBeamformingConfigEntry ::=
SEQUENCE {
dot11VHTSUBeamformeeOptionImplemented TruthValue,
dot11VHTSUBeamformerOptionImplemented TruthValue,
dot11VHTMUBeamformeeOptionImplemented TruthValue,
3169
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11VHTMUBeamformerOptionImplemented TruthValue,
dot11VHTNumberSoundingDimensions Unsigned32,
dot11VHTBeamformeeNTxSupport Unsigned32
}
dot11VHTSUBeamformeeOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the SU
Beamformee role."
DEFVAL { false }
::= { dot11VHTTransmitBeamformingConfigEntry 1 }
dot11VHTSUBeamformerOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the SU
Beamformer role."
DEFVAL { false }
::= { dot11VHTTransmitBeamformingConfigEntry 2 }
dot11VHTMUBeamformeeOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the MU
Beamformee role."
DEFVAL { false }
::= { dot11VHTTransmitBeamformingConfigEntry 3 }
dot11VHTMUBeamformerOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the MU
Beamformer role."
DEFVAL { false }
::= { dot11VHTTransmitBeamformingConfigEntry 4 }
dot11VHTNumberSoundingDimensions OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3170
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute indicates the number of antennas used by the beamformer
when sending beamformed transmissions."
::= { dot11VHTTransmitBeamformingConfigEntry 5 }
dot11VHTBeamformeeNTxSupport OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of space-time streams that the
STA can receive in a VHT NDP, the maximum value for NSTS, total that can
be sent to the STA in a VHT MU PPDU if the STA is MU beamformee capable and
the maximum value of Nr that the STA transmits in a VHT Compressed
Beamforming frame."
::= { dot11VHTTransmitBeamformingConfigEntry 6 }
-- **********************************************************************
-- * End of dot11 VHT Transmit Beamforming Config TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11 Phy TVHT TABLE
-- **********************************************************************
dot11PhyTVHTTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11PhyTVHTEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11PhyTVHTTable. Implemented as a table indexed
on ifIndex to allow for multiple instances on an Agent."
::= { dot11phy 25 }
dot11PhyTVHTEntry OBJECT-TYPE
SYNTAX Dot11PhyTVHTEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11PhyTVHTEntry Table. ifIndex - Each IEEE 802.11
interface is represented by an ifEntry. Interface tables in this MIB
module are indexed by ifIndex."
INDEX {ifIndex}
::= { dot11PhyTVHTTable 1 }
Dot11PhyTVHTEntry ::=
SEQUENCE {
dot11TVHTChannelWidthOptionImplemented INTEGER,
dot11TVHTCurrentChannelWidth INTEGER,
dot11TVHTCurrentChannelCenterFrequencyIndex0 Unsigned32,
dot11TVHTCurrentChannelCenterFrequencyIndex1 Unsigned32,
dot11TVHTShortGIOptionIn4WImplemented TruthValue,
dot11TVHTShortGIOptionIn4WActivated TruthValue,
dot11TVHTLDPCCodingOptionImplemented TruthValue,
dot11TVHTLDPCCodingOptionActivated TruthValue,
dot11TVHTTxSTBCOptionImplemented TruthValue,
dot11TVHTTxSTBCOptionActivated TruthValue,
dot11TVHTRxSTBCOptionImplemented TruthValue,
dot11TVHTRxSTBCOptionActivated TruthValue,
dot11TVHTMUMaxUsersImplemented Unsigned32,
dot11TVHTMUMaxNSTSPerUserImplemented Unsigned32,
3171
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TVHTMUMaxNSTSTotalImplemented Unsigned32,
dot11TVHTMaxNTxChainsImplemented Unsigned32,
dot11TVHTMaxNTxChainsActivated Unsigned32
}
dot11TVHTChannelWidthOptionImplemented OBJECT-TYPE
SYNTAX INTEGER { tvhtmode1(0), tvhtmode2c(1), tvhtmode2n(2),
tvhtmode4c(3), tvhtmode4n(4) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the channel widths supported: W MHz, 2W MHz, W+W
MHz, 4W MHz or 2W+2W MHz."
DEFVAL { tvhtmode1 }
::= { dot11PhyTVHTEntry 1 }
dot11TVHTCurrentChannelWidth OBJECT-TYPE
SYNTAX INTEGER { tvhtw(0), tvht2w(1), tvhtwpw(2), tvht4w(3), tvht2wp2w(4) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
This attribute indicates the operating channel width."
DEFVAL { tvhtw }
::= { dot11PhyTVHTEntry 2 }
dot11TVHTCurrentChannelCenterFrequencyIndex0 OBJECT-TYPE
SYNTAX Unsigned32 (0..200)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
For a W MHz, 2W MHz or 4W MHz channel, denotes the channel center
frequency.
For an W+W or 2W+2W MHz channel, denotes the center frequency of frequency
segment 0. See 22.3.14."
DEFVAL { 0 }
::= { dot11PhyTVHTEntry 3 }
dot11TVHTCurrentChannelCenterFrequencyIndex1 OBJECT-TYPE
SYNTAX Unsigned32 (0..200)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
For an W+W or 2W+2W MHz channel, denotes the center frequency of frequency
segment 1.
Set to 0 for a W MHz, 2W MHz or 4W MHz channel. See 22.3.14."
DEFVAL { 0 }
::= { dot11PhyTVHTEntry 4 }
dot11TVHTShortGIOptionIn4WImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
3172
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute, when true, indicates that the device is capable of
receiving 4W MHz short guard interval packets."
DEFVAL { false }
::= { dot11PhyTVHTEntry 5 }
dot11TVHTShortGIOptionIn4WActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the reception of 4W MHz short
guard interval packets is enabled."
DEFVAL { false }
::= { dot11PhyTVHTEntry 6 }
dot11TVHTLDPCCodingOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the LDPC coding option for TVHT
packets is implemented."
DEFVAL { false }
::= { dot11PhyTVHTEntry 7 }
dot11TVHTLDPCCodingOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the LDPC coding option for TVHT
packets is enabled."
DEFVAL { false }
::= { dot11PhyTVHTEntry 8 }
dot11TVHTTxSTBCOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the device is capable of
transmitting TVHT PPDUs using STBC."
DEFVAL { false }
3173
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11PhyTVHTEntry 9 }
dot11TVHTTxSTBCOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the entity's capability for
transmitting TVHT PPDUs using STBC is enabled."
DEFVAL { false }
::= { dot11PhyTVHTEntry 10 }
dot11TVHTRxSTBCOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the device is capable of
receiving TVHT PPDUs using STBC."
DEFVAL { false }
::= { dot11PhyTVHTEntry 11 }
dot11TVHTRxSTBCOptionActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation. Changes
made while associated with an AP or while operating a BSS should take
effect only after disassociation or the deactivation of the BSS,
respectively.
This attribute, when true, indicates that the entity's capability for
receiving TVHT PPDUs using STBC is enabled."
DEFVAL { false }
::= { dot11PhyTVHTEntry 12 }
dot11TVHTMUMaxUsersImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of users to which this device
is capable of transmitting within a TVHT MU PPDU."
DEFVAL { 1 }
::= { dot11PhyTVHTEntry 13 }
dot11TVHTMUMaxNSTSPerUserImplemented OBJECT-TYPE
SYNTAX Unsigned32
3174
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of space-time streams per user
that this device is capable of transmitting within a TVHT MU PPDU."
DEFVAL { 1 }
::= { dot11PhyTVHTEntry 14 }
dot11TVHTMUMaxNSTSTotalImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of space-time streams for all
users that this device is capable of transmitting within a TVHT MU PPDU."
DEFVAL { 1 }
::= { dot11PhyTVHTEntry 15 }
dot11TVHTMaxNTxChainsImplemented OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of transmit chains within this
device."
DEFVAL { 1 }
::= { dot11PhyTVHTEntry 16 }
dot11TVHTMaxNTxChainsActivated OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum number of transmit chains that are
activated within this device, unless this attribute exceeds
dot11TVHTMaxNTxChainsImplemented, in which case the maximum number of
transmit chains that are activated within this device is equal to
dot11TVHTMaxNTxChainsImplemented."
DEFVAL { 2147483647 }
::= { dot11PhyTVHTEntry 17 }
-- **********************************************************************
-- * End of dot11PhyTVHT TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11 TVHT Transmit Beamforming Config TABLE
-- **********************************************************************
dot11TVHTTransmitBeamformingConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11TVHTTransmitBeamformingConfigEntry
3175
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of attributes for dot11TVHTTransmitBeamformingConfigTable.
Implemented as a table indexed on ifIndex to allow for multiple instances
on an Agent."
::= { dot11phy 26 }
dot11TVHTTransmitBeamformingConfigEntry OBJECT-TYPE
SYNTAX Dot11TVHTTransmitBeamformingConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot11TVHTTransmitBeamformingConfig Table.
ifIndex - Each IEEE 802.11 interface is represented by an ifEntry.
Interface tables in this MIB module are indexed by ifIndex."
INDEX {ifIndex}
::= { dot11TVHTTransmitBeamformingConfigTable 1 }
Dot11TVHTTransmitBeamformingConfigEntry ::=
SEQUENCE {
dot11TVHTSUBeamformeeOptionImplemented TruthValue,
dot11TVHTSUBeamformerOptionImplemented TruthValue,
dot11TVHTMUBeamformeeOptionImplemented TruthValue,
dot11TVHTMUBeamformerOptionImplemented TruthValue,
dot11TVHTNumberSoundingDimensions Unsigned32,
dot11TVHTBeamformeeNTxSupport Unsigned32
}
dot11TVHTSUBeamformeeOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the SU
Beamformee role."
DEFVAL { false }
::= { dot11TVHTTransmitBeamformingConfigEntry 1 }
dot11TVHTSUBeamformerOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the SU
Beamformer role."
DEFVAL { false }
::= { dot11TVHTTransmitBeamformingConfigEntry 2 }
dot11TVHTMUBeamformeeOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the MU
3176
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Beamformee role."
DEFVAL { false }
::= { dot11TVHTTransmitBeamformingConfigEntry 3 }
dot11TVHTMUBeamformerOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the STA supports the MU
Beamformer role."
DEFVAL { false }
::= { dot11TVHTTransmitBeamformingConfigEntry 4 }
dot11TVHTNumberSoundingDimensions OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the number of antennas used by the beamformer
when sending beamformed transmissions."
::= { dot11TVHTTransmitBeamformingConfigEntry 5 }
dot11TVHTBeamformeeNTxSupport OBJECT-TYPE
SYNTAX Unsigned32 (1..8)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute indicates the maximum number of space-time streams that the
STA can receive in a TVHT NDP, the maximum value for NSTS, total that can
be sent to the STA in a TVHT MU PPDU if the STA is MU beamformee capable
and the maximum value of Nr that the STA transmits in a TVHT Compressed
Beamforming frame."
::= { dot11TVHTTransmitBeamformingConfigEntry 6 }
-- **********************************************************************
-- * End of dot11 TVHT Transmit Beamforming Config TABLE
-- **********************************************************************
-- Interworking Management (IMT) Attributes
-- DEFINED AS "The Interworking management object class provides
-- the necessary support for an SSPN Interface function to manage
-- interworking with external systems. IMT objects are conceptual
-- objects for Interworking Service and are defined only for the
-- AP."
dot11imt OBJECT IDENTIFIER ::= {ieee802dot11 6}
-- IMT GROUPS
-- dot11BSSIdTable ::= { dot11imt 1 }
-- dot11InterworkingTable ::= { dot11imt 2 }
-- dot11APLCITable ::= { dot11imt 3 }
-- dot11APCivicLocationTable ::= { dot11imt 4 }
-- dot11RoamingConsortiumTable ::= { dot11imt 5 }
-- dot11DomainNameTable ::= { dot11imt 6 }
3177
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- Generic Advertisement Service (GAS) Attributes
-- DEFINED AS "The Generic Advertisement Service management
-- object class provides the necessary support for an Advertisement
-- service to interwork with external systems."
-- GAS GROUPS
-- dot11GASAdvertisementTable ::= { dot11imt 7 }
--**********************************************************************
-- * dot11BSSId TABLE
--**********************************************************************
dot11BSSIdTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11BSSIdEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object is a table of BSSIDs contained within an Access Point (AP)."
::= { dot11imt 1 }
dot11BSSIdEntry OBJECT-TYPE
SYNTAX Dot11BSSIdEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object provides the attributes identifying a particular BSSID within
an AP."
INDEX { dot11APMacAddress }
::= { dot11BSSIdTable 1 }
Dot11BSSIdEntry ::=
SEQUENCE{
dot11APMacAddress MacAddress
}
dot11APMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
Changes take effect for the next MLME-START.request primitive.
This object specifies the MAC address of the BSSID represented on a
particular BSSID interface and uniquely identifies this entry."
::= { dot11BSSIdEntry 1 }
--**********************************************************************
-- * End of dot11BSSId TABLE
--**********************************************************************
--**********************************************************************
-- * dot11Interworking TABLE
--**********************************************************************
dot11InterworkingTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11InterworkingEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table represents the non-AP STAs associated to the AP. An entry is
created automatically by the AP when the STA becomes associated to the AP.
The corresponding entry is deleted when the STA disassociates. Each STA
added to this table is uniquely identified by its MAC address. This table
3178
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
is moved to a new AP following a successful STA BSS transition event."
::= { dot11imt 2 }
dot11InterworkingEntry OBJECT-TYPE
SYNTAX Dot11InterworkingEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry represents a conceptual row in the dot11InterworkingTable and
provides information about permissions received from an SSPN Interface. If
a non-AP STA does not receive permissions for one or more of these
objects, then the object's default values or AP's locally defined
configuration may be used instead. If the AP's local policy(s) is more
restrictive than an object's value received from the SSPN Interface, then
the AP's local policy shall be enforced. An entry is identified by the
AP's MAC address to which the STA is associated and the STA's MAC
address."
INDEX { dot11APMacAddress, dot11NonAPStationMacAddress }
::= { dot11InterworkingTable 1 }
Dot11InterworkingEntry ::=
SEQUENCE {
dot11NonAPStationMacAddress MacAddress,
dot11NonAPStationUserIdentity DisplayString,
dot11NonAPStationInterworkingCapability BITS,
dot11NonAPStationAssociatedSSID OCTET STRING,
dot11NonAPStationUnicastCipherSuite OCTET STRING,
dot11NonAPStationBroadcastCipherSuite OCTET STRING,
dot11NonAPStationAuthAccessCategories BITS,
dot11NonAPStationAuthMaxVoiceRate Unsigned32,
dot11NonAPStationAuthMaxVideoRate Unsigned32,
dot11NonAPStationAuthMaxBestEffortRate Unsigned32,
dot11NonAPStationAuthMaxBackgroundRate Unsigned32,
dot11NonAPStationAuthMaxVoiceOctets Unsigned32,
dot11NonAPStationAuthMaxVideoOctets Unsigned32,
dot11NonAPStationAuthMaxBestEffortOctets Unsigned32,
dot11NonAPStationAuthMaxBackgroundOctets Unsigned32,
dot11NonAPStationAuthMaxHCCAHEMMOctets Unsigned32,
dot11NonAPStationAuthMaxTotalOctets Unsigned32,
dot11NonAPStationAuthHCCAHEMM TruthValue,
dot11NonAPStationAuthMaxHCCAHEMMRate Unsigned32,
dot11NonAPStationAuthHCCAHEMMDelay Unsigned32,
dot11NonAPStationAuthSourceMulticast TruthValue,
dot11NonAPStationAuthMaxSourceMulticastRate Unsigned32,
dot11NonAPStationVoiceMSDUCount Counter32,
dot11NonAPStationDroppedVoiceMSDUCount Counter32,
dot11NonAPStationVoiceOctetCount Counter32,
dot11NonAPStationDroppedVoiceOctetCount Counter32,
dot11NonAPStationVideoMSDUCount Counter32,
dot11NonAPStationDroppedVideoMSDUCount Counter32,
dot11NonAPStationVideoOctetCount Counter32,
dot11NonAPStationDroppedVideoOctetCount Counter32,
dot11NonAPStationBestEffortMSDUCount Counter32,
dot11NonAPStationDroppedBestEffortMSDUCount Counter32,
dot11NonAPStationBestEffortOctetCount Counter32,
dot11NonAPStationDroppedBestEffortOctetCount Counter32,
dot11NonAPStationBackgroundMSDUCount Counter32,
dot11NonAPStationDroppedBackgroundMSDUCount Counter32,
dot11NonAPStationBackgroundOctetCount Counter32,
dot11NonAPStationDroppedBackgroundOctetCount Counter32,
dot11NonAPStationHCCAHEMMMSDUCount Counter32,
dot11NonAPStationDroppedHCCAHEMMMSDUCount Counter32,
dot11NonAPStationHCCAHEMMOctetCount Counter32,
dot11NonAPStationDroppedHCCAHEMMOctetCount Counter32,
3179
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11NonAPStationMulticastMSDUCount Counter32,
dot11NonAPStationDroppedMulticastMSDUCount Counter32,
dot11NonAPStationMulticastOctetCount Counter32,
dot11NonAPStationDroppedMulticastOctetCount Counter32,
dot11NonAPStationPowerManagementMode INTEGER,
dot11NonAPStationAuthDls TruthValue,
dot11NonAPStationVLANId Unsigned32,
dot11NonAPStationVLANName DisplayString,
dot11NonAPStationAddtsResultCode INTEGER}
dot11NonAPStationMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after a non-AP STA associates to the BSS.
This object specifies the MAC address of the non-AP STA for this entry and
uniquely identifies this entry."
::= { dot11InterworkingEntry 1 }
dot11NonAPStationUserIdentity OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after a non-AP STA associates to the BSS.
This attribute reflects the user identity for the subscriber operating
this non-AP STA"
::= { dot11InterworkingEntry 2 }
dot11NonAPStationInterworkingCapability OBJECT-TYPE
SYNTAX BITS {
interworkingCapability(0),
qosMapCapability(1),
expeditedBwReqCapability(2),
msgcfCapability(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after a non-AP STA associates to the BSS.
This attribute defines the Interworking capabilities possessed by a non-AP
STA. Interworking Capability is set to 1 when the STA includes the
Interworking element in its (re)association request. The QosMapCapability,
ExpeditedBwReqCapability and MSGCFCapability bits reflect the same values
and meanings as those defined in 9.4.2.27"
::= { dot11InterworkingEntry 3 }
dot11NonAPStationAssociatedSSID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
3180
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME after a non-AP STA associates to the BSS.
This attribute reflects the SSID to which the non-AP STA is associated"
::= { dot11InterworkingEntry 4 }
dot11NonAPStationUnicastCipherSuite OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after a non-AP STA authenticates with the BSS.
The selector of the AKM cipher suite that is currently in use by the non-
AP STA. It consists of an OUI or CID (the first 3 octets) and a cipher
suite identifier (the last octet)."
::= { dot11InterworkingEntry 5 }
dot11NonAPStationBroadcastCipherSuite OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after a non-AP STA authenticates with the BSS.
The selector of an AKM suite for broadcast and group addressed frame
transmissions. It consists of an OUI or CID (the first 3 octets) and a
cipher suite identifier the last octet)."
::= { dot11InterworkingEntry 6 }
dot11NonAPStationAuthAccessCategories OBJECT-TYPE
SYNTAX BITS {
bestEffort(0),
background(1),
video(2),
voice(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
The object that represents the access categories which the non-AP STA is
permitted to use when admission control is configured on that AC. An AC is
permitted to be used if its corresponding bit is set to 1; otherwise it is
not permitted to be used."
DEFVAL { { bestEffort, background, video, voice } }
::= { dot11InterworkingEntry 7 }
dot11NonAPStationAuthMaxVoiceRate OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "kb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
3181
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized data rate the non-AP STA
may use, either transmitting to an AP or receiving from an AP on the voice
access category. If this rate is exceeded, the AP should police the flows
traversing this AC. The value '4294967295', which is the default value,
means that the SSP is not requesting the AP to limit the data rate used by
the non-AP STA. Local configuration of the AP, however, may cause the rate
to be limited, especially when the AC is configured for mandatory
admission control."
DEFVAL {4294967295}
::= { dot11InterworkingEntry 8 }
dot11NonAPStationAuthMaxVideoRate OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "kb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized data rate the non-AP STA
may use, either transmitting to an AP or receiving from an AP on the video
access category. If this rate is exceeded, the AP should police the flows
traversing this AC. The value '4294967295', which is the default value,
means that the SSP is not requesting the AP to limit the data rate used by
the non-AP STA. Local configuration of the AP, however, may cause the rate
to be limited, especially when the AC is configured for mandatory
admission control."
DEFVAL {4294967295}
::= { dot11InterworkingEntry 9 }
dot11NonAPStationAuthMaxBestEffortRate OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "kb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized data rate the non-AP STA
may use, either transmitting to an AP or receiving from an AP on the best
effort access category. If this rate is exceeded, the AP should police the
flows traversing this AC. The value '4294967295', which is the default
value, means that the SSP is not requesting the AP to limit the data rate
used by the non-AP STA. Local configuration of the AP, however, may cause
the rate to be limited, especially when the AC is configured for mandatory
admission control."
DEFVAL {4294967295}
::= { dot11InterworkingEntry 10 }
dot11NonAPStationAuthMaxBackgroundRate OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "kb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
3182
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized data rate the non-AP STA
may use, either transmitting to an AP or receiving from an AP on the
background access category. If this rate is exceeded, the AP should police
the flows traversing this AC. The value '4294967295', which is the default
value, means that the SSP is not requesting the AP to limit the data rate
used by the non-AP STA. Local configuration of the AP, however, may cause
the rate to be limited, especially when the AC is configured for mandatory
admission control."
DEFVAL {4294967295}
::= { dot11InterworkingEntry 11 }
dot11NonAPStationAuthMaxVoiceOctets OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized total octet count that a
STA may use on the voice access category. If this octet count is exceeded,
the AP should disassociate the non-AP STA. A value of 0 indicates that
there is no octet limit."
DEFVAL {0}
::= { dot11InterworkingEntry 12 }
dot11NonAPStationAuthMaxVideoOctets OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized total octet count that a
STA may use on the video access category. If this octet count is exceeded,
the AP should disassociate the non-AP STA. A value of 0 indicates that
there is no octet limit."
DEFVAL {0}
::= { dot11InterworkingEntry 13 }
dot11NonAPStationAuthMaxBestEffortOctets OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized total octet count that a
STA may use on the best effort access category. If this octet count is
exceeded, the AP should disassociate the non-AP STA. A value of 0
indicates that there is no octet limit."
DEFVAL {0}
3183
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11InterworkingEntry 14 }
dot11NonAPStationAuthMaxBackgroundOctets OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized total octet count that a
STA may use on the background access category. If this octet count is
exceeded, the AP should disassociate the non-AP STA. A value of 0
indicates that there is no octet limit."
DEFVAL {0}
::= { dot11InterworkingEntry 15 }
dot11NonAPStationAuthMaxHCCAHEMMOctets OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized total octet count that a
STA may use with HCCA or HEMM access. If this octet count is exceeded, the
AP should disassociate the non-AP STA. A value of 0 indicates that there
is no octet limit."
DEFVAL {0}
::= { dot11InterworkingEntry 16 }
dot11NonAPStationAuthMaxTotalOctets OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized total octet count that a
STA may use on all access categories combined. If this octet count is
exceeded, the AP should disassociate the non-AP STA. A value of 0
indicates that there is no octet limit."
DEFVAL {0}
::= { dot11InterworkingEntry 17 }
dot11NonAPStationAuthHCCAHEMM OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute, when true, indicates that the non-AP STA is permitted by
3184
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the SSP to request HCCA or HEMM service via ADDTS frames. If this
attribute is false, then HCCA or HEMM service is not permitted by the
SSP."
DEFVAL {true}
::= { dot11InterworkingEntry 18 }
dot11NonAPStationAuthMaxHCCAHEMMRate OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "kb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized data rate the non-AP STA
may use, either transmitting to an AP or receiving from an AP via HCCA or
HEMM. The value '4294967295', which is the default value, means that the
SSP is not requesting the AP to limit the data rate used by the non-AP
STA. Local configuration of the AP, however, may cause the rate to be
otherwise limited."
DEFVAL {4294967295}
::= { dot11InterworkingEntry 19 }
dot11NonAPStationAuthHCCAHEMMDelay OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the delay bound for frames queued at an AP to a
non-AP STA in the HCCA or HEMM queue. An AP should deliver frames to the
non-AP STA within the time period specified in this attribute. When a non-
AP STA requests admission control to the HCCA or HEMM queue, the requested
delay will be equal to or higher than this value. The value '4294967295',
which is the default value, means that the SSP is not requesting the AP
limit the delay bound in this queue for transmissions to the non-AP STA."
DEFVAL {4294967295}
::= { dot11InterworkingEntry 20 }
dot11NonAPStationAuthSourceMulticast OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute, when true, indicates that the AP's MAC sublayer shall
perform rate limiting to enforce the resource utilization limit in
dot11NonAPStationAuthMaxSourceMulticastRate in the dot11InterworkingEntry
identified by the source MAC address of the received frame. If this
attribute is false, at an AP for which dot11SSPNInterfaceActivated is
true, upon receipt of a frame with the Type subfield equal to Data with
group DA, then the AP's MAC sublayer shall discard the frame."
3185
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DEFVAL {true}
::= { dot11InterworkingEntry 21 }
dot11NonAPStationAuthMaxSourceMulticastRate OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "kb/s"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute indicates the maximum authorized data rate which the non-AP
STA may transmit group addressed frames to an AP. If this rate is
exceeded, the AP should police the flows. The value '4294967295', which is
the default value, means that the SSP is not requesting the AP to limit
the multicast data rate used by the non-AP STA."
DEFVAL {4294967295}
::= { dot11InterworkingEntry 22 }
dot11NonAPStationVoiceMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each MSDU
successfully transmitted by the AP on the voice access category and for
each MSDU successfully received on either user priority 6 or 7."
::= { dot11InterworkingEntry 23 }
dot11NonAPStationDroppedVoiceMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each MSDU
dropped by the AP on the voice access category."
::= { dot11InterworkingEntry 24 }
dot11NonAPStationVoiceOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented by the octet length
of each MSDU successfully transmitted by the AP on the voice access
category and by the octet length of each MSDU successfully received on
3186
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
either user priority 6 or 7."
::= { dot11InterworkingEntry 25 }
dot11NonAPStationDroppedVoiceOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each octet
dropped by the AP on the voice access category."
::= { dot11InterworkingEntry 26 }
dot11NonAPStationVideoMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each MSDU
successfully transmitted by the AP on the video access category and for
each MSDU successfully received on either user priority 4 or 5."
::= { dot11InterworkingEntry 27 }
dot11NonAPStationDroppedVideoMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each MSDU
dropped by the AP on the video access category."
::= { dot11InterworkingEntry 28 }
dot11NonAPStationVideoOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented by the octet length
of each MSDU successfully transmitted by the AP on the voice access
category and by the octet length of each MSDU successfully received on
either user priority 4 or 5."
::= { dot11InterworkingEntry 29 }
dot11NonAPStationDroppedVideoOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
3187
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each octet
dropped by the AP on the video access category."
::= { dot11InterworkingEntry 30 }
dot11NonAPStationBestEffortMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each MSDU
successfully transmitted by the AP on the best effort access category and
for each MSDU successfully received on either user priority 0 or 3. For
DCF or PCF operation, this counter shall be incremented for each MSDU
successfully transmitted or received by the AP."
::= { dot11InterworkingEntry 31 }
dot11NonAPStationDroppedBestEffortMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each MSDU
dropped by the AP on the best effort access category and for each MSDU
dropped by the AP on either user priority 0 or 3. For DCF or PCF
operation, this counter shall be incremented for each MSDU dropped by the
AP."
::= { dot11InterworkingEntry 32 }
dot11NonAPStationBestEffortOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented by the octet length
of each MSDU successfully transmitted by the AP on the best effort access
category and by the octet length of each MSDU successfully received on
either user priority 0 or 3. For DCF or PCF operation, this counter shall
be incremented the octet length of each MSDU successfully transmitted or
received by the AP."
::= { dot11InterworkingEntry 33 }
dot11NonAPStationDroppedBestEffortOctetCount OBJECT-TYPE
3188
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for the octet length
of each MSDU dropped by the AP on the best effort access category and by
the octet length of each MSDU dropped by the AP for either user priority 0
or 3. For DCF or PCF operation, this counter shall be incremented for the
octet length of each MSDU dropped by the AP."
::= { dot11InterworkingEntry 34 }
dot11NonAPStationBackgroundMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each MSDU
successfully transmitted by the AP on the background access category and
for each MSDU successfully received on either user priority 1 or 2."
::= { dot11InterworkingEntry 35 }
dot11NonAPStationDroppedBackgroundMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented for each MSDU
dropped by the AP on the background access category"
::= { dot11InterworkingEntry 36 }
dot11NonAPStationBackgroundOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented by the octet length
of each MSDU successfully transmitted by the AP on the background access
category and by the octet length of each MSDU successfully received on
either user priority 1 or 2."
::= { dot11InterworkingEntry 37 }
dot11NonAPStationDroppedBackgroundOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
3189
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For EDCA operation, this counter shall be incremented by the octet length
of each MSDU dropped by the AP on the background access category"
::= { dot11InterworkingEntry 38 }
dot11NonAPStationHCCAHEMMMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For HCCA or HEMM operation, this counter shall be incremented for each
MSDU successfully transmitted by the AP and for each MSDU successfully
received on either."
::= { dot11InterworkingEntry 39 }
dot11NonAPStationDroppedHCCAHEMMMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For HCCA or HEMM operation, this counter shall be incremented for each
MSDU dropped by the AP."
::= { dot11InterworkingEntry 40 }
dot11NonAPStationHCCAHEMMOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For HCCA or HEMM operation, this counter shall be incremented by the octet
length of each MSDU successfully transmitted by the AP and by the octet
length of each MSDU successfully received."
::= { dot11InterworkingEntry 41 }
dot11NonAPStationDroppedHCCAHEMMOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
3190
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
For HCCA or HEMM operation, this counter shall be incremented by the octet
length of each MSDU dropped by the AP."
::= { dot11InterworkingEntry 42 }
dot11NonAPStationMulticastMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For Multicast operation, this counter shall be incremented for each
Multicast MSDU successfully transmitted by the AP and for each Multicast
MSDU successfully received at the AP."
::= { dot11InterworkingEntry 43 }
dot11NonAPStationDroppedMulticastMSDUCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For Multicast operation, this counter shall be incremented for each
Multicast MSDU dropped by the AP."
::= { dot11InterworkingEntry 44 }
dot11NonAPStationMulticastOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For Multicast operation, this counter shall be incremented by the octet
length of each MSDU successfully transmitted by the AP and by the octet
length of each Multicast MSDU successfully received."
::= { dot11InterworkingEntry 45 }
dot11NonAPStationDroppedMulticastOctetCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the completion of an MA-
UNITDATA.confirm or MA-UNITDATA.indication primitive.
For Multicast operation, this counter shall be incremented by the octet
length of each Multicast MSDU dropped by the AP."
::= { dot11InterworkingEntry 46 }
dot11NonAPStationPowerManagementMode OBJECT-TYPE
3191
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX INTEGER { active(1), powersave(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's MAC after the non-AP STA changes it's power
management mode.
This attribute indicates the power management mode of the non-AP STA."
::= { dot11InterworkingEntry 47 }
dot11NonAPStationAuthDls OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a control variable.
It is written by the SME after the AP receives the permissions for the
non-AP STA from the SSPN Interface.
This attribute, when true, indicates that the non-AP STA is permitted by
the SSPN Interface to use direct link service (DLS). Note this attribute
is an SSP permission and is independent of whether DLS is allowed in the
BSS as governed by dot11DLSAllowedInQBSS. This service is disabled
otherwise."
DEFVAL {true}
::= { dot11InterworkingEntry 48 }
dot11NonAPStationVLANId OBJECT-TYPE
SYNTAX Unsigned32 (0..4095)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after a non-AP STA associates to the BSS.
This attribute indicates the VLAN ID on the an external network to which
frames from the non-AP STA are bridged."
::= { dot11InterworkingEntry 49 }
dot11NonAPStationVLANName OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..64))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after a non-AP STA associates to the BSS.
This attribute indicates the VLAN name corresponding to the VLAN ID on the
external network to which frames from the non-AP STA are bridged."
::= { dot11InterworkingEntry 50 }
dot11NonAPStationAddtsResultCode OBJECT-TYPE
SYNTAX INTEGER {
success(1),
invalidParameters(2),
rejectedWithSuggestedChanges(3),
rejectedForDelayPeriod(4),
rejectedForSspPermissions(5),
rejectedWithSuggestedBssTransition (6),
3192
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
requestedTclasNotSupported (7),
tclasResourcesExhausted (8),
rejectedHomeWithSuggestedChanges (9)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the AP's HC after the AP transmits an ADDTS Response
frame to the non-AP STA or after the AP includes a RIC element in a
Reassociation Response frame.
This attribute indicates the most recent result code returned by the AP in
an ADDTS Response."
::= { dot11InterworkingEntry 51 }
-- **********************************************************************
-- * End of dot11Interworking TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11APLCI TABLE
-- **********************************************************************
dot11APLCITable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11APLCIEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table represents the Geospatial location of the AP as specified in
9.4.2.22.10."
::= { dot11imt 3 }
dot11APLCIEntry OBJECT-TYPE
SYNTAX Dot11APLCIEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"AP location in geospatial coordinates"
INDEX { dot11APLCIIndex }
::= { dot11APLCITable 1 }
Dot11APLCIEntry ::=
SEQUENCE {
dot11APLCIIndex Unsigned32,
dot11APLCILatitudeUncertainty Unsigned32,
dot11APLCILatitudeInteger Integer32,
dot11APLCILatitudeFraction Integer32,
dot11APLCILongitudeUncertainty Unsigned32,
dot11APLCILongitudeInteger Integer32,
dot11APLCILongitudeFraction Integer32,
dot11APLCIAltitudeType INTEGER,
dot11APLCIAltitudeUncertainty Unsigned32,
dot11APLCIAltitude Integer32,
dot11APLCIDatum INTEGER,
dot11APLCIAzimuthType INTEGER,
dot11APLCIAzimuthResolution Unsigned32,
dot11APLCIAzimuth Integer32
}
dot11APLCIIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
3193
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"Index for AP LCI elements in dot11APLCITable, greater than 0."
::= { dot11APLCIEntry 1 }
dot11APLCILatitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Latitude uncertainty is defined in IETF RFC 6225."
::= { dot11APLCIEntry 2 }
dot11APLCILatitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-90..90)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Latitude is a 34 bit fixed point value consisting of 9 bits of integer and
25 bits of fraction. This field contains the 9 bits of integer portion of
Latitude."
::= { dot11APLCIEntry 3 }
dot11APLCILatitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Latitude is a 34 bit fixed point value consisting of 9 bits of integer and
25 bits of fraction. This field contains the 25 bits of fraction portion
of Latitude."
::= { dot11APLCIEntry 4 }
dot11APLCILongitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude uncertainty is defined in IETF RFC 6225."
::= { dot11APLCIEntry 5 }
dot11APLCILongitudeInteger OBJECT-TYPE
SYNTAX Integer32 (-180..180)
MAX-ACCESS read-write
3194
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude is a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. This field contains the 9 bits of integer portion
of Longitude."
::= { dot11APLCIEntry 6 }
dot11APLCILongitudeFraction OBJECT-TYPE
SYNTAX Integer32 (-16777215..16777215)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Longitude is a 2s complement 34 bit fixed point value consisting of 9 bits
of integer and 25 bits of fraction. This field contains the 25 bits of
fraction portion of Longitude."
::= { dot11APLCIEntry 7 }
dot11APLCIAltitudeType OBJECT-TYPE
SYNTAX INTEGER { meters(1), floors(2), hagm (3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Altitude Type is four bits encoding the type of altitude. Codes defined
are: meters in 2s complement fixed-point 22-bit integer part with 8-bit
fraction floors in 2s complement fixed-point 22-bit integer part with 8-
bit fraction hagm: Height Above Ground in meters, in 2s complement fixed-
point 22-bit integer part with 8-bit fraction."
::= { dot11APLCIEntry 8 }
dot11APLCIAltitudeUncertainty OBJECT-TYPE
SYNTAX Unsigned32 (0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Altitude resolution is 6 bits indicating the number of valid bits in the
altitude."
::= { dot11APLCIEntry 9 }
dot11APLCIAltitude OBJECT-TYPE
SYNTAX Integer32 (-536870912..536870911)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
3195
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Altitude is a 30 bit value defined by the Altitude type field. The field
is encoded as a 2s complement fixed-point 22-bit integer part with 8-bit
fraction."
::= { dot11APLCIEntry 10 }
-- Reserved: 11. Was dot11APLCIAltitudeFraction.
dot11APLCIDatum OBJECT-TYPE
SYNTAX INTEGER {
wgs84 (1),
nad83navd88 (2),
nad93mllwvd (3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Datum is a 3-bit value encoding the horizontal and vertical references
used for the coordinates given in this LCI. IETF RFC 6225 defines the
values of Datum. Type 1 is WGS-84, the coordinate system used by GPS. Type
2 is NAD83 with NAVD88 vertical reference. Type 3 is NAD83 with Mean Lower
Low Water vertical datum. All other types are reserved."
::= { dot11APLCIEntry 12 }
dot11APLCIAzimuthType OBJECT-TYPE
SYNTAX INTEGER { frontSurfaceOfSTA(0), radioBeam(1) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Azimuth Type is a one bit attribute encoding the type of Azimuth. Codes
defined are: front surface of STA: in 2s complement fixed-point 9-bit
integer radio beam: in 2s complement fixed-point 9-bit integer."
::= { dot11APLCIEntry 13 }
dot11APLCIAzimuthResolution OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Azimuth Resolution is 4 bits indicating the number of valid bits in the
azimuth."
::= { dot11APLCIEntry 14 }
dot11APLCIAzimuth OBJECT-TYPE
SYNTAX Integer32 (-511..511)
MAX-ACCESS read-write
3196
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Azimuth is a 9 bit value defined by the Azimuth Type field.The field is
encoded as a 2s complement fixed-point 9-bit integer horizontal angle in
degrees from true north."
::= { dot11APLCIEntry 15 }
-- **********************************************************************
-- * End of dot11APLCI TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11APCivicLocation TABLE
-- **********************************************************************
dot11APCivicLocationTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11ApCivicLocationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table represents the location of the AP in civic format using the
Civic Address Type elements defined in IETF RFC 5139 [B47]."
::= { dot11imt 4 }
dot11APCivicLocationEntry OBJECT-TYPE
SYNTAX Dot11ApCivicLocationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Civic Address location of the AP described with Civic Address Type
elements defined in IETF RFC 5139 [B47]."
INDEX {dot11APCivicLocationIndex} ::= {dot11APCivicLocationTable 1}
Dot11ApCivicLocationEntry ::=
SEQUENCE {
dot11APCivicLocationIndex Unsigned32,
dot11APCivicLocationCountry OCTET STRING,
dot11APCivicLocationA1 OCTET STRING,
dot11APCivicLocationA2 OCTET STRING,
dot11APCivicLocationA3 OCTET STRING,
dot11APCivicLocationA4 OCTET STRING,
dot11APCivicLocationA5 OCTET STRING,
dot11APCivicLocationA6 OCTET STRING,
dot11APCivicLocationPrd OCTET STRING,
dot11APCivicLocationPod OCTET STRING,
dot11APCivicLocationSts OCTET STRING,
dot11APCivicLocationHno OCTET STRING,
dot11APCivicLocationHns OCTET STRING,
dot11APCivicLocationLmk OCTET STRING,
dot11APCivicLocationLoc OCTET STRING,
dot11APCivicLocationNam OCTET STRING,
dot11APCivicLocationPc OCTET STRING,
dot11APCivicLocationBld OCTET STRING,
dot11APCivicLocationUnit OCTET STRING,
dot11APCivicLocationFlr OCTET STRING,
dot11APCivicLocationRoom OCTET STRING,
dot11APCivicLocationPlc OCTET STRING,
dot11APCivicLocationPcn OCTET STRING,
dot11APCivicLocationPobox OCTET STRING,
dot11APCivicLocationAddcode OCTET STRING,
3197
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11APCivicLocationSeat OCTET STRING,
dot11APCivicLocationRd OCTET STRING,
dot11APCivicLocationRdsec OCTET STRING,
dot11APCivicLocationRdbr OCTET STRING,
dot11APCivicLocationRdsubbr OCTET STRING,
dot11APCivicLocationPrm OCTET STRING,
dot11APCivicLocationPom OCTET STRING
}
dot11APCivicLocationIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Index for APCivicLocation elements in dot11APCivicLocationTable, greater
than 0."
::= { dot11APCivicLocationEntry 1 }
dot11APCivicLocationCountry OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the two uppercase characters which correspond to
the alpha-2 codes in ISO 3166-1. Example: US."
::= { dot11APCivicLocationEntry 2 }
dot11APCivicLocationA1 OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the national subdivisions (state, Region,
province, prefecture). Example: California. The A1 element is used for the
top level subdivision within a country. In the absence of a country-
specific guide on how to use the A-series of elements, the second part of
the ISO 3166-2 code for a country subdivision SHOULD be used. The ISO
3166-2 code is a formed of a country code and hyphen plus a code of one,
two or three characters or numerals. For the A1 element, the leading
country code and hyphen are omitted and only the subdivision code is
included.
For example, the codes for Canada include CA-BC, CA-ON, CA-QC; Luxembourg
has just three single character codes: LU-D, LU-G And LU-L; Australia uses
both two and three character codes: AU-ACT, AU-NSW, AU-NT; France uses
numerical codes for mainland France and letters for territories: FR-75,
FR-NC."
::= { dot11APCivicLocationEntry 3 }
dot11APCivicLocationA2 OBJECT-TYPE
3198
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the county, parish, gun (JP), district (IN).
Example: King's County."
::= { dot11APCivicLocationEntry 4 }
dot11APCivicLocationA3 OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the city, township, shi (JP). Example: San
Francisco."
::= { dot11APCivicLocationEntry 5 }
dot11APCivicLocationA4 OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the city division, borough, city district, ward,
chou (JP). Example: Manhattan."
::= { dot11APCivicLocationEntry 6 }
dot11APCivicLocationA5 OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the neighborhood, block. Example: Morningside
Heights."
::= { dot11APCivicLocationEntry 7 }
dot11APCivicLocationA6 OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
3199
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute contains the street. Example: Broadway. The A6 element is
retained for use in those countries that require this level of detail.
Where A6 was previously used for street names in IETF RFC 5139 [B47], it
will not be used, the RD element will be used for thoroughfare data.
However, without additional information these fields will not be
interchanged when converting between different civic formats. Where Civic
address information is obtained from another format, such as the DHCP form
IETF RFC 4776 [B44], the A6 element will be copied directly from the
source format."
::= { dot11APCivicLocationEntry 8 }
dot11APCivicLocationPrd OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the leading street direction. Example: NW."
::= { dot11APCivicLocationEntry 9 }
dot11APCivicLocationPod OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the trailing street suffix. Example: SW."
::= { dot11APCivicLocationEntry 10 }
dot11APCivicLocationSts OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the street suffix. Example: Avenue, 'Platz,
Street'."
::= { dot11APCivicLocationEntry 11 }
dot11APCivicLocationHno OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the numeric part only of the
House number. Example: 123."
3200
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11APCivicLocationEntry 12 }
dot11APCivicLocationHns OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the house number suffix. Example: A, 1/2"
::= { dot11APCivicLocationEntry 13 }
dot11APCivicLocationLmk OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the landmark or vanity address. Example: Low
Library."
::= { dot11APCivicLocationEntry 14 }
dot11APCivicLocationLoc OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains additional location information. Example: Room
543."
::= { dot11APCivicLocationEntry 15 }
dot11APCivicLocationNam OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the name (residence, business, or office occupant.
Example: Joe's Barbershop."
::= { dot11APCivicLocationEntry 16 }
dot11APCivicLocationPc OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
3201
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the postal code. Example: 10027-0401."
::= { dot11APCivicLocationEntry 17 }
dot11APCivicLocationBld OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the building (structure). Example: Hope Theater."
::= { dot11APCivicLocationEntry 18 }
dot11APCivicLocationUnit OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the unit (apartment, suite). Example: 12a."
::= { dot11APCivicLocationEntry 19 }
dot11APCivicLocationFlr OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the floor number. Example: 5."
::= { dot11APCivicLocationEntry 20 }
dot11APCivicLocationRoom OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the room. Example: 450F."
::= { dot11APCivicLocationEntry 21 }
dot11APCivicLocationPlc OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
3202
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the place type. Example: office."
::= { dot11APCivicLocationEntry 22 }
dot11APCivicLocationPcn OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the postal community name. Example: Leonia."
::= { dot11APCivicLocationEntry 23 }
dot11APCivicLocationPobox OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the post office box (P.O. Box). Example: U40."
::= { dot11APCivicLocationEntry 24 }
dot11APCivicLocationAddcode OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the additional code. Example: 13203000003."
::= { dot11APCivicLocationEntry 25 }
dot11APCivicLocationSeat OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the seat (desk, cubicle, workstation). Example: WS
181."
::= { dot11APCivicLocationEntry 26 }
dot11APCivicLocationRd OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
3203
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the primary road or street. Example: Broadway."
::= { dot11APCivicLocationEntry 27 }
dot11APCivicLocationRdsec OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the road section. Example: 14.In some countries a
thoroughfare can be broken up into sections, and it is not uncommon for
street numbers to be repeated between sections. A road section identifier
might be needed to make that an address unique. For example, West Alice
Parade has 5 sections, each numbered from 1; unless the section is
specified 7 West Alice Parade could exist in 5 different places."
::= { dot11APCivicLocationEntry 28 }
dot11APCivicLocationRdbr OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the road branch. Example: 'Lane 7'. Minor streets
can share the same name, so that they can only Be distinguished by the
major thoroughfare with which they intersect. For example, both West Alice
Parade, Section 3 and Bob Street could both be interested by a Carol Lane.
This element is used to specify a road branch where the name of the branch
does not uniquely identify the road. Road branches MAY also be used where
a major thoroughfare is split into sections."
::= { dot11APCivicLocationEntry 29 }
dot11APCivicLocationRdsubbr OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the road sub-branch. Example: Alley 8."
::= { dot11APCivicLocationEntry 30 }
dot11APCivicLocationPrm OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
3204
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the road premodifier. Example: Old."
::= { dot11APCivicLocationEntry 31 }
dot11APCivicLocationPom OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the road post-modifier. Example: Extended."
::= { dot11APCivicLocationEntry 32 }
-- **********************************************************************
-- * End of dot11APCivicLocation TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11RoamingConsortium TABLE
-- **********************************************************************
dot11RoamingConsortiumTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11RoamingConsortiumEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a Table of OIs which are to be transmitted in an ANQP Roaming
Consortium ANQP-element. Each table entry corresponds to a roaming
consortium or single SSP. The first 3 entries in this table are
transmitted in Beacon and Probe Response frames."
::= { dot11imt 5 }
dot11RoamingConsortiumEntry OBJECT-TYPE
SYNTAX Dot11RoamingConsortiumEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each OI identifies a roaming consortium (group of SSPs with inter-SSP
roaming agreement) or a single SSP. A non-AP STA in possession of security
credentials for the SSPN(s) identified by the OI should be able to
successfully authenticate to this AP."
INDEX { dot11RoamingConsortiumOI }
::= { dot11RoamingConsortiumTable 1 }
Dot11RoamingConsortiumEntry ::=
SEQUENCE {
dot11RoamingConsortiumOI OCTET STRING,
dot11RoamingConsortiumRowStatus RowStatus
}
dot11RoamingConsortiumOI OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(16))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
3205
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute contains the IEEE defined OI as defined in 9.4.1.32."
::= { dot11RoamingConsortiumEntry 1 }
dot11RoamingConsortiumRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object represents the status column for a conceptual row in this
table."
::= { dot11RoamingConsortiumEntry 2 }
-- **********************************************************************
-- * End of dot11RoamingConsortium TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11DomainName TABLE
-- **********************************************************************
dot11DomainNameTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11DomainNameEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a table of Domain Names which form the Domain Name list in access
network query protocol. The Domain Name list may be transmitted to a non-
AP STA in a GAS Response. Each table entry corresponds to a single Domain
Name."
::= { dot11imt 6 }
dot11DomainNameEntry OBJECT-TYPE
SYNTAX Dot11DomainNameEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
Each Domain Name identifies a domain names of the entity operating the
IEEE 802.11 access network."
INDEX { dot11DomainNameOui }
::= { dot11DomainNameTable 1 }
Dot11DomainNameEntry ::=
SEQUENCE {
dot11DomainName OCTET STRING,
dot11DomainNameRowStatus RowStatus,
dot11DomainNameOui OCTET STRING
}
dot11DomainName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
3206
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute contains a Domain Name of up to 255 octets formatted in
accordance with the 'Preferred Name Syntax' as defined in IETF RFC 1035."
::= { dot11DomainNameEntry 1 }
dot11DomainNameRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object represents the status column for a conceptual row in this
table."
::= { dot11DomainNameEntry 2 }
dot11DomainNameOui OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(3..5))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object represents an IEEE assigned unique identifier (OUI, OUI-36 or
CID), used as an index into the Domain Name table."
::= { dot11DomainNameEntry 3 }
-- **********************************************************************
-- * End of dot11DomainName TABLE
-- **********************************************************************
-- **********************************************************************
-- * dot11GASAdvertisement TABLE
-- **********************************************************************
dot11GASAdvertisementTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11GASAdvertisementEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object is a table of GAS counters that allows for multiple
instantiations of those counters on a STA."
::= { dot11imt 7 }
dot11GASAdvertisementEntry OBJECT-TYPE
SYNTAX Dot11GASAdvertisementEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object provides the attributes identifying a GAS counter within a
STA."
INDEX { dot11GASAdvertisementId }
::= { dot11GASAdvertisementTable 1 }
Dot11GASAdvertisementEntry ::=
SEQUENCE{
dot11GASAdvertisementId Unsigned32,
dot11GASPauseForServerResponse TruthValue,
dot11GASResponseTimeout Unsigned32,
dot11GASComebackDelay Unsigned32,
dot11GASResponseBufferingTime Unsigned32,
dot11GASQueryResponseLengthLimit Unsigned32,
dot11GASQueries Counter32,
dot11GASQueryRate Gauge32,
dot11GASResponses Counter32,
dot11GASResponseRate Gauge32,
dot11GASNoRequestOutstanding Counter32,
dot11GASResponsesDiscarded Counter32,
3207
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11GASFailedResponses Counter32
}
dot11GASAdvertisementId OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The 1 octet identification number for the GAS Advertisement Protocol, as
defined in Table 9-215, for which statistics are stored the logical row of
the GASAdvertisement table."
::= { dot11GASAdvertisementEntry 1 }
dot11GASPauseForServerResponse OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute is used only by the responding STA in a GAS exchange. When
true, it indicates that the responding STA does not transmit a GAS Initial
Response frame until it receives the query response from the Advertisement
Server or a timeout occurs. When false, the STA does not wait for a
response from the Advertisement Server before transmitting the GAS Initial
Response frame. The setting of this MIB object is outside the scope of
this standard."
::= { dot11GASAdvertisementEntry 2 }
dot11GASResponseTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1000..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This parameter shall indicate the GAS response timeout value."
DEFVAL {5000}
::= { dot11GASAdvertisementEntry 3 }
dot11GASComebackDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This object identifies the GAS Comeback Delay to be used for this
3208
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Advertisement Protocol"
DEFVAL {1000}
::= { dot11GASAdvertisementEntry 4 }
dot11GASResponseBufferingTime OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This object defines the time duration after the expiration of the GAS
Comeback Delay that a STA will buffer a Query Response. Upon expiration of
this time, the STA may discard the Query Response."
DEFVAL {1000}
::= { dot11GASAdvertisementEntry 5 }
dot11GASQueryResponseLengthLimit OBJECT-TYPE
SYNTAX Unsigned32 (1..127)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This object indicates the maximum number of octets an AP will transmit in
one or more Query Response fields contained within GAS Comeback Response
frame(s). A value of 127 means the maximum limit enforced is contained by
the maximum allowable number of fragments in the GAS Query Fragment
Response ID"
::= { dot11GASAdvertisementEntry 6 }
dot11GASQueries OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after transmission of an MLME-GAS.request or
receipt of an MLME-GAS.indication primitive.
The number of GAS queries sent or received for the protocol identified by
dot11GASAdvertisementId."
::= { dot11GASAdvertisementEntry 7 }
dot11GASQueryRate OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is updated by the SME after receipt of an MLME-GAS.indication
primitive.
The number of GAS queries per minute received for the protocol identified
3209
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
by dot11GASAdvertisementId, averaged over the previous ten minutes."
::= { dot11GASAdvertisementEntry 8 }
dot11GASResponses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the SME after transmission of an MLME-GAS.response
primitive or receipt of an MLME-GAS.confirm primitive.
The number of GAS responses sent or received for the protocol identified
by dot11GASAdvertisementId."
::= { dot11GASAdvertisementEntry 9 }
dot11GASResponseRate OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is updated by the SME after transmission of an MLME-GAS.response
primitive.
The number of responses to GAS queries per minute transmitted by an AP for
the protocol identified by dot11GASAdvertisementId, averaged over the
previous ten minutes. This MIB variable is not used in non-AP STAs."
::= { dot11GASAdvertisementEntry 10 }
dot11GASNoRequestOutstanding OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is updated by the SME after transmission of an MLME-GAS.response
primitive.
This counter shall be incremented each time a STA returns a status code of
NO_OUTSTANDING_GAS_REQUEST in a GAS Initial Response or GAS Comeback
Response frame for the protocol identified by dot11GASAdvertisementId."
::= { dot11GASAdvertisementEntry 13 }
dot11GASResponsesDiscarded OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is updated by the SME after transmission of an MLME-GAS.response
primitive.
This counter shall be incremented each a STA discards a GAS response due
to the expiration of the dot11GASResponseBufferingTime timer for the
protocol identified by dot11GASAdvertisementId."
::= { dot11GASAdvertisementEntry 14 }
dot11GASFailedResponses OBJECT-TYPE
SYNTAX Counter32
3210
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is updated by the SME after transmission of an MLME-GAS.response
primitive.
This counter shall be incremented each time a STA commences transmitting a
GAS response but fails to successfully complete the transmission of all
GAS fragments in that response due to the expiratin of the
dot11GASResponseTimeout timer for the protocol identified by
dot11GASAdvertisementId."
::= { dot11GASAdvertisementEntry 15 }
-- **********************************************************************
-- * End of dot11GASAdvertisement TABLE
-- **********************************************************************
-- **********************************************************************
-- * MAC state generic convergence function
-- **********************************************************************
-- MAC state generic convergence function attributes
-- DEFINED AS "The MAC state generic convergence function object
-- class provides the necessary support for support of event-driven
-- triggers to higher layer protocols and the capabilities to
-- support those triggers."
dot11MSGCF OBJECT IDENTIFIER ::= { ieee802dot11 7}
-- MAC state generic convergence function GROUPS
-- dot11MACStateConfigTable ::= { dot11MSGCF 1 }
-- dot11MACStateParameterTable ::= { dot11MSGCF 2 }
-- dot11MACStateESSLinkTable ::= { dot11MSGCF 3 }
-- *********************************************************************
-- * dot11ESSLinkIdentifier type definition
-- *********************************************************************
Dot11ESSLinkIdentifier ::= OCTET STRING (SIZE(0..38))
-- This object type holds the identifier for an IEEE 802.11
-- network. It is composed of the SSID string concatenated
-- with the HESSID, if present.
-- *********************************************************************
-- * dot11MACStateConfig TABLE
-- *********************************************************************
dot11MACStateConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11MACStateConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table holds configuration parameters for the IEEE 802.11 MAC
state generic convergence function."
::= { dot11MSGCF 1 }
dot11MACStateConfigEntry OBJECT-TYPE
SYNTAX Dot11MACStateConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry represents a conceptual row in the dot11MACStateConfigTable
and provides information about network configuration parameters used in
3211
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
the MAC state generic convergence function."
INDEX { dot11MSCEESSLinkIdentifier, dot11MSCENonAPStationMacAddress }
::= { dot11MACStateConfigTable 1 }
Dot11MACStateConfigEntry ::=
SEQUENCE {
dot11ESSDisconnectFilterInterval Unsigned32,
dot11ESSLinkDetectionHoldInterval Unsigned32,
dot11MSCEESSLinkIdentifier Dot11ESSLinkIdentifier,
dot11MSCENonAPStationMacAddress MacAddress
}
dot11ESSDisconnectFilterInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute is set to the time that will elapse after an MLME-
DISASSOCIATE.confirm or MLME-DEAUTHENTICATE.confirm primitive without a
subsequent association before the link is declared down. This interval is
intended to allow a non-AP STA time to transition to another AP within the
same ESS before declaring that the link to the ESS is lost."
::= { dot11MACStateConfigEntry 1 }
dot11ESSLinkDetectionHoldInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute is set to the time that an ESS is held in the
dot11MACStateESSLink table after its last observation before purging the
entry from the table."
::= { dot11MACStateConfigEntry 2 }
dot11MSCEESSLinkIdentifier OBJECT-TYPE
SYNTAX Dot11ESSLinkIdentifier
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an auxiliary variable used to identify instances of the columnar
objects in the dot11MACStateConfigTable table."
::= { dot11MACStateConfigEntry 3 }
dot11MSCENonAPStationMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an auxiliary variable used to identify instances of the columnar
objects in the dot11MACStateConfigTable table."
3212
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11MACStateConfigEntry 4 }
-- *********************************************************************
-- * End of dot11MACStateConfig TABLE
-- *********************************************************************
-- *********************************************************************
-- * dot11MACStateParameter TABLE
-- *********************************************************************
dot11MACStateParameterTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11MACStateParameterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table holds the current parameters used for each IEEE 802.11 network
for IEEE 802.11 MAC convergence functions."
::= { dot11MSGCF 2 }
dot11MACStateParameterEntry OBJECT-TYPE
SYNTAX Dot11MACStateParameterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry represents a conceptual row in the dot11MACStateParameterTable
and provides information about link configuration parameters used in the
MAC state generic convergence function."
INDEX { dot11MSPEESSLinkIdentifier, dot11MSPENonAPStationMacAddress }
::= { dot11MACStateParameterTable 1 }
Dot11MACStateParameterEntry ::=
SEQUENCE {
dot11ESSLinkDownTimeInterval Unsigned32,
dot11ESSLinkRssiDataThreshold Unsigned32,
dot11ESSLinkRssiBeaconThreshold Unsigned32,
dot11ESSLinkDataSnrThreshold Unsigned32,
dot11ESSLinkBeaconSnrThreshold Unsigned32,
dot11ESSLinkBeaconFrameErrorRateThresholdInteger Unsigned32,
dot11ESSLinkBeaconFrameErrorRateThresholdFraction Unsigned32,
dot11ESSLinkBeaconFrameErrorRateThresholdExponent Unsigned32,
dot11ESSLinkFrameErrorRateThresholdInteger Unsigned32,
dot11ESSLinkFrameErrorRateThresholdFraction Unsigned32,
dot11ESSLinkFrameErrorRateThresholdExponent Unsigned32,
dot11PeakOperationalRate Unsigned32,
dot11MinimumOperationalRate Unsigned32,
dot11ESSLinkDataThroughputInteger Unsigned32,
dot11ESSLinkDataThroughputFraction Unsigned32,
dot11ESSLinkDataThroughputExponent Unsigned32,
dot11MSPEESSLinkIdentifier Dot11ESSLinkIdentifier,
dot11MSPENonAPStationMacAddress MacAddress
}
dot11ESSLinkDownTimeInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TUs"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
3213
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
This attribute defines the time interval over which the MAC state generic
convergence function will attempt to predict the failure of an IEEE 802.11
network. The convergence function should issue predicted network failure
events at least this time interval before the network failure is
detected."
::= { dot11MACStateParameterEntry 2 }
dot11ESSLinkRssiDataThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute defines the threshold value for RSSI on Data frames. When
the RSSI drops below this threshold, a report is issued."
::= { dot11MACStateParameterEntry 3 }
dot11ESSLinkRssiBeaconThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute defines the threshold value for RSSI on Beacon frames. When
the RSSI drops below this threshold, a report is issued."
::= { dot11MACStateParameterEntry 4 }
dot11ESSLinkBeaconSnrThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute defines the threshold value for SNR on received Beacon
frames. When the SNR drops below this threshold, a report is issued"
::= { dot11MACStateParameterEntry 5 }
dot11ESSLinkDataSnrThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
This attribute defines the threshold value for SNR on received Data
frames. When the SNR drops below this threshold, a report is issued."
::= { dot11MACStateParameterEntry 6 }
dot11ESSLinkBeaconFrameErrorRateThresholdInteger OBJECT-TYPE
3214
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The Beacon frame error rate is stored in scientific notation as a
significant and exponent. This attribute contains the integer value of the
significand."
::= { dot11MACStateParameterEntry 7 }
dot11ESSLinkBeaconFrameErrorRateThresholdFraction OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The Beacon frame error rate is stored in scientific notation as a
significant and exponent. This attribute contains the fractional value of
the significand."
::= { dot11MACStateParameterEntry 8 }
dot11ESSLinkBeaconFrameErrorRateThresholdExponent OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The Beacon frame error rate is stored in scientific notation as a
significant and exponent. This attribute contains the integer value of the
exponent."
::= { dot11MACStateParameterEntry 9 }
dot11ESSLinkFrameErrorRateThresholdInteger OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The frame error rate of the network is stored in scientific notation as a
significant and exponent. This attribute contains the integer value of the
significand."
::= { dot11MACStateParameterEntry 10 }
dot11ESSLinkFrameErrorRateThresholdFraction OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
3215
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The frame error rate of the network is stored in scientific notation as a
significant and exponent. This attribute contains the fractional value of
the significand."
::= { dot11MACStateParameterEntry 11 }
dot11ESSLinkFrameErrorRateThresholdExponent OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The frame error rate of the network is stored in scientific notation as a
significant and exponent. This attribute contains the integer value of the
exponent."
::= { dot11MACStateParameterEntry 12 }
dot11PeakOperationalRate OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The highest operational rate used for transmission of Data frames, encoded
as defined in 9.4.2.3."
::= { dot11MACStateParameterEntry 13 }
dot11MinimumOperationalRate OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The lowest operational rate used for transmission of Data frames, encoded
as defined in 9.4.2.3."
::= { dot11MACStateParameterEntry 14 }
dot11ESSLinkDataThroughputInteger OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The data throughput rate is of the network is stored in scientific
3216
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
notation as a significant and exponent. This attribute contains the
integer value of the significand."
::= { dot11MACStateParameterEntry 15 }
dot11ESSLinkDataThroughputFraction OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The data throughput rate is of the network is stored in scientific
notation as a significant and exponent. This attribute contains the
fractional value of the significand."
::= { dot11MACStateParameterEntry 16 }
dot11ESSLinkDataThroughputExponent OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME.
Changes take effect as soon as practical in the implementation.
The data throughput rate is of the network is stored in scientific
notation as a significant and exponent. This attribute contains the
integer value of the exponent."
::= { dot11MACStateParameterEntry 17 }
dot11MSPEESSLinkIdentifier OBJECT-TYPE
SYNTAX Dot11ESSLinkIdentifier
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an auxiliary variable used to identify instances of the columnar
objects in the dot11MACStateParameterTable table."
::= { dot11MACStateParameterEntry 18 }
dot11MSPENonAPStationMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an auxiliary variable used to identify instances of the columnar
objects in the dot11MACStateParameterTable table."
::= { dot11MACStateParameterEntry 19 }
-- *********************************************************************
-- * End of dot11MACStateParameter TABLE
-- *********************************************************************
-- *********************************************************************
-- * dot11MACStateESSLink TABLE
-- *********************************************************************
dot11MACStateESSLinkDetectedTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot11MACStateESSLinkDetectedEntry
3217
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table holds the detected IEEE 802.11 network list used for MAC
convergence functions."
::= { dot11MSGCF 3 }
dot11MACStateESSLinkDetectedEntry OBJECT-TYPE
SYNTAX Dot11MACStateESSLinkDetectedEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry represents a conceptual row in the dot11MACStateESSLinkTable
and provides information about available networks for use in the MAC state
generic convergence function."
INDEX { dot11MSELDEESSLinkIdentifier, dot11MSELDENonAPStationMacAddress }
::= { dot11MACStateESSLinkDetectedTable 1 }
Dot11MACStateESSLinkDetectedEntry ::=
SEQUENCE {
dot11ESSLinkDetectedIndex Unsigned32,
dot11ESSLinkDetectedNetworkId OCTET STRING,
dot11ESSLinkDetectedNetworkDetectTime Unsigned32,
dot11ESSLinkDetectedNetworkModifiedTime Unsigned32,
dot11ESSLinkDetectedNetworkMIHCapabilities BITS,
dot11MSELDEESSLinkIdentifier Dot11ESSLinkIdentifier,
dot11MSELDENonAPStationMacAddress MacAddress
}
dot11ESSLinkDetectedIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for ESSLinkDetected elements in dot11ESSLinkDetectedTable, greater
than 0."
::= { dot11MACStateESSLinkDetectedEntry 1 }
dot11ESSLinkDetectedNetworkId OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MSGCF after reception of an MSGCF-ESS-LINK-
DETECTED.indication primitive.
The string used to identify the network represented by this row in the
table. It is composed of the SSID of the network concatenated with the
HESSID, if present."
::= { dot11MACStateESSLinkDetectedEntry 2 }
dot11ESSLinkDetectedNetworkDetectTime OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MSGCF after reception of an MSGCF-ESS-LINK-
DETECTED.indication primitive.
The STA's TSF timer when any BSSID supporting the network was first
3218
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
detected."
::= { dot11MACStateESSLinkDetectedEntry 4 }
dot11ESSLinkDetectedNetworkModifiedTime OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MSGCF after reception of an MSGCF-ESS-LINK-
DETECTED.indication primitive.
The STA's TSF timer value when changes were made to any part of this row
in the table, such as by addition of a BSSID to the BSSID list."
::= { dot11MACStateESSLinkDetectedEntry 5 }
dot11ESSLinkDetectedNetworkMIHCapabilities OBJECT-TYPE
SYNTAX BITS {
mihIsSupport(0),
mihCsEsSupport(1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a status variable.
It is written by the MSGCF after reception of an MSGCF-ESS-LINK-
DETECTED.indication primitive.
The object reports whether the network supports IEEE 802.21 MIH
information services and/or IEEE 802.21 MIH command/event services. These
values are determined by examining the Interworking information in frames
that caused the network to be detected."
::= { dot11MACStateESSLinkDetectedEntry 6 }
dot11MSELDEESSLinkIdentifier OBJECT-TYPE
SYNTAX Dot11ESSLinkIdentifier
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an auxiliary variable used to identify instances of the columnar
objects in the dot11MACStateESSLinkDetectedTable table."
::= { dot11MACStateESSLinkDetectedEntry 7 }
dot11MSELDENonAPStationMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is an auxiliary variable used to identify instances of the columnar
objects in the dot11MACStateESSLinkDetectedTable table."
::= { dot11MACStateESSLinkDetectedEntry 8 }
-- *********************************************************************
-- * End of dot11MACStateESSLink TABLE
-- *********************************************************************
-- **********************************************************************
-- * Compliance Information
-- **********************************************************************
3219
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11Conformance OBJECT IDENTIFIER ::= { ieee802dot11 5 }
dot11Groups OBJECT IDENTIFIER ::= { dot11Conformance 1 }
dot11Compliances OBJECT IDENTIFIER ::= { dot11Conformance 2 }
-- **********************************************************************
-- * Groups - units of compliance
-- **********************************************************************
dot11SMTbase OBJECT-GROUP
OBJECTS {
dot11StationID,
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID, dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod, dot11DTIMPeriod,
dot11AssociationResponseTimeout }
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase2.
The SMT object class provides the necessary support at the STA to manage
the processes in the STA such that the STA may work cooperatively as a
part of an IEEE 802.11 network."
::= { dot11Groups 1 }
dot11SMTprivacy OBJECT-GROUP
OBJECTS {
dot11PrivacyInvoked,
dot11WEPKeyMappingLengthImplemented,
dot11ExcludeUnencrypted,
dot11WEPICVErrorCount,
dot11WEPExcludedCount,
dot11WEPDefaultKeyID,
dot11WEPDefaultKeyValue,
dot11WEPKeyMappingWEPOn,
dot11WEPKeyMappingValue,
dot11WEPKeyMappingAddress,
dot11WEPKeyMappingStatus }
STATUS current
DESCRIPTION
"The SMTPrivacy package is a set of attributes that are present if WEP is
implemented in the STA."
::= { dot11Groups 2 }
dot11MACbase OBJECT-GROUP
OBJECTS {
dot11MACAddress,
dot11GroupAddress,
dot11GroupAddressesStatus,
dot11RTSThreshold,
dot11ShortRetryLimit,
dot11LongRetryLimit,
dot11FragmentationThreshold,
dot11MaxTransmitMSDULifetime,
dot11MaxReceiveLifetime,
dot11ManufacturerID,
dot11ProductID }
STATUS deprecated
3220
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"Superseded by dot11MACbase2.
The MAC object class provides the necessary support for the access
control, generation, and verification of frame check sequences (FCSs), and
proper delivery of valid data to upper layers."
::= { dot11Groups 3 }
dot11MACStatistics OBJECT-GROUP
OBJECTS {
dot11RetryCount,
dot11MultipleRetryCount,
dot11RTSSuccessCount,
dot11RTSFailureCount,
dot11AckFailureCount,
dot11FrameDuplicateCount }
STATUS current
DESCRIPTION
"The MACStatistics package provides extended statistical information on
the operation of the MAC. This package is completely optional."
::= { dot11Groups 4 }
dot11ResourceTypeID OBJECT-GROUP
OBJECTS {
dot11ResourceTypeIDName,
dot11manufacturerOUI,
dot11manufacturerName,
dot11manufacturerProductName,
dot11manufacturerProductVersion }
STATUS current
DESCRIPTION
"Attributes used to identify a STA, its manufacturer, and various product
names and versions."
::= { dot11Groups 5 }
dot11SmtAuthenticationAlgorithms OBJECT-GROUP
OBJECTS {
dot11AuthenticationAlgorithm,
dot11AuthenticationAlgorithmActivated }
STATUS current
DESCRIPTION
"Authentication Algorithm Table."
::= { dot11Groups 6 }
dot11PhyOperationComplianceGroup OBJECT-GROUP
OBJECTS { dot11PHYType, dot11CurrentRegDomain, dot11TempType }
STATUS deprecated
DESCRIPTION
"Superseded by dot11PhyOperationComplianceGroup2.
PHY operations attributes."
::= { dot11Groups 7 }
dot11PhyAntennaComplianceGroup OBJECT-GROUP
OBJECTS {
dot11CurrentTxAntenna,
dot11DiversitySupportImplemented,
dot11CurrentRxAntenna }
STATUS deprecated
DESCRIPTION
"Attributes for Data Rates for IEEE Std 802.11."
::= { dot11Groups 8 }
dot11PhyTxPowerComplianceGroup OBJECT-GROUP
OBJECTS {
dot11NumberSupportedPowerLevelsImplemented,
3221
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TxPowerLevel1,
dot11TxPowerLevel2,
dot11TxPowerLevel3,
dot11TxPowerLevel4,
dot11TxPowerLevel5,
dot11TxPowerLevel6,
dot11TxPowerLevel7,
dot11TxPowerLevel8,
dot11CurrentTxPowerLevel }
STATUS current
DESCRIPTION
"Attributes for Control and Management of transmit power."
::= { dot11Groups 9 }
dot11PhyDSSSComplianceGroup OBJECT-GROUP
OBJECTS {
dot11CurrentChannel,
dot11CCAModeSupported,
dot11CurrentCCAMode,
dot11EDThreshold }
STATUS current
DESCRIPTION
"Attributes that configure the DSSS PHY for IEEE Std 802.11."
::= { dot11Groups 11 }
dot11PhyRegDomainsSupportGroup OBJECT-GROUP
OBJECTS { dot11RegDomainsImplementedValue }
STATUS deprecated
DESCRIPTION
"Attributes that specify the supported Regulation Domains."
::= { dot11Groups 13 }
dot11PhyAntennasListGroup OBJECT-GROUP
OBJECTS {
dot11TxAntennaImplemented,
dot11RxAntennaImplemented,
dot11DiversitySelectionRxImplemented }
STATUS current
DESCRIPTION
"Attributes that specify the supported Regulation Domains."
::= { dot11Groups 14 }
dot11PhyRateGroup OBJECT-GROUP
OBJECTS {
dot11ImplementedDataRatesTxValue,
dot11ImplementedDataRatesRxValue }
STATUS current
DESCRIPTION
"Attributes for Data Rates for IEEE Std 802.11."
::= { dot11Groups 15 }
dot11CountersGroup OBJECT-GROUP
OBJECTS {
dot11TransmittedFragmentCount,
dot11GroupTransmittedFrameCount,
dot11FailedCount,
dot11ReceivedFragmentCount,
dot11GroupReceivedFrameCount,
dot11FCSErrorCount,
dot11WEPUndecryptableCount,
dot11TransmittedFrameCount }
STATUS deprecated
3222
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"Superseded by dot11CountersGroup2.
Attributes from the dot11CountersGroup that are not described in the
dot11MACStatistics group. These objects are mandatory."
::= { dot11Groups 16 }
dot11NotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
dot11Disassociate,
dot11Deauthenticate,
dot11AuthenticateFail,
dot11Associate,
dot11AssociateFailed,
dot11Reassociate,
dot11ReassociateFailed }
STATUS current
DESCRIPTION
"IEEE 802.11 notifications"
::= { dot11Groups 17 }
dot11SMTbase2 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID,
dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod,
dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation }
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase3.
The SMTbase2 object class provides the necessary support at the STA to
manage the processes in the STA such that the STA may work cooperatively
as a part of an IEEE 802.11 network."
::= { dot11Groups 18 }
dot11PhyOFDMComplianceGroup OBJECT-GROUP
OBJECTS {
dot11CurrentFrequency,
dot11TIThreshold,
dot11FrequencyBandsImplemented,
dot11ChannelStartingFactor }
STATUS deprecated
DESCRIPTION
"Superseded by dot11PhyOFDMComplianceGroup2.
Attributes that configure the OFDM PHY for IEEE Std 802.11."
::= { dot11Groups 19 }
dot11SMTbase3 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
3223
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID,
dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod,
dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString }
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase4.
The SMTbase3 object class provides the necessary support at the STA to
manage the processes in the STA such that the STA may work cooperatively
as a part of an IEEE 802.11 network, when the STA is capable of
multidomain operation. This object group should be implemented when the
multidomain capability option is implemented."
::= { dot11Groups 20 }
dot11MultiDomainCapabilityGroup OBJECT-GROUP
OBJECTS {
dot11FirstChannelNumber,
dot11NumberofChannels,
dot11MaximumTransmitPowerLevel }
STATUS current
DESCRIPTION
"The dot11MultiDomainCapabilityGroup object class provides the objects
necessary to manage the channels usable by a STA, when the multidomain
capability option is implemented."
::= { dot11Groups 21 }
dot11PhyHRDSSSComplianceGroup OBJECT-GROUP
OBJECTS {
dot11CurrentChannel,
dot11CCAModeSupported,
dot11CurrentCCAMode,
dot11EDThreshold,
dot11ShortPreambleOptionImplemented,
dot11HRCCAModeImplemented }
STATUS current
DESCRIPTION
"Attributes that configure the HRDSSS PHY for IEEE Std 802.11."
::= { dot11Groups 23 }
dot11PhyERPComplianceGroup OBJECT-GROUP
OBJECTS { dot11CurrentChannel,
dot11ShortPreambleOptionImplemented,
dot11ShortSlotTimeOptionImplemented,
dot11ShortSlotTimeOptionActivated }
STATUS current
DESCRIPTION
3224
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"Attributes that configure the ERP."
::= { dot11Groups 24 }
dot11RSNAadditions OBJECT-GROUP
OBJECTS {
dot11RSNAActivated,
dot11RSNAPreauthenticationActivated }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to manage RSNA functionality. Note that additional objects for managing
this functionality are located in the IEEE 802.11 RSN MIB."
::= { dot11Groups 25 }
dot11SMTbase4 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID, dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod, dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11RSNAOptionImplemented }
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase5.
The SMTbase4 object class provides the necessary support at the IEEE STA
to manage the processes in the STA so that the STA may work cooperatively
as a part of an IEEE 802.11 network."
::= { dot11Groups 26 }
-- ********************************************************************
-- * Groups - units of compliance - RSN
-- ********************************************************************
dot11RSNBase OBJECT-GROUP
OBJECTS {
dot11RSNAConfigVersion,
dot11RSNAConfigPairwiseKeysImplemented,
dot11RSNAConfigGroupCipher,
dot11RSNAConfigGroupRekeyMethod,
dot11RSNAConfigGroupRekeyTime,
dot11RSNAConfigGroupRekeyPackets,
dot11RSNAConfigGroupRekeyStrict,
dot11RSNAConfigPSKValue,
dot11RSNAConfigPSKPassPhrase,
dot11RSNAConfigGroupUpdateCount,
dot11RSNAConfigPairwiseUpdateCount,
dot11RSNAConfigGroupCipherSize,
dot11RSNAConfigPairwiseCipherImplemented,
3225
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RSNAConfigPairwiseCipherActivated,
dot11RSNAConfigPairwiseCipherSizeImplemented,
dot11RSNAConfigAuthenticationSuiteImplemented,
dot11RSNAConfigAuthenticationSuiteActivated,
dot11RSNAConfigNumberOfPTKSAReplayCounters,
dot11RSNAConfigSATimeout,
dot11RSNAConfigNumberOfGTKSAReplayCounters,
dot11RSNAAuthenticationSuiteSelected,
dot11RSNAPairwiseCipherSelected,
dot11RSNAGroupCipherSelected,
dot11RSNAPMKIDUsed,
dot11RSNAAuthenticationSuiteRequested,
dot11RSNAPairwiseCipherRequested,
dot11RSNAGroupCipherRequested,
dot11RSNATKIPCounterMeasuresInvoked,
dot11RSNA4WayHandshakeFailures,
dot11RSNAStatsSTAAddress,
dot11RSNAStatsVersion,
dot11RSNAStatsSelectedPairwiseCipher,
dot11RSNAStatsTKIPICVErrors,
dot11RSNAStatsTKIPLocalMICFailures,
dot11RSNAStatsTKIPRemoteMICFailures,
dot11RSNAStatsCCMPReplays,
dot11RSNAStatsCCMPDecryptErrors,
dot11RSNAStatsTKIPReplays,
dot11RSNAConfigSTKKeysImplemented,
dot11RSNAConfigSTKCipher,
dot11RSNAConfigSTKRekeyTime,
dot11RSNAConfigSMKUpdateCount,
dot11RSNAConfigSTKCipherSize,
dot11RSNAConfigNumberOfSTKSAReplayCounters,
dot11RSNAPairwiseSTKSelected,
dot11RSNAPreauthenticationImplemented,
dot11RSNASMKHandshakeFailures }
STATUS current
DESCRIPTION
"The dot11RSNBase object class provides the necessary support for managing
RSNA functionality in the STA."
::= { dot11Groups 27 }
dot11RSNPMKcachingGroup OBJECT-GROUP
OBJECTS {
dot11RSNAConfigPMKLifetime,
dot11RSNAConfigPMKReauthThreshold }
STATUS current
DESCRIPTION
"The dot11RSNPMKcachingGroup object class provides the necessary support
for managing PMKSA caching functionality in the STA."
::= { dot11Groups 28 }
dot11RSNSMKcachingGroup OBJECT-GROUP
OBJECTS {
dot11RSNAConfigSMKLifetime,
dot11RSNAConfigSMKReauthThreshold }
STATUS deprecated
DESCRIPTION
"Deprecated because mechanisms for use of cached SMKSAs are not defined.
The dot11RSNSMKcachingGroup object class provides the necessary support
for managing SMKSA caching functionality in the STA."
::= { dot11Groups 29 }
dot11SMTbase5 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
3226
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID, dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod, dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11SpectrumManagementImplemented,
dot11SpectrumManagementRequired,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired }
STATUS current
DESCRIPTION
"The SMTbase5 object class provides the necessary support at the STA to
manage the processes in the STA so that the STA may work cooperatively as
a part of an IEEE 802.11 network, when the STA is capable of multidomain
operation. This object group should be implemented when the multidomain
capability option is implemented."
::= { dot11Groups 30 }
dot11MACbase2 OBJECT-GROUP
OBJECTS {
dot11MACAddress,
dot11GroupAddress,
dot11GroupAddressesStatus,
dot11RTSThreshold,
dot11ShortRetryLimit,
dot11LongRetryLimit,
dot11FragmentationThreshold,
dot11MaxTransmitMSDULifetime,
dot11MaxReceiveLifetime,
dot11ManufacturerID,
dot11ProductID,
dot11CAPLimit,
dot11HCCWmin,
dot11HCCWmax,
dot11HCCAIFSN,
dot11ADDBAResponseTimeout,
dot11ADDTSResponseTimeout,
dot11ChannelUtilizationBeaconIntervals,
dot11ScheduleTimeout,
dot11DLSResponseTimeout,
dot11QAPMissingAckRetryLimit,
dot11EDCAAveragingPeriod }
STATUS deprecated
DESCRIPTION
"Superseded by dot11MACbase3.
The MAC object class provides the necessary support for the access
control, generation, and verification of frame check sequences (FCSs), and
proper delivery of valid data to upper layers."
::= { dot11Groups 31 }
3227
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11CountersGroup2 OBJECT-GROUP
OBJECTS {
dot11TransmittedFragmentCount,
dot11GroupTransmittedFrameCount,
dot11FailedCount,
dot11ReceivedFragmentCount,
dot11GroupReceivedFrameCount,
dot11FCSErrorCount,
dot11WEPUndecryptableCount,
dot11TransmittedFrameCount,
dot11QosDiscardedFragmentCount,
dot11AssociatedStationCount,
dot11QosCFPollsReceivedCount,
dot11QosCFPollsUnusedCount,
dot11QosCFPollsUnusableCount }
STATUS deprecated
DESCRIPTION
"Superseded by dot11CountersGroup3.
Attributes from the dot11CountersGroup that are not described in the
dot11MACStatistics group. These objects are mandatory."
::= { dot11Groups 32 }
dot11Qosadditions OBJECT-GROUP
OBJECTS {
-- dot11EDCATable,
dot11EDCATableCWmin,
dot11EDCATableCWmax,
dot11EDCATableAIFSN,
dot11EDCATableTXOPLimit,
dot11EDCATableMSDULifetime,
dot11EDCATableMandatory,
-- dot11QAPEDCATable,
dot11QAPEDCATableCWmin,
dot11QAPEDCATableCWmax,
dot11QAPEDCATableAIFSN,
dot11QAPEDCATableTXOPLimit,
dot11QAPEDCATableMSDULifetime,
dot11QAPEDCATableMandatory,
-- dot11QosCountersTable
dot11QosTransmittedFragmentCount,
dot11QosFailedCount,
dot11QosRetryCount,
dot11QosMultipleRetryCount,
dot11QosFrameDuplicateCount,
dot11QosRTSSuccessCount,
dot11QosRTSFailureCount,
dot11QosAckFailureCount,
dot11QosReceivedFragmentCount,
dot11QosTransmittedFrameCount,
dot11QosDiscardedFrameCount,
dot11QosMPDUsReceivedCount,
dot11QosRetriesReceivedCount }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to manage QoS functionality."
::= { dot11Groups 33 }
dot11SMTbase6 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
3228
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID,
dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod,
dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired,
dot11QosOptionImplemented,
dot11ImmediateBlockAckOptionImplemented,
dot11DelayedBlockAckOptionImplemented,
dot11DirectOptionImplemented,
dot11APSDOptionImplemented,
dot11QAckOptionImplemented,
dot11QBSSLoadImplemented,
dot11QueueRequestOptionImplemented,
dot11TXOPRequestOptionImplemented,
dot11MoreDataAckOptionImplemented,
dot11AssociateInNQBSS,
dot11DLSAllowedInQBSS,
dot11DLSAllowed }
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase7.
The SMTbase6 object class provides the necessary support at the STA to
manage the processes in the STA such that the STA may work cooperatively
as a part of an IEEE 802.11 network."
::= { dot11Groups 34 }
dot11PhyOFDMComplianceGroup2 OBJECT-GROUP
OBJECTS {
dot11CurrentFrequency,
dot11TIThreshold,
dot11FrequencyBandsImplemented,
dot11ChannelStartingFactor,
dot11FiveMHzOperationImplemented,
dot11TenMHzOperationImplemented,
dot11TwentyMHzOperationImplemented,
dot11PhyOFDMChannelWidth }
STATUS deprecated
DESCRIPTION
"Superseded by dot11PhyOFDMComplianceGroup3.
Attributes that configure the OFDM PHY for IEEE Std 802.11."
::= { dot11Groups 35}
dot11SMTbase7 OBJECT-GROUP
OBJECTS{
dot11MediumOccupancyLimit,
3229
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID,
dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod,
dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11SpectrumManagementImplemented,
dot11SpectrumManagementRequired,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired,
dot11QosOptionImplemented,
dot11ImmediateBlockAckOptionImplemented,
dot11DelayedBlockAckOptionImplemented,
dot11DirectOptionImplemented,
dot11APSDOptionImplemented,
dot11QAckOptionImplemented,
dot11QBSSLoadImplemented,
dot11QueueRequestOptionImplemented,
dot11TXOPRequestOptionImplemented,
dot11MoreDataAckOptionImplemented,
dot11AssociateInNQBSS,
dot11DLSAllowedInQBSS,
dot11DLSAllowed,
dot11AssociateStation,
dot11AssociateID,
dot11AssociateFailStation,
dot11AssociateFailStatus,
dot11ReassociateStation,
dot11ReassociateID,
dot11ReassociateFailStation,
dot11ReassociateFailStatus,
dot11RadioMeasurementImplemented,
dot11RadioMeasurementActivated,
dot11RMMeasurementNavSync,
dot11RMMeasurementPilotPeriod,
dot11RMLinkMeasurementActivated,
dot11RMNeighborReportActivated,
dot11RMParallelMeasurementsActivated,
dot11RMRepeatedMeasurementsActivated,
dot11RMBeaconPassiveMeasurementActivated,
dot11RMBeaconActiveMeasurementActivated,
dot11RMBeaconTableMeasurementActivated,
dot11RMBeaconMeasurementReportingConditionsActivated,
dot11RMFrameMeasurementActivated,
dot11RMChannelLoadMeasurementActivated,
dot11RMNoiseHistogramMeasurementActivated,
dot11RMStatisticsMeasurementActivated,
dot11RMLCIMeasurementActivated,
3230
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMLCIAzimuthActivated,
dot11RMTransmitStreamCategoryMeasurementActivated,
dot11RMTriggeredTransmitStreamCategoryMeasurementActivated,
dot11RMAPChannelReportActivated,
dot11RMMIBActivated,
dot11RMMaxMeasurementDuration,
dot11RMNonOperatingChannelMaxMeasurementDuration,
dot11RMMeasurementPilotTransmissionInformationActivated,
dot11RMMeasurementPilotActivated,
dot11RMNeighborReportTSFOffsetActivated,
dot11RMRCPIMeasurementActivated,
dot11RMRSNIMeasurementActivated,
dot11RMBSSAverageAccessDelayActivated,
dot11RMBSSAvailableAdmissionCapacityActivated,
dot11RMAntennaInformationActivated}
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase8.
The SMTbase7 object class provides the necessary support at the STA to
manage the processes in the STA such that the STA may work cooperatively
as a part of an IEEE 802.11 network, when the STA is capable of
multidomain operation. This object group should be implemented when the
multidomain capability option is implemented."
::= { dot11Groups 36 }
dot11SMTRMRequest OBJECT-GROUP
OBJECTS {
dot11RMRqstRowStatus,
dot11RMRqstToken,
dot11RMRqstRepetitions,
dot11RMRqstIfIndex,
dot11RMRqstType,
dot11RMRqstTargetAdd,
dot11RMRqstTimeStamp,
dot11RMRqstChanNumber,
dot11RMRqstOperatingClass,
dot11RMRqstRndInterval,
dot11RMRqstDuration,
dot11RMRqstParallel,
dot11RMRqstEnable,
dot11RMRqstRequest,
dot11RMRqstReport,
dot11RMRqstDurationMandatory,
dot11RMRqstBeaconRqstMode,
dot11RMRqstBeaconRqstDetail,
dot11RMRqstFrameRqstType,
dot11RMRqstBssid,
dot11RMRqstSSID,
dot11RMRqstBeaconReportingCondition,
dot11RMRqstBeaconThresholdOffset,
dot11RMRqstSTAStatRqstGroupID,
dot11RMRqstLCIRqstSubject,
dot11RMRqstLCIAzimuthType,
dot11RMRqstLCIAzimuthResolution,
dot11RMRqstPauseTime,
dot11RMRqstTransmitStreamPeerQSTAAddress,
dot11RMRqstTransmitStreamTrafficIdentifier,
dot11RMRqstTransmitStreamBin0Range,
dot11RMRqstTrigdQoSAverageCondition,
dot11RMRqstTrigdQoSConsecutiveCondition,
dot11RMRqstTrigdQoSDelayCondition,
dot11RMRqstTrigdQoSAverageThreshold,
dot11RMRqstTrigdQoSConsecutiveThreshold,
dot11RMRqstTrigdQoSDelayThresholdRange,
3231
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMRqstTrigdQoSDelayThreshold,
dot11RMRqstTrigdQoSMeasurementCount,
dot11RMRqstTrigdQoSTimeout,
dot11RMRqstChannelLoadReportingCondition,
dot11RMRqstChannelLoadReference,
dot11RMRqstNoiseHistogramReportingCondition,
dot11RMRqstAnpiReference,
dot11RMRqstAPChannelReport,
dot11RMRqstSTAStatPeerSTAAddress,
dot11RMRqstFrameTransmitterAddress,
dot11RMRqstVendorSpecific }
STATUS current
DESCRIPTION
"The SMTRMRequest package is a set of attributes that are present if the
STA supports the Radio Measurement service."
::= { dot11Groups 37 }
dot11SMTRMReport OBJECT-GROUP
OBJECTS {
dot11ChannelLoadRprtRqstToken,
dot11ChannelLoadRprtIfIndex,
dot11ChannelLoadMeasuringSTAAddr,
dot11ChannelLoadRprtChanNumber,
dot11ChannelLoadRprtOperatingClass,
dot11ChannelLoadRprtActualStartTime,
dot11ChannelLoadRprtMeasurementDuration,
dot11ChannelLoadRprtChannelLoad,
dot11ChannelLoadRprtVendorSpecific,
dot11ChannelLoadRprtMeasurementMode,
dot11NoiseHistogramRprtRqstToken,
dot11NoiseHistogramRprtIfIndex,
dot11NoiseHistogramMeasuringSTAAddr,
dot11NoiseHistogramRprtChanNumber,
dot11NoiseHistogramRprtOperatingClass,
dot11NoiseHistogramRprtActualStartTime,
dot11NoiseHistogramRprtMeasurementDuration,
dot11NoiseHistogramRprtAntennaID,
dot11NoiseHistogramRprtANPI,
dot11NoiseHistogramRprtIPIDensity0,
dot11NoiseHistogramRprtIPIDensity1,
dot11NoiseHistogramRprtIPIDensity2,
dot11NoiseHistogramRprtIPIDensity3,
dot11NoiseHistogramRprtIPIDensity4,
dot11NoiseHistogramRprtIPIDensity5,
dot11NoiseHistogramRprtIPIDensity6,
dot11NoiseHistogramRprtIPIDensity7,
dot11NoiseHistogramRprtIPIDensity8,
dot11NoiseHistogramRprtIPIDensity9,
dot11NoiseHistogramRprtIPIDensity10,
dot11NoiseHistogramRprtVendorSpecific,
dot11NoiseHistogramRprtMeasurementMode,
dot11BeaconRprtRqstToken,
dot11BeaconRprtIfIndex,
dot11BeaconMeasuringSTAAddr,
dot11BeaconRprtChanNumber,
dot11BeaconRprtOperatingClass,
dot11BeaconRprtActualStartTime,
dot11BeaconRprtMeasurementDuration,
dot11BeaconRprtPhyType,
dot11BeaconRprtReportedFrameType,
dot11BeaconRprtRCPI,
dot11BeaconRprtRSNI,
dot11BeaconRprtBSSID,
dot11BeaconRprtAntennaID,
3232
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11BeaconRprtParentTSF,
dot11BeaconRprtReportedFrameBody,
dot11BeaconRprtVendorSpecific,
dot11BeaconRprtMeasurementMode,
dot11FrameRprtIfIndex,
dot11FrameRprtRqstToken,
dot11FrameRprtChanNumber,
dot11FrameRprtOperatingClass,
dot11FrameRprtActualStartTime,
dot11FrameRprtMeasurementDuration,
dot11FrameRprtTransmitSTAAddress,
dot11FrameRprtBSSID,
dot11FrameRprtPhyType,
dot11FrameRprtAvgRCPI,
dot11FrameRprtLastRSNI,
dot11FrameRprtLastRCPI,
dot11FrameRprtAntennaID,
dot11FrameRprtNumberFrames,
dot11FrameRprtVendorSpecific,
dot11FrameRptMeasurementMode,
dot11STAStatisticsReportToken,
dot11STAStatisticsIfIndex,
dot11STAStatisticsSTAAddress,
dot11STAStatisticsMeasurementDuration,
dot11STAStatisticsGroupID,
dot11STAStatisticsTransmittedFragmentCount,
dot11STAStatisticsGroupTransmittedFrameCount,
dot11STAStatisticsFailedCount,
dot11STAStatisticsRetryCount,
dot11STAStatisticsMultipleRetryCount,
dot11STAStatisticsFrameDuplicateCount,
dot11STAStatisticsRTSSuccessCount,
dot11STAStatisticsRTSFailureCount,
dot11STAStatisticsAckFailureCount,
dot11STAStatisticsQosTransmittedFragmentCount,
dot11STAStatisticsQosFailedCount,
dot11STAStatisticsQosRetryCount,
dot11STAStatisticsQosMultipleRetryCount,
dot11STAStatisticsQosFrameDuplicateCount,
dot11STAStatisticsQosRTSSuccessCount,
dot11STAStatisticsQosRTSFailureCount,
dot11STAStatisticsQosAckFailureCount,
dot11STAStatisticsQosReceivedFragmentCount,
dot11STAStatisticsQosTransmittedFrameCount,
dot11STAStatisticsQosDiscardedFrameCount,
dot11STAStatisticsQosMPDUsReceivedCount,
dot11STAStatisticsQosRetriesReceivedCount,
dot11STAStatisticsReceivedFragmentCount,
dot11STAStatisticsGroupReceivedFrameCount,
dot11STAStatisticsFCSErrorCount,
dot11STAStatisticsTransmittedFrameCount,
dot11STAStatisticsAPAverageAccessDelay,
dot11STAStatisticsAverageAccessDelayBestEffort,
dot11STAStatisticsAverageAccessDelayBackground,
dot11STAStatisticsAverageAccessDelayVideo,
dot11STAStatisticsAverageAccessDelayVoice,
dot11STAStatisticsStationCount,
dot11STAStatisticsChannelUtilization,
dot11STAStatisticsVendorSpecific,
dot11STAStatisticsRprtMeasurementMode,
dot11LCIReportToken,
dot11LCIIfIndex,
dot11LCISTAAddress,
dot11LCILatitudeUncertainty,
3233
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11LCILatitudeInteger,
dot11LCILatitudeFraction,
dot11LCILongitudeUncertainty,
dot11LCILongitudeInteger,
dot11LCILongitudeFraction,
dot11LCIAltitudeType,
dot11LCIAltitudeUncertainty,
dot11LCIAltitude,
dot11LCIDatum,
dot11LCIAzimuthType,
dot11LCIAzimuthResolution,
dot11LCIAzimuth,
dot11LCIVendorSpecific,
dot11LCIRprtMeasurementMode,
dot11TransmitStreamRprtRqstToken,
dot11TransmitStreamRprtIfIndex,
dot11TransmitStreamMeasuringSTAAddr,
dot11TransmitStreamRprtActualStartTime,
dot11TransmitStreamRprtMeasurementDuration,
dot11TransmitStreamRprtPeerSTAAddress,
dot11TransmitStreamRprtTID,
dot11TransmitStreamRprtAverageQueueDelay,
dot11TransmitStreamRprtAverageTransmitDelay,
dot11TransmitStreamRprtTransmittedMSDUCount,
dot11TransmitStreamRprtMSDUDiscardedCount,
dot11TransmitStreamRprtMSDUFailedCount,
dot11TransmitStreamRprtMultipleRetryCount,
dot11TransmitStreamRprtCFPollsLostCount,
dot11TransmitStreamRprtBin0Range,
dot11TransmitStreamRprtDelayHistogram,
dot11TransmitStreamRprtReason,
dot11TransmitStreamRprtVendorSpecific,
dot11TransmitStreamRprtMeasurementMode }
STATUS current
DESCRIPTION
"The SMTRMReport package is a set of attributes that are present if the
STA supports the Radio Measurement service."
::= { dot11Groups 38 }
dot11SMTRMConfig OBJECT-GROUP
OBJECTS {
dot11APChannelReportIfIndex,
dot11APChannelReportOperatingClass,
dot11APChannelReportChannelList,
dot11RMNeighborReportIfIndex,
dot11RMNeighborReportBSSID,
dot11RMNeighborReportAPReachability,
dot11RMNeighborReportSecurity,
dot11RMNeighborReportCapSpectrumMgmt,
dot11RMNeighborReportCapQoS,
dot11RMNeighborReportCapAPSD,
dot11RMNeighborReportCapRM,
dot11RMNeighborReportCapDelayBlockAck,
dot11RMNeighborReportCapImmediateBlockAck,
dot11RMNeighborReportKeyScope,
dot11RMNeighborReportChannelNumber,
dot11RMNeighborReportOperatingClass,
dot11RMNeighborReportPhyType,
dot11RMNeighborReportNeighborTSFInfo,
dot11RMNeighborReportPilotInterval,
dot11RMNeighborReportPilotMultipleBSSID,
dot11RMNeighborReportRMEnabledCapabilities,
dot11RMNeighborReportVendorSpecific,
dot11RMNeighborReportRowStatus,
3234
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMNeighborReportCapHT,
dot11RMNeighborReportHTLDPCCodingCap,
dot11RMNeighborReportHTSupportedChannelWidthSet,
dot11RMNeighborReportHTSMPowerSave,
dot11RMNeighborReportHTGreenfield,
dot11RMNeighborReportHTShortGIfor20MHz,
dot11RMNeighborReportHTShortGIfor40MHz,
dot11RMNeighborReportHTTxSTBC,
dot11RMNeighborReportHTRxSTBC,
dot11RMNeighborReportHTDelayedBlockAck,
dot11RMNeighborReportHTMaxAMSDULength,
dot11RMNeighborReportHTDSSCCKModein40MHz,
dot11RMNeighborReportHTFortyMHzIntolerant,
dot11RMNeighborReportHTLSIGTXOPProtectionSupport,
dot11RMNeighborReportHTMaxAMPDULengthExponent,
dot11RMNeighborReportHTMinMPDUStartSpacing,
dot11RMNeighborReportHTRxMCSBitMask,
dot11RMNeighborReportHTRxHighestSupportedDataRate,
dot11RMNeighborReportHTTxMCSSetDefined,
dot11RMNeighborReportHTTxRxMCSSetNotEqual,
dot11RMNeighborReportHTTxMaxNumberSpatialStreamsSupported,
dot11RMNeighborReportHTTxUnequalModulationSupported,
dot11RMNeighborReportHTPCO,
dot11RMNeighborReportHTPCOTransitionTime,
dot11RMNeighborReportHTMCSFeedback,
dot11RMNeighborReportHTCSupport,
dot11RMNeighborReportHTRDResponder,
dot11RMNeighborReportHTImplictTransmitBeamformingReceivingCap,
dot11RMNeighborReportHTReceiveStaggeredSoundingCap,
dot11RMNeighborReportHTTransmitStaggeredSoundingCap,
dot11RMNeighborReportHTReceiveNDPCap,
dot11RMNeighborReportHTTransmitNDPCap,
dot11RMNeighborReportHTImplicitTransmitBeamformingCap,
dot11RMNeighborReportHTTransmitBeamformingCalibration,
dot11RMNeighborReportHTExplicitCSITransmitBeamformingCap,
dot11RMNeighborReportHTExplicitNonCompressedSteeringCap,
dot11RMNeighborReportHTExplicitCompressedSteeringCap,
dot11RMNeighborReportHTExplicitTransmitBeamformingFeedback,
dot11RMNbRprtHTExplicitNonCompressedBeamformingFeedbackCap,
dot11RMNeighborReportHTExplicitCompressedBeamformingFeedbackCap,
dot11RMNeighborReportHTTransmitBeamformingMinimalGrouping,
dot11RMNbRprtHTCSINumberofTxBeamformingAntennasSuppt,
dot11RMNbRprtHTNonCompressedSteeringNumofTxBmfmingAntennasSuppt,
dot11RMNbRprtHTCompressedSteeringNumberofTxBmfmingAntennasSuppt,
dot11RMNbRprtHTCSIMaxNumberofRowsTxBeamformingSuppt,
dot11RMNeighborReportHTTransmitBeamformingChannelEstimationCap,
dot11RMNeighborReportHTAntSelectionCap,
dot11RMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap,
dot11RMNeighborReportHTAntIndicesFeedbackBasedTxASELCap,
dot11RMNeighborReportHTExplicitCSIFeedbackBasedCap,
dot11RMNeighborReportHTAntIndicesFeedbackCap,
dot11RMNeighborReportHTRxASELCap,
dot11RMNeighborReportHTTxSoundingPPDUsCap,
dot11RMNeighborReportHTInfoPrimaryChannel,
dot11RMNeighborReportHTInfoSecChannelOffset,
dot11RMNeighborReportHTInfoSTAChannelWidth,
dot11RMNeighborReportHTInfoRIFSMode,
dot11RMNeighborReportHTInfoProtection,
dot11RMNeighborReportHTInfoNonGreenfieldHTSTAsPresent,
dot11RMNeighborReportHTInfoOBSSNonHTSTAsPresent,
dot11RMNeighborReportHTInfoDualBeacon,
dot11RMNeighborReportHTInfoDualCTSProtection,
dot11RMNeighborReportHTInfoSTBCBeacon,
dot11RMNeighborReportHTInfoLSIGTXOPProtectionSup,
3235
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMNeighborReportHTInfoPCOActive,
dot11RMNeighborReportHTInfoPCOPhase,
dot11RMNeighborReportHTInfoBasicMCSSet,
dot11RMNeighborReportHTSecChannelOffset,
dot11RMNeighborReportExtCapPSMPSupport,
dot11RMNeighborReportExtCapSPSMPSup,
dot11RMNeighborReportExtCapServiceIntervalGranularity }
STATUS current
DESCRIPTION
"The SMTRMConfig package is a set of attributes that are present if the
STA supports the Radio Measurement service."
::= { dot11Groups 39 }
dot11FTComplianceGroup OBJECT-GROUP
OBJECTS {
-- Dot11FastBSSTransitionConfigEntry
dot11FastBSSTransitionActivated,
dot11FTMobilityDomainID,
dot11FTOverDSActivated,
dot11FTResourceRequestSupported,
dot11FTR0KeyHolderID,
dot11FTR0KeyLifetime,
dot11FTR1KeyHolderID,
dot11FTReassociationDeadline,
-- Dot11RMNeighborReportEntry
dot11RMNeighborReportMobilityDomain }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to manage fast BSS transition functionality. Note that additional objects
for managing this functionality are located in the dot11FastBSS
TransitionConfigTable."
::= { dot11Groups 40}
dot11SMTbase8 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID, dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod, dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11SpectrumManagementImplemented,
dot11SpectrumManagementRequired,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired,
dot11QosOptionImplemented,
dot11ImmediateBlockAckOptionImplemented,
dot11DelayedBlockAckOptionImplemented,
3236
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11DirectOptionImplemented,
dot11APSDOptionImplemented,
dot11QAckOptionImplemented,
dot11QBSSLoadImplemented,
dot11QueueRequestOptionImplemented,
dot11TXOPRequestOptionImplemented,
dot11MoreDataAckOptionImplemented,
dot11AssociateInNQBSS,
dot11DLSAllowedInQBSS,
dot11DLSAllowed,
dot11AssociateStation,
dot11AssociateID,
dot11AssociateFailStation,
dot11AssociateFailStatus,
dot11ReassociateStation,
dot11ReassociateID,
dot11ReassociateFailStation,
dot11ReassociateFailStatus,
dot11RadioMeasurementImplemented,
dot11RadioMeasurementActivated,
dot11RMMeasurementNavSync,
dot11RMMeasurementPilotPeriod,
dot11RMLinkMeasurementActivated,
dot11RMNeighborReportActivated,
dot11RMParallelMeasurementsActivated,
dot11RMRepeatedMeasurementsActivated,
dot11RMBeaconPassiveMeasurementActivated,
dot11RMBeaconActiveMeasurementActivated,
dot11RMBeaconTableMeasurementActivated,
dot11RMBeaconMeasurementReportingConditionsActivated,
dot11RMFrameMeasurementActivated,
dot11RMChannelLoadMeasurementActivated,
dot11RMNoiseHistogramMeasurementActivated,
dot11RMStatisticsMeasurementActivated,
dot11RMLCIMeasurementActivated,
dot11RMLCIAzimuthActivated,
dot11RMTransmitStreamCategoryMeasurementActivated,
dot11RMTriggeredTransmitStreamCategoryMeasurementActivated,
dot11RMAPChannelReportActivated,
dot11RMMIBActivated,
dot11RMMaxMeasurementDuration,
dot11RMNonOperatingChannelMaxMeasurementDuration,
dot11RMMeasurementPilotTransmissionInformationActivated,
dot11RMMeasurementPilotActivated,
dot11RMNeighborReportTSFOffsetActivated,
dot11RMRCPIMeasurementActivated,
dot11RMRSNIMeasurementActivated,
dot11RMBSSAverageAccessDelayActivated,
dot11RMBSSAvailableAdmissionCapacityActivated,
dot11RMAntennaInformationActivated,
dot11FastBSSTransitionImplemented }
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase9.
The SMTbase8 object class provides the necessary support at the STA to
manage the processes in the STA so that the STA may work cooperatively as
a part of an IEEE 802.11 network, when the STA is capable of multidomain
operation. This object group should be implemented when the multidomain
capability option is implemented."
::= { dot11Groups 41 }
dot11PhyOFDMComplianceGroup3 OBJECT-GROUP
OBJECTS {
dot11CurrentFrequency,
3237
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11FrequencyBandsImplemented,
dot11ChannelStartingFactor,
dot11FiveMHzOperationImplemented,
dot11TenMHzOperationImplemented,
dot11TwentyMHzOperationImplemented,
dot11PhyOFDMChannelWidth,
dot11OFDMCCAEDImplemented,
dot11OFDMCCAEDRequired,
dot11OFDMEDThreshold,
dot11STATransmitPowerClass,
dot11ACRType }
STATUS current
DESCRIPTION
"Attributes that configure the OFDM PHY for IEEE Std 802.11."
::= { dot11Groups 42}
dot11SMTbase9 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID, dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod, dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired,
dot11QosOptionImplemented,
dot11ImmediateBlockAckOptionImplemented,
dot11DelayedBlockAckOptionImplemented,
dot11DirectOptionImplemented,
dot11APSDOptionImplemented,
dot11QAckOptionImplemented,
dot11QBSSLoadImplemented,
dot11QueueRequestOptionImplemented,
dot11TXOPRequestOptionImplemented,
dot11MoreDataAckOptionImplemented,
dot11AssociateInNQBSS,
dot11DLSAllowedInQBSS,
dot11DLSAllowed,
dot11RadioMeasurementImplemented,
dot11RadioMeasurementActivated,
dot11FastBSSTransitionImplemented,
dot11LCIDSEImplemented,
dot11LCIDSERequired,
dot11DSERequired,
dot11ExtendedChannelSwitchActivated }
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase10.
3238
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SMTbase9 object class provides the necessary support at the STA to
manage the processes in the STA such that the STA may work cooperatively
as a part of an IEEE 802.11 network, when the STA is capable of
multidomain operation. This object group should be implemented when the
multidomain capability option is implemented."
::= { dot11Groups 43 }
dot11PhyAntennaComplianceGroup2 OBJECT-GROUP
OBJECTS {
dot11CurrentTxAntenna,
dot11DiversitySupportImplemented,
dot11CurrentRxAntenna,
dot11AntennaSelectionOptionImplemented,
dot11TransmitExplicitCSIFeedbackASOptionImplemented,
dot11TransmitIndicesFeedbackASOptionImplemented,
dot11ExplicitCSIFeedbackASOptionImplemented,
dot11TransmitIndicesComputationASOptionImplemented,
dot11ReceiveAntennaSelectionOptionImplemented }
STATUS current
DESCRIPTION
"Attributes for Data Rates for IEEE Std 802.11."
::= { dot11Groups 44 }
dot11MACbase3 OBJECT-GROUP
OBJECTS {
dot11MACAddress,
dot11GroupAddress,
dot11GroupAddressesStatus,
dot11RTSThreshold,
dot11ShortRetryLimit,
dot11LongRetryLimit,
dot11FragmentationThreshold,
dot11MaxTransmitMSDULifetime,
dot11MaxReceiveLifetime,
dot11ManufacturerID,
dot11ProductID,
dot11CAPLimit,
dot11HCCWmin,
dot11HCCWmax,
dot11HCCAIFSN,
dot11ADDBAResponseTimeout,
dot11ADDTSResponseTimeout,
dot11ChannelUtilizationBeaconIntervals,
dot11ScheduleTimeout,
dot11DLSResponseTimeout,
dot11QAPMissingAckRetryLimit,
dot11EDCAAveragingPeriod,
dot11HTProtection,
dot11RIFSMode,
dot11PSMPControlledAccess,
dot11ServiceIntervalGranularity,
dot11DualCTSProtection,
dot11LSIGTXOPFullProtectionActivated,
dot11NonGFEntitiesPresent, dot11PCOActivated,
dot11PCOFortyMaxDuration,
dot11PCOTwentyMaxDuration,
dot11PCOFortyMinDuration,
dot11PCOTwentyMinDuration }
STATUS deprecated
DESCRIPTION
"Superseded by dot11MACbase4.
The MAC object class provides the necessary support for the access
control, generation, and verification of frame check sequences (FCSs), and
proper delivery of valid data to upper layers."
3239
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11Groups 45 }
dot11CountersGroup3 OBJECT-GROUP
OBJECTS {
dot11TransmittedFragmentCount,
dot11TransmittedFrameCount,
dot11FailedCount,
dot11ReceivedFragmentCount,
dot11GroupReceivedFrameCount,
dot11FCSErrorCount,
dot11WEPUndecryptableCount,
dot11TransmittedFrameCount,
dot11QosDiscardedFragmentCount,
dot11AssociatedStationCount,
dot11QosCFPollsReceivedCount,
dot11QosCFPollsUnusedCount,
dot11QosCFPollsUnusableCount,
dot11QosCFPollsLostCount,
dot11TransmittedAMSDUCount,
dot11FailedAMSDUCount,
dot11RetryAMSDUCount,
dot11MultipleRetryAMSDUCount,
dot11TransmittedOctetsInAMSDUCount,
dot11AMSDUAckFailureCount,
dot11ReceivedAMSDUCount,
dot11ReceivedOctetsInAMSDUCount,
dot11TransmittedAMPDUCount,
dot11TransmittedMPDUsInAMPDUCount,
dot11TransmittedOctetsInAMPDUCount,
dot11AMPDUReceivedCount,
dot11MPDUInReceivedAMPDUCount,
dot11ReceivedOctetsInAMPDUCount,
dot11AMPDUDelimiterCRCErrorCount,
dot11ImplicitBARFailureCount,
dot11ExplicitBARFailureCount,
dot11ChannelWidthSwitchCount,
dot11TwentyMHzFrameTransmittedCount,
dot11FortyMHzFrameTransmittedCount,
dot11TwentyMHzFrameReceivedCount,
dot11FortyMHzFrameReceivedCount,
dot11PSMPUTTGrantDuration,
dot11PSMPUTTUsedDuration,
dot11GrantedRDGUsedCount,
dot11GrantedRDGUnusedCount,
dot11TransmittedFramesInGrantedRDGCount,
dot11TransmittedOctetsInGrantedRDGCount,
dot11BeamformingFrameCount,
dot11DualCTSSuccessCount,
dot11DualCTSFailureCount,
dot11STBCCTSSuccessCount,
dot11STBCCTSFailureCount,
dot11nonSTBCCTSSuccessCount,
dot11nonSTBCCTSFailureCount,
dot11RTSLSIGSuccessCount,
dot11RTSLSIGFailureCount }
STATUS deprecated
DESCRIPTION
"Superseded by dot11CountersGroup4.
Attributes from the dot11CountersGroup that are not described in the
dot11MACStatistics group. These objects are mandatory."
::= { dot11Groups 46 }
dot11SMTbase10 OBJECT-GROUP
OBJECTS {
3240
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID,
dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod,
dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired,
dot11QosOptionImplemented,
dot11ImmediateBlockAckOptionImplemented,
dot11DelayedBlockAckOptionImplemented,
dot11DirectOptionImplemented,
dot11APSDOptionImplemented,
dot11QAckOptionImplemented,
dot11QBSSLoadImplemented,
dot11QueueRequestOptionImplemented,
dot11TXOPRequestOptionImplemented,
dot11MoreDataAckOptionImplemented,
dot11AssociateInNQBSS,
dot11DLSAllowedInQBSS,
dot11DLSAllowed,
dot11AssociateStation,
dot11AssociateID,
dot11AssociateFailStation,
dot11AssociateFailStatus,
dot11ReassociateStation,
dot11ReassociateID,
dot11ReassociateFailStation,
dot11ReassociateFailStatus,
dot11RadioMeasurementImplemented,
dot11RadioMeasurementActivated,
dot11FastBSSTransitionImplemented,
dot11LCIDSEImplemented,
dot11LCIDSERequired,
dot11DSERequired,
dot11ExtendedChannelSwitchActivated,
dot11HighThroughputOptionImplemented,
dot11RSNAPBACRequired,
dot11PSMPOptionImplemented }
STATUS deprecated
DESCRIPTION
"Superceded by dot11SMTbase 11.
The SMTbase10 object class provides the necessary support at the STA to
manage the processes in the STA such that the STA may work cooperatively
as a part of an IEEE 802.11 network."
::= { dot11Groups 47 }
3241
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11PhyMCSGroup OBJECT-GROUP
OBJECTS {
dot11SupportedMCSTxValue,
dot11SupportedMCSRxValue }
STATUS current
DESCRIPTION
"Attributes for MCS for IEEE 802.11 HT."
::= { dot11Groups 48 }
dot11PhyHTComplianceGroup OBJECT-GROUP
OBJECTS {
dot11HighThroughputOptionImplemented,
dot11FortyMHzOperationImplemented,
dot11FortyMHzOperationActivated,
dot11FortyMHzIntolerant,
dot11FortyMHzOptionImplemented,
dot11CurrentPrimaryChannel,
dot11CurrentSecondaryChannel,
dot11HTGreenfieldOptionImplemented,
dot11HTGreenfieldOptionActivated,
dot11ShortGIOptionInTwentyImplemented,
dot11ShortGIOptionInTwentyActivated,
dot11ShortGIOptionInFortyImplemented,
dot11ShortGIOptionInFortyActivated,
dot11LDPCCodingOptionImplemented,
dot11LDPCCodingOptionActivated,
dot11TxSTBCOptionImplemented,
dot11TxSTBCOptionActivated,
dot11RxSTBCOptionImplemented,
dot11RxSTBCOptionActivated,
dot11BeamFormingOptionImplemented,
dot11BeamFormingOptionActivated,
dot11NumberOfSpatialStreamsImplemented,
dot11NumberOfSpatialStreamsActivated,
dot11HighestSupportedDataRate,
dot11TxMCSSetDefined,
dot11TxRxMCSSetNotEqual,
dot11TxMaximumNumberSpatialStreamsSupported,
dot11TxUnequalModulationSupported,
dot11TransmitSoundingPPDUOptionImplemented,
dot11NumberOfActiveRxAntennas }
STATUS current
DESCRIPTION
"Attributes that configure the HT PHY for IEEE Std 802.11."
::= { dot11Groups 49 }
dot11HTMACAdditions OBJECT-GROUP
OBJECTS {
dot11HTOperationalMCSSet,
dot11MIMOPowerSave,
dot11NDelayedBlockAckOptionImplemented,
dot11MaxAMSDULength,
dot11STBCControlFrameOptionImplemented,
dot11LsigTxopProtectionOptionImplemented,
dot11MaxRxAMPDUFactor,
dot11MinimumMPDUStartSpacing,
dot11PCOOptionImplemented,
dot11TransitionTime,
dot11MCSFeedbackOptionImplemented,
dot11HTControlFieldSupported,
dot11RDResponderOptionImplemented,
dot11BSSWidthTriggerScanInterval,
dot11BSSWidthChannelTransitionDelayFactor,
dot11OBSSScanPassiveDwell,
3242
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11OBSSScanActiveDwell,
dot11OBSSScanPassiveTotalPerChannel,
dot11OBSSScanActiveTotalPerChannel,
dot112040BSSCoexistenceManagementSupport,
dot11OBSSScanActivityThreshold,
dot11SPPAMSDUCapable,
dot11SPPAMSDURequired }
STATUS deprecated
DESCRIPTION
"Deprecated as contains an object no longer used by IEEE Std 802.11-2016
Attributes that configure the HT PHY for IEEE Std 802.11."
::= { dot11Groups 50 }
dot11TransmitBeamformingGroup OBJECT-GROUP
OBJECTS {
dot11ReceiveStaggerSoundingOptionImplemented,
dot11TransmitStaggerSoundingOptionImplemented,
dot11ReceiveNDPOptionImplemented,
dot11TransmitNDPOptionImplemented,
dot11ImplicitTransmitBeamformingOptionImplemented,
dot11CalibrationOptionImplemented,
dot11ExplicitCSITransmitBeamformingOptionImplemented,
dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented,
dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented,
dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented,
dot11ExplicitCompressedBeamformingFeedbackOptionImplemented,
dot11NumberBeamFormingCSISupportAntenna,
dot11NumberNonCompressedBeamformingMatrixSupportAntenna,
dot11NumberCompressedBeamformingMatrixSupportAntenna }
STATUS current
DESCRIPTION
"Attributes that configure the Beamforming for IEEE 802.11 HT."
::= { dot11Groups 51 }
dot11SMTbase11 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID,
dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod,
dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11SpectrumManagementImplemented,
dot11SpectrumManagementRequired,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired,
3243
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11QosOptionImplemented,
dot11ImmediateBlockAckOptionImplemented,
dot11DelayedBlockAckOptionImplemented,
dot11DirectOptionImplemented,
dot11APSDOptionImplemented,
dot11QAckOptionImplemented,
dot11QBSSLoadImplemented,
dot11QueueRequestOptionImplemented,
dot11TXOPRequestOptionImplemented,
dot11MoreDataAckOptionImplemented,
dot11AssociateInNQBSS,
dot11DLSAllowedInQBSS,
dot11DLSAllowed,
dot11AssociateStation,
dot11AssociateID,
dot11AssociateFailStation,
dot11AssociateFailStatus,
dot11ReassociateStation,
dot11ReassociateID,
dot11ReassociateFailStation,
dot11ReassociateFailStatus,
dot11RadioMeasurementImplemented,
dot11RadioMeasurementActivated,
dot11RMMeasurementNavSync,
dot11RMMeasurementPilotPeriod,
dot11RMLinkMeasurementActivated,
dot11RMNeighborReportActivated,
dot11RMParallelMeasurementsActivated,
dot11RMRepeatedMeasurementsActivated,
dot11RMBeaconPassiveMeasurementActivated,
dot11RMBeaconActiveMeasurementActivated,
dot11RMBeaconTableMeasurementActivated,
dot11RMBeaconMeasurementReportingConditionsActivated,
dot11RMFrameMeasurementActivated,
dot11RMChannelLoadMeasurementActivated,
dot11RMNoiseHistogramMeasurementActivated,
dot11RMStatisticsMeasurementActivated,
dot11RMLCIMeasurementActivated,
dot11RMLCIAzimuthActivated,
dot11RMTransmitStreamCategoryMeasurementActivated,
dot11RMTriggeredTransmitStreamCategoryMeasurementActivated,
dot11RMAPChannelReportActivated,
dot11RMMIBActivated,
dot11RMMaxMeasurementDuration,
dot11RMNonOperatingChannelMaxMeasurementDuration,
dot11RMMeasurementPilotTransmissionInformationActivated,
dot11RMMeasurementPilotActivated,
dot11RMNeighborReportTSFOffsetActivated,
dot11RMRCPIMeasurementActivated,
dot11RMRSNIMeasurementActivated,
dot11RMBSSAverageAccessDelayActivated,
dot11RMBSSAvailableAdmissionCapacityActivated,
dot11FastBSSTransitionImplemented,
dot11LCIDSEImplemented,
dot11LCIDSERequired,
dot11DSERequired,
dot11ExtendedChannelSwitchActivated,
dot11HighThroughputOptionImplemented,
dot11WirelessManagementImplemented,
dot11RSNAPBACRequired,
dot11PSMPOptionImplemented }
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase12.
3244
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SMTbase11 object class provides the necessary support at the STA to
manage the processes in the STA so that the STA may work cooperatively as
a part of an IEEE 802.11 network, when the STA is capable of multidomain
operation. This object group should be implemented when the multidomain
capability option is implemented."
::= { dot11Groups 53 }
dot11SMTWNMRequest OBJECT-GROUP
OBJECTS { dot11WNMRqstRowSta-
tus,
dot11WNMRqstToken,
dot11WNMRqstIfIndex,
dot11WNMRqstType,
dot11WNMRqstTargetAdd,
dot11WNMRqstTimeStamp,
dot11WNMRqstRndInterval,
dot11WNMRqstDuration,
dot11WNMRqstMcstGroup,
dot11WNMRqstMcstTrigCon,
dot11WNMRqstMcstTrigInactivityTimeout,
dot11WNMRqstMcstTrigReactDelay,
dot11WNMRqstLCRRqstSubject,
dot11WNMRqstLCRIntervalUnits,
dot11WNMRqstLCRServiceInterval,
dot11WNMRqstLIRRqstSubject,
dot11WNMRqstLIRIntervalUnits,
dot11WNMRqstLIRServiceInterval,
dot11WNMRqstEventToken,
dot11WNMRqstEventType,
dot11WNMRqstEventResponseLimit,
dot11WNMRqstEventTargetBssid,
dot11WNMRqstEventSourceBssid,
dot11WNMRqstEventTransitTimeThresh,
dot11WNMRqstEventTransitMatchValue,
dot11WNMRqstEventFreqTransitCountThresh,
dot11WNMRqstEventFreqTransitInterval,
dot11WNMRqstEventRsnaAuthType,
dot11WNMRqstEapType,
dot11WNMRqstEapVendorId,
dot11WNMRqstEapVendorType,
dot11WNMRqstEventRsnaMatchValue,
dot11WNMRqstEventPeerMacAddress,
dot11WNMRqstOperatingClass,
dot11WNMRqstChanNumber,
dot11WNMRqstDiagToken,
dot11WNMRqstDiagType,
dot11WNMRqstDiagTimeout,
dot11WNMRqstDiagBssid,
dot11WNMRqstDiagProfileId,
dot11WNMRqstDiagCredentials,
dot11WNMRqstLocConfigLocIndParams,
dot11WNMRqstLocConfigChanList,
dot11WNMRqstLocConfigBcastRate,
dot11WNMRqstLocConfigOptions,
dot11WNMRqstBssTransitQueryReason,
dot11WNMRqstBssTransitReqMode,
dot11WNMRqstBssTransitDisocTimer,
dot11WNMRqstBssTransitSessInfoURL,
dot11WNMRqstBssTransitCandidateList,
dot11WNMRqstColocInterfAutoEnable,
dot11WNMRqstColocInterfRptTimeout,
dot11WNMRqstVendorSpecific }
STATUS current
DESCRIPTION
3245
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"The SMTWNMRequest package is a set of attributes that shall be present if
the STA supports the WNM service."
::= { dot11Groups 54 }
dot11SMTWNMReport OBJECT-GROUP
OBJECTS {
dot11WNMVendorSpecificRprtRqstToken,
dot11WNMVendorSpecificRprtIfIndex,
dot11WNMVendorSpecificRprtContent,
dot11WNMMulticastDiagnosticRprtRqstToken,
dot11WNMMulticastDiagnosticRprtIfIndex,
dot11WNMMulticastDiagnosticRprtMeasurementTime,
dot11WNMMulticastDiagnosticRprtDuration,
dot11WNMMulticastDiagnosticRprtMcstGroup,
dot11WNMMulticastDiagnosticRprtReason,
dot11WNMMulticastDiagnosticRprtRcvdMsduCount,
dot11WNMMulticastDiagnosticRprtFirstSeqNumber,
dot11WNMMulticastDiagnosticRprtLastSeqNumber,
dot11WNMMulticastDiagnosticRprtMcstRate,
dot11WNMLocationCivicRprtRqstToken,
dot11WNMLocationCivicRprtIfIndex,
dot11WNMLocationCivicRprtCivicLocation,
dot11WNMLocationIdentifierRprtRqstToken,
dot11WNMLocationIdentifierRprtIfIndex,
dot11WNMLocationIdentifierRprtExpirationTSF,
dot11WNMLocationIdentifierRprtPublicIdUri,
dot11WNMEventTransitRprtRqstToken,
dot11WNMEventTransitRprtIfIndex,
dot11WNMEventTransitRprtEventStatus,
dot11WNMEventTransitRprtEventTSF,
dot11WNMEventTransitRprtUTCOffset,
dot11WNMEventTransitRprtTimeError,
dot11WNMEventTransitRprtSourceBssid,
dot11WNMEventTransitRprtTargetBssid,
dot11WNMEventTransitRprtTransitTime,
dot11WNMEventTransitRprtTransitReason,
dot11WNMEventTransitRprtTransitResult,
dot11WNMEventTransitRprtSourceRCPI,
dot11WNMEventTransitRprtSourceRSNI,
dot11WNMEventTransitRprtTargetRCPI,
dot11WNMEventTransitRprtTargetRSNI,
dot11WNMEventRsnaRprtRqstToken,
dot11WNMEventRsnaRprtIfIndex,
dot11WNMEventRsnaRprtEventStatus,
dot11WNMEventRsnaRprtEventTSF,
dot11WNMEventRsnaRprtUTCOffset,
dot11WNMEventRsnaRprtTimeError,
dot11WNMEventRsnaRprtTargetBssid,
dot11WNMEventRsnaRprtAuthType,
dot11WNMEventRsnaRprtEapMethod,
dot11WNMEventRsnaRprtResult,
dot11WNMEventRsnaRprtRsnElement,
dot11WNMEventPeerRprtRqstToken,
dot11WNMEventPeerRprtIfIndex,
dot11WNMEventPeerRprtEventStatus,
dot11WNMEventPeerRprtEventTSF,
dot11WNMEventPeerRprtUTCOffset,
dot11WNMEventPeerRprtTimeError,
dot11WNMEventPeerRprtPeerMacAddress,
dot11WNMEventPeerRprtOperatingClass,
dot11WNMEventPeerRprtChanNumber,
dot11WNMEventPeerRprtStaTxPower,
dot11WNMEventPeerRprtConnTime,
dot11WNMEventPeerRprtPeerStatus,
3246
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMEventWNMLogRprtRqstToken,
dot11WNMEventWNMLogRprtIfIndex,
dot11WNMEventWNMLogRprtEventStatus,
dot11WNMEventWNMLogRprtEventTSF,
dot11WNMEventWNMLogRprtUTCOffset,
dot11WNMEventWNMLogRprtTimeError,
dot11WNMEventWNMLogRprtContent,
dot11WNMDiagMfrInfoRprtRqstToken,
dot11WNMDiagMfrInfoRprtIfIndex,
dot11WNMDiagMfrInfoRprtEventStatus,
dot11WNMDiagMfrInfoRprtMfrOi,
dot11WNMDiagMfrInfoRprtMfrIdString,
dot11WNMDiagMfrInfoRprtMfrModelString,
dot11WNMDiagMfrInfoRprtMfrSerialNumberString,
dot11WNMDiagMfrInfoRprtMfrFirmwareVersion,
dot11WNMDiagMfrInfoRprtMfrAntennaType,
dot11WNMDiagMfrInfoRprtCollocRadioType,
dot11WNMDiagMfrInfoRprtDeviceType,
dot11WNMDiagMfrInfoRprtCertificateID,
dot11WNMDiagConfigProfRprtRqstToken,
dot11WNMDiagConfigProfRprtIfIndex,
dot11WNMDiagConfigProfRprtEventStatus,
dot11WNMDiagConfigProfRprtProfileId,
dot11WNMDiagConfigProfRprtSupportedOperatingClasses,
dot11WNMDiagConfigProfRprtTxPowerMode,
dot11WNMDiagConfigProfRprtTxPowerLevels,
dot11WNMDiagConfigProfRprtCipherSuite,
dot11WNMDiagConfigProfRprtAkmSuite,
dot11WNMDiagConfigProfRprtEapType,
dot11WNMDiagConfigProfRprtEapVendorID,
dot11WNMDiagConfigProfRprtEapVendorType,
dot11WNMDiagConfigProfRprtCredentialType,
dot11WNMDiagConfigProfRprtSSID,
dot11WNMDiagConfigProfRprtPowerSaveMode,
dot11WNMDiagAssocRprtRqstToken,
dot11WNMDiagAssocRprtIfIndex,
dot11WNMDiagAssocRprtEventStatus,
dot11WNMDiagAssocRprtBssid,
dot11WNMDiagAssocRprtOperatingClass,
dot11WNMDiagAssocRprtChannelNumber,
dot11WNMDiagAssocRprtStatusCode,
dot11WNMDiag8021xAuthRprtRqstToken,
dot11WNMDiag8021xAuthRprtIfIndex,
dot11WNMDiag8021xAuthRprtEventStatus,
dot11WNMDiag8021xAuthRprtBssid,
dot11WNMDiag8021xAuthRprtOperatingClass,
dot11WNMDiag8021xAuthRprtChannelNumber,
dot11WNMDiag8021xAuthRprtEapType,
dot11WNMDiag8021xAuthRprtEapVendorID,
dot11WNMDiag8021xAuthRprtEapVendorType,
dot11WNMDiag8021xAuthRprtCredentialType,
dot11WNMDiag8021xAuthRprtStatusCode,
dot11WNMLocConfigRprtRqstToken,
dot11WNMLocConfigRprtIfIndex,
dot11WNMLocConfigRprtLocIndParams,
dot11WNMLocConfigRprtLocIndChanList,
dot11WNMLocConfigRprtLocIndBcastRate,
dot11WNMLocConfigRprtLocIndOptions,
dot11WNMLocConfigRprtStatusConfigSubelemId,
dot11WNMLocConfigRprtStatusResult,
dot11WNMLocConfigRprtVendorSpecificRprtContent,
dot11WNMBssTransitRprtRqstToken,
dot11WNMBssTransitRprtIfIndex,
dot11WNMBssTransitRprtStatusCode,
3247
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11WNMBssTransitRprtBSSTerminationDelay,
dot11WNMBssTransitRprtTargetBssid,
dot11WNMBssTransitRprtCandidateList,
dot11WNMColocInterfRprtRqstToken,
dot11WNMColocInterfRprtIfIndex,
dot11WNMColocInterfRprtPeriod,
dot11WNMColocInterfRprtInterfLevel,
dot11WNMColocInterfRprtInterfAccuracy,
dot11WNMColocInterfRprtInterfIndex,
dot11WNMColocInterfRprtInterfInterval,
dot11WNMColocInterfRprtInterfBurstLength,
dot11WNMColocInterfRprtInterfStartTime,
dot11WNMColocInterfRprtInterfCenterFreq,
dot11WNMColocInterfRprtInterfBandwidth }
STATUS current
DESCRIPTION
"The SMTWNMReport package is a set of attributes that shall be present if
the STA supports the WNM service."
::= { dot11Groups 55 }
dot11SMTbase12 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11AuthenticationResponseTimeout,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID,
dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod,
dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11SpectrumManagementImplemented,
dot11SpectrumManagementRequired,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired,
dot11QosOptionImplemented,
dot11ImmediateBlockAckOptionImplemented,
dot11DelayedBlockAckOptionImplemented,
dot11DirectOptionImplemented,
dot11APSDOptionImplemented,
dot11QAckOptionImplemented,
dot11QBSSLoadImplemented,
dot11QueueRequestOptionImplemented,
dot11TXOPRequestOptionImplemented,
dot11MoreDataAckOptionImplemented,
dot11AssociateInNQBSS,
dot11DLSAllowedInQBSS,
dot11DLSAllowed,
dot11AssociateStation,
dot11AssociateID,
3248
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11AssociateFailStation,
dot11AssociateFailStatus,
dot11ReassociateStation,
dot11ReassociateID,
dot11ReassociateFailStation,
dot11ReassociateFailStatus,
dot11RadioMeasurementImplemented,
dot11RadioMeasurementActivated,
dot11RMMeasurementNavSync,
dot11RMMeasurementPilotPeriod,
dot11RMLinkMeasurementActivated,
dot11RMNeighborReportActivated,
dot11RMParallelMeasurementsActivated,
dot11RMRepeatedMeasurementsActivated,
dot11RMBeaconPassiveMeasurementActivated,
dot11RMBeaconActiveMeasurementActivated,
dot11RMBeaconTableMeasurementActivated,
dot11RMBeaconMeasurementReportingConditionsActivated,
dot11RMFrameMeasurementActivated,
dot11RMChannelLoadMeasurementActivated,
dot11RMNoiseHistogramMeasurementActivated,
dot11RMStatisticsMeasurementActivated,
dot11RMLCIMeasurementActivated,
dot11RMLCIAzimuthActivated,
dot11RMTransmitStreamCategoryMeasurementActivated,
dot11RMTriggeredTransmitStreamCategoryMeasurementActivated,
dot11RMAPChannelReportActivated,
dot11RMMIBActivated,
dot11RMMaxMeasurementDuration,
dot11RMNonOperatingChannelMaxMeasurementDuration,
dot11RMMeasurementPilotTransmissionInformationActivated,
dot11RMMeasurementPilotActivated,
dot11RMNeighborReportTSFOffsetActivated,
dot11RMRCPIMeasurementActivated,
dot11RMRSNIMeasurementActivated,
dot11RMBSSAverageAccessDelayActivated,
dot11RMBSSAvailableAdmissionCapacityActivated,
dot11FastBSSTransitionImplemented,
dot11LCIDSEImplemented,
dot11LCIDSERequired,
dot11DSERequired,
dot11ExtendedChannelSwitchActivated,
dot11HighThroughputOptionImplemented,
dot11WirelessManagementImplemented,
dot11MeshActivated,
dot11RSNAPBACRequired,
dot11PSMPOptionImplemented}
STATUS deprecated
DESCRIPTION
"Superseded by dot11SMTbase13.
The SMTbase12 object class provides the necessary support at the STA to
manage the processes in the STA such that the STA may work cooperatively
as a part of an IEEE 802.11 network."
::= { dot11Groups 57 }
dot11OperatingClassesGroup OBJECT-GROUP
OBJECTS {
dot11OperatingClass,
dot11CoverageClass }
STATUS current
DESCRIPTION
"Attributes that configure the OFDM PHY for IEEE Std 802.11 in many
regulatory domains."
3249
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
::= { dot11Groups 58 }
dot11PhyOperationComplianceGroup2 OBJECT-GROUP
OBJECTS { dot11PHYType, dot11CurrentRegDomain }
STATUS current
DESCRIPTION
"PHY operations attributes."
::= { dot11Groups 59 }
dot11MeshComplianceGroup OBJECT-GROUP
OBJECTS {
-- dot11MeshSTAConfigTable
dot11MeshID,
dot11MeshNumberOfPeerings,
dot11MeshAcceptingAdditionalPeerings,
dot11MeshConnectedToMeshGate,
dot11MeshSecurityActivated,
dot11MeshActiveAuthenticationProtocol,
dot11MeshMaxRetries,
dot11MeshRetryTimeout,
dot11MeshConfirmTimeout,
dot11MeshHoldingTimeout,
dot11MeshActivePathSelectionProtocol,
dot11MeshActivePathSelectionMetric,
dot11MeshForwarding,
dot11MeshTTL,
dot11MeshGateAnnouncements,
dot11MeshActiveCongestionControlMode,
dot11MeshActiveSynchronizationMethod,
dot11MeshNbrOffsetMaxNeighbor,
dot11MBCAActivated,
dot11MCCAImplemented,
dot11MCCAActivated }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to manage mandatory mesh functionality. Note that additional objects for
managing mesh functionality are located in the dot11MeshOptionGroup,
dot11MeshHWMPComplianceGroup, and dot11PasswordAuthComplianceGroup."
::= { dot11Groups 56}
dot11MeshOptionGroup OBJECT-GROUP
OBJECTS {
-- dot11MeshSTAConfigTable
dot11MeshConfigGroupUpdateCount,
dot11MeshGateAnnouncementInterval,
dot11MeshBeaconTimingReportInterval,
dot11MeshBeaconTimingReportMaxNum,
dot11MeshDelayedBeaconTxInterval,
dot11MeshDelayedBeaconTxMaxDelay,
dot11MeshDelayedBeaconTxMinDelay,
dot11MeshAverageBeaconFrameDuration,
dot11MeshSTAMissingAckRetryLimit,
dot11MeshAwakeWindowDuration,
dot11MAFlimit,
dot11MCCAScanDuration,
dot11MCCAAdvertPeriodMax,
dot11MCCAMinTrackStates,
dot11MCCAMaxTrackStates,
dot11MCCAOPtimeout,
dot11MCCACWmin,
dot11MCCACWmax,
dot11MCCAAIFSN
3250
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
}
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to manage optional mesh functionality. Note that other objects for
managing mesh functionality are located in the dot11MeshComplianceGroup,
dot11MeshHWMPComplianceGroup, and dot11PasswordAuthComplianceGroup."
::= { dot11Groups 60 }
dot11MeshHWMPComplianceGroup OBJECT-GROUP
OBJECTS {
-- dot11MeshHWMPConfigTable
dot11MeshHWMPmaxPREQretries,
dot11MeshHWMPnetDiameter,
dot11MeshHWMPnetDiameterTraversalTime,
dot11MeshHWMPpreqMinInterval,
dot11MeshHWMPperrMinInterval,
dot11MeshHWMPactivePathToRootTimeout,
dot11MeshHWMPactivePathTimeout,
dot11MeshHWMProotMode,
dot11MeshHWMProotInterval,
dot11MeshHWMPrannInterval,
dot11MeshHWMPtargetOnly,
dot11MeshHWMPmaintenanceInterval,
dot11MeshHWMPconfirmationInterval }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to manage HWMP path selection functionality. Note that other objects for
managing mesh functionality are located in the dot11MeshComplianceGroup,
dot11MeshOptionGroup, and dot11PasswordAuthComplianceGroup."
::= { dot11Groups 61 }
dot11PasswordAuthComplianceGroup OBJECT-GROUP
OBJECTS {
-- dot11RSNAConfigTable
dot11RSNASAERetransPeriod,
dot11RSNASAEAntiCloggingThreshold,
dot11RSNASAESync,
-- dot11RSNAConfigPasswordValueTable
-- dot11RSNAConfigPasswordValueIndex,
dot11RSNAConfigPasswordCredential,
dot11RSNAConfigPasswordPeerMac,
-- dot11RSNAConfigDLCGroupTable
-- dot11RSNAConfigDLCGroupIndex,
dot11RSNAConfigDLCGroupIdentifier }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to manage password authentication. Note that other objects for managing
mesh functionality are located in the dot11MeshComplianceGroup,
dot11MeshOptionGroup, and dot11MeshHWMPComplianceGroup."
::= { dot11Groups 62 }
dot11QMFComplianceGroup OBJECT-GROUP
OBJECTS {
dot11QMFActivated,
dot11QMFReconfigurationActivated,
dot11QMFPolicyChangeTimeout }
STATUS current
DESCRIPTION
"This object group provides the objects from the IEEE 802.11 MIB required
3251
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
to manage QoS Management Frame functionality."
::= { dot11Groups 63 }
dot11DMGComplianceGroup OBJECT-GROUP
OBJECTS {dot11MultibandImplemented, dot11DMGOptionImplemented,
dot11RelayActivated, dot11REDSActivated, dot11RDSActivated,
dot11RSNAProtectedManagementFramesActivated,
dot11MultipleMACActivated,
dot11ClusteringActivated,
dot11LowPowerSCPHYImplemented,
dot11LowPowerSCPHYActivated
}
STATUS current
DESCRIPTION
"Attributes that configure the DMG Group for IEEE Std 802.11."
::= { dot11Groups 64 }
dot11DMGOperationsComplianceGroup OBJECT-GROUP
OBJECTS {dot11MaxLostBeacons, dot11MinBHIDuration,
dot11PSRequestSuspensionInterval,
dot11BroadcastSTAInfoDuration, dot11NbrOfChangeBeacons,
dot11ImplicitHandoverLostBeacons, dot11MinPPDuration,
dot11SPIdleTimeout, dot11QABTimeout, dot11ClusterEnableTime,
dot11PNWarningThresholdLow,dot11PNWarningThresholdHigh,
dot11BeaconSPDuration,
dot11PNExhaustionThresholdLow,dot11PNExhaustionThresholdHigh,
dot11MaxNumberOfClusteringMonitoringPeriods,
dot11DMGEcssPolicyDetailUpdateDurationMax,
dot11DMGEcssClusterReportDurationMin,
dot11DMGNavSync
}
STATUS current
DESCRIPTION
"Attributes that configure the DMG Operation for IEEE Std 802.11."
::= { dot11Groups 65 }
dot11DMGBeamformingComplianceGroup OBJECT-GROUP
OBJECTS {dot11MaxBFTime, dot11BFTXSSTime, dot11MaximalSectorScan,
dot11ABFTRTXSSSwitch, dot11RSSRetryLimit, dot11RSSBackoff,
dot11BFRetryLimit, dot11BFTXSSTime,
dot11BeamLinkMaintenanceTime,dot11BeamTrackingTimeLimit
}
STATUS current
DESCRIPTION
"Attributes that configure the DMG Beamforming functionality
for IEEE Std 802.11."
::= { dot11Groups 66 }
dot11DMGCountersComplianceGroup OBJECT-GROUP
OBJECTS {dot11RSNAStatsGCMPReplays,
dot11RSNAStatsRobustMgmtGCMPReplays
}
STATUS current
DESCRIPTION
"Attributes that are used as counters for a DMG capable Station
for IEEE Std 802.11."
::= { dot11Groups 67 }
dot11AVSBase OBJECT-GROUP
OBJECTS {
dot11RobustAVStreamingImplemented,
dot11GCRActivated,
dot11AdvancedGCRImplemented,
3252
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11AdvancedGCRActivated,
dot11SCSImplemented,
dot11SCSActivated,
dot11QLoadReportActivated,
dot11AlternateEDCAActivated,
dot11PublicHCCATXOPNegotiationActivated,
dot11GCRGroupMembershipAnnouncementActivated,
dot11MeshGCRImplemented,
dot11MeshGCRActivated,
dot11PublicHCCATXOPNegotiationImplemented,
dot11PublicHCCATXOPNegotiationActivated,
dot11ProtectedHCCATXOPNegotiationImplemented,
dot11ProtectedHCCATXOPNegotiationActivated,
dot11ProtectedQLoadReportImplemented,
dot11ProtectedQLoadReportActivated,
dot11QLoadReportIntervalDTIM,
dot11HCCATXOPBeaconTimeout,
dot11GCRConcealmentAddress,
dot11GCRPolicyChangeTimeout,
dot11QLoadReportDelay,
dot11DefaultSurplusBandwidthAllowance,
dot11ShortDEIRetryLimit,
dot11LongDEIRetryLimit,
dot11UnsolicitedRetryLimit,
dot11STAStatisticsAverageMSDUSizeVideo,
dot11STAStatisticsAverageMSDUSizeVoice,
dot11STAStatisticsAverageBitrateVideo,
dot11STAStatisticsAverageBitrateVoice
}
STATUS current
DESCRIPTION
"The AVSBase package is a set of attributes that are present if the STA
supports the robust audio video streaming features."
::= { dot11Groups 68 }
dot11AVSAPCGroup OBJECT-GROUP
OBJECTS {
dot11APCEntryAvoidanceDuration,
dot11APCEntryAvoidanceServiceInterval,
dot11APCEntryAvoidanceOffset,
dot11APCEntryMACAddress
}
STATUS current
DESCRIPTION
"The AVSAPCGroup package is a set of attributes that are present if the
STA supports HCCA TXOP negotiation."
::= { dot11Groups 69 }
dot11TVWSComplianceGroup OBJECT-GROUP
OBJECTS {
dot11ChannelScheduleManagementActivated,
dot11ContactVerificationSignalActivated,
dot11NetworkChannelControlActivated,
dot11WhiteSpaceMapActivated,
dot11GDDActivated,
dot11TVHTOptionImplemented
}
STATUS current
DESCRIPTION
"Attributes that configure the TVWS Group for IEEE Std 802.11."
::= { dot11Groups 70 }
dot11SpectrumManagementGroup OBJECT-GROUP
3253
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
OBJECTS {
-- Dot11SpectrumManagementEntry
-- dot11SpectrumManagementIndex,
dot11ChannelSwitchTime,
dot11PowerCapabilityMaxImplemented,
dot11PowerCapabilityMinImplemented }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB for
spectrum management."
::= { dot11Groups 72 }
dot11ProtectedManagementFrameGroup OBJECT-GROUP
OBJECTS {
-- Dot11StationConfigEntry
dot11RSNAProtectedManagementFramesActivated,
dot11RSNAUnprotectedManagementFramesAllowed,
dot11AssociationSAQueryMaximumTimeout,
dot11AssociationSAQueryRetryTimeout,
-- dot11RSNAStatsEntry
dot11RSNAStatsCMACReplays,
dot11RSNAStatsRobustMgmtCCMPReplays,
dot11RSNAStatsBIPMICErrors}
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to operate management frame protection."
::= { dot11Groups 73 }
dot11LCIDSEGroup OBJECT-GROUP
OBJECTS {
-- Dot11LCIDSEEntry
-- dot11LCIDSEIndex,
dot11LCIDSEIfIndex,
dot11LCIDSECurrentOperatingClass,
dot11LCIDSELatitudeUncertainty,
dot11LCIDSELatitudeInteger,
dot11LCIDSELatitudeFraction,
dot11LCIDSELongitudeUncertainty,
dot11LCIDSELongitudeInteger,
dot11LCIDSELongitudeFraction,
dot11LCIDSEAltitudeType,
dot11LCIDSEAltitudeUncertainty,
dot11LCIDSEAltitude,
dot11LCIDSEDatum,
dot11RegLocAgreement,
dot11RegLocDSE,
dot11DependentSTA,
dot11DependentEnablementIdentifier,
dot11DSEEnablementTimeLimit,
dot11DSEEnablementFailHoldTime,
dot11DSERenewalTime,
dot11DSETransmitDivisor }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to enable 3650-3700 MHz Operation in USA."
::= { dot11Groups 74 }
dot11TDLSComplianceGroup OBJECT-GROUP
OBJECTS {
-- Dot11StationConfigEntry
dot11TunneledDirectLinkSetupImplemented,
dot11TDLSPeerUAPSDBufferSTAActivated,
3254
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11TDLSPeerPSMActivated,
dot11TDLSPeerUAPSDIndicationWindow,
dot11TDLSChannelSwitchingActivated,
dot11TDLSPeerSTAMissingAckRetryLimit,
dot11TDLSResponseTimeout,
dot11OCBActivated,
dot11TDLSNavSync,
dot11TDLSDiscoveryRequestWindow,
dot11TDLSACDeterminationInterval }
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to operate tunneled direct link setup."
::= { dot11Groups 75 }
dot11VHTTransmitBeamformingGroup OBJECT-GROUP
OBJECTS {
dot11VHTSUBeamformeeOptionImplemented,
dot11VHTSUBeamformerOptionImplemented,
dot11VHTMUBeamformeeOptionImplemented,
dot11VHTMUBeamformerOptionImplemented,
dot11VHTNumberSoundingDimensions,
dot11VHTBeamformeeNTxSupport }
STATUS current
DESCRIPTION
"Attributes that configure VHT transmit beamforming for IEEE Std 802.11."
::= { dot11Groups 76 }
dot11PhyVHTComplianceGroup OBJECT-GROUP
OBJECTS {
dot11VHTChannelWidthOptionImplemented,
dot11CurrentChannelWidth,
dot11CurrentChannelCenterFrequencyIndex0,
dot11CurrentChannelCenterFrequencyIndex1,
dot11VHTShortGIOptionIn80Implemented,
dot11VHTShortGIOptionIn80Activated,
dot11VHTShortGIOptionIn160and80p80Implemented,
dot11VHTShortGIOptionIn160and80p80Activated,
dot11VHTLDPCCodingOptionImplemented,
dot11VHTLDPCCodingOptionActivated,
dot11VHTTxSTBCOptionImplemented,
dot11VHTTxSTBCOptionActivated,
dot11VHTRxSTBCOptionImplemented,
dot11VHTRxSTBCOptionActivated,
dot11VHTMUMaxUsersImplemented,
dot11VHTMUMaxNSTSPerUserImplemented,
dot11VHTMUMaxNSTSTotalImplemented,
dot11VHTMaxNTxChainsImplemented,
dot11VHTMaxNTxChainsActivated}
STATUS current
DESCRIPTION
"Attributes that configure the VHT PHY."
::= { dot11Groups 77 }
dot11VHTMACAdditions OBJECT-GROUP
OBJECTS {
dot11VHTOptionImplemented,
dot11OperatingModeNotificationImplemented,
dot11MaxMPDULength,
dot11VHTMaxRxAMPDUFactor,
dot11VHTControlFieldOptionImplemented,
dot11VHTTXOPPowerSaveOptionImplemented,
dot11VHTRxVHTMCSMap,
dot11VHTRxHighestDataRateSupported,
3255
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11VHTTxVHTMCSMap,
dot11VHTTxHighestDataRateSupported,
dot11VHTOBSSScanCount,
dot11VHTExtendedNSSBWCapable
}
STATUS current
DESCRIPTION
"Attributes that configure the VHT MAC."
::= { dot11Groups 78 }
dot11PhyTxPowerComplianceGroup2 OBJECT-GROUP
OBJECTS {
dot11TxPowerLevelExtended,
dot11CurrentTxPowerLevelExtended }
STATUS current
DESCRIPTION
"Additional attributes for Control and Management of transmit power."
::= { dot11Groups 79 }
dot11TVHTTransmitBeamformingGroup OBJECT-GROUP
OBJECTS {
dot11TVHTSUBeamformeeOptionImplemented,
dot11TVHTSUBeamformerOptionImplemented,
dot11TVHTMUBeamformeeOptionImplemented,
dot11TVHTMUBeamformerOptionImplemented,
dot11TVHTNumberSoundingDimensions,
dot11TVHTBeamformeeNTxSupport
}
STATUS current
DESCRIPTION
"Attributes that configure TVHT transmit beamforming for IEEE Std 802.11."
::= { dot11Groups 80 }
dot11PhyTVHTComplianceGroup OBJECT-GROUP
OBJECTS {
dot11TVHTChannelWidthOptionImplemented,
dot11TVHTCurrentChannelWidth,
dot11TVHTCurrentChannelCenterFrequencyIndex0,
dot11TVHTCurrentChannelCenterFrequencyIndex1,
dot11TVHTShortGIOptionIn4WImplemented,
dot11TVHTShortGIOptionIn4WActivated,
dot11TVHTLDPCCodingOptionImplemented,
dot11TVHTLDPCCodingOptionActivated,
dot11TVHTTxSTBCOptionImplemented,
dot11TVHTTxSTBCOptionActivated,
dot11TVHTRxSTBCOptionImplemented,
dot11TVHTRxSTBCOptionActivated,
dot11TVHTMUMaxUsersImplemented,
dot11TVHTMUMaxNSTSPerUserImplemented,
dot11TVHTMUMaxNSTSTotalImplemented,
dot11TVHTMaxNTxChainsImplemented,
dot11TVHTMaxNTxChainsActivated
}
STATUS current
DESCRIPTION
"Attributes that configure the TVHT PHY."
::= { dot11Groups 81 }
dot11MACbase4 OBJECT-GROUP
OBJECTS {
dot11MACAddress,
dot11GroupAddress,
dot11GroupAddressesStatus,
dot11RTSThreshold,
3256
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11ShortRetryLimit,
dot11LongRetryLimit,
dot11FragmentationThreshold,
dot11MaxTransmitMSDULifetime,
dot11MaxReceiveLifetime,
dot11ManufacturerID,
dot11ProductID,
dot11CAPLimit,
dot11HCCWmin,
dot11HCCWmax,
dot11HCCAIFSN,
dot11ChannelUtilizationBeaconIntervals,
dot11ScheduleTimeout,
dot11DLSResponseTimeout,
dot11QAPMissingAckRetryLimit,
dot11EDCAAveragingPeriod,
dot11HTProtection,
dot11RIFSMode,
dot11PSMPControlledAccess,
dot11ServiceIntervalGranularity,
dot11DualCTSProtection,
dot11LSIGTXOPFullProtectionActivated,
dot11NonGFEntitiesPresent, dot11PCOActivated,
dot11PCOFortyMaxDuration,
dot11PCOTwentyMaxDuration,
dot11PCOFortyMinDuration,
dot11PCOTwentyMinDuration }
STATUS current
DESCRIPTION
"The MAC object class provides the necessary support for the access
control, generation, and verification of frame check sequences (FCSs), and
proper delivery of valid data to upper layers."
::= { dot11Groups 84 }
dot11CountersGroup4 OBJECT-GROUP
OBJECTS {
dot11TransmittedFragmentCount,
dot11TransmittedFrameCount,
dot11FailedCount,
dot11ReceivedFragmentCount,
dot11GroupReceivedFrameCount,
dot11FCSErrorCount,
dot11WEPUndecryptableCount,
dot11TransmittedFrameCount,
dot11QosDiscardedFragmentCount,
dot11AssociatedStationCount,
dot11QosCFPollsReceivedCount,
dot11QosCFPollsUnusedCount,
dot11QosCFPollsUnusableCount,
dot11QosCFPollsLostCount,
dot11TransmittedAMSDUCount,
dot11FailedAMSDUCount,
dot11RetryAMSDUCount,
dot11MultipleRetryAMSDUCount,
dot11TransmittedOctetsInAMSDUCount,
dot11AMSDUAckFailureCount,
dot11ReceivedAMSDUCount,
dot11ReceivedOctetsInAMSDUCount,
dot11TransmittedAMPDUCount,
dot11TransmittedMPDUsInAMPDUCount,
dot11TransmittedOctetsInAMPDUCount,
dot11AMPDUReceivedCount,
dot11MPDUInReceivedAMPDUCount,
dot11ReceivedOctetsInAMPDUCount,
3257
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11AMPDUDelimiterCRCErrorCount,
dot11ImplicitBARFailureCount,
dot11ExplicitBARFailureCount,
dot11ChannelWidthSwitchCount,
dot11TwentyMHzFrameTransmittedCount,
dot11FortyMHzFrameTransmittedCount,
dot11TwentyMHzFrameReceivedCount,
dot11FortyMHzFrameReceivedCount,
dot11PSMPUTTGrantDuration,
dot11PSMPUTTUsedDuration,
dot11GrantedRDGUsedCount,
dot11GrantedRDGUnusedCount,
dot11TransmittedFramesInGrantedRDGCount,
dot11TransmittedOctetsInGrantedRDGCount,
dot11BeamformingFrameCount,
dot11DualCTSSuccessCount,
dot11DualCTSFailureCount,
dot11STBCCTSSuccessCount,
dot11STBCCTSFailureCount,
dot11nonSTBCCTSSuccessCount,
dot11nonSTBCCTSFailureCount,
dot11RTSLSIGSuccessCount,
dot11RTSLSIGFailureCount,
dot11TransmittedMSDUOctetsCount,
dot11ReceivedMSDUOctetsCount
}
STATUS current
DESCRIPTION
"Attributes from the dot11CountersGroup that are not described in the
dot11MACStatistics group. These objects are mandatory."
::= { dot11Groups 85 }
dot11BSSStatisticsGroup OBJECT-GROUP
OBJECTS {
dot11AssociatedStationCount,
dot11BSSLoadChannelUtilization,
dot11BSSLoadAvailableAdmissionCapacity,
dot11BSSLoadAssocAttemptCount,
dot11BSSLoadAssocFailCount,
dot11BSSLoadReassocAttemptCount,
dot11BSSLoadReassocFailCount
}
STATUS current
DESCRIPTION
"The BSS Statistics group defines those objects that provide access to
local measurements by an AP of its BSS."
::= { dot11Groups 86 }
dot11HTMACAdditions2 OBJECT-GROUP
OBJECTS {
dot11MIMOPowerSave,
dot11NDelayedBlockAckOptionImplemented,
dot11MaxAMSDULength,
dot11STBCControlFrameOptionImplemented,
dot11LsigTxopProtectionOptionImplemented,
dot11MaxRxAMPDUFactor,
dot11MinimumMPDUStartSpacing,
dot11PCOOptionImplemented,
dot11TransitionTime,
dot11MCSFeedbackOptionImplemented,
dot11HTControlFieldSupported,
dot11RDResponderOptionImplemented,
dot11BSSWidthTriggerScanInterval,
dot11BSSWidthChannelTransitionDelayFactor,
3258
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11OBSSScanPassiveDwell,
dot11OBSSScanActiveDwell,
dot11OBSSScanPassiveTotalPerChannel,
dot11OBSSScanActiveTotalPerChannel,
dot112040BSSCoexistenceManagementSupport,
dot11OBSSScanActivityThreshold,
dot11SPPAMSDUCapable,
dot11SPPAMSDURequired }
STATUS current
DESCRIPTION
"Attributes that configure the HT PHY for IEEE Std 802.11."
::= { dot11Groups 87 }
-- dot11SMTbase13 includes all changes made between IEEE Std 802.11-2012 and IEEE
Std 802.11-2016.
-- Amendments to Std 802.11-2016 should not make any modifications to
dot11SMTbase13. The first amendment needing to modify the dot11SMTbase
object should deprecate dot11SMTbase13 and define a replacement to hold
changes.
dot11SMTbase13 OBJECT-GROUP
OBJECTS {
dot11MediumOccupancyLimit,
dot11CFPollable,
dot11CFPPeriod,
dot11CFPMaxDuration,
dot11PrivacyOptionImplemented,
dot11PowerManagementMode,
dot11DesiredSSID,
dot11DesiredBSSType,
dot11OperationalRateSet,
dot11BeaconPeriod,
dot11DTIMPeriod,
dot11AssociationResponseTimeout,
dot11DisassociateReason,
dot11DisassociateStation,
dot11DeauthenticateReason,
dot11DeauthenticateStation,
dot11AuthenticateFailStatus,
dot11AuthenticateFailStation,
dot11MultiDomainCapabilityImplemented,
dot11MultiDomainCapabilityActivated,
dot11CountryString,
dot11SpectrumManagementImplemented,
dot11SpectrumManagementRequired,
dot11RSNAOptionImplemented,
dot11OperatingClassesImplemented,
dot11OperatingClassesRequired,
dot11QosOptionImplemented,
dot11ImmediateBlockAckOptionImplemented,
dot11DelayedBlockAckOptionImplemented,
dot11DirectOptionImplemented,
dot11APSDOptionImplemented,
dot11QAckOptionImplemented,
dot11QBSSLoadImplemented,
dot11QueueRequestOptionImplemented,
dot11TXOPRequestOptionImplemented,
dot11MoreDataAckOptionImplemented,
dot11AssociateInNQBSS,
dot11DLSAllowedInQBSS,
dot11DLSAllowed,
dot11AssociateStation,
dot11AssociateID,
dot11AssociateFailStation,
3259
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11AssociateFailStatus,
dot11ReassociateStation,
dot11ReassociateID,
dot11ReassociateFailStation,
dot11ReassociateFailStatus,
dot11RadioMeasurementImplemented,
dot11RadioMeasurementActivated,
dot11RMMeasurementNavSync,
dot11RMMeasurementPilotPeriod,
dot11RMLinkMeasurementActivated,
dot11RMNeighborReportActivated,
dot11RMParallelMeasurementsActivated,
dot11RMRepeatedMeasurementsActivated,
dot11RMBeaconPassiveMeasurementActivated,
dot11RMBeaconActiveMeasurementActivated,
dot11RMBeaconTableMeasurementActivated,
dot11RMBeaconMeasurementReportingConditionsActivated,
dot11RMFrameMeasurementActivated,
dot11RMChannelLoadMeasurementActivated,
dot11RMNoiseHistogramMeasurementActivated,
dot11RMStatisticsMeasurementActivated,
dot11RMLCIMeasurementActivated,
dot11RMLCIAzimuthActivated,
dot11RMTransmitStreamCategoryMeasurementActivated,
dot11RMTriggeredTransmitStreamCategoryMeasurementActivated,
dot11RMAPChannelReportActivated,
dot11RMMIBActivated,
dot11RMMaxMeasurementDuration,
dot11RMNonOperatingChannelMaxMeasurementDuration,
dot11RMMeasurementPilotTransmissionInformationActivated,
dot11RMMeasurementPilotActivated,
dot11RMNeighborReportTSFOffsetActivated,
dot11RMRCPIMeasurementActivated,
dot11RMRSNIMeasurementActivated,
dot11RMBSSAverageAccessDelayActivated,
dot11RMBSSAvailableAdmissionCapacityActivated,
dot11FastBSSTransitionImplemented,
dot11LCIDSEImplemented,
dot11LCIDSERequired,
dot11DSERequired,
dot11ExtendedChannelSwitchActivated,
dot11HighThroughputOptionImplemented,
dot11WirelessManagementImplemented,
dot11MeshActivated,
dot11RSNAPBACRequired,
dot11PSMPOptionImplemented,
dot11MaxMSDULength,
dot11ExtendedSpectrumManagementImplemented,
dot11EstimatedServiceParametersOptionImplemented,
dot11FutureChannelGuidanceActivated
}
STATUS current
DESCRIPTION
"The SMTbase13 object class provides the necessary support at the STA to
manage the processes in the STA such that the STA may work cooperatively
as a part of an IEEE 802.11 network."
::= { dot11Groups 92 }
dot11FineTimingMeasurement OBJECT-GROUP
OBJECTS {
dot11WirelessManagementImplemented,
dot11FineTimingMsmtRespActivated,
dot11FineTimingMsmtInitActivated,
dot11LciCivicInNeighborReport,
3260
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11RMFineTimingMsmtRangeRepImplemented,
dot11RMFineTimingMsmtRangeRepActivated,
dot11RMLCIMeasurementActivated,
dot11RMLCIConfigured,
dot11RMCivicMeasurementActivated,
dot11RMCivicConfigured
}
STATUS current
DESCRIPTION
"Attributes that configure the Fine Timing Measurement feature for IEEE
Std 802.11."
::= { dot11Groups 93 }
-- **********************************************************************
-- * Compliance Statements
-- **********************************************************************
dot11Compliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities that implement the IEEE
802.11 MIB."
MODULE -- this module
MANDATORY-GROUPS {
dot11SMTbase13,
dot11MACbase4,
dot11CountersGroup4,
dot11SmtAuthenticationAlgorithms,
dot11ResourceTypeID,
dot11PhyOperationComplianceGroup2 }
GROUP dot11PhyDSSSComplianceGroup
DESCRIPTION
"Implementation of this group is required when object dot11PHYType is
dsss.
This group is mutually exclusive to the following groups:
dot11PhyOFDMComplianceGroup3
dot11PhyHRDSSSComplianceGroup
dot11PhyERPComplianceGroup
dot11PhyHTComplianceGroup
dot11DMGComplianceGroup
dot11PhyVHTComplianceGroup
dot11PhyTVHTComplianceGroup"
GROUP dot11PhyOFDMComplianceGroup3
DESCRIPTION
"Implementation of this group is required when object dot11PHYType is
ofdm.
This group is mutually exclusive to the following groups:
dot11PhyDSSSComplianceGroup
dot11PhyHRDSSSComplianceGroup
dot11PhyERPComplianceGroup
dot11PhyHTComplianceGroup
dot11DMGComplianceGroup
dot11PhyVHTComplianceGroup
dot11PhyTVHTComplianceGroup"
GROUP dot11PhyHRDSSSComplianceGroup
DESCRIPTION
"Implementation of this group is required when object dot11PHYType is
hrdsss.
This group is mutually exclusive to the following groups:
3261
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
dot11PhyDSSSComplianceGroup
dot11PhyOFDMComplianceGroup3
dot11PhyERPComplianceGroup
dot11PhyHTComplianceGroup
dot11DMGComplianceGroup
dot11PhyVHTComplianceGroup
dot11PhyTVHTComplianceGroup"
GROUP dot11PhyERPComplianceGroup
DESCRIPTION
"Implementation of this group is required when object dot11PHYType is erp.
This group is mutually exclusive to the following groups:
dot11PhyDSSSComplianceGroup
dot11PhyOFDMComplianceGroup3
dot11PhyHRDSSSComplianceGroup
dot11PhyHTComplianceGroup
dot11DMGComplianceGroup
dot11PhyVHTComplianceGroup
dot11PhyTVHTComplianceGroup"
GROUP dot11PhyHTComplianceGroup
DESCRIPTION
"Implementation of this group is required when object dot11PHYType is ht.
This group is mutually exclusive to the following groups:
dot11PhyDSSSComplianceGroup
dot11PhyOFDMComplianceGroup3
dot11PhyHRDSSSComplianceGroup
dot11PhyERPComplianceGroup
dot11DMGComplianceGroup
dot11PhyVHTComplianceGroup
dot11PhyTVHTComplianceGroup"
GROUP dot11PhyVHTComplianceGroup
DESCRIPTION
"Implementation of this group is required when object dot11PHYType is vht.
This group is mutually exclusive to the following groups:
dot11PhyDSSSComplianceGroup
dot11PhyOFDMComplianceGroup3
dot11PhyHRDSSSComplianceGroup
dot11PhyERPComplianceGroup
dot11DMGComplianceGroup
dot11PhyHTComplianceGroup
dot11PhyTVHTComplianceGroup"
GROUP dot11PhyTVHTComplianceGroup
DESCRIPTION
"Implementation of this group is required when object dot11PHYType is
tvht.
This group is mutually exclusive to the following groups:
dot11PhyDSSSComplianceGroup
dot11PhyOFDMComplianceGroup3
dot11PhyHRDSSSComplianceGroup
dot11PhyERPComplianceGroup
dot11PhyHTComplianceGroup
dot11DMGComplianceGroup
dot11PhyVHTComplianceGroup"
GROUP dot11HTMACAdditions2
DESCRIPTION
"The dot11HTMACAdditions2 group is optional."
GROUP dot11SMTprivacy
DESCRIPTION
"The dot11SMTprivacy group is optional."
3262
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
GROUP dot11MACStatistics
DESCRIPTION
"The dot11MACStatistics group is optional."
GROUP dot11PhyTxPowerComplianceGroup
DESCRIPTION
"The dot11PhyTxPowerComplianceGroup group is optional."
GROUP dot11PhyTxPowerComplianceGroup2
DESCRIPTION
"The dot11PhyTxPowerComplianceGroup2 group is optional, but dependent on
dot11PhyTxPowerComplianceGroup."
GROUP dot11PhyRegDomainsSupportGroup
DESCRIPTION
"The dot11PhyRegDomainsSupportGroup group is optional."
GROUP dot11PhyAntennasListGroup
DESCRIPTION
"The dot11PhyAntennasListGroup group is optional."
GROUP dot11PhyRateGroup
DESCRIPTION
"The dot11PhyRateGroup group is optional."
GROUP dot11MultiDomainCapabilityGroup
DESCRIPTION
"The dot11MultiDomainCapabilityGroup group is optional."
GROUP dot11RSNAadditions
DESCRIPTION
"The dot11RSNAadditions group is optional."
GROUP dot11OperatingClassesGroup
DESCRIPTION
"The dot11OperatingClassesGroup group is optional."
GROUP dot11Qosadditions
DESCRIPTION
"The dot11Qosadditions group is optional."
GROUP dot11FTComplianceGroup
DESCRIPTION
"The dot11FTComplianceGroup group is optional."
GROUP dot11PhyAntennaComplianceGroup2
DESCRIPTION
"The dot11PhyAntennaComplianceGroup2 group is optional."
GROUP dot11PhyMCSGroup
DESCRIPTION
"The dot11PhyMCSGroup group is optional."
GROUP dot11TransmitBeamformingGroup
DESCRIPTION
"The dot11TransmitBeamformingGroup group is optional."
GROUP dot11VHTTransmitBeamformingGroup
DESCRIPTION
"The dot11VHTTransmitBeamformingGroup group is optional."
GROUP dot11VHTMACAdditions
DESCRIPTION
3263
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
"The dot11VHTMACAdditions group is optional."
GROUP dot11DMGComplianceGroup
DESCRIPTION
"Implementation of this group is required when the object
dot11PHYType is dmg.
This group is mutually exclusive to the following groups:
dot11PhyDSSSComplianceGroup
dot11PhyOFDMComplianceGroup3
dot11PhyHRDSSSComplianceGroup
dot11PhyERPComplianceGroup
dot11PhyHTComplianceGroup
dot11PhyVHTComplianceGroup
dot11PhyTVHTComplianceGroup"
GROUP dot11DMGOperationsComplianceGroup
DESCRIPTION
"DMG Operations Compliance Group"
GROUP dot11DMGBeamformingComplianceGroup
DESCRIPTION
"DMG Beamforming Compliance Group"
GROUP dot11DMGCountersComplianceGroup
DESCRIPTION
"DMG Counters Compliance Group."
GROUP dot11TVWSComplianceGroup
DESCRIPTION
"The dot11TVWSComplianceGroup is optional."
GROUP dot11BSSStatisticsGroup
DESCRIPTION
"Implementation of this group is optional by an AP"
-- OPTIONAL-GROUPS {
-- dot11SMTprivacy,
-- dot11MACStatistics,
-- dot11PhyTxPowerComplianceGroup,
-- dot11PhyRegDomainsSupportGroup,
-- dot11PhyAntennasListGroup,
-- dot11PhyRateGroup,
-- dot11MultiDomainCapabilityGroup,
-- dot11RSNAadditions,
-- dot11OperatingClassesGroup,
-- dot11Qosadditions,
-- dot11RMCompliance,
-- dot11FTComplianceGroup,
-- dot11PhyAntennaComplianceGroup2,
-- dot11HTMACadditions2,
-- dot11PhyMCSGroup,
-- dot11TransmitBeamformingGroup,
-- dot11TVHTTransmitBeamformingGroup,
-- dot11PhyTVHTComplianceGroup,
-- dot11WNMCompliance,
-- dot11BSSStatisticsGroup,
-- dot11VHTTransmitBeamformingGroup,
-- dot11PhyVHTComplianceGroup,
-- dot11VHTMACAdditions,
-- dot11TVWSComplianceGroup }
::= { dot11Compliances 1 }
-- ********************************************************************
3264
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
-- * Compliance Statements - RSN
-- ********************************************************************
dot11RSNCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities that implement the IEEE
802.11 RSN MIB."
MODULE -- this module
MANDATORY-GROUPS { dot11RSNBase }
-- OPTIONAL-GROUPS { dot11RSNPMKcachingGroup }
::= { dot11Compliances 2 }
-- ********************************************************************
-- * Compliance Statements - RM
-- ********************************************************************
dot11RMCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities that implement the IEEE
802.11 MIB for Measurement Services."
MODULE -- this module
MANDATORY-GROUPS {
dot11SMTRMRequest,
dot11SMTRMReport,
dot11SMTRMConfig }
-- OPTIONAL-GROUPS { }
::= { dot11Compliances 3 }
-- ********************************************************************
-- * Compliance Statements - Mesh
-- ********************************************************************
dot11MeshCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities that implement the IEEE
802.11 MIB for Mesh."
MODULE -- this module
MANDATORY-GROUPS {
dot11MeshComplianceGroup,
dot11MeshHWMPComplianceGroup,
dot11PasswordAuthComplianceGroup }
-- OPTIONAL-GROUPS { dot11MeshOptionGroup }
::= { dot11Compliances 4 }
-- ********************************************************************
-- * Compliance Statements - WNM
-- ********************************************************************
dot11WNMCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
" This object class provides the objects from the IEEE 802.11
MIB required to manage wireless network management
functionality. Note that additional objects for managing this
functionality are located in the IEEE 802.11 WNM MIB."
MODULE -- this module
MANDATORY-GROUPS { dot11SMTRMRequest, dot11SMTRMReport, dot11SMTRMConfig }
GROUP dot11SMTbase12
DESCRIPTION "At least the dot11WirelessManagementImplemented object is
required from dot11SMTbase12"
GROUP dot11FineTimingMeasurement
3265
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
DESCRIPTION
"The dot11FineTimingMeasurement group is optional"
OBJECT dot11WirelessManagementImplemented
DESCRIPTION "Required object"
::= { dot11Compliances 5 }
-- ********************************************************************
-- * Compliance Statements - QMF
-- ********************************************************************
dot11QMFCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11 MIB required
to manage QoS Management Frame functionality."
MODULE -- this module
MANDATORY-GROUPS {
dot11QMFComplianceGroup }
::= { dot11Compliances 6 }
-- ********************************************************************
-- * Compliance Statements - AVS
-- ********************************************************************
dot11AVSCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities that implement the IEEE
Std 802.11 Robust Audio/Video Streaming feature.
Note that additional objects for managing this functionality are located
in the IEEE 802.11 AVS MIB."
MODULE -- this module
GROUP dot11AVSBase
DESCRIPTION "At least the dot11RobustAVStreamingImplemented object is
required from dot11StationConfigEntry."
OBJECT dot11RobustAVStreamingImplemented
DESCRIPTION "Required object"
::= { dot11Compliances 7 }
dot11AVSAPCCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities that implement the IEEE
Std 802.11 HCCA TXOP Negotiation feature.
Note that additional objects for managing this
functionality are located in the IEEE 802.11 AVS MIB."
MODULE -- this module
MANDATORY-GROUPS { dot11AVSBase }
GROUP dot11AVSAPCGroup
DESCRIPTION "At least the dot11RobustAVStreamingImplemented object is
required from dot11StationConfigEntry."
OBJECT dot11RobustAVStreamingImplemented
DESCRIPTION "Required object"
::= { dot11Compliances 8 }
-- *******************************************************************
-- * Compliance Statements - DMG
-- *******************************************************************
dot11DMGCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities that implement the IEEE
802.11 MIB for DMG operation."
3266
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
MODULE -- this module
MANDATORY-GROUPS {
dot11DMGComplianceGroup,
dot11DMGOperationsComplianceGroup,
dot11DMGBeamformingComplianceGroup,
dot11DMGCountersComplianceGroup }
::= { dot11Compliances 9 }
-- ********************************************************************
-- * Compliance Statements - Spectrum Management
-- ********************************************************************
dot11SpectrumManagementCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11
MIB used to operate higher throughput."
MODULE -- this module
MANDATORY-GROUPS { dot11SpectrumManagementGroup }
-- OPTIONAL-GROUPS { }
::= { dot11Compliances 10 }
-- ********************************************************************
-- * Compliance Statements - Management frame protection
-- ********************************************************************
dot11ProtectedManagementFrameCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11
MIB required to operate management frame protection."
MODULE -- this module
MANDATORY-GROUPS { dot11ProtectedManagementFrameGroup }
-- OPTIONAL-GROUPS { }
::= { dot11Compliances 11 }
-- ********************************************************************
-- * Compliance Statements - LCIDSE
-- ********************************************************************
dot11LCIDSECompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11
MIB required to enable 3650-3700 MHz Operation in USA."
MODULE -- this module
MANDATORY-GROUPS { dot11LCIDSEGroup }
-- OPTIONAL-GROUPS { }
::= { dot11Compliances 12 }
-- ********************************************************************
-- * Compliance Statements - TDLS
-- ********************************************************************
dot11TDLSCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11
MIB required to manage tunneled direct link setup."
MODULE -- this module
MANDATORY-GROUPS { dot11TDLSComplianceGroup }
-- OPTIONAL-GROUPS { }
::= { dot11Compliances 13 }
-- ********************************************************************
-- * Compliance Statements - VHT
-- ********************************************************************
dot11VHTCompliance MODULE-COMPLIANCE
3267
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STATUS current
DESCRIPTION
"This object class provides the objects from the IEEE 802.11
MIB used to operate at very high throughput."
MODULE -- this module
MANDATORY-GROUPS { dot11PhyVHTComplianceGroup, dot11PhyTxPowerCompliance-
Group2, dot11VHTTransmitBeamformingGroup, dot11VHTMACAdditions }
-- OPTIONAL-GROUPS { }
::= { dot11Compliances 14 }
-- ********************************************************************
-- * Compliance Statements - TVWS
-- ********************************************************************
dot11TVHTCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities that implement the IEEE
802.11 MIB for TVWS operation."
MODULE -- this module
MANDATORY-GROUPS {
dot11PhyTVHTComplianceGroup,
dot11PhyTxPowerComplianceGroup2,
dot11TVHTTransmitBeamformingGroup,
dot11VHTMACAdditions, dot11TVWSComplianceGroup }
::= { dot11Compliances 15 }
-- **********************************************************************
-- * End of IEEE 802.11 MIB
-- **********************************************************************
END
3268
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex D
(normative)
Regulatory references
D.1 External regulatory references
This annex and Annex E provide information and specifications for operation in many regulatory domains.
WLANs implemented in accordance with this standard and the specifications and definitions referenced in it
are subject to equipment certification and operating requirements established by regional and national
regulatory administrations. The specification establishes minimum technical requirements for
interoperability, based upon established regulations at the time this standard was issued. These regional and
national regulations are subject to revision or may be superseded. Regulatory requirements that do not affect
interoperability are not addressed in this standard. Implementers are referred to the regulatory sources in
Table D-1 for further information. Operation in countries within defined regulatory domains may be subject
to additional or alternative national regulations.
The documents listed in Table D-1 specify current regulatory requirements for various frequency bands and
geographic areas at the time this standard was developed. They are provided for information only and are
subject to change or revision at any time.
Table D-1—Regulatory requirement list
Geographic Approval
Approval standards Documents
area authority
Canada Minister of Industry RSS-210 — License-exempt Radio Industry
Apparatus (All Frequency Bands): Canada
Category I Equipment
China Ministry of Industry and Information Xin Bu Wu [2002] #353, MIIT
Technology (MIIT) Xin Bu Wu [2002] #277,
Gong Xin Bu Wu Han [2012] #620
Europe European Conference of Postal and ECC DEC (04) 08, CEPT
Telecommunications (CEPT) ETSI EN 300 328 [B13],
Administrations and its Electronic ETSI EN 301 893,
Communications Committee (ECC). ETSI ES 202 663 [B15],
Also, European Radiocommunications ETSI EN 302 571 [B14], Clause 5
Office, European Telecommunications
Standards Institute (ETSI)
Japan Ministry of Internal Affairs and MIC Equipment Ordinance (EO) for MIC
Communications (MIC) Regulating Radio Equipment
Articles 7, 49.20, 49.21a
3269
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table D-1—Regulatory requirement list (continued)
Geographic Approval
Approval standards Documents
area authority
United States Federal Communications Commission 47 CFR [B9], Part 15, FCC
(FCC) Sections 15.205, 15.209, 15.247 and
15.255; and Subpart E,
Sections 15.401–15.407, and
Subpart H, Sections 15.701–15.716,
Section 90.210,
Sections 90.371–383,
Sections 90.1201–90.1217,
Sections 90.1301–90.1337,
Section 95.639,
Sections 95.1501–1511
aFrequency planning for licensed STAs in Japan is performed by the regulatory authority and the licensees, addressing
the coexistence among STAs operating with a variety of air propagation times and the coexistence between STAs
using 20 MHz channel spacing, STAs operating with 10 MHz channel spacing, and STAs operating with 5 MHz
channel spacing. Note also the CCA mechanism is preserved in licensed operation.
Behavior limits are listed in Table D-2.
Table D-2—Behavior limits
Behavior limit Description
NomadicBehavior The location of the station may change but is stationary while in use. The
nomadic use EIRP power limits apply if the country allows more than one
transmit power limit in the band. This behavior is specified only in bands
where behavior 10 License Exempt bands is also allowed.
LicenseExemptBehavior Frequency bands where some fixed stations can be operated without a license
at a higher radiated transmit power than permitted for nomadic use. This
behavior is specified only in bands where behavior 1 nomadic use is also
allowed.
PrimaryChannelLowerBehaviora 20/40 MHz BSS primary channel with secondary channel above the primary
channel or 20 MHz BSS primary channel operated by a 40MC HT AP and
also 20 MHz operational channel for a non-AP STA when the non-AP STA is
associated with a 40MC HT AP.
See NOTE.
PrimaryChannelUpperBehaviora 14 20/40 MHz BSS primary channel with secondary channel below the
primary channel or 20 MHz BSS primary channel operated by a 40MC HT
AP and also 20 MHz operational channel for a non-AP STA when the non-
AP STA is associated with a 40MC HT AP.
See NOTE.
CCA-EDBehaviorb The PHY shall also indicate a medium busy condition when CCA-
EnergyDetect detects a channel busy condition.
DFS_50_100_Behavior A station operating in a band where radiolocation radar is primary, and
station operation has in-service monitoring requirements for 50-100 µs radar
pulses.
ITS_nonmobile_operations Operations related to an ITS station operating at a fixed location registered
with regulatory authorities, e.g., a Dedicated Short Range Communication
Services (DSRCS) Roadside Unit (RSU).
3270
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table D-2—Behavior limits (continued)
Behavior limit Description
ITS_mobile_operations Operations related to an ITS mobile station, e.g., a vehicle’s DSRCS On-
board Unit (OBU).
80+ In a channel width that contains two or more frequency segments, the
frequency segment that does not contain the primary 80 MHz channel
(see NOTE 2)
UseEirpForVHTTxPowEnv A STA that sends one or more Transmit Power Envelope elements shall
indicate EIRP in the Local Maximum Transmit Power Unit Interpretation
subfield in one of the Transmit Power Envelope elements
GeoDB A STA operating in a TVWS band where broadcast TV operation is primary
and STA operation has GDB requirements. When operating in TVWS,
channel numbers are as assigned in regulation.
NOTE 1—The fields that specify the 40 MHz channels are described in 19.3.15.4.
NOTE 2—For an example using an operating class with an 80+ Behavior limit, see 9.4.2.9. The maximum number
of frequency segments is PHY dependent.
aFor
20 MHz operation where the operating class signifies 40 MHz channel spacing, the 20 MHz channel
corresponds to the channel number indicated.
bProcedures that may be used to improve sharing spectrum in addition to explicit regulatory requirements.
D.2 Radio performance specifications
D.2.1 Transmit and receive in-band and out-of-band spurious emissions
Spurious transmissions shall comply with national regulations.
D.2.2 Transmit power levels
The maximum allowable output power is measured in accordance with practices specified by the appropriate
regulatory bodies.
The maximum allowable STA transmit power classifications for ITS nonmobile operations in the U.S. 5.85–
5.925 GHz band are shown in Table D-3.
Table D-3—Maximum STA transmit power classification for
the 5.85–5.925 GHz band in the United States
STA transmit power Maximum STA transmit power Maximum permitted EIRP
classification (mW) (dBm)
A 1 23
B 10 23
C 100 33
D 760 33 for nongovernment
Note that for this class higher power is permitted
as long as the power level is reduced to this level 44.8 for government
at the antenna input and the emission mask
specifications are met.
3271
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
D.2.3 Transmit spectrum mask
Transmit spectrum masks defined in regulation are subject to change or revision at any time.
For operation in the 5.85–5.925 GHz band the transmitted spectrum shall be as follows:
a) For any STA using 5 MHz channel spacing, the transmitted spectral density shall have a 0 dBr
bandwidth not exceeding 4.5 MHz and shall not exceed the spectrum mask created using the
permitted power spectral density levels listed in Table D-4 for the transmit power class of the STA.
b) For any STA using 10 MHz channel spacing, the transmitted spectral density shall have a 0 dBr
bandwidth not exceeding 9 MHz and shall not exceed the spectrum mask created using the permitted
power spectral density levels listed in Table D-5 for the transmit power class of the STA.
c) For any STA using 20 MHz channel spacing, the transmitted spectral density shall have a 0 dBr
bandwidth not exceeding 18 MHz and shall not exceed the spectrum mask created using the
permitted power spectral density levels listed in Table D-6 for the transmit power class of the
STA.
Table D-4—Spectrum mask data for 5 MHz channel spacing
Permitted power spectral density, dBr
STA transmit
power class ± 2.25 MHz ± 2.5 MHz ± 2.75 MHz ±5 MHz ± 7.5 MHz
offset offset offset offset offset
(±f1) (±f2) (±f3) (±f4) (±f5)
Class A 0 –10 –20 –28 –40
Class B 0 –16 –20 –28 –40
Class C 0 –26 –32 –40 –50
Class D 0 –35 –45 –55 –65
Table D-5—Spectrum mask data for 10 MHz channel spacing
Permitted power spectral density, dBr
STA transmit
power class ± 4.5 MHz ± 5.0 MHz ± 5.5 MHz ± 10 MHz ± 15 MHz
offset offset offset offset offset
(±f1) (±f2) (±f3) (±f4) (±f5)
Class A 0 –10 –20 –28 –40
Class B 0 –16 –20 –28 –40
Class C 0 –26 –32 –40 –50
Class D 0 –35 –45 –55 –65
3272
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table D-6—Spectrum mask data for 20 MHz channel spacing
Permitted power spectral density, dBr
STA transmit
power class ± 10.0 MHz ± 11 MHz ± 20 MHz ± 30 MHz
± 9 MHz offset
offset offset offset offset
(±f1)
(±f2) (±f3) (±f4) (±f5)
Class A 0 –10 –20 –28 –40
Class B 0 –16 –20 –28 –40
Class C 0 –26 –32 –40 –50
Class D 0 –35 –45 –55 –65
The transmit spectral mask is created and applied as shown in Figure D-1 about the channel center
frequency (Fc) defined by the channel starting frequency and channel number from the operating class. The
0 dBr level is the maximum power spectral density measured in the channel. The measurements of transmit
spectral density are made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth.
Power Spectral Density (dB)
Permitted Level at f1 (0dBr)
Transmit Spectrum Mask
(not to scale)
Example Signal Spectrum
Permitted Level at f2
(not to scale)
Permitted Level at f3
Permitted Level at f4
Permitted Level at f5
-f5 -f4 -f3 -f1
-f2 Fc +f1 +f2 +f3 +f4 +f5
Frequency (MHz)
Figure D-1—Transmit spectrum mask and application
D.2.4 Transmit Mask M
This subclause defines the characteristics of transmit mask M.
The power spectral density of the emissions shall be attenuated below the output power of the transmitter as
follows:
a) On any frequency removed from the center frequency between 0-45% of the channel bandwidth
(BW): 0 dB.
b) On any frequency removed from the center frequency between 45-50% of the channel bandwidth:
568 log (% of (BW)/45) dB.
3273
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
c) On any frequency removed from the center frequency between 50-55% of the channel bandwidth:
26 + 145 log (% of BW/50) dB.
d) On any frequency removed from the center frequency between 55-100% of the channel bandwidth:
32 + 31 log (% of (BW)/55) dB.
e) On any frequency removed from the center frequency between 100-150% of the channel bandwidth:
40 + 57 log (% of (BW)/100) dB.
f) On any frequency removed from the center frequency between above 150% of the channel band-
width: 50 dB or 55 + 10 log (P) dB, whichever is the lesser attenuation.
g) The 0 dB reference is measured relative to the highest average power of the fundamental emission
measured across the designated channel bandwidth using a resolution bandwidth of 100 kHz and a
video bandwidth of 30 kHz. The power spectral density is the power measured within the resolution
bandwidth of the measurement device divided by the resolution bandwidth of the measurement
device. Emission levels are also based on the use of measurement instrumentation employing a reso-
lution bandwidth of at least one percent of the occupied bandwidth.
D.2.5 CCA-ED threshold
CCA-ED thresholds for operation in specific bands are given in E.2.
3274
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex E
(normative)
Country elements and operating classes
E.1 Country information and operating classes
WLANs implemented in accordance with this standard and the specifications and definitions referenced in it
may be subject to equipment certification and operating requirements established by regional and national
regulatory administrations. The specification establishes minimum technical requirements for
interoperability, taking into consideration established regulations at the time this standard was issued. These
regional and national regulations may be revised or may be superseded. Regulatory requirements that do not
affect interoperability are not addressed in this standard. Implementers are referred to the regulatory sources
in Table D-1 and their successors for further information. Operation in countries within defined regulatory
domains may be subject to additional or alternative national regulations.
The Country element (see 9.4.2.9) allows a STA to configure its PHY and MAC for operation when the
Operating Triplet field is present. The Operating Triplet field indicates both PHY and MAC configuration
characteristics and operational characteristics. The First Channel Number field of subsequent Subband
Triplet fields is based on the dot11ChannelStartingFactor that is indicated by the Operating Class field.
The operating class is an index into a set of values for radio operation in a regulatory domain. The operating
class tables also contain pointers to behaviors and signal detection limits in Annex D where further
operational requirements may be found.
The channel starting frequency variable is a frequency, used together with an operating class number and a
channel number, to calculate a channel center frequency. A “—” in the Channel starting frequency column
of the operating classes tables (Table E-1 through Table E-5) indicates the channel starting frequency is not
defined by the operating class and is derived from regulation.
Channel spacing is the frequency difference between nonoverlapping adjacent channel center frequencies
when using the maximum bandwidth of one frequency segment allowed for this operating class.
The channel set is the list of integer channel numbers that are legal for a regulatory domain and class. A “—
” in the Channel set column of the operating classes tables (Table E-1 through Table E-5) indicates either
that the values in the channel center frequency index field apply for calculating channel center frequencies
of this operating class, or where both the channel set field and the channel center frequency index field are
“—” indicates that the channel set is not defined by the operating class and is derived from regulation.
The channel center frequency index is the set of integer channel numbers that correspond to frequency
segments and that are allowed for the operating class. A“—” in the Channel center frequency index column
of the operating classes tables (Table E-1 through Table E-5) indicates either that the values in the channel
set field apply for calculating channel center frequencies of this operating class or, when both the Channel
set and the Channel center frequency index column of the operating classes tables (Table E-1 through
Table E-5) are “—”, indicates that the channel center frequency index is not defined by the operating class
and is derived from regulation.
A behavior limits set is an enumerated list, each element of which points to a row in Table D-2 containing
behavior limits in various regulatory domains.
3275
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Operating classes for operation in the United States are enumerated in Table E-1.
Table E-1—Operating classes in the United States
Global Channel Channel
Channel
Operating operating starting spacing Channel set center Behavior limits set
class class (see frequency frequency
Table E-4) (GHz) (MHz) index
1 115 5 20 36, 40, 44, 48 —
2 118 5 20 52, 56, 60, 64 — DFS_50_100_Behavior
3 124 5 20 149, 153, 157, 161 — NomadicBehavior
4 121 5 20 100, 104, 108, 112, — DFS_50_100_Behavior,
116, 120, 124, 128, UseEirpForVHTTxPowEnv
132, 136, 140, 144
5 125 5 20 149, 153, 157, 161, — LicenseExemptBehavior
165
6 103 4.9375 5 1, 2, 3, 4, 5, 6, 7, 8, —
9, 10
7 103 4.9375 5 1, 2, 3, 4, 5, 6, 7, 8, —
9, 10
8 102 4.89 10 11, 13, 15, 17, 19 —
9 102 4.89 10 11, 13, 15, 17, 19 —
10 101 4.85 20 21, 25 —
11 101 4.85 20 21, 25 —
12 81 2.407 25 1, 2, 3, 4, 5, 6, 7, 8, — LicenseExemptBehavior
9, 10, 11
13 94 3.000 20 133, 137 — CCA-EDBehavior
14 95 3.000 10 132, 134, 136, 138 — CCA-EDBehavior
15 96 3.0025 5 131, 132, 133, 134, — CCA-EDBehavior
135, 136, 137, 138
16a — 5.0025 5 170–184 — ITS_nonmobile_operations,
ITS_mobile_operations
17a, b — 5 10 171–184 — ITS_nonmobile_operations,
ITS_mobile_operations
18a, b — 5 20 172–183 — ITS_nonmobile_operations,
ITS_mobile_operations
19–21 Reserved Reserved Reserved Reserved Reserved Reserved
22 116 5 40 36, 44 — PrimaryChannelLowerBehavior
23 119 5 40 52, 60 — PrimaryChannelLowerBehavior
24 122 5 40 100, 108, 116, 124, — PrimaryChannelLowerBehavior,
132, 140 DFS_50_100_Behavior,
UseEirpForVHTTxPowEnv
25 126 5 40 149, 157 — PrimaryChannelLowerBehavior
26 126 5 40 149, 157 — LicenseExemptBehavior,
PrimaryChannelLowerBehavior
27 117 5 40 40, 48 — PrimaryChannelUpperBehavior
3276
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-1—Operating classes in the United States (continued)
Global Channel Channel Channel
Operating operating starting center
class class (see frequency spacing Channel set frequency Behavior limits set
(MHz)
Table E-4) (GHz) index
28 120 5 40 56, 64 — PrimaryChannelUpperBehavior
29 123 5 40 104, 112, 120, 128, — NomadicBehavior,
136, 144 PrimaryChannelUpperBehavior,
DFS_50_100_Behavior,
UseEirpForVHTTxPowEnv
30 127 5 40 153, 161 — NomadicBehavior,
PrimaryChannelUpperBehavior
31 127 5 40 153, 161 — LicenseExemptBehavior,
PrimaryChannelUpperBehavior
32 83 2.407 40 1–7 — LicenseExemptBehavior,
PrimaryChannelLowerBehavior
33 84 2.407 40 5–11 — LicenseExemptBehavior,
PrimaryChannelUpperBehavior
34 180 56.16 2160 1, 2, 3, 4, 5, 6 — —
35–127 Reserved Reserved Reserved Reserved Reserved Reserved
128 128 5 80 — 42, 58, UseEirpForVHTTxPowEnv
106, 122,
138, 155
129 129 5 160 — 50, 114 UseEirpForVHTTxPowEnv
130 130 5 80 — 42, 58, 80+,
106, 122, UseEirpForVHTTxPowEnv
138, 155
131–255 Reserved Reserved Reserved Reserved Reserved Reserved
NOTE 1—The channel spacing for operating classes 22 to 33 specifies the maximum radio bandwidth of one frequency segment. In these
operating classes, the AP operating in a 20/40 MHz BSS, and the operating channel width for a non-AP STA is either 20 MHz or 40 MHz.
NOTE 2—The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one frequency
segment.
aThis operating class specifies
a list of channels in the 5.9 GHz band. Current regulations may only permit a subset of these
channels.
bIt is the responsibility of management layers outside the scope of this standard to ensure that channels in use at any location
are nonoverlapping.
3277
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Operating classes for operation in Europe are enumerated in Table E-2.
Table E-2—Operating classes in Europe
Global Channel Channel
Channel
Operating operating starting Channel center
spacing Behavior limits set
class class (see frequency
(MHz)
set frequenc
Table E-4) (GHz) y index
1 115 5 20 36, 40, —
44, 48
2 118 5 20 52, 56, — NomadicBehavior
60, 64
3 121 5 20 100, 104, —
108, 112,
116, 120,
124, 128,
132, 136,
140
4 81 2.407 25 1, 2, 3, 4, — LicenseExemptBehavior
5, 6, 7, 8,
9, 10, 11,
12, 13
5 116 5 40 36, 44 — PrimaryChannelLowerBehavior
6 119 5 40 52, 60 — PrimaryChannelLowerBehavior
7 122 5 40 100, 108, — PrimaryChannelLowerBehavior
116, 124,
132
8 117 5 40 40, 48 — PrimaryChannelUpperBehavior
9 120 5 40 56, 64 — PrimaryChannelUpperBehavior
10 123 5 40 104, 112, — PrimaryChannelUpperBehavior
120, 128,
136
11 83 2.407 40 1–9 — LicenseExemptBehavior,
PrimaryChannelLowerBehavior
12 84 2.407 40 5–13 — LicenseExemptBehavior,
PrimaryChannelUpperBehavior
13a — 5.0025 5 171–184 — ITS_nonmobile_operations,
ITS_mobile_operations
14a, b — 5 10 171–184 — ITS_nonmobile_operations,
ITS_mobile_operations
15a, b — 5 20 172–183 — ITS_nonmobile_operations,
ITS_mobile_operations
16 — 5 20 100, 104, — ITS_nonmobile_operations,
108, 112, ITS_mobile_operations
116, 120,
124, 128,
132, 136,
140
3278
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-2—Operating classes in Europe (continued)
Global Channel
Channel
Channel
Operating operating starting Channel center
spacing Behavior limits set
class class (see frequency
(MHz)
set frequenc
Table E-4) (GHz) y index
17 125 5 20 149, 153, —
157, 161,
165, 169
18 180 56.16 2160 1, 2, 3, 4 — —
19–127 Reserved Reserved Reserved Reserved Reserved Reserved
128 128 5 80 — 42, 58, UseEirpForVHTTxPowEnv
106, 122
129 129 5 160 — 50, 114 UseEirpForVHTTxPowEnv
130 130 5 80 — 42, 58, 80+,
106, 122 UseEirpForVHTTxPowEnv
131–255 Reserved Reserved Reserved Reserved Reserved Reserved
NOTE 1—The channel spacing for operating classes 5 to 12 specifies the maximum radio bandwidth of one frequency
segment In these operating classes, the AP operates in a 20/40 MHz BSS, and the operating channel width for a non-AP
STA is either 20 MHz or 40 MHz.
NOTE 2—The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one
frequency segment.
aThis operating class specifies a list of channels in the 5.9 GHz band. Current regulations may only permit a subset of these
channels.
bIt
is the responsibility of management layers outside the scope of this standard to ensure that channels in use at any
location are nonoverlapping.
Operating classes for operation in Japan are enumerated in Table E-3. Note that some of the operating
classes in this table were never used and are obsolete. The obsolete operating classes indicated by an asterisk
(*) might be removed in a future revision of the standard.
Table E-3—Operating classes in Japan
Global Channel Channel
Channel
Operating operating starting center
spacing Channel set Behavior limits set
class class (see frequency frequency
(MHz)
Table E-4) (GHz) index
1 115 5 20 34, 38, 42, 46a —
36, 40, 44, 48
2* 112 5 20 8, 12, 16 —
3 112 5 20 8, 12, 16 —
4* 112 5 20 8, 12, 16 —
5* 112 5 20 8, 12, 16 —
6 112 5 20 8, 12, 16 —
3279
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-3—Operating classes in Japan (continued)
Global Channel Channel
Channel
Operating operating starting center
spacing Channel set Behavior limits set
class class (see frequency frequency
(MHz)
Table E-4) (GHz) index
7* 109 4 20 184, 188, 192, —
196
8 109 4 20 184, 188, 192, —
196
9* 109 4 20 184, 188, 192, —
196
10* 109 4 20 184, 188, 192, —
196
11 109 4 20 184, 188, 192, —
196
12* 113 5 10 7, 8, 9, 11 —
13 113 5 10 7, 8, 9, 11 —
14* 113 5 10 7, 8, 9, 11 —
15* 113 5 10 7, 8, 9, 11 —
16* 110 4 10 183, 184, 185, —
187, 188, 189
17 110 4 10 183, 184, 185, —
187, 188, 189
18* 110 4 10 183, 184, 185, —
187, 188, 189
19* 110 4 10 183, 184, 185, —
187, 188, 189
20 110 4 10 183, 184, 185, —
187, 188, 189
21* 114 5.0025 5 6, 7, 8, 9, 10, 11 —
22 114 5.0025 5 6, 7, 8, 9, 10, 11 —
23* 114 5.0025 5 6, 7, 8, 9, 10, 11 —
24* 114 5.0025 5 6, 7, 8, 9, 10, 11 —
25 111 4.0025 5 182, 183, 184, —
185, 186, 187,
188, 189
26 111 4.0025 5 182, 183, 184, —
185, 186, 187,
188, 189
27* 111 4.0025 5 182, 183, 184, —
185, 186, 187,
188, 189
3280
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-3—Operating classes in Japan (continued)
Global Channel Channel
Channel
Operating operating starting center
spacing Channel set Behavior limits set
class class (see frequency frequency
(MHz)
Table E-4) (GHz) index
28* 111 4.0025 5 182, 183, 184, —
185, 186, 187,
188, 189
29 111 4.0025 5 182, 183, 184, —
185, 186, 187,
188, 189
30 81 2.407 25 1, 2, 3, 4, 5, 6, 7, — LicenseExemptBehavior
8, 9, 10, 11, 12,
13
31 82 2.414 25 14 — LicenseExemptBehavior
32 118 5 20 52, 56, 60, 64 —
33 118 5 20 52, 56, 60, 64 —
34 121 5 20 100, 104, 108, — DFS_50_100_Behavior
112, 116, 120,
124, 128, 132,
136, 140
35* 121 5 20 100, 104, 108, — DFS_50_100_Behavior
112, 116, 120,
124, 128, 132,
136, 140
36 116 5 40 36, 44 — PrimaryChannelLowerBehavior
37 119 5 40 52, 60 — PrimaryChannelLowerBehavior
38* 119 5 40 52, 60 — PrimaryChannelLowerBehavior
39 122 5 40 100, 108, 116, — PrimaryChannelLowerBehavior,
124, 132 DFS_50_100_Behavior
40* 122 5 40 100, 108, 116, — PrimaryChannelLowerBehavior,
124, 132 DFS_50_100_Behavior
41 117 5 40 40, 48 — PrimaryChannelUpperBehavior
42 120 5 40 56, 64 — PrimaryChannelUpperBehavior
43* 120 5 40 56, 64 — PrimaryChannelUpperBehavior
44 123 5 40 104, 112, 120, — PrimaryChannelUpperBehavior,
128, 136 DFS_50_100_Behavior
45* 123 5 40 104, 112, 120, — PrimaryChannelUpperBehavior,
128, 136 DFS_50_100_Behavior
46 104 4 40 184, 192 — PrimaryChannelLowerBehavior
47* 104 4 40 184, 192 — PrimaryChannelLowerBehavior
48* 104 4 40 184, 192 — PrimaryChannelLowerBehavior
49* 104 4 40 184, 192 — PrimaryChannelLowerBehavior
3281
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-3—Operating classes in Japan (continued)
Global Channel Channel
Channel
Operating operating starting center
spacing Channel set Behavior limits set
class class (see frequency frequency
(MHz)
Table E-4) (GHz) index
50* 104 4 40 184, 192 — PrimaryChannelLowerBehavior
51 105 4 40 188, 196 — PrimaryChannelUpperBehavior
52* 105 4 40 188, 196 — PrimaryChannelUpperBehavior
53* 105 4 40 188, 196 — PrimaryChannelUpperBehavior
54* 105 4 40 188, 196 — PrimaryChannelUpperBehavior
55* 105 4 40 188, 196 — PrimaryChannelUpperBehavior
56 83 2.407 40 1–9 — LicenseExemptBehavior,
PrimaryChannelLowerBehavior
57 84 2.407 40 5–13 — LicenseExemptBehavior,
PrimaryChannelUpperBehavior
58 121 5 20 100, 104, 108, — NomadicBehavior,
112, 116, 120, LicenseExemptBehavior
124, 128, 132,
136, 140
59 180 56.16 2160 1, 2, 3, 4 — —
60–127 Reserved Reserved Reserved Reserved Reserved Reserved
128 128 5 80 — 42, 58, 106, UseEirpForVHTTxPowEnv
122
129 129 5 160 — 50, 114 UseEirpForVHTTxPowEnv
130 130 5 80 — 42, 58, 106, 80+,
122 UseEirpForVHTTxPowEnv
131–255 Reserved Reserved Reserved Reserved Reserved Reserved
NOTE 1—The channel spacing for operating classes 34–55 specifies the maximum radio bandwidth of one frequency
segment In these regulatory domains, the AP operates in a 20/40 MHz BSS, and the operating channel width of a non-
AP STA is either
NOTE 2—The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one
frequency segment.
a
The use of channels 34, 38, 42, and 46 was included in the initial 5 GHz rules in May, 2005 and cannot be used after
May 2012.
3282
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Operating classes for operation anywhere in the world are enumerated in Table E-4, and are used in addition
to the operating classes enumerated in Table E-1, Table E-2, Table E-3 and (see 9.4.2.54). Where a BSS
includes STAs that do not support global operating classes, then all requests and Action frames to those
STAs that convey elements containing operating classes shall use nonglobal operating class values.
Table E-4—Global operating classes
Channel Channel
Nonglobal Channel
Operating starting Channel center
operating spacing Behavior limits set
class frequency set frequency
class(es) (MHz)
(GHz) index
1–80 — Reserved Reserved Reserved — Reserved
81 E-1-12, 2.407 25 1, 2, 3, 4, —
E-2-4, 5, 6, 7, 8,
E-3-30, 9, 10, 11,
E-5-7 12, 13
82 E-3-31 2.414 25 14 —
83 E-1-32, 2.407 40 1, 2, 3, 4, — PrimaryChannelLowerBehavior
E-2-11, 5, 6, 7, 8,
E-3-56, 9
E-5-8
84 E-1-33, 2.407 40 5, 6, 7, 8, — PrimaryChannelUpperBehavior
E-2-12, 9, 10, 11,
E-3-57, 12, 13
E-5-9
85 — — 6, 7, 8 — — GeoDB
86 — — 12, 14, 16 — — GeoDB
87 — — 24, 28, 32 — — GeoDB
88-93 — Reserved Reserved Reserved Reserved Reserved
94 E-1-13 3 20 133, 137 — CCA-EDBehavior
95 E-1-14 3 10 132, 134, — CCA-EDBehavior
136, 138
96 E-1-15 3.0025 5 131, 132, — CCA-EDBehavior
133, 134,
135, 136,
137, 138
97–100 — Reserved Reserved Reserved Reserved Reserved
101 E-1-10,11 4.85 20 21, 25 —
102 E-1-8,9 4.89 10 11, 13, —
15, 17, 19
103 E-1-6,7 4.9375 5 1, 2, 3, 4, —
5, 6, 7, 8,
9, 10
104 E-3- 4 40 184, 192 — PrimaryChannelLowerBehavior
46,47,48,
49,50
3283
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-4—Global operating classes (continued)
Channel Channel
Nonglobal Channel
Operating starting Channel center
operating spacing Behavior limits set
class frequency set frequency
class(es) (MHz)
(GHz) index
105 E-3- 4 40 188, 196 — PrimaryChannelUpperBehavior
51,52,53,
54,55
106 — 4 20 191, 195 —
107 — 4 10 189, 191, —
193, 195,
197
108 — 4.0025 5 188, 189, —
190, 191,
192, 193,
194, 195,
196, 197
109 E-3- 4 20 184, 188, —
7,8,9,10,11 192, 196
110 E-3- 4 10 183, 184, —
16,17,18, 185, 186,
19,20 187, 188,
189
111 E-3- 4.0025 5 182, 183, —
25,26,27, 184, 185,
28,29 186, 187,
188, 189
112 E-3- 5 20 8, 12, 16 —
2,3,4,5,6
113 E-3- 5 10 7, 8, 9, —
12,13,14,15 10, 11
114 E-3- 5.0025 5 6, 7, 8, 9, —
21,22,23,24 10, 11
115 E-1-1, 5 20 36, 40, — UseEirpForVHTTxPowEnv
E-2-1, 44, 48
E-3-1,
E-5-1
116 E-1-22, 5 40 36, 44 — PrimaryChannelLowerBehavior,
E-2-5, UseEirpForVHTTxPowEnv
E-3-36,
E-5-4
117 E-1-27, 5 40 40, 48 — PrimaryChannelUpperBehavior,
E-2-8, UseEirpForVHTTxPowEnv
E-3-41
118 E-1-2, 5 20 52, 56, — DFS_50_100_Behavior,
E-2-2, 60, 64 UseEirpForVHTTxPowEnv
E-3-32,33,
E-5-2
3284
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-4—Global operating classes (continued)
Channel Channel
Nonglobal Channel
Operating starting Channel center
operating spacing Behavior limits set
class frequency set frequency
class(es) (MHz)
(GHz) index
119 E-1-23, 5 40 52, 60 — PrimaryChannelLowerBehavior,
E-2-6, DFS_50_100_Behavior,
E-3-37,38, UseEirpForVHTTxPowEnv
E-5-5
120 E-1-28, 5 40 56, 64 — PrimaryChannelUpperBehavior,
E-2-9, DFS_50_100_Behavior,
E-3-42,43 UseEirpForVHTTxPowEnv
121 E-1-4, 5 20 100, 104, — DFS_50_100_Behavior,
E-2-3, 108, 112, UseEirpForVHTTxPowEnv
E-3-34, 116, 120,
35,58 124, 128,
132, 136,
140, 144
122 E-1-24, 5 40 100, 108, — PrimaryChannelLowerBehavior,
E-2-7, 116, 124, DFS_50_100_Behavior,
E-3-39,40 132, 140 UseEirpForVHTTxPowEnv
123 E-1-29, 5 40 104, 112, — PrimaryChannelUpperBehavior,
E-2-10, 120, 128, DFS_50_100_Behavior,
E-3-44,45 136, 144 UseEirpForVHTTxPowEnv
124 E-1-3 5 20 149, 153, — NomadicBehavior,
157, 161 UseEirpForVHTTxPowEnv
125 E-1-5, 5 20 149, 153, — LicenseExemptBehavior,
E-2-17, 157, 161, UseEirpForVHTTxPowEnv
E-5-3 165, 169
126 E-1-25,26, 5 40 149, 157 — PrimaryChannelLowerBehavior,
E-5-6 UseEirpForVHTTxPowEnv
127 E-1-30,31 5 40 153, 161 — PrimaryChannelUpperBehavior,
UseEirpForVHTTxPowEnv
128 E-1-128, 5 80 — 42, 58, 106, UseEirpForVHTTxPowEnv
E-2-128, 122, 138,
E-3-128 155
E-5-128
129 E-1-129, 5 160 — 50, 114 UseEirpForVHTTxPowEnv
E-2-129,
E-3-129
E-5-129
130 E-1-130, 5 80 — 42, 58, 106, 80+,
E-2-130, 122, 138, UseEirpForVHTTxPowEnv
E-3-130 155
E-5-130
131–179 — Reserved Reserved Reserved Reserved Reserved
180 E-1-34, 56.16 2160 1, 2, 3, 4, — —
E-2-18, 5, 6
E-3-59
181–191 — Reserved Reserved Reserved — Reserved
3285
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-4—Global operating classes (continued)
Channel Channel
Nonglobal Channel
Operating starting Channel center
operating spacing Behavior limits set
class frequency set frequency
class(es) (MHz)
(GHz) index
192–254 — Vendor Vendor Vendor — Vendor specific
specific specific specific
255 — Reserved Reserved Reserved — Reserved
NOTE 1—The channel spacing for operating classes 116, 117, 119, 120, 122, 123, 126, and 127 specifies the
maximum radio bandwidth of one frequency segment In these operating classes, the AP operates in a 20/40 MHz BSS,
and the operating channel width for a non-AP STA is either 20 MHz or 40 MHz.
NOTE 2—The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one
frequency segment.
For Behavior limit GeoDB, the channel starting frequency shall be the frequency that results in the
regulatory domain’s channel number being the RLAN channel number.
Operating classes for operation in China are enumerated in Table E-5.
Table E-5—Operating classes in China
Global Channel Channel
Channel
Operating operating starting Channel center
spacing Behavior limits set
class class (see frequency set frequency
(MHz)
Table E-4) (GHz) index
1 115 5 20 36, 40, — UseEirpForVHTTxPowEnv
44, 48
2 118 5 20 52, 56, — DFS_50_100_Behavior,
60, 64 UseEirpForVHTTxPowEnv
3 125 5 20 149, 153, — UseEirpForVHTTxPowEnv
157, 161,
165
4 116 5 40 36, 44 — PrimaryChannelLowerBeha
vior
UseEirpForVHTTxPowEnv
5 119 5 40 52, 60 — PrimaryChannelLowerBeha
vior
DFS_50_100_Behavior
UseEirpForVHTTxPowEnv
6 126 5 40 149, 157 — PrimaryChannelLowerBeha
vior
UseEirpForVHTTxPowEnv
7 81 2.407 25 1, 2, 3, 4, — LicenseExemptBehavior
5, 6, 7, 8,
9, 10, 11,
12, 13
8 83 2.407 40 1-9 — LicenseExemptBehavior,
PrimaryChannelLowerBeha
vior
3286
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-5—Operating classes in China (continued)
Global Channel Channel
Channel
Operating operating starting Channel center
spacing Behavior limits set
class class (see frequency set frequency
(MHz)
Table E-4) (GHz) index
9 84 2.407 40 5-13 — LicenseExemptBehavior,
PrimaryChannelUpperBeha
vior
10–127 Reserved Reserved Reserved Reserved Reserved Reserved
128 128 5 80 — 42, 58, 155 UseEirpForVHTTxPowEnv
129 129 5 160 — 50 UseEirpForVHTTxPowEnv
130 130 5 80 — 42, 58, 155 80+
UseEirpForVHTTxPowEnv
131–255 Reserved Reserved Reserved Reserved Reserved Reserved
NOTE 1—The channel spacing for operating classes 4 to 6 specifies the maximum radio bandwidth of one frequency
segment In these operating classes, the AP operates in a 20/40 MHz BSS, and the operating channel width for a non-
AP STA is either 20 MHz or 40 MHz.
NOTE 2—The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one
frequency segment.
Nonglobal operating classes refer to the operating classes enumerated in the leftmost column of Table E-1,
Table E-2, Table E-3, and Table E-5 (see 9.4.2.54).
NOTE 1—The following example Country element (see Figure 9-130) describes U.S. operation (‘55’, ‘53’) using both
Table E-1 class 12 (nonglobal) and Table E-4 class 81 (global) for the 2.4 GHz band, 11 channels at 20 dBm limit (in
hexadecimal): ‘07’, ‘0F’, ‘55’, ‘53’, ‘04’, ‘C9’, ‘0C’, ‘0’, ‘01’, ‘0B’, ‘14’, ‘C9’, ‘51’, ‘0’, ‘01’, ‘0B’, ‘14’.
NOTE 2—The following example Country element describes U.S. operation for an 80+80 MHz BSS using Table E-4
classes 116, 128 and 130 at a 100 mW limit for 40 MHz. The contents (in decimal) are '07' [Country element ID],
'18' [Length], '85', '83', '04' [Country string indicating United States and Table E-4], '201', '116', '0' [Operating Triplet
field for 20/40 MHz with the primary 20 MHz channel on the lower 20 MHz], '36', '1', '20' [Subband triplet field
indicating 20 dBm on the 40 MHz channel 36+40], '201','128', '0' [Operating Triplet field for 80 MHz], '201', '130', '0',
'201', '128', '0' [Pair of Operating Triplet field indicating 80+80 MHz]. Although the Operating Triplet fields for 80 MHz
and 80+80 MHz only express BSS bandwidths rather than specific regulatory permissions (so are optional), they are
included in this example.
Vendor Specific operating classes are used to carry information not defined in this standard within a single
defined format, so that reserved operating classes are not usurped for nonstandard purposes and so that
interoperability is more easily achieved in the presence of nonstandard information.
E.2 Band-specific operating requirements
E.2.1 General
Subclause E.2 contains requirements specific to particular bands and regulatory domains.
E.2.2 3650–3700 MHz in the United States
The registration authority is the FCC’s Universal Licensing System (ULS).
3287
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Regulations specify the following:
— Certified mobile and portable STAs do not need to be registered, but they “must” operate under the
control of an enabling STA (using DSE procedures).
— A registered STA “must” be a fixed STA.
— A registered STA “must” not operate as an enabling STA until the licensee has registered it as a
“base station” in ULS.
Enabling STAs and fixed STAs are registered STAs. Dependent non-AP STAs and dependent APs are
dependent STAs.
A STA shall use the following:
— CCA-ED
— CS/CCA
— TPC
— DFS
For OFDM PHY operation in this specific band, the CCA-ED thresholds shall be less than or equal to
–72 dBm for 20 MHz channel widths, –75 dBm for 10 MHz channel widths, and –78 dBm for 5 MHz
channel widths (minimum sensitivity for BPSK, R=1/2 + 10 dB in Table 17-18).
No STA shall use channel switch announcement.
No station may transmit for more than 4 ms without carrier sensing, whether transmitting fragments or
frames, unless it is controlled by another STA.
A STA shall have the following equal to true:
— dot11LCIDSERequired
— dot11SpectrumManagementRequired
— dot11MultiDomainCapabilityActivated
— dot11ExtendedChannelSwitchActivated
A STA shall be capable of receiving all channels associated with operating classes 13–15.
A STA shall be capable of transmitting on all channels associated with operating class 15.
A STA shall set the value of dot11DSETransmitDivisor to 256 and the other dot11DSE timer values as
shown in Table E-6.
Table E-6—DSE timer limits
Parameter Seconds
dot11DSEEnablementTimeLimit 32
dot11DSEEnablementFailHoldTime 512
dot11DSERenewalTime 60
3288
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz)
STAs operating with a behavior limit of ITS_nonmobile_operations in Table D-2 are required to be
registered with the FCC ULS. The registration includes the following:
— Classification by coverage size, which is defined by EIRP, and
— Identification of channels the STA is permitted to use.
A STA shall be classified for operation in this band by their maximum transmit power capability, as listed in
Table D-3 in D.2.2. A STA shall be compliant with the spectral emission requirements for their class listed
in D.2.3.
A STA shall have dot11OCBActivated equal to true.
EPD as defined in IEEE Std 802-2014 shall be used for transmission of all MSDUs.
E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz)
A STA shall have dot11OCBActivated equal to true.
EPD as defined in IEEE Std 802-2014 shall be used for transmission of all MSDUs.
E.2.5 TVWS band in the United States and Canada (54 MHz to 698 MHz)
Each GDD enabling STA and AP in TVWS determines the available TV channels at its location using its
own geographic location identification and TV bands database access capabilities. Each GDD dependent
STA in TVWS receives an available TV channel list from the STA that enables its operation.
The registration authorities are FCC designated TV bands administrators (FCC 47 CFR [B9], sections
15.713-715).
NOTE—IEEE 802.11 terms differ from FCC 47 CFR [B9], section 15.703, in many particulars. However, generally, a
GDD enabling STA is Fixed or Mode II TVBD, and each GDD dependent STA has only one GDD enabling STA at any
time. Generally, GDD dependent STAs are Mode I TVBDs. Each Fixed or Mode II TVBD is required to contact an
authorized TV bands device database and operate based on the information received from that TV bands database. Fixed
and Mode II TVBDs are certified to operate with specific TV bands databases using protocols specified by TV bands
database administrators. FCC regulations require an encrypted Contact Verification Signal be received by Mode I TVBD
to verify the integrity of the list of available channels FCC 47 CFR, section 15.711. Canadian regulation RSS-196 allows
Remote Rural Broadband operation at transmit powers to 125 W in 6 MHz. The Canadian Minister of Industry held a
consultation documented in SMSE-012-12, wherein a decision to act in concert with FCC license-exempt low power
regulations was taken. It is expected that Canadian RSS-210 will be revised to align with FCC 47 CFR, Part 15, Subpart
H-Television Band Devices.
STAs operating in TVWS shall use
— CS/CCA
— DFS
No STA operating in TVWS shall use Channel Switch Announcement.
STAs operating in TVWS shall have the following equal to true
— dot11GDDActivated
— dot11OperatingClassesRequired
— dot11SpectrumManagementRequired
3289
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— dot11MultiDomainCapabilityActivated
— dot11ContactVerificationSignalActivated
For GDD dependent STA operation in TVWS, the GDD enabling signal (see 11.44.2) is received directly
from a GDD enabling STA and is a Beacon frame or Probe Response frame containing a Geodatabase
Inband Enabling Signal field indicating that enablement in the frequency band is possible.
All GDD dependent STAs shall set the dot11GDD timer values as shown in Table E-7.
Table E-7—TVWS GDD timer limits
Parameter Seconds
dot11GDDEnablementTimeLimit 32
dot11GDDEnablementFailHoldTime 512
dot11ContactVerificationSignalInterval 60
dot11GDDEnablementValidityTimer 60
NOTE—Be aware that most protocols above the MAC operate in the opposite endianness from what is used in
Table E-8 and Table E-9.
The Device Identification Information format is shown in Table E-8.
Table E-8—Device Identification Information Value fields
Length Scope/
Name Type Value
(octets) Country code
FCC ID 4 14 The device identification contains the 14-octet FCC US
ID of the device.
Industry Canada 5 11 The device identification contains the 11-octet CA
ID Industry Canada ID of the device. This value not
present in the United States.
Device Serial 6 4 The Device Serial Number field contains the US
Number manufacturer’s serial number. This field is present
only if the Device Class field (Table 9-264) is equal
to 2 (GDD AP) or 3 (GDD fixed STA); otherwise,
this field is not present.
The WSM Information Value fields format is shown in Table E-9. In some regulatory domains, an AP can
retrieve the WSM information from the GDB through the upper layer protocol (e.g., IETF Protocol to
Access WS database ‘paws-protocol’). When the AP retrieves the WSM information from the upper layer, it
may translate it to the WSM Information field format shown in Table E-9, which is the link-layer-specific
information.
NOTE—In the United States, an example of full Map 1 for a U.S. GDD non-AP STA describing two available channels
with power limits of 100 mW and 40 mW is shown as 85, 0x06, 0x00, 0x03, 0x15, 0x28, 0x33, 0x20. Type is 85, Length
is 0x06, Device Class is 0x00, a full map with MapID 1 is 0x03, TV channel 21 is 0x15, 20 dBm Maximum Power Level
is 0x28, TV channel 51 is 0x33, 16 dBm Maximum Power Level is 0x20.
3290
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table E-9—WSM Information Value fields
Scope/
Length
Name Value Country
(octets)
code
Device Class 1 Single octet TLV comprising fields in Table 9-264. WSM
Map ID 1 Bit 0: The Type bit, which indicates whether the following WSM
channel list is a full channel list or a partial channel list. If the
Type bit is 1, the following channel list is a full channel list; and
if the Type bit is 0, the following channel list is a partial channel
list.
Bits 1–7: The Map version field, which identifies the version of
the WSM.
Channel Number 1 The Channel Number field is a positive integer value as defined WSM, US
in E.1 that indicates the available TV channel for WLAN
operation. When the Channel Number field and Maximum
Power Level field pairs are repeated, they are listed in
ascending TV channel order.
Maximum Power 1 The Maximum Power Level field indicates the maximum WSM, US
Level power, in units of 0.5 dBm, allowed to be transmitted on the
channel indicated in the Channel Number field.
E.2.6 TVWS band in Europe
Each GDD enabling STA and AP in TVWS determines the available TV channels at its location using its
own geographic location identification and TV bands database access capabilities. Each GDD dependent
STA in TVWS receives an available TV channel list from the STA that enables its operation.
The Harmonized Standard for unlicensed device operation in TVWS is EN 301 598.
STAs operating in TVWS shall use:
— CS/CCA
— DFS
No STA operating in TVWS shall use Channel Switch Announcement.
STAs operating in TVWS shall have the following equal to true
— dot11GDDActivated
— dot11OperatingClassesRequired
— dot11SpectrumManagementRequired
— dot11MultiDomainCapabilityActivated
— dot11ContactVerificationSignalActivated
For GDD dependent STA operation in TVWS, the GDD enabling signal (see 11.44.2) is received directly
from a GDD enabling STA and is a Beacon frame or Probe Response frame containing a Geodatabase
Inband Enabling Signal field indicating that enablement in the frequency band is possible.
3291
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
All GDD dependent STAs shall set the dot11GDD timer values as shown in Table E-10.
Table E-10—TVWS GDD timer limits
Parameter Seconds
dot11GDDEnablementTimeLimit 32
dot11GDDEnablementFailHoldTime 512
dot11ContactVerificationSignalInterval 60
dot11GDDEnablementValidityTimer 60
3292
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex F
(normative)
HT LDPC matrix definitions
Table F-1 defines the matrix prototypes of the parity-check matrices for a codeword block length
n = 648 bits, with a subblock size Z = 27 bits.
Table F-1—Matrix prototypes for codeword block length n = 648 bits,
subblock size is Z = 27 bits
(a) Coding rate R = 1/2.
0 - - - 0 0 - - 0 - - 0 1 0 - - - - - - - - - -
22 0 - - 17 - 0 0 12 - - - - 0 0 - - - - - - - - -
6 - 0 - 10 - - - 24 - 0 - - - 0 0 - - - - - - - -
2 - - 0 20 - - - 25 0 - - - - - 0 0 - - - - - - -
23 - - - 3 - - - 0 - 9 11 - - - - 0 0 - - - - - -
24 - 23 1 17 - 3 - 10 - - - - - - - - 0 0 - - - - -
25 - - - 8 - - - 7 18 - - 0 - - - - - 0 0 - - - -
13 24 - - 0 - 8 - 6 - - - - - - - - - - 0 0 - - -
7 20 - 16 22 10 - - 23 - - - - - - - - - - - 0 0 - -
11 - - - 19 - - - 13 - 3 17 - - - - - - - - - 0 0 -
25 - 8 - 23 18 - 14 9 - - - - - - - - - - - - - 0 0
3 - - - 16 - - 2 25 5 - - 1 - - - - - - - - - - 0
(b) Coding rate R = 2/3.
25 26 14 - 20 - 2 - 4 - - 8 - 16 - 18 1 0 - - - - - -
10 9 15 11 - 0 - 1 - - 18 - 8 - 10 - - 0 0 - - - - -
16 2 20 26 21 - 6 - 1 26 - 7 - - - - - - 0 0 - - - -
10 13 5 0 - 3 - 7 - - 26 - - 13 - 16 - - - 0 0 - - -
23 14 24 - 12 - 19 - 17 - - - 20 - 21 - 0 - - - 0 0 - -
6 22 9 20 - 25 - 17 - 8 - 14 - 18 - - - - - - - 0 0 -
14 23 21 11 20 - 24 - 18 - 19 - - - - 22 - - - - - - 0 0
17 11 11 20 - 21 - 26 - 3 - - 18 - 26 - 1 - - - - - - 0
(c) Coding rate R = 3/4.
16 17 22 24 9 3 14 - 4 2 7 - 26 - 2 - 21 - 1 0 - - - -
25 12 12 3 3 26 6 21 - 15 22 - 15 - 4 - - 16 - 0 0 - - -
25 18 26 16 22 23 9 - 0 - 4 - 4 - 8 23 11 - - - 0 0 - -
9 7 0 1 17 - - 7 3 - 3 23 - 16 - - 21 - 0 - - 0 0 -
24 5 26 7 1 - - 15 24 15 - 8 - 13 - 13 - 11 - - - - 0 0
2 2 19 14 24 1 15 19 - 21 - 2 - 24 - 3 - 2 1 - - - - 0
(d) Coding rate R = 5/6.
17 13 8 21 9 3 18 12 10 0 4 15 19 2 5 10 26 19 13 13 1 0 - -
3 12 11 14 11 25 5 18 0 9 2 26 26 10 24 7 14 20 4 2 - 0 0 -
22 16 4 3 10 21 12 5 21 14 19 5 - 8 5 18 11 5 5 15 0 - 0 0
7 7 14 14 4 16 16 24 24 10 1 7 15 6 10 26 8 18 21 14 1 - - 0
3293
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table F-2 defines the matrix prototypes of the parity-check matrices for a codeword block length
n = 1296 bits, with a subblock size Z = 54 bits.
Table F-2—Matrix prototypes for codeword block length n = 1296 bits,
subblock size is Z = 54 bits
(a) Coding rate R = 1/2.
40 - - - 22 - 49 23 43 - - - 1 0 - - - - - - - - - -
50 1 - - 48 35 - - 13 - 30 - - 0 0 - - - - - - - - -
39 50 - - 4 - 2 - - - - 49 - - 0 0 - - - - - - - -
33 - - 38 37 - - 4 1 - - - - - - 0 0 - - - - - - -
45 - - - 0 22 - - 20 42 - - - - - - 0 0 - - - - - -
51 - - 48 35 - - - 44 - 18 - - - - - - 0 0 - - - - -
47 11 - - - 17 - - 51 - - - 0 - - - - - 0 0 - - - -
5 - 25 - 6 - 45 - 13 40 - - - - - - - - - 0 0 - - -
33 - - 34 24 - - - 23 - - 46 - - - - - - - - 0 0 - -
1 - 27 - 1 - - - 38 - 44 - - - - - - - - - - 0 0 -
- 18 - - 23 - - 8 0 35 - - - - - - - - - - - - 0 0
49 - 17 - 30 - - - 34 - - 19 1 - - - - - - - - - - 0
(b) Coding rate R = 2/3.
39 31 22 43 - 40 4 - 11 - - 50 - - - 6 1 0 - - - - - -
25 52 41 2 6 - 14 - 34 - - - 24 - 37 - - 0 0 - - - - -
43 31 29 0 21 - 28 - - 2 - - 7 - 17 - - - 0 0 - - - -
20 33 48 - 4 13 - 26 - - 22 - - 46 42 - - - - 0 0 - - -
45 7 18 51 12 25 - - - 50 - - 5 - - - 0 - - - 0 0 - -
35 40 32 16 5 - - 18 - - 43 51 - 32 - - - - - - - 0 0 -
9 24 13 22 28 - - 37 - - 25 - - 52 - 13 - - - - - - 0 0
32 22 4 21 16 - - - 27 28 - 38 - - - 8 1 - - - - - - 0
(c) Coding rate R = 3/4.
39 40 51 41 3 29 8 36 - 14 - 6 - 33 - 11 - 4 1 0 - - - -
48 21 47 9 48 35 51 - 38 - 28 - 34 - 50 - 50 - - 0 0 - - -
30 39 28 42 50 39 5 17 - 6 - 18 - 20 - 15 - 40 - - 0 0 - -
29 0 1 43 36 30 47 - 49 - 47 - 3 - 35 - 34 - 0 - - 0 0 -
1 32 11 23 10 44 12 7 - 48 - 4 - 9 - 17 - 16 - - - - 0 0
13 7 15 47 23 16 47 - 43 - 29 - 52 - 2 - 53 - 1 - - - - 0
(d) Coding rate R = 5/6.
48 29 37 52 2 16 6 14 53 31 34 5 18 42 53 31 45 - 46 52 1 0 - -
17 4 30 7 43 11 24 6 14 21 6 39 17 40 47 7 15 41 19 - - 0 0 -
7 2 51 31 46 23 16 11 53 40 10 7 46 53 33 35 - 25 35 38 0 - 0 0
19 48 41 1 10 7 36 47 5 29 52 52 31 10 26 6 3 2 - 51 1 - - 0
3294
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table F-3 defines the matrix prototypes of the parity-check matrices for a codeword block length
n = 1944 bits, with a subblock size Z = 81 bits.
Table F-3—Matrix prototypes for codeword block length n = 1944 bits,
subblock size is Z = 81 bits
(a) Coding rate R = 1/2.
57 - - - 50 - 11 - 50 - 79 - 1 0 - - - - - - - - - -
3 - 28 - 0 - - - 55 7 - - - 0 0 - - - - - - - - -
30 - - - 24 37 - - 56 14 - - - - 0 0 - - - - - - - -
62 53 - - 53 - - 3 35 - - - - - - 0 0 - - - - - - -
40 - - 20 66 - - 22 28 - - - - - - - 0 0 - - - - - -
0 - - - 8 - 42 - 50 - - 8 - - - - - 0 0 - - - - -
69 79 79 - - - 56 - 52 - - - 0 - - - - - 0 0 - - - -
65 - - - 38 57 - - 72 - 27 - - - - - - - - 0 0 - - -
64 - - - 14 52 - - 30 - - 32 - - - - - - - - 0 0 - -
- 45 - 70 0 - - - 77 9 - - - - - - - - - - - 0 0 -
2 56 - 57 35 - - - - - 12 - - - - - - - - - - - 0 0
24 - 61 - 60 - - 27 51 - - 16 1 - - - - - - - - - - 0
(b) Coding rate R = 2/3.
61 75 4 63 56 - - - - - - 8 - 2 17 25 1 0 - - - - - -
56 74 77 20 - - - 64 24 4 67 - 7 - - - - 0 0 - - - - -
28 21 68 10 7 14 65 - - - 23 - - - 75 - - - 0 0 - - - -
48 38 43 78 76 - - - - 5 36 - 15 72 - - - - - 0 0 - - -
40 2 53 25 - 52 62 - 20 - - 44 - - - - 0 - - - 0 0 - -
69 23 64 10 22 - 21 - - - - - 68 23 29 - - - - - - 0 0 -
12 0 68 20 55 61 - 40 - - - 52 - - - 44 - - - - - - 0 0
58 8 34 64 78 - - 11 78 24 - - - - - 58 1 - - - - - - 0
(c) Coding rate R = 3/4.
48 29 28 39 9 61 - - - 63 45 80 - - - 37 32 22 1 0 - - - -
4 49 42 48 11 30 - - - 49 17 41 37 15 - 54 - - - 0 0 - - -
35 76 78 51 37 35 21 - 17 64 - - - 59 7 - - 32 - - 0 0 - -
9 65 44 9 54 56 73 34 42 - - - 35 - - - 46 39 0 - - 0 0 -
3 62 7 80 68 26 - 80 55 - 36 - 26 - 9 - 72 - - - - - 0 0
26 75 33 21 69 59 3 38 - - - 35 - 62 36 26 - - 1 - - - - 0
(d) Coding rate R = 5/6.
13 48 80 66 4 74 7 30 76 52 37 60 - 49 73 31 74 73 23 - 1 0 - -
69 63 74 56 64 77 57 65 6 16 51 - 64 - 68 9 48 62 54 27 - 0 0 -
51 15 0 80 24 25 42 54 44 71 71 9 67 35 - 58 - 29 - 53 0 - 0 0
16 29 36 41 44 56 59 37 50 24 - 65 4 65 52 - 4 - 73 52 1 - - 0
3295
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex G
(normative)
Frame exchange sequences
G.1 General
The allowable frame exchange sequences are defined using an extension of the EBNF format as defined in
ISO/IEC 14977:1996 [B49]. The elements of this syntax that are used here are as follows:
— [a] = a is optional.
— {a} = a is repeated zero or more times.
— n{a} = a is repeated n or more times. For example, 3{a} requires 3 or more "a". This notation is an
extension to ISO/IEC 14977 and equivalent to n*a{a} as defined in that standard.
— a|b|c|... = selection between mutually exclusive alternatives, a, b, c ....
— ( ) = grouping, e.g., "a (b|c)" is equivalent to "a b | a c".
— (* a *) = “a” is a comment. Comments are placed before the text they relate to.
— < > = order of frames not relevant. For example, is either "a b" or "b a."
— A rule is terminated by a semicolon ";"
— The meaning of whitespace is changed from ISO/IEC 14977. The name of terminals do not contain
whitespace, and the concatenate-symbol (comma in ISO/IEC 14977) is replaced by white space.
Whitespace appearing between the names of terminals indicates concatenation. Otherwise,
whitespace is not significant and is used to highlight the nesting of grouped terms.
Two types of terminals are defined:
— Frames. The name of a frame is shown in bold and identified by its type/subtype (e.g., Beacon,
Data). Frames are shown with an initial capital letter.
— Attributes. The name of attributes are shown in italic. An attribute is introduced by the "+" character.
The attribute specifies a condition that applies to the frame (or alternatively, for the attributes that
start +mu, the A-MPDU) that precedes it. Where there are multiple attributes applied, they are gen-
erally ordered in the same order of the fields in the frame to which they refer. The syntax a+(b|c)
where b and c are attributes is equivalent to (a+b) | (a+c).
In this syntax the names of nonterminals are shown in a normal font, i.e., a sequence of words joined by
hyphens (e.g., cf-frame-exchange-sequence).
The attributes are defined in Table G-1.
Table G-1—Attributes applicable to frame exchange sequence definition
Attribute Description
a-mpdu Frame is part of an A-MPDU aggregate. See NOTE 2.
a-mpdu-end Frame is the last frame in an A-MPDU aggregate. See NOTE 2.
block-ack QoS Data frame has ack policy equal to Block Ack.
broadcast Frame RA is the broadcast address.
3296
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table G-1—Attributes applicable to frame exchange sequence definition (continued)
Attribute Description
CF Beacon contains a CFP element.
CF-Ack Data type CF-Ack subtype bit (Frame Control field B4) equal to 1 or CF-End
+CF-Ack frame.
CF-Poll Data type CF-Poll subtype bit (Frame Control field B5) equal to 1.
csi An Action frame carrying channel state feedback (i.e., CSI, uncompressed
beamforming, or compressed beamforming feedback matrices).
csi-request A +HTC frame with the Feedback Request field equal to a value > 0.
delayed BlockAck or BlockAckReq frame under a delayed policy.
delayed-no-ack BlockAck or BlockAckReq frame has the BA Ack Policy or BAR Ack Policy
field, respectively, equal to No Acknowlegement.
DTIM Beacon is a DTIM.
frag Frame has its More Fragments subfield equal to 1.
group Frame RA has i/g bit equal to 1.
HTC +HTC frame, i.e., a frame that contains the HT Control field, including the
Control Wrapper frame. See NOTE.
implicit-bar QoS Data frame in an A-MPDU with Normal Ack policy.
individual Frame RA has i/g bit equal to 0.
last Frame has its More Fragments subfield equal to 0.
L-sig L-sig duration not equal to PPDU duration.
action-no-ack Management frame of subtype Action No Ack.
mfb A +HTC frame with the MFB field is not equal to all 1s.
more-psmp A PSMP frame with the More PSMP field equal to 1.
mrq A +HTC frame with the MRQ subfield equal to 1.
mu-ppdu-end This attribute delineates the end of a VHT MU PPDU. See NOTE 3 and
NOTE 4.
mu-user-respond The preceding frame or A-MPDU is part of a VHT MU PPDU and is addressed
to a user from which an immediate response is expected. See NOTE 3 and
NOTE 4.
mu-user-not-respond The preceding frame or A-MPDU is part of a VHT MU PPDU and is addressed
to a user from which no immediate response is expected. See NOTE 3 and
NOTE 4.
ndp-announce A +HTC frame with the HT NDP Announcement subfield equal to 1.
no-ack QoS Data frame with the Ack Policy subfield equal to No Ack.
no-more-psmp A PSMP frame with the More PSMP field equal to 0.
normal-ack QoS Data frame with the Ack Policy subfield equal to Normal Ack.
non-QAP Frame is transmitted by a non-AP QoS STA.
non-stbc PPDU TXVECTOR STBC parameter is equal to 0.
null Data type Null Data subtype bit (Frame Control field B6) equal to 1.
pifs Frame is transmitted following a PIFS.
psmp-ack Ack Policy field of QoS Data frame is equal to PSMP Ack.
3297
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table G-1—Attributes applicable to frame exchange sequence definition (continued)
Attribute Description
QAP Frame is transmitted by a QoS AP.
QoS Data type QoS subtype bit (Frame Control field B7) equal to 1.
RD Frame includes an HT Control field in which the RDG/More PPDU subfield is
equal to 1.
self Frame RA = TA.
sounding PPDU TXVECTOR SOUNDING parameter is present and equal to
SOUNDING.
stbc PPDU TXVECTOR STBC parameter is equal to a value >0.
to-ap Frame is addressed to the AP.
trq Frame is a +HTC frame with the TRQ field equal to 1.
NOTE 1—A Control frame that contains the HT Control field is always transmitted using the Control Wrapper
frame.
NOTE 2—In the case of VHT single MPDU, a single MPDU is carried in a A-MPDU, but the attributes +a-
mpdu and +a-mpdu-end are not used.
NOTE 3—+mu-ppdu-end, +mu-user-respond and +mu-user-other are used in productions that generate VHT
MU PPDUs, according to the pattern: ["an A-MPDU (which might contain a VHT single MPDU) needing a
response" +mu-user-respond ] {"an A-MPDU (which might contain a VHT single MPDU) not needing a
response" +mu-user-not-respond} +mu-ppdu-end. There is at least one of +mu-user-respond or +mu-user-not-
respond in a VHT MU PPDU.
NOTE 4—In the sequence A+mu-user-respond B+mu-user-not-respond … +mu-ppdu-end, although the
terms A, B … (which represent one or more frames) are listed sequentially in these productions, the per-user
sequence of frames represented by A, B, ... are transmitted simultaneously per-user using a VHT MU PPDU.
G.2 Basic sequences
An allowable frame exchange sequence is defined by the rule frame-exchange-sequence. Except where
modified by the pifs attribute, frames are separated by a SIFS or RIFS.
(* This rule defines all of the allowable frame exchange sequences *)
frame-exchange-sequence =
( [CTS] (Management +broadcast | Data +group) ) |
( [CTS | RTS CTS | PS-Poll] {frag-frame Ack} last-frame Ack ) |
(PS-Poll Ack) |
( [Beacon +DTIM ] {cf-sequence} [CF-End [+CF-Ack] ] )|
hcf-sequence |
mcf-sequence;
(* A frag-frame is a nonfinal part of an individually addressed MSDU or MMPDU *)
frag-frame = (Data | Management) +individual +frag;
(* This is the last (or only) part of a an individually addressed MSDU or MMPDU *)
last-frame = (Data | Management) +individual +last;
(* A cf-sequence expresses all of the sequences that may be generated within a contention free period. The
first frame in this sequence is sent by the AP. *)
cf-sequence =
3298
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(*Broadcast *)
Beacon | Management +broadcast | Data +group [+QoS] |
(* CF poll with data *)
(Data+individual +CF-Poll [+CF-Ack]
(Data +individual +CF-Ack [Data +null +CF-Ack] |
Data +null +CF-Ack) ) |
(* CF poll without data *)
Data +individual +null +CF-Poll [+CF-Ack]
(Data +null |
(Data +individual (Data +null +CF-Ack | Ack ) ) )|
(* individual management *)
(Management +individual Ack) |
(* All of the sequences initiated by an HC *)
hcf-sequence;
G.3 EDCA and HCCA sequences
(* An hcf-sequence represents all of the sequences that may be generated under HCCA. The sequence may
be initiated by an HC within a CFP, or it may be initiated by a STA using EDCA channel access. *)
hcf-sequence =
( [CTS] 1{(Data +group [+QoS] ) | Management +broadcast) +pifs} |
( [CTS] 1{txop-sequence} ) |
(* HC only, polled TXOP delivery *)
( [RTS CTS] non-cf-ack-piggybacked-qos-poll-sequence ) |
(* HC only, polled TXOP delivery *)
cf-ack-piggybacked-qos-poll-sequence |
(* HC only, self TXOP delivery or termination *)
Data +self +null +CF-Poll +QoS;
(* A cf-ack-piggybacked-qos-poll-sequence is the start of a polled TXOP that also delivers a CF-Ack. There
are two main variants, polls that deliver data and, therefore, need acknowledgment and polls that do not. *)
cf-ack-piggybacked-qos-poll-sequence=
(qos-poll-requiring-no-ack +CF-Ack (
[CTS +self] polled-txop-content |
polled-txop-termination) ) |
(qos-poll-requiring-ack +CF-Ack (
Ack (
3299
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
polled-txop-content |
polled-txop-termination) ) |
cf-ack-piggybacked-qos-data-sequence);
(* A non-cf-ack-piggybacked-qos-poll-sequence is the start of a polled TXOP that does not deliver a CF-
Ack. Except for this, it is identical to the CF-Ack version. *)
non-cf-ack-piggybacked-qos-poll-sequence=
(qos-poll-requiring-no-ack (
[CTS +self] polled-txop-content |
polled-txop-termination) ) |
(qos-poll-requiring-ack (
Ack (
polled-txop-content |
polled-txop-termination) ) |
cf-ack-piggybacked-qos-data-sequence);
(* This sequence is the delivery of a single frame that is the TXOP poll frame that does not require
acknowledgment either because the frame carries no data or because the frame carries data that do not
require immediate acknowledgment. *)
qos-poll-requiring-no-ack =
Data +null +CF-Poll +QoS |
Data +individual +CF-Poll +QoS +(no-ack|block-ack);
(* A qos-poll-requiring-ack is the delivery of a single frame that is a TXOP poll frame, but also carries data
that require immediate acknowledgment. *)
qos-poll-requiring-ack =
Data +individual +CF-Poll [+CF-Ack] +QoS +normal-ack;
(* Polled-txop-content is what may occur after the delivery of a polled TXOP. A QoS STA transmits the
first frame in this sequence *)
polled-txop-content =
1{txop-sequence} [polled-txop-termination];
(* A polled-txop-termination may be used by a QoS STA to terminate the polled TXOP. The Data frame is
addressed to the HC, which regains control of the medium and may reuse any unused polled TXOP duration.
*)
polled-txop-termination =
Data +individual +null +QoS +normal-ack Ack;
(* A TXOP (either polled or EDCA) may be filled with txop-sequences, which are initiated by the TXOP
holder. *)
txop-sequence =
( ( (RTS CTS) | CTS +self) Data +individual +QoS +(block-ack | no-ack) ) |
[RTS CTS] (txop-part-requiring-ack txop-part-providing-ack )|
[RTS CTS] (Management | (Data +QAP)) +individual Ack |
[RTS CTS] (BlockAckReq BlockAck) |
ht-txop-sequence;
(* These frames require acknowledgment *)
txop-part-requiring-ack =
3300
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Data +individual [+null] |
Data +individual [+null] +QoS +normal-ack |
BlockAckReq +delayed |
BlockAck +delayed;
(* These frames provide acknowledgment to the txop-part-requiring-ack *)
txop-part-providing-ack=
Ack |
cf-ack-piggybacked-qos-poll-sequence | (* An HC responds with a new polled
TXOP on expiration of current TXOP
*)
cf-ack-piggybacked-qos-data-sequence | (* An HC responds with CF-Ack and its
own data on expiration of TXOP *)
Data +CF-Ack;
(* An HC has received a frame requiring acknowledgment with a duration value indicating the end of the
TXOP. The HC continues the CAP by transmitting its own data. *)
cf-ack-piggybacked-qos-data-sequence =
( Data +individual +CF-Ack +QoS +(no-ack|block-ack) polled-txop-content ) |
( Data +individual +CF-Ack +QoS+normal-ack (
Ack polled-txop-content |
Data +CF-Ack |
cf-ack-piggybacked-qos-poll-sequence ) ) ;
(* An mcf-sequence represents all of the sequences that may be generated under MCF. The sequence may be
initiated by a mesh STA using EDCA channel access or MCCA channel access. *)
mcf-sequence =
( [CTS] |{(Data+group+QoS ) | Management+broadcast} ) | ( [CTS] 1{txop-sequence} ) |
group-mccaop-abandon;
(* A group-mccaop-abandon is the delivery of a single QoS Null frame by a mesh STA that has
dot11MCCAActivated true. *)
group-mccaop-abandon =
Data+broadcast+null+QoS
G.4 HT and VHT sequences
(* The ht-txop-sequence describes the additional sequences that may be initiated by an HT STA that is the
holder of a TXOP *)
ht-txop-sequence = L-sig-protected-sequence |
ht-nav-protected-sequence |
dual-cts-protected-sequence |
1{initiator-sequence};
(* an L-sig-protected-sequence is a sequence protected using the L-sig TXOP protection feature *)
L-sig-protected-sequence = L-sig-protection-set 1{initiator-sequence} resync-sequence;
(* an ht-nav-protected sequence consists of setting the NAV, performing one or more initiator-sequences
and then resetting the NAV if time permits *)
ht-nav-protected-sequence = nav-set 1{initiator-sequence} [resync-sequence] ;
3301
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(* a dual-cts-protected-sequence is a sequence protected using the dual CTS protection feature *)
dual-cts-protected-sequence = dual-cts-nav-set 1{initiator-sequence} [dual-cts-nav-reset];
(* a dual-cts-nav-set is an initial exchange that establishes NAV protection using dual CTS protection. *)
dual-cts-nav-set = (* A dual CTS initiated by a non-AP HT STA that is not STBC-capable,
preceded by an optional CTS frame addressed to the AP. *)
(
[ CTS+to-ap+non-stbc+non-QAP ]
RTS+non-stbc+non-QAP
CTS+non-stbc+QAP
[ CTS+stbc+pifs+QAP ]
)|
(* A dual CTS initiated by a non-AP STA that is STBC-capable, preceded by an
optional CTS frame addressed to the AP. *)
(
[ CTS+to-ap+stbc+non-QAP ]
RTS+stbc+non-QAP
CTS+stbc+QAP
CTS+non-stbc+QAP
)|
(* An STBC initiator-sequence (i.e., containing STBC PPDUs) transmitted by
the AP is protected by non-STBC CTS to self *)
(CTS+self+non-stbc+QAP) |
(* A non-STBC initiator-sequence transmitted by the AP is protected by STBC
CTS to self *)
(CTS+self+stbc+QAP);
(* a dual-cts-nav-reset resets the NAV in the vicinity of the transmitting non-AP STA, and resets the NAV
of both STBC and non-STBC-capable STA in the vicinity of the AP *)
dual-cts-nav-reset = [CF-End+non-QAP] CF-End+stbc+QAP CF-End+non-stbc+QAP);
(* an ma-no-ack-htc represents an Action No Ack + HTC frame *)
ma-no-ack-htc = Management+action-no-ack+HTC;
(* This is the sequence of frames that establish protection using the L-sig TXOP protection method *)
L-sig-protection-set = (RTS+L-sig[+HTC] CTS+L-sig[+HTC]) |
(Data+individual+L-sig [+HTC][+null][+QoS+normal-ack] Ack [+HTC] +L-sig)
|
( 1{ Data+L-sig[+HTC]+individual+QoS+implicit-bar+a-mpdu}+a-mpdu-end
BlockAck+L-sig[+HTC]
)|
(BlockAckReq+L-sig[+HTC] (BlockAck[+HTC]|Ack[+HTC])+L-sig) |
(BlockAck+L-sig[+HTC] Ack[+HTC])+L-sig);
(* These are the series of frames that establish NAV protection for an HT sequence *)
nav-set = (RTS[+HTC] CTS[+HTC]) |
CTS+self |
(Data[+HTC]+individual[+null][+QoS+normal-ack] Ack) |
Data[+HTC]+individual[+QoS+(block-ack)] |
Data+group[+null][+QoS] |
3302
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
( 1{ Data[+HTC]+individual+QoS+implicit-bar+a-mpdu}+a-mpdu-end
BlockAck[+HTC]
)|
(BlockAckReq[+HTC] (BlockAck[+HTC]|Ack[+HTC])) |
(BlockAck[+HTC] Ack)
1{vht-rts-cts};
(* The vht-rts-cts term applies to RTS transmitted by a VHT STA to another VHT STA. When the RTS is
transmitted using a non-HT or non-HT duplicate PPDU, the transmission of the RTS is delayed so that at
least a PIFS has elapsed since the previous frame exchange sequence (see 10.22.2.7) and the RTS is
transmitted with a signaling TA (see 10.3.2.6). *)
vht-rts-cts = RTS+pifs [+HTC] CTS[+HTC];
resync-sequence = CF-End | (CF-End+non-QAP CF-End+QAP);
(* This is an initiator sequence. The different forms arise from whether the initiator transmits a frame that
requires a BlockAck frame, and whether it delivers an RDG. When an RDG is delivered, the response is
distinguished according to whether it demands a BlockAck frame response from the initiator. *)
initiator-sequence = (* No BlockAck frame expected, no RDG *)
burst |
(* block ack request delivered, BlockAck frame expected. No RD *)
(burst-bar (BlockAck|Ack) [+HTC]) |
(* No block ack request delivered, RDG *)
(burst-rd (
burst |
burst-bar initiator-sequence-ba
)
)|
(burst-rd-bar (BlockAck|Ack) [+HTC]) |
(burst-rd-bar (
burst-ba |
burst-ba-bar initiator-sequence-ba
)
)|
ht-ack-sequence |
psmp-burst |
link-adaptation-exchange ;
(* This is the same as the initiator-sequence, except the initiator is constrained to generate a BlockAck frame
response because a previous RD response contained a block ack request *)
initiator-sequence-ba = burst-ba |
(burst-ba-bar (BlockAck|Ack)[+HTC)) |
(burst-ba-rd (
burst |
burst-bar initiator-sequence-ba
)
)|
(burst-ba-rd-bar (BlockAck|Ack)[+HTC]) |
(burst-ba-rd-bar (
burst-ba |
burst-ba-bar initiator-sequence-ba
3303
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
)
);
(* These are sequences that occur within an ht-txop-sequence that have an ack response *)
ht-ack-sequence = (BlockAck+delayed[+HTC] [+mu-user-respond other-users]Ack[+HTC]) |
(BlockAckReq+delayed[+HTC][+mu-user-respond other-users] Ack[+HTC]) |
(Data[+HTC]+individual[+null][+QoS+normal-ack][+mu-user-respond other-
users] Ack[+HTC]);
(* The per-user parts of a VHT MU PPDU that do not require a response *)
other-users = {ppdu-not-requiring-response-per-user +mu-user-not-respond} +mu-ppdu-end;
(* A burst is a sequence of one or more packets, none of them requiring a response *)
burst = 1{ppdu-not-requiring-response};
(* A burst containing a block ack request *)
burst-bar = {ppdu-not-requiring-response} ppdu-bar;
(* A burst containing a BlockAck frame *)
burst-ba = ppdu-ba {ppdu-not-requiring-response};
(* A burst containing a BlockAck frame and block ack request, either in the same packet, or in separate
packets. *)
burst-ba-bar = (ppdu-ba {ppdu-not-requiring-response} ppdu-bar) |
ppdu-ba-bar;
(* A burst delivering an RDG *)
burst-rd = {ppdu-not-requiring-response} ppdu-rd;
(* A burst containing a block ack request and delivering an RDG *)
burst-rd-bar = burst ppdu-rd-bar;
(* A burst containing a BlockAck frame and delivering an RDG *)
burst-ba-rd = (ppdu-ba {ppdu-not-requiring-response} ppdu-rd) |
ppdu-ba-rd;
(* A burst containing a block ack request and BlockAck frame and delivering an RDG *)
burst-ba-rd-bar = (ppdu-ba {ppdu-not-requiring-response} ppdu-rd-bar) |
ppdu-ba-rd-bar;
(* The per-user part of a PPDU not requiring a response is either a single frame not requiring response, or an
A-MPDU of such frames.*)
ppdu-not-requiring-response-per-user =
frame-not-requiring-response-non-ampdu | (* Includes VHT single MPDU *)
1{frame-not-requiring-response-ampdu+a-mpdu}+a-mpdu-end;
(* A PPDU not requiring a response is either a single frame not requiring response, or an A-MPDU of such
frames.*)
ppdu-not-requiring-response =
ppdu-not-requiring-response-per-user [+mu-user-not-respond other-users];
(* A frame-not-requiring-response-non-ampdu is a frame that does not require a response and that may be
sent outside A-MPDU. It includes frames that do not require a response and that are not allowed within an
A-MPDU. *)
3304
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
frame-not-requiring-response-non-ampdu =
Data[+HTC]+QoS+no-ack |
frame-not-requiring-response-ampdu;
(* A frame-not-requiring-response-ampdu is a frame that does not require a response and can be sent within
an A-MPDU. It is one of the delayed BlockAck frames sent with the BAR/BA Ack Policy subfield set to No
Acknowledgment, or Data that does not require an immediate ack, or an Action No Ack frame. A frame-not-
requiring-response may be included with any of the following sequences in any position, except the initial
position when this contains a BlockAck frame or Multi-TID BlockAck frame: ppdu-bar, ppdu-ba-bar, ppdu-
ba, ppdu-rd, ppdu-rd-bar, ppdu-ba-rd-bar, psmp-ppdu *)
frame-not-requiring-response-ampdu =
BlockAck[+HTC]+delayed-no-ack |
BlockAckReq[+HTC]+delayed-no-ack |
Data[+HTC]+QoS+block-ack |
ma-no-ack-htc;
(* A PPDU containing a block ack request is either a non-A-MPDU BlockAckReq frame, or an A-MPDU
containing Data carrying implicit block ack request*).
ppdu-bar= ( (BlockAckReq[+HTC] |
(1{Data[+HTC]+QoS+implicit-bar+a-mpdu} + a-mpdu-end);
) [+mu-user-respond other-users];
(* A PPDU containing both BlockAck frame and block ack request is an A-MPDU that contains a BlockAck
frame, plus either a BlockAckReq frame, or one or more Data frames carrying implicit block ack request. *)
ppdu-ba-bar= ( BlockAck[+HTC]+a-mpdu
(
BlockAckReq[+HTC]+a-mpdu |
1{Data[+HTC]+QoS+implicit-bar+a-mpdu}
) + a-mpdu-end
) [+mu-user-respond other-users];
(*A PPDU containing BlockAck frame is either a non-A-MPDU BlockAck frame, or an A-MPDU
containing a BlockAck frame, and also containing data that does not carry implicit block ack request. *)
ppdu-ba= ( BlockAck[+HTC] |
(
BlockAck[+HTC]+a-mpdu
1{Data[+HTC]+QoS+(no-ack|block-ack)+a-mpdu}
) + a-mpdu-end;
) [+mu-user-respond other-users];
(* A PPDU delivering an RDG, but not delivering a block ack request is either a Data frame, not requiring
immediate acknowledgment, or a BlockAck frame or BlockAckReq frame, not requiring immediate
acknowledgment *).
ppdu-rd= ( Data+HTC[+null]+QoS+(no-ack|block-ack)+RD |
(BlockAck|BlockAckReq)+HTC+delayed-no-ack+RD |
(
1{Data+HTC+QoS+RD+a-mpdu}
) + a-mpdu-end;
) [+mu-user-respond other-users];
(* A PPDU containing a block ack request and delivering an RDG is either an non-A-MPDU BlockAckReq
frame, or an A-MPDU containing at least one Data frame with RD and implicit-bar. *)
ppdu-rd-bar= ( BlockAckReq+HTC+RD |
3305
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(
1{Data+HTC+QoS+implicit-bar+RD+a-mpdu}
) + a-mpdu-end;
) [+mu-user-respond other-users];
(* A PPDU containing a BlockAck frame and granting RD is either an unaggregated BlockAck frame or an
A-MPDU that contains a BlockAck frame and at least one Data frame containing RD, but not implicit block
ack request. *)
ppdu-ba-rd= ( BlockAck+HTC+RD |
(
BlockAck+a-mpdu (
1{Data+HTC+QoS+(no-ack|block-ack)+RD+a-mpdu}
)
) + a-mpdu-end;
) [+mu-user-respond other-users];
(* A PPDU containing a BlockAck frame, block ack request and granting RD is an A-MPDU that contains a
BlockAck frame and either an explicit BlockAckReq frame (and no Data frames) or Data frames carrying
the implicit block ack request. The RD attribute is present in all frames carrying an HT Control field, and at
least one of these frames is present. This constraint is not expressed in the syntax below. *)
ppdu-ba-rd-bar= (
(
BlockAck[+HTC+RD]+a-mpdu
BlockAckReq[+HTC+RD]+a-mpdu
) + a-mpdu-end |
(
BlockAck[+HTC+RD]+a-mpdu
1{ Data[+HTC+RD]+QoS+implicit-bar+a-mpdu}
) + a-mpdu-end;
) [+mu-user-respond other-users];
(* A PSMP burst is a sequence of PSMP sequence ending with a last-psmp-sequence *)
psmp-burst = {non-last-psmp-sequence} last-psmp-sequence;
non-last-psmp-sequence = PSMP+more-psmp+QAP downlink-phase uplink-phase;
last-psmp-sequence = PSMP+no-more-psmp+QAP downlink-phase uplink-phase;
(* The downlink phase is a sequence of allocations to STA as defined in the PSMP frame during which they
may expect to receive. *)
downlink-phase = {psmp-allocated-time};
(* The uplink phase is a sequence of allocations to STA as defined in the PSMP frame during which they are
allowed to transmit *)
uplink-phase = {psmp-allocated-time};
(* During a time allocation, one or more packets may be transmitted of contents defined by psmp-ppdu *)
psmp-allocated-time = 1{psmp-ppdu};
(* The packets that may be transmitted during PSMP are isolated Multi-TID BlockAck or Multi-TID
BlockAckReq frames (under an HT-immediate block ack policy), BlockAck or BlockAckReq frames (under
an HT-delayed or immediate block ack policy), isolated Data frames, or an A-MPDU containing an optional
Multi-TID BlockAck frame and one or more Data frames sent under the PSMP Ack Ack Policy, or an
A-MPDU containing both Multi-TID BlockAck and Multi-TID BlockAckReq frames, but no data. Any
number of Action No Ack frames may be present in either A-MPDU. *)
psmp-ppdu = Multi-TID BlockAck | (*HT-immediate*)
3306
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Multi-TID BlockAckReq | (*HT-immediate*)
BlockAck | (*HT-delayed or immediate*)
BlockAckReq | (*HT-delayed or immediate*)
Data[+HTC]+individual+QoS+psmp-ack |
(
[Multi-TID BlockAck+a-mpdu]
{Management+action-no-ack[+HTC] }
1{Data[+HTC]+individual+QoS+psmp-ack+a-mpdu};
) + a-mpdu-end |
(
Multi-TID BlockAck+a-mpdu
{ Management+action-no-ack[+HTC] }
Multi-TID BlockAckReq+a-mpdu
) + a-mpdu-end;
(* A link adaptation exchange is a frame exchange sequence in which over-the-WM signaling is used to
control or return the results of link measurements so that the initiator device can choose effective values for
its TXVECTOR parameters. *)
link-adaptation-exchange =
mcs-adaptation |
implict-txbf |
explicit-txbf |
vht-bf;
(* An mcs-adaptation exchange includes an MCS measurement request and subsequent MFB. The MRQ
and MFB may be present in any +HTC frame. The exchange can occur either as a fast exchange, in which
the feedback is supplied in a response frame, an exchange in which the response is supplied along with some
other Data frame within the same TXOP, or an exchange in which the response is supplied in a subsequent
TXOP won by the MCS responder. Only the fast response is shown in the syntax that follows. The
sequences shown below are representative examples only and are not exhaustive.*)
mcs-adaptation =
(* RTS/CTS *)
(RTS+HTC+mrq CTS+HTC+mfb) |
(* non-aggregated Data/Ack *)
(Data+HTC+QoS+mrq+normal-ack Ack+HTC+mfb) |
(* non-aggregated BlockAck *)
(BlockAckReq+HTC+mrq (BlockAck+HTC+mfb | Ack+HTC+mfb)) |
(* aggregated data with implicit block ack request and MRQ *)
(
(
1{Data[+HTC]+mrq [+rdg] +QoS+implicit-bar+a-mpdu}
) + a-mpdu-end
(
(* Unaggregated BlockAck frame response *)
BlockAck+HTC +mfb |
(* Aggregated BlockAck frame response *)
(
BlockAck[+HTC+mfb] +a-mpdu
1{Data[+HTC+mfb]+QoS+(no-ack|block-ack)+a-mpdu}
) + a-mpdu-end
3307
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
)
);
(* An implicit-txbf (implicit transmit beamforming) starts with the transmission of a request to sound the
channel. The initiator measures the channel based on the sounding packet and updates its beamforming
feedback matrices based on its observations of the sounding packet. No channel measurements are sent over
the air.*)
implict-txbf =
(RTS+HTC+trq CTS+sounding) |
(Data+HTC+trq+QoS+normal-ack
(Ack+sounding | Ack+HTC+ndp-announce NDP)
)|
(BlockAckReq+HTC+trq
(BlockAck+sounding |
BlockAck+HTC+ndp-announce NDP
)
)|
(BlockAck+HTC+trq+delayed
(Ack+sounding |
Ack+HTC+ndp-announce NDP
)
)
(* The trq/sounding protocol also operates within aggregates. In this case the
TRQ is carried in all +HTC frames (of which there has to be at least one) within
the TRQ initiator’s transmission. The response PPDU either is a sounding PPDU,
or carries at least one +HTC frame with an ndp-announce, in which case the
following PPDU is an NDP sounding PPDU. The following syntax is an
simplified representation of this sequence. *)
([BlockAck+HTC+trq+a-mpdu] {Data+HTC+trq+QoS+a-mpdu}+a-mpdu-
end)
(
([BlockAck+HTC+a-mpdu]
{Data+HTC+QoS+a-mpdu}+a-mpdu-end+sounding)
)|
(
([BlockAck+HTC+ndp-announce+a-mpdu]
{Data+HTC+ndp-announce+QoS+a-mpdu}+a-mpdu-end)
) NDP |
(BlockAck+HTC+sounding) |
(BlockAck+HTC+ndp-announce NDP);
(* During operation of explicit transmit beamforming (explicit-txbf), there are three encodings of feedback
information. These are not distinguished here and are all identified by the csi attribute. The feedback
position may be immediate, aggregate, or delayed. Immediate feedback follows a SIFS after the sounding
PPDU (identified by the sounding attribute) or the NDP. Aggregate feedback occurs during an aggregate
within the same TXOP and may accompany Data frames in the same PPDU. Delayed feedback occurs
during a subsequent TXOP during which the CSI responder is TXOP initiator. Only immediate feedback is
described in the syntax below. The frame indicating any csi-request is carried in a sounding PPDU or
followed by an NDP. The CSI response is carried in an Action No Ack frame, which may be aggregated
with a response that is a BlockAck or Ack frame.
There are also two sets of sequences “staggered” and “NDP” that use either staggered sounding, or NDP
sounding respectively.*)
explicit-txbf = explicit-txbf-staggered | explicit-txbf-NDP;
3308
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
(* Staggered sounding. In this case, the sounding request is present in a frame that also generates an
immediate response. The response is aggregated with the feedback in an A-MPDU. *)
explicit-txbf-staggered =
(
Data+HTC+csi-request+QoS+normal-ack+sounding
(Ack+a-mpdu
Management+action-no-ack +csi+a-mpdu-end)
)|
(
BlockAckReq+HTC+csi-request+sounding
(BlockAck+a-mpdu
Management+action-no-ack +csi+a-mpdu-end)
)|
(
BlockAckReq+HTC+csi-request+delayed+sounding
(Ack+a-mpdu
Management+action-no-ack+csi+a-mpdu-end)
);
(* NDP sounding. In this case, the HT NDP announcement is present in a frame that also generates an
immediate response. The beamformer transmits an NDP once the immediate response is received, and the
beamformee transmits immediate feedback once it receives the NDP. *)
explicit-txbf-NDP =
(
RTS+HTC+csi-request+ndp-announce
CTS
NDP
Management+action-no-ack +csi
)|
(
Data+HTC+csi-request+QoS+normal-ack+ndp-announce
Ack
NDP
Management+action-no-ack +csi
)|
(
BlockAckReq+HTC+csi-request+ndp-announce
BlockAck
NDP
Management+action-no-ack +csi
)|
(
BlockAckReq+HTC+csi-request+delayed+ndp-announce
Ack
NDP
Management+action-no-ack +csi
);
(* The VHT beamforming sequence starts with a VHT NDP Announcement frame, followed by a VHT
NDP. One of the STAs in the sequence responds immediately with explicit feedback. The VHT AP might
poll the other STAs to obtain their feedback before generating an MU transmission. The names of the frames
include spaces, so they are delimited using parentheses. *)
vht-bf =
(VHT NDP Announcement) (VHT NDP) vht-feedback
3309
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
{(Beamforming Report Poll) vht-feedback};
(* VHT feedback is provided using VHT Compressed Beamforming frames. Multiple frames may be
needed to provide feedback. *)
vht-feedback =
(VHT Compressed Beamforming frame) | (* VHT single MPDU or non-VHT
PPDU *)
1{(VHT Compressed Beamforming frame) +a-mpdu} +a-mpdu-end;
3310
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex H
(normative)
Usage of Ethertype 89-0d
The Ethertype 89-0d frame body is specified in Figure H-1, omitting any possible security header and trailer.
LLC SNAP Payload Type Payload
Octets: 3 5 1 variable
Figure H-1—Ethertype 89-0d frame body
LLC is defined in ISO/IEC 8802-2:1998.
SNAP is defined in IEEE Std 802-2014. The formatting of the SNAP header is according to IETF RFC
1042. The Ethertype is set to 89-0d.
The Payload Type field is set to one of the values in Table H-1.
Table H-1—Payload Type field values
Protocol name Payload type Subclause
Remote Request/Response 1 13.10.3
TDLS 2 11.23.2
FST 3 11.33.5
RLQP 4 11.25.3.4
Reserved 5–255
The Payload depends on the value inside the Payload Type field and is defined in the subclauses listed in
Table H-1.
3311
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex I
(informative)
Examples of encoding a frame for OFDM PHYs and DMG PHYs
I.1 Example 1 - BCC encoding
I.1.1 Introduction
The purpose of this annex is to show an example of encoding a frame for the OFDM PHY, as described in
Clause 17. This example covers all of the encoding details defined by this standard.
The encoding illustration goes through the following stages:
a) Generating the short training sequence section of the preamble;
b) Generating the long preamble sequence section of the preamble;
c) Generating the SIGNAL field bits;
d) Coding and interleaving the SIGNAL field bits;
e) Mapping the SIGNAL field into frequency domain;
f) Pilot insertion;
g) Transforming into time domain;
h) Delineating the data octet stream into a bit stream;
i) Prepending the SERVICE field and adding the pad bits, thus forming the DATA;
j) Scrambling and zeroing the tail bits;
k) Encoding the DATA with a convolutional encoder and puncturing;
l) Mapping into complex 16-QAM symbols;
m) Pilot insertion;
n) Transforming from frequency to time and adding a circular prefix;
o) Concatenating the OFDM symbols into a single, time-domain signal.
In the description of time domain waveforms, a complex baseband signal at 20 Msample/s shall be used.
This example uses the 36 Mb/s data rate and a message of 100 octets. These parameters are chosen in order
to illustrate as many nontrivial aspects of the processing as possible:
— Use of several bits per symbol (4 in this case);
— Puncturing of the convolutional code;
— Interleaving, which uses the LSB–MSB swapping stage;
— Scrambling of the pilot subcarriers.
In each Annex I table that has “Binary value” columns, the bit positions of the binary values are specified in
the header of the table.
3312
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.1.2 The message for the BCC example
The message being encoded consists of the first 72 characters (shown in bold and including line breaks) of
the well-known “Ode to Joy” by F. Schiller:
Joy, bright spark of divinity,
Daughter of Elysium,
Fire-insired we tread
Thy sanctuary.
Thy magic power re-unites
All that custom has divided,
All men become brothers
Under the sway of thy gentle wings.
The message is converted to ASCII; then it is prepended with an appropriate MAC header and an FCS is
added. The resulting 100 octet PSDU is shown in Table I-1.
Table I-1—The message for the BCC example
Octet ## Val Val Val Val Val
1...5 0x04 0x02 0x00 0x2E 0x00
6...10 0x60 0x08 0xCD 0x37 0xA6
11...15 0x00 0x20 0xD6 0x01 0x3C
16...20 0xF1 0x00 0x60 0x08 0xAD
21...25 0x3B 0xAF 0x00 0x00 0x4A
26...30 0x6F 0x79 0x2C 0x20 0x62
31...35 0x72 0x69 0x67 0x68 0x74
36...40 0x20 0x73 0x70 0x61 0x72
41...45 0x6B 0x20 0x6F 0x66 0x20
46...50 0x64 0x69 0x76 0x69 0x6E
51...55 0x69 0x74 0x79 0x2C 0x0A
56...60 0x44 0x61 0x75 0x67 0x68
61...65 0x74 0x65 0x72 0x20 0x6F
66...70 0x66 0x20 0x45 0x6C 0x79
71...75 0x73 0x69 0x75 0x6D 0x2C
76...80 0x0A 0x46 0x69 0x72 0x65
81...85 0x2D 0x69 0x6E 0x73 0x69
86...90 0x72 0x65 0x64 0x20 0x77
91...95 0x65 0x20 0x74 0x72 0x65
96...100 0x61 0x67 0x33 0x21 0xB6
3313
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.1.3 Generation of the preamble
I.1.3.1 Generation of the short sequences
The short sequences section of the preamble is described by its frequency domain representation, given in
Table I-2.
Table I-2—Frequency domain representation of the short sequences
## Re Im ## Re Im ## Re Im ## Re Im
–32 0.0 0.0 –16 1.472 1.472 0 0.0 0.0 16 1.472 1.472
–31 0.0 0.0 –15 0.0 0.0 1 0.0 0.0 17 0.0 0.0
–30 0.0 0.0 –14 0.0 0.0 2 0.0 0.0 18 0.0 0.0
–29 0.0 0.0 –13 0.0 0.0 3 0.0 0.0 19 0.0 0.0
–28 0.0 0.0 –12 –1.472 –1.472 4 –1.472 –1.472 20 1.472 1.472
–27 0.0 0.0 –11 0.0 0.0 5 0.0 0.0 21 0.0 0.0
–26 0.0 0.0 –10 0.0 0.0 6 0.0 0.0 22 0.0 0.0
–25 0.0 0.0 –9 0.0 0.0 7 0.0 0.0 23 0.0 0.0
–24 1.472 1.472 –8 –1.472 –1.472 8 –1.472 –1.472 24 1.472 1.472
–23 0.0 0.0 –7 0.0 0.0 9 0.0 0.0 25 0.0 0.0
–22 0.0 0.0 –6 0.0 0.0 10 0.0 0.0 26 0.0 0.0
–21 0.0 0.0 –5 0.0 0.0 11 0.0 0.0 27 0.0 0.0
–20 –1.472 –1.472 –4 1.472 1.472 12 1.472 1.472 28 0.0 0.0
–19 0.0 0.0 –3 0.0 0.0 13 0.0 0.0 29 0.0 0.0
–18 0.0 0.0 –2 0.0 0.0 14 0.0 0.0 30 0.0 0.0
–17 0.0 0.0 –1 0.0 0.0 15 0.0 0.0 31 0.0 0.0
One period of the IFFT on the contents of Table I-2 is given in Table I-3.
Table I-3—One period of IFFT of the short sequences
## Re Im ## Re Im ## Re Im ## Re Im
0 0.046 0.046 1 –0.132 0.002 2 –0.013 –0.079 3 0.143 –0.013
4 0.092 0.000 5 0.143 –0.013 6 –0.013 –0.079 7 –0.132 0.002
8 0.046 0.046 9 0.002 –0.132 10 –0.079 –0.013 11 –0.013 0.143
12 0.000 0.092 13 –0.013 0.143 14 –0.079 –0.013 15 0.002 –0.132
16 0.046 0.046 17 –0.132 0.002 18 –0.013 –0.079 19 0.143 –0.013
20 0.092 0.000 21 0.143 –0.013 22 –0.013 –0.079 23 –0.132 0.002
3314
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-3—One period of IFFT of the short sequences (continued)
## Re Im ## Re Im ## Re Im ## Re Im
24 0.046 0.046 25 0.002 –0.132 26 –0.079 –0.013 27 –0.013 0.143
28 0.000 0.092 29 –0.013 0.143 30 –0.079 –0.013 31 0.002 –0.132
32 0.046 0.046 33 –0.132 0.002 34 –0.013 –0.079 35 0.143 –0.013
36 0.092 0.000 37 0.143 –0.013 38 –0.013 –0.079 39 –0.132 0.002
40 0.046 0.046 41 0.002 –0.132 42 –0.079 –0.013 43 –0.013 0.143
44 0.000 0.092 45 –0.013 0.143 46 –0.079 –0.013 47 0.002 –0.132
48 0.046 0.046 49 –0.132 0.002 50 –0.013 –0.079 51 0.143 –0.013
52 0.092 0.000 53 0.143 –0.013 54 –0.013 –0.079 55 –0.132 0.002
56 0.046 0.046 57 0.002 –0.132 58 –0.079 –0.013 59 –0.013 0.143
60 0.000 0.092 61 –0.013 0.143 62 –0.079 –0.013 63 0.002 –0.132
The single period of the short training sequence is extended periodically for 161 samples (about 8 s), and
then multiplied by the window function:
0.5 k=0
W k = 1 1 k 159
0.5 k = 160
The last sample serves as an overlap with the following OFDM symbol. The 161 samples vector is shown in
Table I-4. The time-windowing feature illustrated here is not part of the normative specifications.
Table I-4—Time domain representation of the short sequence
## Re Im ## Re Im ## Re Im ## Re Im
0 0.023 0.023 1 –0.132 0.002 2 –0.013 –0.079 3 0.143 –0.013
4 0.092 0.000 5 0.143 –0.013 6 –0.013 –0.079 7 –0.132 0.002
8 0.046 0.046 9 0.002 –0.132 10 –0.079 –0.013 11 –0.013 0.143
12 0.000 0.092 13 –0.013 0.143 14 –0.079 –0.013 15 0.002 –0.132
16 0.046 0.046 17 –0.132 0.002 18 –0.013 –0.079 19 0.143 –0.013
20 0.092 0.000 21 0.143 –0.013 22 –0.013 –0.079 23 –0.132 0.002
24 0.046 0.046 25 0.002 –0.132 26 –0.079 –0.013 27 –0.013 0.143
28 0.000 0.092 29 –0.013 0.143 30 –0.079 –0.013 31 0.002 –0.132
32 0.046 0.046 33 –0.132 0.002 34 –0.013 –0.079 35 0.143 –0.013
36 0.092 0.000 37 0.143 –0.013 38 –0.013 –0.079 39 –0.132 0.002
40 0.046 0.046 41 0.002 –0.132 42 –0.079 –0.013 43 –0.013 0.143
3315
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-4—Time domain representation of the short sequence (continued)
## Re Im ## Re Im ## Re Im ## Re Im
44 0.000 0.092 45 –0.013 0.143 46 –0.079 –0.013 47 0.002 –0.132
48 0.046 0.046 49 –0.132 0.002 50 –0.013 –0.079 51 0.143 –0.013
52 0.092 0.000 53 0.143 –0.013 54 –0.013 –0.079 55 –0.132 0.002
56 0.046 0.046 57 0.002 –0.132 58 –0.079 –0.013 59 –0.013 0.143
60 0.000 0.092 61 –0.013 0.143 62 –0.079 –0.013 63 0.002 –0.132
64 0.046 0.046 65 –0.132 0.002 66 –0.013 –0.079 67 0.143 –0.013
68 0.092 0.000 69 0.143 –0.013 70 –0.013 –0.079 71 –0.132 0.002
72 0.046 0.046 73 0.002 –0.132 74 –0.079 –0.013 75 –0.013 0.143
76 0.000 0.092 77 –0.013 0.143 78 –0.079 –0.013 79 0.002 –0.132
80 0.046 0.046 81 –0.132 0.002 82 –0.013 –0.079 83 0.143 –0.013
84 0.092 0.000 85 0.143 –0.013 86 –0.013 –0.079 87 –0.132 0.002
88 0.046 0.046 89 0.002 –0.132 90 –0.079 –0.013 91 –0.013 0.143
92 0.000 0.092 93 –0.013 0.143 94 –0.079 –0.013 95 0.002 –0.132
96 0.046 0.046 97 –0.132 0.002 98 –0.013 –0.079 99 0.143 –0.013
100 0.092 0.000 101 0.143 –0.013 102 –0.013 –0.079 103 –0.132 0.002
104 0.046 0.046 105 0.002 –0.132 106 –0.079 –0.013 107 –0.013 0.143
108 0.000 0.092 109 –0.013 0.143 110 –0.079 –0.013 111 0.002 –0.132
112 0.046 0.046 113 –0.132 0.002 114 –0.013 –0.079 115 0.143 –0.013
116 0.092 0.000 117 0.143 –0.013 118 –0.013 –0.079 119 –0.132 0.002
120 0.046 0.046 121 0.002 –0.132 122 –0.079 –0.013 123 –0.013 0.143
124 0.000 0.092 125 –0.013 0.143 126 –0.079 –0.013 127 0.002 –0.132
128 0.046 0.046 129 –0.132 0.002 130 –0.013 –0.079 131 0.143 –0.013
132 0.092 0.000 133 0.143 –0.013 134 –0.013 –0.079 135 –0.132 0.002
136 0.046 0.046 137 0.002 –0.132 138 –0.079 –0.013 139 –0.013 0.143
140 0.000 0.092 141 –0.013 0.143 142 –0.079 –0.013 143 0.002 –0.132
144 0.046 0.046 145 –0.132 0.002 146 –0.013 –0.079 147 0.143 –0.013
148 0.092 0.000 149 0.143 –0.013 150 –0.013 –0.079 151 –0.132 0.002
152 0.046 0.046 153 0.002 –0.132 154 –0.079 –0.013 155 –0.013 0.143
156 0.000 0.092 157 –0.013 0.143 158 –0.079 –0.013 159 0.002 –0.132
160 0.023 0.023
3316
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.1.3.2 Generation of the long sequences
The frequency domain representation of the long training sequence part of the preamble is given in
Table I-5.
Table I-5—Frequency domain representation of the long sequences
## Re Im ## Re Im ## Re Im ## Re Im
–32 0.000 0.000 –16 1.000 0.000 0 0.000 0.000 16 1.000 0.000
–31 0.000 0.000 –15 1.000 0.000 1 1.000 0.000 17 –1.000 0.000
–30 0.000 0.000 –14 1.000 0.000 2 –1.000 0.000 18 –1.000 0.000
–29 0.000 0.000 –13 1.000 0.000 3 –1.000 0.000 19 1.000 0.000
–28 0.000 0.000 –12 1.000 0.000 4 1.000 0.000 20 –1.000 0.000
–27 0.000 0.000 –11 –1.000 0.000 5 1.000 0.000 21 1.000 0.000
–26 1.000 0.000 –10 –1.000 0.000 6 –1.000 0.000 22 –1.000 0.000
–25 1.000 0.000 –9 1.000 0.000 7 1.000 0.000 23 1.000 0.000
–24 –1.000 0.000 –8 1.000 0.000 8 –1.000 0.000 24 1.000 0.000
–23 –1.000 0.000 –7 –1.000 0.000 9 1.000 0.000 25 1.000 0.000
–22 1.000 0.000 –6 1.000 0.000 10 –1.000 0.000 26 1.000 0.000
–21 1.000 0.000 –5 –1.000 0.000 11 –1.000 0.000 27 0.000 0.000
–20 –1.000 0.000 –4 1.000 0.000 12 –1.000 0.000 28 0.000 0.000
–19 1.000 0.000 –3 1.000 0.000 13 –1.000 0.000 29 0.000 0.000
–18 –1.000 0.000 –2 1.000 0.000 14 –1.000 0.000 30 0.000 0.000
–17 1.000 0.000 –1 1.000 0.000 15 1.000 0.000 31 0.000 0.000
The time domain representation is derived by performing IFFT on the contents of Table I-5, cyclically
extending the result to get the cyclic prefix, and then multiplying with the window function given in I.1.3.1.
The resulting 161 points vector is shown in Table I-6. The samples are appended to the short sequence
section by overlapping and adding element 160 of Table I-4 to element 0 of Table I-6.
Table I-6—Time domain representation of the long sequence
## Re Im ## Re Im ## Re Im ## Re Im
0 –0.078 0.000 1 0.012 –0.098 2 0.092 –0.106 3 –0.092 –0.115
4 –0.003 –0.054 5 0.075 0.074 6 –0.127 0.021 7 –0.122 0.017
8 –0.035 0.151 9 –0.056 0.022 10 –0.060 –0.081 11 0.070 –0.014
12 0.082 –0.092 13 –0.131 –0.065 14 –0.057 –0.039 15 0.037 –0.098
16 0.062 0.062 17 0.119 0.004 18 –0.022 –0.161 19 0.059 0.015
3317
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-6—Time domain representation of the long sequence (continued)
## Re Im ## Re Im ## Re Im ## Re Im
20 0.024 0.059 21 –0.137 0.047 22 0.001 0.115 23 0.053 –0.004
24 0.098 0.026 25 –0.038 0.106 26 –0.115 0.055 27 0.060 0.088
28 0.021 –0.028 29 0.097 –0.083 30 0.040 0.111 31 –0.005 0.120
32 0.156 0.000 33 –0.005 –0.120 34 0.040 –0.111 35 0.097 0.083
36 0.021 0.028 37 0.060 –0.088 38 –0.115 –0.055 39 –0.038 –0.106
40 0.098 –0.026 41 0.053 0.004 42 0.001 –0.115 43 –0.137 –0.047
44 0.024 –0.059 45 0.059 –0.015 46 –0.022 0.161 47 0.119 –0.004
48 0.062 –0.062 49 0.037 0.098 50 –0.057 0.039 51 –0.131 0.065
52 0.082 0.092 53 0.070 0.014 54 –0.060 0.081 55 –0.056 –0.022
56 –0.035 –0.151 57 –0.122 –0.017 58 –0.127 –0.021 59 0.075 –0.074
60 –0.003 0.054 61 –0.092 0.115 62 0.092 0.106 63 0.012 0.098
64 –0.156 0.000 65 0.012 –0.098 66 0.092 –0.106 67 –0.092 –0.115
68 –0.003 –0.054 69 0.075 0.074 70 –0.127 0.021 71 –0.122 0.017
72 –0.035 0.151 73 –0.056 0.022 74 –0.060 –0.081 75 0.070 –0.014
76 0.082 –0.092 77 –0.131 –0.065 78 –0.057 –0.039 79 0.037 –0.098
80 0.062 0.062 81 0.119 0.004 82 –0.022 –0.161 83 0.059 0.015
84 0.024 0.059 85 –0.137 0.047 86 0.001 0.115 87 0.053 –0.004
88 0.098 0.026 89 –0.038 0.106 90 –0.115 0.055 91 0.060 0.088
92 0.021 –0.028 93 0.097 –0.083 94 0.040 0.111 95 –0.005 0.120
96 0.156 0.000 97 –0.005 –0.120 98 0.040 –0.111 99 0.097 0.083
100 0.021 0.028 101 0.060 –0.088 102 –0.115 –0.055 103 –0.038 –0.106
104 0.098 –0.026 105 0.053 0.004 106 0.001 –0.115 107 –0.137 –0.047
108 0.024 –0.059 109 0.059 –0.015 110 –0.022 0.161 111 0.119 –0.004
112 0.062 –0.062 113 0.037 0.098 114 –0.057 0.039 115 –0.131 0.065
116 0.082 0.092 117 0.070 0.014 118 –0.060 0.081 119 –0.056 –0.022
120 –0.035 –0.151 121 –0.122 –0.017 122 –0.127 –0.021 123 0.075 –0.074
124 –0.003 0.054 125 –0.092 0.115 126 0.092 0.106 127 0.012 0.098
128 –0.156 0.000 129 0.012 –0.098 130 0.092 –0.106 131 –0.092 –0.115
132 –0.003 –0.054 133 0.075 0.074 134 –0.127 0.021 135 –0.122 0.017
136 –0.035 0.151 137 –0.056 0.022 138 –0.060 –0.081 139 0.070 –0.014
140 0.082 –0.092 141 –0.131 –0.065 142 –0.057 –0.039 143 0.037 –0.098
144 0.062 0.062 145 0.119 0.004 146 –0.022 –0.161 147 0.059 0.015
3318
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-6—Time domain representation of the long sequence (continued)
## Re Im ## Re Im ## Re Im ## Re Im
148 0.024 0.059 149 –0.137 0.047 150 0.001 0.115 151 0.053 –0.004
152 0.098 0.026 153 –0.038 0.106 154 –0.115 0.055 155 0.060 0.088
156 0.021 –0.028 157 0.097 –0.083 158 0.040 0.111 159 –0.005 0.120
160 0.078 0
I.1.4 Generation of the SIGNAL field
I.1.4.1 SIGNAL field bit assignment
The SIGNAL field bit assignment follows 17.3.4 and Figure 17-5. The transmitted bits are shown in Table I-
7, where bit 0 is transmitted first.
Table I-7—Bit assignment for SIGNAL field
## Bit Meaning ## Bit Meaning
0 1 RATE: R1 12 0 —
1 0 RATE: R2 13 0 —
2 1 RATE: R3 14 0 —
3 1 RATE: R4 15 0 —
4 0 Reserved 16 0 LENGTH (MSB)
5 0 LENGTH (LSB) 17 0 Parity
6 0 — 18 0 SIGNAL TAIL
7 1 — 19 0 SIGNAL TAIL
8 0 — 20 0 SIGNAL TAIL
9 0 — 21 0 SIGNAL TAIL
10 1 — 22 0 SIGNAL TAIL
11 1 — 23 0 SIGNAL TAIL
3319
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.1.4.2 Coding the SIGNAL field bits
The bits are encoded by the rate 1/2 convolutional encoder to yield the 48 bits given in Table I-8.
Table I-8—SIGNAL field bits after encoding
## Bit ## Bit ## Bit ## Bit ## Bit ## Bit
0 1 8 1 16 0 24 0 32 0 40 0
1 1 9 0 17 0 25 0 33 1 41 0
2 0 10 1 18 0 26 1 34 1 42 0
3 1 11 0 19 0 27 1 35 1 43 0
4 0 12 0 20 0 28 1 36 0 44 0
5 0 13 0 21 0 29 1 37 0 45 0
6 0 14 0 22 1 30 1 38 0 46 0
7 1 15 1 23 0 31 0 39 0 47 0
I.1.4.3 Interleaving the SIGNAL field bits
The encoded bits are interleaved according to the interleaver of 17.3.5.7. A detailed breakdown of the
interleaving operation is described in I.1.6.2. The interleaved SIGNAL field bits are shown in Table I-9.
Table I-9—SIGNAL field bits after interleaving
## Bit ## Bit ## Bit ## Bit ## Bit ## Bit
0 1 8 1 16 0 24 1 32 0 40 1
1 0 9 1 17 0 25 0 33 0 41 0
2 0 10 0 18 0 26 0 34 1 42 0
3 1 11 1 19 1 27 0 35 0 43 1
4 0 12 0 20 0 28 0 36 0 44 0
5 1 13 0 21 1 29 0 37 1 45 1
6 0 14 0 22 0 30 1 38 0 46 0
7 0 15 0 23 0 31 1 39 0 47 0
I.1.4.4 SIGNAL field frequency domain
The encoded and interleaved bits are BPSK modulated to yield the frequency domain representation given in
Table I-10. Locations –21, –7, 7, and 21 are skipped and are used for pilot insertion.
3320
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-10—Frequency domain representation of SIGNAL field
## Re Im ## Re Im ## Re Im ## Re Im
–32 0.000 0.000 –16 1.000 0.000 0 0.000 0.000 16 –1.000 0.000
–31 0.000 0.000 –15 –1.000 0.000 1 1.000 0.000 17 –1.000 0.000
–30 0.000 0.000 –14 1.000 0.000 2 –1.000 0.000 18 1.000 0.000
–29 0.000 0.000 –13 –1.000 0.000 3 –1.000 0.000 19 –1.000 0.000
–28 0.000 0.000 –12 –1.000 0.000 4 –1.000 0.000 20 –1.000 0.000
–27 0.000 0.000 –11 –1.000 0.000 5 –1.000 0.000 21 X X
–26 1.000 0.000 –10 –1.000 0.000 6 –1.000 0.000 22 1.000 0.000
–25 –1.000 0.000 –9 –1.000 0.000 7 X X 23 –1.000 0.000
–24 –1.000 0.000 –8 –1.000 0.000 8 1.000 0.000 24 1.000 0.000
–23 1.000 0.000 –7 X X 9 1.000 0.000 25 –1.000 0.000
–22 –1.000 0.000 –6 –1.000 0.000 10 –1.000 0.000 26 –1.000 0.000
–21 X X –5 1.000 0.000 11 –1.000 0.000 27 0.000 0.000
–20 1.000 0.000 –4 –1.000 0.000 12 1.000 0.000 28 0.000 0.000
–19 –1.000 0.000 –3 1.000 0.000 13 –1.000 0.000 29 0.000 0.000
–18 –1.000 0.000 –2 –1.000 0.000 14 –1.000 0.000 30 0.000 0.000
–17 1.000 0.000 –1 –1.000 0.000 15 1.000 0.000 31 0.000 0.000
Four pilot subcarriers are added by taking the values {1.0,1.0,1.0,–1.0}, multiplying them by the
first element of sequence p0…126, given in Equation (17-22) (in 17.3.5.10), and inserting them into
location {–21, –7,7,21}, respectively. The resulting frequency domain values are given in Table I-11.
Table I-11—Frequency domain representation of SIGNAL field
with pilots inserted
## Re Im ## Re Im ## Re Im ## Re Im
–32 0.000 0.000 –16 1.000 0.000 0 0.000 0.000 16 –1.000 0.000
–31 0.000 0.000 –15 –1.000 0.000 1 1.000 0.000 17 –1.000 0.000
–30 0.000 0.000 –14 1.000 0.000 2 –1.000 0.000 18 1.000 0.000
–29 0.000 0.000 –13 –1.000 0.000 3 –1.000 0.000 19 –1.000 0.000
–28 0.000 0.000 –12 –1.000 0.000 4 –1.000 0.000 20 –1.000 0.000
–27 0.000 0.000 –11 –1.000 0.000 5 –1.000 0.000 21 –1.000 0.000
–26 1.000 0.000 –10 –1.000 0.000 6 –1.000 0.000 22 1.000 0.000
–25 –1.000 0.000 –9 –1.000 0.000 7 1.000 0.000 23 –1.000 0.000
–24 –1.000 0.000 –8 –1.000 0.000 8 1.000 0.000 24 1.000 0.000
3321
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-11—Frequency domain representation of SIGNAL field
with pilots inserted (continued)
## Re Im ## Re Im ## Re Im ## Re Im
–23 1.000 0.000 –7 1.000 0.000 9 1.000 0.000 25 –1.000 0.000
–22 –1.000 0.000 –6 –1.000 0.000 10 –1.000 0.000 26 –1.000 0.000
–21 1.000 0.000 –5 1.000 0.000 11 –1.000 0.000 27 0.000 0.000
–20 1.000 0.000 –4 –1.000 0.000 12 1.000 0.000 28 0.000 0.000
–19 –1.000 0.000 –3 1.000 0.000 13 –1.000 0.000 29 0.000 0.000
–18 –1.000 0.000 –2 –1.000 0.000 14 –1.000 0.000 30 0.000 0.000
–17 1.000 0.000 –1 –1.000 0.000 15 1.000 0.000 31 0.000 0.000
I.1.4.5 SIGNAL field time domain
The time domain representation is derived by performing IFFT on the contents of Table I-11, extending
cyclically, and multiplying by the window function
0.5 k=0
W k = 1 1 k 79
0.5 k = 80
The resulting 81 samples vector is shown in Table I-12. Note that the time-windowing feature illustrated
here is not a part of the normative specifications.
Table I-12—Time domain representation of SIGNAL field
## Re Im ## Re Im ## Re Im ## Re Im
0 0.031 0.000 1 0.033 –0.044 2 –0.002 –0.038 3 –0.081 0.084
4 0.007 –0.100 5 –0.001 –0.113 6 –0.021 –0.005 7 0.136 –0.105
8 0.098 –0.044 9 0.011 –0.002 10 –0.033 0.044 11 –0.060 0.124
12 0.010 0.097 13 0.000 –0.008 14 0.018 –0.083 15 –0.069 0.027
16 –0.219 0.000 17 –0.069 –0.027 18 0.018 0.083 19 0.000 0.008
20 0.010 –0.097 21 –0.060 –0.124 22 –0.033 –0.044 23 0.011 0.002
24 0.098 0.044 25 0.136 0.105 26 –0.021 0.005 27 –0.001 0.113
28 0.007 0.100 29 –0.081 –0.084 30 –0.002 0.038 31 0.033 0.044
32 0.062 0.000 33 0.057 0.052 34 0.016 0.174 35 0.035 0.116
36 –0.051 –0.202 37 0.011 0.036 38 0.089 0.209 39 –0.049 –0.008
40 –0.035 0.044 41 0.017 –0.059 42 0.053 –0.017 43 0.099 0.100
44 0.034 –0.148 45 –0.003 –0.094 46 –0.120 0.042 47 –0.136 –0.070
3322
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-12—Time domain representation of SIGNAL field (continued)
## Re Im ## Re Im ## Re Im ## Re Im
48 –0.031 0.000 49 –0.136 0.070 50 –0.120 –0.042 51 –0.003 0.094
52 0.034 0.148 53 0.099 –0.100 54 0.053 0.017 55 0.017 0.059
56 –0.035 –0.044 57 –0.049 0.008 58 0.089 –0.209 59 0.011 –0.036
60 –0.051 0.202 61 0.035 –0.116 62 0.016 –0.174 63 0.057 –0.052
64 0.062 0.000 65 0.033 –0.044 66 –0.002 –0.038 67 –0.081 0.084
68 0.007 –0.100 69 –0.001 –0.113 70 –0.021 –0.005 71 0.136 –0.105
72 0.098 –0.044 73 0.011 –0.002 74 –0.033 0.044 75 –0.060 0.124
76 0.010 0.097 77 0.000 –0.008 78 0.018 –0.083 79 –0.069 0.027
80 –0.109 0.000
The SIGNAL field samples are appended with one sample overlap to the preamble, given in Table I-6.
I.1.5 Generating the DATA bits for the BCC example
I.1.5.1 Delineating, SERVICE field prepending, and zero padding
The transmitted message shown in Table I-1 contains 100 octets or, equivalently, 800 bits. The bits are
prepended by the 16 SERVICE field bits and are appended by 6 tail bits. The resulting 822 bits are appended
by some number of bits with value 0 to yield an integer number of OFDM symbols. For the 36 Mb/s mode,
there are 144 data bits per OFDM symbol; the overall number of bits is 822 144 144 = 864. Hence,
864 – 822 = 42 zero bits are appended.
The DATA bits are shown in Table I-13.
Table I-13—The DATA bits before scrambling
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B7 B0 B15 B8 B23 B16 value value value
000-023 00000000 00000000 00000100 0x00 0x00 0x04
024-047 00000010 00000000 00101110 0x02 0x00 0x2E
048-071 00000000 01100000 00001000 0x00 0x60 0x08
072-095 11001101 00110111 10100110 0xCD 0x37 0xA6
096-119 00000000 00100000 11010110 0x00 0x20 0xD6
120-143 00000001 00111100 11110001 0x01 0x3C 0xF1
144-167 00000000 01100000 00001000 0x00 0x60 0x08
168-191 10101101 00111011 10101111 0xAD 0x3B 0xAF
192-215 00000000 00000000 01001010 0x00 0x00 0x4A
3323
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-13—The DATA bits before scrambling (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B7 B0 B15 B8 B23 B16 value value value
216-239 01101111 01111001 00101100 0x6F 0x79 0x2C
240-263 00100000 01100010 01110010 0x20 0x62 0x72
264-287 01101001 01100111 01101000 0x69 0x67 0x68
288-311 01110100 00100000 01110011 0x74 0x20 0x73
312-335 01110000 01100001 01110010 0x70 0x61 0x72
336-359 01101011 00100000 01101111 0x6B 0x20 0x6F
360-383 01100110 00100000 01100100 0x66 0x20 0x64
384-407 01101001 01110110 01101001 0x69 0x76 0x69
408-431 01101110 01101001 01110100 0x6E 0x69 0x74
432-455 01111001 00101100 00001010 0x79 0x2C 0x0A
456-479 01000100 01100001 01110101 0x44 0x61 0x75
480-503 01100111 01101000 01110100 0x67 0x68 0x74
504-527 01100101 01110010 00100000 0x65 0x72 0x20
528-551 01101111 01100110 00100000 0x6F 0x66 0x20
552-575 01000101 01101100 01111001 0x45 0x6C 0x79
576-599 01110011 01101001 01110101 0x73 0x69 0x75
600-623 01101101 00101100 00001010 0x6D 0x2C 0x0A
624-647 01000110 01101001 01110010 0x46 0x69 0x72
648-671 01100101 00101101 01101001 0x65 0x2D 0x69
672-695 01101110 01110011 01101001 0x6E 0x73 0x69
696-719 01110010 01100101 01100100 0x72 0x65 0x64
720-743 00100000 01110111 01100101 0x20 0x77 0x65
744-767 00100000 01110100 01110010 0x20 0x74 0x72
768-791 01100101 01100001 01100111 0x65 0x61 0x67
792-815 00110011 00100001 10110110 0x33 0x21 0xB6
816-839 00000000 00000000 00000000 0x00 0x00 0x00
840-863 00000000 00000000 00000000 0x00 0x00 0x00
3324
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.1.5.2 Scrambling the BCC example
The 864 bits are scrambled by the scrambler defined in 17.3.5.5. The initial state of the scrambler is the state
1011101. The generated scrambling sequence is given in Table I-14.
Table I-14—Scrambling sequence for seed 1011101
## Bit ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit
0 0 16 1 32 0 48 1 64 0 80 0 96 0 112 1
1 1 17 0 33 1 49 1 65 1 81 0 97 0 113 0
2 1 18 1 34 1 50 1 66 1 82 1 98 1 114 0
3 0 19 0 35 0 51 1 67 1 83 1 99 0 115 1
4 1 20 1 36 1 52 0 68 0 84 1 100 0 116 1
5 1 21 0 37 0 53 1 69 0 85 0 101 1 117 0
6 0 22 0 38 0 54 0 70 0 86 1 102 0 118 0
7 0 23 1 39 0 55 0 71 1 87 1 103 0 119 0
8 0 24 1 40 0 56 1 72 1 88 1 104 0 120 1
9 0 25 1 41 1 57 0 73 1 89 1 105 0 121 0
10 0 26 0 42 0 58 1 74 1 90 0 106 0 122 1
11 1 27 0 43 1 59 0 75 1 91 0 107 0 123 1
12 1 28 1 44 0 60 0 76 1 92 1 108 1 124 1
13 0 29 1 45 1 61 0 77 1 93 0 109 0 125 0
14 0 30 1 46 0 62 1 78 0 94 1 110 0 126 1
15 1 31 1 47 1 63 1 79 0 95 1 111 0
After scrambling, the 6 bits in location 816 (i.e., bit 817) to 821 (i.e., bit 822) are set to 0. The scrambled
DATA bits are shown in Table I-15.
Table I-15—The DATA bits after scrambling
Binary Binary Binary
Hexadecimal Hexadecimal Hexadecimal
Bit ## Value Value Value
value value value
B0 B7 B8 B15 B16 B23
000-023 01101100 00011001 10001001 0x6C 0x19 0x89
024-047 10001111 01101000 00100001 0x8F 0x68 0x21
048-071 11110100 10100101 01100001 0xF4 0xA5 0x61
072-095 01001111 11010111 10101110 0x4F 0xD7 0xAE
096-119 00100100 00001100 11110011 0x24 0x0C 0xF3
120-143 00111010 11100100 10111100 0x3A 0xE4 0xBC
3325
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-15—The DATA bits after scrambling (continued)
Binary Binary Binary
Hexadecimal Hexadecimal Hexadecimal
Bit ## Value Value Value
value value value
B0 B7 B8 B15 B16 B23
144-167 01010011 10011000 11000000 0x53 0x98 0xC0
168-191 00011110 00110101 10110011 0x1E 0x35 0xB3
192-215 11100011 11111000 00100101 0xE3 0xF8 0x25
216-239 01100000 11010110 00100101 0x60 0xD6 0x25
240-263 00110101 00110011 11111110 0x35 0x33 0xFE
264-287 11110000 01000001 00101011 0xF0 0x41 0x2B
288-311 10001111 01010011 00011100 0x8F 0x53 0x1C
312-335 10000011 01000001 10111110 0x83 0x41 0xBE
336-359 00111001 00101000 01100110 0x39 0x28 0x66
360-383 01000100 01100110 11001101 0x44 0x66 0xCD
384-407 11110110 10100011 11011000 0xF6 0xA3 0xD8
408-431 00001101 11010100 10000001 0x0D 0xD4 0x81
432-455 00111011 00101111 11011111 0x3B 0x2F 0xDF
456-479 11000011 01011000 11110111 0xC3 0x58 0xF7
480-503 11000110 01010010 11101011 0xC6 0x52 0xEB
504-527 01110000 10001111 10011110 0x70 0x8F 0x9E
528-551 01101010 10010000 10000001 0x6A 0x90 0x81
552-575 11111101 01111100 10101001 0xFD 0x7C 0xA9
576-599 11010001 01010101 00010010 0xD1 0x55 0x12
600-623 00000100 01110100 11011001 0x04 0x74 0xD9
624-647 11101001 00111011 11001101 0xE9 0x3B 0xCD
648-671 10010011 10001101 01111011 0x93 0x8D 0x7B
672-695 01111100 01110000 00000010 0x7C 0x70 0x02
696-719 00100000 10011001 10100001 0x20 0x99 0xA1
720-743 01111101 10001010 00100111 0x7D 0x8A 0x27
744-767 00010111 00111001 00010101 0x17 0x39 0x15
768-791 10100000 11101100 10010101 0xA0 0xEC 0x95
792-815 00010110 10010001 00010000 0x16 0x91 0x10
816-839 00000000 11011100 01111111 0x00 0xDC 0x7F
840-863 00001110 11110010 11001001 0x0E 0xF2 0xC9
3326
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.1.6 Generating the first DATA symbol for the BCC example
I.1.6.1 Coding the DATA bits
The scrambled bits are coded with a rate convolutional code. The DATA encoded bits are shown in
Table I-16.
Table I-16—The BCC encoded DATA bits
Binary Binary Binary Binary
Bit Hexadecimal Hexadecimal Hexadecimal Hexadecimal
Value Value Value Value
## value value value value
B0B7 B8B15 B16B23 B24B31
0000 00101011 00001000 10100001 11110000 0x2B 0x08 0xA1 0xF0
-
0031
0032 10011101 10110101 10011010 00011101 0x9D 0xB5 0x9A 0x1D
-
0063
0064 01001010 11111011 11101000 11000010 0x4A 0xFB 0xE8 0xC2
-
0095
0096 10001111 11000000 11001000 01110011 0x8F 0xC0 0xC8 0x73
-
0127
0128 11000000 01000011 11100000 00011001 0xC0 0x43 0xE0 0x19
-
0159
0160 11100000 11010011 11101011 10110010 0xE0 0xD3 0xEB 0xB2
-
0191
0192 10101111 10011000 11111101 01011001 0xAF 0x98 0xFD 0x59
-
0223
0224 00001111 10001011 01101001 01100110 0x0F 0x8B 0x69 0x66
-
0255
0256 00001100 10101010 11011001 00010000 0x0C 0xAA 0xD9 0x10
-
0287
0288 01010110 10001011 10100110 01000000 0x56 0x8B 0xA6 0x40
-
0319
0320 01100100 10110011 00100001 10011110 0x64 0xB3 0x21 0x9E
-
0351
0352 10001110 10010001 11000001 00000101 0x8E 0x91 0xC1 0x05
-
0383
3327
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-16—The BCC encoded DATA bits (continued)
Binary Binary Binary Binary
Bit Hexadecimal Hexadecimal Hexadecimal Hexadecimal
Value Value Value Value
## value value value value
B0B7 B8B15 B16B23 B24B31
0384 10110111 10110111 11000101 11011000 0xB7 0xB7 0xC5 0xD8
-
0415
0416 10000000 00101111 10100010 11011101 0x80 0x2F 0xA2 0xDD
-
0447
0448 01101111 00101011 10010111 01100001 0x6F 0x2B 0x97 0x61
-
0479
0480 11011001 11011101 00001101 00010010 0xD9 0xDD 0x0D 0x12
-
0511
0512 01110110 00100111 00000010 01001100 0x76 0x27 0x02 0x4C
-
0543
0544 10010010 10111100 00010010 01001011 0x92 0xBC 0x12 0x4B
-
0575
0576 01101010 11110111 01110000 00100011 0x6A 0xF7 0x70 0x23
-
0607
0608 00100111 10001110 00000001 10110100 0x27 0x8E 0x01 0xB4
-
0639
0640 11010110 11000011 01101010 01100000 0xD6 0xC3 0x6A 0x60
-
0671
0672 01001101 01001011 11001011 01010001 0x4D 0x4B 0xCB 0x51
-
0703
0704 10011100 10110000 10000000 11101011 0x9C 0xB0 0x80 0xEB
-
0735
0736 10001001 00110100 00010100 01000000 0x89 0x34 0x14 0x40
-
0767
0768 01101100 10011110 00101100 01010001 0x6C 0x9E 0x2C 0x51
-
0799
0800 01001011 01111100 01101001 00010001 0x4B 0x7C 0x69 0x11
-
0831
3328
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-16—The BCC encoded DATA bits (continued)
Binary Binary Binary Binary
Bit Hexadecimal Hexadecimal Hexadecimal Hexadecimal
Value Value Value Value
## value value value value
B0B7 B8B15 B16B23 B24B31
0832 00010101 10000110 11111101 10111110 0x15 0x86 0xFD 0xBE
-
0863
0864 01011110 11111001 10111110 00101000 0x5E 0xF9 0xBE 0x28
-
0895
0896 11101111 11001010 01010101 00000011 0xEF 0xCA 0x55 0x03
-
0927
0928 11111101 00100110 10010001 00111011 0xFD 0x26 0x91 0x3B
-
0959
0960 10010101 11101100 01011011 00100011 0x95 0xEC 0x5B 0x23
-
0991
0992 10011001 01011111 00101000 00111110 0x99 0x5F 0x28 0x3E
-
1023
1024 11010100 11101001 11110111 10111000 0xD4 0xE9 0xF7 0xB8
-
1055
1056 00010011 01110101 10001110 11110010 0x13 0x75 0x8E 0xF2
-
1087
1088 10100000 00011011 01101100 11101001 0xA0 0x1B 0x6C 0xE9
-
1119
1120 00000111 01011101 10110000 10111111 0x07 0x5D 0xB0 0xBF
-
1151
I.1.6.2 Interleaving the DATA bits
The interleaver is defined as a two-permutation process. The index of the coded bit before the first
permutation shall be denoted by k; i shall be the index after the first and before the second permutation; and
j shall be the index after the second permutation, just prior to modulation mapping. The mapping from k to i
is shown in Table I-17, and the mapping from i to j is shown in Table I-18.
As a specific example, consider the case of k = 17 (the 18th bit after encoding and puncturing). It is mapped
by the first permutation to i = 13 and by the second permutation to j = 12 (the 13th bit before mapping).
The interleaved bits are shown in Table I-19.
3329
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-17—First permutation
k i k i k i k i k i k i k i k i
0 0 24 97 48 3 72 100 96 6 120 103 144 9 168 106
1 12 25 109 49 15 73 112 97 18 121 115 145 21 169 118
2 24 26 121 50 27 74 124 98 30 122 127 146 33 170 130
3 36 27 133 51 39 75 136 99 42 123 139 147 45 171 142
4 48 28 145 52 51 76 148 100 54 124 151 148 57 172 154
5 60 29 157 53 63 77 160 101 66 125 163 149 69 173 166
6 72 30 169 54 75 78 172 102 78 126 175 150 81 174 178
7 84 31 181 55 87 79 184 103 90 127 187 151 93 175 190
8 96 32 2 56 99 80 5 104 102 128 8 152 105 176 11
9 108 33 14 57 111 81 17 105 114 129 20 153 117 177 23
10 120 34 26 58 123 82 29 106 126 130 32 154 129 178 35
11 132 35 38 59 135 83 41 107 138 131 44 155 141 179 47
12 144 36 50 60 147 84 53 108 150 132 56 156 153 180 59
13 156 37 62 61 159 85 65 109 162 133 68 157 165 181 71
14 168 38 74 62 171 86 77 110 174 134 80 158 177 182 83
15 180 39 86 63 183 87 89 111 186 135 92 159 189 183 95
16 1 40 98 64 4 88 101 112 7 136 104 160 10 184 107
17 13 41 110 65 16 89 113 113 19 137 116 161 22 185 119
18 25 42 122 66 28 90 125 114 31 138 128 162 34 186 131
19 37 43 134 67 40 91 137 115 43 139 140 163 46 187 143
20 49 44 146 68 52 92 149 116 55 140 152 164 58 188 155
21 61 45 158 69 64 93 161 117 67 141 164 165 70 189 167
22 73 46 170 70 76 94 173 118 79 142 176 166 82 190 179
23 85 47 182 71 88 95 185 119 91 143 188 167 94 191 191
Table I-18—Second permutation
i j i j i j i j i j i j i j i j
0 0 24 24 48 48 72 72 96 96 120 120 144 144 168 168
1 1 25 25 49 49 73 73 97 97 121 121 145 145 169 169
2 2 26 26 50 50 74 74 98 98 122 122 146 146 170 170
3 3 27 27 51 51 75 75 99 99 123 123 147 147 171 171
4 4 28 28 52 52 76 76 100 100 124 124 148 148 172 172
3330
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-18—Second permutation (continued)
i j i j i j i j i j i j i j i j
5 5 29 29 53 53 77 77 101 101 125 125 149 149 173 173
6 6 30 30 54 54 78 78 102 102 126 126 150 150 174 174
7 7 31 31 55 55 79 79 103 103 127 127 151 151 175 175
8 8 32 32 56 56 80 80 104 104 128 128 152 152 176 176
9 9 33 33 57 57 81 81 105 105 129 129 153 153 177 177
10 10 34 34 58 58 82 82 106 106 130 130 154 154 178 178
11 11 35 35 59 59 83 83 107 107 131 131 155 155 179 179
12 13 36 37 60 61 84 85 108 109 132 133 156 157 180 181
13 12 37 36 61 60 85 84 109 108 133 132 157 156 181 180
14 15 38 39 62 63 86 87 110 111 134 135 158 159 182 183
15 14 39 38 63 62 87 86 111 110 135 134 159 158 183 182
16 17 40 41 64 65 88 89 112 113 136 137 160 161 184 185
17 16 41 40 65 64 89 88 113 112 137 136 161 160 185 184
18 19 42 43 66 67 90 91 114 115 138 139 162 163 186 187
19 18 43 42 67 66 91 90 115 114 139 138 163 162 187 186
20 21 44 45 68 69 92 93 116 117 140 141 164 165 188 189
21 20 45 44 69 68 93 92 117 116 141 140 165 164 189 188
22 23 46 47 70 71 94 95 118 119 142 143 166 167 190 191
23 22 47 46 71 70 95 94 119 118 143 142 167 166 191 190
Table I-19—Interleaved bits of first DATA symbol
## Bit ## Bit ## Bit ## Bit ## Bit ## Bit
0 0 32 0 64 0 96 0 128 0 160 0
1 1 33 1 65 0 97 1 129 0 161 0
2 1 34 1 66 0 98 1 130 0 162 0
3 1 35 1 67 1 99 0 131 1 163 0
4 0 36 0 68 0 100 1 132 1 164 0
5 1 37 0 69 0 101 1 133 0 165 0
6 1 38 1 70 0 102 1 134 1 166 0
7 1 39 1 71 0 103 0 135 1 167 0
8 1 40 0 72 1 104 0 136 0 168 0
9 1 41 0 73 0 105 0 137 1 169 0
3331
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-19—Interleaved bits of first DATA symbol (continued)
## Bit ## Bit ## Bit ## Bit ## Bit ## Bit
10 1 42 0 74 0 106 1 138 1 170 0
11 1 43 0 75 1 107 1 139 0 171 0
12 0 44 0 76 1 108 1 140 1 172 1
13 0 45 0 77 0 109 0 141 0 173 1
14 0 46 0 78 1 110 0 142 1 174 0
15 0 47 0 79 0 111 0 143 1 175 1
16 1 48 1 80 0 112 1 144 1 176 1
17 1 49 0 81 0 113 1 145 0 177 0
18 1 50 1 82 0 114 1 146 0 178 1
19 0 51 1 83 1 115 1 147 1 179 1
20 1 52 1 84 1 116 0 148 1 180 0
21 1 53 1 85 1 117 1 149 0 181 0
22 1 54 1 86 0 118 0 150 0 182 1
23 1 55 1 87 1 119 1 151 0 183 1
24 1 56 0 88 0 120 0 152 0 184 0
25 1 57 0 89 0 121 1 153 1 185 1
26 0 58 0 90 0 122 1 154 0 186 1
27 0 59 1 91 1 123 0 155 0 187 0
28 0 60 0 92 0 124 1 156 0 188 1
29 1 61 0 93 0 125 0 157 0 189 1
30 0 62 0 94 1 126 0 158 1 190 0
31 0 63 1 95 0 127 1 159 1 191 1
I.1.6.3 Mapping into symbols
The frequency domain symbols are generated by grouping 4 coded bits and mapping into complex 16-QAM
symbols according to Table 17-14 (in 17.3.5.8). For instance, the first 4 bits (0 1 1 1) are mapped to the
complex value, –0.316 + 0.316j, inserted at subcarrier #26.
Four pilot subcarriers are added by taking the values {1.0,1.0,1.0,–1.0}, multiplying them by the
second element of sequence p, given in Equation (17-22) (in 17.3.5.10), and inserting them into location
{–21,–7,7,21}, respectively.
The frequency domain is shown in Table I-20.
The time domain samples are produced by performing IFFT, cyclically extending, and multiplying with the
window function in the same manner as described in I.1.4.5. The time domain samples are appended with
one sample overlap to the SIGNAL field symbol.
3332
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-20—Frequency domain of first DATA symbol
## Re Im ## Re Im ## Re Im ## Re Im
–32 0.000 0.000 –16 –0.949 0.316 0 0.000 0.000 16 –0.316 –0.949
–31 0.000 0.000 –15 –0.949 –0.949 1 –0.316 0.949 17 –0.949 0.316
–30 0.000 0.000 –14 –0.949 –0.949 2 0.316 0.949 18 –0.949 –0.949
–29 0.000 0.000 –13 0.949 0.316 3 –0.949 0.316 19 –0.949 –0.949
–28 0.000 0.000 –12 0.316 0.316 4 0.949 –0.949 20 –0.949 –0.949
–27 0.000 0.000 –11 –0.949 –0.316 5 0.316 0.316 21 –1.000 0.000
–26 –0.316 0.316 –10 –0.949 –0.316 6 –0.316 –0.316 22 0.316 –0.316
–25 –0.316 0.316 –9 –0.949 –0.316 7 1.000 0.000 23 0.949 0.316
–24 0.316 0.316 –8 –0.949 –0.949 8 –0.316 0.949 24 –0.949 0.316
–23 –0.949 –0.949 –7 1.000 0.000 9 0.949 –0.316 25 –0.316 0.949
–22 0.316 0.949 –6 0.949 –0.316 10 –0.949 –0.316 26 0.316 –0.316
–21 1.000 0.000 –5 0.949 0.949 11 0.949 0.316 27 0.000 0.000
–20 0.316 0.316 –4 –0.949 –0.316 12 –0.316 0.949 28 0.000 0.000
–19 0.316 –0.949 –3 0.316 –0.316 13 0.949 0.316 29 0.000 0.000
–18 –0.316 –0.949 –2 –0.949 –0.316 14 0.949 –0.316 30 0.000 0.000
–17 –0.316 0.316 –1 –0.949 0.949 15 0.949 –0.949 31 0.000 0.000
I.1.7 Generating the additional DATA symbols
The generation of the additional five data symbols follows the same procedure as described in Clause 4.
Special attention should be paid to the scrambling of the pilot subcarriers. Table I-21 lists the polarity of the
pilot subcarriers and the elements of the sequence p0…126 for the DATA symbols. For completeness, the
pilots in the SIGNAL are included as well. The symbols are appended one after the other with a one-sample
overlap.
Table I-21—Polarity of the pilot subcarriers
i OFDM symbol Element of pi Pilot at #–21 Pilot at #–7 Pilot at #7 Pilot at #21
0 SIGNAL 1 1.0 +0 j 1.0 +0 j 1.0 +0 j –1.0 +0 j
1 DATA 1 1 1.0 +0 j 1.0 +0 j 1.0 +0 j –1.0 +0 j
2 DATA 2 1 1.0 +0 j 1.0 +0 j 1.0 +0 j –1.0 +0 j
3 DATA 3 1 1.0 +0 j 1.0 +0 j 1.0 +0 j –1.0 +0 j
4 DATA 4 –1 –1.0 +0 j –1.0 +0 j –1.0 +0 j 1.0 +0 j
5 DATA 5 –1 –1.0 +0 j –1.0 +0 j –1.0 +0 j 1.0 +0 j
6 DATA 6 –1 –1.0 +0 j –1.0 +0 j –1.0 +0 j 1.0 +0 j
3333
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.1.8 The entire packet for the BCC example
The packet in its entirety is shown in the tables in this subclause. These tables illustrate the short
training sequence section (Table I-22), the long training sequence section (Table I-23), the SIGNAL field
(Table I-24), and the six DATA symbols (Table I-25 to Table I-30).
Table I-22—Time domain representation of the short training sequence
## Real Imag ## Real Imag ## Real Imag ## Real Imag
0 0.023 0.023 1 –0.132 0.002 2 –0.013 –0.079 3 0.143 –0.013
4 0.092 0.000 5 0.143 –0.013 6 –0.013 –0.079 7 –0.132 0.002
8 0.046 0.046 9 0.002 –0.132 10 –0.079 –0.013 11 –0.013 0.143
12 0.000 0.092 13 –0.013 0.143 14 –0.079 –0.013 15 0.002 –0.132
16 0.046 0.046 17 –0.132 0.002 18 –0.013 –0.079 19 0.143 –0.013
20 0.092 0.000 21 0.143 –0.013 22 –0.013 –0.079 23 –0.132 0.002
24 0.046 0.046 25 0.002 –0.132 26 –0.079 –0.013 27 –0.013 0.143
28 0.000 0.092 29 –0.013 0.143 30 –0.079 –0.013 31 0.002 –0.132
32 0.046 0.046 33 –0.132 0.002 34 –0.013 –0.079 35 0.143 –0.013
36 0.092 0.000 37 0.143 –0.013 38 –0.013 –0.079 39 –0.132 0.002
40 0.046 0.046 41 0.002 –0.132 42 –0.079 –0.013 43 –0.013 0.143
44 0.000 0.092 45 –0.013 0.143 46 –0.079 –0.013 47 0.002 –0.132
48 0.046 0.046 49 –0.132 0.002 50 –0.013 –0.079 51 0.143 –0.013
52 0.092 0.000 53 0.143 –0.013 54 –0.013 –0.079 55 –0.132 0.002
56 0.046 0.046 57 0.002 –0.132 58 –0.079 –0.013 59 –0.013 0.143
60 0.000 0.092 61 –0.013 0.143 62 –0.079 –0.013 63 0.002 –0.132
64 0.046 0.046 65 –0.132 0.002 66 –0.013 –0.079 67 0.143 –0.013
68 0.092 0.000 69 0.143 –0.013 70 –0.013 –0.079 71 –0.132 0.002
72 0.046 0.046 73 0.002 –0.132 74 –0.079 –0.013 75 –0.013 0.143
76 0.000 0.092 77 –0.013 0.143 78 –0.079 –0.013 79 0.002 –0.132
80 0.046 0.046 81 –0.132 0.002 82 –0.013 –0.079 83 0.143 –0.013
84 0.092 0.000 85 0.143 –0.013 86 –0.013 –0.079 87 –0.132 0.002
88 0.046 0.046 89 0.002 –0.132 90 –0.079 –0.013 91 –0.013 0.143
92 0.000 0.092 93 –0.013 0.143 94 –0.079 –0.013 95 0.002 –0.132
96 0.046 0.046 97 –0.132 0.002 98 –0.013 –0.079 99 0.143 –0.013
100 0.092 0.000 101 0.143 –0.013 102 –0.013 –0.079 103 –0.132 0.002
104 0.046 0.046 105 0.002 –0.132 106 –0.079 –0.013 107 –0.013 0.143
108 0.000 0.092 109 –0.013 0.143 110 –0.079 –0.013 111 0.002 –0.132
3334
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-22—Time domain representation of the short training sequence (continued)
## Real Imag ## Real Imag ## Real Imag ## Real Imag
112 0.046 0.046 113 –0.132 0.002 114 –0.013 –0.079 115 0.143 –0.013
116 0.092 0.000 117 0.143 –0.013 118 –0.013 –0.079 119 –0.132 0.002
120 0.046 0.046 121 0.002 –0.132 122 –0.079 –0.013 123 –0.013 0.143
124 0.000 0.092 125 –0.013 0.143 126 –0.079 –0.013 127 0.002 –0.132
128 0.046 0.046 129 –0.132 0.002 130 –0.013 –0.079 131 0.143 –0.013
132 0.092 0.000 133 0.143 –0.013 134 –0.013 –0.079 135 –0.132 0.002
136 0.046 0.046 137 0.002 –0.132 138 –0.079 –0.013 139 –0.013 0.143
140 0.000 0.092 141 –0.013 0.143 142 –0.079 –0.013 143 0.002 –0.132
144 0.046 0.046 145 –0.132 0.002 146 –0.013 –0.079 147 0.143 –0.013
148 0.092 0.000 149 0.143 –0.013 150 –0.013 –0.079 151 –0.132 0.002
152 0.046 0.046 153 0.002 –0.132 154 –0.079 –0.013 155 –0.013 0.143
156 0.000 0.092 157 –0.013 0.143 158 –0.079 –0.013 159 0.002 –0.132
Table I-23—Time domain representation of the long training sequence
## Real Imag ## Real Imag ## Real Imag ## Real Imag
160 –0.055 0.023 161 0.012 –0.098 162 0.092 –0.106 163 –0.092 –0.115
164 –0.003 –0.054 165 0.075 0.074 166 –0.127 0.021 167 –0.122 0.017
168 –0.035 0.151 169 –0.056 0.022 170 –0.060 –0.081 171 0.070 –0.014
172 0.082 –0.092 173 –0.131 –0.065 174 –0.057 –0.039 175 0.037 –0.098
176 0.062 0.062 177 0.119 0.004 178 –0.022 –0.161 179 0.059 0.015
180 0.024 0.059 181 –0.137 0.047 182 0.001 0.115 183 0.053 –0.004
184 0.098 0.026 185 –0.038 0.106 186 –0.115 0.055 187 0.060 0.088
188 0.021 –0.028 189 0.097 –0.083 190 0.040 0.111 191 –0.005 0.120
192 0.156 0.000 193 –0.005 –0.120 194 0.040 –0.111 195 0.097 0.083
196 0.021 0.028 197 0.060 –0.088 198 –0.115 –0.055 199 –0.038 –0.106
200 0.098 –0.026 201 0.053 0.004 202 0.001 –0.115 203 –0.137 –0.047
204 0.024 –0.059 205 0.059 –0.015 206 –0.022 0.161 207 0.119 –0.004
208 0.062 –0.062 209 0.037 0.098 210 –0.057 0.039 211 –0.131 0.065
212 0.082 0.092 213 0.070 0.014 214 –0.060 0.081 215 –0.056 –0.022
216 –0.035 –0.151 217 –0.122 –0.017 218 –0.127 –0.021 219 0.075 –0.074
220 –0.003 0.054 221 –0.092 0.115 222 0.092 0.106 223 0.012 0.098
224 –0.156 0.000 225 0.012 –0.098 226 0.092 –0.106 227 –0.092 –0.115
3335
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-23—Time domain representation of the long training sequence (continued)
## Real Imag ## Real Imag ## Real Imag ## Real Imag
228 –0.003 –0.054 229 0.075 0.074 230 –0.127 0.021 231 –0.122 0.017
232 –0.035 0.151 233 –0.056 0.022 234 –0.060 –0.081 235 0.070 –0.014
236 0.082 –0.092 237 –0.131 –0.065 238 –0.057 –0.039 239 0.037 –0.098
240 0.062 0.062 241 0.119 0.004 242 –0.022 –0.161 243 0.059 0.015
244 0.024 0.059 245 –0.137 0.047 246 0.001 0.115 247 0.053 –0.004
248 0.098 0.026 249 –0.038 0.106 250 –0.115 0.055 251 0.060 0.088
252 0.021 –0.028 253 0.097 –0.083 254 0.040 0.111 255 –0.005 0.120
256 0.156 0.000 257 –0.005 –0.120 258 0.040 –0.111 259 0.097 0.083
260 0.021 0.028 261 0.060 –0.088 262 –0.115 –0.055 263 –0.038 –0.106
264 0.098 –0.026 265 0.053 0.004 266 0.001 –0.115 267 –0.137 –0.047
268 0.024 –0.059 269 0.059 –0.015 270 –0.022 0.161 271 0.119 –0.004
272 0.062 –0.062 273 0.037 0.098 274 –0.057 0.039 275 –0.131 0.065
276 0.082 0.092 277 0.070 0.014 278 –0.060 0.081 279 –0.056 –0.022
280 –0.035 –0.151 281 –0.122 –0.017 282 –0.127 –0.021 283 0.075 –0.074
284 –0.003 0.054 285 –0.092 0.115 286 0.092 0.106 287 0.012 0.098
288 –0.156 0.000 289 0.012 –0.098 290 0.092 –0.106 291 –0.092 –0.115
292 –0.003 –0.054 293 0.075 0.074 294 –0.127 0.021 295 –0.122 0.017
296 –0.035 0.151 297 –0.056 0.022 298 –0.060 –0.081 299 0.070 –0.014
300 0.082 –0.092 301 –0.131 –0.065 302 –0.057 –0.039 303 0.037 –0.098
304 0.062 0.062 305 0.119 0.004 306 –0.022 –0.161 307 0.059 0.015
308 0.024 0.059 309 –0.137 0.047 310 0.001 0.115 311 0.053 –0.004
312 0.098 0.026 313 –0.038 0.106 314 –0.115 0.055 315 0.060 0.088
316 0.021 –0.028 317 0.097 –0.083 318 0.040 0.111 319 –0.005 0.120
Table I-24—Time domain representation of the SIGNAL field (1 symbol)
## Real Imag ## Real Imag ## Real Imag ## Real Imag
320 0.109 0.000 321 0.033 –0.044 322 –0.002 –0.038 323 –0.081 0.084
324 0.007 –0.100 325 –0.001 –0.113 326 –0.021 –0.005 327 0.136 –0.105
328 0.098 –0.044 329 0.011 –0.002 330 –0.033 0.044 331 –0.060 0.124
332 0.010 0.097 333 0.000 –0.008 334 0.018 –0.083 335 –0.069 0.027
336 –0.219 0.000 337 –0.069 –0.027 338 0.018 0.083 339 0.000 0.008
340 0.010 –0.097 341 –0.060 –0.124 342 –0.033 –0.044 343 0.011 0.002
3336
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-24—Time domain representation of the SIGNAL field (1 symbol) (continued)
## Real Imag ## Real Imag ## Real Imag ## Real Imag
344 0.098 0.044 345 0.136 0.105 346 –0.021 0.005 347 –0.001 0.113
348 0.007 0.100 349 –0.081 –0.084 350 –0.002 0.038 351 0.033 0.044
352 0.062 0.000 353 0.057 0.052 354 0.016 0.174 355 0.035 0.116
356 –0.051 –0.202 357 0.011 0.036 358 0.089 0.209 359 –0.049 –0.008
360 –0.035 0.044 361 0.017 –0.059 362 0.053 –0.017 363 0.099 0.100
364 0.034 –0.148 365 –0.003 –0.094 366 –0.120 0.042 367 –0.136 –0.070
368 –0.031 0.000 369 –0.136 0.070 370 –0.120 –0.042 371 –0.003 0.094
372 0.034 0.148 373 0.099 –0.100 374 0.053 0.017 375 0.017 0.059
376 –0.035 –0.044 377 –0.049 0.008 378 0.089 –0.209 379 0.011 –0.036
380 –0.051 0.202 381 0.035 –0.116 382 0.016 –0.174 383 0.057 –0.052
384 0.062 0.000 385 0.033 –0.044 386 –0.002 –0.038 387 –0.081 0.084
388 0.007 –0.100 389 –0.001 –0.113 390 –0.021 –0.005 391 0.136 –0.105
392 0.098 –0.044 393 0.011 –0.002 394 –0.033 0.044 395 –0.060 0.124
396 0.010 0.097 397 0.000 –0.008 398 0.018 –0.083 399 –0.069 0.027
Table I-25—Time domain representation of the DATA field: symbol 1of 6
## Real Imag ## Real Imag ## Real Imag ## Real Imag
400 –0.139 0.050 401 0.004 0.014 402 0.011 –0.100 403 –0.097 –0.020
404 0.062 0.081 405 0.124 0.139 406 0.104 –0.015 407 0.173 –0.140
408 –0.040 0.006 409 –0.133 0.009 410 –0.002 –0.043 411 –0.047 0.092
412 –0.109 0.082 413 –0.024 0.010 414 0.096 0.019 415 0.019 –0.023
416 –0.087 –0.049 417 0.002 0.058 418 –0.021 0.228 419 –0.103 0.023
420 –0.019 –0.175 421 0.018 0.132 422 –0.071 0.160 423 –0.153 –0.062
424 –0.107 0.028 425 0.055 0.140 426 0.070 0.103 427 –0.056 0.025
428 –0.043 0.002 429 0.016 –0.118 430 0.026 –0.071 431 0.033 0.177
432 0.020 –0.021 433 0.035 –0.088 434 –0.008 0.101 435 –0.035 –0.010
436 0.065 0.030 437 0.092 –0.034 438 0.032 –0.123 439 –0.018 0.092
440 0.000 –0.006 441 –0.006 –0.056 442 –0.019 0.040 443 0.053 –0.131
444 0.022 –0.133 445 0.104 –0.032 446 0.163 –0.045 447 –0.105 –0.030
448 –0.110 –0.069 449 –0.008 –0.092 450 –0.049 –0.043 451 0.085 –0.017
452 0.090 0.063 453 0.015 0.153 454 0.049 0.094 455 0.011 0.034
456 –0.012 0.012 457 –0.015 –0.017 458 –0.061 0.031 459 –0.070 –0.040
3337
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-25—Time domain representation of the DATA field: symbol 1of 6 (continued)
## Real Imag ## Real Imag ## Real Imag ## Real Imag
460 0.011 –0.109 461 0.037 –0.060 462 –0.003 –0.178 463 –0.007 –0.128
464 –0.059 0.100 465 0.004 0.014 466 0.011 –0.100 467 –0.097 –0.020
468 0.062 0.081 469 0.124 0.139 470 0.104 –0.015 471 0.173 –0.140
472 –0.040 0.006 473 –0.133 0.009 474 –0.002 –0.043 475 –0.047 0.092
476 –0.109 0.082 477 –0.024 0.010 478 0.096 0.019 479 0.019 –0.023
Table I-26—Time domain representation of the DATA field: symbol 2 of 6
## Real Imag ## Real Imag ## Real Imag ## Real Imag
480 –0.058 0.016 481 –0.096 –0.045 482 –0.110 0.003 483 –0.070 0.216
484 –0.040 0.059 485 0.010 –0.056 486 0.034 0.065 487 0.117 0.033
488 0.078 –0.133 489 –0.043 –0.146 490 0.158 –0.071 491 0.254 –0.021
492 0.068 0.117 493 –0.044 0.114 494 –0.035 0.041 495 0.085 0.070
496 0.120 0.010 497 0.057 0.055 498 0.063 0.188 499 0.091 0.149
500 –0.017 –0.039 501 –0.078 –0.075 502 0.049 0.079 503 –0.014 –0.007
504 0.030 –0.027 505 0.080 0.054 506 –0.186 –0.067 507 –0.039 –0.027
508 0.043 –0.072 509 –0.092 –0.089 510 0.029 0.105 511 –0.144 0.003
512 –0.069 –0.041 513 0.132 0.057 514 –0.126 0.070 515 –0.031 0.109
516 0.161 –0.009 517 0.056 –0.046 518 –0.004 0.028 519 –0.049 0.000
520 –0.078 –0.005 521 0.015 –0.087 522 0.149 –0.104 523 –0.021 –0.051
524 –0.154 –0.106 525 0.024 0.030 526 0.046 0.123 527 –0.004 –0.098
528 –0.061 –0.128 529 –0.024 –0.038 530 0.066 –0.048 531 –0.067 0.027
532 0.054 –0.050 533 0.171 –0.049 534 –0.108 0.132 535 –0.161 –0.019
536 –0.070 –0.072 537 –0.177 0.049 538 –0.172 –0.050 539 0.051 –0.075
540 0.122 –0.057 541 0.009 –0.044 542 –0.012 –0.021 543 0.004 0.009
544 –0.030 0.081 545 –0.096 –0.045 546 –0.110 0.003 547 –0.070 0.216
548 –0.040 0.059 549 0.010 –0.056 550 0.034 0.065 551 0.117 0.033
552 0.078 –0.133 553 –0.043 –0.146 554 0.158 –0.071 555 0.254 –0.021
556 0.068 0.117 557 –0.044 0.114 558 –0.035 0.041 559 0.085 0.070
3338
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-27—Time domain representation of the DATA field: symbol 3 of 6
## Real Imag ## Real Imag ## Real Imag ## Real Imag
560 0.001 0.011 561 –0.099 –0.048 562 0.054 –0.196 563 0.124 0.035
564 0.092 0.045 565 –0.037 –0.066 566 –0.021 –0.004 567 0.042 –0.065
568 0.061 0.048 569 0.046 0.004 570 –0.063 –0.045 571 –0.102 0.152
572 –0.039 –0.019 573 –0.005 –0.106 574 0.083 0.031 575 0.226 0.028
576 0.140 –0.010 577 –0.132 –0.033 578 –0.116 0.088 579 0.023 0.052
580 –0.171 –0.080 581 –0.246 –0.025 582 –0.062 –0.038 583 –0.055 –0.062
584 –0.004 –0.060 585 0.034 0.000 586 –0.030 0.021 587 0.075 –0.122
588 0.043 –0.080 589 –0.022 0.041 590 0.026 0.013 591 –0.031 –0.018
592 0.059 0.008 593 0.109 0.078 594 0.002 0.101 595 –0.016 0.054
596 –0.059 0.070 597 0.017 0.114 598 0.104 –0.034 599 –0.024 –0.059
600 –0.081 0.051 601 –0.040 –0.069 602 –0.069 0.058 603 –0.067 0.117
604 0.007 –0.131 605 0.009 0.028 606 0.075 0.117 607 0.118 0.030
608 –0.041 0.148 609 0.005 0.098 610 0.026 0.002 611 –0.116 0.045
612 –0.020 0.084 613 0.101 0.006 614 0.205 –0.064 615 0.073 –0.063
616 –0.174 –0.118 617 –0.024 0.026 618 –0.041 0.129 619 –0.042 –0.053
620 0.148 –0.126 621 –0.030 –0.049 622 –0.015 –0.021 623 0.089 –0.069
624 –0.119 0.011 625 –0.099 –0.048 626 0.054 –0.196 627 0.124 0.035
628 0.092 0.045 629 –0.037 –0.066 630 –0.021 –0.004 631 0.042 –0.065
632 0.061 0.048 633 0.046 0.004 634 –0.063 –0.045 635 –0.102 0.152
636 –0.039 –0.019 637 –0.005 –0.106 638 0.083 0.031 639 0.226 0.028
Table I-28—Time domain representation of the DATA field: symbol 4 of 6
## Real Imag ## Real Imag ## Real Imag ## Real Imag
640 0.085 –0.065 641 0.034 –0.142 642 0.004 –0.012 643 0.126 –0.043
644 0.055 0.068 645 –0.020 0.077 646 0.008 –0.056 647 –0.034 0.046
648 –0.040 –0.134 649 –0.056 –0.131 650 0.014 0.097 651 0.045 –0.009
652 –0.113 –0.170 653 –0.065 –0.230 654 0.065 –0.011 655 0.011 0.048
656 –0.091 –0.059 657 –0.110 0.024 658 0.074 –0.034 659 0.124 0.022
660 –0.037 0.071 661 0.015 0.002 662 0.028 0.099 663 –0.062 0.068
664 0.064 0.016 665 0.078 0.156 666 0.009 0.219 667 0.147 0.024
668 0.106 0.030 669 –0.080 0.143 670 –0.049 –0.100 671 –0.036 –0.082
672 –0.089 0.021 673 –0.070 –0.029 674 –0.086 0.048 675 –0.066 –0.015
3339
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-28—Time domain representation of the DATA field: symbol 4 of 6 (continued)
## Real Imag ## Real Imag ## Real Imag ## Real Imag
676 –0.024 0.002 677 –0.030 –0.023 678 –0.032 0.020 679 –0.002 0.212
680 0.158 –0.024 681 0.141 –0.119 682 –0.146 0.058 683 –0.155 0.083
684 –0.002 –0.030 685 0.018 –0.129 686 0.012 –0.018 687 –0.008 –0.037
688 0.031 0.040 689 0.023 0.097 690 0.014 –0.039 691 0.050 0.019
692 –0.072 –0.141 693 –0.023 –0.051 694 0.024 0.099 695 –0.127 –0.116
696 0.094 0.102 697 0.183 0.098 698 –0.040 –0.020 699 0.065 0.077
700 0.088 –0.147 701 –0.039 –0.059 702 –0.057 0.124 703 –0.077 0.020
704 0.030 –0.120 705 0.034 –0.142 706 0.004 –0.012 707 0.126 –0.043
708 0.055 0.068 709 –0.020 0.077 710 0.008 –0.056 711 –0.034 0.046
712 –0.040 –0.134 713 –0.056 –0.131 714 0.014 0.097 715 0.045 –0.009
716 –0.113 –0.170 717 –0.065 –0.230 718 0.065 –0.011 719 0.011 0.048
720 –0.026 –0.021 721 –0.002 0.041 722 0.001 0.071 723 –0.037 –0.117
Table I-29—Time domain representation of the DATA field: symbol 5 of 6
## Real Imag ## Real Imag ## Real Imag ## Real Imag
724 –0.106 –0.062 725 0.002 0.057 726 –0.008 –0.011 727 0.019 0.072
728 0.016 0.059 729 –0.065 –0.077 730 0.142 –0.062 731 0.087 0.025
732 –0.003 –0.103 733 0.107 –0.152 734 –0.054 0.036 735 –0.030 –0.003
736 0.058 –0.020 737 –0.028 0.007 738 –0.027 –0.099 739 0.049 –0.075
740 0.174 0.031 741 0.134 0.156 742 0.060 0.077 743 –0.010 –0.022
744 –0.084 0.040 745 –0.074 0.011 746 –0.163 0.054 747 –0.052 –0.008
748 0.076 –0.042 749 0.043 0.101 750 0.058 –0.018 751 0.003 –0.090
752 0.059 –0.018 753 0.023 –0.031 754 0.007 –0.017 755 0.066 –0.017
756 –0.135 –0.098 757 –0.056 –0.081 758 0.089 0.154 759 0.120 0.122
760 0.102 0.001 761 –0.141 0.102 762 0.006 –0.011 763 0.057 –0.039
764 –0.059 0.066 765 0.132 0.111 766 0.012 0.114 767 0.047 –0.106
768 0.160 –0.099 769 –0.076 0.084 770 –0.049 0.073 771 0.005 –0.086
772 –0.052 –0.108 773 –0.073 0.129 774 –0.129 –0.034 775 –0.153 –0.111
776 –0.193 0.098 777 –0.107 –0.068 778 0.004 –0.009 779 –0.039 0.024
780 –0.054 –0.079 781 0.024 0.084 782 0.052 –0.002 783 0.028 –0.044
3340
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-29—Time domain representation of the DATA field: symbol 5 of 6 (continued)
## Real Imag ## Real Imag ## Real Imag ## Real Imag
784 0.040 0.018 785 –0.002 0.041 786 0.001 0.071 787 –0.037 –0.117
788 –0.106 –0.062 789 0.002 0.057 790 –0.008 –0.011 791 0.019 0.072
792 0.016 0.059 793 –0.065 –0.077 794 0.142 –0.062 795 0.087 0.025
796 –0.003 –0.103 797 0.107 –0.152 798 –0.054 0.036 799 –0.030 –0.003
Table I-30—Time domain representation of the DATA field: symbol 6 of 6
## Real Imag ## Real Imag ## Real Imag ## Real Imag
800 0.029 –0.026 801 –0.047 0.077 802 –0.007 –0.002 803 0.050 –0.021
804 0.046 –0.040 805 –0.061 –0.099 806 –0.121 0.008 807 0.014 0.050
808 0.145 0.034 809 0.001 –0.046 810 –0.058 –0.121 811 0.040 0.001
812 –0.029 0.041 813 0.002 –0.066 814 0.015 –0.054 815 0.010 –0.029
816 0.008 –0.119 817 –0.134 0.002 818 0.064 0.079 819 0.095 –0.102
820 –0.069 –0.014 821 0.156 0.037 822 0.047 –0.008 823 –0.076 0.025
824 0.117 –0.143 825 0.056 –0.042 826 0.002 0.075 827 –0.039 –0.058
828 –0.092 0.014 829 –0.041 0.047 830 –0.058 0.092 831 0.012 0.154
832 0.079 0.091 833 –0.067 0.017 834 –0.102 –0.032 835 0.039 0.084
836 –0.036 0.014 837 –0.001 –0.046 838 0.195 0.131 839 0.039 0.067
840 –0.007 0.045 841 0.051 0.008 842 –0.074 –0.109 843 –0.033 0.070
844 –0.028 0.176 845 –0.041 0.045 846 0.014 –0.084 847 0.054 –0.040
848 0.110 –0.020 849 0.014 –0.021 850 0.006 0.139 851 0.008 0.011
852 –0.060 –0.040 853 0.008 0.179 854 0.008 0.020 855 0.044 –0.114
856 0.021 –0.015 857 –0.008 –0.052 858 0.091 –0.109 859 –0.025 –0.040
860 –0.049 0.006 861 –0.043 –0.041 862 –0.178 –0.026 863 –0.073 –0.057
864 0.000 –0.031 865 –0.047 0.077 866 –0.007 –0.002 867 0.050 –0.021
868 0.046 –0.040 869 –0.061 –0.099 870 –0.121 0.008 871 0.014 0.050
872 0.145 0.034 873 0.001 –0.046 874 –0.058 –0.121 875 0.040 0.001
876 –0.029 0.041 877 0.002 –0.066 878 0.015 –0.054 879 0.010 –0.029
880 0.004 –0.059
3341
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.2 Generating encoded DATA bits—LDPC example 1
LDPC example 1 is similar to the BCC example. This example illustrates LDPC shortening, encoding, and
puncturing of a single codeword.
Input TXVECTOR parameters for LDPC example 1:
— FEC_CODING = LDPC_CODING = 1 (LDPC encoder; not BCC)
— CH_BANDWIDTH = HT_CBW20 = 0 (CH_BANDWIDTH = 0 => 20 MHz)
— MCS = 4 (MCS = 4; QAM 16; Coding rate = 3/4)
— Coding rate R = 3/4
— LENGTH = 100 octets (with 16-bit SERVICE field becomes 102 Octets =
816 bits to scramble and encode)
— STBC = 0 (STBC = 0 => OFF; m_STBC=1)
I.2.1 The message for LDPC example 1
The message being encoded consists of the first 72 characters (shown in bold and including line breaks) of
the well-known “Ode to Joy” by F. Schiller:
Joy, bright spark of divinity,
Daughter of Elysium,
Fire-insired we tread
Thy sanctuary.
Thy magic power re-unites
All that custom has divided,
All men become brothers
Under the sway of thy gentle wings.
The message is converted to ASCII; then it is prepended with an appropriate MAC header, and an FCS is
added. The resulting 100 octet PSDU is shown in Table I-31.
NOTE 1—The message for LDPC example 1 is identical to the message for the BCC example; in other words, the FCS
field (octets 97–100) has the same value.
NOTE 2—The DurationID field (i.e., octets 3 and 4) remains 0x02E = 46 µs.
Table I-31—Message for LDPC example 1
Octet ## Value Value Value Value Value
1...5 0x04 0x02 0x00 0x2E 0x00
6...10 0x60 0x08 0xCD 0x37 0xA6
11...15 0x00 0x20 0xD6 0x01 0x3C
16...20 0xF1 0x00 0x60 0x08 0xAD
21...25 0x3B 0xAF 0x00 0x00 0x4A
26...30 0x6F 0x79 0x2C 0x20 0x62
31...35 0x72 0x69 0x67 0x68 0x74
36...40 0x20 0x73 0x70 0x61 0x72
3342
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-31—Message for LDPC example 1 (continued)
Octet ## Value Value Value Value Value
41...45 0x6B 0x20 0x6F 0x66 0x20
46...50 0x64 0x69 0x76 0x69 0x6E
51...55 0x69 0x74 0x79 0x2C 0x0A
56...60 0x44 0x61 0x75 0x67 0x68
61...65 0x74 0x65 0x72 0x20 0x6F
66...70 0x66 0x20 0x45 0x6C 0x79
71...75 0x73 0x69 0x75 0x6D 0x2C
76...80 0x0A 0x46 0x69 0x72 0x65
81...85 0x2D 0x69 0x6E 0x73 0x69
86...90 0x72 0x65 0x64 0x20 0x77
91...95 0x65 0x20 0x74 0x72 0x65
96...100 0x61 0x67 0x33 0x21 0xB6
I.2.2 Prepending the SERVICE field for LDPC example 1
The transmitted message shown in Table I-31 contains 100 octets, or equivalently, 800 bits. The bits are
prepended by the 16 SERVICE field bits (bits 0–15 in Table I-32), as defined in 19.3.11.2, but tail bits and
padding bits are not appended as in the BCC example. The resulting 816 bits are shown in Table I-32.
Table I-32—DATA bits for LDPC example 1 before scrambling
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B7 B0 B15 B8 B23 B16 value value value
000–023 00000000 00000000 00000100 0x00 0x00 0x04
024–047 00000010 00000000 00101110 0x02 0x00 0x2E
048–071 00000000 01100000 00001000 0x00 0x60 0x08
072–095 11001101 00110111 10100110 0xCD 0x37 0xA6
096–119 00000000 00100000 11010110 0x00 0x20 0xD6
120–143 00000001 00111100 11110001 0x01 0x3C 0xF1
144–167 00000000 01100000 00001000 0x00 0x60 0x08
168–191 10101101 00111011 10101111 0xAD 0x3B 0xAF
192–215 00000000 00000000 01001010 0x00 0x00 0x4A
216–239 01101111 01111001 00101100 0x6F 0x79 0x2C
240–263 00100000 01100010 01110010 0x20 0x62 0x72
264–287 01101001 01100111 01101000 0x69 0x67 0x68
3343
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-32—DATA bits for LDPC example 1 before scrambling (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B7 B0 B15 B8 B23 B16 value value value
288–311 01110100 00100000 01110011 0x74 0x20 0x73
312–335 01110000 01100001 01110010 0x70 0x61 0x72
336–359 01101011 00100000 01101111 0x6B 0x20 0x6F
360–383 01100110 00100000 01100100 0x66 0x20 0x64
384–407 01101001 01110110 01101001 0x69 0x76 0x69
408–431 01101110 01101001 01110100 0x6E 0x69 0x74
432–455 01111001 00101100 00001010 0x79 0x2C 0x0A
456–479 01000100 01100001 01110101 0x44 0x61 0x75
480–503 01100111 01101000 01110100 0x67 0x68 0x74
504–527 01100101 01110010 00100000 0x65 0x72 0x20
528–551 01101111 01100110 00100000 0x6F 0x66 0x20
552–575 01000101 01101100 01111001 0x45 0x6C 0x79
576–599 01110011 01101001 01110101 0x73 0x69 0x75
600–623 01101101 00101100 00001010 0x6D 0x2C 0x0A
624–647 01000110 01101001 01110010 0x46 0x69 0x72
648–671 01100101 00101101 01101001 0x65 0x2D 0x69
672–695 01101110 01110011 01101001 0x6E 0x73 0x69
696–719 01110010 01100101 01100100 0x72 0x65 0x64
720–743 00100000 01110111 01100101 0x20 0x77 0x65
744–767 00100000 01110100 01110010 0x20 0x74 0x72
768–791 01100101 01100001 01100111 0x65 0x61 0x67
792–815 00110011 00100001 10110110 0x33 0x21 0xB6
3344
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.2.3 Scrambling LDPC example 1
The 816 bits are scrambled by the scrambler defined in 17.3.5.5. The initial state of the scrambler is the state
1011101 binary (0x5D). The scrambled sequence is given in Table I-33.
NOTE—The scrambled entries for the correct FCS field value are given in bits 784–815.
Table I-33—DATA bits for LDPC example 1 after scrambling
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
000–023 01101100 00011001 10001001 0x6C 0x19 0x89
024–047 10001111 01101000 00100001 0x8F 0x68 0x21
048–071 11110100 10100101 01100001 0xF4 0xA5 0x61
072–095 01001111 11010111 10101110 0x4F 0xD7 0xAE
096–119 00100100 00001100 11110011 0x24 0x0C 0xF3
120–143 00111010 11100100 10111100 0x3A 0xE4 0xBC
144–167 01010011 10011000 11000000 0x53 0x98 0xC0
168–191 00011110 00110101 10110011 0x1E 0x35 0xB3
192–215 11100011 11111000 00100101 0xE3 0xF8 0x25
216–239 01100000 11010110 00100101 0x60 0xD6 0x25
240–263 00110101 00110011 11111110 0x35 0x33 0xFE
264–287 11110000 01000001 00101011 0xF0 0x41 0x2B
288–311 10001111 01010011 00011100 0x8F 0x53 0x1C
312–335 10000011 01000001 10111110 0x83 0x41 0xBE
336–359 00111001 00101000 01100110 0x39 0x28 0x66
360–383 01000100 01100110 11001101 0x44 0x66 0xCD
384–407 11110110 10100011 11011000 0xF6 0xA3 0xD8
408–431 00001101 11010100 10000001 0x0D 0xD4 0x81
432–455 00111011 00101111 11011111 0x3B 0x2F 0xDF
456–479 11000011 01011000 11110111 0xC3 0x58 0xF7
480–503 11000110 01010010 11101011 0xC6 0x52 0xEB
504–527 01110000 10001111 10011110 0x70 0x8F 0x9E
528–551 01101010 10010000 10000001 0x6A 0x90 0x81
552–575 11111101 01111100 10101001 0xFD 0x7C 0xA9
576–599 11010001 01010101 00010010 0xD1 0x55 0x12
600–623 00000100 01110100 11011001 0x04 0x74 0xD9
624–647 11101001 00111011 11001101 0xE9 0x3B 0xCD
648–671 10010011 10001101 01111011 0x93 0x8D 0x7B
3345
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-33—DATA bits for LDPC example 1 after scrambling (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
672–695 01111100 01110000 00000010 0x7C 0x70 0x02
696–719 00100000 10011001 10100001 0x20 0x99 0xA1
720–743 01111101 10001010 00100111 0x7D 0x8A 0x27
744–767 00010111 00111001 00010101 0x17 0x39 0x15
768–791 10100000 11101100 10010101 0xA0 0xEC 0x95
792–815 00010110 10010001 00010000 0x16 0x91 0x10
I.2.4 Inserting shortening bits for LDPC example 1
The equations of 19.3.11.7.5 are solved to calculate the following derived parameters for LDPC example 1
from the input TXVECTOR parameters:
— NCW = 1 (number of codewords)
— LLDPC = 1944 (size of codeword)
— NCBPS = 208 (number of coded bits per symbol)
— Navbits = 1248 (number of available bits)
— Nshrt = 642 (number of bits to be shortened)
— Npunc = 54 (number of bits to be punctured)
— NSYM = 6 (number of OFDM symbols)
— Nrep = 0 (number of bits to be repeated)
The results of applying shortening bits, as prescribed in paragraph (c) of 19.3.11.7.5, is given in Table I-34.
NOTE—Nshrt = 642 shortening bits have been inserted as 0s in bits 816–1457.
Table I-34—DATA bits for LDPC example 1 after insertion
of shortening bits
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0000–0023 01101100 00011001 10001001 0x6C 0x19 0x89
0024–0047 10001111 01101000 00100001 0x8F 0x68 0x21
0048–0071 11110100 10100101 01100001 0xF4 0xA5 0x61
0072–0095 01001111 11010111 10101110 0x4F 0xD7 0xAE
0096–0119 00100100 00001100 11110011 0x24 0x0C 0xF3
0120–0143 00111010 11100100 10111100 0x3A 0xE4 0xBC
0144–0167 01010011 10011000 11000000 0x53 0x98 0xC0
0168–0191 00011110 00110101 10110011 0x1E 0x35 0xB3
0192–0215 11100011 11111000 00100101 0xE3 0xF8 0x25
3346
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-34—DATA bits for LDPC example 1 after insertion
of shortening bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0216–0239 01100000 11010110 00100101 0x60 0xD6 0x25
0240–0263 00110101 00110011 11111110 0x35 0x33 0xFE
0264–0287 11110000 01000001 00101011 0xF0 0x41 0x2B
0288–0311 10001111 01010011 00011100 0x8F 0x53 0x1C
0312–0335 10000011 01000001 10111110 0x83 0x41 0xBE
0336–0359 00111001 00101000 01100110 0x39 0x28 0x66
0360–0383 01000100 01100110 11001101 0x44 0x66 0xCD
0384–0407 11110110 10100011 11011000 0xF6 0xA3 0xD8
0408–0431 00001101 11010100 10000001 0x0D 0xD4 0x81
0432–0455 00111011 00101111 11011111 0x3B 0x2F 0xDF
0456–0479 11000011 01011000 11110111 0xC3 0x58 0xF7
0480–0503 11000110 01010010 11101011 0xC6 0x52 0xEB
0504–0527 01110000 10001111 10011110 0x70 0x8F 0x9E
0528–0551 01101010 10010000 10000001 0x6A 0x90 0x81
0552–0575 11111101 01111100 10101001 0xFD 0x7C 0xA9
0576–0599 11010001 01010101 00010010 0xD1 0x55 0x12
0600–0623 00000100 01110100 11011001 0x04 0x74 0xD9
0624–0647 11101001 00111011 11001101 0xE9 0x3B 0xCD
0648–0671 10010011 10001101 01111011 0x93 0x8D 0x7B
0672–0695 01111100 01110000 00000010 0x7C 0x70 0x02
0696–0719 00100000 10011001 10100001 0x20 0x99 0xA1
0720–0743 01111101 10001010 00100111 0x7D 0x8A 0x27
0744–0767 00010111 00111001 00010101 0x17 0x39 0x15
0768–0791 10100000 11101100 10010101 0xA0 0xEC 0x95
0792–0815 00010110 10010001 00010000 0x16 0x91 0x10
0816–0839 00000000 00000000 00000000 0x00 0x00 0x00
0840–0863 00000000 00000000 00000000 0x00 0x00 0x00
0864–0887 00000000 00000000 00000000 0x00 0x00 0x00
0888–0911 00000000 00000000 00000000 0x00 0x00 0x00
0912–0935 00000000 00000000 00000000 0x00 0x00 0x00
0936–0959 00000000 00000000 00000000 0x00 0x00 0x00
0960–0983 00000000 00000000 00000000 0x00 0x00 0x00
3347
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-34—DATA bits for LDPC example 1 after insertion
of shortening bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0984–1007 00000000 00000000 00000000 0x00 0x00 0x00
1008–1031 00000000 00000000 00000000 0x00 0x00 0x00
1032–1055 00000000 00000000 00000000 0x00 0x00 0x00
1056–1079 00000000 00000000 00000000 0x00 0x00 0x00
1080–1103 00000000 00000000 00000000 0x00 0x00 0x00
1104–1127 00000000 00000000 00000000 0x00 0x00 0x00
1128–1151 00000000 00000000 00000000 0x00 0x00 0x00
1152–1175 00000000 00000000 00000000 0x00 0x00 0x00
1176–1199 00000000 00000000 00000000 0x00 0x00 0x00
1200–1223 00000000 00000000 00000000 0x00 0x00 0x00
1224–1247 00000000 00000000 00000000 0x00 0x00 0x00
1248–1271 00000000 00000000 00000000 0x00 0x00 0x00
1272–1295 00000000 00000000 00000000 0x00 0x00 0x00
1296–1319 00000000 00000000 00000000 0x00 0x00 0x00
1320–1343 00000000 00000000 00000000 0x00 0x00 0x00
1344–1367 00000000 00000000 00000000 0x00 0x00 0x00
1368–1391 00000000 00000000 00000000 0x00 0x00 0x00
1392–1415 00000000 00000000 00000000 0x00 0x00 0x00
1416–1439 00000000 00000000 00000000 0x00 0x00 0x00
1440–1457 00000000 00000000 00 - - - - - - 0x00 0x00 0x0-
I.2.5 Encoding data for LDPC example 1
The DATA with shortening bits are LDPC encoded as a single (NCW =1) codeword (LLDPC =944; R=3/4) as
prescribed by paragraph (c) of 19.3.11.7.5. The results are given in Table I-35.
NOTE—The LDPC encoder appends 486 bits (i.e., bits 1458–1943) after the shortening bits.
Table I-35—DATA bits for LDPC example 1 after LDPC encoding
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0000–0023 01101100 00011001 10001001 0x6C 0x19 0x89
0024–0047 10001111 01101000 00100001 0x8F 0x68 0x21
0048–0071 11110100 10100101 01100001 0xF4 0xA5 0x61
3348
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-35—DATA bits for LDPC example 1 after LDPC encoding (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0072–0095 01001111 11010111 10101110 0x4F 0xD7 0xAE
0096–0119 00100100 00001100 11110011 0x24 0x0C 0xF3
0120–0143 00111010 11100100 10111100 0x3A 0xE4 0xBC
0144–0167 01010011 10011000 11000000 0x53 0x98 0xC0
0168–0191 00011110 00110101 10110011 0x1E 0x35 0xB3
0192–0215 11100011 11111000 00100101 0xE3 0xF8 0x25
0216–0239 01100000 11010110 00100101 0x60 0xD6 0x25
0240–0263 00110101 00110011 11111110 0x35 0x33 0xFE
0264–0287 11110000 01000001 00101011 0xF0 0x41 0x2B
0288–0311 10001111 01010011 00011100 0x8F 0x53 0x1C
0312–0335 10000011 01000001 10111110 0x83 0x41 0xBE
0336–0359 00111001 00101000 01100110 0x39 0x28 0x66
0360–0383 01000100 01100110 11001101 0x44 0x66 0xCD
0384–0407 11110110 10100011 11011000 0xF6 0xA3 0xD8
0408–0431 00001101 11010100 10000001 0x0D 0xD4 0x81
0432–0455 00111011 00101111 11011111 0x3B 0x2F 0xDF
0456–0479 11000011 01011000 11110111 0xC3 0x58 0xF7
0480–0503 11000110 01010010 11101011 0xC6 0x52 0xEB
0504–0527 01110000 10001111 10011110 0x70 0x8F 0x9E
0528–0551 01101010 10010000 10000001 0x6A 0x90 0x81
0552–0575 11111101 01111100 10101001 0xFD 0x7C 0xA9
0576–0599 11010001 01010101 00010010 0xD1 0x55 0x12
0600–0623 00000100 01110100 11011001 0x04 0x74 0xD9
0624–0647 11101001 00111011 11001101 0xE9 0x3B 0xCD
0648–0671 10010011 10001101 01111011 0x93 0x8D 0x7B
0672–0695 01111100 01110000 00000010 0x7C 0x70 0x02
0696–0719 00100000 10011001 10100001 0x20 0x99 0xA1
0720–0743 01111101 10001010 00100111 0x7D 0x8A 0x27
0744–0767 00010111 00111001 00010101 0x17 0x39 0x15
0768–0791 10100000 11101100 10010101 0xA0 0xEC 0x95
0792–0815 00010110 10010001 00010000 0x16 0x91 0x10
0816–0839 00000000 00000000 00000000 0x00 0x00 0x00
0840–0863 00000000 00000000 00000000 0x00 0x00 0x00
3349
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-35—DATA bits for LDPC example 1 after LDPC encoding (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0864–0887 00000000 00000000 00000000 0x00 0x00 0x00
0888–0911 00000000 00000000 00000000 0x00 0x00 0x00
0912–0935 00000000 00000000 00000000 0x00 0x00 0x00
0936–0959 00000000 00000000 00000000 0x00 0x00 0x00
0960–0983 00000000 00000000 00000000 0x00 0x00 0x00
0984–1007 00000000 00000000 00000000 0x00 0x00 0x00
1008–1031 00000000 00000000 00000000 0x00 0x00 0x00
1032–1055 00000000 00000000 00000000 0x00 0x00 0x00
1056–1079 00000000 00000000 00000000 0x00 0x00 0x00
1080–1103 00000000 00000000 00000000 0x00 0x00 0x00
1104–1127 00000000 00000000 00000000 0x00 0x00 0x00
1128–1151 00000000 00000000 00000000 0x00 0x00 0x00
1152–1175 00000000 00000000 00000000 0x00 0x00 0x00
1176–1199 00000000 00000000 00000000 0x00 0x00 0x00
1200–1223 00000000 00000000 00000000 0x00 0x00 0x00
1224–1247 00000000 00000000 00000000 0x00 0x00 0x00
1248–1271 00000000 00000000 00000000 0x00 0x00 0x00
1272–1295 00000000 00000000 00000000 0x00 0x00 0x00
1296–1319 00000000 00000000 00000000 0x00 0x00 0x00
1320–1343 00000000 00000000 00000000 0x00 0x00 0x00
1344–1367 00000000 00000000 00000000 0x00 0x00 0x00
1368–1391 00000000 00000000 00000000 0x00 0x00 0x00
1392–1415 00000000 00000000 00000000 0x00 0x00 0x00
1416–1439 00000000 00000000 00000000 0x00 0x00 0x00
1440–1463 00000000 00000000 00100110 0x00 0x00 0x26
1464–1487 00111101 10101001 10011100 0x3D 0xA9 0x9C
1488–1511 01000000 11010111 10110010 0x40 0xD7 0xB2
1512–1535 10000110 11100011 10111111 0x86 0xE3 0xBF
1536–1559 01000011 10100101 11011001 0x43 0xA5 0xD9
1560–1583 00001101 00000110 11010110 0x0D 0x06 0xD6
1584–1607 01100000 11110100 00011111 0x60 0xF4 0x1F
1608–1631 00110001 00001100 00010011 0x31 0x0C 0x13
1632–1655 01110110 00001111 10011111 0x76 0x0F 0x9F
3350
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-35—DATA bits for LDPC example 1 after LDPC encoding (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
1656–1679 11011010 10011111 10101001 0xDA 0x9F 0xA9
1680–1703 01110100 01011001 11011100 0x74 0x59 0xDC
1704–1727 10001001 11110010 11100010 0x89 0xF2 0xE2
1728–1751 11011000 01101000 10100001 0xD8 0x68 0xA1
1752–1775 01100011 00011101 10100101 0x63 0x1D 0xA5
1776–1799 10100110 10000000 11010001 0xA6 0x80 0xD1
1800–1823 10001001 01010111 11011100 0x89 0x57 0xDC
1824–1847 10110011 01011101 00110011 0xB3 0x5D 0x33
1848–1871 01110000 11011100 10110010 0x70 0xDC 0xB2
1872–1895 11110110 00111001 00111101 0xF6 0x39 0x3D
1896–1919 00100011 10011011 00110110 0x23 0x9B 0x36
1920–1943 00111110 00010101 00010001 0x3E 0x15 0x11
I.2.6 Removing shortening bits and puncturing for LDPC example 1
The shortening bits, applied before LDPC encoding, are now removed as prescribed in paragraph (c) of
19.3.11.7.5. Finally, either puncturing is applied as described in paragraph (d) of the same subclause, or the
copying of repeated bits is applied as described in paragraph (e) of the same subclause. In LDPC example 1,
because Npunc = 54 is nonzero and Nrep = 0, puncturing is prescribed and completes the LDPC encoding
process.
The results are given in Table I-36.
NOTE—The Nshrt = 642 shortening bits have been removed, and the Npunc = 54 bits have been punctured from
Table I-35 to produce bits 816–1247 of Table I-36.
Table I-36—DATA bits after puncturing and removal of shortening bits
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0000–0023 01101100 00011001 10001001 0x6C 0x19 0x89
0024–0047 10001111 01101000 00100001 0x8F 0x68 0x21
0048–0071 11110100 10100101 01100001 0xF4 0xA5 0x61
0072–0095 01001111 11010111 10101110 0x4F 0xD7 0xAE
0096–0119 00100100 00001100 11110011 0x24 0x0C 0xF3
0120–0143 00111010 11100100 10111100 0x3A 0xE4 0xBC
0144–0167 01010011 10011000 11000000 0x53 0x98 0xC0
0168–0191 00011110 00110101 10110011 0x1E 0x35 0xB3
3351
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-36—DATA bits after puncturing and removal of shortening bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0192–0215 11100011 11111000 00100101 0xE3 0xF8 0x25
0216–0239 01100000 11010110 00100101 0x60 0xD6 0x25
0240–0263 00110101 00110011 11111110 0x35 0x33 0xFE
0264–0287 11110000 01000001 00101011 0xF0 0x41 0x2B
0288–0311 10001111 01010011 00011100 0x8F 0x53 0x1C
0312–0335 10000011 01000001 10111110 0x83 0x41 0xBE
0336–0359 00111001 00101000 01100110 0x39 0x28 0x66
0360–0383 01000100 01100110 11001101 0x44 0x66 0xCD
0384–0407 11110110 10100011 11011000 0xF6 0xA3 0xD8
0408–0431 00001101 11010100 10000001 0x0D 0xD4 0x81
0432–0455 00111011 00101111 11011111 0x3B 0x2F 0xDF
0456–0479 11000011 01011000 11110111 0xC3 0x58 0xF7
0480–0503 11000110 01010010 11101011 0xC6 0x52 0xEB
0504–0527 01110000 10001111 10011110 0x70 0x8F 0x9E
0528–0551 01101010 10010000 10000001 0x6A 0x90 0x81
0552–0575 11111101 01111100 10101001 0xFD 0x7C 0xA9
0576–0599 11010001 01010101 00010010 0xD1 0x55 0x12
0600–0623 00000100 01110100 11011001 0x04 0x74 0xD9
0624–0647 11101001 00111011 11001101 0xE9 0x3B 0xCD
0648–0671 10010011 10001101 01111011 0x93 0x8D 0x7B
0672–0695 01111100 01110000 00000010 0x7C 0x70 0x02
0696–0719 00100000 10011001 10100001 0x20 0x99 0xA1
0720–0743 01111101 10001010 00100111 0x7D 0x8A 0x27
0744–0767 00010111 00111001 00010101 0x17 0x39 0x15
0768–0791 10100000 11101100 10010101 0xA0 0xEC 0x95
0792–0815 00010110 10010001 00010000 0x16 0x91 0x10
0816–0839 10011000 11110110 10100110 0x98 0xF6 0xA6
0840–0863 01110001 00000011 01011110 0x71 0x03 0x5E
0864–0887 11001010 00011011 10001110 0xCA 0x1B 0x8E
0888–0911 11111101 00001110 10010111 0xFD 0x0E 0x97
0912–0935 01100100 00110100 00011011 0x64 0x34 0x1B
0936–0959 01011001 10000011 11010000 0x59 0x83 0xD0
0960–0983 01111100 11000100 00110000 0x7C 0xC4 0x30
3352
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-36—DATA bits after puncturing and removal of shortening bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0984–1007 01001101 11011000 00111110 0x4D 0xD8 0x3E
1008–1031 01111111 01101010 01111110 0x7F 0x6A 0x7E
1032–1055 10100101 11010001 01100111 0xA5 0xD1 0x67
1056–1079 01110010 00100111 11001011 0x72 0x27 0xCB
1080–1103 10001011 01100001 10100010 0x8B 0x61 0xA2
1104–1127 10000101 10001100 01110110 0x85 0x8C 0x76
1128–1151 10010110 10011010 00000011 0x96 0x9A 0x03
1152–1175 01000110 00100101 01011111 0x46 0x25 0x5F
1176–1199 01110010 11001101 01110100 0x72 0xCD 0x74
1200–1223 11001101 11000011 01110010 0xCD 0xC3 0x72
1224–1247 11001011 11011000 11100100 0xCB 0xD8 0xE4
I.3 Generating encoded DATA bits—LDPC example 2
LDPC example 2 exercises the alternative branches of the LDPC encoding procedure not exercised in LDPC
example 1. Example 2 also exhibits LDPC shortening, encoding, and padding by repetition and employs
multiple codewords and diversifies the TXVECTOR parameters—all without making the length of this
example cumbersome.
The length of the text of the message is increased by 40 octets, from 72 characters to 112 characters, in order
to illustrate padding (rather than puncturing) and encoding of multiple codewords.
Input TXVECTOR parameters for LDPC example 2:
— FEC_CODING = LDPC_CODING = 1 (LDPC encoder; not BCC)
— CH_BANDWIDTH = HT_CBW40 = 1 (CH_BANDWIDTH = 1 => 40 MHz)
— MCS = 1 (MCS = 1; QPSK; coding rate = 1/2)
— Coding rate R = 1/2
— LENGTH = 140 octets (with 16-bit SERVICE field becomes 142 octets =
1136 bits to scramble and encode)
— STBC = 1 (STBC = 1 => ON; m_STBC = 2)
I.3.1 The message for LDPC example 2
The message being encoded consists of the first 112 characters (shown in bold and including line breaks) of
the well-known “Ode to Joy” by F. Schiller:
Joy, bright spark of divinity,
Daughter of Elysium,
Fire-insired we tread
Thy sanctuary.
3353
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Thy magic power re-unites
All that custom has divided,
All men become brothers
Under the sway of thy gentle wings.
The message is converted to ASCII; then it is prepended with an appropriate MAC header and an FCS is
added. The resulting 140 octet PSDU is shown in Table I-37.
Because of the additional 40 characters, note that the message for LDPC example 2 has a different FCS field
(octets 137–140) than the previous examples and that the DurationID field (i.e., octets 3 and 4) changes to
0x036 = 54 µs.
Table I-37—Message for LDPC example 2
Octet ## Value Value Value Value Value
1...5 0x04 0x02 0x00 0x36 0x00
6...10 0x60 0x08 0xCD 0x37 0xA6
11...15 0x00 0x20 0xD6 0x01 0x3C
16...20 0xF1 0x00 0x60 0x08 0xAD
21...25 0x3B 0xAF 0x00 0x00 0x4A
26...30 0x6F 0x79 0x2C 0x20 0x62
31...35 0x72 0x69 0x67 0x68 0x74
36...40 0x20 0x73 0x70 0x61 0x72
41...45 0x6B 0x20 0x6F 0x66 0x20
46...50 0x64 0x69 0x76 0x69 0x6E
51...55 0x69 0x74 0x79 0x2C 0x0A
56...60 0x44 0x61 0x75 0x67 0x68
61...65 0x74 0x65 0x72 0x20 0x6F
66...70 0x66 0x20 0x45 0x6C 0x79
71...75 0x73 0x69 0x75 0x6D 0x2C
76...80 0x0A 0x46 0x69 0x72 0x65
81...85 0x2D 0x69 0x6E 0x73 0x69
86...90 0x72 0x65 0x64 0x20 0x77
91...95 0x65 0x20 0x74 0x72 0x65
96...100 0x61 0x64 0x0A 0x54 0x68
101...105 0x79 0x20 0x73 0x61 0x6E
106...110 0x63 0x74 0x75 0x61 0x72
111...115 0x79 0x2E 0x0A 0x54 0x68
116...120 0x79 0x20 0x6D 0x61 0x67
121...125 0x69 0x63 0x20 0x70 0x6F
3354
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-37—Message for LDPC example 2 (continued)
Octet ## Value Value Value Value Value
126...130 0x77 0x65 0x72 0x20 0x72
131...135 0x65 0x2D 0x75 0x6E 0x69
136...140 0x74 0x3B 0xDB 0xB5 0x22
I.3.2 Prepending the SERVICE field for LDPC example 2
The transmitted message shown in Table I-37 contains 140 octets, or equivalently, 1120 bits. The bits are
prepended by the 16 SERVICE field bits (bits 0–15 in Table I-38), as defined by 19.3.11.2, but tail bits and
padding bits are not appended as in the BCC example. The resulting 1136 bits are shown in Table I-38.
Table I-38—DATA bits for LDPC example 2 before scrambling
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B7 B0 B15 B8 B23 B16 value value value
0000–0023 00000000 00000000 00000100 0x00 0x00 0x04
0024–0047 00000010 00000000 00110110 0x02 0x00 0x36
0048–0071 00000000 01100000 00001000 0x00 0x60 0x08
0072–0095 11001101 00110111 10100110 0xCD 0x37 0xA6
0096–0119 00000000 00100000 11010110 0x00 0x20 0xD6
0120–0143 00000001 00111100 11110001 0x01 0x3C 0xF1
0144–0167 00000000 01100000 00001000 0x00 0x60 0x08
0168–0191 10101101 00111011 10101111 0xAD 0x3B 0xAF
0192–0215 00000000 00000000 01001010 0x00 0x00 0x4A
0216–0239 01101111 01111001 00101100 0x6F 0x79 0x2C
0240–0263 00100000 01100010 01110010 0x20 0x62 0x72
0264–0287 01101001 01100111 01101000 0x69 0x67 0x68
0288–0311 01110100 00100000 01110011 0x74 0x20 0x73
0312–0335 01110000 01100001 01110010 0x70 0x61 0x72
0336–0359 01101011 00100000 01101111 0x6B 0x20 0x6F
0360–0383 01100110 00100000 01100100 0x66 0x20 0x64
0384–0407 01101001 01110110 01101001 0x69 0x76 0x69
0408–0431 01101110 01101001 01110100 0x6E 0x69 0x74
0432–0455 01111001 00101100 00001010 0x79 0x2C 0x0A
0456–0479 01000100 01100001 01110101 0x44 0x61 0x75
0480–0503 01100111 01101000 01110100 0x67 0x68 0x74
3355
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-38—DATA bits for LDPC example 2 before scrambling
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B7 B0 B15 B8 B23 B16 value value value
0504–0527 01100101 01110010 00100000 0x65 0x72 0x20
0528–0551 01101111 01100110 00100000 0x6F 0x66 0x20
0552–0575 01000101 01101100 01111001 0x45 0x6C 0x79
0576–0599 01110011 01101001 01110101 0x73 0x69 0x75
0600–0623 01101101 00101100 00001010 0x6D 0x2C 0x0A
0624–0647 01000110 01101001 01110010 0x46 0x69 0x72
0648–0671 01100101 00101101 01101001 0x65 0x2D 0x69
0672–0695 01101110 01110011 01101001 0x6E 0x73 0x69
0696–0719 01110010 01100101 01100100 0x72 0x65 0x64
0720–0743 00100000 01110111 01100101 0x20 0x77 0x65
0744–0767 00100000 01110100 01110010 0x20 0x74 0x72
0768–0791 01100101 01100001 01100100 0x65 0x61 0x64
0792–0815 00001010 01010100 01101000 0x0A 0x54 0x68
0816–0839 01111001 00100000 01110011 0x79 0x20 0x73
0840–0863 01100001 01101110 01100011 0x61 0x6E 0x63
0864–0887 01110100 01110101 01100001 0x74 0x75 0x61
0888–0911 01110010 01111001 00101110 0x72 0x79 0x2E
0912–0935 00001010 01010100 01101000 0x0A 0x54 0x68
0936–0959 01111001 00100000 01101101 0x79 0x20 0x6D
0960–0983 01100001 01100111 01101001 0x61 0x67 0x69
0984–1007 01100011 00100000 01110000 0x63 0x20 0x70
1008–1031 01101111 01110111 01100101 0x6F 0x77 0x65
1032–1055 01110010 00100000 01110010 0x72 0x20 0x72
1056–1079 01100101 00101101 01110101 0x65 0x2D 0x75
1080–1103 01101110 01101001 01110100 0x6E 0x69 0x74
1104–1127 00111011 11011011 10110101 0x3B 0xDB 0xB5
1128–1135 00100010 -------- -------- 0x22 ---- ----
3356
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.3.3 Scrambling LDPC example 2
The 1136 bits are scrambled by the scrambler defined in 17.3.5.5. The initial state of the scrambler is the
state 1011101 binary (0x5D). The scrambled sequence is given in Table I-39.
Table I-39—DATA bits for LDPC example 2 after scrambling
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0000–0023 01101100 00011001 10001001 0x6C 0x19 0x89
0024–0047 10001111 01101000 00111001 0x8F 0x68 0x39
0048–0071 11110100 10100101 01100001 0xF4 0xA5 0x61
0072–0095 01001111 11010111 10101110 0x4F 0xD7 0xAE
0096–0119 00100100 00001100 11110011 0x24 0x0C 0xF3
0120–0143 00111010 11100100 10111100 0x3A 0xE4 0xBC
0144–0167 01010011 10011000 11000000 0x53 0x98 0xC0
0168–0191 00011110 00110101 10110011 0x1E 0x35 0xB3
0192–0215 11100011 11111000 00100101 0xE3 0xF8 0x25
0216–0239 01100000 11010110 00100101 0x60 0xD6 0x25
0240–0263 00110101 00110011 11111110 0x35 0x33 0xFE
0264–0287 11110000 01000001 00101011 0xF0 0x41 0x2B
0288–0311 10001111 01010011 00011100 0x8F 0x53 0x1C
0312–0335 10000011 01000001 10111110 0x83 0x41 0xBE
0336–0359 00111001 00101000 01100110 0x39 0x28 0x66
0360–0383 01000100 01100110 11001101 0x44 0x66 0xCD
0384–0407 11110110 10100011 11011000 0xF6 0xA3 0xD8
0408–0431 00001101 11010100 10000001 0x0D 0xD4 0x81
0432–0455 00111011 00101111 11011111 0x3B 0x2F 0xDF
0456–0479 11000011 01011000 11110111 0xC3 0x58 0xF7
0480–0503 11000110 01010010 11101011 0xC6 0x52 0xEB
0504–0527 01110000 10001111 10011110 0x70 0x8F 0x9E
0528–0551 01101010 10010000 10000001 0x6A 0x90 0x81
0552–0575 11111101 01111100 10101001 0xFD 0x7C 0xA9
0576–0599 11010001 01010101 00010010 0xD1 0x55 0x12
0600–0623 00000100 01110100 11011001 0x04 0x74 0xD9
0624–0647 11101001 00111011 11001101 0xE9 0x3B 0xCD
0648–0671 10010011 10001101 01111011 0x93 0x8D 0x7B
0672–0695 01111100 01110000 00000010 0x7C 0x70 0x02
3357
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-39—DATA bits for LDPC example 2 after scrambling
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0696–0719 00100000 10011001 10100001 0x20 0x99 0xA1
0720–0743 01111101 10001010 00100111 0x7D 0x8A 0x27
0744–0767 00010111 00111001 00010101 0x17 0x39 0x15
0768–0791 10100000 11101100 01010101 0xA0 0xEC 0x55
0792–0815 10001010 00111111 01101011 0x8A 0x3F 0x6B
0816–0839 10110110 11011000 10110001 0xB6 0xD8 0xB1
0840–0863 10001000 10000100 00001111 0x88 0x84 0x0F
0864–0887 00101100 10001000 10101000 0x2C 0x88 0xA8
0888–0911 11111000 10010010 10100000 0xF8 0x92 0xA0
0912–0935 10110111 10011110 00111100 0xB7 0x9E 0x3C
0936–0959 01100100 01010101 00001110 0x64 0x55 0x0E
0960–0983 01111000 11111011 01110011 0x78 0xFB 0x73
0984–1007 01010100 00000000 01000010 0x54 0x00 0x42
1008–1031 10101011 10000010 10111111 0xAB 0x82 0xBF
1032–1055 11100111 11001011 00100110 0xE7 0xCB 0x26
1056–1079 11110011 01000000 00001101 0xF3 0x40 0x0D
1080–1103 00000111 01101010 00010101 0x07 0x6A 0x15
1104–1127 00010111 11111111 10100101 0x17 0xFF 0xA5
1128–1135 11011100 -------- -------- 0xDC ---- ----
I.3.4 Inserting the shortening bits for LDPC example 2
The equations of 19.3.11.7.5 are solved to calculate the following derived parameters for LDPC example 2
from the input TXVECTOR parameters:
— NCW = 2 (number of codewords)
— LLDPC = 1296 (size of codeword)
— NCBPS = 216 (number of coded bits per symbol)
— Navbits = 2592 (number of available bits)
— Nshrt = 160 (number of bits to be shortened)
— Npunc = 0 (number of bits to be punctured)
— NSYM = 12 (number of OFDM symbols)
— Nrep = 160 (number of bits to be repeated)
3358
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The results of applying shortening bits, as prescribed in paragraph (c) of 19.3.11.7.5, is given in Table I-40.
NOTE—Nshrt = 160 shortening bits have been inserted as 0s: 80 0s at bits 568–647 and 80 0s at bits 1216–1295; this
order equally distributes the shortening bits across the NCW = 2 codewords.
Table I-40—DATA bits for LDPC example 2 after insertion
of shortening bits
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0000–0023 01101100 00011001 10001001 0x6C 0x19 0x89
0024–0047 10001111 01101000 00111001 0x8F 0x68 0x39
0048–0071 11110100 10100101 01100001 0xF4 0xA5 0x61
0072–0095 01001111 11010111 10101110 0x4F 0xD7 0xAE
0096–0119 00100100 00001100 11110011 0x24 0x0C 0xF3
0120–0143 00111010 11100100 10111100 0x3A 0xE4 0xBC
0144–0167 01010011 10011000 11000000 0x53 0x98 0xC0
0168–0191 00011110 00110101 10110011 0x1E 0x35 0xB3
0192–0215 11100011 11111000 00100101 0xE3 0xF8 0x25
0216–0239 01100000 11010110 00100101 0x60 0xD6 0x25
0240–0263 00110101 00110011 11111110 0x35 0x33 0xFE
0264–0287 11110000 01000001 00101011 0xF0 0x41 0x2B
0288–0311 10001111 01010011 00011100 0x8F 0x53 0x1C
0312–0335 10000011 01000001 10111110 0x83 0x41 0xBE
0336–0359 00111001 00101000 01100110 0x39 0x28 0x66
0360–0383 01000100 01100110 11001101 0x44 0x66 0xCD
0384–0407 11110110 10100011 11011000 0xF6 0xA3 0xD8
0408–0431 00001101 11010100 10000001 0x0D 0xD4 0x81
0432–0455 00111011 00101111 11011111 0x3B 0x2F 0xDF
0456–0479 11000011 01011000 11110111 0xC3 0x58 0xF7
0480–0503 11000110 01010010 11101011 0xC6 0x52 0xEB
0504–0527 01110000 10001111 10011110 0x70 0x8F 0x9E
0528–0551 01101010 10010000 10000001 0x6A 0x90 0x81
0552–0575 11111101 01111100 00000000 0xFD 0x7C 0x00
0576–0599 00000000 00000000 00000000 0x00 0x00 0x00
0600–0623 00000000 00000000 00000000 0x00 0x00 0x00
0624–0647 00000000 00000000 00000000 0x00 0x00 0x00
0648–0671 10101001 11010001 01010101 0xA9 0xD1 0x55
0672–0695 00010010 00000100 01110100 0x12 0x04 0x74
3359
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-40—DATA bits for LDPC example 2 after insertion
of shortening bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0696–0719 11011001 11101001 00111011 0xD9 0xE9 0x3B
0720–0743 11001101 10010011 10001101 0xCD 0x93 0x8D
0744–0767 01111011 01111100 01110000 0x7B 0x7C 0x70
0768–0791 00000010 00100000 10011001 0x02 0x20 0x99
0792–0815 10100001 01111101 10001010 0xA1 0x7D 0x8A
0816–0839 00100111 00010111 00111001 0x27 0x17 0x39
0840–0863 00010101 10100000 11101100 0x15 0xA0 0xEC
0864–0887 01010101 10001010 00111111 0x55 0x8A 0x3F
0888–0911 01101011 10110110 11011000 0x6B 0xB6 0xD8
0912–0935 10110001 10001000 10000100 0xB1 0x88 0x84
0936–0959 00001111 00101100 10001000 0x0F 0x2C 0x88
0960–0983 10101000 11111000 10010010 0xA8 0xF8 0x92
0984–1007 10100000 10110111 10011110 0xA0 0xB7 0x9E
1008–1031 00111100 01100100 01010101 0x3C 0x64 0x55
1032–1055 00001110 01111000 11111011 0x0E 0x78 0xFB
1056–1079 01110011 01010100 00000000 0x73 0x54 0x00
1080–1103 01000010 10101011 10000010 0x42 0xAB 0x82
1104–1127 10111111 11100111 11001011 0xBF 0xE7 0xCB
1128–1151 00100110 11110011 01000000 0x26 0xF3 0x40
1152–1175 00001101 00000111 01101010 0x0D 0x07 0x6A
1176–1199 00010101 00010111 11111111 0x15 0x17 0xFF
1200–1223 10100101 11011100 00000000 0xA5 0xDC 0x00
1224–1247 00000000 00000000 00000000 0x00 0x00 0x00
1248–1271 00000000 00000000 00000000 0x00 0x00 0x00
1272–1295 00000000 00000000 00000000 0x00 0x00 0x00
I.3.5 Encoding the data for LDPC example 2
The DATA with shortening bits are LDPC encoded as two (NCW = 2) codewords (LLDPC = 1296; R = 1/2) as
prescribed by paragraph (c) of 19.3.11.7.5. The results are given in Table I-41.
NOTE—The LDPC encoder appends 648 bits as follows: bits 648–1295 after the first shortened codeword and another
648 bits (bits 1944–2591) after the second shortened codeword.
3360
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-41—DATA bits for LDPC example 2 after LDPC encoding
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0000–0023 01101100 00011001 10001001 0x6C 0x19 0x89
0024–0047 10001111 01101000 00111001 0x8F 0x68 0x39
0048–0071 11110100 10100101 01100001 0xF4 0xA5 0x61
0072–0095 01001111 11010111 10101110 0x4F 0xD7 0xAE
0096–0119 00100100 00001100 11110011 0x24 0x0C 0xF3
0120–0143 00111010 11100100 10111100 0x3A 0xE4 0xBC
0144–0167 01010011 10011000 11000000 0x53 0x98 0xC0
0168–0191 00011110 00110101 10110011 0x1E 0x35 0xB3
0192–0215 11100011 11111000 00100101 0xE3 0xF8 0x25
0216–0239 01100000 11010110 00100101 0x60 0xD6 0x25
0240–0263 00110101 00110011 11111110 0x35 0x33 0xFE
0264–0287 11110000 01000001 00101011 0xF0 0x41 0x2B
0288–0311 10001111 01010011 00011100 0x8F 0x53 0x1C
0312–0335 10000011 01000001 10111110 0x83 0x41 0xBE
0336–0359 00111001 00101000 01100110 0x39 0x28 0x66
0360–0383 01000100 01100110 11001101 0x44 0x66 0xCD
0384–0407 11110110 10100011 11011000 0xF6 0xA3 0xD8
0408–0431 00001101 11010100 10000001 0x0D 0xD4 0x81
0432–0455 00111011 00101111 11011111 0x3B 0x2F 0xDF
0456–0479 11000011 01011000 11110111 0xC3 0x58 0xF7
0480–0503 11000110 01010010 11101011 0xC6 0x52 0xEB
0504–0527 01110000 10001111 10011110 0x70 0x8F 0x9E
0528–0551 01101010 10010000 10000001 0x6A 0x90 0x81
0552–0575 11111101 01111100 00000000 0xFD 0x7C 0x00
0576–0599 00000000 00000000 00000000 0x00 0x00 0x00
0600–0623 00000000 00000000 00000000 0x00 0x00 0x00
0624–0647 00000000 00000000 00000000 0x00 0x00 0x00
0648–0671 00001001 11000001 11111011 0x09 0xC1 0xFB
0672–0695 01101000 11001101 00000101 0x68 0xCD 0x05
0696–0719 10110110 11000111 01100101 0xB6 0xC7 0x65
0720–0743 10100101 10011001 11100000 0xA5 0x99 0xE0
0744–0767 01110011 01110000 01101101 0x73 0x70 0x6D
0768–0791 01011110 01111001 11100011 0x5E 0x79 0xE3
3361
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-41—DATA bits for LDPC example 2 after LDPC encoding (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0792–0815 01100111 00100111 01011110 0x67 0x27 0x5E
0816–0839 10010101 10101000 11110110 0x95 0xA8 0xF6
0840–0863 00110101 01001000 10100111 0x35 0x48 0xA7
0864–0887 00100110 00101001 00110001 0x26 0x29 0x31
0888–0911 00101110 00011001 11110100 0x2E 0x19 0xF4
0912–0935 00110100 01101111 01010000 0x34 0x6F 0x50
0936–0959 01010000 11101001 11000100 0x50 0xE9 0xC4
0960–0983 00000110 11011001 11101110 0x06 0xD9 0xEE
0984–1007 11111000 00011011 11011001 0xF8 0x1B 0xD9
1008–1031 01101100 10000110 11010011 0x6C 0x86 0xD3
1032–1055 11101001 01100100 11001000 0xE9 0x64 0xC8
1056–1079 11110001 10100001 00001011 0xF1 0xA1 0x0B
1080–1103 11000010 01000100 01010100 0xC2 0x44 0x54
1104–1127 10100000 10001100 10111011 0xA0 0x8C 0xBB
1128–1151 10100011 11100100 10101001 0xA3 0xE4 0xA9
1152–1175 10101011 01010000 11100010 0xAB 0x50 0xE2
1176–1199 01110000 00101000 00110110 0x70 0x28 0x36
1200–1223 11111100 00110000 00110100 0xFC 0x30 0x34
1224–1247 01101010 01001001 00100010 0x6A 0x49 0x22
1248–1271 11010101 00000111 11001111 0xD5 0x07 0xCF
1272–1295 00110101 00111010 10001110 0x35 0x3A 0x8E
1296–1319 10101001 11010001 01010101 0xA9 0xD1 0x55
1320–1343 00010010 00000100 01110100 0x12 0x04 0x74
1344–1367 11011001 11101001 00111011 0xD9 0xE9 0x3B
1368–1391 11001101 10010011 10001101 0xCD 0x93 0x8D
1392–1415 01111011 01111100 01110000 0x7B 0x7C 0x70
1416–1439 00000010 00100000 10011001 0x02 0x20 0x99
1440–1463 10100001 01111101 10001010 0xA1 0x7D 0x8A
1464–1487 00100111 00010111 00111001 0x27 0x17 0x39
1488–1511 00010101 10100000 11101100 0x15 0xA0 0xEC
1512–1535 01010101 10001010 00111111 0x55 0x8A 0x3F
1536–1559 01101011 10110110 11011000 0x6B 0xB6 0xD8
1560–1583 10110001 10001000 10000100 0xB1 0x88 0x84
3362
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-41—DATA bits for LDPC example 2 after LDPC encoding (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
1584–1607 00001111 00101100 10001000 0x0F 0x2C 0x88
1608–1631 10101000 11111000 10010010 0xA8 0xF8 0x92
1632–1655 10100000 10110111 10011110 0xA0 0xB7 0x9E
1656–1679 00111100 01100100 01010101 0x3C 0x64 0x55
1680–1703 00001110 01111000 11111011 0x0E 0x78 0xFB
1704–1727 01110011 01010100 00000000 0x73 0x54 0x00
1728–1751 01000010 10101011 10000010 0x42 0xAB 0x82
1752–1775 10111111 11100111 11001011 0xBF 0xE7 0xCB
1776–1799 00100110 11110011 01000000 0x26 0xF3 0x40
1800–1823 00001101 00000111 01101010 0x0D 0x07 0x6A
1824–1847 00010101 00010111 11111111 0x15 0x17 0xFF
1848–1871 10100101 11011100 00000000 0xA5 0xDC 0x00
1872–1895 00000000 00000000 00000000 0x00 0x00 0x00
1896–1919 00000000 00000000 00000000 0x00 0x00 0x00
1920–1943 00000000 00000000 00000000 0x00 0x00 0x00
1944–1967 01100100 10110110 01010100 0x64 0xB6 0x54
1968–1991 00110001 00000001 01100001 0x31 0x01 0x61
1992–2015 00101001 00010011 01110000 0x29 0x13 0x70
2016–2039 01010000 10000000 11001110 0x50 0x80 0xCE
2040–2063 01000101 11000000 10101000 0x45 0xC0 0xA8
2064–2087 11001101 11111000 01111100 0xCD 0xF8 0x7C
2088–2111 01010011 01010001 01001110 0x53 0x51 0x4E
2112–2135 11010011 10101110 00010011 0xD3 0xAE 0x13
2136–2159 11110000 11101101 10111111 0xF0 0xED 0xBF
2160–2183 10001110 10010100 00110100 0x8E 0x94 0x34
2184–2207 11111011 00010000 11011001 0xFB 0x10 0xD9
2208–2231 10111110 00110001 10011111 0xBE 0x31 0x9F
2232–2255 01100000 00011100 10100110 0x60 0x1C 0xA6
2256–2279 01010101 11111001 10100110 0x55 0xF9 0xA6
2280–2303 10101010 00111000 01110001 0xAA 0x38 0x71
2304–2327 01111010 10101100 10110010 0x7A 0xAC 0xB2
2328–2351 11110101 11010001 10000001 0xF5 0xD1 0x81
2352–2375 01010000 11110001 00001011 0x50 0xF1 0x0B
3363
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-41—DATA bits for LDPC example 2 after LDPC encoding (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
2376–2399 10111101 10010011 10001011 0xBD 0x93 0x8B
2400–2423 10100010 10010110 00100101 0xA2 0x96 0x25
2424–2447 11100011 01101100 11000111 0xE3 0x6C 0xC7
2448–2471 00000101 00011000 00101000 0x05 0x18 0x28
2472–2495 11110011 00111001 11011000 0xF3 0x39 0xD8
2496–2519 00010001 01110101 00010111 0x11 0x75 0x17
2520–2543 11011101 11111011 11010010 0xDD 0xFB 0xD2
2544–2567 10101010 11101011 10100110 0xAA 0xEB 0xA6
2568–2591 10000101 10110011 01011000 0x85 0xB3 0x58
I.3.6 Removing shortening bits and repetition for LDPC example 2
The shortening bits, applied before LDPC encoding, are now removed as prescribed in paragraph (c) of
19.3.11.7.5. Finally, either puncturing is applied as described in paragraph (d) of the same subclause, or the
copying of repeated bits is applied as described in paragraph (e) of the same subclause. In LDPC example 2,
because Npunc = 0 and Nrep = 160 are nonzero, repetition is prescribed and completes the LDPC encoding
process.
The results are given in Table I-42.
NOTE—The first 80 shortening bits (bits 568–647 from Table I-41) have been removed from the first codeword
between bits 567 and 568 of Table I-42, and the second 80 shortening bits (bits 1864–1943 of Table I-41) have been
removed between bits 1215 and 1216 of Table I-42. Also, 80 bits have been repeated from the beginning of the first
codeword (bits 0–79) to the end of the first codeword (bits 1216–1295), and 80 bits have been repeated from the
beginning of the second codeword (bits 1296–1375) to end of the second codeword (bits 2512–2591) in Table I-42.
Table I-42—DATA bits after removal of shortening bits and
copying of repetition bits
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0000–0023 01101100 00011001 10001001 0x6C 0x19 0x89
0024–0047 10001111 01101000 00111001 0x8F 0x68 0x39
0048–0071 11110100 10100101 01100001 0xF4 0xA5 0x61
0072–0095 01001111 11010111 10101110 0x4F 0xD7 0xAE
0096–0119 00100100 00001100 11110011 0x24 0x0C 0xF3
0120–0143 00111010 11100100 10111100 0x3A 0xE4 0xBC
0144–0167 01010011 10011000 11000000 0x53 0x98 0xC0
0168–0191 00011110 00110101 10110011 0x1E 0x35 0xB3
3364
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-42—DATA bits after removal of shortening bits and
copying of repetition bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0192–0215 11100011 11111000 00100101 0xE3 0xF8 0x25
0216–0239 01100000 11010110 00100101 0x60 0xD6 0x25
0240–0263 00110101 00110011 11111110 0x35 0x33 0xFE
0264–0287 11110000 01000001 00101011 0xF0 0x41 0x2B
0288–0311 10001111 01010011 00011100 0x8F 0x53 0x1C
0312–0335 10000011 01000001 10111110 0x83 0x41 0xBE
0336–0359 00111001 00101000 01100110 0x39 0x28 0x66
0360–0383 01000100 01100110 11001101 0x44 0x66 0xCD
0384–0407 11110110 10100011 11011000 0xF6 0xA3 0xD8
0408–0431 00001101 11010100 10000001 0x0D 0xD4 0x81
0432–0455 00111011 00101111 11011111 0x3B 0x2F 0xDF
0456–0479 11000011 01011000 11110111 0xC3 0x58 0xF7
0480–0503 11000110 01010010 11101011 0xC6 0x52 0xEB
0504–0527 01110000 10001111 10011110 0x70 0x8F 0x9E
0528–0551 01101010 10010000 10000001 0x6A 0x90 0x81
0552–0575 11111101 01111100 00001001 0xFD 0x7C 0x09
0576–0599 11000001 11111011 01101000 0xC1 0xFB 0x68
0600–0623 11001101 00000101 10110110 0xCD 0x05 0xB6
0624–0647 11000111 01100101 10100101 0xC7 0x65 0xA5
0648–0671 10011001 11100000 01110011 0x99 0xE0 0x73
0672–0695 01110000 01101101 01011110 0x70 0x6D 0x5E
0696–0719 01111001 11100011 01100111 0x79 0xE3 0x67
0720–0743 00100111 01011110 10010101 0x27 0x5E 0x95
0744–0767 10101000 11110110 00110101 0xA8 0xF6 0x35
0768–0791 01001000 10100111 00100110 0x48 0xA7 0x26
0792–0815 00101001 00110001 00101110 0x29 0x31 0x2E
0816–0839 00011001 11110100 00110100 0x19 0xF4 0x34
0840–0863 01101111 01010000 01010000 0x6F 0x50 0x50
0864–0887 11101001 11000100 00000110 0xE9 0xC4 0x06
0888–0911 11011001 11101110 11111000 0xD9 0xEE 0xF8
0912–0935 00011011 11011001 01101100 0x1B 0xD9 0x6C
0936–0959 10000110 11010011 11101001 0x86 0xD3 0xE9
3365
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-42—DATA bits after removal of shortening bits and
copying of repetition bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
0960–0983 01100100 11001000 11110001 0x64 0xC8 0xF1
0984–1007 10100001 00001011 11000010 0xA1 0x0B 0xC2
1008–1031 01000100 01010100 10100000 0x44 0x54 0xA0
1032–1055 10001100 10111011 10100011 0x8C 0xBB 0xA3
1056–1079 11100100 10101001 10101011 0xE4 0xA9 0xAB
1080–1103 01010000 11100010 01110000 0x50 0xE2 0x70
1104–1127 00101000 00110110 11111100 0x28 0x36 0xFC
1128–1151 00110000 00110100 01101010 0x30 0x34 0x6A
1152–1175 01001001 00100010 11010101 0x49 0x22 0xD5
1176–1199 00000111 11001111 00110101 0x07 0xCF 0x35
1200–1223 00111010 10001110 01101100 0x3A 0x8E 0x6C
1224–1247 00011001 10001001 10001111 0x19 0x89 0x8F
1248–1271 01101000 00111001 11110100 0x68 0x39 0xF4
1272–1295 10100101 01100001 01001111 0xA5 0x61 0x4F
1296–1319 10101001 11010001 01010101 0xA9 0xD1 0x55
1320–1343 00010010 00000100 01110100 0x12 0x04 0x74
1344–1367 11011001 11101001 00111011 0xD9 0xE9 0x3B
1368–1391 11001101 10010011 10001101 0xCD 0x93 0x8D
1392–1415 01111011 01111100 01110000 0x7B 0x7C 0x70
1416–1439 00000010 00100000 10011001 0x02 0x20 0x99
1440–1463 10100001 01111101 10001010 0xA1 0x7D 0x8A
1464–1487 00100111 00010111 00111001 0x27 0x17 0x39
1488–1511 00010101 10100000 11101100 0x15 0xA0 0xEC
1512–1535 01010101 10001010 00111111 0x55 0x8A 0x3F
1536–1559 01101011 10110110 11011000 0x6B 0xB6 0xD8
1560–1583 10110001 10001000 10000100 0xB1 0x88 0x84
1584–1607 00001111 00101100 10001000 0x0F 0x2C 0x88
1608–1631 10101000 11111000 10010010 0xA8 0xF8 0x92
1632–1655 10100000 10110111 10011110 0xA0 0xB7 0x9E
1656–1679 00111100 01100100 01010101 0x3C 0x64 0x55
1680–1703 00001110 01111000 11111011 0x0E 0x78 0xFB
1704–1727 01110011 01010100 00000000 0x73 0x54 0x00
3366
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-42—DATA bits after removal of shortening bits and
copying of repetition bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
1728–1751 01000010 10101011 10000010 0x42 0xAB 0x82
1752–1775 10111111 11100111 11001011 0xBF 0xE7 0xCB
1776–1799 00100110 11110011 01000000 0x26 0xF3 0x40
1800–1823 00001101 00000111 01101010 0x0D 0x07 0x6A
1824–1847 00010101 00010111 11111111 0x15 0x17 0xFF
1848–1871 10100101 11011100 01100100 0xA5 0xDC 0x64
1872–1895 10110110 01010100 00110001 0xB6 0x54 0x31
1896–1919 00000001 01100001 00101001 0x01 0x61 0x29
1920–1943 00010011 01110000 01010000 0x13 0x70 0x50
1944–1967 10000000 11001110 01000101 0x80 0xCE 0x45
1968–1991 11000000 10101000 11001101 0xC0 0xA8 0xCD
1992–2015 11111000 01111100 01010011 0xF8 0x7C 0x53
2016–2039 01010001 01001110 11010011 0x51 0x4E 0xD3
2040–2063 10101110 00010011 11110000 0xAE 0x13 0xF0
2064–2087 11101101 10111111 10001110 0xED 0xBF 0x8E
2088–2111 10010100 00110100 11111011 0x94 0x34 0xFB
2112–2135 00010000 11011001 10111110 0x10 0xD9 0xBE
2136–2159 00110001 10011111 01100000 0x31 0x9F 0x60
2160–2183 00011100 10100110 01010101 0x1C 0xA6 0x55
2184–2207 11111001 10100110 10101010 0xF9 0xA6 0xAA
2208–2231 00111000 01110001 01111010 0x38 0x71 0x7A
2232–2255 10101100 10110010 11110101 0xAC 0xB2 0xF5
2256–2279 11010001 10000001 01010000 0xD1 0x81 0x50
2280–2303 11110001 00001011 10111101 0xF1 0x0B 0xBD
2304–2327 10010011 10001011 10100010 0x93 0x8B 0xA2
2328–2351 10010110 00100101 11100011 0x96 0x25 0xE3
2352–2375 01101100 11000111 00000101 0x6C 0xC7 0x05
2376–2399 00011000 00101000 11110011 0x18 0x28 0xF3
2400–2423 00111001 11011000 00010001 0x39 0xD8 0x11
2424–2447 01110101 00010111 11011101 0x75 0x17 0xDD
2448–2471 11111011 11010010 10101010 0xFB 0xD2 0xAA
2472–2495 11101011 10100110 10000101 0xEB 0xA6 0x85
3367
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-42—DATA bits after removal of shortening bits and
copying of repetition bits (continued)
Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal
Bit ##
B0 B7 B8 B15 B16 B23 value value value
2496–2519 10110011 01011000 10101001 0xB3 0x58 0xA9
2520–2543 11010001 01010101 00010010 0xD1 0x55 0x12
2544–2567 00000100 01110100 11011001 0x04 0x74 0xD9
2568–2591 11101001 00111011 11001101 0xE9 0x3B 0xCD
I.4 DMG example data vectors
Subclauses I.5 to I.8 contain example data vectors for the DMG PHY (see Clause 20).
For each described node, there is a cross-reference in this annex that is of the form
Reference:
where the named file is one of the text files contained in the DMGEncodingExamples.zip file embedded in
the IEEE 802.11 Working Group document 11-12/0751r0, located at https://mentor.ieee.org/802.11/dcn/12/
11-12-0751-00-00ad-dmg-encoding-examples.docx).
Depending on the node being illustrated, the text file might represent bit data, symbol data, or sample data:
— For bit data, the text file contains a time ordered sequence of 1 and 0 characters, separated by spaces
and without any carriage control characters.
— For symbol data, the text file contains a time ordered sequence of signed integers, separated by
spaces and without any carriage control characters.
— For sample data, the text file contains a time ordered sequence of complex values, formatted as
±±j, separated by spaces and without any carriage control characters.
When referencing specific bits, symbols, or samples in the files, they are considered to be numbered starting
from 1.
This formatting of the text files has been chosen to facilitate import into other tools. For example, the files
can be read using the MATLAB dlmread('filename') command.
For DMG control mode, SC mode and low-power (LP) SC mode modulation samples, no spectrum shaping
has been applied to the data because the implementation of spectrum shaping is not defined in this standard.
For DMG OFDM mode modulation samples, no symbol shaping has been applied to the data because the
implementation of OFDM symbol shaping is not defined in this standard.
I.5 DMG Example 1 – DMG control mode encoding
I.5.1 DMG control mode preamble
The DMG control mode preamble Short Training field (STF) and Channel Estimation field (CEF) are each
constructed from a concatenation of real valued bipolar Golay sequences that is π/2-BPSK modulated, as
shown in Figure I-1.
3368
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure I-1—DMG control mode preamble expressed in Ga128 and Gb128 sequences
The DMG control mode preamble is 7552 samples long.
Reference: CPHY_Preamble Samples.txt
I.5.2 Control mode header
The DMG control mode header coding and modulation are shown in Figure I-2.
I.5.2.1 DMG control mode header and payload bits
Figure I-2 node . The 5 octets of header data followed by the payload data. The first 6 octets of the data
payload are used to complete the construction of the single LDPC codeword of the DMG control mode
header. For this example, the DMG control mode header bit fields are set as listed in Table I-43.
Table I-43—DMG control mode header settings
Field Value
Scrambler Initialization 2
Length 120
Packet Type 0
Training Length 0
Turnaround 0
Reserved bits 0
The data payload octets are provided by a count, modulo 256, starting at 0. The resulting header and payload
sequence is 1000 bits long, of which the first 88 bits are encoded in the header modulation block. For this
example, with a payload of 120 octets, LDPFCW = 88, LDPCW = 152 and LDPLCW = 152.
These numbers illustrate that the payload is not simply packed 168 bits at a time into the LDPC encoding,
with the last few bits (modulo 168) in the last packet getting disproportionate coding gain. The specified
calculation spreads the excess coding gain evenly across all of the packets, so the number of payload bits in
each packet varies between approximately 120 and the maximum 168.
Reference: Bits 1 to 88 of the file CPHY_Header and Payload bits.txt
3369
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Preamble Header Payload
8192 /2-DBPSK symbols 5
32x spreading
with Ga32
and /2 rotation
256 Diff encoded bits 4
Differential
encoder
data parity 3
Strip zeros
data parity
¾ Rate LDPC
data Pad zeros to 504 bits
LDPFCW= 11 octets (88 bits)
LHDR= 5 octets (40 bits) LFDCW = 6 octets (48 bits)
0 init scrambled header scrambled data payload 2
scrambler
1 4 10 bits 1 5 bits 1 2 16 bits data payload 1
Reserved (diff detect or init)
Initialization
Scrambler
Length
Packet type
Training Length
Turnaround
Reserved bits
HCS
Figure I-2—DMG control mode header coding and modulation
I.5.2.2 DMG control mode scrambled header and payload bits
Figure I-2 node . The 5 header plus 6 data = 11 octets after scrambling.
Reference: Bits 1 to 88 of the file CPHY_Scrambled Header and Payload bits.txt
I.5.2.3 DMG control mode LDPC encoded header bits
Figure I-2 node . In this example there are 7 LDPC codewords. The number of bits produced by the first
codeword after zero stripping is 88 + 168 = 256, and the number of bits produced by each of the remaining 6
codewords is 152 + 168 = 320. The total number of bits after LDPC encoding is 256 + 6 x 320 = 2176, of
which the first 256 bits correspond to the LDPC encoded header.
Reference: Bits 1 to 256 of the file CPHY_LDPC Encoded Header and Payload bits.txt
3370
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.5.2.4 DMG control mode differentially encoded header symbols
Figure I-2 node . The 256 LDPC encoded header bits are differentially encoded.
Reference: Symbols 1 to 256 of the file CPHY_Diff Encoded Header and Payload symbols.txt
I.5.2.5 DMG control mode header samples
Figure I-2 node . The 256 differentially encoded bipolar symbol values are spread using the Ga32 Golay
sequence, then /2 rotated to produce 8192 chips at Fc = 1760 MHz.
Reference: Samples 1 to 8192 of the file CPHY_Header and Payload samples.txt
I.5.3 DMG control mode payload
The DMG control mode payload coding and modulation are shown in Figure I-3.
Header Payload
5
32x spreading 32x spreading
with Ga32 with Ga32
and /2 rotation and /2 rotation
Diff encoded bits Diff encoded bits 4
Differential Differential
encoder encoder
data parity data parity 3
Strip zeros Strip zeros
data parity data parity
¾ Rate LDPC ¾ Rate LDPC
data Pad zeros to 504 bits data Pad zeros to 504 bits
LDPCW = ~120...168 bits LDPLCW = ~120...168 bits
last packet scrambled data
middle packets scrambled data payload payload 2
scrambler scrambler
payload 1
Figure I-3—DMG control mode payload coding and modulation
I.5.3.1 DMG control mode payload bits
Figure I-3 node .
Reference: Bits 89 to 1000 of the file CPHY_Header and Payload bits.txt
3371
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.5.3.2 DMG control mode scrambled payload bits
Figure I-3 node .
Reference: Bits 89 to 1000 of the file CPHY_Scrambled Header and Payload bits.txt
I.5.3.3 DMG control mode LDPC encoded payload bits
Figure I-3 node .
Reference: Bits 257 to 2176 of the file CPHY_LDPC Encoded Header and Payload bits.txt
I.5.3.4 DMG control mode differentially encoded payload symbols
Figure I-3 node .
Reference: Symbols 257 to 2176 of the file CPHY_Diff Encoded Header and Data symbols.txt
I.5.3.5 DMG control mode payload samples
Figure I-3 node .
In this example, the 320 differentially encoded bipolar symbol values from each of the 6 payload bearing
LDPC codewords, including the last one, gives a total of 6 x 320 = 1920 symbols which are then spread
using the Ga32 Golay sequence and /2 rotated to produce 61 440 chips at Fc = 1.76 GHz.
Reference: Samples 8193 to 69 632 of the file CPHY_Header and Payload samples.txt
I.6 DMG Example 2 – DMG SC mode encoding
I.6.1 DMG SC mode preamble
The DMG SC mode preamble Short Training field (STF) and Channel Estimation field (CEF) are each
constructed from a concatenation of real valued bipolar Golay sequences that is π/2-BPSK modulated, as
shown in Figure I-4.
Figure I-4—DMG SC mode preamble expressed in Ga128 and Gb128 sequences
The preamble is 3328 samples long.
Reference: SCPHY_Preamble Samples.txt
3372
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.6.2 DMG SC mode header
The DMG SC mode header coding and modulation are shown in Figure I-5.
6
Preamble Header Payload
GI 448 x /2-BPSK symbols GI 448 x /2-BPSK symbols
/2 rotation
Guard interval is always BPSK GI 448 x BPSK symbols GI 448 x BPSK symbols
x -1
448 x BPSK mapped symbols
448 bits BPSK mapping
cs1 cs2 5
XOR with
No change
PN Sequence
64 bits parity 64 bits parity 4
64 bits 504 – 64 = 440 padding zeros parity 3
¾ LDPC
64 bits 504 – 64 = 440 padding zeros
scram. init. scrambled header 2
scrambler
7 bits 5 bits 18 bits 11 5 bits 1 1 4 bits 1 4 bits 16 bits 1
Initialization
Scrambler
MCS
Length
Additional PPDU
Packet type
Training Length
Aggregation
Beam Tracking Request
RSSI
Last
Turnaround
Reserved
HCS
Figure I-5—DMG SC mode header coding and modulation
3373
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.6.2.1 DMG SC control header bits
Figure I-5 node . The 8 octets of header data. For this example, the control SC mode header bit fields are
set as listed in Table I-44.
Table I-44—DMG SC control header settings
Field Value
Scrambler Initialization 66
MCS 2
Length 1000
Additional PPDU 0
Packet Type 0
Training Length 0
Aggregation 0
Beam Tracking Request 0
Last RSSI 0
Turnaround 0
Reserved bits 0
Reference: SCPHY_MCS2_Header bits.txt
I.6.2.2 DMG SC mode scrambled header bits
Figure I-5 node . The header bits after scrambling bits 8 to 64 of the header using the seed 66 (0x42).
Reference: SCPHY_MCS2_Scrambled Header bits.txt
I.6.2.3 DMG SC mode LDPC encoded header bits
Figure I-5 node . The scrambled header data after LDPC encoding but prior to zero stripping.
Reference: SCPHY_MCS2_LDPC Encoded Header bits.txt
3374
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.6.2.4 DMG SC mode LDPC data shortened bits
Figure I-5 node . The dimension of DMG SC mode modulation blocks requires that the CS1 and CS2
sequences are each 224 bits long; this in turn requires that, in addition to the zeros, some of the parity bits are
discarded in order to shorten the LDPC codewords to 224 bits.
The data for the second shortened LDPC codeword is given as they are before they are scrambled to provide
CS2.
Reference: SCPHY_MCS2_Shortened LDPC for CS1 bits.txt
Reference: SCPHY_MCS2_Shortened LDPC for CS2 bits.txt
I.6.2.5 DMG SC mode CS1/CS2 sequence bits
Figure I-5 node . The 448 bit concatenated CS1/CS2 sequence including the PN scrambling of CS2.
Reference: SCPHY_MCS2_Final CS1 CS2 Sequence bits.txt
I.6.2.6 DMG SC mode header samples
Figure I-5 node . The fully modulated signal after BPSK mapping, duplication (with negation), guard
interval addition and π/2 rotation are applied.
The 448 header bits are BPSK mapped to 448 modulation symbols and increased to 512 symbols by the
addition of a 64 symbol guard interval. A second, negated, copy of the 448 modulation symbols is also
increased to 512 symbols by the addition of a 64 symbol guard interval. The two 512 symbol blocks are
concatenated and π/2 rotated to create 1024 samples.
Reference: SCPHY_MCS2_Header Samples.txt
I.6.3 DMG SC mode payload
The DMG SC mode payload coding and modulation are shown in Figure I-6 (for MCS1) and Figure I-7 (for
MCS2–MCS12).
3375
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Data
5
GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI
/2 rotation /2 rotation /2 rotation /2 rotation /2 rotation
GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI
NCBPB bits 4
BPSK mapping BPSK mapping BPSK mapping BPSK mapping BPSK mapping
scrambled zeros (scrambler
state continues from payload)
No change scrambler
LCWD parity LCWD parity LCWD parity LCWD parity LCWD parity NBLK_PAD zeros
NCW x LCW
bits
LCW = 672
672 bits 672 bits
bits
LZ data LZ scrambled parity LZ data LZ scrambled parity LZ data LZ scrambled parity
PN pattern PN pattern PN pattern
Discarded 672 bits Discarded 672 bits Discarded 672 bits
LZ data LZ zeros parity LZ data LZ zeros parity LZ data LZ zeros parity 3
(1/2) LDPC (1/2) LDPC (1/2) LDPC
LZ data LZ zeros LZ data LZ zeros LZ data LZ zeros
m=1 m=2 m = NCW
LZ chunk LZ chunk LZ chunk
of scrambled of scrambled of scrambled
data data data
scrambled data (scrambler state continues from header) 2
LCW LCW 1 LCW
LZ R
2 2 4 scrambler
For MCS1 only = 2, R = 1/2
PPDU Data (PSDU) NDATA_PAD zeros 1
Figure I-6—DMG SC mode MCS1 payload coding and modulation
3376
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Data
4
GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI
/2 rotation /2 rotation /2 rotation /2 rotation /2 rotation
GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI
NCBPB BPSK, QPSK BPSK, QPSK BPSK, QPSK BPSK, QPSK BPSK, QPSK
bits or QAM16 or QAM16 or QAM16 or QAM16 or QAM16 3
mapping mapping mapping mapping mapping
scrambled zeros (scrambler
state continues from payload)
No change scrambler
LCWD parity LCWD parity LCWD parity LCWD parity LCWD parity NBLK_PAD zeros
NCW x LCW bits
LCW = 672 bits 672 bits 672 bits
LCWD parity LCWD parity LCWD parity
(R) LDPC (R) LDPC (R) LDPC
m=1 m=2 m = NCW
LCWD = (R) x LCW LCWD = (R) x LCW LCWD = (R) x LCW
LCWD- sized chunk LCWD- sized chunk LCWD- sized chunk
scrambled data (scrambler state continues from header) 2
LCW LCW
LCWD R R LCW R
1 scrambler
= 1, R = set by MCS
PPDU Data (PSDU) NDATA_PAD zeros 1
Figure I-7—DMG SC mode MCS2—MCS12 payload coding and modulation
I.6.3.1 DMG SC mode MCS1 payload
I.6.3.1.1 Payload bits
Figure I-6 node . The payload at node is a count, modulo 256, starting at 0.
For MCS1 each rate 1/2 LDPC codeword encodes 168 bits (with = 2 repetition) so the payload padding
calculation gives NCW = 48 and NDATA_PAD = 64.
There are 1000 × 8 = 8000 payload bits plus 64 padding bits giving a total of 8 064 bits.
Reference: SCPHY_MCS1_Payload bits.txt
I.6.3.1.2 Scrambled payload bits
Figure I-6 node . All 8 064 bits are scrambled according to a scrambler initialization value of 66.
Reference: SCPHY_MCS1_Scrambled Payload bits.txt
3377
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.6.3.1.3 Rate 1/2 LDPC encoded bits before scrambled duplication
Figure I-6 node . The rate 1/2 LDPC encoding of each block of Lz = 168 scrambled payload bits plus Lz =
168 padding zero bits. In this example, the 8064 actual payload bits are doubled, by repetition, to an
effective payload of 16 128 bits, then doubled again to 32 256 bits by LDPC encoding.
This node, unique to MCS1, is the raw LDPC encoded payload bits before scrambled duplication.
Reference: SCPHY_MCS1_LDPC Encoder Output bits.txt
I.6.3.1.4 Rate 1/2 LDPC encoded bits after scrambled duplication
Figure I-6 node . The LDPC codewords after the Lz = 168 zeros have been replaced by the Lz = 168 re-
scrambled data octets. The data at this node also includes the appended NBLK_PAD scrambled zeros;
however, in this example, NBLK_PAD = 0, so there are still 32 256 bits.
Each 448 bits in the reference file is the NCBPB = 448 bits required to build a modulation block of the MCS1
payload.
Reference: SCPHY_MCS1_LDPC Encoded Payload Bits.txt
I.6.3.1.5 Payload samples
Figure I-6 node . The modulated signal after BPSK mapping, guard interval addition and /2 rotation has
been applied.
In this example, the 32 256 encoded bits are divided into 72 × 448 bit blocks. BPSK mapping converts this
to 72 × 448 modulation symbols which the guard interval increases to 72 × 512 modulation symbols. When
the closing 64-symbol guard interval is added, it results in a total of 72 × 512 + 64 = 36 928 payload
samples.
Reference: SCPHY_MCS1_Payload Samples.txt
I.6.3.2 DMG SC mode MCS5 payload
I.6.3.2.1 Payload bits
Figure I-7 node . The payload at node is a count, modulo 256, starting at 0.
For MCS5 each rate 13/16 LDPC codeword encodes 546 bits so the payload padding calculation gives
NCW = 15 and NDATA_PAD = 190.
There are 1000 × 8 = 8000 payload bits plus 190 padding bits giving a total of 8 190 bits.
Reference: SCPHY_MCS5_Payload bits.txt
I.6.3.2.2 Scrambled payload bits
Figure I-7 node . All 8 190 bits are scrambled according to a scrambler initialization value of 66.
Reference: SCPHY_MCS5_Scrambled Payload bits.txt
3378
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.6.3.2.3 Rate 13/16 LDPC encoded payload bits
Figure I-6 node . The rate 13/16 LDPC encoding of each block of LCWD = 546 scrambled payload bits. In
this example, the 8 190 payload bits are increased to 10 080 bits by the LDPC encoding.
The data at this node also includes the appended NBLK_PAD scrambled zeros. In this example,
NBLK_PAD = 224, so the total number of bits is 10 080 + 224 = 10 304.
Reference: SCPHY_MCS5_LDPC Encoded Payload Bits.txt
I.6.3.2.4 Payload samples
Figure I-7 node . The modulated signal after BPSK mapping, guard interval addition and /2 rotation has
been applied.
In this example, the 10 304 encoded bits are divided into 23 × 448 bit blocks. BPSK mapping converts this
to 23 × 448 modulation symbols which the guard interval increases to 23 × 512 modulation symbols. When
the closing 64-symbol guard interval is added, it results in a total of 23 × 512 + 64 = 11 840 payload
samples.
Reference: SCPHY_MCS5_Payload Samples.txt
I.6.3.3 DMG SC mode MCS7 payload
I.6.3.3.1 Payload bits
Figure I-7 node . The payload at node is a count, modulo 256, starting at 0.
For MCS7 each rate 5/8 LDPC codeword encodes 420 bits so the payload padding calculation gives
NCW = 20 and NDATA_PAD = 400.
There are 1000 × 8 = 8000 payload bits plus 400 padding bits giving a total of 8 400 bits.
Reference: SCPHY_MCS7_Payload bits.txt
I.6.3.3.2 Scrambled payload bits
Figure I-6 node . All 8 400 bits are scrambled according to a scrambler initialization value of 66.
Reference: SCPHY_MCS7_Scrambled Payload bits.txt
I.6.3.3.3 Rate 5/8 LDPC encoded payload bits
Figure I-7 node . The rate 5/8 LDPC encoding of each block of LCWD = 420 scrambled payload bits. In
this example, the 8 400 payload bits are increased to 13 440 bits by the LDPC encoding.
The data at this node also includes the appended NBLK_PAD scrambled zeros. In this example, NBLK_PAD = 0,
so there are still a total of 13 440 bits.
Reference: SCPHY_MCS7_LDPC Encoded Payload Bits.txt
3379
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.6.3.3.4 Payload samples
Figure I-7 node . The modulated signal after QPSK mapping, guard interval addition and /2 rotation has
been applied.
In this example, the 13 440 encoded bits are divided into 15 × 896 bit blocks. QPSK mapping converts this
to 15 × 448 modulation symbols which the guard interval increases to 15 × 512 modulation symbols. When
the closing 64-symbol guard interval is added, it results in a total of 15 × 512 + 64 = 7 744 payload samples.
Reference: SCPHY_MCS7_Payload Samples.txt
I.6.3.4 DMG SC mode MCS12 payload
I.6.3.4.1 Payload bits
Figure I-7 node . The payload at node is a count, modulo 256, starting at 0.
For MCS12 each rate 3/4 LDPC codeword encodes 504 bits so the payload padding calculation gives
NCW = 16 and NDATA_PAD = 64.
There are 1000 × 8 = 8000 payload bits plus 64 padding bits giving a total of 8 064 bits.
Reference: SCPHY_MCS12_Payload bits.txt
I.6.3.4.2 Scrambled payload bits
Figure I-7 node . All 8 064 bits are scrambled according to a scrambler initialization value of 66.
Reference: SCPHY_MCS12_Scrambled Payload bits.txt
I.6.3.4.3 Rate 3/4 LDPC encoded payload bits
Figure I-7 node . The rate 3/4 LDPC encoding of each block of LCWD = 504 scrambled payload bits. In
this example, the 8 064 payload bits are increased to 10 752 bits by the LDPC encoding.
The data at this node also includes the appended NBLK_PAD scrambled zeros. In this example, NBLK_PAD = 0,
so there are still a total of 10 752 bits.
Reference: SCPHY_MCS12_LDPC Encoded Payload Bits.txt
I.6.3.4.4 Payload samples
Figure I-7 node . The modulated signal after 16-QAM mapping, guard interval addition and /2 rotation
has been applied.
In this example, the 10 752 encoded bits are divided into 6 × 1 792 bit blocks. 16-QAM mapping converts
this to 6 × 448 modulation symbols which the guard interval increases to 6 × 512 modulation symbols.
When the closing 64-symbol guard interval is added, it results in a total of 6 × 512 + 64 = 3 136 payload
samples.
Reference: SCPHY_MCS12_Payload Samples.txt
3380
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.7 DMG Example 3 – DMG OFDM mode encoding
I.7.1 DMG OFDM mode preamble
Figure I-8 illustrates that the DMG OFDM mode preamble is similar to the DMG SC mode preamble, but
with the Gu512 and Gv512 parts of the CEF reversed. It is also resampled from 1.76 GSa/s to 2.64 GSa/s
using the specified process of interpolation, resampling, and decimation.
Figure I-8—DMG OFDM mode preamble
Thus the DMG OFDM mode preamble sample count increases from 3 328 to 4 992.
Reference: OFDMPHY_Preamble Samples.txt
I.7.2 DMG OFDM mode header
The DMG OFDM mode header coding is shown in Figure I-9.
I.7.2.1 DMG OFDM mode header bits
Figure I-9 node . The 8 octets of header data.
For this example, the DMG OFDM mode header bit fields are set as listed in Table I-45.
Reference: OFDMPHY_MCS13_Header bits.txt
3381
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NCBPS bits = 672 bits
cs1 cs2 cs3 5
XOR with XOR with
No change
PN Sequence PN Sequence
64 bits parity 64 bits parity 64 bits parity 4
64 bits 504 – 64 = 440 padding zeros parity 3
¾ LDPC
64 bits 504 – 64 = 440 padding zeros
scram. init. scrambled header 2
scrambler
7 bits 5 bits 18 bits 11 5 bits 1 1 1 1 4 bits 1 2 16 bits 1
Initialization
Scrambler
MCS
Length
Additional PPDU
Packet type
Training Length
Aggregation
Beam Tracking Request
Tone Pairing Type
DTP Indicator
Last RSSI
Turnaround
Reserved
HCS
Figure I-9—DMG OFDM mode header coding
Table I-45—DMG OFDM mode header settings
Field Value
Scrambler Initialization 66
MCS 13
Length 1000
Additional PPDU 0
Packet Type 0
Training Length 0
Aggregation 0
Beam Tracking Request 0
Tone Pairing Type 0
3382
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table I-45—DMG OFDM mode header settings (continued)
Field Value
DTP Indicator 0
Last RSSI 0
Turnaround 0
Reserved bits 0
I.7.2.2 DMG OFDM mode scrambled header bits
Figure I-9 node . The header bits after scrambling bits 8 to 64 of the header using the seed 66 (0x42).
Reference: OFDMPHY_MCS13_Scrambled Header bits.txt
I.7.2.3 DMG OFDM mode LDPC encoded header bits
Figure I-9 node . The scrambled header bits after LDPC encoding but prior to zero stripping.
Reference: OFDMPHY_MCS13_LDPC Encoded Header Bits.txt
I.7.2.4 DMG OFDM mode LDPC data shortened bits
Figure I-9 node . The dimension of DMG OFDM mode modulation symbols requires that the CS1, CS2,
and CS3 sequences are each 224 bits long; this in turn requires that, in addition to the zeros, some of the
parity bits are discarded in order to shorten the LDPC codewords to 224 bits.
The data for the second and third shortened LDPC codewords are given as they are before they are
scrambled to provide CS2 and CS3.
Reference: OFDMPHY_MCS13_Shortened LDPC for CS1 bits.txt
Reference: OFDMPHY_MCS13_Shortened LDPC for CS2 bits.txt
Reference: OFDMPHY_MCS13_Shortened LDPC for CS3 bits.txt
I.7.2.5 DMG OFDM mode CS1/CS2/CS3 sequence bits
Figure I-9 node . The 672 bit concatenated CS1/CS2/CS3 sequence including the PN scrambling of CS2
and CS3.
Reference: OFDMPHY_MCS13_Final CS1 CS2 CS3 Sequence bits.txt
3383
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.7.3 DMG OFDM mode header modulation
The DMG OFDM mode header modulation is shown in Figure I-10.
Preamble Header Payload
CP 3
Add cyclic prefix
512 time points
Inverse FFT
512 frequency points 2
Null and pilot
insertion
(NCBPS / 2) points 1
x2 k f c4 k , c4 k 2
x2 k 1 f c4 k 1 , c4 k 3
N SD
k 0,1, , 1
2
T T 1 1 2
dk , dP k Q x2 k , x2 k 1 , where Q
5 2 1
NCBPS bits = 672
From DMG OFDM mode header coding
Figure I-10—DMG OFDM mode header modulation
I.7.3.1 Constellation mapped data points
Figure I-10 node . The LDPC encoded data is converted in the specified manner to 336 QPSK
constellation point values prior to assignment to data carriers (in the same order as the data they were
derived from). Note that because of the action of the Q matrix, these points look like 16-QAM when plotted.
Reference: Samples 1 to 336 of the file OFDMPHY_MCS13_Constellation Mapped Data Points.txt
I.7.3.2 IFFT input samples including data, pilot, DC and null carriers
Figure I-10 node . At this node the data points have been mapped to the data carriers, the pilots, DC and
null carriers have been assigned, and the resulting 512 point frequency domain vector is in the correct order
for input to the inverse Fourier transform, i.e., with positive frequencies in the first 256 locations and
negative frequencies in the second 256 locations.
Reference: Samples 1 to 512 of the file OFDMPHY_MCS13_FFT Input Samples.txt
3384
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.7.3.3 Header samples
Figure I-10 node . At this node the signal has been inverse Fourier transformed to produce a time record
and the cyclic prefix has been appended to create the 640 sample OFDM symbol.
Reference: OFDMPHY_MCS13_Header Samples.txt
I.7.4 DMG OFDM mode payload coding
As illustrated in Figure I-11, the LDPC encoding for the DMG OFDM mode case is identical to the DMG
SC mode case, so no additional LDPC vectors are strictly necessary. However, the equations for computing
the zero padding at the end of the payload are different from the DMG SC mode case so bit vectors for nodes
1, 2, and 3 are provided.
NCW x LCW = NSYM x NCBPS bits
LCW = 672 bits LCW = 672 bits LCW = 672 bits
LCWD parity LCWD parity LCWD parity
(R) LDPC (R) LDPC (R) LDPC
m=1 m=2 m = NCW
3
LCWD = (R) x LCW LCWD = (R) x LCW LCWD = (R) x LCW
LCWD- sized chunk LCWD- sized chunk LCWD- sized chunk
2
scrambled data (scrambler state continues from header)
scrambler
PPDU Data (PSDU) NPAD zeros
1
Figure I-11—DMG OFDM mode payload coding
I.7.5 DMG OFDM mode MCS14 payload modulation
The DMG OFDM mode SQPSK payload modulation is shown in Figure I-12.
I.7.5.1 Payload bits
Figure I-11 node . The payload comprises 1000 × 8 bits. With NCBPS = 336 and rate 5/8 LDPC coding the
DMG OFDM mode zero padding NPAD = 400, so the padded payload comprises 8 400 bits.
Reference: OFDMPHY_MCS14_ Payload bits.txt
I.7.5.2 Scrambled payload bits
Figure I-11 node . All 8 400 bits are scrambled according to a scrambler initialization value of 66.
Reference: OFDMPHY_MCS14_Scrambled Payload bits.txt
3385
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
2
Payload
CP
Add
cyclic prefix
512 time points
Inverse FFT
512 frequency points
Null and pilot
insertion
NCBPS points 1
conjugation and
static tone pairing
(NCBPS / 2) points
dk f c2 k , c2 k 1
NCBPS bits = 336
LCWD
parity
For SQPSK, half of an LDPC codeword is used for each OFDM symbol
Figure I-12—DMG OFDM mode SQPSK payload modulation
I.7.5.3 LDPC encoded payload bits
Figure I-11 node . For this example, with NCBPS = 336 and rate 5/8 LDPC coding there are 20 LDPC
codewords or 20 × 672 = 13 440 bits at this node.
Reference: OFDMPHY_MCS14_LDPC Encoded Payload bits.txt
I.7.5.4 SQPSK constellation mapped data points
Figure I-12 node . For SQPSK modulation, each block of NCBPS = 336 LDPC encoded bits is converted
in the specified manner to 168 QPSK constellation point values and their complex conjugates prior to
assignment to data carriers, in the same order as the data they were derived from.
There are 336 constellation points for each block of 336 LDPC encoded bits, so there are 40 sets of 336
constellation points (13 440 point in total) at this node.
Reference:
Samples 337 to 13 776 of the file OFDMPHY_MCS14_Constellation Mapped Data Points.txt
3386
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.7.5.5 Payload samples
Figure I-12 node . Each set of 336 constellation points is mapped to 512 frequency domain points then
inverse Fourier transformed to 512 time domain points; adding the cyclic prefix creates a 640 sample OFDM
symbol. There are 40 OFDM symbols in this example payload, giving a total of 40 × 640 = 25 600 samples.
Reference: OFDMPHY_MCS14_Payload Samples.txt
I.7.6 DMG OFDM mode MCS17 payload modulation
The DMG OFDM mode QPSK payload modulation is shown in Figure I-13.
2
Payload
CP
Add
cyclic prefix
512 time points
Inverse FFT
512 frequency points
Null and pilot
insertion
(NCBPS / 2) points 1
x2 k f c4 k , c4 k 2
x2 k 1 f c4 k 1 , c4 k 3
N
k 0,1, , SD 1
2
T T 1 1 2
dk , d P k Q x2 k , x2 k 1 , where Q
5 2 1
NCBPS bits = 672
LCWD parity
For QPSK, 1 LDPC codeword is used for each OFDM symbol
Figure I-13—DMG OFDM mode QPSK payload modulation
I.7.6.1 Payload bits
Figure I-11 node . The payload comprises 1000 × 8 bits. With NCBPS = 672 and rate 3/4 LDPC coding the
DMG OFDM mode zero padding NPAD = 64, so the padded payload comprises 8 064 bits.
Reference: OFDMPHY_MCS17_ Payload bits.txt
3387
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.7.6.2 Scrambled payload bits
Figure I-11 node . All 8 064 bits are scrambled according to a scrambler initialization value of 66.
Reference: OFDMPHY_MCS17_Scrambled Payload bits.txt
I.7.6.3 LDPC encoded payload bits
Figure I-11 node . For this example, with NCBPS = 672 and rate 3/4 LDPC coding there are 16 LDPC
codewords or 16 × 672 = 10 752 bits at this node.
Reference: OFDMPHY_MCS17_LDPC Encoded Payload bits.txt
I.7.6.4 QPSK constellation mapped data points
Figure I-13 node . For QPSK modulation, each block of NCBPS = 672 LDPC encoded bits is converted in
the specified manner to 336 QPSK constellation point values prior to assignment to data carriers, in the same
order as the data they were derived from.
There are 336 constellation points for each block of 672 LDPC encoded bits, so there are 16 sets of 336
constellation points (5 376 point in total) at this node.
Reference:
Samples 337 to 5 712 of the file OFDMPHY_MCS17_Constellation Mapped Data Points.txt
I.7.6.5 Payload samples
Figure I-13 node . Each set of 336 constellation points is mapped to 512 frequency domain points then
inverse Fourier transformed to 512 time domain points; adding the cyclic prefix creates a 640 sample OFDM
symbol. There are 16 OFDM symbols in this example payload giving a total of 16 × 640 = 10 240 samples.
Reference: OFDMPHY_MCS17_Payload Samples.txt
I.7.7 DMG OFDM mode MCS19 payload modulation
The DMG OFDM mode 16-QAM payload modulation is shown in Figure I-14.
I.7.7.1 Payload bits
Figure I-11 node . The payload comprises 1000 × 8 bits. With NCBPS = 1 344 and rate 5/8 LDPC coding
the DMG OFDM mode zero padding NPAD = 400, so the padded payload comprises 8 400 bits.
Reference: OFDMPHY_MCS19_ Payload bits.txt
I.7.7.2 Scrambled payload bits
Figure I-11 node . All 8 400 bits are scrambled according to a scrambler initialization value of 66.
Reference: OFDMPHY_MCS19_Scrambled Payload bits.txt
3388
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
2
Payload
CP
Add
cyclic prefix
512 time points
Inverse FFT
512 frequency points
Null and pilot
insertion
(NCBPS / 4) points 1
NCBPS bits = 1344
LCWD parity LCWD parity
For 16-QAM, 2 LDPC codewords are used for each OFDM symbol
Figure I-14—DMG OFDM mode 16-QAM payload modulation
I.7.7.3 LDPC encoded payload bits
Figure I-11 node . For this example, with NCBPS = 1 344 and rate 5/8 LDPC coding there are 20 LDPC
codewords or 20 × 672 = 13 440 bits at this node.
Reference: OFDMPHY_MCS19_LDPC Encoded Payload bits.txt
I.7.7.4 16-QAM constellation mapped data points
Figure I-14 node . For 16-QAM modulation, each block of NCBPS = 1 344 LDPC encoded bits is
converted in the specified manner to 336 16-QAM constellation point values prior to assignment to data
carriers, in the same order as the data they were derived from.
There are 336 constellation points for each block of 1 344 LDPC encoded bits, so there are 10 sets of 336
constellation points (3360 points in total) at this node.
Reference:
Samples 337 to 3 696 of the file OFDMPHY_MCS19_Constellation Mapped Data Points.txt
3389
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.7.7.5 Payload samples
Figure I-14 node . Each set of 336 constellation points is mapped to 512 frequency domain points then
inverse Fourier transformed to 512 time domain points; adding the cyclic prefix creates a 640 sample OFDM
symbol. There are 10 OFDM symbols in this example payload giving a total of 10 × 640 = 6 400 samples.
Reference: OFDMPHY_MCS19_Payload Samples.txt
I.7.8 DMG OFDM mode MCS23 payload modulation
The DMG OFDM mode 64-QAM payload modulation is shown in Figure I-15.
2
Payload
CP
Add
cyclic prefix
512 time points
Inverse FFT
512 frequency points
Null and pilot
insertion
(NCBPS / 6) points 1
NCBPS bits = 2016
LCWD parity LCWD parity LCWD parity
For 64-QAM, 3 LDPC codewords are used for each OFDM symbol
Figure I-15—DMG OFDM mode 64-QAM payload modulation
I.7.8.1 Payload bits
Figure I-11 node . The payload comprises 1000 × 8 bits. With NCBPS = 2 016 and rate 3/4 LDPC coding
the DMG OFDM mode zero padding NPAD = 1 072, so the padded payload comprises 9 072 bits.
Reference: OFDMPHY_MCS23_ Payload bits.txt
3390
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.7.8.2 Scrambled payload bits
Figure I-11 node . All 9 072 bits are scrambled according to a scrambler initialization value of 66.
Reference: OFDMPHY_MCS23_Scrambled Payload bits.txt
I.7.8.3 LDPC encoded bits
Figure I-11 node . For this example, with NCBPS = 2 016 and rate 3/4 LDPC coding there are 18 LDPC
codewords or 18 × 672 = 12 096 bits at this node.
Reference: OFDMPHY_MCS23_LDPC Encoded Payload bits.txt
I.7.8.4 64-QAM constellation mapped data points
Figure I-15 node . For 64-QAM modulation, each block of NCBPS = 2 016 LDPC encoded bits is
converted in the specified manner to 336 64-QAM constellation point values prior to assignment to data
carriers, in the same order as the data they were derived from.
There are 336 constellation points for each block of 2 016 LDPC encoded bits, so there are 6 sets of 336
constellation points (2 016 points in total) at this node.
Reference:
Samples 337 to 2352 of the file OFDMPHY_MCS23_Constellation Mapped Data Points.txt
I.7.8.5 Payload samples
Figure I-15 node . Each set of 336 constellation points is mapped to 512 frequency domain points then
inverse Fourier transformed to 512 time domain points; adding the cyclic prefix creates a 640 sample OFDM
symbol. There are 6 OFDM symbols in this example payload giving a total of 6 × 640 = 3 840 samples.
Reference: OFDMPHY_MCS23_Payload Samples.txt
I.8 DMG Example 4 – DMG low-power SC mode encoding
I.8.1 DMG low-power SC mode preamble
The DMG low-power SC mode preamble is identical to the DMG SC mode preamble.
I.8.2 DMG low-power SC mode header
The DMG low-power SC mode header fields are the same as the DMG SC mode header fields. The DMG
low-power SC mode header is encoded and modulated in the same way as the DMG SC mode header.
3391
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.8.3 DMG low-power SC mode MCS26 payload
The DMG low-power SC mode payload coding and modulation are shown in Figure I-16.
Payload
6
/2-BPSK/QPSK block /2-BPSK/QPSK block /2-BPSK/QPSK block Ga 64
/2 rotation
512 modulation
symbols
Ga64
G8
N EB
N BLKS
NCBPS 392
first block 512-64 -(7 x 8) = 392 modulation symbols last block
BPSK or
QPSK mapping 5
N BLKS N CBPS 392 bits
7 row x
8 column
bit interleaver
NBLK _PAD
NEB = N x (Length + NRS x 16) scrambled zeros
Add padding 4
(N,8) Block
Code 3
16 parity
208 data octets octets
N RS Length 208
2 RS(224,208)
scrambled
"Length" scrambled data octets (scrambler state continues from header) zeros
scrambler scrambler
NBLK_PAD
PPDU Data (PSDU) – "Length" octets
zeros
1
Figure I-16—DMG low-power SC mode payload coding and modulation
I.8.3.1 Payload bits
Figure I-16 node . The payload at node is a count, modulo 256, starting at 0.
For MCS26, the DMG low-power SC mode payload padding calculation gives NDATA_PAD = 368; however,
unlike the other modes, this padding data is not appended before FEC computation.
3392
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
So there are just 1000 × 8 = 8000 payload bits.
Reference: LPSCPHY_MCS26_Payload bits.txt
I.8.3.2 Scrambled payload bits
Figure I-16 node . All 8000 bits are scrambled according to a scrambler initialization value of 66.
Reference: LPSCPHY_MCS26_Scrambled Payload bits.txt
I.8.3.3 RS(224,208) encoded payload bits
Figure I-16 node . In this example, there are 4 RS(224,208) codewords and one shortened RS(184,168)
codeword, giving a total of (4 × 224 + 1 × 184) × 8 = 8 640 bits at this node.
Reference: LPSCPHY_MCS26_RS(224,208) Output bits.txt
I.8.3.4 (12,8) block coded payload bits
Figure I-16 node . The (12,8) block coder increases the effective bits from 8 640 to 12 960.
Reference: LPSCPHY_MCS26_Block Coded Payload bits.txt
I.8.3.5 Interleaved payload bits
Figure I-16 node . Before interleaving the block coder output is padded with NDATA_PAD = 368 scrambled
zeros to give 13 328 bits (34 x 392). The interleaver then redistributes these bits in time, as specified.
Reference: LPSCPHY_MCS26_RS Encoded and Interleaved Payload bits.txt
I.8.3.6 Payload samples
Figure I-16 node . Each block of 392 bits from the interleaver output is BPSK mapped to 392 modulation
symbols, prepended with a Ga64 sequence as a guard interval and punctuated by G8 (last 8 samples of Ga64)
guard intervals, then /2 rotated, thus resulting in a 512 symbol /2-BPSK modulation block.
In this example, there are 34 modulation blocks and, as specified, the last one is followed by a terminating
Ga64 guard interval sequence, so there are 34 × 512 + 64 = 17 472 samples at this node.
Reference: LPSCPHY_MCS26_Payload Samples.txt
I.8.4 DMG low-power SC mode MCS30 payload
I.8.4.1 Payload bits
Figure I-16 node . The payload at node is a count, modulo 256, starting at 0.
For MCS30, the DMG low-power SC mode payload padding calculation gives NDATA_PAD = 472; however,
unlike the other modes, this padding data is not appended before FEC computation.
So there are just 1000 × 8 = 8000 payload bits.
Reference: LPSCPHY_MCS30_Payload bits.txt
3393
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
I.8.4.2 Scrambled payload bits
Figure I-16 node . All 8000 bits are scrambled according to a scrambler initialization value of 66.
Reference: LPSCPHY_MCS30_Scrambled Payload bits.txt
I.8.4.3 RS(224,208) encoded payload bits
Figure I-16 node . In this example, there are 4 RS(224,208) codewords and one shortened RS(184,168)
codeword, giving a total of (4 × 224 + 1 × 184) × 8 = 8 640 bits at this node.
Reference: LPSCPHY_MCS30_RS(224,208) Output bits.txt
I.8.4.4 Spc(9,8) block coded payload bits
Figure I-16 node . The (9,8) block coder increases the effective bits from 8 640 to 9 720.
Reference: LPSCPHY_MCS30_Block Coded Payload bits.txt
I.8.4.5 Interleaved payload bits
Figure I-16 node . Before interleaving the block coder output is padded with NDATA_PAD = 472 scrambled
zeros to give 10 192 bits (26 × 392). The interleaver then redistributes these bits in time, as specified.
Reference: LPSCPHY_MCS30_RS Encoded and Interleaved Payload bits.txt
I.8.4.6 Payload samples
Figure I-16 node . Each block of 784 bits from the interleaver output is QPSK mapped to 392 modulation
symbols, prepended with a Ga64 sequence as a guard interval and punctuated by G8 (last 8 samples of Ga64)
guard intervals, then /2 rotated, thus resulting in a 512 symbol /2-BPSK modulation block.
In this example, there are 13 modulation blocks and, as specified, the last one is followed by a terminating
Ga64 guard interval sequence, so there are 13 × 512 + 64 = 6 720 samples at this node.
Reference: LPSCPHY_MCS30_Payload Samples.txt
3394
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex J
(informative)
RSNA reference implementations and test vectors
J.1 TKIP temporal key mixing function reference implementation and test
vector
J.1.1 TKIP temporal key mixing function reference implementation
This clause provides a C-language reference implementation of the temporal key mixing function.
/***********************************************************************
Contents: Generate IEEE 802.11 per-frame ARC4 key hash test vectors
Date: April 19, 2002
Notes:
This code is written for pedagogical purposes, NOT for performance.
************************************************************************/
#include
#include
#include
#include
#include
typedef unsigned char byte; /* 8-bit byte (octet) */
typedef unsigned short u16b; /* 16-bit unsigned word */
typedef unsigned long u32b; /* 32-bit unsigned word */
/* macros for extraction/creation of byte/u16b values */
#define RotR1(v16) ((((v16) >> 1) & 0x7FFF) ^ (((v16) & 1) << 15))
#define Lo8(v16) ((byte)( (v16) & 0x00FF))
#define Hi8(v16) ((byte)(((v16) >> 8) & 0x00FF))
#define Lo16(v32) ((u16b)( (v32) & 0xFFFF))
#define Hi16(v32) ((u16b)(((v32) >>16) & 0xFFFF))
#define Mk16(hi,lo) ((lo) ^ (((u16b)(hi)) << 8))
/* select the Nth 16-bit word of the Temporal Key byte array TK[] */
#define TK16(N) Mk16(TK[2*(N)+1],TK[2*(N)])
/* S-box lookup: 16 bits --> 16 bits */
#define _S_(v16) (Sbox[0][Lo8(v16)] ^ Sbox[1][Hi8(v16)])
3395
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
/* fixed algorithm "parameters" */
#define PHASE1_LOOP_CNT 8 /* this needs to be "big enough" */
#define TA_SIZE 6 /* 48-bit transmitter address */
#define TK_SIZE 16 /* 128-bit Temporal Key */
#define P1K_SIZE 10 /* 80-bit Phase1 key */
#define ARC4_KEY_SIZE 16 /* 128-bit ARC4KEY (104 bits unknown)*/
/* configuration settings */
#define DO_SANITY_CHECK 1 /* validate properties of S-box? */
/* 2-byte by 2-byte subset of the full AES S-box table */
const u16b Sbox[2][256]= /* Sbox for hash (can be in ROM) */
{ {
0xC6A5,0xF884,0xEE99,0xF68D,0xFF0D,0xD6BD,0xDEB1,0x9154,
0x6050,0x0203,0xCEA9,0x567D,0xE719,0xB562,0x4DE6,0xEC9A,
0x8F45,0x1F9D,0x8940,0xFA87,0xEF15,0xB2EB,0x8EC9,0xFB0B,
0x41EC,0xB367,0x5FFD,0x45EA,0x23BF,0x53F7,0xE496,0x9B5B,
0x75C2,0xE11C,0x3DAE,0x4C6A,0x6C5A,0x7E41,0xF502,0x834F,
0x685C,0x51F4,0xD134,0xF908,0xE293,0xAB73,0x6253,0x2A3F,
0x080C,0x9552,0x4665,0x9D5E,0x3028,0x37A1,0x0A0F,0x2FB5,
0x0E09,0x2436,0x1B9B,0xDF3D,0xCD26,0x4E69,0x7FCD,0xEA9F,
0x121B,0x1D9E,0x5874,0x342E,0x362D,0xDCB2,0xB4EE,0x5BFB,
0xA4F6,0x764D,0xB761,0x7DCE,0x527B,0xDD3E,0x5E71,0x1397,
0xA6F5,0xB968,0x0000,0xC12C,0x4060,0xE31F,0x79C8,0xB6ED,
0xD4BE,0x8D46,0x67D9,0x724B,0x94DE,0x98D4,0xB0E8,0x854A,
0xBB6B,0xC52A,0x4FE5,0xED16,0x86C5,0x9AD7,0x6655,0x1194,
0x8ACF,0xE910,0x0406,0xFE81,0xA0F0,0x7844,0x25BA,0x4BE3,
0xA2F3,0x5DFE,0x80C0,0x058A,0x3FAD,0x21BC,0x7048,0xF104,
0x63DF,0x77C1,0xAF75,0x4263,0x2030,0xE51A,0xFD0E,0xBF6D,
0x814C,0x1814,0x2635,0xC32F,0xBEE1,0x35A2,0x88CC,0x2E39,
0x9357,0x55F2,0xFC82,0x7A47,0xC8AC,0xBAE7,0x322B,0xE695,
0xC0A0,0x1998,0x9ED1,0xA37F,0x4466,0x547E,0x3BAB,0x0B83,
0x8CCA,0xC729,0x6BD3,0x283C,0xA779,0xBCE2,0x161D,0xAD76,
0xDB3B,0x6456,0x744E,0x141E,0x92DB,0x0C0A,0x486C,0xB8E4,
0x9F5D,0xBD6E,0x43EF,0xC4A6,0x39A8,0x31A4,0xD337,0xF28B,
0xD532,0x8B43,0x6E59,0xDAB7,0x018C,0xB164,0x9CD2,0x49E0,
0xD8B4,0xACFA,0xF307,0xCF25,0xCAAF,0xF48E,0x47E9,0x1018,
0x6FD5,0xF088,0x4A6F,0x5C72,0x3824,0x57F1,0x73C7,0x9751,
0xCB23,0xA17C,0xE89C,0x3E21,0x96DD,0x61DC,0x0D86,0x0F85,
0xE090,0x7C42,0x71C4,0xCCAA,0x90D8,0x0605,0xF701,0x1C12,
0xC2A3,0x6A5F,0xAEF9,0x69D0,0x1791,0x9958,0x3A27,0x27B9,
0xD938,0xEB13,0x2BB3,0x2233,0xD2BB,0xA970,0x0789,0x33A7,
0x2DB6,0x3C22,0x1592,0xC920,0x8749,0xAAFF,0x5078,0xA57A,
0x038F,0x59F8,0x0980,0x1A17,0x65DA,0xD731,0x84C6,0xD0B8,
0x82C3,0x29B0,0x5A77,0x1E11,0x7BCB,0xA8FC,0x6DD6,0x2C3A,
},
3396
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
{ /* second half of table is byte-reversed version of first! */
0xA5C6,0x84F8,0x99EE,0x8DF6,0x0DFF,0xBDD6,0xB1DE,0x5491,
0x5060,0x0302,0xA9CE,0x7D56,0x19E7,0x62B5,0xE64D,0x9AEC,
0x458F,0x9D1F,0x4089,0x87FA,0x15EF,0xEBB2,0xC98E,0x0BFB,
0xEC41,0x67B3,0xFD5F,0xEA45,0xBF23,0xF753,0x96E4,0x5B9B,
0xC275,0x1CE1,0xAE3D,0x6A4C,0x5A6C,0x417E,0x02F5,0x4F83,
0x5C68,0xF451,0x34D1,0x08F9,0x93E2,0x73AB,0x5362,0x3F2A,
0x0C08,0x5295,0x6546,0x5E9D,0x2830,0xA137,0x0F0A,0xB52F,
0x090E,0x3624,0x9B1B,0x3DDF,0x26CD,0x694E,0xCD7F,0x9FEA,
0x1B12,0x9E1D,0x7458,0x2E34,0x2D36,0xB2DC,0xEEB4,0xFB5B,
0xF6A4,0x4D76,0x61B7,0xCE7D,0x7B52,0x3EDD,0x715E,0x9713,
0xF5A6,0x68B9,0x0000,0x2CC1,0x6040,0x1FE3,0xC879,0xEDB6,
0xBED4,0x468D,0xD967,0x4B72,0xDE94,0xD498,0xE8B0,0x4A85,
0x6BBB,0x2AC5,0xE54F,0x16ED,0xC586,0xD79A,0x5566,0x9411,
0xCF8A,0x10E9,0x0604,0x81FE,0xF0A0,0x4478,0xBA25,0xE34B,
0xF3A2,0xFE5D,0xC080,0x8A05,0xAD3F,0xBC21,0x4870,0x04F1,
0xDF63,0xC177,0x75AF,0x6342,0x3020,0x1AE5,0x0EFD,0x6DBF,
0x4C81,0x1418,0x3526,0x2FC3,0xE1BE,0xA235,0xCC88,0x392E,
0x5793,0xF255,0x82FC,0x477A,0xACC8,0xE7BA,0x2B32,0x95E6,
0xA0C0,0x9819,0xD19E,0x7FA3,0x6644,0x7E54,0xAB3B,0x830B,
0xCA8C,0x29C7,0xD36B,0x3C28,0x79A7,0xE2BC,0x1D16,0x76AD,
0x3BDB,0x5664,0x4E74,0x1E14,0xDB92,0x0A0C,0x6C48,0xE4B8,
0x5D9F,0x6EBD,0xEF43,0xA6C4,0xA839,0xA431,0x37D3,0x8BF2,
0x32D5,0x438B,0x596E,0xB7DA,0x8C01,0x64B1,0xD29C,0xE049,
0xB4D8,0xFAAC,0x07F3,0x25CF,0xAFCA,0x8EF4,0xE947,0x1810,
0xD56F,0x88F0,0x6F4A,0x725C,0x2438,0xF157,0xC773,0x5197,
0x23CB,0x7CA1,0x9CE8,0x213E,0xDD96,0xDC61,0x860D,0x850F,
0x90E0,0x427C,0xC471,0xAACC,0xD890,0x0506,0x01F7,0x121C,
0xA3C2,0x5F6A,0xF9AE,0xD069,0x9117,0x5899,0x273A,0xB927,
0x38D9,0x13EB,0xB32B,0x3322,0xBBD2,0x70A9,0x8907,0xA733,
0xB62D,0x223C,0x9215,0x20C9,0x4987,0xFFAA,0x7850,0x7AA5,
0x8F03,0xF859,0x8009,0x171A,0xDA65,0x31D7,0xC684,0xB8D0,
0xC382,0xB029,0x775A,0x111E,0xCB7B,0xFCA8,0xD66D,0x3A2C,
}
};
#if DO_SANITY_CHECK
/*
**********************************************************************
* Routine: SanityCheckTable -- verify Sbox properties
*
* Inputs: Sbox
* Output: None, but an assertion fails if the tables are wrong
* Notes:
* The purpose of this routine is solely to illustrate and
3397
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
* verify the following properties of the Sbox table:
* - the Sbox is a "2x2" subset of the AES table:
* Sbox + affine transform + MDS.
* - the Sbox table can be easily designed to fit in a
* 512-byte table, using a byte swap
* - the Sbox table can be easily designed to fit in a
* 256-byte table, using some shifts and a byte swap
**********************************************************************
*/
void SanityCheckTable(void)
{
const static int M_x = 0x11B; /* AES irreducible polynomial */
const static byte Sbox8[256] = { /* AES 8-bit Sbox */
0x63,0x7c,0x77,0x7b,0xf2,0x6b,0x6f,0xc5,
0x30,0x01,0x67,0x2b,0xfe,0xd7,0xab,0x76,
0xca,0x82,0xc9,0x7d,0xfa,0x59,0x47,0xf0,
0xad,0xd4,0xa2,0xaf,0x9c,0xa4,0x72,0xc0,
0xb7,0xfd,0x93,0x26,0x36,0x3f,0xf7,0xcc,
0x34,0xa5,0xe5,0xf1,0x71,0xd8,0x31,0x15,
0x04,0xc7,0x23,0xc3,0x18,0x96,0x05,0x9a,
0x07,0x12,0x80,0xe2,0xeb,0x27,0xb2,0x75,
0x09,0x83,0x2c,0x1a,0x1b,0x6e,0x5a,0xa0,
0x52,0x3b,0xd6,0xb3,0x29,0xe3,0x2f,0x84,
0x53,0xd1,0x00,0xed,0x20,0xfc,0xb1,0x5b,
0x6a,0xcb,0xbe,0x39,0x4a,0x4c,0x58,0xcf,
0xd0,0xef,0xaa,0xfb,0x43,0x4d,0x33,0x85,
0x45,0xf9,0x02,0x7f,0x50,0x3c,0x9f,0xa8,
0x51,0xa3,0x40,0x8f,0x92,0x9d,0x38,0xf5,
0xbc,0xb6,0xda,0x21,0x10,0xff,0xf3,0xd2,
0xcd,0x0c,0x13,0xec,0x5f,0x97,0x44,0x17,
0xc4,0xa7,0x7e,0x3d,0x64,0x5d,0x19,0x73,
0x60,0x81,0x4f,0xdc,0x22,0x2a,0x90,0x88,
0x46,0xee,0xb8,0x14,0xde,0x5e,0x0b,0xdb,
0xe0,0x32,0x3a,0x0a,0x49,0x06,0x24,0x5c,
0xc2,0xd3,0xac,0x62,0x91,0x95,0xe4,0x79,
0xe7,0xc8,0x37,0x6d,0x8d,0xd5,0x4e,0xa9,
0x6c,0x56,0xf4,0xea,0x65,0x7a,0xae,0x08,
0xba,0x78,0x25,0x2e,0x1c,0xa6,0xb4,0xc6,
0xe8,0xdd,0x74,0x1f,0x4b,0xbd,0x8b,0x8a,
0x70,0x3e,0xb5,0x66,0x48,0x03,0xf6,0x0e,
0x61,0x35,0x57,0xb9,0x86,0xc1,0x1d,0x9e,
0xe1,0xf8,0x98,0x11,0x69,0xd9,0x8e,0x94,
0x9b,0x1e,0x87,0xe9,0xce,0x55,0x28,0xdf,
0x8c,0xa1,0x89,0x0d,0xbf,0xe6,0x42,0x68,
0x41,0x99,0x2d,0x0f,0xb0,0x54,0xbb,0x16 };
3398
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
int i,k,k2,k3;
byte bitmap[0x2000];
/* show that smaller tables can be used */
for (i=0;i<256;i++)
{
k = Sbox8[i];
k2 = (k << 1) ^ ((k & 0x80) ? M_x : 0);
k3 = k ^ k2;
assert(Sbox[0][i] == ((k2 << 8) ^ k3));
assert(Sbox[1][i] == ((k3 << 8) ^ k2));
}
/* now make sure that it's a 16-bit permutation */
memset(bitmap,0,sizeof(bitmap));
for (i=0;i<0x10000;i++)
{
k = _S_(i); /* do an S-box lookup: 16 --> 16 bits */
assert(k < (1 << 16));
assert((bitmap[k >> 3] & (1 << (k & 7))) == 0);
bitmap[k >> 3] |= 1 << (k & 7);
}
for (i=0;i> 1);
/* Copy 96 bits of PPK[0..5] to ARC4KEY[4..15] (little-endian) */
for (i=0;i<6;i++)
{
ARC4KEY[4+2*i] = Lo8(PPK[i]);
ARC4KEY[5+2*i] = Hi8(PPK[i]);
}
}
/*
3401
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
**********************************************************************
* Routine: doTestCase -- execute a test case, and print results
**********************************************************************
*/
void DoTestCase(byte *ARC4KEY,u32b IV32,u16b IV16,const byte *TA,const
byte *TK)
{
int i;
u16b P1K[P1K_SIZE/2]; /* "temp" copy of phase1 key */
printf("\nTK =");
for (i=0;i> (24-8*i)) & 0xFF);
printf("]");
printf("\nIV16 = %04X",IV16);
Phase1(P1K,TK,TA,IV32);
printf("\nP1K =");
for (i=0;i
#include
#include
#include
#include "Michael.h"
// Rotation functions on 32 bit values
#define ROL32( A, n ) \
( ((A) << (n)) | ( ((A)>>(32-(n))) & ( (1UL << (n)) - 1 ) ) )
#define ROR32( A, n ) ROL32( (A), 32-(n) )
UInt32 Michael::getUInt32( Byte * p )
// Convert from Byte[] to UInt32 in a portable way
{
UInt32 res = 0;
for( int i=0; i<4; i++ )
{
res |= (*p++) << (8*i);
}
return res;
}
void Michael::putUInt32( Byte * p, UInt32 val )
// Convert from UInt32 to Byte[] in a portable way
{
for( int i=0; i<4; i++ )
{
*p++ = (Byte) (val & 0xff);
val >>= 8;
}
}
void Michael::clear()
{
// Reset the state to the empty message.
L = K0;
R = K1;
3410
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
nBytesInM = 0;
M = 0;
}
void Michael::setKey( Byte * key )
{
// Set the key
K0 = getUInt32( key );
K1 = getUInt32( key + 4 );
// and reset the message
clear();
}
Michael::Michael( Byte * key )
{
setKey( key );
}
Michael::~Michael()
{
// Wipe the key material
K0 = 0;
K1 = 0;
// And the other fields as well.
//Note that this sets (L,R) to (K0,K1) which is just fine.
clear();
}
void Michael::appendByte( Byte b )
{
// Append the byte to our word-sized buffer
M |= b << (8*nBytesInM);
nBytesInM++;
// Process the word if it is full.
if( nBytesInM >= 4 )
{
L ^= M;
R ^= ROL32( L, 17 );
L += R;
R ^= ((L & 0xff00ff00) >> 8) | ((L & 0x00ff00ff) << 8);
L += R;
R ^= ROL32( L, 3 );
L += R;
R ^= ROR32( L, 2 );
L += R;
3411
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
// Clear the buffer
M = 0;
nBytesInM = 0;
}
}
void Michael::append( Byte * src, int nBytes )
{
// This is simple
while( nBytes > 0 )
{
appendByte( *src++ );
nBytes--;
}
}
void Michael::getMIC( Byte * dst )
{
// Append the minimum padding
appendByte( 0x5a );
appendByte( 0 );
appendByte( 0 );
appendByte( 0 );
appendByte( 0 );
// and then 0s until the length is a multiple of 4
while( nBytesInM != 0 )
{
appendByte( 0 );
}
// The appendByte function has already computed the result.
putUInt32( dst, L );
putUInt32( dst+4, R );
// Reset to the empty message.
clear();
}
void Michael::hexToBin( char *src, Byte * dst )
{
// Simple wrapper
hexToBin( src, strlen( src ), dst );
}
void Michael::hexToBin( char *src, int nChars, Byte * dst )
{
assert( (nChars & 1) == 0 );
int nBytes = nChars/2;
3412
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
// Straightforward conversion
for( int i=0; i
#define USE_VECTOR_1 // Use test vector #1 as GCMP input
// #define USE_VECTOR_2 // Use test vector #2 as GCMP input
// Prototype
int tcSubWord(int x);
int tcSubByte(int x);
void tcAESfunc(int StartofRound[4], int RoundKey[44]);
void tcKeyExpansion(int x[4], int RoundKey[44]);
void tcAdjustText(int move, int data[4]);
int tcMixColumns(int x);
int tcMultEight(int x, int y);
void tcMultGF(int x[4], int y[4], int Zout[4]);
int main(void)
{
// Function parameter
int i, j, temp[4];
int Nr = 16; // 256-octet * 8-bit / 128-bit
// Input for main
int ENCDEC=1;
// Indication of Encryption and Decryption: 1 Enc 0 Dec
#ifdef USE_VECTOR_1
// Input for GCMP test vector #1
// Key for system 128-bit
int Key[4]={0xaaaaaaaa, 0xaaaaaaaa, 0xaaaaaaaa, 0xaaaaaaaa};
// Initialization Vector 96-bit + 1 (32-bit)
int IV[4]={0xffffffff, 0xffff0000, 0x00000001, 0x00000001};
// Additional Authenticated Data
int AAD[2][4]={{0x20020000, 0x00000000, 0xffffffff, 0xffffffff},
{0xffffffff, 0x00000000, 0x00000000, 0x00000000}};
// FC, A1=0s, A2=Fs, A3=Fs
// Length of AAD and Cipher Text
int LENAC[4]={0x00000000, 0x000000b0, 0x00000000, 0x00000800};
#endif // USE_VECTOR_1
#ifdef USE_VECTOR_2
// Input for GCMP test vector #2 (see also plaintext input below)
// Key for system 128-bit
int Key[4]={0xc97c1f67, 0xce371185, 0x514a8a19, 0xf2bdd52f};
// Initialization Vector 96-bit + 1 (32-bit)
int IV[4]={0x5030f184, 0x44080089, 0x5f5f2b08, 0x00000001};
// 88 40 0f d2 e1 28 a5 7c 50 30 f1 84 44 08 50 30 f1 84 44 08 00 00 03 00
// Additional Authenticated Data
int AAD[2][4]={{0x88400fd2, 0xe128a57c, 0x5030f184, 0x44085030},
{0xf1844408, 0x00000300, 0x00000000, 0x00000000}};
// FC, A1=0f-d2-e1-28-a5-7c,
// A2=50-30-f1-84-44-08, A3=50-30-f1-84-44-08
// Length of AAD and Cipher Text
3433
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
int LENAC[4]={0x00000000, 0x000000c0, 0x00000000, 0x00000140};
#endif // USE_VECTOR_2
int TextIn[16][4];
// AES parameter
// Round Keys, Generated by Input Keys and use for AES
int RoundKey[44];
// Input/output of AES function
int StartofRound[4];
// HASH output, AES function with 0s input
int HASH[4];
// First output of AES function with Y0 input,
// which uses for generating Tag
int EKY0[4];
// Output Text, which is either Cipher/Plain text.
// Length should much with TextIn
int TextOut[16][4];
// GF parameter
int MultIn[4]; // Input of Multiplication
int Tag[4] = {0, 0, 0, 0};// Tag output
// Processing Parameter
int p_flag = 1; // Indication of end of process
int LengthTxt[2]; // Block length of text that is Plain/Cipher Text
int TxtRemain; // The last block of text, range is between 0 to 127
int Txt_flag = 0; // Indication of last text is not 128-bit
// ===== Main Process =====
// Generate 1500 Octets '0' Text
for (i=0;i> 7;
if ((LENAC[3] & 0x0000007f) == 0) {
LengthTxt[1] = LENAC[3] >> 7;
}
else {
LengthTxt[1] = (LENAC[3] >> 7) + 1;
TxtRemain = LENAC[3] & 0x0000007F;
Txt_flag = 1;
}
// Generate HASH, which uses for GF(2^128) function
// AES function with 0s input
for (i=0;i<4;i++) {
StartofRound[i] = 0;
}
tcAESfunc(StartofRound, RoundKey);
for (i=0;i<4;i++) {
HASH[i] = StartofRound[i];
}
// GF 2^128 with AAD
for (i=0;i<2;i++) {
for (j=0;j<4;j++) {
MultIn[j] = AAD[i][j] ^ Tag[j];
}
tcMultGF(HASH, MultIn, Tag);
}
// Generate Encryption Key and Tag
// AES function with Yi input to generate Encryption Keys
// First output for which Y0 input is used for generating Tag
i = 0;
while (p_flag) {
// Set IV as a Input of AES
for (j=0;j<4;j++) {
StartofRound[j] = IV[j];
}
// AES function
tcAESfunc(StartofRound, RoundKey);
printf("AES Number %02d is %08x %08x %08x %08x\n", i,
StartofRound[0], StartofRound[1],
StartofRound[2], StartofRound[3]);
// Increment IV by '1'
IV[3] = IV[3] + 1;
// Set EKY0 for Tag
if (i == 0) {
for (j=0;j<4;j++) {
EKY0[j] = StartofRound[j];
}
}
// Xor Input Text and Encryption Keys
// Check the last Block of processing
else if (LengthTxt[1] == 0) {
if (LengthTxt[0] == 0) {
p_flag = 0;
for (j=0;j<4;j++) {
TextOut[i-1][j] = TextIn[i-1][j] ^
3435
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
StartofRound[j];
}
// Adjust the length textout
for (j=0;j<4;j++) {
temp[j] = TextOut[i-1][j];
}
if (Txt_flag == 1) {
tcAdjustText(TxtRemain, temp);
}
for (j=0;j<4;j++) {
TextOut[i-1][j] = temp[j];
}
// XOR with last text and former Tag
for (j=0;j<4;j++) {
if (ENCDEC == 1) {
MultIn[j] = TextOut[i-1][j] ^ Tag[j];
}
else {
MultIn[j] = TextIn[i-1][j] ^ Tag[j];
}
}
tcMultGF(HASH, MultIn, Tag);
}
else {
LengthTxt[0]--;
LengthTxt[1]--;
for (j=0;j<4;j++) {
TextOut[i-1][j] = TextIn[i-1][j] ^
StartofRound[j];
if (ENCDEC == 1) {
MultIn[j] = TextOut[i-1][j] ^ Tag[j];
}
else {
MultIn[j] = TextIn[i-1][j] ^ Tag[j];
}
}
tcMultGF(HASH, MultIn, Tag);
}
}
else {
for (j=0;j<4;j++) {
TextOut[i-1][j] = TextIn[i-1][j] ^ StartofRound[j];
if (ENCDEC == 1) {
MultIn[j] = TextOut[i-1][j] ^ Tag[j];
}
else {
MultIn[j] = TextIn[i-1][j] ^ Tag[j];
}
}
tcMultGF(HASH, MultIn, Tag);
}
i++;
LengthTxt[1]--;
}
// Generate Tag
// 1. XOR with LENAC and Tag
for (j=0;j<4;j++) {
MultIn[j] = LENAC[j] ^ Tag[j];
}
3436
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
// 2. GF(2^128)
tcMultGF(HASH, MultIn, Tag);
// 3. XOR with EKY0 and Tag
for (j=0;j<4;j++) {
Tag[j] = EKY0[j] ^ Tag[j];
}
// Display
for (i=0;i>24) & 0x000000FF);
AfterSubWord = tcSubWord(AfterRotWord);
AfterXorWithRcon = AfterSubWord ^ Rcon[i/4-1];
RoundKey[i] = RoundKey[i-4] ^ AfterXorWithRcon;
}
else {
RoundKey[i] = RoundKey[i-4] ^ RoundKey[i-1];
3438
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
}
}
}
// Adjust the Plain/Cipher Text Size if it is not multiply by 128-bit
void tcAdjustText(int move, int data[4])
{
int i;
// Move to MSB -> LSB
i = 128 - move;
while (i) {
data[3] = ((data[3] >> 1) & 0x7FFFFFFF) ^
((data[2] << 31) & 0x80000000);
data[2] = ((data[2] >> 1) & 0x7FFFFFFF) ^
((data[1] << 31) & 0x80000000);
data[1] = ((data[1] >> 1) & 0x7FFFFFFF) ^
((data[0] << 31) & 0x80000000);
data[0] = (data[0] >> 1) & 0x7FFFFFFF;
i--;
}
// Move to LSB -> MSB
i = 128 - move;
while (i) {
data[0] = ((data[0] << 1) & 0xFFFFFFFE) ^
((data[1] >> 31) & 0x00000001);
data[1] = ((data[1] << 1) & 0xFFFFFFFE) ^
((data[2] >> 31) & 0x00000001);
data[2] = ((data[2] << 1) & 0xFFFFFFFE) ^
((data[3] >> 31) & 0x00000001);
data[3] = (data[3] << 1) & 0xFFFFFFFE;
i--;
}
}
// 32-bit SubByte function
int tcSubWord(int x)
{
int r = 0;
int i;
int temp;
for (i=0;i<4;i++) {
temp = (x >> i*8) & 0xFF;
r = r ^ tcSubByte(temp) << i*8;
}
return r;
}
// S-Box Lookup Table
int tcSubByte(int x)
{
int r;
switch(x) {
case 0x00 : r = 0x63; break;
case 0x01 : r = 0x7c; break;
case 0x02 : r = 0x77; break;
case 0x03 : r = 0x7b; break;
case 0x04 : r = 0xf2; break;
case 0x05 : r = 0x6b; break;
case 0x06 : r = 0x6f; break;
3439
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
case 0x07 : r = 0xc5; break;
case 0x08 : r = 0x30; break;
case 0x09 : r = 0x01; break;
case 0x0A : r = 0x67; break;
case 0x0B : r = 0x2b; break;
case 0x0C : r = 0xfe; break;
case 0x0D : r = 0xd7; break;
case 0x0E : r = 0xab; break;
case 0x0F : r = 0x76; break;
case 0x10 : r = 0xca; break;
case 0x11 : r = 0x82; break;
case 0x12 : r = 0xc9; break;
case 0x13 : r = 0x7d; break;
case 0x14 : r = 0xfa; break;
case 0x15 : r = 0x59; break;
case 0x16 : r = 0x47; break;
case 0x17 : r = 0xf0; break;
case 0x18 : r = 0xad; break;
case 0x19 : r = 0xd4; break;
case 0x1A : r = 0xa2; break;
case 0x1B : r = 0xaf; break;
case 0x1C : r = 0x9c; break;
case 0x1D : r = 0xa4; break;
case 0x1E : r = 0x72; break;
case 0x1F : r = 0xc0; break;
case 0x20 : r = 0xb7; break;
case 0x21 : r = 0xfd; break;
case 0x22 : r = 0x93; break;
case 0x23 : r = 0x26; break;
case 0x24 : r = 0x36; break;
case 0x25 : r = 0x3f; break;
case 0x26 : r = 0xf7; break;
case 0x27 : r = 0xcc; break;
case 0x28 : r = 0x34; break;
case 0x29 : r = 0xa5; break;
case 0x2A : r = 0xe5; break;
case 0x2B : r = 0xf1; break;
case 0x2C : r = 0x71; break;
case 0x2D : r = 0xd8; break;
case 0x2E : r = 0x31; break;
case 0x2F : r = 0x15; break;
case 0x30 : r = 0x04; break;
case 0x31 : r = 0xc7; break;
case 0x32 : r = 0x23; break;
case 0x33 : r = 0xc3; break;
case 0x34 : r = 0x18; break;
case 0x35 : r = 0x96; break;
case 0x36 : r = 0x05; break;
case 0x37 : r = 0x9a; break;
case 0x38 : r = 0x07; break;
case 0x39 : r = 0x12; break;
case 0x3A : r = 0x80; break;
case 0x3B : r = 0xe2; break;
case 0x3C : r = 0xeb; break;
case 0x3D : r = 0x27; break;
case 0x3E : r = 0xb2; break;
case 0x3F : r = 0x75; break;
case 0x40 : r = 0x09; break;
case 0x41 : r = 0x83; break;
3440
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
case 0x42 : r = 0x2c; break;
case 0x43 : r = 0x1a; break;
case 0x44 : r = 0x1b; break;
case 0x45 : r = 0x6e; break;
case 0x46 : r = 0x5a; break;
case 0x47 : r = 0xa0; break;
case 0x48 : r = 0x52; break;
case 0x49 : r = 0x3b; break;
case 0x4A : r = 0xd6; break;
case 0x4B : r = 0xb3; break;
case 0x4C : r = 0x29; break;
case 0x4D : r = 0xe3; break;
case 0x4E : r = 0x2f; break;
case 0x4F : r = 0x84; break;
case 0x50 : r = 0x53; break;
case 0x51 : r = 0xd1; break;
case 0x52 : r = 0x00; break;
case 0x53 : r = 0xed; break;
case 0x54 : r = 0x20; break;
case 0x55 : r = 0xfc; break;
case 0x56 : r = 0xb1; break;
case 0x57 : r = 0x5b; break;
case 0x58 : r = 0x6a; break;
case 0x59 : r = 0xcb; break;
case 0x5A : r = 0xbe; break;
case 0x5B : r = 0x39; break;
case 0x5C : r = 0x4a; break;
case 0x5D : r = 0x4c; break;
case 0x5E : r = 0x58; break;
case 0x5F : r = 0xcf; break;
case 0x60 : r = 0xd0; break;
case 0x61 : r = 0xef; break;
case 0x62 : r = 0xaa; break;
case 0x63 : r = 0xfb; break;
case 0x64 : r = 0x43; break;
case 0x65 : r = 0x4d; break;
case 0x66 : r = 0x33; break;
case 0x67 : r = 0x85; break;
case 0x68 : r = 0x45; break;
case 0x69 : r = 0xf9; break;
case 0x6A : r = 0x02; break;
case 0x6B : r = 0x7f; break;
case 0x6C : r = 0x50; break;
case 0x6D : r = 0x3c; break;
case 0x6E : r = 0x9f; break;
case 0x6F : r = 0xa8; break;
case 0x70 : r = 0x51; break;
case 0x71 : r = 0xa3; break;
case 0x72 : r = 0x40; break;
case 0x73 : r = 0x8f; break;
case 0x74 : r = 0x92; break;
case 0x75 : r = 0x9d; break;
case 0x76 : r = 0x38; break;
case 0x77 : r = 0xf5; break;
case 0x78 : r = 0xbc; break;
case 0x79 : r = 0xb6; break;
case 0x7A : r = 0xda; break;
case 0x7B : r = 0x21; break;
case 0x7C : r = 0x10; break;
3441
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
case 0x7D : r = 0xff; break;
case 0x7E : r = 0xf3; break;
case 0x7F : r = 0xd2; break;
case 0x80 : r = 0xcd; break;
case 0x81 : r = 0x0c; break;
case 0x82 : r = 0x13; break;
case 0x83 : r = 0xec; break;
case 0x84 : r = 0x5f; break;
case 0x85 : r = 0x97; break;
case 0x86 : r = 0x44; break;
case 0x87 : r = 0x17; break;
case 0x88 : r = 0xc4; break;
case 0x89 : r = 0xa7; break;
case 0x8A : r = 0x7e; break;
case 0x8B : r = 0x3d; break;
case 0x8C : r = 0x64; break;
case 0x8D : r = 0x5d; break;
case 0x8E : r = 0x19; break;
case 0x8F : r = 0x73; break;
case 0x90 : r = 0x60; break;
case 0x91 : r = 0x81; break;
case 0x92 : r = 0x4f; break;
case 0x93 : r = 0xdc; break;
case 0x94 : r = 0x22; break;
case 0x95 : r = 0x2a; break;
case 0x96 : r = 0x90; break;
case 0x97 : r = 0x88; break;
case 0x98 : r = 0x46; break;
case 0x99 : r = 0xee; break;
case 0x9A : r = 0xb8; break;
case 0x9B : r = 0x14; break;
case 0x9C : r = 0xde; break;
case 0x9D : r = 0x5e; break;
case 0x9E : r = 0x0b; break;
case 0x9F : r = 0xdb; break;
case 0xA0 : r = 0xe0; break;
case 0xA1 : r = 0x32; break;
case 0xA2 : r = 0x3a; break;
case 0xA3 : r = 0x0a; break;
case 0xA4 : r = 0x49; break;
case 0xA5 : r = 0x06; break;
case 0xA6 : r = 0x24; break;
case 0xA7 : r = 0x5c; break;
case 0xA8 : r = 0xc2; break;
case 0xA9 : r = 0xd3; break;
case 0xAA : r = 0xac; break;
case 0xAB : r = 0x62; break;
case 0xAC : r = 0x91; break;
case 0xAD : r = 0x95; break;
case 0xAE : r = 0xe4; break;
case 0xAF : r = 0x79; break;
case 0xB0 : r = 0xe7; break;
case 0xB1 : r = 0xc8; break;
case 0xB2 : r = 0x37; break;
case 0xB3 : r = 0x6d; break;
case 0xB4 : r = 0x8d; break;
case 0xB5 : r = 0xd5; break;
case 0xB6 : r = 0x4e; break;
case 0xB7 : r = 0xa9; break;
3442
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
case 0xB8 : r = 0x6c; break;
case 0xB9 : r = 0x56; break;
case 0xBA : r = 0xf4; break;
case 0xBB : r = 0xea; break;
case 0xBC : r = 0x65; break;
case 0xBD : r = 0x7a; break;
case 0xBE : r = 0xae; break;
case 0xBF : r = 0x08; break;
case 0xC0 : r = 0xba; break;
case 0xC1 : r = 0x78; break;
case 0xC2 : r = 0x25; break;
case 0xC3 : r = 0x2e; break;
case 0xC4 : r = 0x1c; break;
case 0xC5 : r = 0xa6; break;
case 0xC6 : r = 0xb4; break;
case 0xC7 : r = 0xc6; break;
case 0xC8 : r = 0xe8; break;
case 0xC9 : r = 0xdd; break;
case 0xCA : r = 0x74; break;
case 0xCB : r = 0x1f; break;
case 0xCC : r = 0x4b; break;
case 0xCD : r = 0xbd; break;
case 0xCE : r = 0x8b; break;
case 0xCF : r = 0x8a; break;
case 0xD0 : r = 0x70; break;
case 0xD1 : r = 0x3e; break;
case 0xD2 : r = 0xb5; break;
case 0xD3 : r = 0x66; break;
case 0xD4 : r = 0x48; break;
case 0xD5 : r = 0x03; break;
case 0xD6 : r = 0xf6; break;
case 0xD7 : r = 0x0e; break;
case 0xD8 : r = 0x61; break;
case 0xD9 : r = 0x35; break;
case 0xDA : r = 0x57; break;
case 0xDB : r = 0xb9; break;
case 0xDC : r = 0x86; break;
case 0xDD : r = 0xc1; break;
case 0xDE : r = 0x1d; break;
case 0xDF : r = 0x9e; break;
case 0xE0 : r = 0xe1; break;
case 0xE1 : r = 0xf8; break;
case 0xE2 : r = 0x98; break;
case 0xE3 : r = 0x11; break;
case 0xE4 : r = 0x69; break;
case 0xE5 : r = 0xd9; break;
case 0xE6 : r = 0x8e; break;
case 0xE7 : r = 0x94; break;
case 0xE8 : r = 0x9b; break;
case 0xE9 : r = 0x1e; break;
case 0xEA : r = 0x87; break;
case 0xEB : r = 0xe9; break;
case 0xEC : r = 0xce; break;
case 0xED : r = 0x55; break;
case 0xEE : r = 0x28; break;
case 0xEF : r = 0xdf; break;
case 0xF0 : r = 0x8c; break;
case 0xF1 : r = 0xa1; break;
case 0xF2 : r = 0x89; break;
3443
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
case 0xF3 : r = 0x0d; break;
case 0xF4 : r = 0xbf; break;
case 0xF5 : r = 0xe6; break;
case 0xF6 : r = 0x42; break;
case 0xF7 : r = 0x68; break;
case 0xF8 : r = 0x41; break;
case 0xF9 : r = 0x99; break;
case 0xFA : r = 0x2d; break;
case 0xFB : r = 0x0f; break;
case 0xFC : r = 0xb0; break;
case 0xFD : r = 0x54; break;
case 0xFE : r = 0xbb; break;
case 0xFF : r = 0x16; break;
default : r = 0x00; printf("S-BOX Error!!"); break;
}
return r;
}
// MixColumns function for AES
int tcMixColumns(int x)
{
int r;
int s0, s1, s2, s3;
s0 = (tcMultEight(0x02,(x>>24) & 0xFF))^
(tcMultEight(0x03,(x>>16) & 0xFF))^ ((x>>8) & 0xFF)^ (x & 0xFF);
s1 = ((x>>24) & 0xFF)^ (tcMultEight(0x02,(x>>16) & 0xFF))^
(tcMultEight(0x03,(x>>8) & 0xFF))^ (x & 0xFF);
s2 = ((x>>24) & 0xFF)^ ((x>>16) & 0xFF)^
(tcMultEight(0x02,(x>>8) & 0xFF))^ (tcMultEight(0x03,x & 0xFF));
s3 = (tcMultEight(0x03,(x>>24) & 0xFF))^
((x>>16) & 0xFF)^ ((x>>8) & 0xFF)^ (tcMultEight(0x02,x & 0xFF));
r = ((s0<<24) & 0xFF000000) ^
((s1<<16) & 0x00FF0000) ^ ((s2<<8) & 0x0000FF00) ^ (s3 & 0x000000FF);
return r;
}
// Multiplication in GF(2^8)
int tcMultEight(int x, int y)
{
int r = 0x1b;
int i, z = 0;
int y_flag = 0;
for (i=0;i<8;i++) {
if (((x>>i) & 1) == 1) {
z = z ^ y;
}
if (((y >> 7) & 1) == 1) {
y_flag = 1;
}
y = (y << 1) & 0xFF;
if (y_flag == 1) {
y = y ^ r;
}
y_flag = 0;
}
return z;
}
3444
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
// Multiplication in GF(2^128)
void tcMultGF(int x[4], int y[4], int Zout[4])
{
int i,j,k=0;
int r[4] = {0xe1000000, 0x00000000, 0x00000000, 0x00000000};
int z[4] = {0x00000000, 0x00000000, 0x00000000, 0x00000000};
int V[4];
for (i=0;i<4;i++) {
V[i] = x[i];
}
for (i=0;i<4;i++) {
for (j=0;j<32;j++) {
if (((y[i]>>(31-j)) & 1) == 1) {
for (k=0;k<4;k++) {
z[k] = z[k] ^ V[k];
}
}
if ((V[3] & 1) == 0) {
V[3] = ((V[3] >> 1) & 0x7fffffff) ^
((V[2] << 31) & 0x80000000);
V[2] = ((V[2] >> 1) & 0x7fffffff) ^
((V[1] << 31) & 0x80000000);
V[1] = ((V[1] >> 1) & 0x7fffffff) ^
((V[0] << 31) & 0x80000000);
V[0] = ((V[0] >> 1) & 0x7fffffff);
}
else {
V[3] = ((V[3] >> 1) & 0x7fffffff) ^
((V[2] << 31) & 0x80000000);
V[2] = ((V[2] >> 1) & 0x7fffffff) ^
((V[1] << 31) & 0x80000000);
V[1] = ((V[1] >> 1) & 0x7fffffff) ^
((V[0] << 31) & 0x80000000);
V[0] = ((V[0] >> 1) & 0x7fffffff);
for (k=0;k<4;k++) {
V[k] = V[k] ^ r[k];
}
}
}
}
for (i=0;i<4;i++) {
Zout[i] = z[i];
}
}
3445
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex K
(informative)
TSPECs and Admission control
K.1 Example use of TSPEC for admission control
Admission control, in general, depends on vendors’ implementations of schedulers, available channel
capacity, link conditions, retransmission limits, and the scheduling requirements of a given TSPEC.
However, for any given channel capacity, link conditions, and retransmission limits, some TSPEC
constructions might be categorically rejected because a scheduler cannot create a meaningful schedule for
that TSPEC. There needs to be, for example, be a minimum number of specified fields in the TSPEC in
order for the admission control mechanism to create a valid TSPEC. Table K-1 below lists the valid TSPEC
fields that need to be present for all admission control algorithms to admit a TSPEC. This represents a set of
necessary parameters in order for TSPEC to be admitted; it is not sufficient in and of itself to guarantee
TSPEC admittance, which depends upon channel conditions and other factors. Such TSPECs are said to be
admissible. In the table, S means specified, X means unspecified, and Opt means “optional.”
Table K-1—Admissible TSPECs
Continuous time Controlled-access
Bursty traffic Contention based
TSPEC parameter QoS traffic CBR traffic
(HCCA) traffic (EDCA)
(HCCA) (HCCA)
Nominal MSDU
S S X S
Size
Minimum Nominal MSDU S
Service Interval size/mean data rate, Usually set to 0 or a
S X
if specified (VoIP small number (e.g.,
typically uses this) 1)
Maximum Opt
Same as Minimum
Service Interval S S (Used to indicate
SI
aggregation limit)
Inactivity
Always specified X
Interval
Suspension Interval Opt
Minimum Data Rate Specified if peak Equal to mean data Specified if peak
X
data rate is specified rate data rate is specified
Mean Data Rate S S Opt S
Burst Size X X S Opt
Minimum PHY
Always specified
Rate
Peak Data Rate Opt Opt
Should be specified Equal to Mean Data Should be specified
Opt
if Minimum Data Rate if Minimum Data
Rate is specified Rate is specified
3446
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table K-1—Admissible TSPECs (continued)
Continuous time Controlled-access
Bursty traffic Contention based
TSPEC parameter QoS traffic CBR traffic
(HCCA) traffic (EDCA)
(HCCA) (HCCA)
Delay Bound S S Opt Opt
Surplus
Bandwidth Allow- Is specified if the delay bound is present S
ance
Medium Time (not specified by non-AP STA; only an output from the HC)
K.2 Recommendation for implementation of contention based admission
control
K.2.1 Use of ACM (admission control mandatory) subfield
It is recommended that admission control not be required for the access categories AC_BE and AC_BK. The
ACM subfield for these categories should be set to 0. The AC parameters chosen by the AP should account
for unadmitted traffic in these ACs.
When dot11SSPNInterfaceActivated is true, it is recommended that any STA authenticated through an
SSPN interface use admission control to access categories AC_VO and AC_VI to produce network
utilization consistent with the policy imposed by the SSPN for admission. AC parameters chosen by the AP
should further account for any unadmitted traffic in AC_VO and AC_VI that might be reserved for users of
a particular SSPN.
K.2.2 Deriving medium time
An AP should use the following procedure to derive the value of the Medium Time field in its ADDTS
Response frame.
There are two requirements to consider: 1) the traffic requirements of the application, and 2) the expected
error performance of the medium.
The application requirements are captured by the following TSPEC fields: Nominal MSDU Size and Mean
Data Rate. Note that the Nominal MSDU Size field is the nominal A-MSDU size, where A-MSDU
aggregation is employed.
The medium requirements are captured by the following TSPEC fields: Surplus Bandwidth Allowance and
Minimum PHY Rate.
The following formula describes how Medium Time, in units of 32 µs periods per second, can be calculated:
Medium Time = Surplus Bandwidth Allowance Packets Per Second Frame Exchange Time-
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0x2000 32
where
a) if A-MPDU aggregation is not employed (i.e., TS Info Ack Policy = 00 (Normal Acknowledg-
ment)):
3447
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Mean Data Size
Packets Per Second =---------------------------------------------------------------------
-
8 Nominal MSDU Size
Frame Exchange Time =
duration (Nominal MPDU Size, Minimum PHY Rate)
+ SIFS
+ duration (Ack Size, Ack Rate)
Nominal MPDU Size =
MAC Header Size
+ Nominal MSDU Size
+ Security Encapsulation Size
+ FCS Size
b) if A-MPDU aggregation is employed (i.e., TS Info Ack Policy = 11 (Block Ack)):
Mean Data Rate
Packets Per Second = ----------------------------------------------------------------------------------------------------------------------------------------
-
8 Nominal MSDU Size Nominal MSDUAggregation
Frame Exchange Time =
duration (Nominal A-MPDU Size, Minimum PHY Rate)
+ SIFS
+ duration (BlockAck Size, BlockAck Rate)
Nominal A-MPDU Size =
Nominal MSDU Aggregation
× Nominal A-MPDU Subframe Size
– Padding Size
Nominal A-MPDU Subframe Size =
MPDU Delimiter Size
+ MAC Header Size
+ Nominal MSDU Size
+ Security Encapsulation Size
+ FCS Size
+ Padding Size
Padding Size =
3
– (MAC Header Size
+ Nominal MSDU Size
+ Security Encapsulation Size
+ 3)
mod 4
and where
Sizes are in octets; Rates are in b/s; durations and Times are in µs; Surplus Bandwidth Allowance is the
unsigned integer value passed
MAC Header Size = 26
MPDU Delimiter Size = 4
Security Encapsulation Size = 16 (CCMP), 20 (GCMP and TKIP), 8 (WEP) or 0 (open system)
Ack Size = 14
3448
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
BlockAck Size = 32
FCS Size = 4
SIFSIFS = 10 when operating in the 2.4 GHz band, 16 when operating in the 5 GHz band, 3 when operat-
ing in the 60 GHz band
Ack/BlockAck Rate is the rate used for the Ack/BlockAck frame, given the Minimum PHY Rate, subject
to the corresponding multirate rules
duration () is the PLME-TXTIME primitive defined in clauses 6.5.5 and 6.5.6 that returns the duration of
a PPDU based on the PSDU size and the PHY data rate and PHY employed, e.g., clauses
16.3.4, 17.4.3, 18.5.3.2, 19.4.3 and 20.12.3
Notes:
— Division does not truncate.
— Any signal extension is included, even for the acknowledgment frame which ends the frame
exchange.
— If protection frames are used, then they are included in the Frame Exchange Time too. Each frame
contributes an additional term:
Frame Exchange Time +=
duration (Protection Frame Size, Protection Frame Rate)
+ SIFS
where
RTS Protection Frame Size = 20
CTS Protection Frame Size = 14
Protection Frame Rate is the rate used for the protection frame, given the Minimum PHY Rate, subject to
the corresponding multirate and protection rules
An AP assumes that a STA will use CTS-to-self protection if an ERP element directs use of protection.
— The assumption is made that HT Control headers and beamforming frames are not normally used
and so their contribution to Medium Time is negligible.
— The Nominal A-MPDU Subframe Size can be increased by the AP where necessary to account for
the Minimum MPDU Start Spacing. For example, if the Minimum PHY Rate is 65 Mb/s and the
Minimum MPDU Start Spacing is 16 µs then the minimum Nominal A-MPDU Subframe Size is
132 octets (including 2 octets of pad).
— A STA might request TSPEC fields that would result in violation of other applicable constraints
such as the receiver’s maximum A-MSDU or A-MPDU size, any maximum PPDU duration, or, for
uplink or bidirectional TSPECs, any nonzero TXOP limit. An AP receiving such a request is likely
to reject it. An AP might also reject requests that cannot be satisfied for reasons that the STA is not
always aware of, such as, for uplink or bidirectional TSPECs, the AP’s maximum Block Ack Buffer
Size.
— Where A-MPDU aggregation is employed, HT-immediate Block Ack is assumed.
K.3 Guidelines and reference design for sample scheduler and admission
control unit
K.3.1 Guidelines for deriving service schedule parameters
The HC establishes the SI for each admitted TS for a STA to derive the aggregate minimum SI contained in
the STA’s service schedule. The SI for each TS is equal to the maximum SI contained in the TSPEC, if it
3449
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
exists; otherwise, it is the nominal MSDU size divided by the mean data rate. The SI contained in the service
schedule is equal to the smallest SI for any TSPEC.
The HC can use an aggregate “token bucket specification” to police a STA’s admitted flows. The HC
derives the aggregate mean data rate and aggregate burst size to establish the aggregate token bucket
specification. The aggregate mean data rate is equal to the sum of the mean data rates of all of the STA’s
admitted TSs. The aggregate burst size is equal to the sum of the burst size of all of the STA’s admitted TSs.
An aggregate token bucket is initialized with the aggregate burst size. Tokens are added to the token bucket
at the aggregate mean data rate. Alternatively the method of summing TSPECs for statistical multiplexing,
as described in T.2.3, can be used.
When dot11SSPNInterfaceActivated is true, the HC polices all traffic flows from a non-AP STA
authenticated against the maximum authorized data rates stored in the dot11InterworkingTable. Each SSPN-
authenticated STA is given a maximum bandwidth allowance by the SSPN for each access category as well
as scheduled access. The AP polices the SSPN-authenticated STA traffic flows to the maximum bandwidth
allowance provided by the SSPN.
K.3.2 Reference design for sample scheduler and admission control unit
K.3.2.1 General
This subclause provides the guidelines for the design of a simple scheduler and admission control unit (the
unit that administers admission policy in the HC’s SME) that meet the minimum performance requirements
as specified in 10.22.4.3. The scheduler and admission control unit use the minimum set of mandatory
TSPEC fields as specified in 10.22.4.3.
K.3.2.2 Sample scheduler
This subclause includes the reference design for a sample scheduler. This scheduler uses the mandatory set
of TSPEC fields to generate a schedule: Mean Data Rate, Nominal MSDU Size, and Maximum Service
Interval or Delay Bound. If both Maximum Service Interval and Delay Bound parameters are specified in
the TSPEC, the scheduler uses the Maximum Service Interval parameter for the calculation of the schedule.
The schedule generated by the scheduler satisfies the requirements specified in 10.22.4.3. The schedule for
an admitted stream is calculated in two steps. The first step is the calculation of the scheduled SI. In the
second step, the TXOP duration for a given SI is calculated for the stream.
The calculation of the scheduled service interval is done as follows: First, the scheduler calculates the
minimum of all maximum SIs for all admitted streams. Let this minimum be m. Second, the scheduler
chooses a number lower than m that is a submultiple of the beacon interval. This value is the scheduled SI
for all STAs with admitted streams. See Figure K-1.
Figure K-1—Schedule for stream from STA i
For the calculation of the TXOP duration for an admitted stream, the scheduler uses the following
parameters: Mean Data Rate and Nominal MSDU Size; and from the negotiated TSPEC, the Scheduled
Service Interval calculated above, Physical Transmission Rate, Maximum Allowable Size of MSDU, and
3450
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Overhead. The Physical Transmission Rate is the minimum PHY rate negotiated in the TSPEC. If the
minimum PHY rate is not committed in the ADDTS Response frame, the scheduler can use the observed
PHY rate as the Physical Transmission Rate. The Overhead includes IFSs, Ack frames and CF-Poll frames.
For simplicity, details for the Overhead calculation are omitted in this description. The TXOP duration is
calculated as follows: First, the scheduler calculates the number of MSDUs that can arrive at the Mean Data
Rate during the SI:
SI
Ni = ----------------i
Li
where
SI is the Scheduled Service Interval
is the Mean Data Rate
L is the Nominal MSDU Size
Then the scheduler calculates the TXOP duration as the maximum of
— Time to transmit N i frames at R i and
— Time to transmit one maximum size MSDU at R i (plus overhead):
Ni Li M
TXOP i = max (---------------
- + O,----- + O)
Ri Ri
where
R is the Physical Transmission Rate
M is the maximum possible size of MSDU
O is the Overhead in time units
An example is shown in Figure K-1. Stream from STA i is admitted. The beacon interval is 100 ms and the
maximum SI for the stream is 60 ms. The scheduler calculates a scheduled SI ( SI ) equal to 50 ms using the
steps explained above is this annex.
The same process is repeated continuously while the maximum SI for the admitted stream is larger than the
current SI. An example is shown in Figure K-2.
Figure K-2—Schedule for streams from STAs i to k
If a new stream is admitted with a maximum SI smaller than the current SI, the scheduler needs to change
the current SI to a smaller number than the maximum SI of the newly admitted stream. Therefore, the TXOP
duration for the current admitted streams needs also to be recalculated with the new SI.
If a stream is dropped, the scheduler might use the time available to resume contention. The scheduler might
also choose to move the TXOPs for the STAs following the STA dropped to use the unused time. An
example is shown in Figure K-3, when the stream for STA j is removed. However, this option might require
the announcement of a new schedule to all STAs.
3451
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure K-3—Reallocation of TXOPs when a stream is dropped
Different modifications can be implemented to improve the performance of the minimum scheduler. For
example, a scheduler might generate different scheduled SIs ( SI ) for different STAs, and/or a scheduler
might consider accommodating retransmissions while allocating TXOP durations.
K.3.2.3 Admission control unit
This subclause describes a reference design for an admission control unit (ACU) that administers admission
of TS. The ACU uses the same set of parameters that the scheduler uses in K.3.2.2.
When a new stream requests admission, the admission control process is done in three steps. First, the ACU
calculates the number of MSDUs that arrive at the mean data rate during the scheduled SI. The scheduled SI
(SI) is the one that the scheduler calculates for the stream as specified in K.3.2.2. For the calculation of the
number of MSDUs, the ACU uses the equation for Ni shown in K.3.2.2. Second, the ACU calculates the
TXOP duration that needs to be allocated for the stream. The ACU uses the equation for TXOPi shown in
K.3.2.2. Finally, the ACU determines that the stream can be admitted when the following inequality is
satisfied:
k
TXOP k + 1 TXOP i T – T CP
-----------------------
-+ ----------------- ------------------
SI SI T
i=1
where
k is the number of existing streams
k+1 is used as index for the newly arriving stream
T indicates the beacon interval
TCP is the time used for EDCA traffic
Subclause 10.22.3.3 requires that the ACU complies with the dot11CAPlimit, i.e., the scheduler does not
allocate TXOPs that exceed dot11CAPlimit. The ACU might also consider additional time to allow for
retransmissions.
The ACU allows admitted streams to have an allocated access to the channel. Any modification can be
implemented for the design of the ACU. For example, UP-based ACU is possible by examining the UP field
in TSPEC to decide whether to admit, retain, or drop a stream. If the UP is not specified, a default value of 0
is used. If a higher UP stream needs to be serviced, an ACU might drop lower UP streams.
K.4 TSPEC construction
TSPECs are constructed at the SME from application requirements supplied via the SME and with
information specific to the MAC layer. However, in this subclause a description is given of how and where
certain parameters can be chosen. The following parameters typically arise from the application: Nominal
MSDU Size, Maximum MSDU Size, Minimum Service Interval, Maximum Service Interval, Inactivity
Interval, Minimum Data Rate, Mean Data Rate, Burst Size, Peak Data Rate, and Delay Bound. The
3452
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
following parameters are generated locally within the MAC: Minimum PHY Rate and Surplus Bandwidth
Allowance, although the Maximum Service Interval and Minimum Service Intervals can be generated within
the MLME as well. This subclause describes how the parameters that are typically generated within the
MAC can be derived.
Note that a TSPEC can also be generated autonomously by the MAC without any initiation by the SME.
However, if a TSPEC is generated subsequently by the SME, the TSPEC generated autonomously by the
MAC might be overridden (see 11.4.4.5).
Typically, TSPEC fields not determined by the application are built upon the assumption that the following
exist:
— A probability p of not transmitting the frame (because it would have exceeded its delay bound)
— An MSDU length (which can be considered fixed for constant-bit-rate applications)
— Application throughput and delay requirements
— A channel model of error, in particular a channel error probability for the (fixed) frame length
— Possibly country-specific limits on TXOP limits
K.4.1 Surplus Bandwidth Allocation
Typically, it can be assumed that the scheduler would attempt to schedule TXOPs distributed throughout a
small multiple of beacon intervals (if not a single beacon interval). In addition, TXOP limits would typically
be chosen to be as short as possible (within the constraints of the minimum PHY rate, acknowledgment
policy, and so forth), consistent with the goal of maximizing throughput. In other words, because of
overhead, not to mention the requirements for transmitting a single Poll frame, MPDU, and possibly Ack
frame, the TXOPs need to be at least of a certain duration.
The channel model implies an error ratio and an assumption about dependency (joint probability distribution
of channel errors sequentially, i.e., burst error probabilities).
For example, if the channel causes errors independently from frame to frame and the error probability is the
same for all frames of the same length at all times, this channel would be said to be an independent,
identically distributed error channel. With p as the probability of dropping the frame, and pe as the
probability of the frame not being transmitted successfully (i.e., either the Data frame or the Ack frame
associated with it is in error), let Np be the number of retries required to maintain the probability of dropping
the frame to be p.
The probability of any given packet being dropped in such a channel after Np retries is given by
Np + 1
p drop = p e
For example, in such a channel, if pe = 0.1 and pdrop = 10–8, then up to seven retries within the delay bound
are required, and the scheduler should consider these retransmissions in the cumulative TXOP allocations.
The Surplus Bandwidth Allowance (SBA) parameter causes the requesting STA to be allocated a minimum
amount of excess time by the scheduler so that the application dropped packet rates are bounded.
The probability of not successfully transmitting k packets is given by the cumulative distribution function of
the Binomial Distribution.
3453
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The binomial probability mass function is
n! k n–k
b k n p = ----------------------- p 1 – p
k! n – k !
where
n is the number of trials
p is the probability of success for each trial.
The binomial cumulative distribution function is
n
B k n p = b y n p
y=0
Assuming a certain packet error ratio (PER), Pe, the number of extra packets, N, that are required in order to
have a probability, Pns, of not successfully transmitting S packets is given:
n
B S S + N 1 – Pe = b y S + N 1 – Pe
y=0
Then
SBA = (S+N)/S
Now, if just one packet is lost, then the lost packet ratio, LPR, is LPR = 1/(S+N)
The condition where Pns < LPR represents a practical point for determining the value of N.
Medium Time used for EDCA Admission Control is based upon one second periods and HCCA Medium
time, used to aggregate TSPECs (see T.2.3) also uses the one second period. Hence, for each application, S
is the number of packets that are desired to be sent in each one second period.
For example, consider a voice application:
PER, Pe = 0.1 or probability of success is 1 – Pe = 0.9
Number of packets per second, S = 50
Probability of not having 50 successful packets, Pns = 0.87% for N = 13
Lost packet ratio for 1 lost packet, LPR = 1.59%
SBA = 1.26
Take the example of a video stream at 380 packets per second (about 4 Mb/s):
Number of packets per second, S = 380
Probability of not having 380 successful packets, Pns = 0.2% for N = 64
3454
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Lost packet ratio for 1 lost packet, LPR = 0.23%
SBA = 1.168
It can be seen that the value for SBA varies with S, the number of required packets per second.
A reasonable estimate for SBA is given by
SBA = –0.033 ln (S) + 1.37
Table K-2 is a table of SBA for various values of S, and the SBA estimate derived by using the formula
above.
Table K-2—SBA vs Packets/s
S Packets/s SBA Estimated SBA
50 1.26 1.241
95 1.221 1.220
190 1.189 1.197
285 1.179 1.183
380 1.168 1.174
475 1.164 1.167
570 1.160 1.161
665 1.156 1.156
760 1.154 1.151
855 1.151 1.147
950 1.151 1.144
1900 1.139 1.121
The values for SBA as shown in Table K-2 are based upon a one second time period and hence are what
should be used in the TSEC for EDCA Admission Control. The value used in an HCCA TSPEC might be
different, as will now be explained.
In an HCCA TSPEC the SBA relates the overhead required in each scheduled period. A voice stream, for
example, only sends one packet every 20 ms. Obviously an SBA of 1.26 is meaningless as it does not allow
even one retry. To allow just one retry, the minimum SBA is 2.0, Similarly for a video example of say 6
packets per schedule period, to allow at least one retry would require an SBA of (6+1)/6 = 1.167
Hence, for an HCCA TSPEC:
Calculate packets per SI:
Rm
PPSI = -------------------------
-
S n 8 SI
3455
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
Rm is the mean data rate (b/s)
Sn is the nominal MDSU size (octets)
SI is the service interval (seconds)
PPSI + 1
Then Minimum HCCA SBA = MAX SBA ---------------------- .
PPSI
Table K-3 shows the recommended SBA values for HCCA TSPECs for various video streams.
Table K-3—Table HCCA SBA for video streams
Min HCCA
Video, Mb/s Pkts per SI SBA, (1 sec) HCCA SBA
SBA
1 1 2.000 1.221 2.000
2 3 1.333 1.189 1.333
3 4 1.250 1.179 1.250
4 6 1.167 1.168 1.168
5 7 1.143 1.164 1.164
6 9 1.111 1.160 1.160
7 10 1.100 1.156 1.156
8 12 1.083 1.154 1.154
9 13 1.077 1.151 1.151
10 15 1.067 1.151 1.151
20 30 1.033 1.139 1.139
In summary, the suggested value for SBA is derived as follows:
— Calculate Packets per sec, PPS
Rm
PPS = -------------
-
Sn 8
where
Rm is the mean data rate (b/s)
Sn is the nominal MDSU size (octets)
NOTE—Nominal MSDU = MDSU or A-MSDU
— Calculate SBA
SBA = –0.033 Ln (PPS) + 1.37
EDCA Admission Control TSPEC and Medium Time calculation uses SBA.
For HCCA TSPEC:
— Calculate packets per SI, PPSI
Rm
PPSI = -------------------------
-
S n 8 SI
3456
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
where
Rm is the mean data rate (b/s)
Sn is the nominal MDSU size (octets)
SI is the service interval (seconds)
PPSI + 1
— HCCA SBA = MAX SBA ----------------------
PPSI
HCCA Medium Time uses SBA in place of HCCA SBA, if different.
K.4.2 Minimum and Maximum Service Interval
K.4.2.1 Scheduled traffic
The HC uses the Maximum Service Interval for the calculation of the schedule.
The value of the Minimum Service Interval is an indication that the traffic is CBR or VBR.
For CBR traffic the minimum and maximum Service Intervals should be set to the same value. For example,
most voice traffic requires a minimum and maximum service interval value of 20 ms.
In the case of VBR traffic, such as video, Minimum Service Interval should be set to 0 and the Maximum
Service Interval set to the service interval required by the application, e.g., to correspond to the codec that is
to be used For example, Maximum Service Interval is set to 16 ms for many real time video applications.
K.4.2.2 Use of Maximum Service Interval with Aggregation of Packets
Aggregation of MPDUs or MSDUs introduces delay to the packets, but the use of aggregated packets is to
be encouraged because of the increased efficiency. In the case of scheduled traffic, the aggregation of
packets is such that the number of MSDUs that are aggregated into a single packet (A-MSDU or A-MPDU)
does not exceed the scheduling service interval. Consider the following example:
— Video packet = 1316B (7*188 MPEG2-TS)
— Nominal MSDU Size = 1364 (octets)
— Mean Data Rate = 4 Mb/s
— Maximum Service Interval = 16 ms
6
Nominal MSDUs per SI = 4 10 = 3
---------------------
1364 8
Hence, to comply with the 16 ms SI, the limit for aggregation is 3, (an A-MSDU of 3 MSDUs, or an A-
MPDU consisting of 3 MSDUs).
In the case of EDCA Admission Control, where regular scheduling is not used, the value of the Maximum
Service Interval is used to indicate the limit of aggregation of nominal MSDUs and the acceptable latency
between packets. Using aggregation reduces the Medium Time and Used Time required.
For example, assuming a minimum PHY Rate of 39 Mb/s for the example used above, the accurate Medium
Time returned by the AP would be 13 783 µs. If the AP assumed that A-MPDUs were to be used, then the
accurate Medium Time would be 11 681 µs, a 15% reduction. Hence, an AP could ‘force’ a STA to use
aggregation, or alternatively could assume aggregation when it is considering the total traffic as part of its
admittance policy.
3457
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Nominal MSDU Size is the size of the MSDU or A-MSDU belonging to the TS.
Consider another example:
— Video packet = 1316B (7*188 MPEG2-TS)
— Nominal MSDU Size = 4137 (A-MSDU of 3 MSDUs)
— Mean Data Rate = 10 Mb/s
— Maximum Service Interval = 16 ms
6
Nominal MSDUs per SI = 10 10 = 4
---------------------
4137 8
Hence, further aggregation is possible and an A-MPDU consisting of 4 A-MSDUs could be sent and still
comply with the latency or SI requirement.
Note that the TSPEC is invalid if the Nominal MSDUs per Maximum Service Interval is less than 1.
K.4.3 Minimum, Mean, and Peak Data Rate
In an HCCA TSPEC, for CBR traffic the Minimum, Mean and Maximum Data Rate fields should contain
the same value but it is allowable to just specify the Mean Data Rate noting that the Minimum and
Maximum Service Intervals are the same.
In an EDCA TSPEC, for CBR traffic the Minimum, Mean and Maximum Data Rate fields should contain
the same value but it is allowable to just specify the Mean Data Rate.
For VBR traffic it is desirable to populate the Minimum, Mean and Peak data rate fields.
If a TSPEC has the Minimum Data Rate (Rmin) and Peak Data Rate (Rmax) fields populated, then the
standard deviation of that stream, σ, can be estimated as:
= 0.25 R max – R min
If a TSPEC has the Mean Data Rate (Rmean) and Peak Data Rate fields populated, then the standard
deviation of that stream, σ, can be estimated as:
= 0.5 R max – R mean )
If there are n streams, the values of the mean μ and standard deviation σ, of the total stream traffic should be
calculated using:
= n
2
tot = n
This is of particular use to EDCA admission control policy. When summing streams for EDCA Admission
Control, the EDCA Overhead Factor needs to be taken into account; see T.2.7.
3458
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex L
(informative)
Examples and sample code for encoding a TIM Partial Virtual
Bitmap
L.1 Introduction
The purpose of this annex is to show an examples of encoding a Partial Virtual Bitmap field of the TIM
element, as described in 9.4.2.6. Sample C code is provided in L.3.
L.2 Examples
The following examples help clarify the use of TIM values, both with and without the multiple BSSID
capability.
The first example is one in which there are no group addressed MSDUs buffered in the AP but there is traffic
for two STAs queued in the AP. STAs with AID 2 and AID 7 have data buffered in the AP. Figure L-1
shows the values of the Bitmap Control and Partial Virtual Bitmap fields that would be part of the TIM
element for this example.
Figure L-1—Partial Virtual Bitmap example #1
The next example is one in which group addressed MSDUs are buffered in the AP as well as traffic for
STAs. The DTIM Count field in the TIM element equals 0. STAs with AID 2, AID 7, AID 22 and AID 24
have data buffered in the AP. Figure L-2 shows the values of the Bitmap Control and Partial Virtual Bitmap
fields.
Another example is one in which group addressed MSDUs are buffered in the AP as well as traffic for
STAs. The DTIM Count field in the TIM element equals 0. Only the node with AID 24 has data buffered in
the AP. In this example, the Bitmap Offset is used to start the Partial Virtual Bitmap at the third octet.
Figure L-3 shows the values of the Bitmap Control and Partial Virtual Bitmap fields.
The three examples listed above describe the construction of the Partial Virtual Bitmap when multiple
BSSID operation is not supported. The following three examples demonstrate how to construct the Partial
Virtual Bitmap, when multiple BSSID operation is supported.
3459
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Bitmap Offset
B0 B7
AID 0 1 0 0 0 0 0 0 0 Bitmap Control
AID 1 1 0 1 0 0 0 0 1
AID 8 0 0 0 0 0 0 0 0 Partial Virtual Bitmap
AID 16 0 0 0 0 0 0 1 0
AID 24 1 0 0 0 0 0 0 0
Figure L-2—Partial Virtual Bitmap example #2
Bitmap Offset
B0 B7
AID 0 1 1 0 0 0 0 0 0 Bitmap Control
AID 16 0 0 0 0 0 0 0 0
AID 24 1 0 0 0 0 0 0 0 Partial Virtual Bitmap
Figure L-3—Partial Virtual Bitmap example #3
The first example showing multiple BSSID operation is one in which there are eight BSSIDs and the lowest
possible AID that can be assigned to any STA in this example is 8. There are no group addressed frames
buffered in the AP for any of the eight BSSIDs. However, STAs with AID 9 and AID 11 have an
individually addressed frames buffered in the AP. Figure L-4 shows the values of the Bitmap Control and
Partial Virtual Bitmap fields that would be part of the TIM element for this example when either Method A
or Method B is used. It is noted that Method B reduces to Method A in this example.
Figure L-4—Partial Virtual Bitmap example #4, Method A and Method B
In the next example, there are eight BSSIDs and the lowest possible AID that can be assigned to any STA in
this example is 8. There are group addressed frames buffered at the AP for the transmitted BSSID, and the
DTIM Count field in the TIM element of the transmitted BSSID is 0. The nontransmitted BSSID with
BSSID Index 3 also has the DTIM Count field set to 0 and has buffered group addressed frames. All other
nontransmitted BSSIDs have no buffered group addressed frames. In addition, STAs with AID 12, AID 17,
3460
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
AID 22 and AID 24 have data buffered at the AP. Figure L-5 shows the values of the Bitmap Control and
Partial Virtual Bitmap fields that would be part of the TIM element for this example when either Method A
or Method B is used. It is noted that Method B reduces to Method A in this example.
Transmitted BSSID Bitmap Offset
group addressed traffic B0
indication/AID 0 B7
1 0 0 0 0 0 0 0 Bitmap Control
Nontransmitted BSSID
group addressed traffic 1 0 0 1 0 0 0 0
indication
AID 8 0 0 0 0 1 0 0 0
Partial Virtual Bitmap
AID 16 0 1 0 0 0 0 1 0
AID 24 1 0 0 0 0 0 0 0
Figure L-5—Partial Virtual Bitmap example #5, Method A or Method B
In the third example, there are sixteen BSSIDs and the lowest possible AID that can be assigned to any STA
is 16 (n=4, k=15, see 9.4.2.6. There are no group addressed frames buffered at the AP for the transmitted
BSSID, and the DTIM Count field in the TIM element of the transmitted BSSID is 0. The nontransmitted
BSSID Index 3 also has the DTIM Count field set to 0 and has group addressed frames buffered at the AP.
All other nontransmitted BSSIDs have no buffered group addressed frames. In addition, the STA with AID
39 has individually addressed frames buffered at the AP. Figure L-6 and Figure L-7 show the values of the
Bitmap Control and Partial Virtual Bitmap fields that would be part of the TIM element for this example
when Method A (N2=4, see 9.4.2.6) and Method B (N0=2, N1=4, N2=4, see 9.4.2.6) are used, respectively.
Bitmap Offset (always 0 for Method A)
Transmitted BSSID group B0 B7
addressed traffic indication/
AID 0 0 0 0 0 0 0 0 0 Bitmap Control
Nontransmitted
BSSID group 0 0 0 1 0 0 0 0
addressed traffic
indication bits
0 0 0 0 0 0 0 0
AID 16 (begin use of
individually addressed 0 0 0 0 0 0 0 0 Partial Virtual Bitmap
frame buffering)
AID 24 0 0 0 0 0 0 0 0
AID 32 0 0 0 0 0 0 0 1 AID 39
Figure L-6—Partial Virtual Bitmap example #6, Method A
3461
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure L-7—Partial Virtual Bitmap example #6, Method B
L.3 Sample C code
The following C source code illustrates how to construct the Partial Virtual Bitmap. Because this is an
illustration, no efficiency or appropriateness for actual implementation is implied.
#include
#include
#define ADD_TIM_BIT 0
#define REMOVE_TIM_BIT 1
#define TIM_ELEMENT_ID 5
#define TIM_BASE_SIZE 3 /* size of TIM fixed fields */
#define AID_SIZE 2008 /* valid AIDs are numBssids thru 2007 */
#define VBM_SIZE 251 /* size of VBM array = 2008/8 = 251 */
#define MAX_BSSIDS 128 /* maximum possible number of BSSIDs per AP,
is a power of 2 */
typedef unsigned char UINT8;
typedef unsigned short int UINT16;
struct _tim
{
UINT8 Element_id;
UINT8 IELength;
UINT8 DtimCount;
UINT8 DtimPeriod;
UINT8 BitMapControl;
UINT8 PartialVirtualBitMap [VBM_SIZE];
};
UINT8 virtualBitMap [VBM_SIZE];
UINT8 mcast_pending [MAX_BSSIDS] = {0};
UINT8 dtimCount [MAX_BSSIDS] = {0};
UINT8 dtimPeriod [MAX_BSSIDS] = {5};
void
Build_TIM (struct _tim *Tim, char TIM_method, UINT16 numBssids)
{
UINT8 octetIndex = 0;
UINT8 octetIndex0 = 0;
UINT8 octetIndex1 = 0;
UINT8 offset = 0;
UINT8 lengthOfPartialVirtualBitMap = 0;
UINT8 bcast_octet = 0;
3462
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
UINT8 bcast_bit = 0;
UINT8 max_bcast_octetIndex = 0;
UINT16 bssidIndex = 0;
UINT16 N2 = 0;
/* Compute the largest octet_index for bcast indication */
max_bcast_octetIndex = (numBssids - 1) / 8;
/* Initialize PartialVirtualBitMap */
for (octetIndex = 0; octetIndex < VBM_SIZE; octetIndex++)
Tim->PartialVirtualBitMap [octetIndex] = 0;
octetIndex = 0;
if (numBssids == 1)
{
/* Find the first nonzero octet in the Partial Virtual Bitmap */
for (octetIndex = 0; ((virtualBitMap [octetIndex] == 0) &&
(octetIndex < VBM_SIZE));
octetIndex++)
/* empty */ ;
if (octetIndex < VBM_SIZE)
offset = octetIndex & 0xFE;
/* Find the last nonzero octet in the Partial Virtual Bitmap */
for (octetIndex = (VBM_SIZE - 1); ((virtualBitMap [octetIndex] == 0) &&
(octetIndex > 0));
octetIndex--)
/* empty */ ;
lengthOfPartialVirtualBitMap = octetIndex - offset + 1;
Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE;
Tim->BitMapControl = offset;
/* Copy the virtual Bitmap octets that are nonzero */
/* Note: A NULL virtualBitMap will still add a single octet of 0 */
for (octetIndex = 0;
octetIndex < lengthOfPartialVirtualBitMap; octetIndex++)
Tim->PartialVirtualBitMap [octetIndex] =
virtualBitMap [offset + octetIndex];
}
if (numBssids > 1)
{
/* Update the broadcast/multicast bits, when numBssids > 1 */
for (bssidIndex = 1; bssidIndex < numBssids; bssidIndex++)
{
bcast_octet = (bssidIndex >> 3) & 0xff;
bcast_bit = 0x01 << (bssidIndex & 0x07);
if (mcast_pending [bssidIndex])
virtualBitMap [bcast_octet] |= bcast_bit;
else
virtualBitMap [bcast_octet] &= ~bcast_bit;
}
for (octetIndex0 = 0;
(octetIndex0 < VBM_SIZE) && (virtualBitMap [octetIndex0] == 0);
octetIndex0++)
/* empty */ ;
/* Partial virtual bitmap (PVB) contains neither bcast nor
buffered ucast traffic, PVB is a single all-0 octet */
if (octetIndex0 == VBM_SIZE)
{
lengthOfPartialVirtualBitMap = 1;
offset = 0;
Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE;
Tim->BitMapControl = offset;
Tim->PartialVirtualBitMap [0] = virtualBitMap [0];
}
for (octetIndex1 = (max_bcast_octetIndex + 1);
((octetIndex1 < VBM_SIZE) && (virtualBitMap [octetIndex1] == 0));
octetIndex1++)
/* empty */ ;
/* PVB only contains bcast indication, no buffered ucast traffic */
if ((octetIndex1 == VBM_SIZE) && (octetIndex0 < VBM_SIZE))
3463
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
{
lengthOfPartialVirtualBitMap = max_bcast_octetIndex + 1;
offset = 0;
Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE;
Tim->BitMapControl = offset;
for (octetIndex = 0;
octetIndex < (max_bcast_octetIndex + 1);
octetIndex++)
/* empty */ ;
Tim->PartialVirtualBitMap [octetIndex] =
virtualBitMap [octetIndex];
}
/* PVB contains ucast indication with or without buffered bcast traffic */
for (octetIndex = 0;
octetIndex < (max_bcast_octetIndex + 1);
octetIndex++)
Tim->PartialVirtualBitMap [octetIndex] = virtualBitMap [octetIndex];
if ((octetIndex1 < VBM_SIZE) && (octetIndex0 < VBM_SIZE))
{
if (TIM_method == 'A')
{
offset = 0;
for (octetIndex = (VBM_SIZE - 1);
(virtualBitMap [octetIndex] == 0) &&
(octetIndex > (max_bcast_octetIndex + 1));
octetIndex--)
/* empty */ ;
N2 = octetIndex;
lengthOfPartialVirtualBitMap = N2 - offset + 1;
for (octetIndex = (max_bcast_octetIndex + 1);
(octetIndex <= N2); octetIndex++)
Tim->PartialVirtualBitMap [octetIndex] =
virtualBitMap [octetIndex];
Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE;
Tim->BitMapControl = offset;
}
if (TIM_method == 'B')
{
offset = octetIndex1 - (max_bcast_octetIndex + 1);
offset = offset & 0xFE;
/* The result of (max_bcast_octetIndex + 1) + offset is equal
to N1 that is described in 9.4.2.6 for the TIM element. */
for (octetIndex = (VBM_SIZE - 1);
((virtualBitMap [octetIndex] == 0) &&
(octetIndex > (max_bcast_octetIndex + 1)));
octetIndex--)
/* empty */ ;
N2 = octetIndex;
lengthOfPartialVirtualBitMap = N2 - offset + 1;
for (octetIndex = (max_bcast_octetIndex + 1);
octetIndex <= (lengthOfPartialVirtualBitMap - 1);
octetIndex++)
Tim->PartialVirtualBitMap [octetIndex] =
virtualBitMap [offset + octetIndex];
Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE;
Tim->BitMapControl = offset;
}
}
}
Tim->Element_id = TIM_ELEMENT_ID;
Tim->DtimCount = dtimCount [0];
Tim->DtimPeriod = dtimPeriod [0];
/* Update broadcast/ multicast indication bit for transmitted
BSSID if necessary */
if ((Tim->DtimCount == 0) && mcast_pending [0])
Tim->BitMapControl |= 0x01;
}
void
Update_VirtualBitMap (UINT16 station_id, UINT8 Action)
3464
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
{
UINT16 aid = station_id;
UINT8 aid_octet;
UINT8 aid_bit;
if ((aid > 0) && (aid < AID_SIZE))
{
/* Get AID position in the Partial Virtual Bitmap. */
aid_octet = (aid >> 3) & 0xff;
aid_bit = 0x01 << (aid & 0x07);
if (Action == REMOVE_TIM_BIT)
virtualBitMap [aid_octet] &= ~aid_bit;
else
virtualBitMap [aid_octet] |= aid_bit;
}
}
int
main (void)
{
struct _tim Tim;
UINT8 ExampleCase;
UINT16 count = 0;
char TIM_method;
UINT16 numBssids = 1;
/* The value of ExampleCase depends on the test case,
allowed values are 1 to 22 */
ExampleCase = 1;
/* The value of TIM_method depends on the method to use,
allowed values are 'A' and 'B' */
TIM_method = 'A';
switch (ExampleCase)
{
/* Nine examples with numBssids = 1,
no difference between Method A and B */
case 1:
mcast_pending [0] = 0;
Update_VirtualBitMap (2, ADD_TIM_BIT);
Update_VirtualBitMap (7, ADD_TIM_BIT);
break;
case 2:
mcast_pending [0] = 1;
Update_VirtualBitMap (2, ADD_TIM_BIT);
Update_VirtualBitMap (7, ADD_TIM_BIT);
Update_VirtualBitMap (22, ADD_TIM_BIT);
Update_VirtualBitMap (24, ADD_TIM_BIT);
break;
case 3:
mcast_pending [0] = 1;
Update_VirtualBitMap (24, ADD_TIM_BIT);
break;
case 4:
mcast_pending [0] = 0;
Update_VirtualBitMap (3, ADD_TIM_BIT);
Update_VirtualBitMap (37, ADD_TIM_BIT);
Update_VirtualBitMap (43, ADD_TIM_BIT);
break;
case 5:
mcast_pending [0] = 0;
Update_VirtualBitMap (35, ADD_TIM_BIT);
break;
case 6:
mcast_pending [0] = 0;
Update_VirtualBitMap (43, ADD_TIM_BIT);
break;
case 7:
mcast_pending [0] = 0;
Update_VirtualBitMap (35, ADD_TIM_BIT);
Update_VirtualBitMap (35, REMOVE_TIM_BIT);
3465
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
break;
case 8:
mcast_pending [0] = 1;
Update_VirtualBitMap (13, ADD_TIM_BIT);
Update_VirtualBitMap (43, ADD_TIM_BIT);
Update_VirtualBitMap (63, ADD_TIM_BIT);
Update_VirtualBitMap (73, ADD_TIM_BIT);
break;
case 9:
mcast_pending [0] = 1;
Update_VirtualBitMap (2007, ADD_TIM_BIT);
break;
/* Thirteen examples with numBssids > 1, TIM_method = 'A' or 'B' */
case 10:
numBssids = 8;
Update_VirtualBitMap (9, ADD_TIM_BIT);
Update_VirtualBitMap (11, ADD_TIM_BIT);
break;
case 11:
numBssids = 8;
mcast_pending [0] = 1;
mcast_pending [3] = 1;
Update_VirtualBitMap (12, ADD_TIM_BIT);
Update_VirtualBitMap (17, ADD_TIM_BIT);
Update_VirtualBitMap (22, ADD_TIM_BIT);
Update_VirtualBitMap (24, ADD_TIM_BIT);
break;
case 12:
numBssids = 16;
mcast_pending [3] = 1;
Update_VirtualBitMap (39, ADD_TIM_BIT);
break;
case 13:
numBssids = 8;
mcast_pending [5] = 1;
mcast_pending [7] = 1;
Update_VirtualBitMap (23, ADD_TIM_BIT);
break;
case 14:
numBssids = 8;
mcast_pending [2] = 1;
mcast_pending [7] = 1;
Update_VirtualBitMap (10, ADD_TIM_BIT);
break;
case 15:
numBssids = 15;
mcast_pending [5] = 1;
mcast_pending [7] = 1;
Update_VirtualBitMap (2007, ADD_TIM_BIT);
break;
case 16:
numBssids = 15;
mcast_pending [5] = 1;
mcast_pending [7] = 1;
Update_VirtualBitMap (1997, ADD_TIM_BIT);
Update_VirtualBitMap (1999, ADD_TIM_BIT);
break;
case 17:
numBssids = 32;
for (count = 0; count < numBssids; count += 2)
mcast_pending [count] = 1;
Update_VirtualBitMap (32, ADD_TIM_BIT);
Update_VirtualBitMap (33, ADD_TIM_BIT);
Update_VirtualBitMap (39, ADD_TIM_BIT);
break;
case 18:
numBssids = 14;
mcast_pending [5] = 1;
mcast_pending [7] = 1;
break;
3466
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
case 19:
numBssids = 14;
mcast_pending [0] = 1;
mcast_pending [12] = 1;
break;
case 20:
numBssids = 15;
Update_VirtualBitMap (38, ADD_TIM_BIT);
break;
case 21:
numBssids = 15;
mcast_pending [0] = 1;
Update_VirtualBitMap (44, ADD_TIM_BIT);
break;
case 22:
numBssids = 16;
break;
default:
break;
}
Build_TIM (&Tim, TIM_method, numBssids);
printf ("\nCase = %d, method %c.\n", ExampleCase, TIM_method);
printf ("numBssids = %d.\n", numBssids);
printf ("Element_id = %d.\n", Tim.Element_id);
printf ("IELength = %d.\n", Tim.IELength);
printf ("DtimCount = %d.\n", Tim.DtimCount);
printf ("DtimPeriod = %d.\n", Tim.DtimPeriod);
printf ("BitMapControl = 0x%02X\n", Tim.BitMapControl);
if (Tim.IELength - TIM_BASE_SIZE > 0)
{
int octetIndex;
for (octetIndex = 0;
octetIndex < Tim.IELength - TIM_BASE_SIZE;
octetIndex++)
printf ("PartialVirtualBitMap [%d] = 0x%02X\n", octetIndex,
Tim.PartialVirtualBitMap [octetIndex]);
}
return 0;
}
/* The End. */
3467
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex M
(informative)
Integration function
M.1 Introduction
The purpose of this annex is to guide the implementor of an ESS’s infrastructure that includes a portal that
integrates the ESS’s infrastructure with a wired LAN.
M.2 Ethernet V2.0/IEEE 802.3 LAN integration function
It is recommended that any ESS’s infrastructure that logically incorporates a portal that integrates the ESS’s
infrastructure with an Ethernet V2.0/IEEE 802.3 LAN use the procedures defined in ISO/IEC Technical
Report 11802-5:1997 (previously known as IEEE Std 802.1H-1997), with the two-entry selective translation
table (STT) shown in Table M-1, to perform the integration service. Note that the majority of such
IEEE 802.11 implementations currently use this STT, rather than the single-entry STT recommended in
Annex A of IEEE Std 802.1H-1997 [B24].
Table M-1—IEEE 802.11 integration service STT
Encoding in Type field
Ethernet
Protocol use
type value
First octet Second octet
AppleTalk Address Resolution Protocol 0x80F3 80 F3
Novell NetWare Internetwork Packet exchange (IPX) 0x8137 81 37
M.3 Example
The tables below illustrate the translations performed by the integration service using the encapsulation/
decapsulation procedures defined in ISO/IEC Technical Report 11802-5:1997 with the IEEE 802.11
integration service STT. These tables show how the octets in an IEEE 802.11 MSDU correspond to the
octets in the Ethernet/IEEE 802.3 MSDU that represents the same LLC SDU on the integrated Ethernet/
IEEE 802.3 LAN. Table M-2 shows the encapsulation example, and Table M-3 shows the decapsulation
example.
In the tables below the rows that have a 81-00 Type/Length field value represent bridging between an
Ethernet/IEEE 802.3 LAN and an IEEE 802.11 LAN. Both LANs are carrying VLAN-tagged MSDUs (User
Priority=4, DEI=0, VLAN ID=1893).
3468
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table M-2—Ethernet/IEEE 802.3 to IEEE 802.11 translation
Type /
Protocol LLC header IEEE 802.11 LLC header
Length
IP 08-00 — AA-AA-03-00-00-00-08-00
IP 802.3a length AA-AA-03-00-00-00-08-00 AA-AA-03-00-00-00-08-00
IP ARP 08-06 — AA-AA-03-00-00-00-08-06
AppleTalk (1) 80-9B — AA-AA-03-00-00-00-80-9B
AppleTalk (2) length AA-AA-03-08-00-07-80-9B AA-AA-03-08-00-07-80-9B
AppleTalk AARP (1) 80-F3 — AA-AA-03-00-00-F8-80-F3
AppleTalk AARP (2) length AA-AA-03-00-00-00-80-F3 AA-AA-03-00-00-00-80-F3
IPX Ethernet II 81-37 — AA-AA-03-00-00-F8-81-37
IPX SNAP length AA-AA-03-00-00-00-81-37 AA-AA-03-00-00-00-81-37
IPX 802.2 length E0-E0-03 E0-E0-03
IPX 802.3b length FF-FF FF-FF
VLAN-tagged IP 81-00 87-65-08-00 AA-AA-03-00-00-00-81-00-87-65-
AA-AA-03-00-00-00-08-00c
aThis format of IP packet over IEEE Std 802.3 is deprecated, and the change to the canonical Ethernet IP format is not
considered harmful.
bThe
use of this nonstandard format happens to work with these rules, even though the FF-FF is not actually a valid
LLC header value. (The broadcast LSAP is not valid as a source SAP in LLC. See IEEE Std 802.2.)
cThe sequence of octets AA-AA-03-00-00-00-81-00-87-65 represents the SNAP-encoded VLAN header. The
sequence of octets AA-AA-03-00-00-00-08-00 represents the IEEE 802.1H™-translated Type/Length field, using
the same translation as the untagged IP MSDU on the first line of Table M-2.
Table M-3—IEEE 802.11 to Ethernet/IEEE 802.3 translation
Type /
Protocol IEEE 802.11 LLC header LLC header
Length
IP AA-AA-03-00-00-00-08-00 08-00 —
IP 802.3a AA-AA-03-00-00-00-08-00 length —
IP ARP AA-AA-03-00-00-00-08-06 08-06 —
AppleTalk (1) AA-AA-03-00-00-00-80-9B 80-9B —
AppleTalk (2) AA-AA-03-08-00-07-80-9B length AA-AA-03-08-00-07-80-9B
AppleTalk AARP (1) AA-AA-03-00-00-F8-80-F3 80-F3 —
AppleTalk AARP (2) AA-AA-03-00-00-00-80-F3 length AA-AA-03-00-00-00-80-F3
IPX Ethernet II AA-AA-03-00-00-F8-81-37 81-37 —
3469
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table M-3—IEEE 802.11 to Ethernet/IEEE 802.3 translation (continued)
Type /
Protocol IEEE 802.11 LLC header LLC header
Length
IPX SNAP AA-AA-03-00-00-00-81-37 length AA-AA-03-00-00-00-81-37
IPX 802.2 E0-E0-03 length E0-E0-03
IPX 802.3 FF-FF length FF-FF
VLAN-tagged IP AA-AA-03-00-00-00-81-00-87-65- 81-00 87-65-08-06
ARP AA-AA-03-00-00-00-08-06
a
This format of IP packet does not survive the trip across the non-IEEE-802.3 LAN intact.
M.4 Integration service versus bridging
There are a number of differences between the IEEE 802.11 integration service and the service provided by
an IEEE 802.1D bridge [B23]. In the IEEE 802.11 architecture a portal provides the minimum connectivity
between an IEEE 802.11 WLAN and a non-IEEE-802.11 LAN. Requiring an IEEE 802.1D bridge in order
to be compliant with IEEE Std 802.11 would unnecessarily render some implementations noncompliant.
The most important distinction is that a portal has only one “port” (in the sense of IEEE Std 802.1D, for
example) through which it accesses the DS. This renders it unnecessary to update bridging tables inside a
portal each time a STA changes its association status. In other words, the details of distributing MSDUs
inside the IEEE 802.11 WLAN need not be exposed to the portal.
Another difference is that the DS is not an IEEE 802 LAN (although it carries IEEE 802 LLC SDUs).
Requiring that the DS implements all behaviors of an IEEE 802 LAN places an undue burden on the
architecture.
Finally, it is an explicit intent of this standard to permit transparent integration of an IEEE 802.11 WLAN
into another non-IEEE-802.11 LAN, including passing bridge PDUs through a portal. While an implementer
might wish to attach an IEEE 802.1D bridge to the portal (note that the non-IEEE-802.11 LAN interface on
the bridge need not be any particular type of LAN), it is not an architectural requirement of this standard to
do so.
3470
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex N
(informative)
AP functional description
N.1 Introduction
This informative annex seeks to clarify the AP functional description. At times there is some confusion
surrounding the term AP and the relation of that term to the AP functions and common implementations of
AP devices. The core IEEE 802.11 conceptual definitions that surround the AP (refer to Clause 4) are
abstract (and can sometimes cause confusion), but Clause 4 definitions are crafted to be flexible and hence
serve to allow the adaptation and extension of this standard in a wide variety of ways.
In this annex a wireless local area network (WLAN) system is a system that includes the distribution system
(DS), access point (AP), and portal entities. It is also the logical location of distribution and integration
service functions of an extended service set (ESS). A WLAN system contains an optional portal and one or
more APs in addition to the DS.
N.2 Terminology
An enhanced description of these access entities begins with clarification of several terms.
This standard defines an entity called a STA. STAs can operate in different modes. The possible operational
modes of a STA are:
a) Infrastructure mobile STAs
b) Independent mobile STAs
c) Access control mode STAs
d) Mesh STAs
The mobile STAs are the STA entities that are ordinarily moving around, but might also be in a fixed
location. The mobile adjective prefix often helps in visualizing the type of STA under discussion.
Infrastructure mobile STAs operate in infrastructure BSS mode, i.e., they are the users of an AP. Devices
that incorporate an infrastructure mobile STA are referred to in this annex by the term mobile unit. A mobile
unit device might consist of just a mobile STA implementation, but also likely includes an SME and a client.
The exact configuration of the mobile unit it is not relevant to the descriptions in this annex.
Independent mobile STAs operate in IBSS mode. Independent mobile STAs form autonomous networks
that do not require an AP.
A STA can also form an integral part of an AP. To do so, the STA operates in access control mode. This type
of STA is called an access control mode STA (ACM_STA).
The primary function of an AP is to provide the mobile units with access to the DS, as shown in the Unified
Modeling Language (UML) use case diagram in Figure N-1. Complete UML specifications can be found in
Rumbaugh [B57]. The UML diagram shows a system boundary box containing a single use case (ellipse).
Entities that are outside the system boundary box are shown as stick people. These external entities represent
the actors (formal term), or users, of the system. Since the actors are outside the system boundary, their
3471
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
internal behavior is not described (i.e., it is out of scope for the current view). Instead, references to the
external entities are limited to descriptions of their interactions with, and expectations of, the system, which
is accomplished by describing the use cases and scenarios (i.e., functions) of the system and later (in
Figure N-4) a decomposition of the entities (objects and behaviors) within the system that provide that
functionality. The use case diagram employs connecting lines to indicate relationships between the various
artifacts present in the diagram. Relationship lines lacking arrows on both ends indicate that there is a
bidirectional relationship between the artifacts.
Figure N-1—Very high level UML use case diagram for the AP
The DS enables communication between mobile units and the construction of collections of APs. To enable
communication between mobile units and a non-IEEE-802.11 LAN entity requires the presence of a
(logical) portal from the DS to the non-IEEE-802.11 LAN.
Often the functions of an AP (which includes an ACM_STA), a DS, and a portal, are combined into a single
device, referred to in this annex as an access unit (AU). While reference to that basic implementation is
commonplace, it is helpful to discuss the abstract case: a WLAN system. The WLAN system includes the
DS, an optional portal, APs, and the AP’s STAs. It is also the logical location of distribution and integration
service functions of an ESS. An infrastructure WLAN system contains one or more APs and zero or one
portal in addition to the DS.
The primary function of a WLAN system is to provide the mobile units with access to the non-IEEE-802.11
LAN, as shown in Figure N-2. A secondary function is to provide the mobile units with access to each other.
Figure N-2—Very high level UML use case diagram for the WLAN system
3472
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The primary functions of the WLAN system can be further characterized as follows:
a) Provide non-IEEE-802.11 LAN access.
1) Includes mobile unit validation.
2) Includes moving data between the mobile units and the non-IEEE-802.11 LAN.
i) Uses a special data movement function called filtering data.
b) Configure the system.
Those high-level use cases of the WLAN system are shown in the UML use case diagram in Figure N-3. The
UML diagram shows multiple use cases with two types of relationships between those use cases: include
and generalization. The include relationship “includes” functionality in one use case that is described by
another use case. The “provide LAN Access” use case includes the functionality of the “Validate mobile
unit” use case. The generalization relationship indicates that one use case is a more general form of another
use case. The relationship line with a hollow triangle at the end indicates that the “Move Data” use case is a
more generalized form of the “Filter Data” use case. Or, equivalently, “Filter Data” is a more specialized
form of “Move Data.” The constraint artifact (in the lower left corner of the diagram) requires the WLAN
system and the mobile units to be set to the same SSID.
Figure N-3—High-level UML use case diagram for the WLAN system
The primary functions of the WLAN system, depicted in the UML object model diagram in Figure N-4, are
provided by the AP, and DS entities, the latter via the DSSs. The portal is merely a conceptual link from the
DS to the non-IEEE-802.11 LAN. The UML object model diagram shows a package containing a set of
object classes. References to the actors (external entities) are limited to descriptions of their interactions
3473
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
with, and expectations of, the object classes, which is accomplished by describing the attributes and
behaviors of the class entities. The object model diagram uses connecting lines to indicate interfaces (called
associations in UML terminology) between the various artifacts present in the diagram. UML association
lines lacking arrows on both ends indicate that there is a bidirectional interface between the artifacts. The
UML association lines are annotated with multiplicity counts to indicate the how many entities might fill the
position at that end of the association.
Figure N-4—High-level UML entity diagram for the WLAN system
Figure N-4 also shows the relationships between the WLAN system entities. There exists a bidirectional
association between zero or more [0..*] mobile units and a single (given) ACM_STA. The solid diamond
terminated line indicates that there is a composition relationship between the ACM_STA and the AP, i.e.,
the AP is composed of (or always has an) ACM_STA. Hence there is a one-to-one mapping between APs
and ACM_STAs. This composition and one-to-one relationship can also be drawn as shown in Figure N-5.
These two forms are equivalent. There are one or more [1..*] APs connected to a single DS. The DS in turn
connects to zero or one [0..1] portal. The portal connects to a single non-IEEE-802.11 LAN.
3474
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure N-5—AP UML composition diagram (alternate syntax)
N.3 Primary ACM_STA functions
The primary functions of an ACM_STA are as follows:
a) Instantiate the infrastructure BSS.
b) Move data between the mobile units and the AP.
Instantiating the infrastructure BSS consists of advertising the BSS and defining timing for the entire BSS
(i.e., infrastructure mode TSF). Advertising the BSS includes creating an infrastructure mode Beacon frame,
transmitting that Beacon frame, and replying to mobile unit probe requests with corresponding probe
response transmissions. Beacon frames and probe responses provide a way for the mobile units to find, join
with the ACM_STA, and (subsequently) associate with the AP. This includes, for example, the AP
providing channel, regulatory, and country information to the mobile units.
Moving data between the mobile units and the AP consists of translating between MSDUs and MPDUs,
buffering data, and transmitting/receiving MPDUs via an IEEE 802.11 PHY.
N.4 Primary AP functions
The primary functions of an AP are as follows:
a) Provide DS access for the mobile units.
1) Includes mobile unit validation and extends (in some cases) to notifying the DS.
2) Includes moving data between the mobile units and the DS.
i) Uses a special data movement function called data filtering.
b) Configure the AP (both the AP itself and the included ACM_STA).
Those high-level use cases of the AP are shown in the UML use case diagram in Figure N-6. The UML
extend relationship “extends” a use case with optional functions provided by another use case that are
applied only in some scenarios. In Figure N-6, the “Notify the DS” use case extends the “Validate mobile
unit” use case in some scenarios.
3475
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Figure N-6—High-level UML use case diagram for the AP
The AP provides DS access for the mobile units, including validating the mobile units (e.g., via STA and/or
client authentication) and providing access and admission control (e.g., via the association process). An AP
is literally a point of access to the DS (and, by extension, to the non-IEEE-802.11 LAN beyond). Upon
validating a mobile unit, the AP updates the DS mapping of the mobile unit to the AP. DS mapping updates
can, for example, be based on (re)association requests (received from the ACM_STA) or aging of inactive
links (based on session timers). An AP might also receive access control updates directly from other APs,
via a protocol outside the scope of this standard, in the form of inter-AP notifications of mobile unit
association events and transitions. In this way, mobile unit validation and subsequent changes in mobile unit
access control lead to adjustments in how data are allowed to move through the AP (i.e., between the mobile
units and the DS).
Providing DS access for the mobile units also includes moving data between the mobile units and the DS,
which is accomplished by moving MSDUs between the ACM_STA and the DS (bidirectionally).
The moving data function includes “filtering data.” The filtering data function controls which MSDUs (if
any) are moved between the DS and the mobile units. For example, filtering of data to and from a particular
mobile unit is adjusted based on the various stages of validation of that mobile unit.
The AP also provides a function for configuration. Configuring the AP includes configuring the AP itself as
well as the included ACM_STA. For example, configuration might include setting the local values of the
SSID, PHY channel, beacon interval, and so on.
3476
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
N.5 Primary DS functions
The primary functions of the DS (i.e., the DSSs) are as follows:
a) Map mobile unit to AP (for DS-to-mobile unit traffic delivery).
b) Move data.
The DS’s mobile unit-to-AP map determines which AP is to be used for a given mobile unit’s data delivery.
This function includes mapping update adjustments, which are based on notification from the APs, of
changes in mobile unit access control.
Moving data consists of moving MSDUs among the APs (including returning MSDUs to the source AP for
mobile unit-to-mobile unit communications) and between the APs and the portal.
N.6 Primary portal function
The primary function of a portal is as follows:
a) Move data with a special data movement function called data transformation.
Moving data consists of moving MSDUs between the DS and the external non-IEEE-802.11 LAN. Moving
data through the portal transforms the MSDUs using the integration function. The integration function
translates external non-IEEE-802.11-LAN MSDUs to and from IEEE 802.11 MSDUs using, for example,
the procedures defined in Annex M.
3477
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex O
(informative)
Additional VHT and HT information
O.1 VHT and HT waveform generator tool
As an informative extension to this standard, waveform generator tools have been written to model the PHY
transmission process described in Clause 17, Clause 18, Clause 19, and Clause 21.
The waveform generator can be downloaded from the public IEEE 802.11 document website. The waveform
generator code that includes Clause 17, Clause 18, and Clause 19 is contained in document 11-06/1715, and
the waveform generator description is contained in document 11-06/1714 (HT code). A description of the
waveform generator that includes Clause 17, Clause 19, and Clause 21 and the waveform generator code
itself may be found in document 11-11/0517 (VHT code).
The purpose of these tools is to promote common understanding of complex PHY algorithms, facilitate
device interoperability by providing reference test vectors, and assist researchers in industry and academia to
develop next generation wireless solutions.
The code is written in the MATLAB computing language and can be configured to generate test vectors for
most PHY configurations, defined by this standard. Instructions on how to configure and run the tools are
specified in the referenced documents.
A command line interface is used to configure the VHT code tool. For consistency with this standard, the
configuration interface is made very similar to the TXVECTOR parameters defined in 21.2.2.
A command line interface and graphic user interface (GUI) exist to configure the HT code tool. For
consistency with this standard, the configuration interface is made very similar to the TXVECTOR
parameters defined in 19.2.2.
The waveform generator tool produces test vectors for all transmitter blocks, defined in Figure 19-2 and
Figure 19-3, generating reference samples in both frequency and time domains. Outputs of the tool are time
domain samples for all transmitting chains.
O.2 A-MPDU deaggregation
This subclause contains a description of the deaggregation process. Other implementations are also possible.
The receiver checks the MPDU delimiter for validity based on the CRC. It can also check that the length
indicated is within the value of the LENGTH parameter indicated in RXVECTOR.
If the MPDU delimiter is valid, the MPDU is extracted from the A-MPDU. The next MPDU delimiter is
expected at the first multiple of 4 octets immediately after the current MPDU. This process is continued until
the end of the PPDU is reached.
3478
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the MPDU delimiter is not valid, the deaggregation process skips forward 4 octets and checks to see
whether the new location contains a valid MPDU delimiter. It continues searching until either a valid
delimiter is found or the end of the PSDU is reached based on the value of the LENGTH parameter indicated
in the RXVECTOR.62
An A-MPDU parsing (deaggregation) algorithm is expressed (as a C programming language snippet) in
Figure O-1.
void Parse_A_MPDU (int length)
{
int offset = 0; /* Octet offset from start of PSDU */
while (offset+4 < length)
{
if (valid_MPDU_delimiter(offset) &&
get_MPDU_length(offset) <= (length -(offset+4)))
{ /* Valid delimiter */
/* Receive the MPDU */
Receive_MPDU(offset+4, get_MPDU_length(offset));
/* advance by MPDU length rounded up to a multiple of 4 */
offset += 4 + 4*((get_MPDU_length(offset)+3)/4);
}
else /* Invalid delimiter */
{
/* Advance 4 octets and try again */
offset += 4;
}
}
}
NOTE 1—This algorithm is not optimized for efficiency.
NOTE 2—The delimiter signature can be used to reduce the amount of computation required while scanning
for a valid delimiter. In this case, the receiver tests each possible delimiter for a matching Delimiter
Signature field. Only when a match is discovered does it then check the CRC.
Figure O-1—A-MPDU parsing
62
This procedure occasionally wrongly interprets a random bit-pattern as a valid delimiter. When this happens, the MAC attempts to
interpret a random MPDU. The MAC discards it with a high probability based on a check of the FCS field.
3479
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
O.3 Example of an RD exchange sequence
Figure O-2 shows an example of the operation of the RD rules, defined in 10.28.
Remaining TXOP
Duration (t)
Remaining TXOP
Duration (t0)
Remaining TXOP
Duration (t1)
PPDU addressed to
PPDU addressed to PPDU addressed to
STA B
STA C STA C
Duration/ID = t
Duration/ID = t0 Duration/ID = t1
Data + HTC
Data + HTC
Data + HTC
(RDG = 1)
(RDG = 1)
(RDG = 1)
BA + HTC
(RDG =1)
Data
Data
BA
BA
STA A
Response Burst
Data + HTC (More
Data + HTC (More
BA + HTC (More
PPDU = 1)
PPDU = 0)
PPDU = 0)
Data
STA B
Response Burst Response Burst
Data + HTC (More
Data + HTC (More
Data + HTC (More
BA + HTC (More
PPDU = 0)
PPDU = 0)
PPDU = 0)
PPDU = 0)
Data
STA C
Figure O-2—Example of RD exchange sequence showing response burst
The following is a summary of Figure O-2:
a) STA A (acting as RD initiator) transmits a PPDU containing MPDUs addressed to STA B (acting as
RD responder). The Ack Policy field of the QoS Data frames in this PPDU is set to Implicit Block
Ack Request. One or more MPDUs within this PPDU include an HT Control field with the RDG/
More PPDU subfield set to 1, indicating an RDG. The Duration/ID field of MPDUs within the
PPDU contains the remaining duration of the TXOP, t s.
b) STA B (the RD responder) responds with the transmission of a +HTC BlockAck frame in which the
RDG/More PPDU subfield is set to 1, indicating that another PPDU will follow a SIFS or RIFS after
the end of the PPDU containing the BlockAck frame.
c) STA B transmits a PPDU (the second PPDU of an RD response burst) to STA A, with the Ack
Policy field of its QoS Data frames set to Implicit Block Ack Request and containing one or more
+HTC MPDUs in which the RDG/More PPDU subfield is set to 0, indicating that this is the last
PPDU in the response burst.
d) STA A (the RD initiator) regains control of the TXOP and transmits a BlockAck frame addressed to
STA B to acknowledge the MPDUs transmitted by STA B in the RD response burst.
e) STA A (the RD initiator) transmits a PPDU containing MPDUs addressed to STA C (acting as RD
responder). The Ack Policy field of the QoS Data frames in this PPDU is set to Implicit Block Ack.
This PPDU includes one or more +HTC MPDUs in which the RDG/More PPDU subfield is set to 1,
indicating an RDG. The Duration/ID field of MPDUs in the PPDU contains the remaining duration
of the TXOP, t0 s.
3480
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
f) STA C (the RD responder) transmits a PPDU to STA A, containing one or more +HTC MPDUs
with the RDG/More PPDU subfield set to 0, indicating that this is the last PPDU in the response
burst. This PPDU contains a BlockAck frame that is a response to the implicit block ack request of
the previous PPDU, plus QoS Data frames with the Ack Policy field set to Implicit Block Ack.
g) STA A (the RD initiator) regains control of the TXOP and transmits a BlockAck frame to STA C
that acknowledges the MPDUs transmitted by STA C. This PPDU contains one or more +HTC
MPDUs with the RDG/More PPDU subfield set to 1, indicating an RDG. The Duration/ID field of
MPDUs in the PPDU contains the remaining duration of the TXOP, t1 s.
h) STA C (the RD responder) transmits a PPDU to STA A, containing QoS data +HTC MPDUs with
the Ack Policy field set to Implicit Block Ack Request and the RDG/More PPDU subfield set to 0.
This is the only PPDU in the RD response burst.
i) STA A transmits a BlockAck frame to STA C that acknowledges the MPDUs transmitted by STA C
in the RD response burst.
O.4 Illustration of determination of NDP addresses
Determination of NDP SA and DA are illustrated in Figure O-3 and Figure O-4.
MPDU with two or more addresses
HT NDP Announcement =1
... RA1 TA1 ... NDP NDP ...
Calibration Position =0
Address 1 Address 2 HTC
Destination address of each NDP = RA1
Source address of each NDP = TA1
MPDU requiring an immediate response
HT NDP Announcement =1 NDP Destination address = RA1
... RA1 TA1 ... NDP
Calibration Position =0 NDP Source address = TA1
Address 1 Address 2 HTC Response
RA HT NDP Announcement =0
... ...
2 Calibration Position =0
Address 1 HTC
MPDU requiring an immediate response
Destination address of each NDP = RA2 (HT NDP Announcement=1)
HT NDP Announcement =0
... RA1 TA1 ... Source address of each NDP = RA1
Calibration Position =0
(there is no Address 2 field in the HT NDP announcement in this example)
Address 1 Address 2 HTC Response
RA HT NDP Announcement =1
... ... NDP NDP ...
2 Calibration Position =0
Address 1 HTC
Figure O-3—Determination of NDP source and destination for unidirectional NDP sequences
3481
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Destination address of first NDP = RA
MPDU containing two or more addresses Destination address of second NDP = TA
Source address of first NDP = TA
HT NDP Announcement =1 Source address of second NDP = RA
... RA TA ... NDP1
Calibration Position =1
Optional response
Address 1 Address 2 HTC
HT NDP Announcement =0
... ... NDP2
Calibration Position =2
HTC
Figure O-4—Determination of NDP source and destination for bidirectional NDP sequence
O.5 20/40 MHz BSS establishment and maintenance
O.5.1 Signaling 20/40 MHz BSS capability and operation
A BSS that occupies 40 MHz of bandwidth and that is administered by an HT AP is called a 20/40 MHz
BSS.
An HT AP that has dot11FortyMHzOperationImplemented equal to true sets the Supported Channel Width
Set subfield of the HT Capabilities element to a nonzero value. The AP might also operate a 20/40 MHz
BSS. The Supported Channel Width Set subfield of the HT Capabilities element that is transmitted by the
AP indicates the possible operating mode of the BSS and of the AP, but the value in this field is not an
indication of the current BSS bandwidth of either the AP or the BSS.
An HT AP signals the operating width of the BSS through the Secondary Channel offset field of the HT
Operation element. A nonzero value in this field indicates that a secondary channel exists; in other words,
the BSS is a 20/40 MHz BSS. A value of 0 in this field indicates that the BSS is operating as a 20 MHz BSS.
An HT AP that has dot11FortyMHzOperationActivated equal to true sets its STA Channel Width field of the
HT Operation element to a nonzero value. This field signals the current operating mode of the AP, not the
BSS. An HT AP might operate a 20/40 MHz BSS while it is operating as a 20 MHz device. Such a situation
would support, for example, 40 MHz bandwidth DLS traffic among associated STAs, but only 20 MHz
bandwidth traffic between STAs and the AP.
O.5.2 Establishing a 20/40 MHz BSS
Before starting a 20/40 MHz BSS, a 40MC HT AP is required by the rules defined in 11.16.5 to examine the
channels of the current regulatory domain to determine whether the operation of a 20/40 MHz BSS might
unfairly interfere with the operation of existing 20 MHz BSSs. The AP (or some of its associated HT STAs)
is required to scan all of the channels of the current regulatory domain in order to ascertain the operating
channels of any existing 20 MHz BSSs and 20/40 MHz BSSs. This type of scanning is called OBSS
scanning. The particulars of OBSS scanning are controlled by the following MIB attributes:
— dot11FortyMHzOptionImplemented
— dot112040BSSCoexistenceManagementSupport
— dot11FortyMHzIntolerant
— dot11BSSWidthTriggerScanInterval
— dot11BSSWidthChannelTransitionDelayFactor
— dot11OBSSScanPassiveDwell
— dot11OBSSScanActiveDwell
3482
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— dot11OBSSScanPassiveTotalPerChannel
— dot11OBSSScanActiveTotalPerChannel
— dot11OBSSScanActivityThreshold
Specific values for these MIB attributes are provided to set minimum scan times for passive scanning of
each channel, and a separate minimum time is provided for active scanning of each channel. A total
minimum amount of scanning per channel is required before a determination can be made to allow the
operation of a 20/40 MHz BSS.
The rules that are applied when determining whether a 20/40 MHz BSS can be established are intended to
avoid a full or partial overlap of the secondary channel of the 20/40 MHz BSS with an existing primary
channel of either a 20 MHz BSS or a 20/40 MHz BSS. The lack of partially overlapping channels in the
5 GHz band allows these rules to be written as recommendations, while in the 2.4 GHz band, they are
requirements.
An additional constraint on establishing a 20/40 MHz BSS includes the allowance for any IEEE 802.11
device to explicitly prohibit the operation of the 20/40 BSS mode due to other considerations. For example,
if an IEEE 802.15.1™ WPAN device is operating in the area, that device is likely to be unable to
communicate successfully with a paired receiver if the number of available IEEE 802.15.1 WPAN channels
falls below a given threshold. Operation of a 20/40 MHz BSS in the 2.4 GHz band can contribute to the
reduction of the number of available IEEE 802.15.1 WPAN channels, possibly pushing the available
channels below that threshold.
To promote sharing of the spectrum resource under such circumstances, it might be desirable to prohibit the
operation of a 20/40 MHz BSS. As such, the 20/40 BSS coexistence mechanism allows a STA to transmit
Management frames containing a value of 1 for the Forty MHz Intolerant field. (The MIB attribute
dot11FortyMHzIntolerant determines the setting of the value of the Forty MHz Intolerant field in
transmitted frames, and the setting of the value of the MIB attribute is beyond the scope of this standard.)
Receivers of such frames on any channel in the band are not allowed to establish a 20/40 MHz BSS
anywhere in the band for a duration of dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidth-
TriggerScanInterval seconds. To effect this requirement, monitoring STAs and APs maintain a countdown
timer to indicate that a prohibition is in force. The countdown timer is reloaded with the value
dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidthTriggerScanInterval seconds each time
that the STA or AP observes a Management frame containing a value of 1 for the Forty MHz Intolerant field.
STAs communicate changes in their countdown counter (i.e., transitions between a zero value and a nonzero
value) to their associated AP through the 20 MHz BSS Width Request field of the 20/40 BSS Coexistence
Management frame.
O.5.3 Monitoring channels for other BSS operation
Some of the STAs that are associated with a 20/40 MHz BSS perform monitoring so that the conditions
which allowed the establishment of the 20/40 MHz BSS do not change to conditions that would disallow the
existence of the 20/40 MHz BSS.
Monitoring STAs keep a local record of channels that are in use by other BSSs. STAs that receive Beacon
frames determine the primary channel by examining the DSSS Parameter Set element. Secondary channel
existence and channel information are determined by examining the Secondary Channel Offset field of the
20/40 BSS Coexistence element. Monitoring STAs also record receptions of frames that contain a value of 1
for the Forty MHz Intolerant field. Any changes to the local record that would create a prohibition
against 20/40 MHz BSS operation are immediately reported to the associated AP through the transmission
of a 20/40 BSS Coexistence Management frame (i.e., with the 20 MHz BSS Width Request field set to 1).
The reception of a 20 MHz BSS Width Request field equal to 1 at the AP causes the AP to switch the BSS to
20 MHz operation immediately.
3483
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Any change of a channel in use that had not previously been in use is also reported immediately within a
20/40 BSS Coexistence Management frame. The AP examines the new in-use channel information to
determine whether any changes in BSS width operation are required (i.e., to see if any changes have
occurred that indicate an overlap of the secondary channel). If a change to 20 MHz BSS operation is
required, the change occurs immediately.
Conditions that prevent the operation of a 20/40 MHz BSS might be transient. If the number of channels
in use is reduced or all STA signaling 40 MHz intolerance leave the area, an AP might choose to revert to
20/40 MHz operation, if allowed to do so. However, the conditions that allow 20/40 MHz BSS operation
have to persist for a period of dot11BSSWidthChannelTransitionDelayFactor × dot11BSSWidthTrigger-
ScanInterval seconds before a STA can signal that the conditions have changed, and the same period of time
has elapsed before an AP can resume 20/40 MHz BSS operation.
STAs that do not monitor channels through OBSS scanning and do not report any channel information or
received Forty MHz Intolerant field information to their associated AP are listed here:
— Non-HT STAs
— HT STAs that are exempt from scanning as specified in 11.16.6
— HT APs, once the 20/40 MHz BSS is established
— HT STAs that are associated with an AP whose BSS is operating on a channel that is not in the
2.4 GHz band
— HT STAs that are associated with an HT AP that is not 40-MHz-capable (as indicated by a value of
0 in the Supported Channel Width Set subfield of the HT Capabilities element)
All other HT STAs that are associated with a 40-MHz-capable HT AP whose BSS is operating on a channel
in the 2.4 GHz band monitor channels through OBSS scanning and report any channel information or
received Forty MHz Intolerant field information to their associated AP.
All MIB attributes that are employed by the 20/40 BSS Coexistence mechanism are maintained by the AP,
which has the ability to provide updates to the MIB attribute values to the associated STA by transmitting an
OBSS Scan Parameters element.
3484
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex P
(informative)
Location and Time Difference accuracy test
P.1 Location via Time Difference of arrival
The location of a device might be determined using multiple methods, including:
— Signal strength at different sensors
— Time of flight between the device and different sensors
— Time difference of arrival between the device and pairs of sensors
A typical implementation of the time difference of arrival method requires that the sensors are co-channel,
have synchronized clocks, and receive the same transmission from the device. The sensor’s time of arrival
measurements are shared, and the device location is determined via multilateration, i.e., each pair of sensor
measurements provides a time difference of arrival measurement that represents a hyperbola in 2D space of
most likely candidate locations, and the overlap of the multiple hyperbola from multiple pairs of sensors
leads to the location estimate. The single time of departure is not relevant in this typical multilateration
implementation as it is canceled out when time differences of arrival are computed.
When the sensors are on different channels, such as APs in a typical multi-channel deployment, the device
transmits on each channel and thus with multiple times of departure. In this environment it is necessary for
the device to advertise each time of departure so that it can be subtracted from the times of arrivals measured
by sensors on different channels. Furthermore, the device’s clock frequency typically does not match the
clock frequency of the synchronized sensors, and so the device should transmit on the same channel multiple
widely spaced times in order for the sensors to estimate the device’s clock frequency relative to themselves
and to be able to suitably scale the device’s advertised times of departure.
An example transmission sequence comprises frames transmitted on channels 1, 6, 11, 1 at 2.4 GHz. From
this, the device’s clock frequency can be determined relative to the synchronized APs on channel 1, and all
APs on channels 1, 6, and 11 can measure a time of arrival. These four transmissions enable a single location
calculation. The Time of Departure Accuracy test in P.2 is designed to measure errors within such a
transmission sequence that would degrade a multi-channel time difference of arrival location scheme.
P.2 Time Difference of departure accuracy test
The Time Difference of Departure accuracy test is an informative description of how time difference of
departure accuracy can be measured for any parameterizable PHY waveform. This accuracy test does not
apply when the Time of Departure timestamps are exclusively used for timing measurement (see 11.24.5).
The Time Difference of Departure accuracy test is parameterized by the following test parameters:
— TIME_OF_DEPARTURE(j,i), 1 j 500, 1 i I (scalar entries)
— MULTICHANNEL_SAMPLING_RATE (scalar)
— FIRST_TRANSITION_FIELD(j,i), 1 j 500, 1 i I (waveform entries)
— SECOND_TRANSITION_FIELD(j,i), 1 j 500, 1 i I (waveform entries)
— TRAINING_FIELD(j,i), 1 j 500, 1 i I (waveform entries)
— TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH (scalar)
3485
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
TIME_OF_DEPARTURE(j,i) is exposed externally through the TOD Timestamp field in the Time of
Departure subelement in Location Track Notification frames.
The Time Difference of Departure accuracy test is performed as follows or in an equivalent or more accurate
manner.
The Time Difference of Departure accuracy test is performed by instrumentation capable of converting
signals transmitted on one or more channels into a stream of complex samples at fs sample/s or more, with
sufficient accuracy in terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, etc, and at a
fixed delay from the transmitter. The minimum sampling rate is MULTICHANNEL_SAMPLING_RATE
sample/s respectively. A possible embodiment of such a setup is converting the signal to a low IF frequency
with a cabled microwave synthesizer, sampling the signal with a digital oscilloscope and decomposing it
digitally into quadrature components. The sampled signal is processed in a manner similar to an actual time
of arrival processor, according to the following steps:
a) Repeat steps b) to j) indexed by j = 1, … , 500
b) Repeat steps c) to i) indexed by i = 1, … , I
c) Start of frame is detected.
d) Channel number, coarse and fine frequency offsets are estimated.
e) The packet is derotated according to estimated frequency offsets.
f) The transition from FIRST_TRANSITION_FIELD(j,i) to SECOND_TRANSITION_FIELD(j,i) is
detected; and fine timing (with one sample resolution) is established.
g) The TRAINING_FIELD(j,i) of the derotated signal is up-sampled to meet the
TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH requirement. For example, a
TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH of 1 ns requires up-sampling of at least
1 GHz.
h) The up-sampled signal is cross-correlated with a reference waveform of the TRAINING_FIELD(j,i)
i) The measured time of departure xj,i is determined from the time of the peak of the magnitude of the
cross-correlation.
NOTE—The time of the peak of the magnitude of the cross-correlation is actually a time of arrival measurement that
equals the time of departure up to a fixed delay. Since the fixed delay is removed within step j), the fixed need not be
known or explicitly compensated for.
j) Having repeated steps c) to i) I times, the (j,i)th time of departure error ej,i is calculated as
TIME_OF_DEPARTURE(j,i) minus the synchronized time of departure. Defining xj = [xj,1,..,xj,I]T
as the I measured times of departure, y = [TIME_OF_DEPARTURE(j,1), …
TIME_OF_DEPARTURE(j,I)]T, ej = [ej,1, ej,I]T are the I time of departure errors and Xj = [1I ×1, xj],
where 1I ×1 is an I ×1 matrix of 1s, then the relative clock intercept, rcij, and slope, rcsj, between
device and instrumentation are determined as the linear least squares line of best fit: i.e., [rcij, rcsj]T
= (XjTXj)–1XjTy j. With these definitions and calculations, the synchronized time of departure sj =
[sj,1,..,sj,I]T equals rcsj × xj + rcij × 1I ×1, and so the I time of departure errors equal ej = yj – sj.
k) Having repeated steps b) to j) 500 times, there are 500 × I values of the time of departure errors
e = [e1,1, e500,I ]
l) The Time Difference of Departure accuracy test is passed if both of the following conditions are
met:
1) The RMS value of e is less than aTxPHYTxStartRMS.
2) aTxPHYTxStartRMS is less than TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH,
where the units of e, aTxPHYTxStartRMS, and TIME_OF_DEPARTURE_
ACCURACY_TEST_THRESH are properly accounted for.
3486
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
NOTE 1—One possible implementation of a time of departure measurement system is a free-running oscillator clocking
(a) the digital-to-analog converter(s) used to transmit the packet, (b) a 32-bit continuously counting counter and (c) a
hardware finite state machine such that PHY-TXSTART.request primitive causes a transition within the finite state
machine that in turn causes frame transmission at the DACs a fixed number of cycles later; where the time of departure
is recorded as the value of the counter at that transition minus aTxPHYTxStartRFDelay (using
TIME_OF_DEPARTURE_ClockRate), where aTxPHYTxStartRFDelay can vary by channel. In this implementation,
the principal source of time of departure error is short-term oscillator imperfection (e.g., phase noise) and RF group
delay variation across channels uncompensated by aTxPHYTxStartRFDelay.
NOTE 2—1 ns of time of departure error corresponds to approximately 0.3 m of distance error, so high location
accuracy depends upon a tight time of departure standard deviation.
P.3 Differential Distance Computation using Fine Timing Measurement
frames
In Figure P-1 the Observing STA is able to listen to the Fine Timing Measurement frame exchange between
the Sending and Receiving STAs. The time of flight of a line of sight transmission between the Sending and
Receiving STAs is denoted as T. At the Observing STA, the time of Arrival (ToA) of message M and its Ack
frame are respectively tc1 and tc2. At the Sending STA, the time of departure (ToD) of message M and the
ToA of its Ack frame are t1 and t4 respectively.
The differential distance between the Observing STA and each of the Sending and Receiving STAs, denoted
as DSR, is defined as:
D SR = c T SO – T RO
where
c is speed of the light.
TSO is the time of flight between the Sending STA and the Observing STA
TRO is the time of flight between the Receiving STA and the Observing STA
DSR can now be computed as:
D SR = c tc 1 – tc 2 – T – t1 – t4
An Observing STA can use the ToA and the time stamps (t1 and t4) received in the following messages in the
message exchange to refine its computation of the differential distance to the Sending and Receiving STAs.
In Figure P-1 the Receiving and Sending STAs can be APs. The APs can learn about neighboring APs that
support the FTM protocol and an AP can initiate a FTM message exchange on a periodic basis (e.g., the
beacon interval or a multiple of the beacon interval) with its neighbor APs. Monitoring and receiving these
messages can enable Observing STAs to estimate their differential distance with the AP pairs. An Observing
STA that is able to determine its differential distance to at least three pairs of Sending and Receiving STAs
can determine its location using the principle of hyperbolic navigation. An Observing STA can potentially
determine its location by monitoring the FTM exchanges of a single AP (Sending STA) if there are three or
more neighbor APs of the Sending STA that support FTM.
3487
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
t1 = ToD(M)
Action frame M contains:
Dialog Token = n t2 = ToA (M)
Follow On Dialog Token = 0
t3 = ToD(Ack)
t4 = ToA(Ack)
Action frame M Contains:
Dialog Token = m n
Follow On Dialog Token = n t1 and t4 are known
ToD Timestamp = t1
ToA Timestamp = t4 SME at receiving STA
estimates RTT as
(t4-t1)-(t3-t2)
.
.
.
Action frame M Contains:
Dialog Token = 0
Follow On Dialog Token = p
ToD Timestamp = t1'
ToA Timestamp = t4'
tc1 = ToA (M)
tc2 = ToA (Ack)
Sending Observing Receiving
STA STA STA
Figure P-1—Parameters recorded by Observing STA when monitoring an FTM message
exchange
3488
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex Q
(informative)
Example use of the Destination URI for Event and Diagnostic
Reports
Q.1 Destination URI payload
An example of the payload used to transmit Event and Diagnostic reports shown in Table Q-1. The protocol
used to transport the Destination URI payload is beyond the scope of this standard. An example use of the
Destination URI is given in Q.2.
Table Q-1—Destination URI payload
Size (octets) Information
6 BSSID
6 Reporting STA Address
variable Event or Diagnostic Report frame contents
Q.2 Use of HTTP (or HTTPS) for Destination URI of Event and Diagnostic
Reports
Under certain conditions a non-AP STA might need to send Event and Diagnostic reports to an AP using the
Destination URI advertised by the AP in the request frame. A suitable higher layer protocol that could be
used to transport the Event or Diagnostic report is HTTP or HTTPS.
For example, consider the following:
1) IT is investigating a WLAN coverage problem and uses a non-AP STA with a WLAN and
Ethernet adapters to collect some additional information.
2) The non-AP STA with MAC 00-ff-fd-00-00-01 has received a request for a Diagnostic report
from AP 00-ff-fe-00-00-10 and is in fringe coverage. The non-AP STA has an Ethernet adapter
that is connected.
3) The AP includes an Alternate Destination URI of http://www.myserver.mycompany.com in the
Diagnostic Report frame.
4) The non-AP STA loses WLAN connectivity while trying to transmit a Diagnostic Report frame
to the AP and the non-AP STA’s SME determines that it can use the Alternate Destination URI
to send the Diagnostic Report frame using the Ethernet link.
5) The non-AP STA POSTs the Diagnostic report as follows:
POST /wnm/msg/00-ff-fd-00-00-01/msg1 HTTP/1.1
Host: http://www.myserver.mycompany.com
Content-Type: application/octet-stream
Content-Encoding-Type: base64
3489
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Content-Length: i (length of data as specified in Figure 9-697 in 9.6.14.5)
In the HTTPS case, the non-AP STA would need to be provisioned with credentials to establish the TLS
connection prior to posting the message over HTTP. The HTTP post would work as described previously.
3490
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex R
(informative)
Interworking with external networks
R.1 General
The purpose of this informative annex is to describe and clarify the support for interworking with external
networks including the support for network discovery and selection, QoS mapping, SSPN interface, and
emergency services and to provide some background information and recommended practices.
R.2 Network discovery and selection
R.2.1 General
Interworking service provides features to support the network discovery and selection process a STA uses to
choose the network with which to associate. GAS provides a non-AP STA access to an advertisement server
(e.g., an access network server or an IEEE 802.21 information server), which can provide a rich set of
information to aid the network discovery and selection process. In addition, interworking service provides
lightweight features that also facilitate this process. The following subclauses describe several use cases
illustrating how these features can be used to aid in network discovery and selection:
— Airport: A traveling businesswoman needs to connect via an airport hotspot to her enterprise net-
work to download email and information from the customer database.
— Shopping: A shopper visits a shopping mall and wants to use a smartphone to discover items on
sale.
— Sales meeting: A salesman visiting a customer accesses his guest network.
— Museum: A visitor to a museum uses a smartphone to obtain virtual docent service.
— Emergency call: A traveler needs to make an emergency call while in another country.
— Emergency alert: A traveler, having enabled the display of emergency alerts, arrives at a new desti-
nation.
R.2.2 Airport
A traveling businesswoman arrives for the first time at an airport having a WLAN. This user wants to
download email onto her laptop utilizing the airport’s hotspot, a chargeable network. Once associated, the
woman needs to connect via VPN connection back to her company’s servers to access email and information
from the customer database. This is performed as follows:
a) The laptop’s non-AP STA performs an active scan by transmitting a Probe Request frame
containing the wildcard SSID and an Interworking element with Access Network Type subfield set
to “Chargeable Public Network.” In response, it receives Probe Response frames from several of the
airport’s APs, in the immediate neighborhood, for the SSID “Narita Hotspot.”
b) The Probe Response frame received by the laptop indicated the following capabilities:
1) Extended Capabilities element indicates: AP provides interworking service.
3491
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
2) Interworking element indicates: venue group = 1 (Assembly) and venue type = 3 (passenger
terminal), Internet = 1 (Internet access available), ASRA = 1 (there is an additional step
required for network access).
3) Advertisement Protocol element including the Advertisement Protocol ID set to MIH
Information Service.
4) Roaming Consortium element present containing an OI for “Hotspot Roaming International.”
5) There is no RSNE present in the received Beacon frame.
c) Since the laptop’s SME does not recognize the Roaming Consortium OI, it invokes the GAS
protocol to query the network’s IEEE 802.21 IS. The IEEE 802.21 IS’s response indicates the
roaming partners for “Narita Hotspot” and the laptop have security credentials for one of them.
d) Since the AP indicated ASRA = 1, the SME again invokes the GAS protocol to retrieve the Network
Authentication Type ANQP-element. The response indicates that https redirection is in use and
provides the Redirect URL of hotspot.narita.co.jp. Note that this is helpful since some networks use
conditional redirection—that is, access to a walled garden is provided for free, but a subscription fee
is required to access the Internet.
e) Since the laptop’s SME now knows it should be able to successfully authenticate with the network,
the STA associates to the AP.
f) The following operations are then carried out by higher layers operating within the laptop:
1) The laptop’s SME autonomously launches an http client and provides to it the URL of
hotspot.narita.co.jp, which provides the proper security credentials to the network and thereby
successfully authenticates it to the network.
2) The VPN client is autonomously launched and a secure session to the user’s corporate network
is established. Then the user launches the email application to download email and other
required information.
R.2.3 Shopping
A shopper visits a shopping mall and wants to use a smartphone to discover items on sale. In this mall, the
mall’s IT department is providing WLAN facilities for all of the stores in the mall; therefore, there is only
one SSID for shoppers (i.e., there is not a different SSID for each store in the mall). The user arrives at the
mall and taps an icon on the screen to put the smartphone in “shopping mode.” The smartphone’s shopping
application causes the non-AP STA to carry out the following steps:
a) The smartphone’s non-AP STA performs an active scan by transmitting a Probe Request frame
containing the wildcard SSID and an Interworking element with Access Network Type subfield set
to “Free Public Network.” In response, it receives Probe Response frames from several of the mall’s
APs, but only one SSID is provided, which is “Silicon Valley Mall.” The mall’s APs did not
transmit Probe Response frames for the SSIDs “Engineering,” “Deliveries,” and “Janitorial” since
their access network type is “Private network.”
b) The Probe Response frame received by the smartphone indicated the following capabilities:
1) Extended Capabilities element indicates: AP provides interworking service.
2) Interworking element indicates: venue group = 6 (mercantile) and venue type = 4 (shopping
mall), Internet = 0 (unspecified).
3) RSNE indicates: IEEE 802.1X authentication.
c) Since the AP indicated Interworking service is available, the smartphone’s non-AP STA uses the
MLME-GAS.request primitive to invoke GAS to request the Capability List ANQP-element (see
9.4.5.3). In the Capability List ANQP-element, the AP has indicated support for Venue Name and
Domain Name. Subsequent to receipt of the Capability List ANQP-element, the non-AP STA
invokes the MLME-GAS.request primitive to retrieve the other two lists.
3492
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
d) Next, the non-AP STA’s supplicant searches the received Domain Name list to determine whether it
has any stored credentials for these domains. If so,
1) The smartphone autonomously associates to the “Silicon Valley Mall Shopping” SSID and
displays the following information:
i) Venue name: Silicon Valley Mall, 1234 Main Street, Rownhams, CA 98765-1234
ii) SSID: Silicon Valley Mall
iii) Venue type: Shopping Mall
2) The supplicant autonomously provides the security credentials for the selected domain.
e) Higher layer protocols then download discount coupons being offered for items on sale.
R.2.4 Sales meeting
A salesman travels across town to a meeting at ACME Manufacturing. While there, this user needs to send
email to get a document from engineering. On his laptop, he requests the WLAN via the laptop’s UI to
search for guest networks. The laptop performs the following steps:
a) The laptop’s non-AP STA performs an active scan by transmitting a Probe Request frame
containing the wildcard SSID and an Interworking element with Access Network Type subfield set
to “Private Network with Guest Access.” In response, it receives Probe Response frames from
several of ACME Manufacturing’s APs, but only one SSID is provided, which is “Guest.” ACME
Manufacturing’s APs did not transmit Probe Responses for the SSIDs “Engineering” and “Finance”
since their access network type is “Private network.”
b) The Probe Response frame received by the laptop indicated the following capabilities:
1) Extended Capabilities element indicates: AP provides interworking service.
2) Interworking element indicates: Internet is available, venue group = 2 (Business) and venue
type = 8 (Research and Development Facility).
3) RSNE indicates: IEEE 802.1X authentication with CCMP-128 pairwise and group cipher
suites.
c) Since the AP indicated interworking service is available, the laptop’s non-AP STA uses the MLME-
GAS.request primitive to invoke GAS to request the Capability List ANQP-element (see 9.4.5.3). In
the Capability List ANQP-element, the AP has indicated support for venue name. Upon receipt of
the Capability List ANQP-element, the non-AP STA again invokes the MLME-GAS.request
primitive to retrieve the venue name.
d) The laptop’s UI displays the following information and automatically associates to the network:
1) SSID: Guest (Type: Private network with Guest access)
2) Venue name: ACME Manufacturing, 1234 Main Street, Rownhams, CA 98765-1234
3) Venue type: Research and Development Facility
4) Internet is available
e) Upon prompt, the user enters the username and password supplied by his point of contact from
ACME Manufacturing and is then able to send and receive email.
R.2.5 Museum
A visitor enters a museum that is advertising virtual docent service (audio tracks describing each of the
major exhibits). The visitor taps an icon on a smartphone and requests it to search for free networks. The
smartphone then carries out the following:
a) The smartphone’s non-AP STA performs an active scan by transmitting a Probe Request frame
containing the wildcard SSID and an Interworking element with Access Network Type subfield set
to “Free Public Network.” In response, it receives Probe Response frames from several of the
3493
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
museum’s APs, but only one SSID is provided, which is “Visitors.” The museum’s APs did not
transmit Probe Response frames for the SSID “Maintenance” since its access network type is
“Private network.”
b) The Probe Response frame received by the smartphone indicated the following capabilities:
1) Extended Capabilities element indicates: AP provides interworking service.
2) Interworking element indicates: venue group = 1 (assembly), venue type = 9 (museum), and
ASRA = 0 (no additional steps are required for access).
c) Since the AP indicated interworking service is available, the smartphone’s non-AP STA uses the
MLME-GAS.request primitive to invoke GAS to request the Capability List ANQP-element (see
9.4.5.3). In the Capability List ANQP-element, the AP has indicated support for venue name. Upon
receipt of the Capability List ANQP-element, the non-AP STA again invokes the MLME-
GAS.request primitive to retrieve the venue name.
d) The smartphone’s UI displays the following information, asking the user whether they wish to
connect to the network:
1) Venue name: Museum of Modern Art (MOMA)
2) SSID: Visitors
3) Venue type: Museum
4) No authentication required
e) The user taps the “Connect” icon on the smartphone’s display. Note that the smartphone’s non-AP
STA knows that the network uses Open System authentication since there is no RSNE present in the
beacon and ASRA = 0.
R.2.6 Emergency call
A traveler needs to make an emergency call while in another country. The traveler might not be aware of the
emergency call numbers that are used in that country. Being in this new location for the first time, the
traveler is not aware of which local access points provide access for emergency calling. (Note that
emergency calling requires higher layer application(s) that are outside the scope of this standard.) This is
performed as follows:
a) The traveler’s non-AP STA performs an active scan by transmitting a Probe Request frame
containing the wildcard SSID and an Interworking element. (If the non-AP STA is already
associated with an AP that has indicated support for emergency service in its beacon, the probe
request would not be necessary.)
b) In response, it receives Probe Response frames from one or more APs indicating support for
emergency service in the Access Network Options field of the Interworking element.
1) Extended Capabilities element indicates: AP provides interworking service.
2) Emergency services reachability is indicated by the ESR and UESA fields in the Access
Network Options field in the Interworking element.
3) A dedicated emergency services network is indicated by the Access Network Type field in the
Interworking element.
c) The traveler’s non-AP STA then requests the Emergency Call Number ANQP-element with a GAS
Initial Request frame.
d) The GAS Initial Response frame from the AP provides the Emergency Call Number, for example
the sequence of digits “911” or an emergency service URN label, URI pair “urn:service:sos.fire,
tel:112;sip:+15555551002@fire.com” [B46].
e) This information is passed to the higher layer application in the traveler’s non-AP STA.
f) The traveler’s non-AP STA then associates with the AP.
3494
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
g) The traveler’s non-AP STA then places the emergency call, with an expedited bandwidth request
(EBR) in an ADDTS frame to provide priority to the emergency call.
R.2.7 Emergency alert
A traveler has enabled the display of emergency alerts on a wireless device (non-AP STA) by appropriately
setting the higher layer emergency alert application on the device. The traveler arrives at a new destination
and turns on the device. The device, when switched on, will perform a search and then associate with an AP
to which the traveler has a subscription or associate with an open AP (if the traveler has enabled the device
to do that). During the steps leading up to association, the device, when it becomes aware of an emergency
alert, will obtain and display it. The emergency alert will likely be obtained from the AP that has the service
to which the traveler has subscribed, but the device might also obtain the emergency alert from other APs, if
an AP to which the traveler has a subscription is not available. This is performed as follows:
a) The traveler’s non-AP STA performs an active scan by transmitting a Probe Request frame
containing the wildcard SSID. If it is associated with an AP, it checks the beacon.
b) In response, it receives Probe Response frames from one or more APs, which it checks (or,
alternately, checks the beacon) for the subscription and also whether the Emergency Alert element
indicates that there are emergency alert message(s).
c) If there are one or more emergency alert messages to be downloaded, the Emergency Alert Identifier
element provides an Alert Identifier Hash value.
d) The device uses the hash of each of the available emergency message(s) to determine whether that
message has already been received or whether it is a new message that needs to be downloaded.
e) If there are one or more emergency alert messages to be downloaded, the device forms the EAS
Message URI by concatenating the Emergency Alert URI with the hexadecimal numerals of the
Alert Identifier Hash, using the specified method.
f) Should the device be unassociated with an AP when it determines that a new emergency alert is
available, it retrieves the EAS message using either GAS procedures with Advertisement Protocol
ID field set to the value for EAS. If the device is associated with the AP, it retrieves the EAS
message using either GAS procedures with Advertisement Protocol ID field set to the value for EAS
or, for example, using HTTP.
R.3 QoS mapping guidelines for interworking with external networks
R.3.1 General
The EDCA and HCCA mechanism defined in 10.22 provide QoS control at the MAC layer. However, the
QoS control parameters used by the EDCA and HCCA cannot match directly with other QoS control
parameters of the interworked external networks, e.g., SSPN. For example, the SSPN could have different
metrics for defining the QoS levels. Destination Network 1 (DN1) and DN2 can use DSCP values
differently, in which case, STA1 and STA2 would require different QoS mapping information. Therefore,
mapping from these external QoS control parameters to the QoS parameters of this standard is necessary.
The QoS parameters mapping can be used for both uplink and downlink data transmission:
— For uplink: at the non-AP STA, external QoS parameters are mapped to IEEE 802.11 QoS
parameters, e.g., DSCP to IEEE 802.11 User Priority and in turn to EDCA ACs. This mapping helps
the non-AP STA to construct correct QoS requests to the AP, e.g., the ADDTS Request frame and to
transmit frames at the correct priority.
— For downlink: at the AP, DSCP values are mapped to EDCA UPs. Optionally, the non-AP STA can
use TSPEC and TCLAS elements in an ADDTS Request frame to set up a traffic stream in the BSS.
3495
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
In this method, the User Priority is specified in the TCLAS element. The policy used by the AP to
choose a specific method to map frames to user priorities is outside the scope of this standard.
Different external networks can use different DSCP sets for the same services as described in R.3.3. For
example, a 3GPP network can use different code points from that of an enterprise network. The QoS Map
distribution mechanism defined in 11.25.9 provides means to communicate to the STA’s mapping informa-
tion from the network.
R.3.2 Determination of the mapping for a STA
The QoS mapping to be applied depends upon the network the non-AP STA is accessing. In an interworking
IEEE 802.11 infrastructure setting, the same physical AP can serve non-AP STAs from different SSPNs on
different BSSIDs. As such, these STAs are separated into different BSSs. Figure R-1 presents an example of
the scenario using authentication, authorization, and accounting (AAA). In Figure R-1, AAA Server 1
controls access to DN-1 and AAA Server 2 controls access to DN-2.
DN 1
BSS VLAN
Tunnel 1
STA1
AAA
AAA Interface AAA
STA3 AP DS Client Server 1
STA2
AP
Portals
VLAN AAA
Tunnel 2 Server 2
DN 2
Figure R-1—Interworking IEEE 802.11 infrastructure supporting multiple SSPNs
R.3.3 Example of QoS mapping from different networks
IEEE 802.1D UPs map to EDCA ACs, as described in Table 10-1. The use of DSCP sets differs from
network to network. Table R-1 shows examples of DCSP mappings.
NOTE—The mapping of the DSCP to 3GPP Traffic Class is available in GSMA, IR.34 v4.6 [B16] (similar to that of
GSMA IREG34). See TR 21.905 [B2] for definition of general packet radio service (GPRS) roaming exchange.
Table R-1 is extended to cover the EDCA ACs mapping. This mapping can also apply to other networks that adopt the
3GPP QoS definitions, e.g., 3GPP2.
3496
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table R-1—Mapping table of DSCP to 3GPP QoS information and EDCA ACs
UP
EDCA (as in
DiffServ QoS Requirement on
3GPP QoS Information DSCP Access IEEE
PHB GPRS Roaming Exchange
Category Std
802.1D)
Traffic Class THP Max Max MSDU MSDU
Delay Jitter Loss Error
Ratio
Conversational N/A EF 101110 20 ms 5 ms 0.5% 10-6 AC_VO 7, 6
Streaming N/A AF41 -6
100010 40 ms 5 ms 0.5% 10 AV_VI 5, 4
Interactive 1 AF31 011010 250 ms N/A 0.1% 10-8 AC_BE 3
-8
2 AF21 010010 300 ms N/A 0.1% 10 AC_BE 3
3 AF11 001010 350 ms N/A 0.1% 10-8 AC_BE 0
-8
Background N/A BE 000000 400 ms N/A 0.1% 10 AC_BK 2,1
Table R-2 shows an example mapping based on application classes defined in IETF RFC 4594. Mapping
between DSCP and UP can be done using Exception fields or by range. The use of DSCP Exception fields
will map a DSCP to a UP according to Table R-2. Mapping by range will require the setting of DSCP ranges
as shown in Table R-3.
Table R-2—Example Enterprise DSCP to UP/AC mapping
IEEE
Per-hop
802.1D)
Application Class behavior Access Category
User
(PHB)
Priority
Network Control CS6 7 AC_VO
Telephony EF 6 AC_VO
RT Interactive CS4 6 AC_VO
Multimedia Conference AF4x 5 AC_VI
Signaling CS5 5 AC_VI
Broadcast Video CS3 4 AC_VI
Multimedia Stream AF3x 4 AC_VI
Low Latency Data AF2x 3 AC_BE
High Throughput Data AF1x 2 AC_BK
OAM CS2 3 AC_BE
Standard DF 0 AC_BE
Low Priority/Background CS1 1 AC_BK
3497
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Table R-3—UP to DSCP range mapping example
UP Range DSCP Low DSCP High
UP 0 Range 0 0
UP 1 Range 1 9
UP 2 Range 10 16
UP 3 Range 17 23
UP 4 Range 24 31
UP 5 Range 32 40
UP 6 Range 41 47
UP 7 Range 48 63
Furthermore mapping by range will require an additional exceptional element to map DSCP 32 to UP 6.
NOTE—Twenty-one DSCP Exception fields are provided to give more flexibility in defining the QoS mapping. This
number is equal to the number of FIBs (Forwarding Information Bases) defined by IETF RFC 3222.
R.4 Interworking and SSPN interface support
R.4.1 General
The interworking service architecture defines the scope of the SSPN interface. This interface is provided by
the IEEE 802.11 MAC to support the interworking service. In an interworking scenario, the IEEE 802.11
infrastructure is operating in infrastructure mode.
Figure R-2 shows an example implementation of the control aspect of the Interworking Interface. As shown
in the figure, the Interworking Interface consists of two parts: the generic SSPN Interface between the AP
and the AAA Client; and the AAA Interface between the AAA Client and the corresponding AAA Server in
the SSPN. Depending on the implementation the AAA Client can be collocated with the AP or stand alone
serving as a proxy or translation agent between the SSPN Interface and AAA Interface. The AAA Interface
serves as a transparent carrier of the SSPN interface.
The possible interactions over the SSPN interface are defined in 11.25.5. The information transferred over
the SSPN Interface is defined in R.4.2. This interface results in parameters being set in the
dot11InterworkingTable MIB. The AP’s SME thereafter uses these parameters to permit or deny, as
appropriate, services to non-AP STAs.
3498
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
WLAN System
BSS1
Interworking
STA1 AP Interface
STA2
SSPN AAA SSPN
Portal
Interface Client AAA
DS
AAA Server
Interface
ESS
AP
STA4
STA3
BSS2
Figure R-2—Basic architecture of the interworking service
R.4.2 SSPN interface parameters
The parameters for each associated non-AP STA defined in this clause cross the SSPN Interface, i.e.,
between AP and AAA Client as shown in Table R-4.
Table R-4—SSPN Interface information or permission parameters
From AN to From SSPN Per non-AP
Information or permission name
SSPN to AN STA entry
Non-AP STA MAC + +
Non-AP STA User ID + + +
Non-AP STA Interworking Capability + +
Link Layer Encryption Method + +
Authorized Priority + +
Authorized Rate + +
Authorized Delay + +
Authorized Service Access Type + +
Authorized Service Access Information + +
Non-AP STA Transmission Count + +
Non-AP STA Location Information + +
Non-AP STA State Information + +
3499
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The SSPN Interface parameters are stored in the AP with corresponding MIB attributes as defined in
Annex C, and are used by the Interworking Service Management function in the SME. The MIB variables
themselves, which are used by the AP SME, are read only.
R.4.2.1 Non-AP STA MAC
This parameter is the MAC address of the non-AP STA accessing the interworking service through the AP.
It can be requested by the external network, e.g., a 3GPP network, for fraud prevention. The non-AP STA
MAC address is normally available through MLME SAP, e.g., MLME-ASSOCIATE.indication primitive,
and should be forwarded by the AS to the AAA Server entity in the SSPN through the AAA Interface.
The following MIB attribute is used:
— dot11NonAPStationMacAddress
R.4.2.2 Non-AP STA User ID
This parameter contains the subscriber information of the non-AP STA for the interworking service. It is
provided by the non-AP STA through the RSNA establishment process to the AAA Server; in turn, the AAA
Server provides it back to the AP via the SSPN interface. It is in the form of an NAI, i.e., it contains both the
user’s identity and its SSP information.
NOTE—The reason the AAA Server provides the user identity back to the AP is that some EAP methods use encrypted
tunnels to maintain confidentiality of the user and thus the AP might not otherwise be able to learn the user’s identity.
The following MIB attribute is used:
— dot11NonAPStationUserIdentity
R.4.2.3 Non-AP STA Interworking Capability
This parameter is derived from the non-AP STA’s Extended Capabilities element, which is included in
(Re)Association Request frames.The AP SME obtains this information from the MLME SAP, e.g., MLME-
ASSOCIATE.indication primitive. This information needs to be passed over the SSPN interface since the
service authorization decisions can depend on the non-AP STA capabilities.
The following MIB attribute is used:
— dot11NonAPStationInterworkingCapability
R.4.2.4 Link Layer Encryption Method
This parameter indicates the link layer encryption method selected during the RSNA establishment process
for protecting the unicast communication between the non-AP STA and the AP. The cipher suite format of
this parameter is drawn from the RSNE defined in 9.4.2.25. The AP obtains this information about the STA
via the MLME SAP.
In the interworking service, the SSPN also participates in the selection of the cipher suite selection, as
described in 11.25.5. Therefore, the link layer encryption method selected will meet or exceed the security
requirement of the SSPN.
NOTE—In interworking, the SSPN can require visibility and configurability of the STA access.
With this information available to the SSPN, the operator would be able to have better control, e.g., barring
access to IEEE 802.11 networks if null encryption is used. This is also related to the operator network’s
configuration, e.g., if preauthentication should be supported.
3500
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The following MIB attribute is used:
— dot11NonAPStationUnicastCipherSuite
R.4.2.5 Authorized Priority
This parameter is used for admission control and user-priority policing at the AP. It is based on the
Infrastructure Authorization Information delivered from the SSPN during the AAA procedure. The
Authorized Priority specifies the authorized User Priorities that the non-AP STA is allowed to use during the
Interworking access. It also specifies whether the non-AP STA can use HCCA.
For EDCA operation, the following MIB attribute is used:
— dot11NonAPStationAuthAccessCategories MIB attribute after mapping the priority according to
Table 10-1.
For HCCA operation, the following MIB attribute is used:
— dot11NonAPStationAuthHCCAHEMM
R.4.2.6 Authorized Maximum Rate
This parameter is used for admission control decisions or policing actions at the AP. It is based on the
Infrastructure Authorization Information delivered from the SSPN during the AAA procedure. For EDCA
operation, this parameter contains a list of four MaxRate values indicating the maximum rate allowed for
each of the access categories. For HCCA operation, there is one MaxRate value. Each of the MaxRate
values is an unsigned integer and in the unit of kilobits per second. An additional value provides the
maximum rate at which a non-AP STA can source group addressed frames.
The following MIB attributes are used:
— dot11NonAPStationAuthMaxVoiceRate,
— dot11NonAPStationAuthMaxVideoRate,
— dot11NonAPStationAuthMaxBestEffortRate,
— dot11NonAPStationAuthMaxBackgroundRate,
— dot11NonAPStationAuthMaxHCCAHEMMRate
— dot11NonAPStationAuthMaxSourceMulticastRate.
R.4.2.7 Authorized Service Access Type
This per-non-AP STA parameter indicates the access type allowed for the non-AP STA based on the SSPN
decision. The AP will use this information for authorization requests from the STA, e.g., allow or disallow
direct link operation and group addressed services. The parameter uses truth values to indicate the service
type authorized.
The following MIB attributes are used:
— dot11NonAPStationAuthDls is to authorize a non-AP STA to use DLS
— dot11NonAPStationAuthMaxSourceMulticastRate is to authorize a non-AP STA to source group
addressed stream(s) to toward the network
R.4.2.8 Authorized Delay
This parameter is used for admission control decisions at the AP. It is based on the Infrastructure
Authorization Information delivered from the SSPN during the AAA procedure. This parameter is used only
for HCCA operation, and contains one value. An AP should deliver frames to a non-AP STA within the time
3501
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
period specified in this attribute. Furthermore, when a non-AP STA requests admission control, the
requested delay is approved only if it is greater than or equal to the value stored in the corresponding
parameter. Each parameter is an unsigned integer that measures delay in units of microseconds.
The following MIB attribute is used:
— dot11NonAPStationAuthHCCAHEMMDelay
R.4.2.9 Authorized Service Access Information
This parameter contains the relevant information for the AP to enforce the authorized service access type
indicated in the Authorized Service Access Type parameter. The Authorized Service Access parameters
provide the VLAN assignment (VLAN ID and VLAN Name) to which frames to or from the non-AP STA
are bridged.
The following MIB attributes are used:
— dot11NonAPStationVLANId
— dot11NonAPStationVLANName
R.4.2.10 Non-AP STA Transmission Count
This parameter indicates the count of the data traffic transmitted to and received from a non-AP STA. Such
information would be used by the on-line charging and accounting function, especially for the IEEE 802.11
WLAN local service, where the data traffic does not necessarily go through the SSPN network. In such
cases, Layer 3 accounting/charging information is not reliable since addresses could be spoofed. Layer 2
would be a better place to collect such information since due to the cryptographic security association that
exists between the non-AP STA and AP.
The following MIB attributes are used:
— dot11NonAPStationVoiceMSDUCount,
— dot11NonAPStationVideoMSDUCount,
— dot11NonAPStation-BestEffortMSDUCount,
— dot11NonAPStationBackgroundMSDUCount,
— dot11NonAPStationHCCAHEMMMSDUCount,
— dot11NonAPStationMulticastMSDUCount,
— dot11NonAPStationVoiceOctetCount,
— dot11NonAPStationVideoOctetCount,
— dot11NonAPStationBestEffortOctetCount,
— dot11NonAPStationBackgroundOctetCount,
— dot11NonAPStationHCCAHEMMOctetCount,
— dot11NonAPStationMulticastOctetCount MIB attributes
R.4.2.11 Non-AP STA Location Information
This parameter provides information about the STA’s location to the SSPN. It is required by the SSPN
applying location based service control. In the IEEE 802.11 network, the non-AP STA location is
approximated using the AP’s location information. This parameter includes two type of formats, Geospatial
and Civic Location.
3502
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The following MIB attributes are used:
— dot11APLCITable,
— dot11APCivicLocationTable
R.4.2.12 Non-AP STA State Information
This parameter indicates whether the power management mode of the non-AP STA is either active mode or
PS mode.
The following MIB attributes are used:
— dot11NonAPStationPowerManagementMode
R.5 Interworking with external networks and emergency call support
R.5.1 General
Emergency services define the IEEE 802.11 functionality to support an emergency call (e.g., E911) service
as part of an overall multi-layer solution, specifically capability advertisement and access to emergency
services by STAs not having proper security credentials. “Multi-layer” indicates that emergency services will
be provided by protocols developed in part by other standards bodies; see IETF ECRIT [B25], 3GPP TS
23.167 [B1], and 3GPP TS 22.067 [B3]. Three features of interworking with external networks support
emergency call services.
The first feature is a mechanism for a non-AP STA to signal to an AP that a call is an emergency call. This is
useful in the case where the access category to be used to carry the emergency call traffic (typically AC_VO)
is configured for mandatory admission control. If the WLAN is congested, then the AP can deny the TSPEC
request for bandwidth to carry the call. However, if the AP is able to determine that the call is an emergency
call, then it can invoke other options to admit the TSPEC request.
The second and third features provide the means for a client without proper security credentials to be able to
place an emergency call. The second feature makes use of the Interworking element, which can be included
in Association Request frames in order to bypass the IEEE 802.1X port at an AP for unauthenticated access
to emergency services. This is described further in R.5.5. The third feature makes use of an SSID configured
for Open Authentication to provide emergency services and is described in R.5.3.
The STA has the burden to confirm the availability of emergency services from the IEEE 802.11 network,
including that the network is authorized for emergency services. The time it takes for a client to find an
authorized emergency services network is related to the speed of forward progress the authorized network can
make over the air with the STA, relative to all of the other networks (attackers as well), and is inversely related
to the number of false advertisements. A STA can confirm the availability of emergency services by
observing the value of the access network type, ESR and UESA fields in the Interworking element of any
received Beacon or Probe Response frame.
R.5.2 Background on emergency call support over IEEE 802.11 infrastructure
Special handling for emergency service calls is required over IEEE Std 802.11. To use a public hotspot a
user will go typically through an authentication process (e.g., EAP-based, or http/https redirect or DNS
redirection) before being able to use it for emergency calls.
3503
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
There is a need to support these emergency services both when the user has a relationship with the
IEEE 802.11 network (credentials to access the network) and when it does not have any relationship with
the IEEE 802.11 network.
The former case requires no changes to the authentication process—the user, having already been
authenticated to and associated with the WLAN, simply dials the emergency number thereby placing the
call.
In the latter case, the non-AP STA will be able to gain access to the network without using security
credentials and make an emergency call.
Another difficulty is that once the user gains access to the network, there is no mechanism to prioritize their
emergency traffic in the IEEE 802.11 MAC over that of other users, even with IEEE 802.11 QoS capability.
Supporting emergency services, such as E911 calling, requires a multi-layer solution with support at various
protocol layers. Apart from MAC level access and support for transfer of data between non-AP STA and AP
with appropriate QoS at layer 2, there is a clear need, above this layer, to set up the call, conduct call control
and management, and use an appropriate audio codec.
One specific example is when a user arrives in a new country and needs to make an emergency call in a
public hotspot where there is no prior relationship with the available WLAN network or WLAN hotspot
operator.
NOTE—The callback feature, if required in a regulatory domain, is dealt with at a higher layer.
R.5.3 System aspects for emergency call support
An IEEE 802.11 infrastructure by itself cannot ensure that all factors are compatible for an emergency
service call to actually take place. The client device might have to register with a call manager (SIP agent or
some other signaling endpoint) for the call to be placed successfully. Different signaling systems such as
SIP, H.323, etc., can be deployed for supporting emergency service calling. Higher layers can also verify an
emergency service call is being placed so that appropriate level of resources can be granted to the emergency
call. Voice endpoints (e.g., non-AP STAs) can use different codecs such as G.711, AMR, and iLBC. All these
functionalities are outside the scope of this standard.
IEEE Std 802.11 can provide priority for emergency traffic both for the initial call establishment and during
an ongoing emergency call, which assumes advertisement of this functionality supported in the BSS.
This subclause describes general design assumptions to support emergency services with IEEE Std 802.11:
a) It is assumed that there is a higher layer (above IEEE 802.11 Layer 2) protocol (or protocol suite) for
making emergency calls or using any other emergency services.
b) In order to make the emergency call procedure work properly, the non-AP STA has the following
responsibilities:
1) Recognize the user’s request to make an emergency call.
2) Select an AP that supports QoS and EBR capability.
3) Non-AP STA will associate with the AP if it is not already done so. In an RSN, if the user does
not have valid authentication credentials for network access then non-AP STA can bypass the
RSN that will provide access to the network to make emergency calls.
4) If location information is required in a particular regulatory domain, request location
information from the WLAN. If the STA cannot determine its own location by its own means,
then Location information should be obtained from the network prior to initiating the
3504
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
emergency call request. There are two methods a non-AP STA can use to obtain location
services from the IEEE 802.11 network:
i) If the non-AP STA can use location information in geospatial format (i.e., latitude,
longitude and altitude), then the LCI report procedures (11.11.9.6) can be used to obtain
this information. The AP advertises its capability for the LCI report procedures by setting
the LCI Measurement Capability Enabled field to 1 in the RM Enabled Capabilities field
in the RM Enabled Capabilities element, and the non-AP STA transmits an LCI request to
the AP.
NOTE—The non-AP STA can receive an LCI report with the incapable field set. According to the
procedures in 11.11.9.6, the non-AP STA can resubmit an LCI request with a location subject of
“remote.” If the AP still responds with incapable, then location services are not available from the
AP via the LCI report procedures.
ii) If the non-AP STA requires location information in Civic or geospatial formats, then an
AP’s wireless network management capability can be used. In this case, an AP advertises
its ability to provide its location in Civic or geospatial format by setting the Civic Location
or Geospatial Location field in the Extended Capabilities element to 1 respectively in the
Beacon frame. A non-AP STA can also request its location using the procedures in
11.25.7. An AP that advertises its ability to provide its location in civic or geospatial
format does not return an “incapable” response if a requesting STA requests the “remote”
location.
5) Selects one of possibly several SSPNs advertising support for emergency services and VoIP
service.
c) There are two methods described in this annex by which a user lacking security credentials can gain
access to the network. The method selected in any particular deployment is at the discretion of the
IEEE 802.11 infrastructure provider, SSPN or system administrator as appropriate. The AP and non-
AP STA should permit users lacking security credentials to gain access to a network using one of
two methods:
1) Using an emergency services association (see 9.4.2.92) in a BSS configured for RSNA. Using
this type of association means the AP and non-AP STA will exchange unprotected frames for
emergency service access only during the lifetime of the association. In this situation,
cryptographic keys are not exchanged, the IEEE 802.1X uncontrolled port is bypassed without
invoking the IEEE 802.1X state machine. Since protection is used for authenticated STAs, their
traffic is protected.
2) Using an SSID configured for Open System authentication. Network elements necessary to
complete an emergency call are reachable via this SSID. How to reach these network elements
(e.g., a call manager) and which protocol to use (e.g., SIP) are outside the scope of this
standard.
d) The AP can separate the backhaul of emergency services traffic from other traffic, typically via a
dedicated VLAN.
To ease burden of implementation on the network side, some basic means should exist to allow easy
filtering, routing and basic access control of “regular” BSS traffic and emergency-type BSS traffic. This can
be assisted by the downloading of emergency call number information, as described in 9.4.5.5.
R.5.4 Description of the Expedited Bandwidth Request element
For access categories configured for mandatory admission control, a non-AP STA requests bandwidth using
a TSPEC element in an ADDTS Request frame. The TSPEC Request includes parameters describing the
characteristics of the traffic stream, but no information on the use of the traffic stream. The Expedited
Bandwidth Request (EBR) element describes the “use” of a traffic stream. To use this element, it is the
responsibility of the station to transmit this element in response to certain call signaling messages. How this
3505
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
is done is outside the scope for the interworking service. The following bandwidth uses are provided in the
EBR element:
— Emergency call, defined in NENA 08-002 [B56]
— Public first responder (e.g., fire department)
— Private first responder (e.g., enterprise security guard)
— Multi-level precedence and preemption (MLPP)
MLPP services are provided by other voice networking technologies such as 3GPP (see 3GPP TS 22.067
[B3]), H.323 (see ITU-T H4.60.14) and other proprietary signaling protocols. MLPP is used as a
subscription service to provide differentiated levels of consumer service; it is also used by military
organizations so that commanding officers will not get a network busy signal.
If the AP is provided additional information regarding the nature of the Traffic Stream, it can invoke
additional policy that can be configured on the AP to accept the TSPEC request when it would be otherwise
denied. Policy configured at AP defines how bandwidth is allocated. Specification of these policies is
outside the scope of interworking with external networks. Policy examples include the following:
— No action
— Preemptive action: delete a TS of lower priority if necessary to make room for new TS
— Use capacity allocated for nonvoice services if priority is above a certain value (assuming TSPEC is
for AC_VO)
— Interpret MLPP codes as defined 3GPP specification
— Interpret MLPP codes as defined in proprietary specification
R.5.5 Access to emergency services in an RSN
If an infrastructure BSS requires authentication and encryption with RSN, a non-AP STA placing an
emergency call associates and authenticate to the network by using an emergency services association (see
9.4.2.92). If the non-AP STA has user credentials that allow it to use a particular network, the non-AP STA
can use its credentials to authenticate to the SSPN through the IEEE 802.11 infrastructure.
When a mesh STA has an emergency services association, and it receives a Mesh Peering Open frame that
includes the Interworking element, with ASRA bit equal to 1 and UESA bit equal to 0, and the
Authenticated Mesh Peering Exchange element (see 9.4.2.118) it allows access to emergency services. If the
mesh STA has user credentials that allow the accessing mesh STA to use the mesh network, the mesh STA
can use its credentials to authenticate with the accessing mesh peer.
In order to use an emergency services association in an infrastructure BSS, a STA lacking security
credentials can associate with a BSS in which emergency services are accessible by including an
Interworking element with the UESA field set to 1 in a (Re)Association Request frame. An AP receiving
this type of (re)association request recognizes this as a request for unauthenticated emergency access. The
AP can look up the VLAN ID to use with a AAA Server, or it can have an emergency services VLAN
configured. The STA can either have, policies configured locally for quality-of-service parameters and
network access restrictions, or it can look them up through external policy servers. When a mesh STA has an
emergency services association, and it receives a Mesh Peering Open frame, from a mesh STA lacking
security credentials, that includes the Interworking element, with ASRA bit equal to 1 and UESA bit equal
to 1, and the Mesh Peering Management element (see 9.4.2.102) it allows access to emergency services.
When an emergency services association is used, an infrastructure BSS or an MBSS should be designed to
restrict access to emergency services only (or alternatively prioritize the emergency services to the highest
level of access). Methods of such restriction are beyond the scope of this standard, but can include an
isolated VLAN for emergency services, filtering rules in the AP or network entity (e.g., router) in an
3506
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
external network to limit network access to only network elements involved in emergency calls, and per-
session bandwidth control to place an upper limit on resource utilization.
R.6 Peer information
Peer information allows TDLS peer STAs to discover their capabilities. An example of peer information
could be expressed in an XML format as follows:
tdls
00-01-02-03-04-05
00-0a-0b-0c-0d-0e
< network info>
< DHCP> No
< IP address>192.168.2.1
< Subnet> 255.255.255.0
myphone
The minimum required peer information for TDLS is contained in “wireless info.” The “mac address” field
contains the MAC address of the transmitting STA and the “bssid” identifies the BSS in which the STA is a
member. The “network info” could optionally be used to aid the peer devices in establishing a TDLS link.
R.7 Calculating Estimated Throughput
In response to the receipt of MLME-ESTIMATED-THROUGHPUT.request, ESP STAs can determine
values for EstimatedThroughputInbound and EstimatedThroughputOutbound for each AC of a current or
potential link to another STA using Equation (R-1):
EST AirtimeFraction MPDU pPPDU A_MSDU_B 8
EstimatedThroughput = ---------------------------------------------------------------------------------------------------------------------------------
- (R-1)
PPDU Dur
where
EstimatedThroughput is in bits/second
PPDUDur is the expected duration of a single PPDU, in seconds
ESTAirtimeFraction is dimensionless. It is the estimated portion of airtime that is available
for outbound transmissions for this link as indicated in the Estimated
Service Parameters element received from the STA with the MAC
address that matches the PeerMACAddress in the MLME-
ESTIMATED-THROUGHPUT.request primitive
min(x,y) is the minimum of x and y
max(x,y) is the maximum of x and y
MPDUpPPDU = min(BA_WIN_Size, max(1,MPDU_pA_MPDU))
BA_WIN_Size = min(BA_WIN_SizeTX,BA_WIN_SizeRX)
3507
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
BA_WIN_SizeTX is the expected block ack window size of the transmitter of the PPDUs
containing MPDUs with the Type field equal to Data
BA_WIN_SizeRX is the expected block ack window size of the receiver of the PPDUs
containing MPDUs with the Type field equal to Data
PPDUR
MPDU_pA_MPDU = min( ---------------------- PPDUR DataRate - )
- ----------------------------------------------------------------------
MPDU SS MAC Hdr + A_MSDU_B 8
MPDU_pA_MPDU is dimensionless
PPDUR = DPDUR – PHDUR
PPDUR is the PPDU payload duration, in seconds
DPDUR is the Data PPDU duration target of the transmitter of the PPDUs
containing MPDUs with the Type subfield equal to Data, in seconds
PHDUR is the PHY header duration, estimated based on the expected PPDU
format of the PPDUs containing MPDUs with the Type subfield equal
to Data, in seconds
MPDUSS is the minimum MPDU start spacing of the receiver of the PPDUs
containing MPDUs with the Type subfield equal to Data, in seconds
MACHdr is the number of octets of MAC header information for an A-MSDU
A_MSDU_B = min(A_MSDU_BTX, A_MSDU_BRX)
A_MSDU_BTX is the maximum A-MSDU size of the transmitter of the PPDUs
containing MPDUs with the Type subfield equal to Data, in octets
A_MSDU_BRX is the maximum A-MSDU size of the receiver of the PPDUs containing
MPDUs with the Type subfield equal to Data, in octets
MAC Hdr + A_MSDU_B MPDU pPPDU 8
PPDU Dur = -------------------------------------------------------------------------------------------------------------
- DSYM DUR + PHDUR
DataRate DSYM DUR
DSYMDUR is the duration of one PPDU payload symbol for the expected PHY
format of the PPDUs containing MPDUs with the Type subfield equal
to Data, in seconds. If multiple symbol durations are possible, then the
shortest symbol duration is assumed
DataRate is calculated using equation Equation (R-2), in b/s
NSS_max Ntone-
--------------------------------------------
DataRate = min(log 2(1 + SNR_tone) MaxBitsPerSc) (R-2)
DSYM DUR
where
RSSI + P adjust
-----------------------------------
10
SNR_tone = 10
RSSI is the RSSI of Beacon or Probe Response frames received from the STA with the
MAC address that matches the PeerMACAddress in the MLME-ESTIMATED-
THROUGHPUT.request primitive, in dBm
P_adjust is the implementation specific power adjustment parameter used to convert RSSI
into SNR, as well as take into account potential transmit power differences
between Beacon/Probe Response frames to data frames, in dBm.
NSS_max is the maximum number of spatial streams allowed in the link based on the
capabilities of the two STAs
Ntone is N_SD × N_Seg if the expected PPDU format is VHT, and N_SD otherwise,
where N_SD is defined as number of subcarriers in Table 17-16 for non-HT
format, NSD in Table 19-6 for HT format and NSD in Table 21-5 for VHT
format. If multiple PPDU bandwidths are available, the N_SD of the widest
3508
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
possible PPDU bandwidth allowed between the two STAs based on capabilities
is assumed.
40
------ if 256-QAM 5/6 modulation is allowed in the link
6
MaxBitsPerSc = 6 if 256-QAM 3/4 modulation is allowed in the link
but 256-QAM 5/6 modulation is not
5 otherwise
Note that some of the parameters of Equation (R-2) have values that are AC dependent.
3509
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex S
(informative)
Mesh BSS operation
S.1 Clarification of mesh Data frame format
A mesh Data frame consists of MAC header, frame body, and the FCS. The fields in the MAC header are
described in 9.2.3.
In a mesh Data frame containing a single MSDU, the Mesh Control field is placed immediately before the
Data (PDU) in the encrypted Frame Body. The Data (PDU) comprises the LLC/SNAP headers and the
higher layer data. This is shown in the example frame format for a CCMP-128-encrypted mesh Data frame
containing a single MSDU in Figure S-1.
When the mesh Data frame is fragmented, only the first fragment contains the Mesh Control field.
6 or up to
Octets: 2 2 6 6 6 2 6 2 4 8 18 2304 8 4
Frame Body
Frame Control
Duration/ID
Address 1
Address 2
Address 3
Address 4
Sequence
CCMP Header
Mesh Control
DATA (PDU)
Control
Control
Control
QoS
FCS
HT
MIC
MAC Header, Not encrypted Encrypted using
CCMP-128
Figure S-1—Format of a CCMP-128-encrypted mesh Data frame containing a single MSDU
NOTE—A DMG STA does not send mesh Data frames, and all other STAs have a maximum MSDU size of 2304 octets
(see Table 9-19).
S.2 Operational considerations for interworking
S.2.1 Formation and maintenance of the IEEE 802.1D spanning tree
No special action is required to support formation of the IEEE 802.1D spanning tree. Spanning tree control
messages are typically delivered to bridges in group addressed frames. These messages are Data frames
from the point of view of the mesh BSS.
3510
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
S.3 Power save parameters selection
S.3.1 General
Power save mechanisms enable mesh STA operation in doze state. In doze state a mesh STA might set the
transceivers off. The power save mechanism might adjust the mesh power management mode of a mesh
STA for various reasons that are beyond the scope of the standard, including but not limited to traffic load or
scanning and network maintenance needs.
This annex specifies recommendations on how a mesh STA selects mesh power management modes based
on traffic load, recommendations on how to do scanning in mesh BSSs that might contain mesh STAs in
light or deep sleep mode, and recommended default values for power save related parameters.
S.3.2 Selecting the mesh power management mode based on traffic load
A mesh STA might adjust its mesh power management mode based on the traffic load or the QoS
requirements of the forwarded traffic. If a mesh STA has high traffic load or if a mesh STA is congested, the
mesh STA should operate in active mode on the corresponding mesh peering to reduce delays or overhead
that might be created by the operation in light or deep sleep mode.
A mesh STA might consider staying in active mode for all peer mesh STAs, even if only a single link is
congested. When mesh STA operates in active mode, the mesh STA might receive frames at any time and
mesh peer service periods might be triggered on demand, as in case of an AP that receives a trigger frame at
times controlled by a non-AP STA.
If traffic load is moderate or low and best effort data is transmitted, a mesh STA might consider staying in
light sleep mode for all or some mesh peerings. The mesh STA in light sleep mode for a mesh peering
receives beacons from the peer mesh STA with periodic indication of buffered traffic.
If traffic load is low or no traffic is transmitted, a mesh STA might consider staying in deep sleep mode for a
mesh peering. The mesh STA does not need to wake up to receive a beacon from the peer mesh STA to
which it is in deep sleep mode.
The mesh STA might use deep sleep mode to control the number of times it enters the awake state to receive
Beacon frame from a peer mesh STA. If the mesh STA is in deep sleep mode for all of its mesh peering, the
mesh STA needs only to remain in awake state during its own beacon transmission and mesh awake
window.
The mesh STA that forwards real time traffic (AC3 or AC2 with EDCA) should be in active mode for the
corresponding link. A mesh STA forwarding real time traffic with EDCA might stay in light or deep sleep
mode for the corresponding link, if the mesh STA is capable of initiating mesh peer service periods
frequently and the other forwarding peer mesh STAs are in active mode. Poor handling of the mesh power
management modes might result to delays and inappropriate QoS of the forwarded MSDUs.
S.3.3 Scanning of mesh BSSs
A mesh BSS might have mesh STAs that alternate awake state and doze state. With active scanning only
devices in awake state at the transmission time of Probe Request frame might be found. However, with
passive scanning also mesh STAs in light or deep sleep mode for a mesh peering can be found.
Since mesh STAs in light or deep sleep mode might transmit beacons at long intervals, a mesh STA seeking
for candidate mesh STAs for a new mesh peerings should perform passive scanning relatively for a longer
3511
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
time compared to passive scanning in BSS infrastructure mode. Mesh STAs in light or deep sleep mode with
long DTIM interval might not be discovered with short scanning durations. Mesh STAs that operate in light
or deep sleep mode for a mesh peering might use a short DTIM interval, if they intend to establish new mesh
peerings.
S.3.4 Default parameters
The following are the recommended default values for power save related parameters for mesh STAs:
Table S-1—Default parameters for mesh STAs that intend to operate in
light or deep sleep mode for mesh peerings
For moderate power save For aggressive power save
Beacon period 200 TU 800 TU
DTIM Period 4 1
Mesh awake window 10 TU 10 TU
A mesh STA that is eager to conserve power and likely to remain in deep sleep mode with most of the mesh
peerings should utilize the value from aggressive power save parameters.
Although mesh STAs might utilize individual parameters regardless of the parameters used by neighbor
mesh STAs or peer mesh STAs, each implementer should recognize balance between the power save
efficiency and delay in the service initiation.
S.3.5 MSDU forwarding in an MBSS containing mesh STAs in light or deep sleep
mode
The battery powered mesh STAs should avoid forwarding MSDUs, to avoid power consumption and
possible additional delays and inefficiencies that power save mechanisms might cause. If a light or deep
sleep mode mesh STA forwards MSDUs, it should select its mesh power management mode based on the
traffic load and the traffic type as described in S.3.2.
A mesh STA might save power by selecting the light or deep sleep mode for a mesh peering as follows:
— A mesh STA that is “mains powered” might apply light or deep sleep mode if it does not have
MSDUs to forward
— A mesh STA that is “battery powered” might freely use all mesh power management modes
Mesh STAs that are in light or deep sleep mode for a mesh peering might degrade the corresponding link
metric value. The use of worse metric values reduces the probability of a link being used for MSDU
forwarding. If the mesh STA will operate in active mode for the link in forwarding path, it should apply the
link metric value without degradation.
S.3.6 Synchronization maintenance of mesh STAs in deep sleep mode
A mesh STA in deep sleep mode for a mesh peering might not receive Beacon frames from the
corresponding peer mesh STA, but the mesh STA is required to maintain synchronization with the neighbor
peer mesh STAs. Neighbor offset synchronization method imposes the maintenance of TSF offset values
3512
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
between neighbor peer mesh STAs, which generally requires the reception of Beacon frame or Probe
Response frame. The simplest way to maintain the synchronization is that the mesh STA in deep sleep mode
for a mesh peering listens to the corresponding peer mesh STA’s Beacon frame for certain periods and check
the TSF offset value.
S.4 SIV key wrapping test vector
This test vector is from the appendix of IETF RFC 5297.
Input:
-----
Key:
fffefdfc fbfaf9f8 f7f6f5f4 f3f2f1f0
f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff
Associated Data (ad):
10111213 14151617 18191a1b 1c1d1e1f
20212223 24252627
Plaintext:
11223344 55667788 99aabbcc ddee
S2V-CMAC-AES
------------
CMAC(zero):
0e04dfaf c1efbf04 01405828 59bf073a
double():
1c09bf5f 83df7e08 0280b050 b37e0e74
CMAC(ad):
f1f922b7 f5193ce6 4ff80cb4 7d93f23b
xor:
edf09de8 76c642ee 4d78bce4 ceedfc4f
double():
dbe13bd0 ed8c85dc 9af179c9 9ddbf819
pad:
11223344 55667788 99aabbcc ddee8000
xor:
cac30894 b8eaf254 035bc205 40357819
CMAC(final):
85632d07 c6e8f37f 950acd32 0a2ecc93
CTR-AES
-------
CTR:
85632d07 c6e8f37f 150acd32 0a2ecc93
3513
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
E(K,CTR):
51e218d2 c5a2ab8c 4345c4a6 23b2f08f
ciphertext:
40c02b96 90c4dc04 daef7f6a fe5c
output
------
IV || C:
85632d07 c6e8f37f 950acd32 0a2ecc93
40c02b96 90c4dc04 daef7f6a fe5c
S.5 Airtime link metric usage example
The airtime cost constants (Table 14-4) and estimates of the average data rate and frame error rate will vary
from one implementation and configuration of the IEEE 802.11 PHY and MAC to the other. While no
mechanism is defined to measure the average data rate and the frame error rate, numeric values are not
expected to exhibit large variations in amplitude over the lifetime of a path. Unstable measurements might
cause path selection instabilities.
An example of an airtime link metric is provided to illustrate how it might be calculated.
Assume a DSSS PHY with an average data rate of 1 Mb/s to a given neighbor and a frame size of 8192 bits.
The overhead O for the Data frame comprises the PHY preamble (144 µs) and the PHY header (48 µs). The
payload Bit is 8192 bits at an r of 1 Mb/s, or 8192 µs. The data transmission time is therefore 8416 µs. Other
transmission times for different frame types are calculated in the same way (based on their size, rate, and
overhead).
If RTS/CTS is used, the data transmission time (including PHY preamble and header) is 8416 µs, the RTS
transmission time (including PHY preamble and header) is 352 µs, the CTS frame transmission time
(including PHY preamble and header) is 304 µs, the Ack frame transmission time (including PHY preamble
and header) is 304 µs and the interframe spacing overhead is 390 µs. The total time, including overhead, is
9766 µs.
This airtime and overhead value is converted to units of 0.01 TU (10.24 µs), i.e., 953.71 (rounded to 954).
If the frame error rate to the neighbor is 0%, the metric is 954. If the frame error rate is 80%, the metric is
4769 (i.e., 953.71/(1–0.8), rounded).
S.6 Generation of proactive PREP elements in the proactive PREQ
mechanism of HWMP
S.6.1 General
In the proactive PREQ mechanism of HWMP, the generation of a proactive PREP element in response to the
receipt of a proactive PREQ element depends on the value of the Proactive PREP subfield in the received
proactive PREQ element (see 14.10.4.2). Furthermore, if the Proactive PREP subfield is 0, the mesh STA
3514
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
might respond with the proactive PREP element in case it needs a bidirectional path between the root mesh
STA and itself. This is usually the case if the mesh STA has data to be sent to the root mesh STA. This
clause provides a unified mechanism that controls the generation of proactive PREP elements in the
proactive PREQ mechanism of HWMP.
A proactive PREQ element is defined by all of the following:
— The Target Address is set to all 1s; and
— The TO subfield in the Per Target Flags field is 1.
S.6.2 Additions to forwarding information
The forwarding information to a root mesh STA contains two additional Boolean information fields. The
Proactive PREP field indicates whether the mesh STA will generate a proactive PREP element to the root
mesh STA in response to a proactive PREQ element (Proactive PREP = 1) or not (Proactive PREP = 0). The
Proactive PREP Sent field indicates whether the mesh STA has sent a proactive PREP element to the root
mesh STA (Proactive PREP Sent = 1) or not (Proactive PREP Sent = 0). Both fields are initialized with 0.
S.6.3 Actions when sending Data frames as source mesh STA
If a mesh STA receives proactive PREQ elements with the Proactive PREP subfield set to 0, the recipient
mesh STA sends a proactive PREP element before sending a Data frame as source mesh STA only if the
mesh STA has data to send to the root mesh STA, which requires establishing a bidirectional path with the
root mesh STA and the field Proactive PREP Sent of the forwarding information to the root mesh STA is not
set (=0).
If the mesh STA sends a Data frame as source mesh STA to the root mesh STA, the mesh STA sets the field
Proactive PREP of the forwarding information to 1.
S.6.4 Actions on receipt of a proactive PREQ element
If the mesh STA receives a proactive PREQ element, the field Proactive PREP Sent of the forwarding
information to the root mesh STA is set to 0. If the field Proactive PREP of the forwarding information to
the root mesh STA is 1, the mesh STA generates a proactive PREP element to the root mesh STA (see
14.10.10.3 Case D), sets the field Proactive PREP of the forwarding information to 0, and sets the field
Proactive PREP Sent of the forwarding information to 1.
If the Proactive PREP subfield of the Flags field of the received proactive PREQ element is 1, the mesh STA
sets the field Proactive PREP of the forwarding information to the root mesh STA to 1.
S.6.5 Generation of proactive PREP elements
A mesh STA will generate a proactive PREP element according to 14.10.10.3 Case D if one of the following
applies:
— [The mesh STA has received a proactive PREQ element] AND [in the forwarding information to the
root mesh STA of the proactive PREQ element, field Proactive PREP is set to 1 AND field Proactive
PREP Sent is set to 0].
— [The mesh STA has data to send to the root mesh STA, which requires establishing a bidirectional
path with the root mesh STA] AND [the field Proactive PREP Sent of the forwarding information to
the root mesh STA is not set (=0)].
3515
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
If the mesh STA generates a proactive PREP to the root mesh STA, the field Proactive PREP Sent of the
forwarding information is set to 1 and the field Proactive PREP of the forwarding information is set to 0.
S.7 Generation of PREQ elements in proactive RANN mechanism of HWMP
S.7.1 General
In the proactive RANN mechanism of HWMP, the generation of a PREQ element for root path confirmation
in response to the receipt of a RANN element depends on the path metric from the mesh STA to the root
mesh STA as computed by the RANN element propagation. However, the RANN mechanism does not set
up the necessary forwarding information. This is done with individually addressed PREQ elements. This
clause provides further details to the generation of individually addressed PREQ elements in the proactive
RANN mechanism of HWMP.
An individually addressed PREQ element is defined by the following:
— The Addressing Mode subfield in the Flags field is 1 (individually addressed).
S.7.2 Additions to forwarding information
The forwarding information to a root mesh STA contains an additional address field. The RANN element
Sender Address field contains the MAC address of the neighbor peer mesh STA that has sent the RANN
element with the best metric.
S.7.3 Actions when sending Data frames as source mesh STA
If the mesh STA sends a Data frame as source mesh STA to the root mesh STA, the mesh STA uses the
forwarding information to the root mesh STA. The RANN element Sender Address is not used for
forwarding mesh Data frames to the root mesh STA.
S.7.4 Actions on receipt of proactive RANN element
If the mesh STA receives a proactive RANN element, the field RANN element Sender Address of the
forwarding information to the root mesh STA is set to the sender of the RANN element if the metric to the
root mesh STA is better than the path metric of the existing mesh path in the forwarding information.
In this case, the mesh STA generates an individually addressed PREQ element to the root mesh STA—see
14.10.10.3 Case D (Root Path Confirmation (Original Transmission)). This individually addressed PREQ
element is not sent according to the general forwarding information. Instead, it is sent to the neighbor peer
mesh STA indicated in the RANN element Sender Address field.
Since all mesh STAs between the mesh STA and the root mesh STA have already a value in the RANN
element Sender Address field, the individually address PREQ element will eventually reach the root mesh
STA. Since the TO subfield in the Per Target Flags field is 1, only the root mesh STA will generate a PREQ
element as reply to the individually addressed PREQ element.
The individually addressed PREQ elements will set up forwarding information (that can be used for
forwarding mesh Data frames) from the root mesh STA toward the mesh STA that initiated the root path
confirmation in all intermediate mesh STAs according to the normal HWMP procedures.
3516
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Note, since the PREQ element is sent in an individually addressed frame, every sender of the individually
addressed PREQ element will be able to determine whether the next mesh STA toward the root mesh STA
has received the PREQ element.
The root mesh STA will generate a PREP element according to the normal HWMP procedures—see
14.10.10.3 Case A (Original Transmission).
S.7.5 Actions on receipt of a PREP element
The PREP element generated by the root mesh STA will be forwarded on the mesh path from the root mesh
STA to the mesh STA as set up by the individually addressed PREQ element. The PREP element will be
propagated and will eventually reach the mesh STA. The PREP element will set up forwarding information
(that can be used for forwarding mesh Data frames) toward the root mesh STA in the mesh STA that initiated
the root path confirmation and in all intermediate mesh STAs on this path according to the normal HWMP
procedures.
After establishing the forwarding information (mesh path) toward the root mesh STA, the path to the root
mesh STA is updated to the better one.
Note that since the PREP element is sent in an individually addressed frame, every sender of the PREP
element will be able to determine whether the next mesh STA has received the PREP element.
3517
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex T
(informative)
Overlapping BSS (OBSS) management
T.1 Introduction
When two or more BSSs overlap, the available bandwidth is shared and hence reduced for each BSS. The
basic access mechanism, such as DCF, is able to work across OBSSs. Similarly, if EDCA is used, the OBSS
might be considered a larger network, and access to the WM is basically shared according to the EDCA
access mechanism. Note that for both DCF and EDCA overlapping networks, the sharing is affected by the
relative traffic; and if more than two APs are sharing, the problem of “neighbor capture” might occur. The
neighbor capture effect might occur when a BSS is in the middle of two other BSSs that are hidden from
each other, where it might suffer a disproportionate degradation in throughput, relative to the total traffic in
all three BSSs. A particular problem arises when there is some expectation of QoS. If EDCA admission
control is in use, then it can be used to regulate the QoS traffic on its own BSS, but it might not take into
account the EDCA admitted traffic on an OBSS. The result is that the QoS is compromised if each BSS
admits traffic up to its local maximum. Similarly a BSS using HCCA might schedule traffic in its own BSS,
to “guarantee” a service, but, if not controlled, this might suppress overlapping EDCA admission control
BSS. Furthermore, if two HCCA BSSs overlap and they do not coordinate their scheduled TXOPs, then a
degradation of QoS might result. The features described in this annex have been introduced in order to allow
a degree of management for OBSSs and for mitigation of the basic problems outlined above.
T.2 QLoad Report element
T.2.1 General
The fields and their uses in the QLoad Report element are as follows:
— Potential Traffic Self field value represents the potential QoS traffic load that this AP is expecting
and is provided as an indication to other APs that might be considering selecting the same channel
and for sharing when an OBSS situation occurs. The Potential Traffic Self field also includes the
peak number of AC_VO and AC_VI EDCA streams.
— Allocated Traffic Self field value represents the total QoS traffic and the numbers of AC_VI and
AC_VO streams that are active at that time. This field is provided to enable an on-demand sharing
scheme. It might be used by the other APs in OBSSs to determine if the AP has either overallocated
in a proportional sharing scheme or is using an on-demand sharing scheme.
— Allocated Traffic Shared field contains the sum of the Allocated Traffic Self field values for OBSSs
and is used to protect an AP from the neighbor capture effect where an AP that has neighbors that
are hidden from each other. It indicates to other APs in OBSSs if this AP has either overallocated in
a proportional sharing scheme, or might be using an on-demand sharing scheme.
— EDCA Access Factor field value represents the total QoS traffic bandwidth requirement for all of
the APs in OBSSs and is used to indicate potential overallocation. It also enables a proportional
sharing scheme. The Potential Traffic Self fields from QLoad Report elements of nearby co-channel
APs are used for estimating the overhead bandwidth required due to EDCA contention and is used in
the determination of the EDCA Access Factor.
— HCCA Peak field value represents the total peak HCCA TXOP requirement for the BSS and is
provided so that other overlapping APs can determine whether the AP has overallocated.
3518
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
— HCCA Access Factor field contains the sum of all of the HCCA Peak field values in all of the
QLoad Reports of all of the overlapping APs, including its own. This value is used when HCCA
APs are sharing as defined in 11.28.2.
— Overlap field value is the number of other APs that are on the same channel and from which Beacon
frames are being regularly received. It might be used to aid the channel selection process.
T.2.2 Calculating medium time
This annex uses the function defined in Equation (T-1) for calculating and estimating medium times in both
ACM and non-ACM QoS modes:
mediumTime(s,d,m,p) = s ×pps × MPDUExchangeTime (T-1)
where
d -
pps = ------------ (T-2)
8 m
MPDUExchangeTime = duration(m,p) + SIFS + duration(14,p) (T-3)
duration() is the PLME-TXTIME primitive that returns the duration of a frame based on its payload size
and the PHY data rate employed.
s, d, m and p are parameters that are passed in to the mediumTime function
(Also see the definition of MPDUExchangeTime in 10.22.4.2.3.)
T.2.3 Calculation of potential traffic self
The Potential Traffic Self field value represents the sum of all of the streams derived from all of the potential
EDCA admission control and HCCA QoS traffic. The individual TSPEC elements provided by the non-AP
STAs are used by the AP to calculate mean, maximum, and minimum values for
— Medium time, in multiples of 32 µs per second, in the case of EDCA admission control
— HCCA medium time, in the case of HCCA; where HCCA medium time is the TXOP time scheduled
by the HC converted to multiples of 32 μs over a 1 s period, by dividing the scheduled TXOP time
by the SI that the HC has allocated
The AP maintains a tuple that contains the maximum values
from Allocated Traffic Self field. The values of this tuple are calculated using
a) The mean and standard deviation from the Allocated Traffic Self field that had the largest value of
the Mean subfield
b) The AC_VO Streams subfield from the Allocated Traffic Self field that had the largest value
c) The AC_VI Streams subfield from the Allocated Traffic Self field that had the largest value
This tuple is calculated over fixed, consecutive seven-day
periods and is reset at the start of each new period. If, at any time, any of the maximum values in the tuple
are greater than those in the corresponding subfields of the Potential Traffic Self field, then those fields in
the Potential Traffic Self field are set to the value(s) in the tuple. If the AP refuses an ADDTS request due to
a perceived overallocation (for example, step b) 4) in the proportional sharing scheme described in T.4.2.2),
then the AP adds the TSPEC values of the rejected request to the tuple.
3519
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
At the end of each seven-day period, if any of the maximum values in the tuple are less than those in the
corresponding subfields of the Potential Traffic Self field, then those subfields in the Potential Traffic Self
fields are set to the value(s) in the tuple.
NOTE It is not required that the start and end of the seven-day periods be synchronized across OBSSs. After the first
seven-day period, each AP advertises its correct potential load irrespective of its start time.
TSPECs provide for mean, maximum, and minimum bit rate values, which allow for statistical multiplexing
of streams. The result of summing multiple streams is a composite stream, which should be reported in the
Potential Traffic Self field. The summing of streams to produce a composite stream is achieved by using the
mean and standard deviation of each stream.
The mean (MEAN), maximum (MAX), and minimum (MIN) values of the medium time or HCCA medium
time should be calculated using the values provided in the individual TSPECs, as follows:
For a TSPEC for stream, i, the mean value, μ, is:
MINi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Minimum Data Rate,
Minimum PHY Rate) (T-4)
MEANi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Mean Data Rate,
Minimum PHY Rate) (T-5)
MAXi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Peak Data Rate,
Minimum PHY Rate) (T-6)
μi = MEANi (T-7)
If the Minimum Data Rate and Peak Data Rate fields were provided in the TSPEC element, σ is:
σi = 0.25 MAX i – MIN i (T-8)
Else if the Peak Data Rate field was provided in the TSPEC element, σ is:
MAX i – MIN i
σi = --------------------------------
- (T-9)
2
Otherwise:
σi = 0 (T-10)
When the non-AP STA does not have any active TSPECs, the should AP monitor the mean and maximum
frame reception and transmission rates for AC_VI and AC_VO (for example, by regular sampling of
changes to dot11QosMPDUsReceivedCount and dot11QosTransmittedFrameCount of each AC) to
calculate the potential load information as follows:
For a QoS traffic capability, the mean value, μ, is:
μ0 = mediumTime(dot11DefaultSurplusBandwidthAllowance/100,
dot11STAStatisticsAverageMSDUSizeVideo,
MAXt[VI],dot11STAStatisticsAverageBitrateVideo) (T-11)
3520
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
μ1 = mediumTime(dot11DefaultSurplusBandwidthAllowance/100,
dot11STAStatisticsAverageMSDUSizeVoice,
MAXt[VO],
dot11STAStatisticsAverageBitrateVoice) (T-12)
and the standard deviation, σ, is:
σ0 = 0 (T-13)
σ1 = 0 (T-14)
The values reported in the Potential Traffic Self field represent the composite stream of all of the individual
streams of all associated STAs, and this composite stream should be calculated as follows:
Potential traffic self mean is:
μtot = Σμi (T-15)
Potential traffic self standard deviation:
σtot = 2 (T-16)
i
T.2.4 Calculation of allocated traffic self
The Allocated Traffic Self field value represents the total BSS load of all streams that the AP has allocated at
any one time and the number of AC_VI and AC_VO streams that make up that total. The AP should
calculate the mean and standard deviation using the Minimum Data Rate, Mean Data Rate, and Peak Data
Rate fields of admitted TSPECs and to recalculate the Allocated Traffic Self field value as each TS is added
or deleted. The values of the Mean and Standard Deviation subfields placed in the Allocated Traffic Self
field for i allocated streams should be calculated using Equation (T-17) to Equation (T-24).
MINi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size,
Minimum Data Rate, Minimum PHY Rate) (T-17)
MEANi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size,
Mean Data Rate, Minimum PHY Rate) (T-18)
MAXi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size,
Peak Data Rate, Minimum PHY Rate) (T-19)
If TSPECi has the Minimum Data Rate and Peak Data Rate fields populated, σ is:
σi = 0.25 MAX i – MIN i (T-20)
Else if TSPECi has the Mean Data Rate and Peak Data Rate fields populated, σ is:
MAX i – MEAN i
σi = --------------------------------------
- (T-21)
2
Otherwise:
σi = 0 (T-22)
3521
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Mean = Σμi (T-23)
Standard deviation = 2 (T-24)
i
When admission control is not used, the AP should monitor the mean and maximum frame reception and
transmission rates for AC_VI and AC_VO (for example, by regular sampling of changes to
dot11QosMPDUsReceivedCount and dot11QosTransmittedFrameCount of each AC). The MAX, MEAN,
and standard deviation (STDEV) at time t for access category AC are as given in Equation (T-25),
Equation (T-26), and Equation (T-27).
MEANi = o (duration(s, b) + SIFS + duration(14,b)) pt (T-25)
MAXt is the maximum value of MEANt since MLME-START.confirm
MAX t – MEAN t
STDEVt = --------------------------------------
- (T-26)
2
where
d
p t = ----- dot11QosMPDUsReceivedCount AC + (T-27)
dt
dot11QosTransmittedFrameCount AC –
dot11QosFrameDuplicateCount AC
o = dot11DefaultSurplusBandwidthAllowance
s = dot11STAStatisticsAverageMSDUSizeVideo
b = dot11STAStatisticsAverageBitrateVideo
duration() is the PLME-TXTIME primitive that returns the duration of a packet based on its payload size
and the PHY data rate employed
NOTE The differentiation above calculates the frames per second for the given AC.
T.2.5 Calculation of allocated traffic shared
The Allocated Traffic Shared field value is the sum of the values expressed in the Allocated Traffic Self
fields of all APs in OBSSs, including in its own Allocated Traffic Self field. The values of the mean μ and
standard deviation σ, placed in the Allocated Traffic Shared field, for n OBSSs should be calculated using
Equation (T-28) and Equation (T-29).
μ = Σμn (T-28)
σ= 2 (T-29)
n
T.2.6 Calculation of EDCA Access Factor
The EDCA Access Factor is the total traffic requirement for all of the OBSSs. The value of EDCA Access
Factor might be greater than 1. The EDCA Access Factor should be calculated from the addition of all of the
Potential Traffic Self fields of the APs that are overlapping as follows:
3522
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
First calculate the overlap traffic for all of the APs in OBSSs. Each AP notes the reported Potential Traffic
Self fields for every OBSS, including the AP’s own Potential Traffic Self field, and calculates the maximum
traffic of the composite stream, using Equation (T-30), Equation (T-31), and Equation (T-32).
Overlap traffic = μtot + 2 σtot (T-30)
where, for i Potential Traffic Self fields
μtot = Σμi (T-31)
σtot = 2 (T-32)
i
This overlap traffic value is in multiples of 32 µs per second.
The following procedure should be used to calculate the EDCA Access Factor:
a) Sum the AC_VI and AC_VO priority streams reported in the Potential Traffic Self fields of its own
QLoad report and all of the QLoad reports of APs in OBSSs, and determine the EDCA Overhead
Factor as recommended in T.2.7.
b) Multiply the overlap traffic and the resulting EDCA Overhead Factor together. This value represents
the total overlap traffic requirement for the OBSSs in multiples of 32 µs per second.
c) Convert the total overlap traffic to a fraction (seconds per second) by multiplying by 32 × 10-6.
d) Round the resulting fraction value rounded down to a multiple of 1/64.
For example, if the total overlap traffic is 74 268 (32 µs/s), this is 2.376 576 (seconds/second). Now
2.376 576 × 64 = 152.1 rounded to 152. Hence, the EDCA Access Factor octet, in this case, would be
1001100 (152 in decimal, representing the fraction 152/64).
T.2.7 EDCA Overhead Factor
The Potential Traffic Self field also includes the number of AC_VI and AC_VO streams that make up the
composite stream. The recommended calculation for medium time for an admitted EDCA is given in K.2.2.
This value includes the duration of the packet plus SIFS and Ack frame times. The medium time, therefore,
does not include the access time. For example, for a single stream, between each transmitted packet, there is
a time period due to SIFS, AIFSN, and contention window, and for two or more streams, there is also the
time when each packet is delayed while another packet is being transmitted. Hence, in order to calculate the
total time or bandwidth required to service multiple EDCA streams, an overhead is present.
A fixed value of 1.34 should be used for EDCA Overhead Factor. The value of the EDCA Overhead Factor
is dependent upon many factors, including
— Number and mix of streams, voice and video
— Mixture of PHY rates and PHYs
— Mixture of streams’ data rates
— Use and mix of aggregated MSDUs
— Choice of EDCA parameters including different settings in OBSSs
Based on a range of simulations, the value of EDCA Overhead Factor is normally in the range 1.26 to 1.43.
These simulations, however, were not exhaustive and did not include the effects of hidden nodes and
non-IEEE 802.11 interference.
3523
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
T.2.8 Calculation of HCCA Access Factor
The HCCA Access Factor should be calculated as follows:
a) Sum the HCCA Peak field values in all of the QLoad reports of all of the APs in OBSSs, including
its own.
b) Convert the total peak traffic to a fraction (seconds per second) by multiplying by 32 × 10-6.
c) Round the resulting fraction value to the nearest 1/64 and enter the result into the HCCA Access
Factor field.
For example, if the total overlap traffic is 74 268 (32 µs/s), this is 2.376 576 (seconds/second). Now
2.376 576 × 64 = 152.1 rounded to 152. Hence, the HCCA Access Factor octet, in this case, would be 152
(representing the fraction 152/64).
T.3 Channel selection using QLoad report
T.3.1 General
In addition to the channel selection described below, it is advised that other factors such as traffic from
IBSSs, energy from non-IEEE-802.11 systems, and device constraints on the AP or STAs anticipated within
the BSS be considered, and regulatory constraints need to be complied with.
The most effective mitigation to OBSS is for an AP to operate on channels that are free or that are occupied
by another AP that is not fully loaded with QoS traffic. In the absence of a centralized channel assignment
algorithm, an AP should use the Overlap and Potential Traffic Self fields of the QLoad Report element as
part of its channel selection procedure. An AP might use the Overlap field and Potential Traffic Self field
information when deciding the best channel to select. If there are sufficient channels for an AP to find a
channel with no other APs within range, then an AP is advised to select one of them.
When selecting a channel, the AP should scan to see whether there is a free channel taking account of BSS
channel width and channel spacing. If a free channel is not available, then it is advised to select channels that
have the least number of QoS APs present. There might be more than one channel with the same number of
QoS APs present. At this point, the AP is advised to select, in turn, the candidate channels and send a QLoad
Request frame to each AP on that channel. The AP is advised to examine the Overlap and Potential Traffic
Self fields of the QLoad Report element to make its final selection.
T.3.2 AP with admission control mandatory
If no “empty” channels are available, then an AP with the ACM (admission control mandatory) bit in the
EDCA Parameter Set element set for AC_VI or AC_VO should implement a channel selection procedure to
share with one or more APs, in the following preference order:
a) Non-QoS AP where the EDCA Parameter Set element is not present in the Beacon frame
b) QoS AP with the ACM bit set for AC_VI or AC_VO and with an indication of support for QLoad
reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element)
c) QoS AP with an HC and with an indication of support for QLoad reporting (i.e., the QLoad Report
field equal to 1 in the Extended Capabilities element)
d) QoS AP with an HC and with no indication of support for QLoad reporting
e) QoS AP with the ACM bit set for AC_VI or AC_VO and with no indication of support for QLoad
reporting
3524
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
f) QoS AP where the EDCA Parameter Set element is present in the Beacon frame and the ACM bit is
not set for AC_VI or AC_VO
T.3.3 AP with an HC
If no “empty” channels are available, then an AP with an HC should implement a channel selection
procedure to share with one or more APs, in the following preference order:
a) Non-QoS AP where the EDCA Parameter Set element is not present in the Beacon frame
b) QoS AP where the EDCA Parameter Set element is present in the Beacon frame and the ACM bit is
not set for AC_VI or AC_VO
c) QoS AP with the ACM bit set for AC_VI or AC_VO and with an indication of support for QLoad
reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element)
d) QoS AP with an HC and with an indication of support for QLoad reporting (i.e., the QLoad Report
field equal to 1 in the Extended Capabilities element)
e) QoS AP with the ACM bit set for AC_VI or AC_VO and with no indication of support for QLoad
reporting
f) QoS AP with an HC and with no indication of support for QLoad reporting
T.3.4 Channel selection procedures
Channel selection should be performed as follows:
a) Create a list of the available channels. Typically this is the list of channels allowed by regulation in
the operating regulatory domain; however, this list might be modified by management policy (e.g.,
removing overlapping channels, avoiding radar detect channels).
b) Create an array for each available channel that allows the recording of the QoS AP count, ACM bit
count, HC count, overlap count, and potential load for that channel.
c) Step through the list of available channels, listening for beacons for at least
dot11OBSSScanPassiveTotalPerChannel TUs per channel.
d) Upon completion of the scan of a channel, process the beacons received on that channel, filtered to
the set of unique BSSIDs:
1) Using the capabilities signaled in the beacon, modify the QoS AP count, ACM bit count, HC
count, overlap count, and potential load of the channel array for the primary channel indicated
in the received beacon.
2) If the AP is using a channel bandwidth that is greater than the channel spacing (e.g., when using
the 2.4 GHz band or when the overlapping AP allows 40 MHz HT PPDUs in its BSS), also
update the channel array for channels that are affected by this OBSS. For example, a beacon
received on channel 2 indicating a 20 MHz BSS also affects channels 1, 3, and 4.
e) Upon completion of scanning all of the channels, the AP has information on the number of APs and
the potential load of each channel, including co-channel BSSs.
f) If the channel array indicates that there are channels with no other APs, one of these “empty”
channels should be chosen randomly.
g) Otherwise, create a list of candidate channels by selecting only the channels with the lowest number
of QoS APs. For example, if the channel scan procedure indicated that there were two QoS APs on
channel 3, three QoS APs on channel 6, and two QoS APs on channel 11, the list of candidate
channels would contain 3 and 11.
1) If this list contains one or more channels with non-QoS APs, then filter the list for the least
number of APs.
2) If this list contains more than one channel, one of these channels should be chosen randomly.
3525
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
h) If this list contains more than one channel and the AP has been configured to set the ACM bit for
AC_VI or AC_VO:
1) Filter the list for the minimum count of QoS AP where the EDCA Parameter Set element is
present in the Beacon frame and the ACM bit is not set for AC_VI or AC_VO.
2) If this list contains more than one channel, filter the list for the minimum count of QoS AP with
the ACM bit set for AC_VI or AC_VO and with no indication of support for QLoad reporting.
3) If this list contains more than one channel, filter the list for the minimum count of QoS AP with
an HC and with no indication of support for QLoad reporting.
4) If this list contains more than one channel, filter the list for the minimum count of QoS AP with
an HC and with an indication of support for QLoad reporting (i.e., the QLoad Report field
equal to 1 in the Extended Capabilities element).
5) If this list contains more than one channel, filter the list for the minimum count of QoS AP with
the ACM bit set for AC_VI or AC_VO and with an indication of support for QLoad reporting
(i.e., the QLoad Report field equal to 1 in the Extended Capabilities element).
i) If this list contains more than one channel and the AP has an HC:
1) Filter the list for the minimum count of QoS AP with an HC and with no indication of support
for QLoad reporting.
2) If this list contains more than one channel, filter the list for the minimum count of QoS AP with
the ACM bit set for AC_VI or AC_VO and with no indication of support for QLoad reporting.
3) If this list contains more than one channel, filter the list for the minimum count of QoS AP with
an HC and with an indication of support for QLoad reporting (i.e., the QLoad Report field
equal to 1 in the Extended Capabilities element).
4) If this list contains more than one channel, filter the list for the minimum count of QoS AP with
the ACM bit set for AC_VI or AC_VO and with an indication of support for QLoad reporting
(i.e., the QLoad Report field equal to 1 in the Extended Capabilities element).
5) If this list contains more than one channel, filter the list for the minimum count of QoS AP
where the EDCA Parameter Set element is present in the Beacon frame and the ACM bit is not
set for AC_VI or AC_VO.
j) If this list contains more than one channel, filter the list to the set of channels with the minimum
overlap count.
k) If this list contains more than one channel, filter the list to the set of channels with the minimum
potential load.
l) From the remaining channels in this list, randomly choose one of these channels.
T.4 Sharing in an OBSS situation
T.4.1 General
If the EDCA Access Factor is greater than one, then there is a potential overallocation of the WM. APs
should avoid overallocation in the channel selection process, but if overallocation exists, then a sharing
scheme should be used to provide each AP with a fair share of the bandwidth, but more importantly, so that
any already admitted or scheduled QoS streams are not impaired by the addition of streams from any OBSS.
The EDCA Access Factor, HCCA Access Factor, and Potential Traffic Self fields in the QLoad Report
element are provided to enable sharing schemes to be used.
The sharing scheme also protects an AP from the neighbor capture effect where it has neighbors that are
hidden from each other. A major objective of an OBSS sharing scheme is that if a QoS stream is allocated or
scheduled, then it is not compromised by the addition of further streams from any OBSS that would cause
the medium to be overallocated. This objective is achieved if the APs in OBSSs cooperate.
3526
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
T.4.2 Sharing schemes
T.4.2.1 General
Two sharing schemes are suggested: proportional sharing and on-demand sharing. In each sharing scheme,
the purpose is to keep the total allocated traffic to a value where overallocation does not occur. The absolute
maximum allocation is 1 s/s (100%). In the following descriptions of the two suggested sharing schemes,
this value is referred to as the maximum allocation value (MAV). It is suggested that in order to provide some
protection to non-QoS traffic, each AP select a value for MAV:
MAV = (M + 1)/(M + N + 1) s/s (T-33)
where
M is the number of overlapping APs that are robust AV streaming STAs
N is the number of overlapping APs that are not robust AV streaming STAs
There is no requirement that each AP select the same MAV.
T.4.2.2 Proportional sharing scheme
The proportional sharing scheme described in this subclause is an example of a static sharing policy, as
described in Table 9-226 and 11.28.2.2.
When using the proportional sharing scheme, the AP examines the sum of the EDCA Access Factors and
HCCA Access Factors in the QLoad reports from each OBSS, including its own Qload report, and
determines the maximum. This maximum value is termed the combined access factor. If the maximum value
from the combined access factor is less than or equal to MAV, the AP is advised to allocate only up to its
advertised potential traffic self traffic. If the maximum value from the combined access factor is greater than
MAV, then the AP is advised to allocate only up to a value of its potential traffic self divided by the
combined access factor, multiplied by MAV.
In the proportional sharing scheme, before an AP allocates a new medium time or schedules a new TXOP in
response to an ADDTS Request frame, it checks that this addition does not exceed its sharing limit, as
follows:
a) If the EDCA Access Factor is less than or equal to MAV, then the AP allocates up to its
advertised potential traffic self, with the composite stream (MAX traffic) calculated as shown in
Equation (T-34).
MAX traffic = μtot + 2 σtot (T-34)
b) If the EDCA Access Factor is greater than MAV, the AP carries out the following:
1) Calculate the peak traffic value of the potential traffic self using Equation (T-35).
Peak = μtot + 2 σtot (T-35)
2) Divide this value by the combined access factor and multiply by MAV. This value is termed the
maximum allowable potential traffic self traffic.
3) Calculate the resulting value of the allocated traffic self if the new TSPEC is
accepted, as explained in Equation (T.2.4), and then calculate the resulting peak value using
Equation (T-36).
Peak = μtot + 2 σtot (T-36)
3527
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
4) If the resulting peak value, calculated in step 3), is greater than the maximum allowable
potential traffic self traffic, then the AP is advised to reject the ADDTS Request frame.
5) If the resulting peak value, calculated in step 3), is less than the maximum allowable potential
traffic self traffic and the ADDTS Request frame is set for EDCA admission, then the AP is
advised to accept the request.
6) The AP then checks that it is possible to schedule TXOPs using the HCCA TXOP
advertisement as described in Equation (11.28.3).
If the new stream is allocated, then the AP updates the appropriate fields in its QLoad Report element.
T.4.2.3 On-demand sharing scheme
The on-demand sharing scheme described in this subclause is an example of a dynamic sharing policy, as
described in Table 9-226 and 11.28.2.2.
The on-demand sharing scheme is as follows:
a) Before allocating a new stream, the AP examines the Allocated Traffic Shared field values in the
QLoad reports from each OBSS, including its own Qload report, and selects the maximum
Allocated Traffic Shared field value that has the highest peak value, using Equation (T-37).
Peak = μtot + 2 σtot (T-37)
The AP also notes the number of AC_VI and AC_VO streams in this maximum Allocated Traffic
Shared field.
b) The AP adds the requested new stream (new) to the selected maximum Allocated Traffic Shared
field value (max) determined in step a), using Equation (T-38) and Equation (T-38).
μ = μnew + Peak (T-38)
σ= 2 + 2 (T-39)
new max
c) The AP then calculates the peak value for the new composite stream calculated in step b), using
Equation (T-40).
Peak = μ + 2σ (T-40)
d) Using the values of the AC_VI and AC_VO streams noted in step a), plus the stream represented by
the new stream, the AP determines the new EDCA Access Factor and then the combined access
factor, as described in T.4.2.2.
e) Multiply the peak value calculated in step c) by the EDCA Access Factor, determined in step d).
This value is the new peak traffic requirement.
f) If this peak traffic requirement value calculated in step e) is greater than MAV, then the AP is
advised to refuse to allocate the new stream.
g) If the peak value calculated in step e) is less than or equal to MAV and the new allocation is for an
EDCA admission ADDTS, then the AP allocates that new traffic.
h) If the peak value calculated in step d) is less than or equal to MAV and the new allocation is for an
HCCA ADDTS, the AP checks that it is possible to schedule TXOPs using the HCCA TXOP
advertisement as described in 11.28.3.
If the new stream is allocated, then the AP updates the appropriate fields in its QLoad Report element.
3528
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
The Allocated Traffic Self field in the QLoad Report element of a particular AP can be used by other APs as
an indication of whether an AP has overallocated or is using an on-demand sharing scheme.
If, using either the proportional or on-demand sharing schemes, an AP determines that the acceptance of a
TSPEC would exceed the available allocation, or if a non-AP STA has a TSPEC refused, the non-AP STA
could always request a new TSPEC that represents a lower medium time or TXOP. This request might be
used, for example, where the non-AP STA or AP has the ability to send a more compressed stream.
An AP might choose to use the on-demand sharing scheme until the maximum value of any access factor
field in the QLoad Report elements from each OBSS reaches MAV. Once this condition has occurred, the
AP could then use the proportional sharing for subsequent ADDTS requests.
T.5 Mitigating consequences of OBSS sharing in presence of
noncollaborating devices
The performance of the channel selection and HCAA TXOP negotiation procedures described in this annex
and 11.28 might become degraded by the presence of devices that willfully or accidentally behave in an
uncooperative manner.
It is suggested that implementations use additional heuristics (e.g., a history of collaboration, traffic
monitoring, device configuration, or a combination of such) to assess the accuracy of the information they
receive from neighboring APs in order to determine an appropriate collaboration strategy.
An AP that maintains historical information of collaboration results with its neighboring APs could use this
information to control its collaboration behavior. For example, an AP might choose to share a channel with
an AP that had a history of successful collaboration. In another example, an AP might choose to avoid
transmissions only during the HCCA TXOPs of neighboring APs with which it has a history of successful
HCCA TXOP negotiation.
When using HCCA TXOP negotiation, it is suggested that an AP perform some monitoring of the channel to
assess whether the HCCA AP with which it is collaborating is using its advertised HCCA TXOPs. If the
monitoring AP does not detect HCCA traffic during these advertised HCCA TXOPs, such a lack of traffic
might indicate that the neighboring AP is willfully or accidentally behaving in an uncooperative manner by
advertising HCCA TXOPs that it is not using, possibly as a method to suppress traffic in neighboring BSSs.
The monitoring AP might wish to ignore the HCCA TXOP advertisements from APs that do not appear to
be collaborating.
Some of the OBSS procedures use unauthenticated Beacon frames and Public Action frames, which are
susceptible to impersonation. If unauthenticated Beacon frames and Public Action frames are used, an AP
might suffer a denial of service attack by another device impersonating the AP. This denial of service attack,
due to the actions of the impersonating device, might cause neighboring APs to falsely ascertain the AP is
not collaborating.
An AP could enable protected HCCA TXOP negotiation and protected QLoad reporting to provide
protection against impersonation. The AP PeerKey protocol is used in the generation of the PMK to prove
that an AP has the private key that corresponds to its public key. Impersonation of protected HCCA TXOP
negotiation and protected QLoad report management from an AP is prevented while the AP maintains
possession of this private key and this private key is not possessed by any other devices.
3529
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex U
(informative)
Functions of the centralized coordination service root (CCSR)
Via unspecified means over the DS, a centralized coordination service root (CCSR) performs the following
functions:
— Allows APs to enroll or unenroll from the CCSS.
— Provides a directory service, wherein the CCSR responds to a directory service request that includes
a MAC address with an indication of whether the MAC address is an S-AP within the CCSS.
— Configures the beacon interval, ClusterMaxMem, Beacon SP duration, TXSS offset, TXSS CBAP
duration, and TXSS CBAP MaxMem (see 10.37.2.2) of each S-AP.
— Aligns the rate of increment of TSFs of S-APs within the CCSS.
— Configures the individual TSF offsets of each S-AP in order to minimize the temporal, spatial, and
frequency overlap of BHIs of the BSSs in the same CCSS.
— Provides to each S-AP the cluster time offset availability information from nearby co-channel
S-APs.
— Configures each S-AP with certain medium access policies for its centralized AP or PCP cluster (see
10.37.3.4). The CCSR is permitted to configure different S-APs with different medium access
policies.
— Configures each S-AP with a list of one or more channels in an operating class that the S-AP is
excluded from operating upon and that the S-AP advertises via the Channel Usage procedures (see
11.24.15). The excluded channels are available to STAs that are operating in the area covered by the
ECAPC, yet are not within the ECAPC.
3530
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
Annex V
(informative)
TSPEC aggregation for DMG BSSs
Examples of TSPEC aggregation include, but are not limited to, the following:
— Traffic streams between DMG STA A and DMG STA B, having an access policy of SPCA, even if
they flow in opposite directions, sharing an SP allocation created with DMG STA A as Source AID
and DMG STA B as Destination AID.
— Traffic streams between DMG STA A and other DMG STAs, having an access policy of EDCA,
even if they flow in opposite directions (some having DMG STA A as source and some having
DMG STA A as destination), sharing a CBAP allocation created with DMG STA A as Source AID
and broadcast Destination AID.
Figure V-1 and Figure V-2 show examples of TSPEC aggregation in a DMG BSS. Note that TSPEC 3 in
Figure V-1 (for both SPCA and EDCA cases) can flow only through an RD grant.
STA A
STA B
TSPEC 1
Destination AID: B TSPEC 3
Access Policy: SPCA Destination AID: A
(Service Period Channel Access) Access Policy: SPCA
(Service Period Channel Access)
SP Allocation
TSPEC 2
Source AID: A
Destination AID: B
Destination AID: B
Access Policy: SPCA
(Service Period Channel Access)
—TSPECs are added and deleted in any order,
without losing the allocation
—Allocation admission is by the AP or PCP; flow
admission is performed by the flow endpoints
STA A STA B
TSPEC 1
Destination AID: B TSPEC 3
Access Policy: EDCA Destination AID: A
(Contention‐based channel access)
Access Policy: EDCA
(Contention‐based channel access)
CBAP Allocation
TSPEC 2 Source AID: A DMG
Destination AID: C Destination AID: broadcast STA C
Access Policy: EDCA
(Contention‐based channel access)
Figure V-1—Example of TSPEC aggregation (SPCA and EDCA access policies)
3531
Copyright © 2016 IEEE. All rights reserved.
IEEE Std 802.11-2016
IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements
Part 11: Wireless LAN MAC and PHY Specifications
STA A
STA B
TSPEC 1
Destination AID: B TSPEC 4
Access Policy: SPCA Destination AID: A
(Service Period Channel Access) Access Policy: SPCA
SP Allocation (Service Period Channel Access)
TSPEC 2
Source AID: A
Destination AID: B
Destination AID: B
Access Policy: SEMM
(SPCA, EDCA mixed mode)
CBAP Allocation CBAP Allocation
TSPEC 3 Source AID: A Source AID: broadcast
Destination AID: C Destination AID: broadcast Destination AID: broadcast
Access Policy: EDCA
(Contention‐based channel access)
STA C
Figure V-2—Example of TSPEC aggregation (SPCA, EDCA, and SEMM access policies)
3532
Copyright © 2016 IEEE. All rights reserved.
*&&&
TUBOEBSETJFFFPSH
1IPOF 'BY
Ý*&&&